POV-Ray : Newsgroups : povray.binaries.animations : Playing with matrix transforms Server Time
5 Feb 2025 17:44:43 EST (-0500)
  Playing with matrix transforms (Message 3 to 12 of 22)  
<<< Previous 2 Messages Goto Latest 10 Messages Next 10 Messages >>>
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)

From: Kenneth
Subject: Re: Playing with matrix transforms
Date: 25 Jan 2025 09:50:00
Message: <web.6794f97628e99934e83955656e066e29@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:
>
> 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.
>

That is also my usual method of playing with matrices, ha-- because I still have
a hard time understanding how they work and how to use them. I like your video
though; I need to experiment with your code example to see how I can break it!

------------
[In Windows 10]  I thought I should mention something: In the newsgroups'
standard web portal that I use, the Firefox 'previews' of your .mp4 videos do
not play -- with the message "Video cannot be played because the file is
corrupt." (which is not the case!) As a comparison: Josh's .mp4 animation in his
recent post  "Go home, RSOCP, yer drunk" plays fine in the Firefox preview.

So I downloaded your video-- and it plays fine in *most* of my Windows 10 media
players: VLC Media Player, SM Player, and even my old VirtualDub2. But it does
not play in Windows' own Media Player (a black screen)-- and actually breaks
Irfanview (the app hangs and has to be terminated via Windows Task Manager.)
Irfanview will usually play just about any video that I throw at it, so its
behavior in this case is very weird.

In VLC Media Player, I took a look at your first posted video's encoding
statistics:

Codec: H264-MPEG-4 AVC (part 10) (avc1)
Video Resolution: 450 X 450
Buffer Dimensions: 464 X 482
Decoded Format: Planar 4:4:4 YUV
Color Primaries: ITU-R BT.709

I did some research (yet again!) about video encoding and codecs, because it is
all so complicated to remember. Your video's stats are fairly standard stuff
AFAIU-- except for the 4:4:4 chroma subsampling.  4:2:0 is the typical scheme
for h.264; I use that myself. Take a look at Wikipedia's "h.264" page,
particularly the subsection "Feature support in particular profiles". It appears
that 4:4:4 is only supported in a particular high-end 'flavor' of h.264; perhaps
that presents a problem for Firefox, and/or for Windows 10's built-in video
codecs.

Or maybe you encoded the videos using 10-bit colors rather than the more
standard 8-bit?

I also did a search for possible Firefox problems regarding playback of
h.264 .mp4 files, but found nothing that would be helpful-- except for this
possibility:

"Yes, Firefox can play 4:4:4 videos, but only if your hardware and system
settings support it; this is because the capability to play 4:4:4 video depends
on your graphics card and the video codec used, not solely on the browser
itself."

(By the way: I had the same video-playback problems with your December 2024
post,
 "New f_dnoise(), modified f_dturbulence(). yuqk R17"
but forgot to mention it at the time.)


Post a reply to this message

From: Tor Olav Kristensen
Subject: Re: Playing with matrix transforms
Date: 25 Jan 2025 19:25:00
Message: <web.6795803c28e99934805081db89db30a9@news.povray.org>
For those of you that want to be able to do matrix calculations within POV-Ray,
I have made a library that can do some of that.

It can be found here:

https://github.com/t-o-k/POV-Ray-matrices
(NB: Some of the descriptions and examples are not finished yet.)

Below are some examples with this library that may be relevant to this thread.

--
Tor Olav
http://subcube.com
https://github.com/t-o-k


// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#version 3.7;  // Should also work in version 3.8

global_settings { assumed_gamma 1.0 }

#include "matrices.inc"

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#declare No_Change_Transform = transform { }

#declare Rotate_Transform = transform { rotate 60*x }

#declare Shear_Transform =
    transform {
        matrix <
            1, 1, 0,
            0, 1, 0,
            0, 0, 1,
            0, 0, 0
        >
    }

#declare Translate_Transform = transform { translate <3, 1, 2> }

#declare Composite_Transform =
    transform {
        No_Change_Transform
        Rotate_Transform
        Shear_Transform
        Translate_Transform
    }

#debug "\nNo Change Transform:\n"
M_Print(M_FromTransform(No_Change_Transform))

#debug "\nRotate Transform:\n"
M_Print(M_FromTransform(Rotate_Transform))

#debug "\nShear Transform:\n"
M_Print(M_FromTransform(Shear_Transform))

#debug "\nTranslate Transform:\n"
M_Print(M_FromTransform(Translate_Transform))

#debug "\nComposite Transform:\n"
M_Print(M_FromTransform(Composite_Transform))

#debug "\n\n"

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#declare No_Change_Matrix = M_Identity(4);

#declare Rotate_Matrix = M_Rotate3D_AroundX(radians(60));

#declare Shear_Matrix =
    array[4][4] {
        {  1.0,  1.0,  0.0,  0.0 },
        {  0.0,  1.0,  0.0,  0.0 },
        {  0.0,  0.0,  1.0,  0.0 },
        {  0.0,  0.0,  0.0,  1.0 }
    }
;

