Can I reuse these Parameters when I make new DynamicsWorld?

Post Reply
kcjsend2
Posts: 15
Joined: Wed Jun 30, 2021 9:10 am

Can I reuse these Parameters when I make new DynamicsWorld?

Post by kcjsend2 »

hello.

Code: Select all

	mBtCollisionConfiguration = std::make_unique<btDefaultCollisionConfiguration>();

	mBtDispatcher = std::make_unique<btCollisionDispatcher>(mBtCollisionConfiguration.get());

	mBtOverlappingPairCache = std::make_unique<btDbvtBroadphase>();

	mBtSolver = std::make_unique<btSequentialImpulseConstraintSolver>();

	mBtDynamicsWorld = std::make_unique<btDiscreteDynamicsWorld>(mBtDispatcher.get(), mBtOverlappingPairCache.get(), mBtSolver.get(), mBtCollisionConfiguration.get());
I'm trying to make few number of dynamics world, but I can't sure i can reuse these parameters. (configuration, dispatcher, solver)
If I have to create another dynamics world object, do I have to create a new parameters?
User avatar
drleviathan
Posts: 849
Joined: Tue Sep 30, 2014 6:03 pm
Location: San Francisco

Re: Can I reuse these Parameters when I make new DynamicsWorld?

Post by drleviathan »

CollisionConfiguration = yes it is possible but depending on what you're doing you might not want to. If you look at the declaration of the base btCollisionConfiguration interface you'll see the only thing its API requires is that the configuration manage some memory pools. Meanwhile the btDefaultCollisionConfiguration has a hard-coded memory pool size of 4096 elements for each of its two pools. If you were to share between multiple worlds you might hit the pool limits. If you're running many small (e.g. few objects) worlds then maybe you could get by with just one configuration for all of them.

Meanwhile, there is some benefit to maintaining good memory "residency". If you were to make a GiantCollisionConfiguration class and step each world sequentially in a single thread the worlds would scatter their allocations across the big collective pools and you might actually get better performance by keeping each pool smaller and perform less thrashing of CPU memory caches.

Here is an idea: measure how much of the pools your worlds are consuming and then implement TunedCollisionConfiguration which is a straight copy of btDefaultCollisionConfiguration but with smaller pool limits that still satisfy your expected worlds' needs.

btDefaultCollisionConfiguration is not thread-safe so you wouldn't be able to share it between worlds running on different threads.

Dispatcher = no, definitely not.

OverlappingPairCache = no, no definitely not.

Solver = yes this is possible. The btSequentialImpulseConstraintSolver maintains some "pools" but they are actually unbounded btAlignedObjectArray<T> instances so you don't have to worry about hitting limits. They expand as necessary but do not release memory: when there are piles of objects colliding all at once the pools grow to accomodate and then they keep their sizes in case there is a similar event in the future. It is possible sharing one of these could save you some memory. Nevertheless, the concern of thrashing the CPU memory caches could actually hinder the speed of the simulation algorithms. You's have try both ways to measure the tradeoffs. Not thread-safe.
Post Reply