Hi Robert
On 21.08.2017 19:06, Robert Osfield wrote:
You should only need to OPENGL_PROFILE something other than defaults
if you specifically want just a non compatible graphics context. It
sounds like the Intel driver might require OPENGL_PROFILEif you want
to enable the latest GL features, something you won't need under
NVIidia and possible AMD. Try using the OSG_GL_CONTEXT_VERSION and
OSG_GL_CONTEXT_PROFILE_MASK env vars instead of the above
DisplaySettings::instance() code i,e,
export OSG_GL_CONTEXT_VERSION=4.0
export OSG_GL_CONTEXT_PROFILE_MASK=1
Ok I'll fire off a build without passing any cmake options and check
what happens when I just set the environment variables.
Yes as mentioned this also works. But the open issue for me still
remains the first context created by osgEarth::Capabilities::
Capabilities (see first of the stack traces I posted above). In my
view either this is a bug in osgEarth that it creates the traits
without honouring the desired GL version, or OSG should otherwise
ensure the traits contain the overridden GL version.
I don't think it's appropriate to classify a bug for something that is
retrospectively using the software with drivers that add their own
constraints. The OSG hasn't ever worked the way you want it to work -
I've only just integrated the changes to the OSG to support passing
the GL versions for GLX, so only now can we start talking about
passing on suggestions of how to utilize it to the osgEath team.
Sure. However I'm curious, how is the logic supposed to work under
Windows, where support for specifying the GL version was already
implemented? Wouldn't you hit the same issues on that platform also?
I see it as a constraint on osgEarth working with Intel drivers and
recent GL versions and associate drivers. What we are talking about is
working around these constraints in the driver to provide to full
osgEarth functionality across a wider range of hardware. The first
step has been to add the GL version functionality to OSG's GLX support.
Whether we need to push any changes to osgEarth is something I'm not
clear on, if the above export's now work with OSG master and osgEarth
then I think we are most of the way to getting what is reasonable to
expect.
Not that I want to be annoying or repetitive, but surely it's not ideal
that osgEarth::Capabilities::Capabilities performs it's checks with a
1.0 context, even though you specify OSG_GL_CONTEXT_VERSION=4.0? Or am I
missing something here?
Best
Sandro
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org