Skip to content

debounce asset events for scene reloading#20430

Merged
mockersf merged 7 commits intobevyengine:mainfrom
mockersf:debounce-scene-asset-events
Aug 14, 2025
Merged

debounce asset events for scene reloading#20430
mockersf merged 7 commits intobevyengine:mainfrom
mockersf:debounce-scene-asset-events

Conversation

@mockersf
Copy link
Copy Markdown
Member

@mockersf mockersf commented Aug 5, 2025

Objective

Solution

  • Debounce scene asset events so that we ignore modified event happening too quickly after each others

Testing

  • run examples many_foxes or morph_targets

Alternative

I don't think this is a good long term fix, but this should be fixed in the 0.17 and I think alternatives are worse / too complex.

Alternatives are:

  • Revert Fix Scene hot reloading. #18358. Normal scene loading is more important than hot reloading
  • Implement partial asset loading in the asset server and the gltf loader so that when we load file.gltf#Animation0, only the animation data is loaded. This would be a very good change, but too big to do for the 0.17
  • Have the asset server load parent assets only once, even when loading subassets. This would be a good change and less complex, but I think worse than the previous idea and kinda not compatible with it

@mockersf mockersf added this to the 0.17 milestone Aug 5, 2025
@mockersf mockersf added C-Bug An unexpected or incorrect behavior A-Assets Load files from disk to use for things like images, models, and sounds A-Scenes Composing and serializing ECS objects labels Aug 5, 2025
@mockersf mockersf requested review from andriyDev and cart August 5, 2025 18:52
@alice-i-cecile alice-i-cecile added X-Contentious There are nontrivial implications that should be thought through S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Aug 5, 2025
@alice-i-cecile
Copy link
Copy Markdown
Member

Implement partial asset loading in the asset server and the gltf loader so that when we load file.gltf#Animation0, only the animation data is loaded. This would be a very good change, but too big to do for the 0.17

I agree with this: can you make an issue please?

@alice-i-cecile
Copy link
Copy Markdown
Member

I would prefer not to rebreak scene hot reloading, but we definitely need a fix. I have a weak preference to this over reverting, and I think it's better than trying to do a more serious fix now.

@andriyDev
Copy link
Copy Markdown
Contributor

There is already an issue for this partial asset loading problem #12756.

(I will review this when I have time)

Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Copy link
Copy Markdown
Contributor

@andriyDev andriyDev left a comment

Choose a reason for hiding this comment

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

Should we even "fix" this? The problem in the examples is just that they have a system that only ever runs once. Instead, we could change those examples to use the instance ready observer. Practically I would expect most users to be using the observer pattern, and encouraging them to use it would also be good I think.

I'll not block on this, but I think that's my preferred solution.

Copy link
Copy Markdown
Member

@alice-i-cecile alice-i-cecile left a comment

Choose a reason for hiding this comment

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

I agree with @andriyDev's comment about TODOs in the tests and am elevating it to blocking, but otherwise I agree with this strategy.

@alice-i-cecile alice-i-cecile added S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged and removed S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Aug 11, 2025
@mockersf mockersf added S-Needs-Review Needs reviewer attention (from anyone!) to move forward and removed S-Waiting-on-Author The author needs to make changes or address concerns before this can be merged labels Aug 11, 2025
@alice-i-cecile alice-i-cecile removed the S-Needs-Review Needs reviewer attention (from anyone!) to move forward label Aug 11, 2025
@alice-i-cecile alice-i-cecile 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 Aug 11, 2025
@greeble-dev
Copy link
Copy Markdown
Contributor

Should we even "fix" this? The problem in the examples is just that they have a system that only ever runs once. Instead, we could change those examples to use the instance ready observer. Practically I would expect most users to be using the observer pattern, and encouraging them to use it would also be good I think.

I can update the examples - I also think they should be using observers as good practice, separately to this issue. I'll make a PR tomorrow unless anyone objects.

On whether this should even be fixed, as a user I think it should be. The examples are simple - more complex cases might have chains of events running off scene instancing. Having to make that handle "your scenes may spawn twice... sometimes" would be painful.

@mockersf mockersf added this pull request to the merge queue Aug 14, 2025
Merged via the queue into bevyengine:main with commit a22d288 Aug 14, 2025
54 of 55 checks passed
github-merge-queue bot pushed a commit that referenced this pull request Aug 14, 2025
…0531)

## Objective

Change some examples to follow best practices for playing animations,
and as a bonus work around an issue with scenes spawning multiple times.

## Background

Examples that play skeletal animations usually have two steps:

1) Start scene spawning.
2) Play animations after the scene has spawned.

Different examples use different approaches for triggering part 2,
including a scene spawning observer and `Added<AnimationPlayer>`
queries.

The observer approach is arguably best as it's more tightly scoped and
easier for users to extend. The other approaches work in simple examples
but fall down when users want multiple scenes or animations. See #17421
for more detail.

As a bonus, the scene spawning observer works around a current issue
with scenes spawning multiple times - see #20393, #20430. Although
there's an argument that this PR shouldn't land until the issue is
properly fixed, as these examples are a useful test case.

## Solution

Update the `morph_targets` and `many_foxes` examples to use observers.

I also made a few tweaks and fixes to `morph_targets`.

- Fix documentation referring to an `update_weights` feature that isn't
in the example.
- Use the same `AnimationToPlay` component as the `animated_mesh`
example.
- Change the `name_morphs` system to be event driven and print the asset
name.
- This is maybe too complex, but could also be nice for users to c&p
into their app for debugging.

I haven't updated the `animated_mesh_control`, `animated_mesh_events`,
and `animation_masks` examples, which still use
`Added<AnimationPlayer>`.

## Testing

```sh
cargo run --example morph_targets
cargo run --example many_foxes
```
@mockersf
Copy link
Copy Markdown
Member Author

#18358 also introduced a 15% FPS reduction in many_foxes, likely because each fox was spawned several times. This PR fixed that

@andriyDev
Copy link
Copy Markdown
Contributor

andriyDev commented Aug 14, 2025

@mockersf That's very surprising, since hot reloading literally deletes all the entities when hot reloading? I don't see how that would really in such a drastic performance degradation...

If there is such a degradation, that worries me if there are multiple of the scenes spawned...

@mockersf
Copy link
Copy Markdown
Member Author

I haven't investigated why, but it's possible something is not cleaned correctly. At a first glance everything seems OK on entities, so my bet would be on assets. It's possible some assets are not correctly cleaned with rapid spawn/despawn, and may still be present GPU side in multiple copies

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

Labels

A-Assets Load files from disk to use for things like images, models, and sounds A-Scenes Composing and serializing ECS objects C-Bug An unexpected or incorrect behavior S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it X-Contentious There are nontrivial implications that should be thought through

Projects

None yet

Development

Successfully merging this pull request may close these issues.

many_foxes and other animation examples have stopped working

4 participants