[Papervision3D] save render time

[Roland Sproll]

Hello Andy,

perhaps a similar question: for my current project I did this test to 
get a pseudo gradient dof texture (sorry for the bull navigation, please 
just click around):
http://rolandsproll.spot3.de/doftest01/
I did it by shifting the material bitmap of the planes, so I have a 
managable amount of polygons and can assign bitmaps depending on their 
row - better to see here:
http://rolandsproll.spot3.de/doftest02/
In my case I neiter touch the position of the camera, nor the position 
of the planes.
So my question is, may I speed performance a little bit by avoiding the 
matrix calculations of the vertices or does pv3d check if there is a 
movement or not?.

Thanks a lot.
Roland



Andy Zupko schrieb:
> You would only see about 1 less matrix calc per do3d by removing the 
> "world".  You still have to update your view matrices and handle the 
> projection of each individual vertex - which is where most of the math 
> hit comes in (before drawing).  BUT, if you really want to remove it, 
> you would need to either pass in a bool to do3d.project telling it not 
> to recalc its world matrix, or use some sort of singleton hack to flag 
> when to update or not.  It might be worth a shot - but in the grand 
> scheme of things you won't save too much.
>
> I'm not sure if there is anywhere in the materials you could save 
> on.   If you are using a moviematerial, you might want to make a 
> custom one that will only update its bitmap once per frame - but other 
> than that everything in materials is pretty stagnant (unless you are 
> using shaders... which would require a lot of work).
>
> hope that makes sense - i might be overlooking something?
>
> -andy
>
>
>
> On Apr 21, 2009, at 3:13 AM, FounderEffect wrote:
>
>>
>> Hey guys - Thanks for the feedback.
>>
>> It seems to me that there are some calculations in the render that 
>> only need
>> to be done once no matter how many viewports you have.
>>
>> One example that comes to mind is the world matrix calculation. It is a
>> recursive function that multiplies the local matrices of each object 
>> by its
>> parent until it gets to the root - and it is performed with every 
>> render.
>>
>> When we are squeezing out every ounce of performance we can get, it just
>> seems obscene to re-calculate the world matrices for every object for 
>> every
>> viewport.
>>
>> If there is no simpler way, it might be productive to look at the source
>> code and see if the render loop can be split into two - one part for
>> everything that only needs to be done once, and the other for those
>> calculations that pertain to a particular viewport/camera.
>>
>> I'm not enthusiastic about delving into the source, but if it can
>> significantly improve my chugging framerates then it is certainly
>> worthwhile. So if you have any ideas about the practicality of this, or
>> about what else goes on in the render that could be performed just 
>> once, I'd
>> very much appreciate it.
>>
>>
>>
>> Sandeep Menon wrote:
>>>
>>> I concur.
>>> I'm implementing virtually the same thing, except I need to support 
>>> four
>>> views of the same
>>> model, front, top, side, and a perspective view.
>>>
>>> Like you pointed out, the only way seems to be to call
>>> renderer.renderScene(..)
>>> 4 times, once for each view.
>>>
>>> It is hideously expensive.
>>>
>>> Would love to hear if any alternative technique exists.
>>>
>>>
>>>
>>> On Tue, Apr 21, 2009 at 10:30 AM, Steve D <kruass at gmail.com> wrote:
>>>
>>>> I don't know of any other way to do it.  Multiple viewpoints means
>>>> multiple
>>>> renderings.
>>>>
>>>> On Mon, Apr 20, 2009 at 1:40 PM, FounderEffect <rhaedes at gmail.com> 
>>>> wrote:
>>>>
>>>>>
>>>>> Hi all -
>>>>> Apologies if this has been dealt with elsewhere.
>>>>>
>>>>> I have created a model in PV which I would like to display from more
>>>>> than
>>>>> one perspective at the same time - say, one view from the front, 
>>>>> and one
>>>>> from the side.
>>>>>
>>>>> While I know I can use two cameras and two viewports and two 
>>>>> renders -
>>>>> is
>>>>> there a computationally cheaper way? Having two separate
>>>>> 'renderer.renderScene(scene, camera, viewport)' one after the other
>>>>> seems
>>>>> to
>>>>> involve a lot of expensive redundant calculation.
>>>>>
>>>>> Many thanks for any help you can provide!
>>>>> -- 
>>>>> View this message in context:
>>>>> http://www.nabble.com/More-than-one-simultaneous-view-of-same-scene-tp23144459p23144459.html 
>>>>>
>>>>> Sent from the Papervision3D mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>
>> -- 
>> View this message in context: 
>> http://www.nabble.com/More-than-one-simultaneous-view-of-same-scene-tp23144459p23151160.html 
>>
>> Sent from the Papervision3D mailing list archive at Nabble.com.
>>
>>
>> _______________________________________________
>> 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
>