Raise T1/T2 place reveal thresholds so initial fly-in stays uncluttered#76
Merged
Merged
Conversation
T1 was firing at the initial d=10R fly-in on 4K displays (screenPx≈274 at d=10R, above the old T1=200 threshold) — every named place was visible before the user had zoomed in at all. Push T1 to 400 so all common viewport sizes show only T0 on arrival, and push T2 to 700 so secondary cities stay hidden until the user is at "almost landed" range (d≈1.8R on 1080p).
|
The previous absolute-pixel thresholds (T1=400 px radius, T2=700) read very differently across viewports — T1 at 400 was "planet fills 74 % of screen" on a 1080p display but only ~18 % on 8K, so users on larger displays saw T1 names appear at the initial d=10R fly-in. New table is planet apparent DIAMETER as a fraction of viewport height, so the visual size at which each tier reveals is identical across 720p / 1080p / 4K / 8K monitors: T0: 0.06 (small disc — marquee only) T1: 0.75 (planet fills ~3/4 of screen — major cities) T2: 1.30 (planet bigger than screen — "almost landed" picking) `Places.diameterFraction(camera, vph)` is the new viewport-relative metric driving the LOD hook; `screenPx` is retained for tests and debugging. Tier reveal distances (independent of viewport): T0 fires at d ≈ 42 R T1 fires at d ≈ 3.3 R T2 fires at d ≈ 1.8 R
User report: the marquee names (Cairo, Mt. Everest, Sydney…) were already on screen by the time the planet was a tiny disc — fraction 0.06 was way too eager. Push the entire sequence into the "planet is large" regime: T0: 0.75 (planet fills ~3/4 of screen — marquee names, was 0.06) T1: 1.00 (planet fills the screen — major cities, was 0.75) T2: 1.50 (planet 1.5× screen — close zoom for all cities, was 1.30) Corresponding camera-distance progression at default FOV: nothing until d ≈ 3.3 R, T0 reveals there, T1 at d ≈ 2.4 R, T2 at d ≈ 1.5 R.
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
2 participants
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.
Summary
Follow-up to #73. T1 was firing at the initial
d=10Rfly-in on 4Kdisplays (screenPx≈274 at d=10R is above the old T1=200 threshold), so
every named city was visible before the user had zoomed in at all.
viewport sizes (900p / 1080p / 1440p / 2160p). T1 cities reveal as
the user zooms in past
d≈3.3Ron 1080p, ord≈7Ron 4K."almost landed" range (
d≈1.8Ron 1080p).Distance / screenPx mapping (FOV 45°, 1080-px viewport):
Test plan
Places.test.jsupdated for the new thresholdsTokyo, etc.) is visible; T1 (Berlin, Rome, Athens, …) reveals
after a couple scroll-zooms; T2 (Austin, Madrid, Shanghai, …)
reveals when zoomed in close enough to pick a landing spot.
Generated by Claude Code