Re: [osg-users] Modern GLSL and OSG

[Christian Buchner]

If you're using Windows you could try building OSG against ANGLE
and limit yourself to the OpenGL ES 2.0 API feature set. Here you can't
accidentially fall back into using deprecated (fixed function) features
because these have been stripped from the API.

There would also be plenty of books about OpenGL ES 2.0 available - and you
can immediately target mobile platforms (iOS, Android)

Christian


2015-09-23 14:44 GMT+02:00 Garth D :

>
> Hi all,
>
> I was wondering if anyone can make some suggestions as to resources that
> are useful for learning GLSL in modern OpenGL (say, 3.0+) with a specific
> focus on use with OSG.
>
> My existing GLSL knowledge is weak compared to my general 3D knowledge,
> and mostly dates back to the early days of shaders. A lot of what I have
> personally done with OpenGL and OSG has involved the fixed-function
> pipeline, or things that map to it fairly closely.
>
> Thus far I've been digging around online for GLSL resources, but tend to
> frequently find myself doing it the wrong way as I'm using features that
> have since become deprecated. On the OSG side I tend to dig around in the
> OSG examples and search the source to try to find the OSG equivalents to
> OpenGL calls I see mentioned in the GLSL resources. I then put these
> together and if I'm lucky something useful comes out. :)
>
> I think I'll figure things out eventually if I continue to crash around
> blindly as I have been, but if anyone can suggest some better starting
> points for GLSL use in OSG specifically, it would be much appreciated. :)
>
> Cheers,
> Garth
> ___
> 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] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0.

[Davis, Timothy S CTR comnavairsyscom]

smime.p7m
Description: S/MIME encrypted message
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Modern GLSL and OSG

[Garth D]

Hi all,

I was wondering if anyone can make some suggestions as to resources that 
are useful for learning GLSL in modern OpenGL (say, 3.0+) with a 
specific focus on use with OSG.


My existing GLSL knowledge is weak compared to my general 3D knowledge, 
and mostly dates back to the early days of shaders. A lot of what I have 
personally done with OpenGL and OSG has involved the fixed-function 
pipeline, or things that map to it fairly closely.


Thus far I've been digging around online for GLSL resources, but tend to 
frequently find myself doing it the wrong way as I'm using features that 
have since become deprecated. On the OSG side I tend to dig around in 
the OSG examples and search the source to try to find the OSG 
equivalents to OpenGL calls I see mentioned in the GLSL resources. I 
then put these together and if I'm lucky something useful comes out. :)


I think I'll figure things out eventually if I continue to crash around 
blindly as I have been, but if anyone can suggest some better starting 
points for GLSL use in OSG specifically, it would be much appreciated. :)


Cheers,
Garth
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenThread, each with its own viewer and performance

[Curtis Rubel]

Hello OSG users,

I am posting a simple application that uses OpenThreads.
Where each thread creates a Graphics context, sets up one 
composite viewer with one view and turns on the osg stats.
No nodes or data of any kind is added to the view.

There is a define in the  main() osgTest.cpp that sets up
how many threads are created.  Very simple example to
show the problem.

I am hoping that with your help we can determine if this is
something we are doing incorrectly or if it is just something
that is this way for a specific reason that we just do not
understand.

Any help, suggestions or comments would be greatly appreciated.

... 

Thank you!

Cheers,
Curtis

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65185#65185





osgTest.7z
Description: application/7z-compressed
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Getting all Matrix Values

[Erik Hensens]

Hi,

How can I get all 16 values of a Matrixd? I see you can construct a Matrixd 
from its values but I don't see how to get them.

Specifically, I'm wishing to format a text string that can represent a Matrixd 
so that it can be recreated later from reading and analyzing the text.

Thank you very much in advance!

Cheers,
Erik

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65186#65186





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Getting all Matrix Values

[Erik Hensens]

Never mind, I see it. I must have been asleep when I read the documentation. 
Sorry!


ehensens wrote:
> Hi,
> 
> How can I get all 16 values of a Matrixd? I see you can construct a Matrixd 
> from its values but I don't see how to get them.
> 
> Specifically, I'm wishing to format a text string that can represent a 
> Matrixd so that it can be recreated later from reading and analyzing the text.
> 
> Thank you very much in advance!
> 
> Cheers,
> Erik


--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65187#65187





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0

[Robert Osfield]

Hi Scott,

The compression code has been in place quite some while so I'm surprised to
see a report of problem now.  Did this work with previous drivers/OSG
versions/different hardware?

Could you provide a small example and explanation of how to reproduce it so
others can see if they can reproduce the problem?

Thanks,
Robert.

On 22 September 2015 at 20:51, Davis, Timothy S CTR comnavairsyscom <
timothy.s.davis@navy.mil> wrote:

