Hi Robert,
Completely understandable :-)
Regards,
Viggo
> Date: Fri, 25 Jul 2008 14:00:09 +0100> From: [EMAIL PROTECTED]> To:
> [email protected]> 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 <[EMAIL PROTECTED]>
> 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:
> [EMAIL PROTECTED]> > To: [email protected]> > 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> >> [email protected]> >>
> 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> >
> [email protected]> >
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org> >>
> >> _______________________________________________> osg-users mailing list>
> [email protected]>
> 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/_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
