preparing for 2.82 release

[Erwin Coumans]

Just to let you know:
I am applying processing some issues from the issue tracker, apply some patches, and prepare for a Bullet 2.82 release.

It is mostly bug fixes, because I have been working on Bullet 3.x mainly (at http://github.com/erwincoumans/bullet3) and Bullet 3 is making good progress on GPU.
Thanks,
Erwin

[Epileftric]

Just curious, what language are you using for GPU access?

[Erwin Coumans]

OpenCL is used for the GPU, it is pretty much a subset of C, C99.

I'm organizing the code so that most of the implementation can be shared with regular CPU code, and possibly DX11 DirectCompute or CUDA.

[Epileftric]

OpenCL is used for the GPU, it is pretty much a subset of C, C99.

I'm organizing the code so that most of the implementation can be shared with regular CPU code, and possibly DX11 DirectCompute or CUDA.

Is it possibly to implement it in Cg so that it is architecture free? Just asking, I was about to start learning and coding my project in Cg till I found this library...

[Erwin Coumans]

Cg is not generic enough to develop general purpose collision detection and constraint solver. You could use Cg for a simplified implementation.

What do you mean by "architecture free"? OpenCL works on NVIDIA, AMD and Intel GPUs on all operating systems.

[Epileftric]

Cg is not generic enough to develop general purpose collision detection and constraint solver. You could use Cg for a simplified implementation.

What do you mean by "architecture free"? OpenCL works on NVIDIA, AMD and Intel GPUs on all operating systems.

and also works on ARM gpus, Idk i guess i meant to make stand alone from any lib... but that doesn't make any sense.

[Mako_energy02]

Erwin,

Do you have a change list for 2.82 yet or is that still in progress?

Aside from the GPU pipeline, do you have a change list for Bullet 3?

Also in Bullet 3 is the GPU pipeline going to be the only supported pipeline or is it an upgrade of Bullet 2 with added GPU support?

[Erwin Coumans]

Erwin,

Do you have a change list for 2.82 yet or is that still in progress?

I am still reducing the long list in the issue tracker, before making a Bullet 2.82 release.
The change log is basically the commit messages here, from SVN revision 2613 (Bullet 2.81) until now.
See https://code.google.com/p/bullet/source/list

Aside from the GPU pipeline, do you have a change list for Bullet 3?

Also in Bullet 3 is the GPU pipeline going to be the only supported pipeline or is it an upgrade of Bullet 2 with added GPU support?

Bullet 3.x will be a OpenCL GPU-only pipeline, for the first releases. If you need a CPU pipeline, you use Bullet 2.x. Note that Bullet 2.x and 3.x can co-exist in the same binary, there are no naming/linking conflicts.

You can track progress through the commits to Bullet 3.x here: https://github.com/erwincoumans/bullet3/commits/master

[IresomPCH]

Will the Featherstone Solver be added in this release?
looking forward to it~

[Erwin Coumans]

I am looking at the moment if I can add a preview of the Featherstone implementation into Bullet 2.82.

If I can do a basic integration with the Bullet constraint solver for contacts/limits, and I can create a basic sample, I may do it.

Thanks,
Erwin

[Basroil]

I am looking at the moment if I can add a preview of the Featherstone implementation into Bullet 2.82.

If I can do a basic integration with the Bullet constraint solver for contacts/limits, and I can create a basic sample, I may do it.

Thanks,
Erwin

Would this mean the implementation would work with motor joints but not with sleeping? If sleeping is the only thing keeping it from being something other than preview then I'm sure you won't get any complaints After all, if you need featherstone then sleeping is usually a far less important thing.

Look forward to finally having an implementation, it'll help some of my old projects be much more stable.

[Jonathan]

Bullet 3.x will be a OpenCL GPU-only pipeline, for the first releases. If you need a CPU pipeline, you use Bullet 2.x. Note that Bullet 2.x and 3.x can co-exist in the same binary, there are no naming/linking conflicts.

You can track progress through the commits to Bullet 3.x here: https://github.com/erwincoumans/bullet3/commits/master

Since Bullet 3.x won't have a CPU pipeline for the first releases (is it eventually planned?), will Bullet 2.x continue receiving improvements alongside 3.x?

[Erwin Coumans]

I do spend some time processing the issue tracker, so bug fixes and improvements by users will still improve Bullet 2.x

For the Bullet 2.82 there are various bug fixes, and preliminary support for Featherstone btMultiBody, using reduced/general coordinates.

Would this mean the implementation would work with motor joints but not with sleeping?

This is a new Featherstone implementation, that has not been discussed before. I am currently integrating it into Bullet 2.x. I might be able to enable 'sleeping' for btMultiBody. The first version might not have all constraints/motors implemented yet.

[Erwin Coumans]

I am close to the Bullet 2.82 release, this week: some testing, documentation update and a demo for the new MLCP solver.

The btMLCPSolver is a replacement for the btSequentialImpulseConstraintSolver, that explicitly creates the full MLCP A matrix and b vector.
You can use PGS, Lemke, Dantzig or PATH solver . If the MLCP solver doesn't produce a result, there is an automatic fallback to the original btSequentialImpulseConstraintSolver.

Here is an example how to use it:

Code: Select all

bool useSI = false;
btConstraintSolver* sol = 0;
if (useSI)
{
sol = new btSequentialImpulseConstraintSolver;
} else
{
//choose the actual MLCP backend
// btDantzigSolver* mlcp = new btDantzigSolver;
//btSolveProjectedGaussSeidel* mlcp = new btSolveProjectedGaussSeidel;
btPATHSolver* mlcp = new btPATHSolver; 
sol = new btMLCPSolver(mlcp);
}
 m_constraintSolver = sol;

 m_dynamicsWorld = new btDiscreteDynamicsWorld(m_dispatcher,m_overlappingPairCache,m_constraintSolver,m_collisionConfiguration);

 //the MLCP solvers don't support split impulse yet
m_dynamicsWorld->getSolverInfo().m_splitImpulse=false;

It is the first introduction of the btMultiBody (Featherstone) and btMLCPSolver to Bullet, we will improve the implementation in upcoming releases. I have some more MLCP solvers (Lemke, COMPASS etc) that are not ready for release yet. Another idea to explore is to allow fine-grain control when a certain MLCP solver is used (when large mass rations are detected for example, or when strong motors are needed), per simulation-island for example.

[Basroil]

I am close to the Bullet 2.82 release, this week: some testing, documentation update and a demo for the new MLCP solver.

The btMLCPSolver is a replacement for the btSequentialImpulseConstraintSolver, that explicitly creates the full MLCP A matrix and b vector.
You can use PGS, Lemke, Dantzig or PATH solver . If the MLCP solver doesn't produce a result, there is an automatic fallback to the original btSequentialImpulseConstraintSolver.

It is the first introduction of the btMultiBody (Featherstone) and btMLCPSolver to Bullet, we will improve the implementation in upcoming releases. I have some more MLCP solvers (Lemke, COMPASS etc) that are not ready for release yet. Another idea to explore is to allow fine-grain control when a certain MLCP solver is used (when large mass rations are detected for example, or when strong motors are needed), per simulation-island for example.

This is an amazing addition to Bullet, perhaps more useful than GPU only acceleration, at least for robotics. With this, I can see more people moving towards Bullet within my lab, since some wanted a worldstep equivalent. On the topic of robotics, since Bullet doesn't have a (documented) motorized joint with friction, I am currently using an overconstrained joint comprised of two motor joints (one with target speed and torque, other with target zero velocity and some friction torque value, not ideal but gives physically accurate results for the simple robots I tried it on). Would this still be possible in the current implementations of featherstone and the alternative solvers? From what I can find, the joint stacking works just fine in the sequential impulse solver because both motors are never solved at the same time, but since the solving method is different, other solvers may give odd results right?

And +1 to per-island solving, could be a good mix between accuracy and speed, especially when mixing things like robots and moving environments (a box on a box is just an obstacle, but a box touching a robot is important data )