/3/ - 3DCG

The source code is here, as usual:
https://sourceforge.net/projects/snes9l/files/blender-2.76b-sdf.diff/download
It's an aggregate of all the patches I've written in the past two months, but this one is independent of all the others and it's just a few lines of code under "meshlaplacian.c"
Interestingly enough it applies both to Blender 2.76 and Blender 3.5 the same way. It may even go back to 2.3

First of all I remove a line of code which I don't even want to know what's supposed to do, but somehow it ruins all the weights below 25% and the I apply an approximate correctiton.

The theory behind it is interesting. I've tried to explain a little here >>939151 but I'll try to be more specific if anybody's interested.

Keep in mind that this algorithm is way too simple to have any knowledge about anatomy. I may want to use it to bend sheet metal or a doll all the same but in a reliable and predictable way.

If you're thinking: "ok, I kinda like this but I don't want to re-compile Blender from source, I would rather have a Python add-on", then
consider that because of that single line of code I was mentioning earlier, your Python add-on is going to depend on some incorrect behavior to be baked into the C code.
I'm not going to do it for that reason, but you can do what you want.

A view of how this patch affects the weights. Left is default, right is patched.
Although it's in theory possible to do this by hand, in practice it's not. You would have to "snipe" a particular curve and there's also the notion that "pinching" the weights "un-pinches" the final shape, which is very counter-intuitive.

keep your retardation to one thread >>939151

oh, my bad, i missed the original >>937495

>>942142
I'm done with that thread. Can't I make another one? What difference does it make?
And thank you for the kind words.

So will somebody post this on https://blender.chat/channel/animation this time? Yes OP hates the Blender foundation so he is not doing it.

Didn't put much effort into this. There are no helper bones and no Preserve volume.
Maybe I'll post a comparison with the default mpfb2 rig later, which I think it's hand painted.

>>942152
so then why is he using their software, if I may ask?
Also good job OP

code the possibility to edit normals freely like you can in xsi and metasequoia and make blender 2.79 the best low poly modeling app

>>942127
Shoulder anon here, I'm intrigued. But whey does the default version appear more evenly blended than the patched version? Wouldn't that mean the patched version is innacurate?

Also, I've been thinking about weight ever since you posted in the shoulder thread. And I have an idea that might be a dumb idea, but I'm just going to say it and see what you think. If I get called dumb, so be it.

Weight layers. Why don't weights function like layers? Or in other words, "nested". Like, say you have three connected bones. Parented normally. Nothing weird. BoneA is parent to Bone B, and BoneB is parent to BoneC.

They all have their own weights, but their weights aren't "shared". Rather, each bone gets its own layer where its weight resides. So when you twist BoneC, the mesh moves as if BonesB and A have no effect.
However, When you twist BoneB, BoneC also twists, because BoneC's weight is nested in BoneB. But BoneA doesn't have any effect. It's as if BoneA's weight is zero.
Lastly, you twist BoneA, naturally, BoneB and C also twitch, because they're following the chain of parents, following the nesting order.

Am I crazy? Am I trying to reinvent the wheel? In my head, this sounds like the dopest idea every. But practically speaking, does it work?

>>942289
Because I'm DEVELOPER DEVELOPER DEVELOPER, I wanted to share some ideas and I'm using Blender as a vehicle.

>>942293
The underlying support has been there for a while. Maybe you've caught somebody ramble about Spit Normals. It needs to be hooked to the UI.

>>942294
Remember when I told you that loss of volume happens when a vertex is "equally contended" between bones? So I thought of:
https://en.wikipedia.org/wiki/Smoothstep
because I hoped it would pull the weights apart from the contended zone. So I tried it and it happened to match.

>Weight layers
Currently the weights are combined by addition. Addition in commutative, which means the order of the operands don't matter. Layering wouldn't matter.

If weights were combined via the MIN() and MAX() function instead, it would matter. That's how it's done in Signed Distance Fiends. It's not a crazy idea. It has all sorts of interesting properties.

>>942298
>I wanted to share some ideas and I'm using Blender as a vehicle.
your idea is to tweak the way bone weights are assigned, but your tweaks fail to address the problems you set out to solve because they are inherent to the technique.

Another demo just because I had it.

