Find out which particle group to attach with the ObiParticleAttachment

[snowtv]

Trying to attach specific particle to another object, but looks like it's only possible to attach a particle group to an object?

So I'm assuming that a particle can be included by multiple groups, so how do I know which group is the most accurate representation of the target particle?

[josemendez]

Trying to attach specific particle to another object, but looks like it's only possible to attach a particle group to an object?

So I'm assuming that a particle can be included by multiple groups, so how do I know which group is the most accurate representation of the target particle?

You define particle groups yourself, using the blueprint editor. Each group can be one particle, or multiple ones, and there's no restriction on which particles might be part of which groups.

However when a particle is part of multiple attached groups, the outcome is undefined. Quoting the manual page for attachments:
http://obi.virtualmethodstudio.com/manua...ments.html

Particles affected by more than one attachment will follow the attachment that was updated last. The update order for attachments is undefined.

[snowtv]

You define particle groups yourself, using the blueprint editor. Each group can be one particle, or multiple ones, and there's no restriction on which particles might be part of which groups.

However when a particle is part of multiple attached groups, the outcome is undefined. Quoting the manual page for attachments:
http://obi.virtualmethodstudio.com/manua...ments.html

Thanks for the answer. If I don't want to go through the hassle of creating many particle groups, is it possible to create an ObiParticleAttachment that only attaches one particle to the designated object? Or maybe there is another class for attaching a single soft body particle to another object?

I have another question, is it possible to read the total force that's currently applied on a soft body particle from its surrounding particles? You are using your own physics engine so I'm assuming I can?

[josemendez]

Thanks for the answer. If I don't want to go through the hassle of creating many particle groups, is it possible to create an ObiParticleAttachment that only attaches one particle to the designated object?

Attachments work on particle groups, they can't work on individual particles. This being said, creating one particle group per particle is a perfectly valid approach. You can do this programmatically if you don't want to do it by hand in the editor.

Or maybe there is another class for attaching a single soft body particle to another object?

There's at least two other ways to attach particles: set their inverseMass to zero (disables dynamics) and then set their position to whatever value you desire:
http://obi.virtualmethodstudio.com/manua...icles.html

or add pin constraints:
http://obi.virtualmethodstudio.com/manua...aints.html

See for instance the sample /Obi/Scripts/Common/Utils/ObiContactGrabber.cs script: it uses the first approach to attach particles to objects they collide with.

I have another question, is it possible to read the total force that's currently applied on a soft body particle from its surrounding particles? You are using your own physics engine so I'm assuming I can?

Obi is a position-based engine, so internally no forces are used. Shape-matching in particular (the algorithm used for softbody simulation) works with deformation tensors. Each particle and its close neighbors are considered a shape-matching cluster, the algorithm strives to keep the rotationally invariant shape of each of these clusters during simulation. The deformation for each cluster is stored as a 3x3 matrix. For more info: https://matthias-research.github.io/page...ticles.pdf

You can get the 3x3 deformation matrix for each shape matching cluster, and use its trace as a scalar measure of deformation. See the included "DeformationGradient" sample scene: it maps deformation to a vertex color gradient for visualization.

[snowtv]

Attachments work on particle groups, they can't work on individual particles. This being said, creating one particle group per particle is a perfectly valid approach. You can do this programmatically if you don't want to do it by hand in the editor.


There's at least two other ways to attach particles: set their inverseMass to zero (disables dynamics) and then set their position to whatever value you desire:
http://obi.virtualmethodstudio.com/manua...icles.html

or add pin constraints:
http://obi.virtualmethodstudio.com/manua...aints.html

See for instance the sample /Obi/Scripts/Common/Utils/ObiContactGrabber.cs script: it uses the first approach to attach particles to objects they collide with.


Obi is a position-based engine, so internally no forces are used. Shape-matching in particular (the algorithm used for softbody simulation) works with deformation tensors. Each particle and its close neighbors are considered a shape-matching cluster, the algorithm strives to keep the rotationally invariant shape of each of these clusters during simulation. The deformation for each cluster is stored as a 3x3 matrix. For more info: https://matthias-research.github.io/page...ticles.pdf

You can get the 3x3 deformation matrix for each shape matching cluster, and use its trace as a scalar measure of deformation. See the included "DeformationGradient" sample scene: it maps deformation to a vertex color gradient for visualization.

Sounds great, I'll try those out!

[snowtv]

Attachments work on particle groups, they can't work on individual particles. This being said, creating one particle group per particle is a perfectly valid approach. You can do this programmatically if you don't want to do it by hand in the editor.


There's at least two other ways to attach particles: set their inverseMass to zero (disables dynamics) and then set their position to whatever value you desire:
http://obi.virtualmethodstudio.com/manua...icles.html

