Problems with ODE to jME bindings

Hi all,



first let me say: Cool Stuff you already developed. I started using jME just a few days ago and I am impressed by the performance and the bunch of features it already contains.



When I discovered the ODE to jME binding and thought it to be the glue for a tiny racing game (just for fun). So I setup a small model using cylinders for the wheels lines for the axis and hinge and put there some steering elements. This was done very fast due to the simple API jME is providing.



Then I attached the physics model to the raw model and was very disappointed of the result. At least the objects were falling down, but no collisions, no bouncing back, nothing else. Even worse the model did not even look like without physics (rotation of the cylinders were removed again).



Next step for me was to apply model bounds to all objects and tried using the bounds for the physics model. The result was an exception in PhysicsWorld.



What to do? I started looking at the code and found out that the ODE jME binding is a little lazy when handling model bounds. The error causing the exception was solved quickly: wrong objects are passed to the create methods, so the geometries get casted to the ModelBound geometry. This fails if not by accident the bounding geometry matches the objects geometry. But this only removed the exception, the physics still did not work.



Next problem I found is that at some points the name of the BoundingObject is passed to the OdeJava API, which is NULL in most cases. This makes OdeJava resolving wrong objects, since all objects get the same name. I fixed this as well, but the physics still did not work.



Next thing was to update the binding to the latest version of OdeJava, which I retrieved from CVS. There are only few things to adjust - some vectors and quaternions had to be replaced by float arrays. This did not have any effect on my application.



After striving through the code of the ODE jME binding classes I found some smaller errors, where code was duplicated or missing. I also found the bugs posted by DarkProphet regarding the initial translation of spheres and boxes and fixed them. But still the physics model is not working.



Meanwhile I have build a very small application giving me results for some behaviours I do not understand. I also have put some debugging logs to the physics binding to see what is really going on. From this point I can see that at least the application is recognizing all collisions/contacts. But still the result is very poor.



Now I am at a point where I am not sure how to continue. Against all odds ODE seems to me a quite stable, good working physics engine. I do not see a real alternative engine, which is working on all major plattforms and is free for commercial use. Developing a new physics engine is far out of my time scope (and knowledge scope as well) - so I better spent some time on helping improving ODE.



The most concerns I have are around the ODE jME binding. In a short time I have found several bugs which make me think about its status. And overmore I do not like the design. Why do I have to create a PhysicsObject, which gets attached to the PhysicsWorld, and have to add it to the PhysicsWorld again?



I think DarkProphet and Per are the both guys who have written the current binding implementation. Please do not get the impression that I am saying all you have written is not working. You have a lot of good ideas and put some worthy time in developing this code. If you did not put this code here I never would have thought of the idea of using a physics engine for playing around with game development. But for the moment I am thinking about rewriting the ODE jME binding.



I would like to take some of your code as a basis for a new attempt. I would also like to put this in a project at sourceforge or somewhere else, so everyone gets access to the development process. Sorrowly my free time for working on a projects like this is very few, so I do not know if I really have the time to do all this work. Maybe you also can convince me to get on with your solution as well.



First of all I would like to know if there is a serious interest for getting a binding to ODE working, so it can be used for a full fledged game. Otherwise I will stay in my chamber and just play around with it. Your feedback is welcome.



Regards,

Harald

There definitely is major interest in having a pro class jme-ode binding !

That said let’s see what DP and Per have to say about Your shameless accusions :wink:



welcome

Martin

Hi Harald,



The jME ODE binding is not a core component of jME but it is very popular (even as young as it is) and we definitely all have an interest in seeing it mature properly.



That said, I would suggest posting up your small test app so that at least DP and Per can see the problems you mention. Perhaps there are certain assumptions that need to be made when working with the binding that are not well documented. I personally have not used it so I won’t be much help, but if I were them, I’d want to see the accusing app. :slight_smile:



Secondly, both DP and Per are gracious enough in my experience to welcome any help on improving their code. In the demos that I have seen, it seems to work fairly well, so perhaps a complete rewrite is unnecessary and you could instead spend what free time you have to offer in cleaning up the sections that need it.



Anyhow, my 2 cents. Welcome to jME. :slight_smile:

I’ve uploaded my modified version of the jME ODE binding to this url:

http://www.hdietrich.net/downloads/physicsSystem-mod-050225.jar

I just have missed to write comments to the changes I have applied.



Harald

