[Papervision3D] Optimizing performance: anything else I can do? [UPDATED! 20% performance boost]

[John McCormack]

Correct.
John

Alan Pinstein wrote:
> Flash bug. I'll bet you have 10,0,2,54.
>
> We have no idea how to download that runtime version or how to fix.
>
> Alan
>
> Sent from my iPhone
>
> On May 13, 2009, at 6:47 AM, John McCormack <john at easypeasy.co.uk> wrote:
>
>> It looks very good.
>> Perched above, and hiding, the thumbprint images at the bottom there 
>> is a segment of a circle showing in grey.
>> John
>>
>> 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:
>>>
>>> http://www.tourbuzz.net/public/vtour/full/2000
>>>
>>> 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,
>>> Alan
>>>
>>> _______________________________________________
>>> Papervision3D mailing list
>>> Papervision3D at osflash.org
>>> http://osflash.org/mailman/listinfo/papervision3d_osflash.org
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Papervision3D mailing list
>> Papervision3D at osflash.org
>> http://osflash.org/mailman/listinfo/papervision3d_osflash.org
>
> _______________________________________________
> Papervision3D mailing list
> Papervision3D at osflash.org
> http://osflash.org/mailman/listinfo/papervision3d_osflash.org
>
>