joode performance

I decided to check back in on the progress of joode since my project is almost ready to begin using physics (ooh exciting!) and I ran the demos to see how well they performed. On average I was only getting between 30-60 fps depending on the test. When I was using odejava, I could easily get 200 objects at around 100 fps but now 20 objects crawls in comparison.

I’m wondering if this performance decrease is a temporary bug, something that everyone has experienced, or a throttling caused by joode’s coupling with xith.

As a side note, you have an incorrect svn access listed on one of your pages:

The correct one to use is:
svn co https://joode.svn.sourceforge.net/svnroot/joode joode, which can be found http://sourceforge.net/svn/?group_id=151965
but on the page: http://joode.sourceforge.net/download.html, it still says to use:
svn co https://svn.sourceforge.net/svnroot/joode joode

Is joode dead? Where are the developers with the generally timely responses?

At least some of them can be found on xith.org, I believe.

JOODE is asleep (from my perspective) while I write the “other” bits of code relating to my work. Expect a reserection at some point over 2008, but for now I can’t really work on two big libraries.

Tom

Good to know, since it’s asleep, what else has to be done before you’d call it a finished project?

  1. Well there is a problem that a ball rolled along the ground when it touches a wall it will become stuck. The two contacts iteract incorrectly (a well known ODE effect for some of its params, see box friction vs cone friction). This has its roots in that our LCP is not sophisticated enough to handle friction properly, i.e. the maximum tangital effect of friction is proportional to the downward force on an object. The work around is a low coeffecient of restitution.

  2. I think our intergrator is not working properly. I have had 4 stabs at recoding it but I can’t seem to get what it computes to relate to the physics equatons. I simply don’t understand what it does at the moment, but when i code it the way I think it should work the system blows up. This is the biggest hole in my opinion. I would ideally like a range of intergration options available for different accuracies.

  3. trimesh collisions. I don’t see this as too important, spheres and boxes work lovely.

  4. I think the scalability of JOODE is limited by our range of spatial partitioning algorithms. We have a psuedo octree but a proper octree would be nice. I think a frame coherance system would also be easy to implement and would perform well in most situaions (low hanging fruit I reckon).

  5. serialization.

I guess, the solution for trimeshes is pretty simple. I wanted to fix that on my own, but never found the time to do so. The problem for trimeshes (that I see) is, that the algorithm doesn’t care about the vertex winding. When the winding makes the algorithm think, that impacting collider is coming from direction V, but the actual direction is -V, it can be detected pretty simply. Well, I don’t know the way to do this, which I had in mind, but you may get it. It was something about normal/penetration angle.

I guess, you’re talking about something like we have in XPAL. There’s a max-step-size setting, that allows for precise collision detection, while the “outer” step-size is frame-time dependent. The step size must be frame dependent to make the simulation run just as fast as it would do in reality. And the max-step-size must be used to guarantee a sufficient amount of preciseness.

One other serious task to be handled is the bounciness of simulation objects. There doesn’t seem to be a way to adjust bounciness (the “bounce” parameter has no effect). The way it is now makes the bodies gain energy from a collision, while it should actually loose energy with the collision and either don’t bounce at all or bounce only slightly, just as you would expect it in reality. Think of a wooden box crashing on the ground (without getting broken). It would not bounce (especially not higher than it came from), but just slide and roll over its edges.

If this is possible with the current JOODE, I would appreciate a testcase very much.

Marvin

Ah, I think, I remember the idea to solve the trimesh collision direction problem. You can calculate the face normal for the colliding triangle. And if the angle between the face-normal and the collision direction is >90°, the collision direction has to be inverted. That should perfectly do the trick. And it is not too expensive, since the calculation would only have to be done in case of a collision and for only one triangle.

Marvin

I’m pretty sure the bounciness (the part where it bounces even higher) is a known problem with ODE. I remember reading something about the way they solved some of their equations for this situation that doesn’t respect momentum and adds energy to the system.

Since joode is taking a nap, I’ve had this horribly (and potentially wonderful) idea to port bullet since it seems to work very well and consistently according to the web. If there are any specific reasons why this is illegal (pretty sure it’s not since it’s open source) or if it’s been tried and failed for some good reason, I’d like to know before I start.

Yeah go for it. I really like some of the features of bullet, esp. the collision system.

The frame coherance system I was talking about was for the broad phase collision sweep (from wikipedia):-

As JOODE is an axis aligned system this would work well with our current code base

Sounds really interesting? Do you plan to actually port it to Java or just use a JNI wrapper? Which math lib do you plan to use? May I kindly suggest to use OpenMaLi’s vecmth2? :slight_smile:

Sounds interesting, too :).

Marvin

I would do an actual port to java. I’m not a fan of swig (as may have been obvious from previous posts :)) and don’t like messing around with command-line tools all that much. From looking at bullet’s source code, they made it very modularized which should help the porting.

I’ve been thinking of doing openmali’s since it’s the one for my homebuilt graphics engine. What are the benefits of vecmath2?

Also, the porting may go slowly and be a while before anything is available that I’m happy enough with to show the world (college and all that is a drain on time).

Benefits over other math libs or over vecmath1? Well, the reason, why I created vecmath2 was, that I never liked the way sun implemented vecmath with all those public fields. I like to have setters and getters (which are inlined by the JIT compiler) to have real control over what to do when a value is changed. This way you can track changes in a vecmath2 object. One general benefit is, that you can always ask me to do changes or add featuers (or do it yourself), which you cannot do with most other math libs. Another benefit may be subjective. Bit I believe vecmath2 has a very nice interface, which makes it a lot easier to code with.

Marvin

have you done performance tests comparing vecmath2 and vecmath1 (openmali.vecmath not javax.vecmath released with java3d)?

Yes. And they are about equally fast. It depended a little on my computer’s mood, if the one lib was faster or the other, but the difference wasn’t big.

Marvin