If I want to make a character (in Blender) made of cubes, to export it to unity later, should I leave these cubes and all the other body parts as separate objects, or join them all into one mesh?

And, If I should join them - is it a good idea to leave the cubes elements inside of each other?

enter image description here

Or I should remove them, add some loops and connect the vertexes?

enter image description here

In the last case it will be difficult to keep the cubes surfaces flat, because of the vertex shifting during joining.


2 Answers 2


Ultimately, you can take whichever option suits you best, personally. You would easily get away with either.

Leaving the Cubes Separate

If you do not join the cubes, they should import into your scene as separate objects, grouped under a parent object to represent your character. This is fairly easy to run with, but there are considerations you should make:

  • If you automatically generate box collider's, remember that your boxes collide, internally. If you treat each collider separately, you will likely constantly trigger OnCollisionEnter() or OnTriggerEnter(). If you do use OnCollisionEnter(), this will likely result is your object breaking apart. The best solution would be to use a single collider on the parent object to cover all internal parts.
  • Ensure you transform the object by the parent, and not by any internal children, or you will change the way that object appears.
  • When you transform the parent, ensure that this does not have a weird offset impact on the internal objects. This should not be an issue with translation and rotation, but I have seen cases where scaling similar parent objects resulted in using the individual centers of each child object, instead of scaling everything in to/away from the center.

Joining the Cubes

Joining the cubes as you detail should work pretty good. You say the vertex won't be straight after the merge, but it should not be particularly noticeable. Just as before, you still want to make some considerations:

  • Now, you will have a single game object. If you had intended to use multiple box collider's for whatever reason, remember that you can only hold one collider component per game object. A workaround would be to store additional colliders as empty children game objects. Ultimately, you should probably just use the same model as a mesh collider. In fact, if you go for option A (multiple internal objects), you could use this version as a single mesh collider.
  • Naturally, we lose the ability to directly transform the individual boxes. If you should want to do this, for any reason, you should not merge them before importing.

If you generate box collider's on empty objects with shape of these boxes, and your scripts are on a parent of 2 objects that have these colliders, any of these colliders will trigger OnCollisionEnter() method, so don't worry about it, just remember to parent them to 1 object.

Remember to set a pivot where you want - it will influence scaling.

If this mesh is one whole part and it those objects won't be controlled by separate scripts, you can of course join them together, but the question as I see was about - which way is the best practice. To answer this I should say that number of triangles matters. It's always better if there are less triangles, but the look of the model doesn't change. That is why Normal maps are used.

In case not merging them gives you less triangles, it's better to leave them inside each other.

But in case you need to merge I suggest you use boolean modifier that merges meshes automatically, also I would recommend to install boolean add-on - that is better from standart boolean modifier. Of course you can merge them manually (and sometimes it is better - if you can do this without losing the proper shape of the model).


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .