jhofer21 a écrit

Would making use of material property blocks help if the materials are the same but textures are different?

No.

jhofer21 a écrit

I'm not sure if Harald means a deep bone hierarchy here within a spine game object, an exploded spine object within unity using Spawn Hierarchy, or a deep unity game object hierarchy with either a spine game object and/or an exploded spine object at the end.

Basically I meant as the line says: "Use as few GameObject nodes as possible", so I did mean the number of GameObjects and not the number of bones. Obviously reducing the number of bones as well as reducing the number of GameObjects will both have a positive impact. However, reducing the number of bones is sometimes not feasible (below a certain count), while reducing the number of GameObjects could be.

jhofer21 a écrit

That said, what are some uses cases for using the Spawn Hierarchy utility when we have options like the bone follower component? Are there performance concerns when using Spawn Hierarchy vs a contained spine object?

You only need a hierarchy of SkeletonUtilityBone objects when you need to override the bone position, since it requires a parent GameObject to apply local transform values relative to it. Any hierarchy GameObjects that are not needed (any that don't have an Override SkeletonUtilityBone below it) should be removed, so you rarely need the complete generated hierarchy. It does not make sense to use it when only requiring it to follow a bone, that's what the BoneFollower component is for. To cut down the cost of the complete hierarchy above a SkeletonUtilityBone in Override mode, you can also replace the parent hierarchy with a single BoneFollower GameObject that follows just the parent bone.