[Papervision3D] Optimizing performance: anything else I can do? [UPDATED! 20% performance boost]
john at easypeasy.co.uk
Wed May 13 03:47:22 PDT 2009
It looks very good.
Perched above, and hiding, the thumbprint images at the bottom there is
a segment of a circle showing in grey.
Alan Pinstein wrote:
> Just wanted to update everyone as I finally got some positive results,
> after many, many failures and about 20h down the tubes.
> 1. THE SHORT ANSWER: don't use transparent bitmaps!
> THE LONG ANSWER
> After hours of grueling research and several different attempts to
> solve the problem, I happened on a solution that gave me a 20% speed
> boost, which involved slicing my huge texture into 3 distinct textures
> and then using a combination of UV Mapping and assigning different
> materials to different faces to reduce texture size.
> So I thought I was really on to something, and set about to optimize
> the proper # of slices maximize performance. It took me a while, but I
> ended up with a generic algorithm that given #rows and #cols would
> "segment" the texture into row*col sections, splice up the "main"
> texture into smaller BitmapMaterials, and then apply them to the
> appropriate faces.
> After such a big effort I was excited when I finally got this
> algorithm working to see which slicing pattern provided the best
> performance. To my surprise, slicing the texture had -0- measurable
> impact on performance!
> This was quite a shocker, and thus I set out to figure out why did my
> "dirty proof-of-concept" get 20% performance boost when my nice clean
> implementation had no improvement?
> The answer, it turned out, was that I had changed something besides
> the # of textures in the "dirty proof-of-concept," but I didn't
> realize it at the time.
> We had been using BitmapDataUnlimited to manage our textures since
> they are bigger than the 2880x2880 limit in Flash 9. I turns out that
> the default bitmapData.transparent setting used by BitmapDataUnlimited
> is TRUE, rather than the Flash API default of FALSE. So the renderer
> was spending a lot of extra time messing with opacity (even though
> this was an opaque texture).
> In the end, adding a single FALSE parameter to a function yielded a
> 20-25% speed bump!
> Fortunately all Flash bitmaps default to transparent=false, but I
> figured people should be made aware of the implications of transparent
> bitmaps on performance in case they didn't know, or if anyone else is
> using BitmapDataUnlimited.
> So, thanks to all who chimed in, as ultimately the endeavors
> undertaken lead me to this fix.
> If you want to see the new faster player, check it out here:
> I have some other ideas for optimization that I thought of while in
> the trenches, and will be starting another thread for that...
> Thanks & Enjoy,
> Papervision3D mailing list
> Papervision3D at osflash.org
More information about the Papervision3D