The state of ODE

[Dimitris Papavasiliou]

Hello all,

please do not consider this as an accusation but as an investigation into the current state of things and what can be done about it.  The main question is whether ODE should be considered an active, maintained project or not.  Numerous patches have surfaced in recent times, few of them my own, most from a small number of individuals and most of them have met with the same fate, or at least that is the impression one gets.  For some there might have been some discussion which led to their rejection which is understandable, I don't think that every contribution must be accepted into a project merely because it might benefit someone, some consistency and quality control has to exist.  Many patches have not been examined though (at least not visibly so through discussion at the patch tracker page or list) and some of them concern bug fixes (see for instance the recent patch regarding the PU joint submitted by jcooper -- which needs some corrections I think).

I have said in the past that it is understandable that free time for the maintainers might be short and thought that perhaps it would be a good idea to establish some sort of patch submission protocol that would require minimal effort on their part, a simple go, no-go decision.  The patches could for example be requested to always include a demo and some test-cases demonstrating their physically correct behavior, at least to some degree.  Nothing came out of the discussion and in any case It seems doubtful whether even that would be a practical approach.

There are a couple of people in the list that seem to be pretty active and know their way around the internals of ODE, or at least part of them.  Examples include jcooper (Joseph I believe) who seems to be hyperactive by the standards of this project in the joints department and Oleh who seems to be active all over.  Perhaps one or more of them could be promoted to maintainer status and given authority to merge patches into the trunk after examining them.  Of course this hinges on the assumption that some of the active people would actually be willing to undertake this responsibility.  I would happily include myself in the list, I'm not trying to avoid having to do the work, but I don't think I'm particularly fit partly because my knowledge of the internals of ODE is limited and mainly because I have practically zero experience with C++.  I do offer to help in any way I can though, for instance updating the documentation or writing demo code and in a pinch I would not object to becoming a maintainer myself.

ODE does seem to have potential for improvement and quite a few productive people are willing to contribute, it would be a pity for it to remain stagnant.  These are all my thoughts of course, others might differ and hopefully they will chime in.

Dimitris

[Oleh Derevenko]

Hi Dimitris,

 

Truly speaking, I have possibility to review and merge patches into trunk even without being promoted to an admin. You only need commit right for that. ;) It’s just that I refrain from getting into joints part.

 

Oleh Derevenko

-- Skype with underscore

--
You received this message because you are subscribed to the Google Groups "ode-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ode-users+...@googlegroups.com.
To post to this group, send email to ode-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ode-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

---

This e-mail may contain privileged and confidential information. If you are not the intended recipient, be aware that any use, disclosure, copying or distribution of this e-mail or any attachments is prohibited. If you have received this e-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you.

[Dimitris Papavasiliou]

Hi Oleh,

Truly speaking, I have possibility to review and merge patches into trunk even without being promoted to an admin. You only need commit right for that. ;) It’s just that I refrain from getting into joints part.

I did know that you have write access to the trunk but does that mean that you're "allowed" to introduce new features into ODE at will?  I was under the impression that this was not the case since I remember you telling me that Daniel makes this sort of decisions when I posted about my Gearbox joint.  If that is the case then it's nice to know that we have someone we might expect to review patches to the core so if we could have someone for joints too we'd be all set.  I therefore propose that jcooper or, if he doesn't want them, myself or someone else who has the time and expertise be given write access rights to the trunk to cover the joints part.

Dimitris

[Oleh Derevenko]

 

From: ode-...@googlegroups.com [mailto:ode-...@googlegroups.com] On Behalf Of Dimitris Papavasiliou
Sent: Tuesday, April 23, 2013 7:12 PM
To: ode-...@googlegroups.com
Cc: Oleh Derevenko
Subject: Re: [ode-users] The state of ODE

 

Hi Oleh,

Truly speaking, I have possibility to review and merge patches into trunk even without being promoted to an admin. You only need commit right for that. ;) It’s just that I refrain from getting into joints part.

