 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
|
|
