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

[Trajce Nikolov NICK]

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.nick at 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.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-opens
>> cenegraph.org
>> >
>> _______________________________________________
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
>
> --
> trajce nikolov nick
>



-- 
trajce nikolov nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20160907/25ef9011/attachment-0002.htm>