cpu bottlneck ?
This has a huge CPU bottleneck in the geometry pass. It's impossible to render 10,000+ meshinfo (or meshgeometry in same buffer) using this approach.
The Problem: The current RenderView implementation in GeometryPasses.cpp only batches draw calls when meshes share identical geometry AND have sequential instance indices. This fails for scenes with diverse, non-sequential geometry where meshes share materials but have different geometry offsets.
Current behavior: Each distinct mesh becomes a separate draw call → thousands of draw calls for large scenes.
Expected behavior: Efficient batching by material/buffer combinations regardless of geometry sequence.
Scene Context:
Setup: Complex assembled structures with 10,000+ unique components
Culling: Basic frustum culling at mesh level is implemented
Geometry: All meshes share common materials but have unique geometry offsets in buffers
Performance: Currently results in 10,000+ individual draw calls despite shared materials
The Challenge: The current sequential-instance batching works for game assets but fails for large-scale visualization where geometry is diverse but materials are shared. This creates a fundamental scalability limit for professional visualization workloads.
Looking For: Guidance on implementing material-based batching that can handle non-sequential geometry while maintaining the existing rendering architecture.