Right to use Double Precision bullet

[minghia]

I notice in a previous post that the a #define BT_USE_DOUBLE_PRECISION was to be include in btScalar.h. Is this the right way to get double precision or is there an option from the cmake command line to use? If I only put the #define as above then GlutStuff.h doesn't get this change unless an additional include is made.

So what is the right way to go about this?

[ola]

There is an option in Bullet's CMakeLists.txt file (the one in the Bullet root folder).
find
OPTION(USE_DOUBLE_PRECISION "Use double precision" OFF)
and change it to ON, like
OPTION(USE_DOUBLE_PRECISION "Use double precision" ON)

Seems to work fine for me here. After you change the options, I found I had to delete CMakeCache.txt, then run cmake . again, and finally do a clean make on everything. Check if it works by running the DoublePrecision demo afterwards.

Cheers,
Ola

[Erwin Coumans]

The easiest is to use cmake-gui, and just select the option.

Download Bullet 2.76 and see this tutorial on using cmake with Bullet: http://bulletphysics.org/mediawiki-1.5. ... om_scratch

Thanks,
Erwin

[minghia]

So what happened to the Extras directories LibXML, COLLADA_DOM and BullterColladaConverter? I am using osgbBullet to integrate OpenSceneGraph and Bullet and it depends on these libraries to compile.

Tony Vasile

[Erwin Coumans]

So what happened to the Extras directories LibXML, COLLADA_DOM and BullterColladaConverter? I am using osgbBullet to integrate OpenSceneGraph and Bullet and it depends on these libraries to compile.

Tony Vasile

Those projects have been moved to http://dynamica.googlecode.com, the new home of the Dynamica Maya plugin (keeping the same directory layout). Dynamica supports both COLLADA Physics and .bullet export.

The Bullet SDK will primarily support the new .bullet format. If there is interest we might provide a COLLADA Physics to .bullet converter.

Thanks,
Erwin

[minghia]

It looks like the new project just has the moved librarys and a copy of Bullet-2.76. A rather strange way to package something.

On another note does the newly built double precision bullet library require application which use it to know about #define BT_USE_DOUBLE_PRECISION ?

The only reason I ask is the when I now try to construct a btAxisSweep3 broadphase I get a "malloc(): memory corruption" message at the line I try to create the broadphase object. The problem is tied in with the macro BT_DECLARE_ALIGNED_ALLOCATOR because when I use gdb on the program it points to btAxisSweep3.h line 45 which is the call to the allocator. This never happened under bullet 2.75 and single precision.

Any ideas how I get around this?

[Erwin Coumans]

It looks like the new project just has the moved librarys and a copy of Bullet-2.76. A rather strange way to package something.

The main reason is that the new .bullet file format made libxml and COLLADA_DOM redundant within the Bullet SDK, and they were just too bloated. So COLLADA related stuff is moved to the authoring tools side, as part of Dynamica Maya plugin.

It makes perfect sense to me: this way, the Dynamica Maya plugin and COLLADA related stuf compiles out-of-the-box with Bullet. Note that the SVN repository of Dynamica doesn't have a copy of Bullet/src, it is using svn:externals. So you can do a checkout without externals if you like.

Nothings changed related to double precision compared to 2.75. By default, Bullet uses single precision. If you build the library using #define BT_USE_DOUBLE_PRECISION, anything that includes this double precision build of the Bullet library/header files needs to have this define (BT_USE_DOUBLE_PRECISION) too.

Thanks,
Erwin

[minghia]

Any thoughts on why I having this problem:

The only reason I ask is the when I now try to construct a btAxisSweep3 broadphase I get a "malloc(): memory corruption" message at the line I try to create the broadphase object. The problem is tied in with the macro BT_DECLARE_ALIGNED_ALLOCATOR because when I use gdb on the program it points to btAxisSweep3.h line 45 which is the call to the allocator. This never happened under bullet 2.75 and single precision.

Any ideas how I get around this?
\

