syuilo
April 28, 2026, 2:37am
1
Does this simply mean that GridMaterial does not support WGSL?
Thank you for this great framework!
Native wgsl shaders have been created for the main shaders only (standard, pbr, background, etc.).
The materials from the material library are still GLSL only and require TWGSL to be converted to WGSL.
Let me see what AI can do to add native WGSL shaders to the material library…
syuilo
April 28, 2026, 10:41am
4
Thank you for your reply!
I hope this will become unnecessary, since a GLSL-to-WGSL compiler adds network and memory overhead, and also does not work inside a Web Worker without some extra work!
AI works well, here’s the PR:
master ← Popov72:matlib-wgsl
opened 11:30AM - 28 Apr 26 UTC
## Summary
Adds native WGSL shaders to every material in `@babylonjs/materials`… (except `Custom`):
**cell, fire, fur, gradient, grid, lava, mix, normal, shadowOnly, simple, sky, terrain, triPlanar, water**.
Each material now ships both a GLSL and a WGSL shader pair, and selects between them at runtime based on the engine, mirroring the pattern used by `BackgroundMaterial` in core. WebGPU users get native WGSL shaders instead of going through the GLSL→WGSL transpiler.
## Per-material changes
- New `wgsl/<name>.{vertex,fragment}.fx` next to the existing GLSL sources.
- `<name>Material` constructor gains an optional `forceGLSL = false` parameter, forwarded through `PushMaterial` to `Material`.
- `createEffect` now passes `shaderLanguage: this._shaderLanguage` and an `extraInitializationsAsync` that lazy-imports the GLSL or WGSL shader pair based on `this.shaderLanguage` (gated by a `_shadersLoaded` flag).
- The static side-effect imports of the GLSL `.ts` shader files (`import "./<name>.fragment"` / `import "./<name>.vertex"`) are removed in favour of the lazy path. This matches `BackgroundMaterial` exactly.
## Build tool change
`packages/dev/buildTools/src/buildShaders.ts` `BuildShader` now treats a path as WGSL when any path **segment** is exactly `wgsl` (case-insensitive) **or** contains the literal uppercase `WGSL` substring. This:
- Picks up the new per-material `wgsl/` subfolders (lowercase, co-located with the material).
- Keeps the legacy `ShadersWGSL/` convention used in `packages/dev/core`.
- Avoids accidental matches on unrelated paths such as `tools/babylonServer/public/twgsl/`.
## Backward compatibility
- `forceGLSL` is appended after every existing constructor parameter (after `renderTargetSize` for `WaterMaterial`), so no existing call sites break. No subclasses of these materials exist in the repo.
- Removing the static GLSL shader-side-effect imports means the GLSL shader is no longer eagerly registered into `ShaderStore.ShadersStore` simply by importing the material module — registration now happens on the first `createEffect` call. This is the same behavior `BackgroundMaterial` has had, but worth flagging for any consumer that referenced the shader by name without instantiating the material.
## Validation
- `npm run format:check` ✓
- `npm run lint:check` ✓ on changed files (pre-existing errors elsewhere in the repo are unrelated)
- `npm run test:unit` ✓ — all 2930 unit tests pass
- `npm run compile -w @dev/materials` ✓
- Manual visual validation of all 14 materials in the Playground under WebGPU: `http://localhost:1338/?webgpu#GIC9U1#0`