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

Reply via email to