lianlab / bullet

Automatically exported from code.google.com/p/bullet
0 stars 0 forks source link

Value 1e30 too large for single precision #206

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Bullet uses the value 1e30 at numerous places as a "finite approximation of 
infinity". This value is 
too large for single precision as its square 1e60 exceeds the range of singe 
precision (maximum 
value about 3e38). E.g., the static plane has a bounding box -1e30 .. +1e30, 
and btCollisionShape::getBoundingSphere computes the square of the diagonal 
length of the box, which 
s 12e60.

Please use a #define in btScalar.h and replace all 1e30 in Bullet by this 
#define. The #define could 
depend on BT_USE_DOUBLE_PRECISION. For single precision, a safe value should be 
something like 
1e15, so that at least squares are in the valid range. Or are there places 
where three or more 
potentially infinite values get multiplied? Maybe also 1e10 is OK, given that 
Bullet objects should 
have a dimension not too far away from 1.

Original issue reported on code.google.com by ol...@arcor.de on 18 Mar 2009 at 4:20

GoogleCodeExporter commented 9 years ago

We should remove all places where infinite values are multiplied.

Secondly, indeed we should replace 1e30f by BT_MAX_FLOAT. There is another 
issue that 
helps tracking floating point issues.

Original comment by erwin.coumans on 20 Mar 2009 at 3:49

GoogleCodeExporter commented 9 years ago
Any progress on this? I think the first step could really be as simple as 
replacing all 1e30 by some #define. 

Original comment by ol...@arcor.de on 17 Apr 2009 at 2:45

GoogleCodeExporter commented 9 years ago
no progress yet, there is simply too much other work right now.

Perhaps you can help out, with a patch to replace 1e30 by #define BT_MAX_FLOAT 
(in 
btScalar.h) ?
Thanks a lot,
Erwin

Original comment by erwin.coumans on 6 May 2009 at 9:53

GoogleCodeExporter commented 9 years ago
It has been fixed in latest trunk:
http://code.google.com/p/bullet/source/detail?r=1674

Thanks for the report!

Original comment by erwin.coumans on 23 May 2009 at 2:16