[3.8.99] Skin constraints missing after skeleton dup/import

Abelius

Hi there,

I've duplicated a skeleton to compare how it looks, side by side, with different skin constraints applied... and the second skeleton doesn't include those constraints in the skins.

Steps followed
1.- Open project
2.- Select Male_Side skeleton
3.- Click Duplicate

Expected behavior
Skins constraints are included inside the skins containing them in the original skeleton:

Actual behavior
The same skins don't contain the constraints:

Nevertheless, the constraints "think" they're in those skins:

The same behavior occurs when importing the skeleton from the project file.

I've never noticed this specific case before, but I think it must have something to do with another issue I couldn't reproduce at the time, and I told you guys to forget about until I could...:

Skin constraints/bones not enabled after skin change

This is not exactly the same, but it's very similar in the sense that constraints are not actually in the skins reporting their membership.

I'd be willing to sent you my project by email, if you need.

Also, the log file doesn't tell anything other than the common "Automatic backup complete" lines.

Thank you.

Mario

Please send us your project via email referencing this thread.

Abelius

Done, and thanks!

Søren

Thanks for sending the project.
I've managed to reproduce the bug and have created an issue here: https://github.com/EsotericSoftware/spine-editor/issues/574

Sorry for the trouble, hopefully we can get this one fixed quickly.

Cheers!

Nate

Thanks for the project files. There were a number of problems in Spine with duplicating a skeleton:
1) Skin constraints were not duplicated correctly.
2) The applied skins in the duplicate skeleton were in the wrong order.
3) Linked meshes sometimes appeared in the wrong skin in the duplicate (yikes!).

We've fixed all of these in 4.0.09-beta. Please note we don't plan to do more 3.8 releases.

Have you tried v4 yet? I know you have brought up a number of issues and we keep saying it's all better in v4, so it would be great to hear how it goes for you.

Your project is quite large and using clipping attachments can be very expensive. Are you testing that performance at runtime remains acceptable as you continue to add to your project? I highly suggest doing this periodically to identify any potential performance problems as early as possible.

Another concern is that many of your attachments have warning symbols. For meshes this means that the mesh has weights from bones which may not be active. For example, that could happen if the bones are in a skin, but not in the same skin as the mesh. It could also happen if the bones are in a skin but the mesh is not in any skin.

The ramification of the warning symbols is that some or all of the vertex transforms cannot be computed for the mesh when the bones it is weighted to are not active. When that happens the affected vertices will appear at 0,0 in world coordinates.

When in Spine, if you have unchecked Hide viewport skin bones then all the skin bones are active, even if their skin is not. This allows the vertices that would otherwise be placed at 0,0 to be placed correctly. You should not rely on this though, because at runtime only the bones that are active will be available, just like when Hide viewport skin bones is checked. You will see your mesh either not appear at all because all the vertices are at 0,0 or some of the mesh will be OK and the rest will be stretched to 0,0.

I highly suggest fixing all the warning icons in your project before adding more attachments. It may be a lot of work, but your skeleton won't work correctly at runtime unless you do it. It is much easier to fix the warnings as they appear when making changes to the project rather than letting it get up to hundreds of warnings that need fixing.

Abelius

Nate yazdı
Thanks for the project files. There were a number of problems in Spine with duplicating a skeleton:
1) Skin constraints were not duplicated correctly.
2) The applied skins in the duplicate skeleton were in the wrong order.
3) Linked meshes sometimes appeared in the wrong skin in the duplicate (yikes!).

Yeah, "something" was clearly wrong.

My project, as you could see, makes heavy use of skin contraints, and problems started to appear long ago. I couldn't put my finger on what they were, and that's why I only could offer you a repro method for this dupe issue.

But if I'm to be honest, I'm not sure the description of what you guys have covered in those three points will address all of the glitches I've seen, lol. I speak about skin constraints being listed in other skins, but not really "present", when duplicating skins in the same skeleton.

Maybe it's fixed, as a secondary effect of solving the other ones. I'll need to see it. :p

