POV-Ray : Newsgroups : povray.binaries.animations : Playing with matrix transforms Server Time
21 Jan 2025 23:52:57 EST (-0500)
  Playing with matrix transforms (Message 1 to 7 of 7)  
From: William F Pokorny
Subject: Playing with matrix transforms
Date: 19 Jan 2025 15:33:14
Message: <678d618a@news.povray.org>
Ref:

https://news.povray.org/povray.binaries.images/thread/%3C678b9010%40news.povray.org%3E/

Playing more with matrix transforms mixing shears (and by side effect 
rotation) led to the attached animation.

The entire animation part of the set up was:

     matrix <
         1.0, (frame_number-1)/60, 0.0,
        -(frame_number-1)/60, 1.0, 0.0,
         0.0, 0.0, 1.0,
         0.0, 0.0, 0.0>

Then using +kff480 on the command line to render 480 frames.

There is a 'scale 1/6' of the checker pattern following the matrix 
transform in the base scene - which is slowly countered as the frame 
number increases.

I don't 'really' understand what's happening in total. In any case, it's 
cool, though, not as trippy as Josh's earlier post. :-)

Bill P.


Post a reply to this message


Attachments:
Download 'matrixfun.mp4.dat' (747 KB)

From: Josh English
Subject: Re: Playing with matrix transforms
Date: 20 Jan 2025 15:44:54
Message: <678eb5c6$1@news.povray.org>
On 1/19/2025 12:33 PM, William F Pokorny wrote:
> Ref:
> 
> https://news.povray.org/povray.binaries.images/thread/ 
> %3C678b9010%40news.povray.org%3E/
> 
> Playing more with matrix transforms mixing shears (and by side effect 
> rotation) led to the attached animation.
> 
> The entire animation part of the set up was:
> 
>      matrix <
>          1.0, (frame_number-1)/60, 0.0,
>         -(frame_number-1)/60, 1.0, 0.0,
>          0.0, 0.0, 1.0,
>          0.0, 0.0, 0.0>
> 
> Then using +kff480 on the command line to render 480 frames.
> 
> There is a 'scale 1/6' of the checker pattern following the matrix 
> transform in the base scene - which is slowly countered as the frame 
> number increases.
> 
> I don't 'really' understand what's happening in total. In any case, it's 
> cool, though, not as trippy as Josh's earlier post. :-)
> 
> Bill P.

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?

I had thought about shearing my meshes in the camera, so I will have 
work on that sooner rather than later.

Josh


Post a reply to this message

From: William F Pokorny
Subject: Re: Playing with matrix transforms
Date: 21 Jan 2025 04:26:59
Message: <678f6863$1@news.povray.org>
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)

From: Bald Eagle
Subject: Re: Playing with matrix transforms
Date: 21 Jan 2025 06:40:00
Message: <web.678f878a28e999341f9dae3025979125@news.povray.org>
"Easiest" and fastest thing to do is stop speculating and crank out some
numbers.

Have one shear matrix and another and apply them individually to a VECTOR, and
spit out the result to #debug with vstr.

Then have POV-Ray sequentially apply the matrices and spit out the result.

Apply your matrix transforms to a "matrix" by matrix transforming your basic
vectors x-hat, y-hat, and z-hat and stack the transform output in the #debug
stream to see what matrix you're actually applying in both individual cases and
your compound matrix transform case.

You can use the result vectors to plot spheres in a scene.
Match them up with the corners of the checkerboard pattern.

If anything is mis-matched, it's probably not POV-Ray, but some matrix
construction error.

Run all of the calculations with POV-Ray matrix transforms and vectors to check
and verify your calculations in the above post.

- BW


Post a reply to this message

From: William F Pokorny
Subject: Re: Playing with matrix transforms
Date: 21 Jan 2025 13:49:01
Message: <678fec1d@news.povray.org>
On 1/21/25 06:39, Bald Eagle wrote:
> 
> "Easiest" and fastest thing to do is stop speculating and crank out some
> numbers.
> 
> Have one shear matrix and another and apply them individually to a VECTOR, and
> spit out the result to #debug with vstr.
> 
> Then have POV-Ray sequentially apply the matrices and spit out the result.
> 
> Apply your matrix transforms to a "matrix" by matrix transforming your basic
> vectors x-hat, y-hat, and z-hat and stack the transform output in the #debug
> stream to see what matrix you're actually applying in both individual cases and
> your compound matrix transform case.
> 
> You can use the result vectors to plot spheres in a scene.
> Match them up with the corners of the checkerboard pattern.
> 
> If anything is mis-matched, it's probably not POV-Ray, but some matrix
> construction error.
> 
> Run all of the calculations with POV-Ray matrix transforms and vectors to check
> and verify your calculations in the above post.
> 
> - BW
> 

