I am trying to use a single matrix stack for both OpenGL and Direct3D APIs. From all my research on this site and other articles at:
Article 1,
Article 2 among others, it is my understanding that this should be fairly easy as long as certain nuances are handled and consistency is maintained.
Also, this MSDN Article suggests that HLSL by default uses column_major format.
So I have a working Right-Handed Coordinate System, Column_Major MVP matrix for opengl.
I am trying to use this same matrix in DirectX. Since it is a Right-Handed System, I made sure that I do set rasterizerDesc.FrontCounterClockwise = true;
I have the following in my HLSL shader :
output.position = mul(u_mvpMatrix, input.position);
Note that in the above code I am using a post-multiplication as my mvp-matrix is column major and I send it to the shader without transposing it. So it should send it as column major and therefore, the post-multiplication.
Note: I did try pre-multiplication as well as post and pre-multiplication with the transpose of my mvp.
When calculating the projection matrix, as suggested in Article 2 above, I make sure that the depth range for DX is 0-1 and for openGl it is -1-to-1!
I even tested my resulting matrix against the XMMatrixPerspectiveFovRH function from the DirectXMath library and my matrix matches the one produced by that function.
Now with Rasterization flag set ->FrontCounterClockwise = true, RH column major MVP matrix, with correct depth scaling, I would have expected that this would be all that would be needed to get D3D to work with my Matrix.
What is it that I am missing here?
P.S: I believe I provided all the information here, but please let me know if any more information is needed.
Related
I wonder if there is a way how to compute a rotationmatrix using OpenGL shading language, i.e. doing the calculation using a shader. (Optimally by two given vectors using quaternionpower.)
Some background:
I have a project, where I want to implement a lightfield on the vertices of a 3D mesh (+interpolation) that requires vectors to be in local coordinates (Torrance, Lafortune, etc...).
Now this requires the calculation of a rotation matrix quite a number of times(Number of vertices should be scalable). This could be done somewhere in normal sourcecode using normal CPU, but I was hoping to find a way to use the power of the graphicscard to do this job for me.
Till now I could find any hint in the OpenGL manual itself nor anywhere else...
I'm getting started with a OpenGL ES app (C++/SDL) running on a Raspberry PI, that I'll want to output through a pocket projector.
I want to give the user the ability to correct the distortion caused by aiming the projector from a direction that is non-normal to the surface. The surface will also be smaller than the projected area. To do this, the user will be able to "move" the 4 corners of the projection window independently to match the surface.
I was planning to do this by solving a simple linear system of equations that transforms the original corners (in the current projection matrix coordinates) to the corners set by the user, and just push this resulting matrix on top of the GL_PROJECTION matrix stack.
However... I found out that I can't "read" the projection matrix in OpenGL ES:
float matrix[16];
glGetFloatv(GL_PROJECTION_MATRIX, matrix);
In particular, the GL_PROJECTION_MATRIX symbol doesn't exist... and I've even read that there's no such thing as a projection matrix in OpenGL ES (something I find hard to believe, but I'm totally new to it, so...).
Any idea of a workaround for reading this matrix, or maybe an alternative approach to do what I'm trying to do?
Thanks!
OpenGL ES 1.x has a projection matrix, and you should be able to get the current value with exactly the code you have in your question. See http://www.khronos.org/opengles/sdk/1.1/docs/man/glGet.xml for the documentation confirming this, or the header file at http://www.khronos.org/registry/gles/api/GLES/gl.h.
ES 2.0 and higher are a different story. ES 2.0 eliminates most of the fixed pipeline that was present in ES 1.x, and replaces it with shader based rendering.
Therefore, concepts like a built-in projection matrix don't exist anymore in ES 2.0 and are replaced with the much more flexible concept of shader programs written in GLSL. If you want to use a projection matrix in ES 2.0, you have a matrix variable in your vertex shader code, pass a value for the matrix into the shader program (using the glUniformMatrix4fv API call), and the GLSL code you provide for the vertex shader performs the multiplication of vectors with the projection matrix.
So in the case of ES 2.0, there is no need for a glGet*() call for the projection matrix. If you have one, you calculated it, and passed it into the shader program. Which means that you already have the matrix in your code. Well, you could get any matrix value back with the glGetUniformfv() API call, but it's much easier and cleaner to just keep it around in your code.
I have large amount of vertices generated by WPF library/application. I am trying use these vertices values in an OpenGL application.
Basically, converting from DirectX LH co-ordinate to OpenGL RH co-ordinate system. I have read Converting DirectX vertexes to OpenGL vertexes post and changed the indices/faces to point first, third and second but to no positive result.
I haven't go any matrix values, so only thing I have done is changed the vertices order. Can any help me in finding a solution to this.
Here is a screenshot of the current result:
You don't really need to bother with second part of vertex recalculation: index shuffling. It is very error prone. You can just set up GL rasterization to disable culling glDisable(GL_CULL_FACE) or change winding order glFrontFace(GL_CW).
It is still rest for you to negate z coordinates or use additional rotation matrix, but that's much easier.
Issue shown can be unrelated to vertex recalculation. Looking to pictures it looks more like a transformation matrices bugs.
I have been reading through the specification of openGL 1.5, and saw that any reference to what used to be a variable holding the reference to the ModelView matrix (like gl_ModelViewMatrix) has been deprecated, and is only availble in some kind of compatability mode (which happens not to be supported on my GPU).
I have seen a few examples first retrieving the ModelView matrix or creating one, then sending it back to the GPU as a uniform variable.
Now this all seems just backward to me; even for a simple Vertex Shader you will in many cases want to use some kind of transformation on the geometry.
So I am really wondering now; is there any way to get the current ModelView matrix from within a vertex shader, using GLSL 1.5?
OpenGL-3 core completely dropped the matrix stack, i.e. the built-in modelview, projection, texture and color matrices. It's now expected from you to implement the matrix math and supply the matrices through self chosen uniforms.
There is no built in matrix system/lib in core openGL - since 3.+ version.
A lot of people had similar (bad) opinions about that "huge change" in openGL.
You have to use your own set of functions to perform matrix calculation. See libraries like: GLM or in lighthouse3D.
All in all it was very useful to have matrix functions in OpenGL when learning. Now you have to look for other solutions...
On the other side it is not a problem for game engines or game frameworks that usually have their own math libraries. So for them "new" OpenGL is even easier to use.
I'd like to set up an orthographic projection using only modern OpenGL techniques (i.e. no immediate-mode stuff). I'm seeing conflicting info on the web about how to approach this.
Some people are saying that it's still OK to call glMatrixMode(GL_PROJECTION) and then glOrtho. This has always worked for me in the past, but I'm wondering if this has been deprecated in modern OpenGL.
If so, are vertex shaders the standard way to do an orthographic projection nowadays? Does GLSL provide a handy built-in function to set up an orthographic projection, or do I need to write that math myself in the vertex shader?
If so, are vertex shaders the standard way to do an orthographic projection nowadays?
Not quite. Vertex shaders perform the calculations, but the transformation matrices are usually fed into the shader through a uniform. A shader should only evaluate things, that vary with each vertex. Implementing a "ortho" function, the returns a projection matrix in GLSL is counterproductive.
I'd like to set up an orthographic projection using only modern OpenGL techniques (i.e. no immediate-mode stuff). I'm seeing conflicting info on the web about how to approach this.
The matrix stack of OpenGL before version 3 has nothing to do with the immediate mode. Immediate mode was glBegin(…); for(…){ ...; glVertex(…);} glEnd(). And up to OpenGL version 3 is was rather common to use the matrices specified through the matrix stack in a vertex shader.
With OpenGL-3 it was aimed to do, what was originally planned for OpenGL-2: A unification of the API and removing old cruft. One of those things removed was the matrix stack. Many shaders already used more than the standard matrices already, anyway (like for example for skeletal animation), so matrices already had been passed as uniforms and the programs did already contain the whole matrix math code. Taking the step of remocing the matrix math stuff from OpenGL-3 was just the next logical step.
In general, you do not compute matrices in shaders. You compute them on the CPU and upload them as uniforms to the shaders. So your vertex shader would neither know nor care if it is for an orthographic projection or a perspective one. It just transforms by whatever projection matrix it is given.
When you target an OpenGL version > 3.0, glOrtho has been removed from the official specs (but still is present in the compatability profile), so you shouldn't use it anymore. Therefore, you will have to calculate the projection you want to use directly within the vertex shader
(for OpenGL up to 3.0 glOrtho is perfectly ok ;).
And no there is no "handy" function to get the projection matrix in GLSL, so you have to specify it yourself. This is, however, no problem, as there is a) plenty of example code in the web and b) the equations are right in the OpenGL spec, so you can take it simply from there if you want to.