I’m going to randomly generate a bunch of asteroids in my scene. Right now I have 12 different meshes for the asteroids, and I’ll be randomizing various factors (size, mass, etc) as they spawn. Is there a reason I should use 12 prefabs vs 1 prefab and attach the mesh and colliders as I spawn? With 1 prefab it’ll be easier to maintain in the future, but as I’m fairly new to Unity I don’t know how that might affect performance or interact with general Unity best-practices. Thanks!
“Fairly new to Unity” and 116 messages?? xD
Typically it’s better to call the Instantiate() as few times as possible. However, if you instantiate giant prefabs, you’ll see a significant slowdown when you are calling it. There’s sort of a balancing act here–too many Instantiates and you get a large overhead, but too large of an Instantiate, and you have more time to load in more textures/objects. Though there may be a way to fix that.
Whatever you choose, just note that if you have smaller individual prefabs you’ll have more control over each one. (Unless you dig around in the larger prefab searching for asteroid references) But either way it’s almost certainly better to have the mesh and colliders already in the prefab. If you add them at runtime, it’s the same as calling that Instantiate() function again. So you end up with a larger overhead.
But a lot of devs on these forums will recommend to just do whatever’s easiest and worry about optimization down the line with the Profiler. But just keep in mind the consequences of each option!
How are the meshes getting generated?
Here’s why I ask, meshes and the materials you attach to them take up a bit of memory (quite a bit in some cases). So usually if you have multiple things with the same mesh, only one mesh gets loaded into memory, and is used by all objects that use it.
If you’re selecting a random mesh from a pool of meshes, you should be setting the ‘sharedMesh’ property on the ‘MeshFilter’ component, as well as ‘sharedMesh’ on MeshCollider if you’re using that. As long as you do this, a single prefab should be fine. Using the ‘sharedMesh’ property ensures that. Of course, using 12 prefabs will be just as efficient as well… and you don’t have to write the code to match the mesh to the instance.
If you’re randomly generating the mesh, each random mesh is going to be unique. Again a single prefab will be fine… you’re going to take a memory hit, but it’s not the prefab’s fault. Honestly though… if this is what you’re doing, let me know… I’ll tell you a much better way to deal with it.
Well…perhaps not time-wise, but I still feel like a complete noob :). Ok, I’ll just go with 12 prefabs for now, since that’s easy and sounds like it might be a bit more efficient. If I need more flexibility in the future I’ll just rework it. Thanks!
1 Like
Ahh, interesting. The meshes are existing resources, not procedural. I don’t see a ‘sharedMesh’ prop on the MeshFilter - shot attached. Also, I didn’t have any luck with mesh colliders (complained about a concave mesh) so I’m using capsule colliders.
‘sharedMesh’ will be used by the inspector, it doesn’t display that name for you.
‘sharedMesh’ is a property exposed in code:
In your case, using 12 prefabs will probably be the easiest, and gives no real impact on efficiency (and actually your prefab option will most likely faster).
Ok, so that’s used by default on prefabs and is just something I should use if I’m attached meshes via script. Gotcha. Thanks again!
For the most part yes.
Honestly in code you should always access the ‘sharedMesh’ property and not the ‘mesh’ property. Accessing the ‘mesh’ property actually has a HUGE implication, and use case. When you access it, and you’re currently using a sharedMesh, it will duplicate the sharedMesh in memory, and reassert that as its mesh. This means it increase memory usage… BUT, this is ok if you plan on modifying the mesh at runtime, and you need to effect only the object you’re modifying it for. If you modify a shared mesh, ALL objects using the sharedMesh will be modified.