Shiki wrote

In order to avoid having some assets a million time in each atlas, we've decided to add the Eyes, Hair, Nose, and Ear image file directly from Unity:

Is there a reason why you are not using a shared Spine atlas for these RegionAttachments? You can have a look at the Spine Examples/Other Examples/AtlasRegionAttacher example scene on how to do that. Then you would place your shared Attachment images in a separate folder different from the specific character images, and then export your atlas textures by folder structure upon export (or manually run the texture packer). You can find documentation here on the Spine documentation pages, and also multiple forum threads regarding this topic, like this one. There are multiple advantages of using Spine attachments, since you could e.g. use a single larger attachment image size with lots of whitespace large enough for all kinds of ear or weapon types, and then let the Atlas export setting Strip whitespace X/Y remove the unnecessary transparent border at each image. This way every image is already positioned exactly where you want it to, without adjusting any pivots.

If you still want to use Unity Sprites, you can have a look at the Spine Examples/Other Examples/Mix and Match and Mix and Match Equip examples on how to use GetRemappedClone() with different parameters for useOriginalRegionSize, and experiment with different Sprite pivots (set via the Unity Sprite editor).

Shiki wrote

If the game goes well, and in the future we have -for example- 50+ styles of hairs (or any other content unlockable by the player that acts only a visual improve), we would ended up with a giant atlas of hairs...

You could still use atlases exported from Spine: Instead of having a single giant one that is re-generated all the time, you could split the multitude of hairs into multiple atlases (non only multiple atlas page .png files, but multiple .atlas.txt files, generating one Atlas), which could be grouped by release date or by "skin set" so that you don't need to re-publish existing ones at every game-update all the time. (You could also programmatically use any delayed download method like Asset Bundles if you want to, to download on demand e.g. if most hairstyles are locked by default and need to be purchased). Since you mentioned that "start of combat" can be used to assemble the final combined skin, you should not face any performance problems regarding packing the new skin from larger atlas pages either.

