Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

many_cubes: Add no automatic batching and generation of different meshes #12363

Conversation

superdump
Copy link
Contributor

@superdump superdump commented Mar 7, 2024

Objective

  • Enable stressing of more of the material mesh entity draw code paths

Solution

  • Support generation of a number of different mesh assets from the built-in primitives, and select randomly from them. This breaks batches based on different meshes.
  • Support disabling automatic batching. This skips the batching cost at the expense of stressing render pass draw command encoding.
  • Support enabling directional light cascaded shadow mapping - this is commonly a big source of slow down in normal scenes.

@superdump superdump added A-Rendering Drawing game state to the screen C-Performance A change motivated by improving speed, memory usage or compile times labels Mar 7, 2024
std::iter::repeat_with(|| {
let radius = radius_rng.gen_range(0.25f32..=0.75f32);
let (handle, transform) = match variant % 15 {
0 => (
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't you want to only vary the uniqueness of the mesh and not the overall triangle count? Couldn't you use a bunch of separate instances of same-size cubes?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could, but I'd like to use a variety of meshes as well. As they are randomly distributed, the per-frame draws should be fairly consistent, if that's what you're concerned about?

Copy link
Contributor

@rparrett rparrett Mar 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The concern is mainly "changing more than one variable in an experiment."

This switch adds a bunch of triangles to the scene, in addition to making the mesh assets unique. So it seems like like comparisons between runs where this switch is enabled and not enabled would not be useful.

I had assumed based on (from PR description):

This breaks batches based on different meshes.

That just making the assets unique was the main goal.

If that's not the case or not a worry, then I guess I'm not bothered.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My goal was not really to compare single mesh vs many meshes, rather just to create a scene with a bunch of different meshes. The benchmarking is done by using the same configuration of the stress test with two versions of the code.

@superdump superdump force-pushed the many_cubes-shadows-no_auto_batching-meshes-orientations branch from 5043487 to 49a00bc Compare March 12, 2024 10:24
@robtfm robtfm self-assigned this Mar 18, 2024
@robtfm robtfm self-requested a review March 18, 2024 16:18
@robtfm robtfm removed their assignment Mar 18, 2024
}

// camera
commands.spawn(Camera3dBundle::default());
// Inside-out box around the meshes onto which shadows are cast (though you cannot see them...)
commands.spawn((
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand what this does.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It spawns a box that all the other cubes fit within. It was meant to be just a surface for the cubes to cast shadows on. But because of the camera position, the shadows don’t seem to be visible, as far as I can tell.

@james7132 james7132 added the S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it label Mar 29, 2024
@superdump superdump added this pull request to the merge queue Apr 1, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Apr 1, 2024
Co-authored-by: François Mockers <francois.mockers@vleue.com>
@alice-i-cecile alice-i-cecile added this pull request to the merge queue Apr 1, 2024
Merged via the queue into bevyengine:main with commit d0a5dda Apr 1, 2024
27 checks passed
chompaa pushed a commit to chompaa/bevy that referenced this pull request Apr 5, 2024
…hes (bevyengine#12363)

# Objective

- Enable stressing of more of the material mesh entity draw code paths

## Solution

- Support generation of a number of different mesh assets from the
built-in primitives, and select randomly from them. This breaks batches
based on different meshes.
- Support disabling automatic batching. This skips the batching cost at
the expense of stressing render pass draw command encoding.
- Support enabling directional light cascaded shadow mapping - this is
commonly a big source of slow down in normal scenes.

---------

Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Co-authored-by: François Mockers <francois.mockers@vleue.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen C-Performance A change motivated by improving speed, memory usage or compile times S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants