To split or not to split large 3D objects?

Question

I have a fairly simple question for which I'm seeking guidance:

Should large 3D objects be splitted into smaller ones?

By wide, I mean an object that would be as wide as a game level is, below is some mountain, the first picture shows it as a single mesh, the second picture shows it as multiple meshes.

Facts I've considered (might be wrong):

• a large object simplifies the scene hierarchy with less objects in total, but at the same time it might be rendered more often than necessary since it will be considered as visible

• a large object made out of smaller objects makes the scene hierarchy more bloated, but at the same time on a performance aspect is better since only visible parts of it by the camera will be rendered, the rest being culled

Note, these objects aren't complex by today standards, that mountain is less than 1K triangles and a complete level is likely to be less than 30K triangles.

Ideally, I would like to have the least amount of objects in the scene hierarchy to keep it simple, but at the same time I am wondering whether or not over simplifying the level might put extra problems on the table I haven't thought about.

Answer 1

This question is actually anything but simple :)

There are several advantages to splitting a large object, but they are situational:

• Each of those objects can have an own LOD group. If you set up these LOD groups with differently detailed versions, then nearby parts can be rendered in a much higher detail than those which are further away. This allows for a much higher graphic fidelity without compromising on the size of your scenes. But note that you might encounter issues with visible seams between adjacent parts of the object while they are rendered with different detail levels.
• Each of those objects can be separately culled through occlusion culling or frustum culling. When the whole object is one mesh, then the engine has to render either everything of it or nothing of it.
• A large and complex object often requires a mesh collider. Mesh colliders are performance-heavy, especially when they have a large number of polygons and don't have a convex shape. Breaking the object down into multiple colliders allows the collision detection algorithm to rule out many potential mesh collisions by the bounding boxes of the involved objects. It might also allow you to make at least some of its parts use convex collision meshes. Note: You don't necessarily need to use the same strategy for the collision mesh(es) as you use for the rendering mesh(es). When you have one parent object with a rigidbody and multiple children as sub-objects, then you can put the rendering mesh on the parent and the collision meshes on the children. You can also do it the other way around.

But if these situations do not apply to your case (the whole object is usually on the screen at once, all of it is seen from roughly the same distance and there aren't many potential collisions with it), then it is usually better for performance to keep the whole logical object in one physical object. In fact many projects go the opposite way. They go out of their way to unify many small and simple static objects into one large and complex object at runtime in order to improve performance (this is called "mesh welding" and there is a handy utility method for it).

Now you might be more confused than before. Sorry about that. But if you aren't sure what you are supposed to do now, remember the old saying in software development: Premature optimization is the root of all evil (Donald Knuth). Do not waste time and energy on optimizing things in your game when you don't yet know if you even need that performance. Create things the way which is most comfortable for your development process. If you later down the road encounter performance problems, analyze them. And if you find tangible proof that this mountain ridge is indeed the culprit, then you can still consider how to make it more efficient.

I am looking forward to playing your game.