#### Archived

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

# D3D8 camera/matrix question

This topic is 5975 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I have been using DX8 for a bit, but I have run into a bit of a problem lately. I have been using D3DXMatrixLookAtLH() for my camera type thing. I manually change the position and lookat point so get a first person perspective type view. Now today someone told me that manually editing the points in that manner is a REAL bad thing. So I thought to myself, if I could generate a matrix that rotates and use another matrix for the translation. Now that is supposed to be a better. But the question is: how exactly do I do it? Has anyone here done anything like this before, and if so, how should I do it?

##### Share on other sites
I''m not sure if it''s a REALLY BAD THING, except for the fact that it might be more work than just rotating/translating. I''m not sure if it would make a drastic performance difference, unless you''re computing everything very inefficiently. If you want to just build a "normal" view matrix, look at the samples, there should be plenty of code there...

##### Share on other sites
This is my source for the transformations. You have two float[3] array that you must pass to the function, one containing the positions of the viewpoint, the other one contains the angles. Fov is the field of view (which defaults to 0.7853981635f = PI/4) that gives you the possibility to zoom.

  void Renderer::Set3DTransformations(float *viewangles, float *position, float fov) { D3DXMATRIX matProj, matView, matWorld, rx, ry, rz, t, temp, temp2; D3DXMatrixIdentity( &matWorld ); m_pd3dDevice->SetTransform( D3DTS_WORLD, &matWorld ); D3DXMatrixRotationX( &rx, viewangles[1] ); D3DXMatrixRotationY( &ry, viewangles[0] ); D3DXMatrixRotationZ( &rz, viewangles[2] ); D3DXMatrixTranslation( &t, -position[0], -position[1], -position[2] ); D3DXMatrixMultiply( &temp, &t, &ry); D3DXMatrixMultiply( &temp2, &temp, &rx); D3DXMatrixMultiply( &matView, &temp2, &rz); m_pd3dDevice->SetTransform( D3DTS_VIEW, &matView ); D3DXMatrixPerspectiveFovLH( &matProj, fov, 1.0f, 0.001f, 100.0f ); m_pd3dDevice->SetTransform( D3DTS_PROJECTION, &matProj );}

But generally I would say that it doesn''t matter much which version you use, as long as you don''t need to recalculate the LookAt-Point each frame and then have no other use for it. It won''t slow you program down much, but it is not optimal though.

Hope I could help.

##### Share on other sites
Using a utillity rutine to calculate the Perspective Matrix
will never have any serious impact on your performance.

Think of it this way:

there are two possible ways of getting the Perspective Matrix

1. Use the utillity rutine provided by the API
2. Optimize it and do it with fever calculations

Lets just say that(fictional numbers, they are here just to illustrate my point)

1. Uses 4 matrix mults
X-rotation,
Y-rotation,
Z-rotation,
translation
This leaves us with 4 * 16 * 3 = 192 mults

Now lets just say that there an awful lot of other stuff inside the util rutine, so we round up, just for the sake of it, to 1000 mults.

2. you are hardcore at x86 and can optimize
all the above to 0 matrix mults and only 32 mults.

Now, its quite a big difference, but its also damn hard to get there.

Now the result of both would be a 4x4 matrix.

Lets say you have a scene consisting of 5000 triangles,
not sharing any vertices.
this makes 15000 vertices.

Each of these vertices _MUST_ be multiplied by the 4x4 matrix
the cost of this operation must be 16 mults
now if you multiply the numbers
we are now talking about 15000*16=240.000 mults!!!

Can you see where I''m heading?
The overhead for calculating the matrix is _VERY_ insignificant.
Even for the example where i exaggerated the numbers, drawed a pretty low-poly scene, one could see that the overhead of using the utility rutine would be ridicously small.

Its all about the 80-20 rule, which says that 80 percent of the time is spent in 20 percent of the code.
And one would think that when coding graphics its more like a 90-10 rule.

What one must realise is that the setup for the view matrix is _NEVER_ part of the 20 critical percent of the code.

##### Share on other sites
So re-calculating the lookat point like I have been doing is a pretty bad thing? One other problem with using matrices is that it might be a bit more difficult for something like a quadtree because you don''t have a direct player position and lookat point.

I am still a little fuzzy on what I should do exactly. Probably part of that is that the only thing I have ever used is that nice D3DX function.

##### Share on other sites
Moe,

Could you check out my post regarding the D3DXMatrixLookAtLH(). I can''t get it to work properly.

Thanks.
Mark Robinson.

##### Share on other sites
Well, I am not sure if that helped too much .

I have been talking with a few other people and they seem to think that using D3DXMatrixLookAtLH() is an ok idea. What I was thinking of doing with the matrix stuff is to calculate the amount of rotation of the camera (like I was before), then multiply it into the transform somehow. I also like what I am doing because I have a camera position and it might make things easier for a quad-tree or octree.

Any other thoughts/opinions on the subject?

Edited by - Moe on September 14, 2001 5:58:08 PM