[Erwin Coumans]

Any thoughts on why I having this problem:

The only reason I ask is the when I now try to construct a btAxisSweep3 broadphase I get a "malloc(): memory corruption" message at the line I try to create the broadphase object. The problem is tied in with the macro BT_DECLARE_ALIGNED_ALLOCATOR because when I use gdb on the program it points to btAxisSweep3.h line 45 which is the call to the allocator. This never happened under bullet 2.75 and single precision.

Any ideas how I get around this?
\

No direct thoughts other than perhaps you are overloading the global new operator?

Does Bullet 2.76 and single precision also fail for you?
How about Bullet 2.75 and double precision?

Thanks,
Erwin

[minghia]

I get the same problem if I don't define BT_USE_DOUBLE_PRECISION in my program. If do or I don't define it, the new call is trying to allocate 116 something (bytes I assume).

Haven't tried 2.75 and double precision. How do I try that? The program was working with 2.75 and whatever the default precision is.

[Erwin Coumans]

Nothing changed really from 2.75 to 2.76 in this area.

What happens if you leave the precision of Bullet as default (single precision, so not setting BT_USE_DOUBLE_PRECISION during the Bullet build)?

Thanks,
Erwin

[minghia]

Actually when I revert everything to default (single precision) my program works as expected. So is the new of 116 bytes causing me grief as it isn't on an 8 byte boundary or is that what the macro BT_DECLARE_ALIGNED_ALLOCATOR supposed to handle.

I have run valgrind on my executable and the first problem that is detected is an invalid write when the default btCollisionDispatcher is created. This may be the start of my problem. Or maybe someone forgot to convert something in the code base to use btScalar instead of a float/double type. I am only guessing at this point. I trying to compile with gcc -Wall to see if there are any obvious problems.

[minghia]

When I compile this simple program:
//#define BT_USE_DOUBLE_PRECISION
#include <btBulletDynamicsCommon.h>
#include <btBulletCollisionCommon.h>

const int maxNumObjects = 520;
btCollisionObject objects[maxNumObjects];
btCollisionWorld* collisionWorld = 0;

int main(int, char **)
{
btVector3 worldAabbMin(-1000, -1000, -1000);
btVector3 worldAabbMax(1000, 1000, 1000);
const int maxProxies = 32766;
btAxisSweep3 *broadphase = new btAxisSweep3(worldAabbMin, worldAabbMax, maxProxies);
}

I get no illegal memory accesses when I run valgrind (valgrind --tool=memcheck --read-var-info=yes --leak-check=full ./view4) only the odd comment about possible memory leaking. If I recompile bullet to use double precision I get all these illegal writes. It doesn't matter whether or not BT_USE_DOUBLE_PRECISION is defined or not.

Single Precision Valgrind output
==9680== Memcheck, a memory error detector
==9680== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==9680== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==9680== Command: ./view4
==9680==
==9680==
==9680== HEAP SUMMARY:
==9680== in use at exit: 2,884,125 bytes in 11 blocks
==9680== total heap usage: 11 allocs, 0 frees, 2,884,125 bytes allocated
==9680==
==9680== 787,018 (135 direct, 786,883 indirect) bytes in 1 blocks are definitely
lost in loss record 8 of 9
==9680== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==9680== by 0xC0D44C: btAllocDefault(unsigned int) (btAlignedAllocator.cpp:24
)
==9680== by 0xC0D392: btAlignedAllocInternal(unsigned int, int) (btAlignedAll
ocator.cpp:170)
==9680== by 0x8049A0D: btAxisSweep3Internal<unsigned short>::operator new(uns
igned int) (btAxisSweep3.h:45)
==9680== by 0x8049131: main (view4.cpp:14)
==9680==
==9680== 2,097,107 bytes in 1 blocks are possibly lost in loss record 9 of 9
==9680== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==9680== by 0xC0D44C: btAllocDefault(unsigned int) (btAlignedAllocator.cpp:24
)
==9680== by 0xC0D392: btAlignedAllocInternal(unsigned int, int) (btAlignedAll
ocator.cpp:170)
==9680== by 0x28D922: btAxisSweep3::btAxisSweep3(btVector3 const&, btVector3
const&, unsigned short, btOverlappingPairCache*, bool) (btAxisSweep3.h:60)
==9680== by 0x8049165: main (view4.cpp:14)
==9680==
==9680== LEAK SUMMARY:
==9680== definitely lost: 135 bytes in 1 blocks
==9680== indirectly lost: 786,883 bytes in 9 blocks
==9680== possibly lost: 2,097,107 bytes in 1 blocks
==9680== still reachable: 0 bytes in 0 blocks
==9680== suppressed: 0 bytes in 0 blocks
==9680==
==9680== For counts of detected and suppressed errors, rerun with: -v
==9680== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 20 from

