(27-07-2022, 07:20 AM)josemendez Wrote: Hi!

When you add an actor to a solver, all its particle and constraint data are copied into the solver. Each particle in the actor -numbered from 0 to the amount of particles in the actor- is assigned a position in the solver's arrays, its position in the solver is its solver index. The range of a solver index is from 0 to the combined amount of all particles being simulated by the solver.

In your code, "colon" is probably an actor (cloth or softbody), not a solver. Is this correct?

If that's the case, you're retrieving the actor's constraints (whose particle indices run from 0 to the amount of particles in the actor):

Code:

var distanceConstraints = colon.GetConstraintsByType(Oni.ConstraintType.Distance) as ObiConstraints<ObiDistanceConstraintsBatch>;

But then you're passing indices of particles in the entire solver (which run from 0 to the total amount of particles in the solver):

Code:

// Add a constraint for the pair
batch.AddConstraint(new Vector2Int(particleSolverIndexA, particleSolverIndexB), 0);

which will result in an out of index access since particleSolverIndexA and B are probably much larger than the amount of particles in that actor.


Either use actor indices, or access the solver's batches (instead of the actor batches).

kind regards,

(27-07-2022, 09:54 PM)snowtv Wrote: Ohhhhh, that was very dumb of me.

I think it get it to work now, no errors anymore, however I can't tell the difference after DistanceConstraints are added. AddConstraint() for DistanceConstraint only takes two parameters, are there more for me to tweak after adding one? Like strength or something?

(28-07-2022, 07:36 AM)josemendez Wrote: There can be several reasons for this. Could you share the entire code you're using?

For instance, a possible cause would be adding the distance constraint to the blueprint, once the blueprint has been instantiated. This will have no effect on existing instances of it.

(28-07-2022, 07:19 PM)snowtv Wrote: I think I'm adding them to the solver?

Quote:After you've added or removed constraints, you will need to call actor.SetConstraintsDirty(). This rebuilds all solver batches of the given constraint type.

(29-07-2022, 07:59 AM)josemendez Wrote: Yes you're adding them to the solver, but at the very end you're asking the solver to rebuild all distance constraint batches, by calling SetConstraintsDirty(). From the docs:



So what's happening is that you're adding a new constraint to the solver batches, and then asking the solver to discard all existing distance batches and rebuild them by merging batch data from all actors in the solver.

Either add the constraint to the actor blueprint (useful if you want to later instantiate the actor multiple times), or add the constraint to the solver if it's a one-time thing. In this case, don't call SetConstraintsDirty()!.

(29-07-2022, 07:27 PM)snowtv Wrote: 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?

Quote: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.

Quote: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.

(29-07-2022, 07:27 PM)snowtv Wrote: so I'm guessing it's ok to have as many batches as you need?

(29-07-2022, 07:27 PM)snowtv Wrote:
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?

(29-07-2022, 07:27 PM)snowtv Wrote: Just to update, I commented out the line that calls SetConstraintsDirty(), still don't see a difference...

(01-08-2022, 08:11 AM)josemendez Wrote:
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/manual/6.3/scriptingconstraints.html


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/manual/6.3/scriptingconstraints.html



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.



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


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!

(01-08-2022, 08:11 AM)josemendez Wrote:
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/manual/6.3/scriptingconstraints.html


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/manual/6.3/scriptingconstraints.html



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.



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


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!