HI Sandro, On 21 August 2017 at 17:41, Sandro Mani <[email protected]> wrote:
> Agreed, I didn't put much though into it, I just checked that I hit the > OSG_GL3_FEATURES when doing the work on the context. > The OSG is able to detect and use features at runtime, you don't actually need to explictly set OSG_GL3_FEATURES. It's only when you start use a core profile do you need to be selective about the OSG_GL3_FEATURES, but these settings will be set appropriate if you choose OPENGL_PROFILE to be GL3 or GLCORE. > Things should work with just: > > cmake . > make -j 4 # 4 is number of cores available > > When you using the OPENGL_PROFILE it'll set the OSG_*_AVAILABLE options > for you, but in general build with defaults unless you specifically need a > particular feature set. > > Well, in this case I needed it though, right? I mean, OPENGL_PROFILE > defaults to "GL2". > 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_PROFILE if 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 > > 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. 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. Robert.
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
