Fixed joint rigidity

[Cote-Duke]

Hi there,

I'm currently trying to implement the fixed joint capability in the engine. Well, simply put I want to couple objects together into rigid systems. I am planning to break these object systems, so compound collisions for the most part are out.

I do understand that everything is numerical and it is impossible for joints to stay completely rigid. But how rigid can they actually be? I tried a lot of things to implement the joint: limiting a custom universal joint, adding an extra degree of freedom to a custom hinge joint etc. Some wobble more, some wobble less. Currently I've settled with the general 6-DOF joint that's supplied with JointLibrary. It's quite acceptable, but still..

Here's a video that roughly demonstrates my point.

http://www.youtube.com/watch?v=JG7lkUSQ56U

It's a very basic setup: 7 objects, where each object has at least one joint association with some other object in the system (mostly one joint per object). As you can see, when applying a force on the bonnet the trunk area wobbles the most and vice versa. This is all very logical, but maybe I'm missing something and there is a way to make the system more rigid?

Thanks ahead for your time.

[JernejL]

Why are compounds out? you can easily recreate a compound mesh, it is very fast since the original bodies that make up a compound are still accesible and can be easily split.

[Julio Jerez]

The physics solver in newton is the same that you would find on hig end physic solution because it is base on the same laws of physics
In fact Netwon is by far superion tah all of the HIgeh end enfgien liek CMLam and the varios DEM solvers.

But you cannot pretend to have that kind of fidelity is a realt time physics engine
with a numerical solver that can only find a solution with a margin of error.

your best bet is to run at a higher rate first for exampel 240 fps instead of 60,
the rigidity should be must better.

[Leadwerks]

That looks like any other physics simulator running at 60 FPS. Reminds me of the fixed joints in Garry's mod.

You can make single collision objects into breakable pieces. It takes a lot of work to set up, but you just create a mesh for the unbroken whole, then separate meshes for broken pieces. When the body breaks, replace it with the parts.

You could also parent the visual meshes all to one body, until the object breaks. Then the mesh will appear completely rigid, and the user won't notice if the physics are a little loose.

I recently implemented fixed joints. Here is my code:

Code: Select all

Rem
bbdoc:
EndRem
Type TJointCustomFixed Extends TJointCustom
   
   Field childrelativeposition:TVec3
   Field childrelativeaxes:TVec3[3]
   Field parentrelativeaxes:TVec3[3]
   Field oparentmat:TMat4
   Field ochildmat:TMat4   
   
   Method SubmitConstraint(timestep:Float,threadIndex:Int)
      NewtonWorldCriticalSectionLock(TWorld.Current.newtonWorld)
      Local matrix0: TMat4=New TMat4
      Local matrix1: TMat4=New TMat4
      Local desiredposition:TVec3
      Local p0:TVec3
      Local p1:TVec3
      Local stiffness:Float
      Const dist:Float=5000
      
      stiffness=getstiffness()
      
      newtonbodygetmatrix parent.newtonbody,matrix0
      newtonbodygetmatrix child.newtonbody,matrix1
      desiredposition=TFormPointm(childrelativeposition,matrix0,Null)
      
      NewtonUserJointSetRowStiffness(newtonJoint,stiffness)
      NewtonUserJointAddLinearRow( newtonJoint, matrix1.Translation(), desiredposition, vec3(1,0,0) )
      NewtonUserJointSetRowStiffness(newtonJoint,stiffness)
      NewtonUserJointAddLinearRow( newtonJoint, matrix1.Translation(), desiredposition, vec3(0,1,0) )
      NewtonUserJointSetRowStiffness(newtonJoint,stiffness)
      NewtonUserJointAddLinearRow( newtonJoint, matrix1.Translation(), desiredposition, vec3(0,0,1) )
      
      p0=matrix0.Translation().plus( TFormVectorm(parentrelativeaxes[0],matrix0,Null).Scale( dist ) )
      p1=matrix1.Translation().plus( TFormVectorm(childrelativeaxes[0],matrix1,Null).Scale( dist ) )
      NewtonUserJointSetRowStiffness(newtonJoint,stiffness)
      NewtonUserJointAddLinearRow(NewtonJoint, p1, p0, matrix0.J() )
      NewtonUserJointSetRowStiffness(newtonJoint,stiffness)
      NewtonUserJointAddLinearRow(NewtonJoint, p1, p0, matrix0.K() )
      
      p0=matrix0.Translation().plus( TFormVectorm(parentrelativeaxes[1],matrix0,Null).Scale( dist ) )
      p1=matrix1.Translation().plus( TFormVectorm(childrelativeaxes[1],matrix1,Null).Scale( dist ) )
      NewtonUserJointSetRowStiffness(newtonJoint,stiffness)
      NewtonUserJointAddLinearRow (NewtonJoint, p1, p0, matrix0.K() )
      NewtonWorldCriticalSectionUnlock(TWorld.Current.newtonWorld)
   EndMethod
   
   Method SetPin(pin:TVec3)
      Local mat:TMat4=TMat4.FromDir(pin,1)
      childrelativeaxes[0]=TFormVectorm(mat.i(),Null,ochildmat)
      childrelativeaxes[1]=TFormVectorm(mat.j(),Null,ochildmat)
      childrelativeaxes[2]=TFormVectorm(mat.k(),Null,ochildmat)
      parentrelativeaxes[0]=TFormVectorm(mat.i(),Null,oparentmat)
      parentrelativeaxes[1]=TFormVectorm(mat.j(),Null,oparentmat)
      parentrelativeaxes[2]=TFormVectorm(mat.k(),Null,oparentmat)
   EndMethod
   
   Function Create:TJointCustomFixed(parent:TBody,child:TBody,position:TVec3)
      Local joint:TJointCustomFixed=New TJointCustomFixed
      joint.parent=parent
      joint.child=child
      
      joint.childrelativeposition=TFormPoint(joint.child.position,joint.child.parent,joint.parent)
      joint.childrelativeaxes[0]=TFormVectorm(vec3(1,0,0),Null,joint.child.mat)
      joint.childrelativeaxes[1]=TFormVectorm(vec3(0,1,0),Null,joint.child.mat)
      joint.childrelativeaxes[2]=TFormVectorm(vec3(0,0,1),Null,joint.child.mat)
      joint.parentrelativeaxes[0]=TFormVectorm(vec3(1,0,0),Null,joint.parent.mat)
      joint.parentrelativeaxes[1]=TFormVectorm(vec3(0,1,0),Null,joint.parent.mat)
      joint.parentrelativeaxes[2]=TFormVectorm(vec3(0,0,1),Null,joint.parent.mat)
      joint.oparentmat=parent.mat.copy()
      joint.ochildmat=child.mat.copy()
      
      joint.NewtonJoint=NewtonConstraintCreateUserJoint(parent.world.newtonWorld,6,NewtonUserBilateralCallBack,Null,child.newtonBody,parent.newtonBody )
      
      NewtonJointSetUserData(joint.newtonJoint,joint)
      joint.ConnectLinks()
      Return joint
   EndFunction
   
