Terrain Deformation and Explosion Visuals

[Kernel Kraken]

I feel like I'm not alone when I say KSP1's explosions and destruction mechanics were lackluster at best, and just absolutely disappointing on average. I've built my giant lifter capable of moving enough material to create several new solar systems, but when it inevitably crashes due to my own incompetence all I get for it is scattered components and a few poofs of smoke from my fuel tanks. 

This is where I think KSP2 could improve on the most. Sure, the graphics are going to be prettier, and there will be cool colonies and prettier planets, but will the destruction be improved at all? You're telling me that after I "accidentally" diverted a D class asteroid, it leaves not a single dent or divot on the surface? My multi-megaton masterpieces don't strip trees off the ground when they detonate? No epic waves washing away my hard work when I crash into the water off of the runway? Not even a ripple on the surface other than a generic looking splash.jpg?

Destruction has (unfortunately) been a constant threat in our own history of spaceflight, and I hope KSP2 Is more accurately able to represent the consequences of my engineering oopsies with new tech available to today's developers.

[RealKerbal3x]

In this dev diary post they did talk about how they were making explosions better (as well as other VFX), but nothing about terrain deformation or anything like that. I agree though, deformable terrain would be pretty cool, even if it wasn't persistent. If it was persistent though, the system could lend itself to other applications such as more immersive mining or surface levelling for base/colony building.

[SpaceFace545]

there making explosions better but voxel and terrain deformation won't be a thing, that a bit too complex and gets very glitchy

[K^2]

2 hours ago, SpaceFace545 said:

there making explosions better but voxel and terrain deformation won't be a thing, that a bit too complex and gets very glitchy

Voxels for sure, but terrain is height-mapped already. An efficient and, in my professional opinion, correct way of handling it is having displacement map in your terrain virtual texture, taking it into consideration during tessellation to produce correct visual representation, and generating terrain collisions via a compute pass early in the frame. The terrain collisions are then added as additional contact points when you do physics sim, and that should work identical to current collision system, except now you can have procedural craters. There are a few other advantages of moving terrain collision to GPU, but that's a bit beyond the scope.

This is a lot easier to do on a custom engine, or at least, one that you have better access to internals of than with Unity. It also assumes you are using virtual textures, but if you're making an open world game in 2021 and your terrain textures aren't virtual, you are objectively doing it wrong. And while awkward, there's a way to do all of this in Unity. What I'm unsure about is the performance hit, which could be critical for consoles.

On a bespoke engine, this can work as flawlessly as regular terrain collision. Better in a lot of ways, as it allows for higher resolution of terrain collision near the player. Due to how virtual texturing works, resolution will be lower far from player, so you have to address that. But the only real danger is if you land a second craft on parachutes within physics range of your main craft, and it "lands" at slightly the wrong elevation. Which is something you can fix with a few lines of code. In every other way it's better than stock collision in terms of performance, quality, and stability. Finally, because of how virtual texturing is handled, you'll be able to process hundreds of thousands of craters in an area before it starts becoming a problem, so long as not too many overlap at once in any given place. And you can fix that without much visual change by removing older, smaller craters from the list of deformations first.

On Unity, it's a different story. Last time I checked, there was no native support for virtual textures, so you might have to get creative with materials and shaders to get it working with tessellation. That could mean that you'd be stealing significant amount of GPU time. It shouldn't be a huge deal for a game like KSP2, though, as it's not graphics-heavy. The other aspect is that you need to make sure the compute for collision detection runs before actual collision detection, and you can add the additional contact points, which might have to be managed as joints you are adding and removing on every frame, and that's just not good for physics performance or stability. And that might be the breaking point for a Unity implementation of this, especially if Intercept intends to run KSP2 on PS4 and XB1.

It's also most definitely a non-trivial amount of work, and you want at least the collision detection written by somebody who knows what they're doing. So I'm not going to insist that Intercept should have done this, just that there's definitely a way to get good looking craters without having to deal with voxel terrain or create any stability problems or bugs in physics.

[LittleBitMore]

They've announced and demonstrated WAY better explosion graphics. Check out the dev logs, they're EPIC!

as for terrain deformation, perhaps temporary smoldering ejecta type particles, but I don't personally think permanent terrain damage or deformation is the way to go

[Kernel Kraken]

16 hours ago, LittleBitMore said:

They've announced and demonstrated WAY better explosion graphics. Check out the dev logs, they're EPIC!

as for terrain deformation, perhaps temporary smoldering ejecta type particles, but I don't personally think permanent terrain damage or deformation is the way to go

Maybe just spawning a crummy crater model? Having a preset list of areas a crater can spawn in the event of a sufficiently heavy impact? Wait, no, that would take remodelling an entire planet or ay least taking a few hours to pepper it in preset impact points. I guess it's probably too late in development to get voxel deformation too.

