Current state of the ODE project - Poll

[Germán]

Dear all.

Regarding discussions happening in other topics of this mailing list, I think it could help to know what do the people participating in this mailing list think about the current state of ODE.

1. What's your experience with ODE? For example, since when do you use it, what do you use it for, have contributed code, have a private patched version / fork, etc.
2. Do you think there are issues to be addressed regarding the project, including software distribution, documentation, etc?
3. What are those issues? Please order them according to the importance you assign to each one of them, beginning with the most significant.
4. For each one of the previous issues, please give suggestions of what could be done to solve/alleviate them. If you don't know, say so.
5. Are you willing to help to implement those suggestions.

Thank you,

Germán

[Oleh Derevenko]

1.      

since when do you use it

I use it since beginning of year 2006

 

                what do you use it for

Used for collision tests in statically positioned scenes (in multiple threads though)

Used for limited simulation to compute object idle positions in gravity field

 

                have contributed code

Yes, I do

 

have a private patched version / fork

No, I don’t

 

                etc

Not much of practical experience – used just for those two particular problems.

 

2.      

you think there are issues to be addressed regarding the project, including software distribution, documentation, etc?

Documentation is outdated in many aspects. At least, I don’t think much of new documentation was added since year 2006.

3.      

What are those issues? Please order them according to the importance you assign to each one of them, beginning with the most significant.

Code style is very far from perfect in general. In many places original implementation seems to have been performed by people not having even basic idea of how C++ programs should be designed and what instruments the language offers.

There are large stack-allocated buffers still used for some operations (not the most common operations though).

 

4.      

For each one of the previous issues, please give suggestions of what could be done to solve/alleviate them. If you don't know, say so.

Obvious

Quite difficult/not possible without library public interface changes in some places. The other might still be corrected (something within QuadTree/HashSpace – don’t remember exactly/may be wrong).

 

5.      

Are you willing to help to implement those suggestions.

Everything is possible but some events may not happen within lifespan.

 

Oleh Derevenko

-- Skype with underscore

  

 

From: ode-...@googlegroups.com [mailto:ode-...@googlegroups.com] On Behalf Of German
Sent: Tuesday, May 14, 2013 7:15 PM
To: ode-...@googlegroups.com
Subject: [ode-users] Current state of the ODE project - Poll

 

Dear all.

 

Regarding discussions happening in other topics of this mailing list, I think it could help to know what do the people participating in this mailing list think about the current state of ODE.

1.      What's your experience with ODE? For example, since when do you use it, what do you use it for, have contributed code, have a private patched version / fork, etc.

2.      Do you think there are issues to be addressed regarding the project, including software distribution, documentation, etc?

3.      What are those issues? Please order them according to the importance you assign to each one of them, beginning with the most significant.

4.      For each one of the previous issues, please give suggestions of what could be done to solve/alleviate them. If you don't know, say so.

5.      Are you willing to help to implement those suggestions.

Thank you,

Germán

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

[Joseph Cooper]

1. What's your experience with ODE? For example, since when do you use it, what do you use it for, have contributed code, have a private patched version / fork, etc.

I've used ODE for about 6 years. 
I use it drive the physics in a real-time virtual-reality environment for interactive psychophysical experiments. 

I also use it to drive simulated humanoid characters, and abuse it to accomplish skeleton fitting to motion capture data and retargetting and to compute inverse kinematics and inverse dynamics.

I have contributed some bug fixes and a few new features (as patches).  I haven't had time yet to put my recently granted svn access to use.

My copy of ODE has lots and lots of changes to it.

 

2. Do you think there are issues to be addressed regarding the project, including software distribution, documentation, etc?

3. What are those issues? Please order them according to the importance you assign to each one of them, beginning with the most significant.
4. For each one of the previous issues, please give suggestions of what could be done to solve/alleviate them. If you don't know, say so.
5. Are you willing to help to implement those suggestions.

