JOODE update

Game Mechanics
#1

I havn’t really been informing of JOODE updates lately, as really I wanted to wait until something really good happened.

Currently we now have
2D support, using Phys2Ds Rectangle and Colliders colliders (although there are some implmentation issues :confused: , the collision point is always returned as a point on an edge of a geom, which means the collision is exactly on the edge of one geom, but somewhere inside the volume of the other. This causes geoms to get stuck in each other or no collision to be flagged if a geom completely fits inside another, still for slowish stepping this is all ok)

Trimesh trimesh collider. currently being optimized for speed (this is implemented by Art Pope)

Lots of new stepping functions. An RK4 stepper which works with the existing constraint based solver. However, the accuracy gained is rather pointless becuase the rest of the system is quite innacurate. These are inherited problems from ODE. For example, spinning a body WITH NO JOINTS, will not conserve angular momentum.

However, I have addressed this with new body stepping functions that use RK4 implementations to alter just the body variables. This provides accurate individual body stepping. However this is not enough to solve all the problems relating to the constraint based joint implementations. I am working on that, in the mean time, if you just want bodies that fly about and not complicated joint structures there are two new world stepping functions to help you.

SimpleStep uses an RK4 implementation to update all the bodies in the world at the same time. Fast compared to solving LCP constraints.

AccurateSimpleStep uses the same method as above, but uses an adaptive stepsize to ensure accuracy meets a user specified tolerance. Probably not something the gamers are really interested in but I need it :slight_smile: It might be useful though, becuase it does tend to ensure the simulation remains stable.

The two new step methods, although using RK4, I have found to be pretty damn quick even with adaptive stepsizes. One of the reasons I think this is, is becuase the step functions have been built from the ground up with zero garbage in mind so they really do perform well.

In order to utalize the RK4 implementation some new Force features have been added. BodyForce and WorldForce allow forces to be recalculated on a per sub step basis. This means you can implement things like really accurate springs etc. I have provided a sample Spring and Body damping implmentations.

Oh yes also body state variables have changed in nature. Instead of holding a fixed angular velocity, angular velocity (which is not a conserved quantity) is derived from angular momentum (a conserved quantity). Same applies to linear velocity. Its a better way of doing it.

Finally, I am implementing a new type of joint called a JointConfigurable. This should kinda work like the novodex API in that it is a generaly purpose joint that can basically replace all the other types of joints. Its not fully finished yet and I think I need to do a overhaul of the constraint system anyway.

My first next move though is to create a joint configurable that works by inducing spring like forces. This is not as good as a constraint based implementation, but at least I can make it accurate and ensure all momentum constraints etc. are satisfied. At the moment constraint based joints are really prone to increasing the amount of overall energy in the system resulting in horrible looking simulations (not sure if this is a bug or it can’t be helped by nature of constraint implementation).

I am not personally working on any collider stuff becuase it is not in my immediate needs. There are issues with the colliders so volunters please!

#2

Actually I have the constraint based forces working with RK4 now, for fixed stepsizes. So I probably won’t bother with penulty methods for creating joints.

#3

Just wondering how R4K compares to LCP? I know R4K is more accurate, is that right? But in terms of performance…

#4

Actaully they are different aspects of the physics calculation. The LCP algorithm underlies the calculation of constraint forces. So the LCP decides how big a force is needed to ensure a joint remains valid over a time step, taking into acount all the other bodies and all the forces on them (and all the other constraints all at the same time).

The RK4 is an intergrator. This works out what new values of variables are as time passes. It does this accuratly by taking 4 samples of the gradient of the variables at points of the time step interval.

In JOODE the state variables are the bodies momentum and position etc. The gradient of momentum i.e. the rate of change of momentum is force. So actually when RK4 is stepping, it is also calling the LCP algorithm to work out the gradients.

The basic alternative to RK4 intergration is Euler intergration: x at time t+1 = x at time t + dx/dt * stepsize

The time complexity of RK4 is still inear, just 4 times more expensive than Euler. But much much better accuracy.

LCP stuff however, because it has to take into account all constraints at the same time to work out the exact forces that are required is actually something like O(n^2) (thats not really half the story actually). As for its accuracy, I am pretty sure it does produce the correct answers.

The major caveat is that sometimes you can get in situations where the constraints conflict because of numerical errors. Then the LCP algorithm can’t solve the equations becuase they are genuinely impossible to solve. So for that you have to weaken the constraints. An LCP algorithm fed by Euler intergration I think is a receipe for disaster.

I really don’t think there is much point using Euler intergration other than it is really easy to write. I can’t rememeber the exact figures but Euler has an accuracy term of O^2 and RK4^5. So to double the accuracy of Euler intergration you have to half the step size. With RK4 becomes much more accurate very quickly. So you get much more back in accuracy for the time you lose computing RK4. And in many situations accuracy can be traded back into time by taking larger stepsizes, and if this is the case, then RK4 will run much much quicker than Euler.

Anyway so I think ODE’s accuracy issues are largely due to the Euler intergrator feeding the LCP algorithm. In order for the LCP algorithm to terminate the constraints have to be softened alot becuase of large numerical errors caused by the intergrator.

JOODE now has that aspect all sorted. Unfortunatly I think there are still a few bugs in the joint impementations, which means the constrained joints still do not behave correctly, but its not the intergrators or LCP algorithms fault!

Tom

Tom

#5

Thanks for the nice post. Clarified alot of stuff for me…

DP

#6

Tom,

In your last commit (today) you mentioned thoughts about a release. What are the features you think may be included in a first release? Do you plan to have all colliders implemented, JointConfigurable complete, …?

Just to get an idea of what we might expect.

#7

OK. I don’t really have a timescale, but ASAP :confused:

A configurable penulty based joint implementation (basically JointConfigurable but with springs instead of proper constraints).

RK4 and Euler intergration. With dynamic forces.

Not all colliders implemented. I am terrible at coding colliders and all my effort is going into dynamics at the moment. Trimesh Trimesh collider though should be working quite well by then.

The real point of the release though is just to document everything and provide it to people in an easily downloadable format. Then everyone can play with it and tell me all the bugs which I just simply don’t have time to hunt for myself. I don’t expect the constraint based physics to be working properly, so the documentation should reflect what I know works and what does not work. The other major point is for me to actually write a nice website. I feel JOODE in someways is getting pretty good in theory, but 1 no-one knows about it because no-one uses it becuase I don’t advertise it anywhere and 2 it probably doesn’t work as well as the thoery suggests because I have no-one testing it to tell me what tiny things need fixing.

#8

good work!

I’m sorry I wasn’t able to do anything lately - loads of stuff just ate my time - I wasn’t even able to check on the forum!

I hope, I’ll have some time soon to get back to my project owner responsibilities and to test and commit new code.

greetz,
Arne

#9

No worries. Just a general point on the way we are now doing things now. Instead of using loads of static variables, temporary variables should be obtained through the pool classes now. I want to get rid of those static variables eventually, they look ugly. The pool solution is neater, (and uses slightly less memory).

Tom