11
\$\begingroup\$

Here is the corresponding Unity documentation.

According to explanations of Unity documantation pages about Static GameObjects, sometimes marking GameObjects as static may effect performance in a bad way (for example Static Batching causes more memory usage).

So when should i exactly want to use these functionalities?

Thanks in advance.

Footnotes:
I'm currently developing a 2D top-down game which has lots of Sprites and LineRenderers, but no 3D objects (not even a quad). All GameObjects are being instantiated procedurally from premade prefabs. LineRenderers get updated from scripts each frame. And nearly all Sprites are moving constantly. Majority of Sprites share same material. All LineRenderers also share same material of their own.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ NOT FOR TREES IN FORESTS. We got bitten by that bad. LONG build times, MASSIVE data in your levels. Note: the docs on this specifically call out that you should not use it for forests. :) \$\endgroup\$
    – Almo
    Feb 18, 2016 at 22:12
  • \$\begingroup\$ @Almo I'm with boy, can understand this pain \$\endgroup\$ Feb 18, 2016 at 22:23

2 Answers 2

8
\$\begingroup\$

There is no hard rule about when you should or should not make GameObjects static.

At the very least, only do it for objects that will never move in their lifetime. But you have to know what it does to evaluate whether or not you should.

It freezes the mesh into the scene data, so you don't have the overhead of the GameObject for the item. This means a performance boost at the cost of altering the scene data at build time and extra memory cost for the final built application.

This is fine in many cases, though it can cause problems, for example with forests. Also, it means that instead of storing the verts for the tree once and the GPU drawing copies, it has to duplicate those verts all over the place. That takes time during the build, and space in the app. Our app went from 3-4 GB to 300-400 MB when we made the trees not static. Build time went from 3-4 hours to 1 hour.

Having said all that! Your game is 2d, and would probably benefit from setting GameObjects in scenes to static, provided you don't have tons of them.

\$\endgroup\$
3
  • \$\begingroup\$ Isn't making prefab static makes instances static too? \$\endgroup\$ Feb 19, 2016 at 0:23
  • \$\begingroup\$ Not if you instantiate them at runtime... How can those be "static"? Maybe I'm wrong... Will check. \$\endgroup\$
    – Almo
    Feb 19, 2016 at 3:02
  • 2
    \$\begingroup\$ I have just confirmed that, if prefab is marked as static, instantiated instances are being static too. \$\endgroup\$ Feb 20, 2016 at 13:57
1
\$\begingroup\$

If I say in general then Everything which is gonna never move (not even a pixel) in whole app life should mark as static. Usually it is useful for baking lights, baking navmesh paths, so on..

Well, if you are developing with no 3D objects then just relax and get chilled. No need to worry about realtime rendering, shadows or any other issues. Even delete the only light comes with new scene ;)

Well, anybody can correct me if I'm wrong at any place.

\$\endgroup\$
5
  • 3
    \$\begingroup\$ This is really wrong for stuff like forests. It reduces drawcalls... but it bakes all the trees into the mesh. The means that instead of storing the verts for the tree once and the GPU drawing copies, it has to duplicate those verts all over the place. That takes time during the build, and space in the app. Our app went from 3-4 GB to 300-400 MB when we made the trees not static. \$\endgroup\$
    – Almo
    Feb 18, 2016 at 22:25
  • \$\begingroup\$ @Almo huggggeeeeee difference \$\endgroup\$ Feb 18, 2016 at 22:29
  • \$\begingroup\$ I think you should clarify at the start of your answer that you're recommending this only because it's a 2d game. \$\endgroup\$
    – Almo
    Feb 18, 2016 at 22:30
  • \$\begingroup\$ @Almo Thanks to you, now I think static batching is an harmful thing to touch, like an oven that you can not be sure hot or not. :) \$\endgroup\$ Feb 18, 2016 at 22:32
  • \$\begingroup\$ @Almo feel free to edit this bro, if feel any need of it. Go ahead \$\endgroup\$ Feb 18, 2016 at 22:37

You must log in to answer this question.

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