Hi,

a while back, I got lots of help here on the forums (special thanks to alvaro) getting started on interception-equations for my little space-sim. What I produced looks very much like this (I use simplified special-case-functions for better efficiency, but this is the most general approach):

(types are from Irrlicht engine, 32-bit floats and 3d-float-vectors - pretty self-explanatory...)

RPos: targetPosition - interceptorPosition
RVel: targetVelocity - interceptorVelocity
Acc: current targetAcceleration
vel: initial and "omni-directional" interceptorVelocity, can be used for newly spawned projectiles etc.
acc: interceptorAcceleration, also regardless of direction

bool intercept (const vector3df &RPos, const vector3df &RVel, const vector3df &Acc, const f32 &vel, const f32 &acc, vector3df* Dir, f32* ETA, vector3df* POI)
{
array<f32> coefs;// filled from last to first (degree-wise)
coefs.push_back(Acc.dotProduct(Acc)/4.f - pow(acc,2.f)/4.f);
coefs.push_back(RVel.dotProduct(Acc)/*/2.f*/ - vel*acc);
coefs.push_back(RPos.dotProduct(Acc) + RVel.dotProduct(RVel) - pow(vel,2.f));
coefs.push_back(2*(RPos.dotProduct(RVel)));
coefs.push_back(RPos.dotProduct(RPos));
f32 t = smallestPositiveRoot(coefs);
if (t != -1.f)
{
vector3df interception = RPos + t*RVel + pow(t,2.f)*.5f*Acc;
if (ETA)
*ETA = t;
if (POI)
*POI = interception;
if (Dir)
{
interception.normalize();
*Dir = interception;
}
return true;
}
else
{
return false;
}
}

Everything works fine, except when Acc is given. Interceptors lag behind their target in that case.

The math behind it is this:

(A+B+C)^2 = (A+B+C).(A+B+C) = A.A + B.B + C.C + 2*(A.B + A.C + B.C)

interception possible, when
| (P + V*t + A/2 * t^2) | - (v*t + 1/2 * a * t^2) = 0

...^2

(target/left side:)
-> P'(t) = P.P + V.V * t^2 + 1/4 * A.A * t^4 + 2 * P.V * t + 2/2 * P.A * t^2 + 2/2 * V.A * t^3
= P.P + 2 * P.V * t + (V.V + P.A) * t^2 + V.A * t^3 + 1/4 * A.A * t^4

(interceptor/right)
-> v^2 * t^2 + 1/4 * a^2 * t^4 + v*a * t^3

final polynomial:
(1/4 * A.A - 1/4 * a^2) * t^4
(V.A - v*a) * t^3
(V.V + P.A - v^2) * t^2
(2 * P.V) * t^1
(P.P) * t^0

I checked all kinds of values for my simulation objects' masses, accelerations, velocities etc., but they are all fine, so the problem has to be with the equations, I guess. Maybe someone can tell me what I did wrong?

This is what I would do: Make up an instance with very simple numbers (mostly 0s and 1s) so you can do the computations by hand. Verify that your understanding of the equations is correct that way. Then step through the code with a debugger and verify that the code is doing the same thing. Hopefully you'll discover what's wrong that way.

Hmm... I am not really sure what kinds of values to expect from these computations. The individual function-parameters I could all verify, but this is somewhat beyond my mathematical understanding... Still, I will try what you suggest. I have to admit I never actually used a debugger, but I will write some debugging-code to monitor the different function-components, maybe I can notice something suspicious.

I think I may have found the problem, it looks like for some reason my Acceleration-vector pointed in the opposite direction as the others.

I've got another question though. How do I integrate gravity into this? I was experimenting with a scenario where two objects are placed on the ground and are therefore not accelerated by gravity. Now I want to use my intercept-function to launch a projectile (affected by gravity) from one towards the other.

It seemed logical to me to just subtract the gravity-vector from the target-acceleration (in this case Acc = (0,9.8,0)) as if the target was floating up instead of the projectile falling down, but I don't get the desired result. Maybe my logic is flawed?...

It seemed logical to me to just subtract the gravity-vector from the target-acceleration (in this case Acc = (0,9.8,0)) as if the target was floating up instead of the projectile falling down, but I don't get the desired result. Maybe my logic is flawed?...

That sounds to me like it should work. As usual, create a sample scenario with simple numbers, solve it by hand and see if your code is doing the same thing. Feel free to post the simple scenario here if you need help with it.

Some mistakes are just too stupid to be true...
I just found the cause for both problems. Turns out, when writing some operator-overloads for conversion between PhysX and Irrlicht types (months ago), I got something terribly wrong:

vector3df operator- (const vector3df &Irr, const PxVec3 &Px)
{
return vector3df(Px.x - Irr.X,Px.y - Irr.Y,Px.z - Irr.Z);
}

I copy-pasted from the plus-operator and forgot to change the code properly.

And in computing "Acc", I have used that particular overload for the first time. So with "Irr" being the target-acceleration and "Px" being the gravity-vector, I always got reversed Acceleration and subtracting gravity wasn't possible...

Sorry for another pointless topic and until the next!

After several years I need to come back to this topic. What little I understood of the matter is all gone now

I'm working in 2D at the moment, but I guess I can still use the same equations, right?

Most of all I'd like to get some (actually a lot) help modifying them to have the interceptor reach the destination with a set velocity - usually |0|, so it will stop in place. I guess this would require a whole new approach, because the direction of acceleration can not stay constant over time... I hope genius Alvaro is still around

Hi, I could use some more help with my targeting/aiming/homing (all-purpose) algorithm. It hasn't really changed over the years, but my project has changed a lot. There's basically just one thing that's still missing: An optional offset from the "center of rotation" to the point where a projectile should be spawned, when using the function for a humanoid character aiming a gun etc.

Any point on the character's up-axis can be the center of rotation, but it's not where projectiles are spawned. They are spawned with an initial offset, which could be the muzzle of the gun itself (probably hard to do) or just a constant distance from the rotation-center/origin towards the intercept-direction (easier?). The big problem I see here is that both change the relative position of target/interceptor needed for computing intercept position and direction, but I can't really tell how until the intercept-direction has been computed. So I would have to loop through these two things to get closer to a correct result, but that's not really worth the performance in a real-time simulation.

Is there a better way?

edit: in other words, I need to tell the interceptor that, when computing intercept time and position, he/she/it has already teleported a certain distance towards the intercept direction right from the start.

I'm not sure we are talking about the same thing. Choosing an ideal starting point for projectiles is not a problem by itself. I would just use the weapon's muzzle as starting point, because everything else looks glitchy, ranging from intolerably to hardly noticably glitchy.

The problem is that any "offset in character space" messes up my targeting algorithm. These errors may be neglectable in some cases, but definitely not in all. I am not talking about the "instantly travelling" kind of projectile that's basically just a raycast plus some visualization. Those are always easy and precise without any math worth mentioning at all. I'm rather talking about slowly moving, gravity-affected projectiles like grenades etc., where a small offset from the computed aim-direction and projectile-origin can make a big difference, especially when the target is moving and far away.