API: The joint interface is troublesome.  It's annoyingly difficult to capture the state of a model and then rebuild it.  I set joint parameters frequently.  It seems silly that I have to use a different function for each joint type when they're all doing the same thing.  A similar issue exists for the interface to set anchors and axes.  Updating the API is a tough thing.  We don't want to break old code.  I've made changes that I use, but we should probably discuss how they should look when presented for general use.

Bugs: There are a handful of bugs/partially implemented features in several of the joints.  I've fixed some.  When I get a chance, I'll commit them.

Documentation: As Oleh mentioned, the documentation needs help.  At the very least, when I add any thing to the API, I'll update the relevant documentation.

Accuracy: ODE seems to be fairly popular with the academic community for non-game simulation.  It's used for many animation papers; it's popular as a robotics platform (e.g., Gazebo); it's used for simulating biological phenomena in various labs.  However, it uses numerous approximations in the name of time-savings.  Some of these cost a lot of accuracy, with minimal time savings.  It would be convenient to have finer-grain control over the tradeoff.  Friction has a few options.  The finite rotation mode also does this.  Many other joint types, however, quietly sweep their inaccuracies under the rug.

Features: There are some new joint types such as Dimitris' gearbox that are waiting to be integrated into the code.  I've also been playing with some minor changes to the solver. 

 

jc

[Danny Price]

On 14 May 2013, at 17:14, Germán <germanl...@gmail.com> wrote:

1. What's your experience with ODE? For example, since when do you use it, what do you use it for, have contributed code, have a private patched version / fork, etc.

I've only used ODE once commercially and that was for simulating cables and chains on a warship. Not the best tool for the job perhaps but I inherited the project.

I'm personally using ODE for simulating chain drive systems and tracked vehicles.

I've contributed minor patches in the past for Mac-specific fixes.

I used to have a patched version to work around the Mac build system issues but these have been resolved in the trunk.

2. Do you think there are issues to be addressed regarding the project, including software distribution, documentation, etc?
3. What are those issues? Please order them according to the importance you assign to each one of them, beginning with the most significant.

To the outside observer ODE looks dead, if not very dated. The first hit in google is actually http://www.ode.org/ which does not leave a good impression (last modification date was May 2007 but most go the linked material is much older).

Compare ODE's online presence to that of Newton, Bullet or Box2D. There is no contest.

The documentation, although ok, lacks good examples especially for tri-meshes and hight-fields which are hard to get right. The examples included with the distribution are difficult to follow.

Creating anything on-screen with ODE is hard work. I still have trouble with real-time simulations due to the way the collision handling and solver is implemented.

Release packages are also few and far between. And keeping the version at 0.1x is also mis-leading. It has been stated on this list that ODE is 'done' so why not make a 1.0 release? What are milestones (if any) for 0.2, 0.3 etc?

4. For each one of the previous issues, please give suggestions of what could be done to solve/alleviate them. If you don't know, say so.

It think it's time to officially end-of-life ODE in it's current form and instead start a new project with a new name. Same code base, same API, just a face-lift. ODE doesn't have a good reputation in the industry as a whole.

5. Are you willing to help to implement those suggestions.

Yes, time-permitting.

[M@]

1) I use ODE4j for collision detection and rigid body dynamics in a general purpose robot simulator.  I also use PyODE for tracking forces on Stompy (our in-progress 2-seater hexapod).  I haven't contributed code because I haven't needed to change anything.

2) Yes.  Especially ODE4j, it crashes in weird ways with poor messages.

3) ODE4j Instability

4) Go over the code with an eye to multithreading bugs.

5) Willing and able are very different questions.  Perhaps if I was better with physics and scientific computing.

--M@

[Dimitris Papavasiliou]

> 1. What's your experience with ODE? For example, since when do you use

> it, what do you use it for, have contributed code, have a private
> patched version / fork, etc.

