[Bf-committers] make discussion on cloth simulation public

[bjornmose]

Hi erwin, zaz, genscher, orange team, PR team and anyone who cares

we had quite a lot wind about cloth simulation and how close we are to a 
good solution. ... wind yes! i think at the moment we're far away from 
anything usefull.

quoting erwin on that topic

<quote>
 > Erwin Coumans wrote:
Doing fast stable cloth properly seems to require
1) implicit integration for allowing big timesteps and for 
stability/reproducability.
2) continuous collision detection to avoid missing collisions
That's what papers and some collegues in the industry tell me.
So isnt it just a matter how you want to solve the problem?
Spend time to get heuristics, hacks and work arounds for those issues, 
or spend time to do 1 & 2 properly. (implicit+ccd)
Both approaches are hard work
Erwin
</quote>

this is exacly the conclusion i would expect/share after reading all the 
papers i could grab on cloth simulation.

i'd like to collect some historical facts on softbodies
<history>
1.it was designd to do some nice yelo like giggeling effects for any 
kind of blender object holding vertices, like meshes, curves, lattices 
and i think the 2nd order runge-kutta does a pretty good job on that ( 
and i  remember ton asking : "do we really need to get that 
complicated?" .. knowing what's ahead i insisted on some features .. 
humm .. i consider myself a nice, cooperative guy .. so my answer was, 
kind of : "Not yet but ..." ).

2. kind of experimental i gave it a try on collision detection .. well 
not so bad, if i read some of the posts on elysiun and i guess we'd have 
some few complaining users if we'd remove that. ( it's pretty fast and 
can do a decent job, if you know what you 're doing )

3. it never, ever was designed to do cloth simulation
but to take any blender object defining a vertex/particle in XYZT space 
defining a mass/spring system providing
.(paintable) goals (to model "free" motion vs. "pinned")
. springs (to model particle <-> particle distance preserving dynamics)
but that's it!
</history>

hum .. there's a lot more i could write about ( like how softbodies are 
related to elbeem ) but i think i'd better shut up here.

to conclude:
there is a lot work i see before we have a real good cloth simulator.

Being busy to feed my family would be one of the excuses i could pull 
out the sleeve why i did not do it. However me and i guess erwin, will 
be happy to be a guide to do so.




some older mail traffic .. kind of proof

bjornmose writes:

 > Erwin Coumans wrote:
 >
 >>
 >> Hi,
 >> It sounds you already know pretty much what to do, that's good.
 >>
 >>> My cloth simulator works with any blender mesh, so consider this to 
be a
 >>> mixture of triangles and quads.  Presumably it could be decomposed 
to all
 >>> triangles, if that's a requirement, as we'd have the necessary 
information.
 >>
 >>
 >>
 >> Ah, so moving deformable triangle mesh versus moving deformable 
triangle mesh.
 >> Bullet Collision Detection mainly supports primitive versus static 
triangle mesh.
 >> Primitives are implicit box, sphere, cylinder, cone, capsule, convex 
hull (and more, all of them convex with volume). It does have triangle 
mesh (and AABB tree for acceleration) but not triangle-mesh versus 
triangle mesh (because dynamic moving triangle meshes have other issues 
with rigidbody systems). It might be added in the long term. So it 
doesn't have wait you want.
 >> Solid 3.5 does have deformable triangle-mesh versus triangle mesh, 
including acceleration structure, so that is a good recommendation. 
However triangles are infinitly thin, so 1 triangle falling on top of 
another might easily miss collisions, hence the urge of continuous 
collision detection. Things with volume (like bullet) have some benefits 
there. You could approximate limbs and bones with cylinders, capsules etc.
 >> In Havok we had cloth simulation, and the cloth always collided with 
something that had volume. Even deformable objects in Havok had volume, 
you could always tell wether you are inside or outside.
 >
 >
 > So this is the reason why i took another aproach for SB:
 > having a 'local' definition of 'inside / outside' based on 
faces/triangle normals having a volume ( an extruded prism in negative 
normal direction ) behind the face where the particle must not be --> 
seeing a strong repelling force. However you could as well just move the 
particle right out there .. but then with the current adaptive step size 
solver it should be taken out off the error estimation like full goal 
particles are. Otherways the differential equations become 'stiff' and 
the solver iterates 'for ever'.
 > Well, i never found the time to code a nice 'implicit' solver which 
could deal with 'stiff' conditions nicely. On the other hand i see that 
taking time steps 'too far' increase the probability of missing the 
collision target on a kind of 'tunnel effect' ( see comment in SB code )
 > As you have found out yourself and erwin metioned too, missing 
collisions because of frame to frame timing is one of the mayor issues 
here. Reading SB code you'll find, that goals are interpolated at a 
sub-frame timing. This ensures that goals are not pumping too much 
energy into the system while keeping integration times as low as possible.
 > /*OK i assume the use of a simple forward euler IS evil
 > --> it will explode on 'stiff' conditions for SURE
 > and since we want to pin stuff we are 'stiff'!*/
 > However collision targets now are only known at their current state. 
Doing a linear interpolation trick like for goals won't help much: If a 
colliding plane rotates 90 deg from frame to frame you're *very* likely 
to miss it!
 > My suggestion to heal that would be to take smaller ( subframe ) time 
steps while running the simulation. Be aware! : this needs to update all 
the scene --> reevaluating the depsgraph on subframe time. The solver 
itself will we delighted, since it breaks timing down only if needed to 
meet the error limit. So i guess if you feed it with a 'small enough' 
time step it does not have to break down timing at all and 'll give you 
a response in one iteration step.
 > Well that's theory!
 > In practice you will loose performance by
 > 1. building up the scene at subframes
 > 2. building up collision cache /* SB uses a collision target 
preprocessing and caching which is very close to broadband collision in 
bullet --> using bounding boxes with borders paralell to XYZ on object 
and face level*/
 > Hope i gave you a little insight about why things in SB are coded 
that way
 > Anyhoo feel free to poke me on any question you have
 > and i'd be more than happy to have a good : "stable and fast" cloth 
simulation
 > BM (jens ole wund aka bjornmose)