Real-Time Physics Simulation Forum

Hi,

a few month ago we started to publish the position-based dynamics code of our latest research projects. You can find the resulting open-source library here:

https://github.com/janbender/PositionBasedDynamics

Current features:

- Physically-based simulation with position-based constraint handling.
- Library supports many constraints: point-point, point-edge, point-triangle and edge-edge distance constraints, dihedral bending constraint, isometric bending, volume constraint, shape matching, FEM-based PBD (2D & 3D), strain-based dynamics (2D & 3D), position-based fluids and position-based rigid body dynamics.
- Simple interface
- Doxygen documentation
- Demos
- Library is free even for commercial applications.

Hope you find some time to try it out,

Jan

Hi Jan,

just wanted to say thanks for sharing this library with the community as it is an excellent piece of source code! I have been implementing PBD stuff for long time by myself for surgical simulation applications. Since the lib was released I am using it as a reference implementation which saves me a lot of time.

Just wanted to ask if there is any roadmap of future improvements? Are you planning maybe a GPU version (using constraints averaging and/or graph colouring)?

If time allows, I plan to release the toolkit for the PBD which I have developed (for Unity3D).

Best wishes

korzen303

Hi,

the next features of the PBD library will be:

- Generic constraints (which are great to test some new constraint functions, you just have to implement the constraint as callback function)
- an OpenMP parallelization of the demos
- demos for collision handling
- a unified solver for rigid bodies, deformables and fluids
- more documentation

Jan

Thanks Jan,

looking forward for the next releases.

Hi Jan I was wondering how appropriate the PBD library would be for engineering analysis. As I understand the speed increase is at a cost for accuracy and that a force based FEM library is better however they are extremely slow and no where close enough to get to real-time analysis which is my goal. So could a model in real time with a realistic material be solved for stress and deformation with realistic results of x percent (meaning what do you think?) of what a traditional FEA solver would produce?

I don't think that position-based dynamics is appropriate for engineering analysis. In PBD the material behavior depends on the number of iterations, the discretization and the time step size. Hence, you won't be able to get accurate results for a specific material. PBD was developed for computer games and special effects, not for accurate simulations. However, why not use FEM with a fast solver. There exist some CG solvers on the GPU which allow to handle several thousand elements in real-time.

I think it's an interesting question whether you can approach engineering-level accuracy given the same amount of computing power. One could just as well run PBD on the GPU (there are loads of parallelization possibilities), so the question is really what is your desired accuracy/speed tradeoff. If you *must* have it fast, then you will need to give up some accuracy.

Jan Bender wrote:In PBD the material behavior depends on the number of iterations, the discretization and the time step size.

I have only done limited experimentation with PBD, so I may not have discovered the true limitations. But I believe you can counteract some of the effects you mention:

• Number of Iterations: If you're simply talking about getting the same stiffness for a different number of iterations, I think Muller covered that in the original PBD paper. Perhaps the bigger issue is that the solving order affects the behavior - one can see this in the rod implementations where they need fancy solving orders to prevent weird oscillations. That issue is definitely going to make serious engineers shake their heads.
• Discretization: Yes, if you simply double the discretization without adjusting the stiffnesses, you'll have a different material. But I *think* there are ways to compute the stiffness to match the desired response by taking into account the discretization.
• Time Step Size: Large time step sizes introduce artificial and uncontrollable damping, this is a real problem but seems to be true of any implicit solver. The only way I see to help is the most obvious (and expensive) solution: reduce the time step size. But note that if you do this, I think you can also reduce the number of iterations.

Again, maybe I'm way off base and not seeing the true limitations. But I think it would be an interesting comparison.