Just to close the issue. Apparently osg::Matrixd and osg::Matrixf uniforms where managed differently 2010 ;-)..
Thanks for those to tried to help me offline Cheers! Nick On Mon, Sep 5, 2016 at 8:56 PM, Trajce Nikolov NICK < trajce.nikolov.n...@gmail.com> wrote: > 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.osfi...@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.n...@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.n...@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@lists.openscenegraph.org >> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-opens >> cenegraph.org >> > >> _______________________________________________ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> > > > > -- > trajce nikolov nick > -- trajce nikolov nick
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org