1
\$\begingroup\$

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.

enter image description here

enter image description here

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.

\$\endgroup\$
  • 1
    \$\begingroup\$ It seems that the only problem you have about having a large gameObject made by smaller pieces is the tidiness of the hierarchy, whereas the advantage is that you could have gains in terms of performance. If making several smaller piece or just a large one takes relatively the same amount of time for you, I would go for the smaller pieces. To keep your hierarchy tidy then, you can create an empty gameObject in which will put all the chunks of the mountain. \$\endgroup\$ – FSic Oct 10 at 7:01
  • 1
    \$\begingroup\$ This sounds like something you can quickly try both ways and profile the results to find out which one works better in your game context. This answer will be much more reliable than the opinions of Internet strangers, because it's empirically measured in your specific game on your target hardware — something we can only speculate about. \$\endgroup\$ – DMGregory Oct 10 at 10:25
  • \$\begingroup\$ Good points, I'll try to get over hierarchy content and try either approach that works best. \$\endgroup\$ – Aybe Oct 10 at 18:15
2
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ Quite a couple of things I didn't expect but definitely makes point, and you are absolutely right in your last paragraph, thanks :) \$\endgroup\$ – Aybe Oct 10 at 18:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.