renderer: build_room_kit r7 — full impassable coverage + flat-light score capture (#83)#1686
Conversation
…core capture (#83) Six placement/lighting fixes driven by qa/registration_score.py per-cell attribution of kit_crypt_r6 (58.85% vs the 99% bar; 60 invisible-wall + 19 walk-through cells): 1. IMPASSABLE COVERAGE: every geometry impassable cell left visually open (interior buttress cells (2,1),(3,1),(9,1),(11,1),(12,1)) now gets a deterministic stone mass — buttress if adjacent to a wall_run, else plinth. 2. WALL BASE: walls thickened to >=1.4u and centered on their cell. 3. CAMERA-SIDE PARAPET: cut-away near walls render a low 0.55u parapet. 4. PILLAR FOOTPRINT-DRIVEN SIZE: pillar x/z derived from the authored footprint span so a 1x2 footprint reads covered on both cells. 5. DOORWAYS OPEN: closed door leaf disabled so the doorway reads walkable. 6. FLAT-LIGHT SCORE FRAME: CaptureRoom emits a third 1344x768 contract PNG with room lights off + flat grey ambient (placement, not luminance).
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 30 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
evaOS review status: closed or merged before reviewPR: #1686 - renderer: build_room_kit r7 — full impassable coverage + flat-light score capture (#83) evaOS review stopped because the PR closed or merged before this queued head could be reviewed. Automation note: agents should wait for this comment to reach PR URL: #1686 Details: state=closed |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0a0f3cfa55
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| else PlaceWall(pDoor, $"Door_{dn}", doorParent, new Vector3(w.x + CELL * 0.5f, 0f, w.z), 90f, ref nMatFix); | ||
| // r7: center the doorway on its cell (matches the r7 wall centering) and STRIP any closed door | ||
| // LEAF so the opening reads WALKABLE (packet item 5; r6 walk-through at (15,5) was a leaf). | ||
| var dInst = PlaceWall(pDoor, $"Door_{dn}", doorParent, new Vector3(w.x, 0f, w.z), isBack ? 0f : 90f, ref nMatFix); |
There was a problem hiding this comment.
When a door is on a kept far wall, this now centers the thick door-wall prefab in the door cell itself; PlaceWall then scales the wall thickness to WALL_T = 1.4, while qa/paint_coherence.py::derive_room treats door_cells as walkable by subtracting them from wall blocking. Stripping only the leaf still leaves the frame/jamb/arch geometry in the same 2x2 cell the engine expects open, so cases like the crypt right door (15,5) can continue to score as painted-blocked/walk-through. Keep the frame on the outer edge or otherwise avoid rendering blocking doorway geometry inside the walkable door cell.
Useful? React with 👍 / 👎.
1 participant
What
r7 of the Synty kit-room builder (
extensions/renderers/unity/scripts/build_room_kit.cs), driven by the per-cell attribution of the r6 render, which scored 58.85% onqa/registration_score.pyvs the 99% ship bar (60 invisible-wall cells + 19 walk-through cells). Evidence:kit_crypt_r6_registration.json/kit_crypt_r6_heatmap.png.Six placement/lighting fixes, all in the Build/Capture paths, deterministic and material-defensive:
impassablearray (fallbackwalls) and, for every impassable cell NOT covered by a wall_run cell / prop footprint / door cell, place a deterministic stone mass — a buttress (~1.7×2.2×1.7) if orthogonally adjacent to a wall_run cell, else a low plinth (~1.6×0.9×1.6). For the crypt this covers exactly the 5 interior buttress cells(2,1),(3,1),(9,1),(11,1),(12,1)that lived inwalls/impassableonly. Logs per-cell + a+N buttress +M plinthsummary; idempotent under rebuild.WALL_Traised to 1.4u and perimeter walls centered on their cell (were a thin outer-edge skin that left the cell floor bare → read painted-open).(15,5)).CaptureRoomemits a third filekit_<room>_<ts>_score.png(1344×768 contract camera) with all room lights disabled +ambientMode=Flat/ambientLight=(0.6,0.6,0.6), restored in afinally. Rationale: registration measures object placement, not luminance — the r6 19 walk-through false positives were brazier light pools.Deviation note (item 4 formula)
The packet phrases the pillar target as
spanX*2*0.85/spanZ*2*0.85. The code'sFootprint.spanX/spanZare the full world spans of the footprint (e.g. a 1×2 pillar footprint = 2×4 world units), so the packet's formula is implemented asspan*0.85(= the packet target expressed from the half-span). Using the literalspan*2*0.85would make the pillar ~2× the footprint and spill into adjacent walkable cells, manufacturing the exact walk-through false positives this round removes. Flag for the orchestrator's render loop to confirm.Verification
C# is uncompilable on the authoring Mac; authored to mirror the proven sibling idioms (WorldBounds / FixMaterials / Place / FallbackBox / PlacePillar / SetupContractCamera / RenderToPng). No new files; no .cs test framework here. Brace/paren balance checked; no stale symbol refs. Box render + re-score is the orchestrator's loop.
Spec:
/Volumes/LEXAR/Codex/session-notes/2026-07-22/g4-build/dispatch/kit-room-r7-spec.md