[ODE] New release?

[erwin@erwincoumans.com]

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. 

Erwin 

 

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