16 minutes ago, Fulcrum.013 said:

or interpenetration elimination algo bring a additional energy to systems.

Yes this is my problem. I use capsules, scaled down along their axis so the spherical cap becomes more flat to approximate skin curvature. The capsules are long so they go deep under the skin. Cloth penetration is always resolved along the axis of the capsule they intersect. When the character bends the knee, the capsules form self intersection and trapped cloth vertices penetrate with many capsules. Because of the naive penetration resolve they do not converge, even if i use the average of all resolved positions.

The second problem is when cloth points get stuck in the sink formed by adjacent capsules, the average of all resolutions may project the point outside the collision shapes, adding energy, and doing it serially my project it inside a neighboring capsule, so adding energy in the next step.

Maybe i can improve this by considering velocities when choosing the resolving direction, but likely the problem can never be solved completely. The right way would be to use the skin triangles, but that's more expensive and skin self intersection would cause much worse behavior. Also it becomes difficult to resolve properly when the cloth point is deep inside the skin, you would want something like tetrahedrons to represent in/outside robustly. So my system ends up more robust in practice even i do it wrong. It's just cloth simulation, so a graphical effect and i allow myself to cheat here. You really need to zoom in to detect the jitter - it's acceptable, but i still always see jitter as a proof of my failure. 

Avoiding penetration completely would be totally unpractical for cloth - too small timesteps, how to deal with self intersection?... would never work robustly under realtime constraints i think.

But cloth sim is not really my priority - did it just for fun, likely i'll never use it...

2 minutes ago, Dirk Gregorius said:

This is clearly wrong! Angles are not preserved under non-uniform scaling. The  closest point to a circle is not necessarily the closest point to an ellipse after re-scaling back!. See example below. 

I think he meant tracing a ray here, not to find the closest point.

Even in that case it is not as trivial as just non-uniformly scaling back and forth between sphere and ellipse space. IIRC the trick for tracing a ray is to scale around the center of the ellipse since the center of scaling matters. The bottom line is that non-uniform scaling does not preserver angles so you need to be careful when transforming to sphere space.

9 minutes ago, Dirk Gregorius said:

Even in that case it is not as trivial as just non-uniformly scaling back and forth between sphere and ellipse space. IIRC the trick for tracing a ray is to scale around the center of the ellipse since the center of scaling matters. The bottom line is that non-uniform scaling does not preserver angles so you need to be careful when transforming to sphere space.

For collision it does work however which is what he was referring to.  In reality you don't really have to scale much of anything back . You just save your original geometry.

3 hours ago, Gnollrunner said:

In reality you don't really have to scale much of anything back

I see, you are saying something like this:

1) Translate into origin, rotate to align with principal axes, scale to unit sphere

2) Apply same transform to ray

3) Compute t in unit sphere space

4) Compute intersection point in ellipse space - simply evaluate original (un-transformed) ray equation using the same t

5) Compute intersection normal in ellipse space - simply use ellipse gradient at intersection point

I see that this might work, but my original point was *only* that you need to be careful with non-uniform scale and collision detection. As an example I used the closest point test. Before I would use this I would simply compute the intersection by plugging the parametric ray equation into the implicit ellipse equation and try to show that both are equivalent. 

5 hours ago, Dirk Gregorius said:

I see, you are saying something like this:

1) Translate into origin, rotate to align with principal axes, scale to unit sphere

2) Apply same transform to ray

3) Compute t in unit sphere space

4) Compute intersection point in ellipse space - simply evaluate original (un-transformed) ray equation using the same t

5) Compute intersection normal in ellipse space - simply use ellipse gradient at intersection point

 

I see that this might work, but my original point was *only* that you need to be careful with non-uniform scale and collision detection. As an example I used the closest point test. Before I would use this I would simply compute the intersection by plugging the parametric ray equation into the implicit ellipse equation and try to show that both are equivalent.

For ellipse to mesh collision you don't really need to be so careful. I'm just saying his statement was not really "false" in the context he used it. Basally once your ellipse becomes a sphere, you are just doing sphere to mesh collision. The response is calculated as a sphere and so forth.  There is not really a lot of scaling back and forth. You can even just scale your whole geometry up front and leave it that way.  Now if you are trying to do other calculations, then yes, you have to be careful but if you are simply doing character to world collision, especially in a flat world, then it's pretty straight forward.  I get the impression this technique is pretty common and I even tried it myself at one point, but settled on stacked spheres, although I'll probably use a pill now.

17 hours ago, Gnollrunner said:

You can even just scale your whole geometry up front and leave it that way.

Yeah, e.g. Quake did this. The player was a sphere and the collision geometry was inflated (Minkowski sum) by the sphere radius so at run-time the player movement involved only point to plane tests. Note that this didn't mean they just scaled the render geometry, but they also needed to add new geometry (e.g. sweeping around corners - It is called bevel planes in the map files iirc.). Mathematically it is more of Minkowski addition than scaling.