Added realistic physics engine for Xith3d (ODE)

Engines, Libraries and Tools Xith3D Forums
#1

I’ve made a physics demo using Xith3d, jME and OpenMind libraries. The real pearl here is Open Dynamics Engine (ODE). This engine is fantastic. Lot’s of features and it’s fast. The results that some people have done with it are truly amazing. Suites fine for making a game physics used in Max Payne (rigid human bodies) or for example an car game. You can define an ODE car by creating some cylinders (wheels) and boxes (chassis), then you create joints beetween chassis and wheels, after this you can start applying some rotational force into your wheels and see what happens :slight_smile: There exists lot’s of various parameters. Currently ODE java api is still a bit crude (made using swig), but it works very good. My xith3d demo source code is simple, but still great to see thanks to ODE.

I would like for Xith3d community to tell their opinion about physics and especially their interest to add ODE into Xith3d library section. ODE is easy to plug into Xith3d but perhaps Xith3d could consider also minor physics aspects as a part of it’s API?

The downside is that ODE is done with C++, so it’s another native library for every platform. However realisticly speaking, my opinion is that the goodsides are many times stronger. If there is an better alternative, please tell me. And the actual programmer still works with Java only, that’s what counts. One cannot truly ignore native code in any case, even Xith3d currently contains several native libraries for various platforms. They are all precompiled and hidden from the programmer, so in my opinion it’s a good tradeoff.

Be sure to check out http://q12.org/ode/
And for the quick and impatient, here’s two easy to install windows exe’s that shows you what ODE is capable of: http://jet.ro/dismount/
These demos use rigid bodies, ode is much more also.

#2

Hello,

There is definitely an interest to add support for ODE to Xith3D. I personally was thinking how to integrate ODE to Xith3D, so if you made a demo, can you please post a link where others can download and test it?

Anyway, we should think about possible ways of integration of physics angines into Xith3D.

Yuri

#3

Good to hear, I will post a link containing physics Xith3d demo in a day or two. Sorry to tell this, but this first demo will have only windows dll (ode4java.dll) as my home machine has Windows XP only. I’ll add also all the source code on the same package.

Anyone who can compile standard ODE can get ode4java.xx also, building ode4java is quite simple. If ode4java get’s more interest I’ll compile linux .so library also as most of the java people do not want to fiddle with native libraries.

#4

I think in this case native libs are not a problem at all.

Another one concern is a license: ODE4Java is [L]GPL licensed, while Xith3D is BSD-licensed, and ODE can also be distributed/used under BSD license. So we should be careful with integration of ODE4Java into Xith3D core. There are also another efforts on ODE->Java bindings.

Yuri

#5

Will the addition of ODE to Xith3d be optional for Xith3d users?
I got the impression that Xith3d is a 3d engine, so non-3d-graphics additions should be optional, I think. Please correct me if I am wrong…

What makes things even more complicated is that ODE needs a native library, too. It’s already not very simple to feed my few friends with an up to date version of Jogl for their platform (Win32, Linux, …) just to run my small Xith3d project (Webstart isn’t an option.)

Please don’t misunderstand me: if it’s possible to combine Xith3d and a physics engine in a harmonic way so that it’s easy to use, that’s great.
However I think it would be very nice to do this optionally. :slight_smile:

#6

[quote]I think in this case native libs are not a problem at all.

Another one concern is a license: ODE4Java is [L]GPL licensed, while Xith3D is BSD-licensed, and ODE can also be distributed/used under BSD license. So we should be careful with integration of ODE4Java into Xith3D core. There are also another efforts on ODE->Java bindings.

Yuri
[/quote]
Yuri, I am not using ODE4Java (I think you are meaning project called odeforjava.sf.net?).

My ‘java bindings for ode’ library does not have even a name yet. I am planning to create new project into sourceforge in the next few days, perhaps as a name javaode.sf.net. I am a favor of BSD license myself, so this would be no problem for Xith, jME or Openmind (and more 3d libraries here) projects. This project is very simple, but works effectively.

And Preston, yes I agree, Physics engine should be a component that is definately not mandatory for using Xith. ode for Xith should be an optional component that Xith might (or not) support also from it’s API somehow.

So, does anyone have good name candidates for this project? Perhaps javaode.sourceforge.net could be the package name that hold java bindings to native ode library…

#7

Yuri, I tried to find java bindings for ode that worked, I checked also odeforjava.sf.net project, but this project seems ended (last update almost a year ago). It also seems to be quite unfinished, relevant places have no implementation. odeforjava is grasping the whole ODE project in a different way than I do. odeforjava is doing things more ‘java’ way, creating proper classes and java structures for all ODE related data. It’s nicer but also harder to construct (complex).