I did know that you have write access to the trunk but does that mean that you're "allowed" to introduce new features into ODE at will? 

Well, if I’m sure those will be beneficial (or will not do any harm at least) – then why not?

 

I was under the impression that this was not the case since I remember you telling me that Daniel makes this sort of decisions when I posted about my Gearbox joint. 

That’s because he’s much better at that and does not need to study existing joints before carrying out a decision. J

 

 

Oleh Derevenko

-- Skype with underscore

 

[Joseph Cooper]

It definitely feels like the current repository is not very open to
contributions. Several of the joints have some rather blatant bugs.
I've submitted patches for a few. Those patches are certainly not
perfect, but I believe they're an improvement. In response to a
discussion in this group I implemented implicit computation of the
gyroscopic forces so that they don't spin-up out-of-control, but the
only person who seemed very interested was Erwin Coumans, lead
developer for Bullet. I've been working on still better ways to
conserve angular momentum without exploding or costing too much
computation. It's cool to see a properly precessing top or an
asymmetric top demonstrating the Dzhanibekov effect. I've also been
playing with several other ideas, but I haven't gotten the feeling
that the community is terribly interested. It's tempting to start a
new repository, actually. I've spent enough time in the constraint
code, the solver code, and the integrator code to feel like I
understand it and could re-implement it. I'm not terribly-well
acquainted with the collision code, but I think I could pick it up.
I'd like to see things made a lot more modular. I'd like to use Eigen
for the matrix and vector math. That way, we can leverage their
talent for speed optimization and numerical stability. As Eigen's
sparse library matures, it could be great for working with really
large systems. Anyway, spinning off a new project is probably a
separate discussion for another thread, but it is, at least partially,
motivated by the fact that it seems that one can't contribute much
here.

jc

[Oleh Derevenko]

Could someone of admins grant commit rights for Joseph?

Oleh Derevenko
-- Skype with underscore

P.S. Joseph, just in case if you would indeed want to improve anything seriously in solvers, would you agree that with me, please? It's because I've already looked through dWorldQurickStep implementation entirely (not the dWorldStep yet) and come to conclusion that it is completely possible to split it for parallel execution. It would be that with two cores engaged you would unconditionally get almost x2 performance gain in steppers on large systems. It's just that I got yet additional project at work this year and my household takes more time now. :(

-----Original Message-----
From: ode-...@googlegroups.com [mailto:ode-...@googlegroups.com] On Behalf Of Joseph Cooper
Sent: Wednesday, April 24, 2013 4:04 AM
To: ode-...@googlegroups.com
Subject: Re: [ode-users] The state of ODE

[Rodrigo Hernandez]

I've always felt that the whole project is in need of a full rewrite,
there is much we're losing on, the code is (as far as I know) not even
optimized for SSE, let alone GPU parallel processing, and there is IMO
way too much abuse of preprocessor macros. I have some ideas for a
collision detection rewrite that would make adding new shapes not mean
having to add one collision function per existing shape, but on the math
side (read integrator, derivation,etc.) I am still too green to come up
with anything worth looking at, much less something as good as what we
currently have, and reusing without understanding doesn't seem like a
good idea to me.

We need some order, and I feel we won't get that without an architect to
guide development.

[Rodrigo Hernandez]

Sure, what's your username?

[Rodrigo Hernandez]

I just gave Developer access to jcooper, I hope that's you Joseph,
though the name doesn't match, if its not you, give me your username, if
it is you, you should be able to commit directly to the repository now.

[Bill Sellers]

I can certainly imagine situations where gyroscopic effects working properly could be really interesting in game or simulation contexts and anything that improves numerical stability is always useful. It is actually the stability/accuracy/speed tradeoffs that are the actual reasons for choosing (or sticking with) a particular physics engine. My particular issue of the moment is how to cope with quite large mass disparities but I am not sure any of the engines can actually help me there. One of the things I like about ODE is that it compiles relatively easily on a whole range of platforms and that it doesn't require any other libraries. Having an Eigen dependency is fine until getting Eigen to install becomes difficult. Mind you, since it is just a set of headers I guess it is straightforward. I don't know about the license though. Would it allow closed source development, or App Store distribution? If there are license issues then spinning off a separate codebase would probably be necessary but that isn't necessarily a bad thing - generally a sign of good health in projects.

Cheers
Bill

[Dimitris Papavasiliou]

I've always felt that the whole project is in need of a full rewrite,
there is much we're losing on, the code is (as far as I know) not even
optimized for SSE, let alone GPU parallel processing, and there is IMO
way too much abuse of preprocessor macros. I have some ideas for a
collision detection rewrite that would make adding new shapes not mean
having to add one collision function per existing shape, but on the math
side (read integrator, derivation,etc.) I am still too green to come up
with anything worth looking at, much less something as good as what we
currently have, and reusing without understanding doesn't seem like a
good idea to me.

We need some order, and I feel we won't get that without an architect to
guide development.

Not to mention the API, which can be another source of constant frustration.  I've also toyed with the idea of writing a physics engine from scratch, not only due to API frustration, but due to the fact that ODE is explicitly "game-oriented" in the sense that it's biased towards speed rather than accuracy.  That is a reasonable choice but I've wondered if it could not be possible to provide accuracy over speed as a choice, for instance through higher-order integrators, better friction cone approximation etc.  Of course I deliberately never started anything because I knew it would take a lot of effort and would side-track me too far from my main project but if other people feel like experimenting with a "next-generation" physics engine I'd happily participate.

In the mean time many thanks for responding and making Joseph a developer.

Joseph, if you intend to merge any of the outstanding patches and need any help please let me know (on a new thread preferably).  If any of my own joints are to be merged I could perhaps also add a suite of unit tests to validate their physical behavior.
 
D.

[Danny Price]

I think we need to ask the question: why should a developer in 2013 use ODE over Bullet/Newton/Havok?

[carriva...@live.fr]

Hi,
I am PhD student. During my thesis I used ODE to simulate DNA and chromosomes inside thermal bath. Now I have a post-doctoral position and I model the Drosophila nucleus with the help of ODE.
ODE is well designed to study articulated system in thermal bath http://vimeo.com/user4898920.
Pascal

[Alex]

This paper may help: http://www.adrianboeing.com/pal/papers/p281-boeing.pdf

+1 for biasing towards accuracy. I've used ODE in a robot simulator, where speed was less important. I've also tried NVidia PhysX, but I couldn't even model the friction for picking a simple box with a two-fingered gripper.

[Dimitris Papavasiliou]

I think we need to ask the question: why should a developer in 2013 use ODE over Bullet/Newton/Havok?

 Well not wanting to be forced into using C++ just to use a physics simulator springs to mind.  Of course that might not be a problem for many.  I also vaguely remember having some reservations about Bullet's solver, due to it being biased even more towards fast plausible behavior instead of slower and more accurate.  (I'm not sure though so please do not take this statement as a fact).  Another reason might be that you're simply more familiar with ODE as it's one of the oldest ones around.  Or perhaps  because ODE has more joints than some of the alternatives, but probably just because you've discovered that it does your job pretty well and there's no sense in fixing something that isn't broken.

[Danny Price]

Interesting paper but also out of date. OPAL was still being developed (it's officially dead as of 2010)  and PAL hasn't seen much recent development either. And the other alternatives were either closed-source or in their infancy.

[Joseph Cooper]

My sourceforge username is actually "jcooperation". jcooper was already taken.

jc

[Oleh Derevenko]

The strange thing is that patches in bugtracker were uploaded by jcooper. You can see that if you open patch details. Are there two of you? :)

Oleh Derevenko
-- Skype with underscore

-----Original Message-----
From: ode-...@googlegroups.com [mailto:ode-...@googlegroups.com] On Behalf Of Joseph Cooper
Sent: Wednesday, April 24, 2013 4:54 PM
To: ode-...@googlegroups.com
Subject: Re: [ode-users] The state of ODE

