NetworkBoneSelector

Remarks

⚠ Joints was written in exactly one place in the repository and it was a test (). Both pose systems bail out when it is null, so in any real build the whole networked-pose path was a no-op by construction — correct code, reachable by nothing, and the assembly's README costing out a path no shipped configuration could take.

The selection is not replicated, so it has to be a function of content. That is NetworkBoneSelection's own rule and it is what makes these static: given the same rig, two peers compute the same array without a message, in the same order, and the wire layout means the same thing at both ends. Anything drawn from run-time state — a camera, a distance, a random subset — would silently disagree.

Ordered root-first, because NetworkBonePrecision is indexed by slot. A rotation's error compounds down the chain, so the joint nearest the root is the one whose precision everything below it inherits, and a narrowed table is only meaningful if slot 0 is the pelvis on every rig in the game. Breadth-first from the root is what makes that true without anybody maintaining a list.

Methods (2)

• public static int[] Trunk(Skeleton skeleton, int max = 24)

  The joints nearest the root, in breadth-first order, capped.

• public static int[] Named(Skeleton skeleton, IReadOnlyList<string> names)

  The joints a game named, in the order it named them.

Used by (2)

• NetworkAnimationWiringTestsVixen.Net.Animation.Tests
• NetworkBoneSelectionSystemVixen.Net.Animation