#declare Translate_Matrix = M_Translate3D(<3, 1, 2>);

#declare Composite_Matrix =
    M_Mult(
        M_Mult(
            M_Mult(
                No_Change_Matrix,
                Rotate_Matrix
            ),
            Shear_Matrix
        ),
        Translate_Matrix
    )
;

#debug "\nNo Change Matrix:\n"
M_Print(No_Change_Matrix)

#debug "\nRotate Matrix:\n"
M_Print(Rotate_Matrix)

#debug "\nShear Matrix:\n"
M_Print(Shear_Matrix)

#debug "\nTranslate Matrix:\n"
M_Print(Translate_Matrix)

#debug "\nComposite Matrix:\n"
M_Print(Composite_Matrix)

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#debug "\n"
#error "No error, just finished"

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7


Post a reply to this message

From: Bald Eagle
Subject: Re: Playing with matrix transforms
Date: 25 Jan 2025 19:30:00
Message: <web.6795815028e999341f9dae3025979125@news.povray.org>
"Kenneth" <kdw### [at] gmailcom> wrote:

> That is also my usual method of playing with matrices, ha-- because I still have
> a hard time understanding how they work and how to use them.

A matrix is nothing more than a statement of the end position of each basis
vector after the transformation.

For instance, when I do a shear along x, what I do is take "y" (<0, 1, 0>) and
shit it along the x-axis.  Maybe make it become <0.5, 1, 0>.

So matrix {
1, 0, 0,
0, 1, 0,
0, 0, 1,
0, 0, 0
}

becomes

matrix {
1, 0, 0,
0.5, 1, 0,
0, 0, 1,
0, 0, 0
}

Just think of the matrix operator as

matrix {
x,
y,
z,
translate <a, b, c>
}

and your matrix transform is

matrix {
new_x,
new_y,
new_z,
translate <a, b, c>
}

https://www.youtube.com/watch?v=kYB8IZa5AuE


https://www.f-lohmueller.de/pov_tut/trans/trans_000e.htm


Post a reply to this message

From: William F Pokorny
Subject: Re: Playing with matrix transforms
Date: 25 Jan 2025 19:58:04
Message: <6795889c$1@news.povray.org>
On 1/25/25 09:47, Kenneth wrote:
> I did some research (yet again!) about video encoding and codecs, because it is
> all so complicated to remember. Your video's stats are fairly standard stuff
> AFAIU-- except for the 4:4:4 chroma subsampling.  4:2:0 is the typical scheme
> for h.264; I use that myself. Take a look at Wikipedia's "h.264" page,
> particularly the subsection "Feature support in particular profiles". It appears
> that 4:4:4 is only supported in a particular high-end 'flavor' of h.264; perhaps
> that presents a problem for Firefox, and/or for Windows 10's built-in video
> codecs.
> 
> Or maybe you encoded the videos using 10-bit colors rather than the more
> standard 8-bit?

Hi Kenneth,

Excepting - maybe - the noise video where output grayscale and I 
remember trying the flag '-vf format=gray' to get a smaller mp4 file 
(made no difference), everything should be 8 bits because the png output 
is defaulting to 8 bits per channel.

Thank you for taking the time to investigate the problem you've seen 
with my ffmpeg encoded videos! I'm an amateur having encoded very few 
animations over the years - and I've posted fewer still.

I'd captured recommendations Dick Balaska made years ago for options 
(which included a '-pix_fmt yuv420p' setting), however, when I tried the 
command line late last year I kept getting errors I didn't understand.

Being lazy, I dropped back to a very simple command with a flag for 
frame rate, the input pattern for saved image frames and the output file 
name... Things seemed to work, so I went with ffmpeg's defaulting. :-) 
  
  
  
  
  
  


Next time I create an animation with ffmpeg, I'll try to get the 4:2:0 
chroma sub-sampling.

Bill P.


Post a reply to this message

From: Kenneth
Subject: Re: Playing with matrix transforms
Date: 25 Jan 2025 22:35:00
Message: <web.6795aca928e99934e83955656e066e29@news.povray.org>
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > That is also my usual method of playing with matrices, ha-- because I
> > still have a hard time understanding how they work and how to use them.
>
> A matrix is nothing more than a statement of the end position of each basis
> vector after the transformation.
> [clip]

Thanks for the useful info. Actually, the shearing ability of a matrix is one of
the (few) things that I do grasp. And William P's checkerboard rotation trick
has also been informative. But there are other more complex matrix transforms
that I have seen in newsgroup posts and include files that really baffle me, as
to how the 'magical' results are obtained. (Rune's old 'illusion.inc' file is a
prime example; I use it a lot, but its workings are a mystery to me.)

What I *need* to do is devote the time solely to learning the fundamentals-- and
without other POV-ray distractions. But that's difficult! Because there are
many *other* features that I only understand at a basic level...like
sophisticated functions! To truly learn all that I need to know, I could spend
25 hrs a day.

But every now and then, I have the urge to actually *render* something. ;-)


Post a reply to this message

<<< Previous 2 Messages Goto Latest 10 Messages Next 10 Messages >>>

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