Physics Simulation Forum

Thanks Steve!

I will make some plan/preparation very soon, and you can pick some task you if you got time, that is appreciated!

Also, I leave the difficult work on motors/limits up to Dirk
I prefer working on (continuous) collision detection and improving the performance and overal programmability etc. Adding the current sequential impulse solver with constraints was enough fun in that area.

Thanks,
Erwin

The first step in refactoring is committed.

http://continuousphysics.com/Bullet/php ... .php?t=553

Source code moved to src, 2 new headerfiles for convenience, only the src folder needs to be included in projects (instead of 3 path before, LinearMath, Bullet, BulletDynamics now becomes src).

The files in BulletCollision and BulletDynamics have bt prefix. Other files in Demos and Extras folder should not be touched, they are not part of the library. LinearMath still has prefix Simd and Gen, but some files have been moved away etc.

Erwin

I'm surprised that the "Extras/PhysicsInterface" stuff isn't a part of the 'main' package (and hence will be missing the 'bt' prefix).

Those functions aren't demos - they are actually needed - and as far as I can tell, the code doesn't come from someone else's library like the COLLADA and LibXML stuff.

Is there a case for moving them into the new 'src' area?

This CcdPhysicsEnvironment and CcdPhysicsController are experimental mainloops. I am hoping to add TimeWarp or other timestepping algorithms that take time of impact into account. There is also a ParallelPhysicsEnvironment, heading for multi-core. The history of those files is a physics-engine-independent interface. It was used abstracting Havok, Ageia, Mathengine, ODE, Dynamo, Sumo, Bullet etc. Please ignore it for now, and focus on BulletCollision and BulletDynamics.

I will add a DiscreteDynamicsWorld in BulletDynamics very soon. Then all demos will use this, except for some the 'continuuos collision detection, research demo. Once I'm happy with the quality of time-of-impact based physics, I will add a ContinuousDynamicsWorld to BulletDynamics.

So please ignore Demos and Extras in the refactoring, apart from getting it to compile obviously , just tackle the src folder. I will get in touch about the details, it would be useful if you can help.

Thanks,
Erwin

I started working on replacing CcdPhysicsEnvironment with a direct version inside BulletDynamics.

Its objects are just RigidBody, and CollisionShapes.

See http://svn.sourceforge.net/viewvc/bulle ... iew=markup for a sneak preview.

Next to btSimpleDynamicsWorld, a btDiscreteDynamicsWorld and byContinuousDynamicsWorld will be added.

ok, most of the issues have been address hopefully.

Here is a new release with lots of refactoring...
http://www.continuousphysics.com/Bullet ... .php?t=560

The CcdPhysicsEnvironment is now obsolete, and replaced by btDynamicsWorld derived classes.

I thought of starting another topic but maybe it should be adressed here.

How about deallocation of stuff ? I don't think I've seen a demo that deallocates anything. Miraculously I see that I first have to remove the ccdphysics controller from the enviroment in order to delete it's shape and then the object and even so, VC8 shows me a ton of memory leaks and it's not from my code (i'm having cases when I don't use it). Could there (ever) be 2 easy functions like : Enviroment->ClearPhysicalObjects and DeleteEnviroment ? or something like that.

The CcdPhysicsEnvironment and CcdPhysicsController are obsolete and will be erased from the project. They have been replaced by btDiscreteDynamicsWorld. It's just that not all demos are updated yet (I preferred to get the release out first).

Proper memory handling, including custom memory allocators and reference counting is on the todo list. I will add a demo with a custom memory allocator that keeps track of all allocations, to make sure no leaks happen.

Bullet uses this memory rule: you are responsible to destroy what you construct (*).
Do you have any trace of a memory leak, which violate this rule?

Thanks!
Erwin

(*) Bullet has no reference counting yet, but for reference counted objects are an exception to above rule: reference-counted objects will self-destruct as soon as there are no refences to it (its reference count becomes zero)

With this initialization



and just one deallocation



gives this


I guessed that the enviroment self deallocates the Broadphases and all that stuff inside it, guess not ?

EDIT:cleaned unused code

This can be misleading in my oppinion.
When you construct the DynamicsWorld you provide pointers to different stuff that YOU have allocated, yet the destructor of DynamicsWorld deletes it by itself.
At least that is how I understand it.

As Erwin stated. You are responsible for what you allocate. Normally you simply deallocate in opposite order and IMO this is a very practical solution Erwin uses here. Maybe Erwin should consider to explecitely point out that the Environment class doesn't take the ownership of the passed objects.

Then you understand it wrong. If I create the Dispatcher with placement new and use a special allocator, how should the Envirnment know about this. You can't simply call delete since you don't know how the object was constructed.

Am I looking in the wrong place?

This is indeed misleading and IMO this isn't correct. Bullet doesn't know how the object was created and therefore shouldn't destroy the object. Actually this is totally opposite to what Erwin wrote before. Maybe he will comment this himself. The rule of thump is: "Who creates the object should also destroy it".

Erwin:
For the referenced counted objects you should consider to pass an optional deleter function.

You are looking in the wrong place. On my harddrive is Bullet 2.11 which checks a boolean for ownership.

If the user passes it in, it is false and the user needs to delete it.
Otherwise, the btDiscreteDynamicsWorld calls a different constructor, and that ownership boolean is true, in which case the destructor deletes it.

There are no reference-counted object yet. As I mentioned before, memory management, custom allocators and reference counting is on the todo/work in progress. So don't make conclusions about memory management, until this is done