Nate escribióIanM escribióLet me duplicate a skeleton by reference, so that it syncs changes, but allow me to change the directory the images folder points at.
This synchronization would not be easy to implement.
I can imagine, and I have a hard time imagining any use for such a sync to a skeleton in the same scene besides supporting this one strange use case. I only mention it because it's an example of a feature that would sand off one of the remaining friction points in this ad hoc setup. That's not to advocate for the feature itself, just clarifying the pain point/use case; perhaps something the resolves the same problem as a sync would do the job, and be more reasonable!
The specific problem is that changes to the main rig don't propagate to the duplicated one, causing a potential source of errors, possibly subtle ones. My current best workflow workaround for preventing those errors is to make sure I delete and rebuild that skeleton before every export, which is extra manual bookkeeping, or to manually keep track of when I change the rig enough that I need to do so and risk forgetting and having a broken export. If there's a risk that human error could break the atlas sync, as well, that means I need to be checking my export to verify that the sprites line up, which is another thing to worry about.
I'm actually a little leery of asking for tooling for such a clearly ad-hoc workaround, since that feels like just applying duct tape to my ramshackle workflow instead of finding an elegant solution. Additionally, a little bit of discipline around the export process is annoying but considering it's an infrequent operation compared to the time I spend rigging and animating, it's definitely tolerable.
Still, spit-balling some alternatives for discussions sake:
- Being able to automate this as part of my own export step; I've read that there aren't plans for scripting support, but if there were that'd be one place I could do this; on each export, delete the duped skeleton, duplicate again, rename, change image directory.
- Actually, is it possible to have an ad-hoc scripting solution? Earlier you linked to a spine visualization tool with source code, and I'm wondering if the spine editor format is exposed in API a way that'd allow me to write a script for this... then maybe be able to hook that up to the export chain somehow so it fires every time there's an export? Or just trigger the editor export from the script itself?
- Option in export settings to generate the skeleton for specified image folders, then clean it up afterwards. Loses the visualization aspect and another weird thing to turn into an export setting, but would be error free; if that was there, my process might be to make my duplicate skeleton non-exporting and just use it to visually check the results.
- Somehow make the other skeleton "by reference" or something? I'm not sure if that'd actually represent a simpler approach at all, but I could at least imagine it being useful for use cases other than mine when you want to reference external spine files to animate a multi-character interactions or something. Thinking something like the xref stuff in 3DS MAX.
IanM escribióInstead of a binary export toggle, let me turn off the atlas.txt and .JSON parts of the export and only put out the atlas PNG
This isn't hard to do. I'm not sure where such a setting is best placed. It's a bit of a strange feature to do a JSON export with packing and then delete the JSON and atlas files. Putting the setting in the UI is likely to confuse people. It could be a setting in the pack settings JSON, but when Attachments packing is used then the pack.json files are not used. If you can change to packing using Image Folders or running the texture packer separately from JSON export, then the having the setting in the pack.json would work well.
That might work. You're right that it's a strange feature; it's hard to imagine it being helpful for anything else, so sticking it in as a bonus feature in the pack.json doesn't sound unreasonable, it'd be clutter in the export UI that basically nobody would use.
This might also just be something to tool up on the import end; if I gave it a consistent naming scheme, pretty sure I could write a Unity-side import processor that culled out the unused files. A little bit shaky, but as long as we're talking about just sanding off rough edges on a workaround solution for a non-standard use case, it's not unreasonable. After all, it's not even like the extra files even cause problems, they're just clutter!
Though, that makes me wonder... how non-standard is this use case? How many studios using Spine have run into a similar workflow issue with multiple texture maps, and just ended up developing processes or tooling in-house? It strikes me as a feature a lot of game studios might want, particularly for more polished productions or games where normal maps would be valuable for a complex lighting environment... or do studios with those requirements usually self-select out of 2D skeletal animation approaches entirely and go straight to 3D? Hm.
This might also be my bias as a tech artist here talking. It's easy to look at an art problem and start excitedly babbling about how I could write a shader for that. "Art problems? I bet I can solve that by throwing MATH at it!"
...Unrelatedly, I keep hearing people mention something about hammers, problems and nails. Didn't catch what they were saying, though, too busy writing shaders. 😛
Such a pack.json setting could be specifically about your use case. If the setting is telling the packer that this atlas is to be used as matching images for another atlas, then it could avoid writing the atlas file and also do checking to ensure the bounds for all the regions match up with the regions having the same name in the other atlas.
Being able to guarantee that alignment would probably be worth giving up the attachment culling (and I think the rig meshes for polygon packing?) of exporting the rig. One benefit of the machine doing it would be not having to worry about checking the images afterwards to see if they've drifted apart, which shaves another manual step off the process while we're at it.
I prefer keeping my images folders clean rather than relying on Attachments to only pack the images that are used. We'd like to provide tools for cleaning the images folders, moving unused images elsewhere. It's also usually better to run the texture packer separately, which means packing everything in the image folders. This is because there is often a build process that involves packing images not just from one skeleton but from many, possible including images used for things other than skeletons.
Maybe it's a bit sloppy, but I have appreciated being able to keep unused images around without them bloating the atlas! It's let me experiment more easily with image variants or optimizing things by reusing sprites, and keeps me working in Spine instead of my image editor or file system. I've also used it to do a few goofy things like stick in target dummies in enemy animations to demo/visualize how an attack would affect the player... though I suppose I could also do that by sticking those Spine-only images into a folder with a pack.json that prevents export?
As much as I like how it strips out unused images it's not really that much to ask to do a little cleanup here or there, or even just tolerate a few extra sprites in the atlas; it can be a little bit of a hassle on particularly complex rigs, but if you're thinking of tooling that up anyway that makes that a moot point.
