In article <3a43dbf0@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> If I've understood it correctly, to multiply matrixes in POV-Ray I can
> simply apply both matrixes to the object (first A, then C), right?

Depends on what you want to do...matrices are multiplied together to 
concatenate the transforms, but you won't be able to retrieve the 
matrix. And if you really only want to manipulate objects or vectors, 
and don't care about the matrices themselves, MegaPOV allows you to 
transform vectors and use inverse transformations without needing any 
macros.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" wrote:
> "Rune" wrote:
>
> > If I've understood it correctly, to multiply matrixes in
> > POV-Ray I can simply apply both matrixes to the object
> > (first A, then C), right?
>
> Depends on what you want to do...matrices are multiplied
> together to concatenate the transforms, but you won't be
> able to retrieve the matrix.

I haven't figured it all out yet, but I *think* I won't need the matrix
itself.

> And if you really only want to manipulate objects or
> vectors, and don't care about the matrices themselves,
> MegaPOV allows you to transform vectors and use inverse
> transformations without needing any macros.

Uh, clever!

Erm, hehe, I guess that means I don't need the inverse matrix macro after
all...

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated December 17)
/ Also visit http://www.povrayusers.org

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: They're not really.  The fourth column is just a convenient way of specifying
: the translate component.  You could easily take that out, invert, and put 
: it back.

  But aren't the rays also translated with the inverse translation of the
object? Isn't the whole 4x4 matrix inverted?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 24 Dec 2000 12:17:09 -0500, Warp wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: They're not really.  The fourth column is just a convenient way of specifying
>: the translate component.  You could easily take that out, invert, and put 
>: it back.
>
>  But aren't the rays also translated with the inverse translation of the
>object? Isn't the whole 4x4 matrix inverted?

Yes, but it's easiest to invert the 3x3 matrix and then tack on the inverse
translation than to try to invert the whole thing.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: Yes, but it's easiest to invert the 3x3 matrix and then tack on the inverse
: translation than to try to invert the whole thing.

  But would inverting the whole 4x4 matrix work as well?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 24 Dec 2000 13:22:46 -0500, Warp wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: Yes, but it's easiest to invert the 3x3 matrix and then tack on the inverse
>: translation than to try to invert the whole thing.
>
>  But would inverting the whole 4x4 matrix work as well?

Of course.  

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
:>  But would inverting the whole 4x4 matrix work as well?

: Of course.  

  It may be crystal-clear to you, but it isn't to me.

  The decision to put the translation as the fourth column of the matrix
can sound quite arbitrary ("Hey, we need some place to put the translation
along with the other transformations. Where should we put it? Perhaps the
most handy way is just to expand the transformation matrix to 4x4 and put
the translation in the extra places").

  However, if the inversion of this matrix works as expected (that is, the
translation is also inverted as it should), then putting the translation
where it is now has a strong mathematical basis. Which is good, of course :)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 25 Dec 2000 11:11:23 -0500, Warp wrote:
>  However, if the inversion of this matrix works as expected (that is, the
>translation is also inverted as it should), then putting the translation
>where it is now has a strong mathematical basis. Which is good, of course :)

It does.  Essentially, as long as you put a '1' in the last row of the 4-d
vector, the translation gets added in to the transformation as you'd expect
it to.  The last row should always be 0,0,0,1.  Any other sort of 4-d matrix
doesn't have the same effect.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Here's a slightly different method which might be a little faster,
since it uses intrinsically defined functions and pre-calculates more of
the values.

Taking my cue from Rune, define

/////////////////////////////////

#declare bX = <1,-0.05,0>;
#declare bY = <-0.5,0.5,0>;
#declare bZ = <0,0,1>;
#declare bC = <0,0,0>;

// The 16 statements to fill out the 16 elements of the inverse
// New system devised by Ben Birdsey (12/31/00)

#declare xp  = vcross(bY,bZ);
#declare yp  = vcross(bZ,bX);
#declare zp  = vcross(bX,bY);
#declare det = vdot(bX,xp);

#declare c11 = xp.x / det;
#declare c12 = yp.x / det;
#declare c13 = zp.x / det;
#declare c14 = 0;

