diff --git a/docs/formats/core-data-regions.md b/docs/formats/core-data-regions.md index 59ae760..2dc430c 100644 --- a/docs/formats/core-data-regions.md +++ b/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 diff --git a/docs/roadmap.md b/docs/roadmap.md index c22e81e..d675e43 100644 --- a/docs/roadmap.md +++ b/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