Developer Insights #10 – Collisions

[Vanamonde]

Quote

Let us consider a command pod with a nominal size of 2 meters hurtling towards the surface of the Mun at 1000 meters per second.  

If I had a nickel... 

[PlutoISaPlanet]

This was an interesting dev diary. Most of these are very difficult to follow, but you guys make a good effort!

[Dientus]

So there are two seperate algorithms based upon a cursory sampling of position and speed. When the first, simpler and presumably quicker algorithm detects a probable collision then it switches to the more accurate and likely processor intensive algorithm model descriped initially. Did I understand all that correctly?

 

I would love to see this in action on a lower model rig. It makes me wonder if there is a significant (i.e. noticeable) performance change regardless of hardware prior to collision and if so, how far apart are the two objects when (if) this occurs.

 

 

[cyberKerb]

Great Insight Dr Dodd! Love reading the details of behind the scenes methodologies.

I had two questions for you, one of which I expect you probably knew was coming many kilo-frame-ticks away.

1) On a scale of 1m/s to 1,000,000m/s, how sad are you going to make @Danny2462? Is he likely to have to adopt Trackmania 'hunting' style game play where he spends hours / days / weeks to find a tiny incremental improvement on breaking your new KSP2 physics calculations? 

2) Other question is (with tongue firmly in cheek), if 'Krakensbane' is being added to KSP2, and we have new expanses of the great unknown to explore, does that mean we'll be visiting the Kraken Homeworld?!!

Maybe we can send a peace delegation to try and negotiate forgiveness from the species that took so many brave Kerbals from many players KSP1 experience.
To be fair, many of my previous noodle rockets were quite offensive, so I do hope the peace council doesn't devolve into a 'who started what' argument...

Articles like this directly save Kerbal lives through less sacrifices to the physics Gods (i.e you and your team) to understand their nebulous ways. 

Noted exception of @Danny2462, who would sacrifice many Kerbals just to know they exist...  or for a mouse cursor.

Edited July 23, 2021 by cyberKerb

[Anth]

Please keep these types of posts coming. They are awesome

[MARL_Mk1]

I'm so happy every single detail from KSP1 is being addressed. Can't wait for 2022 to come.

[Admiral Fluffy]

Bit late, but ITS FRIIIIIIIIIIIIIIIIIIIIIIIDAYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY!
Not really.

But Still.

 

On 7/23/2021 at 2:00 AM, Intercept Games said:

FANCY WATER!!!!

[Lewie]

Man, this is awesome!!! Always a fantastic to learn about some of the inner workings of ksp2!

[mattinoz]

Does this mean no more wheel catapults?

[jshu]

Very interesting from a developers perspective, thanks for the insights!

[mattinoz]

On 7/24/2021 at 7:21 AM, Dientus said:

So there are two seperate algorithms based upon a cursory sampling of position and speed. When the first, simpler and presumably quicker algorithm detects a probable collision then it switches to the more accurate and likely processor intensive algorithm model descriped initially. Did I understand all that correctly?

 

I would love to see this in action on a lower model rig. It makes me wonder if there is a significant (i.e. noticeable) performance change regardless of hardware prior to collision and if so, how far apart are the two objects when (if) this occurs.

 

 

To my reading the second model only considers pairs of objects considered likely to collide at a time in the future using the first.   So not sure it so much switches but distributes the calculations. As the first pass finds a pair that might collide in a second or so it can ask the other algorithm if they do. Even maybe async it the task and have the answer ready before it happens. 

Assuming the first pass has some awareness about changes to the situation happening like craft acceration then you'd think it should be able to heavy filter the situation down to to critical pairs very well.  

[Redneck]

@dr dodd you definitely got your hands full tackling this one and its not a easy one. Good luck  

[[email protected]]

o... m... g... you're brilliant.  Thanks for sharing!

[Dr. Kerbal]

On 7/23/2021 at 1:39 PM, Nate Simpson said:

Forwarded your question to Dr. Dodd, and here's his answer: "We had to leave out a lot of details on the continuous collision check. One of those details is that it includes a broad-phase algorithm to improve performance. This algorithm performs a low cost sweep of all the objects to rule out pairs of objects that do not collide with each other. The next step is narrow-phase algorithm which performs the detailed and more costly collision checks on objects that are expected to collide based on output from the broad-phase. Thus, if two players are in opposing positions, their vessels collision pair would be removed by the broad-phase algorithm."

