I want to render a plane so that it looks as if it goes to infinity in all directions. I want the plane boundary in the distance to be the horizon.
Using a simple mesh does not work - the computer can't render infinitely many triangles. Even if this was possible, the camera frustum would cut out the distant polygons and create a gap between the plane boundary and the horizon.
A workaround is to compute the horizon mathematically: finding points on the plane, which also lie on the plane at infinity. Connecting these points and two corners of the viewport creates a trapezoid which represents the sought plane. However, this way the plane can not be lit properly, or applied a texture, or anything else which requires a fine triangulation...
You can draw an infinite plane using the standard rasterization pipeline. The homogeneous coordinates it uses can represent "ideal" points (otherwise known as vanishing points or points at infinity) just as happily as regular Euclidean points, and likewise it is perfectly practical to set up a projection matrix which places the far plane at infinity.
A simple way to do this would be to use one triangle per quadrant, as follows:
vertices [x,y,z,w], for drawing an (x,y) coordinate plane, at (z==0):
0: [ 0, 0, 0, 1 ]
1: [ 1, 0, 0, 0 ]
2: [ 0, 1, 0, 0 ]
3: [-1, 0, 0, 0 ]
4: [ 0,-1, 0, 0 ]
draw 4 triangles using indices:
(0,1,2); (0,2,3); (0,3,4); (0,4,1)
If you want a test pattern (like an infinite checkerboard), you will have to deal with the fact that stretching your triangles to infinity will distort any standard texture. However, you can write a pixel shader that determines the color based on the actual 3D point (i.e., use x and y from the worldspace (x,y,z) coordinates), ignoring the (distorted) texture coords altogether.
You could choose between two constant colors based on parity (for a checkerboard), or tile a texture by sampling it based on the fractional part of your chosen coordinates.
Note that OpenGL's clip space is [-1..1] for each of x, y, and z. You can compute the appropriate projection matrix by evaluating the limits as far clip distance f increases without bound:
clip coords: [x] = [ n/r ] * view coords [x]
[y] [ n/t ] [y]
[z] [ -1 -2n ] [z]
[w] [ -1 0 ] [w]
Where (as in the link): n is the near clip plane, r is half the frustum width at the near clip plane, and t is half the frustum height at the near clip plane.
I have not tested the above matrix, so it's worth what you paid for it. Also be aware that the depth value will lose its precision as you approach infinity...
Although, the precision at closer distances will be likely be fine -- e.g., at any given distance, the depth resolution in the (near:infinity) case should be about 10% less than the case where the (near:far) ratio is (1:10).
Your viewing frustum, which is a capped pyramid built from 4 clip planes on the sides and on the top/bottom, and on a near and a far plane is "infinite" (it is not infinite, but since you cannot see anything outside the frustum, it is as infinite as it can be).
Drawing the bottom side of your capped pyramid (a quad, or two triangles) therefore is a plane that is "infinite", going to the horizon. Or, for that matter, any quad with its corner points on the near and far planes.
Related
I was quite confused on how the projection matrix worked so I researched and I discovered a few other things but after researching a few days, I just wanted to confirm my understanding is correct. I might use a few wrong terms but my brain was exhausted after writing this. A few topics I just researched briefly like screen coordinates and window transform so I didn’t write much about it and my knowledge might be incorrect. Is everything I’ve written here correct or mostly correct? Correct me on anything if I’m wrong.
What does the projection matrix do?
So the perspective projection matrix defines a frustum that is a truncated pyramid. Anything outside of that frustum/frustum range will be clipped. I'll get more on that later. The perspective projection matrix also adds perspective. To make the vertices follow the rules of perspective, the perspective projection matrix manipulates the vertex's w component (the homogenous component) depending on how far the vertex is from the viewer (the farther the vertex is, the higher the w coordinate will increase).
Why and how does the w component make the world look perceptive?
The w component makes the world look perceptive because in the perspective division (perspective division happens in the vertex post processing stage), when the x, y and z is divided by the w component, the vertex coordinate will be scaled smaller depending on how big the w component is. So essentially, the w component scales the object smaller the farther the object is.
Example:
Vertex position (1, 1, 2, 2).
Here, the vertex is 2 away from the viewer. In perspective division the x, y, and z will be divided by 2 because 2 is the w component.
(1/2, 1/2, 2/2) = (0.5, 0.5, 1).
As shown here, the vertex coordinate has been scaled by half.
How does the projection matrix decide what will be clipped?
The near and far plane are the limits of where the viewer can see (anything beyond the far plane and before the near plane will be clipped). Any coordinate will also have to go through a clipping check to see if it has to be clipped. The clipping check is checking whether the vertex coordinate is within a frustum range of -w to w. If it is outside of that range, it will be clipped.
Let's say I have a vertex with a position of (2, 130, 90, 90).
x value is 2
y value is 130
z value is 90
w value is 90
This vertex must be within the range of -90 to 90. The x and z value is within the range but the y value goes beyond the range thus the vertex will be clipped.
So after the vertex shader is finished, the next step is vertex post processing. In vertex post processing the clipping happens and also perspective division happens where clip space is converted into NDC (normalized device coordinates). Also, viewport transform happens where NDC is converted to window space.
What does perspective division do?
Perspective division essentially divides the x, y, and z component of a vertex with the w component. Doing this actually does two things, converts the clip space to Normalized device coordinates and also add perspective by scaling the vertices.
What is Normalized Device Coordinates?
Normalized Device Coordinates is the coordinate system where all coordinates are condensed into an NDC box where each axis is in the range of -1 to +1.
After NDC is occurred, viewport transform happens where all the NDC coordinates are converted screen coordinates. NDC space will become window space.
If an NDC coordinate is (0.5, 0.5, 0.3), it will be mapped onto the window based on what the programmer provided in the function glViewport. If the viewport is 400x300, the NDC coordinate will be placed at pixel 200 on x axis and 150 on y axis.
The perspective projection matrix does not decide what is clipped. After transforming a world coordinate with the projection, you get a clipspace coordinate. This is a Homogeneous coordinates. Base on this coordinate the Rendering Pipeline clips the scene. The clipping rule is -w < x, y, z < w. In the following process of the rendering pipeline, the clip space coordinates is transformed into the normalized device space by the perspective divide (x, y, z)' = (x/w, y/w, z/w). This division by the w component gives the perspective effect. (See also What exactly are eye space coordinates? and Transform the modelMatrix)
According to a number sources NDC differs from clip space in that NDC is just clip space AFTER division by the W component. Primitives are clipped in clip space, which in OpenGL is -1 to 1 along X, Y, and Z axes (Edit: this is wrong, see answer). In other words, clip space is a cube. Clipping is done within this cube. If it falls inside, it's visible, if it falls outside, it's not visible.
So let's take this simple example, we're looking from the top down on a viewing frustum, down the negative Y axis. The HALFFOV is 45 degrees, which means the NEAR and the RIGHT are both the same (in this case length 2). The example point is (6, 0, -7).
Now, here is the perspective projection matrix:
For simplicity we'll use an aspect ratio of 1:1. So:
RIGHT = 2
LEFT = -2
TOP = 2
BOTTOM = -2
NEAR = 2
FAR = 8
So filling in our values we get a projection matrix of:
Now we add the homogenous W to our point, which was (6, 0, -7), and get get (6, 0, -7, 1).
Now we multiply our matrix with our point, which results in (6, 0, 6.29, 7).
This point now (the point after being multiplied by the projection matrix, is supposed to lie in "clip space". Supposedly the clipping is done at this stage, figuring out whether a point lies inside or outside the clipping cube, and supposedly BEFORE division with W. Here is how it looks in "clip space":
From the sources I've seen the clipping is done at this stage, as it looks as above, BEFORE dividing by W. If you divide by W NOW, the point ends up in the right area of the clip space cube. This is why I don't understand why everyone says that perspective division is done AFTER the clipping space. In this space, prior to perspective division the point lies completely outside and would be judged to be outside the clipping space, and not visible. However after the perspective division, division by W, here is how it looks:
Now the point lies within the clip space cube, and can be judged to be inside, and visible. This is why I think perspective division is done BEFORE clipping, because if clipping space is in -1 to +1 in each axis, and the clipping stage checks against these dimensions, for a point to be inside this cube it must have already undergone division by W, otherwise almost ANY point lies outside the clipping space cube and is never visible.
So why does everyone say that first comes clipping space which is a result of the projection matrix, and ONLY then there is perspective division (division by W) which results in NDC?
In clip space, clipping is not done against a unit cube. It is done against a cube with side-length w. Points are inside the visible area if each of their x,y,z coordinate is smaller than their w coordinate.
In the example you have, the point [6, 0, 6.29, 7] is visible because all three coordinates (x,y,z) are smaller than 7.
Note, that for points inside the visible area, this is exactly equivalent to testing x/w < 1. The problems start with points in-front of the far-plane since they might get projected to the visible area by the homogeneous divide because their w-value is negative. As we all know, dividing by a negative number in an inequality would switch the operator, which is impracticable on hardware.
Further readings:
OpenGL sutherland-hodgman polygon clipping algorithm in homogeneous coordinates
Why clipping should be done in CCS, not NDCS
Why does GL divide gl_Position by W for you rather than letting you do it yourself?
I am confused about the position of objects in opengl .The eye position is 0,0,0 , the projection plane is at z = -1 . At this point , will the objects be in between the eye position and and the plane (Z =(0 to -1)) ? or its behind the projection plane ? and also if there is any particular reason for being so?
First of all, there is no eye in modern OpenGL. There is also no camera. There is no projection plane. You define these concepts by yourself; the graphics library does not give them to you. It is your job to transform your object from your coordinate system into clip space in your vertex shader.
I think you are thinking about projection wrong. Projection doesn't move the objects in the same sense that a translation or rotation matrix might. If you take a look at the link above, you can see that in order to render a perspective projection, you calculate the x and y components of the projected coordinate with R = V(ez/pz), where ez is the depth of the projection plane, pz is the depth of the object, V is the coordinate vector, and R is the projection. Almost always you will use ez=1, which makes that equation into R = V/pz, allowing you to place pz in the w coordinate allowing OpenGL to do the "perspective divide" for you. Assuming you have your eye and plane in the correct places, projecting a coordinate is almost as simple as dividing by its z coordinate. Your objects can be anywhere in 3D space (even behind the eye), and you can project them onto your plane so long as you don't divide by zero or invalidate your z coordinate that you use for depth testing.
There is no "projection plane" at z=-1. I don't know where you got this from. The classic GL perspective matrix assumes an eye space where the camera is located at origin and looking into -z direction.
However, there is the near plane at z<0 and eveything in front of the near plane is going to be clipped. You cannot put the near plane at z=0, because then, you would end up with a division by zero when trying to project points on that plane. So there is one reasin that the viewing volume isn't a pyramid with they eye point at the top but a pyramid frustum.
This is btw. also true for real-world eyes or cameras. The projection center lies behind the lense, so no object can get infinitely close to the optical center in either case.
The other reason why you want a big near clipping distance is the precision of the depth buffer. The whole depth range between the front and the near plane has to be mapped to some depth value with a limited amount of bits, typically 24. So you want to keep the far plane as close as possible, and shift away the near plane as far as possible. The non-linear mapping of the screen-space z coordinate makes this even more important, as that the precision is non-uniformely distributed over that range.
I need a simple and fast way to find out how big a 3D bounding box appears on screen (for LOD calculation) by using OpenGL Modelview and Projection matrices and the OpenGL Viewport dimensions.
My first intention is to project all 8 box corners on screen by using gluProject() and calculate the area of the convex hull afterwards. This solution works only with bounding boxes that are fully within the view frustum.
But how can a get the covered area on screen for boxes that are not fully within the viewing volume? Imaging a box where 7 corners are behind the near plane and only one corner is in front of the near plane and thus within the view frustum.
I have found another very similar question Screen Projection and Culling united but it does not cover my problem.
what about using queries and get samples that passes rendering?
http://www.opengl.org/wiki/Query_Object and see GL_SAMPLES_PASSED,
that way you could measure how many fragments are rendered and compare it for proper LOD selection.
Why not just manually multiply the world-view-projection with the vertex positions? This will give you the vertices in "normalized device coordinates" where -1 is the bottom left of the screen and +1 is the top-right of the screen?
The only thing is if the projection is perspective, you have to divide your vertices by their 4th component, ie if the final vertex is (x,y,z,w) you would divide by w.
Take for example a position vector
v = {x, 0, -z, 1}
Given a vertical viewing angle view 'a' and an aspect ration 'r', the position of x' in normalized device coordinates (range 0 - 1) is this (this formula taken directly out of a graphics programming book):
x' = x * cot(a/2) / ( r * z )
So a perspective projection for given parameters these will be as follows (shown in row major format):
cot(a/2) / r 0 0 0
0 cot(a/2) 0 0
0 0 z1 -1
0 0 z2 0
When you multiply your vector by the projection matrix (assuming the world, view matrices are identity in this example) you get the following (i'm only computing the new "x" and "w" values cause only they matter in this example).
v' = { x * cot(a/2) / r, newY, newZ, z }
So finally when we divide the new vector by its fourth component we get
v' = { x * cot(a/2) / (r*z), newY/z, newZ/z, 1 }
So v'.x is now the screen space coordinate v.x. This is exactly what the graphics pipeline does to figure out where your vertex is on screen.
I've used this basic method before to figure out the size of geometry on screen. The nice part about it is that the math works regardless of whether or not the projection is perspective or orthographic, as long you divide by the 4th component of the vector (for orthographic projections, the 4th component will be 1).
How can i render a textured plane at some z-pos to be visible towards infinity?
I could achieve this by drawing really huge plane, but if i move my camera off the ground to higher altitude, then i would start to see the plane edges, which i want to avoid being seen.
If this is even possible, i would prefer non-shader method.
Edit: i tried with the 4d coordinate system as suggested, but: it works horribly bad. my textures will get distorted even at camera position 100, so i would have to draw multiple textured quads anyways. perhaps i could do that, and draw the farthest quads with the 4d coordinate system? any better ideas?
Edit2: for those who dont have a clue what opengl texture distortion is, here's example from the tests i did with 4d vertex coords:
(in case image not visible: http://img828.imageshack.us/img828/469/texturedistort.jpg )
note that it only happens when camera gets far enough, in this case its only 100.0 units away from middle! (middle = (0,0) where my 4 triangles starts to go towards infinity). usually this happens around at 100000.0 or something. but with 4d vertices it seems to happen earlier for some reason.
You cannot render an object of infinite size.
You are more than likely confusing the concept of projection with rendering objects of infinite size. A 4D homogeneous coordinate who's W is 0 represents a 3D position that is at infinity relative to the projection. But that doesn't mean a point infinitely far from the camera; it means a point infinitely close to the camera. That is, it represents a point who's Z coordinate (before multiplication with the perspective projection matrix) was equal to the camera position (in camera space, this is 0).
See under perspective projection, a point that is in the same plane as the camera is infinitely far away on the X and Y axes. That is the nature of the perspective projection. 4D homogeneous coordinates allow you to give them all finite numbers, and therefore you can do useful mathematics to them (like clipping).
4D homogeneous coordinates do not allow you to represent an infinitely large surface.
Drawing an infinitely large plane is easy - all you need is to compute the horizon line in screen coordinates. To do so, you have to simply take two non-collinear 4D directions (say, [1, 0, 0, 0] and [0, 0, 1, 0]), then compute their position on the screen (by multiplying manually with the view-matrix and the projection matrix, and then clipping into viewport coordinates. When you have these two points, you can compute a 2D line through the screen and clip it against it. There, you have your infinity plane (the lower polygon). However, it is difficult to display a texture on this plane, because it would be infinitely large. But if your texture is simple (e.g. a grid), then you can compute it yourself with 4D coordinates, using the same schema like above - computing points and their corresponding vanishing point and connecting them.