[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 05:33:16 PDT 2008


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.comTo: osg-users at lists.openscenegraph.orgDate: Fri, 25 Jul 2008 10:42:08 +0200Subject: 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. 

_________________________________________________________________
Morsomme klipp, kjendiser og mer på MSN Video.
http://video.msn.com/?mkt=nb-no&from=HMTAG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20080725/596db61f/attachment-0003.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TransparencyGlitchFixNode.cpp
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20080725/596db61f/attachment-0002.asc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: TransparencyGlitchFixNode.h
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20080725/596db61f/attachment-0004.txt>


More information about the osg-users mailing list