Camera::SetView() explanation

subdigital · Oct 5th 2005, 11:21pm

I've been converting a lot of the scene structure into C# with Managed DirectX.

I was wondering if someone could help me understand what's going on in the SetView method of the Camera class on page 517.

I understand what the idea is, get the matrix of the target node, sit somewhere behind it and set that as the current view matrix, but the source code is bugging me:

vec4 at = g_Forward4 * -10.0f;

what is this line doing? where is that global variable defined, I cannot find it.

then there's a call to VSetTransform(&mat); but I don't see this function defined anywhere.

Anyway, great book, thanks in advance for any help!

Kain · Oct 6th 2005, 8:16pm

In the sample code provided on this website, you'll find these lines in GameCodeStd.cpp:

Source Code

Vec3 g_Right(1.0f, 0.0, 0.0f);
Vec3 g_Up(0.0f, 1.0f, 0.0f);
Vec3 g_Forward(0.0f, 0.0f, 1.0f);
Vec4 g_Up4(g_Up.x, g_Up.y, g_Up.z, 0.0f);
Vec4 g_Right4(g_Right.x, g_Right.y, g_Right.z, 0.0f);
Vec4 g_Forward4(g_Forward.x, g_Forward.y, g_Forward.z, 0.0f);

That line where "vec4 at" is set to "g_Forward4 * -10.0f" is basically saying that the camera will be 10 units behind the target. If you don't specify the -10, then you get a camera right at the root of the target... which is kind of like trying to see the inside of your eyeball.

SceneNode::VSetTransform is defined in SceneNodes.cpp.

subdigital · Oct 7th 2005, 2:35pm

Thanks for the reply. I figured, based on the name that the vector was (0,0,1) but wasn't positive. Why would that even be a global variable? Wouldn't that just be common knowledge? Or would you want to change your "forward" direction at some point?

Moving on...

If you multiply that by -10, you get:

(0,0,-10) cool so far.

Then the next step is to Translate the targetNode's FromWorld Matrix by that vector above, right? The result becomes my camera's matrix, and I set that to the current transform... is this correct?

Also, I tend to think a LOT better in terms of Vectors, not Matrices... is there a reason that Mike chose these as over a more coherent Vec3 for position, rotate, scaling, etc. ??

TIA.

Kain · Oct 7th 2005, 7:11pm

Some people define up as positive Z and others define up as positive Y, so that's why that was made a variable instead of a hard number... it could arguably be better off as a #define, maybe.

Then the next step is to Translate the targetNode's FromWorld Matrix by that vector above, right? The result becomes my camera's matrix, and I set that to the current transform... is this correct?

I think that's correct.

Also, I tend to think a LOT better in terms of Vectors, not Matrices... is there a reason that Mike chose these as over a more coherent Vec3 for position, rotate, scaling, etc. ??

I think the reason was that he wrote that code under a lot of time pressure, or maybe he wanted as little abstraction as possible for educational purposes. Lots of 3D engines will use functions that conveniently take vector arguments instead of matrices, but in the end, it's all matrices under the hood.

That's a good item for a future rev of the source code: work in vectors as much as possible.

Nebuchadnezzar · Oct 8th 2005, 7:14pm

Hey, just a little point of interest:

The matrices are just collections of vectors in an instance like this. Don't let it shake you, it's just faster to pass one matrix than to pass three vectors, and it can look cleaner, too.

So Mat3 (and Mat4) look like this:

x-vector X, Y, Z (, W)
y-vector X, Y, Z (, W)
z-vector X, Y, Z (, W)
(W, W, W, W)

for DirectX (I think) and transpose that for OpenGL. I may have that backwards....

Now back to our irregularly scheduled mischief....

Source Code

Share