Revisited an older conclusion and found the numbers were fine but the inference
from them was not.
The claim was: i16[3] in a tie vertex is not a skin/joint index, because vertices
sharing a value are 0.95x FARTHER apart than vertices differing in it.
mean pairwise distance, same slot-3 value 14,481
mean pairwise distance, different slot-3 value 13,795
ratio 0.95x
control: same position-x bucket 8,105
The measurements are correct, and the control shows the test works. What does not
follow is the conclusion. The premise was "vertices sharing a joint sit together",
and that is only true for a TIGHTLY LOCALISED joint. It is false in the cases that
are common:
* a rigid tie object -- a leaf, a banner, a piece of foliage -- puts every vertex
on joint 0, so "vertices sharing a joint" IS the whole mesh and the mean
distance is the mesh's own diameter
* a root or hip bone's influence region can span most of a mesh
* bone weights fall off gradually, so membership is not a spatial partition
A 0.95x ratio is precisely what a rigid object bound to one joint PREDICTS.
Absence of clustering is fully consistent with the joint reading; the test never
had the power to separate them. A negative result I did not expect was reported
as a disproof.
This makes the hypothesis STRONGER, for an independent reason: MobyInstance carries
jointCnt at 0x57 and jointCache at 0x58, so this engine demonstrably has joints and
per-moby joint state. A per-vertex field in 0..=254 is exactly the shape of a
joint index.
What was always established still stands, and is all that was: slot 3 is per vertex
(50 distinct values per packet) and not shared across LODs (75.3% same-class
against a 78.7% control). The LOD result is the one thing arguing against a joint
index, though two LODs binding a rigid mesh identically would produce it without
being informative.
So: not understood, with the joint reading now the LEADING CANDIDATE rather than a
disproved one. Corrected in the format file and the roadmap, including the second
mention added two commits ago.
This is the sixth correction in this session to withdraw a conclusion rather than
sharpen one, and the first where the measurement was sound and only the reading
was wrong -- which is the hardest kind to catch, because the number looks right and
is quoted in the commit message as well as the doc.
ReaperOfVeriod
412ef4707b