A little bit of shameless self promotion. I've uploaded two short screen casts of my SDF patch, so you can get an idea of how it works:
https://www.youtube.com/watch?v=L9nIFJ3R-AI
https://www.youtube.com/watch?v=BDUztqhwi1Q
Maybe in the future I'll show how to make a hand and how to rig and animate everything.
It is what it is, but it was fun coding it and it's a lot of fun to use.

>>942310
You seem to know what problem (if any) I was set out solve better than I do, so I don't know what to tell you.

>>942298
>Remember when I told you that loss of volume happens when a vertex is "equally contended" between bones?
Yes.

>So I thought of smoothstep, because I hoped it would pull the weights apart from the contended zone.
I see. I was thinking it was a clamp of some kind. I don't know if this really "fixes" the matter. The results are better than standard. But it seems just like smarter weight painting, without solving the fundamentals of weight painting.

>Signed Distance Fiends
Never heard of it. I just googled it, and through images, I'm seeing some depictions of bubble clusters. I think that's pretty close to what I was imagining in regards to bone placement. You remember how I wanted to put bones in the "center" of muscles? Well that's only the half of the idea. The other half, is a whole technical thing that I'm not skilled enough to create on my own. But basically, I envision something of a 3D weight map.

>>942394
I wrote the above yesterday, but I didn't submit it, because I was still thinking on the matter. Now today, I see these videos, and it appears very, very similar to what I had in mind. Pic related was the illustration I made that gave me pause. Because it feels incomplete. Pointless even. But seeing your SDF demonstration, I'm thinking perhaps it isn't so pointless after all.
Your SDF creation is interesting, however I can already see the limitations and complications in trying to create a complex figure using that method. It's probably simpler for more abstract organic forms. Clumps of flesh, slime, goop, and mud. But trying to create a human? I foresee a huge hassle. However, if you were to wrap a human mesh around that simplified ellipsoid geometry, then you can move the mesh in a more organic way that appears like actual mass underneath.

>>942410
>I don't know if this really "fixes" the matter.
It's a compromise. The armature system is older than most people posting on this board.
I was watching this from the MetaHuman project today:
https://www.youtube.com/watch?v=FYgxLuhVzhw
I think they'll propose a new standard armature system at some point but for now there's only so much we can do.

>a 3D weight map
SDFs and Metaballs are 4D height maps.

>I can already see the limitations
My implementation is limited in many ways but there are other people who are doing incredible things with Signed Distance Fields. Just google around a little bit and you'll see.

>more abstract organic forms
I'm not pursuing realism. There are several ways in which you can add fine details to the rough SDFs. You can convert to mesh and decimate, you can re-topologize, paint with textures, grease pencil...

>if you were to wrap a human mesh around
I think there's support for that in Houdini.

>>942410
I'm not completely sure but your diagram makes me think of:
https://en.wikipedia.org/wiki/Voronoi_diagram
It's an interesting idea but that's kinda what "Assign Automatic From Bones" already does.

Mayble look in Houdini or ask somebody with Houdini knowledge. I have a feeling that that's closer to what you're looking for than what I'm doing here.

>>942429
>I'm not completely sure but your diagram makes me think of:
That appears to be exactly what I was thinking. So that's what Voronoi is. I saw that in the nodes. Didn't really get it. But now I see. Scroll down to "Voronoi in 3D". That's a great visual representation. Except in my head, all the dots would be bones.

>It's an interesting idea but that's kinda what "Assign Automatic From Bones" already does.
Yeah. That's what I was thinking. I mean, I don't really know how auto weight paint works on a technical level. But the outcome is essentially the same. That's why I didn't post the idea yesterday, because I was trying to figure out why the "Voronoi" method makes sense. Perhaps knowing the center point of every bubble, you can calculate a kind of density. So weight would no longer be only surface level. Rather, vertices will abide by values of density.

Pic related is what it might look like. With the center points having max density, and the outer points having min density. You would of course be able to adjust the bone's density to increase/decrease pliability.

But the purpose of this density, is that when the bones transform, their vertices won't mindlessly bend inward and crease. Rather, the vertices will now calculate how far they're allowed to move, based on the density of the area they're attempting to occupy.

Like "this space has a density value of 20%, so rather than move the 100mm I want to move, I can only move 80mm". Something like that. It would probably be more complex, because you would have two density values affecting the vertices. But when calculated properly, it would effectively move the vertices in such a way that it appears they're sliding over mass, and then squishing the mass together, when the two masses come in close proximity.

