feat(render): Campaign V slice V6k commit 2 - the viewports name their own target, and section 5.4 is discharged
V4g's first half, and the V7 blocker section 5.4 named. What moved. PrivateEntityViewportRenderer - the paperdoll and creature-appraisal viewports - stops hand-rolling an FBO, a colour texture and a depth renderbuffer and asks the device for an IGpuRenderTarget. The pass it opens DECLARES that target rather than binding one behind the RHI's back, and the colour attachment is registered into the global texture table through RegisterTexture like any other texture. Render() returns the UiTextureTableHandle the retained UI already speaks instead of a raw GL name. That deletes the V4a pre-approved transitional seam. GlGpuDevice's RegisterExternalColorTexture / TryResolveExternalColorTexture existed so the UI could blit a texture whose owner the RHI knew nothing about; plan section 7.1's final paragraph gave them exactly this slice as their end, and both are gone along with the GlGpuDevice casts in RetailPaperdollFrameView and RetailCreatureAppraisalFrameView. Those two views are now backend-neutral: they decode a handle instead of registering one. Section 5.4, stated precisely, because the answer is not what the section predicts. The divergence it describes - GL's BeginPass refusing to bind framebuffer 0 for a null target - is NOT on the tree and has not been since the V4c revert at543bc79f, which took that hunk with it. GL's BeginPass binds the declared target today, so the two backends already agree about what Target: null means. What the revert did not undo was the REASON the divergence existed: this renderer bound a framebuffer no pass had declared. It now names its target, and PortalTunnelPresentation - the other renderer section 5.4 names - draws into the active viewport rather than an offscreen buffer, which is the backbuffer, which is what a null target literally means. The obligation is therefore discharged on both halves and V7's second defect is closed. PortalDepthMaskRenderer is NOT ported and is not blocking. Its two-pass punch is built on glStencilFunc/glStencilOp/glStencilMask, and GpuPipelineDescription has no stencil dimension to express them with. That is a pinned-contract question, reported rather than worked around. The section 5.5.7 re-check, which was asked for explicitly and does not come back clean. That note recorded that "the render-target-view-in-table usage from V6c did not fire" and asked that it not be carried forward as accepted. It still does not fire, and now for a reason worth writing down: a Vulkan render-target image is viewed as VK_IMAGE_VIEW_TYPE_2D because that is what an attachment needs, while the texture table's descriptor array is declared sampler2DArray, so registering one is invalid usage rather than a mismatch that samples oddly. It has never fired because the only renderer with an offscreen target is composed on GL alone. VulkanGpuDevice.RegisterTexture now refuses it loudly and names the fix - a second, layered sampled view per render target - so the slice that gives the Vulkan arm a viewport finds a precondition instead of a driver-level fault. Gates. Release build green. App tests 4,109 passed / 3 skipped, unchanged from commit 1. Strict GL offline pixel gate against22aa2edc: 4.08e-05, 23 differing pixels of 563,200, inside the documented 9-31 band, maximumChannelDelta 48. GL connected repeat gate at 3 runs: 3/3 RENDERED on the desktop witness and 3/3 on the client capture. One offline Vulkan run with VK_LAYER_KHRONOS_validation proven inserted by the loader: zero validation errors, zero warnings. And the surface the automated gates cannot see was checked rather than banked. The offline scene never opens the inventory, so the pixel gate is a tripwire for this change and nothing more - plan section 5.1's debt table has said so since V6d. A connected run that presses ToggleInventoryPanel and captures the result is in artifacts/v6k-paperdoll: the doll renders through the new render target with the correct pose, orientation and alpha, which is the row that table has been carrying since V4c. No divergence-register row: no retail-facing behaviour changes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
parent
22aa2edc65
commit
eb7e6b4e5c
7 changed files with 173 additions and 169 deletions
|
|
@ -810,6 +810,8 @@ internal sealed class LivePresentationCompositionPhase
|
|||
"paperdoll viewport",
|
||||
() => new PaperdollViewportRenderer(
|
||||
gl,
|
||||
host.GpuDevice,
|
||||
host.GpuFrameLifetime,
|
||||
paperdollDispatcher,
|
||||
foundation.SceneLighting!,
|
||||
foundation.TextureCache,
|
||||
|
|
@ -828,8 +830,7 @@ internal sealed class LivePresentationCompositionPhase
|
|||
paperdollLease.Resource,
|
||||
new RetailPaperdollFrameView(
|
||||
viewport,
|
||||
new PaperdollInventoryVisibility(inventoryFrame),
|
||||
host.GpuDevice),
|
||||
new PaperdollInventoryVisibility(inventoryFrame)),
|
||||
new RetailPaperdollDollFactory(
|
||||
new LivePaperdollEntityLookup(liveEntities),
|
||||
d.PlayerIdentity,
|
||||
|
|
@ -855,6 +856,8 @@ internal sealed class LivePresentationCompositionPhase
|
|||
"creature appraisal viewport",
|
||||
() => new CreatureAppraisalViewportRenderer(
|
||||
gl,
|
||||
host.GpuDevice,
|
||||
host.GpuFrameLifetime,
|
||||
appraisalDispatcher,
|
||||
foundation.SceneLighting!,
|
||||
foundation.TextureCache,
|
||||
|
|
@ -878,8 +881,7 @@ internal sealed class LivePresentationCompositionPhase
|
|||
new RetailCreatureAppraisalFrameView(
|
||||
creatureViewport,
|
||||
examinationFrame,
|
||||
appraisalController,
|
||||
host.GpuDevice),
|
||||
appraisalController),
|
||||
new RetailCreatureAppraisalCloneFactory(
|
||||
new LiveCreatureAppraisalEntityLookup(liveEntities)));
|
||||
}
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue