Vega-strike-engine-source: Collision code is not good

[royfalk]

As part of refactoring unit, I discovered there is no possibility of merging missile with missile_generic without refactoring the collision code. However, when I started looking at that code, I discovered it's mostly an unclear patch on top of more patches.

I played the current version of master and started colliding into things and the code we have now is no good. Once I collide with something, unless I die, I am stuck within the other unit and can't disengage on my own.

My proposal

• Push my refactored code, which is stand alone, much cleaner and easier to understand. This means replacing one buggy system with another and requires testing both to discover the bugs in each.
• Decide on a design of some kind. e.g. damage is calculated as ... and so on.
• Create a new issue and implement it.

@BenjamenMeyer , I think you may want to put this to a vote. I try not to introduce new bugs into the game when refactoring, though it seems that it is very hard not to, given the current state of the code.

We should also discuss this further within the issue.

[evertvorster]

@royfalk I will be quite willing to test the collision code, just point me to a branch on your tree.

From my point of view, having something that we can fix is much better than something that is un-fixable.
With a bunch of testing I am sure that we'll iron out all the bugs on the proposed change and that will make for a clear winner.

[BenjamenMeyer]

@royfalk let's clean it up. We should only have a clear path into the collision code and it should be easily traceable. We should also have easy tracking of assets. If a missile can't be managed through a clear hierarchy then something is wrong and we need to fix it at the fundamental level; even if it temporarily introduces more bugs it'll be cleaner and easier to work with in the long run.

Assigning this to 0.7.x for now. If it's too much we can move it to 0.9.x.

[royfalk]

A not so brief discussion of what I've learned:

• Collision reaction is an n x n process. Unit vs. Asteroid. Missile vs. Missile, etc. Each potentially has different behavior, though in reality it is much simpler. For example, anything colliding with a nebula experiences nothing.
• A lot of code goes into fixing basic limitation of the engine. By the time the collision is detected, the units are over each other. There are a bunch of hack calculations to fix this and they don't work well at all.
• A lot of other complicated code has to do with calculating damage. My 3d analytic geometry is non-existent, but it looks like they overly complicated things.
• We should define a simple damage formula of some sort with a parameter or two to tweak it. We can then write a unit test to run multiple scenarios without playing them. When the results match what we want, we're good.
• We should lower our expectation of realism in favor of something that works. In particular, we need some kind of bouncing algorithm. This algorithm will a. stop/reduce set speed drastically for the smaller unit. b. move it back along its vector by reversing its current speed. c. introduce spin?
• Trying to figure out the correct bounce vector like a game of breakout is not feasible at this time. Given that we don't know the current mesh shape in a way that lets us calculate this, we should put this far in the future.

[royfalk]

Proposed damage model

Where:

• v is the relative velocity/magnitude between the objects
• m is the object's mass
• m' is the other object's mass

[royfalk]

Discussion

• The table increases speed and mass at the same time and a bit misleading. But any collision with a similar mass would cause half the damage anyway. This means that a collision at 10kps with another fighter (100ton) would cause serious damage. A collision at 20 would probably be fatal.
• A velocity of a little over 320kps is mach1. Multiply by 3.6 to get kph.
• It's not unreasonable to assume ships would not operate in space after anything but low velocity scrapes.
• We can tweak the model by adding a factor. i.e divide damage by 10 to make collisions at low speeds more survivable.
• We can also tweak the other mass (maybe a max value) to make scrapes with bases survivable at low speeds.
• This can be done in configuration or as part of the realism setting.

[BenjamenMeyer]

I don't have the physics background some of the original contributors do, but have some. So some rambling thoughts on this...

Keep in mind, in Physics:

1. force = mass * velocity (basic 2D)
2. objects traveling away from each other reduce the force of impact
3. objects traveling towards each other increase the force of impact
4. the angle of intersection needs to be applied for 3D applications
5. point of intersection (front of vehicle, center, rear) would also have an impact (front would increase impact b/c the object has to travel through it, possibly induce spin; center wouldn't induce spin and just take the impact as is; rear would reduce impact since it's more of a glancing hit, but might induce spin too - spin would be based on force of impact and distance from center of the craft).

Damage is the application of the final resulting force on a given object. Relativistic speeds don't really change this basic calculation at all.

Damage = ((theta * (v1 * m1)) + (theta * (v2 * m2))) * Object Damage Factor = theta * (v1 * m1 + v2 * m2) * Object Damage Factor
where v1 and m1 are one object, and v2 and m2 are the other object; theta tries to account for the angle of intersection to increase/decrease the force appropriately, and Object Damage Factor is a weapons based figure for the power of the weapon (e.g a basic laser might be 0.01 while a dumb fire missile would be 1; this value can be assigned to each weapon). While we're working a 3D space, it can be probably be calculated based on a simpler 2D plane based on the line of travel of each object. In the simplest terms.

Object Damage Factor could be scaled for application in different realism settings.

I'm not sure which method is better to pursue...

[stephengtuggy]

I've seen comments in the code that indicate that damage from collisions between NPCs is being capped at 50%, since the NPCs bang into each other so often. The comments further say that once the AI is improved to the point that this stops happening, then a more realistic damage calculation can be applied.

[BenjamenMeyer]

Per #325 we will do what we can now to improve things with a long term goal of fixing it full in 0.9.x

[royfalk]

_I've seen comments in the code that indicate that damage from collisions between NPCs is being capped at 50%, since the NPCs bang into each other so often. The comments further say that once the AI is improved to the point that this stops happening, then a more realistic damage calculation can be applied._
I wouldn't worry too much about that. The actual code has disabled damage from NPC - NPC collisions already. By already I mean the previous devs disabled this, not me.