Can Only Export at 50%

wewrwer

I am running the Spine 4.0.35-beta on MacOS and I can only export pngs at 50% of size. If I try to render at 100% it clips 1/3 of the image off. The same file renders find in 3.89. Is this a known issue, or has something changed?

The clipping shows in the preview at least. It caught me off guard when rendering for the first time in the beta. I can't go back to version 3 because of color. I was spending hours adjusting each export because of the lack of color management.

wewrwer

Erika

Hello,
wild guess here, but did you perhaps enable Viewport pixel grid? Settings - Spine User Guide: Viewport pixel grid
It is known to stop rendering beyond a certain size so it may be the cause.

Otherwise, could you provide visual examples of what happens?
or check the logs to see if Spine is actually registering an error?
You can find the log here:
Settings - Spine User Guide: Log

wewrwer

There's no error, it's just a bug. Now it's only letting me save at 25%. Here's a picture of it at 50. It's only half there. It exports exactly what's shown.

Also, there are major problems with color still. Affinity saves properly, but sometimes now when opened there's no color profile. It's just gone and looks terrible. I can't go back to version 3 because it doesn't have proper color.

Nate

Regarding the export not being rendered fully, if you aren't using the "viewport pixel grid" setting then it looks like a bug. Is it possible to send us the project and images so we can reproduce the bug? contact@esotericsoftware.com We only need enough to see the problem, so you could cut the project down if you'd like. Either way we will keep your files private.

Regarding correct colors, are you using the "color management" setting in Spine v4? That will use your monitor's ICC profile when rendering colors to the screen. Note that is separate from reading color profile data from an image file when the image file is read, so that colors stored in the image file are interpreted as intended when they were saved. When you save PNGs from Affinity, are you saving them as sRGB or with some other profile? Can you provide a problematic image so we can see the problem?

Thanks for your help! We'd love to get all of this fixed up.

wewrwer

It's definitely a bug on the color front too. I will try to reproduce. I have two monitors with different color profiles, but this is stripping out the profiles. In the project folder it is correct if you open the images in another program. No setting in Spine affect the result when this happens.

In addition the upgraded old project files would not update the color if I saved new sprites from Affinity. The only way to get them to update was to delete all of the sprites with Spine open and export again. Something is not getting flushed properly. There might be an issue with states. It could be another end of the bug where it doesn't render the color properly.

I also could guess that perhaps a setting is not expecting such large files. I need to render for 4k displays, so the file is quite large. I will send you shortly.

Edit: Sent

We did some more testing. It is definitely a bug.

Were you able to replicate it? If not I can make a video and send another file.

Nate

Thanks, and sorry for the delay. We've reproduced the problem with exports not rendering fully. Interestingly it happens because a GPU buffer was used that is also used to render the Spine window

the clipping of the export happens when the Spine window is smaller than the export! Such unexpected silliness can make reproducing things surprising since it depends on the export size, monitor resolution, if the Spine window is maximized, etc. Anyway, we've got it fixed in 4.0.37-beta which we'll release today.

For the color problem, how can I see the problem? Is a particular image that you sent not being displayed correctly?

wewrwer

I reproduce the color problem on the latest beta on a fresh install on another computer. I will send you a file now.

To reproduce, look at the difference in the color in the folder, and in Spine. I am using MacOS so maybe this problem doesn't exist on what you are developing on. The weird thing is that it was solved, and now it won't update the color. I will be sending you another file now. Completely different project file. The images are the correct color in the folder, and in Spine they show up without profile.

Thank you for solving that annoying bug. I assume Apple will make your life stressful for the next year. I will not be updating to Apple Silicon or Big Sur for at least a year, maybe longer!

Edit: The easiest way to see is the pink in the nose. I know people all see color differently too and have different monitors, but this should be clear.

Abelius

Hmm... I'll also semi-highjack this thread, because if I've understood well, I'm also getting cut images while packing with v4.

Take a look...:

Those are supposed to be forearm images, going from the elbow to the wrist, but only the wrist area is shown.

Also, I've noticed there's a lot of unused space in other atlases and the number of expected files is less than I had before. And indeed, while Spine is packing it tells me this...:

It recognizes 4347 images at the start, but then it only packs 3075.

In the other hand, when I pack with 3.8.99, I get almost all of them packed...:

...and 21 atlases instead of only 15.

So yeah, I'm not even trying importing in Unity.

These are my packing settings...:

...but I also tried with the 'Fast' option unchecked. No difference.

My project uses pretty big images exported at canvas size, so I understand I'm on the extreme side of use cases but... this is a complete showstopper for me.

Nate

@wewrwer Thanks for the emailed files. We've been talking via email, but so far we're not able to get the PNG files to show up incorrectly in Spine. We can continue via email, just wanted to let everyone else know we didn't ghost you. 🙂

@Abelius I don't think your problem is related to the incomplete export (which is now solved) or PNG (which is ongoing) problems, but we are happy to help.

The images in the atlas not appearing fully is very odd. If you pack with Debug checked it will draw magenta borders, maybe that helps see what is going on. For example, it may show images are overlapping. At any rate, it looks like a bug. Can I bother you to send the images and texture packer settings JSON? If you are packing meshes we'll also need the .spine file so whitespace stripping works correctly.

Are some of your images identical? That could explain why it doesn't pack the same number of images found. CheckingAlias will avoid packing images that are the same (after alpha threshold is applied). How do you know only 3075 are packed? By that I mean, where did you get that number?

Abelius

Hi Nate,

Nate ha scritto
Are some of your images identical? That could explain why it doesn't pack the same number of images found.

I've duplicated some meshes to another slot and sort them as needed. So yup, I expected the final number not being identical. But 3075 from 4300+ is definitely unexpected. :p

