Solution to former XSpace problem

[VirtualAce]

You guys remember when I had the laser problems with XSpace?

Well I was reading Game Coding Complete, 2nd ed., and came across two things that stuck in my mind.

1. I was not using 4x4 matrices to represent rotation and
translation. I've written software 3D systems and they all used 4x4 matrices so I dunno why I was using D3DXVec3TransformCoord().
2. I was using D3DXMatrixLookAtLH() which does not work for straight up and straight down.


Also given I've had more experience now with vectors I believe this might work as well.

To fire a laser in the direction the ship is travelling, take the cross product of the up vector and the right vector. This will create a vector perpendicular to those two vectors, which form a plane in themselves. My question is, which direction will the cross product vector point?

Also I'm totally scrapping Euler angles. I've had enough of them and I'm moving to quaternions. I don't fully understand how they work but most of the math is already done anyways. It will make rotating guns to face targets, ships to face other ships, etc, etc...much much easier.

Another question:

What's the difference between these two?

D3DXMATRIX matResult,mat1,mat2;

matResult=mat1*mat2;

D3DXMATRIX matResult,mat1,mat2;

D3DXMatrixMultiply(&matResult,&mat1,&mat2);

[BobMcGee123]

>>I was using D3DXMatrixLookAtLH() which does not work for straight up and straight down.

I'm guessing this is similar to gluLookAt in which the 'up' vector cannot ever be mapped onto the 'view' vector, i.e., when you rotate the view you must also rotate the 'up' vector instead of it always being (0,1,0). If you are still going to write a space travel game, you either need to rotate the 'up' vector along with the other vectors, or you need to store the orientation differently (i.e. perhaps with a quaternion).

Here's the OpenGL equivalent
The up vector must not be parallel to the line of sight from the eye to the reference point.



>>To fire a laser in the direction the ship is travelling, take the cross product of the up vector and the right vector. This will create a vector perpendicular to those two vectors, which form a plane in themselves. My question is, which direction will the cross product vector point?

This should be the vector you want, the 'view' or 'forward' vector

Put your hand out like you are going to shake somebody's hand, but make your thumb stick straight up,

hand cross palm points in the direction of thumb (your hand is pointing 'forward', palm means the line perpendicular to your palm).

in this picture, 'B' is hand, 'V' is thumb, 'F' is palm
http://www.physics.brocku.ca/www/fac...ges/f21007.jpg




>>Also I'm totally scrapping Euler angles. I've had enough of them and I'm moving to quaternions. I don't fully understand how they work but most of the math is already done anyways. It will make rotating guns to face targets, ships to face other ships, etc, etc...much much easier.

I've got a pretty full quaternion class...it's mostly derived from stuff I've found online and in books. As much as I've tried to understand them, I ultimately just use code that I more-or-less copied. But you are right, quaternions make all of the tasks you mentioned much, much easier.



>>What's the difference between these two?

According to MSDN they're the same thing

http://msdn.microsoft.com/library/de...IXmultiply.asp

[VirtualAce]

My problem with the lasers before was orienting them to face down the positive z axis. However I could have solved this by creating the quads facing down the z axis in model/local space instead of re-orienting them every time which just wastes cycles.

At the current time I'm reading Game Coding Complete, 2nd edition which is giving me a lot of insight for engine design. He states that you probably won't ever write your own engine but I would say that is an understatement since most of us probably do know enough code and/or 3D math to do just that. Quality is not limited by the code, but by the art, resources, modellers, etc., etc. which we as indies do not have easy access to. I'm a programmer and as such I can do a little of my own art, but for models, voices, sound effects, etc, etc........I pretty much suck.

I will admit that getting all of the stuff working together in harmony is a tad difficult but I would not go so far as to say you cannot roll your own engine. Personally I'm finding the creation of the data (textures, models, etc, etc) to be far more complex than actually coding the engine.

Are you using interfaces in your code? I'm also going to purchase a book on design patterns from amazon to research this a bit more. I like the idea of using interfaces as a template for what the class that inherits from it should use. It's also easy to place the interface into a DLL and thereby you can keep your engine code in DLLs and just load them when needed.

I believe I'm at the point I can handle

• Collisions
• Intermediate to advanced physics response
• Scripting and events
• Resource management
• Scene graph based rendering
• Render layers/passes
• Shader programming/implementation
• Texture-based animation
• Model-based animation
• Special effects
• Audio/Audio syncing
• Music
• Input
• Serialization of game data
• Custom file formats
• Memory mapped file I/O (if needed)
• Custom memory management

