Hi there, I was wondering is there any quick hack to search entity hierarchy by render asset?
I was dumb enough to forget about batching and there’s more than 1,500 entities sharing 15 models
Any ideas to select all entities that share same asset?
Hi there, I was wondering is there any quick hack to search entity hierarchy by render asset?
I was dumb enough to forget about batching and there’s more than 1,500 entities sharing 15 models
Any ideas to select all entities that share same asset?
You can maybe just select all entities with render asset and add them to a batch? It does not need to be per render asset type.
It doesn’t matter if entities has different asset models and materials?
However, it did a huge impact
Materials 1313 ~> 47
Mesh Instances 1591 ~> 316
Draw calls 1582 ~> 316
Although some collision models are a little inaccurate
All entities rest on the plane that has a world space of 210x210, what should be the correct AABB for batch group?
Thanks
Update: It turns out large AABB drastically increases triangle count once shadows are casted, I wonder what the “golden middle” is between draw calls, triangles and materials count
It does not, the batch group internally automatically creates batches per material.
That’s correct, the larger the batch (based on AABB), the less efficient frustum culling, as whole batch is either in or out. This allows you to balance GPU vs CPU. More triangles to render vs more meshes to submit, and so it depends on your bottleneck.
Gotcha, the scene is very triangle intensive, currently at 450k standing from far away (without shadows enabled) and with shadows enabled getting max 700k at some places without any batching, shadows distance is set to 40, what would be the best option for batching in terms of performance? Thank you
There is no simple answer here. On most devices, 1M triangles is no big deal at all, and most projects are CPU limited and not number of triangles limited. So larger batches are better, as they save CPU cost.
Can confirm these words as just tested and got interesting results.
This PC has relatively old hardware GT630 and Athlon II X3 445
No batching / shadows on:
Looking at all entities far from distance:
Triangles: 500K
Draw Calls: 1900
Fps : Avg 25
Mesh Inst: 1818
Walking trough entities:
Triangles: Up to 700K
Draw Calls: 1900
Fps: Avg 42
Mesh Inst: Below 1818
No batching / shadows off:
Looking at all entities far from distance:
Triangles: 425K
Draw Calls: 1818
Fps : 36
Mesh Inst: 1818
Walking trough entities:
Triangles: Below 425K
Draw Calls: Below 1818
Fps: Avg 59
Mesh Inst: 1818
Batching AABB 100 / shadows on:
Looking at all entities far from distance:
Triangles: 596K
Draw Calls: 218
Fps : Avg 59
Mesh Inst: 152
Walking trough entities:
Triangles: Up to 1.7M
Draw Calls: Up to 400
Fps: Avg 59
Mesh Inst: 152
Batching AABB 100 / shadows off:
Looking at all entities far from distance:
Triangles: 425K
Draw Calls: 152
Fps : Avg 59
Mesh Inst: 152
Walking trough entities:
Triangles: Below 425K
Draw Calls: Below 152
Fps: Avg 59
Mesh Inst: 152
Batching AABB 250 / shadows on:
Looking at all entities far from distance:
Triangles: 1.8M
Draw Calls: 165
Fps : Avg 54
Mesh Inst: 46
Walking trough entities:
Triangles: Up to 2.1M
Draw Calls: Up to 200
Fps: Avg 45
Mesh Inst: 46
Batching AABB 250 / shadows off:
Looking at all entities far from distance:
Triangles: 425K
Draw Calls: 46
Fps : Avg 59
Mesh Inst: 46
Walking trough entities:
Triangles: Little below 425K
Draw Calls: Little below 46
Fps: Avg 59
Mesh Inst: 46
It’s interesting how AABB 100 performed better than 250 on this particular device, probably triangles were too much of to handle
Update: It had to be something else, poped up windows of CPU and GPU usage
GPU usage increases, CPU decreases while AABB size is beeing increased
250 AABB is giving
CPU Usage of 40%
GPU 3D Usage of ~70%
It has to be something else. GeeForce3 released 20 years ago could render few million triangles at 60fps, so your GPU definitely does not struggle with that.
I guess the other aspect is overdraw. If you have lots of small meshes, they sort front to back … and those behind something already rendered are pretty cheap, as the fragment shader is simply skipped.
If your scene is batched, the batches are sorted (and not individual meshes), and so their order is less front to back, and so fragment shader gets to run a lot more … as often mesh behind other gets rendered first.
Thank you for your time and explanations