Re: [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.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 
> 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
>>  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
>> >  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 

Re: [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 
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
>  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
> >  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-
> openscenegraph.org
> >
> ___
> 

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

[Robert Osfield]

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
 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
>  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-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[Trajce Nikolov NICK]

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-openscenegraph.org

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

[Trajce Nikolov NICK]

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
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org