Nate yazdı
We've fixed all of these in 4.0.09-beta. Please note we don't plan to do more 3.8 releases.

Wait, what? :o

Nate yazdı
Have you tried v4 yet? I know you have brought up a number of issues and we keep saying it's all better in v4, so it would be great to hear how it goes for you.

Yeah well... but that's the thing: v4 is in beta stage, and 3.8.99, apart from these hiccups is very stable and my project is huge. I can't take that risk.

My "business" model is through monthly subscription on SubscribeStar (crowdfunding) and I can't afford getting stuck for days if I find myself in a technical impasse.

But regardless of my personal case I don't think that decision of declaring the current production version 3.8 as defunct and unsupported is a wise move. You're basically forcing everyone commiting to an untested platorm without any overlap with the current stable version.

Yes, I had several issues related to memory in recent versions, but you fixed them in 3.8.9x and that was great, but also kind of taken for granted. Sorry if I sound like an entitled bitch lol, but I mean, version overlapping is standard practice.

Unity, for example, has its LTS (Long Term Support) program:
"These updates will only cover usability fixes aimed at improving the stability of the product to enable users to ship their projects."

In short, they're adding new features to Unity 2020, along with new bugs, but making sure 2019 remains stable and supported until people feels confident about 2020 and its brand new shiny features.

But if you don't support 3.8, then you're basically leaving us no options other than getting stuck in time or doing a leap of faith.

Anyway, I'll stop the ranting about this. I just hope you give a second consideration to that decision.

Nate yazdı
Your project is quite large and using clipping attachments can be very expensive. Are you testing that performance at runtime remains acceptable as you continue to add to your project? I highly suggest doing this periodically to identify any potential performance problems as early as possible.

I added that clipping with some fears, as an experiment. I'll probably remove it if I see a 5 year old computer can't handle the game. Thank you for the heads up.

Nate yazdı
Another concern is that many of your attachments have warning symbols. For meshes this means that the mesh has weights from bones which may not be active. For example, that could happen if the bones are in a skin, but not in the same skin as the mesh. It could also happen if the bones are in a skin but the mesh is not in any skin.

Yes, this is intended. It's meant to avoid a ridiculous number of skin combinations and make management of these models a possible task for a human brain. :p

To illustrate it, in the female model you can see there are...:

1.- BreastsType (4 skins): contain transform and path constraints related to the "shape" of the breasts.