I'm sorry for dumping my ideas on you. I doubt you're trying to make what I'm trying to make. But what you're making still looks cool.

>>942429
>Mayble look in Houdini or ask somebody with Houdini knowledge
I guess I'll look into it. But I don't have the money for it atm. Still, maybe I'll get the free version and see if it has what I'm looking for.

>>942435
>I don't have the money for it atm
I love to develop on Blender 2.76 because people gift to me computers that can run it but no later version. Pentium 4 and up, you can literally find them in the trash.
Even if I had the money I wouldn't be able to justify to myself why I spent thousands dollaroni on a water cooled video card instead of anything else like a trip to Amsterdam.
But you can still watch tutorials and keynotes around Unity, Unreal, MetaHuman, Maya, Houdini. I'm never going to touch any of that stuff directly in my life.

>>942439
You sound hopeless. Who knows, maybe you will have the money to go to Amsterdam and get a nice new PC both.

I'm still a Blender noob, so the idea of learning a new program is daunting. And I feel like my ideas are possible in Blender. Even 2.76. There's no reason why they shouldn't be. I just don't have the programming skill to pull it off. It would take god knows how long to learn how to program blender to make it do what I want.

I saw this video last year, and it's set an impossible standard in my mind: https://www.youtube.com/watch?v=BM2tWwBRnfs
Look at how fucking SMOOTH that is. I want to achieve that so bad.
Another video with more demonstrations: https://www.youtube.com/watch?v=GyOwwNvHA1w

This is more or less the idea that's starting to form in my head. Not exactly that. But something that makes it possible to create density underneath the mesh, using simple voronoi calculations to create cells, and then mapping the height of each cell... or something like that.

>>942446
>You sound hopeless
I just like to be melodramatic. I'm old, you know...

>Look at how fucking SMOOTH that is
With enough fiddling you can do something sort of similar in recent versions of Blender with the Cloth modifier.
The problem is that when put physics simulations into the picture, everything baloons in complexity by lot. It may also take a lot of computing power to resolve, it becomes difficult to go back in time, like when you're scrubbing the timeline in an animation and in some cases it may not resolve at all.
But definitely take a look here:
https://docs.blender.org/manual/en/latest/physics/cloth/index.html

>>942460
I don't want to fiddle with cloth physics in order to achieve that squish. I believe it can be done in real time. I get using cloth physics for actual cloth like it's intended. But using it for skinning just seems like a cop-out substitute. What I'm finding out about 3D, is that people make due with half-solutions. And those half-solutions persist as the common popular method of handling things. While actual solutions get developed by a third party as an add-on. I've been searching for better deformation methods, and it seems you either need 1000 shapekeys, simulation, a complex muscle system, or the magic technique remains unreleased in some company server somewhere. It's very frustrating.

As a matter of fact, look. You can use the Cloth sim to prevent the mesh from self-intersecting, but if it's not a very dense mesh, all sorts of artifacts will pop out.

>>942465
I'm aware. But I don't think simulation is necessary. It's costly and unwieldy. There's too much randomness. Setting up animation every time you want to test movement slows workflow down to a snail's pace.

Look at what I can do with three bones and automatic weight paint. Preserve volume turned off. A bendy bone is used at the joint to correct the deformation. I added a subdivide surface modifier to smooth it out, but if you were making this optimally, you would just add a couple loops near the middle of the joint and effective get the same result.

It's not a perfect squeeze. It's intersecting. But it's an acceptable intersection. It *could* be a perfect squeeze, if there was a better way to inform the vertices to move how we want them to move. No simulation required, just smarter math.

>>942516
That's cool. Between an extra bone and the Cloth sim I would choose the extra bone for sure.

>>942516
>It *could* be a perfect squeeze, if there was a better way to inform the vertices to move how we want them to move.
you could try animating each vertex individually.
you could also try, actually try, to understand the math of armature deformation, why it work the way it does, why it's an excellent choice from a practical point of view (it's super easy and efficient to calculate and gives great results), and why other tools have been developed to address deficiencies in the basic model (shape keys and drivers).

instead you choose to continue to use the basic model and attempt to tweak its inputs in a fruitless attempt at "fixing" inherent features of the model. Everything you've posted is worthless trash.

>>942535
If you would like to post some more of your hand drawn Shape Keys, feel free to do it but they have to be better than what you did last time >>940599

