Joints stiffness

[Julio Jerez]

Ah - it is in iterative solver - i thought it's exact only forn now.
Running now & testing...

that solve is both, the problem is stat I will have to execute a number of iterations equal to the number of rows in the system. I limited to 32, so it is actin as iterative. But lie I said it is place holder until I implement the one to do only one pass.
I have there but it is all commted out because if had a hard time debugging it, but that will be easier.

[JoeJ]

Wow, this is stiff!

Balancing does not work anymore but the powered T-pose is stiff closely like it would be a single body.
Awesome!

There is a lot of jitter, but as you explained above, this should be expected.
All is so stiff that the ragdoll feet can't get grip at the ground, even while the controller tries to move them just slowly, the collision forces lift the whole ragdoll an inch upwards to the air so it can't settle. It makes a few steps and finally falls down. (right now it always needs at least one foot in resting contact to do something meaningful).

I'm very excited - seems you're on your way to solve the impossible...

[Julio Jerez]

:shock: Wow, this is stiff!

Balancing does not work anymore but the powered T-pose is stiff closely like it would be a single body.
Awesome!

There is a lot of jitter, but as you explained above, this should be expected. It is like concreted.

All is so stiff that the ragdoll feet can't get grip at the ground, even while the controller tries to move them just slowly, the collision forces lift the whole ragdoll an inch upwards to the air so it can't settle. It makes a few steps and finally falls down. (right now it always needs at least one foot in resting contact to do something meaningful).

I'm very excited - seems you're on your way to solve the impossible...

you see that's the spirit, I knew you will come around.
when the final commit is in, it may be that you need to rethink your work.
Because what has happened in the last 10 years or so is the Game physics engines, wi tehteh help of the self appointed experts, has convinced the people the physics should be noisy, and everyone has modified the work to cope with noisy solutions.
The result is that every thing the you simulated using these physics engines, cannot it be trusted because it can not be realized in reality. This solution now is elimination lot of low frequency noise. the high frequency is there but that will go away too.

Do not do any significant changes yet, because it going to get even stiffer, and the energy added will be reduce to a minimum, The energy added to the system can never be zero, because as the joint forces because stronger, I mean we are talking 10 of found of newton's or even higher. so any small joint drift translator to energy added to the system.

The reason the joint force are so strong is because the condition of rigid under formable bodies.
at the states this is becoming a big limitation.
In reality what happen is that body do deform and the energy generate by the joint force and the small displacement I consume by the body deformations.

Later I will see if I can hack the dissipation of the joint energy, If no I will look at the Shomaker book to see if I can incoopretd stress Inertia tensor.
Because the energy can lead to exposition if not dissipated. The was the problem the old 1.5 solver.
but anyway this is a step in the right direction.

[Julio Jerez]

can you make a video of how it looks?

[JoeJ]

This time i made the video with 120 steps per second (usually 60) - it's better to see what's happening.

I'll be offline til next week - broken internet connection.

[Julio Jerez]

Ok I just committed the second feature for 3.14, The Aggregated
These are lie compound and scene collision, but the group dynamics bodies with no zero mass

My example of that is imagine, a scene with 200 rag doll or many vehicles.
say each rag doll has 20 body part each. we are now talking 20 x 200 = 40000 bodies

The added lot is extra ietetaion on e broader phase when we know that fo ra rad doll adopt each body will inertart with each body.
if we group each rag doll into a aggregate, now the brad phase only have to iterate over 200 cells instead of 4000,

the each time it find an aggregate, I most call the routine for self collision.
howorve there there are lo of short cut that can be taking.
1-if the rag doll is sleeping, the no action is taking because aggregate itself is can be sleeping when the rag doll is sleeping
2-ifn the case of contagions like vehicles when the collision is disable, then the aggregate can have the self collision flag turn off.

Imagine a city made of many big building with many room each room populated with furniture and all king of objects. we many be talking of 400 room, and 10,000 to 20,000 bodies

but we know the must of the city is no active, use aggregate the engine now deal with the 400 aggragate and the active room, instead of 20,000 individual bodies

The feature was in old newton 1.5 which was using obtrees, and I abandonee for 2.xx and early 3.xxbecause required lot of maintenance, but now I am bring in back with the difference that the use control it no the engine.

Now I can either go back to optimize the Joint solver or add the Use contacts. I think I will complete the joints, it bothers me they are done with a place holder solver.

room

[JoeJ]

It's clear for the ragdoll example, but the city / room / objects raises some questions.

Say 20 objects in a room are in a aggregate. Character is entering room an picks up one object.
Would that result in distance checks between ALL 20 objects in the room and the character
(If the character is a aggregate ragdoll, that would lead to 20 x 20 checks - quickly loosing the advantage)

I'd handle it this way:
Character picks up object -> object is removed from room aggregate (Add it to caharacter aggregate ?).
Character walks in another room and puts object on a table -> object is added to the other rooms aggregate of objects.
Is this the kind of user responibility you have in mind

[Julio Jerez]

Oh I am glad you are curios.
yes that’s a legitimate question.

In you example the object is the room that are wooed by an aggregate will interact with each object in eh broad phase scene graph, the reason is that an aggregate is just a a tree node of the prophase that happen to intersect its submit pair function.
The broad phase thinks the aggregate is a terminal node, so there are only five collision possibilities

