0027191: Documentation - redesign of information architecture -- revision (user guides)

Revision of User Guides

- Changes in User Guides Section to correspond with OCCT Overview structure: Mesh became a direct subsection of User Guides (it was a part of Modeling Algorithms).
  TObj is included into OCAF.
- Changes in User Guides – Modeling Algorithms section: Fillets and Chamfers, Offsets, Drafts, Pipes and Evolved shapes, Sewing, Features, 3D Model Defeaturing, 3D Model Periodicity,
  Object Modification are moved into The Topology API section.
- Changes in User Guides – Modeling Data section: Naming shapes, sub-shapes, their orientation and state section is renamed to Shape content. Shape Location is moved into Shape content section.
  Storage of Shapes is moved into BRep Format section of Specification. Lists and Maps of Shapes subsection is moved into Topology - Exploration of Topological Data Structures.
- Some pictures in User Guides (Foundation Classes, Modeling Data, Modeling Algorithms) and Tutorial are updated to improve quality and correct mistakes.

dox/FILES_HTML.txt

@@ -33,13 +33,13 @@ user_guides/user_guides.md
 user_guides/foundation_classes/foundation_classes.md
 user_guides/modeling_data/modeling_data.md
 user_guides/modeling_algos/modeling_algos.md
+user_guides/mesh/mesh.md
 user_guides/shape_healing/shape_healing.md
 user_guides/visualization/visualization.md
 user_guides/iges/iges.md
 user_guides/step/step.md
 user_guides/xde/xde.md
 user_guides/ocaf/ocaf.md
-user_guides/tobj/tobj.md
 user_guides/draw_test_harness/draw_test_harness.md
 user_guides/inspector/inspector.md
 user_guides/vis/vis.md

dox/FILES_PDF.txt

@@ -4,21 +4,22 @@
 # Empty spaces are allowed.
 # Strings starting with '#' are treated as comments and ignored.
 
-specification/brep_wp/brep_wp.md
+tutorial/tutorial.md
+
+upgrade/upgrade.md
+
 user_guides/foundation_classes/foundation_classes.md
-user_guides/iges/iges.md
 user_guides/modeling_data/modeling_data.md
 user_guides/modeling_algos/modeling_algos.md
-specification/boolean_operations/boolean_operations.md
-user_guides/shape_healing/shape_healing.md
+user_guides/mesh/mesh.md
 user_guides/ocaf/ocaf.md
-user_guides/step/step.md
-user_guides/draw_test_harness/draw_test_harness.md
-user_guides/inspector/inspector.md
-user_guides/tobj/tobj.md
 user_guides/visualization/visualization.md
-user_guides/xde/xde.md
 user_guides/vis/vis.md
+user_guides/iges/iges.md
+user_guides/step/step.md
+user_guides/xde/xde.md
+user_guides/inspector/inspector.md
+user_guides/draw_test_harness/draw_test_harness.md
 
 contribution/contribution_workflow/contribution_workflow.md
 contribution/documentation/documentation.md
@@ -26,7 +27,6 @@ contribution/coding_rules.md
 contribution/git_guide/git_guide.md
 contribution/tests/tests.md
 
-upgrade/upgrade.md
+specification/boolean_operations/boolean_operations.md
+specification/brep_format.md
 specification/pbr_math.md
-
-tutorial/tutorial.md

dox/introduction/introduction.md

@@ -281,7 +281,7 @@ Each sub-domain of Shape Healing has its own scope of functionality:
 | Customization | Modifies the shape representation to fit specific needs. | The shape is not modified, only the mathematical form of its internal representation is changed. |
 | Processing | Mechanism of shape modification via a user-editable resource file. | |
 
-For more details, refer to @ref occt_shg "Shape Healing User's guide".
+For more details, refer to @ref occt_user_guides__shape_healing "Shape Healing User's guide".
 
 @subsection intro_overview_ocaf Application Framework
 

dox/user_guides/draw_test_harness/draw_test_harness.md

@@ -6979,7 +6979,7 @@ sr is a shape COMPOUND FORWARD Free Modified
 
 The new algorithm of Boolean operations avoids a large number of weak points and limitations presented in the old Boolean operation algorithm.
 It also provides wider range of options and diagnostics.
-The algorithms of Boolean component are fully described in the @ref specification__boolean_1 "Boolean Operations" of boolean operation user guide.
+The algorithms of Boolean component are fully described in the @ref specification__boolean_operations "Boolean Operations" of boolean operation user guide.
 
 For the Draw commands to perform operations in Boolean component, read the dedicated section @ref occt_draw_bop "Boolean operations commands"
 
@@ -11733,4 +11733,3 @@ The procedure consists in defining the system variables and using the *pload* co
 Draw[]> set env(CSF_MyDrawPluginDefaults) /users/test
 Draw[]> pload -MyDrawPlugin ALL
 ~~~~
-

dox/user_guides/foundation_classes/foundation_classes.md

