why this draw call can‘t be batched with the previous one for Unity2019.4+

why this draw call can't be batched with the previous one  for Unity2019.4+

• Objects either have different shadow caster shaders, or have different shader properties/keywords that affect the output of the shadow caster pass.
• Rendering different meshes or submeshes with GPU instancing.
• The material doesn’t have GPU instancing enabled.
• Objects have different batching-static settings.
• Objects have different MaterialPropertyBlock set.
• A submesh we are trying to dynamic-batch has more than 300 vertices.
• Objects have different materials.
• Objects are affected by different reflection probes.
• An object is affected by multiple forward lights.

 

一: A ‘forward light’ is just a light in forward rendering path (probably needs better wording). This means that some of your draw calls appear to be rendered in forward even if the camera is set to deferred. This happens when the shader doesn’t provide a deferred pass (LightMode = Deferred).

https://docs.unity3d.com/ScriptReference/StaticBatchingUtility.Combine.html?_ga=2.29545020.2059876966.1604280744-1914518766.1598939868

二: This depends on your scene. When rendering a scene, Unity sorts all objects (front to back for opaque objects and back to front for transparent objects) and puts them into groups. If your objects happen to be far away along camera forward axis they will end up in different groups and will not be batched.

Opaque objects are sorted by various criteria (sorting layers, shader queues, materials, distance, lightmaps etc.) to maximize both the CPU efficiency (reduce number of state changes and improve draw call batching), and to maximize GPU efficiency (many GPUs prefer rough front-to-back rendering order for faster rejection of invisible surfaces).

By default, opaque objects are grouped in rough front-to-back buckets, on the GPUs where doing that is beneficial. There are GPUs where doing this distance based sorting is not really helpful (most notably, PowerVR/Apple GPUs), and so on these GPUs the distance based sorting is not done by default.

The Camera.opaqueSortMode property lets you override this default behavior. For example, you might want to never do distance-based sorting for opaque objects, if you know you need much more CPU performance than GPU performance.

By default, perspective Cameras sort objects based on distance from Camera position to the object center; and orthographic Cameras sort based on distance along the view direction.

If you're making a 2D game with a perspective Camera, you might want to use TransparencySortMode.Orthographic sort mode so that objects are sorted based on distance along the Camera's view.

///

What breaks batching

Note that you need Unity 5.6 with the updated Frame Debugger to see the batch breaking causes illustrated in this project.

Here are batch breaking causes from the sample project (as of Unity 5.6). Each says why the object being rendered is in a separate batch:

· Additional Vertex Streams — the object has additional vertex streams set using MeshRenderer.additionalVertexStreams.

· Deferred Objects on Different Lighting Layers — the object is on a different light layer.

· Deferred Objects Split by Shadow Distance — one of the objects is within shadow distance, the other one is not.

· Different Combined Meshes — the object belongs to another combined static mesh.

· Different Custom Properties — the object has a different MaterialProperyBlock set.

· Different Lights — the object is affected by a different forward light.

· Different Materials — the object has a different material.

· Different Reflection Probes — the object is affected by a different reflection probe.

· Different Shadow Caster Hash — the objects either have different shadow caster shaders, or have different shader properties / keywords that affect the output of the shadow caster pass.

· Different Shadow Receiving Settings — the objects either have different “Receive Shadows” settings, or some objects are within the shadow distance, while some other objects are not.

· Different Static Batching Flags — the object has different static batching settings.

· Dynamic Batching Disabled to Avoid Z-Fighting — dynamic batching is turned off in Player Settings or disabled temporarily in the current context to avoid z-fighting.

· Instancing Different Geometries — rendering different meshes or sub-meshes with GPU instancing.

· Lightmapped Objects — the object uses a different light map or has different light map uv transformations within the same light map.

· Lightprobe Affected Objects — the object is affected by different light probes.

· Mixed Sided Mode Shadow Casters — objects have different “Cast Shadows” settings.

· Multipass — the object is using a multi-pass shader.

· Multiple Forward Lights — the object is affected by multiple forward lights.

· Non-instanceable Property Set — non-instanced properties are set for an instanced shader.

· Odd Negative Scaling — the object has odd negative scaling (e.g. (1, -1, 1)).

· Shader Disables Batching — the shader explicitly disables batching with the “DisableBatching” tag.

· Too Many Indices in Dynamic Batch — there are too many indices (more than 32k) in a dynamic batch.

· Too Many Indices in Static Batch — there are too many indices in the combined mesh of a static batch. The limit is 48k indices on OpenGL ES, 32k on OSX and 64k on other platforms.

· Too Many Vertex Attributes for Dynamic Batching — a submesh we are trying to dynamically batch has more than 900 vertex attributes.

· Too Many Vertices for Dynamic Batching — a submesh we are trying to dynamically batch has more than 300 vertices.