I don't really remember how long I've been using ODE, I think the first
version I've used was 0.5. I use ODE as part of my general purpose
real-time simulation and rendering system Techne (A short explanation is
that Techne is to real-time simulation and rendering what Tex is to
typesetting or rather it is meant to be that, or rather still it is
meant as an experiment on whether that would be even possible.)

Among the systems I've simulated are the game of Billiards, Aircrafts
and Motorcycles. (These all resulted in simulations that are probably
too hard for the average gamer and too inaccurate for the average academic).

I should note here that I've been pleasantly surprised by ODE again and
again as far as its actual performance is concerned. Since the
simulations mentioned above were meant as a stress-test of how fancy you
can get with Techne simulation-wise I tried to make them as accurate as
possible. The motorcycle for example is a rigid body system consisting
of 11 bodies and 16 joints simulated with a timestep of 1ms and it
hardly causes me any worries performance-wise. That is perhaps not very
impressive but I was impressed by the fact that I could simply copy the
model straight from an academic paper and it would work more-or-less out
of the box exhibiting, at least qualitatively, most if not all of the
behavior of the real machine. Some quantitative tests I've made seemed
to be reasonable but I lack the expertise or experimentation equipment
to comment as their accuracy.

I have stubbornly avoided keeping a private ODE version choosing instead
to submit some joints I have found useful and implemented for adoption
into the trunk.

> 2. Do you think there are issues to be addressed regarding the project,

> including software distribution, documentation, etc?

There are a few, yes.

> 3. What are those issues? Please order them according to the importance

> you assign to each one of them, beginning with the most significant.

One point is the matter of accuracy which Joseph has already pointed
out. Of course this is probably not of interest to anyone, particularly
those who just want plausible-looking games physics but broad-spectrum
selectable accuracy would be very nice. In the end it's probably the
only thing you cannot work around.

Another point is the API which can get pretty annoying. Joseph has
again pointed out some issues, some other are the fact that joints are
very sensitive to the order in which you do things (because some
functions might have internal state setting side-effects), that you have
to work with awkward structures such as 4x3 rotations matrices, that you
sometimes have to do a lot of manual labor in the name of optimization
(I really don't understand why it would be so bad to keep joint feedback
force and torque vectors in every joint structure instead of delegating
all the book-keeping to the user. Would it take any non-trivial amount
of space in any reasonable scenario? Would it hurt cache performance or
something?)

Another point that could be improved is that one sometimes needs to use
intermediate bodies to simulate a particular joint that is not
available. These can cause all sorts of trouble so more joints would be
helpful.

Documentation is probably not in a particularly good state either but
I'm not in a position to judge it. I'm only using it for reference
these days having figured out most of the quirks through
experimentation. It's ok as a reference manual I suppose but I'm not
sure how good it would be to actually learn ODE and troubleshoot problems.

> 4. For each one of the previous issues, please give suggestions of what

> could be done to solve/alleviate them. If you don't know, say so.

I don't think the first two issues can be fixed in ODE. They would
require extensive backwards-incompatible changes and besides I'm not
sure whether it wouldn't be easier to just start from scratch. I get an
itch to do that once every 5 or 6 months perhaps, then realize that I
have way to much stuff on my hands with my main project and decide to
make do with ODE again.

Joints can easily be added once you figure out how to derive them and
we'll hopefully be able to get them into the trunk now that Joseph has
write access.

Documentation could be improved by updating the Wiki with frequently
asked questions instead of simply answering them on the list again and
again I suppose. Apart from that perhaps a little information on the
"implementation details" of joints would be helpful in order to serve as
a guide when troubleshooting weird behavior.

> 5. Are you willing to help to implement those suggestions.

To the extent that free time constraints permit it yes. Or in other
words: yes but I can't make any guarantees about how quickly I can get
things done.

Dimitris

[Ian Macinnes]

Hi,

