Help Trying to add DistanceConstraint for my TearableCloth but getting IndexOutOfRange

[josemendez]

I thought it's necessary to SetConstraintsDirty() because when adding new constraint to a batch it's possible that the new constraint contains particles that are already in that batch?

Not really, SetConstraintsDirty() is somewhat related to batches but it does not perform constraint coloring.

Constraints are colored -that is, grouped into batches according to shared particles- when you generate the blueprint. This is a very costly step as it has quadratic cost (O(n^2) over the amount of constraints of each type). This is usually never done at runtime. If you do add constraints at runtime, it's usually a small amount of them and quite simple to keep them in separate batches when adding them. If you need to add a large amount of constraints and it's not trivial to determine how to colorize them (separate them into batches), you can use GraphColoring.Colorize() to get a batch index for each one.

So when you Generate() a blueprint, particles are created, constraints are created, and they're grouped into batches using GraphColoring.Colorize().

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

Arranging constraints into batches can be a very time consuming process (known as graph-coloring), so it is generally not done at runtime: it happens as part of blueprint generation, so blueprints store constraints pre-grouped into batches.

The whole point of batching constraints is to be able to apply constraints using multithreading, without threads stepping on each other's toes. However, the more batches you have, the less parallelism you can squeeze out since batches must be done sequentially. Ideally you want as few batches as possible. So when you add an actor to a solver, the solver cannot just append the batches in that actor's blueprint to all the batches already in the solver: it needs to somehow merge all them, minimizing the total batch amount to maximize speed.

This is what SetConstraintsDirty() asks the solver to do: clear all constraint batches in the solver, take all batches from all actor's blueprints, and create new solver batches by merging them in a way that the total amount of batches is minimized. Since actors do not share particles, this is trivial to do: just take the first batch from each actor and merge them all. Then take the second batch from each actor and merge them all, etc. So you end up with only as many batches as the largest actor in the solver, which is way better than the sum of all batches from all actors.

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

Very much like particle data, constraint data isn't laid out in the solver the same way it is in an actor. When an actor gets added to a solver, all its constraints are merged with the existing constraints in the solver to maximize performance.

so I'm guessing it's ok to have as many batches as you need?

It's ok as in "it will work". Ideally, you want as few batches as possible if you want multithreading to be of any benefit. For instance: if you had one batch per constraint, then all constraints would be processed in a single thread. This works, but it's slow.

Also why rebuilding batches will render the constraints useless? I thought it only changed how the constraint data is arranged in the batches, but the actual data which affects the physics behavior won't be different?

Because it ditches all constraints in the solver, and rebuilds them using the constraints found in the actors blueprints.

Just to update, I commented out the line that calls SetConstraintsDirty(), still don't see a difference...

That's unexpected. Would it be possible for you to share a small scene that reproduces this issue, so that I can better understand the context in which you're doing this? (send it to support(at)virtualmethodstudio.com) thanks!