AnimationClipCache

Remarks

The join a compiled clip needs and cannot do for itself. AnimationClipContent is rig-independent — it names joints and does not know which skeleton will have them — and AnimationClip is the resolved form, with every channel bound to a joint index and a bucket table built over the duration. Somebody has to do that resolution, and doing it per instance is how a hundred copies of one enemy come to hold a hundred identical clips.

Keyed on both halves, because both decide the answer. The same content baked against two skeletons is two different clips — different joint indices, possibly a different set of resolved channels — so a cache keyed on the address alone would hand a character the clip belonging to a different rig, which poses the wrong joints and looks like a corrupted animation rather than a cache bug.

⚠ Entries live as long as the content does and no longer. The outer table holds its key weakly, so unloading a clip's asset drops every rig's bake of it without anybody calling a clear method. A static dictionary here would be a leak with a plausible excuse — it is a cache — and the leak would be the whole animation set of every level ever loaded.

Reference identity, not value equality. Two AnimationClipContent instances with identical channels are two entries, which is right: the asset manager hands out one instance per address, so equal-but-distinct contents mean somebody deserialised twice and the duplicate bake is the smaller of their problems.

Methods (2)

• public static AnimationClip Get(AnimationClipContent content, Skeleton skeleton, string? rootJoint = null)

  The clip for a content and a rig, baking it the first time it is asked for.

• public static bool Forget(AnimationClipContent content)

  Forgets every bake of a content, for a rig that has been rebuilt underneath it.

Used by (2)

• LoadPathTestsVixen.Animation.Tests
• MoveSetCacheVixen.Animation