Gizmo

Nearest along the ray wins, except that the centre handle wins outright, which is one documented exception rather than a priority table: a priority table would let a plane handle behind the camera beat an arm in front of it, which a user sees as a click landing on the wrong thing.

As the radii stand the exception decides nothing, and that is worth saying rather than implying otherwise: an arm's pick cylinder starts at ARM_START of the size and the centre's sphere ends at CENTRE_RADIUS, which is smaller, so the two regions do not meet. The ordering is what keeps a later change to either radius from quietly producing a centre nobody can click, which is the failure it is here to prevent.

direction must be unit length. camera.rayThrough gives one.

The transform and the axes are both captured here and neither is re-read until the drag ends. Recomputing the basis from a rotation the drag is changing feeds the answer back into its own input, and what that looks like is a ring that accelerates away from the pointer.

A grab whose anchor cannot be computed — a ray parallel to the axis it is grabbing — refuses rather than starting a drag with an arbitrary origin.

Every answer is absolute, computed from the anchor rather than accumulated from the last call, so a drag cannot drift however many frames it runs for. Rotation is the one exception and §5 of the design says why: an angle has to be unwrapped against the previous one to survive the seam at ±π, so the total is accumulated and the total is what the transform is built from.

A degenerate ray keeps the previous value rather than producing one. The alternative is the object teleporting at the moment the pointer crosses the plane it is dragging in, which is the single most annoying thing a gizmo can do.

Cheap enough to call every frame — a rotation ring at the default resolution is 48 segments of arithmetic — and it has to be, because the highlight changes with the pointer.