On 1/20/25 15:44, Josh English wrote:
> Very cool. I'm very rusty on matrices. My guess is the smooth rotation 
> (I'm assuming the camera is not rotating at all here, or the plane, 
> other than what the matrix is doing) comes from the fact that the first 
> two groups of the transform matrix are orthogonal, so it rotates instead 
> of shears. The scaling happens because the first two "vectors" aren't 
> constrained to the unit vector.
> 
> Or did I misunderstand what you meant by "I don't 'really' understand 
> what's happening...' and just talk down to you by accident?

No worries. I'm a life long "never polished on matrices" guy - who, due 
aging, is rusting badly in all respects at this point! :-) Thank you for 
thinking about it and offering your view of how it is working. What you 
wrote is not too far off my guess. Differing only that I think we are 
both rotating and shearing with the matrices as I'm specifying them here.

You understand correctly that all that is happening is changing matrix 
transforms of the checker pattern on a fixed x,y plane at z==0 as seen 
by a fixed orthogonal camera.

I'd only ever used the matrix, direct specification feature for simple 
shears (to lean things). I vaguely understand what pure rotation, 
scaling and translation matrices looked like internally - and our 
documentation gives equations at:

   https://wiki.povray.org/content/Reference:Transformations#Matrix

I'm fuzzy about the rotation and shearing occurring together - and that 
both effects start with some speed before crawling toward some limit. 
Some thinking aloud.

If we do some left handed, positive rotations about the z axis the 
internal matrices would look like:

v00 v01 v02 v03
v10 v11 v12 v13
v20 v21 v22 v23
v30 v31 v32 v33

+1.000 +0.000 0.0 0.0 // rotate z*+0.0
-0.000 +1.000 0.0 0.0
+0.000 +0.000 1.0 0.0 // Bottom rows dropped hereafter
+0.000 +0.000 0.0 1.0

+0.996 +0.087 0.0 0.0 // rotate z*+5.0
-0.087 +0.996 0.0 0.0

+0.707 +0.707 0.0 0.0 // rotate z*+45.0
-0.707 +0.707 0.0 0.0

+0.000 +1.000 0.0 0.0 // rotate z*+90.0
-1.000 +0.000 0.0 0.0

-0.087 +0.996 0.0 0.0 // rotate z*+95.0
-0.996 -0.087 0.0 0.0

-0.707 +0.707 0.0 0.0 // rotate z*+135.0
-0.707 -0.707 0.0 0.0

-1.000 +0.000 0.0 0.0 // rotate z*+180.0
-0.000 -1.000 0.0 0.0

-0.996 -0.087 0.0 0.0 // rotate z*+185.0
+0.087 -0.996 0.0 0.0

So, with normal positive z rotations through 180 we have -v10 and +v01 
value polarities. The v00 and v11 values are adjusted throughout to 
counter the shear contribution (preventing a scaling effect).

In my scene I'm holding v00 and v11 at 1.0 while the magnitudes of -v10 
and +v01 are always increasing. Meaning there is no counter compensation 
for the shearing adder - and we effectively scale up on frame_number.

Each frame step represents a smaller an smaller delta relative to the 
prior 'magnitudes' and both rotation and scaling slow. The rotation 
itself can never quite reach +180 degrees; The scaling never quite 
infinity.

I'll also guess at this point, the initial rotation and scale speed is 
made faster because my scene has that 'scale 1/6'. I believe this means 
the starting v00 and v11 matrix values are 1/6 rather than 1.0 internally.

Reasonable thinking?

Attached another animation where I applied the matrix rotate+shear 
calculations being played with here to an isosurface where the 'shear' 
values are (+-) f_hypot(x,y)*(frame_number-1)/5.

Bill P.

Post a reply to this message

Attachments:
Download 'matrixplayasiso.mp4.dat' (32 KB)