On Tue, May 14, 2013 at 11:14 PM, Germán <germanl...@gmail.com> wrote:

1. What's your experience with ODE? For example, since when do you use it, what do you use it for, have contributed code, have a private patched version / fork, etc.

I've used it since about 2002 I think (0.0.35 anyway) and previously used MathEngine. I use ODE for producing Karl Sims-style evolved robots, modelling real robots, and an iOS game. I would probably prefer to use Bullet but I've written a lot of library code using the dMatrix and dVector and can't be bothered to rewrite it. Also it would be a pain to rewrite bits of code that's highly integrated with the ODE API e.g. the code that constructs large robots from a description.

I use a slightly patched copy for the iOS game, but I only altered the code around the core.

1. Do you think there are issues to be addressed regarding the project, including software distribution, documentation, etc?

Yes.

 

1. What are those issues? Please order them according to the importance you assign to each one of them, beginning with the most significant.

Main ones:

Unit tests are old and not really maintained so I don't like to change stuff because I don't know if I'm breaking other stuff.

I use Git and it's come as a bit of a revelation (now that I know how to use it effectively). I resisted moving from Subversion for the same reasons I see people use here (if it ain't broke don't fix it, concerned about branching, Git's overly complicated etc.). But I think using Github (rather than Git per se) would promote and open up development and would be good for ODE. It would make the project more visible too.

Other things that I'm looking at with my project manager's eye and are not meant really as criticism (since I realise ODE is free and maintained by volunteers):

General rusting infrastructure, this can be seen e.g. there are eight feature branches, most haven't been used for years - why aren't they merged with the main branch if they are finished? Has work on them stopped? Who uses them?

We don't use the std anywhere and I wonder why. Mutexes and threading are now part of the standard library (and part of tr1 for a long time) but ODE prefers to use it's own. I'm not 100% sure why we use mutexes anyway? I'm surprised we are willing to use pthread but not the official C++ std.

Can we incorporate Oleh's ou library into the main branch rather than as an external repo?

 

What's the extensionapi branch and why does it need bullet? Could we remove this?

The old home page that does ODE no favours.

I suspect that the bulk of ODE users are people that have been using it for years. I'd be surprised if there are many new users. They are all using Bullet. I can't see any reason not to use Bullet over ODE if you were starting from scratch.

1. For each one of the previous issues, please give suggestions of what could be done to solve/alleviate them. If you don't know, say so.

Hosting on Github where everybody can see it, search for it, and it's easily forkable.

Picking an area where ODE is good at (as opposed to Bullet etc.) and concentrating there. What that might be, I don't know. A higher proportion of users appear to be scientists/engineers rather than game writers. Is this also true for Bullet I wonder?  

Improving the documentation, especially adding tutorials. Using premake is a great thing but it wasn't obvious to me it was present. There are no tutorials because nobody is excited by ODE.

1. Are you willing to help to implement those suggestions.

Maybe, time permitting. It will probably take me a while to do things if they are involved.

As stated in a previous email, I've put up a Github repo that's a mirror of the svn repo:

https://github.com/minimind/open-dynamics-engine

I'm writing a script to automatically keep it up to date from the svn repo's (ODE's and Olah's).

 

Best,

Ian

--

Latest doings may be found here: http://www.ianmacinnes.net

[Tilmann]

1.      

since when do you use it

2008/2009

                what do you use it for

Actually I don't use it. But only provide a Java port of it: www.ode4j.org
However, I do have an average of 2 downloads/day for the last year. I know my users very little, but they include university courses and people that require a physics engine on Android devices.

                have contributed code

I think I proposed a patch once, but it didn't get implemented (may also be my fault, I didn't follow it up)

have a private patched version / fork

Yes, I have ported it to Java 

                etc

Not much practical experience, I just ported it.

2.      you think there are issues to be addressed regarding the project, including software distribution, documentation, etc?

