Note: Apologies for links/images being nothing more than text - as a new user I can't post images and can't post >2 hyperlinks.
So I've been using deprecated OpenGL for some time, and decided a few weeks ago to finally make the jump to the more modern methods. I got quite far, using Open.gl as a resource (I found the LWJGL tutorials to be inconsistent and sparse), and am able to render up to this tutorial's last image.
However, I run into some serious problems on the next page (rendering a cube).
I've done a lot of research on the issue and have refined/reorganised my code so many times so as to understand every component's purpose fully and ensure I've not missed something basic (like forgetting to flip buffers), and have only managed to narrow down the areas I believe the error could be occurring.
So, my basic goal is to be rendering a cube, using this example code: http://open.gl/content/code/c5_cube.txt
Here is my code for comparison: http://pastie.org/5864112#241
The results I get from my code are as follows:
If I translate the View Matrix only in the Z direction, I get exactly the same as the image at the end of the last tutorial: https://dl.dropbox.com/u/38489921/vbo11.png
//set up view matrix - TODO: problem 1?
Matrix4f view = new Matrix4f();
view.setIdentity();
view.translate(new Vector3f(0.0f, 0.0f, -2f));
view.m13 = 1f;
FloatBuffer viewSend = BufferUtils.createFloatBuffer(16);
view.store(viewSend);
viewSend.flip();
int uniView = glGetUniformLocation(shaderProgram, "view");
glUniformMatrix4(uniView, false, viewSend);
This could actually be my problem here - the example code uses glm::lookAt(), which I don't have access to, so I could just be doing the complete wrong thing with the matrix.
Moving on, if I translate the view Matrix any amount in the Y direction (code below image), I get a kind of distorted cube: https://dl.dropbox.com/u/38489921/vbo12.png
//set up view matrix - TODO: problem 1?
Matrix4f view = new Matrix4f();
view.setIdentity();
view.translate(new Vector3f(0.0f, 1.0f, -2f));
view.m13 = 1f;
FloatBuffer viewSend = BufferUtils.createFloatBuffer(16);
view.store(viewSend);
viewSend.flip();
int uniView = glGetUniformLocation(shaderProgram, "view");
glUniformMatrix4(uniView, false, viewSend);
This led me to believe it was a problem with perspective projection, so I did a bit more research and ensured that my perspective() function is correct. Almost no changes to the projection implementation change the visual results, so instead I'll just highlight the function and how I use it here:
//set up projection matrix //TODO: problem 2?
Matrix4f proj = perspective(90f, 600f / 800f, 1f, 10f);
FloatBuffer projSend = BufferUtils.createFloatBuffer(16);
proj.store(projSend);
projSend.flip();
int uniPersp = glGetUniformLocation(shaderProgram, "proj");
glUniformMatrix4(uniPersp, false, projSend);
private Matrix4f perspective(float fov, float aspectRatio, float zNear, float zFar) {
float zm = zFar - zNear;
float zp = zFar + zNear;
Matrix4f persp = new Matrix4f();
persp.m00 = (1 / (float)Math.tan(Math.toRadians(fov / 2))) / aspectRatio;
persp.m11 = 1 / (float)Math.tan(Math.toRadians(fov / 2));
persp.m22 = -zp / zm;
persp.m23 = -1;
persp.m32 = -((2 * zNear * zFar) / zm);
return persp;
}
This, in my opinion, is a very strange error to be getting, and I completely fail to understand it. After the mound of research to try and fix it myself, honestly it's gotten to the point where my brain hurts, so I thought I'd ask for some help.
My goal here is to ascertain what is causing this error, why, and how I would fix it (and, if necessary, any special tips or tricks I can use to ensure this type of error doesn't occur again). I'm appreciative of any help and will give any further information needed.
Thanks much,
- Jonno.
Can't quite understand what is your problem. You say that when you translating your view matrix you get unexpected behaviour... Right?
I don't see any errors in your matrix setup, so, please, provide your GLSL shaders code and the moment when you declare your vertices information of the image (not image as a texture, but image as a 3D object in space). I guess there is something wrong with that (you can't just get a cube while you have only 4 vertices, so maybe you have more).
Also, just to help you, this is code for "Modern gluLookAt"
public Matrix4f set(float cameraX, float cameraY, float cameraZ,
float lookX, float lookY, float lookZ){
//My advice to you: you shouldn't create new matrix everytime,
//it will give you little glitches.
//Create some new class containing this method, change type to void
//and declare "matrix" as a field - make your own "camera" object (java object)
Matrix4f matrix = new Matrix4f();
Matrix4f aux = new Matrix4f();
Vector3f dir = new Vector3f(lookX - cameraX, lookY - cameraY, lookZ - cameraZ);
Vector3f up = new Vector3f(0, 1f, 0);
Vector3f right = new Vector3f();
dir.normalise();
Vector3f.cross(dir,up,right);
right.normalise();
Vector3f.cross(right,dir,up);
up.normalise();
matrix.m00 = right.getX();
matrix.m01 = right.getY();
matrix.m02 = right.getZ();
matrix.m03 = 0.0f;
matrix.m10 = up.getX();
matrix.m11 = up.getY();
matrix.m12 = up.getZ();
matrix.m13 = 0.0f;
matrix.m20 = -dir.getX();
matrix.m21 = -dir.getY();
matrix.m22 = -dir.getZ();
matrix.m23 = 0.0f;
matrix.m30 = 0.0f;
matrix.m31 = 0.0f;
matrix.m32 = 0.0f;
matrix.m33 = 1.0f;
//setup aux as a translation matrix by placing positions in the last column
aux.m30 = -cameraX;
aux.m31 = -cameraY;
aux.m32 = -cameraZ;
//multiplication(in fact translation) viewMatrix with aux
Matrix4f.mul(matrix, aux, matrix);
return matrix;
}
I've found your problem:
view.m13 = 1f;
This means that your camera is in fourth W dimension, so your image moves in W direction too, when you translate your view matrix. So, remove this line.
Also, this is a tip for better understanding matrices in LWJGL:
m00 | m10 | m20 | m30 |||_||| Xx | Yx | Zx | Wx
m01 | m11 | m21 | m31 |||_||| Xy | Yy | Zy | Wy
m02 | m12 | m22 | m32 |||_||| Xz | Yz | Zz | Wz
m03 | m13 | m23 | m33 |||_||| Xw | Yw | Zw | Ww
m03, m13, m23 almost always must be 0, and m33 = 1.
Regards.
Related
The question change a bit, I figured out how to rotate around a single axis
I want to rotate a box around the Y axis using an angle.
The box has a size, and a Vector3f to signal the rotation.
To rotate the box correctly what I do is rotate the origin position then rotate the origin position plus the size, and use those two references to render the box.
However this rotation does not work correctly and causes rendering artifacts.
This is my code to rotate the positions:
Matrix4f matrix = new Matrix4f();
// Rotate the origin position
Vector3f pos = new Vector3f(new Vector3f(blockX, blockY, blockZ));
matrix.m03 = pos.x;
matrix.m13 = pos.y;
matrix.m23 = pos.z;
Vector3f rot = new Vector3f(new Vector3f(0, 1f, 0f));
Matrix4f.rotate((float) Math.toRadians(45f), rot, matrix, matrix);
Vector3f locationMin = new Vector3f(matrix.m03, matrix.m13, matrix.m23);
// Rotate the position with the size
// Top left back is the position of the block
Vector3f sizeRot = new Vector3f(new Vector3f(blockX + size, blockY + size, blockZ + size));
matrix = new Matrix4f();
matrix.m03 = sizeRot.x;
matrix.m13 = sizeRot.y;
matrix.m23 = sizeRot.z;
rot = new Vector3f(new Vector3f(0, 1f, 0f));
Matrix4f.rotate((float) Math.toRadians(45f), rot, matrix, matrix);
Vector3f locationMax = new Vector3f(matrix.m03, matrix.m13, matrix.m23);
// Then here I use the locationMax and the locationMin to render the cube
What could be wrong with this code? Is the logic I am using to rotate the box correct? as in rotate the origin position then rotate the origin position plus the size..
EDIT: I released that rotating after translating is stupid so instead I just rotated the locationMax which is not translated (it is only the size) then I translated and I still get the same result (Graphical Artifacts).
New Code:
float rx = blockX, ry = blockY, rz = blockZ;
Matrix4f matrix = new Matrix4f();
Vector3f rot = new Vector3f(0, 1f, 0f);
matrix = new Matrix4f();
matrix.m03 = size;
matrix.m13 = size;
matrix.m23 = size;
Matrix4f.rotate((float) Math.toRadians(45f), rot, matrix, matrix);
matrix.translate(new Vector3f(rx, ry, rz), matrix);
float mx = matrix.m03;
float my = matrix.m13;
float mz = matrix.m23;
// Here is use rx, ry, rz and mx, my, mz to render the box
============ * I figured it out (See below)* =============
EDIT:
This is what I ended up doing:
// Origin point
Vector4f a = new Vector4f(blockX, blockY, blockZ, 1);
// Rotate a matrix 45 degrees
Matrix4f mat = new Matrix4f();
mat.rotate((float) Math.toRandians(45f), new Vector3f(
0, 1f, 0), mat);
/* Transform the matrix to each point */
Vector4f c = new Vector4f(size.x, 0, size.z, 1);
Matrix4f.transform(mat, c, c);
Vector4f.add(c, a, c);
Vector4f b = new Vector4f(size.x, 0, 0, 1);
Matrix4f.transform(mat, b, b);
Vector4f.add(b, a, b);
Vector4f d = new Vector4f(0, 0, size.z, 1);
Matrix4f.transform(mat, d, d);
Vector4f.add(d, a, d);
// Here is use a, b, c, and d to render the box.
The problem with this is that I want to rotate around all axises and not only around the Y axis. This makes the code very long and unreadable and There are a lot of bugs when I try to rotate around all axises.
Update Question:
How do I take the above code and make it so I can rotate around all 3 axises. I want to do this so I can have a billboard that will always face the camera.
This is how I calculate the angle between the camera and the object:
Vector3f angle = new Vector3f();
// Calculate the distance between camera and object
Vector3f.sub(game.getCamera().getLocation(),
new Vector3f(blockX, blockY, blockZ), angle);
// Calculate the angle around the Y axis.
float vectorAngle = (float) ((float) Math.atan2(angle.z, angle.x) * -1 + (Math.PI / 2.0f));
Billboards are a very common application of computer graphics (as I'm sure you've noticed, since you're asking the question!)
Ultimately I think you are over complicating the problem, based on:
as in rotate the origin position then rotate the origin position plus the size..
For computer graphics, the most common transformations are Scaling, Translating, and Rotating, and you do these in an order to achieve a desired effect (traditionally you scale, then rotate about the origin, then translate the vertex's position).
Additionally, you will have three main matrices to render a model in 3d: World Matrix, View Matrix, and Projection Matrix. I believe you are having misunderstandings of transforming from Model Space to World Space.
Graphics TRS and Matrix info. If you are having conceptual problems, or this answer is insufficient, I highly recommend looking at this link. I have yet to find a better resource explaining the fundamentals of computer graphics.
So right at the moment, you have your three angles (in degrees, in a Vector3) corresponding to the angle difference in the X,Y, and Z coordinate spaces from your billboard and your camera. With this information, we generate the View matrix by first gathering all of our matrix transformations in one place.
I'm going to assume that you already have your Translation and Scaling matrices, and that they both work. This means that we only need to generate our Rotation matrix, and then transform that matrix with the scaling matrix, and then transforming that matrix by our translation matrix.
X Rotation Matrix
Y Rotation Matrix
Z Rotation Matrix
(Images taken from CodingLabs link above)
So you will generate these three matrices, using the X,Y, and Z angles you calculated earlier, and then transform them to consolidate them into a single matrix, transform that matrix by the scaling matrix, and then transform that matrix by the translation matrix. Now you have your awesome matrix that, when you multiply a a vertex by it, will transform that vertex into the desired size, rotation, and position.
So you transform every single vertex point by this generated matrix.
And then after that, you should be done! Using these techniques will hopefully simplify your code greatly, and set you on the right path :)
So now how about some code?
//I do not guarantee that this code compiles! I did not write it in an IDE nor did I compile it
float angleToRotX = 180f;
float angleToRotY = 90f;
float angleToRotZ = 0f;
// example vertex
Vector4f vertex = new Vector4f(0, 1, 0, 1);
// Rotate vertex's X coordinates by the desired degrees
Matrix4f rotationXMatrix = new Matrix4f();
rotationXMatrix.rotX(angleToRotX);
Matrix4f rotationYMatrix = new Matrix4f();
rotationYMatrix.rotY(angleToRotY);
Matrix4f rotationZMatrix = new Matrix4f();
rotationZMatrix.rotZ(angleToRotZ);
//now let's translate it by 1.5, 1, 1.5 in the X,Y,Z directions
Matrix4f translationMatrix = new Matrix4f();
translationMatrix.setTranslate(new Vector3f(1.5, 1, 1.5));
/*
Now we have our three rotational matrices. So we multiply them (transform them) to get a single matrix to transform all of the points in this model to the desired world coordinates
*/
Matrix4f rotationMatrix = new Matrix4f();
rotationMatrix.mul(rotationXMatrix);
rotationMatrix.mul(rotationYMatrix);
rotationMatrix.mul(rotationZMatrix);
Matrix4f worldMatrix = translationMatrix;
worldMatrix.mul(rotationMatrix);
//now worldMatrix, when applied to a vertex, will rotate it by X,Y,Z degrees about the origin of it's model space, and then translate it by the amount given in translationMatrix
worldMatrix.transform(vertex);
//now vertex should be (1.5, 0, 1.5, 1) with (x,y,z,1)
Now this code could really be simplified, and it is excessively verbose. Try it out! I don't have java downloaded on my machine, but I grabbed the methods from the java documentation Here
Here is an image of what is happening (again, taking from coding labs):
(Advanced Info: Quaternions. These are really cool way of orienting a model in 3d space, however I don't quite understand them to the degree I need to in order to explain it to someone else, and I also believe that your problem is more fundamental)
You could generate the matrix without much hassle. The OpenGL matrix looks like the following:
|lx,ux,vx,px| - lx,ly,lz = the left vector
|ly,uy,vy,py| - ux,uy,uz = the up vector
|lz,uz,vz,pz| - vx,vy,vz = the view vector
|0 ,0 ,0 ,1 | - px,py,pz = the translation
All you need to do, is set px,py,pz to the position of your box in the world,
your view vector to the normalized(camera position - box position), your up comes straight from your camera, and the left is calculated via normalized cross product. It's also good practice to reconstruct the up vector, after left one is derived (by another cross product). That's all there's to it.
My solution aims to save you some time coding, rather than explain everything in detail. Hope that is useful to someone.
I have got some trees, which are greatly lagging the game, so I would like to check if the trees are in front of the camera or not.
I have had some help from the Mathematics forum, and also had a look at This link to help me convert pitch/yaw to the directional vector needed.
But for some reason, whenever I move the camera to the left, the trees become visible, wheras whenever I move it to the right, they become unvisible (So if camera is pointing at +1 on the Z axis, it seems to be rendering the trees, but -1 on the Z axis and it seems to not render them).
(See http://i.gyazo.com/cdd05dc3f5dbdc07577c6e41fab3a549 for a less-jumpy .mp4)
I am using the following code to check if an object is in front of the camera or not:
Ship you = shipsID.get(UID);
int dis = 300;
Vector3f X = new Vector3f(camera.x(), camera.y(), camera.z());
float x = (float) (Math.cos(Math.toRadians(camera.yaw()))*Math.cos(Math.toRadians(camera.pitch())));
float y = (float) (Math.sin(Math.toRadians(camera.yaw()))*Math.cos(Math.toRadians(camera.pitch())));
float z = (float) Math.sin(Math.toRadians(camera.pitch()));
Vector3f V = new Vector3f(x, y, z);
for (Tree tree : trees){
Vector3f Y = new Vector3f(tree.location.x, tree.location.y, tree.location.z);
Vector3f YMinusX = Y.negate(X);//new Vector3f(Y.x - X.x, Y.y - X.y, Y.z - X.z);
float dot = Vector3f.dot(YMinusX, V);
if (dot > 0){
tree.render();
}
}
Is anyone able to tell me what I have done wrong here? I can't work out if it's the math.. Or the code.. Or what?
Camera translation code:
public void applyTranslations() {
glPushAttrib(GL_TRANSFORM_BIT);
glMatrixMode(GL_MODELVIEW);
glRotatef(pitch, 1, 0, 0);
glRotatef(yaw, 0, 1, 0);
lastYaw = yaw;
glRotatef(roll, 0, 0, 1);
glTranslatef(-x, -y, -z);
glPopAttrib();
}
UPDATE:
It appears to be where the camera is looking. For example, if I look to -Z, nothing happens, but if I look to +Z, they all render.
The if (dot > 0) code appears to somehow being +Z rather than +TheCameraRotation.
Your camera rotations yaw around Y, implying Y is your up vector. However, float z = (float) Math.sin(Math.toRadians(camera.pitch())); gives Z for your up vector. There is an inconsistency. I'd start by swapping y and z here, then print everything out every frame so you can see what happens as you rotate the camera. Also render just one tree and print dot. E.g. you might quickly notice the numbers approach 1.0 only when you look at 90 degrees left of the tree which narrows down the problem. As #DWilches notes, swapping cos/sin will change the phase of the rotation, which would produce such an effect.
You might consider limiting the dot product to the camera's field of view. There are still problems in that trees are not just points. A better way would be to test tree bounding boxes against the camera frustum, as #glampert suggests.
Still, the tree geometry doesn't look that complex. Optimization wise, I'd start trying to draw them faster. Are you using VBOs? Perhaps look at methods to reduce draw calls such as instancing. Perhaps even use a few models for LOD or billboards. Going even further, billboards with multiple trees on them. Occlusion culling methods could be used to ignore trees behind mountains.
[EDIT]
Since your trees are all roughly on a plane, you could limit the problem to the camera's yaw:
float angleToTree = Math.atan2(tree.location.z - camera.z(), tree.location.x - camera.x());
float angleDiff = angleToTree - camera.yaw();
if (angleDiff > Math.PI)
angleDiff -= 2.0f * Math.PI;
if (angleDiff < -Math.PI)
angleDiff += 2.0f * Math.PI;
if (abs(angleDiff) < cameraFOV + 0.1f) //bias as trees are not points
tree.render();
Could you write it like this
Ship you = shipsID.get(UID);
int dis = 300;
Vector3f X = new Vector3f(camera.x(), camera.y(), camera.z());
float x = (float) (Math.cos(Math.toRadians(camera.yaw()))*Math.cos(Math.toRadians(camera.pitch())));
float y = (float) (Math.sin(Math.toRadians(camera.yaw()))*Math.cos(Math.toRadians(camera.pitch())));
float z = (float) Math.sin(Math.toRadians(camera.pitch()));
Vector3f V = new Vector3f(x, y, z);
for (Tree tree : trees){
Vector3f Y = new Vector3f(tree.location.x, tree.location.y, tree.location.z);
Vector3f YMinusX = Y.negate(X);//new Vector3f(Y.x - X.x, Y.y - X.y, Y.z - X.z);
float dot = Vector3f.dot(YMinusX, V);
if (dot > 0){
tree.render();
}
}
As you can see there is far less calculation being performed for each tree.
For what I see here the correct formulas are:
x = Math.sin(pitch) * Math.cos(yaw);
y = Math.sin(pitch) * Math.sin(yaw);
z = Math.cos(pitch);
Could you try them ?
Below is a picture of what my outcome is.
I am using flat shading and have put each vertex in their respectable triangle objects. Then I use these vertices to calculate the surface normals. I have been reading that because my triangles share similar vertices that calculating the normals may be an issue? But to me this looks like a windings problem given that every other one is off.
I provided some of my code below to anyone who wants to look through it and get a better idea what the issue could be.
Triangle currentTri = new Triangle();
int triPointIndex = 0;
List<Triangle> triList = new ArrayList<Triangle>()
GL11.glBegin(GL11.GL_TRIANGLE_STRIP);
int counter1 = 0;
float stripZ = 1.0f;
float randY;
for (float x=0.0f; x<20.0f; x+=2.0f) {
if (stripZ == 1.0f) {
stripZ = -1.0f;
} else { stripZ = 1.0f; }
randY = (Float) randYList.get(counter1);
counter1 += 1;
GL11.glVertex3f(x, randY, stripZ);
Vert currentVert = currentTri.triVerts[triPointIndex];
currentVert.x = x;
currentVert.y = randY;
currentVert.z = stripZ;
triPointIndex++;
System.out.println(triList);
Vector3f normal = new Vector3f();
float Ux = currentTri.triVerts[1].x - currentTri.triVerts[0].x;
float Uy = currentTri.triVerts[1].y - currentTri.triVerts[0].y;
float Uz = currentTri.triVerts[1].z - currentTri.triVerts[0].z;
float Vx = currentTri.triVerts[2].x - currentTri.triVerts[0].x;
float Vy = currentTri.triVerts[2].y - currentTri.triVerts[0].y;
float Vz = currentTri.triVerts[2].z - currentTri.triVerts[0].z;
normal.x = (Uy * Vz) - (Uz * Vy);
normal.y = (Uz * Vx) - (Ux * Vz);
normal.z = (Ux * Vy) - (Uy * Vx);
GL11.glNormal3f(normal.x, normal.y, normal.z);
if (triPointIndex == 3) {
triList.add(currentTri);
Triangle nextTri = new Triangle();
nextTri.triVerts[0] = currentTri.triVerts[1];
nextTri.triVerts[1] = currentTri.triVerts[2];
currentTri = nextTri;
triPointIndex = 2;
}
}
GL11.glEnd();
You should be setting the normal before calling glVertex3f (...). A call to glVertex* is basically what finalizes a vertex, it associates the current color, normal, texture coordinates, etc... with the vertex at the position you pass and emits a new vertex.
glVertex — specify a vertex
Description
glVertex commands are used within glBegin / glEnd pairs to specify point, line, and polygon vertices. The current color, normal, texture coordinates, and fog coordinate are associated with the vertex when glVertex is called.
When only x and y are specified, z defaults to 0.0 and w defaults to 1.0. When x, y, and z are specified, w defaults to 1.0.
Chances are very good that this is a large part of your problem. Triangle strips are designed to workaround implicit winding issues. You have to reverse the winding of every triangle when you use a strip, but the rasterizer compensates for this by flipping the winding order used for front/back internally on each alternate triangle.
Update:
Understand of course that the rasterizer is smart enough to flip the front/back winding for each alternate triangle when using a strip but your code is not (at least not currently). You need to compensate for the alternately reversed winding when you calculate the normals yourself on the CPU side.
Actually it's both in one. The direction of the normal depends on the winding used to calculate it. However ultimately it boils down to a normals problem, since that's what determines lighting calculations.
Winding is also important for OpenGL, but you can't change anything about that in a striped primitive.
I'm currently having an issue with directional light shadow maps from a moving (sun-like) light source.
When I initially implemented, the light projection matrix was computed as 3D, and the shadow map appears beautifully. I then learned that for what I'm trying to do, an orthographic projection would work better, but I'm having a hard time substituting the proper projection matrix.
Each tick, the sun moves a certain amount along a circle, as one would expect. I use a homegrown "lookAt" method to determine the proper viewing matrix. So, for instance, daylight occurs from 6AM to 6PM. When the sun is at the 9AM position (45 degrees) it should look at the origin and render the shadow map to the framebuffer. What appears to be happening with the orthographic projection is that it doesn't "tilt down" toward the origin. It simply keeps looking straight down the Z axis instead. Things look fine at 6AM and 6PM, but 12 noon, for instance, show absolutely nothing.
Here's how I'm setting things up:
Original 3D projection matrix:
Matrix4f projectionMatrix = new Matrix4f();
float aspectRatio = (float) width / (float) height;
float y_scale = (float) (1 / cos(toRadians(fov / 2f)));
float x_scale = y_scale / aspectRatio;
float frustum_length = far_z - near_z;
projectionMatrix.m00 = x_scale;
projectionMatrix.m11 = y_scale;
projectionMatrix.m22 = (far_z + near_z) / (near_z - far_z);
projectionMatrix.m23 = -1;
projectionMatrix.m32 = -((2 * near_z * far_z) / frustum_length);
LookAt method:
public Matrix4f lookAt( float x, float y, float z,
float center_x, float center_y, float center_z ) {
Vector3f forward = new Vector3f( center_x - x, center_y - y, center_z - z );
Vector3f up = new Vector3f( 0, 1, 0 );
if ( center_x == x && center_z == z && center_y != y ) {
up.y = 0;
up.z = 1;
}
Vector3f side = new Vector3f();
forward.normalise();
Vector3f.cross(forward, up, side );
side.normalise();
Vector3f.cross(side, forward, up);
up.normalise();
Matrix4f multMatrix = new Matrix4f();
multMatrix.m00 = side.x;
multMatrix.m10 = side.y;
multMatrix.m20 = side.z;
multMatrix.m01 = up.x;
multMatrix.m11 = up.y;
multMatrix.m21 = up.z;
multMatrix.m02 = -forward.x;
multMatrix.m12 = -forward.y;
multMatrix.m22 = -forward.z;
Matrix4f translation = new Matrix4f();
translation.m30 = -x;
translation.m31 = -y;
translation.m32 = -z;
Matrix4f result = new Matrix4f();
Matrix4f.mul( multMatrix, translation, result );
return result;
}
Orthographic projection (using width 100, height 75, near 1.0, far 100 ) I've tried this with many many different values:
Matrix4f projectionMatrix = new Matrix4f();
float r = width * 1.0f;
float l = -width;
float t = height * 1.0f;
float b = -height;
projectionMatrix.m00 = 2.0f / ( r - l );
projectionMatrix.m11 = 2.0f / ( t - b );
projectionMatrix.m22 = 2.0f / (far_z - near_z);
projectionMatrix.m30 = - ( r + l ) / ( r - l );
projectionMatrix.m31 = - ( t + b ) / ( t - b );
projectionMatrix.m32 = -(far_z + near_z) / (far_z - near_z);
projectionMatrix.m33 = 1;
Shadow map vertex shader:
#version 150 core
uniform mat4 projectionMatrix;
uniform mat4 viewMatrix;
uniform mat4 modelMatrix;
in vec4 in_Position;
out float pass_Position;
void main(void) {
gl_Position = projectionMatrix * viewMatrix * modelMatrix * in_Position;
pass_Position = gl_Position.z;
}
Shadow map fragment shader:
#version 150 core
in vec4 pass_Color;
in float pass_Position;
layout(location=0) out float fragmentdepth;
out vec4 out_Color;
void main(void) {
fragmentdepth = gl_FragCoord.z;
}
I feel that I'm missing something very simple here. As I said, this works fine with a 3D projection matrix, but I want the shadows constant as the user travels across the world, which makes sense for directional lighting, and thus orthographic projection.
Actually, who told you that using an orthographic projection matrix would be a good idea for shadow maps? This might work for things like the sun, which are effectively infinitely far away, but for local lights perspective is very relevant. You have to be careful with perspective projection and shadow maps though, because the sample frequency varies with distance and you wind up getting a lot of precision at some distances and not enough at others unless you use things like cascading or perspective warping in general; this is probably more than you should be thinking about at the moment though :)
Also, orthographic projection matrices are no more or no less 3D than perspective, insofar as they work by projecting a 3D "image" onto a 2D viewing plane... the only difference between them and perspective is that parallel lines remain parallel. Put another way, (x,y,near) and (x,y,far) ideally project to the same position on screen in an orthographic projection.
Your use of gl_FragCoord.z in the fragment shader is unusual. Since this is the value that is written to the depth buffer, you might as well write NOTHING in your fragment shader and re-use the depth buffer. Unless your implementation does not support a floating-point depth buffer you are wasting memory bandwidth by writing the depth to two places. A depth-only pass with glColorMask (GL_FALSE, GL_FALSE, GL_FALSE, GL_FALSE) will usually get you much higher throughput when constructing shadow maps.
If you actually used the value of pass_Position (which is your non-perspective corrected Z coordinate in clip-space), I could see using a separate color attachment to write this, but you're writing the perspective-correct depth-range adjusted depth (gl_FragDepth) currently.
In any case, when the sun is directly overhead and you are using orthographic projection it is to be expected that no shadows are cast. This goes back to the property I explained earlier where parallel lines remain parallel. Since the distance an object is from the sun has no affect on where the object is projected (orthographically), if it is directly overhead you will not see any shadows. Try tracking the sun's position along a sphere instead of a circle to minimize this.
Hey all I'm trying to implement 3D picking into my program, and it works perfectly if I don't move from the origin. It is perfectly accurate. But if I move the model matrix away from the origin (the viewmatrix eye is still at 0,0,0) the picking vectors are still drawn from the original location. It should still be drawing from the view matrix eye (0,0,0) but it isn't. Here's some of my code to see if you can find out why..
Vector3d near = unProject(x, y, 0, mMVPMatrix, this.width, this.height);
Vector3d far = unProject(x, y, 1, mMVPMatrix, this.width, this.height);
Vector3d pickingRay = far.subtract(near);
//pickingRay.z *= -1;
Vector3d normal = new Vector3d(0,0,1);
if (normal.dot(pickingRay) != 0 && pickingRay.z < 0)
{
float t = (-5f-normal.dot(mCamera.eye))/(normal.dot(pickingRay));
pickingRay = mCamera.eye.add(pickingRay.scale(t));
addObject(pickingRay.x, pickingRay.y, pickingRay.z+.5f, Shape.BOX);
//a line for the picking vector for debugging
PrimProperties a = new PrimProperties(); //new prim properties for size and center
Prim result = null;
result = new Line(a, mCamera.eye, far);//new line object for seeing look at vector
result.createVertices();
objects.add(result);
}
public static Vector3d unProject(
float winx, float winy, float winz,
float[] resultantMatrix,
float width, float height)
{
winy = height-winy;
float[] m = new float[16],
in = new float[4],
out = new float[4];
Matrix.invertM(m, 0, resultantMatrix, 0);
in[0] = (winx / width) * 2 - 1;
in[1] = (winy / height) * 2 - 1;
in[2] = 2 * winz - 1;
in[3] = 1;
Matrix.multiplyMV(out, 0, m, 0, in, 0);
if (out[3]==0)
return null;
out[3] = 1/out[3];
return new Vector3d(out[0] * out[3], out[1] * out[3], out[2] * out[3]);
}
Matrix.translateM(mModelMatrix, 0, this.diffX, this.diffY, 0); //i use this to move the model matrix based on pinch zooming stuff.
Any help would be greatly appreciated! Thanks.
I wonder which algorithm you have implemented. Is it a ray casting approach to the problem?
I didn't focus much on the code itself but this looks a way too simple implementation to be a fully operational ray casting solution.
In my humble experience, i would like to suggest you, depending on the complexity of your final project (which I don't know), to adopt a color picking solution.
This solution is usually the most flexible and the easiest to be implemented.
It consist in the rendering of the objects in your scene with unique flat colors (usually you disable lighting as well in your shaders) to a backbuffer...a texture, then you acquire the coordinates of the click (touch) and you read the color of the pixel in that specific coordinates.
Having the color of the pixel and the tables of the colors of the different objects you rendered, makes possible for you to understand what the user clicked from a logical perspective.
There are other approaches to the object picking problem, this is probably universally recognized as the fastest one.
Cheers
Maurizio