I think I was asking the wrong question before when I was asking about camera rotation. I really need to know the basic set up between a camera and an object. I have one set up, but the camera does not rotate right, and every fix, while rotating the camera correct, does not create the right eyespace matrix for the objects. So somewhere im making a simple, yet fundamental, error in my setup. Right now I use standard matrix rotation forumlas and 4x4 matrixs, useing a x*fov/z drawing formula. eyespace matrix = object matrix * camera matrix there are many issues that go on involving the vector coords and such of the matrix, wether they are rows or columns, how it effects the eyespace matrix, what rotates around what etc. Long story short my method is not working right (camera rotating around origin) and I think its something fundamental...anyone who has made an engine that works please let me know the basic set up of how you got the camera to have eveerything rotate around it when the camera rotates, thanks.

How can you expect us to help if you don''t show us the matrices used?

matrix template I use for camera and objects:

xx yx zx wx
xy yy zy wy
xz yz zz wz
tx ty tz w

or in practice:

1 0 0 234
0 1 0 34
0 0 1 453
0 0 0 1

for a translated camera/cube/whatever

The reason why i didn't post my own stuff was that I feel im doing something fundamentaly wrong and m not trrying to fix it so much as start over, but I guess it narrows down what im messing up on.

so basically if I hit the arrow keys or move the mouse it translates or rotates the camera respectivly:

void translate(double mx, double my, double mz)//move matrix's origin { matrix[3][0] += mx; matrix[3][1] += my; matrix[3][2] += mz; }void rotate(double thetax, double thetay, double thetaz)//rotate matrix axis { rx[1][1] = cos(thetax);//build x rot matrix rx[1][2] = sin(thetax); rx[2][1] = -sin(thetax); rx[2][2] = cos(thetax); ry[0][0] = cos(thetay);//build y rot matrix ry[0][2] = -sin(thetay); ry[2][0] = sin(thetay); ry[2][2] = cos(thetay); rz[0][0] = cos(thetaz);//build z rot matrix rz[0][1] = sin(thetaz); rz[1][0] = sin(-thetaz); rz[1][1] = cos(thetaz); //multiply matmult(&matrix[0][0], ℞[0][0]); matmult(&matrix[0][0], &ry[0][0]); matmult(&matrix[0][0], &rz[0][0]); }

These are from my camera class. They are identical to my object classes except my object classes have one additional function I call before I draw them, transform:

void transform(camera cam)//calculate values for new axis for omatrix { int i; instmatrix(&ematrix[0][0]);//set ematrix to identity matmult(&ematrix[0][0], &omatrix[0][0]);//copy omatrix to ematrix matmult(&ematrix[0][0], &cam.matrix[0][0]);//create eyespace matrix from camera matrix for(i = 0; i < 8; i ++)//calculate values for points based on ematrix { p[i][0] = po[i][0] * ematrix[0][0] + po[i][1] * ematrix[0][1] + po[i][2] * ematrix[0][2]; p[i][1] = po[i][0] * ematrix[1][0] + po[i][1] * ematrix[1][1] + po[i][2] * ematrix[1][2]; p[i][2] = po[i][0] * ematrix[2][0] + po[i][1] * ematrix[2][1] + po[i][2] * ematrix[2][2]; } }

Basically right now when i rotate the camera, it rotates around the origin, but most the rest works right. I can pin it in place or move the camera to 000 for rotating, but that does not yield the correct perspective afterwards. Objects I look at just spin in place.



Edited by - Striker222 on January 3, 2002 2:19:15 PM

matmult(&matrix[0][0], &rx[0][0]);

is completely equal to

matmult( matrix, rx );


looks a lot better, doesn''t it?

matmult(&matrix[0][0], ℞[0][0]);

is completely equal to

matmult( matrix, rx );


looks a lot better, doesn''t it?

You are wrong
matmult( matrix, rx );
is equivalent to
matmult( &matrix[0], ℞[0] );

the addresses of
matrix[0] and matrix[0][0] are the same,
that is &matrix[0] == &matrix[0][0]
but they are different types of pointers, not good practice to
write matmult( matrix, rx );
you could write matmult(matrix[0], rx[0]);

Show us everything about the simplest situation that doesn''t work right, like only one triangle, show us how it does not coincide with the code, most importantly be clear not brief

Well, gladly

heres my source and the executable:
point and click and drag to rotate camera around origin(what im trying to fix) and use arrow keys...

