WebGL warning when binding procedural texture to postprocess

Bugs
1

Hello everyone,

I have been trying for a few hours to bind a procedural texture to a postprocess and I kept getting strange results.

When binding the procedural texture to the postprocess, I sometimes get a warning from WebGL:

WebGL: INVALID_OPERATION: uniform1i: location not for current program

I tried changing the texture to a regular texture and the warning went away. Everytime I used the procedural texture it would keep randomly showing this warning, which in my project actually had the effect of messing with my other texture samplers.

I made a small repro, but the bug is unreliable it seems. It arises often on Chromium and Brave but never on Firefox somehow :thinking: I only tested in on Ubuntu 23.10.

Can anyone tell me if they also see the warning, or if it is just a problem with my config?

2

I can not see the warning :frowning: I wonder if it could be a timing issue like the texture not being ready when rendering first for instance.

3

Well I guess the bug is on me. Is there a way to force the texture to render before I bind it?

4

scene.executeWhenReady(callback) would be a good test

5

That fixed it! Here is the updated PG: https://playground.babylonjs.com/#DAC1WM#274

Thank you!!!

1 Like
6

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:

7

You should also create the post process when everything is ready or you will use it without texture resulting in the warning.

I am also adding a helper to execute code when the procedural texture will be ready:

Once deployed, this code should work:

1 Like
8

Thank you for the PR! I am eager to use it soon ^^ I have a good feeling that this is finally solved!

1 Like