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 <[email protected]> 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 > <[email protected]> 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 > > <[email protected]> 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 > > [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 > -- trajce nikolov nick
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
