Issues reported with constraint picking under Linux 32bit double precision

[GoogleCodeExporter]

From http://bulletphysics.com/Bullet/phpBB3/viewtopic.php?f=18&t=3177

I'm using the current SVN version (1610) now, and since a while back the 
mouse picking of objects in the demo applications has been broken. For 
example, when trying to pick a cylinder in the CcdPhysicsDemo, the 
simulation explodes (cylinders flying everywhere quickly), or it aborts due 
to the assert in btQuaternion for a value of 0. This seems to be a general 
issue in all demos that allow picking up objects with the mouse. I'm not 
quite sure at which revision this was broken, I can look further into it if 
you like.

I'm running this on Linux, 32 bit, and it's compiled with double precision. 

EDIT:
I just tried the Bullet demos in single precision mode. The picking issues 
are gone, so it seems that the demos are only broken in double precision 
mode!

Original issue reported on code.google.com by erwin.coumans on 9 Feb 2009 at 9:17

[GoogleCodeExporter]

Ola,

I just built Bullet SVN using the Jam build system (I defined 
BT_USE_DOUBLE_PRECISION
in btScalar.h) and running the CcdPhysicsDemo picking works fine and the 
simulation
doesn't explode.

Original comment by john.mcc...@gmail.com on 9 Feb 2009 at 10:16

[GoogleCodeExporter]

Hi John and Erwin,

thanks for looking into this. I've done further tests now, using the 2.74 beta 
release tarball, to
be sure that it's not something stuck in my svn checkout directory. 

1. A clean build in a fresh directory, in single precision. I checked that it's 
single precision with
the DoublePrecisionDemo. It works fine.

2. A clean double precision build, in a separate directory. I defined 
double-precision by setting
the system variable like this: 
export CPPFLAGS=-DBT_USE_DOUBLE_PRECISION
in the shell. Usually I have this set in my .bashrc file for convenience.
Everything builds fine, the DoublePrecisionDemo reports double precision. 
Picking in
CcdPhysicsDemo is broken, the simulation explodes.

3. A new clean directory, I go and define BT_USE_DOUBLE_PRECISION in 
btScalar.h. Now the
demos won't build at all, I get the following errors instead:
Demos/OpenGL/GL_ShapeDrawer.cpp: In member function ‘virtual void
GL_ShapeDrawer::drawOpenGL(btScalar*, const btCollisionShape*, const 
btVector3&, int,
const btVector3&, const btVector3&)’:                                         

Demos/OpenGL/GL_ShapeDrawer.cpp:372: error: cannot convert ‘btScalar*’ to 
‘const
GLfloat*’ for argument ‘1’ to ‘void glMultMatrixf(const GLfloat*)’    

Demos/OpenGL/GL_ShapeDrawer.cpp:416: warning: suggest parentheses around + or - 
in
operand of &                                                                    

Demos/OpenGL/GL_ShapeDrawer.cpp:435: warning: unused variable ‘planey’      

Demos/OpenGL/GL_ShapeDrawer.cpp: In member function ‘virtual void
GL_ShapeDrawer::drawShadow(btScalar*, const btVector3&, const 
btCollisionShape*, const
btVector3&, const btVector3&)’:   
Demos/OpenGL/GL_ShapeDrawer.cpp:756: error: cannot convert ‘btScalar*’ to 
‘const
GLfloat*’ for argument ‘1’ to ‘void glMultMatrixf(const GLfloat*)’    

Demos/OpenGL/GL_ShapeDrawer.cpp:784: warning: unused variable 
‘useWireframeFallback’ 

From earlier I remember that it was not recommended to define
BT_USE_DOUBLE_PRECISION in btScalar.h, rather to set it as an environment 
variable. 

Anyway, it's weird that I can't get this built when this the way you did, John. 
At exactly which
position did you define the BT_USE_DOUBLE_PRECISION? I set mine at line 29, 
just below the
#define BT_BULLET_VERSION 274

My system is Ubuntu 8.10, 32bit. The same problem happens on Ubuntu 8.04 too. 
The
compiler version is gcc 4.3.2. Maybe we have different compiler versions or 
something?

Best regards,
Ola

Original comment by olaroert...@gmail.com on 10 Feb 2009 at 8:17

[GoogleCodeExporter]

Ola,

I built Bullet following your directions and I do see the quaternion problem. 
I'm
looking into it.

Thanks,
John

Original comment by john.mcc...@gmail.com on 10 Feb 2009 at 5:11

[GoogleCodeExporter]

Excellent, I was starting to wonder if I'd just messed up something. :-) Let me 
know if I can
assist with something,

best regards,
Ola :-)

Original comment by olaroert...@gmail.com on 10 Feb 2009 at 9:39

[GoogleCodeExporter]

Hi,

This turned out to be a difficult to track down bug. I just committed the fix 
to SVN. 

The issue was in the constraint solver and the rowSkip variable. The constraint
solver divides each constraint into (up to) 6 rows (each row is a
btSolverConstraint.) In btConstraintInfo2 they the rows are addressed as arrays 
of
type btScalar. The rowSkip variable is computed as the number of btScalars per 
row.
As long as btSolverConstraint is aligned properly this calculation will be 
correct.
The bug was caused by the ATTRIBUTE_ALIGNED16 macro that Bullet uses to force
alignment being empty on platforms other than Win32 and Cell.

Please test the latest SVN and let me know if you still have problems.

Thanks,
John

Original comment by john.mcc...@gmail.com on 10 Feb 2009 at 10:32

[GoogleCodeExporter]

Original comment by john.mcc...@gmail.com on 10 Feb 2009 at 10:33

• Changed state: Fixed

[GoogleCodeExporter]

Good find John, thanks.

Although the fix works for platforms/compilers that support __attribute__ 
((aligned 
(16))), I would like to try out a fix that can leave it empty.

Instead of using ATTRIBUTE_ALIGNED16, I tried to force btScalar alignment by 
using 
unions for each non-btScalar data type in btSolverConstraint.

Can you please test SVN trunk revision 1621 or later?

Original comment by erwin.coumans on 10 Feb 2009 at 11:51

• Changed state: Accepted

[GoogleCodeExporter]

Hi,

I just tested SVN revision 1623. The issue is gone, the CcdPhysicsDemo picking 
is working in
double precision mode. Also my stability issues in my game engine are gone, the 
ragdoll
models work like they did before. Well done figuring that one out!!!

Thank you,
Ola

Original comment by olaroert...@gmail.com on 11 Feb 2009 at 9:29

[GoogleCodeExporter]

I can also verify that your fix also works.

Original comment by john.mcc...@gmail.com on 11 Feb 2009 at 5:06

[GoogleCodeExporter]

Original comment by john.mcc...@gmail.com on 11 Feb 2009 at 5:06

• Changed state: Fixed