[osg-users] Modern GLSL and OSG

Garth D garthy_gso at entropicsoftware.com
Fri Sep 25 20:02:11 PDT 2015


Hi Jan,

Many thanks for the additional information. :)

On 25/09/15 17:48, Jan Ciger wrote:
> On Fri, Sep 25, 2015 at 2:01 AM, Garth D
> <garthy_gso at entropicsoftware.com> wrote:
>> Thankyou for the suggestion. :)
>>
>> I have to admit being unsure how to set the specific context at present.
>>
>>  From what I've read, there'd need to be a glXCreateContextAttribsARB call
>> somewhere to create the GL3 context under Linux- and there doesn't seem to
>> be one. Skimming the source (I'm presently using OSG 3.2.1, but had a peek
>> at 3.4.0) suggests that perhaps this support is only available on a Windows
>> build. On the cmake side, OSG_GL3_AVAILABLE in my build is off. However,
>> glVersion=4.4 appears in my log during a build.
>
> The cmake variables are meant to be set by the developer, see the
> instructions here:
>
> http://permalink.gmane.org/gmane.comp.graphics.openscenegraph.user/72253
>
> It is possible that GL3 support is still available on Windows only,
> but even if that is the case, it shouldn't be terribly difficult to
> make it work in Linux too. The drivers and OpenGL implementations
> certainly support it now.

Thanks. I thought this might be the case.

>> I'm beginning to suspect that aiming for strict OpenGL 3+ or 4+ might not be
>> the best thing for me to concentrate at the moment. I might be better off
>> just using it where it helps and leaving a jump to "pure" modern GL until a
>> later date.
>
> Well, it depends on what you want to do. Moving to the "modern" OpenGL
> without the fixed pipeline functionality is a big jump, because
> basically you don't have anything pre-defined by the library anymore.
> No matrix stack (glPush/glPop), everything needs to be managed using
> shaders, etc. The older functionality is easier to make display
> something on the screen quickly, because there are fewer things to set
> up. The newer stuff gives you much more flexibility, though.

Excellent, many thanks for the explanation and clarification.

My original motivation was to move to using "modern" OpenGL (ie. 
avoiding anything deprecated) because I didn't want to be in the 
situation where I started relying on something that was likely to be 
removed in the future.

Additionally, I have a need that I know is not going to be handled very 
well in the fixed-function pipeline. From experience I know that whilst 
the FFP is neat for simpler tasks, it feels like a massive burden as the 
needs get more complex.

A last goal was as a learning exercise. The aim was to rely on shader 
functionality a bit more strictly than minimally necessary, as a means 
of taking care of the glaring (and increasingly hard-to-explain 
professionally) hole in my 3D knowledge.

As I've been digging around the first goal seems less and less 
important, so my goals have been shifting somewhat. Going pure non-FFP 
is something I can handle down the track.

 > Using OSG
 > helps to hide this complexity, because OSG abstracts and manages many
 > of these things for you, regardless of which OpenGL profile are you
 > using.

Excellent. I couldn't tell if this was the case, or if OpenGL 3+ was an 
experimental thing in OSG, or how complete the OSG support for it was.

At this point I've made it over the initial hurdle of setting things up 
properly in OSG and getting the basics running, so I'm on to the meat of 
the task at this point- messing about with the shaders themselves.

Thanks for taking the time to write that up, it has clarified things 
considerably. Much appreciated. :)

Cheers,
Garth




More information about the osg-users mailing list