The question nobody can answer (3D math)

Started by
22 comments, last by FeelEvil 22 years, 2 months ago
No, you are over complicating a very simple issue. The guy is working with a camera pos, and a lookat vec. He wants to move the camera along the lookat vector. The complete solution is...

assume D3DVECTOR pos is the camera position
assume D3DVECTOR lookat is the lookat vector

#include "d3dx8math.h" //for the D3DXVec2Normalize function

#define WALKSPEED 10.0f //the distance to move the camera
D3DVECTOR v; //temporary vector
D3DXVec2Normalize( &v, &lookat ); //normalise lookat
v=v*WALKSPEED; //turns your speed in to a vector pointing along the lookat
pos+=v;


There, that''s it. All done. Nothing more. No matrices, or any other nastiness.

ps. Can''t garantee I haven''t put any syntax errors in this, it hasn''t been lifted from existing working code.
Advertisement
last time, I promise... (I'm just REALLY surprised this has turned into an argument! I found the tone of your reply very surprising. So, I feel I must respond...)

The original question explicitly asks about matrices AND any transformation is ultimately a matrix. What am I missing here?

your way:

D3DXMATRIX matRotation;
D3DXMatrixRotationYawPitchRoll(&matRotation, CameraYRotation, CameraXRotation, CameraZRotation);
D3DXVECTOR3 vecDir(0.0f, 0.0f, Speed);
D3DXVECTOR3 vecCam;
D3DXVec3TransformCoord(&vecCam, &vecDir, &matRotation);
CameraXPos += vecCam.x;
CameraYPos += vecCam.y;
CameraZPos += vecCam.z;
//(Added because they are necessary if you actually want to draw anything)
D3DXMATRIX matTrans;
D3DXMatrixTranslate(&matTrans, CameraXPos, CameraYPos, CameraZPos);
pDevice->SetTransform(D3DTS_WORLD, &(matRotation * matTrans));


my way:

D3DXMATRIX matRotation;
D3DXMatrixRotationYawPitchRoll(&matRotation, CameraYRotation, CameraXRotation, CameraZRotation);
D3DXMATRIX matTrans;
D3DXMatrixTranslate(&matTrans, 0.0f, 0.0f, Distance);
pDevice->SetTransform(D3DTS_WORLD, &(matRotation * matTrans));

I'm overcomplicating this how exactly?

Please keep in mind - my way transforms the lookat/travel vector implicitly AND at the same time concatenates the final matrix before calling SetTransform. In your method, the call to D3DXVec3TransformCoord is added and unnecessary processing (given that you have to concatenate the matrix anyway). I would call that an overcomplication and added processing (= slower). If you feel I am on the wrong track, please explain with civility.

Please don't take this the wrong way - someone in another thread mentioned that I don't get into flame wars. I'm only pursuing this because I'm so bemused that this is an argument. You can avoid matrices for awhile, but eventually you end up inventing little twists and turns that make things harder than they have to be. In my mind at least, my way has less steps and therefore less to debug, less to mistype, and less to keep track of. Given that you have to end up with a matrix anyway, I'm really surprised you're fighting this.

Edited by - crazedgenius on January 19, 2002 11:00:31 PM
Author, "Real Time Rendering Tricks and Techniques in DirectX", "Focus on Curves and Surfaces", A third book on advanced lighting and materials
There''s no argument - you mentioned an argument in the first reply, that''s why I mentioned it. The original poster is the one that made mention of the matrices - not me. I think you''re taking this a little more serious than you should be

Let''s take an example to follow along:

You can safely discard the current position of the camera and deal with the rotation matrix that you already have. So, let''s say that the camera is pointed straight down (+1.57 radians along the X-Axis). Setup the rotation matrix:

D3DXMatrixRotationYawPitchRoll(&matRot, 0.0f, 1.57f, 0.0f);

Which comes out to the following matrix:

1.0 0.0 0.0 0.0
0.0 0.000796 1.0 0.0
0.0 -1.0 0.000796 0.0
0.0 0.0 0.0 1.0

Now, using your method, setup the translation matrix (to move forward +20.0f units):
D3DXMatrixTranslation(&matTrans, 0.0f, 0.0f, 20.0f);

No need to list the matrix, it''s empty except for row 4, which looks like this:

0.0 0.0 20.0 1.0

Multiply the two together (as you showed) you''ll get the following matrix:
1.0 0.0 0.0 0.0
0.0 0.000796 1.0 0.0
0.0 -1.0 0.000796 0.0
0.0 0.0 20.0 1.0

See the 4th row, 3rd column? That''s +20.0f in the z-axis, which is wrong. We''re looking for a direction downward along the negative y-axis.

Now, let''s look at my method. Setup the direction vector:

vecDir.x = vecDir.y = 0.0f;
vecDir.z = 20.0f;

Multiply the rotation matrix and vector to get the following translation values:
0.0 -19.99992 0.015925

That is the correct translation values to use for a camera pointing downward. If you don''t trust me, please by all means double check yourself.

Now, about the overcomplication, this method actually has way less multiplications in the process, with only a few more additions. That''s faster than the 4x4 multiplication you recommend.

To get back to FeelEvil, those calculations I listed worked, so I don''t know what might be wrong. Are you using the vectors as I showed in the first posting?

Jim Adams

To let everybody know regarding this thread - it will be closed. It seems to be shifting directions and before anything gets worse, I need to shut it down. Both parties have presented their views - let those that read it come to their own conclusions. If any further questions regarding the original topic is required, please start a new thread.

If you do not agree with this, please feel free to contract Dave or one of the other guys at GameDev.net and inform them of your thoughts.

Thanks!
Jim Adams

This topic is closed to new replies.

Advertisement