C++ Camera Class XNA Math Library

Started by
6 comments, last by Bimble Bob 13 years, 8 months ago
Does anyone know where I can find a good example of a c++ camera class(time based)that uses the XNA Math Library?

Thx ahead of time,
Jacob Jingle
Advertisement
There isn't a C++ version of XNA or it's maths classes available officially. I'm not sure whether you meant C# but here is my suggestion any way:

A simple camera system isn't that hard to make yourself. Assuming you want a 3D camera, you need a 3D position (Which you can store easily in a Vector3) and some way of describing the cameras orientation. I've used the method of storing the cameras local axis (Left, Up and Forward) for a camera system in the past but you can use a point (Again described by a 3D point stored in a Vector3) for the camera to look at or store euler angles that describe the cameras rotation around the world X, Y and Z axis.

Once you have that data you can create methods to manipulate it correctly using vector and matrix mathematics.

You can use any combination of those to produce a matrix that can be used for your 3D drawing.

The XNA maths classes is pretty self explanatory and it should be fairly easy to figure out which methods you need to use to do what. For example Matrix.CreateLookAt will construct a view matrix given an "eye" position, a point to look at and an up vector.
It's not a bug... it's a feature!
Quote:Original post by Dom_152
There isn't a C++ version of XNA or it's maths classes available officially. I'm not sure whether you meant C# but here is my suggestion any way:

A simple camera system isn't that hard to make yourself. Assuming you want a 3D camera, you need a 3D position (Which you can store easily in a Vector3) and some way of describing the cameras orientation. I've used the method of storing the cameras local axis (Left, Up and Forward) for a camera system in the past but you can use a point (Again described by a 3D point stored in a Vector3) for the camera to look at or store euler angles that describe the cameras rotation around the world X, Y and Z axis.

Once you have that data you can create methods to manipulate it correctly using vector and matrix mathematics.

You can use any combination of those to produce a matrix that can be used for your 3D drawing.

The XNA maths classes is pretty self explanatory and it should be fairly easy to figure out which methods you need to use to do what. For example Matrix.CreateLookAt will construct a view matrix given an "eye" position, a point to look at and an up vector.


The D3DX math library is renamed to the XNA Math Library and is completely written in C++ and SIMD instructions.

Just store the up, right and forward vectors and you have all the information you need to construct a camera matrix. You can also store the current roll, pitch and yaw so you can keep track of these and avoid gimbal lock (which is a thing that happens with matrix based cameras)

Also store the eyeposition in world space, this is not neccesarily needed but avoids a computation if you just wish to know where your camera is.

Another solution is to use Quaternions as they avoid the gimbal lock problem.

Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, theHunter, theHunter: Primal, Mad Max, Watch Dogs: Legion

There's a camera class I use in my samples that uses XNAMath. You can download this sample if you wanna have a look.
Quote:You can also store the current roll, pitch and yaw so you can keep track of these and avoid gimbal lock (which is a thing that happens with matrix based cameras)
Incorrect; gimbal lock is not a characteristic of matrix-based transforms.
Quote:Another solution is to use Quaternions as they avoid the gimbal lock problem.
Also incorrect; you can easily encounter gimbal lock when using quaternions.

There seems to be a lot of confusion regarding gimbal lock and the various ways of representing rotations. I won't go into detail here, but in short, gimbal lock can be encountered as the result of certain Euler-angle rotation sequences. The use of matrices and/or quaternions is an orthogonal, unrelated issue (that is, you can encounter gimbal lock, or successfully avoid it, with both matrices and quaternions).

Regarding camera representation, I personally wouldn't recommend the 'side, up, forward' representation for orientation. It's basically just a 'longhand' way of implementing a 3x3 matrix transform, and IMO it makes more sense to make use of the matrix functions that are already available (assuming you're using a decent math library, at least) rather than performing the operations 'by hand'.
Quote:Original post by jyk
Quote:You can also store the current roll, pitch and yaw so you can keep track of these and avoid gimbal lock (which is a thing that happens with matrix based cameras)
Incorrect; gimbal lock is not a characteristic of matrix-based transforms.
Quote:Another solution is to use Quaternions as they avoid the gimbal lock problem.
Also incorrect; you can easily encounter gimbal lock when using quaternions.

There seems to be a lot of confusion regarding gimbal lock and the various ways of representing rotations. I won't go into detail here, but in short, gimbal lock can be encountered as the result of certain Euler-angle rotation sequences. The use of matrices and/or quaternions is an orthogonal, unrelated issue (that is, you can encounter gimbal lock, or successfully avoid it, with both matrices and quaternions).

Wow, I always thought quaternions allowed you to avoid it. A matter of fact, I always thought that was the whole reason for using em.

If you don't mind, and not to divert this thread, but how do you avoid it for matrices?

Quote:Wow, I always thought quaternions allowed you to avoid it. A matter of fact, I always thought that was the whole reason for using em.
Nope.

I don't know where or how that particular misconception got started, but it's been repeated so many times now that many just assume it to be true :| (This thread being a case in point.)

But no, quaternions have no special characteristics with respect to gimbal lock. In fact, quaternions have exactly the same behavior with respect to gimbal lock that matrices do.
Quote:If you don't mind, and not to divert this thread, but how do you avoid it for matrices?
Exactly the same way as with quaternions: don't combine rotations in ways that may give rise to gimbal lock.
Quote:Original post by NightCreature83
Quote:Original post by Dom_152
There isn't a C++ version of XNA or it's maths classes available officially. I'm not sure whether you meant C# but here is my suggestion any way:

A simple camera system isn't that hard to make yourself. Assuming you want a 3D camera, you need a 3D position (Which you can store easily in a Vector3) and some way of describing the cameras orientation. I've used the method of storing the cameras local axis (Left, Up and Forward) for a camera system in the past but you can use a point (Again described by a 3D point stored in a Vector3) for the camera to look at or store euler angles that describe the cameras rotation around the world X, Y and Z axis.

Once you have that data you can create methods to manipulate it correctly using vector and matrix mathematics.

You can use any combination of those to produce a matrix that can be used for your 3D drawing.

The XNA maths classes is pretty self explanatory and it should be fairly easy to figure out which methods you need to use to do what. For example Matrix.CreateLookAt will construct a view matrix given an "eye" position, a point to look at and an up vector.


The D3DX math library is renamed to the XNA Math Library and is completely written in C++ and SIMD instructions.


Hehe, I always forget about D3DX! Thanks for pointing that out.

It's not a bug... it's a feature!

This topic is closed to new replies.

Advertisement