The Speed of Ground - A study into how KSP terrain colliders handle land vehicles with high magnitudes of velocity.

[nascarlaser1]

Good job getting thread of the month! This is cool!!

[memes in space]

But can you do it in half an a press?

[cubinator]

On 9/12/2017 at 1:33 PM, memes in space said:

But can you do it in half an a press?

...To do this, we start the mission already holding spacebar, and use that space press to reach the pole. Now hold on, I know what you're thinking: A launch is a launch, you can't say it's only a half. Well, T.J. "Henry" Kerman, hear me out. A launch actually has three parts to it: When you press launch from the editor, when the craft loads, and when you activate the first stage, and together this forms one complete launch...

[Yi C]

THIS IS A LEGEND.

[vv3k70r]

On 5/16/2017 at 6:46 PM, Stratzenblitz75 said:

This suggests that a craft traveling at a constant velocity above 1368 m/s will encounter the bug, while a craft below this speed will not.

Is that this velocity when controls change from surface to orbit?

On 5/16/2017 at 6:46 PM, Stratzenblitz75 said:

What if the game loads a “radius” of terrain colliders around the craft, and after 1381 m/s, the game stops loading new colliders?

It could be. I encounter this problem with loading terrain partialy in other engines - there is max speed that is to hight to load precision colision blocks (it fly on simplyfied) or even terrain at all.

On 5/16/2017 at 6:46 PM, Stratzenblitz75 said:

So the data seems to be scattered around ~7.4 km

Reasonable horizon on Kerbin.

On 5/16/2017 at 6:46 PM, Stratzenblitz75 said:

This could make sense if we consider that KSP does not load terrain continuously, but rather, loads it in chunks. Would this explain the variation?

Yes, it is reasonable to load it that way to keep ilusion of constrain position and forces. It is quite a mess to seamless load terrain and free memory from the previous one - You have to rpedict where the nasty player would go.

On 5/16/2017 at 6:46 PM, Stratzenblitz75 said:

In an ideal KSP, the distance from the craft to the boundary of the terrain colliders should be constant.

But which terrain to free from memory?

On 5/16/2017 at 6:46 PM, Stratzenblitz75 said:

So indeed, KSP does load terrain in square chunks.

Reasonable - that do most game engines.

On 5/16/2017 at 6:46 PM, Stratzenblitz75 said:

Effectively, this means that once a land-speeder passes 1381 m/s, it only has between 6 km and 9 km (depending on the direction and distance traveled) to hit the land-speed record before falling off the remaining colliders.

Game fishic

On 5/16/2017 at 10:44 PM, something said:

If this hypothesis is true, then other celestial bodies should yield different maximum collider speeds.

You load as much terrain You designated in memory. Propably chunks are same size for any map to meet players expactations.

Smaller body could be loaded almost completly? There is one rock around EVE, but hard to get "land" speed there.

On 5/16/2017 at 10:49 PM, something said:

If the collider's size was subject to the planet's size then the colliders probably wouldn't be squares or rectangles but have another shape since the planet is a sphere.

To memory You load rectangles - easier to keep position.

 

 

Great job!

 

[Corona688]

On 5/16/2017 at 10:46 AM, Stratzenblitz75 said:

In conclusion, this study shows that KSP loads terrain colliders in squares, and completely stops loading new colliders after reaching 1381 m/s. Effectively, this means that once a land-speeder passes 1381 m/s, it only has between 6 km and 9 km (depending on the direction and distance traveled) to hit the land-speed record before falling off the remaining colliders.

But, why does the game stop loading new colliders after 1381 m/s? My theory is that the devs coded a limit into how fast the terrain loaded in an attempt to optimize the game.

I was perusing KSP's old devlog and read a few things that seem related to this.

Number one, yes - the world is mapped as a square.  Six of them, stitched edge-to-edge in a cube.

Number two, terrain calculated from that is imposed onto a dish-shaped object which gets translated under the player.  This dish gets updated and recentered at need,  and is far more accurate in the center than at the edges.

Number three - Unity problems made this necessary.  It just can't update a large collision mesh every single frame.  The dish is a buffer, holding enough live terrain to suit most purposes and occasionally updated asynchronously.

All this gleaned from HarvestR's oldest dev blog here:  https://kerbalspace.tumblr.com/

[Dr. Kerbal]

Wow! You test your crafts and use math? Oh. I juat fly tham and see how they go.

[Ziggy Kerman]

On 5/16/2017 at 12:34 PM, joacobanfield said:

Excellent job! All the tips of the fedora for you.

 

Let me get the Fedora Tipper 9000 running.

[dnbattley]

While this is some serious necro post revival, I missed it the first time, and have one additional data point that may add to the body of knowledge: the five second limit corresponds to a limit which affects landing leg Kraken drives in high SOI environments, whereby they can suffer a sudden and catastrophic stress overload if operated continuously for that time, after previously working fine. Cycling the Kraken drive (pulsing it off even for a fraction of a second, every e.g. four seconds) overcomes this limitation, and I wonder if any testing with a "caterpillar leg" effect on the wheels (i.e. switching between the ones in contact with the ground), could generate any beneficial effect...

[Nazalassa]

Sorry for the necro, but I just watched @Stratzenblitz75's last video about shooting probes into Jool (and Laythe), and I have an explaination for the "Laythe crash" near the end, and it's exactly the topic of this thread:
If your horizontal speed is high enough, the colliders won't load. Stratzenblitz75's probe was unaffected by Laythe's kill sphere, thanks to its landed state, but not by the colliders. So if the colliders load, it will crash. If not, then it will reach the core. They didn't load on the first attempt because of the high horizontal speed of the probe, but did load on the second, as the probe, going straight down, had almost no horizontal velocity.

That's my explaination of the "Laythe crash". I hope it'll be useful.