@@ -7,7 +7,6 @@ Foundation Classes  {#occt_user_guides__foundation_classes}
 
 This manual explains how to use Open CASCADE Technology (**OCCT**) Foundation Classes.
 It provides basic documentation on foundation classes.
-For advanced information on foundation classes and their applications, see our <a href="https://www.opencascade.com/content/tutorial-learning">E-learning & Training</a> offerings.
    
 Foundation Classes provide a variety of general-purpose services such as automated dynamic memory management (manipulation of objects by handle), collections, exception handling, genericity by down-casting and plug-in creation.
 

dox/user_guides/iges/iges.md

@@ -1,4 +1,4 @@
-IGES Support  {#occt_user_guides__iges}
+IGES Translator  {#occt_user_guides__iges}
 ==================
 
 @tableofcontents
@@ -15,7 +15,7 @@ Other kinds of data such as colors and names can be read or written with the hel
   * an IGES entity is an entity in the IGES normal sense.
   * a root entity is the highest level entity of any given type, e.g. type 144 for surfaces and type 186 for solids. Roots are not referenced by other entities.
 
-This manual mainly explains how  to convert an IGES file to an Open CASCADE Technology (**OCCT**) shape and  vice versa. It provides basic documentation on conversion. For advanced  information on conversion, see our <a href="https://www.opencascade.com/content/tutorial-learning">E-learning & Training</a> offerings.
+This manual mainly explains how  to convert an IGES file to an Open CASCADE Technology (**OCCT**) shape and  vice versa. It provides basic documentation on conversion.
 
 IGES files produced in accordance with IGES standard versions up to and including version 5.3 can be read. IGES files that are produced by this  interface conform to IGES version 5.3 (Initial Graphics Exchange Specification,  IGES 5.3. ANS US PRO/IPO-100-1996). 
 

dox/user_guides/mesh/mesh.md

@@ -0,0 +1,228 @@
+Mesh {#occt_user_guides__mesh}
+=========================
+
+@tableofcontents
+
+@section occt_modalg_11_1 Mesh presentations
+
+In addition to support of exact geometrical representation of 3D objects Open CASCADE Technology provides functionality to work with tessellated  representations of objects in form of meshes.
+
+Open CASCADE Technology mesh functionality provides:
+- data structures to store surface mesh data associated to shapes, and some basic algorithms to handle these data
+- data structures and algorithms to build surface triangular mesh from *BRep* objects (shapes).
+- tools to extend 3D visualization capabilities of Open CASCADE Technology with displaying meshes along with associated pre- and post-processor data.
+
+Open CASCADE Technology includes two mesh converters:
+- VRML converter translates Open CASCADE shapes to VRML 1.0 files (Virtual Reality Modeling Language). Open CASCADE shapes may be translated in two representations: shaded or wireframe. A shaded representation present shapes as sets of triangles computed by a mesh algorithm while a wireframe representation present shapes as sets of curves.
+- STL converter translates Open CASCADE shapes to STL files. STL (STtereoLithography) format is widely used for rapid prototyping.
+
+Open CASCADE SAS also offers Advanced Mesh Products:
+- <a href="https://www.opencascade.com/content/mesh-framework">Open CASCADE Mesh Framework (OMF)</a>
+- <a href="https://www.opencascade.com/content/express-mesh">Express Mesh</a>
+
+Besides, we can efficiently help you in the fields of surface and volume meshing algorithms, mesh optimization algorithms etc. If you require a qualified advice about meshing algorithms, do not hesitate to benefit from the expertise of our team in that domain.
+
+The projects dealing with numerical simulation can benefit from using SALOME - an Open Source Framework for CAE with CAD data interfaces, generic Pre- and Post- F.E. processors and API for integrating F.E. solvers.
+
+Learn more about SALOME platform on https://www.salome-platform.org
+
+@section occt_modalg_11_2 Meshing algorithm
+
+The algorithm of shape triangulation is provided by the functionality of *BRepMesh_IncrementalMesh* class, which adds a triangulation of the shape to its topological data structure. This triangulation is used to visualize the shape in shaded mode.
+
+~~~~~
+#include <IMeshData_Status.hxx>
+#include <IMeshTools_Parameters.hxx>
+#include <BRepMesh_IncrementalMesh.hxx>
+
+Standard_Boolean meshing_explicit_parameters()
+{
+  const Standard_Real aRadius = 10.0; 
+  const Standard_Real aHeight = 25.0; 
+  BRepPrimAPI_MakeCylinder aCylinder(aRadius, aHeight); 
+  TopoDS_Shape aShape = aCylinder.Shape();
+
+  const Standard_Real aLinearDeflection   = 0.01;
+  const Standard_Real anAngularDeflection = 0.5;
+  BRepMesh_IncrementalMesh aMesher (aShape, aLinearDeflection, Standard_False, anAngularDeflection, Standard_True);
+  const Standard_Integer aStatus = aMesher.GetStatusFlags();
+  return !aStatus;
+}
+
+Standard_Boolean meshing_imeshtools_parameters()
+{
+  const Standard_Real aRadius = 10.0; 
+  const Standard_Real aHeight = 25.0; 
+  BRepPrimAPI_MakeCylinder aCylinder(aRadius, aHeight); 
+  TopoDS_Shape aShape = aCylinder.Shape();
+  
+  IMeshTools_Parameters aMeshParams;
+  aMeshParams.Deflection               = 0.01;
+  aMeshParams.Angle                    = 0.5;
+  aMeshParams.Relative                 = Standard_False;
+  aMeshParams.InParallel               = Standard_True;
+  aMeshParams.MinSize                  = Precision::Confusion();
+  aMeshParams.InternalVerticesMode     = Standard_True;
+  aMeshParams.ControlSurfaceDeflection = Standard_True;
+
+  BRepMesh_IncrementalMesh aMesher (aShape, aMeshParams);
+  const Standard_Integer aStatus = aMesher.GetStatusFlags();
+  return !aStatus;
+}
+~~~~~
+
+The default meshing algorithm *BRepMesh_IncrementalMesh* has two major options to define triangulation -- linear and angular deflections. 
+
+At the first step all edges from a face are discretized according to the specified parameters. 
+
+At the second step, the faces are tessellated. Linear deflection limits the distance between a curve and its tessellation, whereas angular deflection limits the angle between subsequent segments in a polyline.
+
+@figure{/user_guides/mesh/images/modeling_algos_image056.png,"Deflection parameters of BRepMesh_IncrementalMesh algorithm",420}
+
+There are additional options to control behavior of the meshing of face interior: *DeflectionInterior* and *AngleInterior*. *DeflectionInterior* limits the distance between triangles and the face interior. *AngleInterior* (used for tessellation of B-spline faces only) limits the angle between normals (N1, N2 and N3 in the picture) in the nodes of every link of the triangle. There is an exception for the links along the face boundary edges, "Angular Deflection" is used for them during edges discretization.
+
+@figure{/user_guides/mesh/images/modeling_algos_image057.png,"Linear and angular interior deflections",420}
+
+Note that if a given value of linear deflection is less than shape tolerance then the algorithm will skip this value and will take into account the shape tolerance.
+
+The application should provide deflection parameters to compute a satisfactory mesh. Angular deflection is relatively simple and allows using a default value (12-20 degrees). Linear deflection has an absolute meaning and the application should provide the correct value for its models. Giving small values may result in a too huge mesh (consuming a lot of memory, which results in a  long computation time and slow rendering) while big values result in an ugly mesh.
+
+For an application working in dimensions known in advance it can be reasonable to use the absolute linear deflection for all models. This provides meshes according to metrics and precision used in the application (for example, it it is known that the model will be stored in meters, 0.004 m is enough for most tasks).
+
+However, an application that imports models created in other applications may not use the same deflection for all models. Note that actually this is an abnormal situation and this application is probably just a viewer for CAD models with  dimensions varying by an order of magnitude. This problem can be solved by introducing the concept of a relative linear deflection with some  LOD (level of detail). The level of detail is a scale factor for absolute deflection, which is applied to model dimensions.
+
+Meshing covers a shape with a triangular mesh. Other than hidden line removal, you can use meshing to transfer the shape to another tool: a manufacturing tool, a shading algorithm, a finite element algorithm, or a collision algorithm. 
+
+You can obtain information on the shape by first exploring it. To access triangulation of a face in the shape later, use *BRepTool::Triangulation*. To access a polygon, which is the approximation of an edge of the face, use *BRepTool::PolygonOnTriangulation*.
+
+@section occt_modalg_11_3 BRepMesh Architecture
+@subsection occt_modalg_11_3_1 Goals
+
+The main goals of the chosen architecture are:
+  * Remove tight connections between data structures, auxiliary tools and algorithms to create an extensible solution, easy for maintenance and improvements;
+  * Separate the code among several functional units responsible for specific operation for the sake of simplification of debugging and readability;
+  * Introduce new data structures enabling the possibility to manipulate a discrete model of a particular entity (edge, wire, face) in order to perform computations locally instead of processing the entire model;
+  * Implement a new triangulation algorithm replacing the existing functionality that contains overcomplicated solutions that need to be moved to the upper level. In addition, provide the possibility to change the algorithm depending on surface type (initially to speed up meshing of planes).
+
+@subsection occt_modalg_11_3_2 General workflow
+@figure{/user_guides/mesh/images/modeling_algos_mesh_001.svg,"General workflow of BRepMesh component",500}
+
+Generally, the workflow of the component can be divided into six parts:
+  * **Creation of model data structure**: source *TopoDS_Shape* passed to algorithm is analyzed and exploded into faces and edges. The reflection corresponding to each topological entity is created in the data model. Note that underlying algorithms use the data model as input and access it via a common interface which allows creating a custom data model with necessary dependencies between particular entities (see the paragraph "Data model interface");
+  * **Discretize edges 3D & 2D curves**: 3D curve as well as an associated set of 2D curves of each model edge is discretized in order to create a coherent skeleton used as a base in face meshing process. If an edge of the source shape already contains polygonal data which suits the specified parameters, it is extracted from the shape and stored in the model as is. Each edge is processed separately, the adjacency is not taken into account;
+  * **Heal discrete model**: the source *TopoDS_Shape* can contain problems, such as open wires or self-intersections, introduced during design, exchange or modification of model. In addition, some problems like self-intersections can be introduced by roughly discretized edges. This stage is responsible for analysis of a discrete model in order to detect and repair problems or to refuse further processing of a model part in case if a problem cannot be solved;
+  * **Preprocess discrete model**: defines actions specific to the implemented approach to be performed before meshing of faces. By default, this operation iterates over model faces, checks the consistency of existing triangulations and cleans topological faces and adjacent edges from polygonal data in case of inconsistency or marks a face of the discrete model as not required for the computation;
+  * **Discretize faces**: represents the core part performing mesh generation for a particular face based on 2D discrete data. This operation caches polygonal data associated with face edges in the data model for further processing and stores the generated mesh to *TopoDS_Face*;
+  * **Postprocess discrete model**: defines actions specific for the implemented approach to be performed after meshing of faces. By default, this operation stores polygonal data obtained at the previous stage to *TopoDS_Edge* objects of the source model.
+
+@subsection occt_modalg_11_3_3 Common interfaces
+The component structure contains two units: <i>IMeshData</i> (see Data model interface) and <i>IMeshTools</i>, defining common interfaces for the data model and algorithmic tools correspondingly. Class *IMeshTools_Context* represents a connector between these units. The context class caches the data model as well as the tools corresponding to each of six stages of the workflow mentioned above and provides methods to call the corresponding tool safely (designed similarly to *IntTools_Context* in order to keep consistency with OCCT core tools). All stages, except for the first one, use the data model as input and perform a specific action on the entire structure. Thus, API class *IMeshTools_ModelAlgo* is defined in order to unify the interface of tools manipulating the data model. Each tool supposed to process the data model should inherit this interface enabling the possibility to cache it in context. In contrast to others, the model builder interface is defined by another class *IMeshTools_ModelBuilder* due to a different meaning of the stage. The entry point starting the entire workflow is represented by *IMeshTools_MeshBuilder*.
+
+The default implementation of *IMeshTools_Context* is given in *BRepMesh_Context* class initializing the context by instances of default algorithmic tools.
+
+The factory interface *IMeshTools_MeshAlgoFactory* gives the possibility to change the triangulation algorithm for a specific surface. The factory returns an instance of the triangulation algorithm via *IMeshTools_MeshAlgo* interface depending on the type of surface passed as parameter. It is supposed to be used at the face discretization stage.
+
+The default implementation of AlgoFactory is given in *BRepMesh_MeshAlgoFactory* returning algorithms of different complexity chosen according to the passed surface type. In its turn, it is used as the initializer of *BRepMesh_FaceDiscret* algorithm representing the starter of face discretization stage.
+
+@figure{/user_guides/mesh/images/modeling_algos_mesh_002.svg,"Interface describing entry point to meshing workflow",500}
+
+Remaining interfaces describe auxiliary tools:
+  * *IMeshTools_CurveTessellator*: provides a common interface to the algorithms responsible for creation of discrete polygons on 3D and 2D curves as well as tools for extraction of existing polygons from *TopoDS_Edge* allowing to obtain discrete points and the corresponding parameters on curve regardless of the implementation details (see examples of usage of derived classes *BRepMesh_CurveTessellator*, *BRepMesh_EdgeTessellationExtractor* in *BRepMesh_EdgeDiscret*);
+  * *IMeshTools_ShapeExplorer*: the last two interfaces represent visitor design pattern and are intended to separate iteration over elements of topological shape (edges and faces) from the operations performed on a particular element;
+  * *IMeshTools_ShapeVisitor*: provides a common interface for operations on edges and faces of the target topological shape. It can be used in couple with *IMeshTools_ShapeExplorer*. The default implementation available in *BRepMesh_ShapeVisitor* performs initialization of the data model. The advantage of such approach is that the implementation of *IMeshTools_ShapeVisitor* can be changed according to the specific data model whereas the shape explorer implementation remains the same.
+
+@subsection occt_modalg_11_3_4 Create model data structure
+The data structures intended to keep discrete and temporary data required by underlying algorithms are created at the first stage of the meshing procedure. Generally, the model represents dependencies between entities of the source topological shape suitable for the target task.
+
+#### Data model interface
+Unit <i>IMeshData</i> provides common interfaces specifying the data model API used on different stages of the entire workflow. Dependencies and references of the designed interfaces are given in the figure below. A specific interface implementation depends on the target application which allows the developer to implement different models and use custom low-level data structures, e.g. different collections, either <i>NCollection</i> or STL. *IMeshData_Shape* is used as the base class for all data structures and tools keeping the topological shape in order to avoid possible copy-paste.
+
+The default implementation of interfaces is given in <i>BRepMeshData</i> unit. The main aim of the default data model is to provide features performing discretization of edges in a parallel mode. Thus, curve, pcurve and other classes are based on STL containers and smart-pointers as far as <i>NCollection</i> does not provide thread-safety for some cases (e.g. *NCollection_Sequence*). In addition, it closely reflects topology of the source shape, i.e. the number of edges in the data model is equal to the number of edges in the source model; each edge contains a set of pcurves associated with its adjacent faces which allows creation of discrete polygons for all pcurves or the 3D curve of a particular edge in a separate thread.
+
+**Advantages**:
+In case of necessity, the data model (probably with algorithms for its processing) can be easily substituted by another implementation supporting another kind of dependencies between elements.
+
+An additional example of a different data model is the case when it is not required to create a mesh with discrete polygons synchronized between adjacent faces, i.e. in case of necessity to speed up creation of a rough per-face tessellation used for visualization or quick computation only (the approach used in *XDEDRAW_Props*).
+
+@figure{/user_guides/mesh/images/modeling_algos_mesh_003.svg,"Common API of data model",500}
+
+#### Collecting data model
+At this stage the data model is filled by entities according to the topological structure of the source shape. A default implementation of the data model is given in <i>BRepMeshData</i> unit and represents the model as two sets: a set of edges and a set of faces. Each face consists of one or several wires, the first of which always represents the outer wire, while others are internal. In its turn, each wire depicts the ordered sequence of oriented edges. Each edge is characterized by a single 3D curve and zero (in case of free edge) or more 2D curves associated with faces adjacent to this edge. Both 3D and 2D curves represent a set of pairs point-parameter defined in 3D and 2D space of the reference face correspondingly. An additional difference between a curve and a pcurve is that the latter has a reference to the face it is defined for.
+
+Model filler algorithm is represented by *BRepMesh_ShapeVisitor* class creating the model as a reflection to topological shape with help of *BRepMesh_ShapeExplorer* performing iteration over edges and faces of the target shape. Note that the algorithm operates on a common interface of the data model and creates a structure without any knowledge about the implementation details and underlying data structures. The entry point to collecting functionality is *BRepMesh_ModelBuilder* class.
+
+@subsection occt_modalg_11_3_5 Discretize edges 3D & 2D curves
+At this stage only the edges of the data model are considered. Each edge is processed separately (with the possibility to run processing in multiple threads). The edge is checked for existing polygonal data. In case if at least one representation exists and suits the meshing parameters, it is recuperated and used as reference data for tessellation of the whole set of pcurves as well as 3D curve assigned to the edge (see *BRepMesh_EdgeTessellationExtractor*). Otherwise, a new tessellation algorithm is created and used to generate the initial polygon (see *BRepMesh_CurveTessellator*) and the edge is marked as outdated. In addition, the model edge is updated by deflection as well as recomputed same range, same parameter and degeneracy parameters. See *BRepMesh_EdgeDiscret* for implementation details.
+
+<i>IMeshData</i> unit defines interface *IMeshData_ParametersListArrayAdaptor*, which is intended to adapt arbitrary data structures to the *NCollection_Array1* container API. This solution is made to use both *NCollection_Array1* and *IMeshData_Curve* as the source for *BRepMesh_EdgeParameterProvider* tool intended to generate a consistent parametrization taking into account the same parameter property.
+
+@subsection occt_modalg_11_3_6 Heal discrete model
+In general, this stage represents a set of operations performed on the entire discrete model in order to resolve inconsistencies due to the problems caused by design, translation or rough discretization. A different sequence of operations can be performed depending on the target triangulation algorithm, e.g. there are different approaches to process self-intersections – either to amplify edges discretization by decreasing the target precision or to split links at the intersection points. At this stage the whole set of edges is considered in aggregate and their adjacency is taken into account. A default implementation of the model healer is given in *BRepMesh_ModelHealer* which performs the following actions:
+  * Iterates over model faces and checks their wires for consistency, i.e. whether the wires are closed and do not contain self-intersections. The data structures are designed free of collisions, thus it is possible to run processing in a parallel mode;
+  * Forcibly connects the ends of adjacent edges in the parametric space, closing gaps between possible disconnected parts. The aim of this operation is to create a correct discrete model defined relatively to the parametric space of the target face taking into account connectivity and tolerances of 3D space only. This means that no specific computations are made to determine U and V tolerance;
+  * Registers intersections on edges forming the face shape. Two solutions are possible in order to resolve self-intersection: 
+    * Decrease deflection of a particular edge and update its discrete model. After that the workflow "intersection check – amplification" is repeated up to 5 times. As the result, target edges contain a finer tessellation and meshing continues or the face is marked by *IMeshData_SelfIntersectingWire* status and refused from further processing;
+    * Split target edges by intersection point and synchronize the updated polygon with curve and remaining pcurves associated to each edge. This operation presents a more robust solution comparing to the amplification procedure with a guaranteed result, but it is more difficult for implementation from the point of view of synchronization functionality.
+
+@subsection occt_modalg_11_3_7 Preprocess discrete model
+This stage implements actions to be performed before meshing of faces. Depending on target goals it can be changed or omitted. By default, *BRepMesh_ModelPreProcessor* implements the functionality checking topological faces for consistency of existing triangulation, i.e.: consistency with the target deflection parameter; indices of nodes referenced by triangles do not exceed the number of nodes stored in a triangulation. If the face fails some checks, it is cleaned from triangulation and its adjacent edges are cleaned from existing polygons. This does not affect a discrete model and does not require any recomputation as the model keeps tessellations for the whole set of edges despite consistency of their polygons.
+
+@subsection occt_modalg_11_3_8 Discretize faces
+Discretization of faces is the general part of meshing algorithm. At this stage edges tessellation data obtained and processed on previous steps is used to form contours of target faces and passed as input to the triangulation algorithm. Default implementation is provided by *BRepMesh_FaceDiscret* class which represents a starter for triangulation algorithm. It iterates over faces available in the data model, creates an instance of the triangulation algorithm according to the type of surface associated with each face via *IMeshTools_MeshAlgoFactory* and executes it. Each face is processed separately, thus it is possible to process faces in a parallel mode. The class diagram of face discretization is given in the figure below.
+ 
+@figure{/user_guides/mesh/images/modeling_algos_mesh_004.svg,"Class diagram of face discrete stage",300}
+
+In general, face meshing algorithms have the following structure:
+  * *BRepMesh_BaseMeshAlgo* implements *IMeshTools_MeshAlgo* interface and the base functionality for inherited algorithms. The main goal of this class is to initialize an instance of *BRepMesh_DataStructureOfDelaun* as well as auxiliary data structures suitable for nested algorithms using face model data passed as input parameter. Despite implementation of triangulation algorithm this structure is currently supposed as common for OCCT. However, the user is free to implement a custom algorithm and supporting data structure accessible via *IMeshTools_MeshAlgo* interface, e.g. to connect a 3-rd party meshing tool that does not support *TopoDS_Shape* out of box. For this, such structure provides the possibility to distribute connectors to various algorithms in the form of plugins;
+  * *BRepMesh_DelaunayBaseMeshAlgo* and *BRepMesh_SweepLineMeshAlgo* classes implement core meshing functionality operating directly on an instance of *BRepMesh_DataStructureOfDelaun*. The algorithms represent mesh generation tools adding new points from the data structure to the final mesh;
+  * *BRepMesh_NodeInsertionMeshAlgo* class represents a wrapper intended to extend the algorithm inherited from *BRepMesh_BaseMeshAlgo* to enable the functionality generating surface nodes and inserting them into the structure. On this level, an instance of the classification tool is created and can be used to accept-reject internal nodes. In addition, computations necessary for scaling UV coordinates of points relatively to the range specified for the corresponding direction are performed. As far as both triangulation algorithms work on static data provided by the structure, new nodes are added at the initialization stage. Surface nodes are generated by an auxiliary tool called range splitter and passed as template parameter (see Range splitter);
+  * Classes *BRepMesh_DelaunayNodeInsertionMeshAlgo* and *BRepMesh_SweepLineNodeInsertionMeshAlgo* implement algorithm-specific functionality related to addition of internal nodes supplementing functionality provided by *BRepMesh_NodeInsertionMeshAlgo*;
+  * *BRepMesh_DelaunayDeflectionControlMeshAlgo* extends functionality of *BRepMesh_DelaunayNodeInsertionMeshAlgo* by additional procedure controlling deflection of generated triangles.
+
+
+
+
+
+BRepMesh provides user a way to switch default triangulation algorithm to a custom one, either implemented by user or available worldwide. There are three base classes that can be currently used to integrate 3rd-party algorithms:
+
+* *BRepMesh_ConstrainedBaseMeshAlgo* base class for tools providing generation of triangulations with constraints requiring no common processing by BRepMesh;
+* *BRepMesh_CustomBaseMeshAlgo* provides the entry point for generic algorithms without support of constraints and supposed for generation of base mesh only. Constraint edges are processed using standard functionality provided by the component itself upon background mesh produced by 3rd-party solver;
+* *BRepMesh_CustomDelaunayBaseMeshAlgo* contains initialization part for tools used by BRepMesh for checks or optimizations using results of 3rd-party algorithm.
+
+Meshing algorithms could be provided by implemeting *IMeshTools_MeshAlgoFactory* with related interfaces and passing it to *BRepMesh_Context::SetFaceDiscret()*. OCCT comes with two base 2D meshing algorithms: *BRepMesh_MeshAlgoFactory* (used by default) and *BRepMesh_DelabellaMeshAlgoFactory*.
+
+The following example demonstrates how it could be done from *Draw* environment:
+
+~~~~~
+psphere s 10
+
+### Default Algo ###
+incmesh s 0.0001 -algo default
+
+### Delabella Algo ###
+incmesh s 0.0001 -algo delabella
+~~~~~
+
+The code snippet below shows passing a custom mesh factory to BRepMesh_IncrementalMesh:
+
+~~~~~
+IMeshTools_Parameters aMeshParams;
+Handle(IMeshTools_Context) aContext = new BRepMesh_Context();
+aContext->SetFaceDiscret (new BRepMesh_FaceDiscret (new BRepMesh_DelabellaMeshAlgoFactory()));
+
+BRepMesh_IncrementalMesh aMesher;
+aMesher.SetShape (aShape);
+aMesher.ChangeParameters() = aMeshParams;
+
+aMesher.Perform (aContext);
+~~~~~
+
+#### Range splitter
+Range splitter tools provide functionality to generate internal surface nodes defined within the range computed using discrete model data. The base functionality is provided by *BRepMesh_DefaultRangeSplitter* which can be used without modifications in case of planar surface. The default splitter does not generate any internal node.
+
+*BRepMesh_ConeRangeSplitter*, *BRepMesh_CylinderRangeSplitter* and *BRepMesh_SphereRangeSplitter* are specializations of the default splitter intended for quick generation of internal nodes for the corresponding type of analytical surface.
+
+*BRepMesh_UVParamRangeSplitter* implements base functionality taking discretization points of face border into account for node generation. Its successors BRepMesh_TorusRangeSplitter and *BRepMesh_NURBSRangeSplitter* extend the base functionality for toroidal and NURBS surfaces correspondingly.
+
+@subsection occt_modalg_11_3_9 Postprocess discrete model
+This stage implements actions to be performed after meshing of faces. Depending on target goals it can be changed or omitted. By default, *BRepMesh_ModelPostProcessor* commits polygonal data stored in the data model to *TopoDS_Edge*. 

dox/user_guides/modeling_data/modeling_data.md

@@ -7,7 +7,7 @@ Modeling Data {#occt_user_guides__modeling_data}
 
 Modeling Data supplies data structures to represent 2D and 3D geometric models. 
 
-This manual explains how to use Modeling Data. For advanced information on modeling data, see our <a href="https://www.opencascade.com/content/tutorial-learning">E-learning & Training</a> offerings.
+This manual explains how to use Modeling Data.
 
 @section occt_modat_1 Geometry Utilities
 
@@ -548,181 +548,6 @@ However, the Geom package essentially provides data structures, not algorithms.
 You can refer to the <i> GC</i> package to find more evolved construction algorithms for
 Geom objects.
 
-@section occt_modat_4 Properties of Shapes
-
-@subsection occt_modat_4_1 Local Properties of Shapes
-
-<i>BRepLProp</i> package provides the Local Properties of Shapes component, 
-which contains algorithms computing various local properties on edges and faces in a BRep model.
-
-The local properties which may be queried are:
-
-  * for a point of parameter u on a curve which supports an edge :
-    * the point,
-    * the derivative vectors, up to the third degree,
-    * the tangent vector,
-    * the normal,
-    * the curvature, and the center of curvature;
-  * for a point of parameter (u, v) on a surface which supports a face :
-    * the point,
-    * the derivative vectors, up to the second degree,
-    * the tangent vectors to the u and v isoparametric curves,
-    * the normal vector,
-    * the minimum or maximum curvature, and the corresponding directions of curvature;
-  * the degree of continuity of a curve which supports an edge, built by the concatenation of two other edges, at their junction point.
-
-Analyzed edges and faces are described as <i> BRepAdaptor</i> curves and surfaces, 
-which provide shapes with an interface for the description of their geometric support. 
-The base point for local properties is defined by its u parameter value on a curve, or its (u, v) parameter values on a surface.
-
-@subsection occt_modat_4_2 Local Properties of Curves and Surfaces
-
-The "Local Properties of Curves and Surfaces" component provides algorithms for computing various local properties on a Geom curve (in 2D or 3D space) or a surface. It is composed of:
-
-  * <i> Geom2dLProp</i> package, which allows computing Derivative and Tangent vectors (normal and curvature) of a parametric point on a 2D curve;
-  * <i> GeomLProp </i> package, which provides local properties on 3D curves and surfaces
-  * <i> LProp </i> package, which provides an enumeration used to characterize a particular point on a 2D curve.
-
-Curves are either <i> Geom_Curve </i> curves (in 3D space) or <i> Geom2d_Curve </i> curves (in the plane). 
-Surfaces are <i> Geom_Surface </i> surfaces. The point on which local properties are calculated 
-is defined by its u parameter value on a curve, and its (u,v) parameter values on a surface.
-
-It is possible to query the same local properties for points as mentioned above, and additionally for 2D curves:
-
-  * the points corresponding to a minimum or a maximum of curvature;
-  * the inflection points.
-  
-  
-#### Example: How to check the surface concavity
-
-To check the concavity of a surface, proceed as follows:
-
-  1. Sample the surface and compute at each point the Gaussian curvature.
-  2. If the value of the curvature changes of sign, the surface is concave or convex depending on the point of view.
-  3. To compute a Gaussian curvature, use the class <i> SLprops</i> from <i> GeomLProp</i>, which instantiates the generic class <i> SLProps </i>from <i> LProp</i> and use the method <i> GaussianCurvature</i>.
-
-@subsection occt_modat_4_2a Continuity of Curves and Surfaces
-
-Types of supported continuities for curves and surfaces are described in *GeomAbs_Shape* enumeration.
-
-In respect of curves, the following types of continuity are supported (see the figure below):
-  * C0 (*GeomAbs_C0*) - parametric continuity. It is the same as G0 (geometric continuity), so the last one is not represented by separate variable.
-  * G1 (*GeomAbs_G1*) - tangent vectors on left and on right are parallel.
-  * C1 (*GeomAbs_C1*) - indicates the continuity of the first derivative.
-  * G2 (*GeomAbs_G2*) - in addition to G1 continuity, the centers of curvature on left and on right are the same.
-  * C2 (*GeomAbs_C2*) - continuity of all derivatives till the second order.
-  * C3 (*GeomAbs_C3*) - continuity of all derivatives till the third order.
-  * CN (*GeomAbs_CN*) - continuity of all derivatives till the N-th order (infinite order of continuity).
-
-*Note:* Geometric continuity (G1, G2) means that the curve can be reparametrized to have parametric (C1, C2) continuity.
-
-@figure{/user_guides/modeling_data/images/modeling_data_continuity_curves.svg,"Continuity of Curves",420}
-
-The following types of surface continuity are supported:
-  * C0 (*GeomAbs_C0*) - parametric continuity (the surface has no points or curves of discontinuity).
-  * G1 (*GeomAbs_G1*) - surface has single tangent plane in each point.
-  * C1 (*GeomAbs_C1*) - indicates the continuity of the first derivatives.
-  * G2 (*GeomAbs_G2*) - in addition to G1 continuity, principal curvatures and directions are continuous.
-  * C2 (*GeomAbs_C2*) - continuity of all derivatives till the second order.
-  * C3 (*GeomAbs_C3*) - continuity of all derivatives till the third order.
-  * CN (*GeomAbs_CN*) - continuity of all derivatives till the N-th order (infinite order of continuity).
-
-@figure{/user_guides/modeling_data/images/modeling_data_continuity_surfaces.svg,"Continuity of Surfaces",420}
-
-Against single surface, the connection of two surfaces (see the figure above) defines its continuity in each intersection point only. Smoothness of connection is a minimal value of continuities on the intersection curve.
-
-
-@subsection occt_modat_4_2b Regularity of Shared Edges
-
-Regularity of an edge is a smoothness of connection of two faces sharing this edge. In other words, regularity is a minimal continuity between connected faces in each point on edge.
-
-Edge's regularity can be set by *BRep_Builder::Continuity* method. To get the regularity use *BRep_Tool::Continuity* method.
-
-Some algorithms like @ref occt_modalg_6 "Fillet" set regularity of produced edges by their own algorithms. On the other hand, some other algorithms (like @ref specification__boolean_operations "Boolean Operations", @ref occt_user_guides__shape_healing "Shape Healing", etc.) do not set regularity. If the regularity is needed to be set correctly on a shape, the method *BRepLib::EncodeRegularity* can be used. It calculates and sets correct values for all edges of the shape.
-
-The regularity flag is extensively used by the following high level algorithms: @ref occt_modalg_6_1_2 "Chamfer", @ref occt_modalg_7_3 "Draft Angle", @ref occt_modalg_10 "Hidden Line Removal", @ref occt_modalg_9_2_3 "Gluer".
-
-  
-@subsection occt_modat_4_3 Global Properties of Shapes
-
-The Global Properties of Shapes component provides algorithms for computing the global 
-properties of a composite geometric system in 3D space, and frameworks to query the computed results.
-
-The global properties computed for a system are :
-  * mass,
-  * mass center,
-  * matrix of inertia,
-  * moment about an axis,
-  * radius of gyration about an axis,
-  * principal properties of inertia such as principal axis, principal moments, and principal radius of gyration.
-
-Geometric systems are generally defined as shapes. Depending on the way they are analyzed, these shapes will give properties of:
-
-  * lines induced from the edges of the shape,
-  * surfaces induced from the faces of the shape, or
-  * volumes induced from the solid bounded by the shape.
-
-The global properties of several systems may be brought together to give the global properties of the system composed of the sum of all individual systems.
-
-The Global Properties of Shapes component is composed of:
-* seven functions for computing global properties of a shape: one function for lines, two functions for surfaces and four functions for volumes. The choice of functions depends on input parameters and algorithms used for computation (<i>BRepGProp</i> global functions),
-* a framework for computing global properties for a set of points (<i>GProp_PGProps</i>),
-* a general framework to bring together the global properties retained by several more elementary frameworks, and provide a general programming interface to consult computed global properties.
-
-Packages *GeomLProp* and *Geom2dLProp*  provide algorithms calculating the local properties of curves and surfaces
-
-A curve (for one parameter) has the following local properties: 
-- Point 
-- Derivative
-- Tangent 
-- Normal
-- Curvature
-- Center of curvature. 
-
-A surface (for two parameters U and V) has the following local properties: 
-- point
-- derivative for U and V)
-- tangent line (for U and V)
-- normal
-- max curvature 
-- min curvature 
-- main directions of curvature
-- mean curvature
-- Gaussian curvature
-
-The following methods are available:
-* *CLProps* -- calculates the local properties of a curve (tangency, curvature,normal); 
-* *CurAndInf2d* -- calculates the maximum and minimum curvatures and the inflection points of 2d curves; 
-* *SLProps* -- calculates the local properties of a surface (tangency, the normal and curvature). 
-* *Continuity* -- calculates regularity at the junction of two curves. 
-
-Note that the B-spline curve and surface are accepted but they are not cut into pieces of the desired continuity. It is the global continuity, which is seen. 
-
-@subsection occt_modat_4_4 Adaptors for Curves and Surfaces
-
-Some Open CASCADE Technology general algorithms may work theoretically on numerous types of curves or surfaces. 
-
-To do this, they simply get the services required of the analyzed  curve or surface through an interface so as to a single API,  whatever the type of curve or surface. These interfaces are called adaptors.
-
-For example, <i> Adaptor3d_Curve </i> is the abstract class which provides  the required services by an algorithm which uses any 3d curve.
-
-<i> GeomAdaptor </i> package provides interfaces:
-  * On a Geom curve;
-  * On a curve lying on a Geom surface;
-  * On a Geom surface;
-
-<i> Geom2dAdaptor</i> package provides interfaces :
-  * On a <i>Geom2d</i> curve.
-
-<i> BRepAdaptor </i> package provides interfaces:
-  * On a Face
-  * On an Edge
-
-When you write an algorithm which operates on geometric objects, use <i> Adaptor3d</i> (or <i> Adaptor2d</i>) objects. 
-
-As a result, you can use the algorithm with any kind of object, if you provide for this object an interface derived from *Adaptor3d* or *Adaptor2d*.
-These interfaces are easy to use: simply create an adapted curve or surface from a *Geom2d* curve, and then use this adapted curve as an argument for the algorithm? which requires it.
-
 
 @section occt_modat_5 Topology
 
@@ -763,39 +588,9 @@ Three additional packages provide tools to access and manipulate this abstract t
   * <i> TopTools</i> package provides basic tools to use on topological data structures.
   * <i> TopExp</i> package provides classes to explore and manipulate the topological data structures described in the TopoDS package.
   * <i> BRepTools </i> package provides classes to explore, manipulate, read and write BRep data structures. These more complex data structures combine topological descriptions with additional geometric information, and include rules for evaluating equivalence of different possible representations of the same object, for example, a point.
+ 
 
-@subsection occt_modat_5_1  Shape Location
-
-A local coordinate system can be viewed as either of the following: 
-- A right-handed trihedron with an origin and three orthonormal vectors. The *gp_Ax2* package corresponds to this definition. 
-- A transformation of a +1 determinant, allowing the transformation of coordinates between local and global references frames. This corresponds to the *gp_Trsf*. 
-
-*TopLoc* package distinguishes two notions: 
-- *TopLoc_Datum3D* class provides the elementary reference coordinate, represented by a right-handed orthonormal system of axes or by a right-handed unitary transformation. 
-- *TopLoc_Location* class provides the composite reference coordinate made from elementary ones. It is a marker composed of a chain of references to elementary markers. The resulting cumulative transformation is stored in order to avoid recalculating the sum of the transformations for the whole list. 
-
-@figure{/user_guides/modeling_data/images/modeling_data_image005.png,"Structure of TopLoc_Location",420}
-
-Two reference coordinates are equal if they are made up of the same elementary coordinates in the same order. There is no numerical comparison. Two coordinates can thus correspond to the same transformation without being equal if they were not built from the same elementary coordinates. 
-
-For example, consider three elementary coordinates: 
-R1, R2, R3 
-The composite coordinates are: 
-C1 = R1  * R2, 
-C2 = R2  * R3 
-C3 = C1  * R3 
-C4 = R1  * C2 
-
-**NOTE** C3 and C4 are equal because they are both R1 * R2 * R3.  
-
-The *TopLoc* package is chiefly targeted at the topological data structure, but it can be used for other purposes. 
-
-Change of coordinates
----------------------
-
-*TopLoc_Datum3D* class represents a change of elementary coordinates. Such changes must be shared so this class inherits from *Standard_Transient*. The coordinate is represented by a transformation *gp_Trsfpackage*. This transformation has no scaling factor. 
-
-@subsection occt_modat_5_2 Naming shapes, sub-shapes, their orientation and state
+@subsection occt_modat_5_2 Shape content
 
 The **TopAbs** package provides general enumerations describing the basic concepts of topology and methods to handle these enumerations. It contains no classes. This package has been separated from the rest of the topology because the notions it contains are sufficiently general to be used by all topological tools. This avoids redefinition of enumerations by remaining independent of modeling resources. The TopAbs package defines three notions: 
 - **Type** *TopAbs_ShapeEnum*;
@@ -879,6 +674,37 @@ The State enumeration can also be used to specify various parts of an object. Th
 
 @figure{/user_guides/modeling_data/images/modeling_data_image010.png,"State specifies the parts of an edge intersecting a face",420}
 
+@subsubsection occt_modat_5_1  Shape Location
+
+A local coordinate system can be viewed as either of the following: 
+- A right-handed trihedron with an origin and three orthonormal vectors. The *gp_Ax2* package corresponds to this definition. 
+- A transformation of a +1 determinant, allowing the transformation of coordinates between local and global references frames. This corresponds to the *gp_Trsf*. 
+
+*TopLoc* package distinguishes two notions: 
+- *TopLoc_Datum3D* class provides the elementary reference coordinate, represented by a right-handed orthonormal system of axes or by a right-handed unitary transformation. 
+- *TopLoc_Location* class provides the composite reference coordinate made from elementary ones. It is a marker composed of a chain of references to elementary markers. The resulting cumulative transformation is stored in order to avoid recalculating the sum of the transformations for the whole list. 
+
+@figure{/user_guides/modeling_data/images/modeling_data_image005.png,"Structure of TopLoc_Location",420}
+
+Two reference coordinates are equal if they are made up of the same elementary coordinates in the same order. There is no numerical comparison. Two coordinates can thus correspond to the same transformation without being equal if they were not built from the same elementary coordinates. 
+
+For example, consider three elementary coordinates: 
+R1, R2, R3 
+The composite coordinates are: 
+C1 = R1  * R2, 
+C2 = R2  * R3 
+C3 = C1  * R3 
+C4 = R1  * C2 
+
+**NOTE** C3 and C4 are equal because they are both R1 * R2 * R3.  
+
+The *TopLoc* package is chiefly targeted at the topological data structure, but it can be used for other purposes. 
+
+Change of coordinates
+---------------------
+
+*TopLoc_Datum3D* class represents a change of elementary coordinates. Such changes must be shared so this class inherits from *Standard_Transient*. The coordinate is represented by a transformation *gp_Trsfpackage*. This transformation has no scaling factor.
+
 @subsection occt_modat_5_3 Manipulating shapes and sub-shapes
 
 The *TopoDS* package describes the topological data structure with the following characteristics: 
@@ -1106,7 +932,7 @@ The following steps are performed:
   } 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-@subsection occt_modat_5_5 Lists and Maps of Shapes
+@subsubsection occt_modat_5_5 Lists and Maps of Shapes
 
 **TopTools** package contains tools for exploiting the *TopoDS* data structure. It is an instantiation of the tools from *TCollection* package with the Shape classes of *TopoDS*. 
 
@@ -1257,7 +1083,7 @@ Below is the auxiliary function, which copies the element of rank *i* from the m
   }
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-@subsubsection occt_modat_5_5_1 Wire Explorer
+**Wire Explorer**
 
 *BRepTools_WireExplorer* class can access edges of a wire in their order of connection. 
 
@@ -1277,22 +1103,180 @@ For example, in the wire in the image we want to recuperate the edges in the ord
   } 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-@subsection occt_modat_5_6 Storage of shapes
+@section occt_modat_4 Properties of Shapes
 
-*BRepTools* and *BinTools* packages contain methods *Read* and *Write* allowing to read and write a Shape to/from a stream or a file.
-The methods provided by *BRepTools* package use ASCII storage format; *BinTools* package uses binary format.
-Each of these methods has two arguments:
-- a *TopoDS_Shape* object to be read/written;
-- a stream object or a file name to read from/write to.
+@subsection occt_modat_4_1 Local Properties of Shapes
 
-The following sample code reads a shape from ASCII file and writes it to a binary one:
+<i>BRepLProp</i> package provides the Local Properties of Shapes component, 
+which contains algorithms computing various local properties on edges and faces in a BRep model.
 
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
-  TopoDS_Shape aShape;
-  if (BRepTools::Read (aShape, "source_file.txt")) {
-    BinTools::Write (aShape, "result_file.bin");
-  }
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The local properties which may be queried are:
+
+  * for a point of parameter u on a curve which supports an edge :
+    * the point,
+    * the derivative vectors, up to the third degree,
+    * the tangent vector,
+    * the normal,
+    * the curvature, and the center of curvature;
+  * for a point of parameter (u, v) on a surface which supports a face :
+    * the point,
+    * the derivative vectors, up to the second degree,
+    * the tangent vectors to the u and v isoparametric curves,
+    * the normal vector,
+    * the minimum or maximum curvature, and the corresponding directions of curvature;
+  * the degree of continuity of a curve which supports an edge, built by the concatenation of two other edges, at their junction point.
+
+Analyzed edges and faces are described as <i> BRepAdaptor</i> curves and surfaces, 
+which provide shapes with an interface for the description of their geometric support. 
+The base point for local properties is defined by its u parameter value on a curve, or its (u, v) parameter values on a surface.
+
+@subsection occt_modat_4_2 Local Properties of Curves and Surfaces
+
+The "Local Properties of Curves and Surfaces" component provides algorithms for computing various local properties on a Geom curve (in 2D or 3D space) or a surface. It is composed of:
+
+  * <i> Geom2dLProp</i> package, which allows computing Derivative and Tangent vectors (normal and curvature) of a parametric point on a 2D curve;
+  * <i> GeomLProp </i> package, which provides local properties on 3D curves and surfaces
+  * <i> LProp </i> package, which provides an enumeration used to characterize a particular point on a 2D curve.
+
+Curves are either <i> Geom_Curve </i> curves (in 3D space) or <i> Geom2d_Curve </i> curves (in the plane). 
+Surfaces are <i> Geom_Surface </i> surfaces. The point on which local properties are calculated 
+is defined by its u parameter value on a curve, and its (u,v) parameter values on a surface.
+
+It is possible to query the same local properties for points as mentioned above, and additionally for 2D curves:
+
+  * the points corresponding to a minimum or a maximum of curvature;
+  * the inflection points.
+  
+  
+#### Example: How to check the surface concavity
+
+To check the concavity of a surface, proceed as follows:
+
+  1. Sample the surface and compute at each point the Gaussian curvature.
+  2. If the value of the curvature changes of sign, the surface is concave or convex depending on the point of view.
+  3. To compute a Gaussian curvature, use the class <i> SLprops</i> from <i> GeomLProp</i>, which instantiates the generic class <i> SLProps </i>from <i> LProp</i> and use the method <i> GaussianCurvature</i>.
+
+@subsection occt_modat_4_2a Continuity of Curves and Surfaces
+
+Types of supported continuities for curves and surfaces are described in *GeomAbs_Shape* enumeration.
+
+In respect of curves, the following types of continuity are supported (see the figure below):
+  * C0 (*GeomAbs_C0*) - parametric continuity. It is the same as G0 (geometric continuity), so the last one is not represented by separate variable.
+  * G1 (*GeomAbs_G1*) - tangent vectors on left and on right are parallel.
+  * C1 (*GeomAbs_C1*) - indicates the continuity of the first derivative.
+  * G2 (*GeomAbs_G2*) - in addition to G1 continuity, the centers of curvature on left and on right are the same.
+  * C2 (*GeomAbs_C2*) - continuity of all derivatives till the second order.
+  * C3 (*GeomAbs_C3*) - continuity of all derivatives till the third order.
+  * CN (*GeomAbs_CN*) - continuity of all derivatives till the N-th order (infinite order of continuity).
+
+*Note:* Geometric continuity (G1, G2) means that the curve can be reparametrized to have parametric (C1, C2) continuity.
+
+@figure{/user_guides/modeling_data/images/modeling_data_continuity_curves.svg,"Continuity of Curves",420}
+
+The following types of surface continuity are supported:
+  * C0 (*GeomAbs_C0*) - parametric continuity (the surface has no points or curves of discontinuity).
+  * G1 (*GeomAbs_G1*) - surface has single tangent plane in each point.
+  * C1 (*GeomAbs_C1*) - indicates the continuity of the first derivatives.
+  * G2 (*GeomAbs_G2*) - in addition to G1 continuity, principal curvatures and directions are continuous.
+  * C2 (*GeomAbs_C2*) - continuity of all derivatives till the second order.
+  * C3 (*GeomAbs_C3*) - continuity of all derivatives till the third order.
+  * CN (*GeomAbs_CN*) - continuity of all derivatives till the N-th order (infinite order of continuity).
+
+@figure{/user_guides/modeling_data/images/modeling_data_continuity_surfaces.svg,"Continuity of Surfaces",420}
+
+Against single surface, the connection of two surfaces (see the figure above) defines its continuity in each intersection point only. Smoothness of connection is a minimal value of continuities on the intersection curve.
+
+
+@subsection occt_modat_4_2b Regularity of Shared Edges
+
+Regularity of an edge is a smoothness of connection of two faces sharing this edge. In other words, regularity is a minimal continuity between connected faces in each point on edge.
+
+Edge's regularity can be set by *BRep_Builder::Continuity* method. To get the regularity use *BRep_Tool::Continuity* method.
+
+Some algorithms like @ref occt_modalg_6 "Fillet" set regularity of produced edges by their own algorithms. On the other hand, some other algorithms (like @ref specification__boolean_operations "Boolean Operations", @ref occt_user_guides__shape_healing "Shape Healing", etc.) do not set regularity. If the regularity is needed to be set correctly on a shape, the method *BRepLib::EncodeRegularity* can be used. It calculates and sets correct values for all edges of the shape.
+
+The regularity flag is extensively used by the following high level algorithms: @ref occt_modalg_6_1_2 "Chamfer", @ref occt_modalg_7_3 "Draft Angle", @ref occt_modalg_10 "Hidden Line Removal", @ref occt_modalg_9_2 "Gluer".
+
+  
+@subsection occt_modat_4_3 Global Properties of Shapes
+
+The Global Properties of Shapes component provides algorithms for computing the global 
+properties of a composite geometric system in 3D space, and frameworks to query the computed results.
+
+The global properties computed for a system are :
+  * mass,
+  * mass center,
+  * matrix of inertia,
+  * moment about an axis,
+  * radius of gyration about an axis,
+  * principal properties of inertia such as principal axis, principal moments, and principal radius of gyration.
+
+Geometric systems are generally defined as shapes. Depending on the way they are analyzed, these shapes will give properties of:
+
+  * lines induced from the edges of the shape,
+  * surfaces induced from the faces of the shape, or
+  * volumes induced from the solid bounded by the shape.
+
+The global properties of several systems may be brought together to give the global properties of the system composed of the sum of all individual systems.
+
+The Global Properties of Shapes component is composed of:
+* seven functions for computing global properties of a shape: one function for lines, two functions for surfaces and four functions for volumes. The choice of functions depends on input parameters and algorithms used for computation (<i>BRepGProp</i> global functions),
+* a framework for computing global properties for a set of points (<i>GProp_PGProps</i>),
+* a general framework to bring together the global properties retained by several more elementary frameworks, and provide a general programming interface to consult computed global properties.
+
+Packages *GeomLProp* and *Geom2dLProp*  provide algorithms calculating the local properties of curves and surfaces
+
+A curve (for one parameter) has the following local properties: 
+- Point 
+- Derivative
+- Tangent 
+- Normal
+- Curvature
+- Center of curvature. 
+
+A surface (for two parameters U and V) has the following local properties: 
+- point
+- derivative for U and V)
+- tangent line (for U and V)
+- normal
+- max curvature 
+- min curvature 
+- main directions of curvature
+- mean curvature
+- Gaussian curvature
+
+The following methods are available:
+* *CLProps* -- calculates the local properties of a curve (tangency, curvature,normal); 
+* *CurAndInf2d* -- calculates the maximum and minimum curvatures and the inflection points of 2d curves; 
+* *SLProps* -- calculates the local properties of a surface (tangency, the normal and curvature). 
+* *Continuity* -- calculates regularity at the junction of two curves. 
+
+Note that the B-spline curve and surface are accepted but they are not cut into pieces of the desired continuity. It is the global continuity, which is seen. 
+
+@subsection occt_modat_4_4 Adaptors for Curves and Surfaces
+
+Some Open CASCADE Technology general algorithms may work theoretically on numerous types of curves or surfaces. 
+
+To do this, they simply get the services required of the analyzed  curve or surface through an interface so as to a single API,  whatever the type of curve or surface. These interfaces are called adaptors.
+
+For example, <i> Adaptor3d_Curve </i> is the abstract class which provides  the required services by an algorithm which uses any 3d curve.
+
+<i> GeomAdaptor </i> package provides interfaces:
+  * On a Geom curve;
+  * On a curve lying on a Geom surface;
+  * On a Geom surface;
+
+<i> Geom2dAdaptor</i> package provides interfaces :
+  * On a <i>Geom2d</i> curve.
+
+<i> BRepAdaptor </i> package provides interfaces:
+  * On a Face
+  * On an Edge
+
+When you write an algorithm which operates on geometric objects, use <i> Adaptor3d</i> (or <i> Adaptor2d</i>) objects. 
+
+As a result, you can use the algorithm with any kind of object, if you provide for this object an interface derived from *Adaptor3d* or *Adaptor2d*.
+These interfaces are easy to use: simply create an adapted curve or surface from a *Geom2d* curve, and then use this adapted curve as an argument for the algorithm? which requires it.
 
 @section occt_modat_6 Bounding boxes
 