Documentation may be outdated. Then there are lot of things that make porting to Java hard, but that a perfectly valid in C/C++ (many macros, multiple inheritance, pointer arithmetic). I don't expect them to be changed just for me, but I think even some C/C++ programmer think they are overused.

3.      

What are those issues? Please order them according to the importance you assign to each one of them, beginning with the most significant.

Then there are lot of things that make porting to Java hard, but that a perfectly valid in C/C++ (many macros, multiple inheritance (GIMPACT), pointer arithmetic). I don't expect them to be changed just for me, but I think even some C/C++ programmer think they are overused.
Also, the ubiquitous use of non-private attributes is a bit strange for a Java developer (getters and setters are inlined automatically in Java in most cases).

4.      

For each one of the previous issues, please give suggestions of what could be done to solve/alleviate them. If you don't know, say so.

As I said, these issues are very specific to my use case, except that they may be considered bad style by some. Fixing would be easy in many cases, but I'm not sure it would be appreciated. 

5.      

Are you willing to help to implement those suggestions.

To be honest, I'm struggling to keep my Java port up to date. I don't think I could spend much time changing the original code. But again, I'm not sure anyone would want me to.

Best,
Tilmann 

From: ode-...@googlegroups.com [mailto:ode-...@googlegroups.com] On Behalf Of German
Sent: Tuesday, May 14, 2013 7:15 PM
To: ode-...@googlegroups.com
Subject: [ode-users] Current state of the ODE project - Poll

 

Dear all.

 

Regarding discussions happening in other topics of this mailing list, I think it could help to know what do the people participating in this mailing list think about the current state of ODE.

1.      What's your experience with ODE? For example, since when do you use it, what do you use it for, have contributed code, have a private patched version / fork, etc.

2.      Do you think there are issues to be addressed regarding the project, including software distribution, documentation, etc?

3.      What are those issues? Please order them according to the importance you assign to each one of them, beginning with the most significant.

4.      For each one of the previous issues, please give suggestions of what could be done to solve/alleviate them. If you don't know, say so.

5.      Are you willing to help to implement those suggestions.

Thank you,

Germán

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

[Rodrigo Hernandez]

On 5/14/2013 10:14 AM, Germán wrote:

Dear all.

Regarding discussions happening in other topics of this mailing list, I think it could help to know what do the people participating in this mailing list think about the current state of ODE.

1. What's your experience with ODE? For example, since when do you use it, what do you use it for, have contributed code, have a private patched version / fork, etc.

Since around 2004, I started using it for my game engine hobby, I contributed the initial scripts for autotools builds and the convex shape collision detection, I have no private versions laying around.

1. Do you think there are issues to be addressed regarding the project, including software distribution, documentation, etc?

Yes, plenty

1. What are those issues? Please order them according to the importance you assign to each one of them, beginning with the most significant.

The code is a mess, there is liberal use of macros where inline functions would do, and sometimes you can even see macros embeded into functions, defined, undefined and defined again, that, a lack of comments and single character variable names make the code dificult to read and to improve.

I think the double/single presision build duality should be removed, it just makes things harder to distribution packagers and users as well, we should have a model similar to OpenGL, using a f postfix for single presition and a d for double presision, leaving one API out at build time should be optional just in case you're building for a particular architecture or want to keep the library small.

1. For each one of the previous issues, please give suggestions of what could be done to solve/alleviate them. If you don't know, say so.

A rewrite/refactor efford is needed, the code needs to be more accesible to developers so they can improve it, APIs need to be made to allow seamless custom everything (collision, memory management, joints).

A sandbox should be writen to replace drawstuff examples, an application where you can create and attach bodies, motors, etc to see how they behave without having to write any code.

1. Are you willing to help to implement those suggestions.

Yes, its been on my mind for a while, I just don't have the time, and my own project has not reached the point where I can focus on physics, so I lack specific motivation as well as time.

[Tilmann]

Hi M@,

just wondering regarding 3)/4):

3) ODE4j Instability

--> Do you think these are instabilities inherited from ODE or that are introduced by ODE4j?

4) Go over the code with an eye to multithreading bugs.

--> Multithreading should actually work in ODE4J, even though I did not port the according code. The Java language does require far less handling in order to allow multi-threading. Could you let me know what kind of problems you get along with a test case?

Best,
Tilmann

[Gideon Klompje]

Hi all,

1. What's your experience with ODE? For example, since when do you use it, what do you use it for, have contributed code, have a private patched version / fork, etc.

• since late 2010
• used for inverse dynamics/kinematics based animation system for games
• ported & updated old PyODE code base to Cython and contributed it
• no private branch
1. Do you think there are issues to be addressed regarding the project, including software distribution, documentation, etc.
• yes

1. What are those issues? Please order them according to the importance you assign to each one of them, beginning with the most significant.

• I agree with some of the above posters regarding the documentation.  I found it more easy-going than Bullet's when starting out, but it could use a facelift and maybe some targeted tutorials for newcomers.
• Ownership seems to be a problem as there is no clear roadmap and/or authoritative voices.
• Submission process is bottlenecked somewhat.
• Python bindings are not very "Pythonic", rather they were designed simply to wrap the C API.
  
• The community does not seem to be growing much.

1. For each one of the previous issues, please give suggestions of what could be done to solve/alleviate them. If you don't know, say so.

• Documentation just needs some love.  I think we should do a separate poll to clarify and prioritize tasks for a revamp.
• Some people from this list could form a task team to set some goals, starting with some of the obvious problems requiring quantifiable effort.  I agree with Ian in that we should identify what ODE is good at/for (as opposed to Bullet, etc.) and focus our efforts around that (i.m.o. ODE has a more intuitive API for physics engine newbies, and the Python bindings are obviously a big plus).  Perhaps we could even gamify it a bit by adding a "thanks to..." page on the wiki stating contributions.
• I think a public Github repo will go a long way towards encouraging more people to contribute.
  
• The Python bindings need a re-design from an API perspective.  I believe this could be worthwhile not for its own sake, but for broader adoption among the Python community.
  
• I think the low number of contributions is because of the perception that ODE is dead, and to some extent the submission process. However, I think we can easily turn this around by setting some goals & making some releases.  I also think we should encourage *any* contribution.  Of course not all submissions are equal, but the more experienced devs can always point out flaws and work with submitters to improve.  The more people we welcome to the party, the better, and people do improve with time.  Also, not everything has to be merged into trunk immediately...

1. Are you willing to help to implement those suggestions.

• Willing: yes.  Able? hopefully... :)

Best regards,

Gideon

--

[Teravus Ovares]

1. What's your experience with ODE? For example, since when do you use it, what do you use it for, have contributed code, have a private patched version / fork, etc.

• Since the end of 2006.    I use it to simulate a 256m by 256m by infinitym space that's variable in blocks of 256m in OpenSimulator (A new-BSD Licensed server side world simulator)   The protocol and general physics experience is compatible with Second Life viewers.    In the ODE OpenSimulator Plugin, I use the heightfield, raycasts, feedback loops, character motion controllers, vehicle mechanics, linked objects, coalesced objects, ODE primitive types and Tri-mesh types using both, Opcode and GImpact, on 32 Bit and 64 bit systems using Windows and various forms of *nix.    The physics scene has a script accessible API.  Objects are created by users who are visiting the simulation server and, if the user so desires, simulated physically.   There are a variety of object creation methods including simply uploading a collada mesh.   It's being used by some businesses commercially, It's being used by some education institutions for teaching.   It's being used for online gatherings and conferences.     I do have a patched version, that accomplishes two goals,  1. It eliminates the asserts that won't end the world immediately. I control what I can in layers above the physics layer and as best as I can and look for things like NaN and Normalization issues.   It's a dynamic content server, so I do not have as much control over the physics scene as a game developer would and therefore, while I do my best to eliminate things that can cause NaN black holes and such, I don't have ODE asserting if an API layer passes in something bad.   2.  It fixes the pit circle around peaks of the heightfield primitive.  I've discussed this fix on the list before.     This also has the effect that when I'm raycasting against the heightfield, the ray must be pretty short or I run into memory problems.  Our Libs repository, which contains our version of ODE is git://opensimulator.org/git/opensim-libs   OpenSimulator is a C# server and it uses p-Invoke to utilize the library.  I have contributed patches to the C# bindings.  These have been applied.

