My 3D camera..

Why don''t you put the camera at (0,0,0), NEAR at some small positive number, and FAR at some larger positive number.

Anything with any part behind NEAR (less than NEAR) is not in the view volume and is clipped or not rendered. NEAR is greater than zero because zero causes error for the perspective divide.

Technically, something between NEAR and the camera is visible but we clip it to NEAR to avoid the messy issue with zero.

Hi, you''re right, it was my oversight to set it up that way. putting the camera at origin is actually better.

I got the front clipping working now. The thing is, I still have to rotate each of my vertex data by the rotation and translation before I can do clipping.

I only save the perspective transform + render operation if I found out that the vertices are out of clipping plane.. So if I have 60,000 vertices I still have to multiply each vertex by my "transformation" matrix. Does that sound OK..?

This problem is what keeps 3d engines from going as fast as a video card would let them. Unless you have some kind of hardware transformation going on, processing 60,000 vertices a frame like that isn't going to go real-time. What you need to do is find a way to limit the set of triangles you have to work with per frame. That's where fun stuff like BSPs and Octrees and other occlusion methods come in.

Basically, you organize your triangles in a way that you can quickly find, in world coordinates(before you translate them according to the camera location), what triangles are possibly visible. Then you transform them, clip them, and finally, render them.

Jonathan

Edited by - Jonathan on July 10, 2000 6:58:32 PM

Hmm ok, I am aware there''s fun stuff like BSP trees out there.. But I guess I''m trying to ask, is it a common practice to "fake" your camera view by rotating your models around it, or is it better to rotate your camera around your model.. or does it all end up the same in the end.. sorry my mind is stuck.

You''ve got the rotation part right. Usually, people decide where they want their camera to be, and then rotate everything in the world by the inverse of that location, effectively placing the camera back at the origin. Then you draw from there.

Jonathan

Hey I can sympathise with the 3D camera problems. I''m only a little way into the huge subject of 3D, and the first brick wall I hit was the camera - it took me absolutely ages to figure out how to have an arbitrarily positioned and oriented camera!

TPH, I''m just starting to learn 3D now.
So what finally helped you out with the whole camera problem? Do you recall any sites or books or tutorials off the topof your head?

I can thoroughly recommend three books, in order of favourite:

"Advanced Animation and Rendering Techniques", Alan Watt (fact filled, gives me loads of ideas, sometimes difficult to understand - I have a poor math background)

"3D Computer Graphics", Alan Watt (this is nice and easy to read - explains stuff in a more understandable way)

"Computer Graphics, Principles and Practice" by Foley and others (no description necessary!)

The camera I am using basically has two points, one where the camera is, and one where the camera is looking at (focus). You can specify a rotation, which effectively tilts the camera, and you can alter the field-of-view. It's a nice method that's easy to control programmatically and from a user interface point of view.

I must confess I don't remember the exact details of how I implemented it - I'm at work at the moment! But if I recall correctly it is simply a case of building a matrix that combines all this data (plus a little extra later).

I'm quite happy to give further details if you want - it would have to wait until later when I get home though.

Oh yeah, I also found the DirectX 7.0 SDK very helpful. I'm not particularly interested in writing any DX stuff, at least not yet, but nevertheless it's pretty good.

I have found from experience that some material on the web is pretty good, but the majority of it is not (with the exception of GameDev.Net, Gamasutra and Flipcode!) Maybe I've been looking in the wrong places...

Later.

Edited by - TPH on July 12, 2000 12:11:54 PM

Thought I would post this - might be of some use, at least I hope it is.

Ok, please bear with me on this!
We need the following:

Point3D m_Cam; // camera position in world-space
Point3D m_Focus; // point that the camera looks at in world-space
Point3D m_Up; // the ''up'' vector
float m_FOV; // field-of-view, between 0 and PI
float m_Twist; // the tilt of the camera, in radians

To build the camera matrix (called Mtx in this example, which places objects in viewspace):

Point3D View;
Point3D * Up;
Point3D * Right;
Matrix TiltMtx;

View.x = m_Focus.x - m_Cam.x;
View.y = m_Focus.y - m_Cam.y;
View.z = m_Focus.z - m_Cam.z;

View.Normalise();

// deal with special case when the camera
// is looking either directly up or down
if (View.x == 0 && (View.y == 1 || View.y == -1) && View.z == 0)
Up = new Point3D(0, 0, -View.y);
else
Up = m_Up;

Right = CrossProduct(Up, &View);
Right.Normalise();
Up = CrossProduct(&View, Right);

// now for building the camera matrix
Mtx->E[0][0] = Right->x;
Mtx->E[0][1] = Up->x;
Mtx->E[0][2] = View.x;
Mtx->E[0][3] = 0.0;
Mtx->E[1][0] = Right->y;
Mtx->E[1][1] = Up->y;
Mtx->E[1][2] = View.y;
Mtx->E[1][3] = 0.0;
Mtx->E[2][0] = Right->z;
Mtx->E[2][1] = Up->z;
Mtx->E[2][2] = View.z;
Mtx->E[2][3] = 0.0;
Mtx->E[3][0] = -DotProduct(&m_Cam, Right);
Mtx->E[3][1] = -DotProduct(&m_Cam, Up);
Mtx->E[3][2] = -DotProduct(&m_Cam, &View);
Mtx->E[3][3] = 1.0;

// add the camera tilt
if (m_Twist != 0)
{
TiltMtx.RotateZ(m_Twist);
Mtx->Multiply(&TiltMtx);
}

And that''s about it really. Any suggestions for improvement - especially the special case - are very welcome. I''m not

concerned with optimising the code - I''m more interested in understanding the concepts at the moment.