I have just updated to the latest version of jME and OdeJava and it looks like they have solved at least two of the problems I had. First, in the sample application I have posted the second cylinder is bouncing from the static box. And second, the model in my application now gets displayed in the right way - no obscure rotations anymore. That really great! If the bugfixing continous with this speed I expect everything to be working in two days :wink:

Thanks for pointing the bugs out ByteCount, we really apperciate it. If you still feel that this binding doesn’t work for you then by all means create another one. I can’t stop you, neither can anyone else here…



Me and Per are creating a java.net account shortly with CVS access, so you will get to fix as many bugs as possible!



Having said that, there is still a problem with the first plane and the cylinders, they go straight through. Its definetly an ODE limitation, because why would the box collide and not the sphere?



Anyway, you will have a good solid working solution within your 2 days :slight_smile:



Edit, it seems to be that there is no solution to the cylinder problem, its an ODE limitation, we’l find a way to work around it, dont worry.



DP

You do not have to appologize for the problems. I am a software developer as well and know about this problems. Overmore I have to appologize for not reading all forum entries. I did not realize that you are heavily working on this binding. ://



I really did want to offend you and your work with my posting. I have run the test with your latest .jar and its working. But - without wanting to tease you again - it is due to changes in OdeJava. The test is behaving the same way if I update the current source to latest OdeJava sources.




And overmore I do not like the design. Why do I have to create a PhysicsObject, which gets attached to the PhysicsWorld, and have to add it to the PhysicsWorld again?


Can you please elaborate more on this comment? You dont need to do that, thats an internal working of it, its so that correct bodies can be made with as little fuss as possible and without showing any actual ODE stuff to the user. And if you had read the javadocs, you would have realised this.


I agree with you that hiding the ODE stuff from jME is absolutely necessary. But the use of PhysicsObject is strongly related to PhysicsWorld and vice versa. Why do I need to handle the Placeable and all this stuff in the constructor of the PhysicsObject instead of putting this in the addObject method in the PhysicsWorld. I would like to see the PhysicsWorld as a general container for handling the ODE related stuff, whereas PhysicsObject is just a binding of jME objects to the ODE related objects.

But at the moment I am talking about the current public source files. So I do not know how far you work did proceed. BTW When will be the new sources available? ;)

I would like to improve the physics features to be used with jME and if you accept some help I would like to help you get it on.

Harald

What do you mean updating to a new Odejava? We kinda have a modified version of that inside our physicssystem if you haven’t noticed. The modified version removes all dependancy on Log4j and vecmath and replaces em with their jME equivilants.



And if you set the classpath to use Odejava (ie not the modified one) you will get alot of errors…



DP


If you still feel that this binding doesn't work for you then by all means create another one. I can't stop you, neither can anyone else here...


OK, I have realized that you are working on this and are putting a lot of effort into this. I never meant to demonize your work. I just have detected some flaws and want them to be removed. Would you appreciate some help in this way?


Me and Per are creating a java.net account shortly with CVS access, so you will get to fix as many bugs as possible!


Hey, that's great.


Having said that, there is still a problem with the first plane and the cylinders, they go straight through. Its definetly an ODE limitation, because why would the box collide and not the sphere?


That is my experience as well. I digged a little into the code of OdeJava and found that the contact is recognized and reported to ODE, but the response of ODE is missing. It might be related to the complicated handling of TriMesh collisions in ODE. I do not know if OdeJava is setting up this well.

Harald
"DarkProphet" wrote:
What do you mean updating to a new Odejava? We kinda have a modified version of that inside our physicssystem if you haven't noticed. The modified version removes all dependancy on Log4j and vecmath and replaces em with their jME equivilants.

And if you set the classpath to use Odejava (ie not the modified one) you will get alot of errors...

DP

I have noticed, but due to my problems I had I tried using this with a snapshot from OdeJava. I have removed all errors and compiled your sources against this. Thats the way I now can update to the current standings of OdeJava.

Do you really think its a good idea to have a modified version of OdeJava? You might have minimal improvements from vements by not having to translating the vectors and quaternions. How do you update to the latest version of OdeJava?

Harald

The changes to the odejava source is very small. This is mainly done to save space (i.e we shaved off almost 500Kb just by this improvement). The work is easy to do, it can be done in around 15 minutes for updating, so its not a biggie. Its also easier to modify crucial bugs when they are found, no need to wait for the people over at odejava to change cvs, we make a jar, redo the updating of vecmath/log4j and add it to the path…



I really did want to offend you and your work with my posting

Believe, me, its going to take alot more effort from your side to get me offended! Its not that easy... :)

Yes, I am working on this very hard at the moment, and we are in between releases, our next release is soon and is v0.4, so there are still alot of bugs lying around.

After the next release, we would appreciate some help in reporting and fixing bugs. The next release is going to introduce some very advanced stuff like ragdolls and vehicles...So any bug fixing and reporting is greatly appreciated.


Why do I need to handle the Placeable and all this stuff in the constructor of the PhysicsObject instead of putting this in the addObject method in the PhysicsWorld. I would like to see the PhysicsWorld as a general container for handling the ODE related stuff, whereas PhysicsObject is just a binding of jME objects to the ODE related objects

Ok, fair point. But how do you propose we do this without showing any ODE stuff to the user that they dont want to see and potentionally misuse... e.g like PhysicsWorld.getInstance().getODEWorld(); ?

I think the current design is very eligant and I am happy with it. The internal workings are clear, they do what they are supposed to do, and we dont have any duplicate code (not much anyway, if we do, its very insignificant...). It is also extendable, e.g for ragdoll support, no modifications were needed for PhysicsWorld...and im sure for vehicle support, no modifications would be needed there either...

As you can appreciate, this is a work in progress, and your findings are appreciated.

DP


Quote:

I really did want to offend you and your work with my posting


Believe, me, its going to take alot more effort from your side to get me offended! Its not that easy... Smile


OK, then let me put here the not as well ;) Sorry for this typo!!!

I am excited about your next release and am keen on having a look at the code.

Harald



[/b][/quote]

Yes, as stated above we are aiming for a java.net project. I filed in the request two days ago, so I guess it’ll take a few more until we hear from them. If it gets accepted, it’ll get a lot easier for you guys to commit your patches and staying up to date!



About your own work, we very much appreciate it - it’ll take a while until we’ve got all problems sorted out. More manpower is always wanted, and if you could make a list of what you’ve changed, I promise we’ll look into it. Also, there was no source included in that jar.



However, if you’re feeling there is something wrong with a such a fundemental part of the design as the world/object relationship, it sounds like a reason for you to start your own project. Because that one is here to stay.



PS: if you’re using a project with a version number far below 1, stability issues like these are pretty common. Be patient :slight_smile:



Thanks again for your effort.



Cheers!

I’ve played around a lot with jME, ODE, odejava and the jME to ODE bridge this weekend. And finally most of my tests are working. :smiley:



What is working:

  • collision of all kind of objects (solid -> solid, solid -> mesh, mesh -> mesh)
  • at some level the collisions in a complete scenegraph, where nodes are placed below the root node and translations/rotations is applied to them



    There were finally three things that made the code working. First you have to obey the orientation of the faces meshes. The reason is that handling of collisions is related to the orientation. As long as a collision is detected from behind the object no remarkable effect is applied to the other mesh.



    Second it is much more important to set the depth of a contact, than to set the surface thickness. The collision was only handled in the right way when I started to add set the contact depth to a value greater than 0.



    At last, if you synchronize the jME objects with the ODE objects you also have to take the translation and rotation of the parent objects into account, but I think you had mentioned this before as well.



    At the moment I still have problems with some more complex scenegraphs, where some of the collisions still seem not to be recognized. I will try to solve this problem as soon as I will have some time again.



    DP and Per: What is your status? You mentioned that your code has changed a lot since your last post. When will you put here the next version so I can see if I can contribute something to your code?



    I also would like to know what is your procedure regarding odejava integration? Do you want to keep a separate version of odejava or will there be a version with standard odejava again? For me I do not see an advantage of putting a modified version into the binding (at least not in the stage of development).



    Finally I got one more question: What is your overall goal with the jME to ODE bridge? Right now I am not quite sure anymore that it is the right way to hide ODE completely from jME. It looks to me that there are tons of features in ODE which allow finetuning of the behaviour. Will you try to hide them all from the jME developer or will there be a low level access to the ODE (odejava) structures as well?



    Harald

First you have to obey the orientation of the faces meshes. The reason is that handling of collisions is related to the orientation. As long as a collision is detected from behind the object no remarkable effect is applied to the other mesh


