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
<[email protected]> 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
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
