Haha, yes, I can see how this is not entirely clear. So here’s a full recap and rephrasing of the narrative which leads toward and then describes the single proposal that I’m suggesting, as well as the problems it solves:
The lead-in:
So I bought Spine and it was good, but then I was immediately surprised that I couldn't do whitespace trimming when using a mesh. It seems the atlas generator can basically do it, but then the (Unity) runtime doesn't handle the mesh UVs correctly for some reason. This is what the messy runtime patch I posted at the top fixes. It makes the runtime handle whitespace-stripped mesh regions in atlases. It's messy because I wanted to change only one portion of code, and just wanted to hack together something that seems to work alright as quickly as I could.
Anyway, code quality aside, just modifying the runtime in this way is admittedly not a water-tight solution, as it leaves open the risk that too much whitespace might be stripped away from mesh regions. This is because the atlas exporter doesn’t know about a mesh’s extents within its source image. This issue could typically be solved by just adding some extra padding in the atlas export settings, and I fully understand that it still might not be enough whitespace under all circumstances. But I then thought a bit further about all of this, and now this issue, among others, goes away entirely under the proposal which we are leading towards here.
Personally I was already reasonably happy at this point, because now at least I could use meshes and still make acceptably compact atlases by using whitespace stripping, without having to pre-trim all of the body parts before importing them into Spine.
I strongly prefer this workflow of NOT pre-trimming any layers before bringing them into Spine, as pre-trimming has at least the following disadvantages:
It requires extra steps with extra tools, and scripts within those tools (e.g. PS or Gimp + plugins), and/or some silly amount of manual cropping somehow.
Later on if you want to update a body part’s image, it ends up at an incorrect offset if its dimensions have changed due to, for example, adding or removing some decorative hair/spikes or something.
So I was happy but then Pharan rightly pointed out that the regions might get unwieldy and even slow down the Spine editor if they are not pre-trimmed. Yes, this is not good, as the rectangles surrounding each and every little body part can be quite large.
Pharan told me he uses the Photoshop plugin which apparently pre-trims images, and I use the Gimp plugin which did not, and that's why I went and patched the Gimp script to enable auto-cropping of images on export. Now, this is nice and all, but it still involves pre-trimming images, which I still feel is sub-optimal and should not be necessary.
The actual proposal:
And so now, at long last, my proposal involves you guys adding a feature into the Spine editor which enables it to have all the advantages and none of the disadvantages of both untrimmed and pre-trimmed images that have been elaborated on above, and honestly it should be a fairly straightforward thing to implement:
The proposed idea is that the Spine editor would internally maintain a virtual cropping rectangle for each image. The image data does not get modified in any way, there's just this axis-aligned rectangle that describes which portion of the image is relevant. For standard regions, this cropping rectangle automatically adjusts itself in the same way that whitespace stripping would do, except that it is non-destructive. For mesh regions, this cropping rectangle automatically adjusts itself to be the same as an AABB tightly surrounding all the mesh's UV coords, which is trivially calculated from the mesh UVs themselves.
Yes, you probably would want to expand all of these cropping rectangles by a couple of extra pixels to ensure that no artifacts appear at the very fringes, such as half-drawn texels or filtering and mip-mapping issues. But take note that this is NOT the same thing as adding some padding after stripping away ALL of the whitespace, as currently happens with the atlas exporter.
In the editor viewport, the selection/rendering rectangles would map to the cropping rectangles instead of the rectangles of the full source images.
And finally, when you go to export an atlas, the cropping rectangles would tell the exporter exactly how much whitespace to strip from each image, without any risk of trimming too much away.
Problems that this would solve:
In the editor viewport, the selection rectangle surrounding a given region would now be tight and less unwieldy even if it was not pre-trimmed before coming into Spine.
Such regions would also render faster within the editor as only the small portion of the image with visible pixels would be drawn.
The atlas exporter could not accidentally strip too much away from a mesh, as the cropping bounds are always derived directly from the mesh itself.
It eliminates the legitimate disappointment experienced by those who quite reasonably want/expect support for whitespace-stripping with mesh regions, but currently don’t have it.
Spine would then fully support the workflow choice of NOT pre-trimming images. Remember that there are at least two good reasons that people might prefer to work this way: It’s just simpler/quicker/easier to start out with, and then it pays off again and again as it’s also more robust in the face of many small art changes after the initial import.
(6. I haven't really used the skins feature much yet, but it looks like being able to avoid pre-trimming images could go almost all the way to making that feature far easier to work with too! I could be wrong but it presently appears like there's a lot of manual positioning/adjusting every attachment just to make a new skin sit right. The only further (very small) mod necessary to make this work perfectly would be a simple tweak in the policy of where exactly an attachment lands by default when you drag it into a placeholder. Maybe they could all just land at the same location by default, as that's how untrimmed images fit together properly, as opposed to the guess-try of placing the image centred on the bone which is never going to be quite right regardless of pre-trimmed or not pre-trimmed. Anyway, that's a separate idea really, but one that would be facilitated by having proper support for the non-pre-trimming workflow, or as I now call it, the NATURAL workflow!)
So, unless I'm missing something here, there would be several immediate advantages if Spine had this cropping meta-rectangle feature, and it should not be too difficult to implement for highly skilled guys like you. 8) I know you’re busy people, but the biggest hurdle I perceive here is just me trying to communicate the idea well enough to convince you to implement it. :p
Man, I feel like a bit of a nerd after writing all this, but that's life sometimes, I guess?
In short, Spine good, me very tired, bed now.
Cheers,
Jules
