Re: [osg-users] osgShadow and nested RTT-cams
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. 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. 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. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and nested RTT-cams
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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and nested RTT-cams
Hi Paul, What I know for certain is this: all shadow techniques stemming from ViewDependentShadowTechnique (StandardShadowMap, MinimalShadowMap, LispSM) are not compatible with nested cameras. And its a design flaw. Basically all these techniques allocate resources per View and views are recognized and indexed by cull visitor pointer. Unfortunately cull visitor of the view main camera also traverses nested cameras, so this means these nested cameras will use the same resources as main view camera. Since the shadow map depends on the camera view/projection, obiously shadowmaps, projection and texgen settings will not work correctly for nested cams. 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. I am however, not sure if I agree with your diagnosis on basic ShadowMap problem. Even if shadow map was rendered only once it should work well for both main and nested camera. Thats because ShadowMap projection does not depend on parent camera view or projection. Instead I suspect that shadow tex coord Texgen may be the problem. This is the only view dependent resouce here. Shadow texgen produces EYE_LINEAR coords. These coords depend on current model view matrix. I guess in Felix case main camera view matrix differs from nested camera view matrix. So texgen working for the main cam, does not produce correct coords for nested camera. These however are only theoretical deliberations. I have never tested or debuged such problem in practice, and I may be wrong. Cheers, Wojtek -Oryginalna wiadomość- From: Paul Martz Sent: Friday, May 13, 2011 11:55 PM To: OpenSceneGraph Users Subject: Re: [osg-users] osgShadow and nested RTT-cams Hi all -- While digging into an issue with multiple nested Camera nodes in 2.8.x, I came across this old thread in the archives and wanted to follow up, as it appears no one ever solved the mystery. I imagine there is more up-to-date information, or possibly even fixes on trunk? If so, please let me know. Camera nodes have a 1-to-1 mapping with RenderStage objects, and the first thing that happens in RenderStage::draw() is a check to ensure that the RenderStage only draws once per frame. (This is necessary because the RenderStage is inserted twice into the render graph: Once as a pre-render RenderStage, then once again as a regular child of the top-level Camera.) See RenderStage.cpp line 1109 on trunk. That's almost always what you want, except in Felix's case (see quoted text). In his situation, he has a scene that uses osgShadow (which uses a child Camera to implement the pre-render pass). Because a RenderStage can only draw once per frame, there is no way to render an osgShadow scene twice per frame: once to a texture (using an RTT Camera) and once again to some other framebuffer. Thoughts? -Paul On Aug 6 2009, 8:32 am, Felix Heide felix.he...@student.uni-siegen.de wrote: Hey folks, i have a problem with using theosgShadownodekit together with nestedRTT-Cams. A scenegraph as illustrated in the following image works fine: [Image:http://img7.imageshack.us/img7/5274/sgwithoutrttcam.png] But problems arise, when i use anRTT-Cam to render this scenegraph to an FBO. The FBO is used as a texture which is put on a simple quad-geode. The quad-geode is then rendered by the Viewers-Camera with orthogonal projection. In fact all this stuff is done to apply warping in the fragment shader pass. The resulting scenegraph is illustrated in the following figure: [Image:http://img9.imageshack.us/img9/8421/sgwithrttcam.png] The results are strange shadow artifacts. The shadows move with theRTT-Cameras viewpoint. In addition sometimes flickering in the shadows can be noticed. Except the shadows, the whole scene is rendered as it should be. At first, i thought it would have something to do with the shadowMap's cam. Line 192 in ShadowMap.cpp (osg 2.8.0) is Code: _camera-setReferenceFrame(osg::Camera::ABSOLUTE_RF_INHERIT_VIEWPOINT); If i understand the Reference Frame concept right, this line makes the shadowMaps cam inherit its viewpoint from the viewers cam and not the nestedrtt-cam, which would be the right one. So i tried to set the Referende Frame to ABSOLUTE_RF by accessing the current camera in a cull-callback attached to the ShadowScene node. That did not help. Hope someone has a tip for me. Cheers, Felix -- Read this topic online here:http://forum.openscenegraph.org/viewtopic.php?p=15921#15921 ___ osg-users mailing list osg-us...@lists.openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph... ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi
Re: [osg-users] osgShadow and nested RTT-cams
On 5/16/2011 6:07 AM, Wojciech Lewandowski wrote: Hi Paul, What I know for certain is this: all shadow techniques stemming from ViewDependentShadowTechnique (StandardShadowMap, MinimalShadowMap, LispSM) are not compatible with nested cameras. And its a design flaw. Basically all these techniques allocate resources per View and views are recognized and indexed by cull visitor pointer. Unfortunately cull visitor of the view main camera also traverses nested cameras, so this means these nested cameras will use the same resources as main view camera. I understand. I encountered the same issue in an early prototype version of what eventually became OcclusionQueryNode. Since the shadow map depends on the camera view/projection, obiously shadowmaps, projection and texgen settings will not work correctly for nested cams. Right, because (in the nested case), the CullVisitor address index looks up the wrong values. You get results, you just get the wrong results. 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(). I am however, not sure if I agree with your diagnosis on basic ShadowMap problem. Even if shadow map was rendered only once it should work well for both main and nested camera. Thats because ShadowMap projection does not depend on parent camera view or projection. I came to the same conclusion after I slept on this Friday night. One pass to create the shadow map should be sufficient. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and nested RTT-cams
On 5/16/2011 12:55 PM, Paul Martz wrote: Understood. This is ViewerBase::RenderingTraversals, where it calls renderer-cull(). That's implemented internally with SceneView::cull(). I meant the View, not the CullVisitor. Sorry for the mistake. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and nested RTT-cams
Hi Felix, Felix Heide wrote: no one has an idea ? Unfortunately, I don't have much to offer as I have no access to OSG source currently. But my intuition tells me that your case was not widely tested. I think you may have better chances when you setup your RTT rendering as separate slave camera instead of nested in the graph cam. See osg hud examples on how to setup RTT cam as osgViewer slave (I don't remeber exactly which one). Hope this helps Wojtek Lewandowski ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and nested RTT-cams
Hi Wojciech, Thank you very much ! I will try this ! Cheers, Felix -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16039#16039 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgShadow and nested RTT-cams
no one has an idea ? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=16009#16009 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgShadow and nested RTT-cams
Hey folks, i have a problem with using the osgShadow nodekit together with nested RTT-Cams. A scenegraph as illustrated in the following image works fine: [Image: http://img7.imageshack.us/img7/5274/sgwithoutrttcam.png ] But problems arise, when i use an RTT-Cam to render this scenegraph to an FBO. The FBO is used as a texture which is put on a simple quad-geode. The quad-geode is then rendered by the Viewers-Camera with orthogonal projection. In fact all this stuff is done to apply warping in the fragment shader pass. The resulting scenegraph is illustrated in the following figure: [Image: http://img9.imageshack.us/img9/8421/sgwithrttcam.png ] The results are strange shadow artifacts. The shadows move with the RTT-Cameras viewpoint. In addition sometimes flickering in the shadows can be noticed. Except the shadows, the whole scene is rendered as it should be. At first, i thought it would have something to do with the shadowMap's cam. Line 192 in ShadowMap.cpp (osg 2.8.0) is Code: _camera-setReferenceFrame(osg::Camera::ABSOLUTE_RF_INHERIT_VIEWPOINT); If i understand the Reference Frame concept right, this line makes the shadowMaps cam inherit its viewpoint from the viewers cam and not the nested rtt-cam, which would be the right one. So i tried to set the Referende Frame to ABSOLUTE_RF by accessing the current camera in a cull-callback attached to the ShadowScene node. That did not help. Hope someone has a tip for me. Cheers, Felix -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=15921#15921 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
