Archived

This topic is now archived and is closed to further replies.

Boops

3x3 to 4x4, is the step worth it? Any tips?

Recommended Posts

It has come to my attention in another post that using 3x3 matrices in a software engine might not be the best thing to do. I shall start with describing how I do this, then someone can at once see if that''s a good way . The camera has it''s own 3 vectors to describe it''s orientation, these can rotate, and then there''s the position of the camera (it''s 4th vector, cam.pos) that can move around. I then generate the perspective matrix of the camera (which I put inside the camera class as cam.persp) as follows: I put it''s 3 vectors in a 3x3 matrix, and then invert that matrix. (On many resources, they just transpose that matrix instead of inverting it, but I found that an annoying way to do it, since in my case it''s not always an orthonormal (or whatever it has to be) matrix, especially if I use a seperate FOV in x and y direction, which I have to do to support not 4:3 type screen resolutions.) Then, first I translate vertices by substracting cam.pos from them, and then multiply them by that 3x3 cam.persp matrix to bring it to viewspace, and then to project it on screen, I divide it by z. I make sure it''s in front of the near plane to avoid division by zero, I clip lines to that near plane, ..., got that all working . (around here I sometimes see someone say that dividing by z is a bad way to project, but what''s the good alternative? I''d be very pleased if someone could explain this.) Then I just need to turn that into pixel coordinates, and it''s done. This is working perfectly for me, but I''d first of all like to hear if that''s the "good" way to do it, and if it''s worth it to change it to 4x4 matrices. With my code, I get every weird camera working, including ones with different horizontal and vertical FOV (cam.u and cam.v vectors), zooming by changing FOV and/or changing the length of it''s direction vector, I can even SKEW it''s u and v vector to get a skewed view of the world. And the best of all, I can use that same camera for raytracing, also supporting this zooming and skewing (in my early tries, I had a bug where zooming in looked like zooming OUT in the projective part, and like zooming in for the raytracing, that was because I then took the transpose of the perspective matrix instead of it''s correct inverse). Will this all also work with 4x4 matrices? Is the code supposed to work FASTER with 4x4 matrices (since there''s more multiplication work then, not to talk about taking it''s inverse)? If that being faster is not the point of 4x4, what are the advantages then? Oh, and about quaternions... Is that yet another way to do it without using matrices? Thanks for your help!

Share this post


Link to post
Share on other sites
ive also written a software rasterizer and raytracer, and ive used 4x4 matrices in neither of them. first of all it seems to me that one row/collumn of the 4x4 matrix is always wasted. but more importantly: i just cant see the reason for putting two very seperate things, ie rotation and translation, in one datastructure. it makes about as much sense to me as putting texture information there aswell. the positionvector just doesnt seem like a natural part of a matrix to me, i just use a seperate position vector.
somehow all apis d use 4x4 matrices though, so youll have to use them when doing hardware stuff. im not thicksculled enough to think theres no reason for them making it so. but ive not yet figured out what that reason is though.

you perspective method seems fine to me btw. its the same thing i did basicly.

Share this post


Link to post
Share on other sites
Hi,

Some random thoughts:


The 4x4 matrix is a transformation matrix, and rotation, scaling and translation are all transformations, and are therefore related.

Also, it''s a lot simpler for the hardware to handle streams of 16 numbers in a pipeline, than it is to do the translation separately.

Its a lot easier to implement the matrix stack if you only have one data type to take care of.

The order of these operations is important, and if you want to keep track of it, you can do so easily with a 4x4.

You can invert any 4x4 operation very simply.


Worth it or not? It''s really up to you to decide.

cheers,
-theoddbot

Share this post


Link to post
Share on other sites
quote:
Original post by Eelco
i just cant see the reason for putting two very seperate things, ie rotation and translation, in one datastructure.
Keeping them together allows you to concatenate a bunch of transforms, allowing you to represent them all as a single matrix. This allows you to transform individual vertices in a "single" operation instead of having to calculate and keep track of intermediate vertex positions. You could easily represent a transformation with the form R1*T1*R2 using a single 4d matrix (M = R1*T1*R2), but you couldn't do that with a single rotation matrix / translation vector pair.

[edited by - chronos on November 16, 2003 12:47:17 PM]

Share this post


Link to post
Share on other sites
Note about edited post: I originally compared M = R1*T1*R2 to the rotation of the moon, but that''s not correct, since that may be represented as a translation and rotation. The rest should be correct, however. I have edited the post to correct this mistake.

Share this post


Link to post
Share on other sites
quote:
Original post by Eelco
i just cant see the reason for putting two very seperate things, ie rotation and translation, in one datastructure.

The names ''rotation'' and ''translation'' are just special cases of what matrices actually represent: transformation from one coordinate system to another.

By using 4x4 matrices you have a generic, all purpose structure that doesn''t generate a whole load of special case code.

Share this post


Link to post
Share on other sites