Whether the stored per-vertex normals are meaningful for this epoch's displayed
axes (spec §3.4).
Why this is ORDERED equality, where resolveWinding uses set equality
The two ask different questions of the same two triples, and conflating them
would be a real bug in both directions.
Winding asks "can a uniform index reversal fix the projected orientation", which
only needs the displayed axes to be the same SET as the frame — a permutation
within that set reverses every triangle identically, so parity alone decides.
A normal is a 3-vector whose components are positionally bound to
normal_dims[0..2]. Reordering the displayed axes therefore permutes which
component means which screen direction: [0,1,2] → [1,0,2] leaves the frame
unchanged as a set while swapping x and y in every stored normal, tilting the
whole shade field. Nothing in the stored data records that, and re-deriving it
would mean permuting the normal columns per epoch — the (V, D, 3) full-frame
design §3.4 explicitly rejected for v1. So the answer is the strict one the spec
states: stored normals are used iff normal_dims equals the active
displayDims, in order.
The cost of being strict is bounded and correct: a mismatched epoch falls back to
the screen-space-derivative flat normal, which is exactly right for the projected
geometry — just faceted rather than smoothed.
Whether the stored per-vertex normals are meaningful for this epoch's displayed axes (spec §3.4).
Why this is ORDERED equality, where resolveWinding uses set equality
The two ask different questions of the same two triples, and conflating them would be a real bug in both directions.
Winding asks "can a uniform index reversal fix the projected orientation", which only needs the displayed axes to be the same SET as the frame — a permutation within that set reverses every triangle identically, so parity alone decides.
A normal is a 3-vector whose components are positionally bound to
normal_dims[0..2]. Reordering the displayed axes therefore permutes which component means which screen direction:[0,1,2] → [1,0,2]leaves the frame unchanged as a set while swapping x and y in every stored normal, tilting the whole shade field. Nothing in the stored data records that, and re-deriving it would mean permuting the normal columns per epoch — the(V, D, 3)full-frame design §3.4 explicitly rejected for v1. So the answer is the strict one the spec states: stored normals are used iffnormal_dimsequals the activedisplayDims, in order.The cost of being strict is bounded and correct: a mismatched epoch falls back to the screen-space-derivative flat normal, which is exactly right for the projected geometry — just faceted rather than smoothed.