- 編集済み
Feature request (if not already implemented)
Hi there,
I'm trying to auto-compute weights for a mesh with 98 bones.
Yeah, I'm that crazy. :p
And it can't... as I more or less expected:
It's very possible that I'll need to it by hand, which is ok by me. I won't ask the impossible from the software, I suppose.
But I'm asking myself if there is some way to select a bone and all of its children, instead of needing to click on every one of them individually.
If it's not, it would be nice to have them selected if you hold down Ctrl key or something like that.
Thanks for your time.
BTW... is there a fixed maximum of bones that Spine it doesn't even try to compute?
What happens when you click Auto?
You can shift + click in the tree to select a range of bones. Hide non-bones to make it easier.
Hi Nate,
I click Auto and Spine immediately (about a 0.2 sec) says it cannot compute weights. None of the bones are intersecting but I admit there's a lot of them, they're pretty close and the mesh has 450 vertices... :p
About pressing 'shift', I've tried it but when I click on one of them it only selects it, and all its children stays white.
I mean, it's in the stage of selecting bones when you press on 'Bind' and the cursor changes to "Pick" next to the arrow. Outside of this I know I can select multiple bones by holding shift, but if I do that then I change the context to the first bone clicked, exiting the mesh weights context.
Ok, I've reduced the moronic number of bones and now it's able to calculate their weights.
Nevertheless, my thread is not about that but my humble suggestion to implement that 'select bone and its children' feature I've explained.
I see myself doing a lot of hair meshing and I tend to put a lot of bones in there, so later on is a little hassle needing to select every one of them... with focus on the word 'little'. 
Anyway, thank you for your time.
Can you please post or email your project which weights cannot be computed? It should work on any mesh, with any number of bones. contact@esotericsoftware.com
Ah you mean when binding bones for weights. I've added an issue:
https://waffle.io/EsotericSoftware/spine/cards/58584b88e11f8e4001c11bb3
Nate wroteCan you please post or email your project which weights cannot be computed? It should work on any mesh, with any number of bones. contact@esotericsoftware.com
Sure! I'll email you a link to the project. Please keep in mind that it's NSFW, although I've hidden all the naughty bits in the view. :p
And here's what I wanted to do...:
That triangle is the hair root bone and the rest are 'chains' for the strands. The head bone (not visible) do not participate in the weighting as it would intersect with some of the strands, hence the hair root bone to avoid that.
As you see there are no noticeable intersecting.
But... I've reduced the bones AND also separated them so the end tips doesn't enter inside the 'ring' of the next, and I got Spine computing the weights without problems... I don't know if I've could do that from the start and avoid the problem, but only to think about redoing the thing again it gives me a headache. 
Nate wroteAh you mean when binding bones for weights. I've added an issue:
https://waffle.io/EsotericSoftware/spine/cards/58584b88e11f8e4001c11bb3
Thank you! Do I need to do something in there? Or just keep an eye on it? I'm not very familiar with those boards... :mmm:
Thanks, we'll take a look at the project tomorrow. It could be that bones were intersecting. Maybe we can improve it, at least tell you what bones are problematic.
The issue is for tracking. You can click the issue number on the Waffle to be taken to GitHub, then you can click Subscribe to be emailed when there is activity on the issue.
Having a mesh with more bones that vertices is maybe a bit odd. Do you really need that many bones? If so, you might find it easier to manipulate if your constrain the bones to a path, like the stretchyman example project.
Nate wroteThanks, we'll take a look at the project tomorrow. It could be that bones were intersecting. Maybe we can improve it, at least tell you what bones are problematic.
Much appreciated.
Just to be sure I've taken on the (best?) practice of starting the next bone outside the tip of the previous. At least in long chains.
Nate wroteHaving a mesh with more bones that vertices is maybe a bit odd. Do you really need that many bones? If so, you might find it easier to manipulate if your constrain the bones to a path, like the stretchyman example project.
The mesh has 450 vertices and 98 bones actually, but I don't know...
With putting such long bone chains together I achieve a more natural hair swinging effect. That's the only thing I need really. My animations tend to be more realistic than cartoony, so no stretching is needed. But I admit I would be missing an alternative way of doing things here.
I'm lost with those path constraints so I've never used them, but you're surely right and I'm letting the "good enough" method blocking my way to learning, so I'll take the effort of reviewing them. Thank you.
Path constraints are awesome for hair and other wavy, flexible things. It lets you define the motion of many bone with just a few control points!
No problem! 
Note when you are binding many bones that the vertex gets stored for each bone. If you have 200 vertices and bind 100 bones, under the covers Spine is dealing with 200 * 100 = 20,000 vertices. This is why it is somewhat slow in the editor to rotate your hair mesh above in setup mode
it's doing a bunch of computations on 20k vertices. At runtime things are optimized so it only stores a vertex for each bone which has a weight > 0 for that vertex. This can still be a lot of vertices, but is much less than what the editor has to deal with. However, every time you set a deform key (by moving a mesh vertex), it has to store all those vertices again. You can see how many this is by looking at Deform vertices in the Metrics view. Using Purge can help. The ramifications of using many deform keys on vertices that have many bones bound is larger JSON/binary data, more memory usage at runtime, and of course it takes more CPU to apply a large deform key and to compute the mesh vertices world positions. On the other hand, if you don't encounter any performance problems, you don't have anything to worry about.
TLDR; for best performance, try to avoid huge meshes with many bones bound, especially for mobile.