> Hello Fred, > > > > Hi Sebastian, > > > > The full code is here: > > https://gitorious.org/fg/flightgear/blobs/next/src/Viewer/renderer.cxx#line704 > > I don't move renderbin-items but whole renderbins from a renderbin list to > > another. It seems to me > > that render bins contains state graphs and render leafs, so moving a render > > bin (or deleting one as > > I do now) moves or deletes associated states. > Okay, I used the code snippet you provided me and strangely i had to use > getCurrentRenderStage to get anything (instead of getRenderStage) > osgUtil::RenderStage* renderStage = cv->getCurrentRenderStage(); > So I more or less sticked to your code. I guess I'm doing something > fundamentally different with my camera setup (I'm not using > slave-cameras for instance)
The master camera has nothing to render (except the GUI and the HUD). The 3d is done in slaves, and they don't use the master scene graph, only their own scene graph. > > Note: I now delete states associated to transparent bins generated by the > > geometry pass because > > I have a second pass (the light pass) where I draw these transparent object > > a second time. The > > code that do the move before was there : > > https://gitorious.org/fg/flightgear/commit/c1137f371d1bc7c36ca6ba77420e63a96b443bb8 > > > > By the way, version 2.8 of Flightgear will be released on August 17th. It > > contains the deferred > > renderer codenamed 'Rembrandt' > Okay, but this means you have to traverse the whole graph again, right? > That's exactly what I want to prevent. > My problem is a extremely spanned graph with (too) many leafes, so at > least for opaque/transparent rendering I want to avoid some costs (which > are in the order of milliseconds). The graph is traversed a second time to render lights using node masks. Initially I wanted to render only lights but as they are embedded in models, the graph is traversed again and I had the side effect of redrawing transparent objects a second time, with bogus transparency. This is only the result of my incompetence, but I found easier to cancel rendering of transparent object in the first pass. So, for now, transparent render bins are removed from cv->getRenderStage()->getRenderBinList() . That removes all the states associated to transparent geometry. One thing to note is that Rembrandt requires from modelers that they register their transparent objects by explicitly setting the render bin. If not, all objects are directed by default to the opaque render bin and alpha tested. > > I guess I'll checkout project Rembrandt again and see what you are doing > differently. > By the way: Very nice work there! Thank you Regards, -Fred > > cheers > Sebastian > > > > Regards, > > -Fred > > > > ----- Mail original ----- > > De: "Sebastian Messerschmidt" <[email protected]> > > À: "OpenSceneGraph Users" <[email protected]> > > Cc: "Frederic Bouvier" <[email protected]> > > Envoyé: Lundi 30 Juillet 2012 18:31:23 > > Objet: Re: [osg-users] Separate rendering of renderbins > > > > Hello Fred, > > > > I know it's been a while, but right now I really want to solve this > > issue. Can you give me hint on this one? > > The problem seems to be, that moving the renderbin-items doesn't seem to > > move the associated state with them. I.e. they are not rendered in the > > camera I attach them too. > > > > cheers > > Sebastian > >> Hello, > >> > >> I've tried the approach but it didn't quite give me the results. > >> As proposed I've installed the 2 cullcallbacks and moved the > >> transparent bin from one camera to the other. After debugging I also > >> saw that the transparent bin of the second camera is indeed rendered, > >> but somehow I think all state associated with it is messed up. E.g. > >> the geometry is supposed to use a special shader, which is bound to > >> the second camera, but it seems it is never executed. > >> Any further hints? > >> > >> cheers > >> Sebastian _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