The real difference to using Unity Sprites is in how the individual attachment images are either assembled to atlas pages (when exporting Spine atlases) or how you assign individual Sprites to Asset Bundles (and Unity atlases, if you want finer control) or similar on-demand assets (if you want to avoid loading every texture even if it's not used). In any way, you most likelt want to make sure that only the content that you really use is loaded, so you need to avoid any direct or indirect references to these assets in scenes or prefabs.

Does this make sense for your scenario, or did I perhaps misunderstand some of your constraints?

If you feel more comfortable using individual Unity Sprites, you should be able to use them as well, just be sure to adjust the pivot of your items accordingly and call GetRemappedClone() with the respective parameters.

You're welcome.

Sorry to dig and hijack but we're also trying to incorporate a system of equipment and wondering if we should go the shared atlas route. I tried doing this but it's quite cumbersome and isn't exporting any rotational or positioning data so I assume I've got a workflow issue somewhere.

Is this archaic way still the most up to date?
https://www.youtube.com/watch?v=Im0RB6musvA

Majicpanda wrote

I tried doing this but it's quite cumbersome and isn't exporting any rotational or positioning data so I assume I've got a workflow issue somewhere.

What do you mean by it isn't exporting rotational or positional data?

Majicpanda wrote

Is this archaic way still the most up to date?

Please see the documentation page here.

Packing by folder structure is one possible way, and is still up to date, yes. There are multiple ways to trigger export by folder structure, either manually via the Spine - Texture Packer menu shown in the video, during export of your skeleton, or via the command line interface. Using the command line interface is the recommended way to avoid a lot of repeated manual work.

Ok thank you for that I will start over and follow the video exactly to get a baseline working.

When doing a character with Right/Left + Up directions and equipment is it best practice to do a separate skeleton for the up direction? For performance reasons, it seems most logical to do this so that skeleton image changes aren't called every time the character changes directions. The idea would be on equipping a weapon/armor I would call the attachment change on both skeletons that way it's just hiding/showing the correct skeleton on left/right vs up.

Harald wrote

Majicpanda wrote

I tried doing this but it's quite cumbersome and isn't exporting any rotational or positioning data so I assume I've got a workflow issue somewhere.

What do you mean by it isn't exporting rotational or positional data?

Majicpanda wrote

Is this archaic way still the most up to date?

Please see the documentation page here.

Packing by folder structure is one possible way, and is still up to date, yes. There are multiple ways to trigger export by folder structure, either manually via the Spine - Texture Packer menu shown in the video, during export of your skeleton, or via the command line interface. Using the command line interface is the recommended way to avoid a lot of repeated manual work.

Attempting to follow but getting errors saying there's no matching regions for either Atlas. I have a human skeleton root, exported it with no textures. Ran the packer over the Base Character folder and Weapon folders independently. Dragged the atlas file and png to a Weapons folder in unity and it generated the mat, atlas and everything required no problem for both the Base Character and Weapons.

There's not much in the weapons.atlas.txt is what I was referring to whereas the example "AtlasRegionAttacher" in Unity has a totally different setup than what the video does. It uses a shared atlas but only for equipment. It doesn't try to use 2 atlases in one skeletonData.

Weapons.png
size:1024,256
pma:true
axe
bounds:2,2,500,250
sword
bounds:504,2,500,250

The problem here is that the skeleton is referencing attachment region names including their image directory path "Base Character/" while when calling the Texture Packer manually on the subdirectory "Base Character/" as input directory, this directory counts as the base image directory and so will not be part of any region names, leading to "arm_1" instead of "Base Character/arm_1".

If you want to keep the prefix Base Character/ in your atlas region names (which makes sense), the recommended solution would be to write a simple script to copy your to-be-packed image folders (e.g. "Base Character") over to a packing directory which can then serve as the input directory, and then via the Spine Command Line Interface export the packed atlas, using this parent packing directory as the input directory.

Another way would be to export the Skeleton and select Texture Atlas Pack Image Folder, but this will create a single atlas with multiple atlas pages for each image folder, where you might prefer one atlas per folder.

Harald wrote

When doing a character with Right/Left + Up directions and equipment is it best practice to do a separate skeleton for the up direction?

This is a common solution which has some advantages and drawbacks. Some gameplay framework asset packs on the Asset Store for example are built to switch between separate GameObjects per direction.

On the other hand, having one Spine Skeleton for all directions will allow you to have nicer transition animations from e.g. a walk-up animation to a walk-right animation, which would be more complicated to achieve when having to switch to a different enabled Skeleton. It may also make it easier to control animations in general.

Regarding equipping items and different directions, it will not make much of a difference: you would then equip the goldensword-up attachment at your weapon-up slot and your goldensword-right at your weapon-right slot, while the respectively playing animation will show and hide the respective attachments. You could also see each equipment item as a skin, attaching multiple attachment images at multiple slots, like trousers are also a skin in the Mix and Match example Spine project. You can check out the code in spine-unity example scene Spine Examples/Other Examples/Mix and Match Skins.

Harald wrote

Regarding equipping items and different directions, it will not make much of a difference: you would then equip the goldensword-up attachment at your weapon-up slot and your goldensword-right at your weapon-right slot, while the respectively playing animation will show and hide the respective attachments. You could also see each equipment item as a skin, attaching multiple attachment images at multiple slots, like trousers are also a skin in the Mix and Match example Spine project. You can check out the code in spine-unity example scene Spine Examples/Other Examples/Mix and Match Skins.

This actually makes a lot of sense. I was concerned of the performance problem of constantly changing attachments every direction change, but you're suggesting to run the equip item logic over all slots any equip change and then let the Spine animation itself dictate the slot visibility. Thanks for all the insight, we will see what kind of damage we can do

Glad to hear it helped, thanks for getting back to us.

This new process worked perfectly for being able to use the individually packed atlases, but the rotational info is not in the exported Weapons atlas like the example in the project.

Weapons.png
size:1024,256
pma:true
Weapons/axe
bounds:2,2,500,250
Weapons/sword
bounds:504,2,500,250

I'm using the AtlasRegionAttacher to test the idea out and the weapons are pointed straight along the bone instead of how I positioned and rotated them in the Spine project.

Majicpanda wrote

but the rotational info is not in the exported Weapons atlas like the example in the project.
..
I'm using the AtlasRegionAttacher to test the idea out and the weapons are pointed straight along the bone instead of how I positioned and rotated them in the Spine project.

I'm not sure I understand your question correctly. Please note that the atlas only contains packing rotation of 90, 180 and 270 degrees to fit the attachment better into the available atlas space. Skeleton attachment rotation is not stored in the atlas. It cannot be stored there, since you can use the same attachment (e.g. a dagger attachment) multiple times at a skeleton, with each instance rotated differently to e.g. position one dagger attachment in a mouth, one in each hand and one at a belt.

The Skeleton has each attachment rotation stored at the parent Slot. So when exporting your skeleton, your individual attachment rotations are exported in the .json or .skel.bytes file.

Please let me know if I misunderstood your question.

Harald wrote

Majicpanda wrote

but the rotational info is not in the exported Weapons atlas like the example in the project.
..
I'm using the AtlasRegionAttacher to test the idea out and the weapons are pointed straight along the bone instead of how I positioned and rotated them in the Spine project.

I'm not sure I understand your question correctly. Please note that the atlas only contains packing rotation of 90, 180 and 270 degrees to fit the attachment better into the available atlas space. Skeleton attachment rotation is not stored in the atlas. It cannot be stored there, since you can use the same attachment (e.g. a dagger attachment) multiple times at a skeleton, with each instance rotated differently to e.g. position one dagger attachment in a mouth, one in each hand and one at a belt.

The Skeleton has each attachment rotation stored at the parent Slot. So when exporting your skeleton, your individual attachment rotations are exported in the .json or .skel.bytes file.

Please let me know if I misunderstood your question.

Wow my mistake then... we were going to use spine a few years ago for a project that got too big and I recall simply dragging everything to a slot, rotating and then exporting and it all just worked. I guess the actual workflow is every item needs to be drawn on the X axis pointing right but pivot wise that's something to figure out also since that info is not stored? I assumed I had to drag every item as an attachment to the proper slots and then rotate then move them all so the handle of an axe etc pivot was set.

Majicpanda wrote

I guess the actual workflow is every item needs to be drawn on the X axis pointing right but pivot wise that's something to figure out also since that info is not stored?

Pivot info is also stored at the skeleton, yes.

One easy solution for perfect rotation and pivot offet would be to have one larger attachment image size that fits any future attachments and then let whitespace stripping do the job of removing the unused transparent space, as described a few postings above:

Harald wrote

you could e.g. use a single larger attachment image size with lots of whitespace large enough for all kinds of ear or weapon types, and then let the Atlas export setting Strip whitespace X/Y remove the unnecessary transparent border at each image. This way every image is already positioned exactly where you want it to, without adjusting any pivots.

I finally understood the 0,0 origin for weapon attachments and those are working great with the custom atlas packing, but when moving to all the different pieces of equipment like each foot, leg, chest, arms, etc I'm not quite understanding how all of that equipment will work. It would be quite cumbersome of a flow not to be able to have our artist draw directly onto the skeleton in the PSD or deal with figuring out the pivot of every single slot required to then draw each piece into a separate PSD with 0,0 origin. Is this what's required to make a robust equipment system?

Admittedly I'm not completely familiar with how you can setup PSD layers for export, but what needs to be ensured would be the following:

• You artist shall draw in the real position as usual, no need to move everything to (0,0).
• Each exchangeable layer (e.g. each helmet) bounds need to be setup so that it is "sliced" with the exact same larger bounds that fits all helmets.

So your artist would e.g. draw both a large horned helmet and baseball cap in-place, then setup export layer bounds accordingly so that both helmets fit into it. This will result in unnecessary whitespace around the helmets, which can then be removed by whitespace stripping upon texture packing. This way origins don't need to be (0, 0), they just need to be the same.

Unfortunately I'm not capable of telling you how to setup Photoshop accordingly to "slice" the layers accordingly upon export, I'm just a mere programmer :nerd:. We will find help however in case this is a problem!

Passed this info along to the artist... mere programmer myself here also I really appreciate the time taken to get this process ironed out. I almost feel the Spine workflow will be one of our top 3 systems in the entire game at this point, lol.

Ultimately, do you feel all of this is absolutely necessary or what is the draw back compared to letting spine spit out many, many sheets of atlases and just use basic slot swap API?

The biggest thing we wanted to support was modding in the future which will require static atlases players can draw over, but if it becomes too cumbersome to get all of this working quickly we would need to skip that for now and just get a prototype working. It sounds like maybe the export script for Photoshop may not natively support the slices idea at the moment?