[osg-users] Robert: I figured it out :-) (was: Is it possible to know when the node-graph is 'dirty'?)

Viggo Løvli vigigio at hotmail.com
Fri Jul 25 06:04:32 PDT 2008


Hi Robert,
 
Completely understandable :-)
 
Regards,
Viggo
> Date: Fri, 25 Jul 2008 14:00:09 +0100> From: robert.osfield at gmail.com> To: osg-users at lists.openscenegraph.org> Subject: Re: [osg-users] Robert: I figured it out :-) (was: Is it possible to know when the node-graph is 'dirty'?)> > Hi Viggo,> > I am trying to get a release out the door. I'm afraid I don't have the> the time tot go chasing up experimental user code.> > Robert.> > On Fri, Jul 25, 2008 at 1:33 PM, Viggo Løvli <vigigio at hotmail.com> wrote:> > Hi Robert,> >> > I have a very strange bug.> >> > The code I have written to render one bin twice works fine in the project> > code-base that I am working on. I took the class and integrated into the> > OSGForest example, and there it does not work as expected.> >> > In the OSGForest example:> > - The bin is rendered two times, as expected.> > - The state-set that is added to only one of the bins are now used when both> > bins are rendered. And there is the bug :-/> >> > I would appreciate it if you could take a look at the code and try it out.> >> > I have attached my class to this mail, and below here is the new main> > function for OSGForest. Just keep the rest of the osgforest.cpp file as it> > is. Only add the include and the green code at the bottom of main.> >> >> > #include "TransparencyGlitchFixNode.h"> >> > int main( int argc, char **argv )> >> > {> >> >> >> > // use an ArgumentParser object to manage the program arguments.> >> > osg::ArgumentParser arguments(&argc,argv);> >> >> >> > // construct the viewer.> >> > osgViewer::Viewer viewer(arguments);> >> >> >> > float numTreesToCreates = 10000;> >> > arguments.read('--trees',numTreesToCreates);> >> >> >> > osg::ref_ptr<ForestTechniqueManager> ttm = new ForestTechniqueManager;> >> >> >> > viewer.addEventHandler(new TechniqueEventHandler(ttm.get()));> >> > viewer.addEventHandler(new> > osgGA::StateSetManipulator(viewer.getCamera()->getOrCreateStateSet()));> >> >> >> > // add model to viewer.> >> > TransparencyGlitchFixNode* root = new TransparencyGlitchFixNode();> >> > root->addChild( ttm->createScene((unsigned int)numTreesToCreates) );> >> > viewer.setSceneData( root );> >> >> >> >> >> > return viewer.run();> >> > }> >> >> > Here is what to expect:> > - The forest will be rendered twice.> > - First pass will be additive blend without depth-buffer write.> > - Second pass shall be a normal render of the forest.> > - The bug is so that the state-set is used both times, so both get> > additive-blend.> >> > The additive-blend is something I have added only to ease the visual> > debugging. The final code shall only have the state for turning off> > depth-buffer write. If everything works smoothly then you are supposed to> > see the forest as normal but with high-lighting due to the additive blend at> > all places where the trees are transparent.> >> >> > Regards,> > Viggo> >> >> >> > ________________________________> > From: vigigio at hotmail.com> > To: osg-users at lists.openscenegraph.org> > Date: Fri, 25 Jul 2008 10:42:08 +0200> > Subject: Re: [osg-users] Robert: I figured it out :-) (was: Is it possible> > to know when the node-graph is 'dirty'?)> >> > Hi Robert,> >> >> Hi Viggo,> >>> >> The rendering backend uses ref_ptr<>'s so there shouldn't be any leak,> >> assigning the new RenderBin will lead to the previous one being> >> deleted.> >>> > Yep I figured out that one :-)> >> >> Rather than second guess what will be need might I suggest you> >> maintain a recycling list of ref_ptr<> to your custom RenderBin, then> >> traverse this list to find an entry that has a referenceCount() of> >> one, then take ownership of this.> >>> > I took into usage a std::list which starts off empty. I am currently> > counting how many times cull-traverse is called and increasing the list at> > need.> >> > Your idea of checking the reference count is better. It will make the system> > more robust.> > I will continue using a std::list for this.> > I will keep track of what was the last used element of the list, so when I> > need a new one then I will traverse the list from that point. This should> > increase the chance of finding a free entry immediately.> > If I parse through the whole list, then I will insert a new element to the> > list and use that one.> > The list will thus grow to the maximum needed size and stay there until the> > class is deleted. Future changes of number of cameras or what ever> > re-configurations that can cause one thread to hold data longer will thus> > automatically work.> >> > I am also ensuring that the original RenderBinList of RenderStage is not> > changed anywhere else than for element 10. I used to add a new bin to> > element 9, but that may be in usage already. Element 10 will instead point> > to a new bin that contain it's own bin #9 and #10. Both will point to the> > original content that RenderStage pointed to in it's bin #10.> >> >> Robert.> >> _______________________________________________> >> osg-users mailing list> >> osg-users at lists.openscenegraph.org> >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org> >> >> >> > ________________________________> > Få Hotmail du også. Windows Live Hotmail nå med 5000 MB gratis> > lagringsplass.> >> >> > ________________________________> > Windows Live Messenger på mobilen. Hold kontakten - hvor som helst når som> > helst.> > _______________________________________________> > osg-users mailing list> > osg-users at lists.openscenegraph.org> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org> >> >> _______________________________________________> osg-users mailing list> osg-users at lists.openscenegraph.org> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_________________________________________________________________
Hold kontakten med Windows Live Messenger.
http://clk.atdmt.com/GBL/go/msnnkdre0010000003gbl/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20080725/7323f5d3/attachment-0003.htm>


More information about the osg-users mailing list