1
\$\begingroup\$

I have a large urban area in 3D (Unity), where some models or geometries are repeatedly placed. For instance, we have vegetation objects like trees, grass, or bushes that are positioned in various areas on the floor. These objects share the same geometry, but sometimes they have different sizes when placed in 3D.

My question is whether the size of these repeated geometries is directly proportional to their usage. In other words, as I place more trees with their Levels of Detail (LoD), the overall memory size and player size increase. Is there any way to restrict the size of the player or memory, given the context that I have a large number of objects that are repeating?

Edit: Here is the memory screenshot: enter image description here

\$\endgroup\$
2
  • \$\begingroup\$ How are you placing these objects? As separate Game Objects in a Unity scene, or as separate sub-objects in a combined environment mesh in your 3D modelling software? \$\endgroup\$
    – DMGregory
    Commented Dec 28, 2023 at 11:05
  • \$\begingroup\$ I have set of prefabs that i instantiate on the editor mode. They are seperate objects for trees, bushes, grass. No combine objects. \$\endgroup\$ Commented Dec 29, 2023 at 5:37

1 Answer 1

2
\$\begingroup\$

When you have several copies of a mesh in your scene, Unity does not store several copies of the complete mesh data.

Only one mesh asset is stored in memory or in your build (possibly containing multiple LODs), and the instances just reference this asset. These instance objects store their own distinct position/orientation/scale data (a matter of bytes' worth), but this is applied "just in time" on the GPU during rendering instead of demanding a whole transformed copy of the vertex data.

So, generally speaking, placing more copies of an object does not increase the amount of memory used to store their geometry.

The exception to this is if the objects get baked together as a batch to reduce draw calls.

If these objects are marked as "static", Unity can bake several copies together into one larger mesh to store in the scene, reducing draw calls for faster rendering, at the cost of larger memory/build size.

Batching can also be done dynamically, which would increase video RAM use but not increase build size.

You can disable batching on the material the vegetation uses if you want to prevent this from happening, even when the engine calculates that it would be advantageous to your framerate.

If the vegetation items are using the exact same mesh and the materials used support instancing, then the engine should render them with instancing instead of dynamic batching anyway, since that achieves similar draw call reduction without the same memory overhead.

\$\endgroup\$
2
  • \$\begingroup\$ Thank you very much for the insight. I will test and get back to you soon. \$\endgroup\$ Commented Dec 30, 2023 at 12:27
  • \$\begingroup\$ I profiled the memory and found that the mesh itself is not a problem. However, thousands of meshes rendered, transformed, LOD groups, and game objects are taking up space, even though they are in kilobytes or bytes individually. In total size, it somewhat reaches gigabytes. But that is understandable. Within 2 or 3 gigabytes it maybe acceptable. But I noticed 'untracked' memory in the memory profiler, which is the issue. \$\endgroup\$ Commented Jan 9 at 5:40

You must log in to answer this question.

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