NativeEngine: MultiRenderTarget framebuffers + OIT alpha blend modes#1754
Draft
bkaradzic-microsoft wants to merge 1 commit into
Draft
NativeEngine: MultiRenderTarget framebuffers + OIT alpha blend modes#1754bkaradzic-microsoft wants to merge 1 commit into
bkaradzic-microsoft wants to merge 1 commit into
Conversation
Foundational native-engine support for MultiRenderTarget (MRT) and the order- independent-transparency blend modes, removing several "engine._gl is null" crash classes. It does not by itself land the MRT/OIT/FrameGraph validation tests, which need further work (see follow-ups below). - Add NativeEngine::CreateMultiFrameBuffer: build one bgfx framebuffer with N color attachments (+ optional depth) so a MultiRenderTarget renders to all targets at once (bgfx writes every attachment of the bound framebuffer, so no drawBuffers is needed). JS-controlled attachment count is validated against caps->limits.maxFBAttachments. - Add alpha blend modes ALPHA_ONEONE_ONEONE (11) and ALPHA_LAYER_ACCUMULATE (17) used by the depth-peeling OIT renderer. Pairs with the Babylon.js change (createMultipleRenderTarget + MRT helper overrides, applyStates, reverse-Z clear). Known follow-ups: the OIT depth- peeling path still faults inside the D3D11 driver on submit (needs interactive GPU debugging), and the blend equation (MAX) is not yet applied natively. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
c773272 to
db75d2e
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Paired engine PR: BabylonJS/Babylon.js#18568
What
Foundational native support for
MultiRenderTarget(MRT) and the order-independent-transparency blendmodes, removing several "
engine._glis null" crash classes. It does not by itself turn theMRT/OIT/FrameGraph validation tests green — those need further work (see Follow-ups).
Changes
Plugins/NativeEngine/Source/NativeEngine.cpp/.hNativeEngine::CreateMultiFrameBuffer: build one bgfx framebuffer with N color attachments(+ optional depth) so a
MultiRenderTargetrenders to all targets at once (bgfx writes everyattachment of the bound framebuffer — no
drawBuffersneeded). The JS-controlled attachment countis validated against
caps->limits.maxFBAttachments.ALPHA_ONEONE_ONEONE(11) andALPHA_LAYER_ACCUMULATE(17) used by thedepth-peeling OIT renderer.
Paired engine PR
Pairs with the Babylon.js change (
createMultipleRenderTarget+ MRT helper overrides,applyStatesoverride, reverse-Z
clear, alpha-mode mapping).CI
The validation suite uses the published
babylonjsnpm, which doesn't yet contain the paired JS, sono new tests are enabled here and CI stays in the usual "pending dep bump" state. Verified locally
against a
babylon.max.jsbuilt from the paired branch.Follow-ups (separate work)
submit(multi-output / SRV↔RTVping-pong); needs interactive GPU debugging (PIX / VS Graphics Debugger).
MAX) —setAlphaEquationis a no-op — so OITblending would still be incorrect after the crash is fixed.
types").
Related PRs & landing order
These two are co-dependent and land in this order:
babylonjsnpm release ships that TS change.babylonjsto that release. (This foundational pair does not yet turn the MRT/OIT/FrameGraph tests green — that is separate follow-up work.)