Skip to content

cpu bottlneck ? #37

Description

@dddd545r

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions