Find out which particle group to attach with the ObiParticleAttachment

[josemendez]

Hello, I looked at the DeformationToColors.cs script, and as you said it only shows how to get the scalar part of the deformation. What I care more is actually the direction, if I want to get the direction in which a particle is being "pulled" from its surrounding particles, do I look at the particles that are within the same "cluster"? Is there a way to access the cluster data of a soft body actor?

You can access the cluster data for any particle in a softbody. The DeformationToColors.cs script does this, like so:

Code:

for (int k = 0; k < batch.numIndices[i]; ++k)
                    {
                        int p = batch.particleIndices[batch.firstIndex[i] + k];
                        int or = softbody.solverIndices[p];
                        if (softbody.solver.invMasses[or] > 0)
                        {
                            norms[p] += deformation;
                            counts[p]++;
                        }
                    }

This loop iterates trough all particle indices in each cluster, and accumulates the deformation for each one. See:
http://obi.virtualmethodstudio.com/manua...aints.html

As well as the ObiShapeMatchingConstraintsBatch class in the API docs:
http://obi.virtualmethodstudio.com/api.html

However you seem to operate under the assumption that particles pull from each other as if linked by springs or some similar directional constraint, which is not the case.

Particles are part of one or more clusters. Every frame for each cluster, a 3x3 covariance matrix (see: https://www.visiondummy.com/2014/04/geom...ce-matrix/) is calculated and then SVD (singular value decomposition, that is eigenvector/eigenvalue extraction) used to determine the optimal rotation for each cluster that best preserves its original shape. The different target positions defined by each cluster a particle belongs to are then averaged, and the particle placed there. No explicit forces are calculated anytime during the algorithm, not directions or magnitudes. The deformation value you can extract from each 3x3 matrix is actually a measure of the algorithm's error, and will vanish with enough iterations applied. You simply can't get the information you need from shape matching.

I'm currently working on simulating penetrating a soft body using another rigid object or an Obi rope. I want to simulate the movement of the point of penetration on the soft body along the object that's penetrating it, and my current plan is to set up a bunch of attaching positions on the penetrating object, then analyze the "force" that's currently "pulling " on the particle which is going to be attached on one of those attaching positions, and decide which direction the attached particle should move towards. Do you think this is a good way to approach this situation? Or Obi has a more built-in solution for this type of simulation?

Sounds like you're trying to implement suture constraints of some sort, making a thread penetrate the softbody at some point and stay there during simulation. You face several challenges here:

First, Obi is a particle-based engine. Laws of motion are solved in a discrete manner, which means physics is only solved at each particle's position. Furthermore, shape-matching is a meshless algorithm, which means particles are treated as a point-cloud with no underlying topology or structure. Both these traits mean that it's very difficult to measure any physical property at points that do not coincide with a particle. So if you had for instance a flat, grid-like surface sampled with particles, you could only measure position/velocity/etc at the particle's locations. There's no simple way to interpolate data in-between particles, unlike there is in other algorithms where you have explicit connectivity that allows you to use linear/barycentric interpolation (tetrahedral-based FEM for instance, which is the most often used method for medical skin/organ simulation).

Second: using forces for this is not a good idea, since you're working against the engine. Obi is a position-based solver, no forces are used anywhere. Your case would be best implemented as a position-based constraint, however that requires you to be familiar with position-based dynamics and Obi's architecture. I'd recommend reading some articles on position-based dynamics (XPBD). The references section in Obi's webpage contains a large list of research articles that might be helpful:
http://obi.virtualmethodstudio.com/references.html