Question What is the proper way to optimise imported models and animations?

A couple of question... hope someone can help. Thanks in advance!

Q1) I have an RTS game with various humanoid characters created in blender. They all share they same bones and animations. Currently when I import, I will import each character as a separate FBX file, which in turn appears as a standalone model in Unity. The animations are also imported for each FBX file individually for each model. So, for example, say I have Marine, Firebat, Marauder, and the animations are Idle, Walk, Attack, Die; then in all, I will have 3 x 4 = 12 animations.

My question is, is this normal workflow importing from Blender to Unity, or should I be sharing the animations in more efficient way? If so, how should I share the animations, appreciate if someone can point me to a guide.

Q2) when importing static models like rocks, buildings, and structures, is it better to import all as a single FBX file, or separate FBX file when considering the ability to do batch draw calls? For example, I have "Wall" model in blender, and the wall model is in "Castle", "Tower", "Stone Hut". Should I import "Castle", "Tower", "Stone Hut" in a single FBX file so that Unity knows "Wall" is a shared model across all structures, and knows it should batch them in same call? Or does it not matter at all as Unity will be smart enough?

Q3) Does making a prefab serve as hint to GPU to batch draw the prefabs?

Q4) I understand Skin Mesh Renderer does not get batched. However, does this apply to only the gameobject that has the Skin Mesh Renderer component, or does it apply to its parent and child as well?

 

Make one FBX for each fully featured character model and any model-specific attachments as separate meshes together. Maybe your model has different parts for hips-down and belly-up and head, or maybe they're all one continuous skin. Don't bother keeping generic attachments which can be shared across models in the same FBX.

If you have a very small number of animations which are specific to a model, it's fine to export and keep them in the same FBX, but pretty quickly you will have enough animations to make this cumbersome. Export companion FBX files which just contain the skeleton and small numbers of animations. Many will say you should just have one animation per FBX, especially if you can automate the export from modeling software.

The above guidance is about how to maintain your models, not how Unity needs them organized. It's really about how you want to work on models that might need changes and updates as your game materializes.

For humanoids, heavily leverage the Mixamo/Mechanim system. Your models can have extra bones, your models can be missing some bones, but try to represent most of the humanoid bones. When you import their FBX, you make an Avatar which is a listing of which of your bones match up best with which "standard" Mechanim bones.

Any humanoid animation which can be applied to more than one of your model, regardless of the original skeleton bone names, can be instantly retargeted through the use of the Avatar of each model. This cuts down on your 3 x 4 = 12 animation math a LOT. The models don't even need the same body proportions, they just need to be a two-leg two-arm one-head kind of body. As mentioned before, you can have additional tails and costume bones without any issues to the humanoid Mechanim system.

Multiple parts in FBX files are pretty much irrelevant to batching. As far as meshes go, an FBX is just a generic container for meshes and a recommended hierarchy in case you wanted to move parts around. You specify which mesh belongs to various objects, and it's the mesh, object, shader combinations which drive batching, instead of where those meshes came from. This goes for skin animated models, constructs of interactive physics mechanisms with many parts, or scenery which needs no extra processing. You mark game objects as being static to skip extra processing, not FBX files.

Prefabs are not at all connected to GPU hinting. They are a design-time concept, a recipe of everything that makes up a game object, so they can all be loaded and cloned at runtime. At runtime, there's really no such thing as a prefab, it's just another game object which happens not to be in the scene.

I would really recommend you skip thinking so hard about GPUs and batching, until you learn how to do proper performance analysis in this engine. Every moment you think about performance bottlenecks without concrete profiling data showing you exactly what the bottleneck is, is a moment wasted. There is plenty of time to learn a lesson about what works fast and what works slow... after you got something working at all.

 

@halley Thanks for the comprehensive response!

I am thinking hard about optimization's because I am getting GFX lag and I so this is part of investigations, to see whether I done anything wrong in this part. The folks in the profiling discussion forum, understandably, could not tell me what is wrong with my setup. I learnt there are so many variables, but there isn't a straightforward checklist to go through. For example, I accidentally realized that my materials are all "(instanced)", they are not "GPU Instancing" enabled, not enough "static" gameobjects used, and a lot of skin mesh renderers.

I will try your suggestions and see if they help. Could be a totally different issue that is causing the lag spikes.