1-Self aggregate collision, this is just a recursive call the submit pairs with the root node of the garage as root objects. This is the only part that is new and different the compound collision.
2- Single node vs single node (we have that already)
3- Single node vs aggregate (this recursive call to submit with the single and the root of the aggregate as arguments), the case is borrowed and edited from compound vs simple collisions
4- Aggregate vs single node (same as above but with the arguments transposed), also borrowed and edited from compound vs simple collisions.
5- Aggregate vs Aggregate node (a call to submit pair using the method the was used in newton 3.12

and lower), also borrowed and edited from compound vs simple collisions.

Say 20 objects in a room are in a aggregate. Character is entering room an picks up one object.
Would that result in distance checks between ALL 20 objects in the room and the character
(If the character is a aggregate ragdoll, that would lead to 20 x 20 checks - quickly loosing the advantage)

The above method will prevent that from eve happens, because this isl fall on case 5,
which is a summit pair bewteen two hierarchical aabb trees, just lei compound vs compound is doing already.

Yes you are current is object get out of the room the bound of the aggregate will grow by a very large size and the will make the aggregate overlap with lmao abet child body turn the tree into a N x N search.

But that violates the criteria for making an aggregate which is that the bound will remain unchanged for long periods of times.

In these cases the client app can do few things.
1-No use aggregate for those cases.
2-Use aggregate and do nothing.
3-Use Aggregate destroys it if the bound grows too large.
4-Use Aggregate and only remove the body the leaves the aggregate

For that there is interface for destroy aggregate and add and remove body, I need to add one for reading the Bounds so the client app can make those checks.

I probably need to make a test demo to show that.

[Julio Jerez]

I now have the final optimized version running.
I did a simple test with 25 ragdoll over the terrain and it is about for time faster.
it is also stable when it does now blows up, but it does blows up easily specially if to pick it from the ground, That was expected.

Basixcally I have to do few thongs.
1-Check the to make sure there are no bugs. But think this is very secured now.
2- Some of the matrices are losing the positive semidenitive condition, I did a simple test an I detect some.
3 some intermediate matrices has condition number of over 10,000 even more sometime 100,000
what means is that the can no be inverted using single precision floats

I nee to check these tow thong and it turn out here are correct, the I need to think how to incorporated the regularize to the Math so the condition number is reduced.
the last result is to us a matrix of double as intermediate variable to do the unstable calculations.

The good thing is that the system is fully implemented it jus nee to cove the edge cases.
It is no checked in yet, maybe two ore days.

[Julio Jerez]

Ok, I think I just figure out what is the problem. and for what I can see the solution make even better. I will try tonight. sometime thong that look good on paper do no look as good after implemented. But I have good confidence this is the problem. so maybe tonight

[Julio Jerez]

Ok, the code is now check int.
It is 4 time literately four time faster, and remember you say ta the initial commit the joint were not going to sleep, now the do real fast. that telling that the algorithm is correct.

There is one side effect, and that is het the force calculated by the solver are so strong that the y can easily over flood a 32 bit number. at first I thought it was a bug, by not the math is correct.

this is would happens if the joint are to be very stiff. think about the way to keep the part together is we stronger forces. what happen is the limbs that are fat away for the origin are affect by centripetal acceleration when engine supports, but centripetal acceleration grow w I the square of the angular velocity, so when spinning the array if of joint really fast will case that. specially when talking the moue ands ratline the body like I use to w the iterative

I can see that to a source of criticism by the self appointed experts, but in my conscience this is the right thong to do.

there are few ways to for the problem, one to relax the joint stiffness, right now the default is 0.9
another is to make the mouse pick force let strong,
finally if it becomes a big problems I can go and rewrite the part where intermediate values can over flood and use a double as intermediate variable.

The fat the the join can explode if a force is too strong is no unusual, think about in real like that kind of force will ripe apart the material, I mean the force we are taking about are of the order of billions of newton's. It is like the weight of a loaded container tanker resting on the limb of a human. that's is why I do not think it is serious problem.

finally the implementation is still prove of conspectus the class are virtual function the final review can make about tow to tree tiem even faster. so let us see how it works.

[JoeJ]

No luck so far, my ragdoll explodes immideatly in the first time step.
I've tried those things but nothing helped:

Remove foot platforms, so there is no initial contact.
Reduce mass of all bodies to shorten forces.
Disable Powering (just unlimited ball and socket joints remain).
For the remaining joint reduce stiffness to 0.5 using NewtonUserJointSetRowStiffness.

Is the skeleton container also used in your ragdoll demo?
There i can pick up and shake a ragdoll, sometimes it suddenly disappears, but it runs well as long there is no large external force.

[Julio Jerez]

there was an explosion bug right after I check in please sync again. you do no have to do anything other that what you had before.

[JoeJ]

Downloaded again using Download Zip button but nothing changed.
(I'm never 100% sure the zip button is up to date but i gave up on installing github and trying to download using that)

However, i tried a snake setup of 20 bodies using the same ragdoll joint and this works.
Also it's perfect stable - most probably because there are no branches or cycles in joint graph.

[Julio Jerez]

It should handle braches bur no cycles, do you have cycles (loops) in you model ?
also is should be always perfectly stable, if there are no floats degeneracy in the calculation.

If you have cycle all you need to do is crate a break, by the I mean just do no add that link to the skeleton.
if you has cycle the reason it was working before is because I was using the general solver to get the system going. but the general solve is too slow.

I am now test newton 3.14 vs 3.13 and some how I made a mistake it is about 50 % slower, I have to see why is that because when no using the new feature it should be identical. I am guessing I left some debug code on some where.