Best way to handle large numbers of cube colliders

[bibuth]

Hi,

This is a pet project, basically I want to write a server to support a multiplayer game. I’m not interested in the game (client) stuff as such. I will be happy with my default character controllers I work as a C# developer this being the reason I chose to use unity as my client.

It started as a regular sort of game, but validating physics and collisions on the server was starting to get annoying, so opting for a cube(minecraft) type game made validation of positions and physics easy this meant I could moved generating the world to the server which is nice.

So my current setup is I am running a server client architecture using photon which is working like a dream. I’m generating a minecraft style cube layout on the server based on a seed which is saved as a ‘room’ when you join a room the client sends a position and the server returns a collection of stuff needed to build the chunk your in. When I started I had small chunks so rendering 101010 cubes was fine. Now I’m ready to scale it all up and rendering a large number of cubes just kills the physics (physX throws because it can’t handle that many). I’m not sure of the best route to take with this so I am mainly looking for advice and pointers.

My game has a chunk prefab that has a single script. So I instantiate the chunk prefab then call the Create(Block[,] data) function which is called when a message is received from the server. This then instantiates a cube where it needs one, each cube has its own collider.

So my first idea was to try and have the collider as the chunk which then would wrap a mesh collider around all the child objects but I’m not sure if that’s possible? Or I could try to work out which cubes are visible and only instantiate them but that might have a large overhead to calculate that on a regular basis.

Again like I said it would be nice to have a shove in the right direction as I’m starting to pull my hair out with this if anyone has tried anything like this before.

Thanks

[xt-xylophone]

Hi

I havent tried this before but I read a lot on the process of doing this a couple years ago when I was keen to try it out.

From memory the idea is that each “chunk” in Minecraft is a single solid mesh that takes up 16x16x256. When a single cube in it is interacted with, the entire chunk is rebuilt with the changes.

If you tried to make each cube its own mesh with colliders, a single chunk would have over 65 000 cubes and would probably lag like hell.

So a system is needed which can make heightmaps for your terrain, then be able to generate a mesh to fit that. If you are having ‘digging’ then another system needs to be implemented to know which ‘cube’ in the mesh is interacted with.
I believe oct-trees are the way you go about ‘cutting’ down the starting rectangle mesh to create your chunk and also as a fast way to search your chunk to find the collided cube.
Minecraft also cuts the chunks down into ‘render chunks’ which are 16x16x16 I believe so the entire 256 height isnt rendered, i.e. everything below the ground.

Minecraft is pretty complicated the further you go into it but I think thats the basics.

I was once really keen to try this out so all of this is pretty much from memory, I dont have the sources I got these from sorry but I hope its enough to ‘shove you in the right direction’ to try some stuff out or use some keywords for helpful google results.