[ODE] is ODE losing his 'O' ???

[Nate W]

On Thu, 13 Mar 2003, Frederic Marmond wrote:

> When you get ODE, you get the Physic, but also the collider and the 
> graphic stuff that goes with. And it seems that the Physic part is 
> developped regarding this colliding and this graphical stuff.

My application, Juice, uses ODE for dynamics and collision, but it does
not use the "DrawStuff" application framework.  Si Brown's FreeFall Buggy
Demo also does not use DrawStuff.  The fact that so many people ARE
building their applications atop DrawStuff came as a surprise to me.

It seems to me that Russ developed the Drawstuff application framework for
the purpose of demonstrating and testing ODE's physics and collision
functionality (Russ, do correct me if I'm wrong!).  Drawstuff does that
job nicely.  It provides a helpful example and demonstration of ODE in
use, but if your desired user experience is more sophisticated than "start
it up and watch it go," then drawstuff is probably the wrong place to
begin your project.  If you want to create an application in which the
user really interacts with the ODE universe, you are probably better off
starting without drawstuff, and developing your application from the
ground up.  Nothing about ODE makes that approach difficult.

OK, I must confess that I use drawstuff's cylinder-drawing and
texture-loading code in Juice. :-)

> In my project, I use OpenSceneGraph and OPCODE with ODE, and it's bad 
> that I have to make so much efforts to connect ODE with the other 
> libs... OSG and OPCODE can connect very well, but, I have to say that 
> ODE is less easy to integrate.

I cannot comment on the integration of ODE's physics with other collision
detection systems, but from what I have seen of the API it does not look
like a difficult problem.  Or rather, the difficulty of this problem comes
from the fact that collision detection for dynamic simulation is itself a
hard problem.  That is not a drawback of ODE. :-)

> What do I suggest?
> 
> => make the physic, the collider and the graphics more independants
> collider and graphics are good things to see what physic can do but they 
> may have their own libs

The graphics are already completely independent.  There is no need to
separate them.  It only looks like they are related because ODE happens to
come with a program that *demonstrates* the use of ODE with graphics.  
Drawstuff is not part of ODE though.

> => make more tools to integrate with other libs:
> OPCODE doesn't provide the contact point for a collision. We have to 
> implement our own [...]

That is exactly what I was referring to when I wrote about that the
difficulty comes from the difficulty of physics programming, not from
anything about ODE itself.  I agree that it would be wonderful to have
such integration code already written, but that sort of code falls outside
of ODE itself.  It would make an excellent contribution for the contrib
folder though!

> => make separete documentations
> When you try to find something in the doc, it always speak of the geoms, 
> but it may not be handled by ODE! (OSG in my case). It's hard to see 
> clearly things, as they are all gathered in only one place.
> By splitting libs (physic, graph and colliding), we would be able to 
> concentrate each on our competences and make things betters (independant 
> code, specific docs, ...)

I have difficulty understanding this request.  Sections 5, 6, and 7 of the
documentation descrive ODE's physics.  Section 9 describes collision
detection.  Nothing in the documentation describes drawstuff (and, IMO,
that is good).  How much more separate could they be?

-- 

Nate Waddoups
Redmond WA USA
http://www.natew.com