[ODE] New release?
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.
>> 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?
>>>> ODE mailing list
>>>> ODE at q12.org
>>> ODE mailing list
>>> ODE at q12.org
> ODE mailing list
> ODE at q12.org
More information about the ODE