Hi,

On 5/16/2011 12:55 PM, Paul Martz wrote:
So I always recommended using Slaves cameras
instead of Nested cams because they have their own CullVisitors. If I would design this today, instead of CullVisitor I would probably use RenderStage to
index view resources.

Understood. This is ViewerBase::RenderingTraversals, where it calls
renderer->cull(). That's implemented internally with SceneView::cull().

Wojtek, in your experience, have you found that using multiple slave Cameras in this way causes StandardShadowMap (for example) to do a shadow map creation pass once for each slave Camera? There are multiple shadow map creation render passes done per frame, in other words.

Yes. It does. However StandardShadowMap is not intended for wide use in practice. This class is a direct equivalent of ShadowMap. It is fully functional, so can be used as a replacement of ShadowMap, but its main role is to lay foundation for View Dependent Shadow Techniques derived from it.

It seems like slave Cameras are really designed more for multiple displays, in which case you *do* want a shadow map created for each slave camera (so that it's generated and resident on the per-display GPU). But if the application uses slave Cameras rendering to a single window, the shadow map would still get generated multiple times per frame -- once per slave Camera -- which is undesirable.

And thats the goal for View Dependent techniques which optimize shadow map resolution by adjusting shadow projection to part of the scene visible per view. So each view will need a different shadow map. These classes were designed to work in multi screen / multi threaded configurations. But they would also work for RTT Slave cameras.

It seems like what we really want for shadow map creation is something that creates the shadow map once per frame#/GC pair. As far as I can tell, merely using slave Cameras doesn't achieve this. If I'm wrong about how StandardShadowMap works in the presence of multiple slave Cameras, please correct me.

In case of MinimalShadowMap or LispSM techniques even if views share GC there is an assumption they use different view/projection matrices so Shadow maps for each of them should be created anyway.

Cheers,
Wojtek

_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to