I just figured this out, and as the manual does not state it explicitly, i share it here:
i have a few thousand gameobjects
they all use one of about 20 meshes (shared)
they all use the same material
the shader is gpu instancing enabled
Problem:
they batch, but as the share the same material and different meshes, the batch gets ‘confused’ ending up in a very fragmented batch - e.g. 1000 batches with 10000 gameobjects total.
Solution:
Each of the 20 meshes needs its own material, now the batch ratio is approx 100 batches to 10000 gameobjects
Also swapping the meshes and materials on the fly doesn’t seem to have a good effect on the batch - seems its better to destroy and recreate a Gameobject - still investigating this…
Summary - when using different meshes with the same material and gpu instancing you get bad batching performance, create one material per shared mesh
edit: the ratios are not absolute, as it depends on the objects visible in the frustum, the real batching size depends on the pipeline and shader settings (between 100 and 500) - still it gives an idea of whats going on
a bit more info: i am using materialpropertyblocks to define the light - some homebrew spherical harmonics, 24 values per instance
osx, el capitan, opengl 4.1
That’s pretty bad. Maybe the instancing doesn’t sort per mesh after sorting per material, that would roughly create these numbers. You’ll need someone from unity’s rendering team to look at it, try creating a bug report showing this.
Otherwise, have a free bump and hope for one to see it here
We do sort by geometries after sorting by materials, so manually create a unique material for each mesh shouldn’t make much difference unless your materials have different render queues.
Can we have your test project so that we can take a deeper look into your use case?
I don’t know if creating a material for each mesh would resolve it in my case as I can’t go that route, but I confirm that many identical objects are not instanced.
In the frame debugger, I can easily see that the same object is sometimes instanced and sometimes not. And some objects are not instanced at all even if they should.
What could be the reason?
I don’t want to go out of topic but I just realized that some of the objects that were not working have inverted scaling. I thought that wasn’t a problem, as in the documentation is not reported. Is it a bug or is by design?
About the scaling issue I submitted a but report and Unity QA told that has been already resolved and a fix should appear in the upcoming 5.6 version of Unity.
Sorry to necro this - I have a similiar situation with builtin RP in 2021.2 with lots of objects with two types of meshes, sharing the same transparent shader.
When I use the same material for all of them I get this “why this draw call can’t be batched with the previous one”- message:
“Rendering different meshes with GPU instancing”
On the other way round - when I’m using two seperate materials for both objects the message states
“Objects have different materials”
This is due to the order of the objects in the frame debugger.
So I tried setting the RenderQueues to Transparent+1 / +2 for each material and the instancing works like charm - but I now have z order issues for the transparent objects due to the different queues.
Is there another way of optimizing the order how the objects appear in the frame debugger so that they can share the same RenderQueue to objects being rendered on top of others at the overlapping parts?
DanOtt thank you very much for your advice regarding the Render Queue. I had the same issue with instancing on Unity 2020.3.10 and UPR, and now it’s been resolved by assigning different render queues for materials of each type of mesh
