[osg-users] vertex_array_object branch merged with master

[Robert Osfield]

Hi Curtis,

Thanks for testing things out.

Potentially we could de-instate the osg::State::dirtyTexCoordPointer()
as there osg::VertexArrayState takes over this functionality, you can
get the current VertexArrayState via
state.getCurrentVertexArrayState().  I removed the functions like
dirtyTexCoordPointer() to help make sure the rest of the OSG doesn't
rely on deprecated methods.  I wasn't expect it to be used widely by
users.  Is there code you had to modify open sourced?  If so could you
point me at it so I can work why it's being used and the way it's
being used.  This might help inform how to adapt things.

For OSG-3.6 it would be ideal to smooth out glitches that end uses are
seeing so any assistance on homing on what the issues are will really
help in this.

Robert.



On 13 October 2016 at 16:46, Curtis Rubel <crubel at compro.net> wrote:
> Hi Robert,
>
> I did some very basic testing of this for you yesterday.  There is
> no need to respond back to me with any possible fixes or anything,
> I am just passing this along to you for your information right now.
> We have no plans on updating our OSG version in the near future.
>
> I was able to successfully compile the release on OpenSuSE 13.2 64bit Linux.
>
> Next I recompiled our Opensource OpenIG application against this release and everything compiled OK, with exception of one minor change to the source code for a missing function:
>
> osg::State* state = renderInfo.getState();
> #if OSG_VERSION_LESS_OR_EQUAL(3,5,3)
>         state->dirtyTexCoordPointer(1);
> #endif
>
> I used 3.5.3 above only because that is what I know for sure as I do not
> have a copy of 3.5.4 to check against.
>
> After this change our OpenIG application runs with no segv's, however
> there are a number of visual issues noted with the 3.5.6 master:
>
> 1.  The one FBX model in the scene is not positioned properly anymore.
>      Although the shadow for it seems to still be in the correct location and
>      even shows the animation of that model, even though visually the
>      model itself is not in that location anymore.
> 2.. There appears to be something going on with our terrain shaders too
>      as when I change the TOD to 10:00, the terrain all turns bright white
>      from its normal textures.  In fact just moving around in the scene
>      also results in the terrain textures disappearing totally.
> 3.  Seems that our F+ lighting implementation will also need some
>      adjustments as it appears not to be rendering properly anymore.
>
> I know very little about how the shaders were implemented in
> this application as most of this was done by our consultant, just passing
> on some of the basic results as I seem them right now for you.
>
> All of  this is working properly in the 3.5.3 version we have been using
> so at some point between this and whats on the master branch now these
> visual changes have shown up.
>
> Anyhow I know its just some very basic info, but I figured I would pass
> it along for you in case this is not what you might have expected with
> this latest release.
>
> We will be curious to see what if anything anyone else reports back to you.
>
> ...
>
> Thank you!
>
> Cheers,
> Curtis
>
> ------------------
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=68993#68993
>
>
>
>
>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org