Blender Bone Envelopes

[Anonymous No.937495]

On the right is what you get by default in Blender 3.6 It's unuseable because of the pinching on the interior side.
On the left is what I've got after a day of hacking at the code. If anybody's interested, I've got more examples and code to share.

[Anonymous No.937503]

Same as before but with a 90 degrees bend. Top left is Blender 3.6, bottom right is my patch.
If you're wondering why bone envelopes instead of vertex groups, weights, hooks, drivers, whatever voodoo the latest tutorial guy suggests, it 's because they're easy to use.

[Anonymous No.937504]

I wonder if Hashem looks down at blendlets with as much pity as I do.

[Anonymous No.937526]

Hi

[Anonymous No.937531]

>>937526
Hi to you too. Yes. I've seen that gif before. You could do that but it's a lot of work. You can spend your time doing that.
The examples I've posted here are just bone envelopes with no special weight painting or topology.

[Anonymous No.937533]

The problem is that in Blender bone envelopes don't work right by default because the formulas haven't been reviewed in ages.

[Anonymous No.937535]

But I guess you can't get a PhD by fixing 20+ years old bugs. You have to invent something old-new, convoluted and questionable every time.

[Anonymous No.937541]

>>937495
>If anybody's interested, I've got more examples and code to share.
I know some developers lurk here but you should post it here
https://projects.blender.org/blender/blender/wiki/Module:%20Animation%20&%20Rigging
Or
https://devtalk.blender.org/

[Anonymous No.937543]

>>937541
No. I won't. Because whatever I do, I do it for myself. I have no interest in being part of the Blender people. In fact, in my opinion, people shouldn't be using Blender at all.

[Anonymous No.937545]

>>937543
>casually drops by and fixes your shit software
>"COMMIT NAO!!"
>no.jpg
>doesn't elaborate
>leaves
Based king, fosscucks btfo.

[Anonymous No.937546]

>>937543

...git link to source?

[Anonymous No.937551]

>>937546
GIT? I don't use Microsoft products such as GIT. I'll make a patch for the solution I've found and I'll post a link to it later.

In the meantime if you want to give it a shot yourself, open "armature.c" and locate the function "distfactor_to_bone" in it.

The bad pinching is caused by the fact that the caps of the envelope have the same influence as the cylindrical part, so when the caps and the cylindrical parts overlap, the caps distort some areas that are supposed to remain straight.

[Anonymous No.937555]

I just wanted to show that you can get even better results by giving the bones a little bit of "pre-bend". No vertex weights to adjust. And a wireframe view to show what happens inside.

[Anonymous No.937559]

>>937543
ok, this is based

[Anonymous No.937560]

>>937543
If that's the case, why'd you bother making the thread?

curious...

[Anonymous No.937563]

>>937560
To share the idea. To tell people that the youtube tutorial guy who tells you to use drivers with python code, auxiliary bones, hand painted weights and custom topologies is insane.
That all of the above are just baroque workarounds for crusty old, bad code which is in the C codebase and it's burden-shifting from sloppy programming directly to a huge waste of time for the users.

[Anonymous No.937564]

If you got bone envelopes to work properly that's fine, post the code.
But basically no one is using them everybody is using vertex group weights.
Now it would be awesome if there was a working, less labor intensive alternative and I suspect you need to add even more patches to bone envelopes to make that happen.

[Anonymous No.937566]

I'm curious, what's other software like? You just auto-rig a model and it gives you perfect elbow deformation out of the box? No need to touch up the weights or make corrective shape keys?

Somehow I doubt that.

[Anonymous No.937567]

>>937564
To my knowledge the function "distfactor_to_bone" has never ever been touched since Blender was released as GPL.
Maybe people tried it over time, correctly decided that it didn't work and moved to vertex weights even in situations where bone envelopes would have sufficed.

[Anonymous No.937569]

>>937567
go on...

[Anonymous No.937570]