>>942535
>and gives great results
This is false. Post the best looking shoulders you can find. From any source. Using exclusively armature deformation.
Shape keys are a half-solution.
But if you would like to help me in my pursuit for the perfect squish, then I'll tell you I'm fiddling with raycasting at the moment. The geometry node. My thinking, is that if I can get an object to raycast on itself, then I can create self-collision. But of course it's not so easy. The rays seems to count their starting position as touching the geometry. Like, if you imagine the surface of the mesh as dirt, and rays like thin trees growing out of that dirt, well the trees are always rooted. And it's that root that keeps the tree in contact with the dirt. I don't want the rays to be rooted to the mesh. I need to figure out how to offset from the mesh ever so slightly. And then, it can raycast on itself properly... I think.

>>942102
I don't know what to tell you, OP. The pinch is working as intended. Like you were told in your other threads, you need to learn to rig, and the ways these tools behave will make sense.

>>942150
>I'm done with that thread.
Three threads on the exact topic? You're retarded.

>>942542
>The pinch is working as intended
According to whom? I don't like it. I prefer straight bends by default.

>Three threads on the exact topic?
I've started this thread and >>937495.
This thread is about Assign Automatic From Bones, the other was about Bone Envelopes.
Similar goals and results but different approaches.

>>942543
i remember a long time ago trying to explain the difference between analog and digital TV signals to someone, and why cheap HDMI cables work as well as monster HDMI cables as long as they don't fall apart.
i went to great lengths to point out that noise doesn't affect the fidelity of digital signals as long as the digital symbols can be recovered, unlike analog signals which are invariably corrupted every time they are transmitted and acted upon.
his brain simply could not process what i was telling him.
he then went off and bought his monster cables.

OP, you remind me of that time.

>>942546
I think you've built a religion around pinching in armatures, which is just a long standing bug in Blender and other 3D software.

>>942548
>long standing bug
if by bug you mean normal and expected behavior, then yes, it is a bug

>>942537
I wonder if it would be possible to re-write the whole Armature modifier in Geometry Nodes. It could be a first step and it would help people who don't have access to a C compiler do experiments. I've updated to Blender 3.6 now and I'll give it a try in the next few days.

>>942553
>I wonder if it would be possible to re-write the whole Armature modifier in Geometry Nodes
Likely yes. I think I heard of some add-ons that do that. But I haven't looked into it.
I don't know if that's necessary, but everything is becoming nodes now, so it couldn't hurt to try. With armatures working like nodes, you could probably simulate density.

I got self raycasting to work. Though, I'm not really happy with how I had to go about it. Check out the image. The object is casting rays outward. The normals of each face dictate which direction the rays are facing. Therefore, when I bend the object, the rays move along with the face and hit other faces of the same object.

For now, it's only deforming when the mesh intersects... or something like that. I'm not going to lie, I don't fully understand how this node works. But I'm pretty sure it's going to lead to something. Anyway... From here, I need to tell it to deform in such a way, that it doesn't get all stupidly jagged. I think my goal here, is to tell the vertices to seek the middle distance between the normal and the hit position. And that will cause the squeeze effect.

>>942585
And here are the nodes.

The goal here was to offset the rays from the base mesh very slightly. In order to do that, I extruded the base mesh. And deleted all the side faces, because I don't need them. Then I set the extrude to be a teeny tiny thing. A 0.001 offset. then plugged that into target geometry, so the rays emanate from the extruded face, not the base faces. The extruded mesh is invisible, because it's plugged directly into the target, and not into the group output. So they're only extruded faces in concept. But even conceptual faces are accepted by the raycast node.

>>942585
>>942586
No, these posts are wrong. I've made a dumb mistake.
The rays aren't being casted out. The rays are being cast from the base mesh to the extruded mesh. And then when the hit points intersect, they react.... I think. I'm so confused right now.

>>942586
Are you trying to dynamically delete the parts of the geometry that would self-intersect and then close the gap?

>>942592
Nope. If everything goes as plan, the geometry will simply deform in a way that resembles the cloth physics here. >>942465 Except much cleaner.

OP is a fucking idiot

