Help Trying to add DistanceConstraint for my TearableCloth but getting IndexOutOfRange

[josemendez]

Thanks for the reply. You are correct that I hard-coded some vertex indices for the process. However, you can see that my method is looking up for the solver index for the particle that is closest to each of the vertex, then passing the particle indices to the AddConstraint().

Yes, my bad. I understand what you're doing now. Not sure why the out of bounds exception, but it's happening inside the constraint evaluation method so one or more indices passed to it are wrong in some way.

Plus if my method is getting out of bound error, it doesn't make sense that you didn't encounter the same error on your side.

When testing your project, I hadn't installed any extra packages so Obi was using the fallback backend (Oni). Since it does not perform any out of bounds checks, the error passed undetected. But as I previously mentioned it's dangerous nonetheless, as it's writing outside the allocated memory for the arrays and that's undefined behavior.

Testing again using the Burst backend and Jobs Debugger enabled, I got the same error as you did.

Is it possible to send a copy of the script modified by you?

In my previous post you have my modified version of the AttachParticlePairInColon() function. It works without errors, constraints are persistent (even if you add/remove actors from the solver) and it's faster since it does not require to loop over all particles in the solver to find the closest to a vertex: it uses the mesh topology to look it up in constant time.

Let me know if I can be of further help,

[snowtv]

Yes, my bad. I understand what you're doing now. Not sure why the out of bounds exception, but it's happening inside the constraint evaluation method so one or more indices passed to it are wrong in some way.


When testing your project, I hadn't installed any extra packages so Obi was using the fallback backend (Oni). Since it does not perform any out of bounds checks, the error passed undetected. But as I previously mentioned it's dangerous nonetheless, as it's writing outside the allocated memory for the arrays and that's undefined behavior.

Testing again using the Burst backend and Jobs Debugger enabled, I got the same error as you did.


In my previous post you have my modified version of the AttachParticlePairInColon() function. It works without errors, constraints are persistent (even if you add/remove actors from the solver) and it's faster since it does not require to loop over all particles in the solver to find the closest to a vertex: it uses the mesh topology to look it up in constant time.

Let me know if I can be of further help,

Your code works perfect. However when choosing the Burst backend my frame rate is 4 times slower than Oni backend, is that normal?

Also I noticed that the sewn colon is jittering a little bit, is there a way to get rid of the jitter?

Thanks a lot!

[josemendez]

Your code works perfect. However when choosing the Burst backend my frame rate is 4 times slower than Oni backend, is that normal?

