Good afternoon folks, I have a general question I'd like to pose. As I do more and more with moving my 3D shapes around in DirectX, I'm beginning to think about the actual state of my game. Specifically, I'm wondering about spacial state. How is this usually maintained? I would guess that there are Objects which represent the various actors and items in the world. These Objects might have members that hold position, orientation, and tons of other non-spacial state too. But in terms of the spacial state, I wonder this: If I'm already maintaining structures that will allow me to move the meshes of my world entities in Direct3D( vecotrs, matrices, etc ), is it prudent to simply read and write from those structures when doing NON-render calcuations? Should I keep around generic "x", "z", "z" members and such when I could just peep into my translation matrix? Is it better to keep the graphics state seperate ( so I could draw things in relative coordinates, rather than absolute), or to use it as spacial state for all aspects of a game? I'd love to hear some seasoned advice from someone who has been through this organization proccess. Thanks for reading =) Mike

Hi there Michael,

This is what Ive done...

I have a Graphics Entity Base class, all graphics entities are derived from this, the purpose of which is that I can keep a list of all the graphics entities in a scene manager, this can automatically handle the rendering of the entities by there Render( D3DXMATRIX& ) function (which isn't actually done but u'll see why later), which every entity must have because its a pure virtual function in the graphics entity base class.

Then I have a Graphics Instance Base Class, a graphics instance points to a Graphics Entity, so that I can have multiple references to the same object (eg, 5 DirectX tigers). This base class contains two vital features, a pointer to a World Instance Base Class, and a virtual Render() function. The World Instance Base Class basically contains two D3DXVECTOR3 (rotation and position).

So each Graphics Instance has a pointer to a Graphics Entity, and a World Entity. So in a Graphics Instance we do a call to our World Instance to get our render matrix, and this gets passed to the instances Graphics Entity render function.

Now I also have a SceneInstanceManager which stores a big long list of all our Graphics Instances, this will loop through and Render each one each frame.


Hopefully thats not to confusing, seems to be working quite nicely for me.





Richard.

Personally, I dislike entity designs that keep around a transformation matrix. It's not the natural representation for the data, it's a convenience for the graphics layer. Keep around a 3-element vector for the position, and a quaternion for the rotation, and convert to a transformation matrix when you need it. Direct3D should be a secondary consideration; what your entities basically ARE, are objects in your game world, not meshes on the screen.

OH MY LORD.

After reading Sneftel's post about maintaining more natural data, I stopped for a moment.

"What's a quaternion?" I wondered.

It was then that I embarked on a remarkable voayage of 'WTF'. Holy crap there is a lot on these things out there. I have read through two descriptions and I still don't understand how to use them. I even ended up knee deep in the Gruber article. Urrrrrg. I'll keep sloggin tho :(

You don't reeeeally need to maintain quaternions, if your entities aren't going to be doing free rotation. (For instance, it might be overkill for a FPS.) In this case, substitute "a set of euler angles" for "a quaternion".

I do understand where you lose orientation with Euler's angles though. So I'm guessing that quaternions ( by whatever magic they work ) somehow maintain the equivalent of a 'view-up' vector in addition to the directional vector? And all in 4 floats? And all this can be converted into matrices which will reposition your shapes with their 'view-up's as you rotated them ( even if you rotated right on the axis ) ? Hoo hah.

So at the risk of using something I don't quite understand... are there DirectX functions to translate to and from quaternions via matrices?

>.<

Indeed there are. DirectX is all about "use quaternions without fully grasping the mathematical theory underlying them". As are most game developers. It's a natural synergy. Still, if you want to BLOW YOUR FREAKING MIND about how cool quaternions are, Google for "quaternions" and "belt trick".

In defense of the transformation matrix, it is nice to be able to have the "facing" "up" and "side" directions already calculated. Sure in game code these could also be simple accessors that are computed per-call from the quaternion. But still, while debugging it's nice to just have those orientation numbers right there.

The main weakness I've found with quaternions is there's no way to tell just by looking at the numbers what orientation it represents. You have to convert to matrix to determine that :)

^^^ Totally. Matrices can easily be visualised as a little xyz origin floating around in world-space. Quaternions on the other hand ... the most "intuitive" description I've heard was something like "finding the shortest surface path between two points on a 4D hypersphere" o___O;;;

All you really need to know about quaternions is that they're are a convenient form for manipulating orientations. AFAIK that's solely because interpolating between quats is smoother and more visually pleasing than interpolating between matrices/Euler angles sets.

Quaternions are actually really easy to intuit in the debugger. The XYZ part of it, basically, is your axis of rotation, and the W part grows and shrinks with sin(angle/2). Particularly if you know by heart what sin(45) is, it's really simple to see what rotation is set.

If you really care, though, it's trivial to set a watch in the debugger which will tell you your side, top, and front vectors; the side vector, for example, is just q * vec(1,0,0) * q-1.