When using Spine with Unity, each Spine skeleton instance typically results in a separate draw call, even if they share the same materials. This is because each skeleton is treated as a separate entity that requires its own draw call. Therefore, if you have 10 trees, each using the same two materials (one for leaves and one for trunks), you would indeed end up with 20 draw calls, assuming each tree is a separate Spine skeleton.

To reduce draw calls, you can try to combine multiple skeletons into a single skeleton where possible, or use techniques like runtime repacking to combine textures into a single atlas. However, the latter might not always be feasible if the combined texture size exceeds the maximum texture size supported by the platform. Additionally, ensure that your attachments are packed efficiently to minimize material switching, as this can also impact performance.

In summary, while sharing materials across multiple Spine projects can help with texture memory usage, it does not inherently reduce draw calls. Each skeleton instance will still require its own draw call, so consider combining skeletons or optimizing texture packing to improve performance.

suanLoBeach However, I've now tested with the official Spine project in Unity by duplicating the same Spine character (like Spineboy), and I found that the draw call count increases by 1 for each copy. This doesn't match my expectation. Does this mean that even if all my trees use the same two materials (leaves and trunk atlas textures), my draw call count will still increase? If I have 10 trees, will there be 20 draw calls?

Batching can break due to multiple causes.

• One requirement of dynamic batchins is the vertex count of the tree to be batched, having a 900 vertex attribute limit (see the documentation here).
• It also heavily depends on the used render pipeline. URP tends to batch more aggressively, sometimes messing up draw order to be incorrect in the end just to batch the same atlas textures (materials).
• When using Built-In Render Pipeline, things are more conservative most of the time. If your skeletons are e.g. overlapping each other in the output screen, and placed at different depth (if sorting by depth), Unity wants to maintain correct draw order and thus can't batch them together. If the skeleton's don't overlap each other, Unity might batch them.

suanLoBeach I'm now unsure which approach is correct - should I continue packing all leaves and trunks into unified atlases before creating trees, or should I just use individual textures in each Spine project? Do these two approaches have the same performance cost?

I'm not sure why you want to group them by trunks vs leaves. If you have no special material parameters at the leaves, you could simply group them to two atlas textures by which trees mostly go together in the same scene (which go close together spacially). So you could have trunks and leaves of trees types 1-5 on the first atlas page, and 6-10 on the second page.

suanLoBeach In short, my question is: Are Spine character draw calls independent of materials?

How would they be independent of materials? Draw calls always only ever depend on the materials. A Spine Skeleton uses a standard Unity MeshRenderer with standard materials, nothing magic happens behind the scene there.

suanLoBeach Should I not pursue having multiple Spine projects share textures since it doesn't reduce overhead?

It is indeed recommended to have multiple Skeleton types share the same atlas texture, thus using the same Material, and as a result being able to use a single draw-call.

suanLoBeach You can share the same texture across multiple skeletons, even if they are not in the same Spine project.

To achieve this, follow these steps:

1. Place all the images used by your skeletons into a single folder.
   (In this example, the images used by Spineboy and mix-and-match are placed in one folder):
   
2. Run the texture packer separately in Spine, specify the image folder in the Input folder, choose an Output folder and an Atlas name, then run the pack.
   This will generate a texture that combines the images used by each skeleton into a single atlas:
   
3. When you import your skeleton data into Unity, it may not automatically associate with the atlas, resulting in the warning:
   "Could not automatically set the AtlasAsset for <your skeleton data name>."
   Click on "Import without atlases" to proceed.
   
4. The SkeletonDataAsset created during the import process does not have an assigned atlas, so the skeleton will appear pink in the preview:
   
5. Once you assign the separately packed atlas in SkeletonDataAsset, the images will be referenced according to the image path of each image attachment in the skeleton data:
   
   If the skeleton still appears pink after setting the atlas, the atlas file may contain incorrect image paths. Double-check that the paths are correct. (I recently explained this to another user; you can refer to it here.)

By setting up other skeletons in the same way, you can display visually distinct skeletons within a single material:

I hope this helps you.