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

[Nate W]

On Fri, 14 Mar 2003, Frederic Marmond wrote:

> I think that one repository for the Physic (the main goal of ODE) with 
> it's own sources, it's own documentation, it's own unitary tests 
> (without graphics), and one separate for the collision (with it's own 
> sources, doc andd unitary tests) and one other for the graph (with it's 
> own too), plus one last that demonstrate the gathering of all, to make 
> everybody see what the main goal (Physic) can do, would be nice...

I think this would only require writing small sample applications for each
of the purposes you have described.  I could be wrong, but I don't think
that anything about ODE stops a person from writing a program that uses
only ODE physics or only ODE dynamics.  

The graphics stuff that comes with ODE should probably *not* be considered
part of ODE.  If you think of drawstuff as only a sample application, you
might understand ODE better.  Drawstuff actually is completely separate
from ODE.

I agree that it might be less confusing if ODE's source files were
separated into, for example, 'dynamics' and 'collision' subdirectories
(and perhaps a 'shared' subdirectory for math and other stuff used by
both).  But other than that, I think that most of your concerns could be
addressed though documentation of ODE's internal functionality.

> - if you want to propose an other implementation of one specific part, 
> you must integrate all the stuff...

I do not see how this is no.  Can you give an example?  It seems to me
that, interally, ODE's dynamics and collision are mostly separate.  
Perhaps a document summarizing which files implement which classes would
make that more clear, though.  I am certain that the graphics stuff that
comes with ODE is completely separate.

You might try re-organizing the ODE source tree into subfolders as I
described above.  (It would probably be wise to consult with Russ and the
rest of the ODE internals hackers first, to be sure that nobody is
actively working on it at the moment, of course.)  It would probably not
be too difficult to re-organize things to make them easier to understand.  
I actually considered this myself when I first started looking deeply
inside ODE.

> What about the ODE file format loader/saver ?

There is no ODE file format. :-)  Some of us have talked about that a bit,
but as far as I know nobody has submitted a spec or reference code and
said, "hey, let's use this."

> What about a tools/human tools/car tools/robot, ...    which may contain 
> extentions from users? (basic tools/doc/tips for handling a walk, a car 
> chassis, ...) ?

You could play with Juice for some of that.  Juice is basically just a
user interface for ODE, plus a couple of systems to control joint motors.  
(No support for hinge-2 joints yet though.)  Its usefulness is somewhat
limited by the lack of a 'common' file format, but it will at least allow
you to create rigid body systems and experiment with them, before trying
to implement them in your own application.

> Are all this possible at this point? I really think that as their is a 
> lot of skilled people on this list (ODE's users...) it would be 
> possible, if we give them the opportunity, and the infrastructure for 
> that... divide and conquer!

I think the ideas you suggest are all possible, it's just a matter of
people (not) having the time and energy to implement them.  I think that
only one (the source code re-organization) would require changes to ODE
itself, though.

-- 

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