Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (483)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (550)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  JOODE: documentation  (Read 6270 times)
0 Members and 1 Guest are viewing this topic.
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Posted 2007-04-25 06:58:03 »

Hi

Quote from: hawkwind
On the subject of JOODE, my main hurdle is lack of doc.  I can run the examples but since most of the internals are obscured its hard to figure things out.

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.

:: JOODE :: Xith3d :: OdeJava ::
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #1 - Posted 2007-04-25 08:20:31 »

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

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.

Marvin
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #2 - Posted 2007-04-25 10:48:37 »

then I'll use OpenOffice, too Wink and use XIN as something like a prefab Wink

:: JOODE :: Xith3d :: OdeJava ::
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #3 - Posted 2007-04-25 12:45:02 »

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.

:: JOODE :: Xith3d :: OdeJava ::
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #4 - Posted 2007-04-25 12:56:24 »

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.
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #5 - Posted 2007-04-25 13:12:41 »

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.

:: JOODE :: Xith3d :: OdeJava ::
Offline Marvin Fröhlich

Senior Member




May the 4th, be with you...


« Reply #6 - Posted 2007-04-25 16:58:03 »

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.

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

Senior Member




money is the worst drug- we should not let it rule


« Reply #7 - Posted 2007-04-28 20:55:15 »

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...

:: JOODE :: Xith3d :: OdeJava ::
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #8 - Posted 2007-04-28 22:27:44 »

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.
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #9 - Posted 2007-04-28 23:43:37 »

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #10 - Posted 2007-04-29 01:17:37 »

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.
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #11 - Posted 2007-04-30 12:11:21 »

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.

:: JOODE :: Xith3d :: OdeJava ::
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #12 - Posted 2007-04-30 14:12:26 »

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

:: JOODE :: Xith3d :: OdeJava ::
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #13 - Posted 2007-04-30 14:48:56 »

this "LCP can't find a solution"-problem might not be fixable:

Quote from: 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]

I believe, we use the force approach.

:: JOODE :: Xith3d :: OdeJava ::
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #14 - Posted 2007-04-30 15:45:55 »

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

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

Senior Member




money is the worst drug- we should not let it rule


« Reply #15 - Posted 2007-04-30 17:29:14 »

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

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)

:: JOODE :: Xith3d :: OdeJava ::
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #16 - Posted 2007-05-01 11:09:37 »

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.
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #17 - Posted 2007-05-01 12:27:09 »

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

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

Senior Member




money is the worst drug- we should not let it rule


« Reply #18 - Posted 2007-05-01 12:32:28 »

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

:: JOODE :: Xith3d :: OdeJava ::
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #19 - Posted 2007-05-01 12:37:25 »

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....

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

Senior Member




money is the worst drug- we should not let it rule


« Reply #20 - Posted 2007-05-01 13:05:29 »

mmh read further on in the article.

this is not true for dynamic friction:

Quote
                                                                     
6. Dynamic Friction
If 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.

:: JOODE :: Xith3d :: OdeJava ::
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #21 - Posted 2007-05-01 15:08:41 »

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.
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #22 - Posted 2007-05-01 15:19:22 »

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.
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #23 - Posted 2007-05-01 20:27:04 »

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.
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #24 - Posted 2007-05-03 00:49:14 »

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  Undecided ).

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.
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #25 - Posted 2007-05-03 08:51:59 »

Hey, good work, Tom !!!

Euler now seems to run very stable. I wasn't able to find any explosion like behavior yet.  Cheesy

I can't really test RK4, because it's so damn slow somehow, I get an fps of about 8 fps, while Euler gives me 60. (so it should not entirely be my crappy pc).

cheers
Arne

:: JOODE :: Xith3d :: OdeJava ::
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #26 - Posted 2007-05-03 11:58:00 »

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.
Offline arne

Senior Member




money is the worst drug- we should not let it rule


« Reply #27 - Posted 2007-05-03 15:56:17 »

somehow friction now got totally lost...

:: JOODE :: Xith3d :: OdeJava ::
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #28 - Posted 2007-05-03 17:42:43 »

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.
Offline t_larkworthy

Senior Member


Medals: 1
Projects: 1


Google App Engine Rocks!


« Reply #29 - Posted 2007-05-03 21:54:28 »

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.
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

CopyableCougar4 (18 views)
2014-08-22 19:31:30

atombrot (28 views)
2014-08-19 09:29:53

Tekkerue (25 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (15 views)
2014-08-16 06:20:21

Tekkerue (22 views)
2014-08-16 06:12:11

Rayexar (63 views)
2014-08-11 02:49:23

BurntPizza (39 views)
2014-08-09 21:09:32

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (38 views)
2014-08-06 19:49:38
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!