I understand that zNear, zFar mark the clipping bounds of a scene. But OpenTK restricts the values to be greater than zero. Does this mean all my objects should be drawn on positive Z axis so that its not clipped ?
No, this is only the render clipping, after viewing translations. So if you render an object based at for example {0,0,-100} with your camera at {0,0,-110} it will still render if within the clipping planes, but stuff further then -110+zFar and -110-zNear will be clipped. That a pretty simple explanation, but in effect how it works.
Don't confuse the different spaces that coordinates can be represented in or translated to. The check marked answer oversimplifies so much so that it's possibly not even a correct answer in many cases.
The zNear and zFar are distances away from the "camera" or the eye of the view in world units, but not in world coordinates. Therefore they do have to be positive numbers. They are also sort of in negative eye or camera space. Only if the camera is aligned with the z axis pointing towards -z space is the check marked answer correct, or your statement about what is being clipped.
They do help define the nearest and farthest clipping bounds, but they do not mark the clipping bounds of a scene. Again, this would depend on your camera's position. And your definition of "a scene".
It's often said that OpenGL has no camera. But I prefer not to think of it that way. There is a view and therefore there is a camera. Using a lookAt function you can place your view/camera anywhere in your scene and point it any direction you want. To me your scene is all the objects that you're rendering, not just the current view of those objects. And thinking of it that way your zNear and zFar don't limit your scene at all, they only limit the viewing depth of your camera. It's more like a tape measure sticking out from your eye. It's vector changes as your view of things change.
For example imagine a scene of a grid of blocks in rows and columns along the x and z axis but all at a y of 0. If your camera is aligned with the z axis then the zNear and zFar relate to the world z axis. You'd probably see rows of blocks going away from camera. But if the camera is floating above everything at a y of +100 and pointed down you'd see it more as a grid. And in that case the zNear and zFar have nothing to do with the z axis in your scene. They only have to do with the camera's clipping on objects in the camera's z axis - in camera space.
Related
I'd like to know whether a different model is drawn just before coordinate (xyz) where it's here.
It doesn't work by Z value comparison of depth value and the coordinate I did world change of.
It seems that Z value is normalized in near=0, far=1, but depth value seems to make the point of view drawn at the most inside in View frustum 1.
When I moved a far plane to a far place, Z value decreased, but depth value didn't change.
thank you.
I am not sure I understand your question correctly, but I will make a guess and provide an answer. Apologies in advance if this is not what you were asking. In OpenGL you need to understand what the view frustum is. In it, you have an x and y coordinate and a depth value. The depth value represents how far from your eye the object (pixel) drawn is. This is so that you can avoid having objects i the background obfuscate objects that are closer in, giving a more real representation of the reality. You also have clipping planes, a near and a far clipping planes. Anything closer than the nera clipping plane will not be drawn, and anything farther than the far clipping plane won't be drawn. If, for example, I am drawing an image of the earth from space. I know I won't have to bother with anything that is on the other side of the Earth and can just clip it away, speeding things up. Usually, the near clipping plane is set at z=0, and the far clipping plane at depth=1. Then, this interval is subdivided (depending on your depth buffer) and OpenGL, as said, will put each pixel in each slot and decide what is closer to your eye and what is not (on the same line drawn from the eye to the pixel x,y). If you are in 3D and have x,y,z, the z-value from the scene won't match the value of the depth value, you need to use the view-matrix to map things right.
Hopefully this helps some.
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 am confused with volume of view which generated from glOrtho method ,
I know that last two parameters are for Z axis ,
first one represent the distance between viewer and near plane and second one represent distance between viewer and far plane .
my question is where the viewer(camera) lies exactly in Z coordinate ?
and in this link program some code that make near plane positive and far plane negative , in this case can we say that Z- is behind the viewer and Z+ is in front of viewer ?
if yes , try to make Z coordinate negative for all vertex of one of triangles , you will note that it appear although it is behind the viewer , why ??
first one represent the distance between viewer and near plane and second one represent distance between viewer and far plane
No, it isn't. An orthographic projection defines a box. The zNear and zFar are the positions of the box, not the distance from the "viewer".
Orthographic projections don't have a "viewer" in the same way that perspective projections do. They have a direction of view, not a view position. And the direction of the view is always the direction that puts zFar the farthest away and zNear being closest. If zNear is larger than zFar, then the direction of view is in the positive Z; otherwise, it's the negative Z.
Actually your question is little bit confusing. I think you can try glLookAt() and make the object appear from a different angle and see the difference. here is a link
http://mycodelog.com/2010/05/28/glcamera/
I know it possible to use PerspectiveCamera's frustum member to judge if a point(x,y,z) is in the frustum by calling pointInFrustum(Vector3 point) function. Now if the z-coordinate is fixed to some value, can I get the boundary of x and y axis that is visible directly?
The Frustum contains the 8 points (planePoints) making up the near and far plane:
/** eight points making up the near and far clipping "rectangles". order is counter clockwise, starting at bottom left **/
public final Vector3[] planePoints
These points are updated when Camera.update is called. To be on the safe side, just call this once before doing the following operations:
Calculate a parameter t (in [0,1]) specifying how far the POI is away from the near plane wrt the far plane.
t allows to linearly interpolate the top surface of the frustum (unsure about how to call this) down the z axis.
And btw, frustum in libgdx's Camera class should really be called something like viewvolume, since orthographic projections don't span a frustum in space.
i have implemented first person camera in OpenGL, but when i get closer to an object it starts to disappear, so i want to set near plane close to zero so i could get closer to the objects. So if anybody can tell me what is the best way to do that.
Thank you.
Other responses focus on using glut. Glut is not recommended for professional, or even modern, development, and the OP says nothing about using glut - just OpenGL. So, I'll chime in:
A little background
zNear, the distance from the origin to the near clip plane, is one of the parameters used to build the projection matrix:
Projection Matrix
Where
SYMBOL MEANING TYPICAL VALUE
------ -------------- -------------
fov vertical field of view 45 – 90 degrees
aspect Aspect ratio around 1.8 (frame buffer Width / Height)
znear near clip plane +1
zfar far clip plane. 10
SYMBOL MEANING FORMULA
---------- ------------------------------- --------------
halfHeight half of frustum height at znear znear∗tan(fov/2)
halfWidth half of frustum width at znear halfHeight×aspect
depth depth of view frustum zfar−znear
(More nicely-formatted version on http://davidlively.com/programming/graphics/opengl-matrices/perspective-projection/)
When the perspective divide takes place - between the vertex and fragment shaders - the vertices are converted to normalized device coordinates (NDC), in "clip space." In this space, anything that fits in a 2x2x1 (x,y,z) box will be rendered. Any fragments that don't fit in a box with corners (-1, -1, 0) - (+1, +1, +1) will be clipped.
Practical Upshot Being
It doesn't matter what your zNear and zFar values are, as long as they offer sufficient resolution & precision, and zFar > zNear > 0.
Your collision detection & response system is responsible for keeping the camera from getting too close to the geometry. "Too close" is a function of your zNear and geometry bounds. Even if you have a zNear of 1E-9, geometry will get clipped when it gets too close to the clip space origin.
So: fix your collision detection and stop worrying about your zNear.
So if anybody can tell me
gluPerspective.
The near plane is set when you set the projection matrix, either with glFrustum or glOrtho. One of the parameters is the near plane. Notice that the distance to the near plane must be > 0.
You don't have many options.
Cast some rays from the camera (for instance in the 4 corners and in the center), take the shortest minus epsilon, clamped to a decent value > 0. 0.1f will do.
Simply forbid the camera to be here in the first place ! For this you can link it to a sphere in your physics engine, check whether it intersects something, and it it does, move it (how and where to move it is your problem since it's for a large part gameplay. Think of Super Mario Galaxy)
Never set a too little nearPlane. You will run in precision issues with your z-buffer. The farPlane can be quite large though. Values like (0.1, 1000) can be all right depending on your application