mmh read further on in the article.
this is not true for dynamic friction:
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.
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
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 
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.
Hey, good work, Tom !!!
Euler now seems to run very stable. I wasn’t able to find any explosion like behavior yet. 
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
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.
somehow friction now got totally lost…
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.
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!
@Tom: I’m really highly impressed of how much work and effort you put into the project these days. Thank you very much for that. I wish, I had the time to play around with physics a little more.
Hey, don’t you want to ask Kevin or Chris, if you could get Moderator rights in this forum? then you could split this thread, since it has become a little off topic ;).
Marvin
yeah - Eulerstepper seems to run very well with it 
great work - I think Joode is now finally in a state, which we could really call useable - It’s damn time for me to create a first version of the Joode tutorial 
About this mu-thingi: I think for most simulation it is ok to have non mu-friction, but It’ll be a nice thing to have.
cheers,
Arne
Nah, I want mu friction. If you put the surface parameter “mu” to infinite, the objects get stuck in each other. Its a well documented behaviour ODE suffers from (but they have the solution, I want it too!).
Cheers for the support guys.
PS I don’t want moderator rights, I have enough work to do as it is!
I think it’s time to get this thread “on topic” again
I’ve committed the first version of the documentation into the svn. You can find it in doc/joode-intro. How can we also put it on our Joode-webpage, so newbies won’t have to hassle with svn?
btw. I don’t like the title of the document I’ve created very much yet. So I’m open for renamings Actually I’m not yet quite sure, what we want to put inside it, too.
I’ll be away till next thursday, so don’t expect me to answer till then
cheers,
Arne
PS: And yes - Joints are yet missing in the document.
OK, I’m currently reading your document. And I will write about my floating impressions…
- Doesn’t JOODE mean “Java Object-Oriented ODE” .> “Java Object-Oriented Open Dynamics Engine”?
- Weren’t ODEJava’s problems with native libs solved recently?
- Gravitation -> Gravity
- Triangle Mesh (list entry) should be annotated with the postfix “(TriMesh)”, since this Word will be found in most documentations (and should be used in this doc).
- I would not write, that ODEJava should be faster than JOODE, because it uses native libs. Java can be faster than C(++) even for number cruncher code (Java isn’t that bad ;)). So ODEJava might be slower just because it has to handle the JNI overhead. But, yes, benchmarks are to do :).
- In the very first example you should move line #32 between lines #38 and #38 (and #43 after it), since the canvas is needed first there and if errors occurr while scene setup, OpenGL would not yet have been initialized and would not be hard-destroyed. This is not the best thing for finished games, but the best for testing.
- The step() method should be called like this:
@Override
protected void prepareNextFrame(long gameTime, long frameTime)
{
super.prepareNextFrame( gameTime, frameTime );
w.step( frameTime * 1000L );
}
Well, maybe we should provide the frameTime in nano seconds in xith.
- I guess, your addGeom() method should take a NodeGroup instead of a BranchGroup. A BranchGroup is solely for the root of the scene (a RenderPass). And I guess, you want to add the Geom to any place in the scenegraph.
- You should use a Monospace Font for the code examples. I think, it would be good to use a background color for the code blocks like in XIN.
- EDIT: The RenderLoop method prepareNextFrame() is meant to be used aith the super call as the first one. The renderNextFrame() method should have the super call as the last one. Thsi should be used like this in the documentation. It is not always used in the JOODE test in SVN. Maybe this should also be changed, if it wasn’t made by intent, was it?
After all it is a good beginning of a great documentation. I finally begin to understand, how JOODE works ;). Keep it up :).
Marvin
I’ve changed Xith appropriately and compiled and added new xith jars to the JOODE SVN trunk. Now you can simply call
renderLoop.setTimingMode( TimingMode.MICROSECONDS );
Then the frameTime will be passed in microseconds to these methods. And then you can simply call
@Override
protected void prepareNextFrame(long gameTime, long frameTime)
{
super.prepareNextFrame( gameTime, frameTime );
w.step( frameTime );
}
Should be a useful improvement for JOODE, isn’t it :)?
Marvin
Sorry. Have been sick this week. I will get my comments on documentation etc. as soon as I can.
nope, then it would have been JOOODE
dunno - it’s ugly anyways
done
you’ve got a point - done
changed the should to might
I don’t understand you here. How can I move something between one line. And what am I supposed to do with line 43 ???
I didn’t made those frameTime dependent step sizes, because for now I prefer a stable simulation - jumps can have strange effects in physics simulation
mmh - yeah, but I won’t change that now, because than I would also have to change that XithBinding stuff.
no - When latex gives me Java syntax highlighting, why not use it?
changed
thanks for the feedback
new version is in the svn now.
Arne
Please compare these two snippets and you will see, what I meant. (Of course two times #38 was my fault ;)).
public Example ( ) {
super ( 128 f ) ;
// first we’ll setup Xith (we want to show our results somehow , right ?)
Tuple3f eyePosition = new Vector3f( 10.0f, 10.0f, 5.0f );
Tuple3f viewFocus = new Vector3f( 0.0f, 0.0f, 0.0f );
Tuple3f vecUp = new Vector3f( 0.0f, 1.0f, 0.0f );
Xith3DEnvironment env = new Xith3DEnvironment( eyePosition, viewFocus, vecUp, this );
canvas = Canvas3DFactory.createWindowed( 800, 600, ”My empty scene” );
this. getInputManager().registerKeyboardAndMouse(canvas);
BranchGroup bg = new BranchGroup();
env.addPerspectiveBranch( bg );
env.addCanvas( canvas );
this.begin();
}
public Example ( ) {
super ( 128 f ) ;
// first we’ll setup Xith (we want to show our results somehow , right ?)
Tuple3f eyePosition = new Vector3f( 10.0f, 10.0f, 5.0f );
Tuple3f viewFocus = new Vector3f( 0.0f, 0.0f, 0.0f );
Tuple3f vecUp = new Vector3f( 0.0f, 1.0f, 0.0f );
Xith3DEnvironment env = new Xith3DEnvironment( eyePosition, viewFocus, vecUp, this );
this. getInputManager().registerKeyboardAndMouse(canvas);
BranchGroup bg = new BranchGroup();
env.addPerspectiveBranch( bg );
canvas = Canvas3DFactory.createWindowed( 800, 600, ”My empty scene” );
env.addCanvas( canvas );
this.begin();
}
You will see, that the Canvas3D is created after the scene has been set-up. So when there’s an unhandled exception in the scene set-up code and the app will crash, it doesn’t leave an uncleaned OpenGL context.
Of course when the app (game) is finished, there should not be any exception of this kind and you might want an OpenGL rendered loading screen or what ever. So you will need the Canvas from the beginnig on. But you might see my point.
OK, I understand. But I guess, there should be a comment in the code snippet or in the doc-text or where ever, that says, how it should be done in a real game (just as for the canvas thing).
Doesn’t it give Java syntax highlighting with an alternative font?
Any time :).
Just another thing to mention:
- The overridden onFPSCountIntervalHit() method should get a super call, since otherwise some other things won’t work.
Marvin
this won’t work, because
this. getInputManager().registerKeyboardAndMouse(canvas);
needs the canvas to be created already. But at that point it is still null. Or is that canvas argument not needed?
might also be the same in XIN
Arne