02-08-2022, 09:43 PM
(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/manua...aints.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/manua...aints.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!
Hi, thank you very much for such detailed explanations. I'm currently trying to make a small Unity project that hopefully can recreate the problem but I'm getting some errors right now. I will email the sample project asap!