Collision handling for ships made of blocks

Kind of like empyrion or space engineers.
You have a large space ship made up of many blocks, which perform different functions. Some things take up more than one "block", but they still take up the entire blocks they use.
Also, some blocks have non rectangular collision meshes, like a sloped or curved surface. But more detailed blocks (like a small satellite dish) use a box collider, *maybe* a very simple convex mesh.
The player can add/remove blocks at any time.

I was thinking, how would you approach collision detection for this situation, and generating the collision mesh.
The simplest and probably least efficient approach I can think of is, for each block you have, just add it as a separate gameobject to a parent gameobject, along with its collider. The collider can be a simple box collider, or a very simple mesh. For ships with a million+ blocks, this would be unusable.

Another approach - break the ship into sections of blocks. Generate a simple collision mesh for each section based off of collidable faces. Faces that are not visible (like the faces between two cubes directly beside each other) would not contribute to the collision mesh. If a block uses a simple collision mesh, just add that collision mesh to the overall mesh for that section.

Another approach - use an algorithm to create as many box colliders as possible for "solid" sections of the ship, and use simple meshes for other blocks. I think this could be very efficient for a solid ship...but who does a solid ship? In most of these games, the ship is somewhat hollow. Also, depending on the ship you could have a LOT of box colliders.

Any thoughts on this?

 

Start with the simple, inefficient approach. But isolate its implementation so you can easily swap in a better approach later should you need to. This will let you start iterating on your idea as quickly as possible.

 

Thanks TonyLi. I'm hoping for some ideas on different solutions that I may be missing, thoughts on the different approaches, and hopefully advice from those who have actually attempted this already. I'd prefer not to reinvent the wheel if I have to.

 

I recommended the simple approach because the sooner you start iterating, the sooner you can refine your requirements for collision detection.

As you iterate, you may determine that your gameplay idea is more fun with a huge number of ships. In this case, you might want to use a tiered collision approach, where the first tier is a simple bounding sphere on each ship. Only if bounding spheres collide would you spend additional time on deeper checks.

However, if you decide that, for example, your idea is more fun if you have a small number of ships with vast size differentials, with the possibility of tiny ships making "trench runs" in larger ships, you might want to procedurally generate a mesh collider. This could be a single collider that bounds the ship to a certain minimum accuracy that you've established.

It may be that the challenge isn't to avoid reinventing a single wheel, but to identify which type of wheel your game needs, and then apply whichever relatively standard approach best fits that need.

 

Check out this video for some crazy high performance dynamic collider stuff.

You probably don't need any of that, like @TonyLi suggested, the nieve approach may work well enough.

 

I'm not claiming that the naive approach will necessary work in a final product, but it's how one gets to the right approach that meets the needs of the game design.

 

Hello.
I am also very interested in this technology.
Did you managed to find any additional information about it?

I found a developer of Empyrion on Unity forum here and asked a question. Maybe he will agree to answer.

 

I would solve this by generating flood algorithm which subdivides ship into a set of box colliders of different sizes. If your ship is a large cube of 1m blocks you would have only one large box collider, etc.