[ODE] First steps and collision management.
goncaloclopes at gmail.com
Sat Jan 13 14:42:26 MST 2007
Thank you very much for your feedback and for trying it out :) I'm
happy to finally see OdeNet be put to use. I'm sure I can improve it
to reach out to expectations. After all, I created it so it could be
both user intuitive, extra flexible and efficient.
Now on to some comments about the tickets you posted up.
First, you're right on every account when you say the getter/setter
behaviours are counter-intuitive. Alas, when I was designing the
wrapper I was shocked as well because it was Ode itself which allowed
for such diverse ways to do things. This is mainly because dVector,
dQuaternion and dMatrix are just typedefs to normal arrays, and, as
such, they can appear virtually everywhere, as input/output arguments,
as return pointers, as embedded members of larger data structures,
sometimes disguised as just dReal*, you name it. It was very difficult
just to get something which was minimally coherent with original Ode
However, my main objective for the very first release of OdeNet was to
reproduce as exactly as possible the functionalities and API of Ode.
Later on I hoped I could find a good way to deal with some of the
inconsistencies. If that time is now, much more the better :-)
Actually, it is a bit difficult to decide between getter/setter
parameterization and direct math structure manipulation for OdeNet.
If a getter/setter environment is chosen, lots of needless copies may
crop up, especially if other libraries are tucked in the same
application (like Ogre or DirectX, each with their own math
structures). I got scared at this when once, with other Ode wrapper, I
witnessed that I was wasting more time just copying the positions of
bodies to 3D objects' positions than actually stepping through the
On the other hand, direct structure manipulation may be really
counter-intuitive, especially in a .NET environment, where structures
are usually value types which are copied everywhere.
As I couldn't decide on which was better, I sticked to Ode
functionality, which kind of allows both, maybe at the price of even
There is another interesting possibility for OdeNet, which is that of
specialization. Recently (today) I produced a specialization for Mogre
(Managed OGRE) using OdeNet. Basically I integrated the Mogre math
types (Vector3, Quaternion, Matrix3, etc..) and used them as buffers
to get data from Ode. In this specific case, copying the data makes
much more sense, since I am marshalling directly into a usable
structure for the system with which Ode will be integrated.
I haven't been able to think of a generic way to allow for
specializations as of yet (there probably isn't one since everyone
uses their own formats for data), but it took me just an afternoon to
port everything for Mogre, and it probably wouldn't be much difficult
to bring it for XNA as well, so there's plenty of room for
As for the plain basic library, it's like a swiss army knife.
Sorry for the long post, but these ideas are not ones I can explain in
a concise way. Although you're right about the setter inconsistencies
in Geom. I'll take a look at it and put something new up.
Also, if anyone is into OGRE, please give a look into the new
Mogre.OdeNet dll which will be up very soon. It has a much more
regular, intuitive and consistent usage in regard to these matters, I
Thank you once again for trying it out,
On 1/13/07, Justin Bailey <jgbailey at gmail.com> wrote:
> On 1/12/07, Gonçalo Lopes <goncaloclopes at gmail.com> wrote:
> > Although no one ever cared much about it (after all, it is just my
> > personal pet project ;-)) OdeNet has recently gained a new and
> > hopefully more decent redistribution of its source code. Just pop
> > around http://articaserv.ath.cx/OdeNet and check it out.
> I downloaded your project, tried it out, and it works! Very nice. I
> have some tickets to post to Trac but I was impressed. Thanks!
> ODE mailing list
> ODE at ode.org
More information about the ODE