Map previousWorld0-3 so instanced motion vectors are correct by bkaradzic-microsoft · Pull Request #1839 · BabylonJS/BabylonNative

bkaradzic-microsoft · 2026-08-17T20:29:43Z

Fixes the nightly Playground validation failures on the three motion blur tests.

Problem

A mesh rendered with object based motion blur (or prepass velocity) declares previousWorld0-3 alongside world0-3, so an instanced or thin-instanced mesh has 8 per-instance vec4 attributes, 9 with instanceColor.

previousWorld0-3 had no built-in mapping in the shader compiler, and VertexArray::RecordVertexBuffer rejected anything past the 5th instanced buffer (Number of vertex buffer instances greater than 4 is not supported). Those buffers were never recorded, the shader read a zero previous world matrix, and produced a huge bogus velocity that smeared the whole object.

This is what the nightly has been failing on since MRT support (#1754) enabled object based motion blur on Native.

Why slots are now assigned per shader

The i_data slots cannot come from a fixed per-name table. bgfx requires the used slots to form a contiguous run starting at i_data0:

the D3D11 input layout declares TEXCOORD31 down to TEXCOORD(31 - N + 1) at 16-byte-dense offsets;
the GL path compacts the i_data locations it finds.

Since the declared set varies (world0-3 alone, plus instanceColor, plus previousWorld0-3), a fixed table leaves a hole in the run and every attribute past the hole reads zero.

So slots are assigned per shader from the set that shader actually declares, in reverse name order: alphabetically first gets the highest slot, last gets i_data0. That is dense by construction, stable between the base program compile and any instanced variant (identical declared set), and matches BuildInstanceDataBuffer, which packs the recorded buffers by descending attribute location.

It also reproduces the previous fixed D3D table exactly for every set that existed before previousWorld0-3 (world0-3 → i_data3..0, +instanceColor → i_data4, splatIndex0-3 → i_data3..0), so nothing else changes. OpenGL and Metal already assigned densely; they now share the same map instead of each counting attributes themselves.

The instanced buffer limit is raised to bgfx's real BGFX_CONFIG_MAX_INSTANCE_DATA_COUNT (16 — its doc comment still claims 5), and the off-by-one is fixed: the check ran before the insert, so it rejected the 5th buffer rather than the 6th.

Validation

Playground validation, Win32 D3D11, Babylon.js 9.21.2:

Test	before	after
Thin instances + dynamic buffer resize	3.346%	2.478%
Thin instances + render self motion blur	2.844%	2.355%
Instances + render self motion blur	2.531%	2.061%

All now under the 2.5% allowance, and the instance-limit errors go from 9 to 0. The numbers are bit-identical on hardware D3D11 and on forced WARP, so they are not adapter-flaky.

A full 720 test A/B sweep shows no other test changing by more than 0.001%, and an identical set of pre-existing hangs on both builds.

Known remaining difference

A smaller residual diff remains on these three tests, from a separate bug: Babylon.js's bindAttachments is a no-op on Native, so the scene clear is applied to every MRT attachment and wipes the velocity attachment's alpha-0 background. The motion blur shader multiplies velocity by that alpha, so the background gets a fixed non-zero velocity and moving objects get a faint halo. Fixing it needs a matching Babylon.js change plus per-attachment clear masking here, so it is not addressed in this PR.

The worst test passes at 2.478% against a 2.5% allowance, so there is little headroom until that second bug is fixed.

A mesh rendered with object based motion blur (or prepass velocity) declares previousWorld0-3 alongside world0-3, so an instanced or thin-instanced mesh has 8 per-instance vec4 attributes, 9 with instanceColor. previousWorld0-3 had no built-in mapping, and VertexArray::RecordVertexBuffer rejected anything past the 5th instanced buffer, so those buffers were never recorded: the shader read a zero previous world matrix, produced a huge bogus velocity and smeared the whole object. This is what the nightly has been failing on since MRT support (BabylonJS#1754) turned object based motion blur on for Native. The i_data slots cannot come from a fixed per-name table. bgfx requires the used slots to form a contiguous run starting at i_data0: the D3D11 input layout declares TEXCOORD31 down to TEXCOORD(31 - N + 1) at 16-byte-dense offsets, and the GL path compacts the i_data locations it finds. Since the declared set varies (world0-3 alone, plus instanceColor, plus previousWorld0-3), a fixed table leaves a hole in the run and every attribute past the hole reads zero. So assign the slots per shader, from the set that shader actually declares, in reverse name order: the alphabetically first name gets the highest slot and the last gets i_data0. That is dense by construction, is stable between the base program compile and any instanced variant (the declared set is identical), and matches BuildInstanceDataBuffer, which packs the recorded buffers by descending attribute location. It also reproduces the previous fixed D3D table exactly for every set that existed before previousWorld0-3, so nothing else changes. OpenGL and Metal already assigned densely; they now share the same map instead of each counting attributes themselves. Raise the instanced buffer limit to bgfx's real BGFX_CONFIG_MAX_INSTANCE_DATA_COUNT (16, not the 5 its stale doc comment claims) and fix the off-by-one: the check ran before the insert, so it rejected the 5th buffer rather than the 6th. Playground validation, D3D11, Babylon.js 9.21.2: Thin instances + dynamic buffer resize 3.346% -> 2.478% Thin instances + render self motion blur 2.844% -> 2.355% Instances + render self motion blur 2.531% -> 2.061% all now under the 2.5% allowance, and the "Number of vertex buffer instances greater than 4 is not supported" errors go from 9 to 0. The numbers are bit-identical on hardware D3D11 and on forced WARP. A full 720 test A/B sweep shows no other test changing by more than 0.001%. A smaller residual difference remains on these three tests, from a separate bug: Babylon.js's bindAttachments is a no-op on Native, so the scene clear is applied to every MRT attachment and wipes the velocity attachment's alpha 0 background, leaving a faint halo around moving objects. That needs a matching Babylon.js change and is not addressed here. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 88569c10-a7ff-4373-9a58-afa9c68b8c09

Copilot

Pull request overview

This PR fixes incorrect instanced motion vectors by adding built-in shader compiler handling for previousWorld0-3 and ensuring per-instance i_data slots are assigned densely per shader (as required by bgfx). It also lifts the NativeEngine instanced-buffer recording limit to match bgfx’s actual instance-data slot capacity.

Changes:

Add previousWorld0-3 as built-in instanced attributes and assign built-in instance i_data slots per shader from the declared set (dense, stable mapping across variants).
Add/align compile-time guards for instance-data slot/location invariants and maximum slot counts.
Increase the NativeEngine instanced vertex-buffer instance limit to MAX_INSTANCE_DATA_SLOT_COUNT and fix the prior off-by-one behavior.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
Plugins/ShaderCompiler/Source/ShaderCompilerTraversers.cpp	Adds `previousWorld0-3` built-in instance detection and introduces per-shader dense built-in `i_data` slot assignment used across GL/Metal/D3D traversers.
Plugins/ShaderCompiler/Source/ShaderCompilerCommon.cpp	Updates static asserts/comments for the built-in instance-data location boundary and ensures built-in slot count doesn’t exceed max slot count.
Plugins/NativeEngine/Source/VertexArray.cpp	Raises instanced buffer instance limit to the bgfx max slot count and updates the thrown error message accordingly.
Plugins/NativeEngine/Source/NativeEngine.cpp	Updates documentation/comments for built-in instanced attribute rerouting behavior and the new built-in set.
Core/Graphics/InternalInclude/Babylon/Graphics/BgfxShaderInfo.h	Introduces `MAX_INSTANCE_DATA_SLOT_COUNT`, increases `BUILTIN_INSTANCE_DATA_SLOT_COUNT` to cover `previousWorld0-3`, and adjusts built-in location boundaries.

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 88569c10-a7ff-4373-9a58-afa9c68b8c09

Copilot

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

NativeEngine::Draw derives the routed location from the packing rank over every recorded instanced attribute, so it already accounts for built-ins. On OpenGL/Metal the built-ins are recorded at their stable, name-sorted locations, which puts them in the same range as consumer-declared ones, so a generic attribute sorting after a built-in shifts the packing and only the caller-supplied location reflects it. Prefer that location everywhere and exclude those attributes from the built-in slot assignment. On D3D built-ins carry synthetic locations at or above BUILTIN_INSTANCE_DATA_LAST_LOCATION and are never rerouted, so they never reach the map and nothing changes there. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 88569c10-a7ff-4373-9a58-afa9c68b8c09

Copilot

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Mapping previousWorld0-3 onto i_data slots makes the vertex shader read instance-data semantics the draw does not necessarily supply. bgfx sizes the instance-data half of the D3D11 input layout from the instance data buffer's stride, and CreateInputLayout fails outright (E_INVALIDARG) when the vertex shader's input signature reads a TEXCOORD the layout does not declare, so the mismatch is a hard crash rather than a wrong pixel. Babylon.js reaches that state legitimately. Mesh._renderWithThinInstances creates the previousWorld buffer *after* the draw that first needs it, so that first draw binds world0-3 only while the effect already declares previousWorld0-3: eight declared slots, four supplied. WebGL tolerates this -- an attribute whose array is disabled reads the generic attribute value -- and before previousWorld0-3 were built-ins so did Babylon Native, because a per-vertex attribute missing from the layout gets a dummy element from bgfx's fillVertexLayout. Only instance data has no such fallback. Count the built-in per-instance attributes the current program declares and pad the instance data buffer to that many 16-byte slots. The padding lands on the high slots, after the packed data, since BuildInstanceDataBuffer fills from i_data0 up; it is already zeroed. Move the built-in attribute name table into BgfxShaderInfo.h so the shader compiler and NativeEngine cannot disagree about which names count. Verified on D3D11: "Thin instances + render self motion blur" went from an assert in RendererContextD3D11::setInputLayout to validating at 2.355%, and the sequential validation run is back to 256/256. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 60c2ec68-6de1-445d-9fc9-b699db737eae

bkaradzic-microsoft · 2026-08-18T21:22:07Z

Pushed 5025029, which fixes a hard crash this PR would otherwise introduce. It is not reachable on the Babylon.js version this branch pins, which is why CI here is green — I only hit it while testing this PR together with #1840's bump to Babylon.js 9.21.2.

What breaks

Test 323 Thin instances + render self motion blur aborts the process:

bgfx/src/renderer_d3d11.cpp(2933): ASSERT SUCCEEDED(__hr__) ->
  m_device->CreateInputLayout(vertexElements, num, ...) FAILED 0x80070057
  #0 bgfx::d3d11::RendererContextD3D11::setInputLayout
  #1 bgfx::d3d11::RendererContextD3D11::submit

Why

Traced the offending draw:

shader builtin instance 'previousWorld0' -> i_data7
shader builtin instance 'previousWorld1' -> i_data6
shader builtin instance 'previousWorld2' -> i_data5
shader builtin instance 'previousWorld3' -> i_data4
shader builtin instance 'world0'         -> i_data3
shader builtin instance 'world1'         -> i_data2
shader builtin instance 'world2'         -> i_data1
shader builtin instance 'world3'         -> i_data0
draw instances: 38 39 40 41 (count=4)

The vertex shader declares 8 i_data slots; the draw supplies 4. bgfx derives the instance-data half of the D3D11 input layout from the instance data buffer's stride (renderer_d3d11.cpp, the _numInstanceData loop), so it declares only TEXCOORD31..28 while the VS signature reads TEXCOORD31..24 — and CreateInputLayout rejects a layout that does not cover the signature.

Babylon.js gets there legitimately: Mesh._renderWithThinInstances creates the previousWorld buffer after the draw that first needs it.

this._bind(subMesh, effect, fillMode);
this._draw(subMesh, fillMode, instancesCount);
// Write current matrices as previous matrices
if (this._scene.needsPreviousWorldMatrices && !...previousMatrixData && ...matrixData) {
    if (!this._thinInstanceDataStorage.previousMatrixBuffer) {
        this._thinInstanceDataStorage.previousMatrixBuffer = this._thinInstanceCreateMatrixBuffer("previousWorld", ...);

So the first draw binds world0-3 while the effect already declares previousWorld0-3. WebGL tolerates this — an attribute whose array is disabled reads the generic attribute value — and so did Babylon Native before this PR, because a per-vertex attribute missing from the layout gets a dummy element from bgfx's fillVertexLayout. Instance data has no such fallback, so promoting previousWorld0-3 to built-in instanced attributes turns a tolerated case into an abort.

Fix

Count the built-in per-instance attributes the current program declares and pad the instance data buffer to that many 16-byte slots. Padding lands on the high slots, after the packed data, since BuildInstanceDataBuffer fills from i_data0 up, and the buffer is already zeroed. The built-in attribute name table moved into BgfxShaderInfo.h so the shader compiler and NativeEngine cannot disagree about which names count.

Verification

	before `5025029`	after
323 on 9.21.2, isolated	abort in `setInputLayout`	validated, 2.355%
sequential 56-719 on 9.21.2	aborts at 323	ran=256 passed=256 failed=0
sequential 0-52 + 56-719 on 9.15.0 (this branch's pin)	299/299	299/299

2.355% is bit-identical to what the instance-limit raise alone produced before this PR's slot assignment existed, so the padded first frame does not perturb the final image.

GUI Near Menu was excluded from OpenGL with this recorded reason: OpenGL: BGFX FATAL shader compile error in GUI fragment shader ('=' : cannot convert from 'highp float' to 'bool') That is precisely the bug fixed earlier in this branch: a bool uniform widened to a float vec4 was narrowed back by shape alone, so the AST claimed bool while holding a float. The test now compiles and passes on OpenGL, so the graphics API exclusion is removed and it runs everywhere. Screen Space Reflections 2 is excluded instead. It reaches a multiple-render- target resolve, where bgfx does: const GLenum drawBuffer = GL_COLOR_ATTACHMENT0 + colorIdx; GL_CHECK(glDrawBuffers(1, &drawBuffer) ); GLES requires bufs[i] to be GL_NONE or GL_COLOR_ATTACHMENT0 + i, so resolving any attachment past the first is GL_INVALID_OPERATION. Desktop GL uses glDrawBuffer just above and has no such restriction, but Babylon Native builds the ES path on Linux, so the Ubuntu jobs hit it. The test passes on D3D11. A full sequential run now completes on an ANGLE/GLES build with no assert and no BGFX FATAL: 286 ran, 282 passed. The four remaining reds are the three motion blur tests that BabylonJS#1839 fixes, plus one ANGLE-only pixel difference in MeshDebugPluginMaterial. D3D11 is unchanged at 297/300, red on the same three motion blur tests. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 60c2ec68-6de1-445d-9fc9-b699db737eae

`Win32_x64_D3D11` and `Win32_x64_D3D11_Sanitizers` have hit the one-hour job timeout on every run of this PR. Both are the jobs that build the default JavaScript engine, Chakra; the V8, Hermes, JSI and QuickJS jobs on the same matrix all pass. The hang is reproducible locally with a Chakra build and is deterministic: `Playground --headless --test-index=23` never returns, spinning one core and growing the heap by ~7 MB/s until the runner gives up. Test 23 is "Glow layer and LODs". The scene itself renders fine - what never completes is `Scene.executeWhenReady`, because `EffectLayer.isReady` stays false forever: frame 300 scene.isReady=false layer.isReady(subMesh)=false _shadersLoaded=false isLayerReady=false while the same probe on V8 flips everything to true by frame 50. The one link that never settles is `ThinGlowLayer._importShadersAsync()`. The cause is a Chakra bug, exposed by a Babylon.js code-generation change. `super.x` inside an arrow function nested in a class method resolves to the *derived* class's own method instead of the base: class A { foo() { return "BASE"; } } class B extends A { foo() { const s = Object.create(null, { foo: { get: () => super.foo } }); return s.foo.call(this); // V8: "BASE" Chakra: recurses } } TypeScript emits exactly that `Object.create(null, { get: () => super.x })` helper for a `super` call inside an `async` method, and Babylon.js started shipping it in the UMD bundle in 9.16.0 - which is precisely where this PR's bump to 9.21.2 crosses. Called synchronously it dies with "Out of stack space"; called from a promise chain, as `_importShadersAsync` is, each level is a fresh microtask, so it recurses forever without ever overflowing the stack, never settles, and burns CPU and memory - the exact signature seen on the runner. The repo already has the remedy. `scripts/downlevelNativeScripts.mjs` transpiles the bundles to ES5 for this very reason ("Babylon Native's Chakra engine consumes ES5-level script"); TypeScript's ES5 emit rewrites `super.x` to `_super.prototype.x` and drops the arrow entirely. It was only ever wired into `getNightly`, so builds that take Babylon.js from npm - which is every normal build - ran the un-downleveled ES2015 bundle. Running it from `postinstall` closes that gap for `npm install`, `npm ci`, CI and local builds alike, and leaves the nightly path alone (`getNightly.js` still downlevels the files it refills from the CDN). Validated on Windows/D3D11, Debug, tests 0-52 and 56-719 (53-55 crash locally in Debug regardless of this change): | engine | before | after | |---|---|---| | Chakra | hangs at test 23 | **297/300** | | V8 | 297/300 | **297/300** | Byte-identical results on V8, and Chakra now matches it. The three remaining failures are the motion-blur trio that BabylonJS#1839 fixes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 60c2ec68-6de1-445d-9fc9-b699db737eae

bkaradzic-microsoft · 2026-08-20T22:58:24Z

Some evidence that this fix is load-bearing, which also explains why it does not flip any config.json test on its own.

master pins babylonjs 9.15.0, and at that version nothing declares previousWorld0-3, so the bug this PR fixes is unreachable from the validation suite — that is why enabling tests here would not have demonstrated anything.

#1840 happens to bump the bundles to 9.21.2, and at that version three tests start failing on Win32 D3D11 (and the equivalent jobs on Linux — 9 red jobs in total):

- Thin instances + dynamic buffer resize
- Instances + render self motion blur
- Thin instances + render self motion blur

I A/B'd this locally, RelWithDebInfo, running just those three:

build	result
#1840 alone	`ran=3 passed=0 failed=3` — 3.346% / 2.531% / 2.844% pixel diff (allowed 2.5%)
#1840 + this PR merged	`ran=3 passed=3 failed=0` — 2.478% / 2.061% / 2.355%

So this PR is what unblocks the Babylon.js version bump, and those three tests become real regression coverage for it as soon as the bump lands.

bghgary

[Reviewed by Copilot on behalf of @bghgary]

One blocking comment: the scenario 5025029 fixes for D3D takes a different path on Metal, where I measured a duplicate i_data0. The rest are non-blocking.

Throw on the declared-but-not-recorded case (blocking review comment) -------------------------------------------------------------------- AssignBuiltInInstanceSlots and the caller-supplied locations are two independent numberings over different denominators: the built-in run counts the declared built-ins the caller did not route, while caller-supplied locations are ranked over every recorded instanced attribute. They stay disjoint only while every declared built-in is also recorded. When they are not -- a shader declaring world0-3 and previousWorld0-3 while the draw records only world0-3, which is the first thin-instance draw, since _renderWithThinInstances creates the previousWorld buffer only after it -- both runs reach i_data0. On D3D the built-ins carry synthetic locations that never enter the caller map, so it goes unnoticed; on Metal and OpenGL they do, and the traverser emits two symbols for the same slot. Measured on macOS with Babylon.js 9.22.0, previousWorld3 and world3 both resolved to i_data0 for all four pairs. It does not throw: previousWorld silently aliases world and the velocity comes out zero, which is the smear this mapping exists to prevent. Throw instead -- a duplicate slot has no correct rendering. The guard is slot > 0 (some declared built-in was not routed) plus a non-empty instancedAttributes map; an empty map is the base program compile, where nothing is routed and the built-in run owns the whole range. Use the runtime instance-data cap --------------------------------- VertexArray::RecordVertexBuffer now bounds the instanced buffer count with bgfx::getCaps()->limits.maxInstanceData rather than mirroring the compile-time MAX_INSTANCE_DATA_SLOT_COUNT. Every backend clamps that limit to the device's maxVertexAttributes during init, so the compile-time value is a ceiling a device need not honour, and the mirror can drift on a bgfx bump or from a BGFX_CONFIG_MAX_INSTANCE_DATA_COUNT override in Dependencies/CMakeLists.txt. getCaps() was already queried two lines above. The constant stays for the shader compiler's static_asserts, which need a compile-time bound. Cache the built-in instance slot count -------------------------------------- GetBuiltInInstanceDataSlotCount walked a std::map<std::string, uint32_t> and tested every key against the built-in name table on each draw, including non-instanced draws where the result is discarded (SetVertexBuffers only reaches BuildInstanceDataBuffer when m_vertexBufferInstances is non-empty). m_vertexAttributeLocations is written once in Program::Initialize and cleared only in Dispose, so the count is invariant for the program's lifetime. Compute it where the map is populated and return the cached value. Documentation corrections ------------------------- - AssignBuiltInInstanceSlots no longer claims the assignment is "stable between the base program and any instanced variant (the declared set is identical)". That stopped being true when the base program began compiling with an empty instancedAttributes map: the base assigns every declared built-in while a variant excludes the routed ones. - ShaderCompilerTraversers.h no longer says the built-in names "keep their fixed mapping", which the per-shader dense assignment replaced, and no longer omits previousWorld0-3. - BuildInstanceDataBuffer now records that the zero padding lands in the highest i_data slots, so it is correct only while the attributes the draw omits are the alphabetically first names -- a coincidence between alphabetical order and Babylon.js's creation order that neither side enforces, and whose failure mode is silent. Verification ------------ Builds clean on Win32 D3D11 Release. The new guard does not fire on the Playground suite at the pinned Babylon.js 9.15.0, where these scenes never declare previousWorld0-3 -- which is the same reason this PR's own D3D11 run is green, as the review notes. The Metal collision itself was reported from a macOS run and is not reproducible on this machine, so the guard is verified only as "compiles and does not fire where it must not"; it has not been observed to throw on the case it targets. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 60c2ec68-6de1-445d-9fc9-b699db737eae

…collides a1eaf4d used `slot > 0 && !m_instancedAttributes->empty()` as the collision test. That is not the collision state on D3D, and it broke every Win32 job on this PR (5025029 was green): the validation suite threw Shader declares 4 built-in per-instance attribute(s) that the draw did not record, alongside 1 recorded instanced attribute(s). on ordinary instanced draws. NativeEngine::Draw builds genericInstancedAttributes from instances whose attrib is < Attrib::Count, so the built-ins -- which sit at synthetic locations at or above BUILTIN_INSTANCE_DATA_LAST_LOCATION -- are excluded from the caller map while still counted in the rank. A draw recording world0-3 plus one generic attribute therefore routes only the generic one, at rank 4 -> i_data4, sitting directly on top of the built-in run [0, 4). Dense, correct, and no overlap. Test the slots instead: the built-in run owns [0, builtInCount), so a caller-routed attribute collides only when INSTANCE_DATA_FIRST_LOCATION - location falls inside that window. That still catches the case this guard exists for -- a shader declaring world0-3 and previousWorld0-3 while the draw records only world0-3, where world3 is routed to i_data0 and previousWorld3 also takes i_data0 -- and stays quiet for the D3D arrangement above. Verified: the full validation suite no longer emits the overlap error (0 occurrences, previously thrown on essentially every instanced draw).

Comments had grown to roughly half the diff, much of it restating the code or repeating the same explanation at each of the three traverser call sites. Kept the parts that are not recoverable from reading the code: why the i_data slots are assigned per shader rather than from a fixed table (bgfx needs a contiguous run from i_data0), why reverse name order is the right assignment, why a caller-supplied location wins over the built-in map, what the overlap throw is guarding against, why the instance buffer is padded, and the caveat that the padding is only correct while alphabetical order happens to match Babylon.js's buffer creation order. Comments only, no functional change: 144 comment lines out of 291 added, now 85 out of 216. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 88569c10-a7ff-4373-9a58-afa9c68b8c09

GUI Near Menu was excluded from OpenGL with this recorded reason: OpenGL: BGFX FATAL shader compile error in GUI fragment shader ('=' : cannot convert from 'highp float' to 'bool') That is precisely the bug fixed earlier in this branch: a bool uniform widened to a float vec4 was narrowed back by shape alone, so the AST claimed bool while holding a float. The test now compiles and passes on OpenGL, so the graphics API exclusion is removed and it runs everywhere. Screen Space Reflections 2 is excluded instead. It reaches a multiple-render- target resolve, where bgfx does: const GLenum drawBuffer = GL_COLOR_ATTACHMENT0 + colorIdx; GL_CHECK(glDrawBuffers(1, &drawBuffer) ); GLES requires bufs[i] to be GL_NONE or GL_COLOR_ATTACHMENT0 + i, so resolving any attachment past the first is GL_INVALID_OPERATION. Desktop GL uses glDrawBuffer just above and has no such restriction, but Babylon Native builds the ES path on Linux, so the Ubuntu jobs hit it. The test passes on D3D11. A full sequential run now completes on an ANGLE/GLES build with no assert and no BGFX FATAL: 286 ran, 282 passed. The four remaining reds are the three motion blur tests that BabylonJS#1839 fixes, plus one ANGLE-only pixel difference in MeshDebugPluginMaterial. D3D11 is unchanged at 297/300, red on the same three motion blur tests. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 60c2ec68-6de1-445d-9fc9-b699db737eae

`Win32_x64_D3D11` and `Win32_x64_D3D11_Sanitizers` have hit the one-hour job timeout on every run of this PR. Both are the jobs that build the default JavaScript engine, Chakra; the V8, Hermes, JSI and QuickJS jobs on the same matrix all pass. The hang is reproducible locally with a Chakra build and is deterministic: `Playground --headless --test-index=23` never returns, spinning one core and growing the heap by ~7 MB/s until the runner gives up. Test 23 is "Glow layer and LODs". The scene itself renders fine - what never completes is `Scene.executeWhenReady`, because `EffectLayer.isReady` stays false forever: frame 300 scene.isReady=false layer.isReady(subMesh)=false _shadersLoaded=false isLayerReady=false while the same probe on V8 flips everything to true by frame 50. The one link that never settles is `ThinGlowLayer._importShadersAsync()`. The cause is a Chakra bug, exposed by a Babylon.js code-generation change. `super.x` inside an arrow function nested in a class method resolves to the *derived* class's own method instead of the base: class A { foo() { return "BASE"; } } class B extends A { foo() { const s = Object.create(null, { foo: { get: () => super.foo } }); return s.foo.call(this); // V8: "BASE" Chakra: recurses } } TypeScript emits exactly that `Object.create(null, { get: () => super.x })` helper for a `super` call inside an `async` method, and Babylon.js started shipping it in the UMD bundle in 9.16.0 - which is precisely where this PR's bump to 9.21.2 crosses. Called synchronously it dies with "Out of stack space"; called from a promise chain, as `_importShadersAsync` is, each level is a fresh microtask, so it recurses forever without ever overflowing the stack, never settles, and burns CPU and memory - the exact signature seen on the runner. The repo already has the remedy. `scripts/downlevelNativeScripts.mjs` transpiles the bundles to ES5 for this very reason ("Babylon Native's Chakra engine consumes ES5-level script"); TypeScript's ES5 emit rewrites `super.x` to `_super.prototype.x` and drops the arrow entirely. It was only ever wired into `getNightly`, so builds that take Babylon.js from npm - which is every normal build - ran the un-downleveled ES2015 bundle. Running it from `postinstall` closes that gap for `npm install`, `npm ci`, CI and local builds alike, and leaves the nightly path alone (`getNightly.js` still downlevels the files it refills from the CDN). Validated on Windows/D3D11, Debug, tests 0-52 and 56-719 (53-55 crash locally in Debug regardless of this change): | engine | before | after | |---|---|---| | Chakra | hangs at test 23 | **297/300** | | V8 | 297/300 | **297/300** | Byte-identical results on V8, and Chakra now matches it. The three remaining failures are the motion-blur trio that BabylonJS#1839 fixes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 60c2ec68-6de1-445d-9fc9-b699db737eae

Brings in BabylonJS#1839 (previousWorld0-3 instanced motion vectors), BabylonJS#1851 (bimg zero-depth texture handling) and BabylonJS#1733 (getTextureLayerCount). Conflicts were all in the per-instance attribute path, where upstream BabylonJS#1839 supersedes the earlier draft shotgun carried: - BgfxShaderInfo.h, ShaderCompilerTraversers.cpp, VertexArray.cpp: took upstream. The fixed IF_NAME_RETURN_ATTRIB slot table is replaced by per-shader dynamic slot assignment (BUILTIN_INSTANCE_ATTRIBUTE_NAMES + IsBuiltInInstanceAttributeName, slot count 8 -> 9), which is required because bgfx needs the used i_data slots to be a contiguous run from i_data0. Kept shotgun's FRAGCOORD_TARGET_SIZE_UNIFORM_NAME block, which is unrelated and sits in the same hunk. - Program.h/.cpp: union. Upstream's m_builtInInstanceDataSlotCount counting loop alongside shotgun's cached m_fragCoordTargetSizeUniform lookup. - NativeEngine.cpp: union in DrawIndexedInstanced/DrawInstanced. Kept shotgun's RepackStorageInstances GPU-compute instance path and added upstream's new GetBuiltInInstanceDataSlotCount() argument to SetVertexBuffers. Remaining hunks were comment-only. Verified: Release Playground builds clean.

GUI Near Menu was excluded from OpenGL with this recorded reason: OpenGL: BGFX FATAL shader compile error in GUI fragment shader ('=' : cannot convert from 'highp float' to 'bool') That is precisely the bug fixed earlier in this branch: a bool uniform widened to a float vec4 was narrowed back by shape alone, so the AST claimed bool while holding a float. The test now compiles and passes on OpenGL, so the graphics API exclusion is removed and it runs everywhere. Screen Space Reflections 2 is excluded instead. It reaches a multiple-render- target resolve, where bgfx does: const GLenum drawBuffer = GL_COLOR_ATTACHMENT0 + colorIdx; GL_CHECK(glDrawBuffers(1, &drawBuffer) ); GLES requires bufs[i] to be GL_NONE or GL_COLOR_ATTACHMENT0 + i, so resolving any attachment past the first is GL_INVALID_OPERATION. Desktop GL uses glDrawBuffer just above and has no such restriction, but Babylon Native builds the ES path on Linux, so the Ubuntu jobs hit it. The test passes on D3D11. A full sequential run now completes on an ANGLE/GLES build with no assert and no BGFX FATAL: 286 ran, 282 passed. The four remaining reds are the three motion blur tests that BabylonJS#1839 fixes, plus one ANGLE-only pixel difference in MeshDebugPluginMaterial. D3D11 is unchanged at 297/300, red on the same three motion blur tests. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 60c2ec68-6de1-445d-9fc9-b699db737eae

`Win32_x64_D3D11` and `Win32_x64_D3D11_Sanitizers` have hit the one-hour job timeout on every run of this PR. Both are the jobs that build the default JavaScript engine, Chakra; the V8, Hermes, JSI and QuickJS jobs on the same matrix all pass. The hang is reproducible locally with a Chakra build and is deterministic: `Playground --headless --test-index=23` never returns, spinning one core and growing the heap by ~7 MB/s until the runner gives up. Test 23 is "Glow layer and LODs". The scene itself renders fine - what never completes is `Scene.executeWhenReady`, because `EffectLayer.isReady` stays false forever: frame 300 scene.isReady=false layer.isReady(subMesh)=false _shadersLoaded=false isLayerReady=false while the same probe on V8 flips everything to true by frame 50. The one link that never settles is `ThinGlowLayer._importShadersAsync()`. The cause is a Chakra bug, exposed by a Babylon.js code-generation change. `super.x` inside an arrow function nested in a class method resolves to the *derived* class's own method instead of the base: class A { foo() { return "BASE"; } } class B extends A { foo() { const s = Object.create(null, { foo: { get: () => super.foo } }); return s.foo.call(this); // V8: "BASE" Chakra: recurses } } TypeScript emits exactly that `Object.create(null, { get: () => super.x })` helper for a `super` call inside an `async` method, and Babylon.js started shipping it in the UMD bundle in 9.16.0 - which is precisely where this PR's bump to 9.21.2 crosses. Called synchronously it dies with "Out of stack space"; called from a promise chain, as `_importShadersAsync` is, each level is a fresh microtask, so it recurses forever without ever overflowing the stack, never settles, and burns CPU and memory - the exact signature seen on the runner. The repo already has the remedy. `scripts/downlevelNativeScripts.mjs` transpiles the bundles to ES5 for this very reason ("Babylon Native's Chakra engine consumes ES5-level script"); TypeScript's ES5 emit rewrites `super.x` to `_super.prototype.x` and drops the arrow entirely. It was only ever wired into `getNightly`, so builds that take Babylon.js from npm - which is every normal build - ran the un-downleveled ES2015 bundle. Running it from `postinstall` closes that gap for `npm install`, `npm ci`, CI and local builds alike, and leaves the nightly path alone (`getNightly.js` still downlevels the files it refills from the CDN). Validated on Windows/D3D11, Debug, tests 0-52 and 56-719 (53-55 crash locally in Debug regardless of this change): | engine | before | after | |---|---|---| | Chakra | hangs at test 23 | **297/300** | | V8 | 297/300 | **297/300** | Byte-identical results on V8, and Chakra now matches it. The three remaining failures are the motion-blur trio that BabylonJS#1839 fixes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 60c2ec68-6de1-445d-9fc9-b699db737eae

GUI Near Menu was excluded from OpenGL with this recorded reason: OpenGL: BGFX FATAL shader compile error in GUI fragment shader ('=' : cannot convert from 'highp float' to 'bool') That is precisely the bug fixed earlier in this branch: a bool uniform widened to a float vec4 was narrowed back by shape alone, so the AST claimed bool while holding a float. The test now compiles and passes on OpenGL, so the graphics API exclusion is removed and it runs everywhere. Screen Space Reflections 2 is excluded instead. It reaches a multiple-render- target resolve, where bgfx does: const GLenum drawBuffer = GL_COLOR_ATTACHMENT0 + colorIdx; GL_CHECK(glDrawBuffers(1, &drawBuffer) ); GLES requires bufs[i] to be GL_NONE or GL_COLOR_ATTACHMENT0 + i, so resolving any attachment past the first is GL_INVALID_OPERATION. Desktop GL uses glDrawBuffer just above and has no such restriction, but Babylon Native builds the ES path on Linux, so the Ubuntu jobs hit it. The test passes on D3D11. A full sequential run now completes on an ANGLE/GLES build with no assert and no BGFX FATAL: 286 ran, 282 passed. The four remaining reds are the three motion blur tests that BabylonJS#1839 fixes, plus one ANGLE-only pixel difference in MeshDebugPluginMaterial. D3D11 is unchanged at 297/300, red on the same three motion blur tests. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 60c2ec68-6de1-445d-9fc9-b699db737eae

`Win32_x64_D3D11` and `Win32_x64_D3D11_Sanitizers` have hit the one-hour job timeout on every run of this PR. Both are the jobs that build the default JavaScript engine, Chakra; the V8, Hermes, JSI and QuickJS jobs on the same matrix all pass. The hang is reproducible locally with a Chakra build and is deterministic: `Playground --headless --test-index=23` never returns, spinning one core and growing the heap by ~7 MB/s until the runner gives up. Test 23 is "Glow layer and LODs". The scene itself renders fine - what never completes is `Scene.executeWhenReady`, because `EffectLayer.isReady` stays false forever: frame 300 scene.isReady=false layer.isReady(subMesh)=false _shadersLoaded=false isLayerReady=false while the same probe on V8 flips everything to true by frame 50. The one link that never settles is `ThinGlowLayer._importShadersAsync()`. The cause is a Chakra bug, exposed by a Babylon.js code-generation change. `super.x` inside an arrow function nested in a class method resolves to the *derived* class's own method instead of the base: class A { foo() { return "BASE"; } } class B extends A { foo() { const s = Object.create(null, { foo: { get: () => super.foo } }); return s.foo.call(this); // V8: "BASE" Chakra: recurses } } TypeScript emits exactly that `Object.create(null, { get: () => super.x })` helper for a `super` call inside an `async` method, and Babylon.js started shipping it in the UMD bundle in 9.16.0 - which is precisely where this PR's bump to 9.21.2 crosses. Called synchronously it dies with "Out of stack space"; called from a promise chain, as `_importShadersAsync` is, each level is a fresh microtask, so it recurses forever without ever overflowing the stack, never settles, and burns CPU and memory - the exact signature seen on the runner. The repo already has the remedy. `scripts/downlevelNativeScripts.mjs` transpiles the bundles to ES5 for this very reason ("Babylon Native's Chakra engine consumes ES5-level script"); TypeScript's ES5 emit rewrites `super.x` to `_super.prototype.x` and drops the arrow entirely. It was only ever wired into `getNightly`, so builds that take Babylon.js from npm - which is every normal build - ran the un-downleveled ES2015 bundle. Running it from `postinstall` closes that gap for `npm install`, `npm ci`, CI and local builds alike, and leaves the nightly path alone (`getNightly.js` still downlevels the files it refills from the CDN). Validated on Windows/D3D11, Debug, tests 0-52 and 56-719 (53-55 crash locally in Debug regardless of this change): | engine | before | after | |---|---|---| | Chakra | hangs at test 23 | **297/300** | | V8 | 297/300 | **297/300** | Byte-identical results on V8, and Chakra now matches it. The three remaining failures are the motion-blur trio that BabylonJS#1839 fixes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 60c2ec68-6de1-445d-9fc9-b699db737eae

GUI Near Menu was excluded from OpenGL with this recorded reason: OpenGL: BGFX FATAL shader compile error in GUI fragment shader ('=' : cannot convert from 'highp float' to 'bool') That is precisely the bug fixed earlier in this branch: a bool uniform widened to a float vec4 was narrowed back by shape alone, so the AST claimed bool while holding a float. The test now compiles and passes on OpenGL, so the graphics API exclusion is removed and it runs everywhere. Screen Space Reflections 2 is excluded instead. It reaches a multiple-render- target resolve, where bgfx does: const GLenum drawBuffer = GL_COLOR_ATTACHMENT0 + colorIdx; GL_CHECK(glDrawBuffers(1, &drawBuffer) ); GLES requires bufs[i] to be GL_NONE or GL_COLOR_ATTACHMENT0 + i, so resolving any attachment past the first is GL_INVALID_OPERATION. Desktop GL uses glDrawBuffer just above and has no such restriction, but Babylon Native builds the ES path on Linux, so the Ubuntu jobs hit it. The test passes on D3D11. A full sequential run now completes on an ANGLE/GLES build with no assert and no BGFX FATAL: 286 ran, 282 passed. The four remaining reds are the three motion blur tests that BabylonJS#1839 fixes, plus one ANGLE-only pixel difference in MeshDebugPluginMaterial. D3D11 is unchanged at 297/300, red on the same three motion blur tests. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 60c2ec68-6de1-445d-9fc9-b699db737eae

`Win32_x64_D3D11` and `Win32_x64_D3D11_Sanitizers` have hit the one-hour job timeout on every run of this PR. Both are the jobs that build the default JavaScript engine, Chakra; the V8, Hermes, JSI and QuickJS jobs on the same matrix all pass. The hang is reproducible locally with a Chakra build and is deterministic: `Playground --headless --test-index=23` never returns, spinning one core and growing the heap by ~7 MB/s until the runner gives up. Test 23 is "Glow layer and LODs". The scene itself renders fine - what never completes is `Scene.executeWhenReady`, because `EffectLayer.isReady` stays false forever: frame 300 scene.isReady=false layer.isReady(subMesh)=false _shadersLoaded=false isLayerReady=false while the same probe on V8 flips everything to true by frame 50. The one link that never settles is `ThinGlowLayer._importShadersAsync()`. The cause is a Chakra bug, exposed by a Babylon.js code-generation change. `super.x` inside an arrow function nested in a class method resolves to the *derived* class's own method instead of the base: class A { foo() { return "BASE"; } } class B extends A { foo() { const s = Object.create(null, { foo: { get: () => super.foo } }); return s.foo.call(this); // V8: "BASE" Chakra: recurses } } TypeScript emits exactly that `Object.create(null, { get: () => super.x })` helper for a `super` call inside an `async` method, and Babylon.js started shipping it in the UMD bundle in 9.16.0 - which is precisely where this PR's bump to 9.21.2 crosses. Called synchronously it dies with "Out of stack space"; called from a promise chain, as `_importShadersAsync` is, each level is a fresh microtask, so it recurses forever without ever overflowing the stack, never settles, and burns CPU and memory - the exact signature seen on the runner. The repo already has the remedy. `scripts/downlevelNativeScripts.mjs` transpiles the bundles to ES5 for this very reason ("Babylon Native's Chakra engine consumes ES5-level script"); TypeScript's ES5 emit rewrites `super.x` to `_super.prototype.x` and drops the arrow entirely. It was only ever wired into `getNightly`, so builds that take Babylon.js from npm - which is every normal build - ran the un-downleveled ES2015 bundle. Running it from `postinstall` closes that gap for `npm install`, `npm ci`, CI and local builds alike, and leaves the nightly path alone (`getNightly.js` still downlevels the files it refills from the CDN). Validated on Windows/D3D11, Debug, tests 0-52 and 56-719 (53-55 crash locally in Debug regardless of this change): | engine | before | after | |---|---|---| | Chakra | hangs at test 23 | **297/300** | | V8 | 297/300 | **297/300** | Byte-identical results on V8, and Chakra now matches it. The three remaining failures are the motion-blur trio that BabylonJS#1839 fixes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 60c2ec68-6de1-445d-9fc9-b699db737eae

Bumps Babylon.js 9.15.0 -> 9.21.2, and fixes the i_data slot collision that bump exposes. ### The bug `AssignBuiltInInstanceSlots` numbered the built-in per-instance attributes a draw did not record starting at zero -- the same range the draw-time caller slots use -- and threw when the two collided. OpenGL/Metal route built-ins through the caller map, so a shader declaring `world0-3` and `previousWorld0-3` whose first draw records only `world0-3` always collides (`_renderWithThinInstances` creates the previousWorld buffer after the first draw). That is `Thin instances + render self motion blur` failing on the four Ubuntu legs. D3D keeps built-ins out of that map, so it only collides once a draw mixes a generic instanced attribute with unrecorded built-ins. Fix: give the built-ins the lowest slots not already claimed by a caller-supplied location, and size the instance data buffer from the recorded attributes plus the built-ins the draw left out, so those land in the buffer's zero padding. Introduced by #1839, latent on master only because the lockfile pinned 9.15.0. ### Supporting commits `Restore the original basic type when narrowing widened uniforms` is a shader-compiler fix required by 9.21.2. The rest enable 9 newly-passing tests, downlevel the bundles to ES5 for Chakra (`typescript` moves to `dependencies` because the postinstall hook needs it under `--omit=dev`), and retarget the prepass SSAO / SSR2 exclusions. Those eight were already globally excluded on master for a Mesa/LLVM crash on the Ubuntu runner; they are now `excludedGraphicsApis: ["OpenGL"]` so D3D11 keeps covering them. The sweep only runs on Linux/GL and Win32/D3D11, so this enables them nowhere untested. ### Testing | | before | after | |---|---|---| | Linux/OpenGL sweep | 288/289 | 289/289 | | Win32 D3D11 sweep | 306/306 | 314/314 | --------- Co-authored-by: Branimir Karadzic <branimirkaradzic@gmail.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 60c2ec68-6de1-445d-9fc9-b699db737eae Copilot-Session: 88569c10-a7ff-4373-9a58-afa9c68b8c09

Copilot AI lite review requested due to automatic review settings August 17, 2026 20:29

Copilot started reviewing on behalf of bkaradzic-microsoft August 17, 2026 20:37 View session

bkaradzic-microsoft requested review from bghgary and ryantrem August 17, 2026 20:40

Copilot AI reviewed Aug 17, 2026

View reviewed changes

Comment thread Core/Graphics/InternalInclude/Babylon/Graphics/BgfxShaderInfo.h Outdated

Comment thread Plugins/NativeEngine/Source/VertexArray.cpp Outdated

Restore the lost comment subject and only count new instanced attributes

f73cad9

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 88569c10-a7ff-4373-9a58-afa9c68b8c09

bkaradzic-microsoft requested a balanced review from Copilot August 17, 2026 22:38

Copilot started reviewing on behalf of bkaradzic-microsoft August 17, 2026 22:39 View session

Copilot AI reviewed Aug 17, 2026

View reviewed changes

Comment thread Plugins/ShaderCompiler/Source/ShaderCompilerTraversers.cpp Outdated

bkaradzic-microsoft requested a balanced review from Copilot August 17, 2026 23:42

Copilot started reviewing on behalf of bkaradzic-microsoft August 17, 2026 23:42 View session

Copilot AI reviewed Aug 17, 2026

View reviewed changes

bkaradzic-microsoft mentioned this pull request Aug 18, 2026

Correct gl_FragCoord Y orientation on D3D, Metal and Vulkan #1840

Merged

bkaradzic-microsoft requested a review from CedricGuillemet August 24, 2026 13:57

bghgary reviewed Aug 25, 2026

View reviewed changes

bkaradzic and others added 3 commits August 24, 2026 18:00

bghgary approved these changes Aug 25, 2026

View reviewed changes

bkaradzic-microsoft merged commit 0793422 into BabylonJS:master Aug 25, 2026
86 of 98 checks passed

bkaradzic-microsoft mentioned this pull request Aug 25, 2026

Bump Babylon.js to 9.21.2 and fix i_data slot overlap #1852

Merged

Navigation Menu

Uh oh!

Map previousWorld0-3 so instanced motion vectors are correct - #1839

Map previousWorld0-3 so instanced motion vectors are correct#1839
bkaradzic-microsoft merged 7 commits into
BabylonJS:masterfrom
bkaradzic-microsoft:nativeengine/previous-world-instance-attributes

bkaradzic-microsoft commented Aug 17, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

Copilot AI left a comment

Uh oh!

bkaradzic-microsoft commented Aug 18, 2026

Uh oh!

bkaradzic-microsoft commented Aug 20, 2026

Uh oh!

bghgary left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

bkaradzic-microsoft commented Aug 17, 2026

Problem

Why slots are now assigned per shader

Validation

Known remaining difference

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

bkaradzic-microsoft commented Aug 18, 2026

What breaks

Why

Fix

Verification

Uh oh!

bkaradzic-microsoft commented Aug 20, 2026

Uh oh!

bghgary left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants