William F Pokorny <ano### [at] anonymousorg> wrote:
> On 1/25/25 19:58, William F Pokorny wrote:
>
> > Next time I create an animation with ffmpeg, I'll try to get the 4:2:0
> > chroma sub-sampling.
>
> Alright. Found myself playing again today with a direct matrix transform
>  against yuqk's updated wrinkle pattern. The attached animation uses
> the sampling you suggested. Does it work in programs where failing before?
>

YES, this animation plays in all of my Windows media players, including
Irfanview. AND, it also plays in Firefox's 'preview'. Great work! Thanks for
taking the time to dig down into your settings for ffmpeg; very much
appreciated.

For this animation, my VLC Media Player does not report the particular 'chroma
subsampling' scheme that you used... but that seems to be its usual behavior
when encountering the 'typical' 4:2:0. So I guess the switch from 4:4:4 to 4:2:0
has solved the problem. That is interesting news! :-)

Post a reply to this message

On 1/19/25 15:33, William F Pokorny wrote:
> Playing more with matrix transforms

Recently the idea of splines as interpolations was touched upon in the 
thread:

https://news.povray.org/povray.advanced-users/thread/%3Cweb.6797e39ce9acc1774cc51b5c25979125%40news.povray.org%3E/

Perhaps obvious the matrix play in this thread can act as a rotational 
interpolation.

Attached an animation and full scene file for the animation (for jr). It 
should run in v3.8 beta 2 too.

Bill P.

Post a reply to this message

Attachments:
Download 'interpolatematrix.mp4.dat' (391 KB) Download 'interpolatematrix.pov.txt' (4 KB)

William F Pokorny <ano### [at] anonymousorg> wrote:

> Perhaps obvious the matrix play in this thread can act as a rotational
> interpolation.

Well now that we're going there - Bezier and other splines can all be
represented as matrix multiplications.

https://blog.demofox.org/2016/03/05/matrix-form-of-bezier-curves/

https://observablehq.com/@danburzo/the-matrix-form-of-some-common-cubic-splines

I know that clipka was talking about trying to find as much common ground for
all of the primitives as possible, so that we could have as few specialized
objects/data structures as possible, so perhaps it would good to look at a lot
of the spline/interpolation code as matrix-based.

We ought to have robust and versatile matrix methods available anyway.

Also, rotational matrices tie directly into complex numbers - so maybe there's a
way to roll that in there too.

- Bald "I want it all" Eagle

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> I know that clipka was talking about trying to find as much common ground for
> all of the primitives as possible, so that we could have as few specialized
> objects/data structures as possible, so perhaps it would good to look at a lot
> of the spline/interpolation code as matrix-based.

There are a few fun things one can do with the matrix based spline calculations.
One can blend two spline matrices to a new spline, or over time morph from one
spline to an other spline type. But one needs access to POV-Ray's internals
then.

The whole spline matrices thing is covered here:

http://web.archive.org/web/20151002232205/http://home.comcast.net/~k9dci/site/?/page/Piecewise_Polynomial_Interpolation
/

Download the book PDF and the separate appendix.

ingo

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> > Rune's old 'illusion.inc' file is a prime example [of a complex matrix];
> > I use it a lot, but its workings are a mystery to me.
>
> I have never used it, and the instructions puzzle me.
> Perhaps if you could post a scene using it, and the intermediate render, then
> maybe I can have some idea how to use it and see how it works.
>

(Sorry for the delay, I was updating my own notes about illusion.inc and running
more test renders.)

Yeah, it was confusing to me as well when I first tried to use it-- mainly
because it is set up as a demonstration file rather than a basic include. And
the demonstration results are a bit confusing, IMO. It is basically a different
way of applying an image_map to objects-- but from the camera's viewpoint, and
with a rather magical matrix manipulation that alters the 'depth perspective' of
the applied image.

It is still available at
https://runevision.com/3d/include/

(Rune mentions that the download has a 2010 update by Sam Benge, which is
apparently no longer part of it; I checked recently.)

Back in 2013, I posted some preliminary info about how the include file works:
https://news.povray.org/povray.binaries.images/thread/%3Cweb.5106f53bd9b7ab13c2d977c20%40news.povray.org%3E/

I also posted a kind of explanatory animation at the time, but it is in
an older .avi video format:
https://news.povray.org/povray.binaries.animations/thread/%3Cweb.5106fb628df1613ec2d977c20%40news.povray.org%3E/?ttop=4
44658&toff=150

I should mention have been using my own simplified and slightly updated version
of the include file for years. I've had thoughts of posting it-- along with my
own set of instructions and a different demo-- but was worried that it might
infringe on Rune's original copyright notice from 2003. Although, I now see that
an update would probably be OK to post.