Now to put all of this knowledge together to create the final product. But I still cannot do models for the life of me. I suck at drawing them in any 3D modelling program.

How are you doing with your game?

EDIT: Nevermind I read your blog.

Are you using this for springs?

F=k(R-L)

F=Force
k=coeffiecient for spring
R=compressed length
L=total length

Also I have some quaternion to matrix code if you need it but you will have to alter it for OpenGL matrices. I think you already got billboards working but lighthouse has a good article on this.

Billboards - http://www.lighthouse3d.com/opengl/billboarding/

Lighthouse tutorials -
http://www.lighthouse3d.com/opengl/tutorials.shtml

[BobMcGee123]

>>Are you using interfaces in your code?

Meh, depends who you ask. I've got two 'sections' in my workspace: the 'engine' folder and the 'game' folder...there is an export class which holds pointers to some functions (i.e what function you want to call to update the game), but otherwise I don't really have an interface. I may, eventually, put the engine part into DLLs, but it really isn't a priority.


>>How are you doing with your game?

Really good, actually. Last night I just a working prototype of how the air cusions underneath the hovertank will operate. It is a very difficult process to get it to actually stabalize...each frame I have to trace from the thruster position down to the ground and determine the distance to the ground...it uses this to calculate a compression factor, and each thruster behaves, mathematically speaking, like a spring. It also dampens the springs, meaning it goes a second step and tries reducing the velocity between the thruster position and the point of impact (so that the hovertank can actually come to rest instead of bobbing up and down). It works great, especially when the little hovertanks go up an incline: the front planes upwards just as you'd think it would.

I was quite surprised I was able to get that aspect of it working so quickly.

When I get home I think I will take a movie with fraps and show it off a little bit.

EDIT:

Are you using this for springs?

F=k(R-L)

F=Force
k=coeffiecient for spring
R=compressed length
L=total length

Yeah, that's the first part...you get the force that arises from compression. Then, the second part is to dampen the spring, which acts against the force from the equations you posted

F_dampen = k (RelVelocity)
k = coefficient for velocity

RelVelocity = relative velocity between spring and ground (which arises from both linear and angular momentum)

and F_dampen works against F. I'm not at home right now but I can post code and ideally a video. If you didn't dampen the spring, and you just had the hovertank fall onto a totally flat surface it would just bounce back up to its original height and never settle.

>>Also I have some quaternion to matrix code if you need it but you will have to alter it for OpenGL matrices. I think you already got billboards working but lighthouse has a good article on this.

Yes I do have that implemented but thank you for the links anyway

[skorman00]

Also I'm totally scrapping Euler angles. I've had enough of them and I'm moving to quaternions

I like that line, it made me laugh. Not that I think it's a silly idea, I just picture you with a very frustrated and serious look.

Anyway, quaternions would solve your problem with pointing straight up or straight down (the effect you get when that happens is called Gimble lock by the way, not sure of the spelling on Gimble though). Quaternions are also the only way you can interpolate rotation, so they are handy for animations. They are computationally expensive though, since you will at times have to convert it to and from a 4x4 matrix to perform vector voodoo.

To fire a laser in the direction the ship is travelling, take the cross product of the up vector and the right vector. This will create a vector perpendicular to those two vectors, which form a plane in themselves. My question is, which direction will the cross product vector point?

That depends if you're using a left handed, or right handed coordinate system. Direct3D used a left handed system (fight the power!). So if you were using the identity axes (not sure if that's a term, but I think you'll know what I mean) the resulting vector would be facing toward you. Cross the right with the up vector to get it going the other direction.

to both of you: Keep on rockin.

[VirtualAce]

The problem of gimbal lock can be solved using Euler angles by doing an axis-angle rotation. The interpolation problem cannot be easily solved using Euler angles and thus I'm sick of all the manifolds and limitations of Euler angles.

Every time I rotate or want to rotate this to face that I feel as if I'm working against the Euler code. It's time to move to quaternions.

In your game Bob, are you storing up, right, and look vector's for each object? To me this seems to be the simplest approach to be able to control the object's direction, velocity, and perform other much needed operations on the object.

In the past I've only stored position and rotation values for each axis, but I'm moving more towards making each object more like a camera that stores it's up, right, and look vectors.

So if I want to make the object slide left and right I would move along the right vector for right and -right vector for left. Since the transformation takes care of which direction true right is, I don't have to worry about figuring out how to move the object correctly based on it's orientation. It's already calc'ed in the matrices.

Keep up the work Bob. Looking forward to playing the game.