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, 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 > _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
