Hi Guys, my first post here but wanted to run something by the forums before abandonning the current direction to our issue.
We have a auto generated interior level, which is made up from 2000+ wall pieces that tesserlate around the map to create lego like walls.
Orignally each wall piece had its own collision box so that that we could tell when player/particles had collided with a particular wall. We would then turn that mesh + collider off and have semi destructable levels.
The trouble is, we have now moved the project over to mobile platforms and updating 2000 objects this way sends it straight to fps hell.
We have tested the two scenes, one with 2000+ objects joined toegther and exported as one fbx, and we have tested the same scene with 2000+ individual objects; as you would expect the latter performed dreadfully. This confirmed that the issue is the gameobject count, rather than poly/vert data.
Can anyone think of a way around the issue of having multiple objects whilst still being able to destroy particluar parts of it on collision events.
Why not have it generate one big collider for each wall segment.
Meaning if you have 50 walls next to each other facing the same way use 1 collider that holds all of them but when something collides with it, use an array to tell where it hit. I’m sure you already have an array of sorts upon generation, why not call that?
From what we can tell its not just the colliders that are causing issues, it seems to be the presence of 2000+ gameobjects in general.
Even with only the geometry it performs much much worse than one gameobject with the same 2000+ pieces exported as one fbx.
We need to be able to disable the mesh and collider for the wall piece so it can be walked through.
I guess the issue question is, if we batch our large amount of wall pieces into one object (which gains us a huge performance), is there a way to disable pieces of that mesh and modify colliders to match up with the gap once its been batched?
If anyone has any ideas of how to apporach the above images (one wall piece + one collider * 2000 to make level with grid based destruction) without killing the mobile platform from oversaturation of gameobjects, that would be grand xD
Enable/disable the colliders and make sure of exactly what is causing the problem. You don’t want to invest time in fixing the wrong thing.
If it is the mesh rendering that is slow then you can easily combine meshes together in the engine, to whatever extent you want to - there’s a script for it in the standard assets, and packages on the asset store that provide more functionality.
If you combine the meshes in a hierarchical fashion then you may be able to minimize the work required to fully recombine your meshes when one needs to be destroyed - but you’d need to profile it to make sure this gives a benefit. There are no easy answers.
Is there a script attached to each one? And if so, is there anything in the update function? If that’s the case, it could also possibly be the fact that there are now 2000+ function calls (just for Update) being made each frame.
I don’t know if it’s going to be that huge of an issue, I just remember that in developing with XNA for XBox you wanted to eliminate as many function calls as you could due to the way the .Net Compact Framework (which is what the XBox used) worked. Again, no idea if this would be that big of an issue in Mono.
