I'm currently working on a small game that will include somewhat large levels. Each level will have a somewhat large amount of GameObjects lying around as props. I was told by a friend of mine that marking the GameObjects that the map is comprised of as static will improve performance. However, I am aware that this can greatly increase the amount of space the built game takes up on the disk. Does the performance boost gained from marking GameObjects as static outweigh the cost of increased build size? Is there even a performance increase at all?


1 Answer 1


Definitely maybe; this depends on things like the overall number and complexity of the objects involved.

Not static:

Draw a 100-vertex model with 1,000 different (constantly-changing) transforms.

  • Approximately 17,200 bytes (1,200 bytes uploaded once)
  • New transforms uploaded every frame (approximately 16,000 bytes)
  • More objects creates more overhead (during render), linearly
  • Additional math every frame (transforming normals for lighting, etc.)


Since this object won't move ever, copy and transform the 100 vertices, 1000 times, into a single vertex buffer. Then, draw the new 100,000-vertex model with one transform. Multiple draw calls may be required to process the entire model but will require few state changes in-between. Since it's already in world-space, the GPU can skip a transform; the normals are already in world-space, for lighting, as well.

  • Approximately 1,200,000 bytes (uploaded once)
  • Performance penalty, once, during baking
  • More objects creates "no" additional overhead (during render)


The "vertex" I used is a single float3 each; if we also include UV's (float2) and normals (float3), the size of each vertex becomes 32 bytes:

The non-static method's memory footprint increases from 17.2KB to 19.2KB (1.1X).

The static method's memory footprint increases from 1.2MB to 3.2MB (2.6X).

The memory size of an additional, non-static, object is 64 bytes for a float4x4 matrix. The actual size Unity uses may be different, but the important point is that it is approximately fixed.

The memory size of an additional, static, object is (VertexCount x VertexSize). This method is not feasible for excessively complex and/or numerous objects.


You must log in to answer this question.

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