koobas.hobune.stream
Can static batching prevent frustum culling?
I am optimizing an iOS project.
In one scene there is a large amount of static batching which combines meshes on opposite sides of the level. At any given position in the level, many of these meshes would be outside the camera's FoV if they were all kept separate.
The CPU is processing in good time, however, the GPU typically takes twice as long to process. Most of this time extra GPU time is spent in Camera.Render->Drawing->Render.OpaqueGeometry.
Is it possible that the static batching (which reduces the number of draw calls in the CPU) is preventing frustum culling and causing the GPU to do more work? I think that this may be the case if meshes which would ordinarily be out of the camera's FoV are combined into a single mesh which is visible to the camera from anywhere in the level.
As a corollary question, does static batching have any benefits for the GPU, or does it only help the CPU by reducing the number of draw calls?
I was reading through the documentation and found the following paragraph which seems to say that static batching does not intefere with culling.
http://docs.unity3d.com/Documentation/ScriptReference/StaticBatchingUtility.html "By calling one of the Combine methods you will create an internal mesh which will contain combined geometry, however each original GameObject will be present in the scene and will be culled individually. The fact that GameObjects can be culled individually allows run-time to render the same amount of geometry as it would without batching, unlike combining geometry in the modeling tool. Combining geometry in the modeling tool prevents efficient culling and results in much higher amount of geometry being rendered."
However, I have used occlusion culling in the same scene, and the results strongly suggest that static batching is preventing occlusion culling. This because the amount of draw calls does not change even after I have baked the occlusion culling.
I believe, but I am unsure, that the documentation is only referring to frustum culling when it says "however each original GameObject will be present in the scene and will be culled individually".
Well, you can't check your draw calls to know if culling is working along with batching. For example, let's consider a "best case" scenario in which you have a scene with 100 objects that all share a material.
Without batching: 100 draw calls if all objects are visible. Or 50 draw calls if half of them are visible. Ok, culling is working!
With batching: 1 draw call if all objects are visible. Or 1 draw call if half are visible. Or 1 draw call if any portion is visible. With the objects batched together, you'll always have 1 draw call for all of them . (assu$$anonymous$$g the shader used only requires one draw call etc.)
It is my understanding that along with the usual geometry info, the batched version of the geometry also encodes an object index for each vertex allowing the culling system to turn off portions of the batched mesh to match the original, separate, meshes from which the batch was made.
