All the assets share the same core physics solver, and the same philosophy: everything (cloth, fluids, ropes...) is made out of particles, which are small lumps of matter that relate to each other trough the use of constraints. However, most often there's no use for a unified physics engine in games. So instead of having a single, very expensive asset that can simulate all of the above, we split Obi in multiple smaller assets. This way you only pay for what you need, and it is still possible to use all assets together if you own them all.
Simply restart Unity. Sometimes, Unity fails to load new native libraries upon importing them. The only way to force a reload is to restart Unity.
First make sure both assets are the same version (for instance, you can't install 5.1 and 6.2 together in the same project). Then, simply import both packages into the project.
There should be a CHANGELOG_<assetname>.txt file in the Obi/ installation folder. It contains a register of all notable changes to Obi over time in reverse chronological order (latest changes first). The version you have installed appears at the top of the file.
It depends on what your goals are. If you want to make something more complex than a simple flag or a water faucet, most likely the answer is no. Obi is a powerful, large and complex system. If it makes sense for a particular parameter to be exposed to the user, Obi does expose it. No compromises were made in its design to trade flexibility for ease of use. A considerable amount of effort was put into making it 'as simple as possible, but not simpler'.
Throughout the manual, API documentation and engine design, basic 3D math/simulation concepts (like vector spaces, inertial forces, mass or fixed timestepping) aren't explained in detail. It's a good idea to familiarize yourself with these before attempting to use Obi in a real-world project.
The good news is that if you devote enough time to it, it will pay off. Also it will help you grasp a lot of essential simulation concepts that can be easily transferred to other physics simulators. You'll wonder why these other simulators impose so many artificial limits on what you can do with them.
For anything except the bare basics, yes. Obi is written in HPCS (high performance C#) and C++11, and it exposes a C# API. Obi deals with hundreds of particles and thousands of constraints every frame. These are exposed to you, the user, so learning how to write performant code is a prerequisite.
No. The core physics solver runs 100% in the CPU. Only rendering is done using the GPU.
Yes. It is extremely well optimized. A task-based multithreading scheme is used to split workload into evenly sized chunks. All the math-heavy routines are SIMD accelerated.
Depends on the simulation backend used (see backends). If using Burst, you can build for all platforms supported by Unity's Burst compiler, including consoles. If using Oni, you can build for Windows, Linux, OSX, iOS, and Android.
Cloth, Rope and Softbodies support VR. For Obi Fluid, VR is only supported in the built-in pipeline, and it's necessary to use separate cameras for each eye since the renderer does not support single-pass stereo rendering.
Cloth, Rope and Softbodies support all SRPs out of the box, since they do not perform any custom rendering. Obi Fluid does include a custom rendering pipeline based on screen-space ellipsoid splatting, that currently supports the built-in pipeline and URP (no HDRP support yet, no URP 2D lighting system support).
Obi 6.4 and above do. Older versions do not support configurable enter play mode, since disabling domain reloading requires special handling of static data which wasn't available back then.
The full C# source code for the Burst backend is included. The source code for the Oni backend is not. Oni is written in highly portable C++14. We do license it on a per-case basis, so contact us if you're interested. Sources for everything else (C# MonoBehaviours, classes, shaders, etc.) are included.
Having the jobs debugger/leak detection/Burst timings enabled in-editor will degrade performance of any Burst-compiled jobs considerably. Our of these three, the one that impacts performance the most is the jobs debugger. Make sure you disable it for normal performance while running inside the editor. See the manual page regarding backends.
The rope inspector is a sceneview window, and Unity won't draw sceneview windows if any inspector is in debug mode. Close all inspectors in debug mode (easiest, quickest way is to revert the window layout to the default) and it will become visible again.
Most likely the cause is that collisions are being filtered out. In 6.1 and older versions, only particles and colliders in separate phases will generate contacts. In 6.2 and up, particles and colliders use categories and masks to determine if they should collide with each other. Also, keep in mind that PolygonCollider2D is not currently supported. See the collisions manual page for detailed info.
Most likely the cause is that collisions are being filtered out. In 6.1 and older versions, only particles in separate phases will generate contacts. You can set the phase value on a per-particle basis in the blueprint editor for cloth and softbodies. For ropes, you can define it per-control point in the path editor. In 6.2 and up, particles use categories and masks to determine if they should collide with each other. See the collisions manual page for detailed info.
Most likely the cause is that collisions are being filtered out. Obi 6.2 replaced the phase system with categories and masks, which are more flexible and easier to use. You will need to update your collision filtering setup. Easiest fix is to set your actor's and collider's "Collide with" masks to "Everything". See the collisions manual page for detailed info.