Obi 7 is a major step up from previous Obi versions: its architecture, workflow and API are somewhat different, so you should set aside some time to plan and upgrade existing projects to Obi 7. Upgrading is a delicate process that requires updating your existing scenes, prefabs and code.
First and foremost, make a backup of your project. This shouldn't be necessary if you're using version control at all (and if you aren't, you really should). You can't install Obi 7 on top of a pre-existing Obi installation. You must first remove the /Obi folder in your project, and then import Obi 7. This will ensure older scripts do not linger around and cause compilation errors, since some of them contain references to components/classes/methods/structures that no longer exist in Obi 7.
In Obi 7, all ObiUpdater components have been removed. ObiSolvers now update themselves at the right time, automatically parallelizing work with other solvers in the scene. You should open up your scenes/prefabs and remove missing references to these components:
The substeps parameter in the updaters has been moved to the ObiSolver component. It is important that you adjust the amount of substeps in your ObiSolver to match the value your ObiUpdater was using, as too many substeps can have a large impact on performance.
The way cloth blueprints are generated has significantly changed: blueprints may now decimate/simplify the input mesh and generate particles at positions other than the cloth vertices, automatically binding the original mesh to the -posssibly simplified- particle based representation without the need to use proxies. As a result, all proxy-related components and assets have been removed.
You will need to re-generate your existing cloth blueprints, so that they contain the necessary information for the new mesh binding pipeline. If you don't re-generate your blueprints (by clicking the Generate button on their inspector), you will get NullRefExceptions at runtime due to missing blueprint data.
Since re-generating a blueprint resets all particle properties and particle groups, you'll also need to re-paint any custom per particle data you previously had, re-create particle groups, and re-do the setup of ObiParticleAttachments (or any other components referencing particle groups).
You will need to re-generate existing rope/rod blueprints, as the amount of data generated and stored by them has changed. This can be achieved by simply changing any property in the blueprint inspector (eg. thickness or pooled particles), this will trigger a re-generation of the blueprint.
ObiRopeExtrudedRenderer, ObiRopeLineRenderer and ObiRopeMeshRenderer now take a material and a set of render parameters as input, which removes the need to use MeshRenderer.
ObiRopeChainRenderer has significantly changed: it now uses mesh instancing to render (instead of instantiating individual prefabs, which was a lot heavier in terms of performance). This requires to use a material with GPU instancing support. It also allows for a list of link modifiers to alter how each link is rendered.
The way softbody blueprints are generated has significantly changed: blueprints now automatically bind the input mesh to the softbody particles, without the need to manually bind a ObiSoftbodySkinner component (though you can still optionally perform manual binding).
You will need to re-generate your existing softbody blueprints, so that they contain the necessary information for the new mesh binding pipeline. If you don't re-generate your blueprints (by clicking the Generate button on their inspector), you will get NullRefExceptions at runtime due to missing blueprint data.
Since re-generating a blueprint resets all particle properties and particle groups, you'll also need to re-paint any custom per particle data you previously had, re-create particle groups, and re-do the setup of ObiParticleAttachments (or any other components referencing particle groups).
Fluid rendering in Obi 7 departs from screen-space ellipsoid splatting, and uses isosurface mesh extraction instead. The ObiFluidRenderer component has been replaced by ObiFluidSurfaceMesher, which takes a ObiFluidRenderingPass as input to determine rendering parameters. See fluid rendering for details.
The range and behavior of some fluid material parameters has changed: viscosity now goes from 0 to 1 and yields corotational behavior, surface tension has been replaced by polarity. See emitter materials for details.
Here's a list of most significant changes in the scripting API. For further details regarding specific parts of the API (eg. collision callbacks, or spatial queries), please refer to the scripting section of the manual:
ObiSolver.OnCollision has a different signature, taking a ObiNativeContactList as second parameter. This gives direct access to the list of contacts.
ObiSolver.OnBeginStep has been removed, OnSimulationStart should be used instead. Note OnSimulationStart's delegate has a slightly different signature, taking both total step time and substep time as parameters.
ObiSolver.OnEndStep has been removed,OnInterpolate should be used instead. Note OnInterpolate's delegate has a slightly different signature, taking both total step time and substep time as parameters.
ObiActor.solverIndices is now a ObiNativeIntList, instead of int[]. As a consequence, you must use .count instead of .Length to get the size of the list.
The spatial queries API has significantly changed, it is now asynchronous by default. See the spatial queries manual page for details.
Per-particle fluid data layout has changed. Smoothing radius, surface tension, viscosity and vorticity are now grouped in a single fluidMaterials array. Drag, pressure, buoyancy and miscibility (formerly diffusion) have been grouped in a single fluidInterface array. The "life" array that used to be part of ObiEmitter is now a solver-wide array, just like all other particle properties. See the particles API for details.
ObiCursor.ChangeLength() no longer takes an absolute length as parameter, but a change in length. This simplifies things as there's no longer any need to factor in the rope's current rest length when using this method. Also, it's no longer a synchronous method: the length of the rope isn't changed immediately, but at the start of the next solver update. This means you can't rely on the value of rope.restLength immediately after calling ChangeLength(), as it will take at least one frame for it to reflect any changes in length. Instead, ChangeLength() returns the new rest length that the rope will have once the next solver update takes place.