Rune's matrix transform is quite mysterious (to me) because it uses the
*camera's* settings, along with some math manipulations that are presently way
over my head.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> {Illusion.inc] is basically a different
> way of applying an image_map to objects-- but from the camera's viewpoint, and
> with a rather magical matrix manipulation that alters the 'depth perspective'
> of the applied image.
>

It essentially applies the image_map as an 'orthographic' projection onto scene
objects, devoid of perspective... which is quite different from a typical
map_type 0 projection.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> It is basically a different
> way of applying an image_map to objects-- but from the camera's viewpoint, and
> with a rather magical matrix manipulation that alters the 'depth perspective' of
> the applied image.

Yes, I get that part.


> Rune's matrix transform is quite mysterious (to me) because it uses the
> *camera's* settings, along with some math manipulations that are presently way
> over my head.

So, as best I can tell, he's simply done the kind of thing that's done in the
"make this object/text always face the camera"... with the matrix.

but the image_map is converted to a function that incorporates x/z and y/z which
also corrects for the projection matrix so that everything lines up no matter
how near or far.

I just haven;t had the time to figure out how to start applying his include to a
scene, so that I can reverse-engineer it enough to provide a didactic diagram
and explanation.

So if you have working code....   ;)

- BW

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> >
> > {Illusion.inc] is basically a different
> > way of applying an image_map to objects-- but from the camera's viewpoint, and
> > with a rather magical matrix manipulation that alters the 'depth perspective'
> > of the applied image.
> >
>
> It essentially applies the image_map as an 'orthographic' projection onto scene
> objects, devoid of perspective... which is quite different from a typical
> map_type 0 projection.

So, I spent a bit of time working out how to do the "this object always faces
the camera" thing, and it's essentially what gets done in screen.inc, minus the
final translation.

Compare that to Rune's "rather magical matrix manipulation" and you'll see that
it's basically the same thing.

So it looks to me that what's going on is, the image gets oriented to be
perpendicular to the camera / parallel to the image plane, and the divisions by
z in the image function are there to provide the appropriate scaling of the
image depending upon where it gets mapped to.

- BW

Post a reply to this message

Attachments:
Download 'facecamera.pov.txt' (2 KB)

"Bald Eagle" <cre### [at] netscapenet> wrote:

> So, I spent a bit of time working out how to do the "this object always faces
> the camera" thing,

And here's a bit more commentary to better explain how that works, and provide a
useful bit of code for future reference.

#macro FaceCamera (Object, CL)
 #local Min = min_extent (Object);
 #local Max = max_extent (Object);
 #local OL = Min + (Max-Min)/2;

 #declare CamL = CameraLocation;   // wherever you're putting it
 #declare CamD = vnormalize (OL-CamL);  // direction of camera view
  // One can alternately look at this as -Caml, translated to the object's
  // location by adding OL.  -CamL+OL = (OL-CamL)
 #declare CamR = vnormalize (vcross(y,CamD)); // to the right
  // The vector cross product gives a vector that is perpendicular to the two
  // given vectors.  If we're at the vertex (camera location) and we cross the
  // direction of view and the y-axis, we get a vector pointing out to the right
  // CamD and y are likely not perpendicular, so the resulting vcross is some
  // size != 1, so we normalize the size.
 #declare CamU = vnormalize (vcross(CamD,CamR)); // camera up
  // So now we have a view direction and a right vector, which are perpendicular
  // So we do another vector cross product, and get the new "up" vector
  // Which completes our new "frame of reference".
  // The tangent, normal, and binormal unit vectors, often called T, N, and B,


  // So now when we take the old x, y, and z basis vectors or normal POV-space
  // and move them to align with the new TNB vectors, your object whose
  // orientation was based upon x, y, and z is now based upon the new
  // T, N, and B vectors.
  // Since default camera points at z, and default orientation of most objects
  // is in the xy plane, the object is now in the same relative orientation
  // to the camera in the new TNB frame, and so always faces the camera.
 #declare Object_Transform =
 transform {
  matrix <
  CamR.x, CamR.y, CamR.z,
  CamU.x, CamU.y, CamU.z,
  CamD.x, CamD.y, CamD.z,
      0,      0,      0
  >
 }

 object {
  Object
  transform {Object_Transform}
 }
#end // end macro FaceCamera

Post a reply to this message

Attachments:
Download 'always facing the camera.txt' (2 KB)

OK, so I was diagramming this all out, and that got me to focus on the fact that
the text not only gets rotated, but MOVED.

That's because it's not rotating the text around the origin.
Just apply the following fix:


 object {
  Object
  translate -OL
  transform {Object_Transform}
  translate OL
 }
#end // end macro FaceCamera

Post a reply to this message

Attachments:
Download 'howfacethecameraworks.png' (26 KB)

Preview of image 'howfacethecameraworks.png'