POV-Ray : Newsgroups : povray.advanced-users : Skewness (long) : Re: Skewness (long) Server Time
10 May 2024 22:40:21 EDT (-0400)
  Re: Skewness (long)  
From: clipka
Date: 5 Oct 2018 11:06:46
Message: <5bb77e06$1@news.povray.org>
Am 04.10.2018 um 22:30 schrieb Francois LE COAT:

> When the raytracing POV-Ray program projects a 3D movement in a 2D
> image sequence, it uses what is called "projective transformation" that
> produces the images.
[...]

You're convoluting a couple of things, so let me try to clarify:

(1) The matrix you've posted and described is for a 2D->2D projective
transformation; that would be of no use in a 3D animation, as you can't
just transform one output image into another, as depth is already lost
at that point. The only projective transformations of interest would be
3D->3D (to change the scene)...:

     (x')    1  (m00 m01 m02 m03) (x)
     (y') = --- (m10 m11 m12 m13) (y)
     (z')    w  (m20 m21 m22 m23) (z)
     (1 )       (m30 m31 m32 m33) (1)

... or 3D->2D (for the camera; not sure if the term "projective
transformation" would be correct there):

     (u)    1  (m00 m01 m02 m03) (x)
     (v) = --- (m10 m11 m12 m13) (y)
     (1)    w  (m20 m21 m22 m23) (z)
                                 (1)

(2) The "transform", "rotate", "scale" and "matrix" 3D->3D
transformations in POV-Ray are not /projective/ transformations, but
rather /affine/ transformations:

     (x)   (m00 m01 m02 m03) (x)
     (y) = (m10 m11 m12 m13) (y)
     (z)   (m20 m21 m22 m23) (z)
                             (1)

(Technically, "scale" and "rotate" are actually not affine but linear,
but the implementation uses affine matrices throughout.)

(3) The camera projection in POV-Ray does /not/ use a 3D->2D matrix
transformation as shown above, but rather transforms each individual ray
according to a potentially more complex formula, allowing POV-Ray to
support more camera projections than just a simple pinhole camera. Even
the pinhole camera model is implemented that way.

(4) At no point does POV-Ray perform transformations from one frame of
an animation to the next. Instead, each frame of an animation is created
"from scratch" according to the "recipe" provided by the user in the
form of the scene file script, varying the recipe depending on a "clock"
parameter. In the creation of each frame, affine 3D->3D transformations
are used to specify the orientation, size, position and shearing of the
components.


Now that we got that out of our way:

POV-Ray's primary transformations are far sufficient to exploit all
degrees of freedom: Besides `translate` and `rotate` there is also
`scale`, which can be combined with `rotate` to produce arbitrary
shearing transformations.

Note that in POV-Ray transformations are instructions, not parameters;
thus you can chain multiple instructions, such as apply a rotation, then
a scaling, then another rotation again.

Since it may a major PITA to create a shearing transformation with just
`translate`, `rotate`, `scale`, POV-Ray provides a fourth transformation
type, `matrix`, which gives you direct control over the transformation
matrix. (Again this is an instruction, and chains with the other
transformations.)

To make life even easier, the include file "transforms.inc" distributed
with POV-Ray provides a macro to specify a pure shearing transformation,
`Shear_Trans(X,Y,Z)`.


Theoretically it would be possible to implement a `shear` transformation
in the language itself, but there's no genuine need for it, thanks to
the macro; and unlike the other primary transformations - `translate`,
`rotate` and `scale` - there is no shape that would benefit from
implementing special handling for it. (For example, the sphere shape is
defined by its center and radius; `translate` can be implemented by
changing the center, `scale` (if uniform) can be implemented by changing
the radius, and `rotate` can be ignored entirely.)


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.