I'm trying to compute target lead so I can give the player a reticle to aim for when firing at the enemies in my game.

Here are my calculations but something does not seem right:

Code:
```//Create vector from current position to target
D3DXVECTOR3 toTarget = target - position;

//Calc distance to target
float distance = D3DXVec3Length(&toTarget);

//Calc final laser speed
float finalSpeed = Ship.GetSpeed() + LaserCannon.GetSpeed();

//Calc time to the target
float timeToTarget = finalSpeed / distance;

D3DXVECTOR3 leadPosition = (target.velocityVector * target.Speed * timeToTarget * frameDelta);```
After this I project the leadPosition and arrive at the final screen coords. I then draw the image for the lead reticle or pipper at this 2D point.

Does this look right?

My thought was since the laser moves at a set speed and since I'm treating the laser as a projectile I should add the laser speed and ship speed. Then I find out how long it will take to trave the distance from the current position to the target's current position. I use that time to estimate the target's new position at the time I just computed by using the target's velocity and speed and the computed time and then finally taking into account the frameDelta to put the entire system into the right units for the game.

The example is a very simplified version of what is in the game. I took out a lot of resource manager calls to make it easier to read.

2. Distance from me to target / projectile speed = time to target.
Target speed * time to target = distance it will have moved by then.
Make a triangle from you to it, to it's new estimated heading and see if you'll make it there in time?
Something like that?

Quzah.

3. That is essentially what I did. Just checking with everyone to see if it makes sense or if someone has already done this type of code before.

4. If you want to actually hit the target, you probably need to use the distance from where you are to where you're going to hit the ship, not to where the ship is now. (Since you seem worried, I guess it's because you're missing sometimes? But the idea is roughly right, although at this point I think you either need to (a) do math or (b) iterate using the new distance/new time and recompute etc.)

I'm ignoring z just to do less typing: Assume ship is at (x,y) and we are at (0,0). Assume the ship is moving at a speed of (sx, sy) per unit time and the laser is moving at (lx, ly). Then at time t the position of the ship is (x+sxt, y+syt) and the position of the laser is (lxt, lyt). For the ship and the laser to be in the same place at the same time means those two points must be equal. That means that t = x/(lx-sx) and t = y/(ly-sy). Since both t's must be the same that gives you an equation for ly in terms of lx (I get ly = [y lx - x sy - y sx]/x).

5. Originally Posted by Bubba
That is essentially what I did. Just checking with everyone to see if it makes sense or if someone has already done this type of code before.

i.e. you don't lead the women, children, and old people quite so much

Seriously though, this finally makes use of the two trains leave two stations problem from 2nd grade math.

The target has a vector relative to the shooter, and a velocty along that vector. So calculate the relative velocity towards or away from teh shooter (simple trigonometry).

Then you have two vectors, the relative velocity fo the target adn the speed of the projectile. Subtract these two to give teh true velocity of approach tot eh target.

Now take teh distanc tot eh target adn divide it by the velocity of approach, this gives you the Time to target (T).

Now throw out everything except T. You have a simple triangle defined by 3 points, A the shooter, B the targets current position, and C the aim point. To calculate C you use the distance to teh target as side AB, Side BC is T times the velocity of the target, and side AC is the T times the projectile velocity. Now solve for angle bc and you have how much you lead the target.

6. Wow, this is interesting.... Does army use something like this...or just heat seeking?
Also there are very interesting threads in game programing that could be useful in robotics...

7. The math the military uses takes two pages for one equation and includes wind speed and direction, aerodynamics, temperature, humidity, exact time and date, position of the sun and moon, altitude, air pressure, roll pitch and yaw of both the source and target, and a couple other things im forgetting at the moment.

and then it accounts for countermeasures, which I wont even go into.

8. Just need to solve some vector math since the object is moving along one vector and the projectile will move along another vector.

For the military it depends on what you are shooting. If you are shooting a rifle you do it off of instinct and training. If you are firing a canon from a ship to a target that is on the other side of the horizon you are taking a lot more into account. Ideally you also have a spotter on the ground that is gonna tell you which way to adjust the shots.

