[Bf-committers] I'd like to kill the soft body module

bjornmose bjornmose at gmx.net
Thu Mar 4 00:13:09 CET 2010

Hi all,
I was a bit surprised by the responses.
I think the cloth module does all the task the SB module did,  it uses 
the same mathematical/physical model,
but with a smarter UI,  better integration  to the modifier stack, 
better global collision cache, better rock solid ODE solver for stiff 
situations  and more.
Some tiny extra options of doubtable use may be missing or simply need a 
different set up.
However there still is the question:
How to move from SB to cloth with existing files?
Plain and simple: I don't know.
Sufficient to keep the SB module alive. So relax, it will stay until 
progress will force other actions.

Why did I ask for to removing a working feature?
Coders like to look ahead and it looks like  the existing SB module and 
future plans don't go together too well.

Go inside .. or stop reading here :)

Raul Fernandez Hernandez schrieb:
>  I would like not to remove it , just in case it makes more harm than
> good,  is sad to drop countless man/hours, efforts and knowledge, but I
> guess is just me and is only my personal choice.
Well, the mayor issue I see with the module showed up
when I did a review of the code to see how to get the new
2.5 paradigm 'everything can be animated' in there.
By design a lot of properties are evaluated on 'birth' of the soft body.
Purpose was to avoid per vertex look ups during simulation and do 
calculations only once.
Example: the effective goal value is build from vertex groups and goal 
setting which also involves
remapping the slope to [Gmin, Gmax]
Next thing I see in future are lots of bug reports 'animating property 
XYZ in soft bodies does not work' .

Another thing that worries me is that the the internal collision cache 
hooks to the modifier stack in a thread unaware way.
Once the dependency graph  will be used to spread object evaluation to 
parallel tasks I smell trouble there.

My personal opinion is:
While the SB module seems to do no harm and seems to be working with 2.5 
( bad/ good luck ) ,
 it is deprecated and needs a complete rewrite. I did expect it to fail 
with 2.5.
Keeping up the current code will sooner or later be an obstacle to 
further evolution of the animation system.
The rewrite needs to break compatibility with older file versions to 
some extend I can no estimate right now.
Since 2.5 did big quantum leap forward on animation , I thought it might 
be the right time to cut off rotten parts of the tree.


More information about the Bf-committers mailing list