What I do, I use swig to wrap every meaningful ODE call to Java. This is a very simple approach and therefore it should be easy to create new javaode versions each time there is coming new ode version. I understand that this approach is not so ‘java’ styled, but it works (also effectively). Actually the API does not seem too bad, it’s almost one to one with ODE’s own API (C++).

My hopes are that someone releases a working ode bindings for java and people start contributing to the project. I haven’t found one, so I decided to start that kind of project myself. If someone knows a working open sourced java ode library (other than mine), please tell me.

#8

[quote]Yuri, I am not using ODE4Java (I think you are meaning project called odeforjava.sf.net?).
[/quote]
Cool, so I hope you also support bundings to OPCODE?
Anyway, I need support for physics in my projects bery much, so if you publish your code, I will start using it immediately.

[quote]I am planning to create new project into sourceforge in the next few days, perhaps as a name javaode.sf.net.
[/quote]
Why not at java.net? I see it as more suitable place for Java-related code. Also, Xith3D and Xith-tk are hosted there, so it would be cool to use the same tools for such projects, too.

[quote]I am a favor of BSD license myself, so this would be no problem for Xith, jME or Openmind (and more 3d libraries here) projects.
[/quote]
Great.

[quote]What I do, I use swig to wrap every meaningful ODE call to Java.
[/quote]
So, this means you are goung to choose technology similar to JOGL? They use GlueGen to automatically generate java and c bindings code. I think this is a best approach for java <-> native bindings, because of mirroring Java structures can be built afterwards.

[quote]If someone knows a working open sourced java ode library (other than mine), please tell me.
[/quote]
I do not know really WORKING and up-to-date bindings. Some were announced on Game Physics forum, but still seem to be unpublished.

[quote]I understand that this approach is not so ‘java’ styled, but it works (also effectively).
[/quote]
I think this approach is enough “java” to use it.

[quote]it’s almost one to one with ODE’s own API (C++).
[/quote]
… and this is very very good.

[quote]My hopes are that someone releases a working ode bindings for java and people start contributing to the project.
[/quote]
100% correct.

Yuri

#9

Yuri, my current build uses OPCODE and latest ODE straight from the CVS. It’s compiled single precision (floats). I haven’t added any of the contrib sections though. Can’t imagine that it would be a problem for anyone to compile own ode for some reason and after that run swig related command.

I will release this instantly after:
-I am up to start an project to sf.net or java.net
-do all the tasks related for BSD licensing
(source code is ready and waiting)…

Currently there exists one caveat, ODE’s nearCallback function is still working as C object. This might be the first thing to fix for the community. Perhaps odeforjava.sf.net could show a proper idea how to do this. You can do lot’s of things with the precompiled library (nearCallback defined by me), but it’s impossible to define e.g. frictions or bounce related parameters per object basis (currently all objects use same parameters). I am sure this is not a hard task to fix elegantly, but this currently is a problem with complex simulations. Summarum: basicly everything should work with java as in ODE (except that nearCallback function).

And yes, swig gives this everything very easily, so the project itself is simple (single swig interface file and two c files). The product is bunch of java files and single native javaode library.

#10

Looking forward to see the library!

Let me know if you need some help with Xith3D internals.

Yuri

#11

This is very interesting… I too suggest you host this at java.net alongside the other gaming APIs.

since this would be an optional component that you would use on top of Xith3d i would hope that it can be entirely independent of Xith3D and therefore useful in 2D or directly with JOGL/LWJGL as well. I have a simple game idea that doesn’t need the features of a scenegraph API, but I could use a good physics engine.

I have never heard of “swig” … I will have to look that one up.

It’s great to see these technologies opening the doors for Java game programmers. Get that project up on java.net so the community can get going on the Linux and Mac ports.

#12

How about JODE ;D

Will.

#13

I think this [addition of a realistic physics engine for Xith3d] is a great idea!

[quote]Will the addition of ODE to Xith3d be optional for Xith3d users?
I got the impression that Xith3d is a 3d engine, so non-3d-graphics additions should be optional, I think. Please correct me if I am wrong…

Please don’t misunderstand me: if it’s possible to combine Xith3d and a physics engine in a harmonic way so that it’s easy to use, that’s great.
However I think it would be very nice to do this optionally. :slight_smile:
[/quote]
Regarding the integration of a Physics engine with Xith3D - my thoughts reflect Preston comments.

I believe that Xith3D should not have an integrated Physics engine - but rather it should be easy to use the Physics engine of your choice (including none) with Xith3D. I feel Xith3D would be stronger if it concentrated on it primary goal, that is a game-orentated scene graph. I would rather not see the code get too bloated with the addition of every gaming-related-library-and-their-dog to cater for every perceviable need.

