Hehe, everything that you have mentioned is on my TODO list for 0.2!
PhysicsObject does not have a reference to the ODE Body object. Is there some reason for this?
We have a "Geom" Object which satisfies both Body and static trimeshes.
Currently updating the forces affecting a body has to be done though PhysicsSystem, which looks up the body object (based on it's name, so it also requires all objects to have unique names - which my game doesn't have at the moment).
Yup, i saw that ages ago too. When I implemented the system, we weren't supposed to have PhysicsObject. But that came about without full awarness of what needed to be in the PhysicsObject. So applying forces (e.g. like air resistance, and friction (althought that will be better under the ContactHandler)) will done in the physics object.
I'll probably make these changes locally to my copy of the code in any case, should I submit them somewhere if this design approach is acceptable?
As this project will not go into the jME CVS, i strongly advice you NOT to post it in the code review board. Simply PM me (or email me) and il check the changes, format, and add your name as one of the authors. My email is:
am_alhindawi (at) hotmail (dot) com
That is also my MSN handler, so you can add me in and we'l have a discussion about it if you want.
I tested them with the terrain test and simple test, and both worked ok.
I did some extensive cleanup for PhysicsSystem.java, there was lots of duplicated code which I refactored into methods, as well as something that looked like a bug (using the elements of a quaternion to directly initialize an axis angle object).
I added setTorque and setForce to PhysicsObject, but the number of delegated accessor methods seems to grow quite large if we add ones for all the potentially interesting properties of Body, so I just added a public getter for the Body object contained in the PhysicsObject.
So applying forces (e.g. like air resistance, and friction (althought that will be better under the ContactHandler)) will done in the physics object.
That sounds great! Air resistance is something most users will want, and it's not directly supported by ODE (IIRC, the way to do it is to apply a force inversely proportional to the velocity vector of the object?).
If we wanted to get fancy, we could let the user specify air resistance for e.g. the 6 cardinal directions that the object can travel in, and then interpolate between them for intermediate directions. Could be neat for things like airplanes, but perhaps it's too specialized for a generic library, and too simple for a flight simulation.
As this project will not go into the jME CVS, i strongly advice you NOT to post it in the code review board
Still, it could be nice to use some CVS, so it would be easier for many people to contribute to the project. Is there some CVS space that could be used for jME add-on libraries?
On an unrelated note, I seem to get stack overflows from the JVM if I add a lot of objects to the physics system. This happened with plain javaode also (there the boundary was something like 1000 objects, with the PhysicsSystem and the test terrain it's closer to 100). Any ideas what the reason for this could be?
I’ve just glanced through your code, but it looks good. Now that PhysicsObject stores a reference to the body, the applyForce methods in PhysicsSystem are redundant.
Made addObject throw an IllegalArgumentException if the type of object is not supported, instead of returning a boolean - NOTE: This may break existing code!
Fixed a bug where removing a PhysicsObject didn’t remove the entries for it from the hashmap.
Deprecated the ApplyForce methods
Removed further duplication from addTriMesh
Added clear programmer readable error messages that explain why some type of object could not be added to the physics system.
Changed from name to instance based lookups from ODE Geos to PhysicsObjects (used for collisions). This got rid of the name based hash map completely.
I also made some modifications to PhysicsController (made it use the ODE object from the PhysicsObject, instead of looking it up by name from the PhysicsSystem instance)
About the air resistance, a first crack has already been made:
ContactHandler
It's done the bad way though, affecting the velocity directly - not dealing with any forces.
I think I read on some ODE related forums that that could result in unstabilities in the simulation. But we can fix it as we progress.
Btw, it seems friction and air resistance should be properties of the PhysicsObject too, and not passed to the ContactHandler in the constructor. Probably we want to put the bounce related parameters of collisions in the PhysicsObject too.
no, air resistance will be part of PhysicsObject, and Friction will be part of the ContactHandler because friction only occurs during contact.
I also have an idea of apporximating the air resistance and friction coefficients by the type of object it is. E.g. if it is a box (with a lenght of 5 and a width of 5) then we could apply a home made forumla whereby it would approximate the air resistance. And friction too.
Il look into the additions you have made and that 100 object limit (strange, i can have 300 and still be ok…)
You are correct about the friction, it would depend on both of the objects that are in contact.
Now I actually get a JVM error with more than 20 objects - even if I comment out the terrain from my game, and only add spheres.
I looked at the odejava forums, and there seemed to be some possible problems related to timing and method call ordering isues (although that thread is a bit old):
I’ll try to replicate the problem with a small test program that just uses javaode at some point, but for today I got enough of fighting with native code.
This is what I get in my game:
An unrecoverable stack overflow has occurred.
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
# EXCEPTION_STACK_OVERFLOW (0xc00000fd) at pc=0x0c303477, pid=3400, tid=896
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0-b64 mixed mode)
# Problematic frame:
# C [odejava.dll+0x53477]
#
I also got an EXCEPTION_ACCESS_VIOLATION errors at one point too, and once it completely froze windows xp after running for a while.
If you put in air resistance, can you put in a way to disable it? My game takes place in space witch has no air and I am thinking of using your engine.
Il be creating a binding to their very successful physics engine. Although its only on Windows… a linux port is meant to be planned…but heck, still better than ODE!
"NovodeX Physics SDK and NovodeX Rocket are licensed to you free of charge for non-commercial use. The licensing conditions come along with the installer."
That's bad :(
If users want to sell there games, they would have to pay a lot of bucks...
So I don't think it's a good idea to use novodex, although it's a powerful engine...
How would this work? You can’t have a difference between game play on different systems. IF thay would have the same afect then why not just use ode. If we want to use your code for a comirsol game then we will need the ability to remove all novodex code form the jar.
Just out of curiousity, PhysicsSystem.updateODEAccordingToGeometry’s geo parameter has a quaternion as its rotation right? Right now, the version that I have has the ODE setAxisAndAngle equal to the quaternion from geo. It’s an easy fix, if it hasn’t been done already.
As a side note, I’m wondering how I can set individual ‘bounciness’ properties for each PhysicsObject? I know it can be done but I’m not sure how to go about doing it.
ODE is too buggy for any one to use it. No frame rate independance. No trimesh-trimesh collisions. Some people are having trouble with -z coordinate collision detection.
Id rather give something else a try first, and Novodex was the first solution for me. But Tokumak seems pretty good.
btw, tokamak looks 10 times better than ODE. I just had a read through the docs and several tutorials. It actually surprisingly resembles our own PhysicsSystem! Can’t wait
Yeah, looked through all the tokamak demos - again. Looks very neat, but IMO the biggest issue with ODE is the frame rate thingy. Anyone knows if tokamak solves this?