>>937566
Since you've mentioned an elbow, I've made an abstract one real quick and bent it with just bone envelopes. It's not perfect but it requires practically no work at all.
>>937569
I'll post it soon but it's essentially one line. As I've explained above it just sets the cylindrical part of the bone envelope to take precedence over the caps. I'm sure there are way better solutions people smarter than me can come up with.

[Anonymous No.937572]

>>937569
This patch for bone envelopes is already part of SDF patch (because I'm the same guy), which is here:
https://sourceforge.net/projects/snes9l/files/blender-2.76b-sdf.diff/download
Most of it is about a replacement for the metaballs system but if you search for "armature.c" inside that file, you'll see it.

[Anonymous No.937596]

>>937572
So this is part of the development hell series from the Blender fundation, do you know that they hired that guy from Maya >Jason Schleifer? idk if they are touching this, they have been promising a rework of the animation and rigging system from 2017 or so, next goal 2025

[Anonymous No.938262]

>>937495
>It's unuseable because of the pinching on the interior side.
uh, what are shape keys?
skeleton subspace deformation is very efficient to compute, but suffers from pinching and collapse at extreme angles. this is a very well known issue that shape keys completely solve.
you can play around with bone weights all day and never eliminate this problem because it is inherent to the math.

[Anonymous No.938266]

>>938262
>shape keys
require a lot of manual work
>is inherent to the math
I've just shown you it's not

[Anonymous No.938277]

prove it with code or shut the fuck up, OP

[Anonymous No.938279]

>>938266
learn your tools or be doomed to be a retard.

>I've just shown you it's not
you've shown nothing of the sort. it absolutely is. i know exactly what blender is doing under the hood because i exported blender models for use in research simulations, and i had to reproduce all the math that blender runs to make models work outside of blender.

[Anonymous No.938280]

>>938262
Let me give you some more details.
As it is, Blender assigns vertex weights from envelopes via a somewhat incorrect capsule distance field. The capsule field is continuous.
A continuous surface warped by a continuous field gives a continuous result. That's somewhat correct for the outside of the bend but it's not for the inside.
What you want instead is a field that is continuous when there is no bend, remains continuous on the outside of the bend but becomes discontinuous on the inside.
Any field that satisfies these constraints will work better than the linear field that's currently implemented.
I've chosen the possibly simplest solution for this demonstration, but if you understand math, you can go at it and find better solutions.
Just don't propagate myths that a particular problem is unsolvable just because Blender mathematicians say it isn't.

[Anonymous No.938281]

>>938277
I've posted the code earlier. It's here:
https://sourceforge.net/projects/snes9l/files/blender-2.76b-sdf.diff/download
It's a text file. Open it in your notepad and search for "armature.c". It's there.

[Anonymous No.938282]

>>938281
you are an "amateur.c"

[Anonymous No.938283]

>>938280
you are missing the point. it doesn't matter how you assign weights, if you have two subspaces controlling the same points with weighted averages, then you can always cause pinching and collapse by choosing the right (wrong) transformations for the subspaces.
you can come up with the most clever way to assign weights, and you still have this problem.

the whole point of shape keys is to address this very problem.
when your geometry looks bad after posing, you just fix the geometry and save the new shape key. it's the easiest, best way to deal with the issue.

[Anonymous No.938285]

>>938279
>I had to reproduce all the math that blender runs
My whole point is that the math that's in Blender is questionable. Good to know that you understand how the questionable math that's in Blender works but what's the point of your comment?

[Anonymous No.938286]

>>938283
>the whole point of shape keys is to address this very problem
Address it manually. With a lot of manual work.

[Anonymous No.938287]

>>938282
And you're "nothing.c"
>>938283
You didn't read

[Anonymous No.938288]

>>938285
>My whole point is that the math that's in Blender is questionable.
it's not. it's what everyone uses. once vertex data is generated, deformation and animation is literally weighted average upon weighted average. it's the only way to do it efficiently.

upload your brilliant solution. i'll pose it and break it in 2 seconds.

>>938286
you might as well say you can control your car well enough with the accelerator, brakes are "too much manual work".

[Anonymous No.938289]

And besides, if you're happy with how Blender works currently and you're convinced that manual shape keys and vertex painting are the only solution, then kindly get the fuck out of this thread.

[Anonymous No.938290]

>>938288
>upload your brilliant solution
You need to read before you post. I've posted a link to my code not 5 minutes ago.

[Anonymous No.938291]

>>938290
i'm not running your code on my computer. i'll open a blend file that your code has prepared.
one 180' twist along the axis of your model will break it. i'll show you.

[Anonymous No.938292]

you're ignoring half the functionality of blender and then complaining when the results suck.

[Anonymous No.938295]

>>938291
I'm not sure what you're trying to tell me but
>one 180' twist along the axis of your model will break it
Yes. It should break in that situation.

[Anonymous No.938296]

>>938292
Go back to your manual vertex painting and shape keys then. I'm not stopping you.

[Anonymous No.938297]

>>938295
>Yes. It should break in that situation.
and shape keys could make it work.
for example, you forearm can rotate 180' without collapsing to a point. if you want to properly model a forearm, then you need both skeletal subspace deformation and shape key deformation.

[Anonymous No.938299]

>>938297
Ok, so go ahead and use whatever works for you.

[Anonymous No.938300]

>>938299
that's right, i will keep on using what works for everyone.
and you are free to keep using what works for nobody.

[Anonymous No.938311]

The topology of the mesh is unoptimized. It's just whatever comes out of the metaball/SDF marching cubes process.
Not vertex weight/painting. No Shape keys. No Drivers. Just bone envelopes.
Because it doesn't rely on hand painted vertex weights, the mesh can even be replaced entirely after posing. Bones can be re-positioned and parameters changed on the fly with no extra work required.
Again, it's not perfect but it's a lot better than whatever comes with Blender by default.
And despite some Blender geniuses claims that this is mathematically impossible, I know that it could be made even better.
If you want to see some specific scenario, ask nicely and I may make it happen.
The link to the code I've already posted 3 times. Just scroll up a little bit.

[Anonymous No.938312]

One idea I'm considering is to use negative vertex weights.
The way I've set it up right now, the interior of the bends are as sharp as they can be but maybe sometimes it would be nice if they would bulge out slightly.
In some complex rigs (such as the one in pic related) you can see a bone going backwards after the elbow joint. I suspect the role of that auxiliary bone is to emulate a negative vertex weight somewhere.
I don't if and ever I'm going to work on this idea, but if you're able to code, you're welcome to try it out before I do.

[Anonymous No.938313]

>>938312
>it would be nice if they would bulge out slightly.
shape keys also solve this

>>938311
https://docs.blender.org/manual/en/latest/animation/armatures/bones/properties/deform.html
the whole point of bone envelopes is to produce vertex weights automatically.
instead it seems you are using metaballs to compute the vertex weights. is this correct?

[Anonymous No.938314]

>>938313
No. I can use any mesh. I've used metaballs (SDFs actually) just to draft the example meshes that I've posted. I'll post an example of bending a subdivision mesh eventually, but it makes no difference.
I'm also working on something else entirely different where I do generate automatic vertex weights from SDF information, but that's another project.

[Anonymous No.938315]

>>938313
However, the way bone envelopes work in Blender by default is by computing a distance field from the bone.
I'm using the same method but with a slightly different formula.

[Anonymous No.938316]

As I've already said at the beginning of the thread, Blender uses the function "distfactor_to_bone", which is a sense is an SDF, except it's reversed and clamped.
I've modified that function. I've also removed the code related to the bone head/tail size because for reasons long to explain, it's broken, confusing and does nothing anyway.

[Anonymous No.938317]

For more details you're going to have to look at the code because I can't explain it any better than I've already have in words.
I'm also not trying to convince anybody and sure, shape keys solve everything... at a big price.
I also think that comparing bone envelopes with a manual technique such as shape keys is a little bit dishonest on your part.

[Anonymous No.938318]

>>938317
so you are computing vertex weights and using the standard SSD+SKD to compute mesh deformation.
claiming that your method solves the collapse/pinching issue of SSD without SKD is the dishonest part, because it can't.

[Anonymous No.938319]

the twisting between adjacent bones will _always_ cause collapse

[Anonymous No.938320]

>>938319
I've shown to you right here >>937555

[Anonymous No.938321]

>>938320
straighten and then twist your bones without modifying anything else and it will collapse just like your claims

[Anonymous No.938322]

>>937555
why would i want the mesh to collapse in on itself like you've shown here?

[Anonymous No.938323]

to go further, your just sweeping an inherent issue a little farther under the rug in one specific case. it doesn't solve the issue in general. you need to introduce something else to the model to address this issue (hint hint: shape keys)

[Anonymous No.938324]

what the hell does any of this matter if it only works when rendered in blender

[Anonymous No.938325]

I'm out of time. Chores to do. Sorry. I'll get back to this thread in a while.

[Anonymous No.938326]

>>938324
anon isn't actually changing anything about blender. he's just computing vertex weights in a different way. the same data could be ported to maya or any other animation software since they all use the same model

[Anonymous No.938328]

>>938326
Yes. Exactly. In fact the bake bone envelopes to vertex weights option still works in my patched version of Blender. Multiplying with hand painted vertex weights also still works. It just make it optional. And in fact I have some vague memory of some (obscure, almost certainly closed source) 3D modeling thing that did something similar to "my technique".
I say that in quotes because at its core it's so simple I'm almost certain I've actually "independently re-discovered" it.

[Anonymous No.938330]

>>938328
thanks for confirming that you didn't actually solve the problem you set out to solve

[Anonymous No.938331]

>>938330
Why don't you replicate just one of the examples I've posted with your beloved shape keys and let's compare the results.

[Anonymous No.938373]

Since somebody mentioned it, I've just tried to bend a generic mesh.

[Anonymous No.938374]

You may notice that I've removed the head/tail ball size parameters, so now the visualization is a combination of stick mode and envelope mode.
Because of the way vertex weights work (which I haven't changed) the head/tail ball size do essentially nothing because the code is somewhat bugged and they just shift the linear field outwards, but since the contributions are normalized at the end end of the process, then... And it's two less parameters per bone to worry about.

[Anonymous No.938379]

incredible how defensive blendlets get over the smallest things

[Anonymous No.938382]

>>938379
I'm a retired programmer. I do still have passion for computers and whatever I do these days is for my own enjoyment.
I really don't need the aggravation of having to deal with short-tempered almost-certainly-not-heterosexual Blender cultists.
But nevermind that. I've asked the accomplished researcher/Blender mathematician who totally debunked my code >>938330 to post a counter-example using his Blender Guru's approved Shape Keys and I don't think he's ever going to post anything.

[Anonymous No.938412]

More posing just because I've made it for... reasons... It's again just bone envelopes.

[Anonymous No.938425]

And this is the rig. Unfortunately I've chosen a model with a skirt and since I've imported it as a single piece .obj and I didn't bother to separate the skirt, there are some defects. I didn't expect the skirt to bend even remotely correctly, so... But the defects are fixable.

[Anonymous No.938433]

>>938425
>But the defects are fixable
with manual labor

[Anonymous No.938439]

>>938433
You keep commenting with the assumption that I'm trying to sell you something. I am not.

[Anonymous No.938444]

>>938412
looks like shit desu
Arms are sausages.

[Anonymous No.938445]

>>938444
I think that's supposed to be an armor of dress some sort, so it's supposed to look like that but I'll be sure to forward your complaint to the author of that mesh which I have no idea who he is. Is there anything else I can do for you? Will you ever be pleased?

[Anonymous No.938551]

Another model. Again just modified Bone Envelopes. Corrective Smooth is not necessary but it works well.

[Anonymous No.938595]

Without Corrective Smooth on the left. With Corrective Smooth with default settings on the right.

[Anonymous No.938617]

>>938595
wow, those elbows look great

[Anonymous No.938631]

>>938617
The model is dressed. The forearm is dressed. That's the end of the dress. I thought it was obvious.

[Anonymous No.938634]

Is this better? This has no Corrective Smooth. I knew I had an issue with bone roll on the wrist. But there aren't many polygons to work with in this model and I'm not exactly an animator. I was even unsure where exactly to place the elbow joint.
The thing I like the most is that I can easily shift the bones positions without have to re-calculate anything. It's actually fun to use and that's the thing I care about above anything else.
And thank you: >>938433 >>938444 >>938617 for continuing to bump my thread.

[Anonymous No.938642]

>>938634
still looks like shit.
it will look even worse in more extreme (but completely normal) poses, like if she were touching her left shoulder with her left hand. the elbow will either collapse or self intersect or both, all of which looks bad.

[Anonymous No.938652]

This one, master?

[Anonymous No.938654]

>>938642
Forgive me for asking you again, but it would be of great help to me if you could provide at least one example of how you properly do it.

[Anonymous No.938664]

>>938634
Okay you are wondering why this isn't received better right?
You are engaging in the same behavior as you rightly accuse the blender devs of: Opinionated development of features.
Nobody wants to run your fork of an old blender version because you've added feature.
Want people to appreciate it then implement it on a recent version with python scripting or geometry nodes as a plugin.
>>938595
The thigh/hip bend looks decent but the elbows ... oh well already mentioned.

>But I don't want to do that, blender "community" this and that.
Everybody knows, it's a general problem in FOSS you have to deal with it or stay in obscurity.

[Anonymous No.938665]

>>938652
thanks.

>>938654
the simplest way (and you won't like this) is to
1) put it into the pose you want (like the hand touching the shoulder, which you've done)
2) manually tweak the mesh to look good in this pose (fix self intersections, make muscles bulge, etc)
3) create a new shape key
4) add a driver based on the transformation parameters of the bones (i.e. the angle between the upper and lower arm bones) that controls the interpolation between the two shape keys

