Skip to content

fixed v1.2.0 — the wide world-position family

Choose a tag to compare

@rowan-claude rowan-claude released this 26 Jul 17:12
· 36 commits to main since this release
ba88f94

Seven functions that let a consumer with 128-bit world positions actually use this library. Additions only — backward compatible, both frozen hashes unchanged.

`fixLerpPositionWide` · `fixTransformWorldPointWide` · `fixInvTransformWorldPointWide` · `fixMakeWorldTransformWide` · `fixMulWorldTransformsWide` · `fixInvMulWorldTransformsWide` · `fixToRelativeTransformWide`

Why

A consumer whose world positions are 128-bit cannot call the narrow forms at all — the parameter type is the thing that differs. Bounding volumes are built from world positions, so the two families have to cross a library boundary together or neither can.

The one that is not a mechanical widening

`fixLerpPositionWide` computes `a + t*(b-a)`, not `(1-t)a + tb`. Widening the narrow form directly would multiply an absolute 128-bit coordinate and overflow; the reformulation multiplies only the difference, which is in local range.

One rounding instead of two, so it is deliberately not bit-identical to the narrow build. Anyone running both widths carries separate goldens for it — the wide answer is the more accurate one.

Testing

Every function is called. The round-trip property is pinned against the narrow rotation round-trip rather than against the input: fixed-point quaternion rotate-then-inverse loses a couple of ULPs, a control measurement confirmed the wide route loses the same and adds none, so what is asserted is that the 128-bit translation contributes nothing.

Proven able to fail: swapping the lerp difference operands breaks four checks including monotonicity.