Conclusion on Unity Instancing API (2022) Testing:
1.Regardless of whether using DrawMeshInstanced or RenderMeshInstanced, both are limited by the underlying InstanceCount per batch. Currently, it is not possible to draw 1023 instances in a single batch. For Vulkan and PC, it requires two batches, while GLES3.0 requires nine batches.
2.If SRPBatch is enabled, it will forcibly override AutoInstance(only with the Material checkbox checked). It takes precedence over AutoInstance, presumably because Unity considers it to have better performance.
3.When using AutoInstance (only with the Material checkbox checked), it automatically performs instance batching. The result appears similar to DrawMeshInstanced, and it can also automatically handle culling. In this case, the necessity of ManualInstance (DrawMeshInstanced or RenderMeshInstanced) is questioned.Perhaps using JobSystem to asynchronously perform PerInstanceCulling might be a better alternative.
4.The order of preference is SRPBatch > AutoInstance > DynamicBatch.
5.ManualInstance (DrawMeshInstanced or RenderMeshInstanced) is completely independent of SRPBatch.
6.If there are PerInstance properties (apart from transform attributes), ManualInstance + PropertyBlock is still required.
7.Currently, DrawMeshInstancedIndirect + GPU culling + result RenderTexture seems to be the most advantageous for rendering a large quantity of the same Mesh.
If there are any errors, I appreciate feedback from experts. Thank you.
Thank you for sharing. It is useful and make sense of Unity instancing solutions.
回覆刪除It seems that while RenderMeshInstanced provides support for NativeArray, the MaterialPropertyBlock it uses doesn't have native container support. This feels somewhat incomplete and affects the willingness to substitute for DrawMeshInstanced...
回覆刪除