What do you mean by orientation of the faces? Do you mean their winding? because in jme and ode, there is no orientation (like 3ds max for instance)


Second it is much more important to set the depth of a contact, than to set the surface thickness. The collision was only handled in the right way when I started to add set the contact depth to a value greater than 0.


Those two variables are set by ode's collision detection and the force of contact is calculated by ode's physics simulation. Hence, you should never play with it as it will change your simulation. The depth of contact is very important....


At last, if you synchronize the jME objects with the ODE objects you also have to take the translation and rotation of the parent objects into account, but I think you had mentioned this before as well


Yes thats true. And I do realise the potential problems that will arise from it, we will be using world translation soon...


At the moment I still have problems with some more complex scenegraphs, where some of the collisions still seem not to be recognized. I will try to solve this problem as soon as I will have some time again


Thats due to the above mentioned local/world translation. We know of this, and we also know the fix...but we need the fix to be incoorported nicely and neatly into the design...soon!


What is your status? You mentioned that your code has changed a lot since your last post. When will you put here the next version so I can see if I can contribute something to your code?


Our status: developing! :D
We will release the code when we feel its done and ready. We have a clear cut definition and goal of where we want to go with this, im not sure everyone here knows about it, but this will be evident in future releases...


I also would like to know what is your procedure regarding odejava integration? Do you want to keep a separate version of odejava or will there be a version with standard odejava again? For me I do not see an advantage of putting a modified version into the binding (at least not in the stage of development).


This has already been answered before. We do this to provide a smaller download, and keep the source code closer to us. Fix things quickly...etc. Also getting rid of undue baggage (log4j and vecmath). As I said before, when odejava release a new version, it will take us about 15 minutes/30 minutes to bring our physics system up to speed.

Alot of people are using this for their games and such and them getting accustomed to the heavy libs and the logging formats of two very different loggers, then removing that way from them is not an option. So really, this isn't just in development, its also in use. :)

We feel that the upsides to putting the ode source and removing log4j and vecmath stuff is worth it (saving over 500Kb).


What is your overall goal with the jME to ODE bridge? Right now I am not quite sure anymore that it is the right way to hide ODE completely from jME. It looks to me that there are tons of features in ODE which allow finetuning of the behaviour. Will you try to hide them all from the jME developer or will there be a low level access to the ODE (odejava) structures as well?


Overall goal...it looks simple to me: Provide physics for jme.

As of 0.4, there is going to be a way to access low level ode Placeables (PhysicsObject.getPhysicsEntity() or similar (we haven't finished refactoring yet)).

However, it really seems that you dont like much of this design and its pretty much here to stay. So perhaps you should start your own? Alot of people are happy using this and do realise that this is only 0.3 so bugs and designs will change, nothing is set in concrete.

0.4 will hopefully answer most of your question and fix most of your bugs. Please be patient.

DP
"ByteCount" wrote:
DP and Per: What is your status? You mentioned that your code has changed a lot since your last post. When will you put here the next version so I can see if I can contribute something to your code?
DP, don't be so modest - we're working our asses off! :D

To be frank with you, we are on the very verge of releasing v0.4 - we're in the middle of cleaning up, and maybe it'll even include Vehicle support (it's not working perfectly atm, so it's mostly a question of releasing it as it is and fix it completely for v0.5, or to keep it out of v0.4 entirely).

As for how we keep us updated with odejava, it's easy work. This is sort of an guide on how to do it (I just wrapped it together from the changelogs, so I might have forgotten something):
1) Remove:
- org.odejava.display.
- org.odejava.test.
- org.odejava.xode.
- SimpleSpace - we are not using it.
- Body BODYID_ZERO from Body. Doc says it's depricated.
- Everything that has to do with AxisAngle4f. (have no jME-math counterpart, plus was just an optional way of setting/getting things)
- Redundant getters/setters in Placeable, PlaceableGeom and Body so you now only set and get position, rotation, torque etc through Vector3f's and Quaternions. No more AxisAngle4f, Matrix3f, float[]...

2) Replace math:
- Replace all references to javax.vecmath.Quat4f with com.jme.math.Quaternion.
- Replace all references to javax.vecmath.Vector3f to com.jme.math.Vector3f.

3) Replace the calls to log4j with calls to jME logging. There were only maybe five or six classes using it.


EDIT: sure enough I did forgot a few things...

Also, about the goals of the project, this website I put together for the java.net project request might be of interest for you.