![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
As far as I can figure, there's no way to represent near and far clipping
planes in a transformation matrix, right? The camera itself (in some sense)
has to carry them along separately? I.e., the near and far clipping planes
don't get represented anywhere in a normal 4x4 transformation matrix?
--
Darren New, San Diego CA, USA (PST)
Forget "focus follows mouse." When do
I get "focus follows gaze"?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> As far as I can figure, there's no way to represent near and far clipping
> planes in a transformation matrix, right? The camera itself (in some sense)
> has to carry them along separately? I.e., the near and far clipping planes
> don't get represented anywhere in a normal 4x4 transformation matrix?
If you think about it, how could it ever work?
The idea of a transformation matrix is that it can be used to transform
a point from one coordinate system to another via a simple matrix
multiplication (where the point is represented by a 1xn matrix and the
transformation matrix is an nxn one). When we are talking about 3D points,
a 3x3 transformation matrix can be used to perform any affine transformations,
while a 4x4 one can additionally be used for things like translations and
perspective projection.
The point is that a *point* is transformed from one coordinate system to
another.
Now, how would you apply a "clipping plane" to a point? Literally
speaking a clipping plane would make a point disappear if the point is
on the wrong side of the plane. How do you make a point disappear via
a matrix multiplication? Multiplying a point by a matrix always results
in another point. Multiplication doesn't make a point disappear. (It
doesn't even make much sense in that context.)
(Of course in practice you seldom clip individual points. In practice
what get clipped are lines and polygons, which is a whole different
issue which can certainly not be solved via a single matrix multiplication.)
If what you are asking is whether a 4x4 matrix could carry clipping
plane coorinates inside itself without affecting the transformation
otherwise, I'd say that's not possible. I don't think it could carry
that much information.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> wrote:
>> As far as I can figure, there's no way to represent near and far clipping
>> planes in a transformation matrix, right? The camera itself (in some sense)
>> has to carry them along separately? I.e., the near and far clipping planes
>> don't get represented anywhere in a normal 4x4 transformation matrix?
>
> If you think about it, how could it ever work?
Hence the "as far as I can figure." But such math is not one of my strong
points.
The graphics library I'm exploring has a "Matrix" class, but since it's
compiled, I can't see the implementation. The same "Matrix" class is used to
represent the camera's position. I figured the extra fields must actually be
stored separately, but the high-level-ness of the library made it look like
maybe I was wrong. (For example, the graphics card calls a matrix a
"float4x4" implying there are just 16 floats in the structure.)
> Now, how would you apply a "clipping plane" to a point?
I thought perhaps it would map to 0 or infinity or something, but I was
pretty sure I was right.
> Multiplication doesn't make a point disappear. (It
> doesn't even make much sense in that context.)
Thanks for the confirmation.
> (Of course in practice you seldom clip individual points. In practice
> what get clipped are lines and polygons, which is a whole different
> issue which can certainly not be solved via a single matrix multiplication.)
I think on the *graphics* card, the individual points might get clipped if
the triangle goes from inside the frustum to outside.
> If what you are asking is whether a 4x4 matrix could carry clipping
> plane coorinates inside itself without affecting the transformation
> otherwise, I'd say that's not possible. I don't think it could carry
> that much information.
That was my suspicion too, but I wanted to confirm I was right.
I even tried making two matrix-class instances, one with a clipping plane
and one without, and got back the same entries for the 4x4 part of the matrix.
Thanks for confirming my understanding!
--
Darren New, San Diego CA, USA (PST)
Forget "focus follows mouse." When do
I get "focus follows gaze"?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> > (Of course in practice you seldom clip individual points. In practice
> > what get clipped are lines and polygons, which is a whole different
> > issue which can certainly not be solved via a single matrix multiplication.)
> I think on the *graphics* card, the individual points might get clipped if
> the triangle goes from inside the frustum to outside.
It's not that simple. In order to get the individual points (ie. the points
on the polygon which correspond to the pixels on screen, once the polygon
has been projected to the view plane) the polygon has to be projected first,
after which the individual points can be interpolated.
The near-clipping plane is used to avoid the problem that happens when
a vertex point of the polygon is behind the camera or extremely close to it
(even if the vertex point is in front of the camera, if it's too close to
the camera plane it will be projected to such a large value that the floating
point coordinates will overflow, screwing up the projected coordinates, which
is why the near-clipping plane has to be at some sensible distance from the
projection point).
Thus the near-clipping has to be done *before* the vertex points are
projected. It cannot be done after. This means that if you are clipping
a triangle, you will end up slicing the triangle (usually resulting in a
quadrilateral which has then to be converted into two triangles).
Clipping a triangle with a plane is not a completely trivial operation.
(Far-clipping is done for an entirely different reason, ie. to cut down
the number of polygons being rendered, and could conceivably be done after
the projection to the individual interpolated points. However, since you
already have a triangle-clipping algorithm set up for the near-clipping
plane, you could as well use it for the far-clipping plane as well, which
is probably what most engines/cards do. They might also do it for the
side planes of the view frustum as well, to cut down the amount of points
that need to be interpolated.)
> > If what you are asking is whether a 4x4 matrix could carry clipping
> > plane coorinates inside itself without affecting the transformation
> > otherwise, I'd say that's not possible. I don't think it could carry
> > that much information.
> That was my suspicion too, but I wanted to confirm I was right.
Note that I don't have first-hand experience on this. It wouldn't be the
first time that people have come up with clever tricks to squeeze information
in such places. (For example, there was a time that I didn't know that you
could actually perform perspective projection with a simple multiplication
with a 4x4 matrix, as I had always thought that matrix multiplication could
only be used for affine transformations.)
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Sat, 13 Feb 2010 18:42:35 +0100, Darren New <dne### [at] san rr com> wrote:
> As far as I can figure, there's no way to represent near and far
> clipping planes in a transformation matrix, right? The camera itself (in
> some sense) has to carry them along separately? I.e., the near and far
> clipping planes don't get represented anywhere in a normal 4x4
> transformation matrix?
Typically, the perspective transform is defined such that the resulting
z-coordinates fall in a suitable range (e.g. [0,1]). Clipping can then be
performed without knowledge about the original clipping planes.
--
FE
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
> Typically, the perspective transform is defined such that the resulting
> z-coordinates fall in a suitable range (e.g. [0,1]). Clipping can then be
> performed without knowledge about the original clipping planes.
Ah, now that you mention that, yes, that's probably a very common
technique. Rather than carrying around the distances of the clipping
planes, what is done is to scale the scene so that the clipping planes
are at distances 0 (well, almost) and 1 from the camera. This scaling
is then undone by the perspective projection.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
On Sat, 13 Feb 2010 20:01:51 +0100, Warp <war### [at] tag povray org> wrote:
> Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
>> Typically, the perspective transform is defined such that the resulting
>> z-coordinates fall in a suitable range (e.g. [0,1]). Clipping can then
>> be performed without knowledge about the original clipping planes.
>
> Ah, now that you mention that, yes, that's probably a very common
> technique. Rather than carrying around the distances of the clipping
> planes, what is done is to scale the scene so that the clipping planes
> are at distances 0 (well, almost) and 1 from the camera. This scaling
> is then undone by the perspective projection.
No, the scaling is done *by* the perspective transform.
--
FE
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
> On Sat, 13 Feb 2010 20:01:51 +0100, Warp <war### [at] tag povray org> wrote:
> > Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
> >> Typically, the perspective transform is defined such that the resulting
> >> z-coordinates fall in a suitable range (e.g. [0,1]). Clipping can then
> >> be performed without knowledge about the original clipping planes.
> >
> > Ah, now that you mention that, yes, that's probably a very common
> > technique. Rather than carrying around the distances of the clipping
> > planes, what is done is to scale the scene so that the clipping planes
> > are at distances 0 (well, almost) and 1 from the camera. This scaling
> > is then undone by the perspective projection.
> No, the scaling is done *by* the perspective transform.
I don't remember now how the trick was applied, exactly. The idea was,
I think, to transform the scene so that the view frustum (which in the
original untransformed scene is a truncated square pyramid) becomes a
unit cube. Then all the polygons are clipped against this unit cube (which,
as you can guess, is a lot simpler than doing it against a free truncated
pyramid). Then a simple orthogonal projection onto the near-plane (basically
dropping the z coordinate) is enough to get the final perspective projection.
Hence the near and far clipping planes could indeed be "encoded" into the
transformation matrix by specifying the depth scaling (which, I suppose,
would prove my original assertion in this thread wrong).
However, I don't remember if something else was involved for this to
work properly.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp schrieb:
> I don't remember now how the trick was applied, exactly. The idea was,
> I think, to transform the scene so that the view frustum (which in the
> original untransformed scene is a truncated square pyramid) becomes a
> unit cube. Then all the polygons are clipped against this unit cube (which,
> as you can guess, is a lot simpler than doing it against a free truncated
> pyramid). Then a simple orthogonal projection onto the near-plane (basically
> dropping the z coordinate) is enough to get the final perspective projection.
> Hence the near and far clipping planes could indeed be "encoded" into the
> transformation matrix by specifying the depth scaling (which, I suppose,
> would prove my original assertion in this thread wrong).
Isn't such a transformation non-affine? So it wouldn't be possible to do
it with a simple 4x4 matrix multiplication.
=> more data than just the 4x4 matrix would be needed.
(Though of course part of the 4x4 matrix might be misused to store that
data, as the 4th row of an affine transformation matrix is 0;0;0;1
anyway, so that data can easily be reconstructed.)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
clipka <ano### [at] anonymous org> wrote:
> Isn't such a transformation non-affine? So it wouldn't be possible to do
> it with a simple 4x4 matrix multiplication.
Multiplication with a 4x4 matrix can be used for perspective projection.
It's a 3x3 transformation matrix which is restricted to affine transformations.
(Yes, I didn't know that either, many years ago.)
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |