[Bf-committers] make discussion on cloth simulation public
bjornmose
bjornmose at gmx.net
Tue Feb 28 23:05:32 CET 2006
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)
More information about the Bf-committers
mailing list