Double Precision Bullet BT_USE_DOUBLE_PRECISION not defined
==14004== Memcheck, a memory error detector
==14004== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==14004== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==14004== Command: ./view4
==14004==
==14004== Invalid write of size 4
==14004== at 0x4056215: btAxisSweep3::btAxisSweep3(btVector3 const&, btVector
3 const&, unsigned short, btOverlappingPairCache*, bool) (btAxisSweep3.h:359)
==14004== by 0x8049095: main (view4.cpp:14)
==14004== Address 0x43620bc is 13 bytes after a block of size 135 alloc'd
==14004== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==14004== by 0x435544C: btAllocDefault(unsigned int) (btAlignedAllocator.cpp:
24)
==14004== by 0x4355392: btAlignedAllocInternal(unsigned int, int) (btAlignedA
llocator.cpp:170)
==14004== by 0x804993D: btAxisSweep3Internal<unsigned short>::operator new(un
signed int) (btAxisSweep3.h:45)
==14004== by 0x8049061: main (view4.cpp:14)
==14004==
==14004== Invalid write of size 4
==14004== at 0x405621B: btAxisSweep3::btAxisSweep3(btVector3 const&, btVector
3 const&, unsigned short, btOverlappingPairCache*, bool) (btAxisSweep3.h:359)
==14004== by 0x8049095: main (view4.cpp:14)
==14004== Address 0x43620c0 is not stack'd, malloc'd or (recently) free'd
==14004==
==14004== Invalid write of size 1
==14004== at 0x4056225: btAxisSweep3::btAxisSweep3(btVector3 const&, btVector
3 const&, unsigned short, btOverlappingPairCache*, bool) (btAxisSweep3.h:359)
==14004== by 0x8049095: main (view4.cpp:14)
==14004== Address 0x43620c4 is not stack'd, malloc'd or (recently) free'd
==14004==
==14004== Invalid write of size 4
==14004== at 0x405622C: btAxisSweep3::btAxisSweep3(btVector3 const&, btVector
3 const&, unsigned short, btOverlappingPairCache*, bool) (btAxisSweep3.h:359)
==14004== by 0x8049095: main (view4.cpp:14)
==14004== Address 0x43620c8 is not stack'd, malloc'd or (recently) free'd
==14004==
==14004== Invalid write of size 4
==14004== at 0x4056236: btAxisSweep3::btAxisSweep3(btVector3 const&, btVector
3 const&, unsigned short, btOverlappingPairCache*, bool) (btAxisSweep3.h:359)
==14004== by 0x8049095: main (view4.cpp:14)
==14004== Address 0x43620cc is not stack'd, malloc'd or (recently) free'd
==14004==

valgrind: m_mallocfree.c:225 (mk_plain_bszB): Assertion 'bszB != 0' failed.
valgrind: This is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap metadata. If you fix any
invalid writes reported by Memcheck, this assertion failure will
probably go away. Please try that before reporting this as a bug.

