Joints stiffness

[arkeon]

Hello,

is there a way to make a more robus joint stiffness ?

depending of the joints hierarchy the joints are often going out of limits.
Eventually bodies with high mass linked with a joint to another body with lower mass are not stable.
Is there a logic about the masses to apply on bodies hierachy like a ragdoll for example ?

[Julio Jerez]

If you way a few days, maybe by this weekend I am working on a solution to that.
A really, really good one.
the best thong is that it will no change the interface in any way.

this is something I has stared before but then I got distracted and bu now I am real motivated.
believe you will no be disappointed.

[arkeon]

hehe cool!

no hurry just noticed that the joints are a little more "elastic" in 2.13.

[Julio Jerez]

really? I would think there are stronger, are you in lattet?
by in any case most those issue will go away.


Oh I see, the reason hey are softer is because In 3.13 I relaxed the solver iteration count.
before 1 meant stating at 4. because it added 3

then I set the default to 4, but it you are explicitly setting to 1 mode then yes it will be softer
the it will be internally as opposed 4 like it was before. please try 4, maybe 3 or any other values,

this is why I am planning resolving the joint issue because 1 may be goof for very large number of bodies that are just colliding but are too soft joint but if I can get the joint out the way, them the best of all worlds.

please try 4

[Julio Jerez]

After this new feature that I am thinking about Join will be as hard or even harder the how they are with exacts solver.
This will bring back the possibility of explosion like with the all solver if a matrix or any of the minor co-matrix becomes singular, but this time around I will not make the same mistake that I did by setting stiffness to 100% I will set to a low and let the end user to make them harder

[arkeon]

you mean it should also allow high acceleration on bodies ?

ok I will try 4

[Julio Jerez]

yes

[arkeon]

nice

[arkeon]

good, setting iterative level > 3 gives the previous behavior back.

[JoeJ]

...sounds i'll have to update!

[AntonSynytsia]

Yes!!! I'd like to see joint stiffness not dependent on mass.

[Julio Jerez]

it's is all part of the plan.

[Julio Jerez]

another feature that is coming with the 3.14 is something I wanted to do for come time.
that is the User contact

There some effects that can't be handle well with the normal column box friction model.
two example are sticky contacts and another is a tire contact.

Both do very different things, this is one of the reason why the vehicle is has so much code in the joint library. but that always bothered me.

after concept that newton joint solve I will move the vehicle to the solver so that is all work to together. the vehicle control will register a Tire contact callback will be called to populated the tire friction model stuff.

There the tire can use what mean to the tire calculation included the convex cast stuff.

The second example t the sticky contact which if two object get together the sticky force, this can do cool effect like throwing tuff the get stocked to walls, or voronoi fractures the pieces are glue by stick contacts. so they they do no fall apart so easy.

this will probably made the voronoi destruction easier for people to use. WE have for some time but the amount of code on he sandbox it too much for people to handle.

[JoeJ]

another feature that is coming with the 3.14 is something I wanted to do for come time.
that is the User contact

That's very welcome (i often thaught about your sticky contacts idea since you talked about it).

Also this is what prevents me from updating frequently because i have to hack newton to keep my own user contact joint working (need access to some private members etc.).

The use case for me is: Interesting for walking ragdolls. You can simply remove the foot body and create a contact between ground and shin bone and place it where you want the preassure point.

The origianl reason i have implemented this was another one:
Remember my experiment of scaling a box at runtime smoothly from 100 to 200 %, while some other bodies rest on top of that box.
The default behaviour is that the topside bodies do not move and also the box scales partially into the floor (No velocity at COM, so Newton does nothing).
I've tried 3 things to fix this:
* Update contact velocities to include the 'scaling velocity' - did not work
* Duplicate your contact code in a joint as you suggested - same result (but very usefull for ragdoll)
* Iterate over contacts and add a seperating joint at their positions - this works well, but is not very efficient and it is difficult to choose max friction joint values for penetration / friction.

Maybe you can keep that in mind when doing your user contact. Think of a scale gun in a portal like game


---
You have changed the default solver iteration count - i'd suggest you change the interface for the setter method as well, to force users to recognize this imortant change.

[Julio Jerez]

yes another use case for that. Bscially will contact very similar to a use joint. the can no be member of the same class because contact and bilateral joint have the interface but are on different branch,
and because the contact need to be crated by the contact manager will need to register a creation
call back the call call the constructor the use side.

You have changed the default solver iteration count - i'd suggest you change the interface for the setter method as well, to force users to recognize this imortant change.

excelent idea, will do in next commit.