I think Xith3D-ready modules/plugins are a better solution. It means that people who want Physics support for Xith3D can have it in an instant, those who don’t want it don’t need to worry about it and as swpalmer said, it also works well for people who want a Physics engine but not Xith.

On the topic of ODE - I reakon the bindings would be awesome as a seperate java.net project (you’ve got my +1) as suggested earlier. Then a Xith3D-ODE module/plugin could be made as either a seperate project or as a tool in the xith-tk.

A physics engine for Xith3D would be increadible handy for the current project of mine so I am looking forward to seeing how this works out.

Will.

#14

The things related to this topic that I am planning to add to Xith3D is the following:

The ability to take any TransformGroup in the scenegraph and attach a collider, similar to how we attach an occluder. This collider would represent the node and all the nodes below it. Two colider implementations would be provided, one being a convex hull and the other being a spatial tree (like a bi-tree, bsp or oc). Like occluders it could be loaded or could be generated dynamically.

The next step would where a physics interface comes in. I know how I would do it if I was writing the one and only system for the product, but assuming that we want to have it usable by other systems here are some ideas.

The type of things I would want to do is associate physical properties with colliders like mass. Then we need to have a way to register the collider with the physics interface. perhaps this gives is back an interface which a game could use to then apply velocity, change boyancy, etc. The physics engine would be called in the game game loop to step the physics engine through time. The PE (physics engine) could manipulate the “objects” by adjusting their transform group and using their colliders to calculate collisions, rebounds, friction, etc.

The collider could be asked certain questions. Like, if I changed your transform to this, would you intersect any other colliders in the world? The point of intersection and the normal could be be returned. The PE could then adjust the transforms of moving objects impacting other moving objects and stationary objects.

The nice thing about this is that something as complex as a level of a dungeon (not counting objects in the dungeon) would be a single collider, with its BSP tree able to answer the questions to the PE.

Collision detection, sliding along walls, sinking in water, floating in air are al things I have to do for Magicosm in the next month, so we need to firm up the interfaces so that we dont end up with incompatible systems.

I would provide the default reference implmentaiton of the pure java PE, good enough to support objects moving with mass and velocity colliding with other objects (with callbacks), basically the bare bones of a PE. I would not expect to do something as nice as ODE and provide springs and tension and complex resolution of multiple impacting objects (use a simpler method which should still look good).

Thoughts?

#15

My only thought is that you should make sure to allow for not just transforms coming out of the physics code, but actual point position changes. This is important for physics systems that work on particle systems, such as one of my personal interests, the Jakobsen soft-body system.

#16

I’ve created javaode.dev.java.net project. Yes I know the project name is a bit dull, but it get’s you right to the point. License is BSD. Project topic is Games, this was the only topic that was suitable in my opinion. Now I am waiting for the Sun people to approve my project.

Let’s hope this brings new light for using ODE in Java. And sums up as a pluggable module for various 3d renderers.

BTW There already exists project(s) called Jode.

#17

From what I have seen of ODE, there is no reason why it shouldn’t been ported to Java, i.e. no Java wrappers but pure Java code. And even what haven’t seen it should still pure Java :slight_smile:

The ODE community is fairly active but no talk of Java (except for a few bindings posts in September)

I am seriously looking at starting a porting group for ODE to Java for a GDC demo.
When I post our engine in Dec we’ll decide for sure.

I have not looked at the source, I have for several other phyiscs systems; does ODE have some C/C++ tricks/problems that would be a reason porting would be problematic over using wrappers?

#18

I agree with shawn, it should be possible to port ODE in Java if the source code is available in C++.
No need to add a platform dependant part to Xith3D… after all, a PE is not dependent on platform, it’s just Math. Shouldn’t be a problem. :wink:

DZ

#19

A porting project for ODE is something I can work with the Xith3D folks on, and both our engines could use it.
This is also one way to make sure that utils/etc are clean and without dependancies to other engines.

#20

[quote]From what I have seen of ODE, there is no reason why it shouldn’t been ported to Java, i.e. no Java wrappers but pure Java code.
[/quote]
That would be the best thing: a pure Java physics engine, plugin-able to Xith3d and shawnkendall’s engine any other application/layer.

If Xith3d would stay 100% pure Java with just the JOGL binding (and the hope that JOGL will find its way in J2SE soon) I’d be happy. Probably I’m saying this repeately, but I don’t like native bindings at all. Having done native stuff for the last decades I’m a fan of the “keep Java apps clean” philosophy. :slight_smile: