How fast is joode currently? and how stable?
I’m interested in doing physics with, hopefully, a maximum of 1000 bodies. Is that possible yet with joode (or another engine for that matter)? or am I being a little too wishful?
If it can’t get a 1000 bodies, what’s the best that anyone with experience has achieved with good framerates.
I don’t know about existing API or Framework that include a good CacheResourceManager as meant for a game. You should think about building one for your own.
I’ve been working on that feature for past half a year and now that seems more convenient to load resources (about 2000+ objects in cache)… ;D
This isn’t about loading resources or anything like that. 1000 objects isn’t going to be that memory intensive either. The question was about speed and accuracy stability regarding th joode library, not memory or loading.
That’s right, I load the resources and then I can have a stable Thread to paint and do what I need. That 's always more accurate to have everything loaded in RAM or disk cache before to begin rendering.
Plus I’ve looked at JOODE if it could be better than building my own framework, but that was hopeless… external API or framework are always different concepts to adapt to my own concepting and patterns. 
PS: JOODE is still at an atomical stage of development. So I implemented my own physics for the game I’m building today…
Well then broumbroum, if you think that your physics provides a different enough approach to concept and patterning, then you should release it. The point of using joode is that I don’t have to spend the time working on it and optimizing it. All I need to do is tell the world to step and to collide after adding all the bodies, that doesn’t seem like a pretty hard pattern to follow or squeeze in anyware.
To t_larkworthy (or anyone in joode), how many bodies and geoms have you successfully run physics simulations with in your trials and development?
Hi
I’m not quite sure how many bodies Tom was able to have in joode, he once mentioned something like that though (even in this forum, so do a search). But non the less I think joode will be able to do 1000.
But also the kind of Geoms in the Bodies is important, what are you trying to collide? TriMeshes for example are extremely costly, while spheres really go fast. But that shouldn’t be the main issue, more important: There aren’t yet all types off Collisions implemented yet!
You’ll be able to collide all types of Basic Geoms with each other, those are:
also 2D is possible:
If you need TriMeshes, joode might not be an option for you, because TriMeshes can only collide with Box, Sphere and other TriMeshes yet.
I also don’t know how well the GeomTransform works ( so you’ll be able to create complex geoms out of simpler ones ). And Cylinder doesn’t collide yet with anything.
Bevore you try implementing your own physics engine (that’ll be damn hard) , it’s probably much easier to code the needed Colliders (that’s not very easy either, but non the easier than coding the whole thing, I think 
)
I hope joode is still useable for you 
cheers, Arne
PS: I don’t know what broumbroum is talking about, physics has nothing to do with applying textures to bodies and so on. Joode is completely seperated to any 3D engine. It will be easiest to use joode with Xith3D, because there already exist many helper classes for that.
PPS: As an alternative physics engine, there is also ODEJava, which uses ODE via JNI. In joode we “simply” ported ode to java to get rid of that jni and make it pure java.
I used odejava before and found in unsatisfactory because many of its methods were broken and caused crashes.
I plan on using capsules mostly and maybe sphere’s or boxes. Eventually I would like to also implement a heighmap collider, so if anything ever comes of it I’ll let you guys know.
that was one of the main reasons, why we created joode
With boxes, Spheres and Boxes you’ll be fine indeed.
You’re welcome to contribute your heightmap collider, when you’re finished
cheers,
Arne
The main slowdown in JOODE is the number of bodies connected together with joints. 1000 individual bodies should be no problem as long as they are not conencted together with hinges or something. (tip: spherical masses are even faster if applicable)
That’s great, with odejava I was only able to get about 250 unjointed bodies before weird things happening (explosions, untraceable stack overflows, etc).
In my tests the performance of ODE (or ODEJava) is still by far better than JOODE’s: Simulating 3000 boxes falling to the ground is possible (if you configure it well - auto disable, bounciness, etc.) with ODEJava-jni (recent ODE). JOODE cannot handle more than a couple of collision in the same step, currently (first very slow, later crashes). I have not found an auto disable feature or other means to improve the performance.
With jME Physics 2 you can switch between ODEJava and JOODE (probably needs an update, though) at runtime. If you’ve got the time, check out the tests (esp. stress and domino) with the different implementations.
Hmmm. Dunno when you ran that test but I will have a look when I get time. We don’t really have a stress test but we should do.
Where are you getting this new release of Odejava? To my knowledge the site has been dead for a long time. Is it through jME? because I haven’t tried looking there for anything yet.
I reorganized Odejava a little and separated the jni part into a new module named odejava-jni (in CVS). It can use a recent (maybe current) ODE snapshot/release. The rest of odejava was adapted to the new jni part in a branch (with-odejava-jni).