2.- CupSize (5 per type = 20 skins): contain transform constraints to make them smaller or bigger (it's not enough just scaling).

3.- Breasts (4 breast types * 9 skintones * 3-4 tan effect = approx. 120+ skins): contains the images proper, with no constraints.

And that's not all, I also have numerous clothes, like shirts and bras that use the same meshes as the Breasts (duplicated, as they can't be linked yet). BUT could be affected by additional separate skins constraints to make the breasts more firm (because it's a bra, you know). I have many dozens of those as well...

Now imagine I needed to create a single skin, with all relevant bones and skin constraints for every possible combination... hell no. :shake:

So, as soon as I realized I could separate the image attachments from the constraints, I threw myself into it and thanked you guys for making it possible, even if you didn't designed the thing for this use case, lol. In fact, my game wouldn't be possible if I couldn't apply skin constraints "additively".

ALSO, with all the problems I was having (and I still have) when duplicating skins with constraints in them, of course I wanted to stay as clear as possible from needing to manage hundreds of skins that might have, or maybe not, the constraints Spine said they had.

Nate yazdı
The ramification of the warning symbols is that some or all of the vertex transforms cannot be computed for the mesh when the bones it is weighted to are not active. When that happens the affected vertices will appear at 0,0 in world coordinates.

When in Spine, if you have unchecked Hide viewport skin bones then all the skin bones are active, even if their skin is not. This allows the vertices that would otherwise be placed at 0,0 to be placed correctly. You should not rely on this though, because at runtime only the bones that are active will be available, just like when Hide viewport skin bones is checked. You will see your mesh either not appear at all because all the vertices are at 0,0 or some of the mesh will be OK and the rest will be stretched to 0,0.

I don't use that option in Spine. I wasn't even aware it did that, so I'll be sure to avoid it even with more reason now, lol.

I'm aware of the stretching when not all elements are active, yes. It's to be expected and logical, and I'm careful about it because I'm using that system I've described above.

Nate yazdı
I highly suggest fixing all the warning icons in your project before adding more attachments. It may be a lot of work, but your skeleton won't work correctly at runtime unless you do it. It is much easier to fix the warnings as they appear when making changes to the project rather than letting it get up to hundreds of warnings that need fixing.

Acually... it works, lol.

One of your colleages already saw my project and said the same about the warnings, but seriously it works well with additive skinning and it's a blast to have this kind of customization in an adult game.

Maybe I'm exploiting Spine capabilities far more than you thought as the normal use cases, but... I'm not a normal person. :rofl:

Look what you've done, now I look like a pretentious little bitch, haha!

Anyway, just reconsider the support for 3.8, please? I'm sure I'm not alone in this sentiment.

And thank you for your reply and your troubleshooting work.

Nate

Abelius yazdı
But regardless of my personal case I don't think that decision of declaring the current production version 3.8 as defunct and unsupported is a wise move.

3.8 has been out of beta since August 5, 2019. Continuing development on non-beta versions is very time consuming, even when only doing bug fixes. Non-beta versions are being used for production and changes of any kind are risky, require a lot of testing to try to mitigate that risk, and any problems introduced in new releases are an everything-is-on-fire kind of emergency. We lose 2-3 days for even the simplest 3.8 release and a week or more if the changes are more complex. We stuck with 3.8 a very long time, but at this point we have to focus on Spine's evolution. We just cannot do that if we continue to do 3.8 releases.

Abelius yazdı
You're basically forcing everyone commiting to an untested platorm without any overlap with the current stable version.

I only asked if you tried your project in v4. You should not move to a beta version unless you have the additional time doing that requires. We aren't forcing anyone to move to beta versions. 3.8 works and has been used for production for a long time. There may be some issues but likely there are workarounds. This issue you just found with duplicating a skeleton that has skin constraints could possibly be avoided by using Data Import.

Abelius yazdı
I'm not sure the description of what you guys have covered in those three points will address all of the glitches I've seen, lol. I speak about skin constraints being listed in other skins, but not really "present", when duplicating skins in the same skeleton.

I'm not aware of other problems. We are happy to work on them if they do exist!

Abelius yazdı
Unity, for example, has its LTS (Long Term Support) program:

Unity is a multi-billion dollar company. We, unfortunately, are not. There are pros and cons to that, eg we listen to every individual customer, we have quick turnarounds on fixes, you get responses from the owner of the company on a Saturday afternoon, etc.

Abelius yazdı
But if you don't support 3.8, then you're basically leaving us no options other than getting stuck in time or doing a leap of faith.

This seems like overdramatization. 3.8 is not in such bad shape that you are required to update. We have been supporting 3.8 for a long time and it mostly works great.

Abelius yazdı
Now imagine I needed to create a single skin, with all relevant bones and skin constraints for every possible combination... hell no.

You would never do such a thing. Instead you would compose a skin from multiple other skins, which is equivalent to pinning skins in the Skins view:
Runtime Skins - Spine Runtimes Guide: Grouping attachments

One approach to simplifying a project like yours is to make each unique setup in Spine only once, then at runtime change the images as needed. Eg if you have blonde and brunette hair that use the same meshes, you only need to rig one of them, then at runtime you can swap the images to get the other. This way if you have 20 variations that are image changes, you have only the minimum needed in your skeleton's rigging, though you do need to manage changing the images at runtime.

Abelius yazdı
One of your colleages already saw my project and said the same about the warnings, but seriously it works well with additive skinning and it's a blast to have this kind of customization in an adult game.

You should be able to fix the warnings without an explosion in the number of skins or anything similar. The warnings are telling you that a skin doesn't have everything needed to display the meshes correctly. It can still work if you always make those things active by showing other skins, but it can be error prone because it's easy to forget to do so.

Abelius yazdı
Maybe I'm exploiting Spine capabilities far more than you thought as the normal use cases,

Your project is pretty large, but it's not insane, yet. 😉 In such a large project I think it's worthwhile to try to minimize the amount of rigging you do, as described above and here:
Runtime Skins - Spine Runtimes Guide: Creating attachments
By using the rigging as a template, it doesn't need to be duplicated for each variation when the variations can be done by changing the images. Some projects use this to great effect, enabling them to have thousands of variations without needing to rig all that in Spine.

Abelius

Nate yazdı
Continuing development on non-beta versions is very time consuming, even when only doing bug fixes.

Nate yazdı
Unity is a multi-billion dollar company. We, unfortunately, are not.

Nate yazdı
There are pros and cons to that, eg we listen to every individual customer, we have quick turnarounds on fixes, you get responses from the owner of the company on a Saturday afternoon, etc.

Yes, I actually agree with you but... I just needed to try. :lol:

But yeah, "comparisons are odious", you know.

To be honest, I'd be more than happy to jump on a subscription model with you guys. Those $300 I paid four years ago are waaaay amortized in terms of business utility and customer support. And I don't even understand how you are still alive as a company by now.

The thing is, you've made an amazing piece of software, and it has become the bread and butter for a lot of video game animators out there. But at the same time, there's a finite number of us in the World.

I don't have a clue of how many licenses you've sold, but there will be a day you could be a victim of your own success, when new users still buy the software because it's great, but not in enough numbers to justify, as you've appropriately pointed out, the owner of the company, along with his few staff, giving detailed responses in the forum.

I don't think a $100 yearly sub would be a deal-breaker for people that makes a living thanks to Spine, and it might make a huge difference for you guys.

Nate yazdı
Abelius yazdı
Now imagine I needed to create a single skin, with all relevant bones and skin constraints for every possible combination... hell no.

You would never do such a thing. Instead you would compose a skin from multiple other skins, which is equivalent to pinning skins in the Skins view:
Runtime Skins - Spine Runtimes Guide: Grouping attachments

One approach to simplifying a project like yours is to make each unique setup in Spine only once, then at runtime change the images as needed. Eg if you have blonde and brunette hair that use the same meshes, you only need to rig one of them, then at runtime you can swap the images to get the other. This way if you have 20 variations that are image changes, you have only the minimum needed in your skeleton's rigging, though you do need to manage changing the images at runtime.

This is interesting but it says "A skin can be created programmatically, then populated with the attachments from other skins". It says attachments, not images. And this...:

newSkin.addSkin(skeletonData.findSkin("pants/green");

...is exactly what I'm doing right now. This is part of my PlayMaker skin action:

What I've understood by your suggestion is that there is a way to create an attachmente at runtime and give it an image path? And then add that attachment to a new skin? I mean, creating a skin based on attachments that don't even exist in the skeleton hierarchy?

If that's the case I'd be interested in knowing how, yes. That way I could get rid of all "images only" skins like the hair, multiple skintones, etc.

Nate yazdı
It can still work if you always make those things active by showing other skins, but it can be error prone because it's easy to forget to do so.

Don't underestimate my OCD powers, mortal. :mmm:

Nate yazdı
In such a large project I think it's worthwhile to try to minimize the amount of rigging you do, as described above and here:
Runtime Skins - Spine Runtimes Guide: Creating attachments

Ah, now it is actually talking about "creating" an attachment. You actually meant about this up there, right?

The only problem is that it's only a paragraph with no definite instructions. I've tried to find it in the runtime docs, with no success. Could you point me in the right direction, please?

Nevertheless, there's one thing I like about using premade skins, which is that they represent an abstraction layer to avoid issues in Unity, if I need to change the names of the attachments or images.

Even though I'm also the "coder" for my game, I still like to have animation and logic as separate as possible, if that makes any sense.

Nate

Abelius yazdı
I don't think a $100 yearly sub would be a deal-breaker for people that makes a living thanks to Spine, and it might make a huge difference for you guys.

It would make a big difference. I personally hate subscriptions. There are ways to do it fairly, but they are complicated. For example, you can continue to use the version at the time you purchased and new updates for 1 year, but to move to newer versions you'd need to pay again. This is complex to implement and doesn't encourage everyone to use the latest version, which isn't great. I don't want us to spend a bunch of time on this licensing setup, so instead we have a "Robin Hood" model where big businesses pay yearly and everyone else pays only once. While we don't make as much money as a subscription would, this is much more pleasant for users and better for adoption to individuals who will then push the companies they work for to buy the yearly license.

If you really want to help, then just make more than $500k USD/year and license Spine Enterprise yearly! 😃

Abelius yazdı
It says attachments, not images.

In Spine terminology "image" is usually short for "an image file, eg a PNG". In some cases an "image" refers to a texture region, usually a portion of a texture atlas page image. An attachment is a thing that goes in a slot. There are region attachments, mesh attachments, path attachments, etc. Saying for example "attach an image to a bone" isn't really correct, instead it'd be something like "create a region (or mesh) attachment with this image and set it on a slot which is on a bone".

Abelius yazdı
This is part of my PlayMaker skin action:

Looks good (except the brackets should be on the same line!).

Abelius yazdı
What I've understood by your suggestion is that there is a way to create an attachmente at runtime and give it an image path? And then add that attachment to a new skin? I mean, creating a skin based on attachments that don't even exist in the skeleton hierarchy? ... Ah, now it is actually talking about "creating" an attachment. You actually meant about this up there, right?

Yep. For example, you get an attachment out of the skeleton data, copy it, then change the image it uses. It is common to have more image files than can fit into a texture atlas, so one approach is to use loose image files at runtime, determine all the images needed for a particular configuration of a skeleton (hair, clothes, lack of clothes, etc), pack those loose image files into an atlas at runtime, then use that atlas for rendering.

Abelius yazdı
The only problem is that it's only a paragraph with no definite instructions. I've tried to find it in the runtime docs, with no success. Could you point me in the right direction, please?

Harald will know which examples are an exact match, but check the examples here:
https://github.com/EsotericSoftware/spine-runtimes/tree/3.8/spine-unity/Assets/Spine%20Examples
Specifically the Other Examples/Mix and Match* examples are likely helpful.

Abelius yazdı
Nevertheless, there's one thing I like about using premade skins, which is that they represent an abstraction layer to avoid issues in Unity, if I need to change the names of the attachments or images.

That is true, though at the cost of a more complex skeleton. The main advantage is probably the speed at which variations can be added, and there are performance gains enabled by packing an atlas at runtime with only the images needed.

Abelius

Nate yazdı
If you really want to help, then just make more than $500k USD/year and license Spine Enterprise yearly! 😃

What a big problem to have, yes. :smirk:

Also, thanks for the follow up instructions. Now I wonder if that would be compatible with asset encryption...

This is turning offtopic already, but you may be excited to know that after some serious nagging, a plugin from the Asset Store is now capable of protecting exported files from Spine to Unity.

There's only some compile errors remaining, and for that the author of the plugin told me he'd contact you guys soon.

But it's working for me already and it's awesome. Asset rippers will cry, I'm sure. :p

Nate

Using some protection is better than nothing, but of course there can be no foolproof protection. Using an off the shelf solution is convenient and a lot less time consuming to build and integrate, but will always be easier to rip than a custom solution since it's a bigger target for crackers.

Abelius

Yes, I know what you mean. Look at Red Dead Redemption 2 on PC.

Anyways, I'm excited because I can finally close the door of my house when I leave. Just that makes a real difference.

Before this, ANYONE could dump all assets in a couple minutes with zero effort. Anyone.

Now it's only someone with skills and determination. Two qualities the typical lazy "creator" with the cheap excuses of "I like your game so much that I want to make a spin-off" or "you're not fast enough, so step aside", severely lack of.

So yeah, I'm happy, lol.