21-08-2018, 05:07 PM
(This post was last modified: 21-08-2018, 05:12 PM by josemendez.)
(21-08-2018, 03:13 PM)mmortall Wrote: 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.
We do have a minimal internal representation of all colliders/rigidbodies in the scene, but we do not simulate them. Only particles are simulated by our engine. We need to use Unity's API in order to:
1.- Get collider data so that we can accurately represent these in our internal physics engine, to generate contacts between particles and colliders.
2.- Once particle-collider contacts are solved, Inject forces back to rigidbodies for two-way coupling. The rigidbodies and colliders are still fully simulated by Unity.
As a result, we do not override Unity's physics engine. Each step we merely extract the info we need about colliders in order to be able to generate particle-collider contacts, and then apply forces back to them. Both steps need to use Unity's API. It's the only way to do it.
Thinking about it, you could strip two-way interaction and all rigidbody related code from Obi (in case you do not need it, but if you do then you're stuck as it has to happen at a very specific point of Unity's update cycle), move collider data retrieval to the main thread and do it periodically. Imho this begins to look like a major rewrite of the system and I'm not even sure it would be possible. I guess Unity is just not designed to decouple physics and rendering the way you need to.