>>942585
>>942586
>>942589
ok. With the help of blender stack exchange, I was given a real solution. I had already kind of found a solution on my own, but his is a lot more elegant. Now, everything I promised before is actually happening. The object is raycasting on itself properly. When I fold the object over, the rays hit the object. As illustrated by the deformation. It's only deforming where the object sees itself. Which currently is causing the mesh to bridge gaps. Now, truly, all I have to do, is figure out the math, that tells the mesh to avoid deforming, unless it's near the hit position. Once it's near the hit position, then both points should average out.
This is going to be hard, because I'm not that good at math.

>>942714
And the nodes. It's a lot of math, just to tell the rays to "scoot over a little".

>>942716
Maybe this is not what you're looking for but it's a possibility.

>>942750
I'm not sure what I'm seeing exactly. But it's looking promising. The way the edges light up in the middle is nice. There are a bunch of stray edges though, which makes me think it's intersecting with another mesh. That was something I attempted yesterday. Creating a dual mesh, and the making the dual mesh the target.

But more importantly: are you getting the squish in the middle? The lines are so clean, I can't tell if it's squishing or intersecting.

Pic related is what I'm messing with currently. I copied some nodes off of a video tutorial, that stops hits inside of the mesh. Now it only calculates his on the outside. Another step closer to making this work, I think.

>>942751
It remove the internal geometry. But you guessed it. Because it' Blender, it's kinda bugged. You have to give it a dummy object as the other operand or it won't work.

Also, I don't mean to discourage you but to my knowledge there is no known non-iterative solution to what you're trying to do. But I've read they added some iterative nodes in 3.6, so... maybe it's still possible.

Bruh wtf is this thread. Just use delta mush. Your CPU is spending 90% of it's cycles building an acceleration hierarchy for that raycast.

>>942753
To use Delta Mush or Corrective Smooth would be too simple and too effective. That's why we don't do it here.

>>942752
Ah. Boolean. Yeah, that's not what I'm going for. It's a neat idea though. I'm sure it has a lot of other uses.

>non-iterative solution
I don't know what you mean by iterative. Do you mean sequencing? Like looping logic kind of thing? I believe that's necessary. I can pull up videos that show how to create squish between objects without iteration. But as far as I've found, nobody has created a self-squishing object. It should be possible with just some clever math. I'm not trying to make a whole physics system. I just want points to avoid intersecting each other.

>>942753
I think OP is pretty experienced. And he's trying to code a new weight system or something like that. Then there's me, trying to attack the problem from another angle. I've only been using Blender off and on for about a year and a half, so my knowledge is sparse, and I'm learning as I go. It may just be beginner's arrogance speaking, but I don't like a lot of the "solutions" available. I figure I can cobble together a better one.

>>942755
>>942754
oh, also, I don't know what delta mush or corrective smooth do. Do you have any demonstrations?

>>942756

>>942757
Looks cool. https://www.youtube.com/watch?v=zgpvzWU15bo
That's essentially what I was attempting here: >>940698
See the red colored bendy bones? They're the deformers. They essentially act as delta mushers. I gave up on that idea, because when I tried adding more bendy bones for individual muscle groups, I encountered a problem where twisting the arm would create really ugly creases between the muscles. With all the bones turning on their Y axis at different variables, the creases were essentially unavoidable. At least, that's the conclusion I drew. I could be wrong. That's why I switched to floating bones for muscle groups. The Y twisting is much less of a problem.(but still a problem) I could resolve this Y twisting problem, if skin slid freely on top of the muscles. In which case, I would construct a full muscular anatomy using bendy bones, and have the mesh slide on top. But that's just insanity.

Instead, I figure I can get good enough results with the floating bones and squish. it won't exactly be realistic. But I'm not going for full realism. I just want good looking deformation. In any case, I'll have to keep delta mush in mind. And perhaps I'll look more into later. For now, I really want to get this squish node to work.

>>942762
In that SIGGRAPH video they do something somewhat similar to what I was doing before, except somewhat better? They do skin stretching which I don't do and there is a Laplacian Smooth modifier in Blender but it doesn't seem work for me.

But if you consider the complexity of:
Bone Envelopes + Corrective Smooth vs Assign Automatic + Remap, they both require an iterative step, except in the latter (which is the subject of this thread) the iterative step is pre-computed.

You know what? Whatever bad things I said about Eevee I take them back. Clearly it's great at rendering middle aged men wearing gold body paint.

Since the Dual Quaternion Method (Preserve volume) was mentioned I wanted to show this diagram.
There are several flavors of the Smoothstep function available, so just by mixing and matching SQM/DQM and your remapping function of choice you can have many different curve gradations.

