[Sorry for the strange title; I couldn't think of anything better.]

Assume that I've traced an object using the trace(...) command, including the
normal found at the object's surface (Norm).

GIVEN:
#declare ROTATION_1 = <50,100,150>;  // just a different pre-declared rotation
to be used later

But now, I want to 'combine' the following with that rotation, somehow...

#declare MY_TRANSFORM =
transform{
#if(Norm.z < 0)
rotate 180*y
#else
#end
}

....plus a few other similar Norm-based #if transforms.

I want to end up with...
#declare NEW_ROTATION =  <...the new combined stuff...>;

Assume that it has to be done in this order. and that I need the new final
rotation as a single separate entity (for use in a #debug statement, for
example). What would be the easiest magic way (or built-in tool) to combine the
original rotation with the transforms? I'm stumped...except for the brute-force
method of...
#declare NEW_ROTATION =
<50, 100  #if(Norm.z < 0) + 180 #else #end, 150>;

.... which could get really cumbersome.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
>What would be the easiest magic way (or built-in tool) to combine the
> original rotation with the transforms?

Wait...

Maybe there *is* a simple way:

Instead of the original rotation being...
#declare ROTATION_1 = <50,100,150>;

.... I could change it to
#declare TRANS_1 =
transform{rotate <50,100,150>}

.... then combine ALL the tranforms like this...

#declare NEW_ROTATION =
tranform{
transform{TRANS_1}
transform{MY_TRANSFORM_1} // the #if/rotate transform
transform{MY_TRANSFORM_2} // ditto
transform{MY_TRANSFORM_3} // ditto
....etc.
}

I suppose the result could be used in a #debug statement too. (I've been
thinking about this stuff for *way* too long, not seeing the obvious.)

I guess this scheme would work?

Post a reply to this message

Am 17.09.2018 um 00:31 schrieb Kenneth:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>>
>> What would be the easiest magic way (or built-in tool) to combine the
>> original rotation with the transforms?
> 
> Wait...
> 
> Maybe there *is* a simple way:
> 
> Instead of the original rotation being...
> #declare ROTATION_1 = <50,100,150>;
> 
> ..... I could change it to
> #declare TRANS_1 =
> transform{rotate <50,100,150>}
> 
> ..... then combine ALL the tranforms like this...
> 
> #declare NEW_ROTATION =
> tranform{
> transform{TRANS_1}
> transform{MY_TRANSFORM_1} // the #if/rotate transform
> transform{MY_TRANSFORM_2} // ditto
> transform{MY_TRANSFORM_3} // ditto
> .....etc.
> }
> 
> I suppose the result could be used in a #debug statement too. (I've been
> thinking about this stuff for *way* too long, not seeing the obvious.)
> 
> I guess this scheme would work?

Should do, definitely.
I was just about to suggest something along those lines.

Post a reply to this message

Thanks. The combined transforms do work, as a construction-- but there's a
problem when trying to use the final NEW_ROTATION transform in a #debug
statement (by 'pulling it apart' with the required dot notation)...

#debug concat ("\n","rotate    <",
          str (......,0,3),str(.......,0,3),str (......,0,3),
                 ">\n")

I can't find a usuable syntax for the components.
For example, neither of these  two work there, because #debug doesn't like to
see the transform{...} keyword:
transform{NEW_ROTATION.x}
or, transform{NEW_ROTATION}.x

I also tried to get just the x/y/z components beforehand, like...
#declare FOO_X = transform{NEW_ROTATION.x}
or,  #declare FOO_X = transform{NEW_ROTATION}.x;

....or a few other odd attempts, for subsequent use in the #debug; but no luck.
In these cases, the parser treats the 'dot' as a foreign object in the
#declare.

Maybe there's another syntax that I haven't thought of? Or could the problems be
due to a transform being just a raw matrix(?) behind the scenes, with no way to
extract x/y/z components?

Post a reply to this message

I think what you need to do is define something like:
X = x, Y = y, and Z = z, and use those as the basis vectors of your overall
transform matrix composition.

Then apply those sequential transforms to those vectors, and then, as an
exercise for you, the alert reader, do trig to get the angles back.

This sounds pretty cool - it should be neat once it's worked out.  :)


I suppose it may be possible to work out the answer purely by matrices:
(see last line)

https://en.wikipedia.org/wiki/Transformation_matrix

Composing and inverting transformations
One of the main motivations for using matrices to represent linear
transformations is that transformations can then be easily composed and
inverted.

Composition is accomplished by matrix multiplication. Row and column vectors are
operated upon by matrices, rows on the right and columns on the left. Since text
reads from left to right, row vectors are preferred when transformation matrices
are composed:

If A and B are the matrices of two linear transformations, then the effect of
applying first A and then B to a row vector x is given by:

