I'm having some issues with my camera, where the near plane seems to be too far even when I have it set to 0.1 or lower. It seems like there is already some offset value. So you can't really get close enough an arbitrary object in the scene.
Below is a visual appearance of the bug.
The black triangle shown is the clipping.
Currently I'm using a perspective matrix and here is the code for that.
Matrix4x4 Matrix4x4::Perspective(Float fov, Float aspectRatio, Float near, Float far)
{
Matrix4x4 result(1.0f);
Float q = 1.0f / tan(toRadians(0.5f * fov));
Float a = q / aspectRatio;
Float b = (near + far) / (near - far);
Float c = (2.0f * near * far) / (near - far);
result.elements[0 + 0 * 4] = a;
result.elements[1 + 1 * 4] = q;
result.elements[2 + 2 * 4] = b;
result.elements[2 + 3 * 4] = -1.0f;
result.elements[3 + 2 * 4] = c;
return result;
}
I don't feel that the bug is from the maths class. This is because the maths code are mainly from another project that I've been working on. And works perfectly fine from there.
I also don't suspect that its the way that I render it (forward renderer). I believe my pointers for that are good since I am able to move and rotate the camera via mouse and keyboard.
But! What I suspect is the buffers. The OpenGL buffers. But I'm not entirely sure.
I hope someone gives me some advice as to how I can hunt and tackle this bug down.
Thank you in advance.
Well one image is worth more then 1000 words so:
As I mentioned in my comments if your cube is half size r=1.0 and you set up your camera in distance r from cube center you still get cut by z_near as the cube edges are distant from center in range <sqrt(2),sqrt(3)> so all edges turned towards camera will get cut off ...
But also as mentioned this is just guess because you did not provide any test data relevant for this (matrices and mesh content)...
PS on the right side is the cube side view of your camera settings I am guessing you have set. The green (+/-)Z is your viewing direction.
"glEnable(GL_DEPTH_CLAMP)" Solved The Issue
Related
I'm trying to wrap my head around calculating motion vectors (also called velocity buffer). I found this tutorial, but I'm not satisfied with explanations of how motion vector are calculated. Here is the code:
vec2 a = (vPosition.xy / vPosition.w) * 0.5 + 0.5;
vec2 b = (vPrevPosition.xy / vPrevPosition.w) * 0.5 + 0.5;
oVelocity = a - b;
Why are we multiplying our position vectors by 0.5 and then adding 0.5? I'm guessing that we're trying to get from clip space to NDC, but why? I completly don't understand that.
This is a mapping from the [-1, 1] clip space onto the [0, 1] texture space. Since lookups in the blur shader have to read from a textured at a position offset by the velocity vector, it's necessary to perform this conversion.
Note, that the + 0.5 part is actually unnecessary, since it cancels out in a-b anyway. So the same result would have been achieved by using something like
vec2 a = (vPosition.xy / vPosition.w);
vec2 b = (vPrevPosition.xy / vPrevPosition.w);
oVelocity = (a - b) * 0.5;
I don't know if there is any reason to prefer the first over the second, but my guess is that this code is written in the way it is because it builds up on a previous tutorial where the calculation had been the same.
I've been trying for some time now to get a screen-space pixel (provided by a deferred HLSL shader) to convert to light space. The results have been surprising to me as my light rendering seems to be tiling the depth buffer.
Importantly, the scene camera (or eye) and the light being rendered from start in the same position.
First, I extract the world position of the pixel using the code below:
float3 eye = Eye;
float4 position = {
IN.texCoord.x * 2 - 1,
(1 - IN.texCoord.y) * 2 - 1,
zbuffer.r,
1
};
float4 hposition = mul(position, EyeViewProjectionInverse);
position = float4(hposition.xyz / hposition.w, hposition.w);
float3 eyeDirection = normalize(eye - position.xyz);
The result seems to be correct as rendering the XYZ position as RGB respectively yields this (apparently correct) result:
The red component seems to be correctly outputting X as it moves to the right, and blue shows Z moving forward. The Y factor also looks correct as the ground is slightly below the Y axis.
Next (and to be sure I'm not going crazy), I decided to output the original depth buffer. Normally I keep the depth buffer in a Texture2D called DepthMap passed to the shader as input. In this case, however, I try to undo the pixel transformation by offsetting it back into the proper position and multiplying it by the eye's view-projection matrix:
float4 cpos = mul(position, EyeViewProjection);
cpos.xyz = cpos.xyz / cpos.w;
cpos.x = cpos.x * 0.5f + 0.5f;
cpos.y = 1 - (cpos.y * 0.5f + 0.5f);
float camera_depth = pow(DepthMap.Sample(Sampler, cpos.xy).r, 100); // Power 100 just to visualize the map since scales are really tiny
return float4(camera_depth, camera_depth, camera_depth, 1);
This yields a correct looking result as well (though I'm not 100% sure about the Z value). Also note that I've made the results exponential to better visualize the depth information (this is not done when attempting live comparisons):
So theoretically, I can use the same code to convert that pixel world position to light space by multiplying by the light's view-projection matrix. Correct? Here's what I tried:
float4 lpos = mul(position, ShadowLightViewProjection[0]);
lpos.xyz = lpos.xyz / lpos.w;
lpos.x = lpos.x * 0.5f + 0.5f;
lpos.y = 1 - (lpos.y * 0.5f + 0.5f);
float shadow_map_depth = pow(ShadowLightMap[0].Sample(Sampler, lpos.xy).r, 100); // Power 100 just to visualize the map since scales are really tiny
return float4(shadow_map_depth, shadow_map_depth, shadow_map_depth, 1);
And here's the result:
And another to show better how it's mapping to the world:
I don't understand what is going on here. It seems it might have something to do with the projection matrix, but I'm not that good with math to know for sure what is happening. It's definitely not the width/height of the light map as I've tried multiple map sizes and the projection matrix is calculated using FOV and aspect ratios never inputing width/height ever.
Finally, here's some C++ code showing how my perspective matrix (used for both eye and light) is calculated:
const auto ys = std::tan((T)1.57079632679f - (fov / (T)2.0));
const auto xs = ys / aspect;
const auto& zf = view_far;
const auto& zn = view_near;
const auto zfn = zf - zn;
row1(xs, 0, 0, 0);
row2(0, ys, 0, 0);
row3(0, 0, zf / zfn, 1);
row4(0, 0, -zn * zf / zfn, 0);
return *this;
I'm completely at a loss here. Any guidance or recommendations would be greatly appreciated!
EDIT - I also forgot to mention that the tiled image is upside down as if the y flip broke it. That's strange to me as it's required to get it back to eye texture space correctly.
I did some tweaking and fixed things here and there. Ultimately, my biggest issue was an unexpectedly transposed matrix. It's a bit complicated as to how the matrix got transposed, but that's why things were flipped. I also changed to D32 depth buffers (though I'm not sure that helped any) and made sure that any positions divided by their W affected all component (including W).
So code like this: hposition.xyz = hposition.xyz / hposition.w
became this: hposition = hposition / hposition.w
After all this tweaking, it's starting to look more like a shadow map.
Oh and the transposed matrix was the ViewProjection of the light.
Suppose I would like to draw the following lines:
const GLfloat lineX[] = {
FrustumData.left * FrustumData.ratio , (FrustumData.top + FrustumData.bottom) / 2 * FrustumData.ratio, FrustumData.zFar, //point A
FrustumData.right * FrustumData.ratio , (FrustumData.top + FrustumData.bottom) / 2 * FrustumData.ratio, FrustumData.zFar //point B
};
const GLfloat lineY[] = {
(FrustumData.left + FrustumData.right) / 2 * FrustumData.ratio , FrustumData.bottom * FrustumData.ratio, FrustumData.zFar, //point A
(FrustumData.left + FrustumData.right) / 2 * FrustumData.ratio , FrustumData.top * FrustumData.ratio, FrustumData.zFar //point B
};
const GLfloat lineZ[] = {
(FrustumData.left + FrustumData.right) / 2 * FrustumData.ratio, (FrustumData.top + FrustumData.bottom) / 2 * FrustumData.ratio, FrustumData.zFar, //point A
(FrustumData.left + FrustumData.right) / 2 , (FrustumData.top + FrustumData.bottom) / 2 , FrustumData.zNear //point B
};
where ratio = zFar/zNear and everything else is glFrustum parameters.
Shouldn't I see the lines for any selection of Frustum parameters or it depends somehow on glViewport?
because I don't see them right now and I can't understand why.
Thank you.
There's no direct connection between the two. But they both have a direct influence on where things will appear on the screen.
Essentially glFrustum is a function to create a projection transformation of a certain kind, namely one, that creates perspective. I recommend reading another answer written by me, which explains the transformation stages of OpenGL.
In that answer I wrote:
This transformation maps some volume in eye space to a specific volume with certain boundaries, to which the geometry is clipped.
glFrustum is defining such a volume. It looks like a pyramid with its tip cut of (a frustum), where the tip would be at the eye space origin, the "cut" was the near clip plane and the pyramid's base the far clip plane. The parameters left, right, bottom and top define the extents of the near clipping plane in eye space units.
I need to get an up vector for a camera (to get the right look) from a roll, pitch, and yaw angles (in degrees). I've been trying different things for a couple hours and have had no luck :(. Any help here would be appreciated!
Roll, Pitch and Yaw define a rotation in 3 axis. from these angles you can construct a 3x3 transformation matrix which express this rotation (see here how)
After you have this matrix you take your regular up vector, say (0,1,0) if 'up' is the Y axis and multiply it with the matrix. What you'll get is the transformed up vector.
Edit-
Applying the transformation to (0,1,0) is the same thing as taking the middle row. The 3 rows of the matrix make up an orthogonal base of the rotated system. Mind you that a 3D graphic API uses 4x4 matrices. So to make a 4x4 matrix out of the 3x3 rotation matrix you need to add a '1' at M[3][3] (the corner) and zeros at the rest like so:
r r r 0
r r r 0
r r r 0
0 0 0 1
This may not directly answer your question, although it may still help. I have a free open-source project for XNA that creates a debug terminal that overlays your game while it is running. You can use this for looking up values, invoking methods, or whatever. So if you have a transformation matrix and you wanted to extract various parts of it while the game is running, you can do that. The project can be found here:
http://www.protohacks.net/xna_debug_terminal
I don't have much expertise in the kind of math you are using, but hopefully Shoosh's post helps on that. Maybe the debug terminal can help you when trying out his idea or in any other future problems you encounter.
12 years later...
In case anyone is still interested in the answer to this question, here is the solution (even tough its in Java it should be pretty easy to translate it in other languages):
private Vector3f getRayFromCamera() {
float rx = (float)Math.sin((double)getYaw() * (double)(Math.PI / 180)) * -1 * (1-Math.abs((float)Math.cos((double)getPitch() * (double)(Math.PI / 180) - 90 * (Math.PI / 180)) * -1));
float ry = (float)Math.cos((double)getPitch() * (double)(Math.PI / 180) - 90 * (Math.PI / 180)) * -1;
float rz = (float)Math.cos((double)getYaw() * (double)(Math.PI / 180)) * -1 * (1- Math.abs((float)Math.cos((double)getPitch() * (double)(Math.PI / 180) - 90 * (Math.PI / 180)) * -1));
return new Vector3f(rx, ry, rz);
}
Note: This calculates the Front Vector but when multiplying with the vector (0,1,0) you can change that!
I've been struggling with this for a good while now. I'm trying to determine the screen coordinates of the vertexes in a model on the screen of my NDS using devKitPro. The library seems to implement some functionality of OpenGL, but in particular, the gluProject function is missing, which would (I assume) allow me to do just exactly that, easily.
I've been trying for a good while now to calculate the screen coordinates manually using the projection matricies that are stored in the DS's registers, but I haven't been having much luck, even when trying to build the projection matrix from scratch based on OpenGL's documentation. Here is the code I'm trying to use:
void get2DPoint(v16 x, v16 y, v16 z, float &result_x, float &result_y)
{
//Wait for the graphics engine to be ready
/*while (*(int*)(0x04000600) & BIT(27))
continue;*/
//Read in the matrix that we're currently transforming with
double currentMatrix[4][4]; int i;
for (i = 0; i < 16; i++)
currentMatrix[0][i] =
(double(((int*)0x04000640)[i]))/(double(1<<12));
//Now this hurts-- take that matrix, and multiply it by the projection matrix, so we obtain
//proper screen coordinates.
double f = 1.0 / tan(70.0/2.0);
double aspect = 256.0/192.0;
double zNear = 0.1;
double zFar = 40.0;
double projectionMatrix[4][4] =
{
{ (f/aspect), 0.0, 0.0, 0.0 },
{ 0.0, f, 0.0, 0.0 },
{ 0.0, 0.0, ((zFar + zNear) / (zNear - zFar)), ((2*zFar*zNear)/(zNear - zFar)) },
{ 0.0, 0.0, -1.0, 0.0 },
};
double finalMatrix[4][4];
//Ugh...
int mx = 0; int my = 0;
for (my = 0; my < 4; my++)
for (mx = 0; mx < 4; mx++)
finalMatrix[mx][my] =
currentMatrix[my][0] * projectionMatrix[0][mx] +
currentMatrix[my][1] * projectionMatrix[1][mx] +
currentMatrix[my][2] * projectionMatrix[2][mx] +
currentMatrix[my][3] * projectionMatrix[3][mx] ;
double dx = ((double)x) / (double(1<<12));
double dy = ((double)y) / (double(1<<12));
double dz = ((double)z) / (double(1<<12));
result_x = dx*finalMatrix[0][0] + dy*finalMatrix[0][1] + dz*finalMatrix[0][2] + finalMatrix[0][3];
result_y = dx*finalMatrix[1][0] + dy*finalMatrix[1][1] + dz*finalMatrix[1][2] + finalMatrix[1][3];
result_x = ((result_x*1.0) + 4.0)*32.0;
result_y = ((result_y*1.0) + 4.0)*32.0;
printf("Result: %f, %f\n", result_x, result_y);
}
There are lots of shifts involved, the DS works internally using fixed point notation and I need to convert that to doubles to work with. What I'm getting seems to be somewhat correct-- the pixels are translated perfectly if I'm using a flat quad that's facing the screen, but the rotation is wonky. Also, since I'm going by the projection matrix (which accounts for the screen width/height?) the last steps I'm needing to use don't seem right at all. Shouldn't the projection matrix be accomplishing the step up to screen resolution for me?
I'm rather new to all of this, I've got a fair grasp on matrix math, but I'm not as skilled as I would like to be in 3D graphics. Does anyone here know a way, given the 3D, non-transformed coordinates of a model's vertexes, and also given the matricies which will be applied to it, to actually come up with the screen coordinates, without using OpenGL's gluProject function? Can you see something blatantly obvious that I'm missing in my code? (I'll clarify when possible, I know it's rough, this is a prototype I'm working on, cleanliness isn't a high priority)
Thanks a bunch!
PS: As I understand it, currentMatrix, which I pull from the DS's registers, should be giving me the combined projection, translation, and rotation matrix, as it should be the exact matrix that's going to be used for the translation by the DS's own hardware, at least according to the specs at GBATEK. In practise, it doesn't seem to actually have the projection coordinates applied to it, which I suppose has something to do with my issues. But I'm not sure, as calculating the projection myself isn't generating different results.
That is almost correct.
The correct steps are:
Multiply Modelview with Projection matrix (as you've already did).
Extend your 3D vertex to a homogeneous coordinate by adding a W-component with value 1. E.g your (x,y,z)-vector becomes (x,y,z,w) with w = 1.
Multiply this vector with the matrix product. Your matrix should be 4x4 and your vector of size 4. The result will be a vector of size4 as well (don't drop w yet!). The result of this multiplication is your vector in clip-space. FYI: You can already do a couple of very useful things here with this vector: Test if the point is on the screen. The six conditions are:
x < -w : Point is outside the screen (left of the viewport)
x > W : Point is outside the screen (right of the viewport)
y < -w : Point is outside the screen (above the viewport)
y > w : Point is outside the screen (below the viewport)
z < -w : Point is outside the screen (beyond znear)
z > w : Point is outside the screen (beyond zfar)
Project your point into 2D space. To do this divide x and y by w:
x' = x / w;
y' = y / w;
If you're interested in the depth-value (e.g. what gets written to the zbuffer) you can project z as well:
z' = z / w
Note that the previous step won't work if w is zero. This case happends if your point is equal to the camera position. The best you could do in this case is to set x' and y' to zero. (will move the point into the center of the screen in the next step..).
Final Step: Get the OpenGL viewport coordinates and apply it:
x_screen = viewport_left + (x' + 1) * viewport_width * 0.5;
y_screen = viewport_top + (y' + 1) * viewport_height * 0.5;
Important: The y coordinate of your screen may be upside down. Contrary to most other graphic APIs in OpenGL y=0 denotes the bottom of the screen.
That's all.
I'll add some more thoughts to Nils' thorough answer.
don't use doubles. I'm not familiar with NDS, but I doubt it's got any hardware for double math.
I also doubt model view and projection are not already multiplied if you are reading the hardware registers. I have yet to see a hardware platform that does not use the full MVP in the registers directly.
the matrix storage into registers may or may not be in the same order as OpenGL. if they are not, the multiplication matrix-vector needs to be done in the other order.