[osg-users] porting old code to the latest osg issues

[Trajce Nikolov NICK]

Hi Robert,

I did look in the State.cpp sources for shaders string processing and I
couldn't spot anything. But there is a difference between what OSG reports
wrt. shader source being passed to OpenGL and this interesting thing
apitrace.  Let just work with the header, and the #version string is
dismissed totaly - this is on Ubuntu 14.04, then I switched back on Windows
and all was passed correctly across all the players down to OpenGL.
However, I have this 'OpenGL error after Renderer:compile' with no further
info (maybe time to extend the error messaging in OSG ;-) ). I am fooling
around with gDEBugger now to see if I can catch that reported error (anyone
with gDEBugger knowledge how to setup a breakpoint on GL_ERROR??). But
thanks anyway for the hints so far !!!

The findings on Linux and api trace, Windows works fine

This is my shader string (in the code):

"#version 330 compatibility\n"
"uniform mat4 osg_ViewMatrixInverse; // Automatically updated by OSG\n"
"out vec3 normal, eyeVec;\n"

This is the output with OSG_NOTIFY_LEVEL=INFO

++Before Converted source
#version 330 compatibility
uniform mat4 osg_ViewMatrixInverse; // Automatically updated by OSG
out vec3 normal, eyeVec;

-------- Converted source
#version 330 compatibility
uniform mat3 osg_NormalMatrix;
uniform mat4 osg_ModelViewProjectionMatrix;
uniform mat4 osg_ModelViewMatrix;
uniform mat4 osg_ViewMatrixInverse; // Automatically updated by OSG
out vec3 normal, eyeVec;

The apitrace dump was ignoring the #version line, but works fine on
Windows, so I guess this apitrace is buggy for Linux.


On Mon, Sep 5, 2016 at 9:13 AM, Robert Osfield <robert.osfield at gmail.com>
wrote:

> Hi Nick,
>
> I haven't had the time to look into so don't have any specific
> answers.  From your description it sounds like the osg::State's
> support for automatically tweaking shaders is enabled, perhaps this is
> either doing something inappropriate or something else in the mix (i.e
> osgShadow) or the other shader source.
>
> One thing you can do is enable debugging via the OSG_NOTIFY=DEBUG env
> var setting and then watch the output to see what shader is being
> passed to OpenGL.  Also have a look at the shader substitution code in
> osg::State to see what it's doing.  The method to look at is
> osg::State::convertVertexShaderSourceToOsgBuiltIns(std::string&).
>
> Since OSG-3.4 there have been a few changes to this code so there is
> chance that OSG master will behave differently so might be worth a
> try.
>
> Robert.
>
>
>
> On 4 September 2016 at 22:49, Trajce Nikolov NICK
> <trajce.nikolov.nick at gmail.com> wrote:
> > Robert,
> >
> > are there any changes in the shader management, I mean are the shaders
> > changed by the OSG code somehow (I am using the built-om uniforms)? Here
> is
> > my shader source line:
> >
> > "varying vec4 projShadow;\n"
> >
> > that apitrace logs as (this is being compiled but differs from the
> original
> > shader source):
> >
> > out vec4 projShadow;
> >
> > and then I get this warning
> >
> > warning C5060: out can't be used with non-varying projShadow
> >
> > ?
> >
> > Thanks a lot as always!
> >
> > Nick
> >
> > p.s. Chris, thanks for the apitrace hint
> >
> > On Fri, Sep 2, 2016 at 2:09 AM, Trajce Nikolov NICK
> > <trajce.nikolov.nick at gmail.com> wrote:
> >>
> >> Hi Community,
> >>
> >> I had some discussion and coding some sample with Wojtek's help 2010
> :-).
> >> It is about a sample code that illustrates a simple lights and
> obstacles. It
> >> become actual for me again so I started with this archived example as a
> >> testbed to work on it and integrate it into much larger project. Here
> is the
> >> link of the code:
> >>
> >>
> >> http://markmail.org/message/ccscbkzyxsgmb5vl#query:+page:
> 1+mid:c542rbpj3jdw3v5d+state:results
> >>
> >> I know it was working till recent times. And it doesn't anymore :-/. So
> I
> >> went to see what might have changed in OpenGL and OSG since then (bit
> crazy
> >> but I had to start somewhere). It uses shadow2DProj which I found it was
> >> replaced by the texture call in GLSL after 130. Also on OSG side to use
> the
> >> built in uniforms I know it has to be enabled in the camera's gc state
> with
> >> setUseModelViewAndProjectionUniforms. So far these were my findings
> which
> >> didn't helped.
> >>
> >> I would like to ask you for any hints and for a bit of will to see if
> >> someone can spot something - the code is simple, selfcontained, it has
> >> lighting from the red book implemented and use simple shadow mapping to
> make
> >> the lights to not appear behind obstacles.
> >>
> >> As always, thanks a bunch!!!!!
> >>
> >> Cheers,
> >> Nick
> >>
> >> --
> >> trajce nikolov nick
> >
> >
> >
> >
> > --
> > trajce nikolov nick
> >
> > _______________________________________________
> > osg-users mailing list
> > osg-users at lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
> >
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>



-- 
trajce nikolov nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20160905/a3b91738/attachment-0003.htm>