I wish to add multi-geom support to the API and have been discussing it with Jani over the last week. I thought I would move the discussion here When I looked into this I have thought up a few improvements to the API as well.

Here's a few things I think should be changed:

#1Geom has a set/getBody methods - I think these should just be dropped as otherwise you can have this situation:

1 2 3 4 5 6

Geomg = newGeom ();Bodyb1 = newBody (world);Bodyb2 = newBody (world);

b1.setGeom(g);g.setBody(b2)

which is very misleading (in actual fact - the setBody in this context means zip).

#2Body needs to be expanded to support multiple Geom's. This is fairly easy, we would just have a linked list of Geoms instead of one.

"setGeom" would be changed to "addGeom" - and Iterator getGeomIterator() would replace getGeom. set/getGeom could be retrofitted to simply add a Geom to the list - and return the first Geom in the list.

If you don't like them they can easily be reversed. Note: Everything is backward compatable - the old demo's work fine unmodified.

Basically the changes are these:* Avoid using set/getBody on Geom.* Use World to manage your Bodies instead of Space (all Bodies are added to the master Body list in their world on creation). This was changed to bring Odejava more inline with ODE regarding World and Body, Space and Geom.* Use Space.addBodyGeoms(Body) instead of Space.add(Body) when you use point 2.* You can now add multiple geoms to a body.

So long as these changes are ok - I'll convert the demos (very easy to convert I just want to make sure the changes are ok first).

I apologise for several recent API changes, I hope I am not out of line. I am just trying to correct some problems that I see and add support for new features before we have too much legacy code to make it a real pain

These changes sound good, any API changes we can make that direct people on how and where to use Geoms versus Bodies is going to really help people understand things better. I'll have more concrete feedback once I work with the changes directly (which usually results in a couple rapid fire posts like last time )

Everything in the API is now uptodate and inline with all my changes *phew*.

Both odejava and odejava-xith3d can be compiled with no deprecation warnings - so if you are getting them it is probably in your code. I am happy to help anyone who is getting these warnings in converting their code if they don't understand what I have said and can't do the changes by looking at the official Odejava examples. Email me or post in these forums if you need some help.

The only thing I ended up doing differently is that I have kept the setBody and getBody methods of Geom. This is because ODE clearly has those methods and we want Odejava to be similar to ODE for compatability of the docs.

But what I did do is add a bunch of javadoc comments and asserts to warn and prevent people trying to give a Geom two parents (as this is not possible in ODE - but it was previously possible for the situation to exist in Odejava, even though in actual fact only the most recently set parent Body would have any affect).

It is still possible to give a Geom two parents if you are very sneaky but I have prevented the obvious cases - and warned about the sneaky ones in the javadocs.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org