Multiple Map Workflow (Normal, Mask, Emission, etc.)

Arzola · 2021年4月14日

Sometimes you may need several different versions of a same attachment for a project, and I don't mean skins, I mean that a single attachment can require for example, a normal map, an emission mask, etc. images that convey extra instructions to draw said attachment with a custom shader.

Is there any optimal workflow for exporting several maps at once for a set of skins?
Bouncing off the initial description, let's say I have 5 skins, and each of the attachments of these skins comes with a normal map, and a mask for a special in-game effect. And so, just for organization purposes I keep the following folder structure:

Color
|- Skin 1
|- ...
|- Skin 5

Normal
|- Skin 1
|- ...
|- Skin 5

Mask
|- Skin 1
|- ...
|- Skin 5

As you can imagine, the only folder that is actually used in the spine editor is the color one, and as expected, only the color folder images will be exported to the final atlas. So now, my question is, how should I go about exporting the other maps optimally?

I thought about it for a bit, and it seemed that my best option would be to:
1 - Export as normal, both the generated json, and the color folder atlas.
2 - Use the standalone packer to make an atlas for each main folder (making use of combine subdirectories), and ignore the generated atlas information (as in, the txt that stores the png name and attachment positions).
3 - Copy the generated pngs for the extra maps to the game folder, renaming them as seen convenient.

And I thought it was a pretty good approach... until I had to start disabling some skins. So now, if I wanted to skip the export of skin #2 and #4 (for example), I'd have to add pack.json files that indicate the skip on those subfolders, one for each of these skins for each of the main folders (one for #2 in normals, one for #4 in normals, one for #2 in mask, one for #4 in mask). And while not the end of the world, it can be time consuming on the long run.

So that's mainly why I'm asking if anyone has this sort of situation and has come up with a better solution (If it helps with anything, I also have paid versions of texture packer pro and similar applications).

Nate · 2021年4月14日

If you need the packed normal and mask images to match the color images, the texture packer is deterministic and will pack them exactly the same if the normal and mask images have the exact same silhouette as the color images.

Either way, you can pack all of them into a single atlas or pack multiple atlases and discard the .atlas file for the normal and mask images.

Arzola wrote
until I had to start disabling some skins. So now, if I wanted to skip the export of skin #2 and #4 (for example)

Wait, why would you want to not export some skins? Skeleton data is not intended for partial exports. Exporting all the skins is not much more data. If the idea is to not load all the images for all the skins, keep in mind that the images/atlas are completely separate from the skeleton data. With a little configuration at runtime, you can use skeleton data with an atlas that does not contain all the images. That is done by specifying your own AttachmentLoader.

Here is an explanation I wrote in the past:

AtlasAttachmentLoader is used if an AttachmentLoader is not specified. It has this code to find a mesh's atlas region (varies a little per runtime):

public MeshAttachment newMeshAttachment (Skin skin, String name, String path) {
   AtlasRegion region = atlas.findRegion(path);
   if (region == null) throw new RuntimeException("Region not found in atlas: " + path + " (mesh attachment: " + name + ")");
   MeshAttachment attachment = new MeshAttachment(name);
   attachment.setRegion(region);
   return attachment;
}

You can write your own AttachmentLoader that does similar, but you can customize how it looks in the atlas (instead of using the path) and what happens if a region can't be found (instead of throwing an exception). You'll need to do that for newMeshAttachment and newRegionAttachment, which are the only two that use atlas regions.

For example, to change how it looks in the atlas, you could prepend the skin name to the path, or look in multiple atlases to find the region, etc.

If a region can't be found, you could return null, which means the skeleton will not have the mesh attachment at all. Note that if the skeleton data has linked meshes that use this mesh as a source mesh, it will cause an error to return null.

Or, you could just return the attachment without setting its region. That is the safest, as you can still use its linked meshes, but it means trying to render the attachment will fail. That is probably fine, since if you don't have a region for the attachment, it's probably because you won't be rendering it.

TLDR; copy AtlasAttachmentLoader, paste it into your project, rename it, customize the newMeshAttachment and newRegionAttachment methods, and then create the JSON or binary loader like this:

var loader = new SkeletonJson(new MyAttachmentLoader());