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.

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

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.

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.

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.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

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.

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.

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

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.

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

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

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

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

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.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

Initial attempts to apply LCP methods to frictional contact problemscould not guarantee the existence of a solution for all cases [Baraff1994; Trinkle et al. 1995]. This was later fixed by formulating animpulse-velocity, rather than a force-acceleration, approach to theLCP problem [Stewart and Trinkle 1996; Anitescu and Potra 1997]

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.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

6. Dynamic FrictionIf the relative tangential velocity at a contact point is nonzero, then dynamic friction occurs, as opposed to static friction. Regardless of the resulting tangential acceleration, the strength of the friction force satisfies

|fFi| = mu fNi

This replacement results in a matrix A which is unsymmetric and possibly indefinite as well. Because of this, systems with dynamic friction can fail to have solutions for the contact force magnitudes, requiring the application of an impulsive force.

Yeah ok. I am getting there with this problem. Numerical errors cause the LCP to say it can't terminate when it actually can. When max stepsize is worked out, it is then multiplied and applied, but this route may not actually cause the resultant f's and a' to lie on the boundary as worked out by max step. This can causes slight negative values for acceleration sometimes, which then kinda contradict later calculations.

I have added functionality to max step so that the restriction is recorded, then after the maxstep is applied, the restriction is enforced so that the boundaries for the max size are exactly the correct values as predicted by max step.

Your loop stopper doesn't work becuase in alot of cases the step is tiny, and isZero says it is zero when it shouldn't be. Don't worry about that though. As at the moment I have the LCP thing probed to the max on my machine so don't alter anything becuase it will conflict me. I will commit my stuff as soon as I am finished.

Despite me fixing the constraint errors in the LCP. I still get some strange bouncing behaviour from the bodies. This is caused by something outside the LCP. Am trying to diagnose now.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

Yeah I get a weird bounce when the ramp hinges on the wall, then the lower end hits the plane. It seems to calculate the 4 forces without error (from the LCP point of view), but then on the next step the interpenetraion depth increases on the wall contacts, so the replsive force on the next step is large.Whcih means I think there is an error on the code before. sigh

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

Still hunting... found a bug in edge-edge intersections between boxes! That was definatly one cause of bounce, but still working on the inertia tensor issues. According to me ODE does not calculate the intertia tensor correctly jsut before the LCP is called, however, when I put my "correct" method in, the simulation performs worse :/

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

OK. Bug fix for Box-Box collisions committed (it has taken me one and a half full days to finally work out why it was erroneous, I even tried writing my own collider, the actual bug turned out to be something really petty as usual ).

The only thing outstanding I think is possibly a bug in inertia tensor calculations, but it seems to run alot better without me messing around with it. Arne can you try it out please? The example seems to work for both RK and Euler for me, but I have not totally committed my stuff becuase it is heavily probed.

Tom a happy and tired man.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

Oh thats strange. RK is not that slower on mine, but I will add something to the collision manager so that it can be decided whther to update collisions per step or per substep. The substep thing was added for the wrong reasons. Also RK4 step calls the collision manager twice per substep which is another fault anyway.

I just found a conceptual problem with our LCP solver, I will fix that next because the Euler is still not simulating the dry friction quite right.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

Yeah, I realize of have optimized too far somewhere. Anyway, it does not matter too much, it was broken even when it was wroking better. I am upgrading to a new LCP solver now so that we can have proper friction. So the current LCP will be for non-penatrating contacts only (which it does compute fine), and the new one will be for static and dynamic friction.

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

Oh my god its complete. A new LCP solver. God tutorial one runs lush now. Static friction applies forces to the body, even when the body is moving. So before you could move that ball fast and suddenly it would stop rolling, this was becuase 1. the system of equations can't be solved in one direction, and 2. when acceleration is posatively away from the contact, the contact force is set to zero, so no effect anymore.Anyway, we have proper static friction now, so the ball spins faster and faster, and requires effort to slow it down again and get it to handle well. Ooooooh its nice, it makes a remarkable difference to the simulation. During development I had a few explosions. I think I have solved them all but I can't be sure... keep me posted of errors. Its a pretty massive algorithm in the end with lots of bits were it just gives up on a constraint and moves onto the next so I have a real fear of infinite loops, moreso than the old LCP. However I have not yet had an infinite loop error, only the odd explosion or NaN. Today was a good day!

Runesketch: an Online CCG built on Google App Engine where players draw their cards and trade. Fight, draw or trade yourself to success.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org