Splendid! Because I often collide stations with each other. 

[boolybooly]

Good to know objects will collide effectively at high velocities in KSP2 ! 

The √64k question, can we use impactors to shift asteroid trajectories ?

[gussi111]

Can someone upload this video somewhere else or something, I only get a blank screen playing.

[OldManGamerOMG]

Absolutely fantastic! Realism of the first, with the fun created elements is what makes Kerbal such a brilliant game. Science is amazing, and something that I am passionate about. You should have a Kerbal getting hit with an apple being tossed from a lunch box by another Kerbal, for a spin on the apple from the tree. Would fit your work perfectly.  Look forward to seeing your Newtons in action.

[KSP_linux0191]

Two questions:

1): Why don't you use a 64-bit float point? Is that even in the unity engine, or does it not exsist? and

2): I heard that unity slows down when you add lots of collision meshes. So, why not make it so that the collision meshes only load in when any object-vessel or planet's surface-comes into the physics range? (in KSP1 that was 2.5Km) If the unity-slows-down thing is accurate, wouldn't this algorithm increase performance?

Edited August 24, 2021 by KSP_linux0191

[Klapaucius]

On 7/23/2021 at 9:00 PM, Intercept Games said:

One of the problems we’ve had to solve was the ability to accurately detect and resolve collisions at orbital velocities of 10 kilometers per second or more. Collisions in KSP can be grouped into two main categories: (i) collisions with static objects like terrain and buildings and (ii) collisions with dynamic objects, like vessels. I want to tell you about some of the work we have been doing to improve both.

This was really interesting. Putting this in a KSP1 context: is this the situation occuring with the new fireworks? I have noticed that they will bounce off objects if launched at low velocities.   However, if I speed up the initial velocity, they pass through objects easily.  As an example, in the batting practice video below, any setting above the absolute minimum launch velocity caused the firework to pass right through the "bat".

 

 

[Fletch4]

On 7/23/2021 at 4:00 AM, Intercept Games said:

collisions with static objects like terrain and buildings

did i hear buildings? or does this just mean colonies and the ksc...

[theonegalen]

On 7/23/2021 at 4:00 AM, Intercept Games said:

Therefore, the physics engine knows the current positions of kinematic objects, but it is unaware of their motion. To solve this problem, when we expect a collision between an active vessel and a surface (i.e., kinematic) object,

ah, so you needed Heisenberg compensators

[TLTay]

I wonder what role Nertea is playing on the team?

 

[MrFancyPL]

I like how you are  taking care of things that haven't been taken care of in KSP1. It looks very promising!

[dnbattley]

Being very slow on the uptake, I have only just read this dev diary, but my immediate thought was "why not just simplify/elongate the hit box?": I mean, if an object is travelling at warp 1, the hit box is effectively just a really long cylinder with (if you want to be really flash) the cross sectional area of the object from the perspective of its vector of travel, which you can then over-extend for huge distances in front of and behind the vessel. Only as you slow down or get within a reasonable physics range would this hit box cylinder need to be refined by being compressed and (depending on the speed) interpolated back into the actual 3D shape of the object.

Taking this approach you would then approximate any vessel as an exaggeratedly long cylinder, only looking at the intersection with other craft periodically (this periodicity would in part determine the extent to which you exaggerate this hitbox size and so could be tailored to the machine speed). On the detection of a cylinder collision you could then choose to either refine the calculation (i.e. based on local coordinates and using a more refined collision shape is it still a collision for the vessel?) and/or simply teleport the colliding vessel(s) to the point of intersect as determined by the detected overlap and proceed with the explosion calculations from there.

[t_v]

Essentially, the system does just that. It has calculations to see if it will collide with objects within a certain time interval (sort of like a hitbox elongated to a certain time interval, but more optimized) and then in the tick that has the collision in it, it makes sure the vessels are in the right place to collide (this actually takes an extra tick, as you can see in the video, the red capsules are frozen for a tick all stuck together, which allows the collision calculation to happen) and then the calculation of which parts go where happens and things fly back off.