How do you attach a joint to a body and to the zero body?
For example, in the low-level api you would use Ode.dJointAttach(myJointId, myBodyId, Ode.getBODYID_ZERO()). However, the Joint classes don’t have a getId() method, and there is no high-level equivalent for Ode.getBODYID_ZERO() to be able to use the high-level myJoint.attach(myBody1, myBody2).
[quote] there is no high-level equivalent for Ode.getBODYID_ZERO() to be able to use the high-level myJoint.attach(myBody1, myBody2).
[/quote]
There is now 
update from CVS - and checkout the Body.BODYID_ZERO constant. It’s constructed with the single line:
bodyId = Ode.getBODYID_ZERO();
I hope that works, I don’t have a test case to try it with
Will.
Thanks, I’ve updated my java with the latest CVS (was using the downloaded 0.3 snapshot before). The static BODYID_ZERO works perfectly.
P.S. This is a little off topic, but is related to zero bodies. Why is the native address updating in Geom’s “protected void updateNativeAddr()” method commented out? I use getNativeAddr() to be able to identify with which geoms a particular contact occurs. I have to uncomment the line and recompile for it to work properly. Is there a better way of figuring out the precise geoms of a contact than using myContact.getGeomID1() with myGeom.getNativeAddr()? Note: Some of the geom’s I use are static and don’t have body’s with which to use myContact.getBodyID1() etc.
No probs. I think it was commented out when it was causing some problems - you are right, it shouldn’t be commented out. I’ll look into it tonight.
I don’t think there’s a better way to get the Geoms of a contact at the moment, that code needs an overhaul. How do you think it should be done? Maybe we could change it so the methods return GeomS instead of ID’s. Idealy we don’t want to have to know about ID’s and native addresses in the high-level API.
Will.
Returning Geoms instead of geomIds would, i think, be the best quick fix, which would probably require a hashmap. I’ve implemented contacts in my project but have not really needed them yet (just testing other joints and bodies for the moment). When I start fully using contacts I’ll send some suggestions if there is room for improvement in the API (such as creating a JointContact class etc)
Note: I’m using odejava for research, not a gaming. Some solutions or suggestions that I give may not scale well if you need real-time, as opposed to simulation where it is sufficient for say 10 minutes of simulation time to be computed over a couple of hours. However, I will try to keep in mind the gaming application of odejava.
maybe things like Geoms and Body classes should have static hashmaps which have the map between ids and objects inside them. An entry is put in at creation time and removed when the object is delete()d.
This could be extended to worlds as well when multiple worlds are done.