OpenGL shader built in variables replacement

Question

I have an old vertex shader that used the 150 compatibility GLSL version:

#version 150 compatibility

out vertexData
{
    vec3 v;
    vec3 n;
} vertex;

void main()
{
    vertex.v = gl_Vertex.xyz;
    vertex.n = normalize(gl_NormalMatrix * gl_Normal);
  gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}

However I want to use this on OSX. How can I have access to both the built in variables like gl_ModelViewProjectionMatrix as well as syntax like out uniforms?

If I don't use glutInitDisplayMode(GLUT_3_2_CORE_PROFILE) then I get an old version of OpenGL that uses GLSL version 120 which uses all the old varying syntax, and can't support Geometry shaders apparently, if I do use the 3.2 core profile, then I have to manage all the matrices all myself and frankly I can't be bothered to do a bunch of boilerplate code that didn't need to be done previously.

OpenGL is a _low-level_ API. It's meant for communicating with the graphics drivers in a platform and hardware independent way; anything else is bloat that every graphics driver implementation needs to write and maintain. — Colonel Thirty Two, Feb 15 '16 at 00:29
It's not just the built in variables. It's also the matrix functions, which have different implementations (and thus performance and bugs) across implementations, and offers no advantages since they aren't implemented in hardware. And Vulkan, which is even more low-level, is poised to succeed OpenGL. — Colonel Thirty Two, Feb 15 '16 at 01:14

score 2 · Answer 1 · answered Feb 15 '16 at 00:14

2

However I want to use this on OSX. How can I have access to both the built in variables like gl_ModelViewProjectionMatrix as well as syntax like out uniforms?

You simply can't. Either you use legacy GL, which will limit you to GL2.1 / GLSL 1.20 on that platform, or you use a core profile, where none of those builtins are present.

if I do use the 3.2 core profile, then I have to manage all the matrices all myself and frankly I can't be bothered to do a bunch of boilerplate code that didn't need to be done previously.

You might not like it, but that is just what you have to do. The only profile required to be implemented according to the spec is core profile, so one can't rely on finding an implementation where old legacy GL and modern features like the geomerty shader might be mixed.

answered Feb 15 '16 at 00:14

derhass

43,833
2
57
78

Is there some library that will replace the built in variables like `gl_ModelViewProjectionMatrix` in the core profile? Or some simple guide, stating what needs to be done to replace each one? – Jonathan. Feb 15 '16 at 00:17
Also is there any explanation anywhere for this seemingly crazy deprecation? – Jonathan. Feb 15 '16 at 00:17
@Jonathan.: I'm not aware of a library which will do the complete uniform management. For matrix and vector math, the [glm library](http://glm.g-truc.net/) is quite popular, at least if you use C++. It follows GL conventions and notations, so works quite well when replacing your matrix functions. You might also find [this wiki atricle](https://www.opengl.org/wiki/Legacy_OpenGL#Removed_functionality) helpful. I also remember some project trying to emulate old GL on top of a core profile (but maye I misremeber it), but can't remeber the name, or how far it got. – derhass Feb 15 '16 at 00:26
1

@Jonathan.Might not be exactly what you're looking for, but I wrote a description of the main steps to change code to the core profile here: http://retokoradi.com/2014/03/30/opengl-transition-to-core-profile/. More specifically for the GLSL aspect, this might also help: http://stackoverflow.com/questions/24416589/glsl-using-custom-output-attribute-instead-of-gl-position. – Reto Koradi Feb 15 '16 at 01:16
@Jonathan: "*this seemingly crazy deprecation?*" It's removal, not deprecation. "Deprecated" means "available, but can be removed in later versions." – Nicol Bolas Feb 15 '16 at 01:22
@NicolBolas, I guess they are deprecated in the compatibility profiles and removed in the core profiles? There are so many different versions of different things it's hard to keep track. The whole things a mess – Jonathan. Feb 15 '16 at 01:46
@Jonathan: "*I guess they are deprecated in the compatibility profiles and removed in the core profiles?*" No. Nothing is deprecated in the compatibility profile. And it's only "a mess" because you're trying to use stuff that was removed. – Nicol Bolas Feb 15 '16 at 02:11
@Jonathan.: The reason for the removal of this stuff in the core profile is, that practically no serious application that uses OpenGL did use the built-in matrix functionality. In practically all 3D applications you need those transformation matrices for more than just graphics output (think collision detection, physics simulation, etc.). However in the OpenGL matrix stack you have only a single matrix per pipeline step and the stack which keeps a history of "premultiplication". This is simply not what you want to work with in complex settings. – datenwolf Feb 15 '16 at 17:20
@Jonathan.: So practically every serious application did its own matrix math for reasons of *convenience* and just `glLoadMatrix`-ed the relevant parts at time of rendering. So you actually have it kind of backwards: You may think the OpenGL matrix functions are convenient to work with. But in the grad scheme of things they're cumbersome and "nobody" did actually use them (where "nobody" refers to every application that goes beyond a simple tutorial, techdemo or undergraduate project). That's why they got removed: They're essentially dead weight. – datenwolf Feb 15 '16 at 17:24
@datenwolf The significance is of course only historical, but the matrix stack was actually quite widely used, including in commercial applications with many person years of development effort. So that was not the reason they were removed. – Reto Koradi Feb 16 '16 at 03:42
@RetoKoradi: Hmm, I'd like to know (honestly) which commercial applications this are. Because, frankly, of all the commercial OpenGL code I saw to this date, hardly anything does use the matrix stack, except for push/pop-ing it to isolate the glLoadMatrix in between. – datenwolf Feb 16 '16 at 05:39

OpenGL shader built in variables replacement

1 Answers1