 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Darren New <dne### [at] sanrrcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 13 Feb 2010 18:42:35 +0100, Darren New <dne### [at] sanrrcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 13 Feb 2010 20:01:51 +0100, Warp <war### [at] tagpovrayorg> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
> On Sat, 13 Feb 2010 20:01:51 +0100, Warp <war### [at] tagpovrayorg> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> clipka <ano### [at] anonymousorg> wrote:
>> Isn't such a transformation non-affine? So it wouldn't be possible to do
>> it with a simple 4x4 matrix multiplication.
The trick which allows this is to use "homogeneous coordinates".
Basically the 4th (or 3rd in you're in 2D) index in the coordinate
vector is treated differently and is used to divide the other
coordinates. For example, let's say that the camera matrix maps a point
(x,y,z,1) in 3D homogeneous coordinates to the point (u,v,w) in camera
viewing coordinates. The actual position on the "screen" given by this
is then (u/w, v/w), where we've divided by the last coordinate. It's
this division which allows non-affine transformations to be represented.
Wikipedia has a nice article on homogeneous coordinates if you're
interested in more:
http://en.wikipedia.org/wiki/Homogeneous_coordinates
http://en.wikipedia.org/wiki/Camera_matrix
> Multiplication with a 4x4 matrix can be used for perspective projection.
> It's a 3x3 transformation matrix which is restricted to affine transformations.
3x4 is restricted to affine transformations. A 3x3 matrix is restricted
to linear transformations (assuming Cartesian instead of homogeneous
coordinates).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 13 Feb 2010 21:05:06 +0100, Warp <war### [at] tagpovrayorg> wrote:
> 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.
The clipping itself becomes slightly more complicated in that it must be
performed in homogenous coordinates.
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fredrik Eriksson <fe79}--at--{yahoo}--dot--{com> wrote:
> On Sat, 13 Feb 2010 21:05:06 +0100, Warp <war### [at] tagpovrayorg> wrote:
> > 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.
> The clipping itself becomes slightly more complicated in that it must be
> performed in homogenous coordinates.
Ah, yes, homogenous coordinates. It starts ringing bells now. That's the
thing I was not remembering in all this. (Man, it has been a long time since
I knew all these things.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> point coordinates will overflow, screwing up the projected coordinates, which
I hadn't thought of that. Thanks for clearing it up.
> Note that I don't have first-hand experience on this.
Well, looking at the structure, I'm pretty sure it's not in the matrix, but
again I wanted to make sure it wasn't something clever, as you said.
--
Darren New, San Diego CA, USA (PST)
Forget "focus follows mouse." When do
I get "focus follows gaze"?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fredrik Eriksson 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.
I see. So there's extra information, but it might be implicit. Interesting
approach.
Now I'm curious enough to screw around with the matrixes and math again to
see if I can figure out what it's doing.
(I'll also mention in passing that the XNA compiler is the first compiler
I've run into that hoists constant expressions in loops not only out of the
loop but onto an entirely different CPU altogether. :-)
--
Darren New, San Diego CA, USA (PST)
Forget "focus follows mouse." When do
I get "focus follows gaze"?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:4b770ead@news.povray.org...
> clipka <ano### [at] anonymousorg> 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.)
That's not correct. 3x3 matrix multiplication only gives you linear
transformations (in 3D). You need a particularly designed 4x4 matrix for
affine transformations, which includes translation on top of linear
transformations of scaling, rotation and projective ("orthogonal")
transformations. Perspective projection is not strictly achieved with matrix
multiplication applied to standard coordinates, so you include a special
equivalency clause / homogenous coordinates (a division in disguise), and
with that in mind, you can use the remaining elements of the 4x4 matrix to
that end.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
somebody <x### [at] ycom> wrote:
> Perspective projection is not strictly achieved with matrix
> multiplication applied to standard coordinates, so you include a special
> equivalency clause / homogenous coordinates (a division in disguise), and
> with that in mind, you can use the remaining elements of the 4x4 matrix to
> that end.
Yeah, perspective projection with a 4x4 transformation matrix is only
possible if the points are in homogeneous coordinates.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fredrik Eriksson 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.
Just peeking at some of the HLSL values that get passed around and some of
the graphics card assembler instructions, it looks like this is quite
likely. For example, there's a "free" modifier you can use to shift a result
from [-1...1] to [0...1] on the graphics card without taking any more
instruction cycles. Textures seem to get 0...1 while visible X,Y coordinates
seem to go -1...1. I'm not sure which range the Z coordinates fall into,
but it certainly seems reasonable to believe that if the X and Y are scaled
in such a way, the Z likely will be also.
--
Darren New, San Diego CA, USA (PST)
Forget "focus follows mouse." When do
I get "focus follows gaze"?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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.
>
> I see. So there's extra information, but it might be implicit. Interesting
> approach.
Yes, the 3D hardware is usually programmed to clip when Z is outside a
certain range. It is then up to you (the programmer) to decide how you map
real world coordinates to this range, and yes you can do it with just a 4x4
matrix.
DirectX has a helper function to create such a matrix for you:
http://tinyurl.com/yg5z9t7
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
