





 
 




 
 


Presently, objects can be transformed according to a displacement vector plus a 3x3
matrix. This is a linear transformation. However, it would be useful if one could
also do nonlinear transformations. For example, x > x * y, or x > x * (1 + 0.1 *
sin(y)). I can easily see how this would become hopelessly complex, but it would be
useful.
Post a reply to this message


 
 




 
 


Dan Connelly <djc### [at] yahoocom> wrote:
> Presently, objects can be transformed according to a displacement
> vector plus a 3x3 matrix. This is a linear transformation. However,
> it would be useful if one could also do nonlinear transformations.
> For example, x > x * y, or x > x * (1 + 0.1 * sin(y)). I can easily
> see how this would become hopelessly complex, but it would be useful.
Actually objects are not transformed at all. That would be impossible
in the generic case.
What POVRay does is a common raytracing trick: Rather than transform
the object with the transformation matrix, it transforms the ray with
the inverse of the transformation matrix. The end result is exactly the
same, but the advantage is that it's much easier (and in many cases,
*possible*) to do it like this.
This is the reason why transformations must be linear. The straight ray
must be straight also after it's transformed. It cannot become curved.
This is the reason why only rotation, scaling, skewing (which is actually
a combination of rotation and uneven scaling) and translation is possible.
Raytracing with curved lines cannot be done accurately, and would be
extremely slow.

 Warp
Post a reply to this message


 
 




 
 


Warp wrote:
> Dan Connelly <djc### [at] yahoocom> wrote:
>> Presently, objects can be transformed according to a displacement
>> vector plus a 3x3 matrix. This is a linear transformation. However,
>> it would be useful if one could also do nonlinear transformations.
>> For example, x > x * y, or x > x * (1 + 0.1 * sin(y)). I can easily
>> see how this would become hopelessly complex, but it would be useful.
>
> Actually objects are not transformed at all. That would be impossible
> in the generic case.
>
> What POVRay does is a common raytracing trick: Rather than transform
> the object with the transformation matrix, it transforms the ray with
> the inverse of the transformation matrix. The end result is exactly the
> same, but the advantage is that it's much easier (and in many cases,
> *possible*) to do it like this.
>
> This is the reason why transformations must be linear. The straight ray
> must be straight also after it's transformed. It cannot become curved.
> This is the reason why only rotation, scaling, skewing (which is actually
> a combination of rotation and uneven scaling) and translation is possible.
>
> Raytracing with curved lines cannot be done accurately, and would be
> extremely slow.
>
Excellent answer  thanks.
I'm a bit confused about the skew argument. There's
matrix:
3 degrees of freedom: transformation
3 degrees of freedom: scaling
3 degrees of freedom: rotation
So this leaves 3 more degrees of freedom..... which are skew.
(righthand coordinates)
 ax 0 0 
 0 ay 0  : scaling
 0 0 az 
 cz sz 0 
 0 0 1  (permute for x, y)
So between scaling and rotation, I'm constrained to
antisymmetric matrixes.
A typical shear matrix:
 uz vz 0 
 0 0 1  (permute for x, y)
So this gives me 9 parameters:
ax, ay, az, sx, sy, sz, vx, vy, vz
the same number of parameters needed to specify the full matrix.
Post a reply to this message


 
 




 
 


Dan Connelly wrote:
> Warp wrote:
>> This is the reason why only rotation, scaling, skewing (which is actually
>> a combination of rotation and uneven scaling) and translation is
>> possible.
>>
> I'm a bit confused about the skew argument. There's
> matrix:
>
> 3 degrees of freedom: transformation
That should be translation.
> 3 degrees of freedom: scaling
> 3 degrees of freedom: rotation
>
> So this leaves 3 more degrees of freedom..... which are skew.
>
> (righthand coordinates)
>
>  ax 0 0 
>  0 ay 0  : scaling
>  0 0 az 
>
>  cz sz 0 
>  0 0 1  (permute for x, y)
>
> So between scaling and rotation, I'm constrained to
> antisymmetric matrixes.
>
> A typical shear matrix:
>
>  uz vz 0 
>  0 0 1  (permute for x, y)
>
> So this gives me 9 parameters:
> ax, ay, az, sx, sy, sz, vx, vy, vz
>
> the same number of parameters needed to specify the full matrix.
>
After thinking more about this, I realized my mistake.
Matrix multiplication fails to preserve symmetry, only addition.
So given that, it's possible to generate a symmetric component (the
offdiagonal terms generating shear) in addition to a antisymmetric
component (the offdiagonal terms generating rotation) from rotation
and scaling together, as long as the scaling is nonuniform, as Warp
said. My linear algebra is too rusty....
 0 1  1 0   0 1 
1 0   0 1  =  1 0 
And my degrees of freedom argument follows only if one is allowed a single
rotation and a single scaling. But generating pure shear requires two rotations.
Sorry....
Dan
Post a reply to this message


 
 




 
 


Le Fri, 26 Sep 2008 21:40:57 0700, Dan Connelly a modifié des petits
morceaux de l'univers pour nous faire lire :
> And my degrees of freedom argument follows only if one is allowed a
> single rotation and a single scaling. But generating pure shear
> requires two rotations.
>
> Sorry....
>
> Dan
Might I remind people that the internal transformation matrix is a 4x4,
using weighted coordinates system (x,y,z,w).
Successive transformations are stacked together by matrixmultiplication
at parse time.
Now, I would be interested in seeing a screwing transformationmatrix...
Please enlightme
Post a reply to this message


 
 




 
 


Le Forgeron <jgr### [at] freefr> wrote:
> Now, I would be interested in seeing a screwing transformationmatrix...
> Please enlightme
http://www.geocities.com/evilsnack/matrix.htm

 Warp
Post a reply to this message


 
 




 
 


Warp wrote:
> This is the reason why transformations must be linear. The straight ray
> must be straight also after it's transformed. It cannot become curved.
> This is the reason why only rotation, scaling, skewing (which is actually
> a combination of rotation and uneven scaling) and translation is possible.
Hmm I don't think nonlinear transformations would cause the ray to be a
curve. Nonlinear transf. are already possible in isosurfaces.
All you need is a different matrix for each pixel. Or rather, instead of
using a matrix you multiply with, use a generic function.
Post a reply to this message


 
 




 
 


> Hmm I don't think nonlinear transformations would cause the ray to be a
> curve.
Of course they would, if I apply the following transformation to a sphere:
x > x
y > y^3
z > z
Then it's impossible to convert this to a "straight ray intersecting with a
unit sphere at the origin" problem, which is what POV does for all linear
transformations.
> Nonlinear transf. are already possible in isosurfaces.
Yes, and they are much slower than rendering primitives like a sphere and
take setting up to get correct results. Primitives just work, fast.
Post a reply to this message


 
 




 
 


Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Hmm I don't think nonlinear transformations would cause the ray to be a
> curve.
Well, the very definition of "nonlinear transformation" *is* that
straight lines don't necessarily remain straight after the transformation.
Conversely the very definition of "linear transformation" is that any
straight line remains straight after the transformation.
> Nonlinear transf. are already possible in isosurfaces.
In the same sense as nonlinear transformations are "possible" for
triangle meshes (although not really, but almost).
You are not really transforming the isosurface object. You are modifying
its function, which is a different thing (from the point of view of
raytracing). You can't do that for other primitives.
> All you need is a different matrix for each pixel. Or rather, instead of
> using a matrix you multiply with, use a generic function.
Simply changing the direction of the ray according to a function, while
keeping the ray straight, is *not* enough to achieve nonlinear
transformations of objects.

 Warp
Post a reply to this message


 
 




 

