diff --git a/20_Simulation_Principles/20_MechanicalObject.md b/20_Simulation_Principles/20_MechanicalObject.md
index 7edaf9573..a019770d1 100644
--- a/20_Simulation_Principles/20_MechanicalObject.md
+++ b/20_Simulation_Principles/20_MechanicalObject.md
@@ -122,7 +122,7 @@ Symbolic ids
The MultiVec entries are not directly accessible by the solvers. The MultiVec are represented by identificators. The operations on the vectors are implemented using visitors which contain the identificators of the relevant vectors. The MultiVec identificators (MultiVecId) have different types, depending on the data they contain
(positions or their derivatives) and the access mode.
-The use of symbolic identificators (MultiVecId) prevent other components (like solvers) from handling state vectors directly and allow to easily work with abstract MultiVec by using their ids. These symbolic ids are widely used by specialized visitors, like the ones used in [ODESolver](./system-resolution/integration-scheme/).
+The use of symbolic identificators (MultiVecId) prevent other components (like solvers) from handling state vectors directly and allow to easily work with abstract MultiVec by using their ids. These symbolic ids are widely used by specialized visitors, like the ones used in [ODESolver](./../system-resolution/integration-scheme/).
``` cpp
typedef TMultiVecId
ConstMultiVecCoordId;
diff --git a/20_Simulation_Principles/30_Topology.md b/20_Simulation_Principles/30_Topology.md
index 8b1c00808..98f8da0fa 100644
--- a/20_Simulation_Principles/30_Topology.md
+++ b/20_Simulation_Principles/30_Topology.md
@@ -13,11 +13,11 @@ Loading a topology
When simulating the physics of an object, its topology must therefore be loaded. To do so, many loaders are available in SOFA depending on the format of the loaded file. Among others:
-* obj = [_MeshOBJLoader_](../components/io/mesh/meshobjloader/)
-* vtk = [_MeshVTKLoader_](../components/io/mesh/meshvtkloader/)
-* stl = [_MeshSTLLoader_](../components/io/mesh/meshstlloader/)
-* off = [_MeshOffLoader_](../components/io/mesh/meshoffloader/)
-* gmsh = [_MeshGmshLoader_](../components/io/mesh/meshgmshloader)
+* obj = [_MeshOBJLoader_](../../components/io/mesh/meshobjloader/)
+* vtk = [_MeshVTKLoader_](../../components/io/mesh/meshvtkloader/)
+* stl = [_MeshSTLLoader_](../../components/io/mesh/meshstlloader/)
+* off = [_MeshOffLoader_](../../components/io/mesh/meshoffloader/)
+* gmsh = [_MeshGmshLoader_](../../components/io/mesh/meshgmshloader)
All MeshLoaders share a common API, especially several available data:
@@ -27,7 +27,7 @@ All MeshLoaders share a common API, especially several available data:
* _**createSubelements**_: to divide all n-D elements into their (n-1)-D boundary elements (e.g. tetrahedra to triangles)
* _**onlyAttachedPoints**_: to keep only points attached to elements of the mesh
-Additional data (*translation*, *rotation* and *scale3d*) are available but it rather advised to use a [TransformEngine](../components/engines/transform/transformengine/) to apply a transformation to your geometry.
+Additional data (*translation*, *rotation* and *scale3d*) are available but it rather advised to use a [TransformEngine](../../components/engines/transform/transformengine/) to apply a transformation to your geometry.
All MeshLoaders propose several data as output (for the most used):
* _**position**_: vector of vertices of the mesh loaded
@@ -128,12 +128,12 @@ Topological mappings
**_Multi-model representation_**
-One of the significant strength of SOFA is to allow several representation of a same object. For instance, an object can have a coarse triangular representation for the collision, a tetrahedral representation of the mechanics and a very detailed quad surface for the visualization. However, this means that these different representations must be linked one to another. This is the role of the [mappings](../simulation-principles/multi-model-representation/mapping/). When you run a simulation with such several representations, it assumes to load the different topologies in the scene.
+One of the significant strength of SOFA is to allow several representation of a same object. For instance, an object can have a coarse triangular representation for the collision, a tetrahedral representation of the mechanics and a very detailed quad surface for the visualization. However, this means that these different representations must be linked one to another. This is the role of the [mappings](../../simulation-principles/multi-model-representation/mapping/). When you run a simulation with such several representations, it assumes to load the different topologies in the scene.
**_From a topology to another_**
-It is possible to define a mesh topology from another mesh topology using the same degrees of freedom. Again, the [mappings](../simulation-principles/multi-model-representation/mapping/) make it possible. Mappings can be used either to go from one topology to a lower one in the topological hierarchy (from tetrahedra to triangles), or to split elements (quads into triangles). As usual mappings, forces applied on the slave topology are propagated onto the master one. Both topologies will therefore be assigned to the same _MechanicalObject_. The existing _TopologicalMappings_ are:
+It is possible to define a mesh topology from another mesh topology using the same degrees of freedom. Again, the [mappings](../../simulation-principles/multi-model-representation/mapping/) make it possible. Mappings can be used either to go from one topology to a lower one in the topological hierarchy (from tetrahedra to triangles), or to split elements (quads into triangles). As usual mappings, forces applied on the slave topology are propagated onto the master one. Both topologies will therefore be assigned to the same _MechanicalObject_. The existing _TopologicalMappings_ are:
* _Hexa2TetraTopologicalMapping_
* _Hexa2QuadTopologicalMapping_
diff --git a/20_Simulation_Principles/40_System_Resolution/10_Integration_Scheme.md b/20_Simulation_Principles/40_System_Resolution/10_Integration_Scheme.md
index 50940c100..bebdb2ac5 100644
--- a/20_Simulation_Principles/40_System_Resolution/10_Integration_Scheme.md
+++ b/20_Simulation_Principles/40_System_Resolution/10_Integration_Scheme.md
@@ -32,9 +32,9 @@ Explicit schemes are usually known as being fast to solve (since the created lin
Explicit ODESolvers in SOFA:
-- [EulerExplicitSolver](../../components/odesolver/forward/eulerexplicitsolver/)
-- [CentralDifferenceSolver](../../components/odesolver/forward/centraldifferencesolver/)
-- [RungeKutta2Solver](../../components/odesolver/forward/rungekutta2solver/)
+- [EulerExplicitSolver](../../../components/odesolver/forward/eulerexplicitsolver/)
+- [CentralDifferenceSolver](../../../components/odesolver/forward/centraldifferencesolver/)
+- [RungeKutta2Solver](../../../components/odesolver/forward/rungekutta2solver/)
### Implicit scheme
@@ -51,15 +51,15 @@ Implicit schemes are known as being slower to solve (the outcoming linear system
Implicit ODESolvers in SOFA:
-- [EulerImplicitSolver](../../components/odesolver/backward/eulerimplicitsolver/)
-- [NewmarkImplicitSolver](../../components/odesolver/backward/newmarkimplicitsolver/)
-- [VariationalSymplecticSolver](../../components/odesolver/backward/variationalsymplecticsolver/)
+- [EulerImplicitSolver](../../../components/odesolver/backward/eulerimplicitsolver/)
+- [NewmarkImplicitSolver](../../../components/odesolver/backward/newmarkimplicitsolver/)
+- [VariationalSymplecticSolver](../../../components/odesolver/backward/variationalsymplecticsolver/)
In the SOFA code
----------------
-The integration scheme is described in the `solve()` function of the ODESolver. This *solve()* function is called by the [AnimationLoop](../animation-loop/) (through a dedicated visitor) and builds the complete linear system $$\mathbf{A}x=b$$.
+The integration scheme is described in the `solve()` function of the ODESolver. This *solve()* function is called by the [AnimationLoop](../../animation-loop/) (through a dedicated visitor) and builds the complete linear system $$\mathbf{A}x=b$$.
### Specification of the scheme
@@ -82,7 +82,7 @@ The left hand side matrix $$\mathbf{A}$$ is built using the function:
``` cpp
matrix = MechanicalMatrix(r_M, r_B, r_K);
```
-where $$r_M$$ (mass coefficient), $$r_B$$ (damping coefficient) and $$r_K$$ (stiffness coefficient) are Rayleigh coefficients (see section below). Depending on the scheme (explicit or implicit, see previous paragraph) and on the type of LinearSolver used (if any), the abstract function `MechanicalMatrix` will trigger different [visitors](../visitors/), thus different functions to compute the system matrix $$\mathbf{A}$$. Discover the API used for the computation of $$\mathbf{A}$$ in the [ForceField](../multi-model-representation/forcefield/#forcefield-api) and [Mass](../multi-model-representation/mass/#mass-api) doc pages.
+where $$r_M$$ (mass coefficient), $$r_B$$ (damping coefficient) and $$r_K$$ (stiffness coefficient) are Rayleigh coefficients (see section below). Depending on the scheme (explicit or implicit, see previous paragraph) and on the type of LinearSolver used (if any), the abstract function `MechanicalMatrix` will trigger different [visitors](../../visitors/), thus different functions to compute the system matrix $$\mathbf{A}$$. Discover the API used for the computation of $$\mathbf{A}$$ in the [ForceField](../../multi-model-representation/forcefield/#forcefield-api) and [Mass](../../multi-model-representation/mass/#mass-api) doc pages.
The right hand side vector *b* is built through the function:
@@ -90,14 +90,14 @@ The right hand side vector *b* is built through the function:
computeForce(b)
```
-Again, Depending on the scheme (explicit or implicit, see previous paragraph), the abstract function `computeForce` will trigger different [visitors](../visitors/), thus different functions to accumulate the forces into the vector $$b$$. Discover the API used for the computation of $$b$$ in the [ForceField](../multi-model-representation/forcefield/#forcefield-api) doc page.
+Again, Depending on the scheme (explicit or implicit, see previous paragraph), the abstract function `computeForce` will trigger different [visitors](../../visitors/), thus different functions to accumulate the forces into the vector $$b$$. Discover the API used for the computation of $$b$$ in the [ForceField](../../multi-model-representation/forcefield/#forcefield-api) doc page.
### State vectors in ODESolver
-In order to build the linear matrix system, the ODESolver uses information contained in [state vectors](../mechanicalobject/#state-vectors) (like DOFs and their derivatives) within the scope of the ODESolver. The ODESolver does not access the state vectors directly. It accesses the state vectors remotely using visitors, which traverse the graph starting from the node which contains the solver. This keeps the implementation of the solver independent of the simulated objects and their types.
+In order to build the linear matrix system, the ODESolver uses information contained in [state vectors](../../mechanicalobject/#state-vectors) (like DOFs and their derivatives) within the scope of the ODESolver. The ODESolver does not access the state vectors directly. It accesses the state vectors remotely using visitors, which traverse the graph starting from the node which contains the solver. This keeps the implementation of the solver independent of the simulated objects and their types.
Each type of solver may use different auxiliary state vectors to implement their simulation method. State vectors (MultiVec) are allocated and processed in the scope of the solver in a thread-safe way using an instance of _simulation::common::VectorOperations_. For instance, a Runge-Kutta algorithms needs to save the result of previous time steps.
@@ -113,7 +113,7 @@ MultiVecCoord previousPos(&vop, previousPosID); // additional vector
### Compute the solution
-In most cases, the matrix system $$\mathbf{A}x=b$$ can then be sent to a [LinearSolver](../system-resolution/linear-solver/) in charge of finally solving the system defined according to the chosen scheme. Within the function *ODESolver::solve()*, the call to the LinearSolver will appear through the function call:
+In most cases, the matrix system $$\mathbf{A}x=b$$ can then be sent to a [LinearSolver](../../system-resolution/linear-solver/) in charge of finally solving the system defined according to the chosen scheme. Within the function *ODESolver::solve()*, the call to the LinearSolver will appear through the function call:
``` cpp
matrix.solve(x, b);
diff --git a/20_Simulation_Principles/40_System_Resolution/20_Linear_Solver.md b/20_Simulation_Principles/40_System_Resolution/20_Linear_Solver.md
index 0d90e2566..0e054ecd3 100644
--- a/20_Simulation_Principles/40_System_Resolution/20_Linear_Solver.md
+++ b/20_Simulation_Principles/40_System_Resolution/20_Linear_Solver.md
@@ -1,7 +1,7 @@
Linear solvers
==============
-Once the [integration scheme](./integration-scheme/) described how the linear matrix system is built, this system $$\mathbf{A}x=b$$ must be solved in order to find the solution $$x(t+dt)$$ at the next time step.
+Once the [integration scheme](./../integration-scheme/) described how the linear matrix system is built, this system $$\mathbf{A}x=b$$ must be solved in order to find the solution $$x(t+dt)$$ at the next time step.
To solve this system, two main categories of algorithms exist: the **direct** solvers and the **iterative** solvers.
@@ -17,11 +17,11 @@ For small-size linear systems, the direct methods will be efficient. Large and s
Among the numerous direct solvers available in SOFA, we can mention:
-- [SparseLDLSolver](../../components/linearsolver/direct/sparseldlsolver/) and [AsyncSparseLDLSolver](../../components/linearsolvers/direct/asyncsparseldlsolver//)
-- [SparseLUSolver](../../components/linearsolvers/direct/sparselusolver/)
-- [CholeskySolver](../../components/linearsolvers/direct/choleskysolver/) / [SparseCholeskySolver](../../components/linearsolvers/direct/sparsecholeskysolver/)
-- [SVDLinearSolver](../../components/linearsolvers/direct/svdlinearsolver) (Jacobi SVD)
-- [BTDLinearSolver](../../components/linearsolvers/direct/btdlinearsolver)
+- [SparseLDLSolver](../../../components/linearsolver/direct/sparseldlsolver/) and [AsyncSparseLDLSolver](../../../components/linearsolvers/direct/asyncsparseldlsolver//)
+- [SparseLUSolver](../../../components/linearsolvers/direct/sparselusolver/)
+- [CholeskySolver](../../../components/linearsolvers/direct/choleskysolver/) / [SparseCholeskySolver](../../../components/linearsolvers/direct/sparsecholeskysolver/)
+- [SVDLinearSolver](../../../components/linearsolvers/direct/svdlinearsolver) (Jacobi SVD)
+- [BTDLinearSolver](../../../components/linearsolvers/direct/btdlinearsolver)
@@ -52,9 +52,9 @@ For well-conditioned problems (even large systems), the convergence remains mono
Iterative solvers in SOFA are:
-- [CGLinearSolver](../../linearsolver/iterative/cglinearsolver/)
-- [ShewchukPCGLinearSolver](../../components/linearsolver/iterative/preconditioned-cg/)
-- [MinResLinearSolver](../../components/linearsolver/iterative/minreslinearsolver/)
+- [CGLinearSolver](../../../linearsolver/iterative/cglinearsolver/)
+- [ShewchukPCGLinearSolver](../../../components/linearsolver/iterative/preconditioned-cg/)
+- [MinResLinearSolver](../../../components/linearsolver/iterative/minreslinearsolver/)
#### In the SOFA code
@@ -85,8 +85,8 @@ For example, `` is a shortcut for ``.
diff --git a/20_Simulation_Principles/50_Multi-Model_Representation/10_Physics_integration.md b/20_Simulation_Principles/50_Multi-Model_Representation/10_Physics_integration.md
index 2169a3ce8..f0e671f5e 100644
--- a/20_Simulation_Principles/50_Multi-Model_Representation/10_Physics_integration.md
+++ b/20_Simulation_Principles/50_Multi-Model_Representation/10_Physics_integration.md
@@ -93,5 +93,5 @@ Integration of physics
In SOFA, the physics will be mainly implemented in Mass components and ForceField. You can have a look at the integration of:
-- the mass in [MeshMatrixMass](../../components/mass/meshmatrixmass/)
-- the integration of linear elasticity in [TetrahedronFEMForceField](../../components/solidmechanics/fem/elastic/tetrahedronfemforcefield/)
+- the mass in [MeshMatrixMass](../../../components/mass/meshmatrixmass/)
+- the integration of linear elasticity in [TetrahedronFEMForceField](../../../components/solidmechanics/fem/elastic/tetrahedronfemforcefield/)
diff --git a/20_Simulation_Principles/50_Multi-Model_Representation/11_Mass.md b/20_Simulation_Principles/50_Multi-Model_Representation/11_Mass.md
index 03974e467..bae0491e9 100644
--- a/20_Simulation_Principles/50_Multi-Model_Representation/11_Mass.md
+++ b/20_Simulation_Principles/50_Multi-Model_Representation/11_Mass.md
@@ -1,7 +1,7 @@
Mass
====
-In simulation, the mass usually results from the volume integration of a density (see the [Physics Integration](./physics-integration/) section). It can be a mass density, but it can be an electrical or electrical conductivity among others. In all these equations, the density appears on the left hand side part of the equation. The mass matrix therefore contributes to $$\mathbf{A}$$, in the linear System $$\mathbf{A}x=b$$.
+In simulation, the mass usually results from the volume integration of a density (see the [Physics Integration](./../physics-integration/) section). It can be a mass density, but it can be an electrical or electrical conductivity among others. In all these equations, the density appears on the left hand side part of the equation. The mass matrix therefore contributes to $$\mathbf{A}$$, in the linear System $$\mathbf{A}x=b$$.
Mass API
--------------
@@ -18,9 +18,9 @@ Mass implementations
See examples of Mass implementation:
-- [UniformMass](../../components/mass/UniformMass/)
-- [MeshMatrixMass](../../components/mass/meshmatrixmass/)
-- [DiagonalMass](../../components/mass/diagonalmass/)
+- [UniformMass](../../../components/mass/UniformMass/)
+- [MeshMatrixMass](../../../components/mass/meshmatrixmass/)
+- [DiagonalMass](../../../components/mass/diagonalmass/)
Template of a Mass
diff --git a/20_Simulation_Principles/50_Multi-Model_Representation/12_ForceField.md b/20_Simulation_Principles/50_Multi-Model_Representation/12_ForceField.md
index 1ba862e65..5df0d12fe 100644
--- a/20_Simulation_Principles/50_Multi-Model_Representation/12_ForceField.md
+++ b/20_Simulation_Principles/50_Multi-Model_Representation/12_ForceField.md
@@ -3,7 +3,7 @@ ForceField
ForceFields are components that are adding "forces". These forces will influence the equilibrium of a system by contributing to its change of state.
-In continuum mechanics, these forces can be either internal or external forces. Internal forces corresponds to the effect of the soft body mechanics (elasticity, plasticity etc) and the external forces arise from external phenomenon (gravity, pressure etc). As detailed in the page [Physics Integration](./physics-integration/), the conservation of linear momentum in its generalized form can be written:
+In continuum mechanics, these forces can be either internal or external forces. Internal forces corresponds to the effect of the soft body mechanics (elasticity, plasticity etc) and the external forces arise from external phenomenon (gravity, pressure etc). As detailed in the page [Physics Integration](./../physics-integration/), the conservation of linear momentum in its generalized form can be written:
$$\rho \dot{v}=\rho \boldsymbol{b}+\nabla \cdot \boldsymbol{\sigma}$$
@@ -23,12 +23,12 @@ $$\mathbf{M}\Delta{v}=dt \cdot f(x)$$
where $$x$$ is the position (degrees of freedom), $$v$$ is the velocity (derivative in time of the degrees of freedom) and $$\mathbf{M}$$ is the mass matrix.
-As it is explained in the section [Integration Scheme](../system-resolution/integration-scheme/), the choice of the temporal scheme will influence the way the linear system $$\mathbf{A}x=b$$ is built.
+As it is explained in the section [Integration Scheme](../../system-resolution/integration-scheme/), the choice of the temporal scheme will influence the way the linear system $$\mathbf{A}x=b$$ is built.
### Explicit force
-Using an [explicit scheme](../../components/odesolver/forward/eulerexplicitsolver/) means that forces $$f(x)$$ are computed using the degrees of freedom of the current time step $$t$$ (which are known): $$f(x)=f(x(t))$$. Regardless the form of the function $$f$$, the value of $$f(x(t))$$ can directly be obtained and set in the right hand side vector $$b$$ of our linear system $$\mathbf{A}x=b$$.
+Using an [explicit scheme](../../../components/odesolver/forward/eulerexplicitsolver/) means that forces $$f(x)$$ are computed using the degrees of freedom of the current time step $$t$$ (which are known): $$f(x)=f(x(t))$$. Regardless the form of the function $$f$$, the value of $$f(x(t))$$ can directly be obtained and set in the right hand side vector $$b$$ of our linear system $$\mathbf{A}x=b$$.
The computation of the term $$f$$, the value of $$dt\cdot f(x(t))$$ is done through the function `addForce()` of the ForceField class, called by the integration scheme (ODESolver).
@@ -37,7 +37,7 @@ The computation of the term $$f$$, the value of $$dt\cdot f(x(t))$$ is done thro
### Implicit force
-Using an [implicit scheme](../../components/odesolver/backward/eulerimplicitsolver/) means that forces $$f(x)$$ are computed using the degrees of freedom of the next time step $$t+dt$$ (unknown yet): $$f(x)=f(x(t+dt))$$.
+Using an [implicit scheme](../../../components/odesolver/backward/eulerimplicitsolver/) means that forces $$f(x)$$ are computed using the degrees of freedom of the next time step $$t+dt$$ (unknown yet): $$f(x)=f(x(t+dt))$$.
The value of $$f(x(t))$$ can not be directly be computed. By using a Taylor expansion, we get:
$$\mathbf{M} \Delta v=dt \cdot \left( f(x(t)+\cdot \frac{\partial f}{\partial x} \Delta x \right)$$
@@ -56,7 +56,7 @@ For the **right hand side**:
- the term $$dt^2\cdot \frac{\partial f}{\partial x}v(t)$$ is computed by the function: `addDForce()`
-For the **left hand side**, the API used to compute it depends on the type of [Integration Scheme](../system-resolution/integration-scheme/) used: direct (the system matrix $$\mathbf{A}$$ is built and inversed) or iterative (unbuilt approach). We have:
+For the **left hand side**, the API used to compute it depends on the type of [Integration Scheme](../../system-resolution/integration-scheme/) used: direct (the system matrix $$\mathbf{A}$$ is built and inversed) or iterative (unbuilt approach). We have:
$$\mathbf{A}=\left( M-dt^2 \cdot \frac{\partial f}{\partial x} \right)$$
@@ -87,8 +87,8 @@ ForceField implementations
See examples of ForceField implementation:
-- [ConstantForceField](../../components/mechanicalload/constantforcefield/)
-- [TetrahedronFEMForceField](../../components/solidmechanics/fem/elasticity/tetrahedronfemforcefield/)
+- [ConstantForceField](../../../components/mechanicalload/constantforcefield/)
+- [TetrahedronFEMForceField](../../../components/solidmechanics/fem/elasticity/tetrahedronfemforcefield/)
diff --git a/20_Simulation_Principles/50_Multi-Model_Representation/20_Collision.md b/20_Simulation_Principles/50_Multi-Model_Representation/20_Collision.md
index eb58b6381..06e853628 100644
--- a/20_Simulation_Principles/50_Multi-Model_Representation/20_Collision.md
+++ b/20_Simulation_Principles/50_Multi-Model_Representation/20_Collision.md
@@ -1,7 +1,7 @@
Collisions
==========
-In all SOFA simulations, i.e. using any [animation loop](../animation-loop/), the collision phase is done separately from the physics simulation, and usually before the call to the solvers.
+In all SOFA simulations, i.e. using any [animation loop](../../animation-loop/), the collision phase is done separately from the physics simulation, and usually before the call to the solvers.
Collision detection is split in several phases, each implemented in a different component. Each phase is scheduled by the collision pipeline.
@@ -16,7 +16,7 @@ The collision pipeline follows three steps:
2. a collision detection
3. a collision response
-See a more detailed description of the [collision pipeline here](../../components/collision/detection/algorithm/collisionpipeline/).
+See a more detailed description of the [collision pipeline here](../../../components/collision/detection/algorithm/collisionpipeline/).
### Sequence Diagram
@@ -34,37 +34,37 @@ This contact information is passed to the contact manager, which creates contact
Given $$n$$ moving objects in a virtual environment, testing all objects pairs tend to perform $$n^2$$ pairwise checks.
When $$ \mathcal{O }(n^2)$$ complexity, the collision detection is usually divided into two successive steps:
-- a [broad phase](../../components/components/collision/detection/algorithm/broadphase/)
-- a [narrow phase](../../components/components/collision/detection/algorithm/narrowphase)
+- a [broad phase](../../../components/components/collision/detection/algorithm/broadphase/)
+- a [narrow phase](../../../components/components/collision/detection/algorithm/narrowphase)
-Several [broad phase](../../components/components/collision/detection/algorithm/broadphase/) and [narrow phase](../../components/components/collision/detection/algorithm/narrowphase) methods are available in SOFA.
-All of these methods will compute the contact points between collision models. The evaluation of these contacts will be done using Intersection Methods. Here again, various [intersection methods](../../components/collision/detection/intersection/intersectionmethod/) are available in SOFA. The choice of the collision detection method and the intersection method depends on your specific simulation use case.
+Several [broad phase](../../../components/components/collision/detection/algorithm/broadphase/) and [narrow phase](../../../components/components/collision/detection/algorithm/narrowphase) methods are available in SOFA.
+All of these methods will compute the contact points between collision models. The evaluation of these contacts will be done using Intersection Methods. Here again, various [intersection methods](../../../components/collision/detection/intersection/intersectionmethod/) are available in SOFA. The choice of the collision detection method and the intersection method depends on your specific simulation use case.
-All collision detection algorithms are available in *components/collision/detection/algorithm*, see for instance the [BruteForceBroadPhase](../../components/collision/detection/algorithm/bruteforcebroadphase/).
+All collision detection algorithms are available in *components/collision/detection/algorithm*, see for instance the [BruteForceBroadPhase](../../../components/collision/detection/algorithm/bruteforcebroadphase/).
### Broad phase
-The first step of the pipeline is the so-called [broad-phase](../../components/components/collision/detection/algorithm/broadphase/). It aims at quickly and efficiently removing objects pairs that are not in collision.
+The first step of the pipeline is the so-called [broad-phase](../../../components/components/collision/detection/algorithm/broadphase/). It aims at quickly and efficiently removing objects pairs that are not in collision.
The broad phase uses a set of root collision models in order to compute potentially colliding pairs. It can for instance rely on the bounding boxes of each object with a collision model, thus efficiently checking whether boxes collide or not. This step does not state if pairs of objects collide, but it detects if they *potentially* collide. As output, the broad phase returns pairs of potentially colliding collision models.
### Narrow phase: detect intersection
-The [narrow phase](../../components/components/collision/detection/algorithm/narrowphase) of detection can rely on collision models to detect a contact. Note that different collision models are available to detect a contact:
+The [narrow phase](../../../components/components/collision/detection/algorithm/narrowphase) of detection can rely on collision models to detect a contact. Note that different collision models are available to detect a contact:
- - using [primitives](../../components/collision/geometry/collisionmodels/) (mostly used): point, line, triangle, sphere, cube, cylinder or oriented bounding boxes (OBB)
+ - using [primitives](../../../components/collision/geometry/collisionmodels/) (mostly used): point, line, triangle, sphere, cube, cylinder or oriented bounding boxes (OBB)
- using distance grid, associated to each object in the scene
- using ray casting: that send rays in the volume of simulation to compute a volume of intersection
-All collision detection methods will rely on intersection methods during the broad and/or [narrow phase](../../components/components/collision/detection/algorithm/narrowphase) in order to assess if the models do collide. Given 2 collision elements, these intersection methods test if an intersection is possible.
+All collision detection methods will rely on intersection methods during the broad and/or [narrow phase](../../../components/components/collision/detection/algorithm/narrowphase) in order to assess if the models do collide. Given 2 collision elements, these intersection methods test if an intersection is possible.
In SOFA, a proximity method can be used to detect contact when two objects are getting closer to another. Evaluating this proximity allows for a better anticipation of the contact, i.e. more stable contact. The two main implementations in SOFA are:
-- [MinProximityIntersection](../../components/collision/detection/intersection/minproximityintersection/)
-- [LocalMinDistance](../../components/collision/detection/intersection/localmindistance/)
+- [MinProximityIntersection](../../../components/collision/detection/intersection/minproximityintersection/)
+- [LocalMinDistance](../../../components/collision/detection/intersection/localmindistance/)
Discrete intersection methods also exist to compute intersection only if models are already intersecting. These are using distance grid or ray: FFDDistanceGridDiscreteIntersection, RigidDistanceGridDiscreteIntersection, RayNewProximityIntersection, RayDiscreteIntersection.
@@ -73,7 +73,7 @@ Discrete intersection methods also exist to compute intersection only if models
Output of the detection
-----------------------
-As output, the collision detection (further to the [narrow phase](../../components/components/collision/detection/algorithm/narrowphase)) returns pairs of geometric primitives with the corresponding collision points. The collision information is saved in a vector of DetectionOutput. This data structure is a generic description of a contact point, used for most collision models except special cases such as GPU-based collisions.
+As output, the collision detection (further to the [narrow phase](../../../components/components/collision/detection/algorithm/narrowphase)) returns pairs of geometric primitives with the corresponding collision points. The collision information is saved in a vector of DetectionOutput. This data structure is a generic description of a contact point, used for most collision models except special cases such as GPU-based collisions.
Each contact point is described by a DetectionOutput made up of:
@@ -89,14 +89,14 @@ Each contact point is described by a DetectionOutput made up of:
Collision response
------------------
-The step of collision response is triggered in the [CollisionPipeline](../../components/collision/detection/algorithm/collisionpipeline/).
-The colliding models returned by the [narrow phase](../../components/components/collision/detection/algorithm/narrowphase) are finally given to the ContactManager, which creates contact interactions of various types based on customizable rules. You can specify which one you want to use in the DefaultContactManager. Response has been implemented based on:
+The step of collision response is triggered in the [CollisionPipeline](../../../components/collision/detection/algorithm/collisionpipeline/).
+The colliding models returned by the [narrow phase](../../../components/components/collision/detection/algorithm/narrowphase) are finally given to the ContactManager, which creates contact interactions of various types based on customizable rules. You can specify which one you want to use in the DefaultContactManager. Response has been implemented based on:
- the penalty method, efficient but subject to instability if not properly tuned
- the persistent method
-- or on constraints using [Lagrange multipliers](../constraint/lagrange-constraint/), and is processed by the solvers together with the other forces and constraints.
+- or on constraints using [Lagrange multipliers](../../constraint/lagrange-constraint/), and is processed by the solvers together with the other forces and constraints.
-When stiff contact penalties or contact constraints are created by the contact manager, an optional [GroupManager](../../components/collision/collisiongroupmanagers/collisiongroupmanager/) component is used to create interaction groups handled by a common solver.
+When stiff contact penalties or contact constraints are created by the contact manager, an optional [GroupManager](../../../components/collision/collisiongroupmanagers/collisiongroupmanager/) component is used to create interaction groups handled by a common solver.
When contacts disappear, interaction groups can be split to keep them as small as possible.
The scenegraph structure thus changes along with the interaction groups.
diff --git a/20_Simulation_Principles/60_Constraint/10_Projective_Constraint.md b/20_Simulation_Principles/60_Constraint/10_Projective_Constraint.md
index 09ce32f67..bb17afb0e 100644
--- a/20_Simulation_Principles/60_Constraint/10_Projective_Constraint.md
+++ b/20_Simulation_Principles/60_Constraint/10_Projective_Constraint.md
@@ -7,9 +7,9 @@ Different types of constraint exist in SOFA. The projective constraint are metho
Matrix approach
---------------
-A projection matrix noted $$\mathbf{P}$$ multiplies the matrix $$\mathbf{A}$$ of the linear system $$\mathbf{A}x=b$$ (where our unknown $$x$$ is actually $$\Delta{v}$$) to enforce the so-called project constraint. The system thus becomes: $$\mathbf{P}^T\mathbf{A}\mathbf{P} \Delta v=\mathbf{P}^Tb$$. Implicit integration has the advantage of being more stable for stiff forces or large time steps. The solution of these equation systems requires [linear solvers](../system-resolution/linear-solver/). Due to the superlinear time complexity of equation solvers, it is generally more efficient to process independent interaction groups using separated solvers rather than a unique solver.
+A projection matrix noted $$\mathbf{P}$$ multiplies the matrix $$\mathbf{A}$$ of the linear system $$\mathbf{A}x=b$$ (where our unknown $$x$$ is actually $$\Delta{v}$$) to enforce the so-called project constraint. The system thus becomes: $$\mathbf{P}^T\mathbf{A}\mathbf{P} \Delta v=\mathbf{P}^Tb$$. Implicit integration has the advantage of being more stable for stiff forces or large time steps. The solution of these equation systems requires [linear solvers](../../system-resolution/linear-solver/). Due to the superlinear time complexity of equation solvers, it is generally more efficient to process independent interaction groups using separated solvers rather than a unique solver.
-Another type of constraints is available in SOFA focusing on constraint-based interactions which requires the computation of Lagrange multipliers based on interaction Jacobians. This will be discussed in the next article about [Lagrange constraint](./lagrange-constraint/).
+Another type of constraints is available in SOFA focusing on constraint-based interactions which requires the computation of Lagrange multipliers based on interaction Jacobians. This will be discussed in the next article about [Lagrange constraint](./../lagrange-constraint/).
@@ -18,8 +18,8 @@ API of projective constraint
In SOFA, you can find several of these projective constraints in the SofaBoundaryConditions module, among them:
- - the [_FixedProjectiveConstraint_](../../components/constraint/projective/fixedprojectiveconstraint/): projecting a constant velocity, if the vertex is initially fixed, then it is attached to its initial position
- - the [_PartialFixedProjectiveConstraint_](../../components/constraint/projective/partialfixedprojectiveconstraint/): inheriting from _FixedProjectiveConstraint_, this constraint is projected only along certain degrees of freedom (e.g. only in x direction)
+ - the [_FixedProjectiveConstraint_](../../../components/constraint/projective/fixedprojectiveconstraint/): projecting a constant velocity, if the vertex is initially fixed, then it is attached to its initial position
+ - the [_PartialFixedProjectiveConstraint_](../../../components/constraint/projective/partialfixedprojectiveconstraint/): inheriting from _FixedProjectiveConstraint_, this constraint is projected only along certain degrees of freedom (e.g. only in x direction)
Classes considering on single object inherit from the class _ProjectiveConstraintSet_. The usual API functions associated to projective constraints are:
diff --git a/20_Simulation_Principles/60_Constraint/20_Lagrange_Constraint.md b/20_Simulation_Principles/60_Constraint/20_Lagrange_Constraint.md
index 02df81438..ebd143a0d 100644
--- a/20_Simulation_Principles/60_Constraint/20_Lagrange_Constraint.md
+++ b/20_Simulation_Principles/60_Constraint/20_Lagrange_Constraint.md
@@ -1,13 +1,13 @@
Constraint based on Lagrange Multipliers
========================================
-SOFA allows the use of Lagrange multipliers to handle complex constraints, such as contacts and joints between moving objets that can not be straightforwarly implemented using [projection matrices](./projective-constraint/).
+SOFA allows the use of Lagrange multipliers to handle complex constraints, such as contacts and joints between moving objets that can not be straightforwarly implemented using [projection matrices](./../projective-constraint/).
General presentation of the constraint problem
----------------------------------------------
-To solve the dynamic of two constrained objects, we use a Lagrange Multipliers approach and a single linearization by time step. From the [physical system](../multi-model-representation/physics-integration/) to solve, the constraint problem can be expressed with the linear system as:
+To solve the dynamic of two constrained objects, we use a Lagrange Multipliers approach and a single linearization by time step. From the [physical system](../../multi-model-representation/physics-integration/) to solve, the constraint problem can be expressed with the linear system as:
$$\left(\mathbf{M}+dt\textstyle\frac{\partial f}{\partial \dot{x}}+dt^2\textstyle\frac{\partial f}{\partial x}\right)\Delta v=-dt(f+dt\textstyle\frac{\partial f}{\partial x}v - \mathbf{H}^T\lambda)$$
@@ -61,11 +61,11 @@ Finally, the resolution of the constraint problem is done using the [Gauss-Seide
FreeMotionAnimationLoop
-----------------
-To solve such complex constraint-based interactions, the simulation requires a specific [animation loop](../animation-loop/): the [_FreeMotionAnimationLoop_](../../components/animationloop/freemotionanimationloop/). This animation loop divides each simulation step into two successive resolution steps: the free motion and a corrective motion.
+To solve such complex constraint-based interactions, the simulation requires a specific [animation loop](../../animation-loop/): the [_FreeMotionAnimationLoop_](../../../components/animationloop/freemotionanimationloop/). This animation loop divides each simulation step into two successive resolution steps: the free motion and a corrective motion.
#### Free motion ####
-The first step triggered by the _FreeMotionAnimationLoop_ is the free motion step. It consists in the resolution of the unconstrained (free) system $$\mathbf{A}x=b$$ as described in the System Resolution section. Note that this free resolution may also include [projective constraints](./projective-constraint) that will be projected on the linear system. In the same way, [collision](../multi-model-representation/collision) might also be detected and a response would be created.
+The first step triggered by the _FreeMotionAnimationLoop_ is the free motion step. It consists in the resolution of the unconstrained (free) system $$\mathbf{A}x=b$$ as described in the System Resolution section. Note that this free resolution may also include [projective constraints](./../projective-constraint) that will be projected on the linear system. In the same way, [collision](../../multi-model-representation/collision) might also be detected and a response would be created.
In the _solve()_ function of the _FreeMotionAnimationLoop_, you will find the following functions responsible for the free motion:
``` cpp
@@ -124,7 +124,7 @@ The step of building the system (see the [Build system](#build-system), [Constra
#### Build system ####
-This is the denser part of the constraint resolution. Most steps done to build the constraint problem are triggered using [visitors](../visitors/) browsing the simulation graph. All the following functions are actually not implemented by _ConstraintSolver_ but by the constraint laws available in the scene $$\Phi$$ and $$\Psi$$ (see the [Constraint law](#constraint-laws) section).
+This is the denser part of the constraint resolution. Most steps done to build the constraint problem are triggered using [visitors](../../visitors/) browsing the simulation graph. All the following functions are actually not implemented by _ConstraintSolver_ but by the constraint laws available in the scene $$\Phi$$ and $$\Psi$$ (see the [Constraint law](#constraint-laws) section).
The following steps are processed one after another:
@@ -187,7 +187,7 @@ ConstraintCorrection
As explained above, a _ConstraintCorrection_ is required in the simulation to define the way the compliance matrix $$\mathbf{W}$$ is computed. Different classes of _ConstraintCorrection_ exist in SOFA corresponding to different approaches:
- - _[UncoupledConstraintCorrection](../../components/constraint/lagrangian/correction/uncoupledconstraintcorrection/)_: makes the approximation that the compliance matrix $$\mathbf{W}$$ is diagonal. This is as strong assumption since a diagonal matrix means that all constraints are independent from each other. Note that you can directly specify the compliance matrix values within the Data field "compliance"
+ - _[UncoupledConstraintCorrection](../../../components/constraint/lagrangian/correction/uncoupledconstraintcorrection/)_: makes the approximation that the compliance matrix $$\mathbf{W}$$ is diagonal. This is as strong assumption since a diagonal matrix means that all constraints are independent from each other. Note that you can directly specify the compliance matrix values within the Data field "compliance"
- _LinearSolverConstraintCorrection_: computes the compliance matrix $$\mathbf{W}=\mathbf{H}\mathbf{A}^{-1}\mathbf{H}^T$$ where $$\mathbf{A}^{-1}$$ comes from a direct solver associated to the object. Since the direct solvers in SOFA factorize the matrix $$\mathbf{A}$$ (for instance using a LDL factorization if you use the _LDLSolver_), the factorization is reused to compute the compliance matrix. The matrix-matrix multiplication $$\mathbf{H}\mathbf{A}^{-1}\mathbf{H}^T$$ is not possible in case of a matrix-free solver, since the assembled inverse matrix $$\mathbf{A}^{-1}$$ is not available. From the factorization of $$\mathbf{A}$$, the computation of $$\mathbf{H}\mathbf{A}^{-1}\mathbf{H}^T$$ done in the function _addJMInvJt()_ requires to call the _solve()_ function from the direct solver, computing a matrix-vector multiplication, for each line of the constraint matrix $$\mathbf{H}$$, i.e. for each constraint. This approach can therefore be very computationally-demanding if you have many constraints. Note that this ConstraintCorrection proposes an optimization for wire-like structures (boolean option)
diff --git a/20_Simulation_Principles/70_Engine.md b/20_Simulation_Principles/70_Engine.md
index 74ed83c03..c1925a4e3 100644
--- a/20_Simulation_Principles/70_Engine.md
+++ b/20_Simulation_Principles/70_Engine.md
@@ -32,7 +32,7 @@ This function is in charge of the computation of the ouput Data based on the inp
Example of use
--------------
-Here is an example with the [TransformEngine](../components/engine/transform/transformengine/) with an input data ("input_position") and an output data ("output_position") resulting from a transformation defined by the user (here translation):
+Here is an example with the [TransformEngine](../../components/engine/transform/transformengine/) with an input data ("input_position") and an output data ("output_position") resulting from a transformation defined by the user (here translation):
``` xml
diff --git a/20_Simulation_Principles/90_Example-Simple_Body.md b/20_Simulation_Principles/90_Example-Simple_Body.md
index 85d0549a1..f9a3f373f 100644
--- a/20_Simulation_Principles/90_Example-Simple_Body.md
+++ b/20_Simulation_Principles/90_Example-Simple_Body.md
@@ -15,7 +15,7 @@ In an XML format, this would be written as follows:
State vectors (DOFs)
--------------------
-As described in [the introduction to state vectors](./mechanicalobject/#state-vectors), the degrees of freedom (DOFs) of your simulation are stored in state vectors. These vectors are managed by the main component of a simulation: the MechanicalObject. The SOFA framework was historically focused on soft tissue mechanics. Therefore, the semantic is strongly related to mechanics.
+As described in [the introduction to state vectors](./../mechanicalobject/#state-vectors), the degrees of freedom (DOFs) of your simulation are stored in state vectors. These vectors are managed by the main component of a simulation: the MechanicalObject. The SOFA framework was historically focused on soft tissue mechanics. Therefore, the semantic is strongly related to mechanics.
Depending on the physics (DOFs) you want to compute, you will have to choose the template of the MechanicalObject among: 1, 2, 3 or 6 reals per node, 1 rigid per node.
@@ -35,7 +35,7 @@ To solve the mathematical system at each time step, solvers have to be defined.
* an integration scheme, or ODE solver: Euler explicit, implicit, Runge Kutta, etc. This schemes describes how to compute the next state based on the current one.
* a linear solver: iterative (conjugate gradient) or direct (LU, LDL, etc.) to solve the linear system assembled by the previous integration scheme.
-Discover more about how the mathematical system is solved in SOFA in the [associated page](./system-resolution/integration-scheme/).
+Discover more about how the mathematical system is solved in SOFA in the [associated page](./../system-resolution/integration-scheme/).
In an XML format, this would be written as follows:
```xml
diff --git a/30_Components/10_AnimationLoop/10_DefaultAnimationLoop.md b/30_Components/10_AnimationLoop/10_DefaultAnimationLoop.md
index b44943734..c04629335 100644
--- a/30_Components/10_AnimationLoop/10_DefaultAnimationLoop.md
+++ b/30_Components/10_AnimationLoop/10_DefaultAnimationLoop.md
@@ -1,7 +1,7 @@
DefaultAnimationLoop
====================
-This component belongs to the category of [AnimationLoop](../../simulation-principles/animation-loop/).
+This component belongs to the category of [AnimationLoop](../../../simulation-principles/animation-loop/).
The DefaultAnimationLoop is the component that rules the steps of the simulation in the default order. It consists in computing the collision (if any), the projective constraints, the physics, solving the resulting linear system and finally updating all data before another step begins.
@@ -22,7 +22,7 @@ Usage
The DefaultAnimationLoop has **no pre-requisite**. If no AnimationLoop is specified in the scene, this animation loop is included by default at the root node of the graph.
-Note that this AnimationLoop does not support constraints solved using [Lagrange multipliers](../../simulation-principles/constraint/lagrange-constraint/).
+Note that this AnimationLoop does not support constraints solved using [Lagrange multipliers](../../../simulation-principles/constraint/lagrange-constraint/).
Example
diff --git a/30_Components/10_AnimationLoop/20_MultiStepAnimationLoop.md b/30_Components/10_AnimationLoop/20_MultiStepAnimationLoop.md
index 07a7d7ea5..25aec2023 100644
--- a/30_Components/10_AnimationLoop/20_MultiStepAnimationLoop.md
+++ b/30_Components/10_AnimationLoop/20_MultiStepAnimationLoop.md
@@ -1,9 +1,9 @@
MultiStepAnimationLoop
======================
-This component belongs to the category of [AnimationLoop](../../simulation-principles/animation-loop/).
+This component belongs to the category of [AnimationLoop](../../../simulation-principles/animation-loop/).
-The MultiStepAnimationLoop derives from the [DefaultAnimationLoop](../../components/animationloop/defaultanimationloop/). This animation loop is different due to the fact that it allows - at each iteration - for running several collision (_collisionSteps_), and within each of these collision steps, several integration sub-steps can be computed (_integrationSteps_).
+The MultiStepAnimationLoop derives from the [DefaultAnimationLoop](../../../components/animationloop/defaultanimationloop/). This animation loop is different due to the fact that it allows - at each iteration - for running several collision (_collisionSteps_), and within each of these collision steps, several integration sub-steps can be computed (_integrationSteps_).
@@ -13,4 +13,4 @@ Usage
The MultiStepAnimationLoop has **no pre-requisite**.
-Note that this MultiStepAnimationLoop does not handle constraints solved using [Lagrange multipliers](../../simulation-principles/constraint/lagrange-constraint/).
+Note that this MultiStepAnimationLoop does not handle constraints solved using [Lagrange multipliers](../../../simulation-principles/constraint/lagrange-constraint/).
diff --git a/30_Components/10_AnimationLoop/30_FreeMotionAnimationLoop.md b/30_Components/10_AnimationLoop/30_FreeMotionAnimationLoop.md
index 16a83955a..f33f78d62 100644
--- a/30_Components/10_AnimationLoop/30_FreeMotionAnimationLoop.md
+++ b/30_Components/10_AnimationLoop/30_FreeMotionAnimationLoop.md
@@ -1,9 +1,9 @@
FreeMotionAnimationLoop
=======================
-This component belongs to the category of [AnimationLoop](../../simulation-principles/animation-loop/).
+This component belongs to the category of [AnimationLoop](../../../simulation-principles/animation-loop/).
-The FreeMotionAnimationLoop is the component that rules the simulation in two main steps: a free motion, then a correction step. First, the free motion computes the projective constraints, the physics, solving the resulting free linear system. Second, the correction step solves the constraints based on the Lagrange multipliers. More information on the constraint resolution can be found [here](../../simulation-principles/constraint/lagrange-constraint/).
+The FreeMotionAnimationLoop is the component that rules the simulation in two main steps: a free motion, then a correction step. First, the free motion computes the projective constraints, the physics, solving the resulting free linear system. Second, the correction step solves the constraints based on the Lagrange multipliers. More information on the constraint resolution can be found [here](../../../simulation-principles/constraint/lagrange-constraint/).
@@ -13,7 +13,7 @@ Usage
The FreeMotionAnimationLoop must be used specifically for constraint resolution based on the Lagrange multiplier. It therefore **requires**:
-- a [ConstraintSolver](../../simulation-principles/constraint/lagrange-constraint/#constraintsolver-in-sofa). If no constraint solver can be found, a LCPConstraintSolver is automatically created by default.
+- a [ConstraintSolver](../../../simulation-principles/constraint/lagrange-constraint/#constraintsolver-in-sofa). If no constraint solver can be found, a LCPConstraintSolver is automatically created by default.
-Note that one or multiple [ConstraintCorrection](../../simulation-principles/constraint/lagrange-constraint/#constraintcorrection) may be required by the [ConstraintSolver](../../simulation-principles/constraint/lagrange-constraint/#constraintsolver-in-sofa).
+Note that one or multiple [ConstraintCorrection](../../../simulation-principles/constraint/lagrange-constraint/#constraintcorrection) may be required by the [ConstraintSolver](../../../simulation-principles/constraint/lagrange-constraint/#constraintsolver-in-sofa).
diff --git a/30_Components/15_Collision/10_Detection/10_Algorithm/10_CollisionPipeline.md b/30_Components/15_Collision/10_Detection/10_Algorithm/10_CollisionPipeline.md
index f054a7605..d0db69f47 100644
--- a/30_Components/15_Collision/10_Detection/10_Algorithm/10_CollisionPipeline.md
+++ b/30_Components/15_Collision/10_Detection/10_Algorithm/10_CollisionPipeline.md
@@ -3,7 +3,7 @@ Collision Pipelines
Collision between objects is split in several phases, each implemented in a different component.
Each phase is scheduled by a collision pipeline.
-The collision pipelines are executed in an [animation loop](../../../../simulation-principles/animation-loop/).
+The collision pipelines are executed in an [animation loop](../../../../../simulation-principles/animation-loop/).
The Steps
=========
@@ -17,7 +17,7 @@ The collision pipeline follows three steps:
Implementation
==============
-A collision pipeline is called from an [animation loop](../../../../simulation-principles/animation-loop/) through a CollisionVisitor executing the 3 steps of the pipeline in `CollisionVisitor::processCollisionPipeline`.
+A collision pipeline is called from an [animation loop](../../../../../simulation-principles/animation-loop/) through a CollisionVisitor executing the 3 steps of the pipeline in `CollisionVisitor::processCollisionPipeline`.
The visitor executes the following functions, each corresponding to a step of the pipeline:
```cpp
@@ -52,7 +52,7 @@ void doCollisionResponse() override;
```
The 3 delegate functions describe the 3 different steps, and are usually overriden in derived classes.
-See an example in [_DefaultPipeline_](./defaultpipeline).
+See an example in [_DefaultPipeline_](./../defaultpipeline).
Notes:
In some cases, the 3 steps are called manually by the animation loop through 3 dedicated visitors ([CollisionResetVisitor](https://www.sofa-framework.org/api/master/sofa/html/classsofa_1_1simulation_1_1_collision_reset_visitor.html), [CollisionDetectionVisitor](https://www.sofa-framework.org/api/master/sofa/html/classsofa_1_1simulation_1_1_collision_detection_visitor.html) and [CollisionResponseVisitor](https://www.sofa-framework.org/api/master/sofa/html/classsofa_1_1simulation_1_1_collision_response_visitor.html)).
@@ -64,7 +64,7 @@ Examples of Components
The following components are all collision pipelines, and can be placed in a simulation scene:
-- [_DefaultPipeline_](./defaultpipeline)
+- [_DefaultPipeline_](./../defaultpipeline)
Inheritance Diagram
===================
diff --git a/30_Components/15_Collision/10_Detection/10_Algorithm/15_BroadPhase.md b/30_Components/15_Collision/10_Detection/10_Algorithm/15_BroadPhase.md
index 7faa2f57f..fcdeb8969 100644
--- a/30_Components/15_Collision/10_Detection/10_Algorithm/15_BroadPhase.md
+++ b/30_Components/15_Collision/10_Detection/10_Algorithm/15_BroadPhase.md
@@ -1,7 +1,7 @@
Broad Phase Components
======================
-The broad phase collision detection components are executed in a [collision pipeline](../collisionpipeline).
+The broad phase collision detection components are executed in a [collision pipeline](../../collisionpipeline).
Introduction
============
@@ -16,7 +16,7 @@ For performances reasons, this approach is never selected because of its quadrat
Instead, the collision detection will be divided in two parts:
1. The broad phase collision detection
-2. The [narrow phase collision detection](../narrowphase)
+2. The [narrow phase collision detection](../../narrowphase)
The Broad Phase
===============
@@ -66,14 +66,14 @@ After the execution of the broad phase, the list of potential colliding pairs is
```cpp
sofa::helper::vector< CollisionModelPair > BroadPhaseDetection::cmPairs;
```
-Finally, the [collision pipeline](../collisionpipeline) provides this list to a [narrow phase collision detection](../narrowphase).
+Finally, the [collision pipeline](../../collisionpipeline) provides this list to a [narrow phase collision detection](../../narrowphase).
Examples of Components
======================
The following components are all broad phase collision detections, and can be placed in a simulation scene:
-- [BruteForceBroadPhase](./bruteforcebroadphase)
+- [BruteForceBroadPhase](./../bruteforcebroadphase)
- ParallelBruteForceBroadPhase (plugin MultiThreading)
- BruteForceDetection
- THMPGSpatialHashing (plugin THMPGSpatialHashing)
diff --git a/30_Components/15_Collision/10_Detection/10_Algorithm/17_BruteForceBroadPhase.md b/30_Components/15_Collision/10_Detection/10_Algorithm/17_BruteForceBroadPhase.md
index bd6e0bc27..d84495251 100644
--- a/30_Components/15_Collision/10_Detection/10_Algorithm/17_BruteForceBroadPhase.md
+++ b/30_Components/15_Collision/10_Detection/10_Algorithm/17_BruteForceBroadPhase.md
@@ -1,7 +1,7 @@
Broad Phase: Brute Force Broad Phase
====================================
-BruteForceBroadPhase is a [broad phase component](./broadphase), which is used in a [Collision Detection](../collisionpipeline/#collision-detection) pipeline.
+BruteForceBroadPhase is a [broad phase component](./../broadphase), which is used in a [Collision Detection](../../collisionpipeline/#collision-detection) pipeline.
The method is based on the comparison of the overall [bounding volumes](https://en.wikipedia.org/wiki/Bounding_volume) of objects to determine if they are in collision or not.
This test is very exhaustive because of its $$n^2/2$$ pairwise checks.
diff --git a/30_Components/15_Collision/10_Detection/10_Algorithm/20_DefaultPipeline.md b/30_Components/15_Collision/10_Detection/10_Algorithm/20_DefaultPipeline.md
index e715c3e56..8b3e340f7 100644
--- a/30_Components/15_Collision/10_Detection/10_Algorithm/20_DefaultPipeline.md
+++ b/30_Components/15_Collision/10_Detection/10_Algorithm/20_DefaultPipeline.md
@@ -1,10 +1,10 @@
Collision Pipelines: DefaultPipeline
==============================================
-The DefaultPipeline is a [Collision Pipeline](./collisionpipeline).
+The DefaultPipeline is a [Collision Pipeline](./../collisionpipeline).
It performs steps related to the collision, mainly collision detection and collision response.
-The [animation loop](../../../../simulation-principles/animation-loop/) executes the 3 steps of the pipeline (see documentation on [Collision Pipeline](./collisionpipeline)).
+The [animation loop](../../../../../simulation-principles/animation-loop/) executes the 3 steps of the pipeline (see documentation on [Collision Pipeline](./../collisionpipeline)).
Interaction with Other Components
=================================
@@ -12,10 +12,10 @@ Interaction with Other Components
_DefaultPipeline_ requires other components defined in the same context:
- An intersection method (e.g. MinProximityIntersection, LocalMinDistance)
-- A broad phase detection (e.g. [_BruteForceBroadPhase_](./bruteforcebroadphase))
-- A narrow phase detection (e.g. [_BVHNarrowPhase_](./bvhnarrowphase))
+- A broad phase detection (e.g. [_BruteForceBroadPhase_](./../bruteforcebroadphase))
+- A narrow phase detection (e.g. [_BVHNarrowPhase_](./../bvhnarrowphase))
- A contact manager (e.g. DefaultContactManager)
-- [optional] A group manager (e.g. [_DefaultCollisionGroupManager_](../../collisiongroupmanagers/collisiongroupmanager))
+- [optional] A group manager (e.g. [_DefaultCollisionGroupManager_](../../../collisiongroupmanagers/collisiongroupmanager))
If no intersection method is provided, a default _DiscreteIntersection_ component is created and added to the scene graph, with a warning to the user, and used as the intersection method.
diff --git a/30_Components/15_Collision/10_Detection/10_Algorithm/20_Detection_Sweep_and_Prune.md b/30_Components/15_Collision/10_Detection/10_Algorithm/20_Detection_Sweep_and_Prune.md
index c0afcf197..1aff1e75a 100644
--- a/30_Components/15_Collision/10_Detection/10_Algorithm/20_Detection_Sweep_and_Prune.md
+++ b/30_Components/15_Collision/10_Detection/10_Algorithm/20_Detection_Sweep_and_Prune.md
@@ -1,7 +1,7 @@
Collisions Detection: DirectSAP
===============================
-The DirectSAP component belongs to the category of [Collision Detection](../../../../simulation-principles/multi-model-representation/collision/#collision-detection).
+The DirectSAP component belongs to the category of [Collision Detection](../../../../../simulation-principles/multi-model-representation/collision/#collision-detection).
In this section, we describe the two collision detection methods based on the "[Sweep and Prune](https://en.wikipedia.org/wiki/Sweep_and_prune)" algorithm, noted SAP. The SAP method belongs to the topological methods for broad phase, based on the positions of objects in relation to others.
@@ -32,12 +32,12 @@ It is one of the most used methods in the broad-phase algorithms because it prov
- the second part is in charge of the detection of overlapping between objects. To do that a projection of higher and upper bounds on the three axis of coordinates (x, y and z) of each
AABBs is made.
-Only the pairs of objects whose projected bounding volumes overlap on all axes will be saved in the set of active boxes to be considered for the narrow phase. We can notice two related but different concepts on the way the SAP operates internally: the **DirectSAP** starts from scratch each time even though internal structures could be updated as performed in the [IncrSAP](./incrsap/).
+Only the pairs of objects whose projected bounding volumes overlap on all axes will be saved in the set of active boxes to be considered for the narrow phase. We can notice two related but different concepts on the way the SAP operates internally: the **DirectSAP** starts from scratch each time even though internal structures could be updated as performed in the [IncrSAP](./../incrsap/).
### Narrow phase
-The narrow phase browses all boxes considered as active by the broad phase. From this information, it is possible to recover the finest CollisionModel (which is not a CubeModel) corresponding to each box. An intersection check will then be done between these pairs. This check also depends on the [intersection method](../../../../simulation-principles/multi-model-representation/collision/#intersection-methods) used. This last phase returns the DetectionOutput vector containing elements of CollisionModels in collision and the contact points on the surface of each model.
+The narrow phase browses all boxes considered as active by the broad phase. From this information, it is possible to recover the finest CollisionModel (which is not a CubeModel) corresponding to each box. An intersection check will then be done between these pairs. This check also depends on the [intersection method](../../../../../simulation-principles/multi-model-representation/collision/#intersection-methods) used. This last phase returns the DetectionOutput vector containing elements of CollisionModels in collision and the contact points on the surface of each model.
diff --git a/30_Components/15_Collision/10_Detection/10_Algorithm/25_Detection_SAP_Incremental.md b/30_Components/15_Collision/10_Detection/10_Algorithm/25_Detection_SAP_Incremental.md
index b9a609fa2..04c211c73 100644
--- a/30_Components/15_Collision/10_Detection/10_Algorithm/25_Detection_SAP_Incremental.md
+++ b/30_Components/15_Collision/10_Detection/10_Algorithm/25_Detection_SAP_Incremental.md
@@ -1,11 +1,11 @@
Collisions Detection: IncrSAP
=============================
-The IncrSAP component belongs to the category of [Collision Detection](../../../../simulation-principles/multi-model-representation/collision/#collision-detection). In this section, we describe the two collision detection methods based on the "[Sweep and Prune](https://en.wikipedia.org/wiki/Sweep_and_prune)" algorithm, noted SAP. The SAP method belongs to the topological methods for broad phase, based on the positions of objects in relation to others.
+The IncrSAP component belongs to the category of [Collision Detection](../../../../../simulation-principles/multi-model-representation/collision/#collision-detection). In this section, we describe the two collision detection methods based on the "[Sweep and Prune](https://en.wikipedia.org/wiki/Sweep_and_prune)" algorithm, noted SAP. The SAP method belongs to the topological methods for broad phase, based on the positions of objects in relation to others.
-IncrSAP corresponds to the implementation of SAP in an incremental manner, i.e. collision primitives are stored and updated which should speed up the collision detection compared to the [DirectSAPNarrowPhase](./directsapnarrowphase/).
+IncrSAP corresponds to the implementation of SAP in an incremental manner, i.e. collision primitives are stored and updated which should speed up the collision detection compared to the [DirectSAPNarrowPhase](./../directsapnarrowphase/).
### Preliminary phase
@@ -29,13 +29,13 @@ It is one of the most used methods in the broad-phase algorithms because it prov
- the second part is in charge of the detection of overlapping between objects. To do that a projection of higher and upper bounds on the three axis of coordinates (x, y and z) of each
AABBs is made.
-Only the pairs of objects whose projected bounding volumes overlap on all axes will be saved in the set of active boxes to be considered for the narrow phase. Unlike like the [DirectSAPNarrowPhase](./directsapnarrowphase/) which starts from scratch at each time step, the IncrSAP updates internal structures: this is the **IncrSAP** and should therefore be fore efficient.
+Only the pairs of objects whose projected bounding volumes overlap on all axes will be saved in the set of active boxes to be considered for the narrow phase. Unlike like the [DirectSAPNarrowPhase](./../directsapnarrowphase/) which starts from scratch at each time step, the IncrSAP updates internal structures: this is the **IncrSAP** and should therefore be fore efficient.
### Narrow phase
-The narrow phase browses all boxes considered as active by the broad phase. From this information, it is possible to recover the finest CollisionModel (which is not a CubeModel) corresponding to each box. An intersection check will then be done between these pairs. This check also depends on the [intersection method](../../../../simulation-principles/multi-model-representation/collision/#intersection-methods) used. This last phase returns the DetectionOutput vector containing elements of CollisionModels in collision and the contact points on the surface of each model.
+The narrow phase browses all boxes considered as active by the broad phase. From this information, it is possible to recover the finest CollisionModel (which is not a CubeModel) corresponding to each box. An intersection check will then be done between these pairs. This check also depends on the [intersection method](../../../../../simulation-principles/multi-model-representation/collision/#intersection-methods) used. This last phase returns the DetectionOutput vector containing elements of CollisionModels in collision and the contact points on the surface of each model.
diff --git a/30_Components/15_Collision/10_Detection/10_Algorithm/30_NarrowPhase.md b/30_Components/15_Collision/10_Detection/10_Algorithm/30_NarrowPhase.md
index 129d4a313..b27cf1e0d 100644
--- a/30_Components/15_Collision/10_Detection/10_Algorithm/30_NarrowPhase.md
+++ b/30_Components/15_Collision/10_Detection/10_Algorithm/30_NarrowPhase.md
@@ -1,7 +1,7 @@
Narrow Phase Components
======================
-The narrow phase collision detection components are executed in a [collision pipeline](../collisionpipeline).
+The narrow phase collision detection components are executed in a [collision pipeline](../../collisionpipeline).
Introduction
============
@@ -14,7 +14,7 @@ The number of tests depends on the number of objects, and the number of collisio
For performances reasons, this approach is never selected because of its quadratic complexity.
Instead, the collision detection will be divided in two parts:
-1. The [broad phase collision detection](../broadphase)
+1. The [broad phase collision detection](../../broadphase)
2. The narrow phase collision detection
The Narrow Phase
@@ -25,7 +25,7 @@ The broad phase output is a list of collision models potentially in collision.
The goal of the narrow phase is to examine the list more closely and determine if they are actually in intersection.
If it is the case, it detects which elements are in intersection.
-Following the [DefaultPipeline](../defaultpipeline), the output of the narrow phase is provided to the contact manager.
+Following the [DefaultPipeline](../../defaultpipeline), the output of the narrow phase is provided to the contact manager.
The Implementation
------------------
@@ -68,7 +68,7 @@ Examples of Components
The following components are all narrow phase collision detections, and can be placed in a simulation scene:
-- [BVHNarrowPhase](../bvhnarrowphase)
+- [BVHNarrowPhase](../../bvhnarrowphase)
- ParallelBVHNarrowPhase (plugin MultiThreading)
- DirectSAPNarrowPhase
diff --git a/30_Components/15_Collision/10_Detection/10_Algorithm/31_BVHNarrowPhase.md b/30_Components/15_Collision/10_Detection/10_Algorithm/31_BVHNarrowPhase.md
index 395473442..9be2c1508 100644
--- a/30_Components/15_Collision/10_Detection/10_Algorithm/31_BVHNarrowPhase.md
+++ b/30_Components/15_Collision/10_Detection/10_Algorithm/31_BVHNarrowPhase.md
@@ -1,7 +1,7 @@
Narrow Phase: BVH Narrow Phase
==============================
-BVHNarrowPhase is [narrow phase component](./narrowphase), which is used in the detection phase of a [CollisionPipeline](../collisionpipeline/#collision-detection).
+BVHNarrowPhase is [narrow phase component](./../narrowphase), which is used in the detection phase of a [CollisionPipeline](../../collisionpipeline/#collision-detection).
The algorithm is based on a Bounding Volume Hierarchy (BVH).
diff --git a/30_Components/15_Collision/10_Detection/10_Algorithm/32_DirectSAPNarrowPhase.md b/30_Components/15_Collision/10_Detection/10_Algorithm/32_DirectSAPNarrowPhase.md
index 807525a04..e91ce6468 100644
--- a/30_Components/15_Collision/10_Detection/10_Algorithm/32_DirectSAPNarrowPhase.md
+++ b/30_Components/15_Collision/10_Detection/10_Algorithm/32_DirectSAPNarrowPhase.md
@@ -1,15 +1,15 @@
Narrow Phase: Direct SAP Narrow Phase
=====================================
-_DirectSAPNarrowPhase_ is a [narrow phase component](./narrowphase), which is used in the detection phase of a [CollisionPipeline](../collisionpipeline/#collision-detection).
+_DirectSAPNarrowPhase_ is a [narrow phase component](./../narrowphase), which is used in the detection phase of a [CollisionPipeline](../../collisionpipeline/#collision-detection).
The algorithm is based on the "[Sweep and Prune](https://en.wikipedia.org/wiki/Sweep_and_prune)" algorithm, noted SAP.
The Algorithm
=============
-As mentioned in [Narrow Phase](./narrowphase), _DirectSAPNarrowPhase_ input is a list of pairs of [collision models](../../../geometry/collisionmodels/).
-Among this list, if it is the first time that a [collision model](../../../geometry/collisionmodels/) is provided to _DirectSAPNarrowPhase_, a list of Axis-Aligned Bounding Box (AABB) is created.
-Each associated to a collision element of the new [collision model](../../../geometry/collisionmodels/).
+As mentioned in [Narrow Phase](./../narrowphase), _DirectSAPNarrowPhase_ input is a list of pairs of [collision models](../../../../geometry/collisionmodels/).
+Among this list, if it is the first time that a [collision model](../../../../geometry/collisionmodels/) is provided to _DirectSAPNarrowPhase_, a list of Axis-Aligned Bounding Box (AABB) is created.
+Each associated to a collision element of the new [collision model](../../../../geometry/collisionmodels/).
This list is saved from a time step to the next.
In the second step, all the AABB are updated according to the geometry of the collision elements in the current time step.
diff --git a/30_Components/15_Collision/10_Detection/10_Algorithm/33_RayTraceNarrowPhase.md b/30_Components/15_Collision/10_Detection/10_Algorithm/33_RayTraceNarrowPhase.md
index 9db9491f4..b4265f32d 100644
--- a/30_Components/15_Collision/10_Detection/10_Algorithm/33_RayTraceNarrowPhase.md
+++ b/30_Components/15_Collision/10_Detection/10_Algorithm/33_RayTraceNarrowPhase.md
@@ -1,7 +1,7 @@
Narrow Phase: Ray Trace Narrow Phase
====================================
-The RayTraceNarrowPhase component is a [narrow phase component](./narrowphase), which is used in the detection phase of a [CollisionPipeline](../collisionpipeline/#collision-detection).
+The RayTraceNarrowPhase component is a [narrow phase component](./../narrowphase), which is used in the detection phase of a [CollisionPipeline](../../collisionpipeline/#collision-detection).
This method traces a ray for each point in one object following the opposite of the point's normal up to find a triangle in the other object.
Both triangles are tested to evaluate if they are in a colliding state.
diff --git a/30_Components/15_Collision/10_Detection/20_Intersection/10_IntersectionMethod.md b/30_Components/15_Collision/10_Detection/20_Intersection/10_IntersectionMethod.md
index 67d55e7c1..537c07282 100644
--- a/30_Components/15_Collision/10_Detection/20_Intersection/10_IntersectionMethod.md
+++ b/30_Components/15_Collision/10_Detection/20_Intersection/10_IntersectionMethod.md
@@ -9,8 +9,8 @@ Examples of Components
The following components are all intersection methods, and can be placed in a simulation scene:
-- [_MinProximityIntersection_](./minproximityintersection)
-- [_LocalMinDistance_](./localmindistance)
+- [_MinProximityIntersection_](./../minproximityintersection)
+- [_LocalMinDistance_](./../localmindistance)
Inheritance Diagram
===================
diff --git a/30_Components/15_Collision/10_Detection/20_Intersection/50_MinProximityIntersection.md b/30_Components/15_Collision/10_Detection/20_Intersection/50_MinProximityIntersection.md
index 4b04012ef..f5883707e 100644
--- a/30_Components/15_Collision/10_Detection/20_Intersection/50_MinProximityIntersection.md
+++ b/30_Components/15_Collision/10_Detection/20_Intersection/50_MinProximityIntersection.md
@@ -1,7 +1,7 @@
MinProximityIntersection
========================
-This proximity method for [intersection detection](../../../../simulation-principles/multi-model-representation/collision/#narrow-phase-detect-intersection):
+This proximity method for [intersection detection](../../../../../simulation-principles/multi-model-representation/collision/#narrow-phase-detect-intersection):
- detects a possible contact as soon as pair of collision elements are close to each other (distance smaller than the alarmDistance)
- and creates contact (aka DetectionOutput) when the distance is lower than contactDistance.
@@ -25,7 +25,7 @@ Moreover, the contacts can be a bit degenerated: many contacts with different or
Usage
-----
-The MinProximityIntersection must be placed right after the CollisionPipeline and the associated Detection methods (usually [BruteForceBroadPhase](../algorithm/bruteforcebroadphase/) and [BVHNarrowPhase](../algorithm/bvhnarrowphase/)) on top the scene graph.
+The MinProximityIntersection must be placed right after the CollisionPipeline and the associated Detection methods (usually [BruteForceBroadPhase](../../algorithm/bruteforcebroadphase/) and [BVHNarrowPhase](../../algorithm/bvhnarrowphase/)) on top the scene graph.
Additional information
diff --git a/30_Components/15_Collision/10_Detection/20_Intersection/60_LocalMinDistance.md b/30_Components/15_Collision/10_Detection/20_Intersection/60_LocalMinDistance.md
index 64741a6fa..a84df78d4 100644
--- a/30_Components/15_Collision/10_Detection/20_Intersection/60_LocalMinDistance.md
+++ b/30_Components/15_Collision/10_Detection/20_Intersection/60_LocalMinDistance.md
@@ -1,7 +1,7 @@
LocalMinDistance
================
-This proximity method is an [intersection detection](../../../../simulation-principles/multi-model-representation/collision/#narrow-phase-detect-intersection) close to the previous [MinProximityIntersection](./minproximityintersection/) but in addition, it filters the list of DetectionOutput to keep only the contacts with the local minimal distance.
+This proximity method is an [intersection detection](../../../../../simulation-principles/multi-model-representation/collision/#narrow-phase-detect-intersection) close to the previous [MinProximityIntersection](./../minproximityintersection/) but in addition, it filters the list of DetectionOutput to keep only the contacts with the local minimal distance.
To find an optimal number of contact points, the LocalMinDistance computes cones on all nodes of the collision model. A cone is the combination of the orthogonal directions/planes of the neighboring lines/surfaces.
@@ -28,7 +28,7 @@ The cones on the sides (no 1 and 3) are open with an 90 degree angle, while the
Usage
-----
-The MinProximityIntersection must be placed right after the CollisionPipeline and the associated Detection method (usually [BruteForce](../algorithm/bruteforcebroadphase/)) on top the scene graph.
+The MinProximityIntersection must be placed right after the CollisionPipeline and the associated Detection method (usually [BruteForce](../../algorithm/bruteforcebroadphase/)) on top the scene graph.
Additional information
diff --git a/30_Components/15_Collision/20_Geometry/40_CollisionModels.md b/30_Components/15_Collision/20_Geometry/40_CollisionModels.md
index f689beb23..06f931e0a 100644
--- a/30_Components/15_Collision/20_Geometry/40_CollisionModels.md
+++ b/30_Components/15_Collision/20_Geometry/40_CollisionModels.md
@@ -3,17 +3,17 @@ Collision Models
SOFA implements a series of collision primitives called CollisionModel. A CollisionModel contains a list of same-type elements. It can be part of a list of CollisionModels or a hierarchy. Here is a list of them:
-- [PointCollisionModel](./PointCollisionModel)
-- [LineCollisionModel](./LineCollisionModel)
-- [TriangleCollisionModel](./TriangleCollisionModel)
-- [SphereCollisionModel](./SphereCollisionModel)
-- [CylinderCollisionModel](./CylinderCollisionModel)
-- [CubeCollisionModel](./CubeCollisionModel)
-- [RayCollisionModel](./RayCollisionModel)
+- [PointCollisionModel](./../PointCollisionModel)
+- [LineCollisionModel](./../LineCollisionModel)
+- [TriangleCollisionModel](./../TriangleCollisionModel)
+- [SphereCollisionModel](./../SphereCollisionModel)
+- [CylinderCollisionModel](./../CylinderCollisionModel)
+- [CubeCollisionModel](./../CubeCollisionModel)
+- [RayCollisionModel](./../RayCollisionModel)
See the detailed description of the [CollisionModel class](https://www.sofa-framework.org/api/master/sofa/html/classsofa_1_1core_1_1_collision_model.html).
-Note that the data **contactStiffness** is only taken into account in the case you are using a collision response using the [Penalty method](../../../simulation-principles/multi-model-representation/collision/#collision-response).
+Note that the data **contactStiffness** is only taken into account in the case you are using a collision response using the [Penalty method](../../../../simulation-principles/multi-model-representation/collision/#collision-response).
diff --git a/30_Components/15_Collision/60_CollisionGroupManagers/10_CollisionGroupManager.md b/30_Components/15_Collision/60_CollisionGroupManagers/10_CollisionGroupManager.md
index b3dd2449b..432f925de 100644
--- a/30_Components/15_Collision/60_CollisionGroupManagers/10_CollisionGroupManager.md
+++ b/30_Components/15_Collision/60_CollisionGroupManagers/10_CollisionGroupManager.md
@@ -1,26 +1,26 @@
Collision Group Managers
========================
-The collision group manager components are used in a [collision pipeline](../../../using-sofa/components/collision/detection/algorithm/collisionpipeline).
+The collision group manager components are used in a [collision pipeline](../../../../using-sofa/components/collision/detection/algorithm/collisionpipeline).
The role of a collision group manager is to find and merge solvers for a contact, i.e. two different objects in collision, into groups.
The term 'group' refers to a group of integration components.
-It includes an [ODE solver](../../../using-sofa/simulation-principles/system-resolution/integration-scheme), its associated [linear solver](../../../simulation-principles/system-resolution/linear-solver/) and the [constraint solver](../../../using-sofa/simulation-principles/constraint/lagrange-constraint).
+It includes an [ODE solver](../../../../using-sofa/simulation-principles/system-resolution/integration-scheme), its associated [linear solver](../../../../simulation-principles/system-resolution/linear-solver/) and the [constraint solver](../../../../using-sofa/simulation-principles/constraint/lagrange-constraint).
_DefaultCollisionGroupManager_ modifies the scene graph so that two objects in contact share the same node with a single integration algorithm.
In that case, the integration algorithm solves the ODE of the two objects simultaneously.
-In [DefaultPipeline](../../../using-sofa/components/collision/detection/algorithm/defaultpipeline), groups are created only for contacts between two non-static objects.
+In [DefaultPipeline](../../../../using-sofa/components/collision/detection/algorithm/defaultpipeline), groups are created only for contacts between two non-static objects.
After creating the groups, _DefaultCollisionGroupManager_ is also in charge to create the contact responses.
## Merging Two Integration Nodes
It is possible that two objects in contact are not solved with the same type of solver.
-For example, _objectA_ can be solved with [EulerImplicitSolver](../../../components/odesolver/backward/eulerimplicitsolver/), and _objectB_ with [EulerExplicitSolver](../../../components/odesolver/forward/eulerexplicitsolver/).
+For example, _objectA_ can be solved with [EulerImplicitSolver](../../../../components/odesolver/backward/eulerimplicitsolver/), and _objectB_ with [EulerExplicitSolver](../../../../components/odesolver/forward/eulerexplicitsolver/).
In that case, some rules are pre-defined to select which one is kept.
The other one is removed.
Usually, the more stable or precise solver is preferred.
-For example, [EulerImplicitSolver](../../../components/odesolver/backward/eulerimplicitsolver/), is preferred over [EulerExplicitSolver](../../../components/odesolver/forward/eulerexplicitsolver/).
+For example, [EulerImplicitSolver](../../../../components/odesolver/backward/eulerimplicitsolver/), is preferred over [EulerExplicitSolver](../../../../components/odesolver/forward/eulerexplicitsolver/).
In case both ODE solvers are of the same type, but still a different instance, pre-defined rules merge Data values of both ODE solvers.
@@ -33,13 +33,13 @@ Interaction with Other Components
==============
A collision group manager is optional in a simulation scene.
-A [collision pipeline](../../../using-sofa/components/collision/detection/algorithm/collisionpipeline) uses it if one is defined in the scene.
-It is usually a good practice to place the group manager near the [collision pipeline](../../../using-sofa/components/collision/detection/algorithm/collisionpipeline), at the same level (not in a child node).
+A [collision pipeline](../../../../using-sofa/components/collision/detection/algorithm/collisionpipeline) uses it if one is defined in the scene.
+It is usually a good practice to place the group manager near the [collision pipeline](../../../../using-sofa/components/collision/detection/algorithm/collisionpipeline), at the same level (not in a child node).
Implementation
==============
-The following function must be called in the [collision pipeline](../../../using-sofa/components/collision/detection/algorithm/collisionpipeline), once contacts have been detected:
+The following function must be called in the [collision pipeline](../../../../using-sofa/components/collision/detection/algorithm/collisionpipeline), once contacts have been detected:
```cpp
/// Create the integration groups
void CollisionGroupManager::createGroups(objectmodel::BaseContext* scene, const sofa::helper::vector& contacts)
diff --git a/30_Components/20_Constraint/10_Projective/10_AttachProjectiveConstraint.md b/30_Components/20_Constraint/10_Projective/10_AttachProjectiveConstraint.md
index 0a85d8b43..2149aadaf 100644
--- a/30_Components/20_Constraint/10_Projective/10_AttachProjectiveConstraint.md
+++ b/30_Components/20_Constraint/10_Projective/10_AttachProjectiveConstraint.md
@@ -1,7 +1,7 @@
AttachProjectiveConstraint
================
-This component belongs to the category of [Projective Constraint](../../../simulation-principles/constraint/projective-constraint/).
+This component belongs to the category of [Projective Constraint](../../../../simulation-principles/constraint/projective-constraint/).
The AttachProjectiveConstraint works with a pair of objects, and it projects the degrees of freedom (e.g. position) and their derivatives (e.g. velocity), so that both objects are attached.
As being a projective constraint, this projective constraints ensures a geometrical connection between both objects at the end of the time step, but it does not integrate the physics of both object (contrary to Lagrange based constraints).
diff --git a/30_Components/20_Constraint/10_Projective/50_FixedProjectiveConstraint.md b/30_Components/20_Constraint/10_Projective/50_FixedProjectiveConstraint.md
index 0248cd123..2a2b29c74 100644
--- a/30_Components/20_Constraint/10_Projective/50_FixedProjectiveConstraint.md
+++ b/30_Components/20_Constraint/10_Projective/50_FixedProjectiveConstraint.md
@@ -1,7 +1,7 @@
FixedProjectiveConstraint
=========================
-This component belongs to the category of [Projective Constraint](../../../simulation-principles/constraint/projective-constraint/).
+This component belongs to the category of [Projective Constraint](../../../../simulation-principles/constraint/projective-constraint/).
The FixedProjectiveConstraint projects a constant velocity. If the fixed points have a zero velocity at the simulation start, they will keep a zero velocity i.e. be fixed.
As introduced in the page about the Projective Constraint, the FixedProjectiveConstraint corresponds to a projection matrix noted $$\mathbf{P}$$ which will multiply the system matrix $$\mathbf{A}$$ so that: $$\mathbf{P}^T\mathbf{A}\mathbf{P}\Deltav=\mathbf{P}^Tb$$. This projection matrix $$\mathbf{P}$$ is the identity matrix in which the diagonal value corresponding to the indices of the fixed points equals zero. These lines and columns equals 0. As a consequence, when the integration scheme (ODESolver) will call the ```projectResponse()``` or ```projectVelocity()``` the constraint will be applied, ensuring that the desired degrees of freedom remain fixed.
diff --git a/30_Components/20_Constraint/20_Lagrangian/Model/30_BilateralLagrangianConstraint.md b/30_Components/20_Constraint/20_Lagrangian/Model/30_BilateralLagrangianConstraint.md
index 658e81bc6..824503bdd 100644
--- a/30_Components/20_Constraint/20_Lagrangian/Model/30_BilateralLagrangianConstraint.md
+++ b/30_Components/20_Constraint/20_Lagrangian/Model/30_BilateralLagrangianConstraint.md
@@ -1,7 +1,7 @@
BilateralLagrangianConstraint
==============================
-This component belongs to the category of [Constraint Laws](../../../../simulation-principles/constraint/lagrange-constraint/#constraint-laws) used for the Lagrange constraint resolution and inherits from the PairInteractionConstraint. The BilateralLagrangianConstraint defines an [holonomic constraint](https://en.wikipedia.org/wiki/Holonomic_constraints) law between a pair of simulated body, i.e. the constraint defined between the pair of objects must have an equality form:
+This component belongs to the category of [Constraint Laws](../../../../../simulation-principles/constraint/lagrange-constraint/#constraint-laws) used for the Lagrange constraint resolution and inherits from the PairInteractionConstraint. The BilateralLagrangianConstraint defines an [holonomic constraint](https://en.wikipedia.org/wiki/Holonomic_constraints) law between a pair of simulated body, i.e. the constraint defined between the pair of objects must have an equality form:
$$\Phi(x_1,x_2...)~=~0$$
@@ -23,7 +23,7 @@ As all constraint laws, the BilateralLagrangianConstraint will be called in the
Usage
-----
-The BilateralLagrangianConstraint can only be used in the context of [Lagrange constraint](../../../../simulation-principles/constraint/lagrange-constraint/) resolution. The scene must therefore contain:
+The BilateralLagrangianConstraint can only be used in the context of [Lagrange constraint](../../../../../simulation-principles/constraint/lagrange-constraint/) resolution. The scene must therefore contain:
- a FreeMotionAnimationLoop
- a ConstraintSolver
diff --git a/30_Components/20_Constraint/20_Lagrangian/Model/50_UnilateralLagrangianConstraint.md b/30_Components/20_Constraint/20_Lagrangian/Model/50_UnilateralLagrangianConstraint.md
index d2e6b358e..7973c61b4 100644
--- a/30_Components/20_Constraint/20_Lagrangian/Model/50_UnilateralLagrangianConstraint.md
+++ b/30_Components/20_Constraint/20_Lagrangian/Model/50_UnilateralLagrangianConstraint.md
@@ -2,7 +2,7 @@ UnilateralLagrangianConstraint
===============================
-This component belongs to the category of [Constraint Laws](../../../../simulation-principles/constraint/lagrange-constraint/#constraint-laws) used for the Lagrange constraint resolution and inherits from the PairInteractionConstraint. The UnilateralLagrangianConstraint defines an [non-holonomic constraint](https://en.wikipedia.org/wiki/Nonholonomic_system) law between a pair of simulated body, i.e. the constraint defined between the pair of objects must have an inequality form:
+This component belongs to the category of [Constraint Laws](../../../../../simulation-principles/constraint/lagrange-constraint/#constraint-laws) used for the Lagrange constraint resolution and inherits from the PairInteractionConstraint. The UnilateralLagrangianConstraint defines an [non-holonomic constraint](https://en.wikipedia.org/wiki/Nonholonomic_system) law between a pair of simulated body, i.e. the constraint defined between the pair of objects must have an inequality form:
$$\Psi(x_1,x_2...)~\geq~0$$
@@ -24,7 +24,7 @@ As all constraint laws, the UnilateralLagrangianConstraint will be called in the
Usage
-----
-The UnilateralLagrangianConstraint can only be used in the context of [Lagrange constraint](../../../../simulation-principles/constraint/lagrange-constraint/) resolution. The scene must therefore contain:
+The UnilateralLagrangianConstraint can only be used in the context of [Lagrange constraint](../../../../../simulation-principles/constraint/lagrange-constraint/) resolution. The scene must therefore contain:
- a FreeMotionAnimationLoop
- a ConstraintSolver
diff --git a/30_Components/25_Engine/10_Generate/32_Vertex2Frame.md b/30_Components/25_Engine/10_Generate/32_Vertex2Frame.md
index 0218b0bcb..7823a23d0 100644
--- a/30_Components/25_Engine/10_Generate/32_Vertex2Frame.md
+++ b/30_Components/25_Engine/10_Generate/32_Vertex2Frame.md
@@ -1,7 +1,7 @@
Vertex2Frame
============
-This component belongs to the category of [Engines](../../../simulation-principles/engine/). For each point defined in an .obj file, this engine computes a set of rigid points using the normals. Normal vector will be collinear to the Z axis and orthonormal to X and Y as showed bellow:
+This component belongs to the category of [Engines](../../../../simulation-principles/engine/). For each point defined in an .obj file, this engine computes a set of rigid points using the normals. Normal vector will be collinear to the Z axis and orthonormal to X and Y as showed bellow:
```
Y
diff --git a/30_Components/25_Engine/20_Select/10_ROI_Selection.md b/30_Components/25_Engine/20_Select/10_ROI_Selection.md
index 10564a377..b158ca75f 100644
--- a/30_Components/25_Engine/20_Select/10_ROI_Selection.md
+++ b/30_Components/25_Engine/20_Select/10_ROI_Selection.md
@@ -1,7 +1,7 @@
ROI Selection
=============
-An [Engine](../../../simulation-principles/engine/) is a component that computes a set of output Data's from a set of input Data's. Several ROI engines (standing for "Region Of Interest") allow for selecting topological elements of an object. Three engines thus provide point indices, edges, triangles, tetrahedra and/or hexahedra as output:
+An [Engine](../../../../simulation-principles/engine/) is a component that computes a set of output Data's from a set of input Data's. Several ROI engines (standing for "Region Of Interest") allow for selecting topological elements of an object. Three engines thus provide point indices, edges, triangles, tetrahedra and/or hexahedra as output:
- BoxROI
- PlaneROI
diff --git a/30_Components/25_Engine/20_Select/34_SubsetTopology.md b/30_Components/25_Engine/20_Select/34_SubsetTopology.md
index 6bddefbf8..5202cd48a 100644
--- a/30_Components/25_Engine/20_Select/34_SubsetTopology.md
+++ b/30_Components/25_Engine/20_Select/34_SubsetTopology.md
@@ -1,6 +1,6 @@
SubsetTopology
==============
-This component belongs to the category of [Engines](../../../simulation-principles/engine/). This engine separate topology in two parts, considering a ROI, a topology inside and a topology outside the ROI which can be a sphere or a box ROI used in this engine are similar to BoxROI and SphereROI.
+This component belongs to the category of [Engines](../../../../simulation-principles/engine/). This engine separate topology in two parts, considering a ROI, a topology inside and a topology outside the ROI which can be a sphere or a box ROI used in this engine are similar to BoxROI and SphereROI.
{.wp-image-1612 .alignright width="40%" height="auto"}
diff --git a/30_Components/25_Engine/26_TextureInterpolation.md b/30_Components/25_Engine/26_TextureInterpolation.md
index c2d2d1586..daee65fe9 100644
--- a/30_Components/25_Engine/26_TextureInterpolation.md
+++ b/30_Components/25_Engine/26_TextureInterpolation.md
@@ -1,4 +1,4 @@
TextureInterpolation
====================
-This component belongs to the category of [Engines](../../simulation-principles/engine/). This engine creates texture coordinate in 1D according to an input state vector. Coordinate can be interpolated either from min and max value of input states (default behavior) or on a manual define scale.
+This component belongs to the category of [Engines](../../../simulation-principles/engine/). This engine creates texture coordinate in 1D according to an input state vector. Coordinate can be interpolated either from min and max value of input states (default behavior) or on a manual define scale.
diff --git a/30_Components/25_Engine/30_Transform/27_TransformEngine.md b/30_Components/25_Engine/30_Transform/27_TransformEngine.md
index 415b42271..f5e144adb 100644
--- a/30_Components/25_Engine/30_Transform/27_TransformEngine.md
+++ b/30_Components/25_Engine/30_Transform/27_TransformEngine.md
@@ -1,4 +1,4 @@
`TransformEngine
===============
-This component belongs to the category of [Engines](../../../simulation-principles/engine/). The TransformEngine transforms the positions of one DataFields into new positions after applying a transformation. This transformation can be either: translation, rotation or scale.
+This component belongs to the category of [Engines](../../../../simulation-principles/engine/). The TransformEngine transforms the positions of one DataFields into new positions after applying a transformation. This transformation can be either: translation, rotation or scale.
diff --git a/30_Components/25_Engine/30_Transform/28_TransformPosition.md b/30_Components/25_Engine/30_Transform/28_TransformPosition.md
index 3859e9811..2de1d2ace 100644
--- a/30_Components/25_Engine/30_Transform/28_TransformPosition.md
+++ b/30_Components/25_Engine/30_Transform/28_TransformPosition.md
@@ -1,7 +1,7 @@
TransformPosition
===============
-This component belongs to the category of [Engines](../../../simulation-principles/engine/). The TransformPosition engine transforms the positions of one DataFields into new positions after applying a transformation. This transformation can be either:
+This component belongs to the category of [Engines](../../../../simulation-principles/engine/). The TransformPosition engine transforms the positions of one DataFields into new positions after applying a transformation. This transformation can be either:
- Projection on a plane (plane defined by an origin and a normal vector)
- Translation, rotation, scale and some combinations of translation rotation and scale
diff --git a/30_Components/30_SolidMechanics/10_FEM/Elastic/85_TetrahedronFEMForceField.md b/30_Components/30_SolidMechanics/10_FEM/Elastic/85_TetrahedronFEMForceField.md
index a4ce78c1d..2bc3caafd 100644
--- a/30_Components/30_SolidMechanics/10_FEM/Elastic/85_TetrahedronFEMForceField.md
+++ b/30_Components/30_SolidMechanics/10_FEM/Elastic/85_TetrahedronFEMForceField.md
@@ -1,7 +1,7 @@
TetrahedronFEMForceField
========================
-This component belongs to the category of [ForceField](../../../simulation-principles/multi-model-representation/forcefield/). The page is still incomplete, but give us a bit of time to work on it!
+This component belongs to the category of [ForceField](../../../../simulation-principles/multi-model-representation/forcefield/). The page is still incomplete, but give us a bit of time to work on it!
Description of the component ...
diff --git a/30_Components/30_SolidMechanics/10_FEM/HyperElastic/30_TetrahedronHyperelasticityFEMForceField.md b/30_Components/30_SolidMechanics/10_FEM/HyperElastic/30_TetrahedronHyperelasticityFEMForceField.md
index cee0be908..66831349f 100644
--- a/30_Components/30_SolidMechanics/10_FEM/HyperElastic/30_TetrahedronHyperelasticityFEMForceField.md
+++ b/30_Components/30_SolidMechanics/10_FEM/HyperElastic/30_TetrahedronHyperelasticityFEMForceField.md
@@ -1,7 +1,7 @@
TetrahedronHyperelasticityFEMForceField
=======================================
-This component belongs to the category of [ForceField](../../../../simulation-principles/multi-model-representation/forcefield/). The TetrahedronHyperelasticityFEMForceField implements - for tetrahedral topology only - several non-linear mechanical constitutive laws, also named as hyperelastic constitutive laws. The available models are:
+This component belongs to the category of [ForceField](../../../../../simulation-principles/multi-model-representation/forcefield/). The TetrahedronHyperelasticityFEMForceField implements - for tetrahedral topology only - several non-linear mechanical constitutive laws, also named as hyperelastic constitutive laws. The available models are:
- [Arruda-Boyce model](https://en.wikipedia.org/wiki/Arruda%E2%80%93Boyce_model)
- [Costa model](https://www.jstor.org/stable/pdf/3066567.pdf)
diff --git a/30_Components/30_SolidMechanics/20_Spring/80_PolynomialSpringsForceField.md b/30_Components/30_SolidMechanics/20_Spring/80_PolynomialSpringsForceField.md
index 8c438c125..edffacc5c 100644
--- a/30_Components/30_SolidMechanics/20_Spring/80_PolynomialSpringsForceField.md
+++ b/30_Components/30_SolidMechanics/20_Spring/80_PolynomialSpringsForceField.md
@@ -1,7 +1,7 @@
PolynomialSpringsForceField
===========================
-This component belongs to the category of [ForceField](../../../simulation-principles/multi-model-representation/forcefield/). This component allows to simulate springs with Polynomial stress strain behavior. If we note:
+This component belongs to the category of [ForceField](../../../../simulation-principles/multi-model-representation/forcefield/). This component allows to simulate springs with Polynomial stress strain behavior. If we note:
- $$F$$ the spring force
- $$S$$ the cross section (always 1.0)
diff --git a/30_Components/35_MechanicalLoad/20_ConstantForceField.md b/30_Components/35_MechanicalLoad/20_ConstantForceField.md
index c8eda1998..266cbfbc4 100644
--- a/30_Components/35_MechanicalLoad/20_ConstantForceField.md
+++ b/30_Components/35_MechanicalLoad/20_ConstantForceField.md
@@ -1,7 +1,7 @@
ConstantForceField
==================
-This component belongs to the category of [ForceField](../../simulation-principles/multi-model-representation/forcefield/). The ConstantForceField is a simple force field applying the same constant force on each node. This force field is not integrated over the domain of our object, but simply distributed over the number of nodes.
+This component belongs to the category of [ForceField](../../../simulation-principles/multi-model-representation/forcefield/). The ConstantForceField is a simple force field applying the same constant force on each node. This force field is not integrated over the domain of our object, but simply distributed over the number of nodes.
diff --git a/30_Components/40_ODESolver/10_Forward/10_EulerExplicitSolver.md b/30_Components/40_ODESolver/10_Forward/10_EulerExplicitSolver.md
index db29c4382..727ececa3 100644
--- a/30_Components/40_ODESolver/10_Forward/10_EulerExplicitSolver.md
+++ b/30_Components/40_ODESolver/10_Forward/10_EulerExplicitSolver.md
@@ -1,7 +1,7 @@
EulerExplicitSolver
===================
-The EulerExplicitSolver component belongs to the category of [integration schemes or ODE Solver](../../../simulation-principles/system-resolution/integration-scheme/). This scheme allows to solve dynamic systems explicitly: all forces will be computed based on the state information at the current time step $$x(t)$$.
+The EulerExplicitSolver component belongs to the category of [integration schemes or ODE Solver](../../../../simulation-principles/system-resolution/integration-scheme/). This scheme allows to solve dynamic systems explicitly: all forces will be computed based on the state information at the current time step $$x(t)$$.
Looking at continuum mechanics, the linear system $$\mathbf{A}x=b$$ arises from the dynamic equation. This dynamic is written as follows but other physics (like heat transfer) result in a similar equation:
@@ -34,4 +34,4 @@ Sequence diagram
Usage
-----
-The EulerExplicitSolver **requires** a MechanicalObject to store the state vectors. However, as explained above, no LinearSolver is needed and the EulerExplicitSolver is **only working using a [UniformMass](../../mass/uniformmass/) or [DiagonalMass](../../mass/diagonalmass/)**, which ensures to have a diagonal system matrix.
+The EulerExplicitSolver **requires** a MechanicalObject to store the state vectors. However, as explained above, no LinearSolver is needed and the EulerExplicitSolver is **only working using a [UniformMass](../../../mass/uniformmass/) or [DiagonalMass](../../../mass/diagonalmass/)**, which ensures to have a diagonal system matrix.
diff --git a/30_Components/40_ODESolver/10_Forward/50_StaticSolver.md b/30_Components/40_ODESolver/10_Forward/50_StaticSolver.md
index 2554fa26c..f6273fe3c 100644
--- a/30_Components/40_ODESolver/10_Forward/50_StaticSolver.md
+++ b/30_Components/40_ODESolver/10_Forward/50_StaticSolver.md
@@ -1,7 +1,7 @@
StaticSolver
============
-This component belongs to the category of [integration schemes or ODE Solver](../../../simulation-principles/system-resolution/integration-scheme/).
+This component belongs to the category of [integration schemes or ODE Solver](../../../../simulation-principles/system-resolution/integration-scheme/).
In the field of mechanics, statics consists in finding the equilibrium taking into account the loads (internal forces, external forces and torques) acting on the physical system, that do not experience an acceleration ( $$a=0$$ ). Finding a static equilibrium means finding a solution to: $$\textstyle \sum F=0$$ where $$F$$ is the sum of all loads, one of which might be unknown.
@@ -31,7 +31,7 @@ Usage
At each simulation step and each Newton Raphson iteration, the StaticSolver **requires**:
-- a [LinearSolver](../../../simulation-principles/system-resolution/linear-solver/) to solve the linear system
+- a [LinearSolver](../../../../simulation-principles/system-resolution/linear-solver/) to solve the linear system
- and a MechanicalObject to store the state vectors.
A StaticSolver must be used in simulations where the dynamics has no or a negligible effect on the system. A StaticSolver would also be relevant for systems with low mass. In such case, we fall into the quasi-static analysis.
diff --git a/30_Components/40_ODESolver/20_Backward/20_EulerImplicitSolver.md b/30_Components/40_ODESolver/20_Backward/20_EulerImplicitSolver.md
index c3240df29..cbf3eea23 100644
--- a/30_Components/40_ODESolver/20_Backward/20_EulerImplicitSolver.md
+++ b/30_Components/40_ODESolver/20_Backward/20_EulerImplicitSolver.md
@@ -1,7 +1,7 @@
EulerImplicitSolver
===================
-This component belongs to the category of [integration schemes or ODE Solver](../../../simulation-principles/system-resolution/integration-scheme/). This scheme builds the system following an implicit scheme: forces are considered based on the state information at the next time step $$x(t+dt)$$, unknown at the current time step.
+This component belongs to the category of [integration schemes or ODE Solver](../../../../simulation-principles/system-resolution/integration-scheme/). This scheme builds the system following an implicit scheme: forces are considered based on the state information at the next time step $$x(t+dt)$$, unknown at the current time step.
Looking at continuum mechanics, the linear system $$\mathbf{A}x=b$$ arises from the dynamic equation. This dynamic is written as follows but other physics (like heat transfer) result in a similar equation:
@@ -27,7 +27,7 @@ We can notice the appearance of the stiffness matrix : $$\mathbf{K}_{ij}=\textst
$$\left( \mathbf{M}-dt^2 \cdot \mathbf{K} \right) \Delta v=dt\cdot f(x(t))+dt^2\cdot \mathbf{K}v(t)$$
-The computation of the **right hand side** is done by the ForceFields. Just like in the explicit case (see [EulerExplicitSolver](../forward/eulerexplicitsolver/)), the explicit contribution $$dt\left(f(x(t))\right)$$ is implemented in the same function `addForce()`. The second part $$dt^2\cdot \frac{\partial f}{\partial x}v(t)$$ is computed by the function `addDForce()`.
+The computation of the **right hand side** is done by the ForceFields. Just like in the explicit case (see [EulerExplicitSolver](../../forward/eulerexplicitsolver/)), the explicit contribution $$dt\left(f(x(t))\right)$$ is implemented in the same function `addForce()`. The second part $$dt^2\cdot \frac{\partial f}{\partial x}v(t)$$ is computed by the function `addDForce()`.
It is important to note that, depending on the **choice of LinearSolver** (direct or iterative), the API functions called to build the **left hand side** system matrix $$\mathbf{A}=\left( M-dt^2 \cdot \frac{\partial f}{\partial x} \right)$$ will not be the same:
@@ -70,7 +70,7 @@ This results in the following linear system:
$$\left( \mathbf{M}-\frac{dt^2}{2} \frac{\partial f}{\partial x}\right) \Delta v=dt\cdot f(x(t))+\frac{dt^2}{2}\cdot \frac{\partial f}{\partial x}v(t)$$
-Finally, with Rayleigh damping, the option is given to the user to add numerical damping. The description of the meaning and effect of these Rayleigh damping coefficients is given in [ODESolver](../../../simulation-principles/system-resolution/integration-scheme/#rayleigh-damping).
+Finally, with Rayleigh damping, the option is given to the user to add numerical damping. The description of the meaning and effect of these Rayleigh damping coefficients is given in [ODESolver](../../../../simulation-principles/system-resolution/integration-scheme/#rayleigh-damping).
Sequence diagram
@@ -86,6 +86,6 @@ Usage
The EulerImplicitSolver **requires**:
-- a [LinearSolver](../../../simulation-principles/system-resolution/linear-solver/) to solve the linear system
+- a [LinearSolver](../../../../simulation-principles/system-resolution/linear-solver/) to solve the linear system
- and a MechanicalObject to store the state vectors.
diff --git a/30_Components/40_ODESolver/20_Backward/60_NewmarkImplicitSolver.md b/30_Components/40_ODESolver/20_Backward/60_NewmarkImplicitSolver.md
index 1651589de..0021e5306 100644
--- a/30_Components/40_ODESolver/20_Backward/60_NewmarkImplicitSolver.md
+++ b/30_Components/40_ODESolver/20_Backward/60_NewmarkImplicitSolver.md
@@ -1,7 +1,7 @@
NewmarkImplicitSolver
=====================
-This component belongs to the category of [integration schemes or ODE Solver](../../../simulation-principles/system-resolution/integration-scheme/).
+This component belongs to the category of [integration schemes or ODE Solver](../../../../simulation-principles/system-resolution/integration-scheme/).
This scheme is an implicit time integrator for dynamic system using the Newmark scheme. To compute the new position or new velocity, the NewmarkImplicitSolver is based on the following equations:
@@ -36,5 +36,5 @@ Usage
At each simulation step and each Newton Raphson iteration, the NewmarkImplicitSolver **requires**:
-- a [LinearSolver](../../../simulation-principles/system-resolution/linear-solver/) to solve the linear system
+- a [LinearSolver](../../../../simulation-principles/system-resolution/linear-solver/) to solve the linear system
- and a MechanicalObject to store the state vectors.
diff --git a/30_Components/45_LinearSolver/10_Iterative/10_CGLinearSolver.md b/30_Components/45_LinearSolver/10_Iterative/10_CGLinearSolver.md
index 237c1e940..3fc2251d8 100644
--- a/30_Components/45_LinearSolver/10_Iterative/10_CGLinearSolver.md
+++ b/30_Components/45_LinearSolver/10_Iterative/10_CGLinearSolver.md
@@ -1,11 +1,11 @@
CGLinearSolver
==============
-This component belongs to the category of [LinearSolver](../../../simulation-principles/system-resolution/linear-solver/). The role of the CGLinearSolver is to solve the linear system $$\mathbf{A}x=b$$ without any _a priori_ on this system.
+This component belongs to the category of [LinearSolver](../../../../simulation-principles/system-resolution/linear-solver/). The role of the CGLinearSolver is to solve the linear system $$\mathbf{A}x=b$$ without any _a priori_ on this system.
In SOFA, the CGLinearSolver follows the well-known [conjugate gradient method](https://en.wikipedia.org/wiki/Conjugate_gradient_method), which consists in iteratively solving $$r=b-\mathbf{A}x^k$$ where *r* is known as the residual. This residual will be used to compute mutually conjugate vectors *p* (see the sequence diagram below) which will be used as a basis to find a new approximated solution $$x^{k+1}$$.
-**Note**: the CGLinearSolver in SOFA assumes that the right hand side (RHS) vector *b* is already computed. The computation of *b* is usually called in the [integration scheme](../../../simulation-principles/system-resolution/integration-scheme/) through the function `computeForce()`.
+**Note**: the CGLinearSolver in SOFA assumes that the right hand side (RHS) vector *b* is already computed. The computation of *b* is usually called in the [integration scheme](../../../../simulation-principles/system-resolution/integration-scheme/) through the function `computeForce()`.
diff --git a/30_Components/45_LinearSolver/10_Iterative/80_Preconditioned_CG.md b/30_Components/45_LinearSolver/10_Iterative/80_Preconditioned_CG.md
index 10ec32ef5..22ab702f9 100644
--- a/30_Components/45_LinearSolver/10_Iterative/80_Preconditioned_CG.md
+++ b/30_Components/45_LinearSolver/10_Iterative/80_Preconditioned_CG.md
@@ -1,12 +1,12 @@
ShewchukPCGLinearSolver
=======================
-This component belongs to the category of [LinearSolver](../../../simulation-principles/system-resolution/linear-solver/), it therefore aims at solving the linear system $$\mathbf{A}x=b$$. The ShewchukPCGLinearSolver is an iterative solver using the [conjugate gradient method](https://en.wikipedia.org/wiki/Conjugate_gradient_method) as implemented in the [CGLinearSolver](./cglinearsolver/) in SOFA but it adds the possibility to define a [preconditioner](https://en.wikipedia.org/wiki/Preconditioner). It must be reminded that the ShewchukPCGLinearSolver relies on the conjugate gradient method, meaning that as all iterative approaches, no exact solution can be found. The accuracy of your solution will always depend on the conditioning of your system and your input data (iterations, tolerance and threshold).
+This component belongs to the category of [LinearSolver](../../../../simulation-principles/system-resolution/linear-solver/), it therefore aims at solving the linear system $$\mathbf{A}x=b$$. The ShewchukPCGLinearSolver is an iterative solver using the [conjugate gradient method](https://en.wikipedia.org/wiki/Conjugate_gradient_method) as implemented in the [CGLinearSolver](./../cglinearsolver/) in SOFA but it adds the possibility to define a [preconditioner](https://en.wikipedia.org/wiki/Preconditioner). It must be reminded that the ShewchukPCGLinearSolver relies on the conjugate gradient method, meaning that as all iterative approaches, no exact solution can be found. The accuracy of your solution will always depend on the conditioning of your system and your input data (iterations, tolerance and threshold).
Preconditioners are used in cases where the convergence of the system is slow, which is usually due to a ill-conditioned system (high [condition number](https://en.wikipedia.org/wiki/Condition_number)). In order to preserve accuracy, while improving performance, preconditioning methods aims at projecting a matrix $$\mathbf{P}$$ (preconditioner) on the linear system $$\mathbf{A}x=b$$, in order to get closer to the solution. The efficiency of the preconditioner will depend on the choice of the preconditioner $$\mathbf{P}$$.
-The ShewchukPCGLinearSolver allows to choose the preconditioner of our choice based on an external direct linear solver: LULinearSolver, [SparseLDLSolver](../direct/sparseldlsolver/), etc. These solvers will allow to compute $$\mathbf{P} \approx \mathbf{A}$$ and use it to compute at each iteration _k_ of the conjugate gradient:
+The ShewchukPCGLinearSolver allows to choose the preconditioner of our choice based on an external direct linear solver: LULinearSolver, [SparseLDLSolver](../../direct/sparseldlsolver/), etc. These solvers will allow to compute $$\mathbf{P} \approx \mathbf{A}$$ and use it to compute at each iteration _k_ of the conjugate gradient:
$$\mathbf{P}^{-1}(\mathbf{A}x_k-b)=0$$
diff --git a/30_Components/45_LinearSolver/20_Direct/40_SparseCholeskySolver.md b/30_Components/45_LinearSolver/20_Direct/40_SparseCholeskySolver.md
index c8f2eeeb2..dd2b51611 100644
--- a/30_Components/45_LinearSolver/20_Direct/40_SparseCholeskySolver.md
+++ b/30_Components/45_LinearSolver/20_Direct/40_SparseCholeskySolver.md
@@ -1,7 +1,7 @@
SparseCholeskySolver
====================
-This component belongs to the category of [LinearSolver](../../../simulation-principles/system-resolution/linear-solver/). The role of the SparseLUSolver is to solve the linear system $$\mathbf{A}x=b$$ assuming that the matrix $$\mathbf{A}$$ is symmetric and sparse.
+This component belongs to the category of [LinearSolver](../../../../simulation-principles/system-resolution/linear-solver/). The role of the SparseLUSolver is to solve the linear system $$\mathbf{A}x=b$$ assuming that the matrix $$\mathbf{A}$$ is symmetric and sparse.
The Cholesky decomposition (https://en.wikipedia.org/wiki/Cholesky_decomposition) is a numerical method that solves a linear system $$mathbf{A}x=b$$ by factorizing the matrix of the system as $$\mathbf{LL^T}$$. By doing so, we only need to solve two triangular systems to compute the solution. It is only applyable on **symetric** matrices but is roughtly twice as efficient as the LU solver. The $$\mathbf{LDL^T}$$ decomposition is heavily related to the Cholesky decomposition.
diff --git a/30_Components/45_LinearSolver/20_Direct/50_SparseLDLSolver.md b/30_Components/45_LinearSolver/20_Direct/50_SparseLDLSolver.md
index 234a006c9..1df3a7f7d 100644
--- a/30_Components/45_LinearSolver/20_Direct/50_SparseLDLSolver.md
+++ b/30_Components/45_LinearSolver/20_Direct/50_SparseLDLSolver.md
@@ -1,7 +1,7 @@
SparseLDLSolver
===============
-This component belongs to the category of [LinearSolver](../../../simulation-principles/system-resolution/linear-solver/). The role of the SparseLDLSolver is to solve the linear system $$\mathbf{A}x=b$$ assuming that the matrix $$\mathbf{A}$$ is symmetric and sparse.
+This component belongs to the category of [LinearSolver](../../../../simulation-principles/system-resolution/linear-solver/). The role of the SparseLDLSolver is to solve the linear system $$\mathbf{A}x=b$$ assuming that the matrix $$\mathbf{A}$$ is symmetric and sparse.
To do so, the SparseLDLSolver relies on the method of [LDL decomposition](https://en.wikipedia.org/wiki/Cholesky_decomposition#LDL_decomposition_2). The system matrix will be decomposed $$\mathbf{A}=\mathbf{L}\mathbf{D}\mathbf{L}^T$$, where $$\mathbf{L}$$ is a lower triangular matrix $$\mathbf{A}$$ and $$\mathbf{D}$$ is a diagonal matrix. This decomposition is an extension of the Cholesky decomposition which reduces its numerical inaccuracy.
diff --git a/30_Components/45_LinearSolver/20_Direct/55_AsyncSparseLDLSolver.md b/30_Components/45_LinearSolver/20_Direct/55_AsyncSparseLDLSolver.md
index 66255a054..9fbb2c5cf 100644
--- a/30_Components/45_LinearSolver/20_Direct/55_AsyncSparseLDLSolver.md
+++ b/30_Components/45_LinearSolver/20_Direct/55_AsyncSparseLDLSolver.md
@@ -1,7 +1,7 @@
AsyncSparseLDLSolver
====================
-AsyncSparseLDLSolver is based on [SparseLDLSolver](./sparseldlsolver/).
+AsyncSparseLDLSolver is based on [SparseLDLSolver](./../sparseldlsolver/).
It follows some ideas presented in:
> Courtecuisse, Hadrien, et al. "Asynchronous preconditioners for efficient solving of non-linear deformations." VRIPHYS-Virtual Reality Interaction and Physical Simulation. Eurographics Association, 2010.
@@ -25,7 +25,7 @@ It may also introduce instabilities.
## A Preconditioner
-AsyncSparseLDLSolver can be used as a preconditioner of [ShewchukPCGLinearSolver](../iterative/preconditioned-cg/).
+AsyncSparseLDLSolver can be used as a preconditioner of [ShewchukPCGLinearSolver](../../iterative/preconditioned-cg/).
## Performances
diff --git a/30_Components/45_LinearSolver/20_Direct/60_SparseLUSolver.md b/30_Components/45_LinearSolver/20_Direct/60_SparseLUSolver.md
index 0e2d9f710..dc90d7008 100644
--- a/30_Components/45_LinearSolver/20_Direct/60_SparseLUSolver.md
+++ b/30_Components/45_LinearSolver/20_Direct/60_SparseLUSolver.md
@@ -1,7 +1,7 @@
SparseLUSolver
==============
-This component belongs to the category of [LinearSolver](../../../simulation-principles/system-resolution/linear-solver/). The role of the SparseLUSolver is to solve the linear system $$\mathbf{A}x=b$$ assuming that the matrix $$\mathbf{A}$$ is invertible and sparse.
+This component belongs to the category of [LinearSolver](../../../../simulation-principles/system-resolution/linear-solver/). The role of the SparseLUSolver is to solve the linear system $$\mathbf{A}x=b$$ assuming that the matrix $$\mathbf{A}$$ is invertible and sparse.
In order to solve this system, this solver will factorize the matrix $$\mathbf{A}$$ into the product $$\mathbf{A=LU}$$ where $$\mathbf{L}$$ is a lower triangular matrix with ones on its diagonal and $$\mathbf{U}$$ is an upper triangular matrix (for more, see [LU decomposition article](https://en.wikipedia.org/wiki/LU_decomposition)).
diff --git a/30_Components/48_IO/10_Mesh/10_MeshGmshLoader.md b/30_Components/48_IO/10_Mesh/10_MeshGmshLoader.md
index d86af37aa..12e34d199 100644
--- a/30_Components/48_IO/10_Mesh/10_MeshGmshLoader.md
+++ b/30_Components/48_IO/10_Mesh/10_MeshGmshLoader.md
@@ -1,7 +1,7 @@
MeshGmshLoader
==============
-This component belongs to the category of the [MeshLoaders](../../../simulation-principles/topology/#meshloaders).
+This component belongs to the category of the [MeshLoaders](../../../../simulation-principles/topology/#meshloaders).
The MeshGmshLoader loads a mesh from a file under the format \*.msh. Such a mesh file can be either surface or volumetric meshes. The \*.msh meshes can be generated using software like [Gmsh](https://gmsh.info/).
To be noted, an interesting [project couples SOFA and Gmsh in python](https://github.com/sescaida/gmsh-sofa_tutorial) for applications such as parametric design or design optimization.
diff --git a/30_Components/48_IO/10_Mesh/20_MeshOBJLoader.md b/30_Components/48_IO/10_Mesh/20_MeshOBJLoader.md
index 75a0dce2d..4431f161d 100644
--- a/30_Components/48_IO/10_Mesh/20_MeshOBJLoader.md
+++ b/30_Components/48_IO/10_Mesh/20_MeshOBJLoader.md
@@ -1,7 +1,7 @@
MeshOBJLoader
=============
-This component belongs to the category of the [MeshLoaders](../../../simulation-principles/topology/#meshloaders).
+This component belongs to the category of the [MeshLoaders](../../../../simulation-principles/topology/#meshloaders).
The MeshOBJLoader loads a mesh from a file under the format \*.obj. Such a mesh file **only supports surface meshes**. The \*.obj meshes can be generated using software like [Blender](https://blender.org/).
diff --git a/30_Components/48_IO/10_Mesh/30_MeshOffLoader.md b/30_Components/48_IO/10_Mesh/30_MeshOffLoader.md
index c981b0be0..452f20290 100644
--- a/30_Components/48_IO/10_Mesh/30_MeshOffLoader.md
+++ b/30_Components/48_IO/10_Mesh/30_MeshOffLoader.md
@@ -1,7 +1,7 @@
MeshOffLoader
=============
-This component belongs to the category of the [MeshLoaders](../../../simulation-principles/topology/#meshloaders).
+This component belongs to the category of the [MeshLoaders](../../../../simulation-principles/topology/#meshloaders).
The MeshOffLoader loads a mesh from a file under the format \*.off. Such a mesh file can be either surface or volumetric meshes. The \*.off meshes can be generated using software like [MeshLab](https://www.meshlab.net/).
diff --git a/30_Components/48_IO/10_Mesh/40_MeshSTLLoader.md b/30_Components/48_IO/10_Mesh/40_MeshSTLLoader.md
index bc3221e35..751c9405c 100644
--- a/30_Components/48_IO/10_Mesh/40_MeshSTLLoader.md
+++ b/30_Components/48_IO/10_Mesh/40_MeshSTLLoader.md
@@ -1,7 +1,7 @@
MeshSTLLoader
=============
-This component belongs to the category of the [MeshLoaders](../../../simulation-principles/topology/#meshloaders).
+This component belongs to the category of the [MeshLoaders](../../../../simulation-principles/topology/#meshloaders).
The MeshSTLLoader loads a mesh from a file under the [format \*.stl](https://en.wikipedia.org/wiki/STL_(file_format)). Such a mesh file **only supports surface meshes**. The \*.stl format is widely spread and such meshes can be generated using software like [MeshLab](https://www.meshlab.net/) or [Paraview](https://www.paraview.org) among many other solutions.
diff --git a/30_Components/48_IO/10_Mesh/50_MeshVTKLoader.md b/30_Components/48_IO/10_Mesh/50_MeshVTKLoader.md
index bc139bd45..cd05a55e9 100644
--- a/30_Components/48_IO/10_Mesh/50_MeshVTKLoader.md
+++ b/30_Components/48_IO/10_Mesh/50_MeshVTKLoader.md
@@ -1,7 +1,7 @@
MeshVTKLoader
=============
-This component belongs to the category of the [MeshLoaders](../../../simulation-principles/topology/#meshloaders).
+This component belongs to the category of the [MeshLoaders](../../../../simulation-principles/topology/#meshloaders).
The MeshVTKLoader loads a mesh from a file under the format \*.vtk. Such a mesh file can be either surface or volumetric meshes. The \*.vtk meshes can be generated using the [Paraview](https://www.paraview.org) software.
diff --git a/30_Components/50_Mapping/NonLinear/SquareMapping.md b/30_Components/50_Mapping/NonLinear/SquareMapping.md
index 90f02a980..f6ea8bc0c 100644
--- a/30_Components/50_Mapping/NonLinear/SquareMapping.md
+++ b/30_Components/50_Mapping/NonLinear/SquareMapping.md
@@ -1,6 +1,6 @@
# SquareMapping
-This component is classified under the category of [Mappings](../../../simulation-principles/multi-model-representation/mapping/).
+This component is classified under the category of [Mappings](../../../../simulation-principles/multi-model-representation/mapping/).
In this particular mapping, we designate the input as the parent state and the output as the child state.
diff --git a/30_Components/55_Mass/10_UniformMass.md b/30_Components/55_Mass/10_UniformMass.md
index 6bb39385b..d817f5355 100644
--- a/30_Components/55_Mass/10_UniformMass.md
+++ b/30_Components/55_Mass/10_UniformMass.md
@@ -2,14 +2,14 @@ UniformMass
===========
-This component belongs to the category of [Masses](../../simulation-principles/multi-model-representation/mass/). The UniformMass is a very **simplistic mass** component since it does not compute the volume integration of a density term. The mass is equally spread over the number of points, thus resulting in the following diagonal mass matrix:
+This component belongs to the category of [Masses](../../../simulation-principles/multi-model-representation/mass/). The UniformMass is a very **simplistic mass** component since it does not compute the volume integration of a density term. The mass is equally spread over the number of points, thus resulting in the following diagonal mass matrix:
$$\mathbf{M}=\begin{bmatrix}m&0&\cdots&0\\&m&\cdots&0\\ \vdots&\vdots&\ddots&\vdots\\&0&\cdots&m\end{bmatrix}$$
Each diagonal term equals the nodal mass $$m=\frac{m_{\textnormal{total}}}{N}$$ where $$m_{\textnormal{total}}$$ is the total mass of the objet and $$N$$ is the number of nodes of the object. Spreading the mass over the nodes without considering their connectivity results in this diagonal mass matrix $$\mathbf{M}$$.
-As all mass components, the UniformMass $$\mathbf{M}$$ will contribute to the main matrix $$\mathbf{A}$$ in the system $$\mathbf{A}x=b$$. Depending on the type of [LinearSolver](../../simulation-principles/system-resolution/linear-solver/) used:
+As all mass components, the UniformMass $$\mathbf{M}$$ will contribute to the main matrix $$\mathbf{A}$$ in the system $$\mathbf{A}x=b$$. Depending on the type of [LinearSolver](../../../simulation-principles/system-resolution/linear-solver/) used:
- for iterative solvers, the result of the multiplication between the mass matrix $$\mathbf{M}$$ and an approximated solution is computed by the function:
diff --git a/30_Components/55_Mass/20_MeshMatrixMass.md b/30_Components/55_Mass/20_MeshMatrixMass.md
index 1545d8f77..ce10e814c 100644
--- a/30_Components/55_Mass/20_MeshMatrixMass.md
+++ b/30_Components/55_Mass/20_MeshMatrixMass.md
@@ -1,12 +1,12 @@
MeshMatrixMass
==============
-This component belongs to the category of [Masses](../../simulation-principles/multi-model-representation/mass/). In the dynamic equation (see [Physics integration](../../simulation-principles/multi-model-representation/physics-integration/) page), the mass density results from the first derivative in time of the momentum term. The MeshMatrixMass computes the integral of this mass density over the volume of the object geometry. To do so and for any given topology (triangles, quads, tetrahedra or hexahedra), the MeshMatrixMass integrates the mass density inside each elements and sums the mass matrix $$\mathbf{M}$$ in the system matrix $$\mathbf{A}$$.
+This component belongs to the category of [Masses](../../../simulation-principles/multi-model-representation/mass/). In the dynamic equation (see [Physics integration](../../../simulation-principles/multi-model-representation/physics-integration/) page), the mass density results from the first derivative in time of the momentum term. The MeshMatrixMass computes the integral of this mass density over the volume of the object geometry. To do so and for any given topology (triangles, quads, tetrahedra or hexahedra), the MeshMatrixMass integrates the mass density inside each elements and sums the mass matrix $$\mathbf{M}$$ in the system matrix $$\mathbf{A}$$.
### Volume integration
-As detailed in the [Physics integration](../../simulation-principles/multi-model-representation/physics-integration/) page, the left hand side part of the linear momentum conservation equals $$\rho\dot{v}$$. To integrate over the domain, its weak form will result in the mass matrix:
+As detailed in the [Physics integration](../../../simulation-principles/multi-model-representation/physics-integration/) page, the left hand side part of the linear momentum conservation equals $$\rho\dot{v}$$. To integrate over the domain, its weak form will result in the mass matrix:
$$\mathbf{M}\dot{v}=\int_{\Omega} \phi_j \rho \dot{v}d\Omega$$
@@ -14,7 +14,7 @@ where $$\phi_j$$ are the test functions, which are basis functions ensuring the
$$\mathbf{M}\dot{v}=\sum_{e=0}^E \int_{V_e} \phi_j \rho \dot{v}dV_e$$
-The FEM relies on simple geometries in which any field can be interpolated using shape functions $$\phi_i$$ (see [FEM at a glance](../../simulation-principles/multi-model-representation/physics-integration/#fem-at-a-glance)). Note that the same basis functions are chosen for both the test and the shape functions. The interpolation of the acceleration term $$\dot{v}$$ thus gives:
+The FEM relies on simple geometries in which any field can be interpolated using shape functions $$\phi_i$$ (see [FEM at a glance](../../../simulation-principles/multi-model-representation/physics-integration/#fem-at-a-glance)). Note that the same basis functions are chosen for both the test and the shape functions. The interpolation of the acceleration term $$\dot{v}$$ thus gives:
$$\mathbf{M}\dot{v}=\sum_{e=0}^E \rho \int_{V_e} \phi_j \sum_{i=0}^{N} \phi_i \dot{v}_i dV_e$$
@@ -43,7 +43,7 @@ $$\mathbf{M}\dot{v}=\sum_{e=0}^E \frac{\rho V_e}{20}\begin{bmatrix}2&1&1&1\\1&2&
### API
-Depending on the type of [LinearSolver](../../simulation-principles/system-resolution/linear-solver/) used:
+Depending on the type of [LinearSolver](../../../simulation-principles/system-resolution/linear-solver/) used:
- for iterative solvers, the result of the multiplication between the mass matrix $$\mathbf{M}$$ and an approximated solution is computed by the function:
diff --git a/30_Components/55_Mass/30_DiagonalMass.md b/30_Components/55_Mass/30_DiagonalMass.md
index b09f55a96..e9cd83828 100644
--- a/30_Components/55_Mass/30_DiagonalMass.md
+++ b/30_Components/55_Mass/30_DiagonalMass.md
@@ -1,11 +1,11 @@
DiagonalMass
============
-This component belongs to the category of [Masses](../../simulation-principles/multi-model-representation/mass/). In the dynamic equation (see [Physics integration](../../simulation-principles/multi-model-representation/physics-integration/) page), the mass density results from the first derivative in time of the momentum term. Like the MeshMatrixMass, the DiagonalMass computes the integral of this mass density over the volume of the object geometry. To do so and for any given topology (edges, triangles, quads, tetrahedra or hexahedra), the DiagonalMass integrates the mass density inside each elements and sums the mass matrix $$\mathbf{M}$$ in the system matrix $$\mathbf{A}$$.
+This component belongs to the category of [Masses](../../../simulation-principles/multi-model-representation/mass/). In the dynamic equation (see [Physics integration](../../../simulation-principles/multi-model-representation/physics-integration/) page), the mass density results from the first derivative in time of the momentum term. Like the MeshMatrixMass, the DiagonalMass computes the integral of this mass density over the volume of the object geometry. To do so and for any given topology (edges, triangles, quads, tetrahedra or hexahedra), the DiagonalMass integrates the mass density inside each elements and sums the mass matrix $$\mathbf{M}$$ in the system matrix $$\mathbf{A}$$.
However, the DiagonalMass makes a strong simplification: it considers the mass matrix $$\mathbf{M}$$ as being diagonal. To build this diagonal mass matrix, the DiagonalMass relies on a numerical method called the mass lumping. It consists in summing all mass values of a line on the diagonal. This approach is already implemented in the MeshMatrixMass but the DiagonalMass proposes an optimized version of the mass lumping and extend it to edge topology.
-For details on the volume integration, please report to the [MeshMatrixMass](./meshmatrixmass/) page. As demonstrated in the [MeshMatrixMass](./meshmatrixmass/#case-of-a-linear-tetrahedron) page, in case of a topology using linear tetrahedra, the diagonal mass matrix corresponds to:
+For details on the volume integration, please report to the [MeshMatrixMass](./../meshmatrixmass/) page. As demonstrated in the [MeshMatrixMass](./../meshmatrixmass/#case-of-a-linear-tetrahedron) page, in case of a topology using linear tetrahedra, the diagonal mass matrix corresponds to:
$$\mathbf{M}\dot{v}=\sum_{e=0}^E \frac{\rho V_e}{4}\begin{bmatrix}1&0&0&0\\&1&0&0\\&0&1&0\\&0&0&1\\ \end{bmatrix}\begin{bmatrix}\dot{v}_1\\ \dot{v}_2\\ \dot{v}_3\\ \dot{v}_4\\ \end{bmatrix}$$
@@ -18,7 +18,7 @@ By making the matrix diagonal (i.e. removing extra-diagonal terms), the lumping
### API
-Depending on the type of [LinearSolver](../../simulation-principles/system-resolution/linear-solver/) used:
+Depending on the type of [LinearSolver](../../../simulation-principles/system-resolution/linear-solver/) used:
- for iterative solvers, the result of the multiplication between the mass matrix $$\mathbf{M}$$ and an approximated solution is computed by the function:
diff --git a/35_Plugins/20_Build_a_plugin_from_sources.md b/35_Plugins/20_Build_a_plugin_from_sources.md
index 4a8cbabe2..933242138 100644
--- a/35_Plugins/20_Build_a_plugin_from_sources.md
+++ b/35_Plugins/20_Build_a_plugin_from_sources.md
@@ -11,7 +11,7 @@ i.e. a plugin which is not provided in the source code of SOFA.
Two ways of building a plugin are possible:
- you are compiling SOFA and you integrate your plugin project along SOFA (aka [_in-tree build_](#in-tree-build)).
-- you have an install of SOFA (either you downloaded a [pre-built configuration](https://www.sofa-framework.org/download/), or you installed by yourself from a [SOFA build](../getting-started/build/build-options/)), and you want to use this installation to build your plugin (aka [_out-of-tree build_](#out-of-tree-build))
+- you have an install of SOFA (either you downloaded a [pre-built configuration](https://www.sofa-framework.org/download/), or you installed by yourself from a [SOFA build](../../getting-started/build/build-options/)), and you want to use this installation to build your plugin (aka [_out-of-tree build_](#out-of-tree-build))
## In-tree build
diff --git a/35_Plugins/25_Fetch_plugin_code_source.md b/35_Plugins/25_Fetch_plugin_code_source.md
index 12bede022..51ef87517 100644
--- a/35_Plugins/25_Fetch_plugin_code_source.md
+++ b/35_Plugins/25_Fetch_plugin_code_source.md
@@ -26,4 +26,4 @@ To fetch the source code of a plugin, follow these steps:
Fetching the source code of a plugin uses git to clone a repository (usually the master branch) in the SOFA build directory.
It is done one time, and it is then up to the developer to update and manage the git directory.
-For developing on a plugin repository, it is advised to follow [these steps](./build-a-plugin-from-sources/) rather than fetching the code source.
+For developing on a plugin repository, it is advised to follow [these steps](./../build-a-plugin-from-sources/) rather than fetching the code source.
diff --git a/35_Plugins/30_Use_a_plugin_binaries.md b/35_Plugins/30_Use_a_plugin_binaries.md
index 0c1784cb4..1b42cb652 100644
--- a/35_Plugins/30_Use_a_plugin_binaries.md
+++ b/35_Plugins/30_Use_a_plugin_binaries.md
@@ -12,4 +12,4 @@ In such a case, one must firstly check that the compilation environment of the p
## Load in SOFA
-See [What is a plugin > Plugin loading](./what-is-a-plugin/#plugin_loading).
+See [What is a plugin > Plugin loading](./../what-is-a-plugin/#plugin_loading).
diff --git a/35_Plugins/40_Create_your_plugin_.md b/35_Plugins/40_Create_your_plugin_.md
index 8e059e4f4..3af7ff943 100644
--- a/35_Plugins/40_Create_your_plugin_.md
+++ b/35_Plugins/40_Create_your_plugin_.md
@@ -1,2 +1,2 @@
-See [Programming with SOFA > Create your plugin](../programming-with-sofa/create-your-plugin/).
+See [Programming with SOFA > Create your plugin](../../programming-with-sofa/create-your-plugin/).
diff --git a/35_Plugins/50_Usual_plugins/80_MultiThreading.md b/35_Plugins/50_Usual_plugins/80_MultiThreading.md
index 2e2659b8d..4e7b5d79b 100644
--- a/35_Plugins/50_Usual_plugins/80_MultiThreading.md
+++ b/35_Plugins/50_Usual_plugins/80_MultiThreading.md
@@ -9,16 +9,16 @@ SOFA has some multithreading capabilities in its core, but more features are ava
## Parallel Collision Detection
-Most SOFA scenes use a component defining the [collision pipeline](../../components/collision/detection/algorithm/collisionpipeline/).
-This pipeline requires two components for the [broad phase](../../components/components/collision/detection/algorithm/broadphase/) and the [narrow phase](../../components/components/collision/detection/algorithm/narrowphase) of the collision detection.
-A usual choice is [BruteForceBroadPhase](../../components/collision/detection/algorithm/bruteforcebroadphase/) for the broad phase, and [BVHNarrowPhase](../../components/collision/detection/algorithm/bvhnarrowphase/) for the narrow phase.
+Most SOFA scenes use a component defining the [collision pipeline](../../../components/collision/detection/algorithm/collisionpipeline/).
+This pipeline requires two components for the [broad phase](../../../components/components/collision/detection/algorithm/broadphase/) and the [narrow phase](../../../components/components/collision/detection/algorithm/narrowphase) of the collision detection.
+A usual choice is [BruteForceBroadPhase](../../../components/collision/detection/algorithm/bruteforcebroadphase/) for the broad phase, and [BVHNarrowPhase](../../../components/collision/detection/algorithm/bvhnarrowphase/) for the narrow phase.
Both of these components can be replaced with a parallel version from the MultiThreading plugin.
### ParallelBruteForceBroadPhase
-This component is a parallel implementation of [BruteForceBroadPhase](../../components/collision/detection/algorithm/bruteforcebroadphase/) using a global thread pool.
-It means the result of a simulation with [BruteForceBroadPhase](../../components/collision/detection/algorithm/bruteforcebroadphase/) or with ParallelBruteForceBroadPhase is expected to be equal.
-ParallelBruteForceBroadPhase is the most efficient compared to [BruteForceBroadPhase](../../components/collision/detection/algorithm/bruteforcebroadphase/) when there is a lot of objects in the scene.
+This component is a parallel implementation of [BruteForceBroadPhase](../../../components/collision/detection/algorithm/bruteforcebroadphase/) using a global thread pool.
+It means the result of a simulation with [BruteForceBroadPhase](../../../components/collision/detection/algorithm/bruteforcebroadphase/) or with ParallelBruteForceBroadPhase is expected to be equal.
+ParallelBruteForceBroadPhase is the most efficient compared to [BruteForceBroadPhase](../../../components/collision/detection/algorithm/bruteforcebroadphase/) when there is a lot of objects in the scene.
#### Examples
@@ -30,8 +30,8 @@ Examples of ParallelBruteForceBroadPhase can be found in:
### ParallelBVHNarrowPhase
-This component is a parallel implementation of [BVHNarrowPhase](../../components/collision/detection/algorithm/bvhnarrowphase/) using a global thread pool.
-It means the result of a simulation with [BVHNarrowPhase](../../components/collision/detection/algorithm/bvhnarrowphase/) or with ParallelBVHNarrowPhase is expected to be equal.
+This component is a parallel implementation of [BVHNarrowPhase](../../../components/collision/detection/algorithm/bvhnarrowphase/) using a global thread pool.
+It means the result of a simulation with [BVHNarrowPhase](../../../components/collision/detection/algorithm/bvhnarrowphase/) or with ParallelBVHNarrowPhase is expected to be equal.
#### Examples
@@ -47,7 +47,7 @@ Examples of ParallelBruteForceBroadPhase can be found in:
### ParallelTetrahedronFEMForceField
-ParallelTetrahedronFEMForceField is the multi-threaded equivalent of [TetrahedronFEMForceField](../../components/solidmechanics/fem/elastic/TetrahedronFEMForceField).
+ParallelTetrahedronFEMForceField is the multi-threaded equivalent of [TetrahedronFEMForceField](../../../components/solidmechanics/fem/elastic/TetrahedronFEMForceField).
This implementation is the most efficient when the number of tetrahedron is large (> 1000).
@@ -63,12 +63,12 @@ Examples of ParallelTetrahedronFEMForceField can be found in:
### ParallelHexahedronFEMForceField
-ParallelHexahedronFEMForceField is the multi-threaded equivalent of [HexahedronFEMForceField](../../components/solidmechanics/fem/elastic/HexahedronFEMForceField).
+ParallelHexahedronFEMForceField is the multi-threaded equivalent of [HexahedronFEMForceField](../../../components/solidmechanics/fem/elastic/HexahedronFEMForceField).
This implementation is the most efficient when:
1) the number of hexahedron is large (> 1000)
-2) the global system matrix is not assembled. It is usually the case with a [CGLinearSolver](../../components/linearsolver/iterative/cglinearsolver/) templated with GraphScattered types.
+2) the global system matrix is not assembled. It is usually the case with a [CGLinearSolver](../../../components/linearsolver/iterative/cglinearsolver/) templated with GraphScattered types.
3) the method is 'large'. If the method is 'polar' or 'small', `addForce` is executed sequentially, but `addDForce` in parallel.
The following methods are executed in parallel:
@@ -77,7 +77,7 @@ The following methods are executed in parallel:
- `addDForce`
The method `addKToMatrix` is not executed in parallel.
-This method is called with an assembled system, usually with a direct solver or a [CGLinearSolver](../../components/linearsolver/iterative/cglinearsolver/) templated with types different from GraphScattered.
+This method is called with an assembled system, usually with a direct solver or a [CGLinearSolver](../../../components/linearsolver/iterative/cglinearsolver/) templated with types different from GraphScattered.
In this case, the most time-consuming step is to invert the matrix. This is where efforts should be put to accelerate the simulation.
#### Examples
@@ -119,7 +119,7 @@ Examples of ParallelMeshSpringForceField can be found in:
## Independent SOFA Scenes
The AnimationLoopParallelScheduler component was implemented to run the physics simulation of independent scenes in parallel.
-The component looks for [BaseAnimationLoop components](../../simulation-principles/animation-loop/) in all its child nodes and executes the `step()` function of each AnimationLoop in parallel.
+The component looks for [BaseAnimationLoop components](../../../simulation-principles/animation-loop/) in all its child nodes and executes the `step()` function of each AnimationLoop in parallel.
The DataExchange component can manage the sharing of data between all the concurrent scenes without being bound by synchronization locks.
To avoid the use of synchronization locks, each component in different scenes must have its own copy of the same data to share, and the data synchronization is executed serially.
diff --git a/40_Programming_with_SOFA/40_Create_your_scene_in_Cpp.md b/40_Programming_with_SOFA/40_Create_your_scene_in_Cpp.md
index a8bf66067..0421416fc 100644
--- a/40_Programming_with_SOFA/40_Create_your_scene_in_Cpp.md
+++ b/40_Programming_with_SOFA/40_Create_your_scene_in_Cpp.md
@@ -137,4 +137,4 @@ def createScene(node):
child_dofs = child_node.addObject('MechanicalObject', template = 'Vec3', name = 'dofs')
```
-Please refer to the [documentation](../plugins/usual-plugins/python-scripting/) for further details.
+Please refer to the [documentation](../../plugins/usual-plugins/python-scripting/) for further details.
diff --git a/40_Programming_with_SOFA/50_Create_your_binaries.md b/40_Programming_with_SOFA/50_Create_your_binaries.md
index 8a9dee68b..a4dfd1608 100644
--- a/40_Programming_with_SOFA/50_Create_your_binaries.md
+++ b/40_Programming_with_SOFA/50_Create_your_binaries.md
@@ -64,8 +64,8 @@ Once the binaries are generated:
- Create a [release](https://github.com/sofa-framework/sofa/releases) on GitHub.
- Update the link on the [download](https://www.sofa-framework.org/download/) page for the binaries (add changes in dependencies).
- Update the doc for building SOFA:
- - on [Linux](../getting-started/build/linux/)
- - on [MacOS](../getting-started/build/mac-os-x/)
- - on [Windows](../getting-started/build/windows/)
+ - on [Linux](../../getting-started/build/linux/)
+ - on [MacOS](../../getting-started/build/mac-os-x/)
+ - on [Windows](../../getting-started/build/windows/)
- Update the flags on the forum.
- Create a post on the forum, on Twitter, on LinkedIn.
diff --git a/40_Programming_with_SOFA/60_API_overview/10_Components_in_SOFA.md b/40_Programming_with_SOFA/60_API_overview/10_Components_in_SOFA.md
index 64c097970..b3d267969 100644
--- a/40_Programming_with_SOFA/60_API_overview/10_Components_in_SOFA.md
+++ b/40_Programming_with_SOFA/60_API_overview/10_Components_in_SOFA.md
@@ -28,7 +28,7 @@ to store all the parameters of your component, and handle this way the
input (parametrize the component from XML/Python files for instance), and
output (save at a time T the configuration of your component).
Everything that needs to be saved in your component must be kept into
-memory inside a Data (find out more about the [Data here](./data-in-components/)).
+memory inside a Data (find out more about the [Data here](./../data-in-components/)).
Basically to initialize a data, you must do the following:
``` cpp
@@ -108,7 +108,7 @@ Every SOFA component has a context. By casting this context to a
component. A Node is a very useful component, as you can launch visitors
from them, or quickly get information about the content of the node. However,
we insist on the fact that accessing other components through the context
-is not recommended: instead create [Link](./create-links/)/DataLink.
+is not recommended: instead create [Link](./../create-links/)/DataLink.
``` cpp
sofa::core::objectmodel::BaseContext* getContext();
@@ -123,8 +123,8 @@ simulation::Node* currentNode = static_cast(myComponent->getC
#### handleEvent( Event\* )
-Every SOFA component inherits a [Data](./data-in-components/) **f\_listening** from BaseObject.
-If **f\_listening** is true, then each time an [Event](./events-in-sofa/) is sent to
+Every SOFA component inherits a [Data](./../data-in-components/) **f\_listening** from BaseObject.
+If **f\_listening** is true, then each time an [Event](./../events-in-sofa/) is sent to
the node containing your component, this method will be called. This
way, you can execute specific operations when an event is triggered.
@@ -155,14 +155,14 @@ triggered. The most common SOFA events are:
- TopologyChangeEvent
- UpdateMappingEndEvent
-Find out more about the [Events here](./events-in-sofa/).
+Find out more about the [Events here](./../events-in-sofa/).
## Member variables
#### Component state
-The [Data](./data-in-components/) attribute `d_componentState` defined in Base.h corresponds to
+The [Data](./../data-in-components/) attribute `d_componentState` defined in Base.h corresponds to
the state of every component. This enum defines the following states:
- Undefined: for a component that does not make use of this field have this one
@@ -175,7 +175,7 @@ the state of every component. This enum defines the following states:
#### Print log
-The [Data](./data-in-components/) attribute `f_printLog` defined in Base.h is a boolean triggering
+The [Data](./../data-in-components/) attribute `f_printLog` defined in Base.h is a boolean triggering
the emission of log messages at runtime. If true, all messages as follows will be emitted:
```cpp
diff --git a/40_Programming_with_SOFA/60_API_overview/11_Data_in_components.md b/40_Programming_with_SOFA/60_API_overview/11_Data_in_components.md
index f1acaeadd..f8fdb9108 100644
--- a/40_Programming_with_SOFA/60_API_overview/11_Data_in_components.md
+++ b/40_Programming_with_SOFA/60_API_overview/11_Data_in_components.md
@@ -10,7 +10,7 @@ Wrapping values in this template class provides the following features:
automatic updates
- thread-safe access (work in progress)
-[Naming convention](../guidelines/#naming)
+[Naming convention](../../guidelines/#naming)
in SOFA specifies that Data name must be preceeded from `d_`.
diff --git a/40_Programming_with_SOFA/60_API_overview/13_DataTypes.md b/40_Programming_with_SOFA/60_API_overview/13_DataTypes.md
index 4fbea45e5..b3211b67e 100644
--- a/40_Programming_with_SOFA/60_API_overview/13_DataTypes.md
+++ b/40_Programming_with_SOFA/60_API_overview/13_DataTypes.md
@@ -1,7 +1,7 @@
DataTypes
=========
-As you may know, many SOFA C++ classes are templated, mostly on the type of DOF you want to simulate. Examples of templates can be found in the [MechanicalObject page](../../simulation-principles/mechanicalobject/), in the [templates section](../../simulation-principles/mechanicalobject/#templates). In the code, the use of templates can be confusing, especially when the type used in place of the template has itself many types. This page provides a short introduction to all these DOF types.
+As you may know, many SOFA C++ classes are templated, mostly on the type of DOF you want to simulate. Examples of templates can be found in the [MechanicalObject page](../../../simulation-principles/mechanicalobject/), in the [templates section](../../../simulation-principles/mechanicalobject/#templates). In the code, the use of templates can be confusing, especially when the type used in place of the template has itself many types. This page provides a short introduction to all these DOF types.
All DOF Types must implement (or define) all the following types:
@@ -13,8 +13,8 @@ All DOF Types must implement (or define) all the following types:
- **VecCoord** or **VecDeriv**: correspond to a vector of respectively _Coord_ or _Deriv_
-- **DataVecCoord or DataVecDeriv**: correspond to a [Data](../../simulation-principles/scene-graph/#data) containing a vector of respectively _Coord_ or _Deriv_. As noted in the associated article, the Data are variable of the class exposed to the user and other components in the scene
+- **DataVecCoord or DataVecDeriv**: correspond to a [Data](../../../simulation-principles/scene-graph/#data) containing a vector of respectively _Coord_ or _Deriv_. As noted in the associated article, the Data are variable of the class exposed to the user and other components in the scene
- **MatrixCoord or MatrixDeriv**: correspond to a matrix of respectively _Coord_ or _Deriv_, this is more especially used by solvers and constraint algorithms
-- **VecCoordId, VecDerivId, MatrixCoordId or MatrixDerivId**: correspond to an identifiant value (int) pointing to a vector or matrix of respectively _Coord_ or _Deriv_. This is very useful to access specific vectors or matrix in the simulation. [State vectors](../../simulation-principles/mechanicalobject/#state-vectors) for instance are managed with specific protected Ids by the solvers.
+- **VecCoordId, VecDerivId, MatrixCoordId or MatrixDerivId**: correspond to an identifiant value (int) pointing to a vector or matrix of respectively _Coord_ or _Deriv_. This is very useful to access specific vectors or matrix in the simulation. [State vectors](../../../simulation-principles/mechanicalobject/#state-vectors) for instance are managed with specific protected Ids by the solvers.
diff --git a/40_Programming_with_SOFA/60_API_overview/20_Create_links.md b/40_Programming_with_SOFA/60_API_overview/20_Create_links.md
index a8251ddcd..8c78875e9 100644
--- a/40_Programming_with_SOFA/60_API_overview/20_Create_links.md
+++ b/40_Programming_with_SOFA/60_API_overview/20_Create_links.md
@@ -1,4 +1,4 @@
-A [Link](../../using-sofa/lexicography/#link) allow you to access a SOFA component from another one anywhere
+A [Link](../../../using-sofa/lexicography/#link) allow you to access a SOFA component from another one anywhere
in the simulation graph. In your scene creation file, it usually appears
as : input=@../component. In this page we explain how to use it. In your
.h, declare your link :
diff --git a/40_Programming_with_SOFA/60_API_overview/35_Message_API.md b/40_Programming_with_SOFA/60_API_overview/35_Message_API.md
index bfbe6a361..f215af273 100644
--- a/40_Programming_with_SOFA/60_API_overview/35_Message_API.md
+++ b/40_Programming_with_SOFA/60_API_overview/35_Message_API.md
@@ -96,7 +96,7 @@ msg_warning("GUIManager") << "Previously used GUI not registered. Using default
```
If your message is for developers, you can use the dmsg_info, dmsg_deprecated, dmsg_warning,... functions.
-These messages are removed on end-user application (see SOFA_WITH_DEVTOOLS [build option](../../getting-started/build/build-options/)) and can be more specific and less well written than those
+These messages are removed on end-user application (see SOFA_WITH_DEVTOOLS [build option](../../../getting-started/build/build-options/)) and can be more specific and less well written than those
that target users. A very simple way to guide the use of the dmsg_* API is to ask yourself if fixing the message needs to have the source code to understand the message.
**NB** Please note that for classes that are not inheriting from BaseObject, an additional macro must be defined to register your class to the messaging system.
diff --git a/deprecated/15_Tutorial_application.md b/deprecated/15_Tutorial_application.md
index 816f3d9a4..b5b501cac 100644
--- a/deprecated/15_Tutorial_application.md
+++ b/deprecated/15_Tutorial_application.md
@@ -1,4 +1,4 @@
-**NOTE:** Every scene detailed in tutorial can also be launched using the [runSofa](../getting-started/run-sofa/) application directly.
+**NOTE:** Every scene detailed in tutorial can also be launched using the [runSofa](../../getting-started/run-sofa/) application directly.
Tutorial Application
--------------------
diff --git a/deprecated/Detection_Ray_tracing.md b/deprecated/Detection_Ray_tracing.md
index f13ad26e0..6588e1dc9 100644
--- a/deprecated/Detection_Ray_tracing.md
+++ b/deprecated/Detection_Ray_tracing.md
@@ -1,7 +1,7 @@
Collisions Detection: Ray tracing
=================================
-The RayTraceDetection component belongs to the category of [Collision Detection](../simulation-principles/collision/#collision-detection). This method traces a ray for each point in one object following the opposite of the point's normal up to find a triangle in the other object. Both triangles are tested to evaluate if they are in a colliding state.
+The RayTraceDetection component belongs to the category of [Collision Detection](../../simulation-principles/collision/#collision-detection). This method traces a ray for each point in one object following the opposite of the point's normal up to find a triangle in the other object. Both triangles are tested to evaluate if they are in a colliding state.
It **must be used with a TriangleOctreeModel**, as an octree is used to traverse the object.
@@ -20,7 +20,7 @@ computeBoundingTree(maxDepth=0);
### Broad phase
-The hierarchy is browsed, and the intersection between pairs of CubeModels is tested (using the [intersection method](../simulation-principles/collision/#intersection-methods) in the scene). If a collision is detected, the models are adding in the ```cmPair``` vector, containing potentially colliding pairs. This is done in the ```addCollisionModel()``` function. The detection between bounding volumes (CubeModel) is performed using [intersection method](../simulation-principles/collision/#intersection-methods) defined in the scene.
+The hierarchy is browsed, and the intersection between pairs of CubeModels is tested (using the [intersection method](../../simulation-principles/collision/#intersection-methods) in the scene). If a collision is detected, the models are adding in the ```cmPair``` vector, containing potentially colliding pairs. This is done in the ```addCollisionModel()``` function. The detection between bounding volumes (CubeModel) is performed using [intersection method](../../simulation-principles/collision/#intersection-methods) defined in the scene.
### Narrow phase
diff --git a/deprecated/Python2_Data_wrapping.md b/deprecated/Python2_Data_wrapping.md
index 6d307e7d0..ac8319d7e 100644
--- a/deprecated/Python2_Data_wrapping.md
+++ b/deprecated/Python2_Data_wrapping.md
@@ -13,7 +13,7 @@ If you are using SofaPython to create your scenes, you are probably interested i
This is possible, because the Data `integerValue` from `myComponent` is a scalar, and SofaPython provides natively the access to those Data types. In addition to Scalars, SofaPython also provides a python wrapper for more complex types such as `defaulttype::Vec` or `defaulttype::Matrix`, but also containers classes such as `helper::vector` or `helper::SVector` for instance.
-In order to get python support for your [custom Data types](../programming-with-sofa/api-overview/data-in-components/#data-for-custom-types), you will need to implement bindings for your custom type. This is done by:
+In order to get python support for your [custom Data types](../../programming-with-sofa/api-overview/data-in-components/#data-for-custom-types), you will need to implement bindings for your custom type. This is done by:
1. Implementing data / methods accessors and bindings in CPython
2. Declaring and Registering your bindings to SOFA's Python Factory