{\displaystyle ({\vec {x}}\mathbf {A} )\mathbf {B} ={\vec {x}}(\mathbf {AB} ).}
{\displaystyle ({\vec {x}}\mathbf {A} )\mathbf {B} ={\vec {x}}(\mathbf {AB} ).}


In other words, the matrix of the combined transformation A followed by B is
simply the product of the individual matrices."

I did a brief search to see if anyone had written some macros to do matrix
multiplication - nothing yet, but somewhat related.

http://news.povray.org/povray.advanced-users/thread/%3Chb4nftstffp43ia7le4qpbvassaqhsi2gb%404ax.com%3E/?mtop=63619

http://evilsnack.byethost22.com/matrix.htm?i=1

http://news.povray.org/povray.advanced-users/thread/%3Cslrn94euki.6kk.ron.parker@fwi.com%3E/


and this is in C++, with
"std::ostream &  writePov (std::ostream &os) const
  Write matrix in Povray format."
Which is what grabbed my eye.


http://www.nigels.com/glt/doc/class_matrix.html
http://www.nigels.com/glt/doc/matrix4_8h-source.html

Post a reply to this message

Am 17.09.2018 um 22:38 schrieb Kenneth:

> Maybe there's another syntax that I haven't thought of? Or could the problems be
> due to a transform being just a raw matrix(?) behind the scenes, with no way to
> extract x/y/z components?

Exactly that: There is no native syntax to get at the data in a
transformation matrix.

What you /can/ do though is shove the vectors <0,0,0>, <1,0,0>, <0,1,0>
and <0,0,1> through the transformation (using `vtransform()`), and from
that deduce all the matrix coefficients.

If you know the transformation contains no translation, the vector
<0,0,0> isn't needed as it is then guaranteed to transform to itself.

Once you know the matrix coefficients, using those to compute Euler
angles (presuming the matrix is a pure rotational matrix) would then be
the next step.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> If you know the transformation contains no translation, the vector
> <0,0,0> isn't needed as it is then guaranteed to transform to itself.
>
> Once you know the matrix coefficients, using those to compute Euler
> angles (presuming the matrix is a pure rotational matrix) would then be
> the next step.

Yes, mine is purely a rotational transform.

Thanks to both you and Bald Eagle for the detailed replies. I need to digest it
all, to make sense. (Matrices are "way above my pay grade" at the moment, but I
keep trying to fully understand what they can do, and to learn to use them
intelligently. I see that they're a 'core concept' with a lot of power.)

Just a thought for the future: Could there be a way of writing some source-code
that would deal with all the matrix multiplication etc. behind the scenes, with
the end result being a user syntax that would actually allow simple dot-notation
to pull out x/y/z components from a transform (maybe just for rotations)?
Presently, the inner workings of matrices are pretty much all Greek to me... and
I can see that such a code addition (if possible!) would be useful.

My naive thought for the day ;-)

Meanwhile, I now have some hard cogitating to do...

Post a reply to this message

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

>
> I did a brief search to see if anyone had written some macros to do matrix
> multiplication - nothing yet, but somewhat related.
>
>
http://news.povray.org/povray.advanced-users/thread/%3Chb4nftstffp43ia7le4qpbvassaqhsi2gb%404ax.com%3E/?mtop=63619
>
> http://evilsnack.byethost22.com/matrix.htm?i=1
>
>
http://news.povray.org/povray.advanced-users/thread/%3Cslrn94euki.6kk.ron.parker@fwi.com%3E/
>

Thanks! I've started diligently going through these useful links for insights;
some good tidbits have popped up already...

Post a reply to this message

Am 18.09.2018 um 03:27 schrieb Kenneth:

> Just a thought for the future: Could there be a way of writing some source-code
> that would deal with all the matrix multiplication etc. behind the scenes, with
> the end result being a user syntax that would actually allow simple dot-notation
> to pull out x/y/z components from a transform (maybe just for rotations)?

It might be possible to conjure up something to get at the matrix
coefficients easier.

As for converting a matrix back into Euler rotation angles, I don't
think it would make sense to put anything into the source code; this is
too much of a special case to warrant increasing the matrix memory
footprint to track rotation separately.

I guess it would make sense though to provide some macros in math.inc to
help with that. Either a macro to actually decompose a rotation-only
matrix back into rotation angles, or a macro to combine two Euler
rotation vectors into a new Euler rotation vector.

Unfortunately I myself currently don't have the time to switch to "math
mode" and concoct something like that, so somebody else would have to
pick up that glove.

Post a reply to this message

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

> Thanks! I've started diligently going through these useful links for insights;
> some good tidbits have popped up already...

Well I'm glad they're useful --- I'm never sure.

You might get a little farther, faster, if you think about it - and maybe try to
implement matrices - in a spreadsheet.
Plus you get the benefit of instantaneously visible calculation results.

I'v dabbled with these in SDL in the past - doing determinants - but matrix mult
ought to be fairly straightforward.

Post a reply to this message