1.9.7 hinges and forces

[Kilinich]

I've try to make it simple...
Then hinges is under high force, object starts behave very unrealistic without any visual reason... and it's quite confusing.

[scene]55931[/scene]

[emilk]

You are giving Algodoo a unsolvable problem. Algodoo can't keep allow the circles to overlap, but neither can it allow them to stretch. There is no good solution - just varying degrees of bad.

I do agree that it can be confusing though, and I am open for suggestions here. Perhaps one should warn against these situations, perhaps a showing up where large overlaps persists - but this is likely to show up more often than you'd like, and become quite annoying quickly.

[TC42]

Why not just allow algodoo to do one of two things: revert to the iterative solver--I'm guessing the scene uses a direct solver-- or simply allow the circles to overlap? Just as long as there is a console accessible variable that controls it, like unsolvableOverride = 1, or maxAllowableOverlap = 5.35 or something.

I think warning would not be good unless you can somehow disable them--if someone had a collision engine with high overlap... it would not be pretty.

[Kilinich]

Well, you make everything fine in visualizing - physics need to be adjusted a little.
You've perfectly kill that old "raunits" and here it is again.

We have 2 situations:

1) If two or more hinges bind on conflicting positions - hinges stretched and object unable to rotate. Fine. But it must be unable to rotate related to connected body, not the world...

2) If two or more geoms overlapped because of hinges positions. Deep penetration without shakes. Fine. But why it jumps on "normal" contact with another geom? Let it be like solid block.

[emilk]

1) You're right - the "won't rotate" thing is a bug - and I've fixed it for the next version.
2) Hard to fix. The contacts are still solved iteratively which means there will be no convergence to a solved state. To fix this would require some sort of ad-hoc "large overlap and streched hinge, treat as if fixated" hack, which would be ugly and error prone, or a direct solver for contacts. In fact, you can get that via the following:

Sim.directContactSolveAll = true;
Sim.direct_friction=true;

However, it is quite slow for large scenes.

At any rate, the above scene works no worse than in 1.8.5.

[Kilinich]

At any rate, the above scene works no worse than in 1.8.5.

True,
but in 1.8.5 I've "see" the source of problem (circles shakes) and can fix my scene. Now it's much harder, player can draw box and two overlapped circles thinking it's just a car but it starts jumping...

IMHO, interesting solution is to convert deep penetrated geoms into polygon of similar to original form but with half- cutted penetration zone. Like in reality - object deformation. It can even depend on density and save total mass...

The other way is show somehow to user what is a problem - for example blur the hinge icon to direction of force...

[emilk]

The other way is show somehow to user what is a problem - for example blur the hinge icon to direction of force...

I like that idea - maybe you'll see it in the next beta!

[Someone Else]

Actually, I would suggest leaving the "won't rotate" thing as it is. This is what is largely known as a Lucid device, and is used as a stabilizer in lots of scenes. It actually works better with the new hinges.

However, I can see no practical use for the bouncy thing, so I have no problem with fixing it.

[Kilinich]

Actually, I would suggest leaving the "won't rotate" thing as it is. This is what is largely known as a Lucid device, and is used as a stabilizer in lots of scenes. It actually works better with the new hinges.

inertiaMultiplier = +inf replace all that devices.

[Someone Else]

inertiaMultiplier doesn't work in Phun.

I've just gotten so used to making my scenes Phun-safe that I forgot about it entirely.

And what about forwards compatibility? Old scenes that use it will simply no longer work anymore.