Can you help testing Bullet 2.63-RC1?

Post Reply
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Can you help testing Bullet 2.63-RC1?

Post by Erwin Coumans »

Please try out the release candidate for Bullet 2.63 here:

http://www.bulletphysics.com/Bullet/php ... =18&t=1567
Thanks,
Erwin
Enrico
Posts: 42
Joined: Thu May 17, 2007 9:34 am
Location: Stuttgart, Germany
Contact:

Re: Can you help testing Bullet 2.63-RC1?

Post by Enrico »

Hi,

I just had a small look at it:

1) Extras/GPUPhysics does not link correctly on Linux and the configure-script does not check if GLew is installed or not.
2) Serialising an btOptimisedBVH finally compiles. However, there are differences in the results between 32Bit and 64Bit systems. I narrowed this down to differences in the template btAlignedObjectArray on these two system types. On 32Bit x86 system, sizeof(btAlignedObjectArray) gives 20 bytes and on 64BIt AMD64 systems the size is 32bytes.
3) Lots and lots of warnings using g++/Linux.

I dont know, what your policy regarding 2) is: Make the serialisation results interchangable between 32Bit and 64 bit systems or not? Maybe it should be stated somewhere...

I will continue testing now...

Best regards,
Enrico
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Can you help testing Bullet 2.63-RC1?

Post by Erwin Coumans »

Enrico wrote: 1) Extras/GPUPhysics does not link correctly on Linux and the configure-script does not check if GLew is installed or not.
It shouldn't be included by default. The GPU project is currently dormant, until someone wants to pick it up. I'll update the jam file, not to include it by default.
2) Serialising an btOptimisedBVH finally compiles. However, there are differences in the results between 32Bit and 64Bit systems. I narrowed this down to differences in the template btAlignedObjectArray on these two system types. On 32Bit x86 system, sizeof(btAlignedObjectArray) gives 20 bytes and on 64BIt AMD64 systems the size is 32bytes.
I dont know, what your policy regarding 2) is: Make the serialisation results interchangable between 32Bit and 64 bit systems or not? Maybe it should be stated somewhere...
Good point, there is currently no plan to allow exchange between 32bit and 64bit serialization. It should be possible to exchange between big-endian and little-endian machines, as long as they are both 32bit or both 64bit. I'll add some doxygen comments, and put it in the docs.
3) Lots and lots of warnings using g++/Linux.
Are most of the warnings are in COLLADA_COM and libxml (external projects)? If you can help fixing warnings inside the Bullet projects, a patch would be welcomed :-)

Thanks for the feedback!
Erwin
Eternl Knight
Posts: 44
Joined: Sun Jan 22, 2006 4:31 am

Re: Can you help testing Bullet 2.63-RC1?

Post by Eternl Knight »

Whether this is a MSVC 7.1 issue or something else I am not sure of; but the "libquickstep" will not compile in MSVC 2003 (i.e. MSVC 7.1) as <intrin.h> does not exist.

You also need to add #include <memory.h> in order for memset to be defined in the "#ifdef _MSC_VER" (the __GNUC__ version has #include <string.h> which also defines this)

--EK
Enrico
Posts: 42
Joined: Thu May 17, 2007 9:34 am
Location: Stuttgart, Germany
Contact:

Re: Can you help testing Bullet 2.63-RC1?

Post by Enrico »

Hello,
Erwin Coumans wrote:Are most of the warnings are in COLLADA_COM and libxml (external projects)? If you can help fixing warnings inside the Bullet projects, a patch would be welcomed :-)
I fixed most of the warnings in the Bullet libraries and demos. I have not had time for Extras/ :oops:
Get the patch here. Code's license is "whatever license you need" ;)

Following things have been changed:
1) removed lots of warnings due to wrong order in initialiser lists
2) changed return value of getName()-method to "const char*" instead of "char*" (solves lots of warnings)
3) removed some unused variables
4) Removed double entries in Demos/Jamfile
5) added some missing newlines
6) Padding attributes are now set to zero with memset(), added some ctors for this.

Notes:
1) I left two small comments in the source code, just grep for "Enrico".
2) There are still some warnings due to comparison of signed and unsigned integers. I left them all in, not sure what to do with them. Just cast them away? :?:

I tested on Debian GNU/Linux (testing, AMD64) with g++ (GCC) 4.2.1 (Debian 4.2.1-4) and all included demos seem fine :)


Best regards, Enrico
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Can you help testing Bullet 2.63-RC1?

Post by Erwin Coumans »

Thanks a lot Enrico, that is a huge patch. Overall it looks fine. I made a few minor changes related to padding initialization (no memset to avoid performance issues), accidential left over <iostream> include. Bullet intentionally doesn't use STL (std::) and some other things like C++ exceptions etc, this should go in a how-to contribute to Bullet document.
Eternl Knight wrote:Whether this is a MSVC 7.1 issue or something else I am not sure of; but the "libquickstep" will not compile in MSVC 2003 (i.e. MSVC 7.1) as <intrin.h> does not exist.
You also need to add #include <memory.h> in order for memset to be defined in the "#ifdef _MSC_VER" (the __GNUC__ version has #include <string.h> which also defines this)
SSE/intrinsics will be removed from quickstep. We should re-implement a fully new SSE version separate from Extras/quickstep.

Thanks for reporting, it will be fixed.

Thanks a lot,
Erwin
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Can you help testing Bullet 2.63-RC1?

Post by Erwin Coumans »

Bullet 2.63 has been released, including your fixes.

Thanks!
Erwin
Post Reply