Planetary collisions

[creative-brain]

Any idea, how to implement fast enough collisions? I've managed to generate a convex collision shape from mesh, but it's slow and inaccurate. I am now trying to add a CollisionShape on runtime using PhysicsServer but with no luck so far?

[Hoimar]

Hello, thanks for your interest in this project.

I thought about collisions briefly but didn't put too much time into it (yet).

I don't know where the performance hit comes from, did you try to use the Godot profiler to find out what's using up cycles?
When you say inaccurate, did you use the generated LOD (subdivided) terrain meshes to generate matching convex collision shapes? Because if you only used e.g. the first, top level terrain mesh, you'd indeed end up with a very inaccurate collision shape which wouldn't match the subdivided meshes.

[creative-brain]

I simply called mesh.create_trimesh_collision() for each generated face on its creation. The problem is that collision shapes contain too many vertices and therefore the collision calculation has to process a lot of data. The solution would be (I guess) to generate a multiple collision shapes for each face, which would allow for hierarchical search of close collision shapes (i.e. ship colliders and only nearby terrain colliders). Godot has a build-in function for that, unfortunately it not accessible via GDScript. Only from engine code.

So the solution would be either implement a wrapper function into the GDScript to create the access to the method from the source. Or, one could create a c++ module and access it directly in the engine code.

[Hoimar]

For general, inaccurate collisions, (think planet vs. planet) a sphere shape would suffice.

Well if you create a collision trimesh for every generated chunk, that's a lot of high resolution colliders to check against. If you have a mesh resolution of 100, that's 100*100=10000 vertices or (99^2)*2=19602 triangles to check against for a single terrain patch!

Also, you'll have to disable the colliders of invisible lower LOD meshes or you'll collide with those as well, which might be part of the innaccuracy and performance hit.

So as you can see, a performant terrain collision system has to be thoroughly planned, I've thought about ways to implement it and it's definitely on my list. Help is welcome!

I'll push some big changes in the next days by the way, many parts of the now-addon have been overhauled.

[creative-brain]

Indeed. Maybe I don't understand the collision system correctly but I did a simple experiment. I set the generation of the collision shape only for the closest planetary face. Then in the editor, I created the ship collision shape using a "single convex collision sibling" made from its mesh and tried a collision of the ship and the planet face. I got barely a single fps. Then again in the editor, I changed it to "multiple convex collision siblings" and I got a dramatic performance gain - if the ship stayed inside the actual terrain face (no generation of the new ones) I got solid 50-60 fps. Therefore, I concluded that the collision detection is only performed between the closest collision shapes (which would make sense). If this is correct then when the faces are generated as multiple collision siblings as well, maybe the performance would increase even more. But I could be wrong of course.

It is possible to use a build-in method for this as I stated in the comment before or maybe it could be done manually based on the generated face vertices that you already have. I also found a hint on the godot forum where they used PhysicsServer to set the faces of the collision shape manually but as I stated in my first comment, I didn't make it work.

But yeah, you can always create the collision shape only for the closest planetary face and leave the global collisions to a single (planet sized) sphere collision shape - that would indeed be sufficient for a planet-planet collision while the player collision with the surface would be accurate enough.

Another way would be to pre-generate both the vertices and collision shapes for each face LOD beforehand and only load those that are currently needed in run-time. That would even speed-up the performance of the whole planet as random generators are notorious performance eaters.

Anyway, I am really looking forward to your planet overhaul! ;)

[Hoimar]

The engine by default does a broad phase and a narrow phase, it should only check against nearby collision shapes anyway. I'll have to look into it soon.

By the way, heightmap collision shapes just have been implemented for Godot Physics: https://twitter.com/PouleyKetchoup/status/1379603423398535174 Perhaps this could be beneficial? Though the terrain here is a curved mesh, so it won't be that easy.

[creative-brain]

We can definitelly make some iterative experimentation here and try to find the best solution. I've created a planetary_collisions branch as a playground for this purpose.

[Hoimar]

So I'm still working on a more robust multithreaded job system for better maintainability and performance. It's kind of functional now, but I'm still debugging some hard to narrow down issues with the threads (multithreading is a beast).
After that I'm going to add physics "back in", probably using the PhysicsServer like we talked about because I don't want to generate physics shapes on the main thread.

[creative-brain]

I was struggling with the collisions lately. Don't have a valid solution the way we discussed it yet. Maybe I'll focus on something else and leave this one on you ;)

[Hoimar]

Oh, you actually continued to work on it? Which route did you take, PhysicsServer or physics nodes? I think the latter are not multithreading-friendly at all, I couldn't get it to work reliably using threads in my tests.

[creative-brain]

Well I created a separate scene with StaticBody and Collision shape and instantiated it for each TerrainPatch. Then I tried to inject the mesh data into CollisionShape but it didn't work and as I was in a separate thread I couldn't debug it directly. I did't even got to the PhysicsServer part. But I have a working example of PhysicsServer. I'll send it to you.

[Hoimar]

Okay. In the old version of terrain_patch.gd, there's a flag for threads on/off. Yeah, creating physics nodes doesn't seem to work in a thread as far as my tests went, so either it would have to be done in a call_deferred() function or using the PhysicsServer, which may also be faster.
You may also push to the planet_collisions branch if you want, I've locally worked there but then merged all changes into the master branch, so we should be good.

[creative-brain]

I created a skeleton of the solution using PhysicsServer but as before, it doesn't seem to work. I pushed the current state to the planet_collisions branch so you can have a look if you want. Maybe you'll see something I missed. If I somehow make it work, I'll let you know.

[Hoimar]

I had a quick look at the code, it's looking good already, but yeah, apparently there are no collision shapes yet and it throws a lot of physics errors (also had it crash once).

One problem is probably that it's not possible to instantiate and use any physics nodes from another thread as far as my research went. We'll have to use the PhysicsServer for everything, so we wouldn't even instance these nodes but use only the PhysicsServer to add bodies to the physics world.

I also think that we can't use a heightmap collision shape, because the vertices of a terrain patch only look like they're flat, but are in fact warped onto the planet sphere. Also, a heightmap may only be able to face upwards. A trimesh (convex collision shape) should work better, like you did before in your first version of this, it was rudimentary but collisions were there.

By the way, you can either use the uvs array for elevation values, or use the elevations array to pass to the calc_uvs() function :)