Hi Robert,
Thanks for that. With Mike's message above I was able to dig into things
in a bit more detail, and one of the posts I went through was a post of
yours where you went into detail on the reasons behind the change (if I
may summarise, in short, it is a former bug in OSG that was fixed, whose
presence inadvertently hid bugs in code that used OSG, code such as
mine). The fix you and Mike have mentioned cleared up the original
problem without the need for the fix I found, plus solved some
additional problems besides. It is superior to the solution I used and
outlined in the post you've directly replied to- in fact, after trying
out the suggestion in Mike's code I went and reversed my change, and
established that with this better fix, my fix is no longer needed.
Thankyou also for the extra description, it has helped solidify my
understanding of how OSG handles things in this respect. I do appreciate
you taking the time to help out with your thoughts here, even though it
is clearly something that you have taken the time to go through on
previous occasions with others. Had I had sufficient understanding to
identify the problem at the outset, or with the benefit of hindsight, I
would have liked to have spared you the need to do it yet again.
I hope others reading are similarly helped as I have been. I will be
leaving the day with more knowledge than I began the day with. And on
that note, it's now 1am locally, so it seems a sensible point to bring
my day to a close. :)
Cheers,
Garth
On 03/11/13 00:19, Robert Osfield wrote:
> 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]
> <mailto:[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
> osg-users@lists.__openscenegraph.org
> <mailto:[email protected]>
>
http://lists.openscenegraph.__org/listinfo.cgi/osg-users-__openscenegraph.org
>
<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
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
