Using MeshCombining for Semi-Dynamic Objects and Multiplayer?

Questions & Answers
1

Perhaps this question may have been better in a forum, not sure which section would be best for it. But I’ll just ask away here.

I have close to nil knowledge on the inner works of multiplayer setups for Unity 3D. My game is originally aimed for Multiplayer but If I must I can start with single-player till I find out how to do Multiplayer.

My game is a First person shooter type of game so It’d have multiplayer features like Halo, etc. However I can generally guess what kind of data would be sent and received regarding User’s movements and actions. But I’m not too sure about this one.

So lets say my game has roughly a thousand cubes. Each of the cubes are identical except for size and it’s position. Currently I’m using a Mesh Combiner script to make it optimized so instead of thousand of draw calls I’d have much less. These cubes are Semi-Dynamic objects meaning that they will be static with rigidbody disabled until a player shoots them, re-enabling their rigidbody component . At this time this would mean the group of cubes that were affected would be moving, which means those cubes would have to be removed from the combined mesh. So I’m curious about what kind of lag I would be dealing with if each time that happens it would have to send the mesh shape over to each player? What kind of data would be sent over? Would it be a large amount of data? Or would it work in such a way as instead of essentially loading a new asset/mesh each time, each of the players would have the untouched mesh combined thousands of cubes, and then whatever function that tells it to remove the cubes from the mesh would happen on each of the players game.

I hope I’ve made my question clear, apologize of this is common knowledge, or knowledge that is easily found online.

Thanks for any replies or insight

2

Do you have some way of “addressing” your cubes? I’d add one of those first. A Guid is unique, easy to generate and takes 16 bytes of memory; an incrementing integer would be smaller but you have to make sure that it is unique for each player.

I’d suggest what you do is RPC over a list of the cubes identifiers with an instruction about what to do with them (remove from combined mesh, add to combined mesh) etc. What you’d do then is not try to give each cube a NetworkView - you’d have a single communication point for each player and RPC that with position updates and instructions.

Another point - it is possible that when your cubes break apart you “don’t” remove them from the combined mesh. You could keep the combined vertices array that you are using for combination and tell each cube which vertices within that array it represents.

  • Each Update, each cube that has moved would modify its vertices in the array
  • Every frame you would update the mesh
  • When a cube “breaks off” you would create a game object with no renderer, but with a box collider and give it a reference to the cube in the world it represents - this cube would now be moving and update its vertices

This is always 1 draw call (per 1700+ cubes if you use 36 vertices per cube) no matter how many cubes have “broken off”. The downside is that if cubes move a long way from their source mesh then you would be getting the GPU to potentially handle vertices that were far from the main part of the viewed part of the world.