#declare c21 = xp.y / det;
#declare c22 = yp.y / det;
#declare c23 = zp.y / det;
#declare c24 = 0;

#declare c31 = xp.z / det;
#declare c32 = yp.z / det;
#declare c33 = zp.z / det;
#declare c34 = 0;

#declare c41 = -vdot(xp,bC)/det;
#declare c42 = -vdot(yp,bC)/det;
#declare c43 = -vdot(zp,bC)/det;
#declare c44 = 1;

/////////////////////////////////

I checked the math on Mathematica, so it *should* be right.

You could look at this as some kind of matrix transform and lit it go
there, but maybe we can get some more understanding.

1) The new vectors xp,yp, and zp are the closest thing that the original
transformation could give you for an ordinary coordinate system.  (
because <1,0,0> is equal to vcross(<0,1,0>,<0,0,1>) ...)

2) det, which equals vdot(bX,vcross(bY,bZ)) is equal to the volume
inside the box with corners at 0, bX, bY, bZ, bX+bY, bX+bZ, bY+bZ and
bX+bY+bZ

3) the expressions for the c4x are similar to the amount of bC along
xp,yp,and zp

I hope this helps.

Ben
<><

Post a reply to this message

Ben Birdsey wrote:
> 
>         Here's a slightly different method which might be a little faster,
> since it uses intrinsically defined functions and pre-calculates more of
> the values.
> 
> Taking my cue from Rune, define
> 
> /////////////////////////////////
> 
> #declare bX = <1,-0.05,0>;
> #declare bY = <-0.5,0.5,0>;
> #declare bZ = <0,0,1>;
> #declare bC = <0,0,0>;
> 
> // The 16 statements to fill out the 16 elements of the inverse
> // New system devised by Ben Birdsey (12/31/00)
> 
> #declare xp  = vcross(bY,bZ);
> #declare yp  = vcross(bZ,bX);
> #declare zp  = vcross(bX,bY);
> #declare det = vdot(bX,xp);
> 
> #declare c11 = xp.x / det;
> #declare c12 = yp.x / det;
> #declare c13 = zp.x / det;
> #declare c14 = 0;
> 
> #declare c21 = xp.y / det;
> #declare c22 = yp.y / det;
> #declare c23 = zp.y / det;
> #declare c24 = 0;
> 
> #declare c31 = xp.z / det;
> #declare c32 = yp.z / det;
> #declare c33 = zp.z / det;
> #declare c34 = 0;
> 
> #declare c41 = -vdot(xp,bC)/det;
> #declare c42 = -vdot(yp,bC)/det;
> #declare c43 = -vdot(zp,bC)/det;
> #declare c44 = 1;

I haven't checked or tried your code, so I don't know if 
it does what it's supposed to do.


But if you are going for optimizations, then I THINK that 
doing it this way this will increase the parsing speed:

#declare bX = < 1.00, -0.05,  0.00>;
#declare bY = <-0.50,  0.50,  0.00>;
#declare bZ = < 0.00,  0.00,  1.00>;
#declare bC = < 0.00,  0.00,  0.00>;

#declare det = vdot(bX, vcross(bY, bZ));
#declare xp  = vcross(bY, bZ)/det;
#declare yp  = vcross(bZ, bX)/det;
#declare zp  = vcross(bX, bY)/det;

#declare c11 = xp.x;
#declare c12 = yp.x;
#declare c13 = zp.x;
#declare c14 = 0;

#declare c21 = xp.y;
#declare c22 = yp.y;
#declare c23 = zp.y;
#declare c24 = 0;

#declare c31 = xp.z;
#declare c32 = yp.z;
#declare c33 = zp.z;
#declare c34 = 0;

#declare c41 = -vdot(xp, bC);
#declare c42 = -vdot(yp, bC);
#declare c43 = -vdot(zp, bC);
#declare c44 = 1;


(Note that I haven't checked my modifications either.)


Regards,

Tor Olav
-- 
mailto:tor### [at] hotmailcom
http://www.crosswinds.net/~tok/tokrays.html

Post a reply to this message