[ODE] New release?

erwin@erwincoumans.com erwin at erwincoumans.com
Thu Dec 21 11:07:50 MST 2006

Indeed. Other libraries like Bullet and SOLID have the same issue, and 
require a #define to enable double precision. Usually an application needs 
either one or the other, not both at the same time. And dealing with a 
single system-wide physics dynamics library is not recommended for several 
reasons in my opinion. 

In case of (future) SIMD support you might want to enable two different 
code-paths in the same library, and enable switching on-the-fly, based on 
user-preference and system capabilities. 



Rodrigo Hernandez writes: 

> Yeah, there was a discussion a long while ago, the main reasoning was to 
> create a single compilation library,
> instead of two, however I looked at the code, and making the change is 
> not easy, so it will stay the way it is. 
> Fredrik Sandstrom wrote:
>> Why would you want to change the API in that way?  
>> For graphics programming it makes sense to choose the format of the
>> underlying data but for physics programming you might want to switch
>> from float to double or vice versa just to try out stability issues.
>> Changing a define and recompile is much better (imho) than having to
>> change all function calls. 
>> What would happen if you intermingle float and double precision
>> commands, wouldn't half of the commands just be doing type conversions?
>> How would you chose what precision the underlying engine is using (still
>> with a define?) 
>> Perhaps you just mean to add separate functions with f/d suffixes that
>> do automatic data type conversion to the underlying engine type? I can
>> see some reasons to extend the API but not to remove the current way of
>> easily going between float and double precision without changing
>> application code. Perhaps there is some previous discussions of the
>> topic? I couldn't find a search interface for the mailing list, sorry. 
>> /Fredde 
>> On Wed, 2006-12-20 at 21:38, Rodrigo Hernandez wrote:
>>> No objections here, I've been thinking about doing the change from dual 
>>> float point compilations to OpenGL like suffixes
>>> (f for float arguments,d for double), which would radically change the 
>>> API, so a new release is a very good idea. 
>>> I am also thinking about the switch from static collision detection to a 
>>> dynamic one. 
>>> Jason Perkins wrote:
>>>> Erwin Coumans would like to start working on integrating ODE and the
>>>> Bullet continuous collision library. Since this work might take a
>>>> while, I believe it makes sense to push out a new release of ODE
>>>> before he starts. Are there any objections? Is there anything that
>>>> really needs to be done before a new release? 
>>>> Thanks, 
>>>> Jason
>>>> _______________________________________________
>>>> ODE mailing list
>>>> ODE at q12.org
>>>> http://q12.org/mailman/listinfo/ode 
>>> _______________________________________________
>>> ODE mailing list
>>> ODE at q12.org
>>> http://q12.org/mailman/listinfo/ode
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode

More information about the ODE mailing list