[Bf-committers] Proposal: Up blender requirements to OpenGL 2.1

[Mike Erwin]

Here's a snippet from what I'm working on, since checking for GL version
was brought up in meeting. I like the float version better, but here's both:

#if 0

*bool* versionAtLeast(*int* major, *int* minor)

  {

  *int* actual_major, actual_minor;

  *const* *char** version_str = (*const* *char**)glGetString(GL_VERSION);

  *if* (sscanf(version_str, "%d.%d", &actual_major, &actual_minor) != 2)

     *return* *false*;

  printf("version %d.%d\n", actual_major, actual_minor);

  *return* actual_major > major || (actual_major == major && actual_minor
>= minor);

  }

#else

*bool* versionAtLeast(*float* desired_version)

  {

  *float* actual_version;

  *const* *char** version_str = (*const* *char**)glGetString(GL_VERSION);

  *if* (sscanf(version_str, "%f", &actual_version) != 1)

     *return* *false*;

  printf("version %.1f\n", actual_version);

  *return* actual_version >= desired_version;

  }

#endif


*void* showOpenGLInfo()

  {

  puts("--- OpenGL version ---");

// if (versionAtLeast(2,1))

  *if* (versionAtLeast(2.1))

     puts("GL version ok");

   *else*

     puts("GL version TOO LOW");


  printf("GLSL %s\n", (*char**) glGetString(GL_SHADING_LANGUAGE_VERSION));


  puts((*char**) glGetString(GL_VENDOR));

  puts((*char**) glGetString(GL_RENDERER));


  puts("--- OpenGL extensions ---");

  *char** multiple = (*char**) glGetString(GL_EXTENSIONS);

  *char** single;

  *while* (single = strsep(&multiple," "), strlen(single))

  puts(single);


  // query unchanging limits *once* at startup

  GLint value;

  glGetIntegerv(GL_MAX_ELEMENTS_VERTICES, &value);

  printf("GL_MAX_ELEMENTS_VERTICES: %d\n", value);

  glGetIntegerv(GL_MAX_ELEMENTS_INDICES, &value);

  printf("GL_MAX_ELEMENTS_INDICES: %d\n", value);

  glGetIntegerv(GL_MAX_TEXTURE_SIZE, &value);

  printf("GL_MAX_TEXTURE_SIZE: %d\n", value);


// puts("--- renderer info ---");

// long info;

// CGLGetParameter( contextObj, kCGLCPGPUVertexProcessing, &info );

// printf("vertex processing in %s\n", info ? "GPU" : "software");

// CGLGetParameter( contextObj, kCGLCPGPUFragmentProcessing, &info );

// printf("fragment processing in %s\n", info ? "GPU" : "software");

  }

In next release, before making 2.1 mandatory, we could check and do
*something* if the target system isn't up to snuff. Message in the info
header?. Pop up a message box?


Mike Erwin
musician, naturalist, pixel pusher, hacker extraordinaire

On Wed, Dec 31, 2014 at 6:07 AM, John James <kisolre at gmail.com> wrote:

> Is it possible to make an installation check of future requirements and
> display a strong warning (that is not easily bypassed by just clicking
> "Next") that there is a plan to make them obsolete. This will enable users
> to prepare beforehand and also give them possibility to object. If 50% are
> still using the old features should they be faced with the fact "No new
> updates for You!"? I am for the use of the latest features of the hardware
> when they are present by the way :)
>
> 2014-12-31 11:55 GMT+02:00 Martijn Berger <martijn.berger at gmail.com>:
>
> > Hi everyone,
> >
> > This is a great idea and should be effected as soon as possible ( 2.74 ).
> > As in practice blender does not run really well on graphics hardware that
> > is more then 10 years old anyway.
> > We can save ourselves a lot of bug reports and headaches by just adding a
> > check for this and warning users when we find less then OpenGL 2.1.
> > I am all for trying to keep blender accessible to a as large as possible
> > group of users.
> > But I think it is safe to say that anyone should have access to OpenGL
> 2.1
> > capable hardware as this translates to 10-11 year old hardware.
> >
> >
> >
> >
> >
> > On Tue, Dec 30, 2014 at 4:49 PM, Antony Riakiotakis <kalast at gmail.com>
> > wrote:
> >
> > > Hello again,
> > >
> > > The times of fixed function OpenGL pipeline have been very fun and
> > > happy, with coders trying to ingeniously hack the fixed function
> > > parameters to do the things they wanted.
> > >
> > > But I believe we are getting to the point where fixed function OpenGL
> > > starts holding us back. We already require GLSL support for some of
> > > the fancier features of blender, but probably it's time to feel free
> > > to consider shaders as the primary display mechanism if we want to,
> > > without needing to code fallbacks to a fixed function alternative.
> > >
> > > Especially anything that requires mixing multiple textures (such as
> > > texture painting with masks or brush overlays) or attributes in a non
> > > standard way is difficult without shaders.
> > >
> > > This is scheduled to happen as part of the viewport refactor, but
> > > having the hardware requirements there will enable us to do more
> > > improvements now.
> > >
> > > The proposal is not about throw away every legacy path next release,
> > > rather than assuming that users will need to have access to newer
> > > hardware from now on if they wish to access core features. Shader
> > > availability can be tested to avoid crashes but no alternative
> > > rendering path should be provided for those not meeting the
> > > requirements.
> > > _______________________________________________
> > > Bf-committers mailing list
> > > Bf-committers at blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> > >
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>