Hi Mike,
Thankyou! :) This is exactly the sort of post I was hoping someone would
make- a good solid hint based on a similar experience, and enough
information to let me dig into it further.
In my case a call of setGlobalDefaults on the StateSet of each camera I
create cleared up a few other glitches I hadn't yet figured out, plus I
found that I can now remove the extra explicit StateSet creation I spoke
of in my previous post, and things still work as they should. Perhaps my
original understanding wasn't too far off the mark- I had just missed
the subtlety of the change between 3.0.1 and 3.2.0 in the default
StateSets used for a new Camera.
Whilst it hasn't changed the vanishing overlay issue I'm having with
shadowing enabled, I'm still pretty chuffed that this single change has
cleared up the main issue I was facing, plus a whole bunch of smaller
ones that I hadn't really made a start on solving.
Thanks for taking the time to share your experience and for making my
evening. :)
Cheers,
Garth
On 02/11/13 22:46, Mike Connell wrote:
> I suspect you may need a:
>
> camera->getOrCreateStateSet()->setGlobalDefaults();
>
> There is some previous discussion on the list about it if you search for
> "setGlobalDefaults" and 3.2. I had a very similar problem when we
> upgraded to 3.2, and this fixed it for us.
>
> best wishes
>
> Mike
>
>
> On 2 November 2013 11: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
