Maximum number of objects.: 32k limit reached...

tasora · Post by **tasora** » Wed Mar 07, 2007 2:21 pm

Hallo,
I am using Bullet as a collision engine for my multibody simulation
software - results, so far, are very satisfying.
The problem is that the broadphase collision detection cannot
support more than 32767 proxies (see btAxisSweep3::btAxisSweep3)
and this is limiting my tests about massibe granular flows, where I
must simulate more than 50'000 rigid bodies.
The following is an animation showing an example of what
I am doing (I stopped at 30'000 rigid bodies, but my target is
at least 50'000):

http://ied.eng.unipr.it/~tasora/download/reactor_09.avi

How is it possible to overcome the 32767 limitation of the
broadphase? Is it just a matter of changing all the 'unsigned short'
into 'unsigned int' or such?

bye

Alessandro Tasora

Erwin Coumans · Post by **Erwin Coumans** » Thu Mar 08, 2007 12:39 am

Wow, that is impressive. Are you using default GJK for the sphere-sphere, or the specialize sphere-sphere collision algorithm?

Yes, it should be fairly straightforward to enable 32bit integer indices in the broadphase, by replacing the 'short int' by int, and also the 0xfffc into 0xfffffffc. Can you give it a try, and let me know if there are issues (I might have time to just add it to Bullet).

Bullet 2.44a has a new overlapping pair management, that allows for easier parallel processing and should be more cache friendly.

Could you benchmark if you notice any performance difference between Bullet 2.43 and Bullet 2.44a?

Thanks for sharing this!
Erwin

tasora · Post by **tasora** » Thu Mar 08, 2007 9:59 am

Hallo Erwin,

Wow, that is impressive. Are you using default GJK for the sphere-sphere, or the specialize sphere-sphere collision algorithm?

Well, I tested also the specialized sphere-sphere, but performance
increase wasn't that exceptional - if I remember well now I'm still
using the default GJK. The botleneck is rather the LCP solver.

In fact I am using the Bullet solver, with some modifications,
into my Chrono::Engine middleware. I am planning to release this
library asap (the web site is under renewal, otherwise I'd tell you
the link for more precise infos). In general, I'm using an iterative
LCP solver which I'm developing together with Anitescu. This
solver is similar to the one proposed by Mangasarian.

by replacing the 'short int' by int, and also the 0xfffc into 0xfffffffc.

thanks! - surely I would have forgotten the 0xfffc issue!

By switching from 'unsigned short' to 'unsigned int' I will double
memory requirement for SAP (2 times the bytes) but this is not the
most relevant problem.. I just hope that speed performance is not
affected when dealing with 4byte integers rather than with 2 byte
integers... Let's test and see..

Bullet 2.44a has a new overlapping pair management, that allows for easier parallel processing and should be more cache friendly.

I've not yet tested 2.44 - this week I have few spare time for this
collision issues- but I'll tell you if I find improvements.

By the way, with 2.43 I had a strange 'problem'.. If i create all 30k
spheres at once (somewhat in random position) , the SAP takes
too much memory for temporary computations at first run, while
if I add spheres frame after frame (ex.+1000 spheres each step)
the requirement for temporary data is much lower and I can run in
few RAM without the initial memory peak. I hope this is not getting
worse in 2.44

Ok, later

Alessandro Tasora

tasora · Post by **tasora** » Thu Mar 08, 2007 2:36 pm

In fact I am using the Bullet solver, with some modifications,
into my Chrono::Engine middleware

sorry, a typo..
I meant: 'I am using the Bullet collision detection , with some
modifications... ' , etc. etc. (not the solver, cause I use my own library)

Alessandro Tasora

Erwin Coumans · Post by **Erwin Coumans** » Tue Mar 13, 2007 7:23 pm

Bullet 2.46 is now available, and the Sweep and Prune broadphase can be switched to 32bit indices, allowing more objects.

Just enable

Code: Select all

#define BP_USE_FIXEDPOINT_INT_32 1

in Bullet/src/BulletCollision/btAxisSweep3.h

Hope this helps,
Erwin

tasora · Post by **tasora** » Wed Mar 14, 2007 1:56 pm

Hi Erwin!

funny, I was just sending you my modified copy of Sweep
and Prune sourcecode, with a similar conditional switch to
compile with 32 bit indices, and in fact I already made experiments
with it.
Just look at this simulation (which took few hours, mostly because
my LCP solver used 130 steps for good precision). There are
36'000 spheres with friction etc.

http://ied.eng.unipr.it/~tasora/download/reactor_10.avi

Looks like that 32bit indices aren't affecting the performance.
Ok, I'll download Bullet 2.46 and use your 'official' modification.

regards!

Alessandro Tasora

Remotion · Post by **Remotion** » Mon Mar 19, 2007 6:16 pm

Another limitation was reached in btSequentialImpulseConstraintSolver.

Code: Select all

struct	btOrderIndex
{
	short int	m_manifoldIndex; 
	short int	m_pointIndex;
};

#define SEQUENTIAL_IMPULSE_MAX_SOLVER_POINTS 16384
static btOrderIndex	gOrder[SEQUENTIAL_IMPULSE_MAX_SOLVER_POINTS];

This code only allows up to 16384 but in some of my test this limit was reached with crash!

Also to make gOrder static seems to be not really thread safe for me.
Especially in some of my test I am using two or more Bullet instances simultaneous.

Edit: SOLVER_CACHE_FRIENDLY seems to solve this problem becouse solveGroupCacheFriendly() function used instate with dynamic arrays.