Okay, the bug was actually still present, I spent way too many hours finguring this out. Here is a rundown of everything if anyone needs this in the future:
How to (kinda) reproduce
On all chromium browsers (tested with Chromium, Brave, Google Chrome, Google Chrome Unstable), under Ubuntu 23.10, Ubuntu 22.04 and Windows 11, loading this playground: Babylon.js Playground would result in the warning described in my first post.
The crazy thing about this bug is that the warning would generally not display on the first page load.
Reloading the page was needed to trigger the bug. For this playground, multiple reloads are needed to get the bug, as it is quite rare.
As I was able to reproduce the bug on another computer I can say confidently that it is not just my machine.
The frequency of the bug seems related to the size of the project (probably a timing thing as you said so that would make sense), as I could not get it to happen reliably in the playground, and I would get it everytime in my own project.
Exiting the browser and running it again would fix it for only the first page load again.
Explanation of the bug
I had to print the texture raw pixel data to get a clue about what was happeing. When the bug occured,
readPixels returned an array of the right size but filled with 0s. This would not happen when the bug was not triggered.
I concluded that the texture was somehow not rendered, despite having
isReady returning true. I have no idea why that happens sometimes. I looked up the code of
isReady and could not find an easy answer unfortunately.
Fixing the bug
I then went looking for ways to force the texture to render before setting it in the postprocess. I came by this discussion: Generate and Dump a Procedural Texture without Running Render Loop?
The solution proposed was to use
scene.render() and it actually worked! It is not a perfect fix either as it throws an error with WebGPU:
logger.ts:103 BJS - [00:21:28]: WebGPU uncaptured error (1): [object GPUValidationError] - Destroyed texture [Texture] used in a submit.
- While calling [Queue].Submit([[CommandBuffer from CommandEncoder "upload"], [CommandBuffer from CommandEncoder "render"]])
If there is a better way to force it to render, please let me know! I tried the
render method of the procedural texture itself but it resulted in an error about the effect not being defined.
That’s got to be the strangest bug I ever got haha
Anyway here the fixed version: