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