Physics - poor to finicky (if not simply too dysfunctional)

Archive
1

Maybe I will be shown the light but physics has always seemed a little off expectation to a fault.

I submit this simple example done with the latest Blender 2.82a (.7 still?)
http://pasteall.org/blend/index.php?id=53075

In it we see a cube with a torus as a dangling hook loop as an active dynamic shape.
Then we have a passive torus for hanging the active dangler.

It will break away after about a second say 24-30 frames?

Obviously you need Shape mesh and I lower the friction on both, it should fall to a center of balance that is not really the center of mass (which can be moved around without effect).
I have messed with every expected and then some parameter here is a short list as an example of what users go thorough trying to figure it out, so it’s a little excessive to what you might initially expect to need to do.

up res the models, instead of scaling up (tried that in different ways of applying from big to small or not etc. applying vs not applying procedural subdivisions etc.) I set the Sensitivity Margin to many values (I am assuming that’s why people say scale sims since they missed that point.), moving pivots, adjust friction, Scene’s Speed, Steps, Solver iterations, etc.

There are other confusing possibly related otherwise minor buggy UI issues like “Delete All Bakes” not making the yellow-gold color in the timeline clear. (Zero frame makes no difference and anything else you can think of).

In the end it is frankly a bizarre an futile experience trying to do even a simple test like this.

I guess my motivation in this case, not that it matters, is to find the center of balance for a hook on something you might 3D print. The enter of mass is clearly not such a thing in this regard.

One issue is when the form bends over it kind of knocks itself free by pressure against the passive hook, if that makes any sense.

I imagine maybe there should be a map generated that shows forces of pressure and that would be used to guide and limit the simulation.
Anyway as you can see it simple won’t respect the obvious collision or binding of the interconnected geometry.

If there is something I am missing I would be surprised but also it won’t mater because it is too finicky to get to work in a reasonable amount of time.

Practically every physics thing I have tried to do with all versions ever of Blender are disturbingly unusable like this simple example clearly shows.

How would I best move forward on asking for a feature request to rebuild it completely or is this a bug report?

Yours Truly (finally frustrated and resorting to trying to help by showing the community here there are really serious problems with a lot of Blender.)
Master James

2

I downloaded the file, gave it a shot, and can confirm that it’s an excellent example of Blender’s physics totally freaking out. I messed with every setting I could think of, but no luck.

3

It can be tricky but a file I created based off yours seems to work fine for me. Perhaps the geo on those toruses (tori?) are just too whack? Additionally, your sensitivity is set to 0.1mm, which will typically be way too precise in the general case; though raising that doesn’t help much in your file either.

Here’s my attempt. Open in 2.83 only.
Simple sub-d geo, 30 fps output, 120 fps physics (10steps), 0.1mm sensitivity for kicks: http://pasteall.org/blend/index.php?id=53076

[Edit] Eh, actually, I’m not thrilled with the behavior of mine either. When I actually apply the sub-d modifier, bad behavior results just like yours (basically more geometry even when properly subdividable yields pretty bad results). You can file a bug and feel free to use my file an example of low/high res differences in behavior if you want. I don’t have much hope that it would get looked at and fixed though unless it’s glaringly obvious what the issue might be.

4

I figured out that setting the torus to active and animated prevents the cube from falling through.

5

No shyt. I am impressed and thankful, and appreciating the community and all contributors time and efforts. It’s is dangling around for 2000 frames as I right this.

Now is this still a bug in a sense then? You can see how many people doing that which was expected and struggling with it simply did not work as expected, and for most never worked at all.

I can just link back to this thread in a bug report right? or is it better to repost files etc.?

P.S. I even took the friction off and cranked the margin smaller and still holding! … seems like 5 years at least I’ve tried, failed, and give up until the next version hoping someone would say something and get it fixed.

6

On some level you can even grab the loop and move it around in real time. Still it can break free then and that to me does point to the lack of using a reduced row echelon matrices transformation to detect the collision ray across the steps or jumps in time.

I suppose you could crank the steps up? maybe I run some animated tests and then you can still set the steps to handle the jump but as one intuitively expects it should never break free. Hence my comment in regards to the linear algebra way (yes it is kind of raytracing idea) for detecting that is not being done.

Anyway the point is from one step to another you would cast a ray and see a collision. [To be honest I have not thought about how to mathematically plot a dual body curved intersection over time fully.]

Yup I just confirmed that if you lower your steps and solver iterations with an increasing oscillatory animation on the hook the block dangles from, it will break free, but again with a much higher value it will hold.

I am convinced this does reveal a fundamental issue with the solver and suggests a better solver would not need steps and iterations if done in the way I suggest but would be more of a raytraced solution which would be slow but with a GPU might be super fast and much better.