Newbie question: when should we use static gameobject? or when should we mark gameobject as static?

The definition "game object don't move" is never clear to me.

What about the following circumstances?

- It's a game object prefab, and I instantiate this game object to anywhere, they have the same setup, means same shader, maybe different texture with same material, the position they inititated have different light condition, but it won't physically change world position at all. Should I mark the prefab static game object? should I mark the generated game object static?
- In the above circumstance, what about change the transform scale and rotation?
- If a game object changed it's scale, position and rotation, but after that it won't move anymore in its lifetime (runtime), can I mark it static?
- Under the static menu, there are many "static" markers for different engine parts. Is there any document for them?

I think the basic question is, what is considered "game object moved"?

 

When you alter the transform or rendering components in any way. The most common cases are when you change position, rotation, or scale, or alter the mesh, material, or shader.

For most types of static objects, yes. Static objects get batched together so they can render quickly. When a static object "moves", it must update the data in the batch, which is a slow process, but does not need to be done again unless the object moves again.

Some static flags, such as "Lightmap static" and "Navigation static", create "baked" results, which will only update when you tell them to. So, for example, if you move a "lightmap static" object after you bake the light map, the lights/shadows for that object will act as though it's still in it's original spot during the bake.

Yes. Generally speaking, when people talk about static objects without additional context, they are talking about "batching static", which is where static objects get batched together so they can be rendered together. A quick google search of any static flag should help you identify what it does. About half of them are used to improve rendering performance, and the other half are used for baking things like lightmaps for non-realtime lighting and nav meshes for pathfinding.

 

Thanks. One more question: for static batching, if there is only 1 game objects that doesn't move, and it will be instantiated in runtime (means not contained in the scene), and it constantly change its texture (for example movie texture), do I need to mark this gameobject static batching if everything else are dynamic?

 

I don't think you will get much out of static batching if it's only one object, unless you create many copies of that object. I don't think it's a good idea to mark it static if it's texture will be changing, but I'm not sure. You could test it with a profiler to see if it renders faster as static.

Also, marking things static isn't really that much of an improvement unless you've got a large scene with many non-moving props. Rendering 100 static bushes as 1 giant batch is much faster than rendering 100 bushes separately, but rendering 3 cubes as a static batch isn't much faster than just rendering the 3 cubes separately.

 

Hey! Thanks for the answer, things are more clear to me now!
However I have a final question if anyone is able to answer it, I'd like to know, let's imagine a big part of the scene is a prefab that will be instantiated, so the objects are not present in the scene at the start (So I guess I can't use it for baked lightmaps), is it of any help to mark the objects of the prefab as statics? (because they will, in fact, not move once instantiated)

Thanks in advance !