> I had an issue with OSG 3.4.0 when using a compressed 32x32 texture
> causing an INVALID_OPERATION in Texture::applyTexImage2D_load when calling
> glCompressTexSubImage2D.  This is called only when the texture storage
> object is used.  This resulted in the texture rendering as black.  Note
> that the texture was loaded from a IVE file created with an earlier version
> of OSG.
>
> After some investigation, I suspected that a possible cause was that the
> texture included mipmaps down to 2x2 and 1x1 in size.  The S3TC compression
> being used has a block size of 4 so cannot be used for these small mipmap
> levels.  Modifying numMipmapLevels by subtracting 2 if the image is
> compressed and using texture storage corrected the problem.  However this
> is likely not the best solution.
>
> My limited knowledge of OpenGL and this error suggests that this may be
> highly dependent on the OpenGL implementation.  I had several other
> compressed textures larger than 32x32 with mipmaps down to 2x2 and 1x1 that
> worked fine without this change.  The OpenGL documentation (see
> EXT_texture_compression_s3tc among others) however states that if the width
> or height are not multiples of 4 then the result is an INVALID_OPERATION.
> This can go unnoticed when not using a texture storage object.  But with
> the texture storage object, the error was generated when loading the full
> texture (i.e. level 0).
>
> If my understanding is correct, others may have had similar issues with
> compressed textures with mipmaps. They have worked around the issue by
> disabling mipmaps for compressed textures in ReaderWriterDDS for example.
> If the above holds true, then it may point to the underlying problem.
>
> Windows 7 64-bit, nVidia Driver 352.86, OSG 3.4.0
>
> Scott
>
>
> ___
> 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] My OSG email updates have stopped

[Robert Osfield]

HI Philip,

As far as I can tell you email subscription to osg-users is fine, have a
look in you spam folder perhaps the spam emails that got rejected and sent
back to your account triggered the spam filter to think that all emails
from openscenegraph.org domain are a problem.

Robert.

On 22 September 2015 at 22:47, Philip Taylor  wrote:

> Dear OSG email moderator,
>
>
>
> Following my email being hacked at my ISP, I seem to have lost the usual
> emails from the OSG list, unless there has been no activity for a week!
>
>
>
> I know from bounces that at least two junk emails were sent to the OSG
> mailing list and rejected.
>
>
>
> Please advise me on what needs to be done to restore the emails, as I am
> suffering withdrawal symptoms.
>
>
>
> Thank you
>
>
>
> Philip Taylor
>
>
>
>
>
> ___
> 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] Modern GLSL and OSG

[Garth D]

Hi Christian,

Many thanks for the interesting suggestion. :)

My main development environment is Linux-based, with a secondary 
virtualised Windows development environment. Due to the visualization 
(VirtualBox) I don't believe I can do much in the way of development 
with ANGLE due to its DX backend, at least with my current setup.


Having said that, being able to limit a future port to the OpenGL ES 2.0 
API subset could be very useful indeed. It is likely that I would be 
looking at the feasibility of moving the project I am working on to 
mobile devices in the future, and this sounds like something that could 
be very useful to use while I am doing so.


Cheers,
Garth

On 23/09/15 22:19, Christian Buchner wrote:> If you're using Windows you 
could try building OSG against ANGLE

> and limit yourself to the OpenGL ES 2.0 API feature set. Here you can't
> accidentially fall back into using deprecated (fixed function) features
> because these have been stripped from the API.
>
> There would also be plenty of books about OpenGL ES 2.0 available - 
and you

> can immediately target mobile platforms (iOS, Android)
>
> Christian
>
>
> 2015-09-23 14:44 GMT+02:00 Garth D :
>
>>
>> Hi all,
>>
>> I was wondering if anyone can make some suggestions as to resources that
>> are useful for learning GLSL in modern OpenGL (say, 3.0+) with a 
specific

>> focus on use with OSG.
>>
>> My existing GLSL knowledge is weak compared to my general 3D knowledge,
>> and mostly dates back to the early days of shaders. A lot of what I have
>> personally done with OpenGL and OSG has involved the fixed-function
>> pipeline, or things that map to it fairly closely.
>>
>> Thus far I've been digging around online for GLSL resources, but tend to
>> frequently find myself doing it the wrong way as I'm using features that
>> have since become deprecated. On the OSG side I tend to dig around 
in the

>> OSG examples and search the source to try to find the OSG equivalents to
>> OpenGL calls I see mentioned in the GLSL resources. I then put these
>> together and if I'm lucky something useful comes out. :)
>>
>> I think I'll figure things out eventually if I continue to crash around
>> blindly as I have been, but if anyone can suggest some better starting
>> points for GLSL use in OSG specifically, it would be much 
appreciated. :)

>>
>> Cheers,
>> Garth
>> ___
>> 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
>

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] INVALID_OPERATION with compressed textures with mipmaps in OSG 3.4.0.

[Davis, Timothy S CTR comnavairsyscom]

Robert

