Shape Matching - weird behaviour

[korzen]

Dear Jan,

I am experiencing a weird random drift-like behaviour when applying external forces to the rigid bodies driven by your shape matching algorithm. I made a short video depicting this problem:

https://www.youtube.com/watch?v=hkFGghmarqM

I double checked my wrapping code and I am 99% it is fine. I am not sure if its a bug in your code or its just the way the shape-matching works.

Thank you in advance for your help

Regards

korzen303

[janbender]

Hi,

in general I think it's not a good idea to simulate a rigid body using shape matching. Why not use a real rigid body? It is computationally less expensive and more accurate.

Even for deformable bodies the FEMTetraConstraint is faster and provides more realisitic results as shown here:

http://interactive-graphics.de/index.php/research/53-position-based-simulation-of-continuous-materials-all

Concerning your question I need some more information. Does this problem only occur if one particle is static? The shape matching code should be correct as I use an adapted version of Matthias Müller. However, I am not sure if his handling of static particles does not introduce artifacts.

Jan

[korzen]

Hello Jan,

thank you for your swift reply. I am developing a framework aimed at
medical simulations in a unified particles fashion. I am experimenting
with shape matching to model surgical instruments such as graspers and
cutters which are approximated by spheres. This simplifies collision
detection and handling etc.

The problem also occurs even if all particles are non-static (2nd part of
the first video). It is more noticeable for some models than others:

https://www.youtube.com/watch?v=QkSa8JfWbRA

I have also made a small demo:

https://drive.google.com/file/d/0B84eAyYvBXSMNXhOZUtDeUxHMkE/view?usp=sharing

Please try dragging the object with MMB with the shape-matching on/off.

If time allows I will try to recreate the scenario using your demo
framework in order to exclude any problems with my code.

Best wishes

Przemyslaw

On Mon, 09 Nov 2015 10:02:59 +0100, Jan Bender notifications@github.com
wrote:

Hi, in general I think it's not a good idea to simulate a rigid body using
shape matching. Why not use a real rigid body? It is computationally
less expensive >and more accurate. Even for deformable bodies the FEMTetraConstraint is faster and provides
more realisitic results as shown here: http://interactive-graphics.de/index.php/research/53-position-based-simulation-of-continuous-materials-all

Concerning your question I need some more information. Does this problem
only occur if one particle is static? The shape matching code should be

correct as I use an adapted version of Matthias Müller. However, I am
not sure if his handling of static particles does not introduce
artifacts. Jan

— Reply to this email directly or view it on GitHub.

Using Opera's mail client: http://www.opera.com/mail/

[janbender]

Hi,

how did you realize the constraint between the simulation model and the mouse cursor?

Jan

[korzen]

Hello Jan,

the mouse drag constraint consists of 3 distance constraints between the
mouse cursor in space and 3 vertices of the dragged triangle. The
influance of each constraint is weighted according to the barycentric
coord of the exact contact point on the dragged triangle. I never had
problems with it.

I did a quick test with dragging by a single vertex rather than the whole
triangle. The problem still holds, seems like large amount of energy is
added to the system due to shape matching. This is much more visible for
some models than others (I think that for elongated models is more
visible, but have not verified it thoroughly yet).

Thanks for your time anyways. I aim to release some code for Unity3D,
hopefully, this year. Will let you know so that you could test it by
yourself.

Best regards

On Thu, 12 Nov 2015 08:09:20 +0100, Jan Bender notifications@github.com
wrote:

Hi, how did you realize the constraint between the simulation model and the
mouse cursor?

Jan

— Reply to this email directly or view it on GitHub.

Using Opera's mail client: http://www.opera.com/mail/

[janbender]

Hi,

do you use several overlapping shape matching region (clustered shape matching)? And if so, do you divide position correction of a vertex by the number of clusters which contain the vertex? This is important since otherwise you add energy to the system. This problem is discussed in the paper of Rivers and James. In our demo we do this in the function ShapeMatchingConstraint::solvePositionConstraint().

Jan

[korzen]

I am not using clustered shape matching. All vertices form a single
cluster.

On Wed, 18 Nov 2015 13:55:03 +0100, Jan Bender notifications@github.com
wrote:

Hi, do you use several overlapping shape matching region (clustered shape
matching)? And if so, do you divide position correction of a vertex by
the >number of clusters which contain the vertex? This is important
since otherwise you add energy to the system. This problem is discussed
in the paper of >Rivers and James. In our demo we do this in the
function ShapeMatchingConstraint::solvePositionConstraint().

Jan

— Reply to this email directly or view it on GitHub.

Using Opera's mail client: http://www.opera.com/mail/

[janbender]

Can you provide me some code? Maybe I can see a problem.

We also checked our shape matching implementation. But it seems to be correct. However, as I mentioned before, I would suggest to use real rigid bodies. If you need points for the collision handling, this can be implemented in a simple way by connecting the points to the rigid body.

Jan