1. Do you think there are issues to be addressed regarding the project, including software distribution, documentation, etc?

• I think the biggest issue right now on this project is..    there isn't a lot of people improving it.    There are long standing bugs that, at this point I don't believe will ever get fixed.   Even though the documentation is severely outdated, it still describes how to use the majority of the library...   So it would be nice to update..  but..   the bigger concern for me is lack of activity and paralysis (being afraid to apply patches because nobody knows what it will break).     Last time I checked, stack space was an issue in larger worlds.   This directly affects OpenSimulator as measures had to be taken to track and manage stack space allocations to prevent stack overflow that produce errors in the simulation.

1. What are those issues? Please order them according to the importance you assign to each one of them, beginning with the most significant.

• Question 3 is mostly answered in question 2

1. For each one of the previous issues, please give suggestions of what could be done to solve/alleviate them. If you don't know, say so.

• The project leaders need to spend some time discussing a plan for generating interest in ODE and it's development.     People need to study and understand the code and be able to determine how a patch will affect the system or at the very least be able to develop some standardized tests to validate specific functionality after a patch is applied.

1. Are you willing to help to implement those suggestions.

• Alas, I'm a busy guy.    Not always with physics things.     I've got a life to maintain.  I'm sure that's one of the big issues with everyone who is capable of helping.

[Bill Sellers]

• What's your experience with ODE? For example, since when do you use it, what do you use it for, have contributed code, have a private patched version / fork, etc.

I've used it since 0.5 which must be at least 5 years ago. I have suggested some code on occasion although I don't think any has made it into the trunk. I have a private patched version that I use. I mostly use it for animal simulations and actually it has done everything I need since 0.5, although adding in functions to automatically calculate mass properties of arbitrary trimesh shapes was nice (but hardly core since I used to do this externally). Changing physics engine is actually relatively simple. I used to base my code off Dynamechs and it only took a few weeks to switch. I have thought about changing to other potentially more accurate systems such as Moby but things seem to work OK as they are.

• Do you think there are issues to be addressed regarding the project, including software distribution, documentation, etc?

The documentation of the external API is actually pretty good I think. The reference section is mostly complete and up to date. What is missing is a good step by step guide to creating a custom joint (the chapter in Graphic Gems is OK but written generally rather than being specific for the code that is actually in ODE). There isn't really any documentation about the internals of ODE and that makes modifying the source harder than it could be.

• What are those issues? Please order them according to the importance you assign to each one of them, beginning with the most significant.

Accurate restart is the one thing that I would really like. It is pretty hard to achieve currently.
More joints is always good but I would really like a 'user joint' system so that custom joints do not require the trunk to be modified

• For each one of the previous issues, please give suggestions of what could be done to solve/alleviate them. If you don't know, say so.

I would like to avoid too much change for changes sake. I don't have a problem with slow updates - because mostly what we have works and the maths doesn't change. The changes that are occurring are primarily in the contact system and if we could modularise that out from the solver that might make it easier to maintain, and having a user joint system would make contributing task specific joint much more straightforward.

• Are you willing to help to implement those suggestions.

I probably don't have time at the moment. I was going to edit the wiki about restarting but I could never get things to work perfectly.

