8
\$\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.

|improve this question
\$\endgroup\$
  • 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 '16 at 22:12
  • \$\begingroup\$ @Almo I'm with boy, can understand this pain \$\endgroup\$ – Hamza Hasan Feb 18 '16 at 22:23
5
\$\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.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ Isn't making prefab static makes instances static too? \$\endgroup\$ – S. Tarık Çetin Feb 19 '16 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 '16 at 3:02
  • 2
    \$\begingroup\$ I have just confirmed that, if prefab is marked as static, instantiated instances are being static too. \$\endgroup\$ – S. Tarık Çetin Feb 20 '16 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.

|improve this answer
\$\endgroup\$
  • 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 '16 at 22:25
  • \$\begingroup\$ @Almo huggggeeeeee difference \$\endgroup\$ – Hamza Hasan Feb 18 '16 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 '16 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\$ – S. Tarık Çetin Feb 18 '16 at 22:32
  • \$\begingroup\$ @Almo feel free to edit this bro, if feel any need of it. Go ahead \$\endgroup\$ – Hamza Hasan Feb 18 '16 at 22:37

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.