I'm trying to simulate (in 2d) a capsule (circle-swept linesegment) whose length and radius are subject to physical constraints (i.e capsule can squash and stretch, in response to e.g collision with the environment or other physical constraints) but whose surface area remains the same.

I have a 2d constraint solver, all I need to do is plug in my constraint function and jacobian/gradient; I suspect that one or both of these terms is incorrect, because I'm getting some weird behaviour visually.

The constraint function is:

C(p0,p1,r) = (|p1-p0|*(2*r) + (MATH_PI*r*r)) - A = 0

The partial derivatives I'm using are:

dC/dp0 = -2*r*(p1-p0)/|p1-p0|
dC/dp1 = 2*r*(p1-p0)/|p1-p0|
dC/dr = 2*|p1-p0| + 2*PI*r

Where p0,p1 are the capsule endpoint positions, r is the capsule radius, and A is the desired constant area; A is constant/fixed while p0,p1,r are constrained/adjusted by the solver.

C is just the area of the capsule (a rectangular region and two half-circular regions) minus the desired area, i.e the error vector/delta from the target state to the current state.

My constraint solving process is:

-given a vector of state p = (x0,y0,x1,y1,r)
-calculate C
-calculate J (vector of partial derivatives of C wrt state vector)
-project state: p -= (C/dot(J,J))*J

(I'm omitting mass for simplicity, assume all state variables have e.g unity mass)

Simulating using the above looks okay, but it definitely seems/feels "wrong" somehow; basically as the capsule is stretched, r approaches 0, which means the partial derivatives vanish.

This results in the capsule being hard to squash/stretch when its length is short (i.e radius is large) and very easy to squash/stretch when its length is long (i.e radius is small). Also, when I calculate the partial derivatives numerically (via finite difference), my formula dC/dr seems to always be lower than the correct value by MATH_PI.. so perhaps my jacobian is messed up?

I have a feeling that my utter lack of experience with FEM is part of the problem; intuitively I would like r to "feel heavier" as the capsule is stretched more and more, so that at the limit (capsule length = A, radius = 1) the radius is infinite-mass and the constraint solver only projects the endpoint positions to maintain the constraint.

One thing I don't fully understand is that some constraint formulations use error-squared rather than error; possibly I should use error-squared here? I'm afraid I have very little formal mathematical understanding of constraint solving.

Anyway, if anyone could shed any light on this for me, I'd really appreciate it... I'm a bit lost/in-over-my-head!

thanks,
Raigan

Thanks -- do you know if it would be possible to somehow combine hard constraints (e.g r >= 1, length <= A) or soft constraints (motors driving r, length as you suggested) into this constraint, solving them as a "block" together, or should I just not bother and instead model those additional constraints separately (and "solve" everything via relaxation)?

The main problem I have is the way that, as r goes towards 0, the length of the gradients of p0,p1 go to 0 -- basically the effective mass of the endpoints ends up growing to the point where they stay more or less stationary and r is moved to solve the constraint. The gradients are

Part of my problem is that I don't know what's wrong specifically, just that it feels totally wrong when I drag one of the endpoints around, but I don't know if this is error in the formulas or just that I'm not modelling a behaviour that I should be -- having forces which drive radius and length towards some target is possibly all that's needed.

Basically I have very little idea what I'm doing here, I have a basic geometric understanding of the constraint solving step (moving down the gradient to minimize error) but that's about it...

Hello,

Some time ago we had a "how to make a soft body / blob / slime" discussion that might be of some help to you. There's a link in there to some code samples of soft, deformable bodies with area constraints on them.

http://www.gamedev.net/topic/621866-slime/

cheers,
Mike

Thanks! I'll look through those