Re: [osg-users] traversal question w/latest developer release-blacknodes
Hi Sherman, A shader turning the scene black to me suggests that either the shader itself contains a bug, the uniforms it requires are set up correctly or that the vertex attributes it requires aren't set up correctly. How this relates to your custom node is impossible to say without viewing the code first hand. Robert. On Fri, Feb 15, 2008 at 2:48 AM, sherman wilcox [EMAIL PROTECTED] wrote: mew - Didn't realize there was a potential shader connection till a tad later. Anyway, I spent more time on this yesterday and managed to build a sample app that is much smaller and less complicated than the app I originally found the problem in. There's a bit of propriety code in this sample app - nothing I wouldn't mind sharing with you if you want to take a peek. The thing that bugs me is why is this shader effecting other osg nodes. Now, there could most certainly be a bug in my code somewhere - but I'm using OSG code - I don't *think* I'm going outside of OSG and doing messing with OpenGL states. So, if I'm using all OSG code then I would think that even if I've got a bad shader, or doing something I shouldn't be - then that error should be confined to that node and its children and should NOT travel to its siblings. You can email me privately if you want and I'll be happy to share the code with you. On Thu, Feb 14, 2008 at 5:04 PM, Mike Weiblen [EMAIL PROTECTED] wrote: Hi, Usually try to keep an eye out for shader questions, but this title did not attract my attention. I'm leaving the title unmodified so you'll see this response, but if there's still an open question, pls start a new appropriately-titled thread with the current state of your investigation. Way way back, there was an issue of OSG shader state leakage. It's been fixed a long time (years?), 'course that doesn't preclude another failure mode. Cheers -- mew -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Wednesday, February 13, 2008 10:07 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] traversal question w/latest developer release- blacknodes (Hm, shaders. Maybe someone with more experience with shaders in OSG can read and post an opinion?) Hi Sherman -- Interesting issue. OpenGL is a state machine, and if you're just using raw OpenGL, then you could enable blending, for example, never change blending state again, and blending would be enabled for all subsequent geometry. OSG adds a new level of functionality on top of that. As you traverse a scene graph, state changes are pushed and popped hierarchically, which is what most apps expect. If blending is off in a parent Node but on in the first child, blending is restored to a disabled state before processing the other children. Not all state: Color, as I mentioned previously, is not pushed and popped. So, if you change the color in a Drawable, and then a subsequent sibling (or even a distant cousin) Geometry is missing its color array, the previous color persists (due to OpenGL's state machine nature). I'm not sure why OSG intentionally doesn't push/pop color, but it simply doesn't, and if you always specify color for Drawables that require specific colors, this is not an issue. When it comes to shaders, though, I'm not sure how they behave. If a Node binds a Program, does OSG unbind it before processing sibling Nodes? This is a question better posed to someone like Mike W. or Bob K... =Paul I've found a few clues this evening. Not sure why things are behaving the way they are - I'm probably abusing the OSG in my overridden traverse(...) function. My node has a shader attached. If I do NOT attach that shader to the stateset, no problems. Read on On Feb 12, 2008 3:40 PM, Paul Martz [EMAIL PROTECTED] wrote: I have a class that inherits from osg::Group. In this class I'm overriding the traverse function. It is written in such a way that the CULL_VISITOR doesn't have an opportunity to call osg::Group::traverse(nv). When I add this object to the scenegraph all the nodes in my scene go black. Even if this class is a child - all the nodes (including parent nodes) appear black. The presence of this custom Node is changing the color of your geometry so that they render black? E.g., against a non-black background, you see them render? Or, by appear black, do you mean they just don't show up? What color is your Geometry supposed to render? The only other node is a bluemarble ellipsoid produced by osgdem. It's entirely black when I intrdouce my node into the scenegraph
Re: [osg-users] traversal question w/latest developer release-blacknodes
Hi, Usually try to keep an eye out for shader questions, but this title did not attract my attention. I'm leaving the title unmodified so you'll see this response, but if there's still an open question, pls start a new appropriately-titled thread with the current state of your investigation. Way way back, there was an issue of OSG shader state leakage. It's been fixed a long time (years?), 'course that doesn't preclude another failure mode. Cheers -- mew -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Wednesday, February 13, 2008 10:07 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] traversal question w/latest developer release- blacknodes (Hm, shaders. Maybe someone with more experience with shaders in OSG can read and post an opinion?) Hi Sherman -- Interesting issue. OpenGL is a state machine, and if you're just using raw OpenGL, then you could enable blending, for example, never change blending state again, and blending would be enabled for all subsequent geometry. OSG adds a new level of functionality on top of that. As you traverse a scene graph, state changes are pushed and popped hierarchically, which is what most apps expect. If blending is off in a parent Node but on in the first child, blending is restored to a disabled state before processing the other children. Not all state: Color, as I mentioned previously, is not pushed and popped. So, if you change the color in a Drawable, and then a subsequent sibling (or even a distant cousin) Geometry is missing its color array, the previous color persists (due to OpenGL's state machine nature). I'm not sure why OSG intentionally doesn't push/pop color, but it simply doesn't, and if you always specify color for Drawables that require specific colors, this is not an issue. When it comes to shaders, though, I'm not sure how they behave. If a Node binds a Program, does OSG unbind it before processing sibling Nodes? This is a question better posed to someone like Mike W. or Bob K... =Paul I've found a few clues this evening. Not sure why things are behaving the way they are - I'm probably abusing the OSG in my overridden traverse(...) function. My node has a shader attached. If I do NOT attach that shader to the stateset, no problems. Read on On Feb 12, 2008 3:40 PM, Paul Martz [EMAIL PROTECTED] wrote: I have a class that inherits from osg::Group. In this class I'm overriding the traverse function. It is written in such a way that the CULL_VISITOR doesn't have an opportunity to call osg::Group::traverse(nv). When I add this object to the scenegraph all the nodes in my scene go black. Even if this class is a child - all the nodes (including parent nodes) appear black. The presence of this custom Node is changing the color of your geometry so that they render black? E.g., against a non-black background, you see them render? Or, by appear black, do you mean they just don't show up? What color is your Geometry supposed to render? The only other node is a bluemarble ellipsoid produced by osgdem. It's entirely black when I intrdouce my node into the scenegraph. If the node (my custom node) is a sibling, the bluemarble node goes black. Does your custom Node support the .osg file format? If so, have you dumped your scene to a .osg file to see if anything is amiss? No - doesn't support OSG. Have you tried to reproduce the problem with a very simple scene, like just a single triangle plus your custom Node? Then you could step through in the debugger and determine what's going on. Have you tried capturing the OpenGL output with GLIntercept? In the past, whenever I've seen state bleed from one Node to a sibling Node, it is usually because the sibling Node's Geometry lacks a color array. I suspect either one of (at least) two things: 1) I'm abusing OSG some manner and the code is responding in kind. In other words, I'm doing something I shouldn't be and I'm getting undefined behavior. OR 2) There is some sort of state leakage (of my shader) issue between sibling nodes. If this is leakage - is it a bug or not? What I did to patch things is to hack my class such that the CULL_VISITOR is allowed to call osg::Group::traverse(nv); at least once at the start. This seems to address the problem, albeit in a kludgy sort of way. I'd like to know if: - this is a new OSG bug? Are you saying you tried this same thing in v2.2 and the problem didn't occur? I thought this was new - but went back and tried older versions of OSG and the problem persists. I have a fix (allow one cull traversal on my custom node)...but it seeems kludgy. I'm either doing something terribly wrong OR I've found some bug. It's probably the former. It does strike
Re: [osg-users] traversal question w/latest developer release-blacknodes
mew - Didn't realize there was a potential shader connection till a tad later. Anyway, I spent more time on this yesterday and managed to build a sample app that is much smaller and less complicated than the app I originally found the problem in. There's a bit of propriety code in this sample app - nothing I wouldn't mind sharing with you if you want to take a peek. The thing that bugs me is why is this shader effecting other osg nodes. Now, there could most certainly be a bug in my code somewhere - but I'm using OSG code - I don't *think* I'm going outside of OSG and doing messing with OpenGL states. So, if I'm using all OSG code then I would think that even if I've got a bad shader, or doing something I shouldn't be - then that error should be confined to that node and its children and should NOT travel to its siblings. You can email me privately if you want and I'll be happy to share the code with you. On Thu, Feb 14, 2008 at 5:04 PM, Mike Weiblen [EMAIL PROTECTED] wrote: Hi, Usually try to keep an eye out for shader questions, but this title did not attract my attention. I'm leaving the title unmodified so you'll see this response, but if there's still an open question, pls start a new appropriately-titled thread with the current state of your investigation. Way way back, there was an issue of OSG shader state leakage. It's been fixed a long time (years?), 'course that doesn't preclude another failure mode. Cheers -- mew -Original Message- From: [EMAIL PROTECTED] [mailto:osg-users- [EMAIL PROTECTED] On Behalf Of Paul Martz Sent: Wednesday, February 13, 2008 10:07 AM To: 'OpenSceneGraph Users' Subject: Re: [osg-users] traversal question w/latest developer release- blacknodes (Hm, shaders. Maybe someone with more experience with shaders in OSG can read and post an opinion?) Hi Sherman -- Interesting issue. OpenGL is a state machine, and if you're just using raw OpenGL, then you could enable blending, for example, never change blending state again, and blending would be enabled for all subsequent geometry. OSG adds a new level of functionality on top of that. As you traverse a scene graph, state changes are pushed and popped hierarchically, which is what most apps expect. If blending is off in a parent Node but on in the first child, blending is restored to a disabled state before processing the other children. Not all state: Color, as I mentioned previously, is not pushed and popped. So, if you change the color in a Drawable, and then a subsequent sibling (or even a distant cousin) Geometry is missing its color array, the previous color persists (due to OpenGL's state machine nature). I'm not sure why OSG intentionally doesn't push/pop color, but it simply doesn't, and if you always specify color for Drawables that require specific colors, this is not an issue. When it comes to shaders, though, I'm not sure how they behave. If a Node binds a Program, does OSG unbind it before processing sibling Nodes? This is a question better posed to someone like Mike W. or Bob K... =Paul I've found a few clues this evening. Not sure why things are behaving the way they are - I'm probably abusing the OSG in my overridden traverse(...) function. My node has a shader attached. If I do NOT attach that shader to the stateset, no problems. Read on On Feb 12, 2008 3:40 PM, Paul Martz [EMAIL PROTECTED] wrote: I have a class that inherits from osg::Group. In this class I'm overriding the traverse function. It is written in such a way that the CULL_VISITOR doesn't have an opportunity to call osg::Group::traverse(nv). When I add this object to the scenegraph all the nodes in my scene go black. Even if this class is a child - all the nodes (including parent nodes) appear black. The presence of this custom Node is changing the color of your geometry so that they render black? E.g., against a non-black background, you see them render? Or, by appear black, do you mean they just don't show up? What color is your Geometry supposed to render? The only other node is a bluemarble ellipsoid produced by osgdem. It's entirely black when I intrdouce my node into the scenegraph. If the node (my custom node) is a sibling, the bluemarble node goes black. Does your custom Node support the .osg file format? If so, have you dumped your scene to a .osg file to see if anything is amiss? No - doesn't support OSG. Have you tried to reproduce the problem with a very simple scene, like just a single triangle plus your custom Node? Then you could step through in the debugger and determine what's going on. Have you tried capturing the OpenGL output with GLIntercept? In the past, whenever I've seen state bleed from one Node to a sibling Node
Re: [osg-users] traversal question w/latest developer release -blacknodes
(Hm, shaders. Maybe someone with more experience with shaders in OSG can read and post an opinion?) Hi Sherman -- Interesting issue. OpenGL is a state machine, and if you're just using raw OpenGL, then you could enable blending, for example, never change blending state again, and blending would be enabled for all subsequent geometry. OSG adds a new level of functionality on top of that. As you traverse a scene graph, state changes are pushed and popped hierarchically, which is what most apps expect. If blending is off in a parent Node but on in the first child, blending is restored to a disabled state before processing the other children. Not all state: Color, as I mentioned previously, is not pushed and popped. So, if you change the color in a Drawable, and then a subsequent sibling (or even a distant cousin) Geometry is missing its color array, the previous color persists (due to OpenGL's state machine nature). I'm not sure why OSG intentionally doesn't push/pop color, but it simply doesn't, and if you always specify color for Drawables that require specific colors, this is not an issue. When it comes to shaders, though, I'm not sure how they behave. If a Node binds a Program, does OSG unbind it before processing sibling Nodes? This is a question better posed to someone like Mike W. or Bob K... =Paul I've found a few clues this evening. Not sure why things are behaving the way they are - I'm probably abusing the OSG in my overridden traverse(...) function. My node has a shader attached. If I do NOT attach that shader to the stateset, no problems. Read on On Feb 12, 2008 3:40 PM, Paul Martz [EMAIL PROTECTED] wrote: I have a class that inherits from osg::Group. In this class I'm overriding the traverse function. It is written in such a way that the CULL_VISITOR doesn't have an opportunity to call osg::Group::traverse(nv). When I add this object to the scenegraph all the nodes in my scene go black. Even if this class is a child - all the nodes (including parent nodes) appear black. The presence of this custom Node is changing the color of your geometry so that they render black? E.g., against a non-black background, you see them render? Or, by appear black, do you mean they just don't show up? What color is your Geometry supposed to render? The only other node is a bluemarble ellipsoid produced by osgdem. It's entirely black when I intrdouce my node into the scenegraph. If the node (my custom node) is a sibling, the bluemarble node goes black. Does your custom Node support the .osg file format? If so, have you dumped your scene to a .osg file to see if anything is amiss? No - doesn't support OSG. Have you tried to reproduce the problem with a very simple scene, like just a single triangle plus your custom Node? Then you could step through in the debugger and determine what's going on. Have you tried capturing the OpenGL output with GLIntercept? In the past, whenever I've seen state bleed from one Node to a sibling Node, it is usually because the sibling Node's Geometry lacks a color array. I suspect either one of (at least) two things: 1) I'm abusing OSG some manner and the code is responding in kind. In other words, I'm doing something I shouldn't be and I'm getting undefined behavior. OR 2) There is some sort of state leakage (of my shader) issue between sibling nodes. If this is leakage - is it a bug or not? What I did to patch things is to hack my class such that the CULL_VISITOR is allowed to call osg::Group::traverse(nv); at least once at the start. This seems to address the problem, albeit in a kludgy sort of way. I'd like to know if: - this is a new OSG bug? Are you saying you tried this same thing in v2.2 and the problem didn't occur? I thought this was new - but went back and tried older versions of OSG and the problem persists. I have a fix (allow one cull traversal on my custom node)...but it seeems kludgy. I'm either doing something terribly wrong OR I've found some bug. It's probably the former. It does strike me as add that performing a single cull traversal addresses the issue. Seems as though some state isn't be set properly unless this cull traversal is allowed to pass through. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] traversal question w/latest developer release -blacknodes
Is strange. I'm using all OSG code. Is possible I've found some odd OSG bug - but I think is more likely that I'm doing something that's not intended and am experiencing a side effect. I'm going to spend a bit of time and see if I can simplify this problem down to a trivial example. On Feb 13, 2008 10:07 AM, Paul Martz [EMAIL PROTECTED] wrote: (Hm, shaders. Maybe someone with more experience with shaders in OSG can read and post an opinion?) Hi Sherman -- Interesting issue. OpenGL is a state machine, and if you're just using raw OpenGL, then you could enable blending, for example, never change blending state again, and blending would be enabled for all subsequent geometry. OSG adds a new level of functionality on top of that. As you traverse a scene graph, state changes are pushed and popped hierarchically, which is what most apps expect. If blending is off in a parent Node but on in the first child, blending is restored to a disabled state before processing the other children. Not all state: Color, as I mentioned previously, is not pushed and popped. So, if you change the color in a Drawable, and then a subsequent sibling (or even a distant cousin) Geometry is missing its color array, the previous color persists (due to OpenGL's state machine nature). I'm not sure why OSG intentionally doesn't push/pop color, but it simply doesn't, and if you always specify color for Drawables that require specific colors, this is not an issue. When it comes to shaders, though, I'm not sure how they behave. If a Node binds a Program, does OSG unbind it before processing sibling Nodes? This is a question better posed to someone like Mike W. or Bob K... =Paul I've found a few clues this evening. Not sure why things are behaving the way they are - I'm probably abusing the OSG in my overridden traverse(...) function. My node has a shader attached. If I do NOT attach that shader to the stateset, no problems. Read on On Feb 12, 2008 3:40 PM, Paul Martz [EMAIL PROTECTED] wrote: I have a class that inherits from osg::Group. In this class I'm overriding the traverse function. It is written in such a way that the CULL_VISITOR doesn't have an opportunity to call osg::Group::traverse(nv). When I add this object to the scenegraph all the nodes in my scene go black. Even if this class is a child - all the nodes (including parent nodes) appear black. The presence of this custom Node is changing the color of your geometry so that they render black? E.g., against a non-black background, you see them render? Or, by appear black, do you mean they just don't show up? What color is your Geometry supposed to render? The only other node is a bluemarble ellipsoid produced by osgdem. It's entirely black when I intrdouce my node into the scenegraph. If the node (my custom node) is a sibling, the bluemarble node goes black. Does your custom Node support the .osg file format? If so, have you dumped your scene to a .osg file to see if anything is amiss? No - doesn't support OSG. Have you tried to reproduce the problem with a very simple scene, like just a single triangle plus your custom Node? Then you could step through in the debugger and determine what's going on. Have you tried capturing the OpenGL output with GLIntercept? In the past, whenever I've seen state bleed from one Node to a sibling Node, it is usually because the sibling Node's Geometry lacks a color array. I suspect either one of (at least) two things: 1) I'm abusing OSG some manner and the code is responding in kind. In other words, I'm doing something I shouldn't be and I'm getting undefined behavior. OR 2) There is some sort of state leakage (of my shader) issue between sibling nodes. If this is leakage - is it a bug or not? What I did to patch things is to hack my class such that the CULL_VISITOR is allowed to call osg::Group::traverse(nv); at least once at the start. This seems to address the problem, albeit in a kludgy sort of way. I'd like to know if: - this is a new OSG bug? Are you saying you tried this same thing in v2.2 and the problem didn't occur? I thought this was new - but went back and tried older versions of OSG and the problem persists. I have a fix (allow one cull traversal on my custom node)...but it seeems kludgy. I'm either doing something terribly wrong OR I've found some bug. It's probably the former. It does strike me as add that performing a single cull traversal addresses the issue. Seems as though some state isn't be set properly unless this cull traversal is allowed to pass through. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org
Re: [osg-users] traversal question w/latest developer release - blacknodes
Paul - thanks for the suggestions. I've found an older code tree of mine from November 07 and everything seemed to work there. I'm investigating. On Feb 12, 2008 3:40 PM, Paul Martz [EMAIL PROTECTED] wrote: I have a class that inherits from osg::Group. In this class I'm overriding the traverse function. It is written in such a way that the CULL_VISITOR doesn't have an opportunity to call osg::Group::traverse(nv). When I add this object to the scenegraph all the nodes in my scene go black. Even if this class is a child - all the nodes (including parent nodes) appear black. The presence of this custom Node is changing the color of your geometry so that they render black? E.g., against a non-black background, you see them render? Or, by appear black, do you mean they just don't show up? What color is your Geometry supposed to render? Does your custom Node support the .osg file format? If so, have you dumped your scene to a .osg file to see if anything is amiss? Have you tried to reproduce the problem with a very simple scene, like just a single triangle plus your custom Node? Then you could step through in the debugger and determine what's going on. Have you tried capturing the OpenGL output with GLIntercept? In the past, whenever I've seen state bleed from one Node to a sibling Node, it is usually because the sibling Node's Geometry lacks a color array. What I did to patch things is to hack my class such that the CULL_VISITOR is allowed to call osg::Group::traverse(nv); at least once at the start. This seems to address the problem, albeit in a kludgy sort of way. I'd like to know if: - this is a new OSG bug? Are you saying you tried this same thing in v2.2 and the problem didn't occur? -Paul - anyone else is experiencing this? - or perhaps I'm abusing things in such way that is ill-advised? Comments? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ 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] traversal question w/latest developer release - blacknodes
I have a class that inherits from osg::Group. In this class I'm overriding the traverse function. It is written in such a way that the CULL_VISITOR doesn't have an opportunity to call osg::Group::traverse(nv). When I add this object to the scenegraph all the nodes in my scene go black. Even if this class is a child - all the nodes (including parent nodes) appear black. The presence of this custom Node is changing the color of your geometry so that they render black? E.g., against a non-black background, you see them render? Or, by appear black, do you mean they just don't show up? What color is your Geometry supposed to render? Does your custom Node support the .osg file format? If so, have you dumped your scene to a .osg file to see if anything is amiss? Have you tried to reproduce the problem with a very simple scene, like just a single triangle plus your custom Node? Then you could step through in the debugger and determine what's going on. Have you tried capturing the OpenGL output with GLIntercept? In the past, whenever I've seen state bleed from one Node to a sibling Node, it is usually because the sibling Node's Geometry lacks a color array. What I did to patch things is to hack my class such that the CULL_VISITOR is allowed to call osg::Group::traverse(nv); at least once at the start. This seems to address the problem, albeit in a kludgy sort of way. I'd like to know if: - this is a new OSG bug? Are you saying you tried this same thing in v2.2 and the problem didn't occur? -Paul - anyone else is experiencing this? - or perhaps I'm abusing things in such way that is ill-advised? Comments? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce negraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] traversal question w/latest developer release - blacknodes
I've found a few clues this evening. Not sure why things are behaving the way they are - I'm probably abusing the OSG in my overridden traverse(...) function. My node has a shader attached. If I do NOT attach that shader to the stateset, no problems. Read on On Feb 12, 2008 3:40 PM, Paul Martz [EMAIL PROTECTED] wrote: I have a class that inherits from osg::Group. In this class I'm overriding the traverse function. It is written in such a way that the CULL_VISITOR doesn't have an opportunity to call osg::Group::traverse(nv). When I add this object to the scenegraph all the nodes in my scene go black. Even if this class is a child - all the nodes (including parent nodes) appear black. The presence of this custom Node is changing the color of your geometry so that they render black? E.g., against a non-black background, you see them render? Or, by appear black, do you mean they just don't show up? What color is your Geometry supposed to render? The only other node is a bluemarble ellipsoid produced by osgdem. It's entirely black when I intrdouce my node into the scenegraph. If the node (my custom node) is a sibling, the bluemarble node goes black. Does your custom Node support the .osg file format? If so, have you dumped your scene to a .osg file to see if anything is amiss? No - doesn't support OSG. Have you tried to reproduce the problem with a very simple scene, like just a single triangle plus your custom Node? Then you could step through in the debugger and determine what's going on. Have you tried capturing the OpenGL output with GLIntercept? In the past, whenever I've seen state bleed from one Node to a sibling Node, it is usually because the sibling Node's Geometry lacks a color array. I suspect either one of (at least) two things: 1) I'm abusing OSG some manner and the code is responding in kind. In other words, I'm doing something I shouldn't be and I'm getting undefined behavior. OR 2) There is some sort of state leakage (of my shader) issue between sibling nodes. If this is leakage - is it a bug or not? What I did to patch things is to hack my class such that the CULL_VISITOR is allowed to call osg::Group::traverse(nv); at least once at the start. This seems to address the problem, albeit in a kludgy sort of way. I'd like to know if: - this is a new OSG bug? Are you saying you tried this same thing in v2.2 and the problem didn't occur? I thought this was new - but went back and tried older versions of OSG and the problem persists. I have a fix (allow one cull traversal on my custom node)...but it seeems kludgy. I'm either doing something terribly wrong OR I've found some bug. It's probably the former. It does strike me as add that performing a single cull traversal addresses the issue. Seems as though some state isn't be set properly unless this cull traversal is allowed to pass through. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