[Joseph Cooper]

I had "jcooper" as my "Display Name", whereas the individual with
username "jcooper" has "Jeff Cooper" as his display name. I just
changed my Display name to match my actual name.

jc

[Joseph Cooper]

On Wed, Apr 24, 2013 at 3:49 AM, Bill Sellers <w...@mac.com> wrote:

I can certainly imagine situations where gyroscopic effects working properly could be really interesting in game or simulation contexts and anything that improves numerical stability is always useful.

Gyroscopic effects turn out to be a lot more important than you'd think.  It affects more than just gyroscopes and fun game effects.  For example, when simulating a long-legged animal, a single stride is enough to accumulate significant error because of the large ratio of the principal axes of the inertia tensor.  In particular, if gyroscope forces are enabled you can gain a lot of energy out of thin air. 

 

It is actually the stability/accuracy/speed tradeoffs that are the actual reasons for choosing (or sticking with) a particular physics engine. My particular issue of the moment is how to cope with quite large mass disparities but I am not sure any of the engines can actually help me there.

I've thought a bit about this issue.  I think there might be a relatively simple way to at least distribute the numerical error equally across the bodies by rescaling the joint-error functions so that the effective masses of all the constraints are similar.  This should help keep the matrix well-conditioned for the solving.  It's on my list of interesting things to try.  I need time to get a better idea of what causes the instability.

I've also considered adding in switches that make the constraints more accurate if desired.  E.g., many of the constraints use the small-sign approximation: sin(x)=x, but if you're playing with ERP and CFM to turn a constraint into a spring, it's no longer safe to assume that x is small and a lot of inaccuracy results.

 

One of the things I like about ODE is that it compiles relatively easily on a whole range of platforms and that it doesn't require any other libraries. Having an Eigen dependency is fine until getting Eigen to install becomes difficult. Mind you, since it is just a set of headers I guess it is straightforward. I don't know about the license though. Would it allow closed source development, or App Store distribution? If there are license issues then spinning off a separate codebase would probably be necessary but that isn't necessarily a bad thing - generally a sign of good health in projects.

 

I like this about ODE as well.  I also like how easy it is to understand and debug the code without any befuddling template error messages.  If I were to incorporate Eigen, it would be in a new project or possibly build off of Karen Liu's RTQL8 simulator.

jc

[Rodrigo Hernandez]

Alright, all fixed, enjoy write access :)

[vugie]

On Wednesday, April 24, 2013 12:07:04 PM UTC+2, Danny Price wrote:

I think we need to ask the question: why should a developer in 2013 use ODE over Bullet/Newton/Havok?

My case is:  simplicity and pure C API - I only use ODE coupled to LabVIEW. The only reasonable way to interface it to an external code is C DLL or .NET. That simply limits my choice if I like to avoid NET or making an intermediate C wrapper. It's enough of work to prepare LV wrappers.
I use ODE mainly for research and I quite often suffer from lack of stability (+1 higher order integrator as a choice) and from lack of easy way to create custom joints.

vugie

[Germán]

It seems my message in the Python bindings branch didn't get much attention. Here it is:

I use the Python bindings a lot and I have quite some of experience programming inh Python so I think I can contribute to those.
May I get write privileges to /ode/bindings/python/? If it is not not possible to restrict to just that directory, I can promess to be good and not modify anything else :)
My SF username is "glarrain".

Thanks,

Germán

[Germán]

Hi everybody.

I think it is great Dimitris raised the issue of ODE's current state of affairs, which in turn has raised many others (perhaps separate topics would be better to organize the discussion).

I use lots of open source software, of many different kinds. Also, I personally created one (Autonomous Robot Simulator, ARS) as my M.Sc. thesis. Before I designed and started programming it, I did a LOT of research of what physics, collision and visualization engines existed.

IMO ODE is a very helpful library but the code and project is weak in many aspects. 

I think successful open source project have the following things in common:

• Frequent release cycle (at the very least once a year) for both new features (e.g. ODE 0.13) and bug fixes (e.g. 0.12.1)
  
