Missile - Target distance detection between two frames.

[paccalin]

For now, the missile - target distance detection between two frames is made with either one of two methods:

• Linear interpolation between the Missile - Target distances of the frames (which is fundamentally flawed, as these distances do not evolve linearly at all, no matter the target.)
• Trigonometry to project linearly the target position onto the missile displacement vector to find the shortest point (This method doesn't include target displacement, and thus, is only viable for non-moving target).

The goal is to make an algorithm capable to computing the shortest distance between two linearly moving points to replace both methods.

[paccalin]

We don't have to include acceleration, as the integration of even 15G of acceleration on these timeframes is negligible. For any of both points, the maximum position deviation @15G will be:

• 2.0cm (.787") with a 60hz physics clock.
• 5.1mm (.197") with a 120hz physics clock.

[5H1N0B11]

Well the target won't go over 15G for sure but the missiles, especially modern ones can do some 50g turns.(maybe it is still too little. It just to keep in mind)

[NikolaiVChr]

It is nice you want to improve the missile code, but you have misunderstood how interpolation method works.

It works like this:

The time between the two frames is small, so small that interpolation assumes both target and missile speed to be constant (both in turning and along its flightpath. Interpolation then 'rewinds time'. Lets say 20 steps. The missile flightpath in between the frames is divided into 20 equal length segments (actually 40, since this interpolation takes place over 3 last frames). The target flightpath is also divided into 20 segments. Notice the distance of each target segment might be shorter or longer than the missiles segments, due to speed. It then iterates over the segments at the same time. So missile segment 1 is compared to target segment 1. Then 2 vs 2. etc etc. Once the segment pair with the shortest distance between them is found, the missile segment is then taken as the explosion position and the distance is send out over MP. In other words it figures out when the missile passed the target how close did they get to each other, and takes into account both their different speeds and positions.

In my opinion it is not flawed at all. ..Unless the missile actually explodes when it is within a certain distance from target. What interpolation assumes, is that missile explodes when it is within certain distance AND that distance start increasing again. And even if that assumption is wrong, then its pretty easy to modify the code to trigger as soon as its within certain distance.

PS. And yes, this does not take the missiles fuse time into account either. PS. And yes the MP code does dead reckoning on the targets position, which could mess with the accuracy of this. But that is built into FG, we cannot really modify that with Nasal.

[paccalin]

Well the target won't go over 15G for sure but the missiles, especially modern ones can do some 50g turns.(maybe it is still too little. It just to keep in mind)

Good point, done the maths, it is still 6.8cm (2.67") with the 60hz loop.

[paccalin]

@NikolaiVChr So this is the code in the missile-code::explode() I presume (I'm still not used to reading these 5k+ script files).

[5H1N0B11]

Well... Indeed this is little. Less than the aircraft and missile size. At one extend we need to remember the aircraft size and wing span : a dist missile-target of 10 meter will be a dist between their 2 ref point (that I hope are in the middle of each object, but I can't tell). So 10 meters on a U2 (31 meters of span) means the missile is 5 meters into the aircraft...

[paccalin]

@5H1N0B11 It would be very hard to integrate the geometry of the plane (or the missile for that matter) in the computation of the shortest distance. It could be integrated after, but only in a simple way (effective sphere shapes) to avoid both making assumptions on the orientations and computationally intensive mesh-mesh collision (that I have no idea to do with nasal), but even then, we have to find an reliable way to have an effective radius for both the target plane model, and the missile model (the latter probably being easier than the former).

[NikolaiVChr]

@NikolaiVChr So this is the code in the missile-code::explode() I presume (I'm still not used to reading these 5k+ script files).

Correct.

Well the target won't go over 15G for sure but the missiles, especially modern ones can do some 50g turns.(maybe it is still too little. It just to keep in mind)

Good point, done the maths, it is still 6.8cm (2.67") with the 60hz loop.

Thats 6.8cm per frame, so per interpolation-segment its is going to be negligible.

that I hope are in the middle of each object, but I can't tell

It is where the JSBSim VRP is. So at the 3D models origin (0,0,0). That might not be in the 'middle', but for most aircraft it is.

So 10 meters on a U2 (31 meters of span) means the missile is 5 meters into the aircraft...

Yep, it could be, depending on where the missile explodes, if below the aircraft it might only be for example 8m 'outside'.

But for for example a 10Kg warhead a hit within 10 is pretty much a guaranteed splash (as in the target is done fighting) for Viggen and F16. Not sure how many failure modes you have put into the mirage, but if its the FG default only, you probably need a 5m hit to get proper killed. In other words, make alot of failure modes to increase realism. :)

PS. We have a small hack built into the damage code to account for aircraft size and number of failure modes. But it is a hack, making more failure modes will solve at least part of this.

[paccalin]

Thats 6.8cm per frame, so per interpolation-segment its is going to be negligible.

Segmenting linearly doesn't reduce the maximum deviation error, only using another order of interpolation or integrating acceleration would be able to acchieve such a thing. Said otherwise, if there is 50G perfectly radial to the target all along the frame, the whole last segment would deviate around 6.8cm (but not significantly less) which IMO is negligible indeed (considering how much more complex the system to solve gets if we want to integrate acceleration).

Edit (is not negligible => is negligible)

[NikolaiVChr]

True. But consider what the system does. There is dead-reckoning on the target (it really send out 10Hz position updates). The missile explosion is in comparison to aircraft 'center', wildly unrealistic. The explosion effect is just a curve (non linear) that determines a chance a system on the aircraft gets disabled, crazy unrealistic. Some aircraft have alot more system that can be disabled and since each is checked against a resulting percent chance it gets disabled, aircraft varies insanely much in how susceptible they are to damage, very unrealistic. The damage distance is only send out with 1 decimal digit, so 10cm precision. We use the warhead total mass to determine that curve, although it doesn't in reality scale that way, and warheads can explode in many different ways etc etc.

The code we are discussing, is really the strongest link in a long chain of things that are not realistic. Which is why I don't worry about it too much.

[paccalin]

The time between the two frames is small, so small that interpolation assumes both target and missile speed to be constant (both in turning and along its flightpath. Interpolation then 'rewinds time'. Lets say 20 steps. The missile flightpath in between the frames is divided into 20 equal length segments (actually 40, since this interpolation takes place over 3 last frames). The target flightpath is also divided into 20 segments. Notice the distance of each target segment might be shorter or longer than the missiles segments, due to speed. It then iterates over the segments at the same time. So missile segment 1 is compared to target segment 1. Then 2 vs 2. etc etc. Once the segment pair with the shortest distance between them is found, the missile segment is then taken as the explosion position and the distance is send out over MP.

Then, this is kind of what I'm suggesting, but instead of trying to find the best timestep in a pool of discrete computed disances, my suggestion was to use calculus or a linear system to :

• Have the "true" closest distance according to the "constant speed" rule (not an approximation, no matter how precise it is)
• Have the amount of operation done by the algo reduced (not having to do 40*2 interpolation, then a min applied)

[paccalin]

True. But consider what the system does. There is dead-reckoning on the target (it really send out 10Hz position updates). The missile explosion is in comparison to aircraft 'center', wildly unrealistic. The explosion effect is just a curve (non linear) that determines a chance a system on the aircraft gets disabled, crazy unrealistic. Some aircraft have alot more system that can be disabled and since each is checked against a resulting percent chance it gets disabled, aircraft varies insanely much in how susceptible they are to damage, very unrealistic.

To me, as long as there is a close enough missile hit, the aircraft is dead. I understand that there are many thing that are incorrect, for some, it is because we can't with the current tech / API available. For anything else, "good enough" is IMO not good enough. Not if it is not backed up by an algorithm of lower complexity, which in this case, has a worse degree of complexity (linear to n, n being the approx precision parameter, in our case 40, while it could be constant with another approach)

The code we are discussing, is really the strongest link in a long chain of things that are not realistic. Which is why I don't worry about it too much.

Yet it is still the reason for the "use interpolation" option in the menus that a more formal implementation would remove.

[paccalin]

There is dead-reckoning on the target (it really send out 10Hz position updates).

The mp update is indeed 10Hz, but this includes acceleration (both linear and in rates), which are integrated at a much higher ferquency to get a proper position. This plus the fact that I cannot see more than 1m difference when connecting two fgfs on mp, even in high G/speed maneuver, I'd say that there could be some derivation of the acceleration or some kind filter (maybe kalman) applied to the mp data to end up with quite accurate data (for targets with proper connectivity at least).

[Zaretto]

It isn't the frames on the model that are even relevant - instead it is the MP update frequency - which is usually at least 100ms; but probably anything from 200ms to 2000ms depending on network latency and which mpserver pilots[1] are connected to.

---

[1] ISTR that the sync between MP servers is every second or so.

[NikolaiVChr]

Yet it is still the reason for the "use interpolation" option in the menus that a more formal implementation would remove.

You can switch method in the menu? That's not good. They interpret <max-report-distance> in two different ways, to switch method you would have to change that in all missiles bombs.

[paccalin]

They interpret <max-report-distance> in two different ways, to switch method you would have to change that in all missiles bombs.

@NikolaiVChr, @5H1N0B11 as far as I can tell, they do interpret <max-report-distance> the same way: range < max-report-distance & drange/dt > 0 -> explode()

Here is what I've understood from both methods (feel free to correct me if I'm mistaken): The main difference I can find is the way the subframe time (and thus coordinates) are computed:

• The "Interpolation" method compute the range at multiple discrete values of subframe time, and use the smallest one. Which gives a degree of complexity linear O(n) to the degree of time precision we want (10steps, 20steps, ...).
• The "trigonometry" method uses trigonometry to compute the position in the subframe missile trajectory that will have a radial going through the target position. Although the complexity of such an algorithm is constant O(1), it makes the assumption that the target is not moving in the subframe, which can lead to some quite big differences for fast targets.

[NikolaiVChr]

Trigonometry method does this:

If range < max-report-distance explode immediately if has passed. Do not try to explode where it was closer to target. It does compute if it WAS closer to the target, but it explodes where it did the check, which is after passing.

Thats why for interpolation method for example AIM-9 we set it to like 60m. So that if its not within that when range increases it just keeps flying until hit ground or selfdetonate. With 60m here people get: 'passed target' meaning it got in the vicinity, not very close.

In trigonometry for same missile we want to set it to like 10m. It has a concept called usedChance, if it did a check within 2x10m and failed to explode, it will never explode.

[paccalin]

Okay, thank you for the explaination. What real behaviour is this "trigonometry" method trying to emulate ? Because now that I'm going deeper into it, It would deem that it uses the coordinates at the frame BEFORE the check to define the explosion coordinates.

[paccalin]

Sooo. After some discussion with @5H1N0B11, we concluded that there was no intent to emulate any of the missile behaviors by tying the explosion to the logic clock. The underlaying idea behind both approach was to get the closest position.

Which can be implemented with only one function (see the associated merge request).