My vertex shader decides to discard some triangles. If a triangle should be discarded, what I currently do is set the output position to NaN:
gl_Position = vec4(intBitsToFloat(int(0xFFC00000u)), intBitsToFloat(int(0xFFC00000u)), intBitsToFloat(int(0xFFC00000u)), intBitsToFloat(int(0xFFC00000u)));
intBitsToFloat(int(0xFFC00000u)) is floating point NaN.
This works on the platforms I tested it on.
However, Section 2.3.4.1 of the OpenGL ES 3.2 Spec states that
The special values Inf and −Inf encode values with magnitudes too
large to be represented; the special value NaN encodes “Not A Number”
values resulting from undefined arithmetic operations such as 0/0.
Implementations are permitted, but not required, to support Inf's and
NaN's in their floating-point computations.
So my approach might actually yield undefined behavior.
What's the proper, well defined OpenGL ES 3.x way to completely discard a triangle in the vertex shader?
The result is required to be consistent, even if NaN is not generated. If you set all 3 vertices to NaN (or whatever the fallback value turns out to be) then they are going to be coincident locations. Any two coincident vertices in a triangle = zero area = culled. So I think this works in either case ...
Related
I'm working on porting a Direct3D terrain renderer to Android and just learned that OpenGL did not have an equivalent to the BaseVertexIndex parameter of DrawIndexedPrimitive until version 3.2 introduced the glDrawElementsBaseVertex method. That method is not available in OpenGL ES.
The D3D terrain renderer uses a single, large vertex buffer to hold the active terrain patches in an LRU fashion. The same 16-bit indices are used to draw each patch.
Given the lack of a base vertex index offset in OpenGL ES, I can't use the same indices to draw each patch. Furthermore, the buffer is too large for 16-bit absolute indices. The alternatives I've identified are:
Use one VBO or vertex array per patch.
Use 32-bit indices and generate new indices for every block in the VBO.
Stop using indexing and replicate vertices as needed. Note that most vertices appear in six triangles. Switching to triangle strips could help, but still doubles the number of vertices.
None of these seem very efficient compared to what was possible in D3D. Are there any other alternatives?
You didn't specify the exact data layout of your VBOs, but if your base vertex offset is not negative you can apply an offset when binding the VBO to the vertex attribute (glVertexAttribPointer).
When specifying a value that does not vary over each vertex to my vertex shader, I have the option of either specifying it as a uniform or as a constant vertex attribute (using glVertexAttrib1f and friends).
What are the reasons for which I should choose one over the other? Simply that there are a limited number of available vertex attributes and uniforms on any given implementation and thus I need to choose wisely, or are there also performance implications?
I've done some looking around and found a few discussions, but nothing that answers my concerns concretely:
- http://www.khronos.org/message_boards/showthread.php/7134-Difference-between-uniform-and-constant-vertex-attribute
https://gamedev.stackexchange.com/questions/44024/what-is-the-difference-between-constant-vertex-attributes-and-uniforms
I'm by no means an OpenGL guru, so my apologies if I'm simply missing something fundamental.
Well, vertex attributes can be setup to vary per-vertex if you pass a vertex attribute pointer; you can swap between a constant value and varying per-vertex on the fly simply by changing how you give data to a particular generic attribute location.
Uniforms can never vary per-vertex, they are more constant by far. Generally GLSL ES guarantees you far fewer vertex attribute slots (8, with up to 4 components each) to work with than uniform components (128 vectors, 4 components each) - most implementations exceed these requirements, but the trend is the same (more uniforms than attributes).
Furthermore, uniforms are a per-program state. These are constants that can be accessed from any stage of your GLSL program. In OpenGL ES 2.0 this means Vertex / Fragment shader, but in desktop GL this means Vertex, Fragment, Geometry, Tessellation Control, Tessellation Evaluation.
what is the difference between invariance and polygon offset in OpenGL. I am getting confused with both. Since both are related to low precession problems.
From the GLES 2.0 spec:
[...] variance refers to the possibility of getting different values
from the same expression in different shaders. For example, say two
vertex shaders each set gl_Position with the same expression in both
shaders, and the input values into that expression are the same when
both shaders run.
It is possible, due to independent compilation of the two shaders,
that the values assigned to gl_Position are not exactly the same when
the two shaders run. In this example, this can cause problems with
alignment of geometry in a multi-pass algorithm. In general, such
variance between shaders is allowed. To prevent variance, variables
can be declared to be invariant, either individually or with a global
setting.
In other words, invariant is a mechanism provided by gles for you (the programmer) to tell the implementation that when a certain shader code is compiled, the gpu code generated must be the same every time.
Polygon offset is, ummm, completely unrelated. I refer you to the official FAQ https://www.opengl.org/archives/resources/faq/technical/polygonoffset.htm
Like many 3d graphical programs, I have a bunch of objects that have their own model coordinates (from -1 to 1 in x, y, and z axis). Then, I have a matrix that takes it from model coordinates to world coordinates (using the location, rotation, and scale of the object being drawn). Finally, I have a second matrix to turn those world coordinates into canonical coordinates that OopenGL ES 2.0 will use to draw to the screen.
So, because one object can contain many vertices, all of which use the same transform into both world space, and canonical coordinates, it's faster to calculate the product of those two matrices once, and put each vertex through the resulting matrix, rather than putting each vertex through both matrices.
But, as far as I can tell, there doesn't seem to be a way in OpenGL ES 2.0 shaders to have it calculate the matrix once, and keep using it until the one of the two matrices used until glUniformMatrix4fv() (or another function to set a uniform) is called. So it seems like the only way to calculate the matrix once would be to do it on the CPU, and then result to the GPU using a uniform. Otherwise, when something like:
gl_Position = uProjection * uMV * aPosition;
it will calculate it over and over again, which seems like it would waste time.
So, which way is usually considered standard? Or is there a different way that I am completely missing? As far as I could tell, the shader used to implement the OpenGL ES 1.1 pipeline in the OpenGL ES 2.0 Programming Guide only used one matrix, so is that used more?
First, the correct OpenGL term for "canonical coordinates" is clip space.
Second, it should be this:
gl_Position = uProjection * (uMV * aPosition);
What you posted does a matrix/matrix multiply followed by a matrix/vector multiply. This version does 2 matrix/vector multiplies. That's a substantial difference.
You're using shader-based hardware; how you handle matrices is up to you. There is nothing that is "considered standard"; you do what you best need to do.
That being said, unless you are doing lighting in model space, you will often need some intermediary between model space and 4D homogeneous clip-space. This is the space you transform the positions and normals into in order to compute the light direction, dot(N, L), and so forth.
Personally, I wouldn't suggest world space for reasons that I explain thoroughly here. But whether it's world space, camera space, or something else, you will generally have some intermediate space that you need positions to be in. At which point, the above code becomes necessary, and thus there is no time wasted.
I have googled around but havnt found an answer that suits me for OpenGL.
I want to construct a sparse matrix with a single diagonal and around 9 off-diagonals. These diagonals arent necessarily next to the main diagonal and they wrap around. Each diagonal is an image in row-major format i.e. a vector of size NxM.
The size of the matrix is (NxM)x(NxM)
My question is as follows:
After some messing around with the math I have arrived at the basic units of my operation. It involves a pixel by pixel multiplication of two images (WITHOUT limiting the value of the result i.e. so it can be above 1 or below 0), storing the resulting image and then adding a bunch of the resulting images (SAME as above).
How can I multiply and add images on a pixel by pixel basis in OpenGL? Is it easier in 1.1 or 2.0? Will use of textures cause hard maxing of the results to between 0 and 1? Will this maximize the use of the gpu cores?
In order to be able to store values outside the [0-1] range you would have to use floating point textures. There is no support in OpenGL ES 1.1 and for OpenGL ES 2.0 it is an optional extension (See other SO question).
In case your implementation supports it you could then write a fragment program to do the required math.
In OpenGL ES 1.1 you could use the glTexEnv call to set up how the pixels from different texture units are supposed to be combined. You could then use "modulate" or "add" to multiply/add the values. The result would be clamped to [0,1] range though.