Do you see these materials properly assigned at your _SkeletonData.asset?

Yep, when first brought in they are properly assigned.

In general there should be no need to manually assign anything, unless you are using an older spine-unity runtime version (3.8 or older)

Ahh, excellent and good to know. In that case you may find it interesting that if you do choose to assign them (now I know is not required) to the _Atlas.asset, close Unity, delete the /Library/ folder, re-open Unity, only the one default material is re-generated but not the others (Screen, Multiply). Which then, source control software may get the user tripped up showing that previously commit materials were deleted. Likely most people aren't hitting this so just a strange edge case we accidentally got ourselves into. Not sure if you all would consider that a bug or not?

Which skeleton component are you using, SkeletonAnimation / SkeletonMecanim or SkeletonGraphic?

We typically work with SkeletonAnimation.

Thanks as always Harald!

Hey Esoteric crew,

First a question or two then I may have some repo project and steps to pass along.
After importing an exported skeleton that has multiple blend modes, say Normal, Multiply, and Screen. I notice that the skeleton_Atlas.asset file shows only one normal material assigned.

Are we suppose to add the other two materials?
If and when doing so, should the added assigned materials be remembered after re-building the /Library/ folder?

Thanks!

Excellent, thank you for the responses!

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!

Excellent, thank you both!

Beautiful, I will look at both of these and report back asap.

Thank you!

Hmmm well this is odd. I downloaded Spineboy 3.8+ and get the following message:
"Sorry, an error occurred while reading the project file. Please not that projects which have been saved with a newer version of Spine cannot be opened by an older Spine version." Perhaps that page's zip was updated with a Spineboy for 4.x? I have 3.8.58.

I've been searching the internet "esoteric spine transform constraint separate skeletons" or in the forums with "transform constraint" maybe that's not the right term.

I'm wondering if it's possible for a human style skeleton to be attached at runtime to a platform style skeleton. The platform motion would then affect the humanoid with their feet planted but momentum up through the body depending on how fast or slow the platform moves.

Is that only doable if the two are in a combined skeleton?

Thank you for your time and insight!

Oh awesome! I think that's yet another good reason to get our artists using the spine photoshop export tool and tagging syntax.

Thank you for the suggestion Misaki!

Long one, grab some a drink of choice. Trying to figure out a best practice for artists that is not too complex and also does some basic amount of reasonable optimization for the atlas. Problem space:

Working art - PSD where the artist creates
Spine Source Art - PSD with flattened working art images ready for spine
Spine export - PNG atlas

We often have working art delivered as source art that are the original size (maybe 2x sometimes 4x the target size.) The spine animator has two options, option A) work at the original size and it happens to fit within the maximum spine canvas. Option B) scale the source art down 2 or 4x and animate at a smaller scale. Option C) ?

Now add in effect images like glows, sparkles, glints, shines to the mix. Those are often created at the original working size too, however they take up so much pixel room that could ideally be given to the actual art that is seen 90% of the time. A trick I'd like to use is scale the effect down by 50, 75, or even 90% in some cases since they aren't on the screen very long we can kinda "get away with it." This however is a bit of work on my part to rescale the attachment and or mesh back to the needed original desired size (but at a lower resolution) in the spine project after the animator has worked with it.

But if I do that (technical artist) and then later the art needs to update or a polish pass happens, they don't know how much I reduced their effect texture down by. If I told them, then they'd have this really tiny layer that doesn't do them much good in context of their working file but does give more pixel density to the best parts of their art and helps reduce atlas size overall.
When they reexport their new changes now the spin source art is back at the original working size and I need to go back through and resize the effects and less important art again.

I don't doubt I'm missing something simple here or over thinking it. It's almost as if I'd want to be able to set a scale per image in the spine texture export settings. Some manifest that lists all exporting textures and a scale value next to each one.

Should artists deliver their working art at it's working size for spine or reduce their work before hand to be more inline with the target resolution and reduce their effects even smaller still? Should a middle-person do this and deal with resizing churn? How does this all play in if we want to release 4k textures later, then all the mesh/attachment slots will need readjusting again.

Thanks for any insights anyone has.

There is an atlas per subfolder feature in Spine Texture packing - Spine User Guide: Folder structure may help if you went that route.

Another thought is that your characters textures a larger than the resolution it will be displayed on, you might consider reducing your texture export scale setting which will scale all images before packing by the amount specified. This may also reduce the amount of pages you need (ideally all fitting in one atlas.)

Thanks Mario! There are some special cases in our game that aren't always player focused and the reason for wondering about using base pose in those cases. Thanks for the quick reply.

Stay safe!

Hey all,

Are there reasons to avoid using the setup pose as a visual state at runtime? For example if when we don't want a character animating and want them still could we use the setup pose? We're wondering if we should use that pose directly or use the 'default' animation instead for this state.

Thank you!

Good to know it's still not much of a concern performance wise. I agree on the organization benefits. Looking forward to us upgrading to 4.0 in the near future.

Thanks much Nate!

Performance impact of having several slots

I'm wondering if there are any performance implications for png sequences in this scenario. When I drag and drop the sequence on a bone, Spine creates a slot per image. When I drag the sequence onto a slot, they all attach to that single slot.

Some games I work on can have rather large png sequences embedded (15-20+ frames, and multiple sequences) in a spine skeleton. Should I recommend to our spine artist to group them under one slot or use the spine default behavior where 1 slot for each image.

Thank you!

Got it, thanks Mario!