or add pin constraints:
http://obi.virtualmethodstudio.com/manua...aints.html

See for instance the sample /Obi/Scripts/Common/Utils/ObiContactGrabber.cs script: it uses the first approach to attach particles to objects they collide with.


Obi is a position-based engine, so internally no forces are used. Shape-matching in particular (the algorithm used for softbody simulation) works with deformation tensors. Each particle and its close neighbors are considered a shape-matching cluster, the algorithm strives to keep the rotationally invariant shape of each of these clusters during simulation. The deformation for each cluster is stored as a 3x3 matrix. For more info: https://matthias-research.github.io/page...ticles.pdf

You can get the 3x3 deformation matrix for each shape matching cluster, and use its trace as a scalar measure of deformation. See the included "DeformationGradient" sample scene: it maps deformation to a vertex color gradient for visualization.

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?

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?

[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

[snowtv]

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.


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

Thank you for the directions. I have another question, what is the best way to configure a soft body blueprint so it has different particle density in different regions? I know that you can manually remove particles after the auto-generation, but I don't know how to edit the cluster range. For example, if I want half of the soft body to have half as dense particles compare to the other half, if I set the cluster radius to fits the less dense half (which will be larger), it will work well with the less dense half, however the more dense half will have more cluster connections than desired. And if I set the cluster radius to be smaller to fit the denser half, then when I remove particles for the less dense half, the cluster radius won't be large enough for the less dense particles.

Currently I'm thinking about creating multiple pieces of the soft body, each have their own particle density configuration, then attach them together to form one larger soft body, but this just doesn't feel like an ideal approach.

[josemendez]

Thank you for the directions. I have another question, what is the best way to configure a soft body blueprint so it has different particle density in different regions? I know that you can manually remove particles after the auto-generation, but I don't know how to edit the cluster range. For example, if I want half of the soft body to have half as dense particles compare to the other half, if I set the cluster radius to fits the less dense half (which will be larger), it will work well with the less dense half, however the more dense half will have more cluster connections than desired. And if I set the cluster radius to be smaller to fit the denser half, then when I remove particles for the less dense half, the cluster radius won't be large enough for the less dense particles.

You can't use different resolutions for different parts of a softbody. The reason for this is that it would yield different physical behavior in different parts of the mesh due to different discretization of the space, which is pretty much always undesirable: zones with more particles would be more compliant (elastic) than zones with less particles.

If you really want to do this despite the drawbacks, keep in mind you can use completely different meshes for blueprint generation and rendering. See:
http://obi.virtualmethodstudio.com/manua...inner.html

So a relatively easy approach to do what you want would be authoring a mesh that's similar to the other you're rendering, but distribute vertex density differently throughout the mesh. Use this mesh for blueprint generation. Then use a small particle size when generating the blueprint, such that one particle is generated for each vertex in your mesh. This will take care of vertex density, however cluster radius will still be homogeneous throughout the mesh so certain zones will have a denser cluster network. This is actually a good thing as it reduces simulation dependency on discretization (regions with more particles are more densely interconnected, which compensates for decreased convergence).

If this doesn't do the job for you, you also have the option of deriving ObiSoftbodyBleuprintBase and creating your own blueprint generator. It's more work, but allows you to create particles and constraints any way you need.

[snowtv]

You can't use different resolutions for different parts of a softbody. The reason for this is that it would yield different physical behavior in different parts of the mesh due to different discretization of the space, which is pretty much always undesirable: zones with more particles would be more compliant (elastic) than zones with less particles.

If you really want to do this despite the drawbacks, keep in mind you can use completely different meshes for blueprint generation and rendering. See:
http://obi.virtualmethodstudio.com/manua...inner.html

So a relatively easy approach to do what you want would be authoring a mesh that's similar to the other you're rendering, but distribute vertex density differently throughout the mesh. Use this mesh for blueprint generation. Then use a small particle size when generating the blueprint, such that one particle is generated for each vertex in your mesh. This will take care of vertex density, however cluster radius will still be homogeneous throughout the mesh so certain zones will have a denser cluster network. This is actually a good thing as it reduces simulation dependency on discretization (regions with more particles are more densely interconnected, which compensates for decreased convergence).

If this doesn't do the job for you, you also have the option of deriving ObiSoftbodyBleuprintBase and creating your own blueprint generator. It's more work, but allows you to create particles and constraints any way you need.

Writing custom blueprint generator is an interesting approach, but first I'll try to stich multiple softbodies together.

I have a new question: is the runtime constraint indices data the same with the stored constraint indices data? Like, if I located a constrain for a particle in a batch in the stored data, will the batch index and the constraint index and the index for the particle index always be the same in the runtime data?