[K^2]

2 hours ago, Kernel Kraken said:

Maybe just spawning a crummy crater model?

Visually, very easy to do, but the hard part is updating collision model. Whenever you are playing a game, you can picture it as two worlds co-existing at the same time on the screen. One is what gets rendered, which is purely visual and doesn't affect any gameplay or physics, and the other is the collision world, which defines all the boundaries, but remains entirely invisible. And they are handled completely differently. Rendering is done on the GPU fairly haphazardly, because it's more efficient to throw more shader cores at the problem than do any sort of complicated logic^*. Collisions are handled by CPU, so all the collision geometry is neatly organized into hierarchies for quick access. If you want to render a crater, it's easier to just render terrain with a chunk of it set to transparent and then draw the crater model over transparent bits, and it will look to you like there is a crater in the terrain. You can't do that with collisions, because there is no way to just make a portion of collision geometry "transparent". So if you want to place a rock on the terrain, well, that's still going to require you to update the hierarchy, but otherwise, you just add more collision geometry. But if you need to make the hole in something? That's an adventure.

The engine I'm responsible for, we have a way to disable some of the collision triangles on a mesh during build time. It's convenient specifically for cases where you want to make a crater or a tunnel through geometry that's already been designed. In principle, you could add some code to enable/disable individual triangles in the mesh at run-time. But it's not free - the collisions will take longer to compute if you do this, and it really has to be built into the physics engine. As far as I'm aware, that's not an option in Unity/PhysX. So if you want to be able to have craters in terrain, you have to go custom with your terrain collision system. I've described in a post above a good way to offload it to GPU, which isn't something you can do for general collisions^*, but you can for terrain. It is a lot of extra work, however, and I don't think Intercept has resources to throw at this right now.

^* Worth nothing, I'm describing conventional GPUs with conventional rendering. Ray tracing uses "accelerators" which are very similar to how collision hierarchy is handled, so in theory, at least, RTX/RDNA2 graphics cards should be pretty good at running collision detection. But it's unlikely we'll see a lot of games utilizing that at least for a while.

[runner78]

On 1/22/2021 at 9:45 PM, K^2 said:

On Unity, it's a different story. Last time I checked, there was no native support for virtual textures

Unity is working on it https://forum.unity.com/threads/feedback-wanted-streaming-virtual-texturing.849133/

A simple way would be to simply add a crater to the heightmap.

[Bej Kerman]

I think a simple thing to do would be to merge different explosions into one giant massive explosion rather than having each part get its own dinky little poof of fire. Besides that, parts shouldn't magically disappear, they should either explode into fragments or take a massive dent as a result of the collision force. Rockets don't just abra kadabra IRL.

[Incarnation of Chaos]

2 hours ago, Bej Kerman said:

I think a simple thing to do would be to merge different explosions into one giant massive explosion rather than having each part get its own dinky little poof of fire. Besides that, parts shouldn't magically disappear, they should either explode into fragments or take a massive dent as a result of the collision force. Rockets don't just abra kadabra IRL.

That's mostly just a compromise for performance purposes, you'd have to swap in a different model while also rendering the explosion. This causes lag even with small amounts of destruction, and quickly runs away into slideshow territory.

And that's assuming we're only talking about fragments for cosmetic purposes, if you wanted them to persist....then you can take that and double it.

There's ways around this, but i have absolutely no idea if Unity has them natively.

[K^2]

7 hours ago, runner78 said:

A simple way would be to simply add a crater to the heightmap.

Sure, but that requires a collision scene rebuild and makes streaming terrain more awkward and expnsive. I can see it becoming prohibitive on consoles. And you are still limited to height map resolution, which isn't terribly high.

With VTs, you unload work to GPU and can have resolution down to centimeters.

[Kernel Kraken]

3 hours ago, Incarnation of Chaos said:

That's mostly just a compromise for performance purposes, you'd have to swap in a different model while also rendering the explosion.  

I mean, real rockets don't split into a bunch of different parts then explode. It's one cohesive fireball and shockwave. I feel taking the mass of the rocket to decide the size of the explosion, then just starting it at the impacted part would make sense and be easier to render than a hundred separate particle emitters. 

 

[Incarnation of Chaos]

6 hours ago, Kernel Kraken said:

I mean, real rockets don't split into a bunch of different parts then explode. It's one cohesive fireball and shockwave. I feel taking the mass of the rocket to decide the size of the explosion, then just starting it at the impacted part would make sense and be easier to render than a hundred separate particle emitters. 

 

From what I've seen, that seems like what intercept is doing. They said before that explosions would be based on the fuel types and the mass.