EndType

Rem
bbdoc: Creates a new joint.
EndRem
Function CreateJointFixed:TJointCustomFixed(parent:TBody,child:TBody,position:TVec3)
   Return TJointCustomFixed.Create(parent,child,position)
EndFunction

And here is the base custom joint class:

Code: Select all

Type TJointCustom Extends TJoint

   Method Free()
      DestroyJoint(newtonJoint)
      newtonJoint=Null
      Super.Free()
   EndMethod

   Method SubmitConstraint(timestep:Float,threadIndex) Abstract
   
   Function NewtonUserBilateralCallBack(userJoint:Byte Ptr,timestep:Float,threadIndex:Int)
      Local cjoint:TJointCustom
      cjoint=TJointCustom(NewtonJointGetUserData(userJoint))
      If cjoint   
         cjoint.SubmitConstraint(timestep,threadIndex)
      EndIf
   EndFunction
   
EndType

[Cote-Duke]

Thank you all for your replies.

Why are compounds out? you can easily recreate a compound mesh, it is very fast since the original bodies that make up a compound are still accesible and can be easily split.

They are not out completely, of course. And the it's true that original collision instances are accessible after the compound collision is created.. but one problem is that the engine has to store all original collisions in order to recreate the compound in reasonable time. However I'm not 100% sure as to how exactly this affects the memory footprint. Does it matter if the program releases all original collisions or do they remain in memory until the actual rigid body that uses them is destroyed (well, they obviously remain in some form or another, but perhaps optimized)?

The other, much more significant problem, is that a compound collision is not as versatile\fast to recreate as a joint. After all the research, however, I consider it as an alternative.

The physics solver in newton is the same that you would find on hig end physic solution because it is base on the same laws of physics
In fact Netwon is by far superion tah all of the HIgeh end enfgien liek CMLam and the varios DEM solvers.

Yes, true. In the last week I found out that for myself. Constrained dynamics are a real pain and modern games do not seem to use them extensively.

your best bet is to run at a higher rate first for exampel 240 fps instead of 60,
the rigidity should be must better.

Oh, I completely forgot to tell at which rate the physics was run. Yes it is currently at 60 FPS, and upping it up helps quite a bit. In the days of 1.53 that was severely damaging the performance. With 2.0 it runs faster, but still I'm not sure I can afford 240 FPS for physics in a game. (Yep, that's my problem)

That looks like any other physics simulator running at 60 FPS.

Yeah, 60 FPS.

Reminds me of the fixed joints in Garry's mod.

And that's way there are not many fixed joints in HL2. (Or none at all? )

You can make single collision objects into breakable pieces. It takes a lot of work to set up, but you just create a mesh for the unbroken whole, then separate meshes for broken pieces. When the body breaks, replace it with the parts.

You could also parent the visual meshes all to one body, until the object breaks. Then the mesh will appear completely rigid, and the user won't notice if the physics are a little loose.

It may be a possibility. However, beside the reasons I've already mentioned, due to very generic nature of objects in the game - very little is known at design time (read - the engine does not operate with concepts like vehicle, chassis. More like - joint, wheel) it is going to be really hard to implement that adequately. But in the end of the day, I might give it a try.

