Thank you for your reply.
Harald schrieb
float ratio = vertexDistanceToBonePos / boneLength;
ratio = clamp01(ratio);
float z = lerp(currentLayerZ, nextLayerZ, ratio);
Yea this seems far more approachable than modifying bone rotation, thank you for the idea.
I'm currently in the middle of that implementation, the idea I currently have involves bone names. And would like to hear some feedback (and am also writing this down, to give anyone that potentially stumbles with this thread some ideas in the scenario they also want to do something equally overkill).
Basically, to do what I described before, I might need to semi discard the default draw order.
Let's say you have a simple character, a torso, four limbs, and the head. And for the specific look of this character, I want the torso to be the bottom element, where the rest would sit on top of it. Draw order presents an issue for the vertex offset idea, because while as it stands, while I really don't care for the draw order of the non-torso elements (if left arm is above head, etc), if I was to respect the original implementation, z position would be calculated by [drawOrder * zSpacing], so only one of the pieces would be "connected" to the torso, where the rest would be on top of it, but "floating", there will be a gap to the torso determined by [(drawOrder-1) * zSpacing].
If zSpacing is small, it really won't matter, as it would be fairly difficult to view anyway. But if I was to separate the parts, then that gap will start to pile up the more items to draw there are (meaning the "max" draw order position gets larger).
So my idea was to label bones/slots based on the height I would like them to be rendered at. For the previous example, it would mean labeling the bones something like "0-torso" , "1-left-arm", "1-right-arm", "1-left-leg", "1-right-leg", "1-head". That way, on the mesh generator, I can get the bone name of an attachment and determine if I should render it "traditionally" (the default spine way) if there is NOT a number, or do it via a custom way where I can clamp positions based on that number.
The two challenges I can think of will include:
z fighting, for which I might need to add a secondary zSpacing with a smaller magnitude that actually does make use of draw order.
And changing draw order mid animation (I don't use this option that much, but it might be troublesome when I do need it), let's say I want an arm to go behind the head and torso, a "-1" bone number, I might need to listen to some custom events to change a bone's name during runtime or an equivalent.
There's also the handling of bones that are just points (start = end), I might need to do some special bone names to determine how to draw these (could be something as simple as distance from bone, etc., might need a couple types).
Tweaking all this might gonna need a bit of work, but I think the end look will be worth it.
EDIT: I realized this could all be solved if I could bundle the draw order items into folders, and had a toggle to mark the items within the folder as the "same level". I'm not going to do something as selfish as request this to be a feature, I just thought another solution could be for me to edit the exported jsons to do something to this effect.
EDIT 2: After playing around with the unity mesh generator and seeing how the draw layers are exported to JSON, I noticed all draw layers are p much done sequentially based on priority already, so I might be able to get away with something really simple: draw order "markers". If I add items in the draw order hierarchy (tied to small, 1x1 transparent elements or something), I could start labelling these with "
GROUP_START" and "
GROUP_END" or tags to this extent, and read that on the mesh generator to set flags to increase or keep the current z "height". This should also take care of the runtime order change issue I mentioned before automatically, all depending if an element is before or after these tags.
