I’ve recently been learning @MackeyK24 's excellent Unity Exporter.
I was wondering if there is currently support for WebGPU, because while I’ve been able to build using the WebGPU option, I haven’t been able to play on Canary.
Getting the following error, “Cannot read properties of undefined (reading 'colorAttachments)”
Also saying hi, BabylonJS is great, just found out about it, loving it so far
I was also getting that, figured it was something in the current build of BJS.
I’ll do some more testing tonight. I tried testing on windows, same issue.
I’ll let you know if i find anything
Can you try with Chrome dev (Google Chrome Developer Tools - Google Chrome)?
It seems in the latest version of canary they added some checks that make some PGs to fail (for eg: https://playground.babylonjs.com/#YX6IB8#31) but I can’t debug for the time being because my Canary does not work anymore locally (it seems there’s a bug in Canary: 1276536 - chromium - An open-source project to help move the web forward. - Monorail)
[EDIT] It seems the problem is related to using storage textures in compute shaders, so likely not your problem. I would need a repro to try to figure it out. Note that you must use Canary and not regular Chrome because the latter is not up to date and we are using an API which is not in this version yet (in this PG you will get the error “Invalid destination gpu texture format.” in regular Chrome).
I just did a little debugging in electron. The webgpu breaking change is somewhere in chromium 97. Electron 17.0.0-alpha.3 and below work, 17a.4 to 18-nightly all break, as in completely blank white screen. Lower versions still work though, although the ocean shader has some glitchy rendering. see picture below.
I have a feeling the “invalid destination gpu texture format” is related to using integers in babylon’s glsl without the flat keyword , which causes the resulting wgsl shader to not include [interpolate(flat)]
ie:
struct Actual {
[[location(1)]] z: u32;
};
struct Expected {
[[location(1),interpolate(flat)]] z: u32;
};
I suspect either using flat or changing the glsl to floats (if possible) could fix the shader compiler error.
I think they are added when using the [“OES_standard_derivatives”] for opengl
Edit. Originally was asking if configuring fragment target was required but it seems not. see evgeni post below.
i tried to fix up an electron repo for you evgeni, but i couldn’t get the renderer to stop bugging out. I just realized the playground is doing it too, and i think it must be that the glslang wasm file is hard coded to latest preview, because babylon 5.00-alpha.40 used to work in chromium 96, but now it doesnt .
Renders like this in electron too, using babylon 5.0.0-alpha.63 and electron v14 through v17.0.0-alpha.3. Babylon 5.0.0-alpha.40 worked about a week ago showing the full ocean demo in electron, but no longer does, even when using a deterministic version of chromium.
Is there a way to configure babylon to use a local version of glslang.wasm?
regular chrome
Devtools wont even connect in chromium 97. Just blank everything. Only thing I changed was the electron version, which bumps chromium from 96 to 97.
PLOT TWIST. This is canary
although the ocean seems to have frozen over, maybe its just in time for a merry gpu compute santa adventure?!
I have a feeling the “invalid destination gpu texture format” is related to using integers in babylon’s glsl without the flat keyword
No, the problem with this one is that we are now using copyExternalImageToTexture instead of copyBitmapToTexture (which is deprecated) because it is fully implemented in Canary: it was lacking the support of some texture formats until some days ago, that’s why we switched using this method (which exists for some months now) only lately. But Chrome prod is lagging behind in this regard, hence the error message.
The Ocean demo does not work because we create a texture view with numMipMaps > 1 for some of the storage textures. You can make it work again (in Canary) by removing the mipmaps generation for the derivatives/turbulence textures: https://playground.babylonjs.com/#YX6IB8#33. However, you get some more aliasing in the distance because of this change. Once my local Canary works again I will properly fix the problem and the existing PG will work again.
colorAttachments
Regarding this one I would need a repro because this property is always existing when creating a render pass: it’s a mandatory property of the render pass descriptor. We would get an error from the WebGPU validation layer if that property was missing when calling beginRenderPass.
O captain my captain 
I tried unsuccessfully to find what’s causing this problem playing in WebGPU. I’m wondering if anyone has been able to get it to work in an earlier build, maybe i can try to find out what’s changed.
Not giving up though!
I’d like to help solve this problem but gotta take most of what I say with a grain of salt since I’m still learning.
Using latest [Babylon Toolkit: V5.0.0-A61.1X9]
Unity 2021.2.4f1 (have tried 2020.3, and also OpenGL)
Trying to play a default scene with WebGPU on the latest build of Canary, but I also tried Chrome dev unsuccessfully.
Are you using the latest version of Babylon (alpha 63)?
It definitely works for me in Canary, except for the bug I have explained regarding the Ocean demo but you won’t likely never experience it elsewhere because it is linked to storage textures (so you need to use compute shaders to be able to see it) and it will be fixed shortly (tomorrow).
Ok, sorry if this is a dumb question, but do you think my issue is that the Babylon Toolkit is using an earlier version? I’m taking a guess that it’s using Alpha 61 based on it’s name. I installed the latest preview version and have alpha 63 set in the dependencies for package.json
however, when i try to build from the editor I’m still getting the same error.
I don’t really know what the Unity Exporter is doing regarding WebGPU: I would have expected it is independent from the engine?
@MackeyK24 will know for sure.
It looks like engine.clear is the culprit that is causing the colorAttachments error when using BABYLON.WebGPUEngine.
I will DEPRECIATED that call to engine.clear for now. Will be fixed in my next Alpha 63 Update
UPDATE: My Babylon Toolkit A63.1X Update Fixes WebGPU These WebGPU issues for the toolkit.
I saw that mentioned here gl.clear() failing for framebuffer with RGB color attachment · Issue #70 · stackgl/headless-gl · GitHub , i should have posted it
