I have a decent number of heavy models in my scene - I’d like to be able to see which of the models are hitting the GPU the hardest.
I’ve tried turning them off one by one and watching the profiler, but it hasn’t been useful.
Like in the build report from builds, I’d like to see a list of the highest impacting models like the report does for textures, sounds and such.
Since isolating models one by one in the profiler didn’t yield helpful results, you could try using the frame debugger to step through rendering a typical frame step by step. It’s a fascinating tool that I don’t see mentioned very often. I always find it interesting to step through the rendering process step by step and see how many draw calls you’re dealing with and how much overdraw there is and things like that. You might get some kind of clues about performance just by watching what the GPU is actually doing one step at a time.
Frame debugger is helpful although I’m using URP and many models get SRP batched together. It is a great tool though I love using it.
I’ve resorted to opening every model in Maya, checking the Game Vertex count and cleaning up unneeded secondary UV channels that were doubling and tripling overall vertex count. I’ve also turned off exporting Tangents and Binormals for the FBXs to save on memory since all of my materials have tiled normal maps.
The problem with the single-model-measurement approach is that it’s an artificial test. The hardware can 100% focus on rendering that one mesh and this is unlikely to put any pressure on any subsystem, so they just rock through it.
I would recommend to write a script that puts 10, 100, 1000 instances of the mesh in the scene and measure that. Just so many that the fastest mesh barely scratches the 60 fps mark. Then you have a baseline that you can immediately grasp from a single number.
Something like this:
100 Meshes “A” => 55 fps
100 Meshes “B” => 49 fps
100 Meshes “C” => 23 fps
100 Meshes “D” => 12 fps
You’ll quickly see which ones are worth optimizing and which aren’t.
But note that even this test may be off because, let’s say Mesh “D” would extremely benefit from instanced rendering but it’s not enabled, so enabling instancing could make it a couple factors faster without having to change the mesh. Or Mesh “D” is only ever used as a single mesh in a small isolated area, so it wouldn’t hurt performance as much as Mesh “C” that’s used dozens of times everywhere.