Hi Garth, I've discussed this with the release of OSG-3.2 a number of times. A fix in 3.2 that addressed a bug of the internal rendering classes overriding the Viewer's Camera state causes this problem in client code. The problem is the OSG now does exactly what you ask it to do w.r.t State, so if your Viewer's Camera is empty then it doesn't apply any State.
Normally OSG applications just use the default Camera StateSet set up by the osg::View class which calls the Camera::getOrCreateStateSet()->setGlobalDefaults() for you. For applictions that just apply settings to the View(er)'s Camera directly won't see any problems because all the defaults are in place. However, if you application is creating it's own Camera and then applying this to the View the GlobalDefaults are not set up so you just end up getting OpenGL defaults. It sounds like in your case this is exactly what is happening. The solution is to either just reuse the View(er) Camera rather than creating your own, or do as View does for it's default constructed Camera - call setGlobalDefaults(), or just decide what state you want in your application. In effect the bug in 3.0.0 was actually hiding a bug in the set up of the Camera state in your application, if you fix this in your application as suggested above the code will actually work fine with both 3.0.x and 3.2.x. Robert. On 2 November 2013 10:07, Garth D <[email protected]> wrote: > > Hi all, > > On 02/11/13 13:24, Garth D wrote: > > ... It is almost as if the model is being drawn in > > the reverse order with depth buffering disabled. ... > > Looks like I stumbled onto the solution for this one, and my guess on what > was happening wasn't too far off. Creating an explicit StateSet under each > problematic model with GL_DEPTH_TEST turned on fixed this- it really *was* > rendering without depth testing. I do turn GL_DEPTH_TEST off for parts of > my scene tree, but only in sibling nodes, never direct ancestors for the > models (as far as I know). I had assumed this would not impact things- but > perhaps this is not right. It appears I could get away with this in 3.0.1, > but not 3.2.0. It would also explain why osgviewer etc handle it correctly, > but my app did not. > > I'm guessing that carefully checking that StateSets are explicitly set to > what I need them to be, as close to the Geodes in question as possible, is > going to be the way to clear up many of the problems I am encountering. > > Suggestions on better ways to track down potential problems of this type > definitely appreciated if anyone has any thoughts or suggestions to share. > > > Cheers, > Garth > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
