Jump to content

Developer Insights #10 – Collisions


Intercept Games

Recommended Posts

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.

 

 

Link to comment
Share on other sites

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? :wink:

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?!!:0.0:

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 by cyberKerb
Link to comment
Share on other sites

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.  

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

200px-Newton_apple_tree_hg_clr.gif

Link to comment
Share on other sites

  • 2 weeks later...

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 by KSP_linux0191
Link to comment
Share on other sites

  • 2 weeks later...
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".

 

 

Link to comment
Share on other sites

  • 3 weeks later...
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 :D

Link to comment
Share on other sites

  • 2 weeks later...
  • 1 month later...

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...