JOODE: documentation

Game Mechanics
#1

Hi

I think he is right, we only have javadoc and a link to the ode documentation.

We need at least a little tutorial, to get the people started. I’d offer myself to write such a tutorial. Which format should I use? I think, there are three options: latex, odt (doc), or html.

@Xith-guys: what did you use for Xith in a Nutshell?

Arne

PS: if we’re using html, it can easily be placed directly on the sourceforge site.

#2

I used OpenOffice (odt). And I was quite happy with it. One of the users asked some days ago, if he could convert it to latix and I agreed. But he never did. Of course OpenOffice can easily export to PDF, which is the current result.

I would even suggest to use a similar style as XIN for the JOODE doc, since XIN was always considered to be “a good read” by everyone, who read it.

Both odt and latex can easily be exported to XHTML. On xith.org there is the XHTML export of XIN to be viewed online. Unfortunately the images got lost with this export. Though Amos said, that OpenOffice CAN export to XHTML with images.

Marvin

#3

then I’ll use OpenOffice, too :wink: and use XIN as something like a prefab :wink:

#4

darn - Xith changed a lot - at least the stuff used in XIN. This wouldn’t be problematic, if you’d have also written the import statements needed. Currently I’m using the eclipse search function to find the packages. I think you should add that, so especially newbies don’t have to search for the imports.

#5

I hope I am not too late to join in this conversation but I think LATEX is probably better for JOODE, as empelishment with math could be very handy. Not that I expect the first tutorial to have one iota of math in it, but definatly final documentation should really have math. The system is deeply mathmatical after all.

#6

you’re lucky - until now I have written only text - that goes easily with copy and paste into latex.

mmh yes, if we want to add documentation for writing new Geoms and Joints, we’ll need math.

Actually I’m currently trying to figure out, how to set Xith up as clean as possible. So I try to follow the Xith In a Nutshell. But it seems, as if XIN is already out of date. I’ll make a post about that in the Xith-forums, cause I don’t want to spam this thread here - with unecessary Xith-related stuff.

#7

see: http://www.xith.org/forum/index.php?topic=378.0

#8

ok - now xith can be happy, not be the cause of my post - it works fine now :wink:

no, but those stepper functions we have in JOODE, they all seem to be somehow buggy. I committed the class src/examples/net.java.dev.joode.examples.Example1, it contains a very basic example of some walls and two bodies, one body is movable by pressing the arrow-keys on the keyboard.

  • stepEuler sometimes shows strange jumping behaviors, or even explosion like, with the bodies disappearing
    -> it prints me “Vector has zero size” on the console.
  • stepRungeKutter also shows those strange jumping behaviors, but instead of letting the bodies disappear, it simply seem to get caught in an endless loop.
  • I’ll only say only one thing about stepQuick: Forces seem to get applied totally different to the other methods, I’m not able to get the ball to move up the ramp.
  • the other stepping methods, don’t support Collisions and Joints.

I’ll try to debug and figure the sources of these problems out, especially the zero-size and this endless loop.

cheers,

Arne

EDIT: now Euler also hanged itself…

#9

The endless loop is normally caused by multiple constraints conflicting. Which manifests itself in the fdirection of the lcp. As one constraint is satisfied, it violates the other and they cycle. Really both runge kutter and Euler should do it if one does.
I have had problems with non spherical masses before. like the intertias are not passed correctly or something. This expoloding is normally something like a normal is not normalized properly. I am gonna do a bit of hunting myself now.

Tom

#10

First bug. CFM was not set to the world CFM of the created joints. This stopped the sudden bouncing of RK_4 step, but this is not the real bug I think. I think the problems with RK4 step is that contact joints persist during sub steps of the stepping function, even when the contact no longer should exist. So they kinda last longer and effect longer in a strange way. Solutions would be to rerun the collision code every substep.

I turned off static collisions to help bug hunting.