dox/user_guides/step/step.md

@@ -1,4 +1,4 @@
-STEP processor  {#occt_user_guides__step}
+STEP Translator  {#occt_user_guides__step}
 ========================
 
 @tableofcontents
@@ -22,9 +22,7 @@ File translation is performed in the programming mode, via C++ calls.
 
 @ref occt_user_guides__shape_healing "Shape Healing" toolkit provides tools to heal various problems, which may be encountered in translated shapes, and to make them valid in Open CASCADE. The Shape Healing is smoothly connected to STEP translator using the same API, only the names of API packages change.
 
-For testing the STEP component in DRAW Test Harness, a set of commands for reading and writing STEP files and analysis of relevant data are provided by the *TKXSDRAW* plugin. 
-
-See also our <a href="https://www.opencascade.com/content/tutorial-learning">E-learning & Training</a> offerings.
+For testing the STEP component in DRAW Test Harness, a set of commands for reading and writing STEP files and analysis of relevant data are provided by the *TKXSDRAW* plugin.
 
 @subsection occt_step_1_1 STEP Exchanges in Open Cascade technology
 

dox/user_guides/tobj/tobj.md

@@ -1,910 +0,0 @@
-TObj Package  {#occt_user_guides__tobj}
-==================
-
-@tableofcontents
-
-@section occt_tobj_1 Introduction
-
-This document describes the package TObj, which is an add-on 
-to the Open CASCADE Application Framework (OCAF).
-
-This package provides a set of classes and auxiliary tools facilitating 
-the creation of object-oriented data models on top of low-level OCAF data structures. 
-This includes: 
-
-  * Definition of classes representing data objects. Data objects store their data using primitive OCAF attributes, taking advantage of OCAF mechanisms for Undo/Redo and persistence. At the same time they provide a higher level abstraction over the pure OCAF document structure (labels / attributes).
-  * Organization of the data model as a hierarchical (tree-like) structure of objects.
-  * Support of cross-references between objects within one model or among different models. In case of cross-model references the models should depend hierarchically.
-  * Persistence mechanism for storing *TObj* objects in OCAF files, which allows storing and retrieving objects of derived types without writing additional code to support persistence. 
-
-This document describes basic principles of logical and physical organization 
-of TObj-based data models and typical approaches to implementation of classes representing model objects.
-
-@subsection occt_tobj_1_1 Applicability
-
-The main purpose of the *TObj* data model is rapid development 
-of the object-oriented data models for applications, using the existing 
-functionality provided by OCAF (Undo/Redo and persistence) 
-without the necessity to redevelop such functionality from scratch.
-
-As opposed to using bare OCAF (at the level of labels and attributes), 
-TObj facilitates dealing with higher level abstracts, which are closer 
-to the application domain. It works best when the application data are naturally 
-organized in hierarchical structures, and is especially useful for complex data 
-models with dependencies between objects belonging to different parts of the model.
-
-It should be noted that *TObj* is efficient for representing data structures containing 
-a limited number of objects at each level of the data structure (typically less than 1000).
-A greater number of objects causes performance problems due to list-based organization of OCAF documents. Therefore, other methods of storage, such as arrays, are advisable for data models or their sub-parts containing a great number of uniform objects. However, these methods 
-can be combined with the usage of *TObj* to represent the high-level structure of the model.
-
-@section occt_tobj_2 TObj Model
-
-@subsection occt_tobj_2_1 TObj Model structure
-
-In the *TObj* data model the data are separated from the interfaces that manage them.
-
-It should be emphasized that *TObj* package defines only the interfaces and the basic structure of the model and objects, while the actual contents and structure of the model of a particular application are defined by its specific classes inherited from *TObj* classes. The implementation can add its own features or even change the default behaviour and the data layout, though this is not recommended. 
-
-Logically the *TObj* data model is represented as a tree of model objects, with upper-level objects typically being collections of other objects (called *partitions*, represented by the class *TObj_Partition*). The root object of the model is called the *Main partition* and is maintained by the model itself. This partition contains a list of sub-objects called its *children* each sub-object may contain its own children (according to its type), etc. 
-
-@figure{/user_guides/tobj/images/tobj_image003.png,"TObj Data Model",240}
-
-As the *TObj* Data Model is based on OCAF (Open CASCADE Application Framework) technology, 
-it stores its data in the underlying OCAF document. The OCAF document consists of a tree of 
-items called *labels*. Each label has some data attached to it in the form of *attributes*, 
-and may contain an arbitrary number of sub-labels. Each sub-label is identified by its sequential 
-number called the *tag*. The complete sequence of tag numbers of the label 
-and its parents starting from the document root constitutes the complete *entry* 
-of the label, which uniquely identifies its position in the document.
-
-Generally the structure of the OCAF tree of the *TObj* data 
-model corresponds to the logical structure of the model and can be presented as in the following picture: 
-
-@figure{/user_guides/tobj/images/tobj_image004.png,"TObj Data Model mapped on OCAF document",360}
-
-All data of the model are stored in the root label (0:1) of the OCAF document. 
-An attribute *TObj_TModel* is located in this root label. It 
-stores the object of type *TObj_Model*. This object serves as a main interface tool 
-to access all data and functionalities of the data model.
-
-In simple cases all data needed by the application may be 
-contained in a single data model. Moreover, *TObj* gives the possibility to 
-distribute the data between several interconnected data models. This can be 
-especially useful for the applications dealing with great amounts of data. because 
-only the data required for the current operation is loaded in the memory at one time. 
-It is presumed that the models have a hierarchical (tree-like) structure, 
-where the objects of the child models can refer to the objects of the parent 
-models, not vice-versa. Provided that the correct order of loading and closing 
-of the models is ensured, the *TObj* classes will maintain references between the objects automatically.
-
-@subsection occt_tobj_2_2 Data Model basic features
-
-The class *TObj_Model* describing the data model provides the following functionalities: 
-
-  * Loading and saving of the model from or in a file (methods *Load* and *Save*)
-  * Closing and removal of the model from memory (method *Close*)
-  * Definition of the full file name of the persistence storage for this model (method *GetFile*)
-  * Tools to organize data objects in partitions and iterate on objects (methods *GetObjects*, *GetMainPartition*, *GetChildren*, *getPartition*, *getElementPartition*)
-  * Mechanism to give unique names to model objects 
-  * Copy (*clone*) of the model (methods *NewEmpty* and *Paste*)
-  * Support of earlier model formats for proper conversion of a model loaded from a file written by a previous version of the application (methods *GetFormatVersion* and *SetFormatVersion*)
-  * Interface to check and update the model if necessary (method *Update*)
-  * Support of several data models in one application. For this feature use OCAF multi-transaction manager, unique names and GUIDs of the data model (methods *GetModelName*, *GetGUID*)
-
-@subsection occt_tobj_2_3 Model Persistence
-
-The persistent representation of any OCAF model is contained in an XML or a binary file, 
-which is defined by the format string returned by the method *GetFormat*. 
-The default implementation works with a binary OCAF document format (*BinOcaf*). 
-The other available format is *XmlOcaf*. The class **TObj_Model** declares and provides a default 
-implementation of two virtual methods: 
-
-~~~~~{.cpp}
-    virtual Standard_Boolean Load (const char* theFile); 
-    virtual Standard_Boolean SaveAs (const char* theFile); 
-~~~~~
-
-which retrieve and store the model from or 
-in the OCAF file. The descendants 
-should define the following protected method to support Load and Save operations:
-
-~~~~~{.cpp}
-    virtual Standard_Boolean initNewModel (const Standard_Boolean IsNew); 
-~~~~~
-
-This method is called by *Load* after creation of a new model 
-or after its loading from the file; its purpose is to perform 
-the necessary initialization of the model (such as creation of necessary top-level 
-partitions, model update due to version changes etc.). Note that if 
-the specified file does not exist, method *Load* will create 
-a new document and call *initNewModel* with the argument **True**. 
-If the file has been normally loaded, the argument **False** is passed. 
-Thus, a new empty *TObj* model is created by calling *Load* with an empty 
-string or the path to a nonexistent file as argument. 
-
-The method *Load* returns **True** if the model has been retrieved successfully 
-(or created a new), or **False** if the model could not be loaded. 
-If no errors have been detected during initialization (model retrieval or creation),
-the virtual method *AfterRetrieval* is invoked for all objects of the model. 
-This method initializes or updates the objects immediately after the model initialization. 
-It could be useful when some object data should be imported from an OCAF attribute into transient 
-fields which could be changed outside of the OCAF transaction mechanism. 
-Such fields can be stored into OCAF attributes for saving into persistent storage during the save operation.
-
-To avoid memory leaks, the *TObj_Model* class destructor invokes *Close* method 
-which clears the OCAF document and removes all data from memory before the model is destroyed.
-
-For XML and binary persistence of the *TObj* data model the corresponding drivers are implemented 
-in *BinLDrivers*, *BinMObj* and *XmlLDrivers*, *XmlMObj* packages. 
-These packages contain retrieval and storage drivers for the model, model objects and custom attributes 
-from the *TObj* package. The schemas support persistence for the standard OCAF and *TObj* attributes. 
-This is sufficient for the implementation of simple data models, but 
-in some cases it can be reasonable to add specific OCAF attributes to 
-facilitate the storage of the data specific to the application. 
-In this case the schema should be extended using the standard OCAF mechanism. 
-
-@subsection occt_tobj_2_4 Access to the objects in the model
-
-All objects in the model are stored in the main partition and accessed by iterators.
-To access all model objects use: 
-
-~~~~~{.cpp}
-    virtual Handle(TObj_ObjectIterator) GetObjects () const; 
-~~~~~
-
-This method returns a recursive iterator on all objects stored in the model.
-
-~~~~~{.cpp}
-    virtual Handle(TObj_ObjectIterator) GetChildren () const; 
-~~~~~
-
-This method returns an iterator on child objects of the main partition.
-Use the following method to get the main partition: 
-
-~~~~~{.cpp}
-    Handle(TObj_Partition) GetMainPartition() const; 
-~~~~~
-
-To receive the iterator on objects of a specific type *AType* use the following call: 
-
-~~~~~{.cpp}
-    GetMainPartition()->GetChildren(STANDARD_TYPE(AType) ); 
-~~~~~
-
-The set of protected methods is provided for descendant classes to deal with partitions: 
-
-~~~~~{.cpp}
-    virtual Handle(TObj_Partition) getPartition (const TDF_Label, const Standard_Boolean  theHidden) const; 
-~~~~~
-
-This method returns (creating if necessary) a partition in the specified label of the document. 
-The partition can be created as hidden (*TObj_HiddenPartition* class). 
-A hidden partition can be useful to distinguish the data that 
-should not be visible to the user when browsing the model in the application. 
-
-The following two methods allow getting (creating) a partition 
-in the sub-label of the specified label in the document 
-(the label of the main partition for the second method) and with the given name: 
-
-~~~~~{.cpp}
-    virtual Handle(TObj_Partition) getPartition (const TDF_Label, const Standard_Integer theIndex, const TCollection_ExtendedString& theName, const Standard_Boolean  theHidden) const; 
-    virtual Handle(TObj_Partition) getPartition (const Standard_Integer theIndex, const TCollection_ExtendedString& theName, const Standard_Boolean  theHidden) const; 
-~~~~~
-
-If the default object naming and the name register mechanism 
-is turned on, the object can be found in the model by its unique name: 
-
-~~~~~{.cpp}
-    Handle(TObj_Object) FindObject (const Handle(TCollection_HExtendedString)& theName, const Handle(TObj_TNameContainer)& theDictionary) const; 
-~~~~~
-
-@subsection occt_tobj_2_5 Own model data
-
-The model object can store its own data in the Data label 
-of its main partition, however, there is no standard API for 
-setting and getting these data types. The descendants can add 
-their own data using standard OCAF methods. The enumeration DataTag is defined 
-in *TObj_Model* to avoid conflict of data labels used by this class 
-and its descendants, similarly to objects (see below). 
-
-@subsection occt_tobj_2_6 Object naming
-
-The basic implementation of *TObj_Model* provides the default 
-naming mechanism: all objects must have unique names, 
-which are registered automatically in the data model dictionary. 
-The dictionary is a *TObj_TNameContainer* 
-attribute whose instance is located in the model root label.
-If necessary, the developer can add several dictionaries into 
-the specific partitions, providing the name registration in the 
-correct name dictionary and restoring the name map after document is loaded from file.
-To ignore name registering it is necessary to redefine the methods *SetName*, 
-*AfterRetrieval* of the *TObj_Object* class and skip the registration of the object name. 
-Use the following methods for the naming mechanism: 
-
-~~~~~{.cpp}
-    Standard_Boolean IsRegisteredName (const Handle(TCollection_HExtendedString)& theName, const Handle(TObj_TNameContainer)& theDictionary ) const; 
-~~~~~
-
-Returns **True** if the object name is already registered in the indicated (or model) dictionary. 
-
-~~~~~{.cpp}
-    void RegisterName (const Handle(TCollection_HExtendedString)& theName, const TDF_Label& theLabel, const Handle(TObj_TNameContainer)& theDictionary ) const; 
-~~~~~
-
-Registers the object name with the indicated label where the object 
-is located in the OCAF document. Note that the default implementation 
-of the method *SetName* of the object registers the new name automatically 
-(if the name is not yet registered for any other object) 
-
-~~~~~{.cpp}
-    void UnRegisterName (const Handle(TCollection_HExtendedString)& theName, const Handle(TObj_TNameContainer)& theDictionary ) const; 
-~~~~~
-
-Unregisters the name from the dictionary. Ther names of *TObj* model 
-objects are removed from the dictionary when the objects are deleted from the model. 
-
-~~~~~{.cpp}
-    Handle(TObj_TNameContainer) GetDictionary() const;
-~~~~~
-
-Returns a default instance of the model dictionary (located at the model root label). 
-The default implementation works only with one dictionary. 
-If there are a necessity to have more than one dictionary for the model objects, 
-it is recommended to redefine the corresponding virtual method of TObj_Object 
-that returns the dictionary where names of objects should be registered.
-
-@subsection occt_tobj_2_7 API for transaction mechanism
-
-Class *TObj_Model* provides the API for transaction mechanism (supported by OCAF): 
-
-~~~~~{.cpp}
-    Standard_Boolean HasOpenCommand() const; 
-~~~~~
-
-Returns True if a Command transaction is open 
-
-~~~~~{.cpp}
-    void OpenCommand() const; 
-~~~~~
-
-Opens a new command transaction. 
-
-~~~~~{.cpp}
-    void CommitCommand() const; 
-~~~~~
-
-Commits the Command transaction. Does nothing If there is no open Command transaction. 
-
-~~~~~{.cpp}
-    void AbortCommand() const; 
-~~~~~
-
-Aborts the Command transaction. Does nothing if there is no open Command transaction. 
-
-~~~~~{.cpp}
-    Standard_Boolean IsModified() const; 
-~~~~~
-
-Returns True if the model document has a modified status (has changes after the last save) 
-
-~~~~~{.cpp}
-    void SetModified( const Standard_Boolean ); 
-~~~~~
-
-Changes the modified status by force. For synchronization of transactions 
-within several *TObj_Model* documents use class *TDocStd_MultiTransactionManager*. 
-
-@subsection occt_tobj_28 Model format and version
-
-Class *TObj_Model* provides the descendant classes with a means to control 
-the format of the persistent file by choosing the schema used to store or retrieve operations. 
-
-~~~~~{.cpp}
-    virtual TCollection_ExtendedString GetFormat () const; 
-~~~~~
-
-Returns the string *TObjBin* or *TObjXml* indicating 
-the current persistent mechanism. The default value is *TObjBin*. 
-Due to the evolution of functionality of the developed application, 
-the contents and the structure of its data model vary from version to version. 
-*TObj* package provides a basic mechanism supporting backward versions compatibility, 
-which means that newer versions of the application will be able to read 
-Data Model files created by previous versions (but not vice-versa) with a minimum loss of data. 
-For each type of Data Model, all known versions of the data format 
-should be enumerated in increasing order, incremented with every change 
-of the model format. The current version of the model 
-format is stored in the model file and can be checked upon retrieval. 
-
-~~~~~{.cpp}
-    Standard_Integer GetFormatVersion() const; 
-~~~~~
-
-Returns the format version stored in the model file 
-
-~~~~~{.cpp}
-    void SetFormatVersion(const Standard_Integer theVersion); 
-~~~~~
-
-Defines the format version used for save. 
-
-Upon loading a model, the method *initNewModel()*, called immediately 
-after opening a model from disk (on the level of the OCAF document), 
-provides a specific code that checks the format version stored in that model. 
-If it is older than the current version of the application, the data update can be performed. 
-Each model can have its own specific conversion code 
-that performs the necessary data conversion to make them compliant with the current version. 
-
-When the conversion ends the user is advised of that by the messenger interface 
-provided by the model (see messaging chapter for more details), 
-and the model version is updated. If the version of data model is not supported 
-(it is newer than the current or too old), the load operation should fail. 
-The program updating the model after version change can be implemented as static 
-methods directly in C++ files of the corresponding Data Model classes, 
-not exposing it to the other parts of the application. 
-These codes can use direct access to the model and objects data (attributes) 
-not using objects interfaces, because the data model API and object classes 
-could have already been changed. 
-
-Note that this mechanism has been designed to maintain version compatibility 
-for the changes of data stored in the model, not for the changes of 
-low-level format of data files (such as the storage format of a specific OCAF attribute). 
-If the format of data files changes, a specific treatment on a case-by-case basis will be required. 
-
-@subsection occt_tobj_2_9 Model update
-
-The following methods are used for model update to ensure its consistency 
-with respect to the other models in case of cross-model dependencies: 
-
-~~~~~{.cpp}
-    virtual Standard_Boolean Update(); 
-~~~~~
-
-This method is usually called after loading of the model. 
-The default implementation does nothing and returns **True**. 
-
-~~~~~{.cpp}
-    virtual Standard_Boolean initNewModel( const Standard_Boolean IsNew); 
-~~~~~
-
-This method performs model initialization, check and updates (as described above). 
-
-~~~~~{.cpp}
-    virtual void updateBackReferences( const Handle(TObj_Object)& theObj); 
-~~~~~
-
-This method is called from the previous method to update back references 
-of the indicated object after the retrieval of the model from file 
-(see data model - object relationship chapter for more details) 
-
-@subsection occt_tobj_2_10 Model copying
-
-To copy the model between OCAF documents use the following methods: 
-
-~~~~~{.cpp}
-    virtual Standard_Boolean Paste (Handle(TObj_Model) theModel, Handle(TDF_RelocationTable) theRelocTable = 0 ); 
-~~~~~
-
-Pastes the current model to the new model. The relocation table 
-ensures correct copying of the sub-data shared by several parts of the model. 
-It stores a map of processed original objects of relevant types in their copies. 
-
-~~~~~{.cpp}
-    virtual Handle(TObj_Model) NewEmpty() = 0; 
-~~~~~
-
-Redefines a pure virtual method to create a new empty instance of the model. 
-
-~~~~~{.cpp}
-    void CopyReferences ( const Handle(TObj_Model)& theTarget, const Handle(TDF_RelocationTable)& theRelocTable); 
-~~~~~
-
-Copies the references from the current model to the target model. 
-
-@subsection occt_tobj_2_11 Messaging
-
-The messaging is organised using Open CASCADE Messenger from the package Message. 
-The messenger is stored as the field of the model instance 
-and can be set and retrieved by the following methods: 
-
-~~~~~{.cpp}
-    void SetMessenger( const Handle(Message_Messenger)& ); 
-    Handle(Message_Messenger) Messenger() const; 
-~~~~~
-
-A developer should create his own instance of the Messenger 
-bound to the application user interface, and attribute it to the model 
-for future usage. In particular the messenger is used for reporting 
-errors and warnings in the persistence mechanism. 
-Each message has a unique string identifier (key). 
-All message keys are stored in a special resource file TObj.msg. 
-This file should be loaded at the start of the application 
-by call to the appropriate method of the class *Message_MsgFile*. 
-
-@section occt_tobj_3 Model object
-
-Class *TObj_Object* provides basic interface and default implementation 
-of important features of *TObj* model objects. This implementation defines 
-basic approaches that are recommended for all descendants, 
-and provides tools to facilitate their usage. 
-
-@figure{/user_guides/tobj/images/tobj_image005.png,"TObj objects hierarchy",170}
-
-@subsection occt_tobj_3_1 Separation of data and interface
-
-In the *TObj* data model, the data are separated from the interfaces that manage them. 
-The data belonging to a model object are stored in its root label and sub-labels 
-in the form of standard OCAF attributes. This allows using standard OCAF mechanisms 
-for work with these data, and eases the implementation of the persistence mechanism. 
-
-The instance of the interface which serves as an API for managing object data 
-(e.g. represents the model object) is stored in the root label of the object, 
-and typically does not bring its own data. The interface classes are organized in a hierarchy 
-corresponding to the natural hierarchy of the model objects according to the application. 
-
-In the text below the term 'object' is used to denote either the instance 
-of the interface class or the object itself (both interface and data stored in OCAF). 
-
-The special type of attribute *TObj_TObject* is used for storing instances of objects interfaces 
-in the OCAF tree. *TObj_TObject* is a simple container for the object of type *TObj_Object*. 
-All objects (interfaces) of the data model  inherit this class. 
-
-@figure{/user_guides/tobj/images/tobj_image006.png,"TObj object stored on OCAF label",360}
-
-
-@subsection occt_tobj_3_2 Basic features
-
-The *TObj_Object* class provides some basic features that can be inherited (or, if necessary, redefined) by the descendants: 
-
-  * Gives access to the model to which the object belongs (method *GetModel*) and to the OCAF label in which the object is stored (method *GetLabel*). 
-  * Supports references (and back references) to other objects in the same or in another model (methods *getReference*, *setReference*, *addReference*, *GetReferences*, *GetBackReferences*, *AddBackReference*, *RemoveBackReference*, *ReplaceReference*)
-  * Provides the ability to contain child objects, as it is actual for partition objects (methods *GetChildren*, *GetFatherObject*)
-  * Organizes its data in the OCAF structure by separating the sub-labels of the main label intended for various kinds of data and providing tools to organize these data (see <a href="../../../../Documents%20and%20Settings/TEMP/obj-inher">below</a>). The kinds of data stored separately are: 
-	  * Child objects stored in the label returned by the method *GetChildLabel* 
-	  * References to other objects stored in the label returned by the method *GetReferenceLabel* 
-	  * Other data, both common to all objects and specific for each subtype of the model object, are stored in the label returned by the method *GetDataLabel* 
-  * Provides unique names of all objects in the model (methods *GetDictionary*, *GetName*, *SetName*)
-  * Provides unified means to maintain persistence (implemented in descendants with the help of macros *DECLARE_TOBJOCAF_PERSISTENCE* and *IMPLEMENT_TOBJOCAF_PERSISTENCE*)
-  * Allows an object to remove itself from the OCAF document and check the depending objects can be deleted according to the  back references (method *Detach*)
-  * Implements methods for identification and versioning of objects 
-  * Manages the object interaction with OCAF Undo/Redo mechanism (method *IsAlive*, *AfterRetrieval*, *BeforeStoring*)
-  * Allows make a clone (methods *Clone*, *CopyReferences*, *CopyChildren*, *copyData*)
-  * Contains additional word of bit flags (methods *GetFlags*, *SetFlags*, *TestFlags*, *ClearFlags*)
-  * Defines the interface to sort the objects by rank (methods *GetOrder*, *SetOrder*)
-  * Provides a number of auxiliary methods for descendants to set/get the standard attribute values, such as int, double, string, arrays etc.
-
-An object can be received from the model by the following methods: 
-
-~~~~~{.cpp}
-    static Standard_Boolean GetObj ( const TDF_Label& theLabel, Handle(TObj_Object)& theResObject, const Standard_Boolean isSuper = Standard_False ); 
-~~~~~
-
-Returns *True* if the object has been found in the indicated label (or in the upper level label if *isSuper* is *True*). 
-
-~~~~~{.cpp}
-    Handle(TObj_Object) GetFatherObject ( const Handle(Standard_Type)& theType = NULL ) const; 
-~~~~~
-
-Returns the father object of the indicated type 
-for the current object (the direct father object if the type is NULL). 
-
-@subsection occt_tobj_3_3 Data layout and inheritance
-
-As far as the data objects are separated from the interfaces and stored in the OCAF tree, 
-the functionality to support inheritance is required. Each object has its own data 
-and references stored in the labels in the OCAF tree. All data are stored in the sub-tree 
-of the main object label. If it is necessary to inherit a class from the base class, 
-the descendant class should use different labels for data and references than its ancestor. 
-
-Therefore each *TObj* class can reserve the range of tags in each of 
-*Data*, *References*, and *Child* sub-labels. 
-The reserved range is declared by the enumeration defined 
-in the class scope (called DataTag, RefTag, and ChildTag, respectively). 
-The item *First* of the enumeration of each type is defined via the *Last* item 
-of the corresponding enumeration of the parent class, thus ensuring that the tag numbers 
-do not overlap. The item *Last* of the enumeration defines the last tag reserved by this class. 
-Other items of the enumeration define the tags used for storing particular data items of the object. 
-See the declaration of the TObj_Partition class for the example. 
-
-*TObj_Object* class provides a set of auxiliary methods for descendants 
-to access the data stored in sub-labels by their tag numbers: 
-
-~~~~~{.cpp}
-    TDF_Label getDataLabel (const Standard_Integer theRank1, const Standard_Integer theRank2 = 0) const; 
-    TDF_Label getReferenceLabel (const Standard_Integer theRank1, const Standard_Integer theRank2 = 0) const; 
-~~~~~
-
-Returns the label in *Data* or *References* sub-labels at a given tag number (theRank1). 
-The second argument, theRank2, allows accessing the next level of hierarchy 
-(theRank2-th sub-label of theRank1-th data label). 
-This is useful when the data to be stored are represented by multiple OCAF attributes 
-of the same type (e.g. sequences of homogeneous data or references). 
-
-The get/set methods allow easily accessing the data located in the specified data label 
-for the most widely used data types (*Standard_Real*, *Standard_Integer*, *TCollection_HExtendedString*,
- *TColStd_HArray1OfReal*, *TColStd_HArray1OfInteger*, *TColStd_HArray1OfExtendedString*). 
-For instance, methods provided for real numbers are: 
-
-~~~~~{.cpp}
-    Standard_Real getReal (const Standard_Integer theRank1, const Standard_Integer theRank2 = 0) const; 
-    Standard_Boolean setReal (const Standard_Real theValue, const Standard_Integer theRank1, const Standard_Integer theRank2 = 0, const Standard_Real theTolerance = 0.) const; 
-~~~~~
-
-Similar methods are provided to access references to other objects: 
-
-~~~~~{.cpp}
-    Handle(TObj_Object) getReference (const Standard_Integer theRank1, const Standard_Integer theRank2 = 0) const; 
-    Standard_Boolean setReference (const Handle(TObj_Object) &theObject, const Standard_Integer theRank1, const Standard_Integer theRank2 = 0); 
-~~~~~
-
-The method *addReference* gives an easy way to store a sequence of homogeneous references in one label. 
-
-~~~~~{.cpp}
-    TDF_Label addReference (const Standard_Integer theRank1, const Handle(TObj_Object) &theObject); 
-~~~~~
-
-Note that while references to other objects should be defined by descendant classes 
-individually according to the type of object, *TObj_Object* provides methods 
-to manipulate (check, remove, iterate) the existing references in the uniform way, as described below. 
-
-@subsection occt_tobj_3_4 Persistence
-
-The persistence of the *TObj* Data Model is implemented with the help 
-of standard OCAF mechanisms (a schema defining necessary plugins, drivers, etc.). 
-This implies the possibility to store/retrieve all data that are stored 
-as standard OCAF attributes., The corresponding handlers are added 
-to the drivers for *TObj*-specific attributes. 
-
-The special tool is provided for classes inheriting from *TObj_Object* 
-to add the new types of persistence without regeneration of the OCAF schema. 
-The class *TObj_Persistence* provides basic means for that: 
-
-  * automatic run-time registration of object types
-  * creation of a new object of the specified type (one of the registered types) 
-
-Two macros defined in the file TObj_Persistence.hxx have to be included in the definition 
-of each model object class inheriting TObj_Object to activate the persistence mechanism: 
-
-~~~~~{.cpp}
-    DECLARE_TOBJOCAF_PERSISTENCE (classname, ancestorname) 
-~~~~~
-
-Should be included in the private section of declaration of each class inheriting 
-*TObj_Object* (hxx file). This macro adds an additional constructor to the object class, 
-and declares an auxiliary (private) class inheriting *TObj_Persistence* 
-that provides a tool to create a new object of the proper type. 
-
-~~~~~{.cpp}
-    IMPLEMENT_TOBJOCAF_PERSISTENCE (classname) 
-~~~~~
-
-Should be included in .cxx file of each object class that should be saved and restored. 
-This is not needed for abstract types of objects. This macro implements the functions 
-declared by the previous macro and creates a static member 
-that automatically registers that type for persistence. 
-
-When the attribute *TObj_TObject* that contains the interface object is saved, 
-its persistence handler stores the runtime type of the object class. 
-When the type is restored the handler dynamically recognizes the type 
-and creates the corresponding object using mechanisms provided by *TObj_Persistence*. 
-
-@subsection occt_tobj_3_5 Names of objects
-
-All *TObj* model objects  have names by which the user can refer to the object. 
-Upon creation, each object receives a default name, constructed 
-from the prefix corresponding to the object type (more precisely, the prefix is defined 
-by the partition to which the object belongs), and the index of the object in the current partition. 
-The user has the possibility to change this name. The uniqueness of the name in the model is ensured 
-by the naming mechanism (if the name is already used, it cannot be attributed to another object). 
-This default implementation of *TObj* package works with a single instance of the name container (dictionary) 
-for name registration of objects and it is enough in most simple projects. 
-If necessary, it is easy to redefine a couple of object methods 
-(for instance *GetDictionary*()) and to take care of  construction and initialization of containers. 
-
-This functionality is provided by the following methods: 
-
-~~~~~{.cpp}
-    virtual Handle(TObj_TNameContainer) GetDictionary() const; 
-~~~~~
-
-Returns the name container where the name of object should be registered. 
-The default implementation returns the model name container. 
-
-~~~~~{.cpp}
-    Handle(TCollection_HExtendedString) GetName() const; 
-    Standard_Boolean GetName( TCollection_ExtendedString& theName ) const; 
-    Standard_Boolean GetName( TCollection_AsciiString& theName ) const; 
-~~~~~
-
-Returns the object name. The methods with in / out argument return False if the object name is not defined. 
-
-~~~~~{.cpp}
-    virtual Standard_Boolean SetName ( const Handle(TCollection_HExtendedString)& theName ) const; 
-    Standard_Boolean SetName         ( const Handle(TCollection_HAsciiString)& theName ) const; 
-    Standard_Boolean SetName         ( const Standard_CString theName ) const; 
-~~~~~
-
-Attributes a new name to the object and returns **True** if the name has been attributed successfully. 
-Returns False if the name has been already attributed to another object. 
-The last two methods are short-cuts to the first one. 
-
-@subsection occt_tobj_3_6 References between objects 
-
-Class *TObj_Object* allows creating references to other objects in the model. 
-Such references describe relations among objects which are not adequately reflected 
-by the hierarchical objects structure in the model (parent-child relationship). 
-
-The references are stored internally using the attribute TObj_TReference. 
-This attribute is located in the sub-label of the referring object (called *master*) 
-and keeps reference to the main label of the referred object. 
-At the same time the referred object can maintain the back reference to the master object. 
-
-@figure{/user_guides/tobj/images/tobj_image007.png,"Objects relationship",360}
-
-
-
-The back references are stored not in the OCAF document but as a transient field 
-of the object; they are created when the model is restored from file, 
-and updated automatically when the references are manipulated. 
-The class *TObj_TReference* allows storing references between objects 
-from different *TObj* models, facilitating the construction of complex relations between objects. 
-
-The most used methods for work with references are: 
-
-~~~~~{.cpp}
-    virtual Standard_Boolean HasReference( const Handle(TObj_Object)& theObject) const; 
-~~~~~
-
-Returns True if the current object refers to the indicated object. 
-
-~~~~~{.cpp}
-    virtual Handle(TObj_ObjectIterator) GetReferences ( const Handle(Standard_Type)& theType = NULL ) const; 
-~~~~~
-
-Returns an iterator on the object references. The optional argument *theType* 
-restricts the types of referred objects, or does not if it is NULL. 
-
-~~~~~{.cpp}
-    virtual void RemoveAllReferences(); 
-~~~~~
-
-Removes all references from the current object. 
-
-~~~~~{.cpp}
-    virtual void RemoveReference( const Handle(TObj_Object)& theObject ); 
-~~~~~
-
-Removes the reference to the indicated object. 
-
-~~~~~{.cpp}
-    virtual Handle(TObj_ObjectIterator) GetBackReferences ( const Handle(Standard_Type)& theType = NULL ) const; 
-~~~~~
-
-Returns an iterator on the object back references. 
-The argument theType restricts the types of master objects, or does not if it is NULL. 
-
-~~~~~{.cpp}
-    virtual void ReplaceReference  ( const Handle(TObj_Object)& theOldObject,  const Handle(TObj_Object)& theNewObject ); 
-~~~~~
-
-Replaces the reference to theOldObject by the reference to *theNewObject*. 
-The handle theNewObject may be NULL to remove the reference. 
-
-~~~~~{.cpp}
-    virtual Standard_Boolean RelocateReferences  ( const TDF_Label& theFromRoot,  const TDF_Label& theToRoot, const Standard_Boolean theUpdateackRefs = Standard_True ); 
-~~~~~
-
-Replaces all references to a descendant label of *theFromRoot* 
-by the references to an equivalent label under *theToRoot*. 
-Returns **False** if the resulting reference does not point at a *TObj_Object*. 
-Updates back references if theUpdateackRefs is **True**. 
-
-~~~~~{.cpp}
-    virtual Standard_Boolean CanRemoveReference ( const Handle(TObj_Object)& theObj) const; 
-~~~~~
-
-Returns **True** if the reference can be removed and the master object 
-will remain valid (*weak* reference). 
-Returns **False** if the master object cannot be valid without the referred object (*strong* reference). 
-This affects the behaviour of objects removal from the model -- if the reference cannot be removed, 
-either the referred object will not be removed, or both the referred 
-and the master objects will be removed (depends on the deletion mode in the method **Detach**) 
-
-@subsection occt_tobj_3_7 Creation and deletion of objects
-
-It is recommended that all objects inheriting from *TObj_Object*
- should implement the same approach to creation and deletion. 
- 
-The object of the *TObj* data model cannot be created independently 
-of the model instance, as far as it stores the object data in OCAF data structures. 
-Therefore an object class cannot be created directly as its constructor is protected. 
-
-Instead, each object should provide a static method *Create*(), which accepts the model, 
-with the label, which stores the object and other type-dependent parameters 
-necessary for proper definition of the object. This method creates a new object with its data 
-(a set of OCAF attributes) in the specified label, and returns a handle to the object's interface. 
-
-The method *Detach*() is provided for deletion of objects from OCAF model. 
-Object data are deleted from the corresponding OCAF label; however, 
-the handle on object remains valid. The only operation available after object deletion 
-is the method *IsAlive*()  checking whether the object has been deleted or not, 
-which returns False if the object has been deleted. 
-
-When the object is deleted from the data model, the method checks 
-whether there are any alive references to the object. 
-Iterating on references the object asks each referring (master) object 
-whether the reference can be removed. If the master object can be unlinked, 
-the reference is removed, otherwise the master object will be removed too 
-or the referred object will be kept alive. This check is performed by the method *Detach* , 
-but the behavior depends on the deletion mode *TObj_DeletingMode*: 
-
-  * **TObj_FreeOnly** -- the object will be destroyed only if it is free, i.e. there are no references to it from other objects
-  * **TObj_KeepDepending** -- the object will be destroyed if there are no strong references to it from master objects (all references can be unlinked)
-  * **TObj_Force** -- the object and all depending master objects that have strong references to it will be destroyed.
-
-The most used methods for object removing are: 
-
-~~~~~{.cpp}
-    virtual Standard_Boolean CanDetachObject (const TObj_DeletingMode theMode = TObj_FreeOnly ); 
-~~~~~
-
-Returns **True** if the object can be deleted with the indicated deletion mode. 
-
-~~~~~{.cpp}
-    virtual Standard_Boolean Detach ( const TObj_DeletingMode theMode = TObj_FreeOnly ); 
-~~~~~
-
-Removes the object from the document if possible 
-(according to the indicated deletion mode). 
-Unlinks references from removed objects. 
-Returns **True** if the objects have been successfully deleted. 
-
-@subsection occt_tobj_3_8 Transformation and replication of object data
-
-*TObj_Object* provides a number of special virtual methods  to support replications of objects. These methods should be redefined by descendants when necessary. 
-
-~~~~~{.cpp}
-    virtual Handle(TObj_Object) Clone (const TDF_Label& theTargetLabel, Handle(TDF_RelocationTable) theRelocTable = 0); 
-~~~~~
-
-Copies the object to theTargetLabel. The new object will have all references of its original. 
-Returns a handle to the new object (null handle if fail). The data are copied directly, 
-but the name is changed by adding the postfix *_copy*. 
-To assign different names to the copies redefine the method: 
-
-~~~~~{.cpp}
-    virtual Handle(TCollection_HExtendedString) GetNameForClone ( const Handle(TObj_Object)& ) const; 
-~~~~~
-
-Returns the name for a new object copy. It could be useful to return the same object name 
-if the copy will be in the other model or in the other partition with its own dictionary. 
-The method *Clone* uses the following public methods for object data replications: 
-
-~~~~~{.cpp}
-    virtual void CopyReferences (const const Handle(TObj_Object)& theTargetObject, const Handle(TDF_RelocationTable) theRelocTable); 
-~~~~~
-
-Adds to the copy of the original object its references. 
-
-~~~~~{.cpp}
-    virtual void CopyChildren (TDF_Label& theTargetLabel, const Handle(TDF_RelocationTable) theRelocTable); 
-~~~~~
-
-Copies the children of an object to the target child label. 
-
-@subsection occt_tobj_3_9 Object flags
-
-Each instance of *TObj_Object* stores a set of bit flags, 
-which facilitate the storage of auxiliary logical information assigned to the objects 
-(object state). Several typical state flags are defined in the enumeration *ObjectState*: 
-
-  * *ObjectState_Hidden* -- the object is marked as hidden
-  * *ObjectState_Saved* -- the object has (or should have) the corresponding saved file on disk
-  * *ObjectState_Imported* -- the object is imported from somewhere
-  * *ObjectState_ImportedByFile* -- the object has been imported from file and should be updated to have correct relations with other objects
-  * *ObjectState_Ordered* -- the partition contains objects that can be ordered.
-
-The user (developer) can define any new flags in descendant classes. 
-To set/get an object, the flags use the following methods: 
-
-~~~~~{.cpp}
-    Standard_Integer GetFlags() const; 
-    void SetFlags( const Standard_Integer theMask ); 
-    Stadnard_Boolean TestFlags( const Standard_Integer theMask ) const; 
-    void ClearFlags( const Standard_Integer theMask = 0 ); 
-~~~~~
-
-In addition, the generic virtual interface stores the logical properties 
-of the object class in the form of a set of bit flags. 
-Type flags can be received by the method: 
-
-~~~~~{.cpp}
-    virtual Standard_Integer GetTypeFlags() const; 
-~~~~~
-
-The default implementation returns the flag **Visible** 
-defined in the enumeration *TypeFlags*. This flag is used to define visibility 
-of the object for the user browsing the model (see class *TObj_HiddenPartition*). 
-Other flags can be added by the applications. 
-
-@subsection occt_tobj_310 Partitions
-
-The special kind of objects defined by the class *TObj_Partition* 
-(and its descendant *TObj_HiddenPartition*) is provided for partitioning 
-the model into a hierarchical structure. This object represents the container 
-of other objects. Each *TObj* model contains the main partition that is placed 
-in the same OCAF label as the model object, and serves as a root of the object's tree. 
-A hidden partition is a simple partition with a predefined hidden flag. 
-
-The main partition object methods: 
-
-~~~~~{.cpp}
-    TDF_Label NewLabel() const; 
-~~~~~
-
-Allocates and returns a new label for creation of a new child object. 
-
-~~~~~{.cpp}
-    void SetNamePrefix  ( const Handle(TCollection_HExtendedString)& thePrefix); 
-~~~~~
-
-Defines the prefix for automatic generation of names of the newly created objects. 
-
-~~~~~{.cpp}
-    Handle(TCollection_HExtendedString) GetNamePrefix() const; 
-~~~~~
-
-Returns the current name prefix. 
-
-~~~~~{.cpp}
-    Handle(TCollection_HExtendedString) GetNewName ( const Standard_Boolean theIsToChangeCount) const; 
-~~~~~
-
-Generates the new name and increases the internal counter of child objects if theIsToChangeCount is **True**. 
-
-~~~~~{.cpp}
-    Standard_Integer GetLastIndex() const; 
-~~~~~
-
-Returns the last reserved child index. 
-
-~~~~~{.cpp}
-    void SetLastIndex( const Standard_Integer theIndex ); 
-~~~~~
-
-Sets the last reserved index. 
-
-@section occt_tobj_4 Auxiliary classes
-
-Apart from the model and the object, package *TObj* provides a set of auxiliary classes: 
-
-  * *TObj_Application* -- defines OCAF application supporting existence and operation with *TObj* documents.
-  * *TObj_Assistant* -- class provides an interface to the static data to be used during save and load operations on models. In particular, in case of cross-model dependencies it allows passing information on the parent model to the OCAF loader to correctly resolve the references when loading a dependent model.
-  * *TObj_TReference* -- OCAF attribute describes the references between objects in the *TObj* model(s). This attribute stores the label of the referred model object, and provides transparent cross-model references. At runtime, these references are simple Handles; in persistence mode, the cross-model references are automatically detected and processed by the persistence mechanism of *TObj_TReference* attribute. 
-  * Other classes starting with *TObj_T...* -- define OCAF attributes used to store TObj-specific classes and some types of data on OCAF labels. 
-  * Iterators -- a set of classes implementing *TObj_ObjectIterator* interface, used for iterations on *TObj* objects:
-	  * *TObj_ObjectIterator* -- a basic abstract class for other *TObj* iterators. Iterates on *TObj_Object* instances. 
-	  * *TObj_LabelIterator* -- iterates on object labels in the *TObj* model document 
-	  * *TObj_ModelIterator* -- iterates on all objects in the model. Works with sequences of other iterators. 
-	  * *TObj_OcafObjectIterator* -- Iterates on *TObj* data model objects. Can iterate on objects of a specific type. 
-	  * *TObj_ReferenceIterator* -- iterates on object references. 
-	  * *TObj_SequenceIterator* -- iterates on a sequence of *TObj* objects. 
-	  * *TObj_CheckModel* -- a tool that checks the internal consistency of the model. The basic implementation checks only the consistency of references between objects.
-
-The structure of *TObj* iterators hierarchy is presented below: 
-
-@figure{/user_guides/tobj/images/tobj_image008.png,"Hierarchy of iterators",420}
-
-
-@section occt_tobj_5 Packaging
-
-The *TObj* sources are distributed in the following packages: 
-
-  * *TObj* -- defines basic classes that implement *TObj* interfaces for OCAF-based modelers.
-  * *BinLDrivers, XmlLDrivers* -- binary and XML driver of *TObj* package
-  * *BinLPlugin, XmlLPlugin* -- plug-in for binary and XML persistence
-  * *BinMObj, XmlMObj* -- binary and XML drivers to store and retrieve specific *TObj* data to or from OCAF document
-  * *TKBinL, TKXmlL* -- toolkits of binary and XML persistence
-
-
-

dox/user_guides/user_guides.md

@@ -6,14 +6,13 @@ OCCT User Guides are organized by OCCT modules:
 * @subpage occt_user_guides__foundation_classes "Foundation Classes"
 * @subpage occt_user_guides__modeling_data "Modeling Data"
 * @subpage occt_user_guides__modeling_algos "Modeling Algorithms"
-  * @subpage occt_user_guides__shape_healing "Shape Healing"
+* @subpage occt_user_guides__mesh "Mesh"
+* @subpage occt_user_guides__shape_healing "Shape Healing"
 * @subpage occt_user_guides__visualization "Visualization"
-  * @subpage occt_user_guides__vis "VTK Integration Services"
-* Data Exchange
-  * @subpage occt_user_guides__iges "IGES translator"
-  * @subpage occt_user_guides__step "STEP translator"
-  * @subpage occt_user_guides__xde  "Extended Data Exchange (XDE)"
+* @subpage occt_user_guides__vis "VTK Integration Services"
+* @subpage occt_user_guides__iges "IGES Translator"
+* @subpage occt_user_guides__step "STEP Translator"
+* @subpage occt_user_guides__xde "Extended Data Exchange (XDE)"
 * @subpage occt_user_guides__ocaf "Open CASCADE Application Framework (OCAF)"
-  * @subpage occt_user_guides__tobj "TObj package"
 * @subpage occt_user_guides__test_harness "DRAW Test Harness"
 * @subpage occt_user_guides__inspector "Inspector"

dox/user_guides/visualization/visualization.md

@@ -42,8 +42,6 @@ To answer different needs of CASCADE users, this User's Guide offers the followi
     chapter 2 @ref occt_visu_2 "Fundamental Concepts", chapter 3 @ref occt_visu_3 "AIS: Application Interactive Services", and 4 @ref occt_visu_4 "3D Presentations".
     You may want to begin with the chapter presenting AIS.
 
-For advanced information on visualization algorithms, see our <a href="https://www.opencascade.com/content/tutorial-learning">E-learning & Training</a> offerings.
-
 @section occt_visu_2 Fundamental Concepts
 
 @subsection occt_visu_2_1 Presentation
@@ -1545,28 +1543,34 @@ aViewer->SetDefaultBackgroundColor (Quantity_NOC_DARKVIOLET);
 // Create a structure in this Viewer
 Handle(Graphic3d_Structure) aStruct = new Graphic3d_Structure (aViewer->StructureManager());
 aStruct->SetVisual (Graphic3d_TOS_SHADING); // Type of structure
+
 // Create a group of primitives  in this structure
 Handle(Graphic3d_Group) aPrsGroup = aStruct->NewGroup();
+
 // Fill this group with one quad of size 100
 Handle(Graphic3d_ArrayOfTriangleStrips) aTriangles = new Graphic3d_ArrayOfTriangleStrips (4);
 aTriangles->AddVertex (-100./2., -100./2., 0.0);
 aTriangles->AddVertex (-100./2.,  100./2., 0.0);
 aTriangles->AddVertex ( 100./2., -100./2., 0.0);
 aTriangles->AddVertex ( 100./2.,  100./2., 0.0);
+
 Handle(Graphic3d_AspectFillArea3d) anAspects = new Graphic3d_AspectFillArea3d (Aspect_IS_SOLID, Quantity_NOC_RED,
                                                                                Quantity_NOC_RED, Aspect_TOL_SOLID, 1.0f,
                                                                                Graphic3d_NOM_GOLD, Graphic3d_NOM_GOLD);
 aPrsGroup->SetGroupPrimitivesAspect (anAspects);
 aPrsGroup->AddPrimitiveArray (aTriangles);
+
 // Create Ambient and Infinite Lights in this Viewer
 Handle(V3d_AmbientLight)     aLight1 = new V3d_AmbientLight (Quantity_NOC_GRAY50);
 Handle(V3d_DirectionalLight) aLight2 = new V3d_DirectionalLight (V3d_Zneg, Quantity_NOC_WHITE, true);
 aViewer->AddLight (aLight1);
 aViewer->AddLight (aLight2);
 aViewer->SetLightOn();
+
 // Create a 3D quality  Window with the same DisplayConnection
 Handle(Xw_Window) aWindow = new Xw_Window (aDispConnection, "Test V3d", 100, 100, 500, 500);
 aWindow->Map(); // Map this Window to this screen
+
 // Create a Perspective  View in this Viewer
 Handle(V3d_View) aView = new V3d_View (aViewer);
 aView->Camera()->SetProjectionType (Graphic3d_Camera::Projection_Perspective);
@@ -1622,7 +1626,7 @@ aView->Update(); // update the Visualization in this View
 
 @subsubsection occt_visu_4_4_5 Perspective Projection
 
-**Field of view (FOVy)** -- defines the field of camera view by y axis in degrees (45° is default).
+**Field of view (FOVy)** -- defines the field of camera view by y axis in degrees (45° is default).
 
 @figure{camera_perspective.png,"Perspective frustum",420}
 
@@ -1643,7 +1647,7 @@ There are two types of IOD:
 * _Graphic3d_Camera::IODType_Absolute_ : Intraocular distance is defined as an absolute value.
 * _Graphic3d_Camera::IODType_Relative_ : Intraocular distance is defined relative to the camera focal length (as its coefficient).
 
-**Field of view (FOV)** -- defines the field of camera view by y axis in degrees (45° is default).
+**Field of view (FOV)** -- defines the field of camera view by y axis in degrees (45° is default).
 
 **ZFocus** -- defines the distance to the point of stereographic focus.
 

dox/user_guides/xde/xde.md

@@ -5,7 +5,7 @@
 
 @section occt_xde_1 Introduction
 
-This manual explains how to use the Extended Data Exchange (XDE). It provides basic documentation on setting up and using XDE. For advanced information on XDE and its applications, see our <a href="https://www.opencascade.com/content/tutorial-learning">E-learning & Training</a> offerings.
+This manual explains how to use the Extended Data Exchange (XDE). It provides basic documentation on setting up and using XDE.
 
 The Extended Data Exchange (XDE) module allows extending the scope of exchange by translating  additional data attached to geometric BREP data, thereby improving the interoperability with external software.