• Editor
  • Request - Allow user to further reduce bone scale in v4.0.xx

In settings in 3.8.xx, I have bone scale set to 15. This allows me to see and easily select from the large number of overlapping bones (crosshair bone type, bone length = 0) in my skeleton:

However, in 4.0.xx, with the new high-res bone graphics, I have set bone scale to 0.1 (apparently the smallest setting), and the bones are still huge compared to 3.8.xx. This makes it almost impossible to see and select these crosshair bones when they are near each other:

This is the same area of the same skeleton - sorry that textures are on/off in the different screenshots.

Second Request: I would love it if there was a bone type that was simply a dot or a very small +

Related Discussions
...

What... what are all those bones needed for!?

Bone scale wasn't very useful in 3.8 and works very differently in 4.0. The idea is that bone scale allows you to set the zoom level at which bone icons start to get smaller.

To better understand how to improve bone scale for your use case, maybe you could send us the project from the screenshots?

Here is the file. My goal is indeed to control the "zoom level" of the bones - I just want them to be incredibly small and precise. I would like for their minimum scale (0.1) to be at least 25% of the current size, if not smaller.

As for the use, rotate m700_AIM_000_shortcut and you'll see that the skeleton has isometric rotation that looks 3D. One of our biggest time sinks in creating our humanoid characters was having to re-animate each skeleton in every direction (8-directional) for every animation state. So I built a skeleton that could be fluidly rotated (with mesh distortion for tweening, still in the works), so it can be animated in one direction, and then just rotated and texture-swapped (with texture draw order re-sorted) for the other 7 directions.

The number of constraints is to create the isometric rotation on a number of bones at each lateral layer of the skeleton. Effectively, to achieve the isometric distortion, I have to create a special set of bones at every "vertebrae" of the skeleton.

I'm going to be able to simplify some of the bones in the head that control mesh distortion in the face (what you see in the screenshot above), but unfortunately, due to how vertex sorting is handled, I may have to keep many of them. If you allowed us to sort vertices manually rather than relying on the order of the bones that the mesh is constrained to, I could drastically simplify the skeleton.

I also really need a way to quickly view sort order, attachments, constraints without having to scroll through miles and miles of the tree. See thread here: Ease of Use UI Proposals - Improved Tree & Animation
Specifically, this suggestion about the interface:

Your reply:

Annotations in the tree should help jumping to constraints. We added the Animations view some time ago as an easier way to access animations. We could do a similar thing with separate views for skeletons, skins, constraints, and maybe draw order. This may be simpler than your proposal and seems like it would address the problem about as well?

Thanks for the file. We spent quite some time adjusting things to allow a greater range for bone scale. In 4.0.51-beta (available now) setting a bone scale of 0 means that the bones will never grow larger, even when you are zoomed in all the way. Bone scale > 0 sets the zoom level at which the bones start to grow larger.

We also greatly improved the rendering of bones, especially when they are small. This was needed to make Spine usable when bone scale is 0. It was a lot of work, I hope you like it!

Also thanks for the project description. I still don't quite understand how the rigging works, why it requires 900+ constraints, nor how we might be able to simplify what you are doing. That many constraints is what is bogging Spine down. We'll see what we can do to improve performance.

I do like the improved rendering of bones - you guys did great work on 4.0.xx. I just wish the minimum size of the bones was smaller than currently, or that you had a few more bone icons that were at a smaller size (just a dot or a very tiny crosshair). That's really all it would take to help me out.

If I have some time in the coming months, I'll write up a full explanation of my skeleton and post it on the forums. AFAIK, the only ways that you could change Spine such that I could simplify my skeleton would be as follows:

  1. I have many bones that rely on their parent being scaled on one axis so that upon rotation, their rotation is distorted in an oval. It's very similar to the top face of the diamond in this tutorial, where the rotating bones' parents have a scale of <1 on the vertical axis: Blog: Rotating diamond tutorial
    In my case, I set all of the parent bones that have that <1 scale (let's call them "D2" bones for distortion) to constrain to a single bone (D1) that controls that distortion scale. But since they are at different places in the skeleton hierarchy, I have constrain them individually. Anyway, the child bones that rotate (let's call them "R2" bones for rotation) are also constrained to a single bone that controls rotation (R1). However, this could be greatly simplified for me if we could do away with the D2 bones, and if the R2 bone could pick up both rotation AND scale distortion from the R1. The problem is that all R2's must have an immediate parent with a scale <1 in order to create that distorted ovoid rotation.

I'm wondering if I can come up with some kind of hack using the new 4.0 feature that separates X and Y in constraints, but I haven't had a chance to work on it yet.

  1. Create an interface for mesh vertex sorting that does not rely on the order of bones to which they are bound.

And it would speed up my workflow if one could....

  1. Duplicate a constraint. After duplication, you could then reassign the two bones that are constrained to each other.

  2. When creating a constraint, include the name of the bone that's being constrained, rather than the bone it is constrained to. The reason is that I often set several bones to all be constrained to one parent, so they all need a unique name rather than the parent's name. I know I could just constrain them simultaneously, but the order of the constraints becomes important, and I often have to do them individually in a specific order (which is why it would also help to be able to duplicate constraints).

My constraint nomenclature is normally "200_bone_that_is_constrained <


100_bone_constrained_to". I number the bones in groups, with the parents having the lowest numbers (100 in this case), and sets of children having higher numbers (200). This way I can quickly look through the constraints and sort them by number, which means the order of constraints is (usually) correct so that they don't conflict or override each other.

ryancbaker escreveu

I just wish the minimum size of the bones was smaller than currently, or that you had a few more bone icons that were at a smaller size (just a dot or a very tiny crosshair). That's really all it would take to help me out.

Did you try zero bone scale in 4.0.51-beta? It looks like:

Image removed due to the lack of support for HTTPS. | Show Anyway

Zoomed out:

Image removed due to the lack of support for HTTPS. | Show Anyway

Thanks for the ideas, we'll give them some thought!


In 4.0.52-beta we've made some performance improvements for projects that have many constraints. With your project Spine now runs at > 60 FPS at all times for me, on a laptop. Note this still doesn't mean 3000 bones and 1000 constraints is terribly reasonable! 😉