Not sure about the expolosions yet. I think it is something to do with a strange combination of contacts, and a gain in angular moment. I think somethign goes wrong with the calculations of inertia tensors or something before being passed to the LCP. Its a hunch I had a while back

Tom

#11

OK. bug was that the mass.rotate method rotated the wrong way. I have just put in a couple of transposes ( i.e. the inverse of a rotation matrix) at the beginning and the end of the method. This solves the explosions. Euler seems quite stable now. The transpose fix should be upgraded at some point. Mass.rotate is quite optimized becuase it is where alot of computational time is spent.

RK4 still gets stuck. I think this is becuase 1. contact joints are created. 2. The bodies are adjusted, perhaps rotated a little, yet the contact remains in the same position for subsequent substeps. I think after a little translation and rotation the contacts might end up trying to enforce impossible constraints, which cause the LCP to go in an infinite loop. The infinite loop bug is quite common for lots of different things. I think perhap someone should write a special routine to detect that the constraints are being solved in a periodic fasion. It should be easy to detect.

Cheers arne for the exellent test scenario.

#12

ok I looked at that endlessloop problem. Cause: BaraffLCP.driveIntoRange, line 193, 194, s = 0, so no adaption of the constraints happens. I’ll check, why s = 0.

#13

couldn’t find the problem, but added endless-loop detection instead

#14

this “LCP can’t find a solution”-problem might not be fixable:

[quote=“Fast Frictional Dynamics for Rigid Bodies
(Danny M. Kaufman, Timothy Edmunds, Dinesh K. Pai)”]
Initial attempts to apply LCP methods to frictional contact problems
could not guarantee the existence of a solution for all cases [Baraff
1994; Trinkle et al. 1995]. This was later fixed by formulating an
impulse-velocity, rather than a force-acceleration, approach to the
LCP problem [Stewart and Trinkle 1996; Anitescu and Potra 1997]
[/quote]
I believe, we use the force approach.

#15

In the cases we are getting with the RK4 step I don’t think that is the problem. Is it doing it will Euler step?

The solution problems are hinted at at the bottom of ODE’s FAQ [quote]http://opende.sourceforge.net/wiki/index.php/FAQ
[/quote]

#16

That LCP-Error nearly does not occur with Euler. But with RK4 step it occurs, when the body simply lies around (e.g. on the wall, or on the floor)

#17

OK. The reason why RK seems to have a hard time is becuase of the way violations are handled. Joints are passed the stepsize so that they can constrain the connected bodies velocities to reduce any error by the ERP parameter (if ERP is 1 then errors are reduced to zero in one timestep). So this works nicely for Euler, but in RK the joints are reevaluated multiple times during a timestep. So at halfway through the timestep the violaion is halfway to being removed completely, but then is reevauated, so the correcting force is halved (becuase the error is now half). RK4 then kinda averages the forces over the whole timestep, so you end up with a corrective force that does not correct the force completely in one timestep. I have dealt with this in JointConfigurable for linear dimentions by applying a constant jerk (differential of acceleration) during RK4 stepping, but I don’t think that that is the best way to solve the problem. So when you run RK_4 on example 1, more constraints are present than in the same simulation with Euler, becuase constraints are never corrected properly. I think generally its just bad to have constraints in error, and can cause all kinds of problems when trying to solve the equations, especially when the constraints are interdependant (which they are).

A partial fix to the system I have put in is to essetially pass a halved stepsize to joints during RK-4 stepping. It helps, but does not completely work becuase RK_4 is a little more complicated, and it can’t really be solved by scaling by a single amount. A proper fix is a little more involved.

The much better solution is to aviold excessive violations in the first place. i.e. apriori collision detection.

#18

the matrix A that gets passed to the LCP. Should that be a posative definite?? I got negative values in here. Is that allowed?

#19

in the baraff paper it says, that A should be positive semidefinite

#20

Hmmmmm. Bugger. I have to trawl through that god awful code before the LCP is called now. Maybe I should try to convert it to matrix notation while I am there…

Talk to you in 3 days time…