Hi,

this no request for help nor a bug report, rather a suggestion and possibly
an invitation to correct my opinion.

A decade ago I used POVray to visualize MRI data. Now I came back to it to
teach my son a demonstrative computer language in the hope that an SDL
which rapidly depicts something you created yourself is far more
fascinating than a typical compiler language where you have way to go until
you see an animate window.

So when reading the current manual I stumbled over a sort of inconsistency
of the SDL. When talking about complex tranformations the manual shows
vectors and matrices and even a matrix product; but here the common rules
of matrix multiplication are twisted. Being used to homogeneous matrices
and vectors in computer graphics - where multiplication means passing
through
rows and columns (respectively) of equal dimension - it looks unfamiliar
(and
at first sight even wrong) that you have to arrange the matrix rows and
columns pivotted around the first diagonal and forget about about equal
size of both.

My suggestion is: allow for the use of 4-dimensional homogeneous vectors and
matrices to be switched on if advantageous. I could imagine that the
calculation overhead could be reduced if successive transformations could
be easily simplified to just one either by the programmer or by POVray.

I have not investigated in the source code about this. But I suppose that
internally POVray is using homogeneous matrices for its computations since
they are so handy; so making them apparent would not be much extra work. If
not, I must concede that the need for this amendment is not big enough to
justify true re-modelling of the source.

So my question is: are there others who'd like to use homogeneous matrices
or am I just too academic?

Be that as it may I find POVray a marvellous program and want to thank and
congratulate the involved programmers.

Yours JWH

Post a reply to this message

jwh wrote:
> So my question is: are there others who'd like to use homogeneous matrices
> or am I just too academic?

Homogeneous matrices are indeed a purely academic invention in computer
graphics courses used to show how "great" they are, while in reality they
just obfuscate the subject matter to impress the unsuspecting student. Poor
teachers and book authors usually need them, while in real life you
implement the code to take human-readable forms of transformations (aka
rotation, translation, scaling) and turn them into homogeneous matrices
once. Then you never need to know about them any more as their mathematical
properties are fairly simple (well, matrices in general are simple after
all) - it is only visualizing homogeneous matrices content's meaning in 3D
that is non-intuitive.

The major real benefit homogeneous matrices have in programming with 3D
graphics today is that they are 16 scalars in size. Hence they are easier to
handle by computers when addressing scalars and using SIMD units compared to
3x3 matrices (which in various cases would be sufficient despite some
undesirable properties). In short, homogeneous matrices are nice, but
dealing with computer graphics, one really does not need to know more about
them than that they are matrices with a few interesting properties.

	Thorsten

PS: If you want something really useless, there is of course always the
rendering equation. You can tell a poor instructor or professor at
university if they ask for the memorized rendering equation in an exam ;-)

Post a reply to this message

jwh wrote:

> My suggestion is: allow for the use of 4-dimensional homogeneous vectors and
> matrices to be switched on if advantageous. I could imagine that the
> calculation overhead could be reduced if successive transformations could
> be easily simplified to just one either by the programmer or by POVray.

I'm not quite sure what you're trying to get at. Possibly you are
confused by the syntax of the "matrix" transform, which takes only
12 floats, as the remaining 4 values are assumed to be <0,0,0,1>,
and that the order of the entries in ASCII formatting leads to a
matrix which is actually transposed with respect to the usual
convention of having the translation in the last *column*.

With this in mind, the formular presented in 2.2.7.1.4 is really
just the common matrix multiplication. It probably wouldn't hurt
if the matrix keyword supported specifying a 4x4 matrix directly,
you never know when it might come in handy.

Post a reply to this message

I have found a couple of videos for my college course. But I'm not sure which
type or method to choose, while I'm aware of two of them so far. The first one
was tested, when we used a projective transformation here:
https://www.khanacademy.org/math/precalculus/x9e81a4f98389efdf:matrices/x9e81a4f98389efdf:matrices-as-transformations/v
/transforming-position-vector
https://writemyessaytoday.net/write-my-essay-in-12-hours

Post a reply to this message