Nate ha scritto
How do you know only 3075 are packed? By that I mean, where did you get that number?

From the export process popups. With both versions, 3.8 and 4.0, it first lists the total number of images you have...:

...then, at a later time, it changes to the actual images to be packed in the atlases...:

3.8.99

4.0.38b

Also the number or atlases is not right. I should be 21 and 8, for the female and male models, but I only get 15 and 3.

Nate ha scritto
The images in the atlas not appearing fully is very odd. If you pack with Debug checked it will draw magenta borders, maybe that helps see what is going on. For example, it may show images are overlapping.

I've tried, and the first thing I've seen is an after-export popup with a TON of this kind of messages...:

Female/Arm_B_Dark1 is an alias of: Female/Arm_B
Female/Arm_B_Dark2 is an alias of: Female/Arm_B
Female/Arm_B_Gyaru1 is an alias of: Female/Arm_B
Female/Arm_B_Gyaru2 is an alias of: Female/Arm_B
Female/Arm_B_Pale1 is an alias of: Female/Arm_B
Female/Arm_B_Pale2 is an alias of: Female/Arm_B
Female/Arm_B_Tanned1 is an alias of: Female/Arm_B
Female/Arm_B_Tanned2 is an alias of: Female/Arm_B

I don't know what it means with "alias". They're different images that point to the same master mesh, yes, but the skintones are very different and they definitely need to be exported.

Also, this is how the previous atlas looks like with the magenta lines...:

It also looks very wrong, because the forearm image starts much higher.

Remember, though, that I'm using that "technique" of mine of exporting from PhotoShop at canvas size, so future versions of the same images maintain their position and size. I wonder if something changed in 4.0, that made the cropping of meshes, originating from huge images, innacurate so this could happen?

However, I also have these from the female model...:

...and these in particular are trimmed before export from PS. And they're badly cut all the same.

Anyways, I've disabled the "Alias" option and tried again, and I've got this madness...:

Now I have the expected number of atlases, but some of them are completely blank.

I've also reduced the Alpha Threshold to zero, but the result is the same.

Nate ha scritto
Can I bother you to send the images and texture packer settings JSON? If you are packing meshes we'll also need the .spine file so whitespace stripping works correctly.

Not sure what you mean with the 'packer settings JSON', but I'll send you the whole thing. Thanks. 🙂

Ah, I'm also having this other issue...:

I save the project as 4.0.38b, and 4.0.38b itself, nor 4.0.39b, can open it.

Another showstopper. :lol:

I've attached the log to the post.

Edit: 4.0.39b did open a project saved by itself. Problem solved, I guess.

Nate

Welp, I must say you are quite good at finding problems! :scared: We'll take a look ASAP!

I was able to open both if your project files in the ZIP. Can you please send the project file that won't open? That may be a pretty serious issue.

Abelius

Nate ha scritto
I was able to open both if your project files in the ZIP. Can you please send the project file that won't open? That may be a pretty serious issue.

It only happened with 3.0.38b.

I opened a 3.8.99 project, then I saved it as "4.0.38b-blahblah", and when I tried to open it again with 4.0.38b, it couldn't.

The day after, I upgraded to 4.0.39b and tried to open "4.0.38b-blahblah" again, and still couldn't.

But when I loaded the 3.8.99 project, and saved it as "4.0.39b-blahblah", it worked. So I guess this issue, in particular, is a problem no more.

Now it's "only" the blank packing remaining. :p

Nate

We've fixed the texture packing in 4.0.41-beta! It will be available today.

We also made some efficiency improvements. Spine was getting ₉₇ FPS when playing an animation in your project, now it gets ₁₄₂ FPS, for a gain of +45 FPS. :fiesta: With both skeletons visible and playing an animation I get 107 FPS.

You have many of the same image with different colors. A whole lot of these could be tinted instead of using separate images. Two color tinting (aka "tint black") makes tinting very powerful when used with grayscale images. It's a technique Nintendo uses a lot. See the third Mario coin here:
Attachments - Spine User Guide: Tint black

You could have just one attachment in Spine per unique image, then tint it at runtime. That would simplify your project a lot, since you wouldn't need many hundreds of the same attachment in different colors. You could have a file that stores the color combinations for tinting at runtime. You could probably use the same colors for many different grayscale images. That means adding a new attachment with all possible color combinations would just be added a single attachment in Spine.

If two color tinting is not flexible enough, you could use palette swapping at runtime.

4.0.41-beta is up now! Spine: Changelog: v4.0.41 beta

Abelius

Nate ha scritto
We've fixed the texture packing in 4.0.41-beta! It will be available today.

We also made some efficiency improvements. Spine was getting ₉₇ FPS when playing an animation in your project, now it gets ₁₄₂ FPS, for a gain of +45 FPS. :fiesta: With both skeletons visible and playing an animation I get 107 FPS.

Damn, I missed this post. I'll be sure to test it. That seems very promising.

Nate ha scritto
You have many of the same image with different colors. A whole lot of these could be tinted instead of using separate images. Two color tinting (aka "tint black") makes tinting very powerful when used with grayscale images.

I'm doing that with the iris, but when we tried with the hair, which has 2-3 color tones in some cases, the results weren't good. I think the grayscale reduces saturation quite a lot and, even if I still can tint the "black" pixels, it's very difficult to find the sweet spot so it looks similar to the original one.

At the end, the result is an image with less contrast. Like if you're tinting your grey hair with two colors and expect one tinting only specific strands, while the other stays in the background...: not happening. It ends up too uniform and... "dull"? I don't know how to explain it better than this. I'm not an artist.

Then again, I'll probably do it with the body parts (the flesh), because I have plans for adding demons and furries, and skin is supposed to be uniformly colored anyway.

Nevertheless, it's nice to know I have more options in case I hit some hard limit in the future.