Many constraints or Soft Body Stick field?

User avatar
Dragonlord
Posts: 198
Joined: Mon Sep 04, 2006 5:31 pm
Location: Switzerland

Many constraints or Soft Body Stick field?

Post by Dragonlord »

I've put together for my project what I call "prop fields" to get some nice outdoor scenes going. For that I want the plants to wiggle in the wind. In my first implementation I used my own physics loop after physics detection to determine the wiggling. Now I would like to push this into Bullet as I want to concentrate physics related tasks in this library instead of all over the place ( especially looking at how CUDA can come into play later ). In general this looks like the two sample videos found here. Now I see two ways to do it and I'm not sure which one fits Bullet better.

1) Using one rigid body with one Ball-Socket constraint to limbo.
This can easily produce up to 10K or more bodies and constraints. Chances are this slows down a lot?

2) Using a soft body with ropes similar to the sticks demo but with only 1 segment ( since bending is a render trick in my implementation ).
This would require only one soft body per prop field. But soft bodies are usually slower than rigid bodies. Again this would be a couple of soft bodies with roughly 2-3K sticks each. Can soft body handle this or would it get slow?

3) New typed shape using inner simulation.
The last solution I could think of would be to implement a new typed shape as I did with the height terrain and doing no real constraint solving but tracking the applied forces there doing a sort of small simulation inside the shape. Not sure though if this would be possible. It would though prevent creating many constraints or bodies.

So which solution is most feasible with Bullet given this scenario?
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA

Re: Many constraints or Soft Body Stick field?

Post by Erwin Coumans »

It will probably be best to experiment and compare various solutions.

A soft body stick field seems a good candidate, but don't use 1 stick per soft body. There is a soft body stick field demo, you have tried it?
You will need to customize the implementation probably.

CUDA/OpenCL support will be gradually introduced, including constraint solving kernels. You might want to do the update on GPU indeed.

By the way, cool movie!
Thanks,
Erwin
User avatar
Dragonlord
Posts: 198
Joined: Mon Sep 04, 2006 5:31 pm
Location: Switzerland

Re: Many constraints or Soft Body Stick field?

Post by Dragonlord »

Thought more about using one soft body for one prop field whereas each prop field is usually a patch of 50m times 50m containing roughly 10k instances ( plants ). So this would be 1 soft body with 10k sticks in it. I checked out the sticks demo but did not yet implement anything since I wanted to get an idea on how Bullet copes with large number of constraints. My current implementation runs after the main simulation loop from Bullet but therefore only reacts to force fields ( wind ) but not physical objects. Would be nice if the plants bend also while walking through them to give the player more feedback from the world he moves in.

There's though no need for full blown constraints. The plants only react but never influence other rigid bodies and constraints somehow react on two bodies usually. Thought about some separate simulation code since it is a low importance physics entity which only reacts to the main physics simulation but does not influence it. This would be the same with particle systems. So far in this forum I gathered from he post from various search attempts that there is no particle system implemented. If there would be a particle system of lower priority simulation it could be also used for this scenario. Any plans on implementing such a particle system soon?

Concerning GPU I can't put the stuff there directly. The Graphic and Physics module are separate entities so they communicate over CPU RAM. After all somebody could try using the Bullet Physics module together with some strange Graphic module which is not OpenGL compatible ;)