<div dir="ltr">HI Sandro,<br><div class="gmail_extra"><br><div class="gmail_quote">On 21 August 2017 at 17:41, Sandro Mani <span dir="ltr"><<a href="mailto:manisandro@gmail.com" target="_blank">manisandro@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF"><span class="gmail-"></span>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.<span class="gmail-"><br></span></div></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-">
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div>Things should work with just:<br>
              <br>
            </div>
            <div>cmake .<br>
            </div>
            <div>make -j 4   # 4 is number of cores available<br>
              <br>
            </div>
            <div>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.  <br>
            </div>
          </div>
        </div>
      </div>
    </blockquote></span>
    Well, in this case I needed it though, right? I mean, OPENGL_PROFILE
    defaults to "GL2".</div></blockquote><div><br></div><div>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<span class=""> </span>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,<br>
              <br>
            </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><div><div class="gmail-h5"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
            <div>export OSG_GL_CONTEXT_VERSION=4.0<br>
            </div>
            <div>export OSG_GL_CONTEXT_PROFILE_MASK=1</div>
          </div>
        </div>
      </div>
    </blockquote></div></div>
    Yes as mentioned this also works. But the open issue for me still
    remains the first context created by osgEarth::Capabilities::
    <div bgcolor="#FFFFFF">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.<span class="gmail-HOEnZb"><font color="#888888"></font></span></div></div></blockquote><div><br></div><div>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.<br><br></div><div>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.  <br><br></div><div>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.<br></div><div><br></div><div>Robert.<br></div><div><br><br><br><br><br><br></div><div> </div></div></div></div>