I had GLSL shaders working fine with #version 150 core. The vertex shader outputted gl_PointSize to a triangle strip geometry shader, which uses this to indicate the size of generated objects.
I changed to #version 300 es and got this error
error C7548: 'gl_PointSize' requires "#extension GL_EXT_geometry_point_size : enable" before use
This is mildly surprising -- I thought extensions were normally something you needed in older versions to enable functionality which is provided in later versions. Now it seems like I need to recover something which was lost, but this table seems to say that I can still use it.
What has changed which means I can't use gl_PointSize any more?
Desktop OpenGL and OpenGL ES are not the same thing. That table references desktop OpenGLx, not OpenGL ES of any version. If you ask for GLSL 3.00 ES, you will get GLSL 3.00 ES.
Desktop GLSL 1.50 is not a lesser version of GLSL ES 3.00. Nor is it a greater version. They have no relationship to each other, except in the sense that the ES versions take stuff from the desktop versions. But even that is arbitrary, generally unrelated to version numbers.
The thing is... OpenGL ES 3.00 does include gl_PointSize. But it is only as an output variable from the VS. Assuming that's how your shader uses it, your implementation has a bug in its OpenGL ES support.
Related
Found an article here OpenGL ES versus Vulkan, who is the performance king? mentioned that:
"The problem with OpenGL ES 3.1 is that while the graphics look immensely better than OpenGL ES 2.0, the performance hit is so great that games are basically not playable, looking at the image above comparing OpenGL ES 2.0 and 3.1 on my Nexus 6P shows that the exact same scene runs at a third of the frames per second compared to OpenGL ES 2.0. This is where Vulkan comes in, offering at least the same in graphics quality, but with improved performance. So how does Vulkan do?"
I can't imagine that 3.1 slower than 2.0 with the same scene. Had the author mistaken the image? Seems the right image have GI.
Had the author mistaken the image?
To me it seems that the author of that article is just dumb.
Just a quote from that article:
Vulkan still will not perform as well as the lower graphics capable OpenGL ES 2.0, as Vulkan displays a lot more on screen and the scenes it can render are a lot more complex
It's like saying that a Ferrari will not perform as well as a bicycle because you can ride 10 meters in a bicycle in 10 seconds, but can't drive 100 kilometers in a Ferrari in the same amount of time.
Now, about the image from that article:
It's not the same in OpenGL ES 3.1 and 2.0. I can at least see a more realistic lighting with reflections, as well as smoother looking walls, in the ES 3.1 screenshot.
To compare things like that you need at least to make sure that the resulting images are the same for both cases. If you are rendering a scene without postprocessing effects in one case, and with postprocessing effects on the other, then it's not the right comparison. Also, If you are rendering the scene with, say, a deferred renderer in one case, and a forward renderer in the other, then it's again not the right comparison, even if you got the same image.
I took a look at this article also while searching the same question myself, and please note that in it the author used unreal to do the comparisons. Enabling different options in unreal such as gl es 3 doesnt only change the gl version but also adds more realism that the engine assumes that gl es 3 can handle.
Is it possible to force a GPU to use highp floats in shaders when the OpenGL version being used is 2.0? I know that precision modifiers are basically a GLES concept, but floats do seem to use mediump by default on a desktop I was provided for testing, and it`s driving me nuts.
I`ve stumbled across that problem while running my GL project under Win10 with a GTX1070 GPU (driver version 23.21.13-9135). I don`t even have #version set in my shaders, so I expected the precision to be automatically maxed out.
AFAIK, OpenGL 2.x standard does not define any ways to hint the GPU that at least 20 of 24 mantissa bits are significant (passing integers through floats, since GL 2.0 cannot operate on integers natively), but that`s the first time in 3++ years that I`ve seen a desktop GPU do such a thing, so I`ve never even thought it possible.
Help needed.
I have a question regarding [glPushMatrix], together with the matrix transformations, and OpenGL ES. The GLSL guide says that under OpenGL ES, the matrices have to be computed:
However, when developing applications in modern versions of OpenGL and
OpenGL ES or in WebGL, the model matrix has to be computed.
and
In some versions of OpenGL (ES), a built-in uniform variable
gl_ModelViewMatrix is available in the vertex shader
As I understood, gl_ModelViewMatrix is not available under all OpenGL ES specifications. So, are the functions like glMatrixMode, glRotate, ..., still valid there? Can I use them to calculate the model matrix? If not, how to handle those transformation matrices?
First: You shouldn't use the matrix manipulation functions in regular OpenGL as well. In old versions they're just to inflexible and also redundant, and in newer versions they've been removed entirely.
Second: The source you're mentioning is a Wikibook which means it's not a authorative source. In the case of this Wikibook it's been written to accomodate for all versions of GLSL, and some of them, mainly for OpenGL-2.1 have those variables.
You deal with those matrices by calculating them yourself (no, this is not slower, OpenGL's matrix stuff was not GPU accelerated) and pass them to OpenGL either by glLoadMatrix/glMultMatrix (old versions of OpenGL) or a shader uniform.
If you're planning on doing this in Android, then take a look at this.
http://developer.android.com/reference/android/opengl/Matrix.html
It has functions to setup view, frustum, transformation matrices as well as some matrix operations.
I'm creating an iPhone app with cocos2d and I'm trying to make use of the following OpenGL ES 1.1 code. However, I'm not good with OpenGL and my app makes use of OpenGL ES 2.0 so I need to convert it.
Thus I was wondering, how difficult would it be to convert the following code from ES 1.1 to ES 2.0? Is there some source that could tell me which methods need replacing etc?
-(void) draw
{
glDisableClientState(GL_COLOR_ARRAY);
glDisableClientState(GL_TEXTURE_COORD_ARRAY);
glDisable(GL_TEXTURE_2D);
glColor4ub(_color.r, _color.g, _color.b, _opacity);
glLineWidth(1.0f);
glEnable(GL_LINE_SMOOTH);
if (_opacity != 255)
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
//non-GL code here
if (_opacity != 255)
glBlendFunc(CC_BLEND_SRC, CC_BLEND_DST);
glEnableClientState(GL_COLOR_ARRAY);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glEnable(GL_TEXTURE_2D);
}
It will not be that easy if you're not so fit in OpenGL.
OpenGL ES 2.0 doesn't have a fixed-function pipeline anymore. This means you have to manage vertex transformations, lighting, texturing and the like all yourself using GLSL vertex and fragment shaders. You also have to keep track of the transformation matrices yourself, there are no glMatrixMode, glPushMatrix, glTranslate, ... anymore.
There are also no buitlin vertex attributes anymore (like glVertex, glColor, ...). So these functions, along with the corresponding array functions (like glVertexPointer, glColorPointer, ...) and gl(En/Dis)ableClientState, have been reomved, too. Instead you need the generic vertex attribute functions (glVertexAttrib, glVertexAttribPointer and gl(En/Dis)ableVertexAttribArray, which behave similarly) together with a corresponding vertex shader to give these attributes their correct meaning.
I suggest you look into a good OpenGL ES 2.0 tutorial or book, as porting from 1.1 to 2.0 is really a major change, at least if you never have heard anything about shaders.
Is there a way in OpenGL ES to do flat shading without repeating each vertex for every triangle?
In regular OpenGL this is done with glShadeModel but in ES I write the shaders so its not that simple.
GLSL 1.3 or 1.4 (not sure) introduces the keyword flat which seem to enable this but unfortunately ES 2.0 doesn't have this yet.
Yet another way to do this uses dFdx,dFdy functions which, alas, are also missing in ES.
No, flat-shading is not a feature of OpenGL ES 2.0, sorry.