As for the code - it seems like a modification of the hinge joint. Is this implementation more stable?

[Dave Gravel]

Do you have take a look in the VehicleMultibody joint code ?
The joint use special matrix calculation ProjectTireMatrix to make it more rigid with 1 solver.
I know it's not a fixed joint but maybe it is possible to apply similar matrix trick with your joint or correct it by the force.

[Julio Jerez]

Dave Gravel suggestion is very good but is not that simple and it is not general.
things like Cars and RagDoll are good canditate for that trick. Contaction with internal loop pose a big problem wit the trick.

If your articulated body can be arranged as a tree like structure,
Here are some tips for when to use the projection trick, You can add a unilateral joint to the root object to use as the controller.
In the joint callback you walk the tree from root down in a BreadFirstSearch mode,
for each joint you consider the root the parent, then you determine the distance error, and project eh child body to match the parent at the attachment point,
You also need to cancel the velocities relation to the attachment.
And the you keep going down until you cover all children bodies.
Usually projecting the velocities only can do the trick.
This is a trick that is hard to implement and it depend of the king of object you are making,

Done well it leads to a decent solution but it do not generalize.

How many joint are you using in t he video, all in All it doe no look that bad, can you try 120 fps see hwo tha works?

[JernejL]

They are not out completely, of course. And the it's true that original collision instances are accessible after the compound collision is created.. but one problem is that the engine has to store all original collisions in order to recreate the compound in reasonable time. However I'm not 100% sure as to how exactly this affects the memory footprint. Does it matter if the program releases all original collisions or do they remain in memory until the actual rigid body that uses them is destroyed (well, they obviously remain in some form or another, but perhaps optimized)?

The other, much more significant problem, is that a compound collision is not as versatile\fast to recreate as a joint. After all the research, however, I consider it as an alternative.

The compound object is just a container that holds multiple convex objects in a completely rigid manner, even when serialized, with NewtonCollisionGetInfo you can get the original newton collisions that make up the compound (there's a pointer and object count to a list of pnewtoncollision pointers)

I assume newton supports sharing collision pieces among multiple compounds but julio should be more knowlegeable in this area.

I was making some convex mesh decomposition tools which used newton to create a convex "compound-hull" of spaceships, the finishing step of building a compound of premade collisions was very fast, so i would really suggest you look into this option, because if it's fast enough and works how it should (i mean sharing collisions) it'l be totally rigid and less math intensive for the cpu.

[Cote-Duke]

Do you have take a look in the VehicleMultibody joint code ?
The joint use special matrix calculation ProjectTireMatrix to make it more rigid with 1 solver.
I know it's not a fixed joint but maybe it is possible to apply similar matrix trick with your joint or correct it by the force.

Dave Gravel suggestion is very good but is not that simple and it is not general.
things like Cars and RagDoll are good canditate for that trick. Contaction with internal loop pose a big problem wit the trick.

If your articulated body can be arranged as a tree like structure,
Here are some tips for when to use the projection trick, You can add a unilateral joint to the root object to use as the controller.
In the joint callback you walk the tree from root down in a BreadFirstSearch mode,
for each joint you consider the root the parent, then you determine the distance error, and project eh child body to match the parent at the attachment point,
You also need to cancel the velocities relation to the attachment.
And the you keep going down until you cover all children bodies.
Usually projecting the velocities only can do the trick.
This is a trick that is hard to implement and it depend of the king of object you are making,

Done well it leads to a decent solution but it do not generalize.

Yes, that looks interesting. It's a bit hard to extraploate on every situation but definitely worth a try, if everything else fails.

How many joint are you using in t he video, all in All it doe no look that bad, can you try 120 fps see hwo tha works?

Well, that setup was lost. (There were about 5 joints). I made a new test setup, this time it runs at 120 FPS and features 1, 2 and 3 joints. And I've just spotted a new trend - it seems that instability depends on objects themselves.

http://www.youtube.com/watch?v=lwrYd2gK4As

The wheel wobbles just a bit. The wing is rigidly connected (instability can't be seen by naked eye). But then - just a simple rod (read box made into single-collision compound) is barely fixed at all. After modifying it a bit (on physical level the compound collision now consists of two boxes formed into a "V" shape) the connection becomes rigid.

I suspect that this behaviour might be a product of incorrect inertia. I will look deeper into this and see if that is indeed the case.

EDIT: Forgot to mention that the wheel itself also consists of two jointed objects and no wobble there. So, the situation is not bad indeed.

The compound object is just a container that holds multiple convex objects in a completely rigid manner, even when serialized, with NewtonCollisionGetInfo you can get the original newton collisions that make up the compound (there's a pointer and object count to a list of pnewtoncollision pointers)

I assume newton supports sharing collision pieces among multiple compounds but julio should be more knowlegeable in this area.

I was making some convex mesh decomposition tools which used newton to create a convex "compound-hull" of spaceships, the finishing step of building a compound of premade collisions was very fast, so i would really suggest you look into this option, because if it's fast enough and works how it should (i mean sharing collisions) it'l be totally rigid and less math intensive for the cpu.

Without doubt this is the most prudent way performance-wise and that is a big advantage.