Cheers
Bill
www.animalsimulation.org

[Germán]

After almost a month, it seems it's time to close this poll.

So, where do we go from here? I would be great if all the people interested in the future of ODE could read the posted answers.

Then, perhaps we could compile a list of things in which there is general agreement and those were there is not (I'm not doing that job because I don't want to give the impression that I'm pushing the project in the direction I would like it to, and because I'm certainly a newbie compared to those participating in this topic).

A kind of roadmap, with stated goals and dates, would be awesome to get started. It's useful not only for currently interested parties (e.g. align expectations, coordinate efforts) but also to new users that will see that ODE is not dead but heading somewhere.

After that we could define some kind of job assignments, so we all know who is in charge of, say, development of joints.

These aren't very elaborated thoughts but the important thing is that we don't lose the (little) momentum we already got.

Best regards,

Germán

[Dimitris Papavasiliou]

I think the stated problems can be split into a few broad categories:

1) Text-related changes, either with respect to the actual documentation
or the webpage. To be honest I don't think the documentation is a
particularly big problem. It's true that a couple of things could
perhaps be added to provide insight into the inner workings of ODE which
will probably prove necessary to any user sooner or later especially for
troubleshooting weird behavior but given the complexity inherent in a
physical simulator I don't think ODE is very hard to get started with.

The web-page doesn't have anything wrong about it in a practical sense,
meaning that it does point the user in the right direction for using
ODE, but that basically boils down to "go to the Wiki". It also gives
the impression that the project is dead or at least obsolete though, so
a face-lift might prove beneficial. I'm not sure how to go about this
though both technically and administrationally. I suppose this would
reuquire permission from whomever "owns" the web-page and also finding
someone experienced enough in web design to throw together a decent,
modern webpage. (Granted, just about anything would be an improvement
over the existing one).

2) Core changes. There are a couple of complaints with regard to the
existing code infrastructure and the existing API is a frequent source
of aggravation for me personally too, but I somehow doubt whether we
would be able to address this issue as there are multiple problems.
Making any substantial changes, especially to the API would break
backwards compatibility and probably add a lot of bugs to the existing
ones. ODE is a fairly complicated project which has been worked on by
many different people and making major changes to such a codebase is
never a simple thing. I can't help but feel that a rewrite would be
easier, more enjoyable and with larger scope for improvement (although I
may be of course wrong as I don't have much experiene with developing
simulators).

3) Joint improvement/additions. This is an area where improvements are
more tractable and furthermore could address the question: "Why use ODE
instead of library X". Joseph mentions areas where significant (and
questionably justified) tradeoffs of accuracy for performance are made.
Perhaps we could compile a list of those and add "switches" to the API
to allow user control over this and improve on the overall acuracy of
ODE as well. Also more specialized joints can be added, especially
things that can't be done with a combination of existing joints but this
of course will have to wait until someone has need of such joints to
provide both the incentive for their development as well as the
practical application for their debugging.

One thing I could perhaps contribute to ODE would be my tire and
racetrack bodies since, judging from list traffic, automobile simulation
seems to be a very popular application for ODE. I'm not sure whether
that would fit into ODE though as it is a bit specialized and aimed
towards getting a "perfect" contact response which you can't really get
from the existing triangle mesh and heightfield colliders.

The racetrack is specified as a sequence of road segments with precise
length, width, curvature and superelevation (bank) which allows the
contact point and normal to be resolved analytically. The tire model is
that of a motorcycle tire right now so it is torus-shaped but a car tire
is planned too once I get a bit of time to dabble in car simulation. I
also have contact resolution code for tire to heightfield collision
which uses a cubic spline interpolation on the height field samples to
get a surface with continuous normals and thus jerk-free contact
response. This all works pretty well but as I've said it might perhaps
be deemed "not generic enough" for ODE. I've been meaning to propose
this for some time though so I though I'd take the opportunity.

Dimitris