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

Robert Osfield robert.osfield at gmail.com
Fri Jul 25 06:00:09 PDT 2008


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
>
>



More information about the osg-users mailing list