Replies: 1 comment
-
Using the async compute task pool shouldn't completely choke out bevy from running. That task pool only gets 25% of the number of cpus to run tasks by default. Are you blocking on waiting for your |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The situation
I need to generate chunks for my game map. Chunk generation takes around 200ms. It is not an operation that needs to be quickly achieved. And I want my game to be playable while it is generating the chunks.
For this purpose, I am using an AsyncComputeTaskPool that (according to the doc) is "for CPU-intensive work that may span across multiple frames". In which I add one Task for each chunk that needs to be generated.
The issue
Even though the AsyncComputeTaskPool is effectively handling all the generation tasks in a few frames. It is still processing the task too quickly to not induce a significant FPS drop while generating a chunk. I would like to know if there is a way to limit the time given to the AsyncComputeTaskPool to run its tasks. I would like to tell Bevy "Spend a maximum of 10ms running the tasks in this compute pool each frame" or to be able to tag my task as "Low priority" or to force Bevy to run it in a fully separated thread.
Potential cause
I do know exactly how futures work in Rust and my chunk generation task is looking like this:
the generate_tree and generate_mesh functions are async but the expensive calculations they make are just written like a classic program would be. It may force the TaskPool to execute the generate_tree and the generate_mesh function in only one frame.
Beta Was this translation helpful? Give feedback.
All reactions