If the jobs debugger is enabled or Burst is disabled, then yes: the Burst backend will be a lot slower than Oni (since Oni is pre-compiled, and doesn't have a debugger), but this is not how it's intended to be used. For normal performance, the Burst compiler must be active (otherwise, there's no point in using Burst) and the jobs debugger must be disabled. See:

http://obi.virtualmethodstudio.com/manua...olver.html

Also I noticed that the sewn colon is jittering a little bit, is there a way to get rid of the jitter?

Make sure the sewn particles are not colliding against each other. That will cause constraint fighting: particles are told to collapse into each other, and avoid penetrating each other, simultaneously. Since both conditions cannot be fulfilled simultaneously, particles jitter between both.

kind regards,

[snowtv]

If the jobs debugger is enabled or Burst is disabled, then yes: the Burst backend will be a lot slower than Oni (since Oni is pre-compiled, and doesn't have a debugger), but this is not how it's intended to be used. For normal performance, the Burst compiler must be active (otherwise, there's no point in using Burst) and the jobs debugger must be disabled. See:

http://obi.virtualmethodstudio.com/manua...olver.html


Make sure the sewn particles are not colliding against each other. That will cause constraint fighting: particles are told to collapse into each other, and avoid penetrating each other, simultaneously. Since both conditions cannot be fulfilled simultaneously, particles jitter between both.

kind regards,

Thanks, how should I disable the collisions between the sewn particles? Or should I extend the distance constraints added to them?

One more question, after adding the new batch to the blueprint, and set the constraint type dirty in the solver, does it change the index of the new batch in the actor's batches list? I'd like to be able to retrieve the added constraints later on and edit/remove them.

[josemendez]

Thanks, how should I disable the collisions between the sewn particles? Or should I extend the distance constraints added to them?

Either set the particle's rest positions so that they intersect (particles that intersect at the rest pose skip self-collisions at runtime), or just give some extra slack to the distance constraints.

One more question, after adding the new batch to the blueprint, and set the constraint type dirty in the solver, does it change the index of the new batch in the actor's batches list? I'd like to be able to retrieve the added constraints later on and edit/remove them.

No, the index in the actor's batches list is kept intact.

[snowtv]

Either set the particle's rest positions so that they intersect (particles that intersect at the rest pose skip self-collisions at runtime), or just give some extra slack to the distance constraints.


No, the index in the actor's batches list is kept intact.

Hi, I've tried to deactivate the distance constraint but it doesn't seem to work. Here is the code

Code:

ObiActor colon = obiSolver.actors[cutConstraint[0]];
            // get a hold of the distance constraint
            var distanceConstraints = colon.GetConstraintsByType(Oni.ConstraintType.Distance) as ObiConstraints<ObiDistanceConstraintsBatch>;
            distanceConstraints.batches[cutConstraint[1]].DeactivateAllConstraints();

I'd also like to know how to correctly edit the distance of the distance constraint

[josemendez]

Hi, I've tried to deactivate the distance constraint but it doesn't seem to work. Here is the code

Code:

ObiActor colon = obiSolver.actors[cutConstraint[0]];
            // get a hold of the distance constraint
            var distanceConstraints = colon.GetConstraintsByType(Oni.ConstraintType.Distance) as ObiConstraints<ObiDistanceConstraintsBatch>;
            distanceConstraints.batches[cutConstraint[1]].DeactivateAllConstraints();

You've deactivated the constraints in the actor, but you'll need the solver to reload them for this to have any affect. See "Adding/removing constraints" in the manual:
http://obi.virtualmethodstudio.com/manua...aints.html

I'd also like to know how to correctly edit the distance of the distance constraint

Like with anything else, there's two ways to do this: either change the rest distance in the actor and then force the solver to reload all actor constraints by marking them dirty, or access the solver batches directly and change the rest distance there.

There's code in the manual that modifies constraint data at runtime, accessing the solver batches directly:
http://obi.virtualmethodstudio.com/manua...aints.html

The example modifies for skin constraint radius, doing it for distance constraints is basically the same. The only difference is in accessing constraint data arrays (the for loop at the end):

Code:

// get constraints stored in the actor:
var actorConstraints = cloth.GetConstraintsByType(Oni.ConstraintType.Distance)
                        as ObiConstraints<ObiDistanceConstraintsBatch>;

// get runtime constraints in the solver:
var solverConstraints = cloth.solver.GetConstraintsByType(Oni.ConstraintType.Distance)
                        as ObiConstraints<ObiDistanceConstraintsBatch>;

// get first batch for both:
var actorBatch = actorConstraints.batches[0];
var solverBatch = solverConstraints.batches[0];

// get the offset of the batch in the solver:
int offset = cloth.solverBatchOffsets[(int)Oni.ConstraintType.Distance][0];

// iterate over all active skin constraints in the batch,
// setting their properties:
for (int i = 0; i < actorBatch.activeConstraintCount; ++i)
{

    // set constraint rest length:
    solverDistanceBatch.restLengths[offset + i] = 0.05f;
}

See the API docs for info on how constraint data is stored for each specific constraint type:
http://obi.virtualmethodstudio.com/api.html

[snowtv]

You've deactivated the constraints in the actor, but you'll need the solver to reload them for this to have any affect. See "Adding/removing constraints" in the manual:
http://obi.virtualmethodstudio.com/manua...aints.html



Like with anything else, there's two ways to do this: either change the rest distance in the actor and then force the solver to reload all actor constraints by marking them dirty, or access the solver batches directly and change the rest distance there.

There's code in the manual that modifies constraint data at runtime, accessing the solver batches directly:
http://obi.virtualmethodstudio.com/manua...aints.html

The example modifies for skin constraint radius, doing it for distance constraints is basically the same. The only difference is in accessing constraint data arrays (the for loop at the end):

Code:

// get constraints stored in the actor:
var actorConstraints = cloth.GetConstraintsByType(Oni.ConstraintType.Distance)
                        as ObiConstraints<ObiDistanceConstraintsBatch>;

// get runtime constraints in the solver:
var solverConstraints = cloth.solver.GetConstraintsByType(Oni.ConstraintType.Distance)
                        as ObiConstraints<ObiDistanceConstraintsBatch>;

// get first batch for both:
var actorBatch = actorConstraints.batches[0];
var solverBatch = solverConstraints.batches[0];

// get the offset of the batch in the solver:
int offset = cloth.solverBatchOffsets[(int)Oni.ConstraintType.Distance][0];

// iterate over all active skin constraints in the batch,
// setting their properties:
for (int i = 0; i < actorBatch.activeConstraintCount; ++i)
{

    // set constraint rest length:
    solverDistanceBatch.restLengths[offset + i] = 0.05f;
}

See the API docs for info on how constraint data is stored for each specific constraint type:
http://obi.virtualmethodstudio.com/api.html

Thanks for the response. I'm not really looking to remove the constraints, only "deactivate" them, which I assume is possible since there is ObiDistanceConstraintsBatch.DeactivateAllConstraints()

If I don't need to remove them then I shouldn't need to update my saved batch index in actor for these constraints, right?

[josemendez]

Thanks for the response. I'm not really looking to remove the constraints, only "deactivate" them, which I assume is possible since there is ObiDistanceConstraintsBatch.DeactivateAllConstraints()

*Any* change you make to the actor blueprint constraints will have no effect at all in the solver, unless you tell the solver to reload them. This includes adding, removing, activating, deactivating, or modifying constraints.

Loading constraints on the solver is a one-way road. This works exactly the same way prefabs do: if you instantiate a prefab 5 times, any changes you make to the prefab from that point on will only affect new instances, the 5 already existing instances will not be modified.

When you modify a blueprint -either directly or trough an actor that's using it-, think of it as modifying a prefab: unless you apply the changes to all existing instances (that is, tell the solver to reload all constraints), these instances will remain unchanged.

If I don't need to remove them then I shouldn't need to update my saved batch index in actor for these constraints, right?

As long as the amount of batches in the actor's blueprint does not change, the saved batch index will not change either.