renderer: build_room_kit r5 — measured pillar columns + pillar material + wall height (#83)#1684
Conversation
…al + wall height (#83) r4-probe fixes (measured live on the GEX44 box, issue #83): - Pillar scaling → measured-multiplier: measure the instance's renderer world bounds, multiply localScale per-axis by target/measured for world (1.2,4.0,1.2), then RE-MEASURE + Debug.Log achieved size, loud warning if any axis off >10%. Fixes the r3 z-half-x asymmetry (world (1.80,5.00,0.90) wide thin slabs → symmetric column). - Pillar material: FixMaterials gains a force flag; pillars shipped a valid-but-grey material FixMaterials skipped (r4b left them default grey) → force stone/brick like walls. - Wall height baked to 1.5x the r3 value (WALL_H 3.6 -> 5.4); r4b frame read right at 1.5x. - r3 lighting / braziers / tomb unchanged.
evaOS review status: closed or merged before reviewPR: #1684 - renderer: build_room_kit r5 — measured pillar columns + pillar material + wall height (#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: #1684 |
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 11 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 |
1 participant
r5 — measured pillar columns + pillar material + wall height (#83)
Deterministic fixes against the r4 probe data measured live on the GEX44 box (issue #83). C# is uncompilable on the authoring Mac; authored to mirror the proven sibling idioms and compiled/run on the box.
Probe facts (issue #83)
SM_Bld_Base_Pillar_01natural bounds(0.43, 3.02, 0.43), single renderer.(4.20, 1.66, 4.20)→ world(1.80, 5.00, 0.90)— wide thin slabs, x/z asymmetric (z ≈ half x) and default grey.kit_crypt_r4b.png).Changes (all in
build_room_kit.cs, deterministic)target/measuredfor a world target(1.2, 4.0, 1.2). Then RE-MEASURE,Debug.Logthe achieved world size, and log a loud warning if any axis is off target by >10%. Both x/z share one target → the z-half-x asymmetry is gone by construction.FixMaterialsgains aforceflag: pillars shipped a valid-but-grey material the null/error-only walk skipped (r4b left them default grey), so pillars now force the stone/brick material like the walls.WALL_H3.6 → 5.4).// r5header note added.Evidence:
kit_crypt_r3.png,kit_crypt_r4.png(overshoot),kit_crypt_r4b.png(measured, grey pillars). Next box render verifies the achieved-size log + brick columns.