Not realtime simulation without affecting FPS

[mmortall]

Not unless you're willing to use threads. A simulation step cannot be chopped up in pieces. It must be run in a single go, so running it on a thread other than the main thread is the only option.

solver.SimulateStep() sends all simulation tasks to a threadpool and puts the calling thread to sleep until all tasks have been completed. You could call solver.SimulateStep() on a thread other than Unity's main thread. That would allow the main thread to continue updating stuff while this other thread waits for Obi to complete the step.

Also note that neither Obi or Unity are designed to do this. Unity expects physics simulation to be completed during FixedUpdate(), and it will not go on with the frame until FixedUpdate() has ended. So two-way interaction with rigidbodies would not work if you simulate outside of Unity's stablished update cycle. You should also keep in mind that many Unity methods/classes cannot be used outside of the main thread, so issues might arise with this.

Another, much cheaper option that might work for you is using Unity's captureFramerate: (https://docs.unity3d.com/ScriptReference...erate.html). This allows you to decouple game time from real time.

Thanks for help.

So even if I call solver.SimulateStep() from other thread internally it will call Unity API, so this leads to crash or exception because Unity not allowing to call its API from separate thread. 
I thought you are transferring Untiy colliders data into your native solver code which probably running in the separate thread already. So why to use unity API if you do the whole simulation and collision detection by yourself in native code? So you have a whole physical world decoupled from Unity aren't you? Or maybe I am wrong. Could you clarify?

Regarding captureFramerate as I understand it basicaly slows down the whole game. But I need to game runs normally, only slow down the simulation.