for something as complex as a human, you may need to break the body up into a bunch of different meshes (arms, torso, legs, etc) to make this a robust solution, since a shape key is for the entire mesh, not just a subset of vertices (unless that's been recently changed).

all of this is necessary because SSD+SKD isn't a physical model, but it is extremely easy to compute. of course, you could use a more complicated physical model to compute the interaction of geometry, but this is computationally expensive and takes away your ability to tweak things since now everything is contingent on a physics equation and not artistic license.

[Anonymous No.938669]

>>938664
>>938665
Thanks to you.

[Anonymous No.938672]

>you are wondering why this isn't received better right?
I don't care.
>implement it on a recent version with python scripting or geometry nodes as a plugin
You're so dense and unaware. I know that it pisses you off when people post stuff from the 2.7 series because, as many pointed out, 2.8+ was a mistake.
>accuse the blender devs of: Opinionated development
I've never done such I thing. I said that you Blender people are brainwashed possibly homosexual cultists and I stand by it.
>the simplest way (and you won't like this) is to
And in the end you're trying to indoctrinate me.

[Anonymous No.938847]

I've re-positioned the elbow joint, fixed some bone roll issues and added some color to help show what's going on with the mesh.
No Corrective Smooth, no other filters, no manual tweaking of vertices. Just bone envelopes. For what it is I'm very happy with it.

[Anonymous No.938850]

Also, in response to >>938322 I was trying to remember where I saw the idea of inverting a segment and pushing it past the z-buffer to make a sharp bend before. It's actually right here: >>937526 and it's suggested as the right way to do it.

[Anonymous No.938856]

>>938672
>I know that it pisses you off when people post stuff from the 2.7 series because, as many pointed out, 2.8+ was a mistake.
Nope personally I even agree with you, huge performance regression and unnecessary ui changes.
Other than that: cope

[Anonymous No.938867]

Regardless if you're you're using my patch or not, you can still do all your artistic things on top of bone envelopes if you want. You got upset because you didn't read: >>938328

[Anonymous No.938952]

>>937543
this is the post that made me reply after lurking for 2y. holy based.

[Anonymous No.938960]

>>938952
this is the post that made me roll my eyes so hard they got stuck in my brain, holy fuck.

[Anonymous No.938971]

This is something I wanted to try out of curiosity. Somebody in another thread asked how to bend things made of multiple objects simply joined together. They're default cubes.

[Anonymous No.939564]

This sums up my modified bone envelopes. Corrective smooth is optional. Baking to vertex weights is useful for exporting.

[Anonymous No.939852]

In response to >>938319

[Anonymous No.939853]

And here's a wireframe view of the same thing.
You do need a patched version of Blender (as I've tried to explain ITT) or some other software that actually works or some very carefully hand painted vertex weights to do this, but it's possible.

[Anonymous No.939858]

And just for fun, with bendy bones.
This uses a little new patch I've made yesterday that generates a Split Normal data block for Metaballs/SDF, so they retain high quality normals even after they're converted to mesh.

[Anonymous No.942228]

>>938320
now bend it the other way around
whoops, where's the smooth surface?

[Anonymous No.942245]

>>942228
The other patch I'm presenting here >>942102 has no need for pre-bending, if that worries you.

[Anonymous No.942292]

>>942245
that image shows clearly where the method fails, do you see that large flat spot on the extending side? That's a single edge/face which will produce some awful texture stretching. You can migitate this with subdivisions, but for realtime cases this is not an option.

[Anonymous No.942300]

>>942292
You have to consider that I'm working within the limitations of the existing armature system. You're welcome to do better or ignore all of this if you don't like it.

[Anonymous No.942303]

>>938322
not that guy but for low poly models you'd want to preserve the volume as much as possible.

[Anonymous No.942304]

how do you install this .diff patch?

[Anonymous No.942306]

>>942303
Part of the reason I'm doing this is because I've always liked the look of those old PSX models that were made of discrete pieces. They had visible breaks at the joints but not volume loss or pinching issues.

>>942304
You have to get the Blender 2.76 source, re-build it, apply the patch and then re-build again.
It's hard to do in general and on Windows I've been told it's hell on earth.

Unfortunately if you have to ask, it means you'll have to wait until somebody to publishes a patched binary.

The Blender people are unlikely to ever incorporate any of this because it doesn't affect their proven "import from Maya and claim it was made in Blender" pipeline, so...

[Anonymous No.942314]

>>942306
that's fine. i can still view the code in vscode and get a sense of the underlying logic, so there's merit behind having it. it's a pretty cool implementation all in all, and depending on how efficient it is compared to using weight painting and topology techniques, i could see myself wanting to repurpose it in a game engine.

[Anonymous No.942315]

>>942314
That's the best you can do in my opinion. Try to understand the general idea and then do your own implementation, which is very simple anyway. Also consider >>942102 because I managed to get the same results as in here but using standard weight groups.

[Anonymous No.942544]

>>937563
>>938266
This is just how weight paints work. The bone influence is dependent on the weights.
>is insane
>a lot of manual work
because you won't learn to do it properly. You think you're going to automate their methods without understanding them.

>>937531
>You could do that but it's a lot of work.
lmao why

why is the quick and easy way the hard way, while mangling the blender source code to get it to do it a really specific and limited way the easy way, in your opinion?

[Anonymous No.942765]

>>942544
Migrate to >>942102 because in between starting this thread and now I believe I've found a batter way to do the same thing, which is explained there. That's still my thread, I just don't want some rogue janny to ban me again for having two similar threads.

A short answer to your question is that if you like do hand paint your rigs, then none of the changes I'm presenting here or on the other thread affect you in any way.