Clicks in crowded places hit nothing when a held click's depth page arrives late #1500

New issue

Open

opened 2026-11-09 00:27:27 +00:00 by TheSlowly · 1 comment

TheSlowly commented

2026-11-09 00:27:27 +00:00

Collaborator

In a crowded place, alt-click focus (and any world click) sometimes hits nothing, so the camera neither focuses nor orbits. Happens on the first try in a busy region.

Log (RenderVKPickDebug), two failed clicks:

pick click -> exact age 0 cand 292/5220/0 frags 5 hud 0 [window undecided] => nothing
pick latency (10 s): 2 clicks held (avg 6.0, max 8 frames; 1 ran out; 2 pages fetched, 2 missing)

In the same second, hover picks at that pixel resolve the static object under it (=> c031a688... face 0 (static)).

Cause (llcleancursorpick.cpp, held clicks from 7bbbb2a4b6):

About 5,200 rigged wearer draws cross every ray in this region ("rigged candidate list full", steady for 8+ minutes, not a teleport transient), so every click's world layer overflows and needs a depth-window page.
The held click's page did not arrive within kMaxClickWaitFrames (8 frames, ~320 ms at 25 fps).
With the page missing, pageAnswer returns false, the walk ends undecided without visiting any fragment, and the click hits nothing. A hover walks the same answer as a partial rigged layer and finds the object.

Plan:

Safety net: a held click whose page is missing after its hold ran out answers that page now (the pre-7bbbb2a4b6 behaviour, only in this case) instead of ending the walk undecided.
Diagnostics under RenderVKPickDebug: per held click, the frames each page waited and why answers were not taken, to find why pages are late.
Then fix whatever (2) shows.

In a crowded place, alt-click focus (and any world click) sometimes hits nothing, so the camera neither focuses nor orbits. Happens on the first try in a busy region. Log (`RenderVKPickDebug`), two failed clicks: ``` pick click -> exact age 0 cand 292/5220/0 frags 5 hud 0 [window undecided] => nothing pick latency (10 s): 2 clicks held (avg 6.0, max 8 frames; 1 ran out; 2 pages fetched, 2 missing) ``` In the same second, hover picks at that pixel resolve the static object under it (`=> c031a688... face 0 (static)`). Cause (llcleancursorpick.cpp, held clicks from 7bbbb2a4b6): - About 5,200 rigged wearer draws cross every ray in this region ("rigged candidate list full", steady for 8+ minutes, not a teleport transient), so every click's world layer overflows and needs a depth-window page. - The held click's page did not arrive within `kMaxClickWaitFrames` (8 frames, ~320 ms at 25 fps). - With the page missing, `pageAnswer` returns false, the walk ends undecided without visiting any fragment, and the click hits nothing. A hover walks the same answer as a partial rigged layer and finds the object. Plan: 1. Safety net: a held click whose page is missing after its hold ran out answers that page now (the pre-7bbbb2a4b6 behaviour, only in this case) instead of ending the walk undecided. 2. Diagnostics under `RenderVKPickDebug`: per held click, the frames each page waited and why answers were not taken, to find why pages are late. 3. Then fix whatever (2) shows.

TheSlowly added the

status

in-progress

bug

labels

2026-11-09 00:27:27 +00:00

TheSlowly self-assigned this

2026-11-09 00:27:27 +00:00

TheSlowly added this to the Slipstream project

2026-11-09 00:27:27 +00:00

TheSlowly referenced this issue from a pull request that will close it,

2026-11-09 01:09:28 +00:00

#1500: Clicks in crowds and alt-clicks pick what is under them without a GPU wait #1502

TheSlowly commented

2026-11-09 01:09:37 +00:00

Author

Collaborator

Found with the new pick log: with DisableCameraConstraints and a 4096 m draw distance, alt-click's camera pick asks an ~8,300 m ray while the held click's answer reaches 1024 m. covers() rejected it, so every alt-click asked the GPU now (~15-20 ms; plain clicks logged none), and that pick's depth pages were not among the held click's pages, so they went missing without any hold running out. That was the second way the focus click hit nothing.

PR #1502: missing pages are answered now; the long ray takes the held answer for its first 1024 m and asks now only when nothing is hit there. In a 5,300-wearer crowd the held pages themselves came in 2 frames each.

Found with the new pick log: with DisableCameraConstraints and a 4096 m draw distance, alt-click's camera pick asks an ~8,300 m ray while the held click's answer reaches 1024 m. `covers()` rejected it, so every alt-click asked the GPU now (~15-20 ms; plain clicks logged none), and that pick's depth pages were not among the held click's pages, so they went missing without any hold running out. That was the second way the focus click hit nothing. PR #1502: missing pages are answered now; the long ray takes the held answer for its first 1024 m and asks now only when nothing is hit there. In a 5,300-wearer crowd the held pages themselves came in 2 frames each.

TheSlowly added

and removed

labels

2026-11-09 01:10:04 +00:00