Force recompile ProcedualTexture after updating #defines

Questions
, ,
1

Can a ProceduralTexture be forced to recompile with updated defines?

I’ve tried a lot of things in various combinations.

// t is the NormalMapProceduralTexture
// mat is the StandardMaterial
t.defines="#define SOBEL"
t.resetRefreshCounter();
t.reset();
(t as any)._setEffect(null);
(t as any)._cachedDefines = null;
mat.markAsDirty(StandardMaterial.TextureDirtyFlag);

I can retrieve the Effect with t.getEffect());

I see that EffectWrapper has .updateEffect() but the Effect is within a DrawWrapper that doesn’t have anything similar (and neither does Effect itself).

I think I only need to recompile the fragment from Effect.fragmentSourceCodeBeforeMigration

The fragment is initialized from a file and doesn’t need to be retrieved again, just recompiled after changing the #defines.

2

You should be able to call reset() to have the effect rebuilt with your new settings.

3

I’ll have to build a sharable repro. When refreshRate is non-zero, the NormalMapProceduralTexture appears to update on its own, without reset().

When refreshRate is 0, I can’t figure out the right sequence for updating. reset() does appear mostly work, but I think there’s a race condition somewhere. I change defines on setInterval every 10 seconds. I saw the main gui on the AdvancedDynamicTexture appear on the NormalMapProceduralTexture during one of the updates.

With refreshRate = 0, in one trial, checking .isReady() immediately after setting .defines, a false seems to correlate to a failure to update. A “failure” is either 1) no visual update, or 2) visual updated to the GUI/AdvancedDynamicTexture.

I’ll keep investigating and provide a repro Playground when I get some time.

1 Like
4

I reimplemented with ProceduralTexture (thank you for the fragmentSource option!)

I am not seeing the same issues. It seems to work great!

My original test had a lot going on and I used the NormalMapProceduralTexture. It’s possible either contributed to the errors I saw. If I get a chance to dig into it and find the problem, I’ll report back.

This playground uses a refreshRate of 0 and only calls resetRefreshCounter() after setting defines. The first cycle through (5 different defines values), there are slight visual glicthes, presumably as a result of the compiling. After the first cycle, the remaining changes are seamless. The differences are subtle, but can be made solid colors by changing the code line TESTCOLOR = true.

https://playground.babylonjs.com/#OYC4R8

5

Exactly, it’s because the new effect isn’t ready until a few frames in, so the texture can’t be bound to the sphere’s shader. You should create all the textures in advance and only switch to one of them when it’s ready if you want to get rid of the flickering.

1 Like