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