Flash player lockup during Extrusion elevation generation for terrain meshes

[Ari Braginsky]

I'm working on pretty large bitmaps (1386x3318 3MB .gifs) for use as
terrain elevations and I'm noticing that the Flash player "locks up"
while it processes them in while creating data for the point array.
It takes about 4-5 seconds to process each.

---------------------
var mat:IMaterial = new BitmapMaterial(this.meshTextureBitmapData,
{smooth: true, debug: this.terrainDebug, repeat: false, precision: 0,
alpha: this.terrainAlpha} );

this.elevation = new away3d.extrusions.Elevation();

var pointArray:Array =
this.elevation.generate(this.elevationBitmapData,
this.heightMapColorChannel, curSubdivisionX, curSubdivisionY,
curScalingX, curScalingY, curElevation);

this.skinExtrude = new SkinExtrude(pointArray, { material:mat,
recenter:true, closepath:false, coverall:true, subdivision:1,
bothsides:false, flip:false } );

(this.skinExtrude as away3d.core.base.Mesh).pushback = true;

this.view.scene.addChild(this.skinExtrude);
---------------------

Is there anything to help alleviate the the lockup that the Flash
player goes through when it chews on all the point data in the
bitmap? Since AS3 is still single threaded I'm not sure what can be
done and I'm open to suggestions.

In the meantime I'm seeing what I can do to reduce the size of the
overall bitmaps and/or apply compression to get the overall sizes
down.

Thanks,
Ari Braginsky

[Ari Braginsky]

FYI, things take just as long for a 5KB all black image file as they
do for a 3MB image file with different colors.

Ari

[Fabrice]

no, got same issue while doing the greenplanet demo.
This only thing I can think of would be to add an interval in the loop.
but if you would win something here...?

I don't know what curSubdivisionX, curSubdivisionY are in your code...
if you set the resolution high, the more info needs to be generated...
instead, smooth your sourcemap
and low down the res. This class has one problem, it makes models too
nice for Flash :)

Also, a little trick I use very often with it for the colour info,
instead of loading an heavy bitmap just to compensate the pixel look,
load half of your size, say 1000x1000 instead of your 2800x2800, and
blow it up by code say 2,8 times. you get rid of the pixel look. yet
save enough details from the 1000x1000 to look good. This work
especially well when you set the stage quality to low.

-------------------------------------
btw, for the elevation users,
just updated it this morning (got twice the request this week), you
can now update the mesh by just passing same params and a modified
source bitmap.

I plan add some rects for this in the next weeks, so say you have a
lake in the middle, and you generate the height with some perlin
magic, only the rect you will pass will be updated... but I'll come
back to it when done...
that's also the reason why you'll need to pass all params again,
instead of just pass the bitmapdata. Its just not finished yet.

Fabrice

[Ari Braginsky]

Yep I'm now working on using a color map 50% in size and tweaking the
scale factor/etc.

Thanks for the advice,
Ari

[Ari Braginsky]

In my special case I can't really shrink the size of the bitmap since
scaling it up within the scene causes too much deformation for what
I'm using it for.

I had another idea that I've been able to prototype...

Since AS3 is single threaded and purely event driven, one might
"throttle" the execution of long running for loops with potentially
calculation intensive operations by using timers. This is especially
if the containing SWF framerate is set at a high value (> 30).

By setting the delay appropriately on a timer loop, every time the
Timer event is dispatched, one would perform whatever operation that
needed to run each successive step in the for loop. You would also
need to dispatch a TIMER_COMPLETE event once the boundary for the for
loop was reached and then the assigned listener function would stop
the timer/clean up listener.

After running a few tests in a SWF set at 35 FPS, CPU usage on a
simple for loop that counted from 0 to 10,000 went from 99% when the
timer delay was set to 1ms to under 20% when the timer delay was set
to 300ms (on my MacBook Pro).

An added benefit to using this method would be that you could assign
additional listeners that would watch for progress updates on the for
loop to be dispatched so that the progress could be reported back to
the user (loading bar, etc.).

One could wrap this logic into a "managed for loop class" that would
accept throttle speed, starting value, end value, increment value, and
function to call each time through the for loop. This class should
extend the Event class so that one could attach listeners/dispatch
events back.

Warning: due to the bugs that AS3 with regards to not being able to
completely remove child SWFs in certain cases, especially in those
that have timers, etc., one must be careful to clean up after
execution is done in addition to handling any errors that might arise.

Thoughts?
Ari

[Fabrice]

Just woke up and dunno why, remember your problem and got an answer
than should improve speed by a great factor. ( must be the coffee )
Implementation is almost a zero effort and I think nothing else would
beat it on the excec time.

What if the class would export the elevation array?
If you would at dev time trace the array, and save it as or in a class
then next export, you don't even need the sourcemap, you just pass the
array to the skinextrude class :)
No more parsing! No loading time! Lighter swf.

I will add for the next update to both elevation and elevationReader
this export to as3.
since I work on a demo where I use both, It should land pretty soon in
the svn.

In the meanwhile, just trace the array...

Fabrice

[Ari Braginsky]

Duh. This will work, just means a bit more logic needs to be added to
manage the saved array data somewhere as opposed to doing it on the
fly as the bitmap is loaded and processed.

I think I'll actually go with this method for now and worry about
fixing the more generalized case for heavy for loops later.

Thanks,
Ari

[Fabrice]

just check the new exporter... I've uploaded it in svn
check details on thread "Elevation to as3 added" posted this morning...

Fabrice