Sorry for the bad posting of my last message.  I'll repeat here and update with 
new information.

The code in question was added sometime during OSG 3.3.x development.  It was 
not in OSG 3.2.1.  I just recently jumped from 3.2.1 to 3.4.0 for my 
application which is when I ran into the problem.  It worked fine with OSG 
3.2.1.  In particular, it appears to be the added support for texture storage 
objects and not specifically "compressed texture support".  I noted the call 
that gave the error was glCompressTexSubImage2D.  However I should point out 
that I determined this using gDEBugger.  My version doesn't seem to understand 
the texture storage extension.  So the error may have been generated by the 
earlier call to setup the texture storage.  I checked into this and indeed an 
INVALID_OPERATION was generated by the call to glTexStorage2D. 

In addition, on my machine the problem doesn't affect all compressed textures 
with mipmaps.  The model that first caused the problem had several such 
textures, but only a small 32x32 texture resulted in a problem.  I have no idea 
why this would be the case.  However I remember others reporting issues with 
loading DDS textures and working around it by commenting out the following line 
in ReaderWriterDDS:
If ( mipmap_offset.size()>0) osgImage->setMipmapLevels(mipmap_offsets);
Commenting that line out would appear to disable mipmaps for compressed 
textures and avoid the problems I've indicated.  This older problem was 
reported only on OSX, but may be related.  This type of changed made to the IVE 
loader would also have fixed my problem at the expense of disabling mipmaps.

Looking at a different model, the one problem texture was 128x128.  So there 
appears to be nothing special about the size.  I did see that the rendering 
result for the models that have the problem is different between using the 
fixed-function pipeline and a shader.  With the FFP, the rendering appears 
correct, though the INVALID_OPERATION error is generated.  With a shader, the 
textures rendered black.

I looked at making a simple model that would reproduce the problem.  However, 
I've failed to create such a model.  It just always works with no render 
problems or OpenGL errors.

For my application, I've worked around the problem by reducing the number of 
mipmap levels to avoid using levels smaller than the compression block size.  
So I consider the problem fixed for me.  However, I feel this is information 
that you and the rest of the community can use.


Scott



smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Modern GLSL and OSG

[Garth D]

Replying to myself with what I have managed to figure out so far to 
provide some information in case it comes up in a search. I can't vouch 
for the accuracy as this is still new to me. Anyway:


- Compile messages end up being sent through the osg::NotifyHandler 
mechanism.


- Shaders don't appear to be compiled immediately, but if you use them 
(by attaching an osg::Program to a osg::StateSet with 
setAttributeAndModes()), they end up being compiled and used at a later 
point.


- osg::StateSet::addUniform() with a osg::Uniform argument seems to be 
the way to specify uniforms.


- osg::Program::addBindAttribLocation() is a means of binding variables 
to a specific attribute index (output location), which you need for 
other calls. I believe location layout qualifiers in the shaders 
themselves can be used as well.


- osg::Program::getAttribBindingList() seems to only return the 
variables set with addBindAttribLocation(), and not ones specified in 
the shader itself. This might be a timing issue, perhaps the results 
change after the shaders are actually compiled and linked?


- osg::State::setUseModelViewAndProjectUniforms(true) can be used to 
automatically hook up variables such as "osg_ModelViewProjectionMatrix", 
which seems to be an OSG analogue to  "gl_ModelViewProjectionMatrix". 
This seems to be a useful bridge while trying to figure things out.


- The compile messages can be used to confirm the actual attribute 
indexes used.


- Variables that aren't used may be optimised out, which makes them 
unavailable.


- Using Geometry::setVertexAttribArray with the last argument set 
correctly (eg. BIND_PER_VERTEX) seems to be the way that you can pass 
texture coordinates to shaders. I'm guessing other information such as 
vertices and normals are handled similarly.


Hopefully this helps someone in a similar situation to the one I was in.

On 23/09/15 22:14, Garth D wrote:

Hi all,

I was wondering if anyone can make some suggestions as to resources that
are useful for learning GLSL in modern OpenGL (say, 3.0+) with a
specific focus on use with OSG.

My existing GLSL knowledge is weak compared to my general 3D knowledge,
and mostly dates back to the early days of shaders. A lot of what I have
personally done with OpenGL and OSG has involved the fixed-function
pipeline, or things that map to it fairly closely.

Thus far I've been digging around online for GLSL resources, but tend to
frequently find myself doing it the wrong way as I'm using features that
have since become deprecated. On the OSG side I tend to dig around in
the OSG examples and search the source to try to find the OSG
equivalents to OpenGL calls I see mentioned in the GLSL resources. I
then put these together and if I'm lucky something useful comes out. :)

I think I'll figure things out eventually if I continue to crash around
blindly as I have been, but if anyone can suggest some better starting
points for GLSL use in OSG specifically, it would be much appreciated. :)

Cheers,
Garth
___
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