Source + EXE


The reason I didn't post this before was that I highly doubled anyone wanted to wade through my source, also, im not so much trying to fix what I have here... I am trying to start over in a more correct fashion, so either a link to a guide taylored to this situation or someones advice basically.


That being said, ill sumerize my whole engine since i doubt anyone is gona get my source unless they want to copy it or something, which is fine whatever.

Right now I have a class for a cube, and a camera. The cube has rotate functions(see above) translate functions (see above) and transform functions (see above)
I call a translate or rotate as the key input is needed, then I call the transform at the end of a game loop, and then I call the draw. Rasterization isn't important at this point though.(I use x*focus/z btw)

The camera has rotate and translate, which are done on input from keyboard/mouse. (see above)

Right now, my camera rotates around the origin, not itself. And though I can hack it to rotate around it self(move to origin, rotate, move back) it doesn't get the right perspective on objects, they just spin in place when I rotate the camera.

I need to set up the engine so the objects rotate around the camera, and the camera rotates around the camera. Right now both rotate around the origin. I cannot figure out a way to keep the camera at the origin while still keeping the correct perspective.

Thats why im asking for the basic outline of an engine someone has made (the steps, none of the accual code is needed I don't think)


Perhaps something about subtracting the camera coords from the objects, since that would do something like making the camera the relative origin, or something like that. Then perhaps putting their coordinates back. Howeveer whenever I try hacks like that I always end of getting the wrong perspective...but i'm asking you guys for help on that


EDIT: I'm a html newb and my first post was not very helpfull.

Edited by - Striker222 on January 4, 2002 4:53:17 AM

Edited by - Striker222 on January 4, 2002 4:58:21 AM

One thing is that you need to think in terms of seperate coordinate spaces. You generally have at least a view and model coordinate space. The camera is at the origin of view space, points down the positive z axis of view space and the positive y axis is its up vector. The screeen plane is then z=near or z=fov as you use fov. Model space has a position, orientation and scale within view space. To render you have to convert model coordinates to view coordinates. If you "move" the camera you have to move all the models in view space. Rather than doing that you define a third coordinate space, i.e. world space, and define the positions of the models relative to world space. Now to move all the models you just have to move the world. It is no less work since all the model vertices have to be transformed either way, but it is easier conceptually.

So you have view, world and model space. That is three origins. When you render you transfom model to world and world to view. So those are the transforms you store. You might have additional transforms if for example you use animations or assemblies. Overall you are just trying to get a frame of referance that makes everything easy. It may be easiest to visualize the camera moving through the world, but your transform is world to view not view to world so the world is moving through the view. Any "movement" to the camera has to be done through modification of the world to view transform. With a model it is a little easier because you naturally think of the model moving through the world. So you translate, rotate and scale the model. It is a little less intuitive that you translate, rotate and scale the world. So if you want the camera at (cx,cy,cz) in the world then you have to position the world at (-cx,-cy,-cz) in the view assuming no rotation and scaling.

You can build a transform matrix to move the camera within the world. It may be easier to visualize that way. You then have to calculate the inverse of the that matrix and apply it to the world to view transform. Now as far as ordering if your axes are rows then you multiply the transform by a column vector. If they are columns then you multiply a row vector by the transform. I believe you concatenate transforms on the opposite end of from the vector. So a scaling S followed by rotation R and then translation T of vector V would be either TRSV or VSRT. It is an important little detail that many books seem to gloss over.

Thanks again, LilBudyWizer.

Right now I have world coordinates of objects that DO NOT change unless they are supposed to(like an impulse or whatveer) but they go to their correct positions (for viewing) when the camera matrix is applied to the world position matrix of the objects. I think I have that part down solid...

However, when you said "inverse" you got my attention. I have not implimented an inverse in any way shape or form (in fact i don''t know how, ill read up on that tonight) perhaps thats what I am missing?

The main guide I have been useing says
o = t*rx*ry*rz
and
e = o * c

o = object matrix = world positoin
e = eyespace = relative position (for drawing)
c = camera

I assume

matmult(&matrix[0][0], &t[0][0]); matmult(&matrix[0][0], ℞[0][0]); matmult(&matrix[0][0], &ry[0][0]); matmult(&matrix[0][0], &rz[0][0]);

would be the same as
o = t*rx*ry*rz

So yeah, i''ll look into inverses.