Re: [osg-users] Robert: I figured it out :-) (was: Is it possible to know when the node-graph is 'dirty'?)
Hi Robert, My current code instances a new one each cull traverse. I wonder if that means I get a sizeof(osgUtil::RenderBin) memory leak each cull-traverse? Anyway, I am going to try to multi-buffer it. I should be able to count the number of cull-traverse calls I get for each update tranverse. That (I guess) should tell me automatically how many instances of osgUtil::RenderBin that I would need. I will multiply it by two for double buffering and then it should work like a dream. Cheers, Viggo Date: Thu, 24 Jul 2008 17:53:57 +0100 From: [EMAIL PROTECTED] To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Robert: I figured it out :-) (was: Is it possible to know when the node-graph is 'dirty'?) On Thu, Jul 24, 2008 at 3:08 PM, Viggo Løvli [EMAIL PROTECTED] wrote: The only thing that annoy me now is the call to new(). Creating one bin as a member variable in my class and using it instead of the call to new cause the system to crash. Double buffering I guess. So maybe I can fix this by having two RenderBin instances in my class, and use them every other call? But, I suspect that it may not be enough? Would I need two per cull call that is ran per frame? Say that I in the future render with 4 different cameras and cull the world 4 times. Would I then need 4*2 bin instances to use instead of calling new()? The OSG's rendering backend is both very dynamic (created on demand on each frame) and flexible (it can be a huge range of bin configurations, potentially different on each frame) and the threading and multiple graphics context rendering are all thrown into this mix. This makes reuse of data something you have to be very careful about, in your case you'd either need to create on each new frame or multi-buffer. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _ Windows Live Messenger - også på mobilen. http://windowslivemobile.msn.com/Homepage.aspx?lang=nb-noocid=30032___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Robert: I figured it out :-) (was: Is it possible to know when the node-graph is 'dirty'?)
Hi Viggo, On Fri, Jul 25, 2008 at 7:22 AM, Viggo Løvli [EMAIL PROTECTED] wrote: Hi Robert, My current code instances a new one each cull traverse. I wonder if that means I get a sizeof(osgUtil::RenderBin) memory leak each cull-traverse? 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. Anyway, I am going to try to multi-buffer it. I should be able to count the number of cull-traverse calls I get for each update tranverse. That (I guess) should tell me automatically how many instances of osgUtil::RenderBin that I would need. I will multiply it by two for double buffering and then it should work like a dream. 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. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
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@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/msnnkdre001003gbl/direct/01/___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Robert: I figured it out :-) (was: Is it possible to know when the node-graph is 'dirty'?)
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 = 1;
arguments.read('--trees',numTreesToCreates);
osg::ref_ptrForestTechniqueManager 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]: [EMAIL PROTECTED]: 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@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-nofrom=HMTAG#include TransparencyGlitchFixNode.h
#include osg/Depth
#include osg/BlendFunc
#include osg/StateSet
#include osgUtil/CullVisitor
//
/*!
* \par Actions:
* - Creates one state-set that will be used multiple places.
* - Creates two helper-bins to be ready for use (see traverse function).
*/
TransparencyGlitchFixNode::TransparencyGlitchFixNode()
: osg::Group ()
, _stateSet ( 0 )
{
// Create the state-set that we use to turn off depth-buffer write
Re: [osg-users] Robert: I figured it out :-) (was: Is it possible to know when the node-graph is 'dirty'?)
Hi Robert,
Completely understandable :-)
Regards,
Viggo
Date: Fri, 25 Jul 2008 14:00:09 +0100 From: [EMAIL PROTECTED] To:
osg-users@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 [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 = 1;
arguments.read('--trees',numTreesToCreates);
osg::ref_ptrForestTechniqueManager 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: osg-users@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@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Få Hotmail du også. Windows Live
Hotmail nå med
Re: [osg-users] Robert: I figured it out :-) (was: Is it possible to know when the node-graph is 'dirty'?)
Hi Robert :-D
Thanx a lot for pointing in the right direction!!!
I can now enforce render-bin 10 to be rendered twice each frame with the needed
stateset changes. No node-mask stuff is needed. This is a completely
stand-alone fix :-)
This is what I did:
Camera is set up with a callback:
camera.setPreDrawCallback( new MyCallback() );
The callback struct's operator () looks like this:
virtual void operator () (osg::RenderInfo renderInfo) const
{
osg::Camera* camera = renderInfo.getCurrentCamera();
if( !camera )
{
return;
}
osgViewer::Renderer* renderer = dynamic_castosgViewer::Renderer*(
camera-getRenderer() );
if( !renderer )
{
return;
}
// HACK: This loop should not be here...
// Need to figure out which scene-view that is used (0 or 1).
// Renderer::draw() does it this way: sceneView =
_drawQueue.takeFront()
// _drawQueue is protected and not accessible through class
methods.
// This hack means we do the job below twice each frame.
//
for( int i=0; i2; i++ )
{
osgUtil::SceneView* sceneView = renderer-getSceneView( i );
if( !sceneView )
{
return;
}
osgUtil::RenderStage* renderStage = sceneView-getRenderStage();
if( !renderStage )
{
return;
}
osgUtil::RenderBin::RenderBinList binList =
renderStage-getRenderBinList();
if( binList.find(10) != binList.end() )
{
// Clone bin 10
osgUtil::RenderBin* clonedBin = new osgUtil::RenderBin(
*(binList[10].get()) );
// Clone the stateset
// TODO: Need to check that getStateSet does not return NULL.
osg::StateSet* stateSet = new osg::StateSet(
*(clonedBin-getStateSet()) );
// Ensure the cloned stateset is used in the cloned bin
clonedBin-setStateSet( stateSet );
// Cloned bin shall not write to the depth-buffer
stateSet-setMode( GL_DEPTH_TEST, osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE );
stateSet-setAttributeAndModes( new
osg::Depth(osg::Depth::LESS, 0.0, 1.0, false), osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE );
// Ensure cloned bin is rendered before bin 10.
binList[9] = clonedBin;
}
}
}
I am not sure how to solve the 0..1 loop marked by // HACK: in the source. Do
you know how I can know what SceneView that is used?
Do you see any other problems with this code?
Regards,
Viggo
Date: Wed, 23 Jul 2008 15:01:50 +0100 From: [EMAIL PROTECTED] To:
osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Is it possible
to know when the node-graph is 'dirty'? Hi Viggo, I think you are on
totally wrong take w.r.t trying to track changes in the scene graph, for
what is effectively just a custom transparent renderbin setup, and has
little to do with the scene itself. The way you should tackle it is to
customize the rendering backend so that the bins you require are built for
you. One one for instance would be to post process the RenderStage and its
contents after the CullVisitor has filled it in. Robert.
_
Windows Live Messenger - også på mobilen.
http://windowslivemobile.msn.com/Homepage.aspx?lang=nb-noocid=30032___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Robert: I figured it out :-) (was: Is it possible to know when the node-graph is 'dirty'?)
Hi Viggo,
I'd do this trick using a CullCallback on the topmost node of sub
graph that you won't to repeat rather than a pre draw callback. The
CullVisitor keeps track of the current RenderStage.
Robert.
On Thu, Jul 24, 2008 at 10:53 AM, Viggo Løvli [EMAIL PROTECTED] wrote:
Hi Robert :-D
Thanx a lot for pointing in the right direction!!!
I can now enforce render-bin 10 to be rendered twice each frame with the
needed stateset changes. No node-mask stuff is needed. This is a completely
stand-alone fix :-)
This is what I did:
Camera is set up with a callback:
camera.setPreDrawCallback( new MyCallback() );
The callback struct's operator () looks like this:
virtual void operator () (osg::RenderInfo renderInfo) const
{
osg::Camera* camera = renderInfo.getCurrentCamera();
if( !camera )
{
return;
}
osgViewer::Renderer* renderer = dynamic_castosgViewer::Renderer*(
camera-getRenderer() );
if( !renderer )
{
return;
}
// HACK: This loop should not be here...
// Need to figure out which scene-view that is used (0 or 1).
// Renderer::draw() does it this way: sceneView =
_drawQueue.takeFront()
// _drawQueue is protected and not accessible through class
methods.
// This hack means we do the job below twice each frame.
//
for( int i=0; i2; i++ )
{
osgUtil::SceneView* sceneView = renderer-getSceneView( i );
if( !sceneView )
{
return;
}
osgUtil::RenderStage* renderStage = sceneView-getRenderStage();
if( !renderStage )
{
return;
}
osgUtil::RenderBin::RenderBinList binList =
renderStage-getRenderBinList();
if( binList.find(10) != binList.end() )
{
// Clone bin 10
osgUtil::RenderBin* clonedBin = new osgUtil::RenderBin(
*(binList[10].get()) );
// Clone the stateset
// TODO: Need to check that getStateSet does not return
NULL.
osg::StateSet* stateSet = new osg::StateSet(
*(clonedBin-getStateSet()) );
// Ensure the cloned stateset is used in the cloned bin
clonedBin-setStateSet( stateSet );
// Cloned bin shall not write to the depth-buffer
stateSet-setMode( GL_DEPTH_TEST, osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE );
stateSet-setAttributeAndModes( new
osg::Depth(osg::Depth::LESS, 0.0, 1.0, false), osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE );
// Ensure cloned bin is rendered before bin 10.
binList[9] = clonedBin;
}
}
}
I am not sure how to solve the 0..1 loop marked by // HACK: in the source.
Do you know how I can know what SceneView that is used?
Do you see any other problems with this code?
Regards,
Viggo
Date: Wed, 23 Jul 2008 15:01:50 +0100
From: [EMAIL PROTECTED]
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Is it possible to know when the node-graph is
'dirty'?
Hi Viggo,
I think you are on totally wrong take w.r.t trying to track changes in
the scene graph, for what is effectively just a custom transparent
renderbin setup, and has little to do with the scene itself.
The way you should tackle it is to customize the rendering backend so
that the bins you require are built for you. One one for instance
would be to post process the RenderStage and its contents after the
CullVisitor has filled it in.
Robert.
Windows Live Hotmail på mobilen. Ha alltid e-posten din tilgjengelig.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Robert: I figured it out :-) (was: Is it possible to know when the node-graph is 'dirty'?)
Hi Robert,
I followed your advice added the code into the traverse function of my root
node.
Much of the code could now be removed, and I got rid of the 0..1 loop-hack
that I had to do earlier.
I think the new code looks very good. Do you see anything you would do
differently?
The new code looks like this:
void MyRootNodeClass::traverse( osg::NodeVisitor nv )
{
osg::Group::traverse( nv );
// Clone render-bin 10 if this is a cull visitor
if( nv.getVisitorType() == osg::NodeVisitor::CULL_VISITOR )
{
osgUtil::CullVisitor* cv = dynamic_castosgUtil::CullVisitor*( nv );
if( cv )
{
// Act if we have a RenderStage pointer
if( osgUtil::RenderStage* renderStage = cv-getRenderStage() )
{
// Get the render-bin list
osgUtil::RenderBin::RenderBinList binList =
renderStage-getRenderBinList();
if( binList.find(10) != binList.end() )
{
// Clone bin 10
osgUtil::RenderBin* clonedBin = new osgUtil::RenderBin(
*(binList[10].get()) );
// Clone the state-set
osg::StateSet* originalStateSet = clonedBin-getStateSet();
osg::StateSet* stateSet = (originalStateSet) ? new
osg::StateSet( *(originalStateSet) ) : new osg::StateSet();
// Ensure the cloned state-set is used in the cloned bin
clonedBin-setStateSet( stateSet );
// Cloned bin shall not write to the depth-buffer
stateSet-setMode( GL_DEPTH_TEST, osg::StateAttribute::ON
| osg::StateAttribute::OVERRIDE );
stateSet-setAttributeAndModes( new
osg::Depth(osg::Depth::LESS, 0.0, 1.0, false), osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE );
// Ensure cloned bin is rendered before bin 10.
binList[9] = clonedBin;
}
}
}
}
}
Regards,
Viggo Date: Thu, 24 Jul 2008 11:19:21 +0100 From: [EMAIL PROTECTED] To:
osg-users@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'd do this trick using a CullCallback on the topmost node of sub
graph that you won't to repeat rather than a pre draw callback. The
CullVisitor keeps track of the current RenderStage. Robert.
_
Hold kontakten med Windows Live Messenger.
http://clk.atdmt.com/GBL/go/msnnkdre001003gbl/direct/01/___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Robert: I figured it out :-) (was: Is it possible to know when the node-graph is 'dirty'?)
Hi Viggo,
You could possible experiment with reuse the bin rather than cloning
it. Inserting a two bins for bin 9 and 10, then have the original
transparent bin nested within them. I can't recall the exact details
but I think I've tried a trick like this in the past. This would also
allow you to reuse a fixed StateSet on every frame rather than
creating one.
Robert.
On Thu, Jul 24, 2008 at 12:41 PM, Viggo Løvli [EMAIL PROTECTED] wrote:
Hi Robert,
I followed your advice added the code into the traverse function of my root
node.
Much of the code could now be removed, and I got rid of the 0..1
loop-hack that I had to do earlier.
I think the new code looks very good. Do you see anything you would do
differently?
The new code looks like this:
void MyRootNodeClass::traverse( osg::NodeVisitor nv )
{
osg::Group::traverse( nv );
// Clone render-bin 10 if this is a cull visitor
if( nv.getVisitorType() == osg::NodeVisitor::CULL_VISITOR )
{
osgUtil::CullVisitor* cv = dynamic_castosgUtil::CullVisitor*( nv
);
if( cv )
{
// Act if we have a RenderStage pointer
if( osgUtil::RenderStage* renderStage = cv-getRenderStage() )
{
// Get the render-bin list
osgUtil::RenderBin::RenderBinList binList =
renderStage-getRenderBinList();
if( binList.find(10) != binList.end() )
{
// Clone bin 10
osgUtil::RenderBin* clonedBin = new osgUtil::RenderBin(
*(binList[10].get()) );
// Clone the state-set
osg::StateSet* originalStateSet =
clonedBin-getStateSet();
osg::StateSet* stateSet = (originalStateSet) ? new
osg::StateSet( *(originalStateSet) ) : new osg::StateSet();
// Ensure the cloned state-set is used in the cloned bin
clonedBin-setStateSet( stateSet );
// Cloned bin shall not write to the depth-buffer
stateSet-setMode( GL_DEPTH_TEST,
osg::StateAttribute::ON | osg::StateAttribute::OVERRIDE );
stateSet-setAttributeAndModes( new
osg::Depth(osg::Depth::LESS, 0.0, 1.0, false), osg::StateAttribute::ON |
osg::StateAttribute::OVERRIDE );
// Ensure cloned bin is rendered before bin 10.
binList[9] = clonedBin;
}
}
}
}
}
Regards,
Viggo
Date: Thu, 24 Jul 2008 11:19:21 +0100
From: [EMAIL PROTECTED]
To: osg-users@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'd do this trick using a CullCallback on the topmost node of sub
graph that you won't to repeat rather than a pre draw callback. The
CullVisitor keeps track of the current RenderStage.
Robert.
Få Hotmail du også. Windows Live Hotmail nå med 5000 MB gratis
lagringsplass.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Robert: I figured it out :-) (was: Is it possible to know when the node-graph is 'dirty'?)
Hi Robert,
I have changed the code a bit.
Now I create my statset (_myPreCreatedStateSet) at class construction.
I no longer clone bin 10.
I now only do this inside the inner check:
if( binList.find(10) != binList.end() )
{
binList[9] = new osgUtil::RenderBin();
binList[9]-setStateSet( _myPreCreatedStateSet );
(binList[9]-getRenderBinList())[9] = binList[10];
}
The only thing that annoy me now is the call to new().
Creating one bin as a member variable in my class and using it instead of the
call to new cause the system to crash. Double buffering I guess.
So maybe I can fix this by having two RenderBin instances in my class, and use
them every other call?
But, I suspect that it may not be enough? Would I need two per cull call that
is ran per frame? Say that I in the future render with 4 different cameras and
cull the world 4 times. Would I then need 4*2 bin instances to use instead of
calling new()?
Regards,
Viggo
Date: Thu, 24 Jul 2008 12:52:06 +0100 From: [EMAIL PROTECTED] To:
osg-users@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, You could possible experiment with reuse the bin
rather than cloning it. Inserting a two bins for bin 9 and 10, then have the
original transparent bin nested within them. I can't recall the exact
details but I think I've tried a trick like this in the past. This would
also allow you to reuse a fixed StateSet on every frame rather than
creating one. Robert.
_
Windows Live Messenger - også på mobilen.
http://windowslivemobile.msn.com/Homepage.aspx?lang=nb-noocid=30032___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Robert: I figured it out :-) (was: Is it possible to know when the node-graph is 'dirty'?)
On Thu, Jul 24, 2008 at 3:08 PM, Viggo Løvli [EMAIL PROTECTED] wrote: The only thing that annoy me now is the call to new(). Creating one bin as a member variable in my class and using it instead of the call to new cause the system to crash. Double buffering I guess. So maybe I can fix this by having two RenderBin instances in my class, and use them every other call? But, I suspect that it may not be enough? Would I need two per cull call that is ran per frame? Say that I in the future render with 4 different cameras and cull the world 4 times. Would I then need 4*2 bin instances to use instead of calling new()? The OSG's rendering backend is both very dynamic (created on demand on each frame) and flexible (it can be a huge range of bin configurations, potentially different on each frame) and the threading and multiple graphics context rendering are all thrown into this mix. This makes reuse of data something you have to be very careful about, in your case you'd either need to create on each new frame or multi-buffer. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
