for example,
lOrtho (-3.5, 3.5, -3.5*(GLfloat)h/(GLfloat)w,
3.5*(GLfloat)h/(GLfloat)w, -3.5, 3.5);
where the near argument is -3.5, why can it use such nagtive number?
and the others, like perspective can not?
The space of the final result of a projection transformation (after the division by W) is a cube, centered at the origin, which extends to -1, 1 in all 3 axes. This space, called Normalized Device Coordinate (NDC) space, represents the visible part of the world, no matter what particular projection transformation you use.
So the job of a projection transform is to transform positions from some space into NDC space (after the division by W).
glOrtho defines a transformation from an axis-aligned rectangular prism to the NDC space cube. The 6 coordinates define the sides of the axis-aligned prism. In such a space, a negative Z is no worse than a positive Z. The orthographic transformation defines everything in that prism to be visible, with everything outside of it not visible.
The perspective transformation is very different. The area of the world used by the perspective projection is a rectangular [i]frustum[/i]; essentially a pyramid with the top chopped off. Everything inside the frustum is considered visible, with everything outside of it not visible. Also, the tip of the frustum (where the top of the pyramid would be if the top wasn’t chopped off) is where the camera resides.
Part of the definition of a frustum includes two distances: camera zNear and camera zFar. These are expressed as distances from the camera rather than absolute coordinates. So zNear has a positive distance, even though in eye-space, negative Z values are in front of the camera, with positive Z values behind.
Ignoring the fact that a negative distance makes no sense, if zNear were allowed to be negative, you still wouldn’t have a reasonable transformation. If zNear were zero (which it isn’t allowed to be, but let’s pretend), then the frustum would be a perfect pyramid. The four sides would meet at the camera.
So if zNear were less than zero… what would be behind the camera?
The sides of the frustum are considered to be infinitely long planes. This includes the near and far planes, but also the four sides. And OpenGL’s clipping rules state that any part of any object which falls behind even one of these 6 planes doesn’t get rendered.
But all points behind the camera are behind at least one of the side clipping planes. So even if you could have a negative zNear, you wouldn’t have any extra visibility compared to a zNear of zero (which again, is also not allowed).
[QUOTE=Alfonse Reinheart;1267498]The space of the final result of a projection transformation (after the division by W) is a cube, centered at the origin, which extends to -1, 1 in all 3 axes. This space, called Normalized Device Coordinate (NDC) space, represents the visible part of the world, no matter what particular projection transformation you use.
So the job of a projection transform is to transform positions from some space into NDC space (after the division by W).
glOrtho defines a transformation from an axis-aligned rectangular prism to the NDC space cube. The 6 coordinates define the sides of the axis-aligned prism. In such a space, a negative Z is no worse than a positive Z. The orthographic transformation defines everything in that prism to be visible, with everything outside of it not visible.
The perspective transformation is very different. The area of the world used by the perspective projection is a rectangular [i]frustum[/i]; essentially a pyramid with the top chopped off. Everything inside the frustum is considered visible, with everything outside of it not visible. Also, the tip of the frustum (where the top of the pyramid would be if the top wasn’t chopped off) is where the camera resides.
Part of the definition of a frustum includes two distances: camera zNear and camera zFar. These are expressed as distances from the camera rather than absolute coordinates. So zNear has a positive distance, even though in eye-space, negative Z values are in front of the camera, with positive Z values behind.
Ignoring the fact that a negative distance makes no sense, if zNear were allowed to be negative, you still wouldn’t have a reasonable transformation. If zNear were zero (which it isn’t allowed to be, but let’s pretend), then the frustum would be a perfect pyramid. The four sides would meet at the camera.
So if zNear were less than zero… what would be behind the camera?
The sides of the frustum are considered to be infinitely long planes. This includes the near and far planes, but also the four sides. And OpenGL’s clipping rules state that any part of any object which falls behind even one of these 6 planes doesn’t get rendered.
But all points behind the camera are behind at least one of the side clipping planes. So even if you could have a negative zNear, you wouldn’t have any extra visibility compared to a zNear of zero (which again, is also not allowed).[/QUOTE]
Either glOrtho or glPerspective is belong to projection. the last can’t see the behind (as it were), but the front can see?
where is the projection plane? is it not at the camera place?
and what’s matter with this thread at
Draw two objects, but only one teapot display, why? - OpenGL: Basic Coding - Khronos Forums
odd enough.
The perspective projection transformation defines the “camera” as a specific position (the eye-space origin). However, orthographic projections don’t really have a camera at all. The closest thing to a camera you might say is a camera plane, but even that’s not really correct.
It’s just a fundamentally different kind of transformation.
[QUOTE=Alfonse Reinheart;1267501]The perspective projection transformation defines the “camera” as a specific position (the eye-space origin). However, orthographic projections don’t really have a camera at all.
It’s just a fundamentally different kind of transformation.[/QUOTE]
thanks, I think we can conside the camera is located at infinit far place. Thus there is no begin and end. then there could be a nagtive relatively.
The closest thing to a camera you might say is a camera plane, but even that’s not really correct.
WHAts that?
and btw, have a look at
https://www.opengl.org/discussion_bo...96#post1267496
odd enough. what’s matter with this thread ?