Enormous amount of objects

[rTi]

Hello.

I am having problems with the following situation.



Just kiddin'

What I really want to do is to report some experiences I made. I am currently testing a little self built framework which uses bullet.
The above screenshot shows a scene continuously spawning tubes. The stuff described below was tested with sphere, box and convex hull shapes with no significant differences.

Spawning 10 tubes at a time, all 10 positioned next to each other, next 10 on the same position (with a minor random offset) enabled me to spawn up to 7500 tubes (within ~9 seconds) until the application crashed.

Some sample back traces:

Code: Select all

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000198
[Switching to process 1500 thread 0x2903]
0x000acda7 in btSequentialImpulseConstraintSolver::prepareConstraints ()
(gdb) bt
#0  0x000acda7 in btSequentialImpulseConstraintSolver::prepareConstraints ()
#1  0x4008de74 in ?? ()
#2  0x3da19047 in ?? ()
Cannot access memory at address 0x40028f30

Code: Select all

Program received signal EXC_ARITHMETIC, Arithmetic exception.
[Switching to process 1839 thread 0x2903]
0x0013973b in dyld_stub__Z24TestTriangleAgainstAabb2PK9btVector3RS0_S2_ ()
(gdb) bt
#0  0x0013973b in dyld_stub__Z24TestTriangleAgainstAabb2PK9btVector3RS0_S2_ ()
#1  0x000bca79 in btSequentialImpulseConstraintSolver::prepareConstraints ()

Code: Select all

Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to process 1841 thread 0x2903]
0x8fe01045 in __dyld_dyld_fatal_error ()
(gdb) bt
#0  0x8fe01045 in __dyld_dyld_fatal_error ()
#1  0x8fe06fa7 in __dyld__ZN4dyld14bindLazySymbolEPK11mach_headerPm ()
#2  0x8fe18b6f in __dyld_stub_binding_helper_interface2 ()
#3  0x000bca79 in btSequentialImpulseConstraintSolver::prepareConstraints ()

Code: Select all

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xdef4d15c
[Switching to process 1891 thread 0x2903]
0x0013a739 in dyld_stub__Z24TestTriangleAgainstAabb2PK9btVector3RS0_S2_ ()
(gdb) bt
#0  0x0013a739 in dyld_stub__Z24TestTriangleAgainstAabb2PK9btVector3RS0_S2_ ()
#1  0x000bda59 in btSequentialImpulseConstraintSolver::prepareConstraints ()

In my next setup I changed the y position (gravity is -y) of the 10 tubes continuously to prevent them from spawning "in" each other. This setup enabled me to spawn up to ~17500 tubes until the following assertion failed:

Code: Select all

Assertion failed: (m_firstFreeHandle), function allocHandle, file src/BulletCollision/BroadphaseCollision/btAxisSweep3.h, line 329.

I know, this is a completely insane setup, but maybe such a stress test is interesting.
What I would like to know is, are you surprised by those "errors"?
Is it completely natural to happen?
I cannot proof that I am not making anything wrong. So maybe such a thing must not crash and my engine is crap?

Thanks for reading,
rTi

btw. I am running Mac OS X 10.5.2 MacBook Pro Intel

[Erwin Coumans]

Can you make sure to use the 32-bit broadphase (bt32BitAxisSweep3), and to reserve enough objects when initializing Bullet? The 16-bit btAxisSweep3 broadphase only reserves 16384 handles (default argument).

It should be possible to simulate many more objects,
Please let us know how this works for you,
Thanks,
Erwin

[rTi]

Hello.

Thanks for the fast answer. I was indeed using btAxisSweep3 instead if the 32bit version. This will help out the second scenario i think.

But the first problem i described:
the crashes around btSequentialImpulseConstraintSolver::prepareConstraints() ... Is it possible that they are caused by an enormous amount of overlapping dynamic objects? Or may there be another problem?

Greets
rTi

[rTi]

Ok.

I just tested the bt32BitAxisSweep3 and it let me spawn _way_ more objects.
I stopped with 30000 because the app already took 1.4GB. A bit unoptimized here and there I am using a quite naive implementation. The spawn position was totally random (in a given range) and I experienced no crashes. So bt32BitAxisSweep3 does a great job!

But still, the app crashes as soon as I spawn this load of object at the same position.

Code: Select all

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x77108d62
[Switching to process 29291 thread 0x2903]
0x0014a80f in dyld_stub_GetEventKind ()
(gdb) bt
#0  0x0014a80f in dyld_stub_GetEventKind ()
#1  0x000ad699 in btSequentialImpulseConstraintSolver::prepareConstraints ()

This is really not a use case, so maybe we just should not bother here.
A normal applications logic should forbid such a situation anyway.

Thanks
rTi