The ObiSolver component is arguably the most important component in Obi. It is responsible for simulating particle physics and enforcing constraints. Three important things to remember about solvers:

  • They can be added to any GameObject in your scene and there can be more than one solver working simultaneously in the same scene.
  • Every actor needs to be child of a solver to get its simulation updated.
  • Each solver is completely independent from other solvers. Therefore, actors being updated by different solver won't interact / collide with each other. Only actor in the same solver will react to each other.

Solvers always perform the simulation in local space. This means that translating, rotating or scaling the solver will rigidly transform the simulation as a whole.

You can inject a percentage of the solver linear/rotational movement back into the simulation, in the form of inertial forces. For instance, you might want to control how much of the overall character movement will affect the clothing simulation. For this purpose, solvers expose two parameters to independently control linear and rotational inertial forces (see below).

Solver parameters

Simulate when invisible

Should this solver keep the simulation going when invisible to all cameras? Keep this enabled if your simulation needs to be updated at all times, disable it to improve performance when multiple solvers exist in the scene but they are not visible at all times.


The solver can simulate in 2D or 3D mode. In 2D mode, simulation only happens in the XY plane.


Interpolation mode used to render particles. None is faster to calculate, but Interpolate will give more visually pleasing results.


Direction and magnitude of gravity applied to particles in this solver, expressed in the solver's local space.


Velocity damping applied to particle velocities. Increase it to reduce their kinetic energy.

Shock propagation

High values will artificially increase the mass of particles supporting other particles. Use it to obtain better stacking stability.

Max Anisotropy

Particles in Obi can be ellipsoidal in shape, instead of perfectly spherical. This is used to better adapt their shape to the surface of the object they represent, achieving more accurate collision detection and smoother rendering. Max anistropy lets you determine the maximum ratio between the ellipsoid's radii: a value of 1 will force all particles to be spherical (deactivates anisotropy), values larger than 1 will allow particles to become more ellipsoidal the higher max anisotropy is.

fluid w/max anisotropy = 1
fluid w/max anisotropy = 3

Sleep threshold

Any particle with a kinetic energy below this value will be freezed in place. This is useful when you don´t want minuscule variations in velocity or force to perturb an actor, making it look like its jittering or moving very slowly. Set it to zero if you want your particles' positions to be affected by any force that acts upon them, however small it may be.

World linear inertia scale

Controls how much of the world-space linear inertia of the solver transform is applied to the particles. Values range from 0 (none) to 1 (100% of it).

Moving solver containing a piece of cloth with linear inertia scale set to 1. Notice how the cloth continues moving forward when the solver abruptly stops, and how it is launched backwards when the solver resumes its movement.

World angular inertia scale

Analogous to the previous property, but controls angular inertia (rotations) instead of linear inertia (translations). Note that centrifugal and coriolis forces are accounted for.

Rotating solver containing a piece of cloth with angular inertia scale set to 1. Note how centrifugal forces lift it up while rotating.


Enable/disable constraints using the checkbox next to their name.

You can globally enable/disable each constraint type for all actors being managed by the solver. Disabling constraints this way (as opposed to disabling constraint components for individual actors) will allow the solver to completely skip any related calculations. This allows you to customize what's being done under the hood and get rid of unnecessary overhead.

Constraint parameters

ObiSolver exposes 4 parameters for each constraint type:

  • Enabled (checkbox right next to the name)
  • Iterations
  • Evaluation order
  • SOR Factor


Are these constraints updated at all? By default all constraint types are enabled, altough this is rarely what you want for production-ready simulations. You should disable any constraints that are not critical for the final look of your simulation.


How many times per substep should these constraints be evaluated? A high iteration count will keep the simulation closer to the ground-truth solution. Keep it low if these constraints aren`t very important for your particular purpose and you want to get better performance. The default is 3.

Evaluation order

This tells the solver in which order to evaluate the constraints of this kind. There are two modes:

  • In Sequential mode, all constraints are evaluated in the order they were created (which is determined by each specific ObiActor) and each constraint “sees” the adjustments made by all previous constraints. This ensures quick convergence, so your constraints will need few iterations to look good. However it is not very stable when several constraints are fighting for control -it will introduce jittering-, so there are some use-cases where this mode is not a good choice. It is order-dependent, so in low-budget situations (few iterations and/or large timesteps) this can result in visible patterns in particle arrangement. For those of you a bit on the technical side, this is a Gauss-Seidel type of solver.

  • In Parallel mode, all constraints are evaluated but their adjustments are not immediately applied to the particles. Instead, they are stored, averaged, and then the final result is then used to adjust particle positions. This yields a very stable simulation even with lots of constraints applied at once, however more iterations are needed for “hard” constraints. It is also order-independent, so it ensures smooth particle arrangements. Use this mode if you want to trade performance -with high iteration counts- or quality -with low iteration counts- for stability. Again, for technical users: this is Jacobi-like solving.

SOR Factor

SOR stands for Successive Over-Relaxation. When trying to satisfy constraints, one way to improve convergence is to “over-relax” the constraints. That is, if moving a particle 2 units to the left would satisfy the constraint for now, why not moving it 3 units? This is exactly what this factor is used for. 1 is the default value, which does not perform over-relaxation at all. 2 is the maximum, which allows you to perform twice as much relaxation on constraints. High values can be used to help speed up convergence in any of the two modes (sequential or parallel), but keep in mind that simulation stability can degrade.