• A website containing demos, tutorials, FAQ, etc, for both users and developers
  
• Extensive, updated documentation
  
• Encourage user contributions of bug reports, documentation, patches, feature suggestions, etc.
• Distribute the software as source code and binaries (or easy to install packages)
• Have a public roadmap by the leaders for the software and project
• A large user community (obviously the number will depend on the topic)

Obviously related, the software itself should have:

• Heavily-documented source code. For example, include explanations of why some things were implemented in a certain way and not another
• Test suite with a high level of coverage
• Explicit coding conventions
• An evolution taking care of backwards compatibility but eventually removing "bad/wrong stuff"
• Clear deprecation timeline

After writing the text above, I decided to take a look around

• Top ten reasons why I won’t use your open source project
  
• Producing Open Source Software: How to Run a Successful Free Software Project
• How to start an Open Source Project
  
• Starting An Open-Source Project
  
• How To Build An Open Source Community

Last October I posted a topic named "Time for DVCS?". I personally think SourceForge and SVN are obsolete ways of keeping track of code and collaborating. Git/Mercurial and Github/Bitbucket (I prefer Mercurial) are SO much better at this. It is quite typical that those who get used to some technologies hesitate to start using new ones. That is often a wise choice since sometimes the "new stuff" is the cool thing for some time and does not stick around. But many times the reason is avoiding to get out of the comfort zone.

Last but not least, I want to state that I am very grateful for all the effort the leaders of the project have put into taking ODE to this degree of development. I think we can all contribute (in different ways) to make it even better.

Best regards,

Germán Larraín

[Germán]

(please forgive my previous email, it was a old draft)

Hi everybody.

It is great Dimitris raised the issue of ODE's current state of affairs, which in turn has raised many others (perhaps separate topics would be better to organize the discussion).

I use lots of open source software, of many different kinds. Also, I personally created one (Autonomous Robot Simulator, ARS) as my M.Sc. thesis. Before I designed and started programming it, I did a LOT of research of what physics, collision and visualization engines existed.

IMO ODE is a good and very helpful library but the code and project is weak in many aspects. 

I think successful open source project have the following things in common:

• Frequent release cycle (at the very least once a year) for both new features (e.g. ODE 0.13) and bug fixes (e.g. 0.12.1)
  
• A website containing demos, tutorials, FAQ, etc, for both users and developers
  
• Extensive, updated documentation
  
• Encourage user contributions of bug reports, documentation, patches, feature suggestions, etc.
• Distribute the software as source code and binaries (or easy to install packages)
• Have a public roadmap by the leaders for the software and project
• A large user community (obviously the number will depend on the topic)

(obviously related) the software itself should have:

• Heavily-documented source code. For example, include explanations of why some things were implemented in a certain way and not another
• Test suite with a high level of coverage
• Explicit coding conventions
• An evolution taking care of backwards compatibility but eventually removing "bad/wrong stuff"
• Clear deprecation timeline

After writing the text above, I decided to take a look around and found these interesting resources:

• Top ten reasons why I won’t use your open source project
  
• Producing Open Source Software: How to Run a Successful Free Software Project
  
• How to start an Open Source Project
  
• Starting An Open-Source Project
  
• How To Build An Open Source Community

Last but not least, I want to state that I am very grateful for all the effort the leaders of the project have put into taking ODE to this degree of development. I think we can all contribute (in different ways) to make it even better.

Best regards,

Germán Larraín

On Tuesday, April 23, 2013 10:04:04 PM UTC-3, jcooper wrote:

[Rodrigo Hernandez]

Hi Germán,

I granted you developer access to the repository, try not to break stuff :).

About your other email... well you're right, its really all I can say right now, I have some ideas to evolve ODE just not enough time to commit to them at the moment.

[Germán]

Thanks Rodrigo.

I submitted a few commits to clean up the bindings a little (and provide some uniform, general coding convention). I hope to contribute more in the weeks to come.