You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
use bevy::{prelude::*, render::draw::OutsideFrustum, tasks::AsyncComputeTaskPool};fnmain(){App::build().add_plugins(DefaultPlugins).add_system(update_chunk_system.system()).add_system_to_stage(CoreStage::PostUpdate,
remesh_chunk_system.system(),).add_startup_system(setup.system()).run();}fnsetup(mutcommands:Commands){// Spawn chunksfor _ in0..5{
commands
.spawn().insert(Chunk{needs_remesh:true});}}structChunk{pubneeds_remesh:bool,}fnupdate_chunk_system(mutchunk_query:Query<&mutChunk>,){formut chunk in chunk_query.iter_mut(){
chunk.needs_remesh = true;}}fnremesh_chunk_system(mutchunk_query:Query<&mutChunk,Without<OutsideFrustum>>,task_pool:Res<AsyncComputeTaskPool>,){
chunk_query.par_for_each_mut(&task_pool,4, |mut chunk| {if !chunk.needs_remesh{// This code should NEVER run, since update_chunk_system is// setting needs_remesh back to true EVERY frame... BUT IT DOES. WHY?// Seems like this iteration may be somehow being run multiple times each frame, which it shouldn't.// This ONLY happens when:// * The number of chunks is higher than the batch size// * The Without<OutsideFrustum> query filter is present in the Query// ... even more strangely, it ONLY seems to happen if the component being// filtered on is OutsideFrustum. I tried replacing it with a custom// component that would never be present on the entity, and the issue// went away.dbg!("NOREM");return;}// REMESH HAPPENS HERE// Set needs_remesh back to false
chunk.needs_remesh = false;});}
What you expected to happen
chunk_query.par_for_each_mut() should execute its closure once, and only once per frame for each chunk entity, meaning that NOREM should never be printed, since needs_remesh is always being set back to true by the update_chunk_system.
What actually happened
NOREM gets printed constantly, presumably meaning that chunk_query.par_for_each_mut() is executing its closure multiple times on the same entity each frame because otherwise needs_remesh should always be true on every entity every time this system runs.
Additional information
This issue seems to happen only under very specific circumstances. The criteria I've been able to nail down so far are:
The number of entities being iterated MUST be higher than the batch size used
The Without<OutsideFrustum> query filter MUST be present. I tried replacing it with a custom component, and the issue was no longer happening. I have no idea why or how OutsideFrustum is special in this context, it just happened to be what I was checking for in the project I encountered the issue in, where I was using it to avoid remeshing chunks that are not being rendered.
The text was updated successfully, but these errors were encountered:
Bevy version
v0.5.0
Operating system & version
Windows 10 20H2
What you did
What you expected to happen
chunk_query.par_for_each_mut() should execute its closure once, and only once per frame for each chunk entity, meaning that NOREM should never be printed, since needs_remesh is always being set back to true by the update_chunk_system.
What actually happened
NOREM gets printed constantly, presumably meaning that chunk_query.par_for_each_mut() is executing its closure multiple times on the same entity each frame because otherwise needs_remesh should always be true on every entity every time this system runs.
Additional information
This issue seems to happen only under very specific circumstances. The criteria I've been able to nail down so far are:
Without<OutsideFrustum>
query filter MUST be present. I tried replacing it with a custom component, and the issue was no longer happening. I have no idea why or how OutsideFrustum is special in this context, it just happened to be what I was checking for in the project I encountered the issue in, where I was using it to avoid remeshing chunks that are not being rendered.The text was updated successfully, but these errors were encountered: