visgl / deck.gl / 42417835777

84%

push

github

fix(core): orient GlobeView meter offsets east, north and up (1/2) (#10914)

* fix(core): orient GlobeView meter offsets east, north and up

project_get_orientation_matrix returned columns pointing west and south.
project_position_to_clipspace and project_normal rotate meter offsets by
it, so below zoom 12 GlobeView turned every offset half a turn about the
local up direction: SimpleMeshLayer and ScenegraphLayer meshes, ColumnLayer
angles, and IconLayer and TextLayer with billboard: false. They turned back
at the zoom-12 switch to WebMercatorViewport. The meter-offsets projection
negated x and y to compensate, so it was already correct.

The matrix now returns east, north and up columns, and the meter-offsets
projection no longer negates. At the poles, east is +x, the limit of east
along longitude 0, so a meter-offset origin exactly at a pole now matches
its neighbours instead of being turned half a turn.

The WGSL version passed its select() arguments in the wrong order: away
from the poles x was always +x, and at the poles normalize(vec3(0.0))
gave NaN, including for normals that SimpleMeshLayer and ScenegraphLayer
project before setting geometry.position. It now matches the GLSL.

The CPU mirrors of the frame in @deck.gl/extensions and deck-gpu-layers
follow the new convention; their results are unchanged away from the
poles.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* fix(core): describe globe orientation at the poles as a longitude limit

At a pole, project_get_orientation_matrix returns the limit of east along
the longitude that up retains: GlobeViewport.projectPosition leaves a tiny
horizontal component, so an origin at [90, 90] has east +y. Only an up
exactly on the polar axis takes +x. Say so in the shader comments, the
project docs, the upgrade guide and the deck-gpu-layers mirror, and test
both poles at nonzero longitudes on WebGL and WebGPU. WGSL test literals
now use exponent notation so that those tiny components survive.... (continued)

11051 of 13563 branches covered (81.48%)

Branch coverage included in aggregate %.

3 of 3 new or added lines in 1 file covered. (100.0%)

17617 of 20281 relevant lines covered (86.86%)

30409.88 hits per line