Re: [osg-users] Sharing culling results among multiple cameras
Hi, Thanks a lot for this idea ! I'll try to do something based on it. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51457#51457 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Sharing culling results among multiple cameras
Frank Kane wrote on 2012-12-06: Let's say I have two cameras with identical view frusta, say a main camera and a camera for reflections that contain the same objects, only flipped. Except for in very specific situations, the objects in the reflection camera's frustum aren't going to be the same as the main camera's. Are you sure that this statement is true for your case? -- Bryan Thrall Principal Software Engineer FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Sharing culling results among multiple cameras
Hi Frank, On 6 December 2012 13:50, Frank Kane fk...@sundog-soft.com wrote: Let's say I have two cameras with identical view frusta, say a main camera and a camera for reflections that contain the same objects, only flipped. Is there any way I can avoid incurring the overhead of culling once for each camera, when the results will be the same for both? Basically I'd like to have two cameras share the results from one culling pass if possible. I wouldn't recommend trying to be clever by reusing culling results as the rendering backend is rather more sophisticated than just a list of results - the OSG's culling traversal creates a rendering graph that stores the projection and modelview matrices for each rendered Drawable along with the complete state graph required to make sure the Drawable is rendered with the correct OpenGL state. In your case the reflection will mean that the modelview matrix will be different for each rendered Drawable so will require a separate RenderLeaf that binds the projection and modelview matrices to the Drawable. This means even though the leaves and the bulk of OpenGL state is same the rendering graph will have to be different. In theory you could clone the rendering graphs and modify the duplicate and modify the modelview matrices to achieve the required result, but this requires a pretty deep understanding of the internals of the OSG's rendering back end is rather more complex than one might - the complexity comes from the flexibility of the OSG to manage dynamically multiple rendering stages and passes. This complexity is hidden from most users thanks to the scene graphs front end - users just worry about RenderBin's and in scene graph osg::Camera for render to texture effects. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Sharing culling results among multiple cameras
robertosfield wrote: I wouldn't recommend trying to be clever by reusing culling results as the rendering backend is rather more sophisticated than just a list of results Thanks Robert. I thought it might be more trouble than it would be worth. In a release build, the culling isn't too much of a hit really - there are better ways to speed up the reflection pass. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51446#51446 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Sharing culling results among multiple cameras
Hi, I'm intersted by this topic, because in my application, sometimes I need to render the same scene multiple times. For example, I render the scene a first time to generate a regular OpenGL image. Then I render with different shaders/textures to generate an image with computation results (often using a FBO and RGBA32F render target) So, between these different image, the only modified data are the StateAttribute : shaders, uniforms and textures. In this situation, is there anyway to share the culling results ? Maybe anyway to retrieve the RenderGraph and re-excute it ? Thank you! Cheers, Aurelien -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51447#51447 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Sharing culling results among multiple cameras
One approach is to create a custom RenderBin. The cull pass collects RenderLeaf objects and puts them into the bin. Each RenderLeaf contains a single Drawable along with its modelview matrix, projection martix, and state graph. You can tweak these properties at draw time, or even draw a leaf multiple times (if you override the right functions in RenderBin). I use custom RenderBins in a couple places in osgEarth - it's powerful once you get the hang of it :) Glenn Waldron / osgEarth.org / @glennwaldron On Thu, Dec 6, 2012 at 5:31 PM, Aurelien Albert aurelien.alb...@alyotech.fr wrote: Hi, I'm intersted by this topic, because in my application, sometimes I need to render the same scene multiple times. For example, I render the scene a first time to generate a regular OpenGL image. Then I render with different shaders/textures to generate an image with computation results (often using a FBO and RGBA32F render target) So, between these different image, the only modified data are the StateAttribute : shaders, uniforms and textures. In this situation, is there anyway to share the culling results ? Maybe anyway to retrieve the RenderGraph and re-excute it ? Thank you! Cheers, Aurelien -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51447#51447 ___ 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