Also the cardinal rule: The harder it is to hit the bigger the payload

9. That's why if you watch some fighter plane movies where they have a targeting reticule you'll see it skip off to the left or right for a bit ... it's calculating based on shifts in the target's movement, assuming it keeps that same heading. Then it sees its heading change and recalculates.

Quzah.

10. Cool (abachler, you are scary ).

11. That's the most beastly signature I've seen on this board yann, cheers!

12. Hehe sorry, I'll shrink it now...

13. I believe the military predictors work based on aspect angle to the target (since that is indicated on the pipper), velocity of the target, closure rate, etc. I'm not even sure closure rate matters.
Roll, yaw, and pitch have nothing to do with the actual velocity vector of the target. A fighter plane can certainly be at 90 degrees of roll and yet not be inside of a turn or could very well make an outside turn. Unlikely though since this would cause the pilot to pull more -G forces than the human body can handle. Also if the target aircraft is an SU-27 or an F-22 they both have thrust vectoring which would really throw off a predictor if it only looked at the attitude of the aircraft. Attitude of an aircraft says nothing about it's actual velocity vector. In a flat spin and/or deep stall an F-16's attitude is slightly nose up and bouncing as it spins but it is falling straight down. No amount of afterburner or thrust will bring it out of the spin since the wings have simply stopped generating lift. Even in commercial aircraft the attitude is not indicative of the velocity vector of the aircraft. Any type of pitching and rolling will cause the actual velocity vector to swing around. If you ever have played FSX or F-16 you will notice the indicator that is a circle with 3 lines coming out top, left. This is the true velocity indicator of the aircraft. If you line up the straight ahead marker ( the small circle or cross that never moves) on the HUD with this indicator then you are aligned with your velocity vector. Large commercial aircraft on final approach are slightly nose up yet the velocity vector of the aircraft is around -3 to -7 degrees. All glideslopes are set to 4 degrees which creates a glideslope cone as the beam emanates from the base of the runway. The difference between the actual velocity vector and pitch of the aircraft is the angle of attack. Most wings begin to stall at around 15 to 20 degrees angle of attack and most smaller aircraft are far below that. Regardless of thrust a wing cannot and will not produce lift beyond it's rated angle of attack. I seriously doubt there is any way for a radar system to know the exact condition of a target aircraft. It is simply estimating the speed of the target and it's aspect angle. I believe my equations fail b/c they are not estimating the aspect angle which is the angular difference between the target's velocity vector and the velocity vector of the attacker.

Also since in combat you would be firing a fast moving projectile I believe one can probably nullify aerodynamic effects and wind resistance and still get a fairly accurate shot. Anything will fly straight, even in a windstorm, provided you throw it fast enough. But most fighter planes do not dogfight in inclement weather conditions so it's a moot point. At most the additive thrust to the projectile will be about 225to 300 knots since most dogfights occur around these speeds. Most combat performance envelopes don't require a great deal of speed to stay in the envelope. Since I am firing lasers moving at extremely high rates of speed in outer space with no wind and therefore no aero none of the above matters in my simulation.

I will keep researching to see if I can find a leak about how some popular space-based games did it. It would be nice if the Freelancer, Novalogic, or Egosoft (X2,X3) guys blogged about it but I doubt I'll have any such luck.

14. Roll Pitch Yaw effects its maneuvering options, most planes can pull higher positive G's than the can negative G's. Since the direction that is positive is effected by all 3, they all effect the calculations. These are usually calculated with respect to air flow. A high yaw with respect to airflow can decrease maneuverability, making it more likely that the pilot will have to use throttle to restore laminar flow across the control surfaces.

15. Which a radar based system cannot possibly calculate since it does not have intimate knowledge of the target. Roll, pitch, and yaw say next to nothing about the current state of the aircraft. Velocity vector and speed say much more about where the target will be at a time T than anything else. The predictor does not predict what the target pilot will do or what the target aircraft will do it only predicts it's possible position. As the velocity vector changes then so does the predictor. But if the aircraft rolls on the Z axis and does not alter it's velocity vector the predictor will not change.