Camera code problems..

not that this will fix it, but the aspect ratio should be more like 1.333 (1024 / 768 or whatever you resolution is, most have a 4/3 ratio)

Okay, for the Aspect Ratio...it should be

rtCamera.fAspect = XRES / YRES;

Or whatever the backbuffer width and height are. It''s a good idea to store them. Because if you are windowed mode, you can''t be sure of what the width and height of your buffer is. That will make things like cubes more square like and spheres more like circles instead of the ellipse and stuff.

Anyway, what do you mean your clip planes aren''t computed easily? To me it looks like you aren''t computing any clipping planes...it automatically does that when you set up the VIEW and PROJECTION matrices...unless you need additional clipping planes.

Are you having problems with objects being clipped too close or far away? What are your rtCamera.fNear and fFar values? What about the rtCamera.fFov? A nice value to use for FOV is D3DX_PI/4. Yeah, that''s nice.

The tutorials that come with the SDK documentation seem to work somewhat well. Tutorial number 3 is about using Matrices, which includes setting up the camera and stuff.

Heh, camera stuff for a real game can be a pain. Good luck.

~Aeroum
www.aeroum.com

Cool, thanks for your reply. fFar and fNear is obvious that are they near and far clipping planes, no?

for Fov, i use d3dx_pi/4 yes, it is good. About the Up vector.. For making a 6DOF camera, should I change it or keep it always at vec3(0,1,0)? what would happen if i change the up vector and when do i need to change it?

Well, actually I meant ''what were the near and far values you were using?''

If you want all the degrees of freedom. It is necessary to change the camera''s up vector. If you wanted everything on its side, like the direction ''right'' would be up, you would of course make it 1,0,0 and everything be rotated 90 degrees, or ''roll''ed.

Now if you keep the up vector at 0,1,0 always, you''ll have some problems even if you don''t want that freedom. Like if the At object is at 0,0,0 and the Eye, or camera is at 0, 10, 0. Then with the standard up vector all of the sudden, everything disappears, and that''s really bad, and sometimes hard to debug. But you could fix it by making the up vector 0,0,1. Then it could be looking down and it''d work correctly (with up being the along the z axis).

Besides those problems, until you''re really familiar with the camera operations or whatever, I''d recommend keeping the up vector 0,1,0. But in the future, you would want to change it if you want to look up or down, or roll (like tilt).

You may also want to create your own matrix instead of using D3DXMatrixLookAtLH() in the future. If you want to see how that works. The source for that function in the SDK is (for DirectX 8.0)
DirectX 8.0 - DirectX Graphics - Understanding DirectX Graphics - Direct3D Rendering Pipeline - Fixed Function Vertex and Pixel Processing - Transformation and Lighting Engine - The View Matrix - Setting Up A View Matrix

That shows how the matrix is actually built.

Aeroum

Ohhhh, my near and far are 0.1f and 1000.0f respectively.

Is there a way to automaticcaly calculate the up vector from the view matrix? So I wont have to manually set it everytime I change the lookat?

The problem you mentioned about the 0,10,0 lookat point and everything disappears, I have noticed it, yes.

Not sure about automatically calculating the up vector from the view matrix. I''d just set it to 0,1,0 until you find if/how you want it to be different.

Aeroum

Ok, I will use that and post my problems, if any, later!
Cya

In response to Aeorum. If you are at 0, 10, 0 and you object is at 0, 0, 0, and you have a first person camera (we''ll even assume without collision detection), then you are over the object, and if you have it capped, you probably don''t wish for it to move that far anyways. I always cap mine to one radian up or down, so I can''t see where with a normal first person style cam (unless you want a descent style camera or something), that that would even become a problem, as most people cap their rotations.