Add NoiseTextureGenerator singleton #110765
Open
+610
−133
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Adds
NoiseTextureGenerator
singleton to facilitate the baking of noise textures using existing threads from theWorkerThreadPool
when available.Previously each single
NoiseTexture2D/3D
created its own dedicatedThread
, which was neither efficient or performant.This fresh thread creation made it more or less performance impossible to use noise textures at runtime when not hidden behind a loading screen. The thread-spawn alone would cause stutters to no end on all platforms with a higher thread-spawn costs like Windows. Having so many additional threads running next to the actual WorkerThreadPool max thread count caused a lot of thread congestion when many noise textures were used.
This PR removes the dedicated
Thread
fromNoiseTexture2D/3D
and makes them useWorkerThreadPool
threads to bake noise images. Because this requires additional bookkeeping and thread synchronization work a newNoiseTextureGenerator
singleton was added.Note that there is no elegant hook option with the main loop to do thread synchronization for optional modules like the noise module. To solve this I decided to piggyback on the RenderingServer
frame_pre_draw
signal for thread synchronization. The reason I did not pick a SceneTree signal for this (like some other resources and nodes do) is because not every main loop is always a SceneTree, so those signals might not be available at all.Using the
frame_pre_draw
signal also allows to sync all the noise bakes that users kicked off in script and that might have been finished quickly by the time the RenderingServer starts its own sync and frame thing. This gives less window to run into issues with async baked noise textures being already baked so the duplicated bake attempts get blocked. Keeping the wait window small is important because all the noise resources have this awkward implementation of using the deferred queue for auto updates that users can't really stop from triggering.Note that this largely copies the bake logic of the navigation mesh generator, except for the new signal and deferred quirks that are specific to the noise module and resources.