Memory Usage - console issues

[MatthewHarmon]

I was wondering if anybody familiar with Bullet could give me a quick heads-up as to some memory-related issues.

We are currently using ODE, but looking at Bullet partly as a speed boost, and partly in the hopes that it is a little more "predictable" in its memory allocation strategy.

Specifically, ODE likes to use realloc() quite a bit to resize buffers (up and down). This ain't so great on systems without a virtualized address space, and we're worried about fragmentation.

Does anybody have experience with this? I'll look through the code but some real-world advice here could save me some time

Thanks!

[yassim]

I've been doing a bit of bullet work with our current tech (which is 360, ps2, wii, pc (sorry, nothing released with bullet in it yet..)) and some new stuff.

We use our own rolled allocators, and that was easy enough to get bullet using.
To get bullet using your allocators you need to give it call backs to use.
You set them through.
btAlignedAllocSetCustomAligned and btAlignedAllocSetCustom
which are declared in bullet\src\linearmath\btalignedallocator.h

Bullet only seems to use malloc and free.

I also didnt need concave shaps so I nerfed the btStackAlloc * m_stackAlloc in btDefaultCollisionConstructionInfo (bullet\src\bulletcollision\collisiondispatch\btdefaultcollisionconfiguration.h)
the HACK i used was in the default constructer, setting it to 1. ( yep :m_stackAlloc( (btStackAlloc*)1 ), //nasty as hell )

Bullet though it had been handed one and so did not construct its own. (which takes about 5 meg)
It would also then crash on me when it tried to use it.
At the time the only use for it I could find was the GJK(?). As I didn't use concave shapes, no crash.
NOTE: this was not full tested by any streach of the imagination.
Better would be top reduse the number of contact pairs (other posts have that detail) and or tune the m_defaultStackAllocatorSize to what you need.

Hope this helps.

[AlexSilverman]

yassim,

I'm curious why you didn't just change the stack allocator size in the btDefaultCollisionConstructionInfo structure, then pass that to the btDefaultCollisionConfiguration constructor, rather than hacking a fix in and working around the resulting crashes? This seems a preferable fate. You could set it to 1 byte or something (I'm not sure what setting the size to 0 would do), so the memory loss is minimal, and you don't need to worry about Bullet using an invalid pointer.

- Alex

[yassim]

Fair question.

Orginally, I was trying to confirm what it was being used for.

I had already done various searches and traces, but what I've found from using various middel ware is thats not always enough.
So If I have a reasonable debug enviro, I set the object in question to crash horribly if ever used.
Using 1 for a class like this should pass by null checks, but exception horribly when called on becasue the 'this' pointer is not aligned correctly.

Its a cheep trick, but *should* always work. (though I'm sure there are cases where it wouldn't and would just cause strange things (tm) )

[josemarin]

If you know exactly how many objects your simulation will use, it´s possible to set Bullet to use the minimum required memory?

[yassim]

Short answer, probably.

A few of the factors for that answer would be.
* what type shapes are you using?
* for some shapes, how big are they? (or better, how many contact points can they genorate.)
* how many are static.

Its also a question of where are you drawing the line in the accounting?
* Are the shapes your using in Asset memory and Bullets.
* Where are the collision entitys?

I think your best bet is to instrument bullets run time allocators for things like contact points and such for a instrumented build.
Take a read of what you are using, then set it to those numbers (plus say 5%) for your release.

[AxeD]

Hi there,
I'm fighting with bullet on a Wii. All i can say is, just try to create collision object from primitives. It work really fast.

Best regards