Re: [osg-users] SceneView, RenderStage, existing Renderer and migrating 1.2 to 2.0
HI Michael, On 8/2/07, Michael Ebner [EMAIL PROTECTED] wrote: 1.) How do i get access to a RenderStage object, to set the sorting (i.e. osgUtil::RenderBin::SORT_FRONT_TO_BACK) so that my transparent object are rendered correctly? This is bit of backward solution to your transparent object problem - you aren't setting up your scene graph correctly, you should be setting the transparent subgraphs to fall into the transparent rendering bin via: stateset-setRenderingHint(osg::StateSet::TRANSPARENT_BIN); This is how the OSG has managed transparent state since the turn of this century. There is more fine grained control of render bins available via StateSet as well, but this is whole big topic, but on another occassion. First just fix your scene graphs. 2.) How can i get access to osgUtil::Statistics which i formerly accessed through RenderStage? In 2.0 osgViewer there isn't a convenient way to get access to the SceneView used for rendering. In the latest in SVN the Camera's now have a osgViewer::Renderer objects that you can use to get access to the SceneView and from their the RenderStage and the Statistics. 3.) Is there any way to use the new Multi-Threading Model, although the viewer is used as osgViewer::GraphicsWindowEmbedded gw = viewer_-setUpViewerAsEmbeddedInWindow(...) ? GraphicsWindowEmbedded does not support multi-threading. To use the new threading models you'll need to use a full blown GraphicsWindow implementation. 4.) What exactly is the advantage of putting sutff that is rendered outside of osg into the Camera's Pre/PostDrawCallback? (as mentioned in a previous posting) Previous posting? Lost me there, there are lots of postings on lots of topics, some mention Camera pre/post draw callbacks. As general note, integrating other OpenGL code with app can be done via custom Drawable (as per osgteapot example), via pre/post draw callbacks, via custom GraphicsOperations that you attach to the GraphicsWindow/GraphicsThread, or just in the main loop if you are running single theaded. The advantage of using subclassing OSG centric methods for adding your OpenGL code is that it can help manage the threading for you and ordering. Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SceneView, RenderStage, existing Renderer and migrating 1.2 to 2.0
Hello Robert, Robert Osfield wrote: stateset-setRenderingHint(osg::StateSet::TRANSPARENT_BIN); This is how the OSG has managed transparent state since the turn of this century. There is more fine grained control of render bins available via StateSet as well, but this is whole big topic, but on another occassion. First just fix your scene graphs. I was already setting the TRANSPARENT_BIN, but had z write disabled and the RenderBin::SORT_FRONT_TO_BACK did the sorting. But it is working now, thanks. GraphicsWindowEmbedded does not support multi-threading. To use the new threading models you'll need to use a full blown GraphicsWindow implementation. Could you explain that to me in more detail? I took a quick look at the GraphicsWindowEmbedded and GraphicsWindowWin32 implementation and this seems all to be about setting up a window and providing a context to the Viewer. The Viewer is handling the threads based on the context(s) provided, so it should not make a difference if he gets them from embedded or full blown GraphicsWindow? Or am i missing something here? I'm using SDL for window and input handling and read in: http://www.mail-archive.com/[EMAIL PROTECTED]/msg12744.html about a GraphicsWindowSDL class, is it going to be submitted to SVN? Thanks for help and keep up the good work! greetings, Michael. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SceneView, RenderStage, existing Renderer and migrating 1.2 to 2.0
HI Zullizum, Could you break the various problems you've seen out into separate emails send to osg-users so we can work through them one at a time, and if there are bugs resolve them before 2.2. Robert. On 8/3/07, Zulizman Berdu [EMAIL PROTECTED] wrote: Hi, Mine also might have the same problem. I'm using terrapage for terrain in my application and it works fine in OSG 1.2. When I switch to OSG 2.0 and OSG 2.1.3 the terrain start flickering. The code to avoid the auto calculate for near/far plane clipping seems not function anymore. The following are my code snippet, The code for OSG 1.2 : m_Viewer.getCullSettings().setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); The code for OSG 2.0 : m_Camera = m_Viewer.getCamera(); m_Camera-setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR); Is there anything that i miss here ? Hope this can be resolved before ver 2.2 coming out :) Thanks, -Zulizman- ___ 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] SceneView, RenderStage, existing Renderer and migrating 1.2 to 2.0
Hi, Mine also might have the same problem. I'm using terrapage for terrain in my application and it works fine in OSG 1.2. When I switch to OSG 2.0 and OSG 2.1.3 the terrain start flickering. The code to avoid the auto calculate for near/far plane clipping seems not function anymore. The following are my code snippet, The code for OSG 1.2 : m_Viewer.getCullSettings().setComputeNearFarMode(osgUtil::CullVisitor::DO_NOT_COMPUTE_NEAR_FAR); The code for OSG 2.0 : m_Camera = m_Viewer.getCamera(); m_Camera-setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR); Is there anything that i miss here ? Hope this can be resolved before ver 2.2 coming out :) Thanks, -Zulizman- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
