11-10-2021, 08:34 AM
Something I was not aware of, but am passing on here relating to extensions in OpenGLES3.x
Though it seems odd, the gl3ext.h file is redundant, it has no content, in fact all extensions for OpenGLES3.x are actually listed in gl2ext.h
I know right? This was news to me, but happy to have been informed about it.
Anyway, I post this because I was just trying out the new Geometry Shader extensions on the latest mesa drivers for Raspberry (Bullseye OS, mesa 20.3.5) and was having some issues getting it to recognise GL_GEOMETRY_SHADER as a valid shader type to compile and link.
Geometry Shaders are a 3.2 feature of course, so I included the gl32.h header and it worked fine and is an exciting addition, expecially to make particles more interesting and for a quick normal display debug option. But it niggled me that was probably going to cause an issue using that header, and posted a question on the Raspberry forums which I'm happy to say was responded to promptly.
Use the gl2ext.h header and for the type of shader use, GL_GEOMETRY_SHADER_OES and now we're in business. The only other thing to do is make sure in the gshader itself you inform the shader to use a couple of important extension values to allow it to compile, it needs to be version 310 es and you have to inform it about 2 extensions that are required to make it work
#version 310 es
#extension GL_EXT_geometry_shader : require
#extension GL_EXT_shader_io_blocks : require
thats it.. when you make a PO, just add the geometry shader you compile to the vertex and fragment shader before you link. It will sit in the middle of them, they seem to work very well, though I've not pushed them to any extreme, I can indeed generate new vertex outputs. I will tinker with them a little more and report any problems.
There's a great tutorial on geometry shaders here
Though it seems odd, the gl3ext.h file is redundant, it has no content, in fact all extensions for OpenGLES3.x are actually listed in gl2ext.h
I know right? This was news to me, but happy to have been informed about it.
Anyway, I post this because I was just trying out the new Geometry Shader extensions on the latest mesa drivers for Raspberry (Bullseye OS, mesa 20.3.5) and was having some issues getting it to recognise GL_GEOMETRY_SHADER as a valid shader type to compile and link.
Geometry Shaders are a 3.2 feature of course, so I included the gl32.h header and it worked fine and is an exciting addition, expecially to make particles more interesting and for a quick normal display debug option. But it niggled me that was probably going to cause an issue using that header, and posted a question on the Raspberry forums which I'm happy to say was responded to promptly.
Use the gl2ext.h header and for the type of shader use, GL_GEOMETRY_SHADER_OES and now we're in business. The only other thing to do is make sure in the gshader itself you inform the shader to use a couple of important extension values to allow it to compile, it needs to be version 310 es and you have to inform it about 2 extensions that are required to make it work
#version 310 es
#extension GL_EXT_geometry_shader : require
#extension GL_EXT_shader_io_blocks : require
thats it.. when you make a PO, just add the geometry shader you compile to the vertex and fragment shader before you link. It will sit in the middle of them, they seem to work very well, though I've not pushed them to any extreme, I can indeed generate new vertex outputs. I will tinker with them a little more and report any problems.
There's a great tutorial on geometry shaders here
Brian Beuken
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's