Withdraw the tie "not a joint index" claim: the measurement never settled it

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.

docs/formats/core-data-regions.md

@@ -2214,24 +2214,47 @@ single draw packet** (median, 1,804 records). A material or texture-set index
 would be constant per packet, so it is per vertex -- which invites the obvious
 reading: tie objects are skinned, and slot 3 is a joint index.
 
-That reading is wrong. If it named a joint, vertices sharing it would sit
-together. They do not:
+> **CORRECTED.** An earlier version of this concluded "slot 3 is not a skin
+> index". The measurement does not support that, and the inference from it was
+> wrong. The correction is the reasoning, not the numbers.
 
     mean pairwise distance, same slot-3 value        14,481
     mean pairwise distance, different slot-3 value  13,795
     ratio different/same                              0.95x
     control: same position-x bucket                   8,105
 
-Vertices sharing a slot-3 value are if anything marginally *farther* apart than
-vertices differing in it -- 0.95x, the wrong side of neutral, though not far
-enough to claim much on its own. The control shows the measurement works:
-bucket by position-x and pairs collapse to 8,105, half the global distance.
+The numbers are fine: vertices sharing a slot-3 value are about as far apart as
+vertices differing in it, and the control shows the measurement works -- bucket
+by position-x and pairs collapse to 8,105, half the global distance.
 
-So slot 3 is not a skin index. It is also not shared across LODs: 75.3%
-same-class against a 78.7% control, i.e. no signal at all. Per-vertex, in
-`0..=254`, correlated with neither the geometry it sits in nor the detail level.
-**It is not understood**, and no reading is offered here. A per-vertex phase
-would fit the arithmetic, but that is a guess and is labelled as one.
+What does not follow is "so it is not a joint index". The premise was that
+vertices sharing a joint sit together. That is only true for a *tightly
+localised* joint. It is false in the cases that are actually 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 every vertex, and the mean
+    distance is the mesh's own diameter;
+  * a root or hip bone's influence region can span most of a mesh;
+  * a bone's weights fall off gradually, so membership is not a spatial partition.
+
+A 0.95x ratio is what a rigid object bound to one joint **predicts**. Absence of
+clustering is therefore fully consistent with the joint reading, and the test
+never had the power to separate them.
+
+That makes the hypothesis stronger rather than weaker, for a separate reason:
+`MobyInstance` carries `jointCnt` at `0x57` and `jointCache` at `0x58`, so this
+engine has joints and per-moby joint state. A per-vertex field in `0..=254` is
+exactly the shape of a joint index.
+
+What is still true, and is all that was ever established: slot 3 is **per vertex**
+(50 distinct values per packet), in `0..=254`, and **not shared across LODs**
+(75.3% same-class against a 78.7% control). A joint index shared across a class's
+two LODs would be expected to share, which is the one thing arguing against it --
+though two LODs may also bind a rigid mesh identically without that being
+informative.
+
+So: **not understood**, with the joint reading now the leading candidate rather
+than a disproved one.
 
 ### Slots 6 and 7 are mostly not per-vertex
 
@@ -3292,9 +3315,11 @@ axis the two tables share.
 
 `jointCnt` and `jointCache` also settle something from earlier in this log by
 contradiction rather than confirmation. A tie vertex's `i16[3]` was tested as a
-skin/joint index and **disproved** -- vertices sharing it were 0.95x *farther*
-apart than vertices differing in it. That result stands and is unaffected: this is
-the *moby* struct, and a moby is a different object from a tie.
+skin/joint index, which the measurement **did not settle** -- see the correction
+above. That earlier result was over-read, and the joint reading is now the
+leading candidate rather than a disproved one. Either way this is the *moby*
+struct and a moby is a different object from a tie, so the two are not evidence
+about each other.
 
 What this does **not** do is find `moby_anim`. It names the instance-side state --
 a sequence pointer, a layer list, a joint cache -- which means the asset to locate

docs/roadmap.md

@@ -353,10 +353,13 @@ Phase 1 hands over the extents; this phase works out what each one contains.
 - [~] The remaining tie vertex **fields are not named**, and two readings are now
       excluded. `i16[6]`/`i16[7]` are constant across a whole draw packet in
       43%/34% of records, so they are usually per-packet rather than per-vertex.
-      `i16[3]` is per-vertex (50 distinct values per packet) but **not a skin or
-      joint index**: vertices sharing it are 0.95x *farther* apart than vertices
-      differing in it, against a control that halves. It is also unshared across
-      LODs. Recorded as not understood rather than guessed.
+      `i16[3]` is per-vertex (50 distinct values per packet) and unshared across
+      LODs (75.3% against a 78.7% control). **An earlier note here called it "not
+      a joint index" on a 0.95x distance ratio; that was an over-read and is
+      withdrawn.** A rigid object bound to joint 0 makes "vertices sharing a
+      joint" the whole mesh, so absence of clustering is what a joint index
+      predicts. With `MobyInstance.jointCnt` now named, the joint reading is the
+      leading candidate, not a disproved one.
       `i16` range with 10,803-13,421 distinct values each. `i16[0..2]` are most
       likely position, but that is not established.
 - [~] `shrub` — class table done (48-byte entries, not 32; reading shrub at