Additional clarification on optimization from anolder thread

jhofer21

Heylo,

My team and I are wondering more specifics on these bullet points mentioned by Harald.

Nintendo Switch Optimizations thread from 3 years ago
http://esotericsoftware.com/forum/Optimisation-Tips-Nintendo-Switch-General-11507?p=51695#p51695

"Use as few materials as possible (equals as few textures as possible, pack them to shared atlases where possible). This keeps the number of drawcalls lower."

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

"Use as few GameObject nodes as possible - a very deep hierarchy with many GameObjects per character can have a very noticable impact on performance."

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.

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?

Thanks as always!

Harald

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

No.

jhofer21 escreveu
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 escreveu
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.

jhofer21

Excellent, thank you for the responses!