Starting with Babylon.js version 7.20.0 (the latest at the time of writing),
using depth of field in DefaultRenderingPipeline fails to load the shader and cause an error.
It looks like @Deltakosh already added support for loading async shader source to the PostProcess class.
However, PostProcess’s updateEffect is a method that synchronously calls createEffect,
which is executed by the subclass or object it references and attempts to compile the shader before the shader source is loaded.
This is also why the depth of field post process doesn’t work.
I’ve seen code around PostProcess.updateEffect to address this, but it feels like the current approach to supporting WGSL is that programming to account for asynchronous processing will propagate from the bottom to the top of the engine.
If you’ve seen this result from searching the repository source for “_initShaderSourceAsync”, you know what I’m talking about.
In order for Babylon.js to support wgsl code in a sustainable and simple way, it would be nice to take async import promise as a parameter in Engine.createEffect and end all asynchronous network processes for loading shaders inside the createEffect function.
e.g.
let effect = engine.createEffect(
shaderName,
<IEffectCreationOptions>{
attributes: attribs,
// ...
shaderLoadPromises: [
import("../Shaders/default.vertex"),
import("../Shaders/default.fragment")
]
},
engine
);
Since createEffect already has an implementation that loads and compiles code asynchronously, it should be easy to add an implementation that takes a Promise as a parameter.
Nevertheless, I wonder why the “_initShaderSourceAsync” mechanism was adopted. Was there a reason why createEffect couldn’t be made to take a Promise as a parameter?
