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

[Frederic Marmond]

Hi Nate (and others that would like to join us in this discussion!)

I don't want to denigrate ODE, which is a very very nice job.

What I'm saying is that I find it hard to concentrate on the Physic part.

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...
Some exemples of actual confusing:
- You find colliding stuff in the ode/src (plus a windows specific in 
the contrib/).
- If you try to use doxygen or something to get a technical doc, you 
have all mixed in it
- you try to find a bug (we frequently speak about problems about 
varying the worldStep), it's hard to isolate, correct, see if it has 
dependency, ...
- if you want to propose an other implementation of one specific part, 
you must integrate all the stuff...

I think it's really a bad thing to help us contribute.
If I was a math guru (but I'm not...), and if I would want to contribute 
(I do want ;-)) to the physic engine, I would be disapointed by this 
confusion: where can I find doc about ONLY the physic part, where is the 
code for ONLY this?
I re-write the main computing formula: "divide and conquer". If you have 
one place with all mixed in this, you can't have visibility to identify 
what you are working on.

Plus, I don't think it helps us to write tools to make it open.
For exemple, many colliding-engins only gives you the colliding 
triangles pairs (much fast). I'm working on a little function to extract 
the contact point + normals + depth from theses triangles. I think that 
a lot of people already did this (perhapse in the tri-collider in the 
contrib/ ?) but it may be 'closed', embedeed in their implementation for 
a specific use (the ODE's collider).

That's just my feeling and few suggestions... I may be wrong...
But as I see in OSG, which has also it's core job (Scene Graph) and 
extensions (shaders, loaders, particules engines, ...), separations of 
things (wich are plugins, with their own source / doc / tests 
directories) make a lot of people contribute and maintain their 
contributions.
I don't say "OSG is good, and ODE is bad", I just say "perhapse it may 
be a good idea to look why do they have so much contributions and why it 
works".

What about the ODE file format loader/saver ?
What about the other implementation of the solver ?
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, ...) ?

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!

Fred




Nate W wrote:

>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?
>
>  
>