Skip to main content
gamedev.net
🔒 Locked 🎮 Unity

Aiming a object

Started by tbcpp 5 replies 700+ views
Original Post
tbcpp
tbcpp
Okay, I'm working on some behavior AI and I seem to be having some issues going from 2d math (which I can do like the back of my hand) and 3d math. What I want to do is have one object ram another object, let's say like a missile would. Here's what I have so far: two objects: rocket and target each object has the following properties: location - Vector3 rotation - matrix modelTransform - Calculated from the above two whenever they change. So I got a simple "thrust" working by doing the following: location += Vector3.Transform(new Vector3(0,ThrustValue,0), rotation); That works well, I have the target object running circles around the screen. Now the question is, (and I'm using XNA btw) how do I get the rocket to aim at the target, and how do I limit the rocket's turning speed (let's say to 180deg/sec). I've seen stuff about how to use the Cross product, or Matrix.CreateFromLookAt, but if someone could just write a step by step description on how to do this, that would be great! Thanks.
Bob Janova
Bob Janova
How do you do these things in 2D?

The 3D case will probably be a simple extension of the 2D one.

First you will want to get the target's position (and possibly velocity, depends how clever your rocket is) in rocket local space. That is (position of target-position of rocket)×rocket coordinate transform matrix. Once you have that, the problem reduces to 'how to get a rocket to steer towards a target in local space'; if your rocket has a fixed speed this simply becomes 'rotate around an axis in one direction. The axis of rotation (in local space) is (rocket forward vector: [1,0,0]?)×(target's location in rocket local space) – that's the vector cross product and it assumes that the rocket's local forward vector is along its X axis – and you can then transform the resulting quaternion/rotation matrix by the inverse of the rocket's transform matrix to get the new transform matrix in world space.
tbcpp
tbcpp
Thanks, I'll give that a try.

In 2d I'd use atan to find the angle and then rotate to that angle.
InvalidPointer
InvalidPointer
Bob pretty much hit the nail on the head there. I have a strong suspicion you're radically overcomplicating 3D math. After all, you're really just adding a third number/identifier. The cool thing about math is that pretty much everything carries over, and indeed a large amount of calculations in 3D can safely (and effectively!) be done in a 2D plane.

Also, I would suggest storing rotation as three angles for handling situations like this much more cleanly :) It's actually somewhat more efficient in the grand scale; aside from consuming less memory, you actually can concatenate transformations much more easily (just operate on angles/position vectors rather than full-blown 4x4 or 3x3 matrix multiplies) and then just do a final conversion to a transformation matrix.
clb: At the end of 2012, the positions of jupiter, saturn, mercury, and deimos are aligned so as to cause a denormalized flush-to-zero bug when computing earth's gravitational force, slinging it to the sun.
alvaro
alvaro
Quote:
Original post by InvalidPointer
Also, I would suggest storing rotation as three angles for handling situations like this much more cleanly :) It's actually somewhat more efficient in the grand scale; aside from consuming less memory, you actually can concatenate transformations much more easily (just operate on angles/position vectors rather than full-blown 4x4 or 3x3 matrix multiplies) and then just do a final conversion to a transformation matrix.

I would suggest you *don't* do that. Composition of rotations expressed as three angles is very hard to do. If you use matrices, you simply multiply them. If you want a more compact representation that also has good behavior in interpolation, use quaternions.

What you should do is try to not use angles in geometry. Things are usually easier and cleaner if you think of vectors instead of angles. They also generalize much better from 2D to 3D.
Bob Janova
Bob Janova
I agree; yaw/pitch/roll are useful in a limited set of circumstances where 'gimbal lock' is a sensible outcome: for example, a character's vision when the character is fixed to the ground. A transform (translate+rotate) matrix can be modified by a delta-rotation matrix very easily whereas combining Euler angles is a pain.

Also, the cross product in my first post

(rocket forward vector: [1,0,0]?)×(target's location in rocket local space)

simplifies to

[0, -targety, targetx]
Zakwayda
Zakwayda
Quote:
Also, I would suggest storing rotation as three angles for handling situations like this much more cleanly :) It's actually somewhat more efficient in the grand scale; aside from consuming less memory, you actually can concatenate transformations much more easily (just operate on angles/position vectors rather than full-blown 4x4 or 3x3 matrix multiplies) and then just do a final conversion to a transformation matrix.
This has already been touched on, but I just wanted to reinforce that Euler angles are usually (but not always) more trouble than they're worth.

You mentioned memory consumption, but that's not really an issue here. In most cases, it won't make any difference whether you use 3 floats or 9 to store an orientation. Where it does matter, you can store two vectors (6 floats), a quaternion or axis-angle pair (4 floats), or a compressed quaternion (3 floats).

As for combining rotations, adding to and subtracting from Euler-angle values isn't really equivalent to combining rotations in matrix or quaternion form.

Now, as has been noted, in a 'fixed-up' environment where only two of the rotations are really needed (typically yaw and pitch), Euler angles are fine. In the OP's case though, I'd recommend using the method proposed by Bob Janova (apply incremental rotations to the rocket to keep it aligned with the target).

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.