Libvisual
Port old GL code in actors to work with OpenGL 3.2+ core profiles
The OpenGL code in Libvisual's collection uses API functions that are deprecated in OpenGL 3.0 and removed from OpenGL 3.2 Core Profile. Most notably, the fixed function pipeline has been removed, so no more glVertex() and matrix functions. They can be found under the Compatibility Profile but the OpenGL implementation is not required to support it.
If we want to make use of OpenGL 3.2+ core functionality without using extensions, we will need to port the plugins.
Note that OpenGL ES and WebGL both do not implement the fixed function pipeline. Porting the GL actors will also mean they can work on mobile devices.
Reserving this post to track the changes required.
| Actor | Functions | Status | |
|---|---|---|---|
| ☐ | lv_gltest | Transforms, Vertex Specifications | Not started |
| ☐ | madspin | Transforms, Vertex Specifications | Not started |
| ☐ | dancingparticles | Transforms, Vertex Specifications | Not started |
| ☐ | nebulus | Display Lists, Fog, Materials, Lights, TexCoord Generation, Transforms, Vertex Specifications | Not started |
| ☐ | flower | Lights, Materials, Transforms, Vertex Specifications | Not started |
| ☐ | nastyfft | Display Lists, Materials, Lights, Transforms, Vertex Specifications | Not started |
@kaixiong this matches the OpenGL related compile warnings we saw on macOS :+1: Btw you can add checkboxes to the status table about using [ ] syntax if you like. May need a bullet point - in front to work though.
@hartwork thanks for the suggestion but I couldn't get it to work even with the bullet point. In the end I resorted to Unicode.
For this porting, we will probably need to bring in GLEW or glad and introduce a few support functions for doing the following:
- Bind GLSL variables
- Load, compile and link shaders
- Matrix transformation code for scaling, rotation and projection
The actors that use the fixed function pipeline to light and shade their geometries will need to do so using GLSL vertex and fragment shaders
You can write them by typing - [ ] some thing
- [ ] first thing
- [ ] second thing
- [x] put an x between the brackets to cross it off
@hartwork thanks for the suggestion but I couldn't get it to work even with the bullet point. In the end I resorted to Unicode.
@kaixiong let's see if this works (EDIT: it does not, or not 100%). If it does, the two key ideas are ​ (zero width space) and more importantly this. They key advantage over Unicode is that we can edit state live with the mouse, if we want.
| Actor | Functions | Status | |
|---|---|---|---|
|
lv_gltest | Transforms, Vertex Specifications | Not started |
|
madspin | Transforms, Vertex Specifications | Not started |
|
dancingparticles | Transforms, Vertex Specifications | Not started |
|
nebulus | Display Lists, Fog, Materials, Lights, TexCoord Generation, Transforms, Vertex Specifications | Not started |
|
flower | Lights, Materials, Transforms, Vertex Specifications | Not started |
|
nastyfft | Display Lists, Materials, Lights, Transforms, Vertex Specifications | Not started |
For this porting, we will probably need to bring in GLEW or glad and introduce a few support functions for doing the following:
Glad does not seem to be widely available, but no concerns about GLEW.
The actors that use the fixed function pipeline to light and shade their geometries will need to do so using GLSL vertex and fragment shaders
To be sure I understand correctly, are you saying that lv_gltest will have to use shaders?
Glad does not seem to be widely available, but no concerns about GLEW.
@hartwork, Glad has OpenGL ES and Vulkan support and seems to be the more actively maintained of the two.
To be sure I understand correctly, are you saying that lv_gltest will have to use shaders?
Yes. The entire fixed function pipeline is replaced by programmable shaders (vertex, fragment, geometry).
lv_gltest will need a vertex shader to perform camera transformations on the geometry. The projection and modelview matrices will also have to be computed/constructed manually (easier than it sounds) and applied in the vertex shader. The matrix formulas are well documented.
Glad does not seem to be widely available, but no concerns about GLEW.
@hartwork, Glad has OpenGL ES and Vulkan support and seems to be the more actively maintained of the two.
@kaixiong that is nice but it's not widely available, even less than that: https://repology.org/project/glad/versions . Unless I'm looking at the wrong package, there is no Ubuntu, no Debian, no Gentoo, no Fedora. If that's reality, It's not something that will be a healthy dependency. Are we talking different packages?
To be sure I understand correctly, are you saying that lv_gltest will have to use shaders?
Yes. The entire fixed function pipeline is replaced by programmable shaders (vertex, fragment, geometry).
lv_gltest will need a vertex shader to perform camera transformations on the geometry. The projection and modelview matrices will also have to be computed/constructed manually (easier than it sounds) and applied in the vertex shader. The matrix formulas are well documented.
That sounds surprising. Let me double check this before moving existing plugins to shaders please.
@hartwork, you can view the OpenGL 3.2 API reference card here (PDF). The functions absent from Core Profile are in blue. The removed list includes the functions glRotate, glScale, glTranslate, glLoadIdentity, glMatrixMode, and glFrustrum.
@hartwork, here's a great site to learn about modern OpenGL. The section Transformations has example code on this (scroll all the way down). They use GLM for the standard matrices and matrix multiplications but we don't really need it.