with corrective smooth modifier is this patch really necessary

>>942796
The answer is maybe. This patch focuses on correcting the pinch on the inside of the bends. Corrective Smooth doesn't necessarily do that. It's better at fixing breaks on the exterior.

You also need to consider that if you're making models in Blender with the intent to export to some game engine, then this patch will work, Corrective Smooth and Preserve Volume probably won't. It depends.

>>942795
SQM patched looks really good.

I'm struggling to do my own thing, because I have a fundamental misunderstanding with how vectors move. Maybe it's just a node thing, or maybe it's universal. Idk. But basically, I want every normal, or every point for that matter, to move locally to the normal vector. But every time I try to do that, the results end up moving in relation to the origin of the object. It's so frustrating. I've tried 100 node combinations. Plug this into that, and that into this, and no matter what I try, all the points move back to the origin. I just don't understand how to get them to move locally from the normals.(Please help)

>>943000
Maybe you're doing it in the wrong order? To offset a vertex you need to multiply the normal (not the vertex) by the distance and then add to the vertex. It's vertex + normal * distance. It should work. Tifa unrelated.

>>943008
I kind of get it, but then again, I don't get it. It never works out how I expect it to.
This is frustrating. If I were as good at understanding vectors as everyone else, I would have this done in an afternoon. But instead, I'm just over here scratching my head, trying to understand why adding position to normal sometimes appears correct, but for other instances, appears to offset everything in an ugly way.

When you guys finally witness the what I'm attempting, it's going to blow your fucking mind. I just got to get over these technical hurdles.

>>943027
hmmm... With the mix node, I can find a middle ground between the Hit Position and the Position. Essentially, controlling how far the hit position is calculated. Maybe this is the starting point I need?

Another example with a Makehuman model and a very simple rig. It's not perfect but it's usable and it's all automatic.

With a little animation. I haven't manually touched any weight nor I have added any modifier other than Armature with default settings (i.e. no Preserve Volume).
This is where Assign Automatic with this patch leaves you no questions asked and for the simplicity I think it's very well worth it.

I don't like the Makehuman model. I don't like Eevee. I don't like how slow and annoying Blender 2.8+ is.

>>944055
I can't tell what makehuman does better than any other artist's base mesh and rigging. I guess it's a quick way to generate a base? But if you've already made your own, you can just copy and paste your own to make other characters.

>>944073
Nothing. The difference is the amount of effort you want (or are able) to put into making a little animation with a doll.
I've done >>944065 in a few hours from scratch. Real artists can do better... sure... given time, resources and talent I don't have, they can.

>>944077
And there's the problem that the default hand painted bone weights in Makehuman are really bad, which is why I've made these little test animations with my own bone weighting scheme.

>>944055
>>944056
>>944065
wtf is this real?

>>944083
No?

>>944083
I mean, it's a demo of my automatic bone weighting scheme I've presented at the beginning of the thread.

Same as >>944065 but I've let the Mixamo web service generate the skeleton and then I've replaced the bone weights.

I'm starting to doubt that I may have done something wrong in >>944338 but regardless as a reference, pic related is what you're supposed to get with this method and the Mixamo rig.

import bpy

# default mapping replica
def rws_make(i):

w = i / 255

if w < .025:
w = 0
elif w < .05:
w = (w - .025) / (.05 - .025) * .05

return w

# table to undo the default mapping
rws = tuple([rws_make(i) for i in range(256)])

def rws_search(w):

for i in range(256):
if rws[i] > w:
break

return i / 255

def smoothstep(edge0, edge1, x):
x = min(max((x - edge0) / (edge1 - edge0), 0), 1)
return x * x * (3 - 2 * x)

object = bpy.context.active_object
mesh = object.data

nverts = len(mesh.vertices)

# for every vertex group
for group in object.vertex_groups:

# for every vertex
for i in range(nverts):

try:

# retrieve weight
weight = group.weight(i)

# default mapping to linear
weight = rws_search(weight)

# linear to new mapping
weight = smoothstep(0, 1, weight)

# replace weight
group.add((i,), weight, 'REPLACE')

except RuntimeError as error:
# vertex not in group
pass

I'll just leave the above here for those who can understand it.