Hi Bill,

Your suggestions are reasonable ways we might better see what's 
happening. I suspect I've mislead you into thinking I believe something 
is amiss with how matrix transforms are working or with what I expect 
for a result.

My original surprise at the result in the lower right image over in pbi 
came from setting up a matrix I knew was out of bounds for typical use. 
I didn't expect things to work like two separate shear matrices; I 
didn't know what would happen, but the result surprised me due how 
dramatically it whacked the checker pattern.

I started to wonder what other useful direct matrix transformations 
there might be. The 'matrix form' posted about in this thread looks 
useful too, but I fully admit I'm just poking the matrix with a stick to 
see what happens. To some extent, I wonder about why it does what it 
does, but I care more about whether what it does might be useful.

The isosurface animation was itself another way to verify behavior. 
There is the usual pattern space to function space inversion. I 
un-inverted the rotation so it looked like the checker rotation. I left 
the scaling as is because scaling up of the function's coordinate space 
shrinks the isosurface result here - keeping the results in a fixed 
view/frame, so to speak.

I ran the animation out only to frame 50, but I did spot checks at 
frame_numbers 100 through 900 stepping by 100. An image of those renders 
is attached.

Bill P.


Post a reply to this message


Attachments:
Download 'matrixplayasiso_frm100__900.png' (33 KB)

Preview of image 'matrixplayasiso_frm100__900.png'
matrixplayasiso_frm100__900.png


 

From: Bald Eagle
Subject: Re: Playing with matrix transforms
Date: 21 Jan 2025 15:35:00
Message: <web.679003ca28e99934b00a87a025979125@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:

> My original surprise at the result in the lower right image over in pbi
> came from setting up a matrix I knew was out of bounds for typical use.
> I didn't expect things to work like two separate shear matrices; I
> didn't know what would happen, but the result surprised me due how
> dramatically it whacked the checker pattern.

Now that I've reviewed it all, your initial result was due to making x-hat and
y-hat the same vector.  <1, 1, 0> Essentially collapsing 3d space into a plane.
Attempting to apply the inverse and getting a parse error therefore makes sense.

> The isosurface animation was itself another way to verify behavior.
> There is the usual pattern space to function space inversion. I
> un-inverted the rotation so it looked like the checker rotation. I left
> the scaling as is because scaling up of the function's coordinate space
> shrinks the isosurface result here - keeping the results in a fixed
> view/frame, so to speak.

The isosurface looks like a strange, but interesting result to me, because
you're getting distortion of the square instead of the simple rotation like you
do in the checker.
It sort of looks like a camera iris - something to be pursued, I think.


Post a reply to this message

From: William F Pokorny
Subject: Re: Playing with matrix transforms
Date: 21 Jan 2025 18:00:47
Message: <6790271f$1@news.povray.org>
On 1/21/25 15:30, Bald Eagle wrote:
> The isosurface looks like a strange, but interesting result to me, because
> you're getting distortion of the square instead of the simple rotation like you
> do in the checker.
> It sort of looks like a camera iris - something to be pursued, I think.

Yes, I added a f_hypot(x,y) multiplier to the two 'rotation/shear terms' 
to create something more interesting than the square-frame rotating and 
shrinking.

Attaching two more mp4s. The one with the _BW.mp4 suffix removes that 
f_hypot() multiplier.

The one with the _SinCosHyp.mp4 suffix adds a sin() then cos() wrap of 
the f_hypot() multipliers. Done with the thought it might be 
interesting. :-)

Bill P.


Post a reply to this message


Attachments:
Download 'matrixplayasiso_bw.mp4.dat' (37 KB) Download 'matrixplayasiso_sincoshyp.mp4.dat' (30 KB)

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