mirror of
https://git.dev.opencascade.org/repos/occt.git
synced 2025-04-03 17:56:21 +03:00
0026187: Implement m-dashes in the documentation
- m-dashes added. - some other cases of incorrect dash use fixed - unicode dashes were removed throughout the documentation. - other comments taken into account.
This commit is contained in:
ysn
bugmaster
parent
d94fa32ef9
commit
3f8122493a
@ -11,12 +11,12 @@ You need to use the same version of MS Visual Studio for building all third-part
|
||||
The links for downloading the third-party products are available on the web site of OPEN CASCADE SAS at http://www.opencascade.org/getocc/require/. There are two types of third-party products used by OCCT:
|
||||
|
||||
* Mandatory products:
|
||||
* Tcl/Tk 8.5 - 8.6;
|
||||
* FreeType 2.4.10 - 2.5.3.
|
||||
* Tcl/Tk 8.5 -- 8.6;
|
||||
* FreeType 2.4.10 -- 2.5.3.
|
||||
* Optional products:
|
||||
* TBB 3.x - 4.x;
|
||||
* gl2ps 1.3.5 - 1.3.8;
|
||||
* FreeImage 3.14.1 -3.16.0;
|
||||
* TBB 3.x -- 4.x;
|
||||
* gl2ps 1.3.5 -- 1.3.8;
|
||||
* FreeImage 3.14.1 -- 3.16.0;
|
||||
* VTK 6.1.0.
|
||||
|
||||
It is recommended to create a separate new folder on your workstation, where you will unpack the downloaded archives of the third-party products, and where you will build these products (for example, *c:\\occ3rdparty*).
|
||||
@ -168,9 +168,9 @@ You can download its sources from http://geuz.org/gl2ps/src/.
|
||||
As a result, you will get a folder named, for example, *3rdparty\\gl2ps-1.3.5-source*.
|
||||
|
||||
Rename it into <i>gl2ps-platform-compiler-building mode</i>, where
|
||||
* **platform** is *win32* or *win64*;
|
||||
* **compiler** is *vc8*, *vc9* or *vc10*;
|
||||
* **building mode** - *opt* (for release) or *deb* (for debug).
|
||||
* **platform** -- *win32* or *win64*;
|
||||
* **compiler** -- *vc8*, *vc9* or *vc10*;
|
||||
* **building mode** -- *opt* (for release) or *deb* (for debug).
|
||||
|
||||
For example, <i>gl2ps-win64-vc10-deb</i>
|
||||
|
||||
@ -208,7 +208,7 @@ You can download its sources from http://geuz.org/gl2ps/src/.
|
||||
@image html /dev_guides/building/3rdparty/images/3rdparty_image004.png
|
||||
@image latex /dev_guides/building/3rdparty/images/3rdparty_image004.png
|
||||
|
||||
* Select the generator (the compiler and the target platform - 32 or 64 bit) in the pop-up window.
|
||||
* Select the generator (the compiler and the target platform -- 32 or 64 bit) in the pop-up window.
|
||||
|
||||
@image html /dev_guides/building/3rdparty/images/3rdparty_image005.png
|
||||
@image latex /dev_guides/building/3rdparty/images/3rdparty_image005.png
|
||||
|
||||
@ -35,7 +35,7 @@ Select "MinGW MakeFiles" item from the list
|
||||
- Click "Finish"
|
||||
@figure{/dev_guides/building/android/images/android_image003.png}
|
||||
|
||||
If ANDROID_NDK environment variable is not defined in current OS, add cache entry ANDROID_NDK (entry type is PATH) - path to the NDK folder ("Add Entry" button)
|
||||
If ANDROID_NDK environment variable is not defined in current OS, add cache entry ANDROID_NDK (entry type is PATH) -- path to the NDK folder ("Add Entry" button)
|
||||
@figure{/dev_guides/building/android/images/android_image004.png}
|
||||
|
||||
If on Windows the message is appeared: "CMake Error: CMake was unable to find a build program corresponding to "MinGW Makefiles"
|
||||
|
||||
@ -60,7 +60,7 @@ To prevent this, it is suggested to make links:
|
||||
Example:
|
||||
|
||||
|
||||
\> ./configure -prefix=/PRODUCTS/occt-6.5.5 --with-tcl=/PRODUCTS/tcltk-8.5.8/lib --with-tk=/PRODUCTS/tcltk-8.5.8/lib --with-freetype=/PRODUCTS/freetype-2.4.10 --with-gl2ps=/PRODUCTS/gl2ps-1.3.5 --with-freeimage=/PRODUCTS/freeimage-3.14.1 --with-tbb-include=/PRODUCTS/tbb30_018oss/include --with-tbb-library=/PRODUCTS/tbb30_018oss/lib/ia32/cc4.1.0_libc2.4_kernel2.6.16.21 -–with-vtk-include=/PRODUCTS/VTK-6.1.0/include/vtk-6.1 –with-vtk-library=/PRODUCTS/ /VTK-6.1.0//lib
|
||||
\> ./configure -prefix=/PRODUCTS/occt-6.5.5 --with-tcl=/PRODUCTS/tcltk-8.5.8/lib --with-tk=/PRODUCTS/tcltk-8.5.8/lib --with-freetype=/PRODUCTS/freetype-2.4.10 --with-gl2ps=/PRODUCTS/gl2ps-1.3.5 --with-freeimage=/PRODUCTS/freeimage-3.14.1 --with-tbb-include=/PRODUCTS/tbb30_018oss/include --with-tbb-library=/PRODUCTS/tbb30_018oss/lib/ia32/cc4.1.0_libc2.4_kernel2.6.16.21 --with-vtk-include=/PRODUCTS/VTK-6.1.0/include/vtk-6.1 -with-vtk-library=/PRODUCTS/ /VTK-6.1.0//lib
|
||||
|
||||
|
||||
3.If configure exits successfully, you can build OCCT with *make* command.
|
||||
|
||||
@ -35,7 +35,7 @@ The bare sources distribution contains not only the sources of Open CASCADE Tech
|
||||
|
||||
Now it is time to run a CMake tool which will generate the actual project files for the target IDE (e.g., Visual Studio 2010 solution).
|
||||
|
||||
It is recommended to use *cmake-gui* - cross-platform GUI tool provided by CMake on Windows, Mac and Linux. As a command-line alternative, *ccmake* also can be used.
|
||||
It is recommended to use *cmake-gui* -- cross-platform GUI tool provided by CMake on Windows, Mac and Linux. As a command-line alternative, *ccmake* also can be used.
|
||||
|
||||
CMake deals with three directories: source, build or binary and install.
|
||||
|
||||
@ -47,11 +47,11 @@ CMake deals with three directories: source, build or binary and install.
|
||||
|
||||
**Note**: The good practice is not to mix up different build configurations in a single directory and not to use the source directory as a build one, for example:
|
||||
|
||||
d:/occt/ - the source directory
|
||||
d:/tmp/occt-build-vc10-x64 - the build directory with the generated
|
||||
solution and other intermediate files created during a CMake tool working
|
||||
d:/occt-install - the installation directory that is
|
||||
able to contain several OCCT configuratoion
|
||||
d:/occt/ -- the source directory
|
||||
d:/tmp/occt-build-vc10-x64 -- the build directory with the generated
|
||||
solution and other intermediate files created during a CMake tool working
|
||||
d:/occt-install -- the installation directory that is
|
||||
able to contain several OCCT configuratoion
|
||||
|
||||
## Configuration process
|
||||
|
||||
@ -93,9 +93,9 @@ The following table enumerates the full list of environment variables used at co
|
||||
| CMAKE_BUILD_TYPE | String | Specifies the build type on single-configuration generators (sush as make). Possible values are Debug, Release and RelWithDebInfo |
|
||||
| USE_FREEIMAGE | Boolean flag | Indicates whether Freeimage product should be used in OCCT visualization module for support of popular graphics image formats (PNG, BMP etc) |
|
||||
| USE_GL2PS | Boolean flag | Indicates whether GL2PS product should be used in OCCT visualization module for support of vector image formats (PS, EPS etc) |
|
||||
| USE_TBB | Boolean flag | Indicates whether TBB 3-rd party is used or not. TBB stands for Threading Building Blocks, the technology of Intel Corp, which comes with different mechanisms and patterns for injecting parallelism into your application. OCCT remains parallel even without TBB product |
|
||||
| USE_VTK | Boolean flag | Indicates whether VTK 3-rd party is used or not. VTK stands for Visualization ToolKit, the technology of Kitware Inc intended for general-purpose scientific visualization. OCCT comes with a bridge between CAD data representation and VTK by means of its dedicated VIS component (VTK Integration Services). You may skip this 3-rd party unless you are planning to use VTK visualization for OCCT geometry. The official documentation @ref occt_user_guides__vis for the details on VIS |
|
||||
| 3RDPARTY_DIR | Path | Defines the root directory where all required 3-rd party products will be searched. Once you define this path it is very convenient to click "Configure" button in order to let CMake automatically detect all necessary products|
|
||||
| USE_TBB | Boolean flag | Indicates whether TBB 3rd party is used or not. TBB stands for Threading Building Blocks, the technology of Intel Corp, which comes with different mechanisms and patterns for injecting parallelism into your application. OCCT remains parallel even without TBB product |
|
||||
| USE_VTK | Boolean flag | Indicates whether VTK 3rd party is used or not. VTK stands for Visualization ToolKit, the technology of Kitware Inc intended for general-purpose scientific visualization. OCCT comes with a bridge between CAD data representation and VTK by means of its dedicated VIS component (VTK Integration Services). You may skip this 3rd party unless you are planning to use VTK visualization for OCCT geometry. The official documentation @ref occt_user_guides__vis for the details on VIS |
|
||||
| 3RDPARTY_DIR | Path | Defines the root directory where all required 3rd party products will be searched. Once you define this path it is very convenient to click "Configure" button in order to let CMake automatically detect all necessary products|
|
||||
| 3RDPARTY_FREETYPE_* | Path | Path to Freetype binaries |
|
||||
| 3RDPARTY_TCL_* 3RDPARTY_TK_* | Path | Path to Tcl/Tk binaries |
|
||||
| 3RDPARTY_FREEIMAGE* | Path | Path to Freeimage binaries |
|
||||
@ -125,18 +125,18 @@ OCCT sources. This way you are able to introduce patches to Open CASCADE Technol
|
||||
|
||||
**Note:** In those CMake options defining paths only the forward slashes ("/") are acceptable.
|
||||
|
||||
### 3rd-party search mechanism (The variables with <i>3RDPARTY_</i> prefix)
|
||||
### 3rd party search mechanism (The variables with <i>3RDPARTY_</i> prefix)
|
||||
|
||||
If *3RDPARTY_DIR* directory is defined, required 3rd-party binaries are sought in it, default system folders are ignored.
|
||||
If *3RDPARTY_DIR* directory is defined, required 3rd party binaries are sought in it, default system folders are ignored.
|
||||
|
||||
The procedure expects to find binary and header files of each 3rd-party product in its own sub-directory: *bin*, *lib* and *include*.
|
||||
The procedure expects to find binary and header files of each 3rd party product in its own sub-directory: *bin*, *lib* and *include*.
|
||||
|
||||
The result of the search (achived on the next pass of the configuration process) are recorded in the corresponding variables:
|
||||
|
||||
* *3RDPARTY_\<PRODUCT\>_DIR* - path to the 3rdparty directory (with directory name) (e.g. <i>D:/3rdparty/tcltk-86-32</i>)
|
||||
* *3RDPARTY_\<PRODUCT\>_LIBRARY_DIR* - path to directory containing a library (e.g. <i>D:/3rdparty/tcltk-86-32/lib</i>).
|
||||
* *3RDPARTY_\<PRODUCT\>_INCLUDE_DIR* - path to the directory containing a header file (e.g., <i>D:/3rdparty/tcltk-86-32/include</i>)
|
||||
* *3RDPARTY_\<PRODUCT\>_DLL_DIR* - path to the directory containing a shared library (e.g., <i>D:/3rdparty/tcltk-86-32/bin</i>) This variable is only relevant to Windows platforms
|
||||
* *3RDPARTY_\<PRODUCT\>_DIR* -- path to the 3rdparty directory (with directory name) (e.g. <i>D:/3rdparty/tcltk-86-32</i>)
|
||||
* *3RDPARTY_\<PRODUCT\>_LIBRARY_DIR* -- path to the directory containing a library (e.g. <i>D:/3rdparty/tcltk-86-32/lib</i>).
|
||||
* *3RDPARTY_\<PRODUCT\>_INCLUDE_DIR* -- path to the directory containing a header file (e.g., <i>D:/3rdparty/tcltk-86-32/include</i>)
|
||||
* *3RDPARTY_\<PRODUCT\>_DLL_DIR* -- path to the directory containing a shared library (e.g., <i>D:/3rdparty/tcltk-86-32/bin</i>) This variable is only relevant to Windows platforms.
|
||||
|
||||
Note: each library and include directory should be the children of product directory if the last one is defined.
|
||||
|
||||
@ -194,14 +194,14 @@ Normally you use the installation directory of OCCT to link against your specifi
|
||||
|
||||
the directory structure is follow:
|
||||
|
||||
data - data files for OCCT (brep, iges, stp)
|
||||
doc - OCCT overview documentation in HTML format
|
||||
inc - header files
|
||||
samples - samples
|
||||
src - all required source files for OCCT
|
||||
tests - OCCT test suite
|
||||
win32\vc10\bind - binary files (installed 3rdparties and occt)
|
||||
\libd - libraries (installed 3rdparties and occt)
|
||||
data -- data files for OCCT (brep, iges, stp)
|
||||
doc -- OCCT overview documentation in HTML format
|
||||
inc -- header files
|
||||
samples -- samples
|
||||
src -- all required source files for OCCT
|
||||
tests -- OCCT test suite
|
||||
win32\vc10\bind -- binary files (installed 3rdparties and occt)
|
||||
\libd -- libraries (installed 3rdparties and occt)
|
||||
|
||||
**Note:** The above example is given for debug configuration. However, it is generally safe to use the same installation directory for the release build. In the latter case the contents of install directory will be enriched with subdirectories and files related to the release configuration. In particular, the binaries directory win64 will be expanded as
|
||||
follows:
|
||||
@ -211,6 +211,6 @@ follows:
|
||||
\bin
|
||||
\lib
|
||||
|
||||
If CMake installation flags are enabled for the 3-rd party products (e.g. INSTALL_FREETYPE), then the corresponding binaries will be copied to the same bin(d) and lib(d) directories together with the native binaries of OCCT. Such organization of libraries can be especially helpful if your OCCT-based software does not use itself the 3-rd parties of Open CASCADE Technology (thus, there is no sense to pack them into dedicated directories)
|
||||
If CMake installation flags are enabled for the 3rd party products (e.g. INSTALL_FREETYPE), then the corresponding binaries will be copied to the same bin(d) and lib(d) directories together with the native binaries of OCCT. Such organization of libraries can be especially helpful if your OCCT-based software does not use itself the 3rd parties of Open CASCADE Technology (thus, there is no sense to pack them into dedicated directories)
|
||||
|
||||
The installation folder contains the scripts to run *DRAWEXE* (*draw.bat* or *draw.sh*), samples (if its were installed) and overview.html (short-cut for installed OCCT overview documentation).
|
||||
|
||||
@ -13,11 +13,11 @@ paragraph 1 of \ref occt_dev_guides__building for instructions.
|
||||
|
||||
1. Edit file *custom.bat* to define the environment:
|
||||
|
||||
- *VCVER* - version of Visual Studio (vc8, vc9, vc10, vc11 or vc12),
|
||||
- *VCVER* -- version of Visual Studio (vc8, vc9, vc10, vc11 or vc12),
|
||||
and relevant *VCVARS* path
|
||||
- *ARCH* - architecture (32 or 64), affects only *PATH* variable for execution
|
||||
- <i>HAVE_*</i> - flags to enable or disable use of optional third-party products
|
||||
- CSF_OPT_* - paths to search for includes and binaries of all used
|
||||
- *ARCH* -- architecture (32 or 64), affects only *PATH* variable for execution
|
||||
- <i>HAVE_*</i> -- flags to enable or disable use of optional third-party products
|
||||
- CSF_OPT_* -- paths to search for includes and binaries of all used
|
||||
third-party products
|
||||
|
||||
2. Launch *msvc.bat* to start Visual Studio with all necessary environment
|
||||
|
||||
@ -115,14 +115,14 @@ and third-party components required for building OCCT.
|
||||
LOC:dev:occt> wgenproj [ -target=<TARGET> ] [ -no_wprocess ]
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
TARGET:
|
||||
* *vc8* - Visual Studio 2005;
|
||||
* *vc9* - Visual Studio 2008;
|
||||
* *vc10* - Visual Studio 2010;
|
||||
* *vc11* - Visual Studio 2012;
|
||||
* *cbp* - CodeBlocks;
|
||||
* *cmake* - CMake;
|
||||
* *amk* - AutoMake;
|
||||
* *xcd* - Xcode;
|
||||
* *vc8* -- Visual Studio 2005;
|
||||
* *vc9* -- Visual Studio 2008;
|
||||
* *vc10* -- Visual Studio 2010;
|
||||
* *vc11* -- Visual Studio 2012;
|
||||
* *cbp* -- CodeBlocks;
|
||||
* *cmake* -- CMake;
|
||||
* *amk* -- AutoMake;
|
||||
* *xcd* -- Xcode;
|
||||
* <i>-no_wprocess</i> option skips generation of derived headers and source files.
|
||||
|
||||
Note that this command takes several minutes to complete at the first call.
|
||||
@ -135,14 +135,14 @@ To regenerate derived headers and source files without regeneration of projects
|
||||
LOC:dev:occt> wprocess -DGroups=Src,Xcpp
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
The generated building project has been placed into <i>$CASROOT/adm</i> folder:
|
||||
* for vc8 - <i>$CASROOT/adm/msvc/vc8</i>;
|
||||
* for vc9 - <i>$CASROOT/adm/msvc/vc9</i>;
|
||||
* for vc10 - <i>$CASROOT/adm/msvc/vc10</i>;
|
||||
* for vc11 - <i>$CASROOT/adm/msvc/vc11</i>;
|
||||
* for cbp - <i>$CASROOT/adm/\<OS\>/cbp</i>;
|
||||
* for cmake - <i>$CASROOT/adm/cmake</i>;
|
||||
* for amk - <i>$CASROOT/adm/lin/amk</i>;
|
||||
* xcd - <i>$CASROOT/adm/\<OS\>/xcd</i>
|
||||
* for vc8 -- <i>$CASROOT/adm/msvc/vc8</i>;
|
||||
* for vc9 -- <i>$CASROOT/adm/msvc/vc9</i>;
|
||||
* for vc10 -- <i>$CASROOT/adm/msvc/vc10</i>;
|
||||
* for vc11 -- <i>$CASROOT/adm/msvc/vc11</i>;
|
||||
* for cbp -- <i>$CASROOT/adm/\<OS\>/cbp</i>;
|
||||
* for cmake -- <i>$CASROOT/adm/cmake</i>;
|
||||
* for amk -- <i>$CASROOT/adm/lin/amk</i>;
|
||||
* xcd -- <i>$CASROOT/adm/\<OS\>/xcd</i>
|
||||
|
||||
@section wok4 Generation of documentation
|
||||
|
||||
@ -152,11 +152,11 @@ The generated building project has been placed into <i>$CASROOT/adm</i> folder:
|
||||
:LOC:dev:occt> wgendoc
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
The following options can be used:
|
||||
* <i>-wb=\<workbench name\></i> the name of OCCT workbench (the current one by default);
|
||||
* <i>-m=\<list of modules\></i> the list of modules that will be contained in the documentation;
|
||||
* <i>-outdir=\<path\></i> the output directory for the documentation;
|
||||
* <i>-chm</i> the option to generate CHM file;
|
||||
* <i>-hhc=\<path\></i> the path to HTML Help Compiler *hhc.exe* or equivalent;
|
||||
* <i>-qthelp=\<path\></i> the option to generate Qt Help file, where <i>\<path\></i> is the required path to *qthelpgenerator* executable;
|
||||
* <i>-doxygen=\<path\></i> the path to Doxygen executable;
|
||||
* <i>-dot=\<path\></i> the path to GraphViz dot executable.
|
||||
* <i>-wb=\<workbench name\></i> -- the name of OCCT workbench (the current one by default);
|
||||
* <i>-m=\<list of modules\></i> -- the list of modules that will be contained in the documentation;
|
||||
* <i>-outdir=\<path\></i> -- the output directory for the documentation;
|
||||
* <i>-chm</i> -- the option to generate CHM file;
|
||||
* <i>-hhc=\<path\></i> -- the path to HTML Help Compiler *hhc.exe* or equivalent;
|
||||
* <i>-qthelp=\<path\></i> -- the option to generate Qt Help file, where <i>\<path\></i> is the required path to *qthelpgenerator* executable;
|
||||
* <i>-doxygen=\<path\></i> -- the path to Doxygen executable;
|
||||
* <i>-dot=\<path\></i> -- the path to GraphViz dot executable.
|
||||
|
||||
@ -67,10 +67,10 @@ Names of units should not contain underscores, unless the use of underscores is
|
||||
|
||||
The following extensions should be used for source files, depending on their type:
|
||||
|
||||
* <i>.cdl</i> - CDL declaration files
|
||||
* <i>.cxx</i> - C++ source files
|
||||
* <i>.hxx</i> - C++ header files
|
||||
* <i>.lxx</i> - headers with definitions of inline methods (CDL packages)
|
||||
* <i>.cdl</i> -- CDL declaration files
|
||||
* <i>.cxx</i> -- C++ source files
|
||||
* <i>.hxx</i> -- C++ header files
|
||||
* <i>.lxx</i> -- headers with definitions of inline methods (CDL packages)
|
||||
|
||||
### Prefix for toolkit names [MANDATORY]
|
||||
|
||||
@ -452,7 +452,7 @@ The source code is one of the most important references for documentation.
|
||||
The comments in the source code should be complete enough to allow understanding the corresponding code and to serve as basis for other documents.
|
||||
|
||||
The main reasons why the comments are regarded as documentation and should be maintained are:
|
||||
- The comments are easy to reach - they are always together with the source code;
|
||||
- The comments are easy to reach -- they are always together with the source code;
|
||||
- It is easy to update a description in the comment when the source is modified;
|
||||
- The source by itself is a good context to describe various details that would require much more explanations in a separate document;
|
||||
- As a summary, this is the most cost-effective documentation.
|
||||
@ -950,7 +950,7 @@ Command should warn the user about unknown arguments, including cases when extra
|
||||
|
||||
### Message printing
|
||||
|
||||
Informative messages should be printed into standard output *std::cout*, whilst command results (if any) - into Draw Interpreter.
|
||||
Informative messages should be printed into standard output *std::cout*, whilst command results (if any) -- into Draw Interpreter.
|
||||
|
||||
Information printed into Draw Interpreter should be well-structured to allow usage in TCL script.
|
||||
|
||||
|
||||
@ -198,9 +198,9 @@ The following lines should provide a description of the context and details on t
|
||||
The contents and the recommended structure of the description depend on the nature of the bug.
|
||||
|
||||
In a general case, the following elements should be present:
|
||||
* **Problem** – a description of the unwanted behavior;
|
||||
* **Change** – a description of the implemented changes, including the names of involved classes / methods / enumerations etc.;
|
||||
* **Result** – a description of the current behavior (after the implementation).
|
||||
* **Problem** -- a description of the unwanted behavior;
|
||||
* **Change** -- a description of the implemented changes, including the names of involved classes / methods / enumerations etc.;
|
||||
* **Result** -- a description of the current behavior (after the implementation).
|
||||
|
||||
Example:
|
||||
|
||||
|
||||
@ -59,8 +59,8 @@ const char* DBRep_Set (const char* theNameStr, void* theShapePtr)
|
||||
~~~~~
|
||||
|
||||
Sets the specified shape as a value of DRAW interpreter variable with the given name.
|
||||
- *theNameStr* - the DRAW interpreter variable name to set.
|
||||
- *theShapePtr* - a pointer to *TopoDS_Shape* variable.
|
||||
- *theNameStr* -- the DRAW interpreter variable name to set.
|
||||
- *theShapePtr* -- a pointer to *TopoDS_Shape* variable.
|
||||
|
||||
~~~~~
|
||||
const char* DrawTrSurf_Set (const char* theNameStr, void* theHandlePtr)
|
||||
@ -69,10 +69,10 @@ const char* DrawTrSurf_SetPnt2d (const char* theNameStr, void* thePnt2dPtr)
|
||||
~~~~~
|
||||
|
||||
Sets the specified geometric object as a value of DRAW interpreter variable with the given name.
|
||||
- *theNameStr* - the DRAW interpreter variable name to set.
|
||||
- *theHandlePtr* - a pointer to the geometric variable (Handle to *Geom_Geometry* or *Geom2d_Curve* or descendant) to be set.
|
||||
- *thePntPtr* - a pointer to the variable of type *gp_Pnt* to be set.
|
||||
- *thePnt2dPtr* - a pointer to the variable of type *gp_Pnt2d* to be set.
|
||||
- *theNameStr* -- the DRAW interpreter variable name to set.
|
||||
- *theHandlePtr* -- a pointer to the geometric variable (Handle to *Geom_Geometry* or *Geom2d_Curve* or descendant) to be set.
|
||||
- *thePntPtr* -- a pointer to the variable of type *gp_Pnt* to be set.
|
||||
- *thePnt2dPtr* -- a pointer to the variable of type *gp_Pnt2d* to be set.
|
||||
|
||||
All these functions are defined in *TKDraw* toolkit and return a string indicating the result of execution.
|
||||
|
||||
@ -85,8 +85,8 @@ const char* BRepTools_Write (const char* theFileNameStr, void* theShapePtr)
|
||||
~~~~~
|
||||
|
||||
Saves the specified shape to a file with the given name.
|
||||
- *theFileNameStr* - the name of the file where the shape is saved.
|
||||
- *theShapePtr* - a pointer to *TopoDS_Shape* variable.
|
||||
- *theFileNameStr* -- the name of the file where the shape is saved.
|
||||
- *theShapePtr* -- a pointer to *TopoDS_Shape* variable.
|
||||
|
||||
~~~~~
|
||||
const char* BRepTools_Dump (void* theShapePtr)
|
||||
@ -94,7 +94,7 @@ const char* BRepTools_DumpLoc (void* theShapePtr)
|
||||
~~~~~
|
||||
|
||||
Dumps shape or its location to cout.
|
||||
- *theShapePtr* - a pointer to *TopoDS_Shape* variable.
|
||||
- *theShapePtr* -- a pointer to *TopoDS_Shape* variable.
|
||||
|
||||
The following function is provided by *TKMesh* toolkit:
|
||||
|
||||
@ -103,8 +103,8 @@ const char* BRepMesh_Dump (void* theMeshHandlePtr, const char* theFileNameStr)
|
||||
~~~~~
|
||||
|
||||
Stores mesh produced in parametric space to BREP file.
|
||||
- *theMeshHandlePtr* - a pointer to *Handle(BRepMesh_DataStructureOfDelaun)* variable.
|
||||
- *theFileNameStr* - the name of the file where the mesh is stored.
|
||||
- *theMeshHandlePtr* -- a pointer to *Handle(BRepMesh_DataStructureOfDelaun)* variable.
|
||||
- *theFileNameStr* -- the name of the file where the mesh is stored.
|
||||
|
||||
The following additional function is provided by *TKGeomBase* toolkit:
|
||||
|
||||
@ -113,7 +113,7 @@ const char* GeomTools_Dump (void* theHandlePtr)
|
||||
~~~~~
|
||||
|
||||
Dump geometric object to cout.
|
||||
- *theHandlePtr* - a pointer to the geometric variable (<i>Handle</i> to *Geom_Geometry* or *Geom2d_Curve* or descendant) to be set.
|
||||
- *theHandlePtr* -- a pointer to the geometric variable (<i>Handle</i> to *Geom_Geometry* or *Geom2d_Curve* or descendant) to be set.
|
||||
|
||||
@section occt_debug_vstudio Using Visual Studio debugger
|
||||
|
||||
|
||||
@ -117,16 +117,16 @@ If you want to use the same image for several documents, you can place it in *do
|
||||
|
||||
|
||||
The documentation is generated in subfolder *doc* :
|
||||
* *html* - a directory for generated HTML pages;
|
||||
* *pdf* - a directory for generated PDF files.
|
||||
* *html* -- a directory for generated HTML pages;
|
||||
* *pdf* -- a directory for generated PDF files.
|
||||
|
||||
@section OCCT_DM_SECTION_4 Adding a New Document
|
||||
|
||||
Place a new document in the folder taking into account its logical position in the documentation hierarchy. For instance, the document *svn.md* about the use of SVN to work with OCCT source code can be placed into <i>/dox/dev_guides/</i>.
|
||||
|
||||
If there are images in the document, it should be placed in its own folder containing a subfolder for images. For instance:
|
||||
* <i> /dox/dev_guides/svn/ </i> - for *svn.md* file;
|
||||
* <i> /dox/dev_guides/svn/images/ </i> - for images.
|
||||
* <i> /dox/dev_guides/svn/ </i> -- for *svn.md* file;
|
||||
* <i> /dox/dev_guides/svn/images/ </i> -- for images.
|
||||
|
||||
Add a relative path to *svn.md* in file <i>dox/FILES.txt</i>. For instance
|
||||
|
||||
@ -168,9 +168,9 @@ The table of contents, page numbers (in PDF), and figure numbers (in PDF) are ge
|
||||
@subsection OCCT_DM_SECTION_A_1 Headers and hierarchic document structure
|
||||
|
||||
Headers of different levels can be specified with the following tags:
|
||||
* <i>\@section</i> - for the first-level headers;
|
||||
* <i>\@subsection</i> - for the second level headers;
|
||||
* <i>\@subsubsection</i> - for the third level headers.
|
||||
* <i>\@section</i> -- for the first-level headers;
|
||||
* <i>\@subsection</i> -- for the second level headers;
|
||||
* <i>\@subsubsection</i> -- for the third level headers.
|
||||
|
||||
For example:
|
||||
|
||||
|
||||
@ -66,7 +66,7 @@ The official repository contains:
|
||||
Integration of contributions that have passed certification testing is made exclusively by the Bugmaster.
|
||||
Normally this is made by rebasing the contribution branch on the current master
|
||||
and squashing it into a single commit. This is made to have the master branch history plain and clean,
|
||||
following the general rule “one issue – one commit”.
|
||||
following the general rule “one issue -- one commit”.
|
||||
The description of the commit integrated to the master branch is taken from the Mantis issue
|
||||
(ID, 'Summary', followed by the information from 'Documentation' field if present).
|
||||
|
||||
@ -222,8 +222,8 @@ The official repository contains:
|
||||
|
||||
On Windows, make sure to note the complete path to the generated files (the location of your $HOME might be not obvious). Two key files will be created in the specified location (by default in $HOME/.ssh/):
|
||||
|
||||
* *id_rsa* - private key
|
||||
* *id_rsa.pub* - public key
|
||||
* *id_rsa* -- private key
|
||||
* *id_rsa.pub* -- public key
|
||||
|
||||
The content of the public key file (one text line) is the key to be added to the user account on the site (see below).
|
||||
|
||||
@ -358,7 +358,7 @@ In TortoiseGit:
|
||||
> git commit -a -m "Write meaningful commit message here"
|
||||
~~~~~
|
||||
|
||||
Option –a tells the command to automatically include (stage) files
|
||||
Option -a tells the command to automatically include (stage) files
|
||||
that have been modified or deleted, but it will omit the new files that might have been added by you.
|
||||
To commit such new files, you must add (stage) them before commit command.
|
||||
|
||||
@ -437,7 +437,7 @@ Note that Git forbids pushing a branch if the corresponding remote branch alread
|
||||
@image html OCCT_GitGuide_V2_image019.png
|
||||
@image latex OCCT_GitGuide_V2_image019.png
|
||||
|
||||
Note that the local branches of your repository are the primary place, where your changes are stored until they get integrated to the official version of OCCT (master branch). The branches submitted to official repository are for collaborative work, review, and integration - that repository should not be used for long-term storage of incomplete changes.
|
||||
Note that the local branches of your repository are the primary place, where your changes are stored until they get integrated to the official version of OCCT (master branch). The branches submitted to official repository are for collaborative work, review, and integration -- that repository should not be used for long-term storage of incomplete changes.
|
||||
|
||||
Remove the local branches that you do not need any more. Note that you cannot delete the current branch. It means that you need to switch to another one (e.g. master) if the branch you are going to delete is the current one.
|
||||
|
||||
|
||||
@ -101,7 +101,7 @@ Example:
|
||||
The tests are considered as non-regressive if only OK, BAD (i.e. known problem), and SKIPPED (i.e. not executed, typically because of lack of a data file) statuses are reported. See @ref testmanual_details_results "Interpretation of test results" for details.
|
||||
|
||||
The results and detailed logs of the tests are saved by default to a new subdirectory of the subdirectory *results* in the current folder, whose name is generated automatically using the current date and time, prefixed by Git branch name (if Git is available and current sources are managed by Git).
|
||||
If necessary, a non-default output directory can be specified using option <i> –outdir</i> followed by a path to the directory. This directory should be new or empty; use option <i>–overwrite</i> to allow writing results in the existing non-empty directory.
|
||||
If necessary, a non-default output directory can be specified using option <i> -outdir</i> followed by a path to the directory. This directory should be new or empty; use option <i>-overwrite</i> to allow writing results in the existing non-empty directory.
|
||||
|
||||
Example:
|
||||
~~~~~
|
||||
@ -199,7 +199,7 @@ Example:
|
||||
* Added files:
|
||||
|
||||
~~~~~
|
||||
git status –short
|
||||
git status -short
|
||||
A tests/bugs/heal/data/bug210_a.brep
|
||||
A tests/bugs/heal/data/bug210_b.brep
|
||||
A tests/bugs/heal/bug210_1
|
||||
@ -570,7 +570,7 @@ Other Tcl variables defined during the test execution are:
|
||||
|
||||
In order to ensure that the test works as expected in different environments, observe the following additional rules:
|
||||
* Avoid using external commands such as *grep, rm,* etc., as these commands can be absent on another system (e.g. on Windows); use facilities provided by Tcl instead.
|
||||
* Do not put call to *locate_data_file* in catch statement – this can prevent correct interpretation of the missing data file by the test system.
|
||||
* Do not put call to *locate_data_file* in catch statement -- this can prevent correct interpretation of the missing data file by the test system.
|
||||
* Do not use commands *decho* and *dlog* in the test script, to avoid interference with use of these commands by the test system.
|
||||
|
||||
@subsection testmanual_details_results Interpretation of test results
|
||||
@ -705,15 +705,15 @@ testdiff dir1 dir2 [groupname [gridname]] [options...]
|
||||
Here *dir1* and *dir2* are directories containing logs of two test runs.
|
||||
|
||||
Possible options are:
|
||||
* <i>-save \<filename\> </i> - saves the resulting log in a specified file (<i>$dir1/diff-$dir2.log</i> by default). HTML log is saved with the same name and extension .html;
|
||||
* <i>-status {same|ok|all}</i> - allows filtering compared cases by their status:
|
||||
* *same* - only cases with same status are compared (default);
|
||||
* *ok* - only cases with OK status in both logs are compared;
|
||||
* *all* - results are compared regardless of status;
|
||||
* <i>-verbose \<level\> </i> - defines the scope of output data:
|
||||
* 1 - outputs only differences;
|
||||
* 2 - additionally outputs the list of logs and directories present in one of directories only;
|
||||
* 3 - (by default) additionally outputs progress messages;
|
||||
* <i>-save \<filename\> </i> -- saves the resulting log in a specified file (<i>$dir1/diff-$dir2.log</i> by default). HTML log is saved with the same name and extension .html;
|
||||
* <i>-status {same|ok|all}</i> -- allows filtering compared cases by their status:
|
||||
* *same* -- only cases with same status are compared (default);
|
||||
* *ok* -- only cases with OK status in both logs are compared;
|
||||
* *all* -- results are compared regardless of status;
|
||||
* <i>-verbose \<level\> </i> -- defines the scope of output data:
|
||||
* 1 -- outputs only differences;
|
||||
* 2 -- additionally outputs the list of logs and directories present in one of directories only;
|
||||
* 3 -- (by default) additionally outputs progress messages;
|
||||
|
||||
Example:
|
||||
|
||||
@ -760,9 +760,9 @@ This group allows testing Boolean operations.
|
||||
DRAW module: MODELING (packages *BOPTest* and *BRepTest*).
|
||||
|
||||
Grids names are based on name of the command used, with suffixes:
|
||||
* <i>_2d</i> – for tests operating with 2d objects (wires, wires, 3d objects, etc.);
|
||||
* <i>_simple</i> – for tests operating on simple shapes (boxes, cylinders, toruses, etc.);
|
||||
* <i>_complex</i> – for tests dealing with complex shapes.
|
||||
* <i>_2d</i> -- for tests operating with 2d objects (wires, wires, 3d objects, etc.);
|
||||
* <i>_simple</i> -- for tests operating on simple shapes (boxes, cylinders, toruses, etc.);
|
||||
* <i>_complex</i> -- for tests dealing with complex shapes.
|
||||
|
||||
| Grid | Commands | Functionality |
|
||||
| :---- | :----- | :------- |
|
||||
@ -1223,9 +1223,9 @@ To check pixel color command *checkcolor* can be used.
|
||||
|
||||
Use: checkcolor x y red green blue
|
||||
|
||||
x y - pixel coordinates
|
||||
x, y -- pixel coordinates
|
||||
|
||||
red green blue - expected pixel color (values from 0 to 1)
|
||||
red green blue -- expected pixel color (values from 0 to 1)
|
||||
|
||||
This procedure checks color with tolerance (5x5 area)
|
||||
|
||||
|
||||
@ -438,7 +438,7 @@ To display this object use command *vdisplay*. For example:
|
||||
~~~~~
|
||||
pload VISUALIZATION
|
||||
vinit
|
||||
vcolorscale cs –demo
|
||||
vcolorscale cs -demo
|
||||
pload MODELING
|
||||
box b 100 100 100
|
||||
vdisplay b
|
||||
|
||||
@ -59,8 +59,8 @@ OPEN CASCADE S.A.S.
|
||||
|
||||
**Mac** and the Mac logo are trademarks of Apple Inc., registered in the U.S. and other countries.
|
||||
|
||||
Acknowledgements
|
||||
------------------
|
||||
Acknowledgments
|
||||
-----------------
|
||||
|
||||
The following parties are acknowledged for producing tools which are used within
|
||||
Open CASCADE Technology libraries or for release preparation.
|
||||
@ -115,7 +115,7 @@ implementation of 3D viewer. OpenGL specification is developed by the
|
||||
Khronos group, http://www.khronos.org/opengl/. OCCT code includes header
|
||||
file *glext.h* obtained from Khronos web site.
|
||||
|
||||
**VTK** - The **Visualization Toolkit (VTK)** is an open-source, freely available software system for 3D computer graphics, image processing and visualization. OCCT VIS component provides adaptation functionality for visualization of OCCT topological shapes by means of VTK library. If you need further information on VTK, please, refer to VTK Homepage http://www.vtk.org/.
|
||||
**VTK** -- The **Visualization Toolkit (VTK)** is an open-source, freely available software system for 3D computer graphics, image processing and visualization. OCCT VIS component provides adaptation functionality for visualization of OCCT topological shapes by means of VTK library. If you need further information on VTK, please, refer to VTK Homepage http://www.vtk.org/.
|
||||
|
||||
**Doxygen** developed by Dimitri van Heesch is open source documentation system for
|
||||
C++, C, Java, Objective-C, Python, IDL, PHP and C#. This product is used in Open CASCADE Technology
|
||||
@ -312,7 +312,7 @@ To run any Open CASCADE Technology application you need to set the environment v
|
||||
|
||||
You can define the environment variables with env.bat script located in the
|
||||
$CASROOT folder. This script accepts two arguments to be used:
|
||||
the version of Visual Studio (vc8 - vc12) and the architecture (win32 or win64).
|
||||
the version of Visual Studio (vc8 -- vc12) and the architecture (win32 or win64).
|
||||
|
||||
The additional environment settings necessary for compiling OCCT libraries and samples
|
||||
by Microsoft Visual Studio can be set using script custom.bat located in the same folder.
|
||||
@ -569,9 +569,9 @@ There are two samples are representing usage OCCT framework on Android mobile pl
|
||||
jniviewer
|
||||
@image html /overview/images/samples_java_android_occt.jpg
|
||||
@image latex /overview/images/samples_java_android_occt.jpg
|
||||
Java - See \subpage samples_java_android_occt "Readme" for details.
|
||||
Java -- See \subpage samples_java_android_occt "Readme" for details.
|
||||
|
||||
AndroidQt
|
||||
@image html /overview/images/samples_qml_android_occt.jpg
|
||||
@image latex /overview/images/samples_qml_android_occt.jpg
|
||||
Qt - See \subpage samples_qml_android_occt "Readme" for details.
|
||||
Qt -- See \subpage samples_qml_android_occt "Readme" for details.
|
||||
|
||||
@ -75,13 +75,13 @@ Geometry types and utilities provide geometric data structures and services for:
|
||||
* Calculation of extrema between geometric objects.
|
||||
|
||||
Topology defines relationships between simple geometric entities. A shape, which is a basic topological entity, can be divided into components (sub-shapes):
|
||||
* Vertex – a zero-dimensional shape corresponding to a point;
|
||||
* Edge - a shape corresponding to a curve and bounded by a vertex at each extremity;
|
||||
* Wire - a sequence of edges connected by their vertices;
|
||||
* Face - a part of a plane (in 2D) or a surface (in 3D) bounded by wires;
|
||||
* Shell - a collection of faces connected by edges of their wire boundaries;
|
||||
* Solid - a finite closed part of 3D space bounded by shells;
|
||||
* Compound solid - a collection of solids connected by faces of their shell boundaries.
|
||||
* Vertex -- a zero-dimensional shape corresponding to a point;
|
||||
* Edge -- a shape corresponding to a curve and bounded by a vertex at each extremity;
|
||||
* Wire -- a sequence of edges connected by their vertices;
|
||||
* Face -- a part of a plane (in 2D) or a surface (in 3D) bounded by wires;
|
||||
* Shell -- a collection of faces connected by edges of their wire boundaries;
|
||||
* Solid -- a finite closed part of 3D space bounded by shells;
|
||||
* Compound solid -- a collection of solids connected by faces of their shell boundaries.
|
||||
|
||||
Complex shapes can be defined as assemblies of simpler entities.
|
||||
|
||||
@ -123,9 +123,9 @@ Top-level API provides the following functionality:
|
||||
* Spheres;
|
||||
* Toruses.
|
||||
* Kinematic Modeling:
|
||||
* Prisms - linear sweeps;
|
||||
* Revolutions - rotational sweeps;
|
||||
* Pipes - general-form sweeps;
|
||||
* Prisms -- linear sweeps;
|
||||
* Revolutions -- rotational sweeps;
|
||||
* Pipes -- general-form sweeps;
|
||||
* Lofting.
|
||||
|
||||
@figure{/technical_overview/images/0001.png "Shapes containing pipes with variable radius produced by sweeping"}
|
||||
|
||||
@ -30,12 +30,12 @@ The operator can be represented as:
|
||||
<i>R<sub>B</sub>=B<sub>j</sub> (G<sub>1</sub>, G<sub>2</sub>),</i>
|
||||
|
||||
where:
|
||||
* *R<sub>B</sub>* - result of the operation;
|
||||
* *B<sub>j</sub>* - operation of type *j* (Common, Fuse, Cut);
|
||||
* *R<sub>B</sub>* -- result of the operation;
|
||||
* *B<sub>j</sub>* -- operation of type *j* (Common, Fuse, Cut);
|
||||
* *G<sub>1</sub>={S<sub>11</sub>, S<sub>12</sub> ... S<sub>1n1</sub>}* group of arguments (Objects);
|
||||
* *G<sub>2</sub>={S<sub>21</sub>, S<sub>22</sub> ... S<sub>2n2</sub>}* group of arguments (Tools);
|
||||
* *n<sub>1</sub>* - Number of arguments in *Objects* group;
|
||||
* *n<sub>2</sub>* - Number of arguments in *Tools* group.
|
||||
* *n<sub>1</sub>* -- Number of arguments in *Objects* group;
|
||||
* *n<sub>2</sub>* -- Number of arguments in *Tools* group.
|
||||
|
||||
|
||||
**Note** There is an operation *Cut21*, which is an extension for forward Cut operation, i.e <i>Cut21=Cut(G2, G1)</i>.
|
||||
@ -49,9 +49,9 @@ The GFA operator can be represented as:
|
||||
<i>R<sub>GF</sub> = GF (S<sub>1</sub>, S<sub>2</sub> ... S<sub>n</sub>), </i>
|
||||
|
||||
where
|
||||
* *R<sub>GF</sub>* - result of the operation,
|
||||
* *S<sub>1</sub>, S<sub>2</sub> ... S<sub>n</sub>* - arguments of the operation,
|
||||
* *n* - number of arguments.
|
||||
* *R<sub>GF</sub>* -- result of the operation,
|
||||
* *S<sub>1</sub>, S<sub>2</sub> ... S<sub>n</sub>* -- arguments of the operation,
|
||||
* *n* -- number of arguments.
|
||||
|
||||
The result of the Boolean operator, *R<sub>B</sub>*, can be obtained from *R<sub>GF</sub>*.
|
||||
|
||||
@ -79,11 +79,11 @@ The PA operator can be represented as follows:
|
||||
|
||||
<i>R<sub>PA</sub>=PA (G<sub>1</sub>, G<sub>2</sub>),</i>
|
||||
where:
|
||||
* <i>R<sub>PA</sub></i> - is the result of the operation;
|
||||
* <i>R<sub>PA</sub></i> -- is the result of the operation;
|
||||
* *G<sub>1</sub>={S<sub>11</sub>, S<sub>12</sub> ... S<sub>1n1</sub>}* group of arguments (Objects);
|
||||
* *G<sub>2</sub>={S<sub>21</sub>, S<sub>22</sub> ... S<sub>2n2</sub>}* group of arguments (Tools);
|
||||
* *n<sub>1</sub>* - Number of arguments in *Objects* group;
|
||||
* *n<sub>2</sub>* - Number of arguments in *Tools* group.
|
||||
* *n<sub>1</sub>* -- Number of arguments in *Objects* group;
|
||||
* *n<sub>2</sub>* -- Number of arguments in *Tools* group.
|
||||
|
||||
The result *R<sub>PA</sub>* can be obtained from *R<sub>GF</sub>* .
|
||||
|
||||
@ -105,9 +105,9 @@ The fact that the *R<sub>GF</sub>* contains the components of *R<sub>PA</sub>* a
|
||||
The Section operator *SA* can be applied to arbitrary number of arguments in terms of *TopoDS_Shape*. The result of *SA* contains vertices and edges in accordance with interferences between the arguments
|
||||
The SA operator can be represented as follows:
|
||||
<i>R<sub>SA</sub>=SA(S1, S2… Sn)</i>, where
|
||||
* <i>R<sub>SA</sub></i> – is result of the operation;
|
||||
* <i>S1, S2 … Sn</i> - Arguments of the operation;
|
||||
* *n* - Number of arguments.
|
||||
* <i>R<sub>SA</sub></i> -- the operation result;
|
||||
* <i>S1, S2 ... Sn</i> -- the operation arguments;
|
||||
* *n* -- the number of arguments.
|
||||
|
||||
@subsection occt_algorithms_2_2 Parts of algorithms
|
||||
|
||||
@ -127,7 +127,7 @@ This chapter provides the background terms and definitions that are necessary to
|
||||
|
||||
There are two groups of interferences.
|
||||
|
||||
At first, each shape having a boundary representation (vertex, edge, face) has an internal value of geometrical tolerance. The shapes interfere with each other in terms of their tolerances. The shapes that have a boundary representation interfere when there is a part of 3D space where the distance between the underlying geometry of shapes is less or equal to the sum of tolerances of the shapes. Three types of shapes - vertex, edge and face - produce six types of **BRep interferences:**
|
||||
At first, each shape having a boundary representation (vertex, edge, face) has an internal value of geometrical tolerance. The shapes interfere with each other in terms of their tolerances. The shapes that have a boundary representation interfere when there is a part of 3D space where the distance between the underlying geometry of shapes is less or equal to the sum of tolerances of the shapes. Three types of shapes: vertex, edge and face -- produce six types of **BRep interferences:**
|
||||
* Vertex/Vertex,
|
||||
* Vertex/Edge,
|
||||
* Vertex/Face,
|
||||
@ -350,7 +350,7 @@ If the pave blocks *PBi* geometrically coincide with a face *Fj*, the pave block
|
||||
|
||||
In general case a common block *CB* contains:
|
||||
* Pave blocks *PBi (i=0,1,2, 3… NbPB)*.
|
||||
* A set of faces *Fj (j=0,1... NbF), NbF* - number of faces.
|
||||
* A set of faces *Fj (j=0,1... NbF), NbF* -- number of faces.
|
||||
|
||||
|
||||
@subsection occt_algorithms_3_6 FaceInfo
|
||||
@ -702,12 +702,12 @@ The input data for this step is the DS after computing Face/Face interferences.
|
||||
|
||||
| No | Contents | Implementation |
|
||||
| :---- | :---- | :---- |
|
||||
| 1 | For each Face/Face interference *nFi, nFj*, retrieve @ref occt_algorithms_4_6 "FaceInfo". Create draft vertices from intersection points *VPk (k=1, 2…, NbVP)*, where *NbVP* is the number of new vertices, and the draft vertex *VPk* is created from an intersection point if *VPk ≠ Vm (m = 0, 1, 2… NbVm)*, where *Vm* is an existing vertex for the faces *nFi* and *nF,j* (*On* or *In* in terms of *TopoDs_Shape*), *NbVm* is the number of vertices existing on faces *nFi* and *nF,j* and ≠ - means non-coincidence in terms of @ref occt_algorithms_3_1_1 "Vertex/Vertex interference". | *BOPAlgo_PaveFiller::MakeBlocks()* |
|
||||
| 1 | For each Face/Face interference *nFi, nFj*, retrieve @ref occt_algorithms_4_6 "FaceInfo". Create draft vertices from intersection points *VPk (k=1, 2…, NbVP)*, where *NbVP* is the number of new vertices, and the draft vertex *VPk* is created from an intersection point if *VPk ≠ Vm (m = 0, 1, 2… NbVm)*, where *Vm* is an existing vertex for the faces *nFi* and *nF,j* (*On* or *In* in terms of *TopoDs_Shape*), *NbVm* is the number of vertices existing on faces *nFi* and *nF,j* and ≠ -- means non-coincidence in terms of @ref occt_algorithms_3_1_1 "Vertex/Vertex interference". | *BOPAlgo_PaveFiller::MakeBlocks()* |
|
||||
| 2 | For each intersection curve *Cijk* | |
|
||||
| 2.1 | Create paves PVc for the curve using existing vertices, i.e. vertices On or In (in terms of *FaceInfo*) for faces *nFi* and *nFj*. Append the paves *PVc* | *BOPAlgo_PaveFiller::PutPaveOnCurve()* and *BOPDS_PaveBlock::AppendExtPave()* |
|
||||
| 2.2 | Create technological vertices *Vt*, which are the bounding points of an intersection curve (with the value of tolerance *Tol(Cijk)*). Each vertex *Vt* with parameter *Tt* on curve *Cijk* forms pave *PVt* on curve *Cijk*. Append technological paves. | *BOPAlgo_PaveFiller::PutBoundPaveOnCurve()* |
|
||||
| 2.3 | Create pave blocks *PBk* for the curve using paves <i>(k=1, 2…, NbPB)</i>, where *NbPB* is the number of pave blocks | *BOPAlgo_PaveFiller::MakeBlocks()* |
|
||||
| 2.4 | Build draft section edges *ESk* using the pave blocks <i>(k=1, 2…, NbES)</i>, where *NbES* is the number of draft section edges The draft section edge is created from a pave block *PBk* if *PBk* has state *In* or *On* for both faces *nFi* and *nF,j* and *PBk ≠ PBm (m=0, 1, 2… NbPBm)*, where *PBm* is an existing pave block for faces *nFi* and *nF,j* (*On* or *In* in terms of *FaceInfo*), *NbVm* is the number of existing pave blocks for faces *nFi* and *nF,j* and ≠ - means non-coincidence (in terms of @ref occt_algorithms_3_1_3 "Vertex/Face interference"). | *BOPTools_Tools::MakeEdge()* |
|
||||
| 2.4 | Build draft section edges *ESk* using the pave blocks <i>(k=1, 2…, NbES)</i>, where *NbES* is the number of draft section edges The draft section edge is created from a pave block *PBk* if *PBk* has state *In* or *On* for both faces *nFi* and *nF,j* and *PBk ≠ PBm (m=0, 1, 2… NbPBm)*, where *PBm* is an existing pave block for faces *nFi* and *nF,j* (*On* or *In* in terms of *FaceInfo*), *NbVm* is the number of existing pave blocks for faces *nFi* and *nF,j* and ≠ -- means non-coincidence (in terms of @ref occt_algorithms_3_1_3 "Vertex/Face interference"). | *BOPTools_Tools::MakeEdge()* |
|
||||
| 3 | Intersect the draft vertices *VPk (k=1, 2…, NbVP)* and the draft section edges *ESk (k=1, 2…, NbES)*. For this: a) create new object *PFn* of type *BOPAlgo_PaveFiller* with its own DS; b) use vertices *VPk* and edges *ESk* as arguments (in terms of @ref occt_algorithms_4_1 "Arguments") of *PFn*; c) invoke method *Perform()* for *PFn*. Resulting vertices *VPXk (k=1, 2… NbVPX)* and edges *ESXk (k=1, 2… NbESX)* are obtained via mapping between *VPk, ESk* and the results of *PVn*. | *BOPAlgo_PaveFiller::PostTreatFF()* |
|
||||
| 4 | Update face info (sections about pave blocks and vertices) | *BOPAlgo_PaveFiller::PerformFF()* |
|
||||
|
||||
@ -736,9 +736,9 @@ Building Part (BP) is used to
|
||||
* Provide history information (in terms of <i>\::Generated(), \::Modified()</i> and <i>\::IsDeleted()</i>)
|
||||
BP uses the DS prepared by *BOPAlgo_PaveFiller* described at chapter 5 as input data.
|
||||
BP is implemented in the following classes:
|
||||
* *BOPAlgo_Builder* - for the General Fuse operator (GFA).
|
||||
* *BOPAlgo_BOP* - for the Boolean Operation operator (BOA).
|
||||
* *BOPAlgo_Section* - for the Section operator (SA).
|
||||
* *BOPAlgo_Builder* -- for the General Fuse operator (GFA).
|
||||
* *BOPAlgo_BOP* -- for the Boolean Operation operator (BOA).
|
||||
* *BOPAlgo_Section* -- for the Section operator (SA).
|
||||
|
||||
@figure{/user_guides/boolean_operations/images/operations_image020.svg, "Diagram for BP classes"}
|
||||
|
||||
@ -934,8 +934,8 @@ This step is the same as @ref occt_algorithms_7_4_4 "Building Result of Type Ver
|
||||
|
||||
The input data for this step is:
|
||||
* *BOPAlgo_Builder* object after building result of type *Edge*;
|
||||
* Original Shape - Wire
|
||||
* *Type* - the shape type <i>(TopAbs_WIRE).</i>
|
||||
* Original Shape -- Wire
|
||||
* *Type* -- the shape type <i>(TopAbs_WIRE).</i>
|
||||
|
||||
| No | Contents | Implementation |
|
||||
| :---- | :---- | :----- |
|
||||
@ -981,8 +981,8 @@ This step is the same as @ref occt_algorithms_7_4_4 "Building Result of Type Ver
|
||||
@subsubsection occt_algorithms_7_4_11 Build Images for Shells
|
||||
The input data for this step is:
|
||||
* *BOPAlgo_Builder* object after building result of type face;
|
||||
* *Original Shape* - Shell;
|
||||
* *Type* - the type of the shape <i>(TopAbs_SHELL)</i>.
|
||||
* *Original Shape* -- a Shell;
|
||||
* *Type* -- the type of the shape <i>(TopAbs_SHELL)</i>.
|
||||
|
||||
The procedure is the same as for building images for wires.
|
||||
|
||||
@ -1011,8 +1011,8 @@ This step is the same as @ref occt_algorithms_7_4_4 "Building Result of Type Ver
|
||||
|
||||
The input data for this step is:
|
||||
* *BOPAlgo_Builder* object after building result of type solid;
|
||||
* *Original Shape* - Compsolid;
|
||||
* *Type* - the type of the shape <i>(TopAbs_COMPSOLID)</i>.
|
||||
* *Original Shape* -- a Compsolid;
|
||||
* *Type* -- the type of the shape <i>(TopAbs_COMPSOLID)</i>.
|
||||
|
||||
The procedure is the same as for building images for wires.
|
||||
|
||||
@ -1021,9 +1021,9 @@ This step is the same as @ref occt_algorithms_7_4_4 "Building Result of Type Ver
|
||||
|
||||
@subsubsection occt_algorithms_7_4_17 Build Images for Compounds
|
||||
The input data for this step is as follows:
|
||||
* *BOPAlgo_Builder* object after building results of type compsolid;
|
||||
* *Original Shape* - Compound;
|
||||
* *Type* - the type of the shape <i>(TopAbs_COMPOUND)</i>.
|
||||
* *BOPAlgo_Builder* object after building results of type *compsolid*;
|
||||
* *Original Shape* -- a Compound;
|
||||
* *Type* -- the type of the shape <i>(TopAbs_COMPOUND)</i>.
|
||||
|
||||
The procedure is the same as for building images for wires.
|
||||
|
||||
@ -1845,7 +1845,7 @@ The chapter describes the problems that are considered as Algorithm limitations.
|
||||
|
||||
A lot of failures of GFA algorithm can be caused by bugs in low-level algorithms: Intersection Algorithm, Projection Algorithm, Approximation Algorithm, Classification Algorithm, etc.
|
||||
* The Intersection, Projection and Approximation Algorithms are mostly used at the Intersection step. Their bugs directly cause wrong section results (i.e. incorrect section edges, section points, missing section edges or micro edges). It is not possible to obtain a correct final result of the GFA if a section result is wrong.
|
||||
* The Projection Algorithm is used at the Intersection step. The purpose of Projection Algorithm is to compute 2D-curves on surfaces. Wrong results here lead to incorrect or missing faces in the final GFA result.
|
||||
* The Projection Algorithm is used at the Intersection step. The purpose of Projection Algorithm is to compute 2D curves on surfaces. Wrong results here lead to incorrect or missing faces in the final GFA result.
|
||||
* The Classification Algorithm is used at the Building step. The bugs in the Classification Algorithm lead to errors in selecting shape parts (edges, faces, solids) and ultimately to a wrong final GFA result.
|
||||
|
||||
The description below illustrates some known GFA limitations. It does not enumerate exhaustively all problems that can arise in practice. Please, address cases of Algorithm failure to the OCCT Maintenance Service.
|
||||
@ -1863,11 +1863,11 @@ However, it is important to note that class *BRepCheck_Analyzer* is just a tool
|
||||
|
||||
Let us consider the following example:
|
||||
|
||||
The Analyzer checks distances between couples of 3D check-points <i>(Pi, PSi)</i> of edge *E* on face *F*. Point *Pi* is obtained from the 3D-curve (at the parameter *ti*) of the edge. *PSi* is obtained from 2D-curve (at the parameter *ti*) of the edge on surface *S* of face *F*. To be valid the distance should be less than *Tol(E)* for all couples of check-points. The number of these check-points is a pre-defined value (e.g. 23).
|
||||
The Analyzer checks distances between couples of 3D check-points <i>(Pi, PSi)</i> of edge *E* on face *F*. Point *Pi* is obtained from the 3D curve (at the parameter *ti*) of the edge. *PSi* is obtained from 2D curve (at the parameter *ti*) of the edge on surface *S* of face *F*. To be valid the distance should be less than *Tol(E)* for all couples of check-points. The number of these check-points is a predefined value (e.g. 23).
|
||||
|
||||
Let us consider the case when edge *E* is recognized valid (in terms of *BRepCheck_Analyzer*).
|
||||
|
||||
Further, after some operation, edge *E* is split into two edges *E1* and *E2*. Each split edge has the same 3D-curve and 2D-curve as the original edge *E*.
|
||||
Further, after some operation, edge *E* is split into two edges *E1* and *E2*. Each split edge has the same 3D curve and 2D curve as the original edge *E*.
|
||||
|
||||
Let us check *E1* (or E2). The Analyzer again checks the distances between the couples of check-points points <i>(Pi, PSi)</i>. The number of these check-points is the same constant value (23), but there is no guarantee that the distances will be less than *Tol(E)*, because the points chosen for *E1* are not the same as for *E*.
|
||||
|
||||
@ -2071,7 +2071,7 @@ The Fuzzy option is useful on the shapes with gaps or embeddings between the ent
|
||||
|
||||
Most likely, the Basic Operations will give unsatisfactory results on such models. The result may contain unexpected and unwanted small entities, faulty entities (in terms of *BRepCheck_Analyzer*), or there can be no result at all.
|
||||
|
||||
With the Fuzzy option it is possible to get the expected result - it is just necessary to define the appropriate value of fuzzy tolerance for the operation. To define that value it is necessary to measure the value of the gap (or the value of embedding depth) between the entities of the models, slightly increase it (to make the shifted entities coincident in terms of their tolerance plus the additional one) and pass it to the algorithm.
|
||||
With the Fuzzy option it is possible to get the expected result -- it is just necessary to define the appropriate value of fuzzy tolerance for the operation. To define that value it is necessary to measure the value of the gap (or the value of embedding depth) between the entities of the models, slightly increase it (to make the shifted entities coincident in terms of their tolerance plus the additional one) and pass it to the algorithm.
|
||||
|
||||
Fuzzy option is included in interface of Intersection Part (class *BOPAlgo_PaveFiller*) and application programming interface (class *BRepAlgoAPI_BooleanOperation*)
|
||||
|
||||
@ -2143,13 +2143,13 @@ The chapter contains some examples of the OCCT Boolean Component usage. The usag
|
||||
The package *BRepAlgoAPI* provides the Application Programming Interface of the Boolean Component.
|
||||
|
||||
The package consists of the following classes:
|
||||
* *BRepAlgoAPI_Algo* – the root class that provides the interface for algorithms.
|
||||
* *BRepAlgoAPI_BuilderAlgo* - the class API level of General Fuse algorithm.
|
||||
* *BRepAlgoAPI_BooleanOperation* – the root class for the classes *BRepAlgoAPI_Fuse*. *BRepAlgoAPI_Common*, *BRepAlgoAPI_Cut* and *BRepAlgoAPI_Section*.
|
||||
* *BRepAlgoAPI_Fuse* – the class provides Boolean fusion operation.
|
||||
* *BRepAlgoAPI_Common* - the class provides Boolean common operation.
|
||||
* *BRepAlgoAPI_Cut* - the class provides Boolean cut operation.
|
||||
* *BRepAlgoAPI_Section* - the class provides Boolean section operation.
|
||||
* *BRepAlgoAPI_Algo* -- the root class that provides the interface for algorithms.
|
||||
* *BRepAlgoAPI_BuilderAlgo* -- the class API level of General Fuse algorithm.
|
||||
* *BRepAlgoAPI_BooleanOperation* -- the root class for the classes *BRepAlgoAPI_Fuse*. *BRepAlgoAPI_Common*, *BRepAlgoAPI_Cut* and *BRepAlgoAPI_Section*.
|
||||
* *BRepAlgoAPI_Fuse* -- the class provides Boolean fusion operation.
|
||||
* *BRepAlgoAPI_Common* -- the class provides Boolean common operation.
|
||||
* *BRepAlgoAPI_Cut* -- the class provides Boolean cut operation.
|
||||
* *BRepAlgoAPI_Section* -- the class provides Boolean section operation.
|
||||
|
||||
@figure{/user_guides/boolean_operations/images/operations_image065.svg, "Diagram of BRepAlgoAPI package"}
|
||||
|
||||
@ -2158,8 +2158,8 @@ The detailed description of the classes can be found in corresponding .cdl files
|
||||
@subsection occt_algorithms_11b_2 Package BOPTest
|
||||
The package *BOPTest* provides the usage of the Boolean Component on Tcl level. The method *BOPTest::APICommands* contains corresponding Tcl commands:
|
||||
|
||||
* *bapibuild* – for General Fuse Operator;
|
||||
* *bapibop* – for Boolean Operator and Section Operator.
|
||||
* *bapibuild* -- for General Fuse Operator;
|
||||
* *bapibop* -- for Boolean Operator and Section Operator.
|
||||
|
||||
The examples of how to use the commands are below in this chapter.
|
||||
|
||||
|
||||
@ -121,13 +121,13 @@ Q\cdot(x\;y\;z\;1)^{T} =
|
||||
|
||||
*Q* may be a composition of matrices for the following elementary transformations:
|
||||
|
||||
* parallel translation –
|
||||
* parallel translation --
|
||||
@f$ \begin{pmatrix}
|
||||
1 &0 &0 &{q}_{1,4}\\
|
||||
0 &1 &0 &{q}_{2,4}\\
|
||||
0 &0 &1 &{q}_{3,4}
|
||||
\end{pmatrix}; @f$
|
||||
* rotation around an axis with a direction *D(D<sub>x</sub>, D<sub>y</sub>, D<sub>z</sub>)* by an angle @f$ \varphi @f$ –
|
||||
* rotation around an axis with a direction *D(D<sub>x</sub>, D<sub>y</sub>, D<sub>z</sub>)* by an angle @f$ \varphi @f$ --
|
||||
|
||||
@f[ \begin{pmatrix}
|
||||
D_{x}^{2} \cdot (1-cos(\varphi)) + cos(\varphi) &D_{x} \cdot D_{y} \cdot (1-cos(\varphi)) - D_{z} \cdot sin(\varphi) &D_{x} \cdot D_{z} \cdot (1-cos(\varphi)) + D_{y} \cdot sin(\varphi) &0\\
|
||||
@ -135,10 +135,10 @@ Q\cdot(x\;y\;z\;1)^{T} =
|
||||
D_{x} \cdot D_{z} \cdot (1-cos(\varphi)) - D_{y} \cdot sin(\varphi) &D_{y} \cdot D_{z} \cdot (1-cos(\varphi)) + D_{x} \cdot sin(\varphi) &D_{z}^{2} \cdot (1-cos(\varphi)) + cos(\varphi) &0
|
||||
\end{pmatrix}; @f]
|
||||
|
||||
* scaling – @f$ \begin{pmatrix} s &0 &0 &0\\ 0 &s &0 &0\\ 0 &0 &s &0 \end{pmatrix} @f$ where @f$ S \in (-\infty,\; \infty)/\left \{ 0 \right \}; @f$
|
||||
* central symmetry – @f$ \begin{pmatrix} -1 &0 &0 &0\\ 0 &-1 &0 &0\\ 0 &0 &-1 &0 \end{pmatrix}; @f$
|
||||
* axis symmetry – @f$ \begin{pmatrix} -1 &0 &0 &0\\ 0 &-1 &0 &0\\ 0 &0 &1 &0 \end{pmatrix}; @f$
|
||||
* plane symmetry – @f$ \begin{pmatrix} 1 &0 &0 &0\\ 0 &1 &0 &0\\ 0 &0 &-1 &0 \end{pmatrix}. @f$
|
||||
* scaling -- @f$ \begin{pmatrix} s &0 &0 &0\\ 0 &s &0 &0\\ 0 &0 &s &0 \end{pmatrix} @f$ where @f$ S \in (-\infty,\; \infty)/\left \{ 0 \right \}; @f$
|
||||
* central symmetry -- @f$ \begin{pmatrix} -1 &0 &0 &0\\ 0 &-1 &0 &0\\ 0 &0 &-1 &0 \end{pmatrix}; @f$
|
||||
* axis symmetry -- @f$ \begin{pmatrix} -1 &0 &0 &0\\ 0 &-1 &0 &0\\ 0 &0 &1 &0 \end{pmatrix}; @f$
|
||||
* plane symmetry -- @f$ \begin{pmatrix} 1 &0 &0 &0\\ 0 &1 &0 &0\\ 0 &0 &-1 &0 \end{pmatrix}. @f$
|
||||
|
||||
\<location data 2\> is interpreted as a composition of locations raised to a power and placed above this \<location data 2\> in the section \<locations\>. \<location data 2\> is a sequence @f$l_{1}p_{1} ... l_{n}p_{n}@f$ of @f$ n \geq 0 @f$ integer pairs @f$ l_{i}p_{i} \; (1 \leq i \leq n) @f$. \<flag\> 0 is the indicator of the sequence end. The sequence is interpreted as a composition @f$ L_{l_{1}}^{p_{1}} \cdot ... \cdot L_{l_{n}}^{p_{n}} @f$ where @f$ L_{l_{i}} @f$ is a location from @f$ l_{i} @f$-th \<location record\> in the section locations. \<location record\> numbering starts from 1.
|
||||
|
||||
@ -1621,22 +1621,22 @@ An example of section shapes and a whole *.brep file are given in chapter 7 @re
|
||||
|
||||
\<shape flag word\> @f$ f_{1}\; f_{2}\; f_{3}\; f_{4}\; f_{5}\; f_{6}\; f_{7} @f$ \<flag\>s @f$ f_{i}\;(1\leq i \leq 7) @f$ are interpreted as shape flags in the following way:
|
||||
|
||||
* @f$ f_{1} @f$ – free;
|
||||
* @f$ f_{2} @f$ – modified;
|
||||
* @f$ f_{3} @f$ – IGNORED(version 1) \\ checked (version 2);
|
||||
* @f$ f_{4} @f$ – orientable;
|
||||
* @f$ f_{5} @f$ – closed;
|
||||
* @f$ f_{6} @f$ – infinite;
|
||||
* @f$ f_{7} @f$ – convex.
|
||||
* @f$ f_{1} @f$ -- free;
|
||||
* @f$ f_{2} @f$ -- modified;
|
||||
* @f$ f_{3} @f$ -- IGNORED(version 1) \\ checked (version 2);
|
||||
* @f$ f_{4} @f$ -- orientable;
|
||||
* @f$ f_{5} @f$ -- closed;
|
||||
* @f$ f_{6} @f$ -- infinite;
|
||||
* @f$ f_{7} @f$ -- convex.
|
||||
|
||||
The flags are used in a special way [1].
|
||||
|
||||
\<shape subshape orientation\> is interpreted in the following way:
|
||||
|
||||
* + – forward;
|
||||
* - – reversed;
|
||||
* i – internal;
|
||||
* e – external.
|
||||
* + -- forward;
|
||||
* - -- reversed;
|
||||
* i -- internal;
|
||||
* e -- external.
|
||||
|
||||
\<shape subshape orientation\> is used in a special way [1].
|
||||
|
||||
@ -1644,14 +1644,14 @@ The flags are used in a special way [1].
|
||||
|
||||
\<shape subrecord\> types are interpreted in the following way:
|
||||
|
||||
* "Ve" – vertex;
|
||||
* "Ed" – edge;
|
||||
* "Wi" – wire;
|
||||
* "Fa" – face;
|
||||
* "Sh" – shell;
|
||||
* "So" – solid;
|
||||
* "CS" – compsolid;
|
||||
* "Co" – compound.
|
||||
* "Ve" -- vertex;
|
||||
* "Ed" -- edge;
|
||||
* "Wi" -- wire;
|
||||
* "Fa" -- face;
|
||||
* "Sh" -- shell;
|
||||
* "So" -- solid;
|
||||
* "CS" -- compsolid;
|
||||
* "Co" -- compound.
|
||||
|
||||
\<shape final record\> determines the orientation and location for the whole model.
|
||||
|
||||
|
||||
@ -72,7 +72,7 @@ Declaration of available plug-ins is done through the special resource file(s).
|
||||
|
||||
@subsubsection occt_draw_1_3_1 Launching DRAW Test Harness
|
||||
|
||||
Test Harness executable *DRAWEXE* is located in the <i>$CASROOT/\<platform\>/bin</i> directory (where \<platform\> is Win for Windows and Linux for Linux operating systems). Prior to launching it is important to make sure that the environment is correctly set-up (usually this is done automatically after the installation process on Windows or after launching specific scripts on Linux).
|
||||
Test Harness executable *DRAWEXE* is located in the <i>$CASROOT/\<platform\>/bin</i> directory (where \<platform\> is Win for Windows and Linux for Linux operating systems). Prior to launching it is important to make sure that the environment is correctly setup (usually this is done automatically after the installation process on Windows or after launching specific scripts on Linux).
|
||||
|
||||
|
||||
@subsubsection occt_draw_1_3_2 Plug-in resource file
|
||||
@ -103,8 +103,8 @@ pload [-PluginFileName] [[Key1] [Key2]...]
|
||||
|
||||
where:
|
||||
|
||||
* <i>-PluginFileName</i> - defines the name of a plug-in resource file (prefix "-" is mandatory) described above. If this parameter is omitted then the default name *DrawPlugin* is used.
|
||||
* *Key…* - defines the key(s) enumerating plug-ins to be loaded. If no keys are specified then the key named *DEFAULT* is used (if there is no such key in the file then no plug-ins are loaded).
|
||||
* <i>-PluginFileName</i> -- defines the name of a plug-in resource file (prefix "-" is mandatory) described above. If this parameter is omitted then the default name *DrawPlugin* is used.
|
||||
* *Key* -- defines the key(s) enumerating plug-ins to be loaded. If no keys are specified then the key named *DEFAULT* is used (if there is no such key in the file then no plug-ins are loaded).
|
||||
|
||||
According to the OCCT resource file management rules, to access the resource file the environment variable *CSF_PluginFileNameDefaults* (and optionally *CSF_PluginFileNameUserDefaults*) must be set and point to the directory storing the resource file. If it is omitted then the plug-in resource file will be searched in the <i>$CASROOT/src/DrawResources</i> directory.
|
||||
|
||||
@ -850,7 +850,7 @@ TopoDS_Solid B = DBRep::Get(argv[1]);
|
||||
|
||||
@section occt_draw_4 Graphic Commands
|
||||
|
||||
Graphic commands are used to manage the Draw graphic system. Draw provides a 2d and a 3d viewer with up to 30 views. Views are numbered and the index of the view is displayed in the window’s title. Objects are displayed in all 2d views or in all 3d views, depending on their type. 2d objects can only be viewed in 2d views while 3d objects – only in 3d views correspondingly.
|
||||
Graphic commands are used to manage the Draw graphic system. Draw provides a 2d and a 3d viewer with up to 30 views. Views are numbered and the index of the view is displayed in the window’s title. Objects are displayed in all 2d views or in all 3d views, depending on their type. 2d objects can only be viewed in 2d views while 3d objects -- only in 3d views correspondingly.
|
||||
|
||||
@subsection occt_draw_4_1 Axonometric viewer
|
||||
|
||||
@ -1274,7 +1274,7 @@ Graphic operations are buffered by Draw (and also by the X system). Usually the
|
||||
|
||||
See also: @ref occt_draw_4_1_11 "pick" command.
|
||||
|
||||
@subsection occt_draw_4_2 AIS viewer – view commands
|
||||
@subsection occt_draw_4_2 AIS viewer -- view commands
|
||||
|
||||
@subsubsection occt_draw_4_2_1 vinit
|
||||
|
||||
@ -1544,13 +1544,13 @@ vstereo [0|1] [-mode Mode] [-reverse {0|1}] [-anaglyph Filter]
|
||||
|
||||
Control stereo output mode.
|
||||
Available modes for -mode:
|
||||
* quadBuffer - OpenGL QuadBuffer stereo, requires driver support. Should be called BEFORE vinit!
|
||||
* anaglyph - Anaglyph glasses
|
||||
* rowInterlaced - row-interlaced display
|
||||
* columnInterlaced - column-interlaced display
|
||||
* chessBoard - chess-board output
|
||||
* sideBySide - horizontal pair
|
||||
* overUnder - vertical pair
|
||||
* quadBuffer -- OpenGL QuadBuffer stereo, requires driver support. Should be called BEFORE vinit!
|
||||
* anaglyph -- Anaglyph glasses
|
||||
* rowInterlaced -- row-interlaced display
|
||||
* columnInterlaced -- column-interlaced display
|
||||
* chessBoard -- chess-board output
|
||||
* sideBySide -- horizontal pair
|
||||
* overUnder -- vertical pair
|
||||
Available Anaglyph filters for -anaglyph:
|
||||
* redCyan, redCyanSimple, yellowBlue, yellowBlueSimple, greenMagentaSimple
|
||||
|
||||
@ -1576,7 +1576,7 @@ vfrustumculling [toEnable]
|
||||
Enables/disables objects clipping.
|
||||
|
||||
|
||||
@subsection occt_draw_4_3 AIS viewer – display commands
|
||||
@subsection occt_draw_4_3 AIS viewer -- display commands
|
||||
|
||||
@subsubsection occt_draw_4_3_1 vdisplay
|
||||
|
||||
@ -1607,7 +1607,7 @@ Local selection context will be opened if there is not any.
|
||||
* *trsfPersPos* sets an anchor point for transform persistence.
|
||||
* *2d|-2dTopDown* displays object in screen coordinates.
|
||||
* *dispmode* sets display mode for objects.
|
||||
* *highmode* sets hilight mode for objects.
|
||||
* *highmode* sets highlight mode for objects.
|
||||
* *redisplay* recomputes presentation of objects.
|
||||
|
||||
**Example:**
|
||||
@ -1776,7 +1776,7 @@ vaspects [-noupdate|-update] [name1 [name2 [...]] | -defaults]
|
||||
Manage presentation properties of all, selected or named objects.
|
||||
When *-subshapes* is specified than following properties will be assigned to specified sub-shapes.
|
||||
When *-defaults* is specified than presentation properties will be assigned to all objects that have not their own specified properties and to all objects to be displayed in the future.
|
||||
If *-defaults* is used there should not be any objects' names and -subshapes specifier.
|
||||
If *-defaults* is used there should not be any names of objects and *-subshapes* specifier.
|
||||
|
||||
Aliases:
|
||||
~~~~~
|
||||
@ -2009,8 +2009,8 @@ vstate [-entities] [-hasSelected] [name1] ... [nameN]
|
||||
~~~~~
|
||||
|
||||
Reports show/hidden state for selected or named objects
|
||||
* *entities* - print low-level information about detected entities
|
||||
* *hasSelected* - prints 1 if context has selected shape and 0 otherwise
|
||||
* *entities* -- prints low-level information about detected entities;
|
||||
* *hasSelected* -- prints 1 if the context has a selected shape and 0 otherwise.
|
||||
|
||||
@subsubsection occt_draw_4_3_25 vraytrace
|
||||
|
||||
@ -2032,17 +2032,17 @@ vrenderparams [-rayTrace|-raster] [-rayDepth 0..10] [-shadows {on|off}]
|
||||
~~~~~
|
||||
|
||||
Manages rendering parameters:
|
||||
* rayTrace - Enables GPU ray-tracing
|
||||
* raster - Disables GPU ray-tracing
|
||||
* rayDepth - Defines maximum ray-tracing depth
|
||||
* shadows - Enables/disables shadows rendering
|
||||
* reflections - Enables/disables specular reflections
|
||||
* fsaa - Enables/disables adaptive anti-aliasing
|
||||
* gleam - Enables/disables transparency shadow effects
|
||||
* gi - Enables/disables global illumination effects
|
||||
* brng - Enables/disables blocked RNG (fast coherent PT)
|
||||
* env - Enables/disables environment map background
|
||||
* shadingModel - Controls shading model from enumeration color, flat, gouraud, phong
|
||||
* rayTrace -- Enables GPU ray-tracing
|
||||
* raster -- Disables GPU ray-tracing
|
||||
* rayDepth -- Defines maximum ray-tracing depth
|
||||
* shadows -- Enables/disables shadows rendering
|
||||
* reflections -- Enables/disables specular reflections
|
||||
* fsaa -- Enables/disables adaptive anti-aliasing
|
||||
* gleam -- Enables/disables transparency shadow effects
|
||||
* gi -- Enables/disables global illumination effects
|
||||
* brng -- Enables/disables blocked RNG (fast coherent PT)
|
||||
* env -- Enables/disables environment map background
|
||||
* shadingModel -- Controls shading model from enumeration color, flat, gouraud, phong
|
||||
|
||||
Unlike vcaps, these parameters dramatically change visual properties.
|
||||
Command is intended to control presentation quality depending on hardware capabilities and performance.
|
||||
@ -2082,7 +2082,7 @@ vinit
|
||||
vsetcolorbg 200 0 200
|
||||
~~~~~
|
||||
|
||||
@subsection occt_draw_4_4 AIS viewer – object commands
|
||||
@subsection occt_draw_4_4 AIS viewer -- object commands
|
||||
|
||||
@subsubsection occt_draw_4_4_1 vtrihedron
|
||||
|
||||
@ -2186,8 +2186,8 @@ vplane name [PlaneName] [PointName]
|
||||
|
||||
Creates a plane from named or interactively selected entities.
|
||||
TypeOfSensitivity:
|
||||
* 0 - Interior
|
||||
* 1 - Boundary
|
||||
* 0 -- Interior
|
||||
* 1 -- Boundary
|
||||
|
||||
**Example:**
|
||||
~~~~~
|
||||
@ -2275,15 +2275,15 @@ vselmode [object] mode_number is_turned_on=(1|0)
|
||||
Sets the selection mode for an object. If the object value is not defined, the selection mode is set for all displayed objects.
|
||||
*Mode_number* is non-negative integer that has different meaning for different interactive object classes.
|
||||
For shapes the following *mode_number* values are allowed:
|
||||
* 0 - shape
|
||||
* 1 - vertex
|
||||
* 2 - edge
|
||||
* 3 - wire
|
||||
* 4 - face
|
||||
* 5 - shell
|
||||
* 6 - solid
|
||||
* 7 - compsolid
|
||||
* 8 - compound
|
||||
* 0 -- shape
|
||||
* 1 -- vertex
|
||||
* 2 -- edge
|
||||
* 3 -- wire
|
||||
* 4 -- face
|
||||
* 5 -- shell
|
||||
* 6 -- solid
|
||||
* 7 -- compsolid
|
||||
* 8 -- compound
|
||||
*is_turned_on* is:
|
||||
* 1 if mode is to be switched on
|
||||
* 0 if mode is to be switched off
|
||||
@ -2361,18 +2361,18 @@ vpointcloud name shape [-randColor] [-normals] [-noNormals]
|
||||
|
||||
Creates an interactive object for an arbitary set of points from the triangulated shape.
|
||||
Additional options:
|
||||
* *randColor* - generate random color per point
|
||||
* *normals* - generate normal per point (default)
|
||||
* *noNormals* - do not generate normal per point
|
||||
* *randColor* -- generate random color per point
|
||||
* *normals* -- generate normal per point (default)
|
||||
* *noNormals* -- do not generate normal per point
|
||||
|
||||
~~~~~
|
||||
vpointcloud name x y z r npts {surface|volume} [-randColor] [-normals] [-noNormals]
|
||||
~~~~~
|
||||
Creates an arbitrary set of points (npts) randomly distributed on a spheric surface or within a spheric volume (x y z r).
|
||||
Additional options:
|
||||
* *randColor* - generate random color per point
|
||||
* *normals* - generate normal per point (default)
|
||||
* *noNormals* - do not generate normal per point
|
||||
* *randColor* -- generate random color per point
|
||||
* *normals* -- generate normal per point (default)
|
||||
* *noNormals* -- do not generate normal per point
|
||||
|
||||
**Example:**
|
||||
~~~~~
|
||||
@ -2385,21 +2385,21 @@ vfit
|
||||
|
||||
Syntax:
|
||||
~~~~~
|
||||
vclipplane maxplanes <view_name> - gets plane limit for the view.
|
||||
vclipplane create <plane_name> - creates a new plane.
|
||||
vclipplane delete <plane_name> - delete a plane.
|
||||
vclipplane clone <source_plane> <plane_name> - clones the plane definition.
|
||||
vclipplane set/unset <plane_name> object <object list> - sets/unsets the plane for an IO.
|
||||
vclipplane set/unset <plane_name> view <view list> - sets/unsets plane for a view.
|
||||
vclipplane change <plane_name> on/off - turns clipping on/off.
|
||||
vclipplane change <plane_name> equation <a> <b> <c> <d> - changes plane equation.
|
||||
vclipplane change <plane_name> capping on/off - turns capping on/off.
|
||||
vclipplane change <plane_name> capping color <r> <g> <b> - sets color.
|
||||
vclipplane change <plane name> capping texname <texture> - sets texture.
|
||||
vclipplane change <plane_name> capping texscale <sx> <sy> - sets texture scale.
|
||||
vclipplane change <plane_name> capping texorigin <tx> <ty> - sets texture origin.
|
||||
vclipplane change <plane_name> capping texrotate <angle> - sets texture rotation.
|
||||
vclipplane change <plane_name> capping hatch on/off/<id> - sets hatching mask.
|
||||
vclipplane maxplanes <view_name> -- gets plane limit for the view.
|
||||
vclipplane create <plane_name> -- creates a new plane.
|
||||
vclipplane delete <plane_name> -- deletes a plane.
|
||||
vclipplane clone <source_plane> <plane_name> -- clones the plane definition.
|
||||
vclipplane set/unset <plane_name> object <object list> -- sets/unsets the plane for an IO.
|
||||
vclipplane set/unset <plane_name> view <view list> -- sets/unsets plane for a view.
|
||||
vclipplane change <plane_name> on/off -- turns clipping on/off.
|
||||
vclipplane change <plane_name> equation <a> <b> <c> <d> -- changes plane equation.
|
||||
vclipplane change <plane_name> capping on/off -- turns capping on/off.
|
||||
vclipplane change <plane_name> capping color <r> <g> <b> -- sets color.
|
||||
vclipplane change <plane name> capping texname <texture> -- sets texture.
|
||||
vclipplane change <plane_name> capping texscale <sx> <sy> -- sets texture scale.
|
||||
vclipplane change <plane_name> capping texorigin <tx> <ty> -- sets texture origin.
|
||||
vclipplane change <plane_name> capping texrotate <angle> -- sets texture rotation.
|
||||
vclipplane change <plane_name> capping hatch on/off/<id> -- sets hatching mask.
|
||||
~~~~~
|
||||
|
||||
Manages clipping planes
|
||||
@ -2498,7 +2498,7 @@ vmovedim dim1 -10 30 0
|
||||
~~~~~
|
||||
|
||||
|
||||
@subsection occt_draw_4_5 AIS viewer – Mesh Visualization Service
|
||||
@subsection occt_draw_4_5 AIS viewer -- Mesh Visualization Service
|
||||
|
||||
**MeshVS** (Mesh Visualization Service) component provides flexible means of displaying meshes with associated pre- and post- processor data.
|
||||
|
||||
@ -2543,10 +2543,10 @@ meshselmode meshname selectionmode
|
||||
~~~~~
|
||||
|
||||
Changes the selection mode of object **meshname**. The *selectionmode* is integer OR-combination of mode flags. The basic flags are the following:
|
||||
* *1* – node selection;
|
||||
* *2* – 0D elements (not supported in STL);
|
||||
* *4* – links (not supported in STL);
|
||||
* *8* – faces.
|
||||
* *1* -- node selection;
|
||||
* *2* -- 0D elements (not supported in STL);
|
||||
* *4* -- links (not supported in STL);
|
||||
* *8* -- faces.
|
||||
|
||||
**Example:**
|
||||
~~~~~
|
||||
@ -2597,27 +2597,27 @@ meshmat meshname material
|
||||
Changes the material of object **meshname**.
|
||||
|
||||
*material* is represented with an integer value as follows (equivalent to enumeration *Graphic3d_NameOfMaterial*):
|
||||
* *0 - BRASS,*
|
||||
* *1 - BRONZE,*
|
||||
* *2 - COPPER,*
|
||||
* *3 - GOLD,*
|
||||
* *4 - PEWTER,*
|
||||
* *5 - PLASTER,*
|
||||
* *6 - PLASTIC,*
|
||||
* *7 - SILVER,*
|
||||
* *8 - STEEL,*
|
||||
* *9 - STONE,*
|
||||
* *10 - SHINY_PLASTIC,*
|
||||
* *11 - SATIN,*
|
||||
* *12 - METALIZED,*
|
||||
* *13 - NEON_GNC,*
|
||||
* *14 - CHROME,*
|
||||
* *15 - ALUMINIUM,*
|
||||
* *16 - OBSIDIAN,*
|
||||
* *17 - NEON_PHC,*
|
||||
* *18 - JADE,*
|
||||
* *19 - DEFAULT,*
|
||||
* *20 - UserDefined*
|
||||
* *0 -- BRASS,*
|
||||
* *1 -- BRONZE,*
|
||||
* *2 -- COPPER,*
|
||||
* *3 -- GOLD,*
|
||||
* *4 -- PEWTER,*
|
||||
* *5 -- PLASTER,*
|
||||
* *6 -- PLASTIC,*
|
||||
* *7 -- SILVER,*
|
||||
* *8 -- STEEL,*
|
||||
* *9 -- STONE,*
|
||||
* *10 -- SHINY_PLASTIC,*
|
||||
* *11 -- SATIN,*
|
||||
* *12 -- METALIZED,*
|
||||
* *13 -- NEON_GNC,*
|
||||
* *14 -- CHROME,*
|
||||
* *15 -- ALUMINIUM,*
|
||||
* *16 -- OBSIDIAN,*
|
||||
* *17 -- NEON_PHC,*
|
||||
* *18 -- JADE,*
|
||||
* *19 -- DEFAULT,*
|
||||
* *20 -- UserDefined*
|
||||
|
||||
**Example:**
|
||||
~~~~~
|
||||
@ -2949,7 +2949,7 @@ Syntax:
|
||||
IsInSession path
|
||||
~~~~~
|
||||
|
||||
Returns *0*, if **path** document is managed by the application session, *1* – otherwise.
|
||||
Returns *0*, if **path** document is managed by the application session, *1* -- otherwise.
|
||||
|
||||
**Example:**
|
||||
~~~~~
|
||||
@ -3183,7 +3183,7 @@ Syntax:
|
||||
NewCommand docname
|
||||
~~~~~
|
||||
|
||||
This is a short-cut for Commit and Open transaction.
|
||||
This is a shortcut for Commit and Open transaction.
|
||||
|
||||
**Example:**
|
||||
~~~~~
|
||||
@ -3765,7 +3765,7 @@ Finds or creates a Plane attribute at *entry* label and sets *plane* as generate
|
||||
|
||||
**Example:**
|
||||
~~~~~
|
||||
plane pl 10 20 30 –1 0 0
|
||||
plane pl 10 20 30 -1 0 0
|
||||
SetPlane D 0:2 pl
|
||||
~~~~~
|
||||
|
||||
@ -4695,7 +4695,7 @@ Syntax:
|
||||
~~~~~
|
||||
cone name [x y z [dx dy dz [ux uy uz]]] semi-angle radius
|
||||
~~~~~
|
||||
Creates a cone in the infinite coordinate system along the Z-axis. The radius is that of the circle at the intersection of the cone and the XY plane. The semi-angle is the angle formed by the cone relative to the axis; it should be between –90 and 90. If the radius is 0, the vertex is the origin.
|
||||
Creates a cone in the infinite coordinate system along the Z-axis. The radius is that of the circle at the intersection of the cone and the XY plane. The semi-angle is the angle formed by the cone relative to the axis; it should be between -90 and 90. If the radius is 0, the vertex is the origin.
|
||||
|
||||
**Example:**
|
||||
~~~~~
|
||||
@ -5765,11 +5765,11 @@ normals s (length = 10), disp normals
|
||||
range name value value
|
||||
~~~~~
|
||||
|
||||
* **orientation** assigns the orientation of shapes - simple and complex - to one of the following four values: *FORWARD, REVERSED, INTERNAL, EXTERNAL*.
|
||||
* **complement** changes the current orientation of shapes to its complement, *FORWARD - REVERSED, INTERNAL - EXTERNAL*.
|
||||
* **invert** creates a new shape which is a copy of the original with the orientation all subshapes reversed. For example, it may be useful to reverse the normals of a solid.
|
||||
* *normals** returns the assignment of colors to orientation values.
|
||||
* **range** defines the length of a selected edge by defining the values of a starting point and an end point.
|
||||
* **orientation** -- assigns the orientation of simple and complex shapes to one of the following four values: *FORWARD, REVERSED, INTERNAL, EXTERNAL*.
|
||||
* **complement** -- changes the current orientation of shapes to its complement: *FORWARD* to *REVERSED* and *INTERNAL* to *EXTERNAL*.
|
||||
* **invert** -- creates a copy of the original shape with a reversed orientation of all subshapes. For example, it may be useful to reverse the normals of a solid.
|
||||
* *normals** -- returns the assignment of colors to orientation values.
|
||||
* **range** -- defines the length of a selected edge by defining the values of a starting point and an end point.
|
||||
|
||||
**Example:**
|
||||
~~~~~
|
||||
@ -5851,7 +5851,7 @@ add name toname
|
||||
compound [name ...] compoundname
|
||||
~~~~~
|
||||
|
||||
**emptycopy** returns an empty shape with the same orientation, location, and geometry as the target shape, but with no sub-shapes. If the newname argument is not given, the new shape is stored with the same name. This command is used to modify a frozen shape. A frozen shape is a shape used by another one. To modify it, you must emptycopy it. Its subshape may be reinserted with the **add** command.
|
||||
**emptycopy** returns an empty shape with the same orientation, location, and geometry as the target shape, but with no sub-shapes. If the **newname** argument is not given, the new shape is stored with the same name. This command is used to modify a frozen shape. A frozen shape is a shape used by another one. To modify it, you must **emptycopy** it. Its subshape may be reinserted with the **add** command.
|
||||
|
||||
**add** inserts shape *C* into shape *S*. Verify that *C* and *S* reference compatible types of objects:
|
||||
* Any *Shape* can be added to a *Compound*.
|
||||
@ -5884,10 +5884,10 @@ checkshape [-top] shape [result] [-short]
|
||||
~~~~~
|
||||
|
||||
Where:
|
||||
* *top* – optional parameter, which allows checking only topological validity of a shape.
|
||||
* *shape*– the only required parameter which represents the name of the shape to check.
|
||||
* *result* – optional parameter which is the prefix of the output shape names.
|
||||
* *short* – a short description of the check.
|
||||
* *top* -- optional parameter, which allows checking only topological validity of a shape.
|
||||
* *shape* -- the only required parameter which represents the name of the shape to check.
|
||||
* *result* -- optional parameter which is the prefix of the output shape names.
|
||||
* *short* -- a short description of the check.
|
||||
|
||||
**checkshape** examines the selected object for topological and geometric coherence. The object should be a three dimensional shape.
|
||||
|
||||
@ -6385,7 +6385,7 @@ All these commands create solid blocks in the default coordinate system, using t
|
||||
|
||||
**psphere** creates a solid sphere centered on the origin. If two angles, *angle1* and *angle2*, are given, the solid will be limited by two planes at latitude *angle1* and *angle2*. The angles must be increasing and in the range -90,90.
|
||||
|
||||
**ptorus** creates a solid torus with the given radii, centered on the origin, which is a point along the z axis. If two angles increasing in degree in the range 0 – 360 are given, the solid will be bounded by two planar surfaces at those positions on the circle.
|
||||
**ptorus** creates a solid torus with the given radii, centered on the origin, which is a point along the z axis. If two angles increasing in degree in the range 0 -- 360 are given, the solid will be bounded by two planar surfaces at those positions on the circle.
|
||||
|
||||
**Example:**
|
||||
~~~~~
|
||||
@ -6424,11 +6424,11 @@ halfspace hr b_3 0.5 0.5 0.5
|
||||
|
||||
Sweeping creates shapes by sweeping out a shape along a defined path:
|
||||
|
||||
* **prism** sweeps along a direction.
|
||||
* **revol** sweeps around an axis.
|
||||
* **pipe** sweeps along a wire.
|
||||
* **mksweep** and **buildsweep** are commands to create sweeps by defining the arguments and algorithms.
|
||||
* **thrusections** creates a sweep from wire in different planes.
|
||||
* **prism** -- sweeps along a direction.
|
||||
* **revol** -- sweeps around an axis.
|
||||
* **pipe** -- sweeps along a wire.
|
||||
* **mksweep** and **buildsweep** -- to create sweeps by defining the arguments and algorithms.
|
||||
* **thrusections** -- creates a sweep from wire in different planes.
|
||||
|
||||
|
||||
@subsubsection occt_draw_7_4_1 prism
|
||||
@ -6511,12 +6511,12 @@ options are :
|
||||
* *-G guide*
|
||||
|
||||
These commands are used to create a shape from wires. One wire is designated as the contour that defines the direction; it is called the spine. At least one other wire is used to define the the sweep profile.
|
||||
* **mksweep** initializes the sweep creation and defines the wire to be used as the spine.
|
||||
* **addsweep** defines the wire to be used as the profile.
|
||||
* **deletesweep** cancels the choice of profile wire, without leaving the mksweep mode. You can re-select a profile wire.
|
||||
* **setsweep** commands the algorithms used for the construction of the sweep.
|
||||
* **simulsweep** can be used to create a preview of the shape. [n] is the number of sections that are used to simulate the sweep.
|
||||
* **buildsweep** creates the sweep using the arguments defined by all the commands.
|
||||
* **mksweep** -- initializes the sweep creation and defines the wire to be used as the spine.
|
||||
* **addsweep** -- defines the wire to be used as the profile.
|
||||
* **deletesweep** -- cancels the choice of profile wire, without leaving the mksweep mode. You can re-select a profile wire.
|
||||
* **setsweep** -- commands the algorithms used for the construction of the sweep.
|
||||
* **simulsweep** -- can be used to create a preview of the shape. [n] is the number of sections that are used to simulate the sweep.
|
||||
* **buildsweep** -- creates the sweep using the arguments defined by all the commands.
|
||||
|
||||
**Example:**
|
||||
~~~~~
|
||||
@ -6568,9 +6568,9 @@ Tolerances obtenues -- 3d : 0
|
||||
|
||||
Transformations are applications of matrices. When the transformation is nondeforming, such as translation or rotation, the object is not copied. The topology localcoordinate system feature is used. The copy can be enforced with the **tcopy** command.
|
||||
|
||||
* **tcopy** makes a copy of the structure of a shape.
|
||||
* **ttranslate**, **trotate**, **tmove**, **reset** move a shape.
|
||||
* **tmirror**, **tscale** always modify the shape.
|
||||
* **tcopy** -- makes a copy of the structure of a shape.
|
||||
* **ttranslate**, **trotate**, **tmove** and **reset** -- move a shape.
|
||||
* **tmirror** and **tscale** -- always modify the shape.
|
||||
|
||||
|
||||
@subsubsection occt_draw_7_5_1 tcopy
|
||||
@ -6875,19 +6875,19 @@ bop shape1 shape2
|
||||
bopsection result
|
||||
~~~~~
|
||||
|
||||
* **bopsection** creates a compound object consisting of the edges for the intersection curves on the faces of two shapes.
|
||||
* **bop** fills data structure (DS) of boolean operation for *shape1* and *shape2*.
|
||||
* **bopsection** command used after **bop** command.
|
||||
* **bopsection** -- creates a compound object consisting of the edges for the intersection curves on the faces of two shapes.
|
||||
* **bop** -- fills data structure (DS) of boolean operation for *shape1* and *shape2*.
|
||||
* **bopsection** -- is used after **bop** command.
|
||||
|
||||
Short variant syntax:
|
||||
~~~~~
|
||||
bsection result shape1 shape2 [-2d/-2d1/-2s2] [-a]
|
||||
~~~~~
|
||||
|
||||
* <i>-2d</i> - PCurves are computed on both parts.
|
||||
* <i>-2d1</i> - PCurves are computed on first part.
|
||||
* <i>-2d2</i> - PCurves are computed on second part.
|
||||
* <i>-a</i> - built geometries are approximated.
|
||||
* <i>-2d</i> -- PCurves are computed on both parts.
|
||||
* <i>-2d1</i> -- PCurves are computed on first part.
|
||||
* <i>-2d2</i> -- PCurves are computed on second part.
|
||||
* <i>-a</i> -- built geometries are approximated.
|
||||
|
||||
**Example:**
|
||||
|
||||
@ -6914,15 +6914,15 @@ bopargcheck shape1 [[shape2] [-F/O/C/T/S/U] [/R|F|T|V|E|I|P]] [#BF]
|
||||
|
||||
**bopargcheck** checks the validity of argument(s) for boolean operations.
|
||||
|
||||
* Boolean Operation - (by default a section is made) :
|
||||
* Boolean Operation -- (by default a section is made) :
|
||||
* **F** (fuse)
|
||||
* **O** (common)
|
||||
* **C** (cut)
|
||||
* **T** (cut21)
|
||||
* **S** (section)
|
||||
* **U** (unknown)
|
||||
* Test Options - (by default all options are enabled) :
|
||||
* **R** (disable small edges (shrank range) test)
|
||||
* Test Options -- (by default all options are enabled) :
|
||||
* **R** (disable small edges (shrink range) test)
|
||||
* **F** (disable faces verification test)
|
||||
* **T** (disable tangent faces searching test)
|
||||
* **V** (disable test possibility to merge vertices)
|
||||
@ -6930,8 +6930,8 @@ bopargcheck shape1 [[shape2] [-F/O/C/T/S/U] [/R|F|T|V|E|I|P]] [#BF]
|
||||
* **I** (disable self-interference test)
|
||||
* **P** (disable shape type test)
|
||||
* Additional Test Options :
|
||||
* **B** (stop test on first faulty found) - by default it is off;
|
||||
* **F** (full output for faulty shapes) - by default the output is made in a short format.
|
||||
* **B** (stop test on first faulty found) -- by default it is off;
|
||||
* **F** (full output for faulty shapes) -- by default the output is made in a short format.
|
||||
|
||||
**Note** that Boolean Operation and Test Options are used only for a couple of argument shapes, except for <b>I</b> and <b>P</b> options that are always used to test a couple of shapes as well as a single shape.
|
||||
|
||||
@ -7252,11 +7252,11 @@ xdistc2dc2dss curve2d_1 curve2d_2 surface_1 surface_2 startParam finishParam [Nu
|
||||
It is assumed that curves have the same parametrization range and *startParam* is less than *finishParam*.
|
||||
|
||||
Commands with prefix *xdist* allow checking the distance between two objects on even grid:
|
||||
* **xdistef** - distance between edge and face;
|
||||
* **xdistcs** - distance between curve and surface. This means that the projection of each sample point to the surface is computed;
|
||||
* **xdistcc** - distance between two 3D curves;
|
||||
* **xdistcc2ds** - distance between 3d curve and 2d curve on surface;
|
||||
* **xdistc2dc2dss** - distance between two 2d curves on surface.
|
||||
* **xdistef** -- distance between edge and face;
|
||||
* **xdistcs** -- distance between curve and surface. This means that the projection of each sample point to the surface is computed;
|
||||
* **xdistcc** -- distance between two 3D curves;
|
||||
* **xdistcc2ds** -- distance between 3d curve and 2d curve on surface;
|
||||
* **xdistc2dc2dss** -- distance between two 2d curves on surface.
|
||||
|
||||
**Examples**
|
||||
~~~~~
|
||||
@ -7693,21 +7693,21 @@ See @ref occt_user_guides__boolean_operations "Boolean operations" user's guide
|
||||
@subsection occt_draw_20_1 Definitions
|
||||
|
||||
The following terms and definitions are used in this document:
|
||||
* **Objects** – list of shapes that are arguments of the algorithm.
|
||||
* **Tools** – list of shapes that are arguments of the algorithm. Difference between Objects and Tools is defined by specific requirements of the operations (Boolean Operations, Partition Operation).
|
||||
* **DS** – internal data structure used by the algorithm (*BOPDS_DS* object).
|
||||
* **PaveFiller** – intersection part of the algorithm (*BOPAlgo_PaveFiller* object).
|
||||
* **Builder** – builder part of the algorithm (*BOPAlgo_Builder* object).
|
||||
* **IDS Index** – the index of the vector *myLines*.
|
||||
* **Objects** -- list of shapes that are arguments of the algorithm.
|
||||
* **Tools** -- list of shapes that are arguments of the algorithm. Difference between Objects and Tools is defined by specific requirements of the operations (Boolean Operations, Partition Operation).
|
||||
* **DS** -- internal data structure used by the algorithm (*BOPDS_DS* object).
|
||||
* **PaveFiller** -- intersection part of the algorithm (*BOPAlgo_PaveFiller* object).
|
||||
* **Builder** -- builder part of the algorithm (*BOPAlgo_Builder* object).
|
||||
* **IDS Index** -- the index of the vector *myLines*.
|
||||
|
||||
@subsection occt_draw_20_2 General commands
|
||||
|
||||
* **bclearobjects** - clears the list of Objects;
|
||||
* **bcleartools** - clears the list of Tools;
|
||||
* **baddobjects** *S1 S2...Sn* - adds shapes *S1, S2, ... Sn* as Objects;
|
||||
* **baddtools** *S1 S2...Sn* - adds shapes *S1, S2, ... Sn* as Tools;
|
||||
* **bfillds** - performs the Intersection Part of the Algorithm;
|
||||
* **bbuild** *r* - performs the Building Part of the Algorithm; *r* is the resulting shape.
|
||||
* **bclearobjects** -- clears the list of Objects;
|
||||
* **bcleartools** -- clears the list of Tools;
|
||||
* **baddobjects** *S1 S2...Sn* -- adds shapes *S1, S2, ... Sn* as Objects;
|
||||
* **baddtools** *S1 S2...Sn* -- adds shapes *S1, S2, ... Sn* as Tools;
|
||||
* **bfillds** -- performs the Intersection Part of the Algorithm;
|
||||
* **bbuild** *r* -- performs the Building Part of the Algorithm; *r* is the resulting shape.
|
||||
|
||||
@subsection occt_draw_20_3 Commands for Intersection Part
|
||||
|
||||
@ -7717,14 +7717,14 @@ All commands listed below are available when the Intersection Part of the algor
|
||||
|
||||
Syntax:
|
||||
~~~~
|
||||
bopds –v [e, f]
|
||||
bopds -v [e, f]
|
||||
~~~~
|
||||
|
||||
Displays:
|
||||
* all BRep shapes of arguments that are in the DS [default];
|
||||
* <i>–v</i> : only vertices of arguments that are in the DS;
|
||||
* <i>–e</i> : only edges of arguments that are in the DS;
|
||||
* <i>–f</i> : only faces of arguments that are in the DS.
|
||||
* <i>-v</i> : only vertices of arguments that are in the DS;
|
||||
* <i>-e</i> : only edges of arguments that are in the DS;
|
||||
* <i>-f</i> : only faces of arguments that are in the DS.
|
||||
|
||||
@subsubsection occt_draw_20_3_2 bopdsdump
|
||||
|
||||
@ -7751,9 +7751,9 @@ Example:
|
||||
~~~~
|
||||
|
||||
@code 0 : SOLID { 1 } @endcode has the following meaning:
|
||||
* *0* – index in the DS;
|
||||
* *SOLID* – type of the shape;
|
||||
* <i>{ 1 }</i> – a DS index of the successors.
|
||||
* *0* -- index in the DS;
|
||||
* *SOLID* -- type of the shape;
|
||||
* <i>{ 1 }</i> -- a DS index of the successors.
|
||||
|
||||
@subsubsection occt_draw_20_3_3 bopindex
|
||||
|
||||
@ -7773,9 +7773,9 @@ bopiterator [t1 t2]
|
||||
Prints pairs of DS indices of source shapes that are intersected in terms of bounding boxes.
|
||||
|
||||
<i>[t1 t2]</i> are types of the shapes:
|
||||
* *7* - vertex;
|
||||
* *6* - edge;
|
||||
* *4* – face.
|
||||
* *7* -- vertex;
|
||||
* *6* -- edge;
|
||||
* *4* -- face.
|
||||
|
||||
Example:
|
||||
~~~~
|
||||
@ -7789,7 +7789,7 @@ Example:
|
||||
~~~~
|
||||
|
||||
* *bopiterator 6 4* prints pairs of indices for types: edge/face;
|
||||
* *z58 z12* - DS indices of intersecting edge and face.
|
||||
* *z58 z12* -- DS indices of intersecting edge and face.
|
||||
|
||||
|
||||
@subsubsection occt_draw_20_3_5 bopinterf
|
||||
@ -7813,9 +7813,9 @@ Example:
|
||||
~~~~
|
||||
|
||||
Here, record <i>(58, 12, 68)</i> means:
|
||||
* *58* – a DS index of the edge;
|
||||
* *12* – a DS index of the face;
|
||||
* *68* – a DS index of the new vertex.
|
||||
* *58* -- a DS index of the edge;
|
||||
* *12* -- a DS index of the face;
|
||||
* *68* -- a DS index of the new vertex.
|
||||
|
||||
@subsubsection occt_draw_20_3_6 bopsp
|
||||
|
||||
@ -7832,8 +7832,8 @@ Example:
|
||||
edge 38 : z38_84 z38_85
|
||||
~~~~
|
||||
|
||||
* *edge 58* – 58 is a DS index of the original edge.
|
||||
* *z58_74 z58_75* – split edges, where 74, 75 are DS indices of the split edges.
|
||||
* *edge 58* -- 58 is a DS index of the original edge.
|
||||
* *z58_74 z58_75* -- split edges, where 74, 75 are DS indices of the split edges.
|
||||
|
||||
@subsubsection occt_draw_20_3_7 bopcb
|
||||
|
||||
@ -7855,13 +7855,13 @@ Example:
|
||||
~~~~
|
||||
|
||||
This command dumps common blocks for the source edge with index 17.
|
||||
* *PB* – information about the Pave Block;
|
||||
* *71* – a DS index of the split edge
|
||||
* *17* – a DS index of the original edge
|
||||
* <i>Pave1 : { 68 3.000 }</i> – information about the Pave:
|
||||
* *68* – a DS index of the vertex of the pave
|
||||
* *3.000* – a parameter of vertex 68 on edge 17
|
||||
* *Faces: 36* – 36 is a DS index of the face the common block belongs to.
|
||||
* *PB* -- information about the Pave Block;
|
||||
* *71* -- a DS index of the split edge
|
||||
* *17* -- a DS index of the original edge
|
||||
* <i>Pave1 : { 68 3.000 }</i> -- information about the Pave:
|
||||
* *68* -- a DS index of the vertex of the pave
|
||||
* *3.000* -- a parameter of vertex 68 on edge 17
|
||||
* *Faces: 36* -- 36 is a DS index of the face the common block belongs to.
|
||||
|
||||
|
||||
@subsubsection occt_draw_20_3_8 bopfin
|
||||
@ -7884,8 +7884,8 @@ Example:
|
||||
~~~~
|
||||
|
||||
|
||||
* <i>PB:{ E:71 orE:17 Pave1: { 68 3.000 } Pave2: { 18 10.000 } }</i> – information about the Pave Block;
|
||||
* <i>vrts In ... 18 – 18</i> a DS index of the vertex IN the face.
|
||||
* <i>PB:{ E:71 orE:17 Pave1: { 68 3.000 } Pave2: { 18 10.000 } }</i> -- information about the Pave Block;
|
||||
* <i>vrts In ... 18 </i> -- a DS index of the vertex IN the face.
|
||||
|
||||
@subsubsection occt_draw_20_3_9 bopfon
|
||||
|
||||
@ -7907,8 +7907,8 @@ Example:
|
||||
68 69 70 71
|
||||
~~~~
|
||||
|
||||
* <i>PB:{ E:72 orE:38 Pave1: { 69 0.000 } Pave2: { 68 10.000 } }</i> – information about the Pave Block;
|
||||
* <i>vrts On: ... 68 69 70 71 – 68, 69, 70, 71 </i> DS indices of the vertices ON the face.
|
||||
* <i>PB:{ E:72 orE:38 Pave1: { 69 0.000 } Pave2: { 68 10.000 } }</i> -- information about the Pave Block;
|
||||
* <i>vrts On: ... 68 69 70 71</i> -- DS indices of the vertices ON the face.
|
||||
|
||||
@subsubsection occt_draw_20_3_10 bopwho
|
||||
|
||||
@ -7925,7 +7925,7 @@ Example:
|
||||
rank: 0
|
||||
~~~~
|
||||
|
||||
* *rank: 0* – means that shape 5 results from the Argument with index 0.
|
||||
* *rank: 0* -- means that shape 5 results from the Argument with index 0.
|
||||
|
||||
Example:
|
||||
~~~~
|
||||
@ -7937,9 +7937,9 @@ Example:
|
||||
~~~~
|
||||
|
||||
This means that shape 68 is a result of the following interferences:
|
||||
* *EF: (58, 12)* – edge 58 / face 12
|
||||
* *FF curves: (12, 56)* – edge from the intersection curve between faces 12 and 56
|
||||
* *FF curves: (12, 64)* – edge from the intersection curve between faces 12 and 64
|
||||
* *EF: (58, 12)* -- edge 58 / face 12
|
||||
* *FF curves: (12, 56)* -- edge from the intersection curve between faces 12 and 56
|
||||
* *FF curves: (12, 64)* -- edge from the intersection curve between faces 12 and 64
|
||||
|
||||
@subsubsection occt_draw_20_3_11 bopnews
|
||||
|
||||
@ -7948,8 +7948,8 @@ Syntax:
|
||||
bopnews -v [-e]
|
||||
~~~~
|
||||
|
||||
* <i>-v</i> - displays all new vertices produced during the operation;
|
||||
* <i>-e</i> - displays all new edges produced during the operation.
|
||||
* <i>-v</i> -- displays all new vertices produced during the operation;
|
||||
* <i>-e</i> -- displays all new edges produced during the operation.
|
||||
|
||||
@subsection occt_draw_20_4 Commands for the Building Part
|
||||
|
||||
@ -8102,11 +8102,11 @@ stepwrite mode shape_name file_name
|
||||
Writes an OCCT shape to a STEP file.
|
||||
|
||||
The following modes are available :
|
||||
* *a* - as is – mode is selected automatically depending on the type & geometry of the shape;
|
||||
* *m* - *manifold_solid_brep* or *brep_with_voids*
|
||||
* *f* - *faceted_brep*
|
||||
* *w* - *geometric_curve_set*
|
||||
* *s* - *shell_based_surface_model*
|
||||
* *a* -- as is -- the mode is selected automatically depending on the type & geometry of the shape;
|
||||
* *m* -- *manifold_solid_brep* or *brep_with_voids*
|
||||
* *f* -- *faceted_brep*
|
||||
* *w* -- *geometric_curve_set*
|
||||
* *s* -- *shell_based_surface_model*
|
||||
|
||||
For further information see <a href="#user_guides__step.html#occt_step_6_5">Writing a STEP file</a>.
|
||||
|
||||
@ -8412,17 +8412,17 @@ tpstat [*|?]<symbol> [<selection>]
|
||||
|
||||
Provides all statistics on the last transfer, including a list of transferred entities with mapping from IGES or STEP to OCCT types, as well as fail and warning messages. The parameter <i>\<symbol\></i> defines what information will be printed:
|
||||
|
||||
* *g* - General statistics (a list of results and messages)
|
||||
* *c* - Count of all warning and fail messages
|
||||
* *C* - List of all warning and fail messages
|
||||
* *f* - Count of all fail messages
|
||||
* *F* - List of all fail messages
|
||||
* *n* - List of all transferred roots
|
||||
* *s* - The same, with types of source entity and the type of result
|
||||
* *b* - The same, with messages
|
||||
* *t* - Count of roots for geometrical types
|
||||
* *r* - Count of roots for topological types
|
||||
* *l* - The same, with the type of the source entity
|
||||
* *g* -- General statistics (a list of results and messages)
|
||||
* *c* -- Count of all warning and fail messages
|
||||
* *C* -- List of all warning and fail messages
|
||||
* *f* -- Count of all fail messages
|
||||
* *F* -- List of all fail messages
|
||||
* *n* -- List of all transferred roots
|
||||
* *s* -- The same, with types of source entity and the type of result
|
||||
* *b* -- The same, with messages
|
||||
* *t* -- Count of roots for geometrical types
|
||||
* *r* -- Count of roots for topological types
|
||||
* *l* -- The same, with the type of the source entity
|
||||
|
||||
The sign \* before parameters *n, s, b, t, r* makes it work on all entities (not only on roots).
|
||||
|
||||
@ -8455,7 +8455,7 @@ xload /disk1/tmp/aaa.stp
|
||||
|
||||
@subsection occt_draw_8_4 Overview of XDE commands
|
||||
|
||||
These commands are used for translation of IGES and STEP files into an XCAF document (special document is inherited from CAF document and is intended for Extended Data Exchange (XDE) ) and working with it. XDE translation allows reading and writing of shapes with additional attributes – colors, layers etc. All commands can be divided into the following groups:
|
||||
These commands are used for translation of IGES and STEP files into an XCAF document (special document is inherited from CAF document and is intended for Extended Data Exchange (XDE) ) and working with it. XDE translation allows reading and writing of shapes with additional attributes -- colors, layers etc. All commands can be divided into the following groups:
|
||||
* XDE translation commands
|
||||
* XDE general commands
|
||||
* XDE shape’s commands
|
||||
@ -8607,7 +8607,7 @@ Syntax:
|
||||
XShow <document> [ <label1> … ]
|
||||
~~~~~
|
||||
|
||||
Shows a shape from a given label in the 3D viewer. If the label is not given – shows all shapes from the document.
|
||||
Shows a shape from a given label in the 3D viewer. If the label is not given -- shows all shapes from the document.
|
||||
|
||||
**Example:**
|
||||
~~~~~
|
||||
@ -8759,7 +8759,7 @@ XGetFreeShapes <document> [shape_prefix]
|
||||
~~~~~
|
||||
|
||||
Print labels or create DRAW shapes for all free shapes in the document.
|
||||
If *shape_prefix* is absent – prints labels, else – creates DRAW shapes with names
|
||||
If *shape_prefix* is absent -- prints labels, else -- creates DRAW shapes with names
|
||||
<i>shape_prefix</i>_num (i.e. for example: there are 3 free shapes and *shape_prefix* = a therefore shapes will be created with names a_1, a_2 and a_3).
|
||||
|
||||
**Note**: a free shape is a shape to which no other shape refers to.
|
||||
@ -8985,7 +8985,7 @@ Syntax:
|
||||
XGetShapeColor <document> <label> <colortype(s|c)>
|
||||
~~~~~
|
||||
|
||||
Returns the color defined by label. If <i>colortype</i>=’s’ – returns surface color, else – returns curve color.
|
||||
Returns the color defined by label. If <i>colortype</i>=’s’ -- returns surface color, else -- returns curve color.
|
||||
|
||||
**Example:**
|
||||
~~~~~
|
||||
@ -9235,7 +9235,7 @@ Syntax:
|
||||
XCheckProps <document> [ {0|deflection} [<shape>|<label>] ]
|
||||
~~~~~
|
||||
|
||||
Gets properties for a given shape (*volume*, *area* and <i>centroid</i>) and compares them with the results after internal calculations. If the second parameter is 0, the standard OCCT tool is used for the computation of properties. If the second parameter is not 0, it is processed as a deflection. If the deflection is positive the computation is done by triangulations, if it is negative – meshing is forced.
|
||||
Gets properties for a given shape (*volume*, *area* and <i>centroid</i>) and compares them with the results after internal calculations. If the second parameter is 0, the standard OCCT tool is used for the computation of properties. If the second parameter is not 0, it is processed as a deflection. If the deflection is positive the computation is done by triangulations, if it is negative -- meshing is forced.
|
||||
|
||||
**Example:**
|
||||
~~~~~
|
||||
@ -9354,7 +9354,7 @@ Syntax:
|
||||
XShapeMassProps <document> [ <deflection> [{<shape>|<label>}] ]
|
||||
~~~~~
|
||||
|
||||
Computes and returns real mass and real center of gravity for a given shape or for all shapes in a document. The second parameter is used for calculation of the volume and CG(center of gravity). If it is 0, then the standard CASCADE tool (geometry) is used for computation, otherwise - by triangulations with a given deflection.
|
||||
Computes and returns real mass and real center of gravity for a given shape or for all shapes in a document. The second parameter is used for calculation of the volume and CG(center of gravity). If it is 0, then the standard CASCADE tool (geometry) is used for computation, otherwise -- by triangulations with a given deflection.
|
||||
|
||||
**Example:**
|
||||
~~~~~
|
||||
@ -9403,7 +9403,7 @@ Syntax:
|
||||
checkfclass2d <face> <ucoord> <vcoord>
|
||||
~~~~~
|
||||
|
||||
Shows where a point which is given by coordinates is located in relation to a given face – outbound, inside or at the bounds.
|
||||
Shows where a point which is given by coordinates is located in relation to a given face -- outbound, inside or at the bounds.
|
||||
|
||||
**Example:**
|
||||
~~~~~
|
||||
@ -9534,14 +9534,14 @@ The following syntax is used:
|
||||
* "+" to set on or
|
||||
* "*" to set default
|
||||
* <i>\<parameter\></i> is identified by letters:
|
||||
* l - FixLackingMode
|
||||
* o - FixOrientationMode
|
||||
* h - FixShiftedMode
|
||||
* m - FixMissingSeamMode
|
||||
* d - FixDegeneratedMode
|
||||
* s - FixSmallMode
|
||||
* i - FixSelfIntersectionMode
|
||||
* n - FixNotchedEdgesMode
|
||||
* l -- FixLackingMode
|
||||
* o -- FixOrientationMode
|
||||
* h -- FixShiftedMode
|
||||
* m -- FixMissingSeamMode
|
||||
* d -- FixDegeneratedMode
|
||||
* s -- FixSmallMode
|
||||
* i -- FixSelfIntersectionMode
|
||||
* n -- FixNotchedEdgesMode
|
||||
For enhanced message output, use switch '+?'
|
||||
|
||||
**Example:**
|
||||
@ -9720,7 +9720,7 @@ DT_ClosedSplit <result> <shape>
|
||||
~~~~~
|
||||
|
||||
Divides all closed faces in the shape (for example cone) and returns result of given shape into shape, which is given as parameter result. Number of faces in resulting shapes will be increased.
|
||||
Note: Closed face – it’s face with one or more seam.
|
||||
Note: A closed face is a face with one or more seam.
|
||||
|
||||
**Example:**
|
||||
~~~~~
|
||||
@ -9911,7 +9911,7 @@ void MyPack::CurveCommands(Draw_Interpretor& theCommands)
|
||||
...
|
||||
char* g = "Advanced curves creation";
|
||||
|
||||
theCommands.Add ( "myadvcurve", "myadvcurve name p1 p2 p3 – Creates my advanced curve from points",
|
||||
theCommands.Add ( "myadvcurve", "myadvcurve name p1 p2 p3 - Creates my advanced curve from points",
|
||||
__FILE__, myadvcurve, g );
|
||||
...
|
||||
}
|
||||
@ -9946,7 +9946,7 @@ DPLUGIN(MyPack)
|
||||
As mentioned above, the plug-in resource file must be compliant with Open CASCADE Technology requirements (see *Resource_Manager.cdl* file for details). In particular, it should contain keys separated from their values by a colon (;:;).
|
||||
For every created plug-in there must be a key. For better readability and comprehension it is recommended to have some meaningful name.
|
||||
Thus, the resource file must contain a line mapping this name (key) to the library name. The latter should be without file extension (.dll on Windows, .so on Unix/Linux) and without the ;lib; prefix on Unix/Linux.
|
||||
For several plug-ins one resource file can be created. In such case, keys denoting plug-ins can be combined into groups, these groups - into their groups and so on (thereby creating some hierarchy). Any new parent key must have its value as a sequence of child keys separated by spaces, tabs or commas. Keys should form a tree without cyclic dependencies.
|
||||
For several plug-ins one resource file can be created. In such case, keys denoting plug-ins can be combined into groups, these groups -- into their groups and so on (thereby creating some hierarchy). Any new parent key must have its value as a sequence of child keys separated by spaces, tabs or commas. Keys should form a tree without cyclic dependencies.
|
||||
|
||||
**Examples** (file MyDrawPlugin):
|
||||
~~~~~
|
||||
|
||||
@ -120,7 +120,7 @@ Inside a package, two data types cannot bear the same name.
|
||||
* **Class method** Does not work on individual instances, only on the class itself.
|
||||
|
||||
@subsubsection occt_fcug_2_a_3 Classes
|
||||
The fundamental software component in object-oriented software development is the class. A class is the implementation of a **data type**. It defines its **behavior** (the services offered by its functions) and its **representation** (the data structure of the class – the fields, which store its data).
|
||||
The fundamental software component in object-oriented software development is the class. A class is the implementation of a **data type**. It defines its **behavior** (the services offered by its functions) and its **representation** (the data structure of the class -- the fields, which store its data).
|
||||
|
||||
Classes fall into three categories:
|
||||
* Ordinary classes.
|
||||
@ -512,10 +512,10 @@ There are two approaches how to avoid such situation:
|
||||
|
||||
Though generation of Handle class and related C++ code is normally performed by CDL extractor, it is also possible to define a class managed by handle without CDL. To facilitate that, several macros are provided in the file Standard_DefineHandle.hxx:
|
||||
|
||||
* **DEFINE_STANDARD_HANDLE(class_name,ancestor_name)** - declares Handle class for a class *class_name* that inherits class *ancestor_name* (for instance, *Standard_Transient*). This macro should be put in a header file; the declaration of the handle to a base class must be available (usually put before or after the declaration of the class *class_name*, or into a separate header file).
|
||||
* **IMPLEMENT_STANDARD_HANDLE(class_name,ancestor_name)** - implements method *DownCast()* of the *Handle* class. Should be located in a C++ file (normally the file where methods of the class *class_name* are implemented).
|
||||
* **DEFINE_STANDARD_RTTI(class_name)** - declares methods required for RTTI in the class *class_name* declaration; should be in public: section.
|
||||
* **IMPLEMENT_STANDARD_RTTIEXT(class_name,ancestor_name)** - implements above methods. Usually put into the C++ file implementing class *class_name*.
|
||||
* **DEFINE_STANDARD_HANDLE(class_name,ancestor_name)** -- declares Handle class for a class *class_name* that inherits class *ancestor_name* (for instance, *Standard_Transient*). This macro should be put in a header file; the declaration of the handle to a base class must be available (usually put before or after the declaration of the class *class_name*, or into a separate header file).
|
||||
* **IMPLEMENT_STANDARD_HANDLE(class_name,ancestor_name)** -- implements method *DownCast()* of the *Handle* class. Should be located in a C++ file (normally the file where methods of the class *class_name* are implemented).
|
||||
* **DEFINE_STANDARD_RTTI(class_name)** -- declares methods required for RTTI in the class *class_name* declaration; should be in public: section.
|
||||
* **IMPLEMENT_STANDARD_RTTIEXT(class_name,ancestor_name)** -- implements above methods. Usually put into the C++ file implementing class *class_name*.
|
||||
Note that it is important to ensure correctness of macro arguments, especially the ancestor name, otherwise the definition may be inconsistent (no compiler warnings will be issued in case of mistake).
|
||||
|
||||
In *Appli_ExtSurface.hxx* file:
|
||||
@ -762,7 +762,7 @@ It is a widely used practice to include that kind of protections in a debug bui
|
||||
~~~~~
|
||||
where *ErrorTypeName* is the exception type, *condition* is the logical expression leading to the raise of the exception, and *Error message* is the associated message.
|
||||
|
||||
The entire call may be removed by defining one of the pre-processor symbols *No_Exception* or <i>No_<ErrorTypeName></i> at compile-time:
|
||||
The entire call may be removed by defining one of the preprocessor symbols *No_Exception* or <i>No_<ErrorTypeName></i> at compile-time:
|
||||
|
||||
~~~~~
|
||||
#define No_Exception /* remove all raises */
|
||||
@ -809,7 +809,7 @@ void f(1)
|
||||
}
|
||||
~~~~~
|
||||
|
||||
Here, the first handler will catch exceptions of *Overflow* type and the second one - exceptions of *NumericError* type and all exceptions derived from it, including *Underflow* and *ZeroDivide*.
|
||||
Here, the first handler will catch exceptions of *Overflow* type and the second one -- exceptions of *NumericError* type and all exceptions derived from it, including *Underflow* and *ZeroDivide*.
|
||||
|
||||
The handlers are checked in order of appearance, from the nearest to the try block to the most distant from it, until one matches the raise expression. For a try block, it would be a mistake to place a handler for a base exception type ahead of a handler for its derived type since that would ensure that the handler for the derived exception would never be invoked.
|
||||
|
||||
@ -1409,7 +1409,7 @@ The NCollection library provides a full replacement of all TCollection generic c
|
||||
|
||||
Macro definitions of these classes are stored in *NCollection_Define\*.hxx* files. These definitions are now obsolete though still can be used, particularly for compatibility with the existing code. On the contrary, template classes in *NCollection_\*.hxx* files are recommended, they are supported by OPEN CASCADE Company and further developed according to various needs.
|
||||
|
||||
The technology used in this unit continues and complements the one offered in the header file *Standard_DefineHandle* – allowing to implement outside CDL the classes managed by Handle, also providing OCCT RTTI support.
|
||||
The technology used in this unit continues and complements the one offered in the header file *Standard_DefineHandle* -- allowing to implement outside CDL the classes managed by Handle, also providing OCCT RTTI support.
|
||||
|
||||
@subsubsection occt_fcug_3_3_2 Instantiation of collection classes
|
||||
|
||||
@ -1508,11 +1508,11 @@ There are 4 collection types provided as template classes:
|
||||
This type is implemented internally as a list of arrays of the same size. Its properties:
|
||||
* Direct (constant-time) access to members like in Array1 type; data are allocated in compact blocks, this provides faster iteration.
|
||||
* Can grow without limits, like List, Stack or Queue types.
|
||||
* Once having the size LEN, it cannot be reduced to any size less than LEN – there is no operation of removal of items.
|
||||
* Once having the size LEN, it cannot be reduced to any size less than LEN -- there is no operation of removal of items.
|
||||
|
||||
Insertion in a Vector-type class is made by two methods:
|
||||
* _SetValue(ind, theValue)_ – array-type insertion, where ind is the index of the inserted item, can be any non-negative number. If it is greater than or equal to Length(), then the vector is enlarged (its Length() grows).
|
||||
* _Append(theValue)_ – list-type insertion equivalent to _myVec.SetValue(myVec.Length(), theValue)_ – incrementing the size of the collection.
|
||||
* _SetValue(ind, theValue)_ -- array-type insertion, where ind is the index of the inserted item, can be any non-negative number. If it is greater than or equal to Length(), then the vector is enlarged (its Length() grows).
|
||||
* _Append(theValue)_ -- list-type insertion equivalent to _myVec.SetValue(myVec.Length(), theValue)_, incrementing the size of the collection.
|
||||
|
||||
Other essential properties coming from List and Array1 type collections:
|
||||
* Like in *List*, the method *Clear()* destroys all contained objects and releases the allocated memory.
|
||||
@ -1617,11 +1617,11 @@ NCollection defines some specific features, in addition to the public API inheri
|
||||
|
||||
Every collection defines its Iterator class capable of iterating the members in some predefined order. Every Iterator is defined as a subtype of the particular collection type (e.g., MyPackage_StackOfPnt::Iterator ). The order of iteration is defined by a particular collection type. The methods of Iterator are:
|
||||
|
||||
* _void Init (const MyCollection&)_ - initializes the iterator on the collection object;
|
||||
* _Standard_Boolean More () const_ - makes a query if there is another non-iterated member;
|
||||
* _void Next ()_ - increments the iterator;
|
||||
* _const ItemType& Value () const_ - returns the current member;
|
||||
* _ItemType& ChangeValue () const_ - returns the mutable current member
|
||||
* _void Init (const MyCollection&)_ -- initializes the iterator on the collection object;
|
||||
* _Standard_Boolean More () const_ -- makes a query if there is another non-iterated member;
|
||||
* _void Next ()_ -- increments the iterator;
|
||||
* _const ItemType& Value () const_ -- returns the current member;
|
||||
* _ItemType& ChangeValue () const_ -- returns the mutable current member
|
||||
|
||||
~~~~~
|
||||
typedef Ncollection_Sequence<gp_Pnt>
|
||||
@ -1645,9 +1645,9 @@ There is a common abstract base class for all collections for a given item type
|
||||
|
||||
This base class has the following public API:
|
||||
* abstract class Iterator as the base class for all Iterators descried above;
|
||||
* _Iterator& CreateIterator () const_ - creates and returns the Iterator on this collection;
|
||||
* _Standard_Integer Size () const_ - returns the number of items in this collection;
|
||||
* *void Assign (const NCollection_BaseCollection& theOther)* - copies the contents of the Other to this collection object;
|
||||
* _Iterator& CreateIterator () const_ -- creates and returns the Iterator on this collection;
|
||||
* _Standard_Integer Size () const_ -- returns the number of items in this collection;
|
||||
* *void Assign (const NCollection_BaseCollection& theOther)* -- copies the contents of the Other to this collection object;
|
||||
|
||||
These members enable accessing any collection without knowing its exact type. In particular, it makes possible to implement methods receiving objects of the abstract collection type:
|
||||
|
||||
@ -1672,8 +1672,8 @@ gp_Pnt COG(const MyPackage_BaseCollPnt& theColl)
|
||||
~~~~~
|
||||
|
||||
Note that there are fundamental differences between the shown type-independent iterator and the iterator belonging to a particular non-abstract collection:
|
||||
* Type-independent iterator can only be obtained via the call CreateIterator(); the typed iterator - only via the explicit construction.
|
||||
* Type-independent iterator is an abstract class, so it is impossible to copy it or to assign it to another collection object; the typed iterators can be copied and reassigned using the method Init() .
|
||||
* Type-independent iterator can only be obtained via the call <i>CreateIterator()</i>; the typed iterator -- only via the explicit construction.
|
||||
* Type-independent iterator is an abstract class, so it is impossible to copy it or to assign it to another collection object; the typed iterators can be copied and reassigned using the method <i>Init()</i>.
|
||||
* Type-independent iterator is actually destroyed when its collection object is destroyed; the typed iterator is destroyed as any other C++ object in the corresponding C++ scope.
|
||||
|
||||
The common point between them is that it is possible to create any number of both types of iterators on the same collection object.
|
||||
@ -1926,7 +1926,7 @@ These are non-persistent classes.
|
||||
|
||||
@subsection occt_occt_fcug_4_5 Basic Geometric Libraries
|
||||
There are various library packages available which offer a range of basic computations on curves and surfaces.
|
||||
If you are dealing with objects created from the *gp* package, the useful algorithms are in the elementary curves and surfaces libraries - the *ElCLib* and *ElSLib* packages.
|
||||
If you are dealing with objects created from the *gp* package, the useful algorithms are in the elementary curves and surfaces libraries -- the *ElCLib* and *ElSLib* packages.
|
||||
* *EICLib* provides methods for analytic curves. This is a library of simple computations on curves from the *gp* package (Lines, Circles and Conics). It is possible to compute points with a given parameter or to compute the parameter for a point.
|
||||
* *EISLib* provides methods for analytic surfaces. This is a library of simple computations on surfaces from the package *gp* (Planes, Cylinders, Spheres, Cones, Tori). It is possible to compute points with a given pair of parameters or to compute the parameter for a point. There is a library for calculating normals on curves and surfaces.
|
||||
|
||||
|
||||
@ -179,8 +179,8 @@ Default value is 1.
|
||||
|
||||
<h4>read.stdsameparameter.mode</h4>
|
||||
defines the using of *BRepLib::SameParameter*. Its possible values are:
|
||||
* 0 (Off) - *BRepLib::SameParameter* is not called,
|
||||
* 1 (On) - *BRepLib::SameParameter* is called.
|
||||
* 0 (Off) -- *BRepLib::SameParameter* is not called,
|
||||
* 1 (On) -- *BRepLib::SameParameter* is called.
|
||||
*BRepLib::SameParameter* is used through *ShapeFix_Edge::SameParameter*. It ensures that the resulting edge will have the lowest tolerance taking pcurves either unmodified from the IGES file or modified by *BRepLib::SameParameter*.
|
||||
Read this parameter with:
|
||||
~~~~~
|
||||
@ -271,8 +271,8 @@ Please find an example of the resource file for IGES (which defines parameters
|
||||
In order for the IGES translator to use that file, you have to define the environment variable *CSF_IGESDefaults*, which should point to the directory where the resource file resides. Note that if you change parameter *read.iges.resource.name*, you should change the name of the resource file and the name of the environment variable correspondingly. The variable should contain a path to the resource file.
|
||||
|
||||
Default values:
|
||||
* read.iges.resource.name - IGES,
|
||||
* read.iges.sequence - FromIGES.
|
||||
* read.iges.resource.name -- IGES,
|
||||
* read.iges.sequence -- FromIGES.
|
||||
|
||||
<h4>xstep.cascade.unit</h4>
|
||||
This parameter defines units to which a shape should be converted when translated from IGES or STEP to CASCADE. Normally it is MM; only those applications that work internally in units other than MM should use this parameter.
|
||||
@ -319,25 +319,25 @@ faces = Reader.GiveList(“xst-type(!=SurfaceOfRevolution)”);
|
||||
~~~~~
|
||||
|
||||
<h4>List of predefined operators that can be used:</h4>
|
||||
* *xst-model-all* - selects all entities.
|
||||
* *xst-model-roots* - selects all roots.
|
||||
* *xst-transferrable-all* - selects all translatable entities.
|
||||
* *xst-transferrable-roots* - selects all translatable roots (default).
|
||||
* *xst-sharing + \<selection\>* - selects all entities sharing at least one entity selected by \<selection\>.
|
||||
* *xst-shared + \<selection\>* - selects all entities shared by at least one entity selected by \<selection\>.
|
||||
* *iges-visible-roots* - selects all visible roots, whether translatable or not.
|
||||
* *iges-visible-transf-roots* - selects all visible and translatable roots.
|
||||
* *iges-blanked-roots* - selects all blank roots, whether translatable or not.
|
||||
* *iges-blanked-transf-roots* - selects all blank and translatable roots.
|
||||
* *iges-status-independant* - selects entities whose IGES Subordinate Status = 0.
|
||||
* *iges-bypass-group* Selects all root entities. If a root entity is a group (402/7 or 402/9), the entities in the group are selected.
|
||||
* *iges-bypass-subfigure* Selects all root entities. If a root entity is a subfigure definition (308), the entities in the subfigure definition are selected.
|
||||
* *iges-bypass-group-subfigure* Selects all root entities. If a root entity is a group (402/7 or 402/9) or a subfigure definition (308), the entities in the group and in the subfigure definition are selected.
|
||||
* *iges-curves-3d* - selects 3D curves, whether they are roots or not (e.g. a 3D curve on a surface).
|
||||
* *iges-basic-geom* - selects 3D curves and untrimmed surfaces.
|
||||
* *iges-faces* - selects face-supporting surfaces (trimmed or not).
|
||||
* *iges-surfaces* - selects surfaces not supporting faces (i.e. with natural bounds).
|
||||
* *iges-basic-curves-3d* selects the same entities as iges-curves-3d. Composite Curves are broken down into their components and the components are selected.
|
||||
* *xst-model-all* -- selects all entities.
|
||||
* *xst-model-roots* -- selects all roots.
|
||||
* *xst-transferrable-all* -- selects all translatable entities.
|
||||
* *xst-transferrable-roots* -- selects all translatable roots (default).
|
||||
* *xst-sharing + \<selection\>* -- selects all entities sharing at least one entity selected by \<selection\>.
|
||||
* *xst-shared + \<selection\>* -- selects all entities shared by at least one entity selected by \<selection\>.
|
||||
* *iges-visible-roots* -- selects all visible roots, whether translatable or not.
|
||||
* *iges-visible-transf-roots* -- selects all visible and translatable roots.
|
||||
* *iges-blanked-roots* -- selects all blank roots, whether translatable or not.
|
||||
* *iges-blanked-transf-roots* -- selects all blank and translatable roots.
|
||||
* *iges-status-independant* -- selects entities whose IGES Subordinate Status = 0.
|
||||
* *iges-bypass-group* -- selects all root entities. If a root entity is a group (402/7 or 402/9), the entities in the group are selected.
|
||||
* *iges-bypass-subfigure* -- selects all root entities. If a root entity is a subfigure definition (308), the entities in the subfigure definition are selected.
|
||||
* *iges-bypass-group-subfigure* -- selects all root entities. If a root entity is a group (402/7 or 402/9) or a subfigure definition (308), the entities in the group and in the subfigure definition are selected.
|
||||
* *iges-curves-3d* -- selects 3D curves, whether they are roots or not (e.g. a 3D curve on a surface).
|
||||
* *iges-basic-geom* -- selects 3D curves and untrimmed surfaces.
|
||||
* *iges-faces* -- selects face-supporting surfaces (trimmed or not).
|
||||
* *iges-surfaces* -- selects surfaces not supporting faces (i.e. with natural bounds).
|
||||
* *iges-basic-curves-3d* -- selects the same entities as iges-curves-3d. Composite Curves are broken down into their components and the components are selected.
|
||||
|
||||
@subsubsection occt_iges_2_3_5 Performing the IGES file translation
|
||||
Perform translation according to what you want to translate:
|
||||
@ -401,11 +401,11 @@ reader.PrintTransferInfo (failsonly, mode);
|
||||
displays the messages that appeared during the last invocation of *Transfer* or *TransferRoots*.
|
||||
|
||||
If *failsonly* is *IFSelect_FailOnly*, only fail messages will be output, if it is *IFSelect_FailAndWarn*, all messages will be output. Parameter “mode” can have *IFSelect_xxx* values where *xxx* can be:
|
||||
* *GeneralCount* - gives general statistics on the transfer (number of translated IGES entities, number of fails and warnings, etc)
|
||||
* *CountByItem* - gives the number of IGES entities with their types per message.
|
||||
* *ListByItem* - gives the number of IGES entities with their type and DE numbers per message.
|
||||
* *ResultCount* - gives the number of resulting OCCT shapes per type.
|
||||
* *Mapping* gives mapping between roots of the IGES file and the resulting OCCT shape per IGES and OCCT type.
|
||||
* *GeneralCount* -- gives general statistics on the transfer (number of translated IGES entities, number of fails and warnings, etc)
|
||||
* *CountByItem* -- gives the number of IGES entities with their types per message.
|
||||
* *ListByItem* -- gives the number of IGES entities with their type and DE numbers per message.
|
||||
* *ResultCount* -- gives the number of resulting OCCT shapes per type.
|
||||
* *Mapping* -- gives mapping between roots of the IGES file and the resulting OCCT shape per IGES and OCCT type.
|
||||
|
||||
@subsection occt_iges_2_4 Mapping of IGES entities to Open CASCADE Technology shapes
|
||||
|
||||
@ -555,10 +555,10 @@ Geometrical entities are translated by classes *IGESToBRep_BasicCurve* and *IGE
|
||||
Since these objects are not BRep objects, they do not have tolerances. Hence, tolerance parameters are used in these classes only as precisions: to detect specific cases (e.g., to distinguish a circle, an ellipse, a parabola and a hyperbola) and to detect bad cases (such as coincident points).
|
||||
|
||||
Use of precision parameters is reflected in the following classes:
|
||||
* *IGESToBRep_BasicCurve* - all parameters and points are compared with precision *EpsGeom*. All transformations (except *IGESToBRep_BasicCurve::TransferTransformation*) are fulfilled with precision *Epsilon* which is set to 10<sup>-3</sup> (in the *IGESToBRep_BasicCurve::TransferTransformation* the value 10<sup>-5</sup> is used).
|
||||
* *IGESToBRep_BasicCurve::TransferBSplineCurve* - all weights of *BSplineCurve* are assumed to be more than *Precision::PConfusion* (else the curve is not translated).
|
||||
* *IGESToBRep_BasicSurface* all parameters and points are compared with precision *EpsGeom*. All transformations are fulfilled with precision *Epsilon*, which is set to 10<sup>-3</sup>.
|
||||
* *IGESToBRep_BasicSurface::TransferBSplineSurface* - all weights of *BSplineSurface* are assumed to be more than *Precision::PConfusion* (else the surface is not translated).
|
||||
* *IGESToBRep_BasicCurve* -- all parameters and points are compared with precision *EpsGeom*. All transformations (except *IGESToBRep_BasicCurve::TransferTransformation*) are fulfilled with precision *Epsilon* which is set to 10<sup>-3</sup> (in the *IGESToBRep_BasicCurve::TransferTransformation* the value 10<sup>-5</sup> is used).
|
||||
* *IGESToBRep_BasicCurve::TransferBSplineCurve* -- all weights of *BSplineCurve* are assumed to be more than *Precision::PConfusion* (else the curve is not translated).
|
||||
* *IGESToBRep_BasicSurface* -- all parameters and points are compared with precision *EpsGeom*. All transformations are fulfilled with precision *Epsilon*, which is set to 10<sup>-3</sup>.
|
||||
* *IGESToBRep_BasicSurface::TransferBSplineSurface* -- all weights of *BSplineSurface* are assumed to be more than *Precision::PConfusion* (else the surface is not translated).
|
||||
|
||||
|
||||
<h4>Translating into Topology</h4>
|
||||
@ -574,11 +574,11 @@ The following classes show what default tolerances are used when creating shape
|
||||
<h5>Class IGESToBRep_TopoCurve</h5>
|
||||
|
||||
All methods are in charge of transferring curves from IGES curve entities <i>(TransferCompositeCurve, Transfer2dCompositeCurve, TransferCurveOnFace, TransferBoundaryOnFace, TransferOffsetCurve, TransferTopoBasicCurve)</i> if an entity has transformation call to *IGESData_ToolLocation::ConvertLocation* with *Epsilon* value set to 10<sup>-4</sup>.
|
||||
* *IGESToBRep_TopoCurve::TransferPoint* - vertex is constructed from a Point entity with tolerance *EpsGeom*UnitFactor*.
|
||||
* *IGESToBRep_TopoCurve::Transfer2dPoint* - vertex is constructed from a Point entity with tolerance *EpsCoeff*.
|
||||
* *IGESToBRep_TopoCurve::TransferCompositeCurveGeneral* - obtains shapes (edges or wires) from other methods and adds them into the resulting wire. Two adjacent edges of the wire can be connected with tolerance up to *MaxTol*.
|
||||
* *IGESToBRep_TopoCurve::TransferCurveOnFace* and *IGESToBRep_TopoCurve::TransferBoundaryOnFace* build a wire from 3D and 2D representations of a curve on surface. Edges and vertices of the wire cannot have tolerance larger than *MaxTol*. The value *EpsGeom*UnitFactor* is passed into *ShapeFix_Wire::SetPrecision* and *MaxTol* - into *ShapeFix_Wire::MaxTolerance*. To find out how these parameters affect the resulting tolerance changes, please, refer to class *ShapeFix_Wire*.
|
||||
* *IGESToBRep_TopoCurve::TransferTopoBasicCurve* and *IGESToBRep_TopoCurve::Transfer2dTopoBasicCurve* - the boundary vertices of an edge (or a wire if a curve was of C0 continuity) translated from a basis IGES curve (*BSplineCurve, CopiousData, Line,* etc.) are built with tolerance *EpsGeom*UnitFactor*, the edge tolerance is *Precision::Confusion*. If a curve was divided into several edges, the common vertices of such adjacent edges have tolerance *Precision::Confusion*.
|
||||
* *IGESToBRep_TopoCurve::TransferPoint* -- vertex is constructed from a Point entity with tolerance *EpsGeom*UnitFactor*.
|
||||
* *IGESToBRep_TopoCurve::Transfer2dPoint* -- vertex is constructed from a Point entity with tolerance *EpsCoeff*.
|
||||
* *IGESToBRep_TopoCurve::TransferCompositeCurveGeneral* -- obtains shapes (edges or wires) from other methods and adds them into the resulting wire. Two adjacent edges of the wire can be connected with tolerance up to *MaxTol*.
|
||||
* *IGESToBRep_TopoCurve::TransferCurveOnFace* and *IGESToBRep_TopoCurve::TransferBoundaryOnFace* build a wire from 3D and 2D representations of a curve on surface. Edges and vertices of the wire cannot have tolerance larger than *MaxTol*. The value *EpsGeom*UnitFactor* is passed into *ShapeFix_Wire::SetPrecision* and *MaxTol* is passed into *ShapeFix_Wire::MaxTolerance*. To find out how these parameters affect the resulting tolerance changes, please, refer to class *ShapeFix_Wire*.
|
||||
* *IGESToBRep_TopoCurve::TransferTopoBasicCurve* and *IGESToBRep_TopoCurve::Transfer2dTopoBasicCurve* -- the boundary vertices of an edge (or a wire if a curve was of C0 continuity) translated from a basis IGES curve (*BSplineCurve, CopiousData, Line,* etc.) are built with tolerance *EpsGeom*UnitFactor*, the edge tolerance is *Precision::Confusion*. If a curve was divided into several edges, the common vertices of such adjacent edges have tolerance *Precision::Confusion*.
|
||||
|
||||
|
||||
<h5>Class IGESToBRep_TopoSurface</h5>
|
||||
@ -587,10 +587,10 @@ All faces created by this class have tolerance *Precision::Confusion*.
|
||||
|
||||
<h5>Class IGESToBRep_BRepEntity</h5>
|
||||
|
||||
* *IGESToBRep_BRepEntity::TransferVertex* - the vertices from the *VertexList* entity are constructed with tolerance *EpsGeom*UnitFactor*.
|
||||
* *IGESToBRep_BRepEntity::TransferEdge* - the edges from the *EdgeList* entity are constructed with tolerance *Precision::Confusion*.
|
||||
* *IGESToBRep_BRepEntity::TransferLoop* - this function works like *IGESToBRep_TopoCurve::TransferCurveOnFace* and *IGESToBRep_TopoCurve::TransferBoundaryOnFace*.
|
||||
* *IGESToBRep_BRepEntity::TransferFace* the face from the Face IGES entity is constructed with tolerance *Precision::Confusion*.
|
||||
* *IGESToBRep_BRepEntity::TransferVertex* -- the vertices from the *VertexList* entity are constructed with tolerance *EpsGeom*UnitFactor*.
|
||||
* *IGESToBRep_BRepEntity::TransferEdge* -- the edges from the *EdgeList* entity are constructed with tolerance *Precision::Confusion*.
|
||||
* *IGESToBRep_BRepEntity::TransferLoop* -- this function works like *IGESToBRep_TopoCurve::TransferCurveOnFace* and *IGESToBRep_TopoCurve::TransferBoundaryOnFace*.
|
||||
* *IGESToBRep_BRepEntity::TransferFace* -- the face from the *Face* IGES entity is constructed with tolerance *Precision::Confusion*.
|
||||
|
||||
<h5>Shape Healing classes</h5>
|
||||
After performing a simple mapping, shape-healing algorithms are called (class *ShapeFix_Shape*) by *IGESToBRep_Actor::Transfer()*. Shape-healing algorithm performs the correction of the resulting OCCT shape.
|
||||
@ -663,8 +663,8 @@ The result is an *IGESControl_Writer* object.
|
||||
The following parameters are used for the OCCT-to-IGES translation.
|
||||
|
||||
* *write.iges.brep.mode:* allows choosing the write mode:
|
||||
* "Faces" (0): OCCT *TopoDS_Faces* will be translated into IGES 144 (Trimmed Surface) entities, no B-Rep entities will be written to the IGES file,
|
||||
* "BRep" (1): OCCT *TopoDS_Faces* will be translated into IGES 510 (Face) entities, the IGES file will contain B-Rep entities.
|
||||
* "Faces" (0): OCCT *TopoDS_Faces* will be translated into IGES 144 (Trimmed Surface) entities, no BRep entities will be written to the IGES file,
|
||||
* "BRep" (1): OCCT *TopoDS_Faces* will be translated into IGES 510 (Face) entities, the IGES file will contain BRep entities.
|
||||
Read this parameter with:
|
||||
~~~~~
|
||||
Standard_Integer byvalue = Interface_Static::IVal("write.iges.brep.mode");
|
||||
@ -687,7 +687,7 @@ Default value is "Faces" (0).
|
||||
* *write.iges.header.product:* gives the name of the sending product. The default value is "CAS.CADE IGES processor Vx.x", where *x.x* means the current version of Open CASCADE Technology.
|
||||
* Read this parameter with *Standard_String byvalue = Interface_Static::CVal("write.iges.header.product")*;
|
||||
* Modify this value with *Interface_Static::SetCVal ("write.iges.header.product", "product name")*;
|
||||
* *write.iges.header.receiver:* - gives the name of the receiving company. The default value is "" (empty).
|
||||
* *write.iges.header.receiver:* -- gives the name of the receiving company. The default value is "" (empty).
|
||||
* Read this parameter with *Standard_String byvalue = Interface_Static::CVal("write.iges.header.receiver");*
|
||||
* Modify this value with *Interface_Static::SetCVal ("write.iges.header.receiver", "reciever name");*
|
||||
* *write.precision.mode:* specifies the mode of writing the resolution value into the IGES file.
|
||||
@ -715,8 +715,8 @@ Default value is 0.0001.
|
||||
|
||||
Default values :
|
||||
~~~~~
|
||||
write.iges.resource.name – IGES,
|
||||
write.iges.sequence – ToIGES.
|
||||
write.iges.resource.name - IGES,
|
||||
write.iges.sequence - ToIGES.
|
||||
~~~~~
|
||||
|
||||
@subsubsection occt_iges_3_3_3 Performing the Open CASCADE Technology shape translation
|
||||
@ -778,7 +778,7 @@ Translated objects depend on the write mode that you chose. If you chose the Fa
|
||||
| Geom_SurfaceOfRevolution | 120: Surface Of Revolution | |
|
||||
| Geom_OffsetSurface | 140: Offset Surface | |
|
||||
|
||||
@subsubsection occt_iges_3_4_3 Topological entities - Translation in Face mode
|
||||
@subsubsection occt_iges_3_4_3 Topological entities -- Translation in Face mode
|
||||
|
||||
| CASCADE shapes | IGES entity type | Comments |
|
||||
| :------------- | :--------------- | :------- |
|
||||
@ -793,7 +793,7 @@ Translated objects depend on the write mode that you chose. If you chose the Fa
|
||||
| TopoDS_CompSolid | 402: Form 1 Group or no equivalent | Group is created only if *TopoDS_CompSolid* contains more than one *TopoDS_Solid*. One IGES entity is created per *TopoDS_Solid*. |
|
||||
| TopoDS_Compound | 402: Form 1 Group or no equivalent | Group is created only if *TopoDS_Compound* contains more than one item. One IGES entity is created per *TopoDS_Shape* in the *TopoDS_Compound*. If *TopoDS_Compound* is nested into another *TopoDS_Compound*, it is not mapped. |
|
||||
|
||||
@subsubsection occt_iges_3_4_4 Topological entities - Translation in BRep mode
|
||||
@subsubsection occt_iges_3_4_4 Topological entities -- Translation in BRep mode
|
||||
|
||||
| CASCADE shapes | IGES entity type | Comments |
|
||||
| :------------- | :--------------- | :------- |
|
||||
@ -865,10 +865,10 @@ The third argument is used to set a new value of the given parameter. The resul
|
||||
During all interface operations, the protocol of the process (fail and warning messages, mapping of the loaded entities into OCCT shapes etc.) can be output to the trace file. Two parameters are defined in the DRAW session: trace level (integer value from 0 to 9, default is 0), and trace file (default is a standard output).
|
||||
|
||||
Command *xtrace* is intended to view and change these parameters:
|
||||
* *Draw> xtrace* - prints current settings (e.g.: "Level=0 - Standard Output");
|
||||
* *Draw> xtrace #* - sets the trace level to the value #;
|
||||
* *Draw> xtrace tracefile.log* - sets the trace file as *tracefile.log*;
|
||||
* *Draw xtrace* - directs all messages to the standard output.
|
||||
* *Draw> xtrace* -- prints current settings (e.g.: "Level=0 - Standard Output");
|
||||
* *Draw> xtrace #* -- sets the trace level to the value #;
|
||||
* *Draw> xtrace tracefile.log* -- sets the trace file as *tracefile.log*;
|
||||
* *Draw xtrace* -- directs all messages to the standard output.
|
||||
|
||||
@subsection occt_iges_4_3 Reading IGES files
|
||||
For a description of parameters used in reading an IGES file refer to @ref occt_iges_2_3_3 "Setting the translation parameters".
|
||||
@ -928,10 +928,10 @@ An asterisk “*” can be specified instead of *selection*, it means *xst-tran
|
||||
During the IGES translation, a map of correspondence between IGES entities and OCCT shapes is created.
|
||||
The following commands are available:
|
||||
|
||||
* *Draw> tpent \#* - provides information on the result of translation of the given IGES entity;
|
||||
* *Draw> tpdraw \#* - creates an OCCT shape corresponding to an IGES entity;
|
||||
* *Draw> fromshape \<shape_name\>* provides the number of an IGES entity corresponding to an OCCT shape;
|
||||
* *Draw> tpclear* clears the map of correspondences between IGES entities and OCCT shapes.
|
||||
* *Draw> tpent \#* -- provides information on the result of translation of the given IGES entity;
|
||||
* *Draw> tpdraw \#* --creates an OCCT shape corresponding to an IGES entity;
|
||||
* *Draw> fromshape \<shape_name\>* -- provides the number of an IGES entity corresponding to an OCCT shape;
|
||||
* *Draw> tpclear* -- clears the map of correspondences between IGES entities and OCCT shapes.
|
||||
|
||||
@subsection occt_iges_4_4 Analyzing the transferred data
|
||||
|
||||
@ -980,9 +980,9 @@ Draw> givecount <selection_name> [<selection_name>]
|
||||
prints a number of loaded entities defined by <i>selection</i> argument.
|
||||
|
||||
Three commands are used to calculate statistics on the entities in the model:
|
||||
* *Draw> count \<counter\> [\<selection\> ...]* - prints only a number of entities per each type matching the criteria defined by arguments.
|
||||
* *Draw> sumcount \<counter\> [\<selection\> ...]* - prints the total number of entities of all types matching the criteria defined by arguments and the largest number corresponding to one type.
|
||||
* *Draw> listcount \<counter\> [\<selection\> ...]* prints a list of entities per each type matching the criteria defined by arguments.
|
||||
* *Draw> count \<counter\> [\<selection\> ...]* -- prints only a number of entities per each type matching the criteria defined by arguments.
|
||||
* *Draw> sumcount \<counter\> [\<selection\> ...]* -- prints the total number of entities of all types matching the criteria defined by arguments and the largest number corresponding to one type.
|
||||
* *Draw> listcount \<counter\> [\<selection\> ...]* -- prints a list of entities per each type matching the criteria defined by arguments.
|
||||
|
||||
Optional <i>\<selection\></i> argument, if specified, defines a subset of entities, which are to be taken into account. Argument <i>\<counter\></i> should be one of the currently defined counters:
|
||||
|
||||
@ -1000,10 +1000,10 @@ gives a list of entity types which were encountered in the last loaded file (wi
|
||||
|
||||
Entities in the IGES file are numbered in the succeeding order. An entity can be identified either by its number (#) or by its label. Label is the letter ‘D’ followed by the index of the first line with the data for this entity in the Directory Entry section of the IGES file. The label can be calculated on the basis of the number as ‘D(2*# -1)’. For example, entity # 6 has label D11.
|
||||
|
||||
* *Draw> elab \#* - provides a label for an entity with a known number;
|
||||
* *Draw> enum \#* - prints a number for an entity with the given label;
|
||||
* *Draw> entity \# \<level_of_information\>* - gives the content of an IGES entity;
|
||||
* *Draw> estat \#* - provides the list of entities referenced by a given entity and the list of entities referencing to it.
|
||||
* *Draw> elab \#* -- provides a label for an entity with a known number;
|
||||
* *Draw> enum \#* -- prints a number for an entity with the given label;
|
||||
* *Draw> entity \# \<level_of_information\>* -- gives the content of an IGES entity;
|
||||
* *Draw> estat \#* -- provides the list of entities referenced by a given entity and the list of entities referencing to it.
|
||||
|
||||
@subsubsection occt_iges_4_4_2 Estimating the results of reading IGES
|
||||
All of the following commands are available only after the data are converted into OCCT shapes (i.e. after command **igesbrep**).
|
||||
@ -1012,17 +1012,17 @@ All of the following commands are available only after the data are converted i
|
||||
Draw> tpstat [*|?]<symbol> [<selection>]
|
||||
~~~~~
|
||||
provides all statistics on the last transfer, including the list of transferred entities with mapping from IGES to OCCT types, as well as fail and warning messages. The parameter <i>\<symbol\></i> defines what information will be printed:
|
||||
* G - General statistics (list of results and messages)
|
||||
* C - Count of all warning and fail messages
|
||||
* C - List of all warning and fail messages
|
||||
* F - Count of all fail messages
|
||||
* F - List of all fail messages
|
||||
* N - List of all transferred roots
|
||||
* S - The same, with types of source entity and result type
|
||||
* B - The same, with messages
|
||||
* T - Count of roots for geometrical types
|
||||
* R - Count of roots for topological types
|
||||
* l - The same, with a type of the source entity
|
||||
* G -- General statistics (list of results and messages)
|
||||
* C -- Count of all warning and fail messages
|
||||
* C -- List of all warning and fail messages
|
||||
* F -- Count of all fail messages
|
||||
* F -- List of all fail messages
|
||||
* N -- List of all transferred roots
|
||||
* S -- The same, with types of source entity and result type
|
||||
* B -- The same, with messages
|
||||
* T -- Count of roots for geometrical types
|
||||
* R -- Count of roots for topological types
|
||||
* l -- The same, with a type of the source entity
|
||||
|
||||
The sign ‘*’ before the parameters **n**, **s**, **b**, **t**, **r** makes it work on all entities (not only on roots). The sign ‘?’ before **n**, **s**, **b**, **t** limits the scope of information to invalid entities.
|
||||
|
||||
@ -1038,11 +1038,11 @@ The second version of the same command is TPSTAT (not capital spelling).
|
||||
Draw:> TPSTAT <symbol>
|
||||
~~~~~
|
||||
Symbol can be of the following values:
|
||||
* g - General statistics (list of results and messages)
|
||||
* c - Count of all warning and fail messages
|
||||
* C - List of all warning and fail messages
|
||||
* r - Count of resulting OCCT shapes per each type
|
||||
* s - Mapping of IGES roots and resulting OCCT shapes
|
||||
* g -- General statistics (list of results and messages)
|
||||
* c -- Count of all warning and fail messages
|
||||
* C -- List of all warning and fail messages
|
||||
* r -- Count of resulting OCCT shapes per each type
|
||||
* s -- Mapping of IGES roots and resulting OCCT shapes
|
||||
|
||||
Sometimes the trimming contours of IGES faces (i.e., entity 141 for 143, 142 for 144) can be lost during translation due to fails.
|
||||
|
||||
@ -1083,10 +1083,10 @@ It outputs maximum, average and minimum values of tolerances for each kind of s
|
||||
When specifying *min* and *max* arguments this command outputs shapes with names <i>\<shape_name\>...</i> and their total number with tolerances in the range <i>[min, max]</i>.
|
||||
|
||||
<i>\<Symbol\></i> is used for specifying the kind of sub-shapes to analyze:
|
||||
* v - for vertices,
|
||||
* e - for edges,
|
||||
* f - for faces,
|
||||
* c - for shells and faces.
|
||||
* v -- for vertices,
|
||||
* e -- for edges,
|
||||
* f -- for faces,
|
||||
* c -- for shells and faces.
|
||||
|
||||
@subsection occt_iges_4_5 Writing an IGES file
|
||||
|
||||
|
||||
@ -230,10 +230,10 @@ as the left-hand side of the curve in relation to its orientation.
|
||||
This technique of qualification of a solution, in relation to the curves to which
|
||||
it is tangential, can be used in all algorithms for constructing a circle or a straight
|
||||
line by geometric constraints. Four qualifiers are used:
|
||||
* **Enclosing** - the solution(s) must enclose the argument;
|
||||
* **Enclosed** - the solution(s) must be enclosed by the argument;
|
||||
* **Outside** - the solution(s) and the argument must be external to one another;
|
||||
* **Unqualified** - the relative position is not qualified, i.e. all solutions apply.
|
||||
* **Enclosing** -- the solution(s) must enclose the argument;
|
||||
* **Enclosed** -- the solution(s) must be enclosed by the argument;
|
||||
* **Outside** -- the solution(s) and the argument must be external to one another;
|
||||
* **Unqualified** -- the relative position is not qualified, i.e. all solutions apply.
|
||||
|
||||
It is possible to create expressions using the qualifiers, for example:
|
||||
~~~~~
|
||||
@ -588,9 +588,9 @@ The class *GeomFill_BoundWithSurf* allows defining a boundary for the surface to
|
||||
|
||||
The enumerations *FillingStyle* specify the styles used to build the surface. These include:
|
||||
|
||||
* *Stretch* - the style with the flattest patches
|
||||
* *Coons* - a rounded style with less depth than *Curved*
|
||||
* *Curved* - the style with the most rounded patches.
|
||||
* *Stretch* -- the style with the flattest patches
|
||||
* *Coons* -- a rounded style with less depth than *Curved*
|
||||
* *Curved* -- the style with the most rounded patches.
|
||||
|
||||
@image html /user_guides/modeling_algos/images/modeling_algos_image018.png "Intersecting filleted edges with different radii leave a gap, is filled by a surface"
|
||||
@image latex /user_guides/modeling_algos/images/modeling_algos_image018.png "Intersecting filleted edges with different radii leave a gap, is filled by a surface"
|
||||
@ -1318,13 +1318,13 @@ If *BRepBuilderAPI_MakeEdge* is used as a class, it can provide two vertices. Th
|
||||
|
||||
The *Error* method returns a term of the *BRepBuilderAPI_EdgeError* enumeration. It can be used to analyze the error when *IsDone* method returns False. The terms are:
|
||||
|
||||
* **EdgeDone** - No error occurred, *IsDone* returns True.
|
||||
* **PointProjectionFailed** - No parameters were given, but the projection of the 3D points on the curve failed. This happens if the point distance to the curve is greater than the precision.
|
||||
* **ParameterOutOfRange** - The given parameters are not in the range *C->FirstParameter()*, *C->LastParameter()*
|
||||
* **DifferentPointsOnClosedCurve** - The two vertices or points have different locations but they are the extremities of a closed curve.
|
||||
* **PointWithInfiniteParameter** - A finite coordinate point was associated with an infinite parameter (see the Precision package for a definition of infinite values).
|
||||
* **DifferentsPointAndParameter** - The distance of the 3D point and the point evaluated on the curve with the parameter is greater than the precision.
|
||||
* **LineThroughIdenticPoints** - Two identical points were given to define a line (construction of an edge without curve), *gp::Resolution* is used to test confusion .
|
||||
* **EdgeDone** -- No error occurred, *IsDone* returns True.
|
||||
* **PointProjectionFailed** -- No parameters were given, but the projection of the 3D points on the curve failed. This happens if the point distance to the curve is greater than the precision.
|
||||
* **ParameterOutOfRange** -- The given parameters are not in the range *C->FirstParameter()*, *C->LastParameter()*
|
||||
* **DifferentPointsOnClosedCurve** -- The two vertices or points have different locations but they are the extremities of a closed curve.
|
||||
* **PointWithInfiniteParameter** -- A finite coordinate point was associated with an infinite parameter (see the Precision package for a definition of infinite values).
|
||||
* **DifferentsPointAndParameter** -- The distance of the 3D point and the point evaluated on the curve with the parameter is greater than the precision.
|
||||
* **LineThroughIdenticPoints** -- Two identical points were given to define a line (construction of an edge without curve), *gp::Resolution* is used to test confusion .
|
||||
|
||||
The following example creates a rectangle centered on the origin of dimensions H, L with fillets of radius R. The edges and the vertices are stored in the arrays *theEdges* and *theVertices*. We use class *Array1OfShape* (i.e. not arrays of edges or vertices). See the image below.
|
||||
|
||||
@ -1541,11 +1541,11 @@ To add more than one wire an instance of the *BRepBuilderAPI_MakeFace* class ca
|
||||
|
||||
The *Error* method returns an error status, which is a term from the *BRepBuilderAPI_FaceError* enumeration.
|
||||
|
||||
* *FaceDone* - no error occurred.
|
||||
* *NoFace* - no initialization of the algorithm; an empty constructor was used.
|
||||
* *NotPlanar* - no surface was given and the wire was not planar.
|
||||
* *CurveProjectionFailed* - no curve was found in the parametric space of the surface for an edge.
|
||||
* *ParametersOutOfRange* - the parameters *umin, umax, vmin, vmax* are out of the surface.
|
||||
* *FaceDone* -- no error occurred.
|
||||
* *NoFace* -- no initialization of the algorithm; an empty constructor was used.
|
||||
* *NotPlanar* -- no surface was given and the wire was not planar.
|
||||
* *CurveProjectionFailed* -- no curve was found in the parametric space of the surface for an edge.
|
||||
* *ParametersOutOfRange* -- the parameters *umin, umax, vmin, vmax* are out of the surface.
|
||||
|
||||
@subsection occt_modalg_3_6 Wire
|
||||
The wire is a composite shape built not from a geometry, but by the assembly of edges. *BRepBuilderAPI_MakeWire* class can build a wire from one or more edges or connect new edges to an existing wire.
|
||||
@ -1587,10 +1587,10 @@ return MW;
|
||||
BRepBuilderAPI_MakeWire class can return the last edge added to the wire (Edge method). This edge can be different from the original edge if it was copied.
|
||||
|
||||
The Error method returns a term of the *BRepBuilderAPI_WireError* enumeration:
|
||||
*WireDone* - no error occurred.
|
||||
*EmptyWire* - no initialization of the algorithm, an empty constructor was used.
|
||||
*DisconnectedWire* - the last added edge was not connected to the wire.
|
||||
*NonManifoldWire* - the wire with some singularity.
|
||||
*WireDone* -- no error occurred.
|
||||
*EmptyWire* -- no initialization of the algorithm, an empty constructor was used.
|
||||
*DisconnectedWire* -- the last added edge was not connected to the wire.
|
||||
*NonManifoldWire* -- the wire with some singularity.
|
||||
|
||||
@subsection occt_modalg_3_7 Shell
|
||||
The shell is a composite shape built not from a geometry, but by the assembly of faces.
|
||||
@ -1744,10 +1744,10 @@ TopoDS_Solid S = BRepPrimAPI_MakeCone(R1,R2,H);
|
||||
@subsubsection occt_modalg_4_1_6 Sphere
|
||||
*BRepPrimAPI_MakeSphere* class allows creating spherical primitives. Like a cylinder, a sphere is created either in the default coordinate system or in a given coordinate system *gp_Ax2*. There are four constructions:
|
||||
|
||||
* From a radius - builds a full sphere.
|
||||
* From a radius and an angle - builds a lune (digon).
|
||||
* From a radius and two angles - builds a wraparound spherical segment between two latitudes. The angles *a1* and *a2* must follow the relation: <i>PI/2 <= a1 < a2 <= PI/2 </i>.
|
||||
* From a radius and three angles - a combination of two previous methods builds a portion of spherical segment.
|
||||
* From a radius -- builds a full sphere.
|
||||
* From a radius and an angle -- builds a lune (digon).
|
||||
* From a radius and two angles -- builds a wraparound spherical segment between two latitudes. The angles *a1* and *a2* must follow the relation: <i>PI/2 <= a1 < a2 <= PI/2 </i>.
|
||||
* From a radius and three angles -- a combination of two previous methods builds a portion of spherical segment.
|
||||
|
||||
The following code builds four spheres from a radius and three angles.
|
||||
|
||||
@ -1769,10 +1769,10 @@ Note that we could equally well choose to create Shells instead of Solids.
|
||||
@subsubsection occt_modalg_4_1_7 Torus
|
||||
*BRepPrimAPI_MakeTorus* class allows creating toroidal primitives. Like the other primitives, a torus is created either in the default coordinate system or in a given coordinate system *gp_Ax2*. There are four constructions similar to the sphere constructions:
|
||||
|
||||
* Two radii - builds a full torus.
|
||||
* Two radii and an angle - builds an angular torus segment.
|
||||
* Two radii and two angles - builds a wraparound torus segment between two radial planes. The angles a1, a2 must follow the relation 0 < a2 - a1 < 2*PI.
|
||||
* Two radii and three angles - a combination of two previous methods builds a portion of torus segment.
|
||||
* Two radii -- builds a full torus.
|
||||
* Two radii and an angle -- builds an angular torus segment.
|
||||
* Two radii and two angles -- builds a wraparound torus segment between two radial planes. The angles a1, a2 must follow the relation 0 < a2 - a1 < 2*PI.
|
||||
* Two radii and three angles -- a combination of two previous methods builds a portion of torus segment.
|
||||
|
||||
@image html /user_guides/modeling_algos/images/modeling_algos_image032.png "Examples of Tori"
|
||||
@image latex /user_guides/modeling_algos/images/modeling_algos_image032.png "Examples of Tori"
|
||||
@ -1819,9 +1819,9 @@ It is forbidden to sweep Solids and Composite Solids. A Compound generates a Co
|
||||
@image latex /user_guides/modeling_algos/images/modeling_algos_image033.png "Generating a sweep"
|
||||
|
||||
*BRepPrimAPI_MakeSweep class* is a deferred class used as a root of the the following sweep classes:
|
||||
* *BRepPrimAPI_MakePrism* - produces a linear sweep
|
||||
* *BRepPrimAPI_MakeRevol* - produces a rotational sweep
|
||||
* *BRepPrimAPI_MakePipe* - produces a general sweep.
|
||||
* *BRepPrimAPI_MakePrism* -- produces a linear sweep
|
||||
* *BRepPrimAPI_MakeRevol* -- produces a rotational sweep
|
||||
* *BRepPrimAPI_MakePipe* -- produces a general sweep.
|
||||
|
||||
|
||||
@subsubsection occt_modalg_4_2_2 Prism
|
||||
@ -2588,7 +2588,7 @@ TopoDS_Shape res1 = MKPipe.Shape();
|
||||
|
||||
Mechanical features include ribs, protrusions and grooves (or slots), depressions along planar (linear) surfaces or revolution surfaces.
|
||||
|
||||
The semantics of mechanical features is built around giving thickness to a contour. This thickness can either be symmetrical - on one side of the contour - or dissymmetrical - on both sides. As in the semantics of form features, the thickness is defined by construction of shapes in specific contexts.
|
||||
The semantics of mechanical features is built around giving thickness to a contour. This thickness can either be symmetrical -- on one side of the contour -- or dissymmetrical -- on both sides. As in the semantics of form features, the thickness is defined by construction of shapes in specific contexts.
|
||||
|
||||
The development contexts differ, however, in the case of mechanical features.
|
||||
Here they include extrusion:
|
||||
@ -2690,9 +2690,9 @@ The class *BRepFeat_SplitShape* is used to split faces of a shape into wires or
|
||||
|
||||
The class is created or initialized from a shape (the basic shape).
|
||||
Three Add methods are available:
|
||||
* *Add(Wire, Face)* - adds a new wire on a face of the basic shape.
|
||||
* *Add(Edge, Face)* - adds a new edge on a face of the basic shape.
|
||||
* *Add(EdgeNew, EdgeOld)* - adds a new edge on an existing one (the old edge must contain the new edge).
|
||||
* *Add(Wire, Face)* -- adds a new wire on a face of the basic shape.
|
||||
* *Add(Edge, Face)* -- adds a new edge on a face of the basic shape.
|
||||
* *Add(EdgeNew, EdgeOld)* -- adds a new edge on an existing one (the old edge must contain the new edge).
|
||||
|
||||
**Note** The added wires and edges must define closed wires on faces or wires located between two existing edges. Existing edges must not be intersected.
|
||||
|
||||
@ -2903,7 +2903,7 @@ const Standard_Real anAngularDeflection = 0.5;
|
||||
BRepMesh_IncrementalMesh aMesh(aShape, aLinearDeflection, Standard_False, anAngularDeflection);
|
||||
~~~~~
|
||||
|
||||
The default meshing algorithm *BRepMesh_IncrementalMesh* has two major options to define triangulation – linear and angular deflections.
|
||||
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.
|
||||
|
||||
|
||||
@ -452,8 +452,8 @@ and, in particular, to compute the point of parameter u on a curve and the deriv
|
||||
|
||||
As a consequence of the parameterization, a <i> Geom2d </i> curve is naturally oriented.
|
||||
|
||||
Parameterization and orientation differentiate elementary <i>Geom2d </i>curves from their
|
||||
equivalent as provided by <i> gp</i> package. <i> Geom2d</i> package provides conversion
|
||||
Parameterization and orientation differentiate elementary <i>Geom2d</i>curves from their
|
||||
equivalent as provided by <i> gp</i> package. <i>Geom2d</i> package provides conversion
|
||||
functions to transform a <i> Geom2d</i> object into a <i> gp</i> object, and vice-versa, when this is possible.
|
||||
|
||||
Moreover, <i> Geom2d</i> package provides more complex curves, including Bezier curves,
|
||||
@ -641,10 +641,10 @@ A surface (for two parameters U and V) has the following local properties:
|
||||
- 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.
|
||||
* *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.
|
||||
|
||||
@ -686,14 +686,14 @@ Topological library allows you to build pure topological data structures. Topolo
|
||||
|
||||
You can, for example, represent a single object made of several distinct bodies containing embedded curves and surfaces connected or non-connected to an outer boundary.
|
||||
|
||||
Abstract topological data structure describes a basic entity - a shape, which can be divided into the following component topologies:
|
||||
* Vertex - a zero-dimensional shape corresponding to a point in geometry;
|
||||
* Edge - a shape corresponding to a curve, and bound by a vertex at each extremity;
|
||||
* Wire - a sequence of edges connected by their vertices;
|
||||
* Face - part of a plane (in 2D geometry) or a surface (in 3D geometry) bounded by a closed wire;
|
||||
* Shell - a collection of faces connected by some edges of their wire boundaries;
|
||||
* Solid - a part of 3D space bound by a shell;
|
||||
* Compound solid - a collection of solids.
|
||||
Abstract topological data structure describes a basic entity -- a shape, which can be divided into the following component topologies:
|
||||
* Vertex -- a zero-dimensional shape corresponding to a point in geometry;
|
||||
* Edge -- a shape corresponding to a curve, and bound by a vertex at each extremity;
|
||||
* Wire -- a sequence of edges connected by their vertices;
|
||||
* Face -- part of a plane (in 2D geometry) or a surface (in 3D geometry) bounded by a closed wire;
|
||||
* Shell -- a collection of faces connected by some edges of their wire boundaries;
|
||||
* Solid -- a part of 3D space bound by a shell;
|
||||
* Compound solid -- a collection of solids.
|
||||
|
||||
The wire and the solid can be either infinite or closed.
|
||||
|
||||
@ -756,15 +756,15 @@ The **TopAbs** package provides general enumerations describing the basic concep
|
||||
@subsubsection occt_modat_5_2_1 Topological types
|
||||
|
||||
TopAbs contains the *TopAbs_ShapeEnum* enumeration,which lists the different topological types:
|
||||
- COMPOUND - a group of any type of topological objects.
|
||||
- COMPSOLID - a composite solid is a set of solids connected by their faces. It expands the notions of WIRE and SHELL to solids.
|
||||
- SOLID - a part of space limited by shells. It is three dimensional.
|
||||
- SHELL - a set of faces connected by their edges. A shell can be open or closed.
|
||||
- FACE - in 2D it is a part of a plane; in 3D it is a part of a surface. Its geometry is constrained (trimmed) by contours. It is two dimensional.
|
||||
- WIRE - a set of edges connected by their vertices. It can be an open or closed contour depending on whether the edges are linked or not.
|
||||
- EDGE - a topological element corresponding to a restrained curve. An edge is generally limited by vertices. It has one dimension.
|
||||
- VERTEX - a topological element corresponding to a point. It has zero dimension.
|
||||
- SHAPE - a generic term covering all of the above.
|
||||
- COMPOUND -- a group of any type of topological objects.
|
||||
- COMPSOLID -- a composite solid is a set of solids connected by their faces. It expands the notions of WIRE and SHELL to solids.
|
||||
- SOLID -- a part of space limited by shells. It is three dimensional.
|
||||
- SHELL -- a set of faces connected by their edges. A shell can be open or closed.
|
||||
- FACE -- in 2D it is a part of a plane; in 3D it is a part of a surface. Its geometry is constrained (trimmed) by contours. It is two dimensional.
|
||||
- WIRE -- a set of edges connected by their vertices. It can be an open or closed contour depending on whether the edges are linked or not.
|
||||
- EDGE -- a topological element corresponding to a restrained curve. An edge is generally limited by vertices. It has one dimension.
|
||||
- VERTEX -- a topological element corresponding to a point. It has zero dimension.
|
||||
- SHAPE -- a generic term covering all of the above.
|
||||
|
||||
A topological model can be considered as a graph of objects with adjacency relationships. When modeling a part in 2D or 3D space it must belong to one of the categories listed in the ShapeEnum enumeration. The TopAbspackage lists all the objects, which can be found in any model. It cannot be extended but a subset can be used. For example, the notion of solid is useless in 2D.
|
||||
|
||||
@ -799,7 +799,7 @@ Based on this default region the orientation allows definition of the region to
|
||||
@image html /user_guides/modeling_data/images/modeling_data_image007.png "Four Orientations"
|
||||
@image latex /user_guides/modeling_data/images/modeling_data_image007.png "Four Orientations"
|
||||
|
||||
The notion of orientation is a very general one, and it can be used in any context where regions or boundaries appear. Thus, for example, when describing the intersection of an edge and a contour it is possible to describe not only the vertex of intersection but also how the edge crosses the contour considering it as a boundary. The edge would therefore be divided into two regions - exterior and interior - with the intersection vertex as the boundary. Thus an orientation can be associated with an intersection vertex as in the following figure:
|
||||
The notion of orientation is a very general one, and it can be used in any context where regions or boundaries appear. Thus, for example, when describing the intersection of an edge and a contour it is possible to describe not only the vertex of intersection but also how the edge crosses the contour considering it as a boundary. The edge would therefore be divided into two regions: exterior and interior and the intersection vertex would be the boundary. Thus an orientation can be associated with an intersection vertex as in the following figure:
|
||||
|
||||
| Orientation | Association |
|
||||
| :-------- | :-------- |
|
||||
@ -847,7 +847,7 @@ OCCT topological descriptions also allow the simple shapes defined in these term
|
||||
|
||||
Listing shapes in order of complexity from vertex to composite solid leads us to the notion of the data structure as knowledge of how to break a shape down into a set of simpler shapes. This is in fact, the purpose of the *TopoDS* package.
|
||||
|
||||
The model of a shape is a shareable data structure because it can be used by other shapes. (An edge can be used by more than one face of a solid). A shareable data structure is handled by reference. When a simple reference is insufficient, two pieces of information are added - an orientation and a local coordinate reference.
|
||||
The model of a shape is a shareable data structure because it can be used by other shapes. (An edge can be used by more than one face of a solid). A shareable data structure is handled by reference. When a simple reference is insufficient, two pieces of information are added: an orientation and a local coordinate reference.
|
||||
- An orientation tells how the referenced shape is used in a boundary (*Orientation* from *TopAbs*).
|
||||
- A local reference coordinate (*Location* from *TopLoc*) allows referencing a shape at a position different from that of its definition.
|
||||
|
||||
@ -1070,10 +1070,10 @@ The following steps are performed:
|
||||
**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*.
|
||||
|
||||
|
||||
* *TopTools_Array1OfShape, HArray1OfShape* - Instantiation of the *TCollection_Array1* and *TCollection_HArray1* with *TopoDS_Shape*.
|
||||
* *TopTools_SequenceOfShape* - Instantiation of the *TCollection_Sequence* with *TopoDS_Shape*.
|
||||
* *TopTools_MapOfShape* - Instantiation of the *TCollection_Map*. Allows the construction of sets of shapes.
|
||||
* *TopTools_IndexedMapOfShape* - Instantiation of the *TCollection_IndexedMap*. Allows the construction of tables of shapes and other data structures.
|
||||
* *TopTools_Array1OfShape, HArray1OfShape* -- instantiation of the *TCollection_Array1* and *TCollection_HArray1* with *TopoDS_Shape*.
|
||||
* *TopTools_SequenceOfShape* -- instantiation of the *TCollection_Sequence* with *TopoDS_Shape*.
|
||||
* *TopTools_MapOfShape* - instantiation of the *TCollection_Map*. Allows the construction of sets of shapes.
|
||||
* *TopTools_IndexedMapOfShape* - instantiation of the *TCollection_IndexedMap*. Allows the construction of tables of shapes and other data structures.
|
||||
|
||||
With a *TopTools_Map*, a set of references to Shapes can be kept without duplication.
|
||||
The following example counts the size of a data structure as a number of *TShapes*.
|
||||
|
||||
@ -19,8 +19,8 @@ OCAF (the Open CASCADE Application Framework) is an easy-to-use platform for ra
|
||||
|
||||
Developing a design application requires addressing many technical aspects.
|
||||
In particular, given the functional specification of your application, you must at least:
|
||||
|
||||
* Design the architecture of the application — definition of the software components and the way they cooperate;
|
||||
|
||||
* Design the architecture of the application— definition of the software components and the way they cooperate;
|
||||
* Define the data model able to support the functionality required — a design application operates on data maintained during the whole end-user working session;
|
||||
* Structure the software in order to:
|
||||
* synchronize the display with the data — commands modifying objects must update the views;
|
||||
@ -35,7 +35,7 @@ Architectural guidance and ready-to-use solutions provided by OCAF offer you the
|
||||
* The final application can be developed by industrializing the prototype — you don't need to restart the development from scratch.
|
||||
* The Open Source nature of the platform guarantees the long-term usefulness of your development.
|
||||
|
||||
OCAF is much more than just one toolkit among many in the CAS.CADE Object Libraries. Since it can handle any data and algorithms in these libraries - be it modeling algorithms, topology or geometry - OCAF is their logical supplement.
|
||||
OCAF is much more than just one toolkit among many in the CAS.CADE Object Libraries. Since it can handle any data and algorithms in these libraries -- be it modeling algorithms, topology or geometry -- OCAF is their logical supplement.
|
||||
|
||||
The table below contrasts the design of a modeling application using object libraries alone and using OCAF.
|
||||
|
||||
@ -265,7 +265,7 @@ The root label cannot have brother labels. Consequently, various lamps in the fr
|
||||
* a bulb label with tag 2
|
||||
* a stem label with tag 3
|
||||
|
||||
Label tags are chosen at will. They are only identifiers of the lamp parts. Now you can refine all units: by setting geometry, color, material and other information about the lamp or its parts to the specified label. This information is placed into special attributes of the label: the pure label contains no data – it is only a key to access data.
|
||||
Label tags are chosen at will. They are only identifiers of the lamp parts. Now you can refine all units: by setting geometry, color, material and other information about the lamp or its parts to the specified label. This information is placed into special attributes of the label: the pure label contains no data -- it is only a key to access data.
|
||||
|
||||
Remember that tags are private addresses without any meaning outside the data framework. It would, for instance, be an error to use part names as tags. These might change or be removed from production in next versions of the application, whereas the exact form of that part might be reused in your design, the part name could be integrated into the framework as an attribute.
|
||||
|
||||
@ -292,7 +292,7 @@ In relative identification, a label’s tag has a meaning relative to the father
|
||||
|
||||
In absolute identification, a label’s place in the data framework is specified unambiguously by a colon-separated list of tags of all the labels from the one in question to the root of the data framework. This list is called an entry. *TDF_Tool::TagList* allows retrieving the entry for a specific label.
|
||||
|
||||
In both relative and absolute identification, it is important to remember that the value of an integer has no intrinsic semantics whatsoever. In other words, the natural sequence that integers suggest, i.e. 0, 1, 2, 3, 4 ... - has no importance here. The integer value of a tag is simply a key.
|
||||
In both relative and absolute identification, it is important to remember that the value of an integer has no intrinsic semantics whatsoever. In other words, the natural sequence that integers suggest, i.e. 0, 1, 2, 3, 4 ... -- has no importance here. The integer value of a tag is simply a key.
|
||||
|
||||
The tag can be created in two ways:
|
||||
|
||||
@ -327,7 +327,7 @@ Standard_Integer tag = achild.Tag();
|
||||
|
||||
@subsection occt_ocaf_3_4 Label
|
||||
|
||||
The tag gives a persistent address to a label. The label – the semantics of the tag – is a place in the data framework where attributes, which contain data, are attached. The data framework is, in fact, a tree of labels with a root as the ultimate father label.
|
||||
The tag gives a persistent address to a label. The label -- the semantics of the tag -- is a place in the data framework where attributes, which contain data, are attached. The data framework is, in fact, a tree of labels with a root as the ultimate father label.
|
||||
|
||||
Label can not be deleted from the data framework, so, the structure of the data framework that has been created can not be removed while the document is opened. Hence any kind of reference to an existing label will be actual while an application is working with the document.
|
||||
|
||||
@ -406,7 +406,7 @@ isroot = father.IsRoot();
|
||||
|
||||
@subsection occt_ocaf_3_5 Attribute
|
||||
|
||||
The label itself contains no data. All data of any type whatsoever - application or non-application - is contained in attributes. These are attached to labels, and there are different types for different types of data. OCAF provides many ready-to-use standard attributes such as integer, real, constraint, axis and plane. There are also attributes for topological naming, functions and visualization. Each type of attribute is identified by a GUID.
|
||||
The label itself contains no data. All data of any type whatsoever -- application or non-application -- is contained in attributes. These are attached to labels, and there are different types for different types of data. OCAF provides many ready-to-use standard attributes such as integer, real, constraint, axis and plane. There are also attributes for topological naming, functions and visualization. Each type of attribute is identified by a GUID.
|
||||
|
||||
The advantage of OCAF is that all of the above attribute types are handled in the same way. Whatever the attribute type is, you can create new instances of them, retrieve them, attach them to and remove them from labels, "forget" and "remember" the attributes of a particular label.
|
||||
|
||||
@ -485,11 +485,11 @@ There are two ways to implement a new data type: create a new attribute (standar
|
||||
|
||||
In order to create a new attribute in the standard way do the following:
|
||||
* Create a class inherited from *TDF_Attribute* and implement all purely virtual and necessary virtual methods:
|
||||
+ **ID()** – returns a unique GUID of a given attribute
|
||||
+ **Restore(attribute)** – sets fields of this attribute equal to the fields of a given attribute of the same type
|
||||
+ **Paste(attribute, relocation_table)** – sets fields of a given attribute equal to the field values of this attribute ; if the attribute has references to some objects of the data framework and relocation_table has this element, then the given attribute must also refer to this object .
|
||||
+ **NewEmpty()** - returns a new attribute of this class with empty fields
|
||||
+ **Dump(stream)** - outputs information about a given attribute to a given stream debug (usually outputs an attribute of type string only)
|
||||
+ **ID()** -- returns a unique GUID of a given attribute
|
||||
+ **Restore(attribute)** -- sets fields of this attribute equal to the fields of a given attribute of the same type
|
||||
+ **Paste(attribute, relocation_table)** -- sets fields of a given attribute equal to the field values of this attribute ; if the attribute has references to some objects of the data framework and relocation_table has this element, then the given attribute must also refer to this object .
|
||||
+ **NewEmpty()** -- returns a new attribute of this class with empty fields
|
||||
+ **Dump(stream)** -- outputs information about a given attribute to a given stream debug (usually outputs an attribute of type string only)
|
||||
* Create the persistence classes for this attribute according to the file format chosen for the document (see below).
|
||||
|
||||
Methods *NewEmpty, Restore* and *Paste* are used for the common transactions mechanism (Undo/Redo commands). If you don’t need this attribute to react to undo/redo commands, you can write only stubs of these methods, else you must call the Backup method of the *TDF_Attribute* class every time attribute fields are changed.
|
||||
@ -497,8 +497,8 @@ Methods *NewEmpty, Restore* and *Paste* are used for the common transactions mec
|
||||
If you use a standard file format and you want your new attributes to be stored during document saving and retrieved to the data framework whenever a document is opened, you must do the following:
|
||||
|
||||
1. If you place an attribute to a new package, it is desirable (although not mandatory) if your package name starts with letter "T" (transient), for example: attribute *TMyAttributePackage_MyAttribute* in the package *TMyAttributePackage*.
|
||||
2. Create a new package with name "P[package name]" (for example *PMyAttributePackage*) with class *PMyAttributePackage_MyAttribute* inside. The new class inherits the *PDF_Attribute* class and contains fields of attributes, which must be saved or retrieved ("P" - persistent).
|
||||
3. Create a new package with name "M[package name]" (for example *MMyAttributePackage*) with classes *MMyAttributePackage_MyAttributeRetrievalDriver* and *MMyAttributePackage_MyAttributeStorageDriver* inside. The new classes inherit *MDF_ARDriver* and *MDF_ASDriver* classes respectively and contain the translation functionality: from T... attribute to P... and vice versa (M - middle) (see the realization of the standard attributes).
|
||||
2. Create a new package with name "P[package name]" (for example *PMyAttributePackage*) with class *PMyAttributePackage_MyAttribute* inside. The new class inherits the *PDF_Attribute* class and contains fields of attributes, which must be saved or retrieved ("P" -- persistent).
|
||||
3. Create a new package with name "M[package name]" (for example *MMyAttributePackage*) with classes *MMyAttributePackage_MyAttributeRetrievalDriver* and *MMyAttributePackage_MyAttributeStorageDriver* inside. The new classes inherit *MDF_ARDriver* and *MDF_ASDriver* classes respectively and contain the translation functionality: from T... attribute to P... and vice versa (M -- middle) (see the realization of the standard attributes).
|
||||
4. M... package must contain *AddStorageDrivers(aDriverSeq : ASDriverHSequence* from MDF) and *AddRetrievalDrivers(aDriverSeq : ASDriverHSequence* from MDF) methods, which append to the given sequence of drivers *aDriverSeq*, which is a sequence of all new attribute drivers (see the previous point) used for the storage/retrieval of attributes.
|
||||
5 Use the standard schema (*StdSchema* unit) or create a new one to add your P-package and compile it.
|
||||
|
||||
@ -666,7 +666,7 @@ doc = TDocStd_Document::Get(label);
|
||||
If in your document you use only standard attributes (from the packages *TDF, TDataStd, TNaming, TFunction, TPrsStd* and *TDocStd*), you just do the following steps:
|
||||
|
||||
* In your application class (which inherits class *TDocStd_Application*) implement two methods:
|
||||
+ Formats (TColStd_SequenceOfExtendedString& theFormats), which append to a given sequence <i>\<theFormats\></i> your document format string, for example, "NewDocumentFormat" – this string is also set in the document creation command
|
||||
+ Formats (TColStd_SequenceOfExtendedString& theFormats), which append to a given sequence <i>\<theFormats\></i> your document format string, for example, "NewDocumentFormat" -- this string is also set in the document creation command
|
||||
+ ResourcesName(), which returns a string with a name of resources file (this file contains a description about the extension of the document, storage/retrieval drivers GUIDs...), for example, "NewFormat"
|
||||
* Create the resource file (with name, for example, "NewFormat") with the following strings:
|
||||
|
||||
@ -802,7 +802,7 @@ XLinkTool.UpdateLink(target);
|
||||
|
||||
#### Without any link between the copy and the original
|
||||
|
||||
You can also create a copy of the document with no link between the original and the copy. The syntax to use this option is *TDocStd_XLinkTool::Copy*. The copied document is again represented by the argument *target*, and the original – by *source.*
|
||||
You can also create a copy of the document with no link between the original and the copy. The syntax to use this option is *TDocStd_XLinkTool::Copy*. The copied document is again represented by the argument *target*, and the original -- by *source.*
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
XLinkTool.Copy(target, source);
|
||||
@ -838,9 +838,11 @@ Consider the following example. Two boxes (solids) are fused into one solid (the
|
||||
@image html /user_guides/ocaf/images/ocaf_image014.png "Resulting box"
|
||||
@image latex /user_guides/ocaf/images/ocaf_image014.png "Resulting box"
|
||||
|
||||
After the fuse operation a modified result is placed to a separate label as a named shape, which refers to the old shape – one of the boxes, as well as to the new shape – the shape resulting from the fuse operation – and has evolution MODIFY (see the following figure).
|
||||
After the fuse operation a modified result is placed to a separate label as a named shape, which refers to the old shape (one of the boxes) and to the new shape resulting from the fuse operation, and has evolution MODIFY (see the following figure).
|
||||
|
||||
Named shapes, which contain information about modified faces, belong to the fuse result sub-labels: sub-label with tag 1 – modified faces from box 1, sub-label with tag 2 – modified faces from box 2.
|
||||
Named shapes, which contain information about modified faces, belong to the fuse result sub-labels:
|
||||
* sub-label with tag 1 -- modified faces from box 1,
|
||||
* sub-label with tag 2 -- modified faces from box 2.
|
||||
|
||||
@image html /user_guides/ocaf/images/ocaf_image015.png
|
||||
@image latex /user_guides/ocaf/images/ocaf_image015.png
|
||||
@ -860,11 +862,11 @@ When using TNaming_NamedShape to create attributes, the following fields of an a
|
||||
|
||||
* A list of shapes called the "old" and the "new" shapes A new shape is recomputed as the value of the named shape. The meaning of this pair depends on the type of evolution.
|
||||
* The type of evolution, which is a term of the *TNaming_Evolution* enumeration used for the selected shapes that are placed to the separate label:
|
||||
* PRIMITIVE – newly created topology, with no previous history;
|
||||
* GENERATED – as usual, this evolution of a named shape means, that the new shape is created from a low-level old shape ( a prism face from an edge, for example );
|
||||
* MODIFY – the new shape is a modified old shape;
|
||||
* DELETE – the new shape is empty; the named shape with this evolution just indicates that the old shape topology is deleted from the model;
|
||||
* SELECTED – a named shape with this evolution has no effect on the history of the topology.
|
||||
* PRIMITIVE -- newly created topology, with no previous history;
|
||||
* GENERATED -- as usual, this evolution of a named shape means, that the new shape is created from a low-level old shape ( a prism face from an edge, for example );
|
||||
* MODIFY -- the new shape is a modified old shape;
|
||||
* DELETE -- the new shape is empty; the named shape with this evolution just indicates that the old shape topology is deleted from the model;
|
||||
* SELECTED -- a named shape with this evolution has no effect on the history of the topology.
|
||||
|
||||
Only pairs of shapes with equal evolution can be stored in one named shape.
|
||||
|
||||
@ -879,7 +881,7 @@ TNaming_Builder builder(label);
|
||||
builder.Generated(oldshape1,newshape1);
|
||||
// set another pair of shapes with the same evolution
|
||||
builder.Generated(oldshape2,newshape2);
|
||||
// get the result – TNaming_NamedShape attribute
|
||||
// get the result - TNaming_NamedShape attribute
|
||||
Handle(TNaming_NamedShape) ns = builder.NamedShape();
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@ -891,7 +893,7 @@ More detailed information about the contents of the named shape or about the mod
|
||||
* *TNaming_Tool* provides a common high-level functionality for access to the named shapes contents:
|
||||
* The method <i>GetShape(Handle(TNaming_NamedShape)) </i> returns a compound of new shapes of the given named shape;
|
||||
* The method <i>CurrentShape(Handle(TNaming_NamedShape))</i> returns a compound of the shapes, which are latest versions of the shapes from the given named shape;
|
||||
* The method <i>NamedShape(TopoDS_Shape,TDF_Label) </i> returns a named shape, which contains a given shape as a new shape. A given label is any label from the data framework – it just gives access to it.
|
||||
* The method <i>NamedShape(TopoDS_Shape,TDF_Label) </i> returns a named shape, which contains a given shape as a new shape. A given label is any label from the data framework -- it just gives access to it.
|
||||
* *TNaming_Iterator* gives access to the named shape and hooks pairs.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
@ -935,7 +937,7 @@ The "correct" history of a used modeling operation serves the basis of naming me
|
||||
|
||||
The history should return (and track) only elementary types of sub-shapes, i.e. Faces, Edges and Vertexes, while other so-called aggregation types: Compounds, Shells, Wires, are calculated by Selection mechanism automatically.
|
||||
|
||||
There are some simple exceptions for several cases. For example, if the Result contains a seam edge - in conical, cylindrical or spherical surfaces - this seam edge should be tracked by the history and in addition should be defined before the types. All degenerated entities should be filtered and excluded from consideration.
|
||||
There are some simple exceptions for several cases. For example, if the Result contains a seam edge -- in conical, cylindrical or spherical surfaces -- this seam edge should be tracked by the history and in addition should be defined before the types. All degenerated entities should be filtered and excluded from consideration.
|
||||
|
||||
@subsubsection occt_ocaf_5_6_2 Loading history in data framework
|
||||
|
||||
@ -948,9 +950,9 @@ The "Result Label" is *TDF_label* used to keep the algorithm result *Shape* from
|
||||
When the Data Framework is filled with all impacted entities (including the data structures resulting from the current modeling operation and the data structures resulting from the previous modeling operations, on which the current operation depends) any sub-shape of the current result can be **selected**, i.e. the corresponding new naming data structures, which support this functionality, can be produced and kept in the Data Framework.
|
||||
|
||||
One of the user interfaces for topological naming is the class *TNaming_Selector*. It implements the above mentioned sub-shape "selection" functionality as an additional one. I.e. it can be used for:
|
||||
* Storing the selected shape on a label - its **Selection**;
|
||||
* Accessing the named shape – check the kept value of the shape
|
||||
* Update of this naming – recomputation of an earlier selected shape.
|
||||
* Storing the selected shape on a label -- its **Selection**;
|
||||
* Accessing the named shape -- check the kept value of the shape
|
||||
* Update of this naming -- recomputation of an earlier selected shape.
|
||||
|
||||
The selector places a new named shape with evolution **SELECTED** to the given label. The selector creates a **name** of the selected shape, which is a unique description (data structure) of how to find the selected topology using as resources:
|
||||
* the given context shape, i.e. the main shape kept on **Result Label**, which contains a selected sub-shape,
|
||||
@ -992,7 +994,7 @@ There may be several nails with different size and position. A **Hammer** should
|
||||
* Makes several Nails of different height and diameter (according to the need),
|
||||
* Chooses (selects) the upper surface of each Nail for the Hammer.
|
||||
|
||||
The job is done. The application should do the rest – the Hammer calculates a center point for each selected surface of the Nail and “strikes” each Nail driving it into the wooden plate.
|
||||
The job is done. The application should do the rest -- the Hammer calculates a center point for each selected surface of the Nail and “strikes” each Nail driving it into the wooden plate.
|
||||
|
||||
What happens if the user changes the position of some Nails? How will the Hammer know about it? It keeps reference to the surface of each Nail. However, if a Nail is relocated, the Hammer should know the new position of the selected surface. Otherwise, it will “strike” at the old position (keep the fingers away!)…
|
||||
|
||||
@ -1001,30 +1003,30 @@ Topological naming mechanism should help the Hammer to obtain the relocated surf
|
||||
The topological naming is represented as a “black box” in the example above. Now it is time to make the box a little more “transparent”.
|
||||
|
||||
The application contains 3 functions:
|
||||
* **Nail** - produces a shape representing a nail,
|
||||
* **Translator** - translates a shape along the wooden plate,
|
||||
* **Hammer** - drives the nail in the wooden plate.
|
||||
* **Nail** -- produces a shape representing a nail,
|
||||
* **Translator** -- translates a shape along the wooden plate,
|
||||
* **Hammer** -- drives the nail in the wooden plate.
|
||||
|
||||
Each function gives the topological naming some hints how to “re-solve” the selected sub-shapes:
|
||||
* The Nail constructs a solid shape and puts each face of the shape into sub-labels:
|
||||
|
||||
@figure{/user_guides/ocaf/images/ocaf_image021.png, "Distribution of faces through sub-labels of the Nail"}
|
||||
|
||||
* The **Translator** moves a shape and registers modification for each face: it puts a pair: “old” shape – “new” shape at a sub-label of each moving Nail. The “old” shape represents a face of the Nail at the initial position. The “new” shape – is the same face, but at a new position:
|
||||
* The **Translator** moves a shape and registers modification for each face: it puts a pair: “old” shape -- “new” shape at a sub-label of each moving Nail. The “old” shape represents a face of the Nail at the initial position. The “new” shape -- is the same face, but at a new position:
|
||||
|
||||
@figure{/user_guides/ocaf/images/ocaf_image022.png, "Registration of relocation of faces of a Nail"}
|
||||
|
||||
How does it work?
|
||||
* The Hammer selects a face of a Nail calling *TNaming_Selector::Select()*. This call makes a unique name for the selected shape. In our example, it will be a direct reference to the label of the top face of the Nail (Face 1).
|
||||
* When the user moves a Nail along the wooden plate, the Translator registers this modification by putting the pairs: “old” face of the Nail – new face of the Nail into its sub-labels.
|
||||
* When the user moves a Nail along the wooden plate, the Translator registers this modification by putting the pairs: “old” face of the Nail -- new face of the Nail into its sub-labels.
|
||||
* When the Hammer calls *TNaming::Solve()*, the topological naming “looks” at the unique name of the selected shape and tries to re-solve it:
|
||||
* It finds the 1st appearance of the selected shape in the data tree – it is a label under the Nail function *Face 1*.
|
||||
* It follows the evolution of this face. In our case, there is only one evolution – the translation: *Face 1* (top face) – <i>Face 1’</i> (relocated top face). So, the last evolution is the relocated top face.
|
||||
* Calling the method *TNaming_Selector::NamedShape()* the Hammer obtains the last evolution of the selected face – the relocated top face.
|
||||
* It finds the 1st appearance of the selected shape in the data tree -- it is a label under the Nail function *Face 1*.
|
||||
* It follows the evolution of this face. In our case, there is only one evolution -- the translation: *Face 1* (top face) -- <i>Face 1’</i> (relocated top face). So, the last evolution is the relocated top face.
|
||||
* Calling the method *TNaming_Selector::NamedShape()* the Hammer obtains the last evolution of the selected face -- the relocated top face.
|
||||
|
||||
The job is done.
|
||||
|
||||
P.S. Let us say a few words about a little more complicated case – selection of a wire of the top face. Its topological name is an “intersection” of two faces. We remember that the **Nail** puts only faces under its label. So, the selected wire will represent an “intersection” of the top face and the conic face keeping the “head” of the nail. Another example is a selected vertex. Its unique name may be represented as an “intersection” of three or even more faces (depends on the shape).
|
||||
P.S. Let us say a few words about a little more complicated case -- selection of a wire of the top face. Its topological name is an “intersection” of two faces. We remember that the **Nail** puts only faces under its label. So, the selected wire will represent an “intersection” of the top face and the conic face keeping the “head” of the nail. Another example is a selected vertex. Its unique name may be represented as an “intersection” of three or even more faces (depends on the shape).
|
||||
|
||||
|
||||
@section occt_ocaf_6 Standard Attributes
|
||||
@ -1042,51 +1044,51 @@ Standard attributes are ready-to-use attributes, which allow creating and modify
|
||||
|
||||
### Geometric attributes
|
||||
|
||||
* **Axis** – simply identifies, that the concerned *TNaming_NamedShape* attribute with an axis shape inside belongs to the same label;
|
||||
* **Constraint** – contains information about a constraint between geometries: used geometry attributes, type, value (if exists), plane (if exists), "is reversed", "is inverted" and "is verified" flags;
|
||||
* **Geometry** – simply identifies, that the concerned *TNaming_NamedShape* attribute with a specified-type geometry belongs to the same label;
|
||||
* **Plane** – simply identifies, that the concerned *TNaming_NamedShape* attribute with a plane shape inside belongs to the same label;
|
||||
* **Point** – simply identifies, that the concerned *TNaming_NamedShape* attribute with a point shape inside belongs to the same label;
|
||||
* **Shape** – simply identifies, that the concerned *TNaming_NamedShape* attribute belongs to the same label;
|
||||
* **PatternStd** – identifies one of five available pattern models (linear, circular, rectangular, circular rectangular and mirror);
|
||||
* **Position** – identifies the position in 3d global space.
|
||||
* **Axis** -- simply identifies, that the concerned *TNaming_NamedShape* attribute with an axis shape inside belongs to the same label;
|
||||
* **Constraint** -- contains information about a constraint between geometries: used geometry attributes, type, value (if exists), plane (if exists), "is reversed", "is inverted" and "is verified" flags;
|
||||
* **Geometry** -- simply identifies, that the concerned *TNaming_NamedShape* attribute with a specified-type geometry belongs to the same label;
|
||||
* **Plane** -- simply identifies, that the concerned *TNaming_NamedShape* attribute with a plane shape inside belongs to the same label;
|
||||
* **Point** -- simply identifies, that the concerned *TNaming_NamedShape* attribute with a point shape inside belongs to the same label;
|
||||
* **Shape** -- simply identifies, that the concerned *TNaming_NamedShape* attribute belongs to the same label;
|
||||
* **PatternStd** -- identifies one of five available pattern models (linear, circular, rectangular, circular rectangular and mirror);
|
||||
* **Position** -- identifies the position in 3d global space.
|
||||
|
||||
### General attributes
|
||||
|
||||
* **AsciiString** – contains AsciiString value;
|
||||
* **BooleanArray** – contains an array of Boolean;
|
||||
* **BooleanList** – contains a list of Boolean;
|
||||
* **ByteArray** – contains an array of Byte (unsigned char) values;
|
||||
* **Comment** – contains a string – some comment for a given label (or attribute);
|
||||
* **Expression** – contains an expression string and a list of used variables attributes;
|
||||
* **ExtStringArray** – contains an array of *ExtendedString* values;
|
||||
* **ExtStringList** – contains a list of *ExtendedString* values;
|
||||
* **Integer** – contains an integer value;
|
||||
* **IntegerArray** – contains an array of integer values;
|
||||
* **IntegerList** – contains a list of integer values;
|
||||
* **IntPackedMap** – contains a packed map of integers;
|
||||
* **Name** – contains a string – some name of a given label (or attribute);
|
||||
* **NamedData** – may contain up to 6 of the following named data sets (vocabularies): *DataMapOfStringInteger, DataMapOfStringReal, DataMapOfStringString, DataMapOfStringByte, DataMapOfStringHArray1OfInteger* or *DataMapOfStringHArray1OfReal*;
|
||||
* **NoteBook** – contains a *NoteBook* object attribute;
|
||||
* **Real** – contains a real value;
|
||||
* **RealArray** – contains an array of real values;
|
||||
* **RealList** – contains a list of real values;
|
||||
* **Relation** – contains a relation string and a list of used variables attributes;
|
||||
* **Tick** – defines a boolean attribute;
|
||||
* **Variable** – simply identifies, that a variable belongs to this label; contains the flag *is constraint* and a string of used units ("mm", "m"...);
|
||||
* **UAttribute** – attribute with a user-defined GUID. As a rule, this attribute is used as a marker, which is independent of attributes at the same label (note, that attributes with the same GUIDs can not belong to the same label).
|
||||
* **AsciiString** -- contains AsciiString value;
|
||||
* **BooleanArray** -- contains an array of Boolean;
|
||||
* **BooleanList** -- contains a list of Boolean;
|
||||
* **ByteArray** -- contains an array of Byte (unsigned char) values;
|
||||
* **Comment** -- contains a string -- the comment for a given label (or attribute);
|
||||
* **Expression** -- contains an expression string and a list of used variables attributes;
|
||||
* **ExtStringArray** -- contains an array of *ExtendedString* values;
|
||||
* **ExtStringList** -- contains a list of *ExtendedString* values;
|
||||
* **Integer** -- contains an integer value;
|
||||
* **IntegerArray** -- contains an array of integer values;
|
||||
* **IntegerList** -- contains a list of integer values;
|
||||
* **IntPackedMap** -- contains a packed map of integers;
|
||||
* **Name** -- contains a string -- the name of a given label (or attribute);
|
||||
* **NamedData** -- may contain up to 6 of the following named data sets (vocabularies): *DataMapOfStringInteger, DataMapOfStringReal, DataMapOfStringString, DataMapOfStringByte, DataMapOfStringHArray1OfInteger* or *DataMapOfStringHArray1OfReal*;
|
||||
* **NoteBook** -- contains a *NoteBook* object attribute;
|
||||
* **Real** -- contains a real value;
|
||||
* **RealArray** -- contains an array of real values;
|
||||
* **RealList** -- contains a list of real values;
|
||||
* **Relation** -- contains a relation string and a list of used variables attributes;
|
||||
* **Tick** -- defines a boolean attribute;
|
||||
* **Variable** -- simply identifies, that a variable belongs to this label; contains the flag *is constraint* and a string of used units ("mm", "m"...);
|
||||
* **UAttribute** -- attribute with a user-defined GUID. As a rule, this attribute is used as a marker, which is independent of attributes at the same label (note, that attributes with the same GUIDs can not belong to the same label).
|
||||
|
||||
### Relationship attributes
|
||||
|
||||
* **Reference** – contains reference to the label of its own data framework;
|
||||
* **ReferenceArray** – contains an array of references;
|
||||
* **ReferenceList** – contains a list of references;
|
||||
* **TreeNode** – this attribute allows to create an internal tree in the data framework; this tree consists of nodes with the specified tree ID; each node contains references to the father, previous brother, next brother, first child nodes and tree ID.
|
||||
* **Reference** -- contains reference to the label of its own data framework;
|
||||
* **ReferenceArray** -- contains an array of references;
|
||||
* **ReferenceList** -- contains a list of references;
|
||||
* **TreeNode** -- this attribute allows to create an internal tree in the data framework; this tree consists of nodes with the specified tree ID; each node contains references to the father, previous brother, next brother, first child nodes and tree ID.
|
||||
|
||||
### Auxiliary attributes
|
||||
|
||||
* **Directory** – high-level tool attribute for sub-labels management;
|
||||
* **TagSource** – this attribute is used for creation of new children: it stores the tag of the last-created child of the label and gives access to the new child label creation functionality.
|
||||
* **Directory** -- high-level tool attribute for sub-labels management;
|
||||
* **TagSource** -- this attribute is used for creation of new children: it stores the tag of the last-created child of the label and gives access to the new child label creation functionality.
|
||||
|
||||
All attributes inherit class *TDF_Attribute*, so, each attribute has its own GUID and standard methods for attribute creation, manipulation, getting access to the data framework.
|
||||
|
||||
@ -1167,7 +1169,7 @@ It is possible to describe any model by means of standard OCAF attributes.
|
||||
So, this approach may be considered only in case of non-editable data.
|
||||
|
||||
Let’s consider the allocation of data of each measurement point per label (the second case).
|
||||
In this case we create 100 000 labels – one label for each measurement point
|
||||
In this case we create 100 000 labels -- one label for each measurement point
|
||||
and attach an array of double values to these labels:
|
||||
|
||||
@image html ocaf_tree_wp_image004.png "Allocation of data of each measurement point as arrays of double values"
|
||||
@ -1271,7 +1273,7 @@ TPrsStd_AISPresentation::Set(NS};
|
||||
|
||||
@section occt_ocaf_8 Function Services
|
||||
|
||||
Function services aggregate data necessary for regeneration of a model. The function mechanism - available in the package TFunction - provides links between functions and any execution algorithms, which take their arguments from the data framework, and write their results inside the same framework.
|
||||
Function services aggregate data necessary for regeneration of a model. The function mechanism -- available in the package *TFunction* -- provides links between functions and any execution algorithms, which take their arguments from the data framework, and write their results inside the same framework.
|
||||
|
||||
When you edit any application model, you have to regenerate the model by propagating the modifications. Each propagation step calls various algorithms. To make these algorithms independent of your application model, you need to use function services.
|
||||
|
||||
@ -1309,10 +1311,10 @@ The procedure of its creation is as follows:
|
||||
* the solver calls the driver of the face *F* function for a regeneration of the face;
|
||||
* the driver rebuilds face *F* and adds the label of the face *width* argument to the logbook as touched and the label of the function of face *F* as impacted;
|
||||
|
||||
* the solver detects the function of *P* – it depends on the function of *F*;
|
||||
* the solver detects the function of *P* -- it depends on the function of *F*;
|
||||
* the solver calls the driver of the prism *P* function;
|
||||
* the driver rebuilds prism *P* and adds the label of this prism to the logbook as impacted;
|
||||
* the solver detects the function of *L* – it depends on the function of *P*;
|
||||
* the solver detects the function of *L* -- it depends on the function of *P*;
|
||||
* the solver calls the *L* function driver;
|
||||
* the driver rebuilds fillet *L* and adds the label of the fillet to the logbook as impacted.
|
||||
|
||||
@ -1327,7 +1329,7 @@ The procedure of its creation is as follows:
|
||||
@image latex ocaf_functionmechanism_wp_image003.png " A nail"
|
||||
|
||||
These three objects (a cone and two cylinders) are independent,
|
||||
but the Function Mechanism makes them connected to each other and representing one object – a nail.
|
||||
but the Function Mechanism makes them connected to each other and representing one object -- a nail.
|
||||
The object "nail" has the following parameters:
|
||||
|
||||
* The position of the nail is defined by the apex point of the cone.
|
||||
@ -1400,9 +1402,9 @@ The procedure of its creation is as follows:
|
||||
It sets the default values of position, radius and height of the nail.
|
||||
|
||||
The nail has the following user parameters:
|
||||
* The position – coincides with the position of the cone
|
||||
* The radius of the stem part of the nail – coincides with the radius of the cone
|
||||
* The height of the nail – a sum of heights of the cone and both cylinders
|
||||
* The position -- coincides with the position of the cone
|
||||
* The radius of the stem part of the nail -- coincides with the radius of the cone
|
||||
* The height of the nail -- a sum of heights of the cone and both cylinders
|
||||
|
||||
The values of the position and the radius of the nail are defined for the cone object data.
|
||||
The height of the cone is recomputed as 2 * heights of nail and divided by 9.
|
||||
@ -1444,8 +1446,8 @@ To automatically erase the nail from the viewer and the data tree it is enough
|
||||
The only thing the Function Mechanism requires from its user
|
||||
is the implementation of pure virtual methods of *TFunction_Driver*:
|
||||
|
||||
* <i>\::Arguments()</i> – returns a list of arguments for the function
|
||||
* <i>\::Results()</i> – returns a list of results of the function
|
||||
* <i>\::Arguments()</i> -- returns a list of arguments for the function
|
||||
* <i>\::Results()</i> -- returns a list of results of the function
|
||||
|
||||
These methods give the Function Mechanism the information on the location of arguments
|
||||
and results of the function and allow building a graph of functions.
|
||||
@ -1460,13 +1462,13 @@ To automatically erase the nail from the viewer and the data tree it is enough
|
||||
The cone and cylinder functions differ only in geometrical construction algorithms.
|
||||
Other parameters are the same (position, radius and height).
|
||||
|
||||
It means that it is possible to create a base class – function driver for the three functions,
|
||||
It means that it is possible to create a base class -- function driver for the three functions,
|
||||
and two descendant classes producing: a cone or a cylinder.
|
||||
|
||||
For the base function driver the methods <i>\::Arguments()</i> and <i>\::Results()</i> will be overridden.
|
||||
Two descendant function drivers responsible for creation of a cone and a cylinder will override only the method <i>\::Execute()</i>.
|
||||
|
||||
The method <i>\::Arguments()</i> of the function driver of the nail returns the results of the functions located under it in the tree of leaves. The method <i>\::Execute()</i> just collects the results of the functions and makes one shape – a nail.
|
||||
The method <i>\::Arguments()</i> of the function driver of the nail returns the results of the functions located under it in the tree of leaves. The method <i>\::Execute()</i> just collects the results of the functions and makes one shape -- a nail.
|
||||
|
||||
This way the data model using the Function Mechanism is ready for usage. Do not forget to introduce the function drivers for a function driver table with the help of *TFunction_DriverTable* class.
|
||||
|
||||
@ -1551,7 +1553,7 @@ To automatically erase the nail from the viewer and the data tree it is enough
|
||||
// Execution of the function driver.
|
||||
Int CylinderDriver::Execute( TFunction_Logbook& log )
|
||||
{
|
||||
// Position of the cylinder – position of the first function (cone)
|
||||
// Position of the cylinder - position of the first function (cone)
|
||||
//is elevated along Z for height values of all previous functions.
|
||||
gp_Ax2 axes = …. // out of the scope of this guide.
|
||||
// The radius value is retrieved.
|
||||
@ -1606,7 +1608,7 @@ Writing and reading XML files in OCCT is provided by LDOM package, which constit
|
||||
of XML OCAF persistence, which is the optional component provided on top of Open CASCADE Technology.
|
||||
|
||||
The Light DOM (LDOM) package contains classes maintaining a data structure whose main principles conform to W3C DOM Level 1 Recommendations. The purpose of these classes as required by XML OCAF persistence schema is to:
|
||||
* Maintain a tree structure of objects in memory representing the XML document. The root of the structure is an object of the *LDOM_Document* type. This object contains all the data corresponding to a given XML document and contains one object of the *LDOM_Element* type named "document element". The document element contains other *LDOM_Element* objects forming a tree. Other types of nodes: *LDOM_Attr, LDOM_Text, LDOM_Comment* and *LDOM_CDATASection* - represent the corresponding XML types and serve as branches of the tree of elements.
|
||||
* Maintain a tree structure of objects in memory representing the XML document. The root of the structure is an object of the *LDOM_Document* type. This object contains all the data corresponding to a given XML document and contains one object of the *LDOM_Element* type named "document element". The document element contains other *LDOM_Element* objects forming a tree. Other types of nodes: *LDOM_Attr, LDOM_Text, LDOM_Comment* and *LDOM_CDATASection* -- represent the corresponding XML types and serve as branches of the tree of elements.
|
||||
* Provide class *LDOM_Parser* to read XML files and convert them to *LDOM_Document* objects.
|
||||
* Provide class *LDOM_XmlWriter* to convert *LDOM_Document* to a character stream in XML format and store it in file.
|
||||
|
||||
@ -1631,8 +1633,8 @@ The drivers for document storage and retrieval manage conversion between a tra
|
||||
Document in memory and its persistent reflection in a container (disk, memory, network). For XML Persistence, they are defined in the package XmlDrivers.
|
||||
|
||||
The main methods (entry points) of these drivers are:
|
||||
* *Write()* - for a storage driver;
|
||||
* *Read()* - for a retrieval driver.
|
||||
* *Write()* -- for a storage driver;
|
||||
* *Read()* -- for a retrieval driver.
|
||||
|
||||
The most common case (which is implemented in XML Persistence) is writing/reading document to/from a regular OS file. Such conversion is performed in two steps:
|
||||
|
||||
@ -1669,10 +1671,10 @@ The basic class *XmlMDF_ADriver* supports errors reporting via the method *Write
|
||||
@subsection occt_ocaf_9_3 XML Document Structure
|
||||
|
||||
Every XML Document has one root element, which may have attributes and contain other nodes. In OCAF XML Documents the root element is named "document" and has attribute "format" with the name of the OCAF Schema used to generate the file. The standard XML format is "XmlOcaf". The following elements are sub-elements of \<document\> and should be unique entries as its sub-elements, in a specific order. The order is:
|
||||
* **Element info** - contains strings identifying the format version and other parameters of the OCAF XML document. Normally, data under the element is used by persistence algorithms to correctly retrieve and initialize an OCAF document. The data also includes a copyright string.
|
||||
* **Element comments** - consists of an unlimited number of \<comment\> sub-elements containing necessary comment strings.
|
||||
* **Element label** is the root label of the document data structure, with the XML attribute "tag" equal to 0. It contains all the OCAF data (labels, attributes) as tree of XML elements. Every sub-label is identified by a tag (positive integer) defining a unique key for all sub-labels of a label. Every label can contain any number of elements representing OCAF attributes (see OCAF Attributes Representation below).
|
||||
* **Element shapes** - contains geometrical and topological entities in BRep format. These entities being referenced by OCAF attributes written under the element \<label\>. This element is empty if there are no shapes in the document. It is only output if attribute driver *XmlMNaming_NamedShapeDriver* has been added to drivers table by the *DocumentStorageDriver*.
|
||||
* **Element info** -- contains strings identifying the format version and other parameters of the OCAF XML document. Normally, data under the element is used by persistence algorithms to correctly retrieve and initialize an OCAF document. The data also includes a copyright string.
|
||||
* **Element comments** -- consists of an unlimited number of \<comment\> sub-elements containing necessary comment strings.
|
||||
* **Element label** -- the root label of the document data structure, with the XML attribute "tag" equal to 0. It contains all the OCAF data (labels, attributes) as tree of XML elements. Every sub-label is identified by a tag (positive integer) defining a unique key for all sub-labels of a label. Every label can contain any number of elements representing OCAF attributes (see OCAF Attributes Representation below).
|
||||
* **Element shapes** -- contains geometrical and topological entities in BRep format. These entities being referenced by OCAF attributes written under the element \<label\>. This element is empty if there are no shapes in the document. It is only output if attribute driver *XmlMNaming_NamedShapeDriver* has been added to drivers table by the *DocumentStorageDriver*.
|
||||
|
||||
### OCAF Attributes Representation
|
||||
|
||||
@ -1682,7 +1684,7 @@ XML types for OCAF attributes are declared with XML W3C Schema in a few XSD file
|
||||
|
||||
### Example of resulting XML file
|
||||
|
||||
The following example is a sample text from an XML file obtained by storing an OCAF document with two labels (0: and 0:2) and two attributes - *TDataStd_Name* (on label 0:) and *TNaming_NamedShape* (on label 0:2). The \<shapes\> section contents are replaced by an ellipsis.
|
||||
The following example is a sample text from an XML file obtained by storing an OCAF document with two labels (0: and 0:2) and two attributes -- *TDataStd_Name* (on label 0:) and *TNaming_NamedShape* (on label 0:2). The \<shapes\> section contents are replaced by an ellipsis.
|
||||
|
||||
~~~~
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
@ -1781,7 +1783,7 @@ All schemes are independent of each other, but they guarantee that the standard
|
||||
attributes stored and retrieved by one schema will be storable and retrievable by
|
||||
the other. Therefore in any OCAF application you can use any persistence schema or
|
||||
even all three of them. The choice is made depending on the *Format* string of stored OCAF documents
|
||||
or automatically by the file header data - on retrieval.
|
||||
or automatically by the file header data -- on retrieval.
|
||||
|
||||
Persistent data storage in OCAF using the <i> Standard</i> package is presented in:
|
||||
|
||||
@ -1967,54 +1969,54 @@ aShape.Nullify();
|
||||
|
||||
@section occt_ocaf_10 GLOSSARY
|
||||
|
||||
* **Application** - a document container holding all documents containing all application data.
|
||||
* **Application data** - the data produced by an application, as opposed to data referring to it.
|
||||
* **Associativity of data** - the ability to propagate modifications made to one document to other documents, which refer to such document. Modification propagation is:
|
||||
* **Application** -- a document container holding all documents containing all application data.
|
||||
* **Application data** -- the data produced by an application, as opposed to data referring to it.
|
||||
* **Associativity of data** -- the ability to propagate modifications made to one document to other documents, which refer to such document. Modification propagation is:
|
||||
* unidirectional, that is, from the referenced to the referencing document(s), or
|
||||
* bi-directional, from the referencing to the referenced document and vice-versa.
|
||||
* **Attribute** - a container for application data. An attribute is attached to a label in the hierarchy of the data framework.
|
||||
* **Child** - a label created from another label, which by definition, is the father label.
|
||||
* **Compound document** - a set of interdependent documents, linked to each other by means of external references. These references provide the associativity of data.
|
||||
* **Data framework** - a tree-like data structure which in OCAF, is a tree of labels with data attached to them in the form of attributes. This tree of labels is accessible through the services of the *TDocStd_Document* class.
|
||||
* **Document** - a container for a data framework which grants access to the data, and is, in its turn, contained by an application. A document also allows you to:
|
||||
* **Attribute** -- a container for application data. An attribute is attached to a label in the hierarchy of the data framework.
|
||||
* **Child** -- a label created from another label, which by definition, is the father label.
|
||||
* **Compound document** -- a set of interdependent documents, linked to each other by means of external references. These references provide the associativity of data.
|
||||
* **Data framework** -- a tree-like data structure which in OCAF, is a tree of labels with data attached to them in the form of attributes. This tree of labels is accessible through the services of the *TDocStd_Document* class.
|
||||
* **Document** -- a container for a data framework which grants access to the data, and is, in its turn, contained by an application. A document also allows you to:
|
||||
* Manage modifications, providing Undo and Redo functions
|
||||
* Manage command transactions
|
||||
* Update external links
|
||||
* Manage save and restore options
|
||||
* Store the names of software extensions.
|
||||
* **Driver** - an abstract class, which defines the communications protocol with a system.
|
||||
* **Entry** - an ASCII character string containing the tag list of a label. For example:
|
||||
* **Driver** -- an abstract class, which defines the communications protocol with a system.
|
||||
* **Entry** -- an ASCII character string containing the tag list of a label. For example:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
0:3:24:7:2:7
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
* **External links** - references from one data structure to another data structure in another document.
|
||||
* **External links** -- references from one data structure to another data structure in another document.
|
||||
To store these references properly, a label must also contain an external link attribute.
|
||||
* **Father** - a label, from which other labels have been created. The other labels are, by definition, the children of this label.
|
||||
* **Framework** - a group of co-operating classes which enable a design to be re-used for a given category of problem. The framework guides the architecture of the application by breaking it up into abstract classes, each of which has different responsibilities and collaborates in a predefined way. Application developer creates a specialized framework by:
|
||||
* **Father** -- a label, from which other labels have been created. The other labels are, by definition, the children of this label.
|
||||
* **Framework** -- a group of co-operating classes which enable a design to be re-used for a given category of problem. The framework guides the architecture of the application by breaking it up into abstract classes, each of which has different responsibilities and collaborates in a predefined way. Application developer creates a specialized framework by:
|
||||
* defining new classes which inherit from these abstract classes
|
||||
* composing framework class instances
|
||||
* implementing the services required by the framework.
|
||||
|
||||
In C++, the application behavior is implemented in virtual functions redefined in these derived classes. This is known as overriding.
|
||||
|
||||
* **GUID** - Global Universal ID. A string of 37 characters intended to uniquely identify an object. For example:
|
||||
* **GUID** -- Global Universal ID. A string of 37 characters intended to uniquely identify an object. For example:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
2a96b602-ec8b-11d0-bee7-080009dc3333
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
* **Label** - a point in the data framework, which allows data to be attached to it by means of attributes. It has a name in the form of an entry, which identifies its place in the data framework.
|
||||
* **Modified label** - containing attributes whose data has been modified.
|
||||
* **Reference key** - an invariant reference, which may refer to any type of data used in an application. In its transient form, it is a label in the data framework, and the data is attached to it in the form of attributes. In its persistent form, it is an entry of the label. It allows an application to recover any entity in the current session or in a previous session.
|
||||
* **Resource file** - a file containing a list of each document’s schema name and the storage and retrieval plug-ins for that document.
|
||||
* **Root** - the starting point of the data framework. This point is the top label in the framework. It is represented by the [0] entry and is created at the same time with the document you are working on.
|
||||
* **Scope** - the set of all the attributes and labels which depend on a given label.
|
||||
* **Tag list** - a list of integers, which identify the place of a label in the data framework. This list is displayed in an entry.
|
||||
* **Topological naming** - systematic referencing of topological entities so that these entities can still be identified after the models they belong to have gone through several steps in modeling. In other words, topological naming allows you to track entities through the steps in the modeling process. This referencing is needed when a model is edited and regenerated, and can be seen as a mapping of labels and name attributes of the entities in the old version of a model to those of the corresponding entities in its new version. Note that if the topology of a model changes during the modeling, this mapping may not fully coincide. A Boolean operation, for example, may split edges.
|
||||
* **Topological tracking** - following a topological entity in a model through the steps taken to edit and regenerate that model.
|
||||
* **Valid label** - in a data framework, this is a label, which is already recomputed in the scope of regeneration sequence and includes the label containing a feature which is to be recalculated. Consider the case of a box to which you first add a fillet, then a protrusion feature. For recalculation purposes, only valid labels of each construction stage are used. In recalculating a fillet, they are only those of the box and the fillet, not the protrusion feature which was added afterwards.
|
||||
* **Label** -- a point in the data framework, which allows data to be attached to it by means of attributes. It has a name in the form of an entry, which identifies its place in the data framework.
|
||||
* **Modified label** -- containing attributes whose data has been modified.
|
||||
* **Reference key** -- an invariant reference, which may refer to any type of data used in an application. In its transient form, it is a label in the data framework, and the data is attached to it in the form of attributes. In its persistent form, it is an entry of the label. It allows an application to recover any entity in the current session or in a previous session.
|
||||
* **Resource file** -- a file containing a list of each document’s schema name and the storage and retrieval plug-ins for that document.
|
||||
* **Root** -- the starting point of the data framework. This point is the top label in the framework. It is represented by the [0] entry and is created at the same time with the document you are working on.
|
||||
* **Scope** -- the set of all the attributes and labels which depend on a given label.
|
||||
* **Tag list** -- a list of integers, which identify the place of a label in the data framework. This list is displayed in an entry.
|
||||
* **Topological naming** -- systematic referencing of topological entities so that these entities can still be identified after the models they belong to have gone through several steps in modeling. In other words, topological naming allows you to track entities through the steps in the modeling process. This referencing is needed when a model is edited and regenerated, and can be seen as a mapping of labels and name attributes of the entities in the old version of a model to those of the corresponding entities in its new version. Note that if the topology of a model changes during the modeling, this mapping may not fully coincide. A Boolean operation, for example, may split edges.
|
||||
* **Topological tracking** -- following a topological entity in a model through the steps taken to edit and regenerate that model.
|
||||
* **Valid label** -- in a data framework, this is a label, which is already recomputed in the scope of regeneration sequence and includes the label containing a feature which is to be recalculated. Consider the case of a box to which you first add a fillet, then a protrusion feature. For recalculation purposes, only valid labels of each construction stage are used. In recalculating a fillet, they are only those of the box and the fillet, not the protrusion feature which was added afterwards.
|
||||
|
||||
@section occt_ocaf_11 Samples
|
||||
|
||||
|
||||
@ -44,11 +44,11 @@ The following diagram shows dependencies of API packages:
|
||||
@figure{/user_guides/shape_healing/images/shape_healing_image009.svg, "Shape Healing packages"}
|
||||
|
||||
Each sub-domain has its own scope of functionality:
|
||||
* analysis - exploring shape properties, computing shape features, detecting violation of OCCT requirements (shape itself is not modified);
|
||||
* fixing - fixing shape to meet the OCCT requirements (the shape may change its original form: modifying, removing, constructing sub-shapes, etc.);
|
||||
* upgrade - shape improvement for better usability in Open CASCADE Technology or other algorithms (the shape is replaced with a new one, but geometrically they are the same);
|
||||
* customization - modifying shape representation to fit specific needs (shape is not modified, only the form of its representation is modified);
|
||||
* processing - mechanism of managing shape modification via a user-editable resource file.
|
||||
* analysis -- exploring shape properties, computing shape features, detecting violation of OCCT requirements (shape itself is not modified);
|
||||
* fixing -- fixing shape to meet the OCCT requirements (the shape may change its original form: modifying, removing, constructing sub-shapes, etc.);
|
||||
* upgrade -- shape improvement for better usability in Open CASCADE Technology or other algorithms (the shape is replaced with a new one, but geometrically they are the same);
|
||||
* customization -- modifying shape representation to fit specific needs (shape is not modified, only the form of its representation is modified);
|
||||
* processing -- mechanism of managing shape modification via a user-editable resource file.
|
||||
|
||||
Message management is used for creating messages, filling them with various parameters and storing them in the trace file. This tool provides functionality for attaching messages to the shapes for deferred analysis of various run-time events. In this document only general principles of using Shape Healing will be described. For more detailed information please see the corresponding CDL files.
|
||||
|
||||
@ -59,9 +59,9 @@ Tools responsible for analysis, fixing and upgrading of shapes can give the info
|
||||
Each fixing and upgrading tool has its own status, which is reset when their methods are called. The status can contain several flags, which give the information about how the method was performed. For exploring the statuses, a set of methods named *Status...()* is provided. These methods accept enumeration *ShapeExtend_Status* and return True if the status has the corresponding flag set. The meaning of flags for each method is described below.
|
||||
|
||||
The status may contain a set of Boolean flags (internally represented by bits). Flags are coded by enumeration ShapeExtend_Status. This enumeration provides the following families of statuses:
|
||||
* *ShapeExtend_OK* - The situation is OK, no operation is necessary and has not been performed.
|
||||
* *ShapeExtend_DONE* - The operation has been successfully performed.
|
||||
* *ShapeExtend_FAIL* - An error has occurred during operation.
|
||||
* *ShapeExtend_OK* -- The situation is OK, no operation is necessary and has not been performed.
|
||||
* *ShapeExtend_DONE* -- The operation has been successfully performed.
|
||||
* *ShapeExtend_FAIL* -- An error has occurred during operation.
|
||||
|
||||
It is possible to test the status for the presence of some flag(s), using Status...() method(s) provided by the class:
|
||||
|
||||
@ -71,9 +71,9 @@ if ( object.Status.. ( ShapeExtend_DONE ) ) {// something was done
|
||||
~~~~~
|
||||
|
||||
8 'DONE' and 8 'FAIL' flags, named ShapeExtend_DONE1 ... ShapeExtend_FAIL8, are defined for a detailed analysis of the encountered situation. Each method assigns its own meaning to each flag, documented in the CDL for that method. There are also three enumerative values used for testing several flags at a time:
|
||||
* *ShapeExtend_OK* - if no flags have been set;
|
||||
* *ShapeExtend_DONE* - if at least one ShapeExtend_DONEi has been set;
|
||||
* *ShapeExtend_FAIL* - if at least one ShapeExtend_FAILi has been set.
|
||||
* *ShapeExtend_OK* -- if no flags have been set;
|
||||
* *ShapeExtend_DONE* -- if at least one ShapeExtend_DONEi has been set;
|
||||
* *ShapeExtend_FAIL* -- if at least one ShapeExtend_FAILi has been set.
|
||||
|
||||
@section occt_shg_2 Repair
|
||||
|
||||
@ -89,7 +89,7 @@ The *ShapeFix* package currently includes functions that:
|
||||
* limit the tolerance value of shapes within a given range,
|
||||
* set a given tolerance value for shapes,
|
||||
* repair the connections between adjacent edges of a wire,
|
||||
* correct self–intersecting wires,
|
||||
* correct self-intersecting wires,
|
||||
* add seam edges,
|
||||
* correct gaps between 3D and 2D curves,
|
||||
* merge and remove small edges,
|
||||
@ -111,12 +111,13 @@ The sequence of actions is as follows :
|
||||
sfs->SetMaxTolerance ( maxTol );
|
||||
sfs->SetMinTolerance ( mintol );
|
||||
|
||||
where *Prec* – basic precision, *maxTol* – maximum allowed tolerance, *minTol* – minimal allowed tolerance.
|
||||
* *maxTol* - All problems will be detected for cases when a dimension of invalidity is larger than the basic precision or a tolerance of sub-shape on that problem is detected.
|
||||
The maximum tolerance value limits the increasing tolerance for fixing a problem such as fix of not connenected and self-intersected wires. If a value larger than the maximum allowed tolerance is necessary for correcting a detected problem the problem can not be fixed.
|
||||
The maximal tolerance is not taking into account during computation of tolerance of edges in ShapeFix_SameParameter() method and ShapeFix_Edge::FixVertexTolerance() method.
|
||||
where:
|
||||
* *Prec* -- basic precision.
|
||||
* *maxTol* -- maximum allowed tolerance. All problems will be detected for cases when a dimension of invalidity is larger than the basic precision or a tolerance of sub-shape on that problem is detected.
|
||||
The maximum tolerance value limits the increasing tolerance for fixing a problem such as fix of not connected and self-intersected wires. If a value larger than the maximum allowed tolerance is necessary for correcting a detected problem the problem can not be fixed.
|
||||
The maximal tolerance is not taking into account during computation of tolerance of edges in *ShapeFix_SameParameter()* method and *ShapeFix_Edge::FixVertexTolerance()* method.
|
||||
See @ref occt_shg_2_3_8 for details.
|
||||
* *minTol* - The minimal allowed tolerance defines minimal allowed length of edges. Detected edges having length less than specified minimal tolerance will be removed if ModifyTopologyMode in Repairing tool for wires is set to true.
|
||||
* *minTol* -- minimal allowed tolerance. It defines the minimal allowed length of edges. Detected edges having length less than the specified minimal tolerance will be removed if *ModifyTopologyMode* in Repairing tool for wires is set to true.
|
||||
See @ref occt_shg_2_3_7 for details.
|
||||
|
||||
3. Launch fixing:
|
||||
@ -165,12 +166,12 @@ If you do not want to make fixes on the whole shape or make a definite set of fi
|
||||
For each type of sub-shapes there are specific types of fixing tools such as *ShapeFix_Solid, ShapeFix_Shell, ShapeFix_Face, ShapeFix_Wire,* etc.
|
||||
|
||||
@subsubsection occt_shg_2_2_1 Fixing sub-shapes
|
||||
If you want to make a fix on one subshape of a certain shape it is possible to take the following steps:
|
||||
* create a tool for a specified subshape type and initialize this tool by the subshape;
|
||||
If you want to make a fix on one sub-shape of a certain shape it is possible to take the following steps:
|
||||
* create a tool for a specified sub-shape type and initialize this tool by the sub-shape;
|
||||
* create a tool for rebuilding the shape and initialize it by the whole shape (section 5.1);
|
||||
* set a tool for rebuilding the shape in the tool for fixing the subshape;
|
||||
* fix the subshape;
|
||||
* get the resulting whole shape containing a new corrected subshape.
|
||||
* set a tool for rebuilding the shape in the tool for fixing the sub-shape;
|
||||
* fix the sub-shape;
|
||||
* get the resulting whole shape containing a new corrected sub-shape.
|
||||
|
||||
For example, in the following way it is possible to fix face *Face1* of shape *Shape1*:
|
||||
|
||||
@ -277,14 +278,14 @@ cout<< "Initial face is valid with specified precision ="<< precendl;
|
||||
Class *ShapeFix_Solid* allows fixing solids and building a solid from a shell to obtain a valid solid with a finite volume. The tool *ShapeFix_Shell* is used for correction of shells belonging to a solid.
|
||||
|
||||
This tool has the following control flags:
|
||||
* *FixShellMode* - Mode for applying fixes of ShapeFix_Shell, True by default.
|
||||
* *CreateOpenShellMode* - If it is equal to true solids are created from open shells, else solids are created from closed shells only, False by default.
|
||||
* *FixShellMode* -- Mode for applying fixes of ShapeFix_Shell, True by default.
|
||||
* *CreateOpenShellMode* -- If it is equal to true solids are created from open shells, else solids are created from closed shells only, False by default.
|
||||
|
||||
@subsubsection occt_shg_2_3_5 Repairing tool for shells
|
||||
Class *ShapeFix_Shell* allows fixing wrong orientation of faces in a shell. It changes the orientation of faces in the shell so that all faces in the shell have coherent orientations. If it is impossible to orient all faces in the shell (like in case of Mebious tape), then a few manifold or non-manifold shells will be created depending on the specified Non-manifold mode. The *ShapeFix_Face* tool is used to correct faces in the shell.
|
||||
This tool has the following control flags:
|
||||
* *FixFaceMode* - mode for applying the fixes of *ShapeFix_Face*, *True* by default.
|
||||
* *FixOrientationMode* - mode for applying a fix for the orientation of faces in the shell.
|
||||
* *FixFaceMode* -- mode for applying the fixes of *ShapeFix_Face*, *True* by default.
|
||||
* *FixOrientationMode* -- mode for applying a fix for the orientation of faces in the shell.
|
||||
|
||||
@subsubsection occt_shg_2_3_6 Repairing tool for faces
|
||||
|
||||
@ -295,11 +296,11 @@ The following fixes are available:
|
||||
* fixing the case when the face on the closed surface is defined by a set of closed wires, and the seam is missing (this is not valid in OCCT). In that case, these wires are connected by means of seam edges into the same wire.
|
||||
|
||||
This tool has the following control flags:
|
||||
* *FixWireMode* - mode for applying fixes of a wire, True by default.
|
||||
* *FixOrientationMode* - mode for orienting a wire to border a limited square, True by default.
|
||||
* *FixAddNaturalBoundMode* - mode for adding natural bounds to a face, False by default.
|
||||
* *FixMissingSeamMode* – mode to fix a missing seam, True by default. If True, tries to insert a seam.
|
||||
* *FixSmallAreaWireMode* - mode to fix a small-area wire, False by default. If True, drops wires bounding small areas.
|
||||
* *FixWireMode* -- mode for applying fixes of a wire, True by default.
|
||||
* *FixOrientationMode* -- mode for orienting a wire to border a limited square, True by default.
|
||||
* *FixAddNaturalBoundMode* -- mode for adding natural bounds to a face, False by default.
|
||||
* *FixMissingSeamMode* -- mode to fix a missing seam, True by default. If True, tries to insert a seam.
|
||||
* *FixSmallAreaWireMode* -- mode to fix a small-area wire, False by default. If True, drops wires bounding small areas.
|
||||
|
||||
~~~~~
|
||||
|
||||
@ -346,11 +347,11 @@ The fixing methods can be turned on/off by using their corresponding control fla
|
||||
Some fixes can be made in three ways:
|
||||
* Increasing the tolerance of an edge or a vertex.
|
||||
* Changing topology (adding/removing/replacing an edge in the wire and/or replacing the vertex in the edge, copying the edge etc.).
|
||||
* Changing geometry (shifting a vertex or adjusting ends of an edge curve to vertices, or re-computing a 3D curve or 2D curves of the edge).
|
||||
* Changing geometry (shifting a vertex or adjusting ends of an edge curve to vertices, or recomputing a 3D curve or 2D curves of the edge).
|
||||
|
||||
When it is possible to make a fix in more than one way (e.g., either by increasing the tolerance or shifting a vertex), it is chosen according to the user-defined flags:
|
||||
* *ModifyTopologyMode* - allows modifying topology, False by default.
|
||||
* *ModifyGeometryMode* - allows modifying geometry. Now this flag is used only in fixing self-intersecting edges (allows to modify 2D curves) and is True by default.
|
||||
* *ModifyTopologyMode* -- allows modifying topology, False by default.
|
||||
* *ModifyGeometryMode* -- allows modifying geometry. Now this flag is used only in fixing self-intersecting edges (allows to modify 2D curves) and is True by default.
|
||||
|
||||
#### Fixing disordered edges
|
||||
|
||||
@ -373,17 +374,17 @@ When it is possible to make a fix in more than one way (e.g., either by increasi
|
||||
These fixes will be activated with the help of a set of fixes from the repairing tool for edges called *ShapeFix_Edge*. Each of these fixes can be forced or forbidden by means of setting the corresponding flag to either True or False.
|
||||
|
||||
The mentioned fixes and the conditions of their execution are:
|
||||
* fixing a disoriented 2D curve by call to *ShapeFix_Edge::FixReversed2d* - if not forbidden by flag *FixReversed2dMode*;
|
||||
* removing a wrong 2D curve by call to *ShapeFix_Edge::FixRemovePCurve* - only if forced by flag *FixRemovePCurveMode*;
|
||||
* fixing a missing 2D curve by call to *ShapeFix_Edge::FixAddPCurve* - if not forbidden by flag *FixAddPCurveMode*;
|
||||
* removing a wrong 3D curve by call to *ShapeFix_Edge::FixRemoveCurve3d* - only if forced by flag *FixRemoveCurve3dMode*;
|
||||
* fixing a missing 3D curve by call to *ShapeFix_Edge::FixAddCurve3d* - if not forbidden by flag *FixAddCurve3dMode*;
|
||||
* fixing 2D curves of seam edges - if not forbidden by flag *FixSeamMode*;
|
||||
* fixing 2D curves which can be shifted at an integer number of periods on the closed surface by call to *ShapeFix_Edge::FixShifted* - if not forbidden by flag *FixShiftedMode*.
|
||||
* fixing a disoriented 2D curve by call to *ShapeFix_Edge::FixReversed2d* -- if not forbidden by flag *FixReversed2dMode*;
|
||||
* removing a wrong 2D curve by call to *ShapeFix_Edge::FixRemovePCurve* -- only if forced by flag *FixRemovePCurveMode*;
|
||||
* fixing a missing 2D curve by call to *ShapeFix_Edge::FixAddPCurve* -- if not forbidden by flag *FixAddPCurveMode*;
|
||||
* removing a wrong 3D curve by call to *ShapeFix_Edge::FixRemoveCurve3d* -- only if forced by flag *FixRemoveCurve3dMode*;
|
||||
* fixing a missing 3D curve by call to *ShapeFix_Edge::FixAddCurve3d* -- if not forbidden by flag *FixAddCurve3dMode*;
|
||||
* fixing 2D curves of seam edges -- if not forbidden by flag *FixSeamMode*;
|
||||
* fixing 2D curves which can be shifted at an integer number of periods on the closed surface by call to *ShapeFix_Edge::FixShifted* -- if not forbidden by flag *FixShiftedMode*.
|
||||
|
||||
This fix is required if 2D curves of some edges in a wire lying on a closed surface were recomputed from 3D curves. In that case, the 2D curve for the edge, which goes along the seam of the surface, can be incorrectly shifted at an integer number of periods. The method *FixShifted* detects such cases and shifts wrong 2D curves back, ensuring that the 2D curves of the edges in the wire are connected.
|
||||
|
||||
* fixing the SameParameter problem by call to *ShapeFix_Edge::FixSameParameter* - if not forbidden by flag *FixSameParameterMode*.
|
||||
* fixing the SameParameter problem by call to *ShapeFix_Edge::FixSameParameter* -- if not forbidden by flag *FixSameParameterMode*.
|
||||
|
||||
|
||||
#### Fixing degenerated edges
|
||||
@ -399,7 +400,7 @@ This fix is required if 2D curves of some edges in a wire lying on a closed surf
|
||||
|
||||
#### Fixing a lacking edge
|
||||
|
||||
*FixLacking* method checks whether a wire is not closed in the parametrical space of the surface (while it can be closed in 3D). This is done by checking whether the gap between 2D curves of each of the two adjacent edges in the wire is smaller than the tolerance of the corresponding vertex. The algorithm computes the gap between the edges, analyses positional relationship of the ends of these edges and (if possible) tries to insert a new edge into the gap or increases the tolerance.
|
||||
*FixLacking* method checks whether a wire is not closed in the parametric space of the surface (while it can be closed in 3D). This is done by checking whether the gap between 2D curves of each of the two adjacent edges in the wire is smaller than the tolerance of the corresponding vertex. The algorithm computes the gap between the edges, analyses positional relationship of the ends of these edges and (if possible) tries to insert a new edge into the gap or increases the tolerance.
|
||||
|
||||
#### Fixing gaps in 2D and 3D wire by geometrical filling
|
||||
The following methods check gaps between the ends of 2D or 3D curves of adjacent edges:
|
||||
@ -535,8 +536,8 @@ Class *ShapeFix_Wireframe* provides methods for geometrical fixing of gaps and m
|
||||
* merges and removes small edges.
|
||||
|
||||
Fixing of small edges can be managed with the help of two flags:
|
||||
* *ModeDropSmallEdges()* – mode for removing small edges that can not be merged, by default it is equal to Standard_False.
|
||||
* *LimitAngle* – maximum possible angle for merging two adjacent edges, by default no limit angle is applied (-1).
|
||||
* *ModeDropSmallEdges()* -- mode for removing small edges that can not be merged, by default it is equal to Standard_False.
|
||||
* *LimitAngle* -- maximum possible angle for merging two adjacent edges, by default no limit angle is applied (-1).
|
||||
To perform fixes it is necessary to:
|
||||
* create a tool and initialize it by shape,
|
||||
* set the working precision problems will be detected with and the maximum allowed tolerance
|
||||
@ -649,7 +650,7 @@ These functionalities include:
|
||||
* checking the consistency of edge curves,
|
||||
* checking for the presence or missing of degenerated edges,
|
||||
* checking for the presence of self-intersecting edges and intersecting edges (edges intersection is understood as intersection of their 2D curves),
|
||||
* checking for lacking edges to fill gaps in the surface parametrical space,
|
||||
* checking for lacking edges to fill gaps in the surface parametric space,
|
||||
* analyzing the wire orientation (to define the outer or the inner bound on the face),
|
||||
* analyzing the orientation of the shape (edge or wire) being added to an already existing wire.
|
||||
|
||||
@ -861,11 +862,11 @@ Methods for calculating the number of geometrical objects or sub-shapes with a s
|
||||
and selecting sub-shapes by various criteria.
|
||||
|
||||
The corresponding flags should be set to True for storing a shape by a specified criteria:
|
||||
* faces based on indirect surfaces - *safc.MofifyIndirectMode() = Standard_True*;
|
||||
* faces based on offset surfaces - *safc.ModifyOffsetSurfaceMode() = Standard_True*;
|
||||
* edges if their 3D curves are trimmed - *safc.ModifyTrimmed3dMode() = Standard_True*;
|
||||
* edges if their 3D curves and 2D curves are offset curves - *safc.ModifyOffsetCurveMode() = Standard_True*;
|
||||
* edges if their 2D curves are trimmed - *safc.ModifyTrimmed2dMode() = Standard_True*;
|
||||
* faces based on indirect surfaces -- *safc.MofifyIndirectMode() = Standard_True*;
|
||||
* faces based on offset surfaces -- *safc.ModifyOffsetSurfaceMode() = Standard_True*;
|
||||
* edges if their 3D curves are trimmed -- *safc.ModifyTrimmed3dMode() = Standard_True*;
|
||||
* edges if their 3D curves and 2D curves are offset curves -- *safc.ModifyOffsetCurveMode() = Standard_True*;
|
||||
* edges if their 2D curves are trimmed -- *safc.ModifyTrimmed2dMode() = Standard_True*;
|
||||
|
||||
Let us, for example, select faces based on offset surfaces.
|
||||
|
||||
@ -1051,14 +1052,14 @@ They have methods:
|
||||
* for initializing by geometry (method *Init*)
|
||||
* for splitting (method *Perform*)
|
||||
* for getting the status after splitting and the results:
|
||||
+ *Status* – for getting the result status;
|
||||
+ *ResSurface* - for splitting surfaces;
|
||||
+ *GetCurves* - for splitting 3D and 2D curves.
|
||||
+ *Status* -- for getting the result status;
|
||||
+ *ResSurface* -- for splitting surfaces;
|
||||
+ *GetCurves* -- for splitting 3D and 2D curves.
|
||||
During the process of splitting in the method *Perform* :
|
||||
* splitting values in the parametric space are computed according to a specified criterion (method *Compute*)
|
||||
* splitting is made in accordance with the values computed for splitting (method *Build*).
|
||||
|
||||
To create new tools for geometry splitting it is enough to inherit a new tool from the general tool for splitting a corresponding type of geometry and to re-define the method for computation of splitting values according to the specified criterion in them. (method *Compute*).
|
||||
To create new tools for geometry splitting it is enough to inherit a new tool from the general tool for splitting a corresponding type of geometry and to redefine the method for computation of splitting values according to the specified criterion in them. (method *Compute*).
|
||||
|
||||
Header file for the tool for surface splitting by continuity:
|
||||
|
||||
@ -1276,11 +1277,11 @@ The following flags define whether a specified-type geometry has been converted
|
||||
* *ConvertRevolutionSurf,*
|
||||
* *ConvertExtrusionSurf,*
|
||||
* *ConvertOffsetSurf,*
|
||||
* *ConvertCurve3d,* - for conversion of all types of 3D curves.
|
||||
* *ConvertOffsetCurv3d,* - for conversion of offset 3D curves.
|
||||
* *ConvertCurve2d,* - for conversion of all types of 2D curves.
|
||||
* *ConvertOffsetCurv2d,* - for conversion of offset 2D curves.
|
||||
* *SegmentSurfaceMode* - defines whether the surface would be approximated within the boundaries of the face lying on this surface.
|
||||
* *ConvertCurve3d,* -- for conversion of all types of 3D curves.
|
||||
* *ConvertOffsetCurv3d,* -- for conversion of offset 3D curves.
|
||||
* *ConvertCurve2d,* -- for conversion of all types of 2D curves.
|
||||
* *ConvertOffsetCurv2d,* -- for conversion of offset 2D curves.
|
||||
* *SegmentSurfaceMode* -- defines whether the surface would be approximated within the boundaries of the face lying on this surface.
|
||||
|
||||
|
||||
|
||||
@ -1317,7 +1318,7 @@ The general calling syntax for scaling is
|
||||
TopoDS_Shape scaled_shape = ShapeCustom::ScaleShape(shape, scale);
|
||||
~~~~~
|
||||
|
||||
Note that scale is a real value. You can refine your mapping process by using additional calls to follow shape mapping subshape by subshape. The following code along with pertinent includes can be used:
|
||||
Note that scale is a real value. You can refine your mapping process by using additional calls to follow shape mapping sub-shape by sub-shape. The following code along with pertinent includes can be used:
|
||||
|
||||
~~~~~
|
||||
p_Trsf T;
|
||||
@ -1333,7 +1334,7 @@ Shape, TM, context,MD );
|
||||
|
||||
The map, called context in our example, contains the history.
|
||||
Substitutions are made one by one and all shapes are transformed.
|
||||
To determine what happens to a particular subshape, it is possible to use:
|
||||
To determine what happens to a particular sub-shape, it is possible to use:
|
||||
|
||||
~~~~~
|
||||
TopoDS_Shape oneres = context.Find (oneshape);
|
||||
@ -1514,14 +1515,14 @@ TopoDS_Shape tempshape1 = Context->Apply(subshape1);
|
||||
//replacing the intermediate shape obtained from subshape1 with the newsubshape1.
|
||||
Context->Replace(tempsubshape1,newsubshape1);
|
||||
…
|
||||
//for removing the subshape
|
||||
//for removing the sub-shape
|
||||
TopoDS_Shape tempshape2 = Context->Apply(subshape2);
|
||||
Context->Remove(tempsubshape2);
|
||||
|
||||
//getting the result and the history of modification
|
||||
TopoDS_Shape resultShape = Context->Apply(initialShape);
|
||||
|
||||
//getting the resulting subshape from the subshape1 of the initial shape.
|
||||
//getting the resulting sub-shape from the subshape1 of the initial shape.
|
||||
TopoDS_Shape result_subshape1 = Context->Apply(subshape1);
|
||||
~~~~~
|
||||
|
||||
@ -1721,8 +1722,8 @@ The operator applies the computation *SameParameter* which ensures that various
|
||||
* For each edge coded as *not same parameter* the deviation is computed as in the first case. Then an attempt is made to achieve the edge equality to *same parameter* by means of modification of 2d curves. If the deviation of this modified edge is less than the original deviation then this edge is returned, otherwise the original edge (with non-modified 2d curves) is returned with an increased (if necessary) tolerance. Computation is done by call to the standard algorithm *BRepLib::SameParameter*.
|
||||
|
||||
This operator can be called with the following parameters:
|
||||
* *Boolean : Force* (optional) - if True, encodes all edges as *not same parameter* then runs the computation. Else, the computation is done only for those edges already coded as *not same parameter*.
|
||||
* *Real : Tolerance3d* (optional) - if not defined, the local tolerance of each edge is taken for its own computation. Else, this parameter gives the global tolerance for the whole shape.
|
||||
* *Boolean : Force* (optional) -- if True, encodes all edges as *not same parameter* then runs the computation. Else, the computation is done only for those edges already coded as *not same parameter*.
|
||||
* *Real : Tolerance3d* (optional) -- if not defined, the local tolerance of each edge is taken for its own computation. Else, this parameter gives the global tolerance for the whole shape.
|
||||
|
||||
### BSplineRestriction
|
||||
|
||||
@ -1767,8 +1768,8 @@ This operator converts elementary periodic surfaces to SurfaceOfRevolution.
|
||||
This operator splits surfaces of revolution, cylindrical, toroidal, conical, spherical surfaces in the given shape so that each resulting segment covers not more than the defined number of degrees.
|
||||
|
||||
It can be called with the following parameters:
|
||||
* *Real : Angle* - the maximum allowed angle for resulting faces;
|
||||
* *Real : MaxTolerance* - the maximum tolerance used in computations.
|
||||
* *Real : Angle* -- the maximum allowed angle for resulting faces;
|
||||
* *Real : MaxTolerance* -- the maximum tolerance used in computations.
|
||||
|
||||
### SurfaceToBSpline
|
||||
This operator converts some specific types of Surfaces, to BSpline (according to parameters).
|
||||
@ -1896,9 +1897,9 @@ Various messages about modification, warnings and fails can be generated in the
|
||||
@subsection occt_shg_7_1 Message Gravity
|
||||
Enumeration *Message_Gravity* is used for defining message gravity.
|
||||
It provides the following message statuses:
|
||||
* *Message_FAIL* - the message reports a fail;
|
||||
* *Message_WARNING* - the message reports a warning;
|
||||
* *Message_INFO* - the message supplies information.
|
||||
* *Message_FAIL* -- the message reports a fail;
|
||||
* *Message_WARNING* -- the message reports a warning;
|
||||
* *Message_INFO* -- the message supplies information.
|
||||
|
||||
@subsection occt_shg_7_2 Tool for loading a message file into memory
|
||||
Class *Message_MsgFile* allows defining messages by loading a custom message file into memory. It is necessary to create a custom message file before loading it into memory, as its path will be used as the argument to load it. Each message in the message file is identified by a key. The user can get the text content of the message by specifying the message key.
|
||||
@ -1939,9 +1940,9 @@ Message_MsgFile::LoadFile (MsgFilePath);
|
||||
The class *Message_Msg* allows using the message file loaded as a template. This class provides a tool for preparing the message, filling it with parameters, storing and outputting to the default trace file.
|
||||
A message is created from a key: this key identifies the message to be created in the message file. The text of the message is taken from the loaded message file (class *Message_MsgFile* is used).
|
||||
The text of the message can contain places for parameters, which are to be filled by the proper values when the message is prepared. These parameters can be of the following types:
|
||||
* string - coded in the text as \%s,
|
||||
* integer - coded in the text as \%d,
|
||||
* real - coded in the text as \%f.
|
||||
* string -- coded in the text as \%s,
|
||||
* integer -- coded in the text as \%d,
|
||||
* real -- coded in the text as \%f.
|
||||
The parameter fields are filled by the message text by calling the corresponding methods *AddInteger, AddReal* and *AddString*. Both the original text of the message and the input text with substituted parameters are stored in the object. The prepared and filled message can be output to the default trace file. The text of the message (either original or filled) can be also obtained.
|
||||
~~~~~
|
||||
Message_Msg msg01 (;SampleKeyword;);
|
||||
|
||||
@ -56,7 +56,7 @@ Basic interface reads and writes geometrical, topological STEP data and assembly
|
||||
|
||||
The interface is able to translate one entity, a group of entities or a whole file.
|
||||
|
||||
Other kinds of data such as colors, validation properties, layers, names and the structure of assemblies can be read or written with the help of XDE tools - <i> STEPCAFControl_Reader</i> and <i> STEPCAFControl_Writer</i>.
|
||||
Other kinds of data such as colors, validation properties, layers, names and the structure of assemblies can be read or written with the help of XDE tools: <i> STEPCAFControl_Reader</i> and <i> STEPCAFControl_Writer</i>.
|
||||
|
||||
To choose a translation mode when exporting to a STEP format, use <i> STEPControl_STEPModelType</i>.
|
||||
|
||||
@ -139,9 +139,9 @@ If *failsonly* is true only fail messages are displayed. All messages are displa
|
||||
IFSelect_PrintCount mode = IFSelect_xxx
|
||||
~~~~~
|
||||
Where xxx can be one of the following:
|
||||
* *ItemsByEntity* - gives a sequential list of all messages per STEP entity,
|
||||
* *CountByItem* - gives the number of STEP entities with their types per message
|
||||
* *ListByItem* - gives the number of STEP entities with their types and rank numbers per message
|
||||
* *ItemsByEntity* -- gives a sequential list of all messages per STEP entity,
|
||||
* *CountByItem* -- gives the number of STEP entities with their types per message
|
||||
* *ListByItem* -- gives the number of STEP entities with their types and rank numbers per message
|
||||
|
||||
@subsubsection occt_step_2_3_3 Setting the translation parameters
|
||||
The following parameters can be used to translate a STEP file into an OCCT shape.
|
||||
@ -150,8 +150,8 @@ If you give a value that is not within the range of possible values it will simp
|
||||
|
||||
<h4>read.precision.mode</h4>
|
||||
Defines which precision value will be used during translation (see section 2.5 below for details on precision and tolerances).
|
||||
* *File (0)* - the precision value is set to length_measure in uncertainty_measure_with_unit from STEP file.
|
||||
* *User (1)* - the precision value is that of the *read.precision.val* parameter.
|
||||
* *File (0)* -- the precision value is set to length_measure in uncertainty_measure_with_unit from STEP file.
|
||||
* *User (1)* -- the precision value is that of the *read.precision.val* parameter.
|
||||
|
||||
Read this parameter with:
|
||||
|
||||
@ -201,8 +201,8 @@ Note that maximum tolerance even explicitly defined by the user may be insuffici
|
||||
|
||||
<h4>read.maxprecision.mode:</h4>
|
||||
Defines the mode of applying the maximum allowed tolerance. Its possible values are:
|
||||
* 0 (Preferred) - maximum tolerance is used as a limit but sometimes it can be exceeded (currently, only for deviation of a 3D curve and pcurves of an edge, and vertices of such edge) to ensure the shape validity,
|
||||
* 1 (Forced) - maximum tolerance is used as a rigid limit, i.e. no tolerance can exceed it and if it is the case, the tolerance is trimmed by the maximum tolerance.
|
||||
* 0 (Preferred) -- maximum tolerance is used as a limit but sometimes it can be exceeded (currently, only for deviation of a 3D curve and pcurves of an edge, and vertices of such edge) to ensure the shape validity,
|
||||
* 1 (Forced) -- maximum tolerance is used as a rigid limit, i.e. no tolerance can exceed it and if it is the case, the tolerance is trimmed by the maximum tolerance.
|
||||
|
||||
Read this parameter with:
|
||||
~~~~~
|
||||
@ -218,8 +218,8 @@ Default value is 0 ("Preferred").
|
||||
<h4>read.stdsameparameter.mode</h4>
|
||||
defines the use of *BRepLib::SameParameter*. Its possible values are:
|
||||
|
||||
* 0 (Off) - *BRepLib::SameParameter* is not called,
|
||||
* 1 (On) - *BRepLib::SameParameter* is called.
|
||||
* 0 (Off) -- *BRepLib::SameParameter* is not called,
|
||||
* 1 (On) -- *BRepLib::SameParameter* is called.
|
||||
The functionality of *BRepLib::SameParameter* is used through *ShapeFix_Edge::SameParameter*. It ensures that the resulting edge will have the lowest tolerance taking pcurves either unmodified from the STEP file or modified by *BRepLib::SameParameter*.
|
||||
|
||||
Read this parameter with:
|
||||
@ -273,15 +273,15 @@ Default value is File
|
||||
|
||||
<h4>read.step.resource.name and read.step.sequence</h4>
|
||||
|
||||
These two parameters define the name of the resource file and the name of the sequence of operators (defined in that file) for Shape Processing, which is automatically performed by the STEP translator. Shape Processing is a user-configurable step, which is performed after translation and consists in applying a set of operators to a resulting shape. This is a very powerful tool allowing customizing the shape and adapting it to the needs of a receiving application. By default the sequence consists of a single operator ShapeFix - that is how Shape Healing is called from the STEP translator.
|
||||
These two parameters define the name of the resource file and the name of the sequence of operators (defined in that file) for Shape Processing, which is automatically performed by the STEP translator. Shape Processing is a user-configurable step, which is performed after translation and consists in applying a set of operators to a resulting shape. This is a very powerful tool allowing customizing the shape and adapting it to the needs of a receiving application. By default the sequence consists of a single operator ShapeFix -- that is how Shape Healing is called from the STEP translator.
|
||||
|
||||
Please find an example of the resource file for STEP (which defines parameters corresponding to the sequence applied by default, i.e. if the resource file is not found) in the Open CASCADE Technology installation, by the path <i>%CASROOT%/src/XSTEPResource/STEP</i>.
|
||||
|
||||
In order for the STEP translator to use that file, you have to define the *CSF_STEPDefaults* environment variable, which should point to the directory where the resource file resides. Note that if you change parameter *read.step.resource.name*, you will change the name of the resource file and the environment variable correspondingly.
|
||||
|
||||
Default values:
|
||||
* read.step.resource.name - STEP,
|
||||
* read.step.sequence - FromSTEP.
|
||||
* read.step.resource.name -- STEP,
|
||||
* read.step.sequence -- FromSTEP.
|
||||
|
||||
<h4>xstep.cascade.unit</h4>
|
||||
This parameter defines units to which a shape should be converted when translated from IGES or STEP to CASCADE. Normally it is MM; only those applications that work internally in units other than MM should use this parameter.
|
||||
@ -290,8 +290,8 @@ Default value is MM.
|
||||
|
||||
<h4>read.step.product.mode:</h4>
|
||||
Defines the approach used for selection of top-level STEP entities for translation, and for recognition of assembly structures
|
||||
* 1 (ON) - *PRODUCT_DEFINITION* entities are taken as top-level ones; assembly structure is recognized by *NEXT_ASSEMBLY_USAGE_OCCURRENCE* entities. This is regular mode for reading valid STEP files conforming to AP 214, AP203 or AP 209.
|
||||
* 0 (OFF) - *SHAPE_DEFINITION_REPRESENTATION* entities are taken as top-level ones; assembly is recognized by *CONTEXT_DEPENDENT_SHAPE_REPRESENTATION* entities. This is compatibility mode, which can be used for reading legacy STEP files produced by older versions of STEP translators and having incorrect or incomplete product information.
|
||||
* 1 (ON) -- *PRODUCT_DEFINITION* entities are taken as top-level ones; assembly structure is recognized by *NEXT_ASSEMBLY_USAGE_OCCURRENCE* entities. This is regular mode for reading valid STEP files conforming to AP 214, AP203 or AP 209.
|
||||
* 0 (OFF) -- *SHAPE_DEFINITION_REPRESENTATION* entities are taken as top-level ones; assembly is recognized by *CONTEXT_DEPENDENT_SHAPE_REPRESENTATION* entities. This is compatibility mode, which can be used for reading legacy STEP files produced by older versions of STEP translators and having incorrect or incomplete product information.
|
||||
|
||||
Read this parameter with:
|
||||
~~~~~
|
||||
@ -310,9 +310,9 @@ Note that the following parameters have effect only if *read.step.product.mode*
|
||||
<h4>read.step.product.context:</h4>
|
||||
|
||||
When reading AP 209 STEP files, allows selecting either only ‘design’ or ‘analysis’, or both types of products for translation
|
||||
* 1 (all) - translates all products;
|
||||
* 2 (design) - translates only products that have *PRODUCT_DEFINITION_CONTEXT* with field *life_cycle_stage* set to ‘design’;
|
||||
* 3 (analysis) - translates only products associated with *PRODUCT_DEFINITION_CONTEXT* entity whose field *life_cycle_stage* set to ‘analysis’.
|
||||
* 1 (all) -- translates all products;
|
||||
* 2 (design) -- translates only products that have *PRODUCT_DEFINITION_CONTEXT* with field *life_cycle_stage* set to ‘design’;
|
||||
* 3 (analysis) -- translates only products associated with *PRODUCT_DEFINITION_CONTEXT* entity whose field *life_cycle_stage* set to ‘analysis’.
|
||||
|
||||
Note that in AP 203 and AP214 files all products should be marked as ‘design’, so if this mode is set to ‘analysis’, nothing will be read.
|
||||
|
||||
@ -331,13 +331,13 @@ Default value is 1 (all).
|
||||
<h4>read.step.shape.repr:</h4>
|
||||
|
||||
Specifies preferred type of representation of the shape of the product, in case if a STEP file contains more than one representation (i.e. multiple PRODUCT_DEFINITION_SHAPE entities) for a single product
|
||||
* 1 (All) - Translate all representations (if more than one, put in compound).
|
||||
* 1 (All) -- Translate all representations (if more than one, put in compound).
|
||||
* 2 (ABSR) - Prefer ADVANCED_BREP_SHAPE_REPRESENTATION
|
||||
* 3 (MSSR) - Prefer MANIFOLD_SURFACE_SHAPE_REPRESENTATION
|
||||
* 4 (GBSSR) - Prefer GEOMETRICALLY_BOUNDED_SURFACE_SHAPE_REPRESENTATION
|
||||
* 5 (FBSR) - Prefer FACETTED_BREP_SHAPE_REPRESENTATION
|
||||
* 6 (EBWSR) - Prefer EDGE_BASED_WIREFRAME_SHAPE_REPRESENTATION
|
||||
* 7 (GBWSR) - Prefer GEOMETRICALLY_BOUNDED_WIREFRAME _SHAPE_REPRESENTATION
|
||||
* 3 (MSSR) -- Prefer MANIFOLD_SURFACE_SHAPE_REPRESENTATION
|
||||
* 4 (GBSSR) -- Prefer GEOMETRICALLY_BOUNDED_SURFACE_SHAPE_REPRESENTATION
|
||||
* 5 (FBSR) -- Prefer FACETTED_BREP_SHAPE_REPRESENTATION
|
||||
* 6 (EBWSR) -- Prefer EDGE_BASED_WIREFRAME_SHAPE_REPRESENTATION
|
||||
* 7 (GBWSR) -- Prefer GEOMETRICALLY_BOUNDED_WIREFRAME _SHAPE_REPRESENTATION
|
||||
|
||||
When this option is not equal to 1, for products with multiple representations the representation having a type closest to the selected one in this list will be translated.
|
||||
|
||||
@ -355,10 +355,10 @@ Default value is 1 (All).
|
||||
<h4>read.step.assembly.level:</h4>
|
||||
|
||||
Specifies which data should be read for the products found in the STEP file:
|
||||
* 1 (All) - Translate both the assembly structure and all associated shapes. If both shape and sub-assemblies are associated with the same product, all of them are read and put in a single compound. Note that this situation is confusing, as semantics of such configuration is not defined clearly by the STEP standard (whether this shape is an alternative representation of the assembly or is an addition to it), therefore warning will be issued in such case.
|
||||
* 2 (assembly) - Translate the assembly structure and shapes associated with parts only (not with sub-assemblies).
|
||||
* 3 (structure) - Translate only the assembly structure without shapes (a structure of empty compounds). This mode can be useful as an intermediate step in applications requiring specialized processing of assembly parts.
|
||||
* 4 (shape) - Translate only shapes associated with the product, ignoring the assembly structure (if any). This can be useful to translate only a shape associated with specific product, as a complement to *assembly* mode.
|
||||
* 1 (All) -- Translate both the assembly structure and all associated shapes. If both shape and sub-assemblies are associated with the same product, all of them are read and put in a single compound. Note that this situation is confusing, as semantics of such configuration is not defined clearly by the STEP standard (whether this shape is an alternative representation of the assembly or is an addition to it), therefore warning will be issued in such case.
|
||||
* 2 (assembly) -- Translate the assembly structure and shapes associated with parts only (not with sub-assemblies).
|
||||
* 3 (structure) -- Translate only the assembly structure without shapes (a structure of empty compounds). This mode can be useful as an intermediate step in applications requiring specialized processing of assembly parts.
|
||||
* 4 (shape) -- Translate only shapes associated with the product, ignoring the assembly structure (if any). This can be useful to translate only a shape associated with specific product, as a complement to *assembly* mode.
|
||||
|
||||
Read this parameter with:
|
||||
~~~~~
|
||||
@ -374,8 +374,8 @@ Default value is 1 (All).
|
||||
|
||||
<h4>read.step.shape.relationship:</h4>
|
||||
Defines whether shapes associated with the main *SHAPE_DEFINITION_REPRESENTATION* entity of the product via *SHAPE_REPRESENTATIONSHIP_RELATION* should be translated. This kind of association is used for the representation of hybrid models (i.e. models whose shape is composed of different types of representations) in AP 203 files since 1998, but it can be also used to associate auxiliary data with the product. This parameter allows to avoid translation of such auxiliary data.
|
||||
* 1 (ON) - translate
|
||||
* 0 (OFF) - do not translate
|
||||
* 1 (ON) -- translate
|
||||
* 0 (OFF) -- do not translate
|
||||
|
||||
Read this parameter with:
|
||||
~~~~~
|
||||
@ -391,8 +391,8 @@ Default value is 1 (ON).
|
||||
<h4>read.step.shape.aspect:</h4>
|
||||
Defines whether shapes associated with the *PRODUCT_DEFINITION_SHAPE* entity of the product via *SHAPE_ASPECT* should be translated. This kind of association was used for the representation of hybrid models (i.e. models whose shape is composed of different types of representations) in AP 203 files before 1998, but it is also used to associate auxiliary information with the sub-shapes of the part. Though STEP translator tries to recognize such cases correctly, this parameter may be useful to avoid unconditionally translation of shapes associated via *SHAPE_ASPECT* entities.
|
||||
|
||||
* 1 (ON) - translate
|
||||
* 0 (OFF) - do not translate
|
||||
* 1 (ON) -- translate
|
||||
* 0 (OFF) -- do not translate
|
||||
|
||||
Read this parameter with:
|
||||
~~~~~
|
||||
@ -426,10 +426,10 @@ Perform the translation according to what you want to translate. You can choose
|
||||
|
||||
The following methods are used for translation:
|
||||
|
||||
* *Standard_Boolean ok = reader.TransferRoot(rank)* - translates a root entity identified by its rank;
|
||||
* *Standard_Boolean ok = reader.TransferOne(rank)* - translates an entity identified by its rank;
|
||||
* *Standard_Integer num = reader.TransferList(list)* - translates a list of entities in one operation (this method returns the number of successful translations);
|
||||
* *Standard_Integer NbRoots = reader.NbRootsForTransfer()* and *Standard_Integer num = reader.TransferRoots()* - translate all transferable roots.
|
||||
* *Standard_Boolean ok = reader.TransferRoot(rank)* -- translates a root entity identified by its rank;
|
||||
* *Standard_Boolean ok = reader.TransferOne(rank)* -- translates an entity identified by its rank;
|
||||
* *Standard_Integer num = reader.TransferList(list)* -- translates a list of entities in one operation (this method returns the number of successful translations);
|
||||
* *Standard_Integer NbRoots = reader.NbRootsForTransfer()* and *Standard_Integer num = reader.TransferRoots()* -- translate all transferable roots.
|
||||
|
||||
@subsubsection occt_step_2_3_5 Getting the translation results
|
||||
Each successful translation operation outputs one shape. A series of translations gives a set of shapes.
|
||||
@ -441,10 +441,10 @@ reader.ClearShapes();
|
||||
between two translation operations, if you do not, the results from the next translation will be added to the accumulation.
|
||||
|
||||
*TransferRoots()* operations automatically clear all existing results before they start.
|
||||
* *Standard_Integer num = reader.NbShapes()* - gets the number of shapes recorded in the result;
|
||||
* *TopoDS_Shape shape = reader.Shape(rank)* gets the result identified by its rank, where rank is an integer between 1 and NbShapes;
|
||||
* *TopoDS_Shape shape = reader.Shape()* gets the first result of translation;
|
||||
* *TopoDS_Shape shape = reader.OneShape()* - gets all results in a single shape which is:
|
||||
* *Standard_Integer num = reader.NbShapes()* -- gets the number of shapes recorded in the result;
|
||||
* *TopoDS_Shape shape = reader.Shape(rank)* -- gets the result identified by its rank, where rank is an integer between 1 and NbShapes;
|
||||
* *TopoDS_Shape shape = reader.Shape()* -- gets the first result of translation;
|
||||
* *TopoDS_Shape shape = reader.OneShape()* -- gets all results in a single shape, which is:
|
||||
* a null shape if there are no results,
|
||||
* in case of a single result, a shape that is specific to that result,
|
||||
* a compound that lists the results if there are several results.
|
||||
@ -505,20 +505,20 @@ for (i = 1; i <= nb; i ++) {
|
||||
|
||||
<h4>Selections</h4>
|
||||
There is a number of predefined operators that can be used. They are:
|
||||
* *step214-placed-items* - selects all mapped_items or context_depended_shape_representations.
|
||||
* *step214-shape-def-repr* - selects all shape_definition_representations.
|
||||
* *step214-shape-repr* - selects all shape_representations.
|
||||
* *step214-type(\<entity_type\>)* - selects all entities of a given type
|
||||
* *step214-faces* - selects all faces_surface, advanced_face entities and the surface entity or any sub type if these entities are not shared by any face entity or shared by geometric_set entity.
|
||||
* *step214-derived(\<entity_type\>)* - selects entities of a given type or any subtype.
|
||||
* *step214-GS-curves* - selects all curve entities or any subtype except the composite_curve if these entities are shared by the geometric_set entity.
|
||||
* *step214-assembly* - selects all mapped_items or context_depended_shape_representations involved into the assembly structure.
|
||||
* *xst-model-all* - selects all entities.
|
||||
* *xst-model-roots* - selects all roots.
|
||||
* *xst-shared + \<selection\>* - selects all entities shared by at least one entity selected by selection.
|
||||
* *xst-sharing + \<selection\>* - selects all entities sharing at least one entity selected by selection.
|
||||
* *xst-transferrable-all* - selects all transferable entities.
|
||||
* *xst-transferrable-roots* selects all translatable roots.
|
||||
* *step214-placed-items* -- selects all mapped_items or context_depended_shape_representations.
|
||||
* *step214-shape-def-repr* -- selects all shape_definition_representations.
|
||||
* *step214-shape-repr* -- selects all shape_representations.
|
||||
* *step214-type(\<entity_type\>)* -- selects all entities of a given type
|
||||
* *step214-faces* -- selects all faces_surface, advanced_face entities and the surface entity or any sub type if these entities are not shared by any face entity or shared by geometric_set entity.
|
||||
* *step214-derived(\<entity_type\>)* -- selects entities of a given type or any subtype.
|
||||
* *step214-GS-curves* -- selects all curve entities or any subtype except the composite_curve if these entities are shared by the geometric_set entity.
|
||||
* *step214-assembly* -- selects all mapped_items or context_depended_shape_representations involved into the assembly structure.
|
||||
* *xst-model-all* -- selects all entities.
|
||||
* *xst-model-roots* -- selects all roots.
|
||||
* *xst-shared + \<selection\>* -- selects all entities shared by at least one entity selected by selection.
|
||||
* *xst-sharing + \<selection\>* -- selects all entities sharing at least one entity selected by selection.
|
||||
* *xst-transferrable-all* -- selects all transferable entities.
|
||||
* *xst-transferrable-roots* -- selects all translatable roots.
|
||||
Cumulative lists can be used as well.
|
||||
|
||||
<h5>Single entities</h5>
|
||||
@ -652,11 +652,11 @@ During the STEP to OCCT translation several parameters are used as tolerances an
|
||||
<h4>3D (spatial) tolerance</h4>
|
||||
* Package method *Precision::Confusion()* Value is 10-7. It is used as the minimal distance between points, which are considered to be distinct.
|
||||
* Uncertainty parameter is attached to each shape_representation entity in a STEP file and defined as *length_measure* in *uncertainty_measure_with_unit*. It is used as a fundamental value of precision during translation.
|
||||
* User - defined variable *read.precision.val* is used instead of uncertainty from a STEP file when parameter *read.precision.mode* is 1 (User).
|
||||
* User-defined variable *read.precision.val* is used instead of uncertainty from a STEP file when parameter *read.precision.mode* is 1 (User).
|
||||
|
||||
<h4>2D (parametric) tolerances</h4>
|
||||
* Package method *Precision\::PConfusion()* is a value of *0.01\*Precision\::Confusion()*. It is used to compare parametric bounds of curves.
|
||||
* Methods *UResolution* and *VResolution (tolerance3d)* of the class *GeomAdaptor_Surface* or *BRepAdaptor_Surface* - return tolerance in parametric space of a surface computed from 3d tolerance. When one tolerance value is to be used for both U and V parametric directions, the maximum or the minimum value of *UResolution* and *VResolution* is used.
|
||||
* Methods *UResolution* and *VResolution (tolerance3d)* of the class *GeomAdaptor_Surface* or *BRepAdaptor_Surface* return tolerance in parametric space of a surface computed from 3d tolerance. When one tolerance value is to be used for both U and V parametric directions, the maximum or the minimum value of *UResolution* and *VResolution* is used.
|
||||
* Methods *Resolution (tolerance3d)* of the class *GeomAdaptor_Curve* or *BRepAdaptor_Curve* return tolerance in parametric space of a curve computed from 3d tolerance.
|
||||
|
||||
@subsubsection occt_step_2_5_2 Initial setting of tolerances in translating objects
|
||||
@ -676,7 +676,7 @@ If the starting STEP entity is a geometric_curve_set all the edges and vertices
|
||||
If the starting STEP entity is not a geometric_curve_set the sub-shapes of the resulting shape have the following tolerance:
|
||||
* all the faces are constructed with *Precision::Confusion()*,
|
||||
* edges are constructed with *Precision::Confusion()*. It can be modified later by:
|
||||
* *ShapeFix::SameParameter()* - the tolerance of edge shows real deviation of the 3D curve and pcurves.
|
||||
* *ShapeFix::SameParameter()* -- the tolerance of edge shows real deviation of the 3D curve and pcurves.
|
||||
* *ShapeFix_Wire::FixSelfIntersection()* if a pcurve of a self-intersecting edge is modified.
|
||||
* vertices are constructed with Precision::Confusion(). It can be modified later by:
|
||||
*StepToTopoDS_TranslateEdge*
|
||||
@ -911,8 +911,8 @@ These two parameters define the name of the resource file and the name of the se
|
||||
See description of parameter read.step.resource.name above for more details on using resource files.
|
||||
|
||||
Default values:
|
||||
* read.step.resource.name - STEP,
|
||||
* read.step.sequence - ToSTEP.
|
||||
* read.step.resource.name -- STEP,
|
||||
* read.step.sequence -- ToSTEP.
|
||||
|
||||
<h4>write.step.vertex.mode</h4>
|
||||
This parameter indicates which of free vertices writing mode is switch on.
|
||||
@ -947,11 +947,11 @@ The following values of enumeration are allowed:
|
||||
* *STEPControl_GeometricCurveSet* resulting entity is *geometric_curve_set*;
|
||||
|
||||
The following list shows which shapes can be translated in which mode:
|
||||
* *STEP214Control_AsIs* - any OCCT shape
|
||||
* *STEP214Control_ManifoldSolidBrep* - *TopoDS_Solid, TopoDS_Shell, TopoDS_Compound* (if it contains *TopoDS_Solids* and *TopoDS_Shells*.
|
||||
* *STEP214Control_FacetedBrep* - *TopoDS_Solid* or *TopoDS_Compound* containing *TopoDS_Solids* if all its surfaces are *Geom_Planes* and all curves are *Geom_Lines*.
|
||||
* *STEP214Control_ShellBasedSurfaceModel* - *TopoDS_Solid, TopoDS_Shell, TopoDS_Face* and *TopoDS_Compound* (if it contains all mentioned shapes)
|
||||
* *STEP214Control_GeometricCurveSet* - any OCCT shape.
|
||||
* *STEP214Control_AsIs* -- any OCCT shape
|
||||
* *STEP214Control_ManifoldSolidBrep* -- *TopoDS_Solid, TopoDS_Shell, TopoDS_Compound* (if it contains *TopoDS_Solids* and *TopoDS_Shells*.
|
||||
* *STEP214Control_FacetedBrep* -- *TopoDS_Solid* or *TopoDS_Compound* containing *TopoDS_Solids* if all its surfaces are *Geom_Planes* and all curves are *Geom_Lines*.
|
||||
* *STEP214Control_ShellBasedSurfaceModel* -- *TopoDS_Solid, TopoDS_Shell, TopoDS_Face* and *TopoDS_Compound* (if it contains all mentioned shapes)
|
||||
* *STEP214Control_GeometricCurveSet* -- any OCCT shape.
|
||||
|
||||
If *TopoDS_Compound* contains any other types besides the ones mentioned in the table, these sub-shapes will be ignored.
|
||||
|
||||
@ -1109,7 +1109,7 @@ To perform data loading from a STEP file and to translate this data it is necess
|
||||
* Late binding means that the processor works with a description of the schema. The processor builds a dictionary of entities and can recognize and read any entity that is described in the schema. To change the behavior and the scope of processor based on late binding it is enough to change the description of the schema. However, this binding has some disadvantages (for example low speed of reading process).
|
||||
* In case of early binding, the structure of CDL classes is created beforehand with the help of a specific automatic tool or manually. If the processor finds an entity that is not found in this schema, it will simply be ignored. The processor calls constructors of appropriate classes and their read methods. To add a new type in the scope of the processor it is necessary to create a class corresponding to the new entity.
|
||||
|
||||
The STEP processor is based on early binding principles. It means that specific classes for each EXPRESS type have been created with the help of an automatic tool from the EXPRESS schema. There are two CDL classes for each EXPRESS type. The first class (named the representing class) represents the STEP entity in memory. The second one (RW - class) is intended to perform the initialization of the representing class and to output data to an intermediate structure to be written in a STEP file.
|
||||
The STEP processor is based on early binding principles. It means that specific classes for each EXPRESS type have been created with the help of an automatic tool from the EXPRESS schema. There are two CDL classes for each EXPRESS type. The first class (named the representing class) represents the STEP entity in memory. The second one (RW-class) is intended to perform the initialization of the representing class and to output data to an intermediate structure to be written in a STEP file.
|
||||
|
||||
@subsubsection occt_step_4_1_2 Complex entities
|
||||
EXPRESS schema allows multiple inheritance. Entities that are built on the basis of multiple inheritance are called complex entities. Multiple inheritance is not available in CDL. EXPRESS enables any type of complex entities that can be inherited from any EXPRESS type. In the manner of early binding it is not possible to create a CDL class for any possible complex type. Thus, only widespread complex entities have corresponding representing classes and RW-classes that are created manually beforehand.
|
||||
@ -1134,7 +1134,7 @@ For each entity specified by its rank number the arrays storing its identifier,
|
||||
@subsubsection occt_step_4_2_3 Creating empty Open CASCADE Technology objects that represent STEP entities
|
||||
For each STEP entity an empty OCCT object representing this entity is created. A map of correspondence between entity rank and OCCT object is created and filled out. If a STEP entity is not recognized by the STEP processor then the *StepData_UndefinedEntity* object is created.
|
||||
@subsubsection occt_step_4_2_4 Initializing Open CASCADE Technology objects
|
||||
Each OCCT object (including StepData_UndefinedEntity) is initialized by its parameters with the help of the appropriate RW - class. If some entity has another entity as its parameter, the object that represents the latter entity will be initialized immediately. All initialized objects are put into a special map to avoid repeated initialization.
|
||||
Each OCCT object (including StepData_UndefinedEntity) is initialized by its parameters with the help of the appropriate RW-class. If an entity has another entity as its parameter, the object that represents the latter entity will be initialized immediately. All initialized objects are put into a special map to avoid repeated initialization.
|
||||
@subsubsection occt_step_4_2_5 Building a graph
|
||||
The final phase is building a graph of references between entities. For each entity its RW-class is used to find entities referenced by this entity. Back references are built on the basis of direct references. In addition to explicit references defined in the STEP entities some additional (implicit) references are created for entities representing assembly structures (links from assemblies to their components).
|
||||
@subsection occt_step_4_3 How to add a new entity in scope of the STEP processor
|
||||
@ -1168,7 +1168,7 @@ Each field of a STEP entity should be represented by a corresponding field of th
|
||||
@subsection occt_step_4_4 Physical file writing
|
||||
Physical file writing consists of the following steps:
|
||||
1. Building a references graph. Physical writing starts when STEP model, which was either loaded from a STEP file or created from OCCT shape with the help of translator, is available together with corresponding graph of references. During this step the graph of references can be recomputed.
|
||||
2. Transferring data from a model to a sequence of strings. For each representing entity from the model a corresponding RW - class is called. RW - class performs the writing of data that is contained in the representing class into an intermediate data structure. The mentioned structure is a sequence of strings in memory.
|
||||
2. Transferring data from a model to a sequence of strings. For each representing entity from the model a corresponding RW-class is called. RW-class writes data that is contained in the representing class into an intermediate data structure. The mentioned structure is a sequence of strings in memory.
|
||||
3. Writing the sequence of strings into the file. The sequence of strings is written into the file. This is the last phase of physical STEP writing.
|
||||
|
||||
|
||||
@ -1198,10 +1198,10 @@ The third argument is used to set a new value of the given parameter. The result
|
||||
During all interface operations, the protocol of the process (fail and warning messages, mapping of loaded entities into OCCT shapes etc.) can be output to the trace file. Two parameters are defined in the DRAW session: trace level (integer value from 0 to 9, default is 0), and trace file (default is standard output).
|
||||
|
||||
Command xtrace is intended to view and change these parameters:
|
||||
* *Draw:> xtrace* - prints current settings (e.g.: `Level=1 - Standard Output');
|
||||
* *Draw:> xtrace \#* - sets trace level to the value #;
|
||||
* *Draw:> xtrace tracefile.log* - sets the trace file as *tracefile.log*;
|
||||
* *Draw:> xtrace.* - directs all messages to the standard output.
|
||||
* *Draw:> xtrace* -- prints current settings (e.g.: `Level=1 - Standard Output');
|
||||
* *Draw:> xtrace \#* -- sets trace level to the value #;
|
||||
* *Draw:> xtrace tracefile.log* -- sets the trace file as *tracefile.log*;
|
||||
* *Draw:> xtrace.* -- directs all messages to the standard output.
|
||||
|
||||
@subsection occt_step_6_3 Reading a STEP file
|
||||
|
||||
@ -1267,16 +1267,16 @@ Draw:> data <symbol>
|
||||
|
||||
Information printed by this command depends on the symbol specified:
|
||||
|
||||
* *g* - Prints the information contained in the header of the file;
|
||||
* *c* or *f* - Prints messages generated during the loading of the STEP file (when the procedure of the integrity of the loaded data check is performed) and the resulting statistics (f works only with fails while c with both fail and warning messages) ;
|
||||
* *t* - The same as *c* or *f*, with a list of failed or warned entities;
|
||||
* *m* or *l* - The same as *t* but also prints a status for each entity;
|
||||
* *e* - Lists all entities of the model with their numbers, types, validity status etc.
|
||||
* *R* - The same as e but lists only root entities
|
||||
* *g* -- Prints the information contained in the header of the file;
|
||||
* *c* or *f* -- Prints messages generated during the loading of the STEP file (when the procedure of the integrity of the loaded data check is performed) and the resulting statistics (f works only with fails while c with both fail and warning messages) ;
|
||||
* *t* -- The same as *c* or *f*, with a list of failed or warned entities;
|
||||
* *m* or *l* -- The same as *t* but also prints a status for each entity;
|
||||
* *e* -- Lists all entities of the model with their numbers, types, validity status etc;
|
||||
* *R* -- The same as e but lists only root entities.
|
||||
|
||||
There is a set of special objects, which can be used to operate with a loaded model. They can be of the following types:
|
||||
* Selection Filters - allow selecting subsets of entities of the loaded model;
|
||||
* Counter - calculates some statistics on the model data.
|
||||
* Selection Filters -- allow selecting subsets of entities of the loaded model;
|
||||
* Counter -- calculates some statistics on the model data.
|
||||
|
||||
A list of these objects defined in the current session can be printed in DRAW by command @code Draw:> listitems. @endcode
|
||||
|
||||
@ -1300,8 +1300,8 @@ Draw:> listcount <counter> [<selection>]
|
||||
The former only prints a count of entities while the latter also gives a list of them.
|
||||
|
||||
The optional selection argument, if specified, defines a subset of entities, which are to be taken into account. The first argument should be one of the currently defined counters:
|
||||
* *xst-types* - calculates how many entities of each OCCT type exist
|
||||
* *step214-types* - calculates how many entities of each STEP type exist
|
||||
* *xst-types* -- calculates how many entities of each OCCT type exist
|
||||
* *step214-types* -- calculates how many entities of each STEP type exist
|
||||
|
||||
Entities in the STEP file are numbered in the succeeding order. An entity can be identified either by its number or by its label. Label is the letter \# followed by the rank.
|
||||
* *Draw:> elab \#* outputs a label for an entity with a known number.
|
||||
@ -1317,17 +1317,17 @@ All the following commands are available only after data is converted into OCCT
|
||||
|
||||
Command *Draw:> tpstat [*|?]\<symbol\> [\<selection\>]* is provided to get all statistics on the last transfer, including a list of transferred entities with mapping from STEP to OCCT types, as well as fail and warning messages. The parameter <i>\<symbol\></i> defines what information will be printed:
|
||||
|
||||
* *g* - General statistics (a list of results and messages)
|
||||
* *c* - Count of all warning and fail messages
|
||||
* *C* - List of all warning and fail messages
|
||||
* *f* - Count of all fail messages
|
||||
* *F* - List of all fail messages
|
||||
* *n* - List of all transferred roots
|
||||
* *s* - The same, with types of source entity and the type of result
|
||||
* *b* - The same, with messages
|
||||
* *t* - Count of roots for geometrical types
|
||||
* *r* - Count of roots for topological types
|
||||
* *l* - The same, with the type of the source entity
|
||||
* *g* -- General statistics (a list of results and messages)
|
||||
* *c* -- Count of all warning and fail messages
|
||||
* *C* -- List of all warning and fail messages
|
||||
* *f* -- Count of all fail messages
|
||||
* *F* -- List of all fail messages
|
||||
* *n* -- List of all transferred roots
|
||||
* *s* -- The same, with types of source entity and the type of result
|
||||
* *b* -- The same, with messages
|
||||
* *t* -- Count of roots for geometrical types
|
||||
* *r* -- Count of roots for topological types
|
||||
* *l* -- The same, with the type of the source entity
|
||||
|
||||
The sign \* before parameters *n, s, b, t, r* makes it work on all entities (not only on roots).
|
||||
|
||||
@ -1351,10 +1351,10 @@ To get information on tolerances of the shape use command <i>Draw:> tolerance \<
|
||||
When specifying min and max arguments this command saves shapes with tolerances in the range [min, max] with names shape_name_... and gives their total number.
|
||||
|
||||
<i>\<Symbol\></i> is used for specifying the kind of sub-shapes to analyze:
|
||||
* *v* - for vertices,
|
||||
* *e* - for edges,
|
||||
* *f* - for faces,
|
||||
* *c* - for shells and faces.
|
||||
* *v* -- for vertices,
|
||||
* *e* -- for edges,
|
||||
* *f* -- for faces,
|
||||
* *c* -- for shells and faces.
|
||||
|
||||
@subsection occt_step_6_5 Writing a STEP file
|
||||
For writing shapes to a STEP file, the following parameters are defined (see above, @ref occt_step_6_2 "the command *param*"):
|
||||
@ -1372,13 +1372,13 @@ Draw:> stepwrite <mode> <shape_name> [<file_name>]
|
||||
~~~~~
|
||||
|
||||
The following modes are available :
|
||||
* *a* - as is - the mode is selected automatically depending on the type & geometry of the shape;
|
||||
* *m* - *manifold_solid_brep* or *brep_with_voids*
|
||||
* *f* - *faceted_brep*
|
||||
* *w* - *geometric_curve_set*
|
||||
* *s* - *shell_based_surface_model*
|
||||
* *a* -- "as is" -- the mode is selected automatically depending on the type & geometry of the shape;
|
||||
* *m* -- *manifold_solid_brep* or *brep_with_voids*
|
||||
* *f* -- *faceted_brep*
|
||||
* *w* -- *geometric_curve_set*
|
||||
* *s* -- *shell_based_surface_model*
|
||||
|
||||
After a successful translation, if file_name parameter is not specified, the procedure asks you whether to write a STEP model in the file or not:
|
||||
After a successful translation, if *file_name* parameter is not specified, the procedure asks you whether to write a STEP model in the file or not:
|
||||
~~~~~
|
||||
execution status : 1
|
||||
Mode (0 end, 1 file) :
|
||||
|
||||
@ -15,7 +15,7 @@ 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 re-generating the schema.
|
||||
* Persistence mechanism for storing *TObj* objects in OCAF files, which allows storing and retrieving objects of derived types without regenerating the schema.
|
||||
|
||||
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.
|
||||
@ -25,7 +25,7 @@ of TObj-based data models and typical approaches to implementation of classes re
|
||||
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 re-develop such functionality from scratch.
|
||||
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
|
||||
@ -592,7 +592,7 @@ 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_35 Names of objects
|
||||
@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
|
||||
@ -632,7 +632,7 @@ Attributes a new name to the object and returns **True** if the name has been at
|
||||
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_36 References between objects
|
||||
@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
|
||||
@ -711,7 +711,7 @@ Updates back references if theUpdateackRefs is **True**.
|
||||
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,
|
||||
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**)
|
||||
|
||||
@ -743,9 +743,9 @@ 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.
|
||||
* **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:
|
||||
|
||||
@ -803,11 +803,11 @@ 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.
|
||||
* *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:
|
||||
@ -883,18 +883,18 @@ Sets the last reserved index.
|
||||
|
||||
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.
|
||||
* *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:
|
||||
|
||||
@ -906,10 +906,10 @@ The structure of *TObj* iterators hierarchy is presented below:
|
||||
|
||||
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* – plugin 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
|
||||
* *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
|
||||
|
||||
|
||||
|
||||
@ -16,10 +16,10 @@ This document describes both scenarios of VIS integration into application. To u
|
||||
@section occt_vis_2 Component Architecture
|
||||
@subsection occt_vis_2_1 Common structure
|
||||
VIS component consists of the following packages:
|
||||
* **IVtk** – common interfaces which define the principal objects playing as foundation of VIS.
|
||||
* **IVtkOCC** – implementation of interfaces related to CAD domain. The classes from this package deal with topological shapes, faceting and interactive selection facilities of OCCT;
|
||||
* **IVtkVTK** – implementation of interfaces related to VTK visualization toolkit;
|
||||
* **IVtkTools** – high-level tools designed for integration into VTK visualization pipelines.
|
||||
* **IVtk** -- common interfaces which define the principal objects playing as foundation of VIS.
|
||||
* **IVtkOCC** -- implementation of interfaces related to CAD domain. The classes from this package deal with topological shapes, faceting and interactive selection facilities of OCCT;
|
||||
* **IVtkVTK** -- implementation of interfaces related to VTK visualization toolkit;
|
||||
* **IVtkTools** -- high-level tools designed for integration into VTK visualization pipelines.
|
||||
|
||||
@figure{/user_guides/vis/images/vis_image002.png "Dependencies of VIS packages"}
|
||||
|
||||
@ -35,36 +35,37 @@ Basically, it is enough to use the first three packages in the end user’s appl
|
||||
|
||||
@subsection occt_vis_2_2 IVtk package
|
||||
**IVtk** package contains the following classes:
|
||||
* *IVtk_Interface* - Base class for all interfaces of the component. Provides inheritance for *Handle* (OCCT “smart pointer”) functionality.
|
||||
* *IVtk_IShape* - Represents a 3D shape of arbitrary nature. Provides its ID property. Implementation of this interface should maintain unique IDs for all visualized shapes. These IDs can be easily converted into original shape objects at the application level.
|
||||
* *IVtk_IShapeData* - Represents faceted data. Provides methods for adding coordinates and cells (vertices, lines, triangles).
|
||||
* *IVtk_IShapeMesher* - Interface for faceting, i.e. constructing *IVtk_IShapeData* from *IVtk_IShape* input shape.
|
||||
* *IVtk_IShapePickerAlgo* - Algorithmic interface for interactive picking of shapes in a scene. Provides methods for finding shapes and their parts (sub-shapes) at a given location according to the chosen selection mode.
|
||||
* *IVtk_IView* Interface for obtaining view transformation parameters. It is used by *IVtk_IShapePickerAlgo*.
|
||||
* *IVtk_Interface* -- Base class for all interfaces of the component. Provides inheritance for *Handle* (OCCT “smart pointer”) functionality.
|
||||
* *IVtk_IShape* -- Represents a 3D shape of arbitrary nature. Provides its ID property. Implementation of this interface should maintain unique IDs for all visualized shapes. These IDs can be easily converted into original shape objects at the application level.
|
||||
* *IVtk_IShapeData* -- Represents faceted data. Provides methods for adding coordinates and cells (vertices, lines, triangles).
|
||||
* *IVtk_IShapeMesher* -- Interface for faceting, i.e. constructing *IVtk_IShapeData* from *IVtk_IShape* input shape.
|
||||
* *IVtk_IShapePickerAlgo* -- Algorithmic interface for interactive picking of shapes in a scene. Provides methods for finding shapes and their parts (sub-shapes) at a given location according to the chosen selection mode.
|
||||
* *IVtk_IView* -- Interface for obtaining view transformation parameters. It is used by *IVtk_IShapePickerAlgo*.
|
||||
|
||||
@subsection occt_vis_2_3 IVtkOCC package
|
||||
|
||||
**IVtkOCC** package contains the implementation of classes depending on OCCT:
|
||||
* *IVtkOCC_Shape* - Implementation of *IVtk_IShape* interface as a wrapper for *TopoDS_Shape*.
|
||||
* *IVtkOCC_ShapeMesher* - Implementation of *IVtk_IShapeMesher* interface for construction of facets from *TopoDS* shapes.
|
||||
* *IVtkOCC_ShapePickerAlgo* Implementation of interactive picking algorithm. It provides enabling/disabling of selection modes for shapes (*IVtk_IShape* instances) and picking facilities for a given position of cursor.
|
||||
* *IVtkOCC_ViewerSelector* - Interactive selector, which implements *Pick()* methods for the picking algorithm *IVtkOCC_ShapePickerAlgo* and connects to the visualization layer with help of abstract *IView* interface.
|
||||
* *IVtkOCC_Shape* -- Implementation of *IVtk_IShape* interface as a wrapper for *TopoDS_Shape*.
|
||||
* *IVtkOCC_ShapeMesher* -- Implementation of *IVtk_IShapeMesher* interface for construction of facets from *TopoDS* shapes.
|
||||
* *IVtkOCC_ShapePickerAlgo* -- Implementation of interactive picking algorithm. It provides enabling/disabling of selection modes for shapes (*IVtk_IShape* instances) and picking facilities for a given position of cursor.
|
||||
* *IVtkOCC_ViewerSelector* -- Interactive selector, which implements *Pick()* methods for the picking algorithm *IVtkOCC_ShapePickerAlgo* and connects to the visualization layer with help of abstract *IView* interface.
|
||||
|
||||
*IVtkOCC_ViewerSelector* is a descendant of OCCT native *SelectMgr_ViewerSelector*, so it implements OCCT selection mechanism for *IVtkVTK_View* (similarly to *StdSelect_ViewerSelector3D* which implements *SelectMgr_ViewerSelector* for OCCT native *V3d_View*). *IVtkOCC_ViewerSelector* encapsulates all projection transformations for the picking mechanism. These transformations are extracted from *vtkCamera* instance available via VTK Renderer. *IVtkOCC_ViewerSelector* operates with native OCCT *SelectMgr_Selection* entities. Each entity represents one selection mode of an OCCT selectable object. *ViewerSelector* is an internal class, so it is not a part of the public API.
|
||||
* *IVtkOCC_SelectableObject* - OCCT shape wrapper used in the picking algorithm for computation of selection primitives of a shape for a chosen selection mode.
|
||||
|
||||
* *IVtkOCC_SelectableObject* -- OCCT shape wrapper used in the picking algorithm for computation of selection primitives of a shape for a chosen selection mode.
|
||||
|
||||
@subsection occt_vis_2_4 IVtkVtk package
|
||||
**IVtkVTK** package contains implementation classes depending on VTK:
|
||||
* *IVtkVTK_ShapeData* - Implementation of *IVtk_IShapeData* interface for VTK polydata. This class also stores information related to sub-shape IDs and sub-shape mesh type *IVtk_MeshType* (free vertex, shared vertex, free edge, boundary edge, shared edge, wireframe face or shaded face). This information is stored in VTK data arrays for cells.
|
||||
* *IVtkVTK_View* - Implementation of *IVtk_IView* interface for VTK viewer. This implementation class is used to connect *IVtkOCC_ViewerSelector* to VTK renderer.
|
||||
**IVtkVTK** package contains implementation of classes depending on VTK:
|
||||
* *IVtkVTK_ShapeData* -- Implementation of *IVtk_IShapeData* interface for VTK polydata. This class also stores information related to sub-shape IDs and sub-shape mesh type *IVtk_MeshType* (free vertex, shared vertex, free edge, boundary edge, shared edge, wireframe face or shaded face). This information is stored in VTK data arrays for cells.
|
||||
* *IVtkVTK_View* -- Implementation of *IVtk_IView* interface for VTK viewer. This implementation class is used to connect *IVtkOCC_ViewerSelector* to VTK renderer.
|
||||
|
||||
@subsection occt_vis_2_5 IVtkTools package
|
||||
**IVtkTools** package gives you a ready-to-use toolbox of algorithms facilitating the integration of OCCT shapes into visualization pipeline of VTK. This package contains the following classes:
|
||||
* *IVtkTools_ShapeDataSource* - VTK polygonal data source for OCCT shapes. It inherits *vtkPolyDataAlgorithm* class and provides a faceted representation of OCCT shape for visualization pipelines.
|
||||
* *IVtkTools_ShapeObject* - Auxiliary wrapper class for OCCT shapes to pass them through pipelines by means of VTK information keys.
|
||||
* *IVtkTools_ShapePicker* - VTK picker for shape actors. Uses OCCT selection algorithm internally.
|
||||
* *IVtkTools_DisplayModeFilter* - VTK filter for extracting cells of a particular mesh type according to a given display mode *IVtk_DisplayMode* (Wireframe or Shading).
|
||||
* *IVtkTools_SubPolyDataFilter* - VTK filter for extracting the cells corresponding to a given set of sub-shape IDs.
|
||||
* *IVtkTools_ShapeDataSource* -- VTK polygonal data source for OCCT shapes. It inherits *vtkPolyDataAlgorithm* class and provides a faceted representation of OCCT shape for visualization pipelines.
|
||||
* *IVtkTools_ShapeObject* -- Auxiliary wrapper class for OCCT shapes to pass them through pipelines by means of VTK information keys.
|
||||
* *IVtkTools_ShapePicker* -- VTK picker for shape actors. Uses OCCT selection algorithm internally.
|
||||
* *IVtkTools_DisplayModeFilter* -- VTK filter for extracting cells of a particular mesh type according to a given display mode *IVtk_DisplayMode* (Wireframe or Shading).
|
||||
* *IVtkTools_SubPolyDataFilter* -- VTK filter for extracting the cells corresponding to a given set of sub-shape IDs.
|
||||
|
||||
Additionally, *IVtkTools* package contains auxiliary methods in *IVtkTools* namespace. E.g. there is a convenience function populating *vtkLookupTable* instances to set up a color scheme for better visualization of sub-shapes.
|
||||
|
||||
@ -259,7 +260,7 @@ DS->SetShape(shapeImpl);
|
||||
// Create a new sub-polydata filter for sub-shapes filtering
|
||||
vtkSmartPointer<IVtkTools_SubPolyDataFilter> subShapesFilter = IVtkTools_SubPolyDataFilter::New();
|
||||
|
||||
// Set a shape source as an input of the subpolydata filter
|
||||
// Set a shape source as an input of the sub-polydata filter
|
||||
subShapesFilter->SetInputConnection(DS->GetOutputPort());
|
||||
|
||||
// Get all picked sub-shapes ids of the shape from a picker (see 3.4)
|
||||
@ -309,8 +310,8 @@ vtkPolyData* aPolyData = aDataImpl->GetVtkPolyData();
|
||||
|
||||
The resulting *vtkPolyData* instance can be used for initialization of VTK pipelines.
|
||||
*IVtkVTK_ShapeData* object is used to keep and pass the mapping between sub-shapes, their mesh types and the resulting mesh cells through a pipeline. It stores sub-shape IDs and mesh type in VTK data arrays for each generated cell. As a result, the generated VTK cells get the following data arrays populated:
|
||||
* *SUBSHAPE_IDS* – array of *vtkIdTypeArray* type. It contains the shape IDs the corresponding cells were generated for. The name of this array is defined in *ARRNAME_SUBSHAPE_IDS* constant of *IVtkVTK_ShapeData* class.
|
||||
* *MESH_TYPES* – array of *vtkShortArray type*. It contains the type tags of the shape parts the corresponding cells were generated for. The name of this array is defined in *ARRNAME_MESH_TYPES* constant of *IVtkVTK_ShapeData* class.
|
||||
* *SUBSHAPE_IDS* - array of *vtkIdTypeArray* type. It contains the shape IDs the corresponding cells were generated for. The name of this array is defined in *ARRNAME_SUBSHAPE_IDS* constant of *IVtkVTK_ShapeData* class.
|
||||
* *MESH_TYPES* - array of *vtkShortArray type*. It contains the type tags of the shape parts the corresponding cells were generated for. The name of this array is defined in *ARRNAME_MESH_TYPES* constant of *IVtkVTK_ShapeData* class.
|
||||
|
||||
@subsection occt_vis_4_2 Usage of OCCT picking algorithm
|
||||
|
||||
@ -362,5 +363,5 @@ IVtk_ShapeIdList subShapeIds
|
||||
@section occt_vis_5 DRAW Test Harness
|
||||
|
||||
*TKIVtkDraw* toolkit contains classes for embedding VIS functionality into DRAW Test Harness with possibility of simple interactions, including detection and highlighting.
|
||||
* *IVtkDraw_HighlightAndSelectionPipeline* - Creates VTK pipeline with OCCT shape data source and properly initialized VIS filters.
|
||||
* *IVtkDraw_Interactor* - Controls simple interactive actions, such as detection and selection of the displayed shapes.
|
||||
* *IVtkDraw_HighlightAndSelectionPipeline* -- Creates VTK pipeline with OCCT shape data source and properly initialized VIS filters.
|
||||
* *IVtkDraw_Interactor* -- Controls simple interactive actions, such as detection and selection of the displayed shapes.
|
||||
|
||||
@ -5,8 +5,8 @@ Visualization {#occt_user_guides__visualization}
|
||||
@section occt_visu_1 Introduction
|
||||
|
||||
Visualization in Open CASCADE Technology is based on the separation of:
|
||||
* on the one hand - the data which stores the geometry and topology of the entities you want to display and select, and
|
||||
* on the other hand - its **presentation** (what you see when an object is displayed in a scene) and **selection** (possibility to choose the whole object or its sub-parts interactively to apply application-defined operations to the selected entities).
|
||||
* on the one hand -- the data which stores the geometry and topology of the entities you want to display and select, and
|
||||
* on the other hand -- its **presentation** (what you see when an object is displayed in a scene) and **selection** (possibility to choose the whole object or its sub-parts interactively to apply application-defined operations to the selected entities).
|
||||
|
||||
Presentations are managed through the **Presentation** component, and selection through the **Selection** component.
|
||||
|
||||
@ -34,7 +34,7 @@ The figure below presents a schematic overview of the relations between the key
|
||||
To answer different needs of CASCADE users, this User's Guide offers the following three paths in reading it.
|
||||
|
||||
* If the 3D services proposed in AIS meet your requirements, you need only read chapter 3 @ref occt_visu_3 "AIS: Application Interactive Services".
|
||||
* If you need more detail, for example, a selection filter on another type of entity - you should read 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.
|
||||
* If you need more detail, for example, a selection filter on another type of entity -- you should read 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="http://www.opencascade.com/content/tutorial-learning">E-learning & Training</a> offerings.
|
||||
|
||||
@ -565,7 +565,7 @@ The calculation of Selection primitives (or sensitive primitives) is done by th
|
||||
|
||||
A detailed explanation of the mechanism and the manner of implementing this function has been given in @ref occt_visu_3_6 "Dynamic Selection" chapter.
|
||||
|
||||
Moreover, just as the most frequently manipulated entity is *TopoDS_Shape*, the most used Interactive Object is *AIS_Shape*. You will see below activation functions for standard selection modes are proposed in the Interactive context (selection by vertex, by edges etc). To create new classes of interactive object with the same behavior as *AIS_Shape* - such as vertices and edges - you must redefine the virtual function *AIS_ConnectedInteractive::AcceptShapeDecomposition*.
|
||||
Moreover, just as the most frequently manipulated entity is *TopoDS_Shape*, the most used Interactive Object is *AIS_Shape*. You will see below activation functions for standard selection modes are proposed in the Interactive context (selection by vertex, by edges etc). To create new classes of interactive object with the same behavior as *AIS_Shape* -- such as vertices and edges -- you must redefine the virtual function *AIS_ConnectedInteractive::AcceptShapeDecomposition*.
|
||||
|
||||
You can change the default selection mode index of an Interactive Object using the following functions:
|
||||
* *AIS_InteractiveObject::HasSelectionMode* checks if there is a selection mode;
|
||||
@ -667,7 +667,7 @@ Negative offset values move polygons closer to the viewer while positive values
|
||||
|
||||
**Warning**
|
||||
|
||||
This method has a side effect - it creates its own shading aspect if not yet created, so it is better to set up the object shading aspect first.
|
||||
This method has a side effect -- it creates its own shading aspect if not yet created, so it is better to set up the object shading aspect first.
|
||||
|
||||
You can use the following functions to obtain the current settings for polygon offsets:
|
||||
~~~~~
|
||||
@ -900,12 +900,12 @@ virtual Standard_Boolean MyFilter::IsOk
|
||||
In *SelectMgr*, there are also Composition filters (AND Filters, OR Filters), which allow combining several filters. In InteractiveContext , all filters that you add are stocked in an OR filter (which answers *OK* if at least one filter answers *OK*).
|
||||
|
||||
There are Standard filters, which have already been implemented in several packages:
|
||||
* *StdSelect_EdgeFilter* - for edges, such as lines and circles;
|
||||
* *StdSelect_FaceFilter* - for faces, such as planes, cylinders and spheres;
|
||||
* *StdSelect_ShapeTypeFilter* - for shape types, such as compounds, solids, shells and wires;
|
||||
* *AIS_TypeFilter* - for types of interactive objects;
|
||||
* *AIS_SignatureFilter* - for types and signatures of interactive objects;
|
||||
* *AIS_AttributeFilter* - for attributes of Interactive Objects, such as color and width.
|
||||
* *StdSelect_EdgeFilter* -- for edges, such as lines and circles;
|
||||
* *StdSelect_FaceFilter* -- for faces, such as planes, cylinders and spheres;
|
||||
* *StdSelect_ShapeTypeFilter* -- for shape types, such as compounds, solids, shells and wires;
|
||||
* *AIS_TypeFilter* -- for types of interactive objects;
|
||||
* *AIS_SignatureFilter* -- for types and signatures of interactive objects;
|
||||
* *AIS_AttributeFilter* -- for attributes of Interactive Objects, such as color and width.
|
||||
|
||||
As there are specific behaviors on shapes, each new *Filter* class must, if necessary, redefine *AIS_LocalContext::ActsOn* function, which informs the Local Context if it acts on specific types of sub-shapes. By default, this function answers *FALSE*.
|
||||
|
||||
@ -950,11 +950,11 @@ myContext->MoveTo( xpix,ypix,Vue);
|
||||
@subsubsection occt_visu_3_4_6 Selection in the Local Context
|
||||
|
||||
Dynamic detection and selection are put into effect in a straightforward way. There are only a few conventions and functions to be familiar with. The functions are the same in neutral point and in open local context:
|
||||
* *AIS_InteractiveContext::MoveTo* - passes mouse position to Interactive Context selectors
|
||||
* *AIS_InteractiveContext::Select* - stocks what has been detected on the last *MoveTo*. Replaces the previously selected object. Empties the stack if nothing has been detected at the last move
|
||||
* *AIS_InteractiveContext::ShiftSelect* - if the object detected at the last move was not already selected, it is added to the list of the selected objects. If not, it is withdrawn. Nothing happens if you click on an empty area.
|
||||
* *AIS_InteractiveContext::Select* selects everything found in the surrounding area.
|
||||
* *AIS_InteractiveContext::ShiftSelect* selects what was not previously in the list of selected, deselects those already present.
|
||||
* *AIS_InteractiveContext::MoveTo* -- passes mouse position to Interactive Context selectors
|
||||
* *AIS_InteractiveContext::Select* -- stocks what has been detected on the last *MoveTo*. Replaces the previously selected object. Empties the stack if nothing has been detected at the last move
|
||||
* *AIS_InteractiveContext::ShiftSelect* -- if the object detected at the last move was not already selected, it is added to the list of the selected objects. If not, it is withdrawn. Nothing happens if you click on an empty area.
|
||||
* *AIS_InteractiveContext::Select* -- selects everything found in the surrounding area.
|
||||
* *AIS_InteractiveContext::ShiftSelect* -- selects what was not previously in the list of selected, deselects those already present.
|
||||
|
||||
Highlighting of detected and selected entities is automatically managed by the Interactive Context, whether you are in neutral point or Local Context. The Highlight colors are those dealt with above. You can nonetheless disconnect this automatic mode if you want to manage this part yourself :
|
||||
~~~~~
|
||||
@ -1194,10 +1194,10 @@ myCtx->CloseLocalContext(myIndex);
|
||||
Interactive Objects are selectable and viewable objects connecting graphic representation and the underlying reference geometry.
|
||||
|
||||
They are divided into four types:
|
||||
* the **Datum** - a construction geometric element;
|
||||
* the **Relation** - a constraint on the interactive shape and the corresponding reference geometry;
|
||||
* the **Object** - a topological shape or connection between shapes;
|
||||
* **None** a token, that instead of eliminating the object, tells the application to look further until it finds an acceptable object definition in its generation.
|
||||
* the **Datum** -- a construction geometric element;
|
||||
* the **Relation** -- a constraint on the interactive shape and the corresponding reference geometry;
|
||||
* the **Object** -- a topological shape or connection between shapes;
|
||||
* **None** -- a token, that instead of eliminating the object, tells the application to look further until it finds an acceptable object definition in its generation.
|
||||
|
||||
Inside these categories, there is a possibility of additional characterization by means of a signature. The signature provides an index to the further characterization. By default, the **Interactive Object** has a *None* type and a signature of 0 (equivalent to *None*).
|
||||
If you want to give a particular type and signature to your interactive object, you must redefine the two virtual methods: <i>Type</i> and <i>Signature</i>.
|
||||
@ -1220,7 +1220,7 @@ when you activate one of modes: 1 2 3 4, you pick AIS objects of type:
|
||||
*AIS_PlaneTrihedron* offers three selection modes:
|
||||
* mode 0 : selection of the whole trihedron;
|
||||
* mode 1 : selection of the origin of the trihedron;
|
||||
* mode 2 : selection of the axes - same remarks as for the Trihedron.
|
||||
* mode 2 : selection of the axes -- same remarks as for the Trihedron.
|
||||
|
||||
For the presentation of planes and trihedra, the default unit of length is millimeter, and the default value for the representation of axes is 100. If you modify these dimensions, you must temporarily recover the object **Drawer**. From it, take the *Aspects* in which the values for length are stored (*PlaneAspect* for the plane, *FirstAxisAspect* for trihedra), and change these values inside these Aspects. Finally, recalculate the presentation.
|
||||
|
||||
@ -1321,7 +1321,7 @@ The list of relations is not exhaustive.
|
||||
|
||||
*MeshVS_Mesh* is an Interactive Object that represents meshes. This object differs from the *AIS_Shape* as its geometrical data is supported by the data source *MeshVS_DataSource* that describes nodes and elements of the object. As a result, you can provide your own data source.
|
||||
|
||||
However, the *DataSource* does not provide any information on attributes, for example nodal colors, but you can apply them in a special way - by choosing the appropriate presentation builder.
|
||||
However, the *DataSource* does not provide any information on attributes, for example nodal colors, but you can apply them in a special way -- by choosing the appropriate presentation builder.
|
||||
|
||||
The presentations of *MeshVS_Mesh* are built with the presentation builders *MeshVS_PrsBuilder*. You can choose between the builders to represent the object in a different way. Moreover, you can redefine the base builder class and provide your own presentation builder.
|
||||
|
||||
@ -1369,9 +1369,9 @@ There is also a set of selection modes flags that can be grouped in a combinatio
|
||||
* *MeshVS_SMF_Link*
|
||||
* *MeshVS_SMF_Face*
|
||||
* *MeshVS_SMF_Volume*
|
||||
* *MeshVS_SMF_Element* - groups *0D, Link, Face* and *Volume* as a bit mask ;
|
||||
* *MeshVS_SMF_Element* -- groups *0D, Link, Face* and *Volume* as a bit mask ;
|
||||
* *MeshVS_SMF_Node*
|
||||
* *MeshVS_SMF_All* - groups *Element* and *Node* as a bit mask;
|
||||
* *MeshVS_SMF_All* -- groups *Element* and *Node* as a bit mask;
|
||||
* *MeshVS_SMF_Mesh*
|
||||
* *MeshVS_SMF_Group*
|
||||
|
||||
@ -1540,15 +1540,15 @@ for(VS->Init();VS->More();VS->Next())
|
||||
|
||||
* **Anti-aliasing** This mode attempts to improve the screen resolution by drawing lines and curves in a mixture of colors so that to the human eye the line or curve is smooth. The quality of the result is linked to the quality of the algorithm used by the workstation hardware.
|
||||
* **Depth-cueing** Reduces the color intensity for the portion of an object further away from the eye to give the impression of depth. This is used for wireframe objects. Shaded objects do not require this.
|
||||
* **Group** - a set of primitives and attributes on those primitives. Primitives and attributes may be added to a group but cannot be removed from a group, except by erasing them globally. A group can have a pick identity.
|
||||
* **Light** There are five kinds of light source - ambient, headlight, directional, positional and spot. The light is only activated in a shading context in a view.
|
||||
* **Primitive** - a drawable element. It has a definition in 3D space. Primitives can either be lines, faces, text, or markers. Once displayed markers and text remain the same size. Lines and faces can be modified e.g. zoomed. Primitives must be stored in a group.
|
||||
* **Structure** - manages a set of groups. The groups are mutually exclusive. A structure can be edited, adding or removing groups. A structure can reference other structures to form a hierarchy. It has a default (identity) transformation and other transformations may be applied to it (rotation, translation, scale, etc). It has no default attributes for the primitive lines, faces, markers, and text. Attributes may be set in a structure but they are overridden by the attributes in each group. Each structure has a display priority associated with it, which rules the order in which it is redrawn in a 3D viewer. If the visualization mode is incompatible with the view it is not displayed in that view, e.g. a shading-only object is not visualized in a wireframe view.
|
||||
* **View** - is defined by a view orientation, a view mapping, and a context view.
|
||||
* **Viewer** - manages a set of views.
|
||||
* **View orientation** - defines the manner in which the observer looks at the scene in terms of View Reference Coordinates.
|
||||
* **View mapping** - defines the transformation from View Reference Coordinates to the Normalized Projection Coordinates. This follows the Phigs scheme.
|
||||
* **Z-Buffering** -= a form of hidden surface removal in shading mode only. This is always active for a view in the shading mode. It cannot be suppressed.
|
||||
* **Group** -- a set of primitives and attributes on those primitives. Primitives and attributes may be added to a group but cannot be removed from it, unless erased globally. A group can have a pick identity.
|
||||
* **Light** There are five kinds of light source -- ambient, headlight, directional, positional and spot. The light is only activated in a shading context in a view.
|
||||
* **Primitive** -- a drawable element. It has a definition in 3D space. Primitives can either be lines, faces, text, or markers. Once displayed markers and text remain the same size. Lines and faces can be modified e.g. zoomed. Primitives must be stored in a group.
|
||||
* **Structure** -- manages a set of groups. The groups are mutually exclusive. A structure can be edited, adding or removing groups. A structure can reference other structures to form a hierarchy. It has a default (identity) transformation and other transformations may be applied to it (rotation, translation, scale, etc). It has no default attributes for the primitive lines, faces, markers, and text. Attributes may be set in a structure but they are overridden by the attributes in each group. Each structure has a display priority associated with it, which rules the order in which it is redrawn in a 3D viewer. If the visualization mode is incompatible with the view it is not displayed in that view, e.g. a shading-only object is not visualized in a wireframe view.
|
||||
* **View** -- is defined by a view orientation, a view mapping, and a context view.
|
||||
* **Viewer** -- manages a set of views.
|
||||
* **View orientation** -- defines the manner in which the observer looks at the scene in terms of View Reference Coordinates.
|
||||
* **View mapping** -- defines the transformation from View Reference Coordinates to the Normalized Projection Coordinates. This follows the Phigs scheme.
|
||||
* **Z-Buffering** -- a form of hidden surface removal in shading mode only. This is always active for a view in the shading mode. It cannot be suppressed.
|
||||
|
||||
@subsection occt_visu_4_2 Graphic primitives
|
||||
|
||||
@ -1579,23 +1579,23 @@ The root is the top of a structure hierarchy or structure network. The attribute
|
||||
* Have one closed boundary,
|
||||
* Have at least three vertices,
|
||||
* Are planar and have a normal,
|
||||
* Have interior attributes - style, color, front and back material, texture and reflection ratio,
|
||||
* Have a boundary with the following attributes - type, width scale factor, color. The boundary is only drawn when the interior style is hollow.
|
||||
* Have interior attributes -- style, color, front and back material, texture and reflection ratio,
|
||||
* Have a boundary with the following attributes -- type, width scale factor, color. The boundary is only drawn when the interior style is hollow.
|
||||
|
||||
* **Polygons with holes**
|
||||
* Have multiple closed boundaries, each one with at least three vertices,
|
||||
* Are planar and have a normal,
|
||||
* Have interior attributes - style, color, front and back material,
|
||||
* Have a boundary with the following attributes - type, width scale factor, color. The boundary is only drawn when the interior style is hollow.
|
||||
* Have interior attributes -- style, color, front and back material,
|
||||
* Have a boundary with the following attributes -- type, width scale factor, color. The boundary is only drawn when the interior style is hollow.
|
||||
|
||||
* **Polylines**
|
||||
* Have two or more vertices,
|
||||
* Have the following attributes - type, width scale factor, color.
|
||||
* Have the following attributes -- type, width scale factor, color.
|
||||
|
||||
* **Text**
|
||||
* Has geometric and non-geometric attributes,
|
||||
* Geometric attributes - character height, character up vector, text path, horizontal and vertical alignment, orientation, three-dimensional position, zoomable flag
|
||||
* Non-geometric attributes - text font, character spacing, character expansion factor, color.
|
||||
* Geometric attributes -- character height, character up vector, text path, horizontal and vertical alignment, orientation, three-dimensional position, zoomable flag
|
||||
* Non-geometric attributes -- text font, character spacing, character expansion factor, color.
|
||||
|
||||
@subsubsection occt_visu_4_2_4 Primitive arrays
|
||||
|
||||
@ -1843,9 +1843,9 @@ aGroup->Text (Standard_CString ("Text"), aPoint, 16.0);
|
||||
|
||||
A *Graphic3d_MaterialAspect* is defined by:
|
||||
* Transparency;
|
||||
* Diffuse reflection - a component of the object color;
|
||||
* Diffuse reflection -- a component of the object color;
|
||||
* Ambient reflection;
|
||||
* Specular reflection - a component of the color of the light source;
|
||||
* Specular reflection -- a component of the color of the light source;
|
||||
* Refraction index.
|
||||
|
||||
The following items are required to determine the three colors of reflection:
|
||||
@ -1977,7 +1977,7 @@ VM->Viewer()->Display();
|
||||
aView->Update();
|
||||
~~~~~
|
||||
|
||||
As an alternative to manual setting of perspective parameters the V3d_View::ZfitAll() and V3d_View::FitAll() functions can be used:
|
||||
As an alternative to manual setting of perspective parameters the *V3d_View::ZfitAll()* and *V3d_View::FitAll()* functions can be used:
|
||||
|
||||
~~~~~
|
||||
// Display shape in Viewer VM
|
||||
@ -1996,21 +1996,21 @@ V->FitAll();
|
||||
|
||||
View projection and orientation in OCCT *v3d* view are driven by camera. The camera calculates and supplies projection and view orientation matrices for rendering by OpenGL. The allows to the user to control all projection parameters. The camera is defined by the following properties:
|
||||
|
||||
* **Eye** - Defines the observer (camera) position. Make sure the Eye point never gets between the Front and Back clipping planes.
|
||||
* **Eye** -- defines the observer (camera) position. Make sure the Eye point never gets between the Front and Back clipping planes.
|
||||
|
||||
* **Center** - defines the origin of View Reference Coordinates (where camera is aimed at).
|
||||
* **Center** -- defines the origin of View Reference Coordinates (where camera is aimed at).
|
||||
|
||||
* **Direction** - defines the direction of camera view (from the Eye to the Center).
|
||||
* **Direction** -- defines the direction of camera view (from the Eye to the Center).
|
||||
|
||||
* **Distance** - defines the distance between the Eye and the Center.
|
||||
* **Distance** -- defines the distance between the Eye and the Center.
|
||||
|
||||
* **Front** Plane - Defines the position of the front clipping plane in View Reference Coordinates system.
|
||||
* **Front** Plane -- defines the position of the front clipping plane in View Reference Coordinates system.
|
||||
|
||||
* **Back** Plane - Defines the position of the back clipping plane in View Reference Coordinates system.
|
||||
* **Back** Plane -- defines the position of the back clipping plane in View Reference Coordinates system.
|
||||
|
||||
* **ZNear** - defines the distance between the Eye and the Front plane.
|
||||
* **ZNear** -- defines the distance between the Eye and the Front plane.
|
||||
|
||||
* **ZFar** - defines the distance between the Eye and the Back plane.
|
||||
* **ZFar** -- defines the distance between the Eye and the Back plane.
|
||||
|
||||
Most common view manipulations (panning, zooming, rotation) are implemented as convenience methods of *V3d_View* class, however *Graphic3d_Camera* class can also be used directly by application developers:
|
||||
|
||||
@ -2038,7 +2038,7 @@ aView->Update();
|
||||
|
||||
@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).
|
||||
|
||||
@image html camera_perspective.png "Perspective frustum"
|
||||
|
||||
@ -2054,15 +2054,15 @@ aView->Update();
|
||||
|
||||
@subsubsection occt_visu_4_4_6 Stereographic Projection
|
||||
|
||||
**IOD** - defines the intraocular distance (in world space units).
|
||||
**IOD** -- defines the intraocular distance (in world space units).
|
||||
|
||||
There are two types of IOD:
|
||||
* _IODType_Absolute_ : Intraocular distance is defined as an absolute value.
|
||||
* _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.
|
||||
**ZFocus** -- defines the distance to the point of stereographic focus.
|
||||
|
||||
@image html stereo.png "Stereographic projection"
|
||||
|
||||
@ -2261,10 +2261,10 @@ To set the image as a background and change the background image style you can
|
||||
~~~~~
|
||||
|
||||
The *FileName* parameter defines the image file name and the path to it, the *FillStyle* parameter defines the method of filling the background with the image. The methods are:
|
||||
* *Aspect_FM_NONE* - draws the image in the default position;
|
||||
* *Aspect_FM_CENTERED* - draws the image at the center of the view;
|
||||
* *Aspect_FM_TILED* tiles the view with the image;
|
||||
* *Aspect_FM_STRETCH* stretches the image over the view.
|
||||
* *Aspect_FM_NONE* -- draws the image in the default position;
|
||||
* *Aspect_FM_CENTERED* -- draws the image at the center of the view;
|
||||
* *Aspect_FM_TILED* -- tiles the view with the image;
|
||||
* *Aspect_FM_STRETCH* -- stretches the image over the view.
|
||||
|
||||
|
||||
@subsubsection occt_visu_4_4_10 Dumping a 3D scene into an image file
|
||||
|
||||
@ -20,9 +20,9 @@ The XDE component requires @ref occt_user_guides__shape_healing "Shape Healing"
|
||||
@subsection occt_xde_1_1 Basic terms
|
||||
|
||||
For better understanding of XDE, certain key terms are defined:
|
||||
* **Shape** - a standalone shape, which does not belong to the assembly structure.
|
||||
* **Instance** - a replication of another shape with a location that can be the same location or a different one.
|
||||
* **Assembly** - a construction that is either a root or a sub-assembly.
|
||||
* **Shape** -- a standalone shape, which does not belong to the assembly structure.
|
||||
* **Instance** -- a replication of another shape with a location that can be the same location or a different one.
|
||||
* **Assembly** -- a construction that is either a root or a sub-assembly.
|
||||
|
||||
@subsection occt_xde_1_2 XDE Organization
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user