==14004== at 0x38027440: report_and_quit (m_libcassert.c:145)
==14004== by 0x3802767C: vgPlain_assert_fail (m_libcassert.c:217)
==14004== by 0x38033F63: vgPlain_arena_malloc (m_mallocfree.c:225)
==14004== by 0x380628C7: vgPlain_cli_malloc (replacemalloc_core.c:86)
==14004== by 0x38002F88: vgMemCheck_new_block (mc_malloc_wrappers.c:199)
==14004== by 0x380033F6: vgMemCheck_malloc (mc_malloc_wrappers.c:236)
==14004== by 0x38064E89: vgPlain_scheduler (scheduler.c:1363)
==14004== by 0x38091584: run_a_thread_NORETURN (syswrap-linux.c:91)

sched status:
running_tid=1

Thread 1: status = VgTs_Runnable
==14004== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==14004== by 0x435544C: btAllocDefault(unsigned int) (btAlignedAllocator.cpp:
24)
==14004== by 0x4355392: btAlignedAllocInternal(unsigned int, int) (btAlignedA
llocator.cpp:170)
==14004== by 0x4056499: btAxisSweep3::btAxisSweep3(btVector3 const&, btVector
3 const&, unsigned short, btOverlappingPairCache*, bool) (btAxisSweep3.h:365)
==14004== by 0x8049095: main (view4.cpp:14)


Note: see also the FAQ in the source distribution.
It contains workarounds to several common problems.
In particular, if Valgrind aborted or crashed after
identifying problems in your program, there's a good chance
that fixing those problems will prevent Valgrind aborting or
crashing, especially if it happened in m_mallocfree.c.

If that doesn't help, please report this bug to: http://www.valgrind.org

In the bug report, send all the above text, the valgrind
version, and what OS and version you are using. Thanks.

Double Precision BT_USE_DOUBLE_PRECISION defined:

==14028== Memcheck, a memory error detector
==14028== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==14028== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==14028== Command: ./view4
==14028==
==14028==
==14028== HEAP SUMMARY:
==14028== in use at exit: 3,932,725 bytes in 11 blocks
==14028== total heap usage: 11 allocs, 0 frees, 3,932,725 bytes allocated
==14028==
==14028== 787,074 (183 direct, 786,891 indirect) bytes in 1 blocks are definitel
y lost in loss record 8 of 9
==14028== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==14028== by 0x41E044C: btAllocDefault(unsigned int) (btAlignedAllocator.cpp:
24)
==14028== by 0x41E0392: btAlignedAllocInternal(unsigned int, int) (btAlignedA
llocator.cpp:170)
==14028== by 0x8049A87: btAxisSweep3Internal<unsigned short>::operator new(un
signed int) (btAxisSweep3.h:45)
==14028== by 0x804914F: main (view4.cpp:14)
==14028==
==14028== 3,145,651 bytes in 1 blocks are possibly lost in loss record 9 of 9
==14028== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==14028== by 0x41E044C: btAllocDefault(unsigned int) (btAlignedAllocator.cpp:
24)
==14028== by 0x41E0392: btAlignedAllocInternal(unsigned int, int) (btAlignedA
llocator.cpp:170)
==14028== by 0x405638D: btAxisSweep3::btAxisSweep3(btVector3 const&, btVector
3 const&, unsigned short, btOverlappingPairCache*, bool) (btAxisSweep3.h:60)
==14028== by 0x8049183: main (view4.cpp:14)
==14028==
==14028== LEAK SUMMARY:
==14028== definitely lost: 183 bytes in 1 blocks
==14028== indirectly lost: 786,891 bytes in 9 blocks
==14028== possibly lost: 3,145,651 bytes in 1 blocks
==14028== still reachable: 0 bytes in 0 blocks
==14028== suppressed: 0 bytes in 0 blocks
==14028==
==14028== For counts of detected and suppressed errors, rerun with: -v
==14028== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 24 from

It seems there are some problems with using the compiled bullet on Fedora Core 12 and gcc 4.4.3
At this point I am stuck and can't think of anything obvious. Any help would be most appreciated.

Tony Vasile