I wasn't sure if I was going to do this or not but:
https://sourceforge.net/projects/snes9l/files/AutomaticWeightRemap.py/download
So you can try this bone weighting scheme for yourself without patching the Blender executable.
It pains me that half of the script is dedicated reversing the effects of one single 20 years old erroneous line of C code but such is Blender.

great. please now let this thread die.

>>944972
I shouldn't have anything more to add after this. Sorry that it bothers you.

Kino

>>944969
what are py files, and how do I use them?

>>945004
.py files are Python source code. The script I've presented here >>944969 specifically, you're supposed to load it into Blender's text editor, follow the instructions at the top of the script and press the play icon.

However be aware that some Python script executed this way can be malicious. Mine specifically isn't malicious but at the same time if you have to ask how to use it, it's probably not for you.

I believe it's a nice thing but still experimental thing. It's not a finished product and it's more for people who have some technical knowledge at this stage.

Maybe wait until me or somebody else packages it as a proper Add-on, writes some documentation for it, puts it on Github, you know, the usual protocol.

I'm doing this purely as a hobby and I'm also facing quite a lot of hostility from certain people for whatever reason, so things will happen when they will happen.

Pic related is the Python script >>944969 in action instead of the C patch. Tested on Blender 3.6 alpha. I've used the default mpfb2 model, the mixamo rig and two static support bones for the hips, as shown.

>>942754
I wish the smooth corrective in Blender was as good as the delta mush in houdini. The delta mush node is magic but I don't know how it compares to the one in Maya.

>>942762
There is a blender add on called "X-Muscle System" that might be worth playing around with.

>>945102
You're right. Corrective Smooth is Blender is not nearly as good as good as delta mush but...
I've experimented with it in my previous thread about Bone Envelopes >>937495
The key to make it work it to generate breakages on purpose. If you try to use it with perfectly smooth weights, it'll find nothing to correct and it'll do nothing.
Unfortunately by default Blender's Bone Envelopes and also Assign Automatic creates weights that are way too smooth to be usable with Corrective Smooth.

>>945103
I'm not into muscles but I've done experiments with the Cloth sim >>944606 and it's amazing. I can grow asses everywhere.

And as you can see, if you raise the internal pressure in the Cloth sim, it's not exactly like muscles, but you can get something that resembles bulging... or a party balloon.

>>942751
>>942714
Minor update. But I watched this video yesterday https://www.youtube.com/watch?v=0dZUAh4fFfM
And it's kind of unlocked a part of my brain to the idea of vectors. I'm beginning to actually comprehend what Blender is doing. And so I'm amending the previous node set up. This is truly how you accurately offset the starting position of the rayscast rays. The previous node arrangement was off a little.

I also now understand why the dot product node works. The video has been enlightening. And I hope my brain continues to expand large enough to find the solution I'm looking for.

Another test.
The model is BuildABod from smutba.se
I've added two support bones for the hips and replaced the bone weights with >>944969
On the left is without Corrective Smooth, on the right with Corrective Smooth.
It's not perfect but for me, long as I can completely avoid manual weight painting, shape keys and drivers, I'm ok with some imperfections.

This is nothing in particular, but I've rendered it and so I'm posting it. If it pleases you.

And I just wanted to note that as was saying here >>945120 in order to use Corrective Smooth, you first have to create some sort of breakage or discontinuity.
The advantage of "breaking" the weights and repair them later with Corrective Smooth is that Corrective Smooth operates outside of the limitation of the Armature system, so it can potentially do things which you wouldn't be able to do if you tried to do them with the Armature system directly.

Just a quick preview of what I'm working on right now. If you've followed my threads about SDFs and this thread maybe you can guess what this is, otherwise I'll explain later.

This is very low effort but it shows what I wanted to achieve. When I was attempting to model faces with SDFs I had trouble modeling the mouth especially and I thought the only solution was to texture map it.
But then I realized that I can make use of the armature system as non-destructive modeling tool and since I'm going to want to animate the model anyway...

And for those who are into "the great puzzle of topology", here's my topology.

This is just to show that the whole process is non-destructive. I can go back and change the SDF structure even after I've already made an animation. I can add, remove and reposition bones, swap out meshes... It works in Blender 2.79 which is a huge plus for me and I've already written the majority of the code that I need.
I'll make a proper demo eventually.

And finally, this is how the modeler looks like. There is no option to manually edit vertices or polygons. You just place positive and negative ellipsoids for the most part.

>>945575
>And finally
yeah fucking right.