Terrain cinematographer — DEM ambient occlusion + relief-model mode#104
Conversation
…ef mode Operator critique confirmed the remaining artifacts are RENDERER (imagery), not geometry: - the white blobs are CLOUDS in the ESRI capture (fuzzy, don't follow the canyon, change between captures) — 0.85% of the demgrid; - the washed mid-canyon is a low-contrast mosaic tile — the DEM has the relief, the imagery lost the texture contrast; - 10M looking blockier than 2.7M is because our colour is PER-VERTEX at grid resolution (= z14 imagery, ~6.7 m/px) — more mesh just samples the same z14 pixels more finely and exposes their native blockiness. Imagery is the ceiling. Response, all decode/shader (no rebake — AO derives from the height grid the wire already carries): - DEM AMBIENT OCCLUSION (aAo, decode-side): a height box-blur gives a sky-openness proxy — a vertex below its neighbourhood mean is a gorge (occluded → darker), a ridge is open (brighter). This restores the dark cracks in the washed tiles FROM THE GEOMETRY, which has them. Occlusion also suppresses the sky-fill in crevices. Normalized by height span (scene-independent). - RELIEF-MODEL mode (uRelief + `relief` toggle on skin scenes): drops the satellite imagery, renders a flat sandstone albedo under the museum light + AO — "the Grand Canyon 3D-printed in sandstone, lit perfectly". This IS the operator's proposed experiment made permanent: at identical 643k verts it is razor-sharp where the satellite skin is imagery-limited, proving the geometry was never the bottleneck. Also the timeless imagery-independent aesthetic. - CLOUD de-emphasis: the near-white response is dimmed (0.86) + de-chroma'd and its specular sheen removed, so cloud blobs read as pale haze, not glowing snow. - MATERIAL response (not colour alone): vegetation gets a wider light wrap (cheap subsurface); water is the only specular (suppressed in relief mode); snow/cloud and sandstone stay matte. aWet/aAo attributes are always bound (0 / 128 neutral) so non-skin scenes are unaffected. Verified headless: skin+AO restores mid-canyon contrast; relief mode is razor-sharp (the confirming experiment). Open follow-ups the critique named: higher-res imagery (z15/Sentinel-2), mosaic seam blending, per-tile contrast normalization. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012jEwwaT5JZ5x8qWvcnaMYC
|
Warning Review limit reached
Next review available in: 32 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: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_cbaaf69f-7fce-4ac7-98c4-3e5c4167cda4) |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e99bf4a189
ℹ️ 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".
| vec3 base = mix(aColor, vec3(0.66, 0.55, 0.42), uRelief); | ||
| float blum = dot(base, vec3(0.299, 0.587, 0.114)); | ||
| base = blum + (base - blum) * 1.20; | ||
| base = blum + (base - blum) * mix(1.20, 0.0, uRelief); |
There was a problem hiding this comment.
Preserve sandstone color in relief mode
When uRelief is 1, the previous line selects the sandstone constant, but this line then applies a zero chroma multiplier and collapses it to vec3(blum) (a neutral gray around 0.56). On any ver-9 skin scene using the new relief toggle, the advertised sandstone relief model loses its sandstone hue; keep the constant relief albedo unchanged (or use a nonzero relief chroma factor) instead of desaturating it to luminance.
Useful? React with 👍 / 👎.
| lit += vec3(1.35, 1.30, 1.10) * pow(nh, 80.0) * chan * 0.55; | ||
| lit += vec3(1.60, 1.55, 1.30) * pow(nh, 420.0) * chan * 1.10; | ||
| lit += vec3(0.9, 0.95, 1.05) * pow(nh, 24.0) * snow * 0.18; | ||
| float spec = (1.0 - uRelief); |
There was a problem hiding this comment.
Disable the water tint in relief mode
This only suppresses the specular glints when relief mode is active, but the diffuse river block above still uses chan/bank to tint Water-KIND vertices blue-green. In /garmin/grand-canyon or /havel relief mode the scene is therefore not the promised imagery-independent flat sandstone model, because rivers remain colored as water; gate the diffuse water mix by (1.0 - uRelief) as well or skip that block in relief mode.
Useful? React with 👍 / 👎.
Operator critique (13 phone screenshots) landed the diagnosis precisely: the remaining artifacts are the imagery pipeline, not the geometry.
All render fixes are decode/shader — no rebake (AO derives from the height grid the wire already carries; the committed asset is untouched).
Render (
GeoHelix.tsx)aAo) — a height box-blur → sky-openness proxy: below-neighbourhood = gorge (occluded, darker), ridge = open (brighter). Restores the dark cracks in the washed tiles from the geometry.uRelief+relieftoggle on skin scenes) — the operator's experiment made permanent: drop the imagery, render flat sandstone under museum light + AO. At identical 643k verts it is razor-sharp where the satellite skin is imagery-limited — the confirming evidence that geometry was never the bottleneck.Build fix (folded in — unblocks the deploy)
The cockpit-server Railway build failed with
error[E0432]: unresolved import lance_graph_planner::api::ThinkingStyle— a cross-repo drift unrelated to the terrain work: lance-graph'sapire-export ofThinkingStylepostdates the pinned rev. Fixed by importing from the canonicallance_graph_planner::thinking::style::ThinkingStyle(public in every version) in the twoplanner-gated call sites ofcrates/stubs/notebook-query. Same type, robust path.Verification
npx tsc --noEmit✓ ·npm run build✓pub mod thinking→pub mod style) + compile-check running locally; CI is the authoritative gate.Follow-ups the critique named
🤖 Generated with Claude Code