user_guides/tobj/tobj.md
user_guides/shape_healing/shape_healing.md
user_guides/draw_test_harness/draw_test_harness.md
-user_guides/wok/wok.md
dev_guides/dev_guides.md
-dev_guides/wok/wok.md
dev_guides/cdl/cdl.md
dev_guides/tests/tests.md
dev_guides/documentation/documentation.md
+dev_guides/wok/wok.md
+dev_guides/building/building.md
+dev_guides/building/wok/wok.md
dev_guides/building/automake.md
dev_guides/building/cmake.md
dev_guides/building/code_blocks.md
### 11. Copyright
-The Initial Developer retains all rights, title and interest in and to the Original Code. You may not remove the copyright © notice which appears when You download the Software.
+The Initial Developer retains all rights, title and interest in and to the Original Code. You may not remove the copyright (c) notice which appears when You download the Software.
### 12. Term
The content of this file is subject to the Open CASCADE Technology Public License Version 6.5 (the "License").
You may not use the content of this file except in compliance with the License.
-Please obtain a copy of the License at http://www.opencascade.org and read it completely before using this file. The Initial Developer of the Original Code is Open CASCADE S.A.S., with main offices at 1, place des Frères Montgolfier, 78280 Guyancourt, France. The Original Code is copyright © Open CASCADE S.A.S., 2001. All rights reserved.
+Please obtain a copy of the License at http://www.opencascade.org and read it completely before using this file. The Initial Developer of the Original Code is Open CASCADE S.A.S., with main offices at 1, place des Frères Montgolfier, 78280 Guyancourt, France. The Original Code is copyright (c) Open CASCADE S.A.S., 2001. All rights reserved.
"The Original Code and all software distributed under the License are distributed on an "AS IS" basis, without warranty of any kind, and the Initial Developer hereby disclaims all such warranties, including without limitation, any warranties of merchantability, fitness for a particular purpose or non-infringement.
#### Schedule "B"
-"The content of this file is subject to the Open CASCADE Technology Public License Version 6.5 (the "License"). You may not use the content of this file except in compliance with the License. Please obtain a copy of the License at http://www.opencascade.org and read it completely before using this file. The Initial Developer of the Original Code is Open CASCADE S.A.S., with main offices at 1, place des Frères Montgolfier, 78280 Guyancourt, France. The Original Code is copyright © Open CASCADE S.A.S., 2001. All rights reserved.
+"The content of this file is subject to the Open CASCADE Technology Public License Version 6.5 (the "License"). You may not use the content of this file except in compliance with the License. Please obtain a copy of the License at http://www.opencascade.org and read it completely before using this file. The Initial Developer of the Original Code is Open CASCADE S.A.S., with main offices at 1, place des Frères Montgolfier, 78280 Guyancourt, France. The Original Code is copyright (c) Open CASCADE S.A.S., 2001. All rights reserved.
-Modifications to the Original Code have been made by ________________________. Modifications are copyright © [Year to be included]. All rights reserved.
+Modifications to the Original Code have been made by ________________________. Modifications are copyright (c) [Year to be included]. All rights reserved.
The software Open CASCADE Technology and all software distributed under the License are distributed on an "AS IS" basis, without warranty of any kind, and the Initial Developer hereby disclaims all such warranties, including without limitation, any warranties of merchantability, fitness for a particular purpose or non-infringement. Please see the License for the specific terms and conditions governing rights and limitations under the License".
@section OCCT_OVW_SECTION_1 Welcome
-Welcome to Open CASCADE Technology version 6.6.0, a minor release,
+Welcome to Open CASCADE Technology version 6.7.0, a minor release,
which introduces a number of new features and improved traditional
-functionality along with some changes over the previous maintenance release 6.5.5.
+functionality along with some changes over the previous release 6.6.0.
This release makes Open CASCADE Technology even a more powerful and stable
development platform for 3D modeling and numerical simulation applications.
-Open CASCADE Technology 6.6.0 is a full-featured package that allows developing
+Open CASCADE Technology 6.7.0 is a full-featured package that allows developing
applications on Windows and Linux platforms.
@htmlonly<center>@endhtmlonly http://www.opencascade.org
-
+@image html /overview/images/overview_occttransparent.png
+@image latex /overview/images/overview_occttransparent.png
-Copyright © 2001-2013 OPEN CASCADE S.A.S.
+Copyright (c) 2001-2013 OPEN CASCADE S.A.S.
-
+@image html /resources/occt_logo.png
+@image latex /resources/occt_logo.png
@htmlonly</center>@endhtmlonly
@section OCCT_OVW_SECTION_2 Copyrights
-Copyright© 2001-2013 by OPEN CASCADE S.A.S. All rights reserved.
+Copyright(c) 2001-2013 by OPEN CASCADE S.A.S. All rights reserved.
Trademark information
----------------------
FreeType 2 is released under two open-source licenses: BSD-like FreeType License and the GPL.
-**Intel® Threading Building Blocks (TBB)** offers a rich and complete approach to expressing parallelism in a C++ program.
+**Intel(R) Threading Building Blocks (TBB)** offers a rich and complete approach to expressing parallelism in a C++ program.
It is a library that helps you to take advantage of multi-core processor performance without having to be a threading expert.
Threading Building Blocks is not just a threads-replacement library. It represents a higher-level, task-based parallelism that
abstracts platform details and threading mechanisms for scalability and performance.
Open CASCADE Technology WOK module on Windows also makes use of LGPL-licensed C routines * regexp and getopt, taken from GNU C library.
-**Doxygen** (Copyright © 1997-2010 by Dimitri van Heesch) is open source documentation system for
+**Doxygen** (Copyright (c) 1997-2010 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
for automatic creation of Technical Documentation from C++ header files.
If you need further information on Doxygen, please refer to http://www.stack.nl/~dimitri/doxygen/index.html.
e.g., wgendoc –output=d:/occt/doc {–m=Draw Visualization} -chm
+@section OCCT_OVW_SECTION_5 Requirements
+
+@subsection OCCT_OVW_SECTION_5_1 Linux Intel
+<table>
+<tr> <th>Operating System </th> <th> 64-bit: Mandriva 2010, CentOS 5. 5, CentOS 6.3, Fedora 17, Fedora 18, Ubuntu-1304, Debian 6.0 * </th> </tr>
+<tr> <td> Minimum memory </td> <td> 512 Mb, 1 Gb recommended </td > </tr>
+<tr> <td> Free disk space (complete installation) </td> <td> For full installation Open CASCADE Technology requires 600 Mb of disk space. </td > </tr>
+<tr> <td>Minimum swap space </td> <td> 500 Mb </td > </tr>
+<tr> <td> Video card </td> <td> **GeForce** The following versions of GeForce drivers are recommended: 64-bit Version: 100.14.19 or later http://www.nvidia.com/object/linux_display_amd64_100.14.19.html 32-bit Version: 100.14.19 or later http://www.nvidia.com/object/linux_display_ia32_100.14.19.html </td > </tr>
+<tr> <td> Graphic library </td> <td> OpenGL 1.1+ (OpenGL 1.5+ is recommended) </td > </tr>
+<tr> <td>C++ </td> <td>GNU gcc 4.0. - 4.7.3. </td > </tr>
+<tr> <td> TCL (for testing tools) </td> <td> Tcltk 8.5 or 8.6 http://www.tcl.tk/software/tcltk/8.6.html</td > </tr>
+<tr> <td> Qt (for demonstration tools) </td> <td> Qt 4.6.2 http://qt.nokia.com/downloads </td > </tr>
+<tr> <td> Freetype (OCCT Text rendering) </td> <td> freetype-2.4.11 http://sourceforge.net/projects/freetype/files/ </td > </tr>
+<tr> <td> FreeImage (Support of common graphic formats) </td> <td>FreeImage 3.15.4 http://sourceforge.net/projects/freeimage/files/Source%20Distribution/ </td > </tr>
+<tr> <td> gl2ps (Export contents of OCCT viewer to vector graphic file) </td> <td> gl2ps-1.3.8 http://geuz.org/gl2ps/ </td > </tr>
+<tr> <td>TBB (optional tool for parallelized version of BRepMesh component) </td> <td> TBB 3.x or 4.x http://www.threadingbuildingblocks.org/ </td > </tr>
+<tr> <td> OpenCL (optional for providing ray tracing visualization core </td> <td>http://developer.amd.com/tools-and-sdks/heterogeneous-computing/amd-accelerated-parallel-processing-app-sdk/downloads/ </td> </tr>
+</table>
+\* Debian 60 64 bit is a permanently tested platform.
+
+@subsection OCCT_OVW_SECTION_5_2 Windows Intel
+
+<table>
+<tr> <th>Operating System </th> <th> 32/64-bit: 8/ 7 SP1 / VISTA SP2 /XP SP3 </th> </tr>
+<tr> <td> Minimum memory </td> <td> 512 Mb, 1 Gb recommended </td > </tr>
+<tr> <td> Free disk space (complete installation) </td> <td> For full installation Open CASCADE Technology requires 650 Mb of disk space but during the process of installation you will need 1,2 Gb of free disk space. </td > </tr>
+<tr> <td>Minimum swap space </td> <td> 500 Mb </td > </tr>
+<tr> <td> Video card </td> <td> **GeForce** Version 266.58 WHQL or later is recommended: http://www.nvidia.com/Download/index.aspx
+ </td > </tr>
+<tr> <td> Graphic library </td> <td> OpenGL 1.1+ (OpenGL 1.5+ is recommended) </td > </tr>
+<tr> <td>C++ </td> <td>Microsoft Visual Studio .NET 2005 SP1 with all security updates
+Microsoft Visual Studio .NET 2008 SP1*
+Microsoft Visual Studio .NET 2010
+Microsoft Visual Studio .NET 2012
+Microsoft Visual Studio .NET 2013
+ </td > </tr>
+<tr> <td> TCL (for testing tools) </td> <td> TActiveTcl 8.5 or 8.6
+http://www.activestate.com/activetcl/downloads </td > </tr>
+<tr> <td> Qt (for demonstration tools) </td> <td> Qt 4.6.2 http://qt.digia.com/downloads </td > </tr>
+<tr> <td> Freetype (OCCT Text rendering) </td> <td> freetype-2.4.11 http://sourceforge.net/projects/freetype/files/ </td > </tr>
+<tr> <td> FreeImage (Support of common graphic formats )</td> <td>FreeImage 3.15.4 http://sourceforge.net/projects/freeimage/files/Source%20Distribution/ </td > </tr>
+<tr> <td> gl2ps (Export contents of OCCT viewer to vector graphic file) </td> <td> gl2ps-1.3.8 http://geuz.org/gl2ps/ </td > </tr>
+<tr> <td>TBB (optional tool for parallelized version of BRepMesh component) </td> <td> TBB 3.x or 4.x http://www.threadingbuildingblocks.org/ </td > </tr>
+<tr> <td> OpenCL (optional for providing ray tracing visualization core </td> <td>http://developer.amd.com/tools-and-sdks/heterogeneous-computing/amd-accelerated-parallel-processing-app-sdk/downloads/ </td> </tr>
+</table>
+
+* The official release of OCCT for Windows contains libraries built with VC++ 2008.
+
+
+@subsection OCCT_OVW_SECTION_5_3 MAC OS X
+
+<table>
+<tr> <th>Operating System </th> <th> Mac OS X 10.6.8 Snow Leopard / 10.7 Lion </th> </tr>
+<tr> <td> Minimum memory </td> <td> 512 Mb, 1 Gb recommended </td > </tr>
+<tr> <td> Free disk space (complete installation) </td> <td> For full installation Open CASCADE Technology requires 600 Mb of disk space. </td > </tr>
+<tr> <td>Minimum swap space </td> <td> 500 Mb </td > </tr>
+<tr> <td> Video card </td> <td> **GeForce** Version 266.58 WHQL or later is recommended: http://www.nvidia.com/Download/index.aspx
+ </td > </tr>
+<tr> <td> Graphic library </td> <td> OpenGL 1.1+ (OpenGL 1.5+ is recommended) </td > </tr>
+<tr> <td>C++ </td> <td>XCode 3.2 or newer (4.x is recommended) </td > </tr>
+<tr> <td> Qt (for demonstration tools) </td> <td> Qt 4.6.2 http://qt.digia.com/downloads </td > </tr>
+<tr> <td> Freetype (OCCT Text rendering) </td> <td> freetype-2.4.11 http://sourceforge.net/projects/freetype/files/ </td > </tr>
+<tr> <td> FreeImage (Support of common graphic formats )</td> <td>FreeImage 3.15.4 http://sourceforge.net/projects/freeimage/files/Source%20Distribution/ </td > </tr>
+<tr> <td> gl2ps (Export contents of OCCT viewer to vector graphic file) </td> <td> gl2ps-1.3.8 http://geuz.org/gl2ps/ </td > </tr>
+<tr> <td>TBB (optional tool for parallelized version of BRepMesh component) </td> <td> TBB 3.x or 4.x http://www.threadingbuildingblocks.org/ </td > </tr>
+<tr> <td> OpenCL (optional for providing ray tracing visualization core </td> <td> OpenCL 1.2.8 native </td> </tr>
+</table>
@section OCCT_OVW_SECTION_4 Installation
OPEN CASCADE also provides the documents with recommendations on building
third-party products from source files.
+
+
When the installation is complete, you will find the following directories
(some might be absent in case of custom installation):
-
+@image html /overview/images/overview_installation.png "The directory tree"
+@image latex /overview/images/overview_installation.png "The directory tree"
+
+
-### Description of directory tree
+ * **adm** This folder contains administration files, which allow rebuilding OCCT;
+ * **adm/cmake** This folder contains files of CMake building procedure;
+ * **adm/msvc** This folder contains Visual Studio projects for Visual C++ 2005, 2008 and 2010, which allow rebuilding OCCT under Windows platform in 32 and 64-bit mode;
+ * **data** This folder contains CAD files in different formats, which can be used to test the OCCT functionalities;
+ * **doc** This folder contains OCCT Overview documentation;
+ * **drv** This folder contains source files generated by WOK (private header files and instantiations of generic classes);
+ * **inc** This folder contains all OCCT header files;
+ * **samples** This folder contains sample applications.
+ * **src** This folder contains OCCT source files. They are organized in folders, one per development unit;
+ * **tests** This folder contains scripts for OCCT testing.
+ * **win32/vc9** This folder contains executable and library files built in optimize mode for Windows platform by Visual C++ 2008;
+3rd party products have been moved to the root of Open CASCADE installation.
- * **3rdparty** * This folder contains third-party products necessary to compile and use OCCT as well as start sample applications with Visual C++ 2008;
- * **ros/adm** * This folder contains administration files, which allow rebuilding OCCT;
- * **ros/adm/cmake** * This folder contains files of CMake building procedure;
- * **ros/adm/msvc** * This folder contains Visual Studio projects for Visual C++ 2005, 2008 and 2010, which allow rebuilding OCCT under Windows platform in 32 and 64-bit mode;
- * **ros/data** * This folder contains CAD files in different formats, which can be used to test the OCCT functionalities;
- * **ros/doc** * This folder contains OCCT Overview documentation;
- * **ros/drv** * This folder contains source files generated by WOK (private header files and instantiations of generic classes);
- * **ros/inc** * This folder contains all OCCT header files;
- * **ros/samples** * This folder contains sample applications.
- * **ros/src** * This folder contains OCCT source files. They are organized in folders, one per development unit;
- * **ros/tests** * This folder contains scripts for OCCT testing.
- * **ros/win32/vc9** * This folder contains executable and library files built in optimize mode for Windows platform by Visual C++ 2008;
+@image html /overview/images/overview_3rdparty.png "The third-party products"
+@image latex /overview/images/overview_3rdparty.png "The third-party products"
@subsection OCCT_OVW_SECTION_4_2 System Environment Variables
* **PATH** is required to define the path to OCCT binaries and 3rdparty folder;
* **LD_LIBRARY_PATH** is required to define the path to OCCT libraries (on UNIX platforms only);
* **MMGT_OPT** if set to 1, the memory manager performs optimizations as described below; if set to 2,
- Intel ® TBB optimized memory manager is used; if 0 (default), every memory block is allocated
+ Intel (R) TBB optimized memory manager is used; if 0 (default), every memory block is allocated
in C memory heap directly (via malloc() and free() functions).
In the latter case, all other options except MMGT_CLEAR and MMGT_REENTRANT are ignored;
* **MMGT_CLEAR** if set to 1 (default), every allocated memory block is cleared by zeros;
* **CSF_MIGRATION_TYPES** is required in order to read documents that contain old data types, such as *TDataStd_Shape*;
* **TCLLIBPATH**, **TCL_LIBRARY**, **TK_LIBRARY** and **TIX_LIBRARY** are required to allow work with **DRAW** and **WOK**.
-
-@section OCCT_OVW_SECTION_5 Requirements
-
-@subsection OCCT_OVW_SECTION_5_1 Linux Intel
-
-| Operating System | 32/64-bit: Debian: 4.0, Mandriva: 2010* |
-| :--------------------------------------------- | :------------------------------------------------------------------------------------------------- |
-| Minimum memory | 512 Mb, 1 Gb recommended |
-| Free disk space (complete installation) | For full installation Open CASCADE Technology requires 600 Mb of disk space. |
-| Minimum swap space | 500 Mb |
-| Video card | GeForce, |
-| | The following versions of GeForce drivers are recommended: |
-| | 64-bit Version: 100.14.19 or later http://www.nvidia.com/object/linux_display_amd64_100.14.19.html |
-| | 32-bit Version: 100.14.19 or later http://www.nvidia.com/object/linux_display_ia32_100.14.19.html |
-| Graphic library | OpenGL 1.1+ (OpenGL 1.5+ is recommended) |
-| C++ | GNU gcc 4.0. * 4.3.2. |
-| TCL (for testing tools) | Tcltk 8.5 or 8.6 |
-| | http://www.tcl.tk/software/tcltk/8.6.html |
-| Qt (for demonstration tools) | Qt 4.6.2 http://qt.digia.com/downloads |
-| Freetype (OCCT Text rendering) | freetype-2.4.10 |
-| | http://sourceforge.net/projects/freetype/files/ |
-| FreeImage (Support of common graphic formats ) | FreeImage 3.14.1 |
-| | http://sourceforge.net/projects/freeimage/files/Source%20Distribution/ |
-| gl2ps (Export contents of OCCT | gl2ps-1.3.5 |
-| viewer to vector graphic file) | http://geuz.org/gl2ps/ |
-| TBB (optional tool for parallelized | TBB 3.x or 4.x |
-| version of BRepMesh component) | http://www.threadingbuildingblocks.org/ |
-
-@subsection OCCT_OVW_SECTION_5_2 Windows Intel
-
-| Operating System | 32/64-bit: 8/ 7 SP1 / VISTA SP2 /XP SP3 |
-| :--------------------------------------------- | :----------------------------------------------------------------------------------------------- |
-| Minimum memory | 512 Mb, 1 Gb recommended |
-| Free disk space | For full installation Open CASCADE Technology requires 650 Mb of disk space. |
-| (complete installation) | but during the process of installation you will need 1,2 Gb of free disk space. |
-| Minimum swap space | 500 Mb |
-| Video card | GeForce, |
-| | Version 266.58 WHQL or later is recommended:http://www.nvidia.com/Download/index.aspx |
-| Graphic library | OpenGL 1.1+ (OpenGL 1.5+ is recommended) |
-| C++ | Microsoft Visual Studio .NET 2005 SP1 with all security updates |
-| | Microsoft Visual Studio .NET 2008 SP1* |
-| | Microsoft Visual Studio .NET 2010 |
-| | Microsoft Visual Studio .NET 2012 |
-| TCL (for testing tools) | ActiveTcl 8.5 or 8.6 |
-| | http://www.activestate.com/activetcl/downloads |
-| Qt (for demonstration tools) | Qt 4.6.2 http://qt.digia.com/downloads |
-| Freetype (OCCT Text rendering) | freetype-2.4.10 |
-| | http://sourceforge.net/projects/freetype/files/ |
-| FreeImage (Support of common graphic formats ) | FreeImage 3.14.1 |
-| | http://sourceforge.net/projects/freeimage/files/Source%20Distribution/ |
-| gl2ps (Export contents of OCCT | gl2ps-1.3.5 |
-| viewer to vector graphic file) | http://geuz.org/gl2ps/ |
-| TBB (optional tool for parallelized | TBB 3.x or 4.x |
-| version of BRepMesh component) | http://www.threadingbuildingblocks.org/ |
-
-@subsection OCCT_OVW_SECTION_5_3 MAC OS X
-
-| Operating System | Requires Mac OS X 10.6.8 Snow Leopard / 10.7 Lion |
-| :--------------------------------------------- | :----------------------------------------------------------------------------------------------- |
-| Minimum memory | 512 Mb, 1 Gb recommended |
-| Free disk space (complete installation) | For full installation Open CASCADE Technology requires 600 Mb of disk space. |
-| Minimum swap space | 500 Mb |
-| Graphic library | OpenGL 1.1+ (OpenGL 1.5+ is recommended) |
-| C++ | XCode 3.2 or newer (4.x is recommended) |
-| TCL (for testing tools) | Tcltk 8.5 or 8.6 |
-| | http://www.tcl.tk/software/tcltk/8.6.html |
-| Qt (for demonstration tools) | Qt 4.6.2 http://qt.digia.com/downloads |
-| Freetype (OCCT Text rendering) | freetype-2.4.10 |
-| | http://sourceforge.net/projects/freetype/files/ |
-| FreeImage (Support of common graphic formats ) | FreeImage 3.14.1 |
-| | http://sourceforge.net/projects/freeimage/files/Source%20Distribution/ |
-| gl2ps (Export contents of OCCT | gl2ps-1.3.5 |
-| viewer to vector graphic file) | http://geuz.org/gl2ps/ |
-| TBB (optional tool for parallelized | TBB 3.x or 4.x |
-| version of BRepMesh component) | http://www.threadingbuildingblocks.org/ |
-
-
@section OCCT_OVW_SECTION_6 Release Notes
Open CASCADE Technology latest version
@htmlonly
-<a href="http://occtrel.nnov.opencascade.com/OpenCASCADE6.6.0/doc/release_notes.pdf">Release Notes</a>
+<a href="http://occtrel.nnov.opencascade.com/OpenCASCADE6.7.0/doc/release_notes.pdf">Release Notes</a>
@endhtmlonly (PDF)
Draw can be used interactively to create, display and modify objects such as curves, surfaces and topological shapes.
-
+@image html /overview/images/overview_draw.png
+@image latex /overview/images/overview_draw.png
Scripts can be written to customize Draw and perform tests.
New types of objects and new commands can be added using C++ programming language.
* Animation
* Convert
-
+@image html /overview/images/overview_mvc.png
+@image latex /overview/images/overview_mvc.png
**Remarks:**
Import Export programming sample contains 3D Viewer and Import // Export functionality.
-
+@image html /overview/images/overview_qt.png
+@image latex /overview/images/overview_qt.png
Tutorial
---------
C# sample containing 3D Viewer and Import // Export functionality.
-
+@image html /overview/images/overview_c__ie.png
+@image latex /overview/images/overview_c__ie.png
Import:
* C# sample is available only on Windows platform;
* It is delivered in source code only and must be built with Microsoft Visual C++ 2005.
+
+
+
+
--- /dev/null
+Building OCCT Libraries {#dev_guides__building}
+=========
+
+The source package of the Open CASCADE Technology including the source files of samples
+and tools and the set of building procedures is available for self-dependent preparation
+binary files on UNIX and Windows platforms.
+
+In order to build OCCT libraries from these sources for use in your program,
+you need to:
+
+1. Install the required third-party libraries.
+
+ Follow the instructions provided in the documents titled "Building 3rd party
+ products for OCCT" on http://dev.opencascade.org/?q=home/resources for
+ choice of the needed libraries, their installation and building.
+
+2. If you use OCCT sources from Git repository or do come changes affecting
+ CDL files or dependencies of OCCT toolkit, update header files generated
+ from CDL, and regenerate build scripts for your environment using WOK.
+ See \subpage dev_guides__building__wok "WOK" for details.
+
+ Skip to step 3 if you use complete source package (e.g. official OCCT
+ release) without changes in CDL.
+
+3. Build using your preferred build tool.
+ - \subpage dev_guides__building__automake "Building on Linux with Autotools"
+ - \subpage dev_guides__building__cmake "Building with CMake (cross-platform)"
+ - \subpage dev_guides__building__code_blocks "Building on Mac OS X with Code::Blocks"
+ - \subpage dev_guides__building__msvc "Building on Windows with MS Visual Studio 2005-2012"
+ - \subpage dev_guides__building__xcode "Building on Mac OS X with Xcode"
+
+The current version of OCCT can be consulted in the file src/Standard/Standard_Version.hxx
\ No newline at end of file
--- /dev/null
+WOK {#dev_guides__building__wok}
+=========
+
+WOK is a legacy build environment for Open CASCADE Technology. It is required
+for generation of header files for classes defined with @ref ug_cdl "CDL"
+("Cascade Definition Language"). Also tools for generation of project files
+for other build systems, and OCCT documentation, are integrated to WOK.
+
+WOK thus is needed in the following situations:
+- Building from OCCT sources from Git repository (do not contain generated files)
+- Building after some changes made in CDL files
+
+Before installing and using WOK, make sure that you have installed a compiler (it is assumed that it is Visual Studio on Windows or gcc on Linux and MacOS) and third-party components required for building OCCT.
+
+@section wok1 Installing WOK
+
+ Download the latest version of binary distribution WOK from http://dev.opencascade.org/index.php?q=home/resources
+
+@subsection wok11 Windows
+
+ Run the installer. You will be prompted to read and accept the OCCT Public License to proceed:
+
+ @image html /dev_guides/building/wok/images/wok_image001.jpg
+ @image latex /dev_guides/building/wok/images/wok_image001.jpg
+
+ Click Next and proceed with the installation.
+ At the end of the installation you will be prompted to specify the version and the location of Visual Studio to be used, and the location of third-party libraries:
+
+ @image html /dev_guides/building/wok/images/wok_image002.jpg
+ @image latex /dev_guides/building/wok/images/wok_image002.jpg
+
+ You can change these settings at any time later. For this click on the item "Customize environment (GUI tool)" in the WOK group in the Windows Start menu.
+
+ The shortcuts from this group provide two ways to run WOK:
+ * In command prompt window ("WOK TCL shell").
+ * In Emacs editor ("WOK Emacs"). Using Emacs is convenient if you need to work within WOK environment.
+
+ By default WOK installer creates a WOK factory with name "LOC" within workshop "dev" (WOK path :LOC:dev).
+
+@subsection wok12 Linux
+
+ * Unpack the .tgz archive containing WOK distributive into an installation directory <WOK_INSTALL_DIR>.
+
+ * Perform the following commands assuming that you have unpacked WOK distributive archive into <WOK_INSTALL_DIR>:
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ cd <WOK_INSTALL_DIR>/site
+ wok_confgui.sh
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ Define all necessary paths to third-party products in the dialog window:
+
+ @image html /dev_guides/building/wok/images/wok_image003.jpg
+ @image latex /dev_guides/building/wok/images/wok_image003.jpg
+
+ * Run the following commands to create WOK LOC factory:
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ cd <WOK_INSTALL_DIR>/site
+ wok_init.sh
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ * Your installation procedure is over. To run WOK use one the following commands:
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ cd <WOK_INSTALL_DIR>/site
+ wok_emacs.sh
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ or
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ cd <WOK_INSTALL_DIR>/site
+ wok_tclsh.sh
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsection wok13 Mac OS X
+
+ * In the Finder double click on wokSetup.dmg file. This will open a new window. Drag and drop "wokSetup" folder from this window at the location in the Finder where you want to install WOK, i.e. <WOK_INSTALL_DIR>.
+
+ * Browse in the Finder to the folder <WOK_INSTALL_DIR>/site and double click on WokConfig. This will open a window with additional search path settings. Define all necessary paths to third-party products in the dialog window:
+
+ @image html /dev_guides/building/wok/images/wok_image004.jpg
+ @image latex /dev_guides/building/wok/images/wok_image004.jpg
+
+ * Run the following commands to create WOK LOC factory:
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ cd <WOK_INSTALL_DIR>/site
+ wok_init.sh
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ * Your installation procedure is over. To run WOK in Emacs navigate in the Finder to the folder <WOK_INSTALL_DIR>/site and double click on WokEmacs.
+
+
+@section wok2 Initialization of Workbench
+
+ To start working with OCCT, clone the OCCT Git repository from the server (see http://dev.opencascade.org/index.php?q=home/resources for details) or unpack the source archive.
+
+ Then create a WOK workbench (command wcreate) setting its Home to the directory, where the repository is created ($CASROOT variable). The workbench should have the same name as that directory.
+
+ For example, assuming that OCCT repository has been cloned into D:/occt folder:
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ LOC:dev> wcreate occt -DHome=D:/occt
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+ Note: $CASROOT is equal to D:/occt now
+
+ Then you can work with this workbench using normal WOK functionality (wprocess, umake, etc.; see WOK User\92s Guide for details) or use it only for generation of derived sources and project files, and build OCCT with Visual Studio on Windows or make command on Linux, as described below.
+
+@section wok3 Generation of building projects
+
+ Use command wgenproj in WOK to generate derived headers, source and building projects files:
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ LOC:dev> wokcd 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
+-no_wprocess - skip generation of derived headers and source files
+
+Note that this command takes several minutes to complete at the first call.
+
+Re-execute this step to generate derived headers, source and building projects files if some CDL files in OCCT have been modified (either by you directly, or due to updates in the repository). Note that in some cases WOK may fail to update correctly; in such case remove sub-directories drv and .adm and repeat the command.
+
+To regenerate derived headers and source files without regeneration of projects use command:
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ LOC:dev> wokcd occt
+ LOC:dev:occt> wprocess -DGroups=Src,Xcpp
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The generated building project has been placed into $CASROOT/adm folder:
+ * for vc8 - $CASROOT/adm/msvc/vc8
+ * for vc9 - $CASROOT/adm/msvc/vc9
+ * for vc10 - $CASROOT/adm/msvc/vc10
+ * for vc11 - $CASROOT/adm/msvc/vc11
+ * for cbp - $CASROOT/adm/<OS> /cbp
+ * for cmake - $CASROOT/adm/cmake
+ * for amk - $CASROOT/adm/lin/amk
+ * xcd - $CASROOT/adm/<OS>/xcd
+
+@section wok4 Generation of documentation
+
+ Use command wgendoc in WOK to generate reference documentation:
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
+ :LOC:dev> wokcd occt
+ :LOC:dev:occt> wgendoc
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The following options can be used:
+ * -wb=< workbench name > the name of OCCT workbench (the current one by default);
+ * -m=< list of modules > the list of modules that will be contained in the documentation;
+ * -outdir=< path > the output directory for the documentation;
+ * -chm the option to generate CHM file;
+ * -hhc=< path > the path to HTML Help Compiler (hhc.exe) or equivalent;
+ * -qthelp=< path > the option to generate Qt Help file, it is necessary to specify the path to qthelpgenerator executable;
+ * -doxygen=< path > the path to Doxygen executable
+ * -dot=< path > the path to GraphViz dot executable
\ No newline at end of file
To save data in a file, you need to define persistent classes. Then, you group these classes in a schema, which provides the necessary read/write tools.
- <table>
- <tr>
- <td>
-
- </td>
- </tr>
- <tr>
- <td>
-
- </td>
- <td>
- 
- </td>
- </tr>
-</table>
+
+ @image html /dev_guides/cdl/images/cdl_image003.jpg
+ @image latex /dev_guides/cdl/images/cdl_image003.jpg
+
Figure 1. Building an Open CASCADE Technology application
@section occt_1819379591_986437237 2. Introduction to CDL
@subsection occt_1819379591_98643723721 Purposes of the Language
You use CDL in the **design phase **of a development process to define a set of software components which best model the concepts stated in the application specification.
- <table>
- <tr>
- <td>
-
- </td>
- </tr>
- <tr>
- <td>
-
- </td>
- <td>
- 
- </td>
- </tr>
-</table>
+ @image html /dev_guides/cdl/images/cdl_image004.jpg
+ @image latex /dev_guides/cdl/images/cdl_image004.jpg
Figure 2. The Development Process
* Data types manipulated by handle (or reference)
* Data types manipulated by value
- <table>
- <tr>
- <td>
-
- </td>
- </tr>
- <tr>
- <td>
-
- </td>
- <td>
- 
- </td>
- </tr>
-</table>
+
+ @image html /dev_guides/cdl/images/cdl_image005.jpg
+ @image latex /dev_guides/cdl/images/cdl_image005.jpg
Figure 3. Manipulation of data types
The following is a list of keywords.
-alias any as asynchronous
-class client deferred end
-enumeration exception executable external
-fields friends from generic
-immutable imported inherits instantiates
-is library like me
-mutable myclass out package
-pointer primitive private protected
-raises redefined returns schema
-static to uses virtual
+alias any as asynchronous
+class client deferred end
+enumeration exception executable external
+fields friends from generic
+immutable imported inherits instantiates
+is library like me
+mutable myclass out package
+pointer primitive private protected
+raises redefined returns schema
+static to uses virtual
In a CDL file, the following characters are used as punctuation:
; : , = ( ) [ ] ‘ “
An **integer **constant consists of a string of digits, which may or may not be preceded by a sign. Integer constants express whole numbers.
**Examples**
-1995 0 -273 +78
+1995 0 -273 +78
A **real **constant may or may not be preceded by a sign, and consists of an integral part followed by a decimal point and a fractional part (either one or both parts may be null, but both parts must always be present). It may also be followed by the letter E to indicate that the following figures represent the exponent (also optionally signed).
**Examples**
-5.0 0.0 -0.8E+3 5.67E-12
+5.0 0.0 -0.8E+3 5.67E-12
***Literal Constants***
An **individual character **constant is a single printable character enclosed by two apostrophes. (See the definition of the class Character in the Standard Package).
**Examples**
- ‘B’ ‘y’ ‘&’ ‘*’ ‘’’ ‘‘
+ ‘B’ ‘y’ ‘&’ ‘*’ ‘’’ ‘‘
A **string **constant is composed of printable characters enclosed by quotation marks.
**Examples**
-’’G’’ ’’jjjj’’ ’’This is a character string, isn’t it?’’
+’’G’’ ’’jjjj’’ ’’This is a character string, isn’t it?’’
The **quotation mark **can itself appear within a character string as long as it is preceded by a backslash.
**Examples**
The primitives inheriting from Storable are the following:
-**Boolean **Is used to represent logical data. It has only two values:
+**Boolean **Is used to represent logical data. It has only two values:
*True *and *False*.
-**Byte **8-bit number.
-**Character **Designates any ASCII character.
-**ExtCharacter **Is an extended character.
-**Integer **Is an integer number.
-**Real **Denotes a real number (i.e. one with a whole and a fractional part, either of which may be null).
-**ShortReal **Real with a smaller choice of values and memory size.
+**Byte **8-bit number.
+**Character **Designates any ASCII character.
+**ExtCharacter **Is an extended character.
+**Integer **Is an integer number.
+**Real **Denotes a real number (i.e. one with a whole and a fractional part, either of which may be null).
+**ShortReal **Real with a smaller choice of values and memory size.
There are also non-storable primitives. They are:
-**CString **Is used for literal constants.
-**ExtString **Is an extended string.
-**Address **Represents a byte address of undetermined size.
+**CString **Is used for literal constants.
+**ExtString **Is an extended string.
+**Address **Represents a byte address of undetermined size.
The services offered by each of these types are described in the Standard Package.
* Types defined using classes inheriting from the **Transient **class.
These types are not storable as such in a file.
-
+@image html /dev_guides/cdl/images/cdl_image006.jpg
+@image latex /dev_guides/cdl/images/cdl_image006.jpg
Figure 4. Manipulation of a data type by reference
You can store types known to the schema (i.e. either primitives or inheriting from Storable) and manipulated by value inside a persistent object as part of the representation. This is the only way for you to store objects “manipulated by value” in a file.
-
- <table>
- <tr>
- <td>
-
- </td>
- </tr>
- <tr>
- <td>
-
- </td>
- <td>
- 
- </td>
- </tr>
-</table>
+ @image html /dev_guides/cdl/images/cdl_image007.jpg
+ @image latex /dev_guides/cdl/images/cdl_image007.jpg
+
Figure 5. Manipulation of a data type by value
Three types are manipulated by value:
* the invariants
* the internal representation
* the friend methods and friend classes.
- <table>
- <tr>
- <td>
-
- </td>
- </tr>
- <tr>
- <td>
-
- </td>
- <td>
- 
- </td>
- </tr>
-</table>
+
+ @image html /dev_guides/cdl/images/cdl_image009.jpg
+ @image latex /dev_guides/cdl/images/cdl_image009.jpg
+
**Figure 7. Contents of a class**
*** a deferred class does not have to contain a constructor**
@subsubsection occt_1819379591_1718435309331 Package declaration
- **Packages** are used to group classes, which have some logical coherence. For example, the Standard Package groups together all the predefined resources of the language. In its simplest form, a package contains the declaration of all data types, which it introduces. You may also use a package to offer public methods and hide its internal classes by declaring them private.
+ **Packages** are used to group classes, which have some logical coherence. For example, the Standard Package groups together all the predefined resources of the language. In its simplest form, a package contains the declaration of all data types, which it introduces. You may also use a package to offer public methods and hide its internal classes by declaring them private.
** **
**Example**
The methods you declare in a package do not belong to any particular class. **Package methods ***must *carry a name different from the data types contained in the package. Like any other method, they can be overloaded. With the exception of the keyword **me **and the visibility (a package method can *only *be either public or private) package methods are described in the same way as **instance methods**.
-
+@image html /dev_guides/cdl/images/cdl_image010.jpg
+@image latex /dev_guides/cdl/images/cdl_image010.jpg
Figure 8. Contents of a package
The example of the package below includes some of the basic data structures:
end SingleList;
-- Third compilation unit, the class “Set” :
generic class Set from Collection (Item as Storable)
- inherits
+ inherits
Persistent from Standard;
raises
NoSuchObject from Collection,
private class Node instantiates SingleList
from Collection (Item);
-- etc....
- end Set;
+ end Set;
NOTE
static Handle(Standard_Type) _aType =
new Standard_Type (“MyPack_MyImport”,sizeof
(MyPack_MyImport))
- return _aType;
+ return _aType;
}
Then, add the names of these two files (MyPack_MyImport.hxx, MyPack_MyImport.cxx) to a file called FILES in the src subdirectory of the package. If the file does not exist you must create it.
The behavior of an object class is defined by a list of **methods, **which are either **functions **or **procedures**. Functions return an object, whereas procedures only communicate by passing arguments. In both cases, when the transmitted object is an instance manipulated by a handle, its identifier is passed. There are three categories of methods:
-**Object constructor **Creates an instance of the described class. A class will have one or more object constructors with various arguments or none.
+**Object constructor **Creates an instance of the described class. A class will have one or more object constructors with various arguments or none.
-**Instance method **Operates on the instance which owns it.
+**Instance method **Operates on the instance which owns it.
-**Class method **Does not work on individual instances, only on the class itself.
+**Class method **Does not work on individual instances, only on the class itself.
@subsubsection occt_1819379591_1972310108411 Object Constructors
declaration-of-constructed-type ::=
**returns **[ **mutable **] class-name
-The name of the constructors is fixed: “Create”. The object returned by a constructor is always of the type of the described class. If that type is manipulated by a handle, you *must *declare it as **mutable**, in which case the content of the instance it references is accessible for further modification.
+The name of the constructors is fixed: “Create”. The object returned by a constructor is always of the type of the described class. If that type is manipulated by a handle, you *must *declare it as **mutable**, in which case the content of the instance it references is accessible for further modification.
For example, the constructor of the class “Point”
**Example**
[ declaration-of-returned-type ]
[ exception-declaration ]
formal-part-of-instance-method ::=
- ’(’ me [’:’ passing-mode parameter-access ] {’;’
+ ’(’ me [’:’ passing-mode parameter-access ] {’;’
parameter}’)’
parameter ::=
identifier {’,’ identifier} ’:’ passing-mode
Depending on their type, Object fields have one of the two forms. When the field is of the “manipulated by handle” type, it corresponds to an identifier. In this case, the contents of the object can be shared by other objects or by a handle in a program. When the field is of a “manipulated by value” type, it contains the value of the object. In this case you say the object is **embedded**.
@subsection occt_1819379591_197231010843 Exceptions
-
-Exceptions describe exceptional situations, which can arise during the execution of a method. With the raising of an exception, the normal course of program execution is interrupted. The actions carried out in response to this situation are called treatment of exception.
+
+Exceptions describe exceptional situations, which can arise during the execution of a method. With the raising of an exception, the normal course of program execution is interrupted. The actions carried out in response to this situation are called treatment of exception.
exception-treatment ::= **raises **exception-name {’,’
exception-name}
Instance methods are likely to raise certain exceptions called **systematic exceptions **which do not have to appear. They are:
-**NullObject **Raised when the principal object does not exist.
+**NullObject **Raised when the principal object does not exist.
-**ImmutableObject **Raised when a method tries to modify an immutable principal object.
+**ImmutableObject **Raised when a method tries to modify an immutable principal object.
-**TypeMismatch **Raised if an argument typed by association is of an unsuitable type.
+**TypeMismatch **Raised if an argument typed by association is of an unsuitable type.
These exceptions are described in the Standard Package (System Toolkits).
A class cannot inherit one of its descendent classes; nor can it inherit a native type. All the classes of a system can be described in a non-cyclic diagram called the **inheritance graph**.
-The definition of a sub-class is identical to that of a simple class. Note that a super-class *must not *appear in the **uses **clause of the sub-class, even if it appears in the definition of the sub-class. The behavior of a sub-class includes as a minimum all instance methods and protected methods of its super-classes.
+The definition of a sub-class is identical to that of a simple class. Note that a super-class *must not *appear in the **uses **clause of the sub-class, even if it appears in the definition of the sub-class. The behavior of a sub-class includes as a minimum all instance methods and protected methods of its super-classes.
NOTE
Note that constructors and class methods are never inherited.
identifier formal-part-of-instance-method [returnedtype-
declaration]
[declaration-of-exceptions]
-** is redefined **[visibility]’;’
+** is redefined **[visibility]’;’
A redefined method must conform to the syntax described in the super-class where it appears. The exceptions contained in the super-class can be renewed, and others may be added as long as they inherit from an ancestor class.
identifier formal-part-of-instance-method [returnedtype-
declaration]
[declaration-of-exceptions]
-** is virtual **[visibility]’;’
+** is virtual **[visibility]’;’
All methods are static by default. To enable redefinition in all the child classes, add “**is virtual;**“ when declaring the method.
declaration-of-a-deferred-class ::=
**deferred class **class-name
- [**inherits **class-name
+ [**inherits **class-name
[**uses **data-type {’,’ data-type}]
[**raises **exception-name {’,’ exception-name}]
**is **class-definition
raises NoSuchObject
is
Create returns mutable SingleList;
- ---Purpose: Creates an empty list
+ ---Purpose: Creates an empty list
IsEmpty (me) returns Boolean;
- ---Purpose: Returns true if the list me is empty
+ ---Purpose: Returns true if the list me is empty
SwapTail (me : mutable; S : in out mutable
SingleList)
- ---Purpose: Exchanges the tail of list me with S
+ ---Purpose: Exchanges the tail of list me with S
-- Exception NoSuchObject raised when me is
empty
raises NoSuchObject;
- Value (me) returns Item
- ---Purpose: Returns first element of the list me
+ Value (me) returns Item
+ ---Purpose: Returns first element of the list me
-- Exception NoSuchObject raised when me is
empty
raises NoSuchObject;
- Tail (me) returns mutable SingleList
+ Tail (me) returns mutable SingleList
---Purpose: Returns the tail of the list me
-- Exception NoSuchObject raised when me is
empty
raises NoSuchObject;
- fields
+ fields
Data : Item;
- Next : SingleList;
- end SingleList;
+ Next : SingleList;
+ end SingleList;
Even though no object of the type “SingleList” IS created, the class contains a constructor. This class constitutes a model, which will be recopied at instantiation time to create a new class which will generate objects. The constructor will then be required.
**Example**
instantiation-of-a-generic-class ::=
[**deferred**] **class **class-name
-** instantiates **class-name ’(’data-type {’,’
+** instantiates **class-name ’(’data-type {’,’
data-type}’);’
Instantiation is said to be **static**. In other words, it must take place before any use can be made of the type of the instantiated class. Each data type is associated term by term with those declared at the definition of the generic class. These latter ones, when they are not of the type **any**, restrict instantiation to those classes, which have a behavior at least equal to that of the class specified in the type constraint, including constructors. Note that this is not guaranteed by inheritance itself.
**Example**
declaration-of-a-generic-class ::=
- [**deferred**] **generic class **class-name ’(’generic-
+ [**deferred**] **generic class **class-name ’(’generic-
type{’,’generic-type}’)’
- [**inherits **class-name {’,’ class-name}]
- [**uses **data-type {’,’ data-type}]
- [**raises **exception-name {’,’ exception-name}]
- [{[visibility] class-declaration}]
-** is **class-definition
+ [**inherits **class-name {’,’ class-name}]
+ [**uses **data-type {’,’ data-type}]
+ [**raises **exception-name {’,’ exception-name}]
+ [{[visibility] class-declaration}]
+** is **class-definition
**end **[class-name]’;’
- class-declaration ::=
- incomplete-declaration-of-a-class |
- declaration-of-a-non-generic-class |
- instantiation-of-a-generic-class
+ class-declaration ::=
+ incomplete-declaration-of-a-class |
+ declaration-of-a-non-generic-class |
+ instantiation-of-a-generic-class
**Nested classes**, even though they are described as non-generic classes, are generic by construction, being inside the class of which they are a part. As a consequence, the generic types introduced by the **encompassing class **can be used in the definition of the nested class. This is true even if the generic type is only used in a nested class. The generic types still* must *appear as an argument of the encompassing class. All other types used by a nested class *must *appear in its **uses **or **raises **clauses, just as if it were an independent class.
inherits Persistent
private class Node instantiates SingleList (Item);
class Iterator
- uses Set, Node
- raises NoSuchObject, NoMoreObject
- is
- Create (S : Set) returns mutable Iterator;
+ uses Set, Node
+ raises NoSuchObject, NoMoreObject
+ is
+ Create (S : Set) returns mutable Iterator;
---Purpose: Creates an iterator on the group S
- More (me) returns Boolean;
+ More (me) returns Boolean;
---Purpose: Returns true if there are still elements
- -- to explore
- Next (me) raises NoMoreObject;
+ -- to explore
+ Next (me) raises NoMoreObject;
---Purpose: Passes to the following element
- Value (me) returns any Item raises NoSuchObject;
+ Value (me) returns any Item raises NoSuchObject;
---Purpose: Returns the current element
- fields
- Current : Node;
+ fields
+ Current : Node;
end Iterator;
is
- Create returns mutable Set;
+ Create returns mutable Set;
---Purpose: Creates an empty group
- IsEmpty (me) returns Boolean;
+ IsEmpty (me) returns Boolean;
---Purpose: Returns true if the group is empty
- Add (me : mutable; T : Item);
+ Add (me : mutable; T : Item);
---Purpose: Adds an item to the group me
- Remove (me : mutable; T : item) raises
+ Remove (me : mutable; T : item) raises
NoSuchObject;
---Purpose: Removes an item from the group me
- etc.
- fields
- Head : Node;
+ etc.
+ fields
+ Head : Node;
end Set;
Note that in their fields, both “Set” and “Iterator” are clients of another class, “Node”. This last can be effectively declared **private **for it only appears in fields which are themselves private.
Example
fields
- Phi, Delta, Gamma : AngularMomenta [3]
- is protected ;
+ Phi, Delta, Gamma : AngularMomenta [3]
+ is protected ;
@subsubsection occt_1819379591_1972310108463 Visibility of Methods
Methods act on fields. Only methods belonging to a class can act on the fields of the class; this stems from the principle of object encapsulation. Methods can be characterized in three ways: by default, methods are **public**. Methods can be declared **private **or **protected **to restrict their usage.
-**Public methods **Are the default and are generally the most common. They describe the behavior of a class or a package, and they are callable by any part of a program.
+**Public methods **Are the default and are generally the most common. They describe the behavior of a class or a package, and they are callable by any part of a program.
-**Private methods **Exist only for the internal structuring of their class or their package. Private class methods can only be called by methods belonging to the same class. Private package methods can only be called by all methods belonging to the same package and its classes.
+**Private methods **Exist only for the internal structuring of their class or their package. Private class methods can only be called by methods belonging to the same class. Private package methods can only be called by all methods belonging to the same package and its classes.
-**Protected methods **Are private methods, which are also callable from the interior of descendent classes.
+**Protected methods **Are private methods, which are also callable from the interior of descendent classes.
If you want to restrict the usage of a method, you associate with it a visibility as follows :
declaration-of-friends ::=
**friends **friend {’,’friend}
- friend ::=
- identifier **from **[**class**] class-name [formal-part] |
+ friend ::=
+ identifier **from **[**class**] class-name [formal-part] |
**Defining the Software Components 67**
identifier **from **[**package**] package-name [formal-part] |
-** class**] class-name
- formal-part ::=
- simple-formal-part |
- formal-part-of-instance-method |
- formal-part-of-class-method
+** class**] class-name
+ formal-part ::=
+ simple-formal-part |
+ formal-part-of-instance-method |
+ formal-part-of-class-method
The formal part *must *be presented if the method contains one; thus this can be overloaded without necessarily propagating the friend relationship among its homonyms. The keyword **class **allows you to avoid certain ambiguities. For example, it removes any confusion between “method M from class C” and “method M from package P”.
friends Distance from Line (me; P : Point)
A method can be a friend to many classes. The class to which the method belongs does *not *need to appear in the **uses **clause of other classes of which it is a friend.
- <table>
- <tr>
- <td>
-
- </td>
- </tr>
- <tr>
- <td>
-
- </td>
- <td>
- 
- </td>
- </tr>
-</table> When the methods of a class are all friends of another class, you can establish the friendship at the level of the class.
+ @image html /dev_guides/cdl/images/cdl_image011.jpg
+ @image latex /dev_guides/cdl/images/cdl_image011.jpg
+When the methods of a class are all friends of another class, you can establish the friendship at the level of the class.
Figure 9. Visibility of various components
@section occt_1819379591_858765726 Appendix A. Syntax Summary
**raises**** **exception-name {’,’ exception-name}
(35) declaration-of-visibility ::=
-**is**** **visibility
+**is**** **visibility
(36) declaration-of-attributes-of-instance-method ::=
**is**** **visibility | **is **definition-of-level
[**inherits**** **class-name
[**uses**** **data-type {’,’ data-type}]
[**raises**** **exception-name {’,’ exception-name}]
-** is **definition-of-a-class
+** is **definition-of-a-class
**end **[class-name]’;’
(55) type-constraint ::=
@subsection occt_1819379591_213955286151 Comparison of CDL & C++ Syntax for Data Types manipulated by Handle and by Value
- <table>
- <tr>
- <td>
-
- </td>
- </tr>
- <tr>
- <td>
-
- </td>
- <td>
- 
- </td>
- </tr>
-</table>
-
+ @image html /dev_guides/cdl/images/cdl_image012.jpg
+ @image latex /dev_guides/cdl/images/cdl_image012.jpg
+
\ No newline at end of file
Developer Guides {#dev_guides}
================
-@section OCCT_OVW_SECTION1 Source Repository
+## Source Repository
This directory contains sources of Open CASCADE Technology (OCCT), a collection
of C++ libraries providing services for 3D surface and solid modeling, CAD data
License at http://www.opencascade.org and read it completely before using this
software.
-@section OCCT_OVW_SECTION11 Building OCCT Libraries
-
-The source package of the Open CASCADE Technology including the source files of samples
-and tools and the set of building procedures is available for self-dependent preparation
-binary files on UNIX and Windows platforms.
-
-In order to build OCCT libraries from these sources for use in your program,
-you need to:
-
-1. Install the required third-party libraries.
-
- Follow the instructions provided in the documents titled "Building 3rd party
- products for OCCT" on http://dev.opencascade.org/?q=home/resources for
- choice of the needed libraries, their installation and building.
-
-2. If you use OCCT sources from Git repository or do come changes affecting
- CDL files or dependencies of OCCT toolkit, update header files generated
- from CDL, and regenerate build scripts for your environment using WOK.
- See \subpage dev_guides__wok "WOK" for details.
-
- Skip to step 3 if you use complete source package (e.g. official OCCT
- release) without changes in CDL.
-
-3. Build using your preferred build tool.
- - \subpage dev_guides__building__automake "Building on Linux with Autotools"
- - \subpage dev_guides__building__cmake "Building with CMake (cross-platform)"
- - \subpage dev_guides__building__code_blocks "Building on Mac OS X with Code::Blocks"
- - \subpage dev_guides__building__msvc "Building on Windows with MS Visual Studio 2005-2012"
- - \subpage dev_guides__building__xcode "Building on Mac OS X with Xcode"
-
-The current version of OCCT can be consulted in the file src/Standard/Standard_Version.hxx
-
-@section OCCT_OVW_SECTION111 Automatic tests
+## Automatic tests
OCCT automatic testing system is integrated with @ref draw "DRAW Test Harness",
a console application based on Tcl (a scripting language).
add one more argument '-echo' at the end of the command line, or type 'dlog get'
after test completion.
-For more information consult \subpage dev_guides__tests "Automatic Testing System"
+For more information consult \subpage dev_guides__tests
+
+## docs
+**short description**
+
+\subpage dev_guides__documentation
+
+## wok
+**short description**
-@section OCCT_OVW_SECTION1112 CDL Overview
+\subpage dev_guides__wok
-CDL is the component definition language of the Open CASCADE Technology (OCCT) programming platform.
-Some components, which CDL allows you to create, are specific to OCCT application architecture.
+## building
+**short description**
-For more information consult \subpage dev_guides__cdl "Component Definition Language Developer's Guide"
+\subpage dev_guides__building
-@section OCCT_OVW_SECTION1113 Documentation Overview
+## cdl
+**short description**
-\subpage dev_guides__documentation "Documentation Developer's Guide"
+\subpage dev_guides__cdl
\ No newline at end of file
<b>MiKTeX</b> or equivalent tool (used for PDF document creation)
Latest version: http://miktex.org/download
+**Note**: to generate pdf documentation with MiKTeX you should execute gen.bat with MiKTeX environment
+(e.g. into MiKTeX command promt)
+
@section OCCT_DM_SECTION_2_1 Documentation Generation
Run gendoc.bat from OCCT directory to generate all articles are defined in FILES.txt:
@subsection OCCT_DM_SECTION_3_2 Directory Structure
-
+@image html /dev_guides/documentation/images/documentation_image001.png
+@image latex /dev_guides/documentation/images/documentation_image001.png
Every separate article has own folder if images are used in it. These images
are stored into "images" subfolder.
**Note**: Every article can use any image that is used by others articles. To avoid incorrect image
displaying, use relative path to the image (starting from dox folder). For instance
@verbatim
-
+@image html /dev_guides/snv/images/snv_image001.svg
@endverbatim
Result of generation of the documentation is:
- Place a new article into folder that is chosen taking into account the place of the article
at the hierarchy of the documentation. For instance the article about "using SVN working with OCCT
-source code" (svn.md - the file of the article) might be placed into /dox/devs_guide/ . If the article has images then you may create
+source code" (svn.md - the file of the article) might be placed into /dox/dev_guides/ . If the article has images then you may create
the own folder of the article and subfolder in it for images. For instance
-*/dox/devs_guide/svn/ - for svn.md file
-*/dox/devs_guide/svn/images/ - for images
+*/dox/dev_guides/svn/ - for svn.md file
+*/dox/dev_guides/svn/images/ - for images
- Update dox/FILES.txt to add relative path to svn.md. For instance
@verbatim
-devs_guide/snv/svn.md
+dev_guides/snv/svn.md
@endverbatim
**Note**: the place of the relative path to an article is connected with the place
More information on MarkDown and Doxygen syntax can be found at:
http://www.stack.nl/~dimitri/doxygen/manual
-
-
-@section OCCT_DM_SECTION_A Appendix 1: Document Syntax
-
-Each OCCT document file in *.md format has a simple structure.
-It can contain:
-
-| Content type | Obligation |
-| :---------------- | :-------------------: |
-| Header | M |
-| Footer | M |
-| Plain text | O |
-| List | O |
-| Table | O |
-| Code | O |
-| Formula | O |
-| Image | O |
-| Page numbers | M (auto generation) |
-| Table of contents | M (auto generation) |
-
-The legend:
-
- * M is for Mandatory
- * O is for Optional
-
-@subsection OCCT_DM_SECTION_A_1 Text Caption (a header)
-
-headings of different levels can be specified with the following code:
-
-@verbatim
-Header 1 {#header1}
-=======
-@endverbatim
-
- to get
-
- Header 1
-=========
-
- and with the following code:
-
-@verbatim
-Header 2 {#header2}
---------
-@endverbatim
-
-to get
-
-Header 2
----------
-
-Where a word in curly braces is a MarkDown-style reference, which can be used in table of contents.
-If you would like to have the table of contents, it is recommended to use \@section,
-\@subsection and \@subsubsection pages instead of MarkDown headers as follows:
-
-@verbatim
- @section Section_Name Section Header
- @subsection SubSection_Name SubSection Header
- @subsubsection SubSubSection_Name SubSubSection Header
-@endverbatim
-
-@subsection OCCT_DM_SECTION_A_2 Plain Text
-
-Plain text is a text in a notepad-like format. To insert special symbols,
-like \< , \> or \\, prepend them with \\ character: \\\<, \\\>, \\\\
-To emphasize some words, write one pair of asterisks ( * ) or underscores ( _ ) across the word
-to make it *italic* and two pairs of these symbols to make a word **Bold**.
-
-@subsection OCCT_DM_SECTION_A_3 Lists
-
-To create a bulleted list, start each line with a hyphen or an asterisk,
-followed by a space. List items can be nested. This code:
-
-@verbatim
- * Bullet 1
- * Bullet 2
- * Bullet 2a
- * Bullet 2b
- * Bullet 3
-@endverbatim
-
- produces this list:
-
- * Bullet 1
- * Bullet 2
- * Bullet 2a
- * Bullet 2b
- * Bullet 3
-
-To create a numbered list, start each line with number and a period, then a space. Thus this code
-
-@verbatim
- 1. ListItem_1
- 2. ListItem_2
- 3. ListItem_3
-@endverbatim
-
- produces this list:
-
- 1. ListItem_1
- 2. ListItem_2
- 3. ListItem_3
-
-It is recommended to indent lists with 2 spaces.
-
-@subsection OCCT_DM_SECTION_A_4 Tables
-
-A table consists of a header line, a separator line, and at least one row line.
-Table columns are separated by the pipe (|) character. The following example:
-
-@verbatim
-First Header | Second Header
-------------- | -------------
-Content Cell | Content Cell
-Content Cell | Content Cell
-@endverbatim
-
- will produce the following table:
-
-First Header | Second Header
------------- | -------------
-Content Cell | Content Cell
-Content Cell | Content Cell
-
-Column alignment can be controlled via one or two colons at the header separator line:
-
-@verbatim
-| Right | Center | Left |
-| ----: | :----: | :---- |
-| 10 | 10 | 10 |
-| 1000 | 1000 | 1000 |
-@endverbatim
-
-which will looks as follows:
-
-| Right | Center | Left |
-| ----: | :----: | :---- |
-| 10 | 10 | 10 |
-| 1000 | 1000 | 1000 |
-
-@subsection OCCT_DM_SECTION_A_5 Code Blocks
-
-It is recommended to indent a code lines with 4 spaces.
-A fenced code block does not require indentation, and is defined by a pair of "fence lines".
-Such line consists of 3 or more tilde (~) characters on a line.
-The end of the block should have the same number of tildes. Here is an example:
-
-~~~~~~~~~~~~~~~~~~~~~~~
- a one-line code block
-~~~~~~~~~~~~~~~~~~~~~~~
-
-By default the output is the same as for a normal code block.
-To highlight the code, the developer has to indicate the typical file extension,
-which corresponds to the programming language, after the opening fence.
-For highlighting according to the C++ language, for instance, write the following code (the curly braces and dot are optional):
-
-@verbatim
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
- int func(int a,int b) { return a*b; }
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-@endverbatim
-
-which will produce:
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
- int func(int a,int b) { return a*b; }
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Verbatim content can be written by using framing \@verbatim \@endverbatim . For instance
-
-@verbatim
- verbatim text
-@endverbatim
-
-@subsection OCCT_DM_SECTION_A_6 References
-
-To insert a reference to a website, it is proposed to write a URL. For example: http://en.wikipedia.org
-To insert a reference to another part of the same document, the developer can write:
-
-@verbatim
- @htmlonly
- <a href="#OCCT_DOC_SECTION_5">Doxygen Configuration file</a>
- @endhtmlonly
-@endverbatim
-
-to get a link to paragraph : @htmlonly <a href="#OCCT_DOC_SECTION_5">Doxygen configuration</a> @endhtmlonly
-
-@subsection OCCT_DM_SECTION_A_7 Images
-
-To insert image into document the developer can write the following code(in Doxygen-style):
-@verbatim
-
-@endverbatim
-
-This code tells Doxygen to insert a picture right in the place this code was written. Like this:
-@verbatim
-
-@endverbatim
-
-
-
-@subsection OCCT_DM_SECTION_A_8 Table Of Contents
-
-To get the table of contents at the beginning of the document, write \@tableofcontents tag.
-But it is not needed now because TreeView option for HTML is used.
-The TOC in the PDF document will be generated automatically.
-
-@subsection OCCT_DM_SECTION_A_9 Formulas
-
-Formulas within documents will be generated using MathJax tool.
-
-A developer has to specify these parameters in Doxyfile to enable support of MathJax in Doxygen:
-
- USE_MATHJAX = YES
- MATHJAX_FORMAT = HTML-CSS
- MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest
- MATHJAX_EXTENSIONS = TeX/AMSmath TeX/AMSsymbols
-
-To use MathJax tool with the HTML page, it's \<head\> block has to contain
-
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.html}
- <script type="text/x-mathjax-config">
- MathJax.Hub.Config({
- tex2jax: {inlineMath: [["$","$"],["\\(","\\)"]]},
- displayAlign: "left"
- });
- </script>
-
- <script type="text/javascript"
- src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
- </script>
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-First script configures MathJax to understand separator types and to left allign formulas.
-The second script inserts reference to MathJax tool.
-This tool will always be used when the HTML output will be shown.
-
-Equations can be written by several ways:
-
-1.Unnumbered displayed formulas that are centered on a separate line.
-These formulas should be put between \@f\[ and \@f\] tags. An example:
-
-@verbatim
-@f$[
- |I_2|=\left| \int_{0}^T \psi(t)
- \left\{
- u(a,t)-
- \int_{\gamma(t)}^a
- \frac{d\theta}{k(\theta,t)}
- \int_{a}^\theta c(\xi)u_t(\xi,t)\,d\xi
- \right\} dt
- \right|
-@f$]
-@endverbatim
-
-gives the following result:
-
- @f$
- |I_2|=\left| \int_{0}^T \psi(t)
- \left\{
- u(a,t)-
- \int_{\gamma(t)}^a
- \frac{d\theta}{k(\theta,t)}
- \int_{a}^\theta c(\xi)u_t(\xi,t)\,d\xi
- \right\} dt
- \right|
- @f$
-
-2.Formulas can also be put between @verbatim \begin{align} @endverbatim and @verbatim \end{align} @endverbatim tags. An example:
-
-@verbatim
- \begin{align}
- \dot{x} & = \sigma(y-x) \\
- \dot{y} & = \rho x - y - xz \\
- \dot{z} & = -\beta z + xy
- \end{align}
-@endverbatim
-
- gives the following result:
-@latexonly
- \begin{align}
- \dot{x} & = \sigma(y-x) \\
- \dot{y} & = \rho x - y - xz \\
- \dot{z} & = -\beta z + xy
- \end{align}
-@endlatexonly
-
-@htmlonly
- \begin{align}
- \dot{x} & = \sigma(y-x) \\
- \dot{y} & = \rho x - y - xz \\
- \dot{z} & = -\beta z + xy
- \end{align}
-@endhtmlonly
-
-3.Inline formulas can be specified using this syntax:
-
-@verbatim
- @f$ \sqrt{3x-1}+(1+x)^2 @f$
-@endverbatim
-
- that leads to the following result: @f$ \sqrt{3x-1}+(1+x)^2 @f$
-
-@section OCCT_DM_SECTION_B Appendix 2: Doxygen Configuration
-
-@subsection OCCT_DM_SECTION_B_1 Doxygen Configuration File
-
-To generate documentation from "source" *.md files a developer can use file OCCT.doxyfile,
-which is located in /docs directory of OCCT (more information can be found at @htmlonly
-<a href="#OCCT_DM_SECTION_X_X_X">Directory Structure</a> @endhtmlonly paragraph)
-or create his own configuration file, called "Doxyfile". The configuration file may look as follows:
-
-@verbatim
- DOXYFILE_ENCODING = UTF-8
- PROJECT_NAME = "OCCT User's Guides"
- PROJECT_NUMBER = 1.0.1
- PROJECT_LOGO = "D:/OS/OCCT/docs/OCCT_logo.png"
- OUTPUT_LANGUAGE = English
- TAB_SIZE = 4
- MARKDOWN_SUPPORT = YES
- AUTOLINK_SUPPORT = NO
- SHOW_FILES = NO
- WARNINGS = YES
- WARN_IF_UNDOCUMENTED = YES
- WARN_IF_DOC_ERROR = YES
- WARN_NO_PARAMDOC = NO
- WARN_FORMAT = "$file:$line: $text"
- INPUT = "D:/OS/OCCT/docs/"
- INPUT_ENCODING = UTF-8
- FILE_PATTERNS = *.md
- RECURSIVE = YES
- IMAGE_PATH = tmp
- GENERATE_HTML = YES
- SEARCHENGINE = NO
- HTML_OUTPUT = html
- HTML_FILE_EXTENSION = .html
- HTML_HEADER = "static/header.html"
- HTML_FOOTER = "static/footer.html"
- HTML_STYLESHEET = "static/general.css"
- HTML_EXTRA_STYLESHEET = "static/styles.css"
- HTML_COLORSTYLE_HUE = 220
- HTML_COLORSTYLE_SAT = 100
- HTML_COLORSTYLE_GAMMA = 80
- HTML_TIMESTAMP = YES
- HTML_DYNAMIC_SECTIONS = NO
- HTML_INDEX_NUM_ENTRIES = 100
- GENERATE_LATEX = YES
- GENERATE_RTF = YES
-@endverbatim
-
-@subsection OCCT_DM_SECTION_B_2 Doxygen Output Customization
-
-The customization of the output files, produced by Doxygen, can be made by using different Doxyfile parameters,
-like HTML_COLORSTYLE_SAT, which specifies one of HSV color component of HTML page header, and also by using DoxygenLayout xml file.
-A developer can use default file from /docs directory or generate his own with doxygen -l command. It may looks as follows:
-
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.xml}
-<doxygenlayout version="1.0">
- <!-- Generated by doxygen 1.8.3.1 -->
- <!-- Navigation index tabs for HTML output -->
- <navindex>
- <tab type="mainpage" visible="yes" title="Introduction"/>
- <tab type="pages" visible="yes" title="Documents" intro=
- "This section contains links to all OCCT documents that are available at the moment"/>
- <tab type="modules" visible="no" title="" intro=""/>
- <tab type="namespaces" visible="no" title="">
- <tab type="namespacelist" visible="no" title="" intro=""/>
- <tab type="namespacemembers" visible="no" title="" intro=""/>
- </tab>
- <tab type="classes" visible="no" title="">
- <tab type="classlist" visible="no" title="" intro=""/>
- <tab type="classindex" visible="$ALPHABETICAL_INDEX" title=""/>
- <tab type="hierarchy" visible="no" title="" intro=""/>
- <tab type="classmembers" visible="no" title="" intro=""/>
- </tab>
- <tab type="files" visible="yes" title="Files">
- <tab type="filelist" visible="yes" title="" intro=""/>
- <tab type="globals" visible="yes" title="" intro=""/>
- </tab>
- <tab type="examples" visible="no" title="" intro=""/>
- </navindex>
- ...
-</doxygenlayout>
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The tag \<tab\> specifies tabs which appear at the head of each html page. For the OCCT user documentation
- "mainpage" and "pages" tabs are usually needed and their visible parameter should always be "yes".
-The visibility of other tabs should be set to "no".
-
-Developers can find more information about Doxygen configuration in the help file
-or at http://www.stack.nl/~dimitri/doxygen/manual/
-
-@subsection OCCT_DM_SECTION_B_3 Doxywizard Usage
-
-The easiest way of applying and modification of Doxyfile is to use a Doxywizard application,
-which is usually a part of the Doxygen tool. To apply a configuration file, the developer should
-select "Open..." item of the File menu or press Ctrl + O. Modification of Doxyfile can be made
-using "Wizard" or "Expert" tabs of Doxywizard application.
-
-Developers can find more information about Doxywizard usage in the help file or at
-http://www.stack.nl/~dimitri/doxygen/manual/doxywizard_usage.html.
Names begin, end, data, parse.rules, grids.list, cases.list are reserved.
General layout of test scripts is shown on Figure 1.
-
+@image html /dev_guides/tests/images/tests_image001.png
+@image latex /dev_guides/tests/images/tests_image001.png
Figure 1. Layout of tests folder
-WOK {#dev_guides__wok}
-=========
+Workshop Organisation Toolkit {#dev_guides__wok}
+==============================
-WOK is a legacy build environment for Open CASCADE Technology. It is required
-for generation of header files for classes defined with @ref ug_cdl "CDL"
-("Cascade Definition Language"). Also tools for generation of project files
-for other build systems, and OCCT documentation, are integrated to WOK.
+@section occt_wok_1_ Introduction Glossary
-WOK thus is needed in the following situations:
-- Building from OCCT sources from Git repository (do not contain generated files)
-- Building after some changes made in CDL files
+@subsection occt_wok_1_1 About the Development Environment
-Before installing and using WOK, make sure that you have installed a compiler (it is assumed that it is Visual Studio on Windows or gcc on Linux and MacOS) and third-party components required for building OCCT.
+Open CASCADE Technology (**OCCT**) development environment is able to accommodate large numbers of developers working on a variety of products. Within this environment developers can produce multiple versions of products for various hardware and software platforms, including versions corresponding to particular marketing requirements. At the same time, OCCT development environment enables the maximum possible reuse of software components. In other words, OCCT development environment is designed to facilitate industrial scale development.
+@subsection occt_wok_1_2 Brief Overview of Open CASCADE Technology Development Environment
+The following diagram shows OPEN CASCADE tools and resources, the development method, and the architecture of applications that you can develop with Open CASCADE Technology.
-@section wok1 Installing WOK
+@image html /dev_guides/wok/images/wok_image005.png "Schematic View of OCCT Development Platform"
+@image latex /dev_guides/wok/images/wok_image005.png "Schematic View of OCCT Development Platform"
- Download the latest version of binary distribution WOK from http://dev.opencascade.org/index.php?q=home/resources
+The application developer goes about creating his application by editing his source code and producing the final application using a set of intelligent construction tools. These tools are available within a structured development environment called the **software factory**.
-@subsection wok11 Windows
+The developer defines new software components in CDL, Component Description Language, and uses a CDL compiler to derive their C++ implementations. These components are then compiled into packages.
+@subsection occt_wok_1_3 WOK Components
+@subsubsection occt_wok_1_3_1 Entities
+The WOK environment is made up of entities, for example software factories and development units. A full list of WOK entities is provided in the <a href="#occt_wok_1_4">Glossary</a> section.
+@subsubsection occt_wok_1_3_2 Files
+WOK manages two different types of files: user source files and WOK administration files. To support this, each entity has a home directory, which contains its administration directory. This is called *adm* and stores the administration files that WOK needs. In addition development units have a source directory called *src*, which contains both .cdl and .cxx source files, and a header file directory called *inc*, which contains .hxx files.
- Run the installer. You will be prompted to read and accept the OCCT Public License to proceed:
-
- 
-
- Click Next and proceed with the installation.
- At the end of the installation you will be prompted to specify the version and the location of Visual Studio to be used, and the location of third-party libraries:
-
- 
+@subsection occt_wok_1_4 Glossary
+@subsubsection occt_wok_1_4_1 Development Units
+A **development unit** is the smallest unit that can be subject to basic development operations such as modifying, compiling, linking and building.
+The following list contains all types of development units. The letter in parentheses indicates the letter key by commands such as *ucreate* and *umake*. In the rest of the manual, this letter key is referred to as the *short key*.
+* package (p) A set of related classes and methods along with their CDL definitions.
+* schema (s) A set of persistent data types.
+* executable (x) An executable is used for unit and integration test purposes. It is based on one or more packages.
+* nocdlpack (n) A package without a CDL definition. Used for low-level programming or for incorporating foreign resources.
+* interface (i) A specific set of services available for wrapping (an interface contains packages, classes, and methods).
+* jni (j) A development unit used to wrap C++ classes to Java. It is based on one or more interfaces.
+* toolkit (t) A set of packages. Useful in grouping packages together when there is a large number of packages based around a particular subject.
+* delivery (d) A development unit for publishing development units.
+* resource (r) A development unit containing miscellaneous files.
+
+@subsubsection occt_wok_1_4_2 Workbenches
+A workbench is a specialized directory structure where the user creates, modifies, and uses development units. A workbench is likely to be the personal property of one user or at most a small team of developers.
+@image html /dev_guides/wok/images/wok_image006.png "Schema of a Workbench Containing three Development Units"
+@image latex /dev_guides/wok/images/wok_image006.png "Schema of a Workbench Containing three Development Units"
+
+@subsubsection occt_wok_1_4_3 Workshops
+A workshop is a tree of workbenches. It provides the development team with an independent workspace inside which the complete cycle of software production can be carried out.
+The root workbench is in a valid state and contains the working versions of the development units.
+Development units in a root workbench are visible in its child workbenches.
+
+For example, the schema below shows a workshop containing three workbenches. Workbenches B and C are the children of workbench A. Development units in A are visible in both B and C
+@image html /dev_guides/wok/images/wok_image007.png "Workbenches"
+@image latex /dev_guides/wok/images/wok_image007.png "Workbenches"
+
+Workshops are fully independent of each other. They are organized in such a way that development units can be grouped into a delivery and placed in a warehouse. Communication between workshops is carried out by means of these deliveries. A warehouse belongs to a factory and is visible from all workshops in that factory. In this way, development units can be shared between a group of development teams.
+
+@image html /dev_guides/wok/images/wok_image008.png "Two Workshops Delivering and Borrowing Parcels"
+@image latex /dev_guides/wok/images/wok_image008.png "Two Workshops Delivering and Borrowing Parcels"
+
+@subsubsection occt_wok_1_4_4 Factories
+A factory is a set of workshops and their corresponding warehouse. There is a single warehouse in any factory. The continuous upgrading and improvement of a product is carried out in a specific factory.
+To create a new version of an application within the factory, you establish a new workshop dedicated to creation and support of the new version.
+
+@image html /dev_guides/wok/images/wok_image009.png "Factory Contains Workshops and Warehouse"
+@image latex /dev_guides/wok/images/wok_image009.png "Factory Contains Workshops and Warehouse"
+
+@section occt_wok_2_ Elements of the Platform
+@subsection occt_wok_2_1 Development Units
+A **development unit** is the basic element of WOK development. It includes the following three entities:
+ * A directory structure (a minor component)
+ * Source files, also called primary files
+ * The result of the build process (compilation, etc.), also called derived files.
+
+@subsubsection occt_wok_2_1_1 Directory Structure of a Development Unit
+The directory structure of a development unit consists of a tree of directories, which are created when the development unit is initialized. Refer to the <a href="#occt_wok_2_2">Workbenches</a> section for further details on the workbench structure.
+@subsubsection occt_wok_2_1_2 Files in a Development Unit
+
+#### Source Files
- You can change these settings at any time later. For this click on the item "Customize environment (GUI tool)" in the WOK group in the Windows Start menu.
+Source files are written by the developer in the source section (the *src* directory) of the development unit.
+Each development unit maintains the description of its own source files, and this description is stored in one or more files within the *src* directory. The details of how the description is stored vary according to development unit type as shown below:
+* package (p) The names of all source files are worked out from the CDL description, following the conventions described in the *C++ Programming Guide*. This list of files can be supplemented by additional files listed in the file called FILES. This file must be stored in the unit’s src directory. Whenever header files are included in the *src* directory of a development unit, they must be specified in FILES so that the C++ preprocessor will take them into account. This reduces compilation time by 10 to 40 percent.
+* schema (s) No description of the source files is needed. There is a single source file: *schema.cdl*.
+* executable (x) The names of all source files are worked out from the CDL description. The format of this file is described in the <a href="#occt_wok_3_5">Building an Executable</a> section.
+* nocdlpack (n) The list of source files is contained in the FILES file stored in the unit’s src directory.
+interface (i). No description of the source files is needed. There is a single source file: *interface.cdl*.
+* jni (j). No description of the source files is needed. There is a single source file: *jni.cdl*.
+* toolkit (t) The description is given by the file called PACKAGES which is stored in the unit’s src directory. FILES must also exist in this directory, and must include PACKAGES in its list of files.
+* delivery (d) The description is given by two files stored in the unit’s src directory: FILES and a file called COMPONENTS. FILES must include COMPONENTS in its list of files.
+* resource (r) A resource unit is used in a delivery. FILES contains a list of the unit’s files, one per line in the following format: *atype:::afilename* Here, *filename* is the name of a file, which the compiler will look for in the src directory of the unit, and *atype* is a WOK type. To display a list of all available WOK types, use the command: *wokinfo -T*.
+
+#### Derived files
+
+Derived files created by compilation are automatically placed in the derived section of the development unit. These may be executable files or archives of compilation results.
+
+@subsubsection occt_wok_2_1_3 Package
+A package is a development unit that defines a set of classes, which share a number of common features such as similar data structure or a set of complementary algorithmic services. Packages help to manage creation and the use of large hierarchies of software components.
+To create a package, you write a .cdl file describing it in the src directory of the package development unit. The description includes classes and global methods, which comprise it. Each class is also described in a separate .cdl file. The package .cdl file also lists the packages used in the specification of its classes and methods.
+C++ implementation files are also stored in the src subdirectory of the package development unit. These implementation files are:
+ * .cxx for an ordinary class
+ * .lxx for any inline methods
+ * .pxx for any private declarations
+ * .gxx for a generic class
- The shortcuts from this group provide two ways to run WOK:
- * In command prompt window ("WOK TCL shell").
- * In Emacs editor ("WOK Emacs"). Using Emacs is convenient if you need to work within WOK environment.
+To create the Development Unit structure for a package use the following syntax:
+~~~~~
+ucreate –p MyPackage
+~~~~~
- By default WOK installer creates a WOK factory with name "LOC" within workshop "dev" (WOK path :LOC:dev).
+The package description has the following CDL syntax:
+~~~~~
+package PackageName
+[uses AnotherPackage {‘,’ YetAnotherPackage}]
+is
+[{type-declaration}]
+[{package-method}]
+end [PackageName]’:’
+~~~~~
-@subsection wok12 Linux
+For example:
+~~~~~
+package CycleModel
+uses
+Pcollection
+Tcollection
+BREpPrimAPI
+TopExp
+Geom
+Pgeom
+is
+deferred class Element;
+class Wheel;
+class Frame;
+class LocalReference;
+Adjust(awheel: wheel from CycleModel;
+ aframe: Frame from CycleModel);
+end CycleModel;
+~~~~~
+For full details on the CDL syntax, refer to the *CDL User’s Guide*.
- * Unpack the .tgz archive containing WOK distributive into an installation directory <WOK_INSTALL_DIR>.
+@subsubsection occt_wok_2_1_4 Schema
- * Perform the following commands assuming that you have unpacked WOK distributive archive into <WOK_INSTALL_DIR>:
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
- cd <WOK_INSTALL_DIR>/site
- wok_confgui.sh
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
- Define all necessary paths to third-party products in the dialog window:
+A schema is a development unit that defines the set of all data types, which your application is likely to need in order to read and write files. Such data types are **persistent**.
+
+To create a schema, write a .cdl file that lists all the packages, which contain all persistent data types used by the application. Note that only persistent classes are taken into account during compilation; transient classes are ignored.
+
+Note that you don’t have to put dependencies in all packages and classes. You only have to write the highest level dependencies. In other words, the *uses* keyword in the schema file allows you to list packages. Any package similarly listed in the package files for these packages are also incorporated into the schema.
+
+To create the Development Unit structure for a schema use the syntax below:
+~~~~~
+ucreate –s MySchema
+~~~~~
+
+The schema description has the following CDL syntax :
+
+~~~~~
+schema SchemaName
+is
+ListOfPackagesContainingPersistentClasses;
+ListOfPersistentClasses;
+end;
+~~~~~
+
+For example:
+~~~~~
+schema MyCycleSchema
+is
+class Wheel from package CycleModel;
+class Frame from package CycleModel;
+..
+class Spanner from package CycleTools;
+end;
+~~~~~
+For full details on the CDL syntax, refer to the *CDL User’s Guide*.
+
+@subsubsection occt_wok_2_1_5 Executable
+The purpose of an executable is to make executable programs. The executable can use services from one or more packages and is described in a .cdl file as a set of packages.
+
+To create an executable, you write one or more MyExe.cxx files in the src subdirectory of the unit. This file will contain the main function. Then it is possible to compile the executable.
+
+To create the Development Unit structure for an executable, use the syntax below:
+~~~~~
+ucreate –x MyExec
+~~~~~
+
+The executable description has the following CDL syntax:
+~~~~~
+executable ExecName
+is
+executable BinaryFile
+uses
+LibFile as external
+is
+C++File;
+end;
+end;
+~~~~~
+
+For example:
+~~~~~
+executable MyExecUnit’
+is
+executable myexec
+uses
+Tcl_Lib as external
+is
+myexec;
+end;
+executable myex2
+is
+myex2;
+end;
+end;
+~~~~~
+For full details on the CDL syntax, refer to the *CDL Reference Manual*.
+
+@subsubsection occt_wok_2_1_6 Toolkit
+A toolkit is a development unit that groups a set of packages to create a shareable library. An example of a toolkit is the ModelingData module. Toolkits serve for the following purposes:
+ * Linking of large numbers of packages
+ * Faster loading of executable files that use toolkits such as test files.
- 
+A toolkit has no CDL definition. Creating a toolkit involves writing a PACKAGES file in the src subdirectory of its development unit. This file lists all the packages needed in the toolkit. You then create a definition of this file to the FILES.
+
+You then compile the toolkit to create a shareable library.
+
+@subsubsection occt_wok_2_1_7 Nocdlpack
+A nocdlpack is a development unit that has no CDL definition. It is compiled directly from source files written in C, C++, Fortran, or in sources to be treated by the lex or yacc tools. A nocdlpack is useful when you write a low-level interface with another product, for example, a network application.
+
+To define a nocdlpack, you create a file called FILES in the src subdirectory of the nocdlpack development unit. In this file, you list the Fortran, C, C++, lex, and yacc files that compose the pack. You list the files one per line.
+
+On compilation, the result is a shareable library.
+
+@subsubsection occt_wok_2_1_8 Interface
+An interface is a development unit that defines a set of services available for wrapping into Java.
+An interface is defined in a .cdl file as a list of packages, package methods, classes, and methods. It makes these available to a jni unit.
+
+To create the Development Unit structure for an interface, use the syntax below:
+~~~~~
+ucreate -i MyInterface
+~~~~~
+
+The interface description has the following CDL syntax:
+
+~~~~~
+interface InterfaceName
+is
+ListOfPackages
+ListOfClasses
+ListOfMethods
+end;
+~~~~~
+
+For example:
+~~~~~
+interface MyInterface
+is
+ package TopoDS;
+ class Shape from ShapeFix;
+end ;
+~~~~~
+
+@subsubsection occt_wok_2_1_9 Jni
+A jni is a development unit that wraps declared services into Java using JNI (Java Native Interface).
+
+A jni creates Java classes that are used as C++ counterparts when developing in Java.
+
+To create the Development Unit structure for an Jni, use the syntax below:
+ucreate -j MyJni
+
+The interface description has the following CDL syntax:
+~~~~~
+client JniName
+is
+{interface InterfaceName;}
+end;
+~~~~~
+
+For example :
+~~~~~
+client MyJni
+is
+ interface MyInterface;
+ interface MyAnotherInterface;
+end ;
+~~~~~
+
+@subsubsection occt_wok_2_1_10 Delivering Parcels
+The delivery process allows creating parcels. These parcels group together the development work done within a given workshop. You can ship these parcels to other workshops called client workshops.
+
+A delivery is autonomous. Once the delivery development unit is compiled, a parcel is stored in the factory warehouse and has no more connection with the workshop where it was created. A parcel has its own directory structure.
+
+All Open CASCADE Technology resources are seen as parcels.
+
+@image html /dev_guides/wok/images/wok_image010.png "Parcels"
+@image latex /dev_guides/wok/images/wok_image010.png "Parcels"
+
+You create a delivery unit under a specified workbench.
+
+You are **strongly advised** to create delivery units under the *root* workbench of the workshop. Child workbenches could be deleted in the future, whereas the root workbench is likely to remain untouched. In other words, you safeguard the delivery by creating it in the root workbench.
+
+**Note** If you do not specify a workbench when you make a delivery, it is created under the current workbench.
- * Run the following commands to create WOK LOC factory:
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
- cd <WOK_INSTALL_DIR>/site
- wok_init.sh
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
- * Your installation procedure is over. To run WOK use one the following commands:
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
- cd <WOK_INSTALL_DIR>/site
- wok_emacs.sh
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- or
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
- cd <WOK_INSTALL_DIR>/site
- wok_tclsh.sh
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-@subsection wok13 Mac OS X
-
- * In the Finder double click on wokSetup.dmg file. This will open a new window. Drag and drop "wokSetup" folder from this window at the location in the Finder where you want to install WOK, i.e. <WOK_INSTALL_DIR>.
-
- * Browse in the Finder to the folder <WOK_INSTALL_DIR>/site and double click on WokConfig. This will open a window with additional search path settings. Define all necessary paths to third-party products in the dialog window:
-
- 
+@subsection occt_wok_2_2 Workbenches
+A workbench is generally the place where one particular developer or a team of developers works on a particular development. A workbench is composed of a public part and a private part.
+
+@subsubsection occt_wok_2_2_1 Roots
+The following roots are used in the structure of a workbench:
+* **Home** Workbench root containing various administration files of the workbench.
+* **Src** Root of the workbench sources, which facilitates the integration into WOK of version management software such as CVS.
+* **DBMS** Root of the derived files dependent on the extraction profile (.hxx, _0.cxx files, etc.).
+* **DBMS_Station** Roots of the derived files dependent on the extraction profile and on the platform (.o, .so files, etc.).
+
+Roots are defined for each profile and platform supported by the workbench. For example, a workbench supporting the DFLT profile on Sun and SGI platforms has the following roots:
+* **Home** Workbench root,
+* **Src** Root of the source files,
+* **DFLT** Root of the derived files,
+* **DFLT_sun** Root of the files built on Sun platforms,
+* **DFLT_sil** Root of the files built on SGI platforms,
+
+For a workbench additionally supporting *ObjectStore*, the following additional roots are also found: *OBJS, OBJS_sun, OBJS_sil*.
+
+These roots are defined in the workbench definition file *MyWorkbench.edl* as the parameter <i>\%MyWorkbench_RootName</i>.
+
+**Note** that default values help to define various roots.
- * Run the following commands to create WOK LOC factory:
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
- cd <WOK_INSTALL_DIR>/site
- wok_init.sh
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsubsection occt_wok_2_2_2 Directories
+Under each root, a hierarchy of directories allows to store various files.
+* Under the Home root are found:
+ * *work*, the private workbench directory reserved for the developer
+ * *Adm*, the directory reserved for administration files.
+* Src contains:
+ * *src/MyUD*, the directory containing the source files of the development unit MyUD.
+* DBMS contains:
+ * *inc*, containing the public header files of the workbench UDs
+ * *drv/MyUD*, containing the private extracted files of MyUD
+ * *drv/MyUD/.adm*, containing the administration files dependent on the extraction profile
+ * *drv/MyUD/.tmp*, containing the temporary files dependent on the extraction profile.
+* DBMS_Station contains:
+ * *<station>/lib* with all the libraries produced in the workbench
+ * *<station>/bin* with all the binaries produced in the workbench
+ * *<station>/MyUD* with all the station dependent files which are private to the development unit such as objects
+ * *<station>/MyUD/.adm* with all the station dependent administration files
+ * *<station>/MyUD/.tmp* with all the temporary files constructed in the development unit.
+
- * Your installation procedure is over. To run WOK in Emacs navigate in the Finder to the folder <WOK_INSTALL_DIR>/site and double click on WokEmacs.
+@image html /dev_guides/wok/images/wok_image011.png "Structure of the workbench Mywb"
+@image latex /dev_guides/wok/images/wok_image011.png "Structure of the workbench Mywb"
+@subsection occt_wok_2_2_3 Workshops
+A **workshop** is an independent workspace inside which the complete cycle of software production is carried out. Workbenches inside a workshop are organized so that development units can be shared either by being published in a father workbench or by being placed in reference in the root workbench.
+
+@image html /dev_guides/wok/images/wok_image012.png "Visibility between Workbenches in a Workshop"
+@image latex /dev_guides/wok/images/wok_image012.png "Visibility between Workbenches in a Workshop"
-@section wok2 Initialization of Workbench
+In this image:
+ * **A** is the development unit A from Grandchild 11 placed in reference in root. It is visible throughout the workshop.
+ * **B** is the development unit B from Grandchild 12 published in ancestor Child 1. It is visible to Child 1, Grandchild 11 and Grandchild 12.
- To start working with OCCT, clone the OCCT Git repository from the server (see http://dev.opencascade.org/index.php?q=home/resources for details) or unpack the source archive.
-
- Then create a WOK workbench (command wcreate) setting its Home to the directory, where the repository is created ($CASROOT variable). The workbench should have the same name as that directory.
+
+In a large-scale development that involves one or more teams of developers, you should decide how you are going to structure a workshop right at the beginning. If need be, you can review your decision later.
+
+An existing workshop can be duplicated and the original workshop can be used as the basis for maintaining the present version of a product. The new workshop can then be used to develop and maintain a new version of the product.
+
+When creating a new workshop, you specify - in the form of parcels – which resources are to be available within the workshop.
+
+@subsection occt_wok_2_2_4 Factories
+A factory contains a number of workshops and a warehouse. When Open CASCADE Technology is installed, the system administrator creates a single factory. This contains a single workshop as well as the warehouse containing OCCT resources in the form of parcels.
+
+There is no theoretical limit to the number of workshops that can be added to a factory. However, a single factory should be enough.
+
+@section occt_wok_3 Development Process
+@subsection occt_wok_3_1 WOK Environment
+The WOK interface is based on tcl, a command language provided by the Regents of the University of California and Sun Microsystems, Inc. The WOK development environment is in fact a tcl session.
+
+
+Before you run a tcl session you must make sure that your account is configured for using tcl, see the <a href="#occt_wok_8_3">Configuring Your Account for Tcl and WOK</a> section.
+
+To start a tcl session use the command:
+~~~~~
+% tclsh
+~~~~~
+Within this session, all WOK commands are available as well as standard tcl commands. You can also use tcl language extensions, if these are installed.
+To exit from a tcl session use the command:
+~~~~~
+> exit
+~~~~~
+Online help is provided with tcl. To access this, use the following command:
+~~~~~
+% tclhelp
+~~~~~
+Online help is also available for all WOK commands. To display help on a particular WOK command, give the command name followed by the -h flag, as in the following example:
+~~~~~
+> wokcd -h
+~~~~~
+
+@subsection occt_wok_3_2 Steps
+Implementation of an application is based on the following steps:
+1. Enter the software factory using the command wokcd MyFactory
+2. Enter a workshop using the command wokcd MyWorkshop
+3. Open a workbench using the command wokcd MyWorkbench
+4. Search for the data types required among the existing OCCT libraries
+5. Define one or more packages which will contain the classes
+6. Define new data types as classes
+7. Implement the methods of those classes in C++
+8. Implement any package methods in C++
+9. Unite the test packages
+10. Define any nocdlpacks (if any)
+11. Test the components
+
+**Note:** Steps 1-3 can be performed with a single WOK command:
+~~~~~
+> wokcd MyFactory:MyWorkshop:MyWorkbench
+~~~~~
+
+@subsection occt_wok_3_3 Getting Started
+@subsubsection occt_wok_3_3_1 Entity Names
+Before you start, the following restrictions on WOK entity names must be noted:
+ * Entity names may only contain alphanumeric characters and dashes.
+ * Entity names must be unique within a hierarchy. For example, you must not have two workbenches called MyBench in the same Workshop. Likewise, you may not have a workshop called CSF in a factory of the same name.
+ * Do not use upper and lower case characters to distinguish between two entity names, for example ENT1 and eNt1. This restriction is for reasons of portability.
+ * Parcel names must be unique.
- For example, assuming that OCCT repository has been cloned into D:/occt folder:
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
- LOC:dev> wcreate occt -DHome=D:/occt
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+@subsubsection occt_wok_3_3_2 Entering the Factory
+When you start work you go to the factory using the following command:
+~~~~~
+> wokcd <MyFactory>
+~~~~~
+@subsubsection occt_wok_3_3_3 Creating a New Workshop
+If you don’t want to work in a workshop already present in the factory, you can create a new one. To do this, use the following command:
+~~~~~
+> screate –d <MyWorkshop>
+~~~~~
+This creates the new workshop **MyWorkshop** in the current factory. To create the same workshop in a different factory use the syntax below:
+~~~~~
+> screate –d <MyFactory:MyWorkshp>
+~~~~~
+
+When you create a new workshop, it is empty.
+
+@subsubsection occt_wok_3_3_4 Selecting Parcels
+When you create a workshop, you select existing OCCT resources, for example, parcels, to use in it. To do this, you create the workshop and add the parcels using the following syntax:
+~~~~~
+> screate –d <MyWorkshop> -DparcelConfig=Parcel1,Parcel2…
+~~~~~
+To display available OCCT resources, in other words, to see what parcels are available, you use the following command:
+~~~~~
+Winfo –p <WarehouseName>
+~~~~~
+**Note:** parcel configuration rarely needs to change. If it does, only the workshop administrator should make them.
+@subsubsection occt_wok_3_3_5 Opening a Workshop
+To open a workshop, you use the following command:
+~~~~~
+> wokcd <MyWorkshop>
+~~~~~
+@subsubsection occt_wok_3_3_6 Creating a New Workbench
+When you create a new workshop, it is empty. In other words, it does not contain any workbenches.
+To create the root workbench of a new workshop, you use the following command:
+~~~~~
+> wcreate -d <MyWorkbench>
+~~~~~
+This creates a tree of workbench subdirectories.
+If workbenches already exist in your workshop, but you do not want to work in any of these, create a new workbench as a child of an existing one. You do this using the following syntax:
+~~~~~
+> wcreate –d <MyWorkbench> -f <ParentWorkbench>
+~~~~~
+@subsubsection occt_wok_3_3_7 Opening a Workbench
+To open a workbench, you use the command below:
+~~~~~
+> wokcd <MyWorkbench>
+~~~~~
+This automatically takes you to the root directory of the workbench
+
+@subsubsection occt_wok_3_3_8 Using Existing Resources
+Before creating new data types, you should look for existing components that you can reuse. In particular, you should look through the existing resources of your Open CASCADE Technology platform to see if any of the required components already exist, or if any existing generic components can be suitably implemented. This search can be conducted using the online documentation. You should note the packages and classes, which you can reuse.
+@subsection occt_wok_3_4 Creating Software Components
+@subsubsection occt_wok_3_4_1 Creating a Package
+To develop new software components, you usually need to create one or more packages. You do this, by using the following command:
+~~~~~
+> ucreate –p <MyPackage>
+~~~~~
+Because the key -p defines the default value for the *ucreate* command, you do not need to specify it. The following syntax, for example, will also create a package:
+~~~~~
+ > ucreate <MyPackage>
+~~~~~
+#### Enter a Package or other Development Unit Structure
+
+Enter the package or any other development unit structure using the *wokcd* command as in the syntax below:
+~~~~~
+> wokcd MyPackage
+~~~~~
+The current directory is now:
+~~~~~
+MyWorkbenchRoot/src/MyPackage
+~~~~~
+
+#### Writing the Package and Class Specifications in CDL
+
+Write the descriptions of the software components in CDL using an editor of your choice. Write each class in its own .cdl file and write one .cdl file (MyPackage.cdl) to specify the package that contains those classes.
+
+#### CDL Compilation of the Package
+
+Compile and check the package and its classes using:
+~~~~~
+ > umake –e xcpp
+~~~~~
+This command also extracts the C++ header files (.hxx) and stores them in the derived files directory.
+
+#### Implementing Methods in C++
+
+A package will contain methods, which may be:
+ * Instance methods
+ * Class methods
+ * Package methods.
+Extract **prototypes** for the C++ methods using the following command:
+~~~~~
+ > umake -o xcpp.fill -o xcpp.template
+~~~~~
+
+You should not confuse this syntax with the template feature of C++ used to implement the genericity.
+The *umake -o xcpp.template* command creates a skeleton C++ file for:
+ * Each class
+ * All the package methods.
+The packages methods will be created in a file called *package.cxx.template*. This command is not included in the umbrella command *MyPackage*.
+You will need to use an editor to implement these methods in C++.
+
+
+#### Compiling the Package
+
+To compile the package, use the command:
+~~~~~
+ > umake -o obj <MyPackage>
+~~~~~
+If you do not specify a package, the current development unit is compiled.
+
+#### Sample Construction of a Package
+
+In the following example a workbench named **MyWb** is created as a child of an existing workbench **Topo**. MyWb is used for working on the package **MyPack**. Commands preceded by an asterisk below are used only once per session:
+1. Create the MyWb workbench as a child of Topo.
+~~~~~
+ > wcreate MyWb -f Topo -d
+~~~~~
+2. Create MyPack in MyWb.
+~~~~~
+ > ucreate MyPack
+~~~~~
+3. Move to the source directory of MyPack.
+~~~~~
+ > wokcd MyPack
+~~~~~
+4. Edit the source files (MyPack.cdl etc.). You do this outside tcl, using the editor of your choice.
+5. Start the extraction of MyPack.
+~~~~~
+ > umake -e xcpp
+~~~~~
+6. Generate the .cxx templates for MyPack: MyPack.cxx.template
+~~~~~
+ > umake -o xcpp.fill -o xcpp.template -t
+~~~~~
+7. Edit the source files (MyPack.cxx etc). You do this outside tcl, using the editor of your choice.
+
+**Note** that *umake* command used without arguments will carry out all the above *umake* steps. You can also use it with specific arguments as above to go through the development process step by step.
+
+#### Package Files
+
+* Primary Files for a Package
+ + <Package>.cdl Primary package file.
+ + <Package>_<Class>.cdl Primary class file.
+* C++ Files for a Package
+ + <Package>.cxx Primary package source file.
+ + <Package>_[1..9[0..9]*].cxx Secondary package source files.
+ + <Package>.lxx Inline package methods source file.
+ + <Package>.pxx Private instructions source file.
+* C++ Files for a Class
+ + <Package>_<Class>.cxx Primary class source file.
+ + <Package>_<Class>_[1..9[0..9]*].cxx
+* Secondary class source files.
+ + <Package>_<Class>.gxx Generic class methods source file. This is an alternative to the .cxx file(s), you do not have both.
+ + <Package>_<Class>.lxx Inline methods source file.
+ + <Package>_<Class>.pxx Private instructions source file.
+* Derived C++ Files for a Package
+ + <Package>.hxx User header file.
+ + <Package>.ixx User header file included in <Package>.cxx.
+ + <Package>.jxx User header file included in <Package>_[1-9].cxx.
+* Derived C++ files for a class
+ + <Package>_<Class>.hxx User header file.
+ + <Package>_<Class>.ixx User header file included in <Package>_<Class>.cxx.
+ + <Package>_<Class>.jxx User header file in <Package>_<Class>_[1..9[0..9]*].cxx.
+ + Handle_<Package>_<Class>.hxx Persistent or Transient class header file.
+ + <Package>_<Class>_0.cxx For instantiated classes.
+
+Umake Steps for a Package
+-------------------------
+The umake steps for development units of package type are explained below.
+* *src* Processes the file *MyPackage.cdl* to generate a list of all the CDL files in the development unit. Processes FILES to list source files.
+* *xcpp.fill* Compiles the internal data structure to prepare for subsequent extractions.
+* *xcpp.src* Lists the source files (.cxx, .gxx, .lxx) deduced from the CDL files.
+* *xcpp.header* Extracts header files for the classes in the development unit.
+* *xcpp.template* Extracts a template for implementation of methods. (Hidden step.)
+* *obj.inc* Based on the list of source files generated by the src and xcpp.src steps, this step publishes the include files for the development unit so that other units can use them.
+* *obj.cgen* Processes the source files to generate code.
+* *obj.comp* Compiles each file that can be compiled.
+* *obj.idep* Generates dependency information for the unit. This comprises:
+ + Includes performed by unit compilation (Unit.MakeState)
+ + Implementation dependencies in terms of the unit suppliers (Unit.ImplDep)
+* *obj.lib* Generates the shared library for the development unit.
+
+@subsubsection occt_wok_3_4_2 Creating a Nocdlpack
+If your executable requires the use of a nocdlpack, create a development unit of nocdlpack type and move to its structure using the commands below:
+~~~~~
+ > ucreate -n <MyNoCDLPack>
+ > wokcd <MyNoCDLPack>
+~~~~~
+Use an editor to write *FILES*, which is a nomenclature file for a nocdlpack. This file must list all the C, C++, Fortran, lex, and yacc sourcs files (one per line).
+Build the nocdlpack using the following command:
+~~~~~
+ > umake [<MyNoCDLPack>]
+~~~~~
+**Note** that a nocdlpack unit is not intended to perform tests. Use an executable unit instead.
+
+
+#### Sample Construction of a Nocdlpack
+
+In the following example a nocdlpack *MyNocdlpack*, is created. Commands preceded by an asterisk below are used only once per session:
+1. \*Create MyNocdlpack in MyWb.
+~~~~~
+> ucreate -n <MyNoCDLPack>
+~~~~~
+2. Move to the source directory of MyNocdlpack.
+~~~~~
+> wokcd <MyNoCDLPack>
+~~~~~
+3. Write the FILES list. You do this outside tcl, using the editor of your choice.
+4. Write the source code.
+5. Build MyNocdlpack.
+~~~~~
+> umake [<MyNoCDLPack>]
+~~~~~
+
+#### Umake Steps for a Nocdlpack
+
+The *umake* steps for development units of *nocdlpack* type are explained below.
+* *src* Processes FILES to list source files.
+* *obj.cgen* Processes the source files to generate code.
+* *obj.inc* Based on the list of source files, this step publishes the header files for the unit so that other units can use them.
+* *obj.comp* Compiles each file that can be compiled.
+* *obj.idep* Generates dependency information for the unit. This comprises:
+ + Includes performed by unit compilation. (Unit.MakeState)
+ + Implementation dependencies in terms of the unit suppliers. (Unit.ImplDep)
+* *obj.lib* Generates the shared library for the unit.
+
+@subsubsection occt_wok_3_3_3 Creating a Schema
+If the application, which you intend to build, stores data in a file, you need to define a schema for the persistent data types that are known.
+
+You create a schema and go to its root directory using the commands:
+~~~~~
+> ucreate -n <MySchema>
+> wokcd <MySchema>
+~~~~~
+Using the editor of your choice, write a .cdl file to define the schema. This schema file lists all the packages that contain persistent data types used in the implementation of your application. It has the following format:
+~~~~~
+ schema MySchema
+ is
+class <MyClass> from <Package>;
+ end;
+~~~~~
+
+#### Building a Schema
+
+Compile and check the coherence of the CDL specification for the schema:
+~~~~~
+> umake -e xcpp.fill
+~~~~~
+Extract the C++ description:
+~~~~~
+> umake -o xcpp
+~~~~~
+Compile the C++ description of the schema:
+~~~~~
+> umake -o obj
+~~~~~
+Alternatively, the above three steps can all be carried out by one command:
+~~~~~
+> umake
+~~~~~
+#### Sample Construction of a Schema
+
+In the following example the schema *MySchema* is created. It contains all the schemas of the persistent classes of your own packages and the packages they depend on. Commands preceded by an asterisk below are used only once per session:
+1. Create MySchema in MyWb.
+~~~~~
+ > ucreate -s MySchema
+~~~~~
+2. Move to the source directory of MySchema.
+~~~~~
+> wokcd MySchema
+~~~~~
+3. Edit the source file MySchema.cdl. You do this outside tcl, using the editor of your choice.
+4. Derive implementation files.
+~~~~~
+ > umake -e xcpp.sch
+~~~~~
+5. Derive application schema files.
+~~~~~
+ > umake -o xcpp.ossg
+~~~~~
+6. Compile the schema.
+~~~~~
+ > umake -o obj
+~~~~~
+
+#### Schema Files
+
+* Primary Files for a Schema
+ + *<Schema>.cdl* Primary schema file.
+* Derived C++ Files for a Schema
+ + *<Schema>.hxx* User header files.
+ + *<Schema>.cxx* Schema implementation files.
+ + *<Sch_MyPack_MyClass>.cxx* Schema implementation files.
+
+#### Umake Steps for a Schema
+
+The umake steps for development units of schema type are explained below.
+* *src* Processes MySchema.cdl to generate a list of CDL files for the development unit. Processes the FILES file to list source files.
+* *xcpp.fill* Compiles the internal data structure to prepare for subsequent extractions.
+* *xcpp.sch* Extracts the schema implementation code.
+* *obj.comp* Compiles the extracted files that can be compiled.
+* *obj.lib* Generates the shared library for the unit.
+* *obj.idep* Generates dependency information for the schema.
+
+@subsection occt_wok_3_5 Building an Executable
+@subsubsection occt_wok_3_5_1 Creating an Executable
+To make an executable from one or more of the packages, which you have created, write a .cdl file to specify the packages to use.
+
+#### Writing an Executable
+
+Refer to the **CDL User’s Guide** for full details. A simple example is given below.
+
+~~~~~
+ executable <MyExec> // the executable unit
+is
+ executable myexec // the binary file
+uses
+Tcl_Lib as external
+is
+ myexec; // the C++ file
+end; // several binaries can be specified in one .cdl file.
+executable myex2
+is
+ myex2;
+end;
+ end;
+~~~~~
+
+Write the C++ file(s). For the example above you write two files: *myexec.cxx* and *myex2.cxx*.
+
+#### Building the Executable
+
+To build the executable, use the command *umake*
+
+#### Construction of an Executable
+
+In the following example an executable, *MyExec*, is created in the workbench *MyWb*. Commands preceded by an asterisk below are used only once per session:
+1. \*Create MyExec in MyWb.
+~~~~~
+ > ucreate -x MyExec
+~~~~~
+2. Move to the source directory of *MyExec*.
+~~~~~
+ > wokcd MyExec
+~~~~~
+3. Edit the cdl source file *MyExec.cdl*. You do this outside tcl, using the editor of your choice.
+4. Edit the C++ files *AnExe.cxx*, etc. You do this outside tcl, using the editor of your choice.
+5. Build MyExec.
+~~~~~
+ > umake
+~~~~~
+6. Run the executable file.
+~~~~~
+ > wokcd -PLib
+ > MyExec
+~~~~~
+
+#### Executable Files
+
+| <Exec>.cdl | primary executable file |
+| <AnExe>.cxx | Source C++ file |
+| <AnExe>_[1-9].cxx | Other source C++ files |
+
+#### Umake Steps for an Executable
+
+The umake steps for development units of executable type are explained below.
+* *src* Processes MyExe.cdl to generate a list of CDL files for the development unit. Processes FILES to list source files.
+* *src.list* Based on MyExe.cdl, works out the list of parts and the source files involved for each part.
+* *exec.comp* Compiles the files that can be compiled for each part of the executable.
+* *exec.idep* Generates dependency information for each part of the executable.
+* *exec.libs* Computes full implementation dependency to prepare for linking for each part of the executable.
+* *exec.tks* Performs toolkit substitution according to TOOLKITS for each part of the executable.
+* *exec.link* Links each part of the executable.
+
+@subsection occt_wok_3_6 Test Environments
+@subsubsection occt_wok_3_3_1 Testing an Executable
+To test an executable, you create an executable development unit and move to its structure.
+
+When you write the .cdl file for your test executable, specify the packages to test, for example:
+~~~~~
+executable MyTest // the executable unit
+ is
+executable mytest1 // the binary file
+is
+ mytest1; //the C++ file
+end; // several binaries can be specified in one .cdl file.
+executable mytest2
+is
+ mytest2;
+end;
+ end;
+~~~~~
+Write the C++ test file(s), in the example, *mytest1.cxx* and *mytest2.cxx*.
+#### Building the Executable
+
+To build the executable use the command:
+~~~~~
+> umake
+~~~~~
+
+#### Setting up a Test Environment
- Note: $CASROOT is equal to D:/occt now
+To set up a test environment, move to the <i>/drv</i> subdirectory that corresponds to the current profile (e.g. <i>/MyExec/drv/DFLT/sun</i>) and run the executable test file.
+~~~~~
+> wokcd -PLib
+> wokenv -s
+> myApp
+~~~~~
+The command *wokenv* is used with -s option to configure the test environment.
+The command *wokenv –s* uses the current workbench to decide what actions are needed to configure the tcl shell for use as your test environment.
+WOK sets the following environment variables:
- Then you can work with this workbench using normal WOK functionality (wprocess, umake, etc.; see WOK User\92s Guide for details) or use it only for generation of derived sources and project files, and build OCCT with Visual Studio on Windows or make command on Linux, as described below.
+* <i>$STATION</i> - The current station.
+* <i>$TARGET_DBMS</i> - The current database platform.
+* <i>$PATH</i> - The current path, plus the bin directories of the parcels.
+* <i>$LD_LIBRARY_PATH</i> The current path, plus the lib directories of the parcels.
+WOK then sets a variable for each parcel listed in the parcel configuration of the current workshop. This variable is the original name of the delivery unit in the uppercase, with the suffix *HOME*.
+* <i>$ORIGDELIVUNITHOME</i> is set as the root directory of the parcel.
+WOK then sources the following files:
+ * MyFactory.tcl, found in the admin directory of the factory.
+ * MyWorkshop.tcl found in the admin directory of the workshop.
+Then for each Workbench, WOK sources according to the hierarchy of the workbenches:
+ * Workbench.tcl, found in the /Adm directory of the workbench.
-@section wok3 Generation of building projects
-
- Use command wgenproj in WOK to generate derived headers, source and building projects files:
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
- LOC:dev> wokcd 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
--no_wprocess - skip generation of derived headers and source files
-
-Note that this command takes several minutes to complete at the first call.
-
-Re-execute this step to generate derived headers, source and building projects files if some CDL files in OCCT have been modified (either by you directly, or due to updates in the repository). Note that in some cases WOK may fail to update correctly; in such case remove sub-directories drv and .adm and repeat the command.
-
-To regenerate derived headers and source files without regeneration of projects use command:
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
- LOC:dev> wokcd occt
- LOC:dev:occt> wprocess -DGroups=Src,Xcpp
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The generated building project has been placed into $CASROOT/adm folder:
- * for vc8 - $CASROOT/adm/msvc/vc8
- * for vc9 - $CASROOT/adm/msvc/vc9
- * for vc10 - $CASROOT/adm/msvc/vc10
- * for vc11 - $CASROOT/adm/msvc/vc11
- * for cbp - $CASROOT/adm/<OS> /cbp
- * for cmake - $CASROOT/adm/cmake
- * for amk - $CASROOT/adm/lin/amk
- * xcd - $CASROOT/adm/<OS>/xcd
-
-@section wok4 Generation of documentation
-
- Use command wgendoc in WOK to generate reference documentation:
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
- :LOC:dev> wokcd occt
- :LOC:dev:occt> wgendoc
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The following options can be used:
- * -wb=< workbench name > the name of OCCT workbench (the current one by default);
- * -m=< list of modules > the list of modules that will be contained in the documentation;
- * -outdir=< path > the output directory for the documentation;
- * -chm the option to generate CHM file;
- * -hhc=< path > the path to HTML Help Compiler (hhc.exe) or equivalent;
- * -qthelp=< path > the option to generate Qt Help file, it is necessary to specify the path to qthelpgenerator executable;
- * -doxygen=< path > the path to Doxygen executable
- * -dot=< path > the path to GraphViz dot executable
\ No newline at end of file
+After the environment is set up, you are at a C shell prompt and can run the executable.
+
+**Note** Environment variables are only set when the command is used with the option <i>-s</i>. Thus, if you change a workbench or a factory within WOK and then return to the test environment you must use *wokenv -s* to ensure that the set environment variables configuration is correct for the current WOK state.
+The configuration actions that WOK performs can be written to a file and saved as a script. You can then edit this script to suit it to your own needs, and generate a personalized test environment.
+
+To create the script file use the following command:
+~~~~~
+ > wokenv -f <ScriptFile> -t csh
+~~~~~
+This command generates a file, ScriptFile, which configures a C shell to mirror the current WOK environment. An example script file is given below.
+~~~~~
+setenv STATION *sil*
+setenv TARGET_DBMS *DFLT*
+setenv KERNELHOME */adv_22/WOK/BAG/KERNEL-K1-2-WOK*
+setenv LD_LIBRARY_PATH */adv_22/WOK/BAG/wok-K1-2/lib/sil:/adv_22/WOK/BAG/KERNEL-K1-2-WOK/sil/lib/*
+setenv PATH */usr/tcltk/bin:/usr/bin:/bin:/usr/bin/X11:/lib:.:/SGI_SYSTEM/util_MDTV/factory_proc:/adv_22/WOK/BAG/KERNEL-K1-2-WOK/sil/bin/*
+source /adv_22/WOK/BAG/KERNEL-K1-2-WOK/adm/Kernel.csh
+~~~~~
+
+@subsection occt_wok_3_7 Building a Toolkit
+@subsubsection occt_wok_3_7_1 Creating a Toolkit
+
+You create and enter a toolkit development unit using the following commands:
+~~~~~
+ > ucreate -t <TKMyToolkit>
+ > wokcd <TKMyToolkit>
+~~~~~
+
+#### Write the Nomenclature File for the Toolkit
+
+Using an editor, write a nomenclature file called PACKAGES which lists all the packages, one per line, that make up the toolkit. Add PACKAGES to FILES.
+Build the shareable library for this toolkit as follows:
+~~~~~
+\> umake [<TKMyToolkit>]
+~~~~~
+**Note:** when one of the packages in the toolkit is modified, recompile the toolkit. A package should belong to one toolkit only.
+
+#### Sample Construction of a Toolkit
+
+In the following example, the toolkit **TKMyToolkit** is created. Commands preceded by an asterisk are used only once per session:
+1. \*Create MyToolkit in MyWb.
+~~~~~
+\> ucreate -t TKMyToolkit
+~~~~~
+2. Move to the source directory of MyToolkit.
+~~~~~
+\> wokcd TKMyToolkit
+~~~~~
+3. Edit the nomenclature files, PACKAGES and FILES. You do this outside tcl, using the editor of your choice.
+4. \*Create the library for MyToolkit
+~~~~~
+\> umake TKMyToolkit
+~~~~~
+
+#### Umake Steps for a Toolkit
+
+The umake steps for development units of toolkit type are explained below.
+* *src* Processes FILES to list source files.
+* *lib.list* Works out the objects and archive library to add to the toolkit shared library.
+* *lib.limit* Manages the build process strategy within the limitations of a particular platform.
+* *lib.arch* Builds archives according to the building strategy.
+* *lib.uncomp* Decompresses third party archives.
+* *lib.arx* Extracts object files from archives.
+* *lib.build* Generates the shared library for the toolkit.
+
+Building strategy depends on the platform. The following step sequences apply:
+ * On Sun (Solaris):
+~~~~~
+src
+lib.list
+lib.arx
+lib.build
+~~~~~
+ * On sil (IRIX):
+~~~~~
+src
+lib.list
+lib.uncomp
+lib.build
+~~~~~
+
+#### The TOOLKITS File
+
+When executables are compiled, a TOOLKITS file is used to determine which toolkits are included. This file is located in the src directory of the entity being compiled. The process is as follows:
+* If no TOOLKITS file has been found, all toolkits are candidates for substitution. To find out which toolkits are candidates, use the command *w_info -k*.
+* If an empty TOOLKITS file has been found, there is no toolkit candidate for substitution.
+* If a non-empty TOOLKITS file has been found, only the toolkits listed in this file are candidates for substitution.
+
+#### Toolkit Substitution
+
+Toolkit substitution is performed as follows:
+1. MyEngine uses A, B and C;
+2. The toolkit TK provides A and D; D uses E;
+3. Compilation of *MyEngine* includes TK, B C and E.
+
+Here, for simplicity, assume that additional toolkits are not substituted for B, C and E.
+
+@subsection occt_wok_3_8 Building a Delivery Unit
+@subsubsection occt_wok_3_8_1 Creating a Delivery Unit
+~~~~~
+\> ucreate -d <MyDeliveryUnit>
+~~~~~
+
+#### Writing the COMPONENTS File
+
+Create a file named COMPONENTS in the src subdirectory of the delivery development unit. List in this file the prerequisites of the delivery and the components that are part of the delivery. Use the syntax shown below.
+Note that keywords and default options are shown in bold.
+
+| **Name** | ParcelName |
+| Put path | |
+| Put include ||
+|Put lib ||
+| **Requires** | DeliveryName\* |
+| **Package** | MyPack **[CDL][LIBRARY][INCLUDES][SOURCES]** |
+| **Nocdlpack** | MyNcdl **[LIBRARY][INCLUDES][SOURCES]** |
+| **Executable** | MyExec **[CDL][DYNAMIC][SOURCES]** |
+| **Interface** | MyIntf **[CDL][STUB_SERVER][SOURCES]** |
+| **Client** | MyClient **[CDL]**[STUB_CLIENT][SOURCES] |
+| **Engine** | MyEng **[CDL][DYNAMIC][SOURCES]** |
+| **Schema** | MyShma **[CDL][LIBRARY][SOURCES][DOC]** |
+| **Toolkit** |MyTk **[LIBRARY][SOURCES]** |
+| **Get** | DevelopmentUnitName::Type:::File |
+
+\* Without mention of the version
+
+If no keywords are specified then all default arguments shown in bold are taken into account. To select arguments, list the ones required explicitly. The arguments are explained below:
+* **Name** The full name of the current delivery, including a version number. This is the name of the parcel.
+* **Put path** Requires that the delivery be inserted in the user path (bin directory).
+* **\[CDL\]** Copy the cdl files to the delivery.
+* **\[LIBRARY\]** Generate the static library. Copy the shareable library to the delivery. Copy the list of objects of the library.
+* **\[INCLUDES\]** Generate includes.origin. Copy the includes to the delivery. Copy the ddl to the delivery.
+* **\[DYNAMIC\]** Select to copy the static or dynamic executable file.
+* **\[SOURCES\]** Copy the source files.
+
+#### Build the Delivery
+
+To build the delivery unit, use the command:
+~~~~~
+\> umake <MyDeliveryUnit>
+~~~~~
+The result of building a delivery unit is a **parcel**, which can be installed in a warehouse and used by other workbenches.
+
+#### Sample Delivery of a Parcel
+
+In the following example a delivery is created, compiled and made into a parcel. Commands preceded by an asterisk below are used only once per session:
+1. Move to the root workbench under which the parcel is to be made.
+~~~~~
+> wokcd MyRootWb
+~~~~~
+2. \*Create MyDelivery in MyRootwb.
+~~~~~
+> ucreate -d MyDelivery
+~~~~~
+3. Move to the source directory of MyDelivery.
+~~~~~
+> wokcd MyDelivery
+~~~~~
+4. Use an editor to list all the prerequisites and components of the delivery in the COMPONENTS files using the appropriate syntax.
+5. Build MyDelivery.
+~~~~~
+> umake MyDelivery
+~~~~~
+The output of the umake process is a parcel
+
+#### Umake Steps for a Delivery Unit
+
+The umake steps for development units of type delivery are explained below.
+* *src* Processes FILES to list source files.
+* *base* Creates directories, defines the list of units, copies the parcels and the release notes.
+* *get.list* Lists files to get (using Get, Resource).
+* *get.copy* Copy the files listed by get.list.
+* *cdl.list* Lists CDL files to copy.
+* *cdl.copy* Copies the files listed by cdl.list.
+* *source.list* Lists units from which sources are to be copied.
+* *source.build* Creates a file for sources (in the format: unit.type.Z).
+* *inc.list* Lists includes to copy.
+* *inc.copy* Copies files listed by inc.list.
+* *lib.shared* Works out the inputs for building or copying shareable libraries.
+* *lib.shared.build* Copies or builds (depending on the platform) the shareable libraries.
+* *lib.server.list* Lists interface files to copy.
+* *exec.list* Lists inputs for executable delivery.
+* *exec.build* Creates executable in the parcel.
+* *files* Works out the list of files delivered in the parcel.
+
+@subsubsection occt_wok_3_8_2 Installing a Parcel
+You open the root workbench of the workshop where you want to install the parcel using the following command:
+~~~~~
+\> wokcd <MyWorkshop>
+~~~~~
+To install the parcel, use the following syntax:
+~~~~~
+\> pinstall <MyParcel>
+~~~~~
+
+@subsection occt_wok_3_9 Working with Resource
+
+### Building a Resource
+
+There is a single umake step for development units of resource type.
+* *src* Processes FILES to list source files.
+
+@subsection occt_wok_3_10 Java wrapping
+@subsubsection occt_wok_3_10_1 Creating an interface
+
+To create an interface development unit and move to its structure, use commands:
+~~~~~
+\> ucreate -i <MyInterface>
+\> wokcd <MyInterface>
+~~~~~
+
+### Writing an Interface
+
+Having created the interface, you select the classes and packages that you wish to make available for Java wrapping in the jni units. Use an editor of your choice to write a .cdl interface file that specifies these exported services. This file has the format:
+
+~~~~~
+interface MyInterface
+uses
+ ListOfPackages;
+is
+ ListOfPackages;
+ ListOfClasses;
+ ListOfMethods;
+end;
+~~~~~
+
+### Building an Interface
+
+To make the services of the interface available for further wrapping, build the interface, using the command:
+~~~~~
+> umake [<MyInterface>] -o src
+~~~~~
+
+### Sample Construction of an Interface
+
+In the following example a workbench, *MyWb*, is used for working on the interface *MyInterface*. Commands preceded by \* (asterisk) are used only once during a session.
+
+1. \*Create MyInterface in MyWb.
+~~~~~
+>ucreate -i MyInterface
+~~~~~
+2. Move to the source directory of MyInterface.
+~~~~~
+>wokcd MyInterface
+~~~~~
+3. Edit the source file MyInterface.cdl. You do this outside tcl, using an editor of your choice.
+4. Build the interface.
+~~~~~
+> umake -o src
+~~~~~
+
+### Interface Files
+
+_<Interface>.cdl_ is the primary interface file.
+
+### Umake Steps for an Interface
+
+The umake steps for development units of type interface are explained below.
+
+* *src* - processes *MyInt.cdl* to list the CDL files for the development unit. Processes the FILES file to list source files.
+
+**Note** Make sure you only use the *src* step of umake. Using umake without arguments will lead to an attempt of launching other steps relevant to the interface unit. However these steps will fail and anyway are not required for use in Java wrapping.
+
+@subsubsection occt_wok_3_10_2 Creating a jni
+To create a development unit of type jni and move to its structure, use commands:
+~~~~~
+> ucreate -j <MyJni>
+> wokcd <MyJni>
+~~~~~
+
+### Writing a Jni
+
+Use an editor to write a .cdl file that specifies the interface or interfaces required by the jni. This file has the following format:
+~~~~~
+client MyJni
+is
+{interface MyInterface;}
+{interface YourInterface;}
+end;
+~~~~~
+
+### Building a Jni
+
+To wrap services exported by the interfaces to Java, build the jni, using the command:
+~~~~~
+ > umake [MyJni]
+~~~~~
+
+### Sample Construction of a Jni
+
+In the following example a workbench, *MyWb*, is used for working on the jni, *MyJni*. Commands preceded by \* (asterisk) are used only once during a session.
+
+1. \*Create MyJni in MyWb.
+~~~~~
+> ucreate -j MyJni
+~~~~~
+2. Move to the source directory of *MyJni*.
+~~~~~
+> wokcd MyJni
+~~~~~
+3. Edit the source file *MyJni.cdl*. You do this outside tcl, using an editor of your choice.
+4. Derive Java files (.java and .class files) and C++ files (.h and .cxx) used for wrapping.
+~~~~~
+ > umake -e xcpp
+~~~~~
+5. Compile the sources.
+~~~~~
+> umake -o obj
+~~~~~
+6. Link the object files.
+~~~~~
+> umake -o exec
+~~~~~
+
+Primary jni file is *Jni.cdl*
+
+Derived Java files for a Jni are:
+* <Package>_<Class>.java - Java source file of the class to be wrapped.
+* <Package>_<Class>.class - Compiled java source file.
+
+Derived C++ files for a Jni are:
+* <Jni>_<Package>_<Class>_java.h - Include file for the C++ implementation of JNI.
+* <Jni>_<Package>_<Class>_java.cxx - C++ implementation of JNI.
+
+### Umake Steps for a Jni
+
+The umake steps for development units of type jni are explained below.
+* *src* Processes MyJni.cdl to list the CDL files for the development unit. Processes the FILES file to list source files.
+* *xcpp.fill* Compiles the internal data structure to prepare for subsequent extractions.
+* *xcpp.client* Extracts the services declared in included interface unit(s) into Java and creates .java and \*_java.cxx files.
+* *xcpp.javac* Compiles .java files into .class files.
+* *xcpp.javah* Creates .h header files.
+* *obj.comp* Compiles generated C++ files.
+* *obj.idep* Generates dependency information for the unit.
+* *exec.libs* Computes full implementation dependency to prepare for linking.
+* *exec.tks* Performs toolkit substitution.
+* *exec.link* Generates the shared library for the development unit.
+
+@subsection occt_wok_3_11 More Advanced Use
+@subsubsection occt_wok_3_11_1 Default User Profile
+There is a default user profile. If you wish to change this profile the command *wokprofile* is available.
+
+An example profile is given below.
+~~~~~
+ Info : Profile in : WOK:k1dev:ref
+ Info : Extractor : DFLT
+ Info : Compile Mode : Optimized
+ Info : Station Type : sil
+~~~~~
+@subsubsection occt_wok_3_11_2 Changing Parcel Configuration
+Parcel configuration rarely needs changes. However, if you do need to modify the list of resources, you can do so by editing the admin parameter file of the factory. This file is found in the admin directory of the factory and is named after the workshop. It has the suffix .edl. Its full name has the following format:
+~~~~~
+<MyWorkshop>.edl.
+~~~~~
+
+Move to the admin directory of the factory:
+~~~~~
+\> wokcd <MyFactory> -PAdm
+~~~~~
+
+Then use the editor of your choice to edit the admin parameter file, MyWorkshop.edl.
+In this file, the parcel configuration is defined by an entry of the form:
+~~~~~
+\@set %<MyWorkshop>_ParcelConfig = “Parcel1 Parcel2...Parceln”;
+~~~~~
+The resources are listed within quotation marks. They are separated by spaces.
+Edit this list as required. Save the file and close it.
+To validate and take into account your changes use the command:
+~~~~~
+\> wokclose -a
+~~~~~
+This command closes and reopens all the entities. Without the -a option, *wokclose* only applies to the current entity.
+
+@section occt_wok_4_ Available Services
+@subsection occt_wok_4_1 Synopsis
+WOK provides sets of services, which can be grouped according to the entity they apply to:
+ * General Services
+ * Factories
+ * Warehouses
+ * Parcels
+ * Workshops
+ * Workbenches
+ * Development Units
+ * Source Management Services
+ * Session Services
+@subsubsection occt_wok_4_1_1 Common Command Syntax
+
+#### Command Names
+
+All WOK commands follow a common naming convention. This is based on a set of common command names and a group of prefixes, which denote entity type. The command name takes a prefix representing the entity to which it applies.
+The following prefixes exist:
+ * f: for factories
+ * s: for workshops
+ * w: for workbenches
+ * u: for development units
+ * W: for warehouses
+ * p: for parcels
+ * wok: for commands that apply to any type of entity
+These prefixes are followed by a command that determines the action to be executed. Examples of such commands are:
+ * create: create an entity
+ * rm: delete an entity
+ * info: request information
+Consequently, the command ucreate creates a development unit. The command wrm removes a workbench.
+
+#### Command Options
+
+All command options are expressed using a dash (-) followed by one or more key letters and, if applicable, an argument. For example:
+~~~~~
+> umake -f -o <argument> MyUnit
+~~~~~
+The compact version of this syntax is also valid:
+~~~~~
+ umake -fo argument MyUnit
+~~~~~
+This syntax conforms to the POSIX recommendations for UNIX commands.
+For all commands, there is a –h option, which displays help on usage.
+
+#### Presentation of Commands
+
+The general syntax of the commands is presented in this document as follows:
+~~~~~
+CommandName [option(s) [<argument(s)>] [<Entity>]]
+~~~~~
+Consequently, there are four general cases for a command:
+~~~~~
+CommandName <Entity>
+CommandName <option(s)> [<argument(s)>] <Entity>
+CommandName <option(s)> [<argument(s)>]
+CommandName
+~~~~~
+**Note** a few commands described in this chapter do not completely respect this syntax; for example, *create* and *rm*.
+
+As a rule, where an _<EntityPath>_ is given as an argument it specifies which entity the command applies to. Where no _<EntityPath>_ is specified, the command applies to the nearest appropriate entity. The *create* and *rm* commands are notable exceptions: you **must** specify an entity path with these commands.
+
+@subsection occt_wok_4_2 General Services
+General services are commands that apply to any entity manipulated by WOK. They are used for:
+ * Navigation
+ * Managing parameters
+ * Managing profiles.
+
+@subsubsection occt_wok_4_2_1 wokcd
+~~~~~
+wokcd
+wokcd <EntityPath>
+wokcd -P <ParamSuffix> [<EntityPath>]
+~~~~~
+
+Navigates between different WOK entities and changes the current working directory. Without any arguments wokcd lists the current position (the WOK equivalent of ‘pwd’). With an argument, wokcd moves to the specified location.
+Options:
+* _<EntityPath>_ Moves to the home directory of the entity specified by <EntityPath>, i.e. moves to the location given by the parameter: %wokcd <EntityPath>_Home.
+* _-P <ParamSuffix> [<EntityPath>]_ Moves to the <ParamSuffix> directory of the entity specified by <EntityPath>. i.e. moves to the location given by the parameter: %<EntityPath>_<ParamSuffix>. If no entity path is specified, this command moves to the <ParamSuffix> directory of the current entity.
+
+Possible values for <ParamSuffix> are: Home, Adm and Src.
+Use the following commands to change directories within a development unit:
+* **wsrc** To access the source files.
+* **winc** To access the include files.
+* **wobj** To access objects.
+* **wlib** To access shareable libraries.
+* **wbin** To access executables.
+* **wadm** To access the workbench administration files.
+
+#### Examples
+
+*wokcd* - Lists the current position.
+
+*wokcd MODEL:GTI:gti:gp* - Moves to the home directory of the gp package of the gti workbench in the GTI workshop in the MODEL factory.
+
+*wokcd -P Adm* - Moves to the administration directory of the current entity.
+
+
+@subsubsection occt_wok_4_2_2 wokclose
+~~~~~
+wokclose [-a]
+~~~~~
+Closes and reopens entities, i.e. reloads them into memory thus taking any changes into account.
+Option <i>-a</i> closes and reloads all entities.
+
+#### Examples
+
+~~~~~
+wokclose
+~~~~~
+Closes and reopens the current entity.
+~~~~~
+wokclose -a
+~~~~~
+Closes and reopens all the entities.
+@subsubsection occt_wok_4_2_3 wokenv
+~~~~~
+wokenv -f <ScriptFile> -t csh
+~~~~~
+Creates the file <ScriptFile>. This file is a script, which configures a C shell to mirror the current WOK environment. See the <a href="#occt_wok_3_6">Test Environments</a> section for more details.
+Options:
+* -f <ScriptFile> - Specifies the name of the file to produce.
+* -t csh - Produces a file for configuring a C shell.
+* -s - Sets up environment variables for application launching.
+Example
+-------
+~~~~~
+> wokenv -f MyTestEnvScript -t csh
+~~~~~
+Generates the shell script *MyTestEnvScript* to configure a C shell so that it mirrors the current WOK environment.
+@subsubsection occt_wok_4_2_4 wokinfo
+~~~~~
+wokinfo -<option> [<EntityPath>]
+wokinfo -<option> <argument> [<EntityPath>]
+~~~~~
+Displays information about _<EntityPath>_. The information displayed is common to all the entities. If no _<EntityPath>_ is specified, information about the current entity is returned.
+This command can be used to find the path of a file.
+Options:
+* -t - Returns the type of entity (factory, warehouse, parcel, workbench, development unit).
+* -T - Lists the types of files known in the entity.
+* -f - Gets factory from path.
+* -N - Gets the nesting path, i.e. where the current entity is nested.
+* -n - Gets entity name.
+* -P - Gets parcel from path.
+* -s - Gets workshop from path.
+* -u - Gets development unit from path.
+* -W - Gets warehouse from path.
+* -w - Gets workbench from path.
+* -x - Tests if entity exists.
+* -d <type> - Gets type definition.
+* -a <type> - Gets type arguments.
+* -p <type>:<filename> - Gets the path for a file, which is of the type type that depends on %File. In other words, the path for a file of this type depends on the file name, <filename>.
+* -p <type> - Gets the path for a file, which is of the type <type> that is not %File dependent, for example EXTERNLIB.
+
+#### Examples
+
+~~~~~
+wokinfo -p source:gp.cdl MODEL:GTI:gti:gp
+~~~~~
+Returns the path of the source file gp.cdl in the MODEL:GTI:gti:gp.
+~~~~~
+wokinfo -t MODEL:GTI:gti:gp
+~~~~~
+Returns the development unit.
+
+@subsubsection occt_wok_4_2_5 woklocate
+~~~~~
+woklocate -<option> <argument> [<WorkbenchPath>]
+woklocate -P [<WorkbenchPath>]
+~~~~~
+Using WorkbenchPath as the starting point, this command locates files associated with the development unit and specified by the argument argument.
+Options are:
+* -f <Unit:Type:File> - Locates a file and gives its ID.
+* -p <Unit:Type:File> - Locates a file and gives its path.
+* -u <Unit> - Locates a development unit.
+* -P - Displays all available WOK public types.
+
+#### Example
+
+~~~~~
+woklocate <MyFile>
+~~~~~
+Displays the location of the file, MyFile.
+
+@subsubsection occt_wok_4_2_6 wokparam
+~~~~~
+wokparam -<option> [<EntityPath>]
+wokparam -<option> <argument> [<EntityPath>]
+~~~~~
+Queries system parameters such as variables and templates. For more information about parameters refer to the appendix *Parameters and EDL Files* at the end of this User’s Guide. If an <EntityPath> is specified this indicates the entity to which the command applies.
+Options:
+* -L - Lists the directories used to search for the parameter files.
+* -C - Displays the subclasses list.
+* -a <TemplateName> - Gets arguments for the template TemplateName.
+* -e <ParamName> - Evaluates the parameter ParamName.
+* -F <ClassName> - Displays the files comprising the definition of the class *ClassName*.
+* -l <Class> - Lists parameters concerning class (prefix) class.
+* -S <FileName> - Finds the first file FileName in the list of directories cited afterwards.
+* -t <Name> - Tests if the variable Name is set.
+* -v <ParamName> - Displays the value of the parameter *ParamName*.
+* -s <Name>=\<Value> Reserved for advanced use. Sets the variable *Name* to value *Value*.
+* -u <Name> Reserved for advanced use. Unsets the variable Name.
+
+#### Examples
+
+~~~~~
+wokparam -L MODEL:GTI:gti
+~~~~~
+Returns a list of directories used for parameters by the gti workbench.
+~~~~~
+wokparam -S CSF.edl
+~~~~~
+Locates the nearest CSF.edl file used by the current entity.
+~~~~~
+wokparam MODEL:GTI:gti:gp -e %WOKUMake_Steps
+~~~~~
+Displays the value of the _\%WOKUMake_Steps_ parameter in the *gp* package. The _\%WOKUMake_Steps_ parameter contains a description of the steps used by umake.
+@subsubsection occt_wok_4_2_7 wokprofile
+~~~~~
+wokprofile
+wokprofile -<option> [<argument>]
+~~~~~
+Modifies session parameters. This command changes the mode of the current compilation and the profile of the current database. It also displays the current value of the session parameters. If no argument is specified, it displays the values of different parameters in the current session as well as the current position *wokprofile -v*.
+Options:
+* -b - Returns the current database profile (OBJS, DFLT).
+* -d - Switches to compilation with debug.
+* -m - Returns the current compilation mode.
+* -o - Switches to optimized compilation.
+* -s - Returns the current station type
+* -v - Switches to wokprofile verbose mode. In this mode all the parameters of the session are displayed. Running this command displays the current/changed profile.
+
+#### Examples
+
+~~~~~
+wokprofile
+~~~~~
+Displays all the session parameters.
+~~~~~
+wokprofile -b
+~~~~~
+Displays the current database profile.
+~~~~~
+wokprofile -v -o
+~~~~~
+Switches to optimized compilation and displays the parameters of the current session after the change has been made.
+~~~~~
+wokprofile -o -v
+~~~~~
+Switches to optimized compilation and displays the parameters of the current session after the change has been made. Note that the order in which these options are specified does not affect the result.
+
+@subsection occt_wok_4_3 Services Associated with Factories
+There is a dedicated list of commands for the management of factories. The commands to create and destroy factories are reserved for the exclusive use of the site administrator.
+* *fcreate* Creates a factory.
+* *finfo* Displays information about the factory.
+* *frm* Deletes a factory if it is empty.
+
+@subsubsection occt_wok_4_3_1 fcreate
+*Reserved for administrator’s use*
+~~~~~
+fcreate -<option> [-D <Suffix>=<Value>]* <EntityPath>
+~~~~~
+Creates a factory. The name of the factory to create is specified by EntityPath. You can also specify the entity that will contain the entity to be created.
+
+Once the creation is completed, a file containing the parameters of the creation of the factory is created in the administration directory of the container to which the factory belongs.
+
+Parameters:
+The following parameters are mandatory when a factory is created:
+* **Adm** - Path name for administration directory
+* **Home** - Path name for home directory
+* **Stations** - List of supported stations
+* **DBMSystems** - List of supported dbms
+* **Warehouse** - Name of factory warehouse.
+
+Options:
+* -P - Propose defaults. Returns a list of default values for the parameters necessary for the creation of the factory. No entity is created if this option is used.
+* -d Use default. Uses default values to create the factory.
+* -D<Suffix>=\<Value> - Defines parameter(s). Specifies the value to use for the given parameter(s) explicitly. This option can be used in conjunction with the –d option to take default values for all the mandatory parameters except the parameter(s) explicitly specified here.
+
+#### Examples
+
+~~~~~
+fcreate -P NewFactoryName
+~~~~~
+Returns a list of default values for the parameters that are mandatory when creating a factory.
+~~~~~
+fcreate MyFactory -d -DHome=/fred/myfactory
+~~~~~
+Creates the factory MyFactory using default values for all mandatory parameters, except for Home, which is set to: /fred/myfactory
+
+@subsubsection occt_wok_4_3_2 finfo
+~~~~~
+finfo -<option> [<EntityPath>]
+~~~~~
+Displays details about the factory. If an EntityPath is specified this determines the factory to apply to. If no entity path is given, the command applies to the nearest factory.
+Options:
+* -s - Displays a list of workshops in the factory.
+* -W - Displays the name of the warehouse in the factory.
+* -S - Displays the name of the source repository.
+
+#### Examples
+
+~~~~~
+finfo -s
+~~~~~
+Displays a list of workshops in the nearest factory.
+~~~~~
+finfo MyFactory -W
+~~~~~
+Displays the name of the warehouse in MyFactory.
+
+@subsubsection occt_wok_4_3_3 frm
+*Reserved for administrator’s use*
+~~~~~
+frm <EntityPath>
+~~~~~
+Deletes the factory specified by EntityPath if it is empty.
+
+Note, that you must not be in the factory you intend to destroy.
+
+#### Example
+
+~~~~~
+frm MyFactory
+~~~~~
+Deletes the factory MyFactory provided that it is empty.
+
+@subsection occt_wok_4_4 Services Associated with Warehouses
+A warehouse contains the parcels that are available in a factory. There is a dedicated list of commands for management of warehouses.
+The commands you use to create and destroy the warehouses are reserved for the exclusive use of the site administrator.
+* *Wcreate* - creates a warehouse.
+* *Winfo* - displays information about the warehouse
+* *Wrm* - deletes a warehouse if it is empty.
+* *Wdeclare* - declares a parcel in the warehouse.
+
+@subsubsection occt_wok_4_4_1 Wcreate
+*Reserved for administrator’s use.*
+~~~~~
+Wcreate [-<option>] -D<Suffix>=<Value>* <WarehouseName>
+Wcreate -<option> [-D <Suffix>=<Value>]* <WarehouseName>
+~~~~~
+Creates a warehouse. The name of the warehouse to create is given by *<WarehouseName>*. You can also specify the factory that will contain the warehouse.
+Once the creation is completed, a file containing the parameters of warehouse creation is in its turn created in the administration directory of the factory to which the warehouse belongs.
+
+Parameters:
+The following parameters are mandatory when a warehouse is created:
+* **Adm** - Path name for administration directory.
+* **Home** - Path name for home directory.
+* **Stations** - List of supported stations.
+* **DBMSystems** - List of supported dbms.
+
+Options:
+* -P - (Propose defaults.) Returns a list of default values for the parameters necessary for the creation of a warehouse. No entity is created if this option is used.
+* -d - (Use defaults.) Uses default values to create the warehouse.
+* -D <Suffix>=\<Value> (Define parameter.) Explicitly specifies the value to use for this parameter. This option can be used in conjunction with the –d option to take default values for all the mandatory parameters except the parameter(s) explicitly specified here.
+
+#### Examples
+
+~~~~~
+Wcreate -P MyWarehouse
+~~~~~
+Returns a list of default values for the parameters that are mandatory when creating a warehouse.
+~~~~~
+Wcreate MyWarehouse -d
+~~~~~
+Creates the warehouse *MyWarehouse* using default values for all mandatory parameters.
+@subsubsection occt_wok_4_4_2 Winfo
+~~~~~
+Winfo -p [<EntityPath>]
+~~~~~
+Displays details about the warehouse and its contents. If an EntityPath is specified, this determines the warehouse to apply to.
+Option -p displays the parcels in the warehouse.
+
+#### Example
+
+~~~~~
+Winfo -p
+~~~~~
+Displays a list of parcels in the current warehouse.
+@subsubsection occt_wok_4_4_3 Wrm
+*Reserved for Administrator’s Use.*
+~~~~~
+Wrm <EntityPath>
+~~~~~
+Deletes the warehouse specified by EntityPath if it is empty. You should not be in the warehouse you intend to destroy.
+#### Example
+
+~~~~~
+Wrm MyWarehouse
+~~~~~
+Deletes the warehouse *MyWarehouse* provided that it is empty.
+@subsubsection occt_wok_4_4_4 Wdeclare
+*Reserved for administrator’s use*
+~~~~~
+Wdeclare -p<Parcel> [-d] [-D<ParamName>=<Value>]* <House>
+~~~~~
+Declares the *Parcel*. This command adds the parcel to the list of parcels available in the warehouse House.
+Note that a factory has a default list of deliveries (which are represented by parcels) available to it. This list only needs to be modified when moving to a new version of the delivery. This is done using the *Wdeclare* command, and then by editing the .edl file of the appropriate workshop.
+
+The following parameters are mandatory when declaring parcels:
+* **Adm** - Path name for administration directory of a parcel.
+* **Home** - Path name for home directory of a parcel.
+* **Stations** - List of available stations.
+* **DBMSystems** - List of available dbms.
+* **Delivery** - Delivery name.
+
+Options:
+* -p <Parcel> Defines the name of the parcel to declare. This name must be given with the option.
+* -d Creates a parcel using defaults.
+* -P Proposes defaults.
+
+#### Example
+
+~~~~~
+Wdeclare -pMyParcel -d MyWarehouse
+~~~~~
+Adds the parcel MyParcel to the warehouse MyWarehouse.
+
+@subsection occt_wok_4_5 Services Associated with Parcels
+A parcel is a receptacle for development units. You use it to group together the units, which comprise a delivery unit. There is a dedicated list of commands for management of parcels. Only the site administrator should perform installation of parcels in a warehouse.
+* *pinfo* - displays information about the contents of the parcel
+* *pinstall* - installs the parcel in a Warehouse.
+
+@subsubsection occt_wok_4_5_1 pinfo
+
+pinfo -<option> [<ParcelPath>] - displays details about the contents of the parcel. If *ParcelPath* is specified this determines the parcel to apply to. If no parcel path is specified the command applies to the nearest parcel.
+
+Options:
+* -d - Displays the delivery contained in the parcel.
+* -l - Displays the development units in the parcel.
+* -a - Lists the development units in the parcel together with their types.
+
+#### Examples
+
+~~~~~
+pinfo -l MyParcel
+~~~~~
+Displays a list of units in the parcel MyParcel.
+
+@subsubsection occt_wok_4_5_2 pinstall
+*Reserved for administrator’s use*
+~~~~~
+pinstall <ParcelName>
+~~~~~
+Installs the parcel <ParcelName> in the current warehouse. The process of installing a parcel sets up various paths and variables to ensure that the application can locate necessary resources and so on.
+The administrator must perform *pinstall* for each platform used.
+
+#### Example
+
+~~~~~
+pinstall MyParcel
+~~~~~
+Installs the parcel *MyParcel* in the current warehouse.
+
+@subsection occt_wok_4_6 Services Associated with Workshops
+A workshop is a tree of workbenches using the same parcel configuration. There is a dedicated list of commands for management of workshops. The commands to create and destroy workshops are reserved for the exclusive use of the site administrator.
+* *screate* - creates a workshop.
+* *sinfo* - displays information about the workshop
+* *srm* - deletes a workshop if it is empty.
+
+@subsubsection occt_wok_4_6_1 screate
+*Reserved for administrator’s use*
+~~~~~
+screate [-<option>] {-D<Suffix>=<Value>}* <WorkshopName>
+screate -<option> <WorkshopName>
+~~~~~
+Creates a workshop, <WorkshopName>. You can also specify the factory that contains this workshop.
+Once the creation is completed, a file containing the parameters for the creation of the workshop is generated in the administration directory of the factory to which it belongs.
+
+The following parameters are mandatory when creating a workshop:
+* **Adm** - Path name for administration directory.
+* **Home** - Path name for home directory.
+* **Stations** - List of supported stations.
+* **DBMSystems** - List of supported dbms.
+* **ParcelConfig** - List of parcels used.
+* **Workbenchlist** - Path name for the list of workbenches.
+
+Options:
+* -P (Propose defaults.) Returns a list of default values for the parameters necessary for the creation of a workshop. No entity is created if this option is used.
+* -d (Use defaults.) Uses default values to create the workshop.
+* -D <Suffix>=\<Value> (Define parameter.) Specifies the value to use for this parameter explicitly. This option can be used in conjunction with the –d option to accept default values for all the mandatory parameters except the parameter(s) explicitly specified here.
+
+
+#### Examples
+
+~~~~~
+screate -P <WorkshopName>
+~~~~~
+Returns a list of default values for the parameters that are mandatory for creating a workshop.
+~~~~~
+screate MyFactory:MyWorkshop -d
+~~~~~
+Creates the workshop *MyWorkshop* in the factory *MyFactory*, using default values for all mandatory parameters.
+~~~~~
+screate -DParcelConfig=Parcel1,Parcel2 MyFactory:MyWorkshop -d
+~~~~~
+Creates the workshop *MyWorkshop* in the factory *MyFactory*, using default values for all mandatory parameters except for *ParcelConfig*, which is set to *Parcel1 Parcel2*.
+
+@subsubsection occt_wok_4_6_2 sinfo
+~~~~~
+sinfo -<option> [WorkshopName]
+~~~~~
+Displays details about the workshop. If *WorkshopName* is specified this determines the workshop this command is applied to. If no workshop is specified the command applies to the nearest workshop.
+Options:
+* -w - Displays a list of workbenches in the workshop.
+* -p - Displays the parcel configuration of the workshop.
+
+#### Example
+
+~~~~~
+sinfo -w
+~~~~~
+Displays a list of workbenches in the nearest workshop.
+
+@subsubsection occt_wok_4_6_3 srm
+*Reserved for administrator’s use*
+~~~~~
+srm WorkshopName
+~~~~~
+Deletes the workshop <WorkshopName> if it is empty. You must not be in the workshop you intend to destroy.
+
+#### Example
+
+~~~~~
+srm MyWorkshop
+~~~~~
+Deletes the *MyWorkshop* provided that it is empty.
+
+@subsection occt_wok_4_7 Services Associated with Workbenches
+A workbench is the place where a developer (or a team of developers) works on a particular product. There is a dedicated list of commands for management of workbenches.
+
+* *wcreate* - creates a workbench.
+* *w_info* - displays information about a workbench.
+* *wrm* - deletes a workbench if it is empty.
+* *wmove* - moves a workbench to a new location.
+
+@subsubsection occt_wok_4_7_1 wcreate
+~~~~~
+wcreate -f <ParentWB> [-D <Suffix>=<Value>]* <WBName>
+wcreate -f <ParentWB> -P|d [-D <Suffix>=<Value>]* <WBName>
+wcreate -f <ParentWB> -P|d <WBName>
+~~~~~
+Creates the workbench <WBName> as a child of the workbench <ParentWB>. The result of this creation is a directory structure.
+Compared to the creation of other entities, creating a workbench requires an additional piece of information: you must specify the parent of the workbench to create.
+Once the creation is completed, a file containing the parameters of the creation of this workbench is created in the administration directory of the workshop that contains it.
+Parameters:
+The following parameters are mandatory when creating a workbench:
+* **Adm** Path name for administration directory.
+* **Home** Path name for home directory.
+* **Stations** List of supported stations.
+* **DBMSystems** List of supported dbms.
+
+Options:
+* -f - Specifies the parent workbench.
+* -P - (Propose defaults.) Returns a list of default values for the parameters necessary for the creation of the workbench. No entity is created if this option is used.
+* -d - (Use defaults.) Uses default values to create the workbench.
+* -D <Suffix>=\<Value> - (Define parameter.) Specifies the value to use for this parameter explicitly. This option can be used in conjunction with the –d option to take default values for all the mandatory parameters except the parameter(s) explicitly specified here.
+
+#### Example
+
+~~~~~
+wcreate -P WorkBenchName
+~~~~~
+Returns a list of default values for the mandatory parameters to create a workbench.
+~~~~~
+wcreate MyWorkbench -d
+~~~~~
+Creates the workbench MyWorkbench using default values for all mandatory parameters.
+**Note** The –f option of this command is not obligatory. The system administrator can create the root workbench of a workshop without specifying a parent workbench.
+
+@subsubsection occt_wok_4_7_2 w_info
+~~~~~
+w_info -option[Workbench]
+w_info -option argument[Workbench]
+~~~~~
+The *w_info* command is the exception to the common command syntax. The form w_info is used instead of winfo because the latter already exists as a tcl/tk command and cannot be reused as a name by WOK. If <Workbench> is specified, this determines the workbench to apply to. If no <Workbench> is specified, the nearest workbench is used.
+
+Using the tcl winfo command by mistake generates an error message, but does not cause any damage.
+
+Options:
+* -l - Lists the development units in the workbench.
+* -a - Lists the development units in the workbench along with their respective types.
+* -f - Displays the parent workbench.
+* -A - Lists all the ancestors of the workbench.
+* -k - Lists visible toolkits.
+* -S <arg> - Lists suppliers of the unit <arg> within the visibility of the workbench.
+* -S <execname:partname> - Lists the suppliers of the component executable partname within an executable development unit execname.
+* -I <arg1, arg2 ... argN> - Lists the development units, sorted by order of implementation dependency.
+
+#### Example
+
+~~~~~
+w_info -S MyDevUnit
+~~~~~
+
+Returns a list of suppliers of the development unit MyDevUnit within the visibility of the current workbench.
+
+@subsubsection occt_wok_4_7_3 wrm
+~~~~~
+wrm Workbench
+~~~~~
+Deletes the workbench, provided that it is empty and has no children. You must not be in a workbench you intend to destroy.
+
+#### Example
+~~~~~
+wrm MyWorkbench
+~~~~~
+Deletes *MyWorkbench*, provided that it is empty and has no children.
+
+@subsubsection occt_wok_4_7_4 wmove
+*Reserved for advanced use*
+wmove -f <NewParentWorkbench> <Workbench>
+Moves the <Workbench> (and its children), to a different parent *NewParentWorkbench* within the same workshop.
+Option -f <argument> specifies the new parent workbench.
+
+#### Example
+
+~~~~~
+wmove -f MyOtherWorkbench MyWorkbench
+~~~~~
+Moves the *MyWorkbench* under *MyOtherWorkbench*.
+
+@subsubsection occt_wok_4_7_5 wprocess
+~~~~~
+wprocess <WorkbenchName> <options>
+~~~~~
+Allows automatic reconstruction of a workbench.
+
+Options:
+* -DGroups =Obj,Lib,Exec - Selects groups Obj, Lib and Exec.
+* -DUnits = MyUd1,MyUd2,... - Selects the development units MyUd1, MyUd2 etc.
+* -DXGroups =Src,Deliv - Excludes groups Obj and Deliv.
+* -DXUnits=MyUd1,MyUd2,... - Excludes units MyUd1, MyUd2 etc.
+* -B <Profile> - Selects the extraction profile.
+* -f - Forces all selected steps.
+* -d | -o - Switches between debug and optimized modes.
+* -P - Prints out the selected steps.
+* -S - Silent mode (no print of the banner).
+* -L - Logs output to MyUD_<step code>. Log in step administration directory. Valid group names are: Src, Xcpp, Obj, Dep, Lib, Exec, Deliv.
+
+#### Example
+
+~~~~~
+wprocess -DGroups=Src,Xcpp,Obj,Lib,Exec
+~~~~~
+Compiles the whole workbench
+
+@subsection occt_wok_4_8 Services Associated with Development Units
+The development unit is the basic building block of development work in the WOK environment. It is the base component of Open CASCADE Technology architecture. For a list of available types of development units refer to the <a href="#occt_wok_2_1">Development Units</a> section. There is a dedicated list of commands for management of development units.
+
+* *ucreate* **Creates** a development unit.
+* *uinfo* **Displays** information about the development unit.
+* *urm* **Deletes** a development unit.
+* *umake* **Builds** a development unit.
+
+@subsubsection occt_wok_4_8_1 ucreate
+~~~~~
+ucreate [-<TypeCode>] <UnitName>
+ucreate -P
+~~~~~
+Creates a development unit named <UnitName> of type <TypeCode>.
+
+Once the creation is completed, a file containing the parameters of the creation of the development unit is generated in the administration directory of the workbench to which the development unit belongs.
+
+TypeCodes:
+* -p - Creates a development unit of type package. This is the default option. Where no option is specified, a development unit of type package is created.
+* -n - Creates a development unit of type nocdlpack.
+* -s - Creates a development unit of type schema.
+* -t - Creates a development unit of type toolkit.
+* -d - Creates a development unit of type delivery.
+* -x - Creates a development unit of type executable.
+* -f - Creates a development unit of type frontal.
+* -r - Creates a development unit of type resource.
+* -P - Displays ucreate creation possibilities in format: <TypeCode> <TypeName>.
+
+#### Examples
+
+~~~~~
+ucreate -p MyWorkbench:MyPackage
+~~~~~
+Creates the development unit *MyPackage* in *MyWorkbench*. The unit is of package type.
+
+@subsubsection occt_wok_4_8_2 uinfo
+
+~~~~~
+uinfo -t|c [<UnitPath>]
+uinfo -f|F|p [-<FilterOption> [<Type>]]* [<UnitPath>]
+~~~~~
+
+Displays details about the development unit. Where no <UnitPath> is specified, details of the current unit are displayed. Filter options are available for use in conjunction with the options -f, -F, -p to filter the file list. Combinations of filter options can be used.
+
+Note that the uinfo command is based on the results of construction using umake. As a consequence, the list of files displayed by uinfo is only valid if the construction has completed normally. Similarly, the list of files derived from the CDL is only valid if the CDLs of the unit have been translated successfully.
+
+Options:
+* -t - Displays the type of the development unit as a string.
+* -c - Displays the typecode of the development unit, i.e. a single character, as used by *ucreate* to indicate package (p), schema (s) and so on.
+* -f - Displays a list of file names associated with the unit.
+* -F - Displays a list of file names associated with the unit, together with their respective types. Types of files include for example: *source*, *library*, *executable*, and *pubinclude*. To display a full list of file types, use the command *ucreate*.
+* -p - Displays the full paths of the files associated with the unit.
+Filter Options:
+* -T - <Type> Displays files of type <Type> only.
+* -i - Displays only *independent* files, i.e. files that are not specific to a DBMS, for example sources.
+* -s - Displays only station dependent files.
+* -b - Displays only DBMS dependent files.
+* -B - Displays only files that are dependent on *both *DBMS and Station.
+* -l - Displays only files that are local to the workbench.
+* -m - Displays only missing files, i.e. files that are listed, but not found.
+* -e - Displays only existing files, i.e. files that are listed and found.
+
+#### Examples
+
+~~~~~
+uinfo -Fp
+~~~~~
+Displays the types, paths and names of all files associated with the unit.
+~~~~~
+uinfo -f -Tpubinclude MyWorkbench:MyUnit
+~~~~~
+Lists the names of the header files associated with the unit MyUnit which is in MyWorkbench.
+
+@subsubsection occt_wok_4_8_3 urm
+~~~~~
+urm <UnitPath>
+~~~~~
+Deletes the development unit <UnitPath> with its directory structure and its files, even if the unit is referenced by another one.
+
+#### Example
+~~~~~
+urm MyWorkBench:MyPack
+~~~~~
+Deletes the development unit *MyPack* found in *MyWorkBench*.
+
+@subsubsection occt_wok_4_8_4 umake
+~~~~~
+umake -S [<UnitPath>]
+umake [-f][<UnitPath>]
+umake [-f]-o<step> [-t<target>]* [-o<step> [-t<target>]*]*[<UnitPath>]
+umake [-f][-s <step>] [-e <step>][<UnitPath>]
+umake
+~~~~~
+Builds a development unit. The build process includes compilations, links, and various other actions, which make the development unit usable. The build process is specific for each type of development unit, refer to chapter 3 for details.
+The following properties apply:
+1. There are steps identified by a keyword.
+2. The steps involved and their content depends on the type of development unit being treated.
+3. You can ask for single step execution using the -o option.
+4. Unless explicitly requested using the –f option, the operations are carried out in those steps where necessary.
+5. Only the processed development unit is modified.
+
+Used without any arguments the *umake* command carries out all of the steps appropriate for the development unit to be constructed. Using keywords and arguments you can perform the build process step by step.
+
+Options:
+* -S - Displays the list of steps.
+* -s <step> - Starts the build process at the step specified.
+* -e <step> - Ends the build process at the step specified.
+* -o <step> - Only executes the step specified.
+* -t <target> - Specifies the target to build.
+* -f - Forces the build process, skipping the verification of dependencies.
+
+#### Example
+
+~~~~~
+umake gp
+~~~~~
+Builds the gp package.
+
+@subsubsection occt_wok_4_8_5 Specifying Targets (-t) for umake
+
+The umake command is also used to specify build targets and extract C++ method prototypes. src, xcpp and obj units can be targeted. The syntax is explained below.
+For delivery units (for all options apart from *.list) the syntax is as follows:
+~~~~~
+-\*.\* -t MyDU
+umake MyDeliv -olib.shared.build -tMyUD.
+~~~~~
+
+#### src
+
+This target computes a source file list as in the example below:
+~~~~~
+umake -o src MyUnit
+~~~~~
+
+#### xcpp
+
+Extracts C++ header files. For -xcpp.\* (with the exception of \*.fill), the syntax is as follows:
+~~~~~
+umake -o -xcpp.* -t MyPack_MyClass
+~~~~~
+You extract the method prototypes using the following command:
+~~~~~
+umake -o xcpp.template [-t<class>|-t<package>]
+~~~~~
+This syntax of *umake* command is only used with packages. It extracts the C++ prototypes of the methods of the classes contained in the package.
+The generated files are placed in the src directory of the current package. These files always have a .template suffix. With each extraction of a class, these files will contain all the methods of the class.
+Prototypes are extracted for:
+ * Ordinary classes (non-instantiated)
+ * Generic classes (including nested generic classes)
+ * Package methods
+Classes, which are instantiations of generic classes, are not extracted. Nor are other CDL types (exceptions, alias, etc.) which have no user implementation.
+For each class, we extract the prototypes of:
+ * Instance methods
+ * Class methods
+ * Constructors
+The extracted files are the following:
+ * for an ordinary class C
+ + C.cxx.template for the non-inline class methods.
+ + C.lxx.template for the inline class methods.
+ * for a generic class G
+ * G.gxx.template for the non-inline class methods.
+ * G.lxx.template for the inline class methods.
+ * for a package method P
+ * P.cxx.template for the non-inline package methods.
+ * P.lxx.template for the inline package methods.
+
+
+#### obj
+
+Specifying the target, *obj* compiles the object files for one or more files. The syntax for -obj.* is as follows:
+~~~~~
+umake -o -obj.* -t MyPack_MyClass.cxx
+~~~~~
+In a package, the following command executes all construction steps up to and including obj, doing for each of them only what is strictly necessary:
+~~~~~
+umake -s obj
+~~~~~
+The following command will recompile all the primary sources of a package which are out of date:
+~~~~~
+umake -o obj
+~~~~~
+
+@subsubsection occt_wok_4_8_6 Customizing umake
+You can use three levels of umake customization for a development unit.
+ * Compiler and link options, EXTERNLIB
+ * Step definition
+ * Tcl umake step implementation
+These different levels of complexity correspond to the needs of regular users and more advanced users.
+
+#### Modification of Compiler and Link Options and EXTERNLIB
+
+Customization at this level involves setting parameters of existing umake steps using an .edl file. This file is taken into account each time umake is performed. It contains a series of assignments or appended variables used when creating the development unit. These commands can be preceded by instructions dedicated to the preprocessor in order to adjust its behavior within the actual context.
+
+EXTERNLIB uses resources contained in Open CASCADE Technology prerequisites. To avoid referencing the path of these resources more than one time, the user may use the component EXTERNLIB to include these resources automatically via the link. The file contains the name of parameters, which are set independently.
+
+The umake command does not generate actual dependencies. To avoid any cumbersome dependencies, for example, if you do not want the shareable library file for a package but the package enumeration only, use the INTERNLIB component listed in FILES, to get only the given dependencies.
+
+In practice, the generated file, <myUD>.ImplDep, in the /drv/adm directory, is copied into INTERNLIB. INTERNLIB contains lines of enumerations, as below:
+~~~~~
+Dependence 1
+Dependence 2
+...
+~~~~~
+The example below illustrates how you can modify your WOK compiler options. Refer to *Using EDL to Define WOK Parameters* for an example of how to set link options as well as for more details about available parameters and .edl files.
+~~~~~
+-- File Name: Kernel_CMPLRS.edl
+-- Copyright: Matra Datavision 1996
+#---------------------------------
+#// First, ensure that we only execute this file once
+\@ifnotdefined ( %Kernel_CMPLRS_EDL ) then
+ \@set %Kernel_CMPLRS_EDL = **;
+#// Then set C++ compilation options, based on workstation type:
+ \@if( %Station == *sil* ) then
+\@set %ModeOpt = * *;
+ \@endif;
+ \@if( %Station == *ao1* ) then
+\@set %ModeOpt = *-g *;
+ \@endif;
+ \@if( %Station == *hp* ) then
+\@string %CMPLRS_C_Options += * -Aa -D_HPUX_SOURCE +e*;
+ \@endif;
+\@endif;
+~~~~~
+
+#### Step Definition
+
+The WOK umake command uses a dependency tree. This dependency tree is a graph that shows the umake steps, their inputs and their dependencies. You use it to perform the build, for example to ensure that only files, which have changed, and the files, which depend on these modified files, are recompiled.
+
+This dependency tree is defined in an .edl file. The steps are listed in an order. Each is assigned a name and has its inputs specified. The output of one or more steps is the input to another step.
+
+The following steps are standard for WOK umakes: src, src.list, exec.comp and exec.link. Any new step that you insert into the tree must be associated with a tcl program, which will be responsible for performing the step. You supply these tcl programs. For more details of tcl programming refer to the examples below and also to the <a href="#occt_wok_8">Tcl Overview</a> section.
+
+The following example defines a umake dependency tree and introduces two new steps: exec.kerobj and exec.core. Each of these steps is then associated with a tcl program.
+~~~~~
+-- File Name: DCube_WOKSteps.edl
+
+\@ifnotdefined (%DCube_WOKSteps_EDL) then
+ \@set %DCube_WOKSteps_EDL = **;
+ \@string %WOKSteps_ObjGroup += *obj.libs obj.arx obj.objs *;
+---\@set %WOKUmake_Steps =**src obj.inc(src) objc.cgen(src) obj.comp(src, obj.cgen) obj.libs(src) obj.arx(obj.libs) obj.objs(obj.arx) obj.lib(obj.comp, obj.objs) obj.idep(obj.comp,src)*;
+ \@set %WOKSteps_obj_libs = *DCube_Libs(src)*;
+ \@set %WOKSteps_obj_arx = *WOKStep_LibExtract(obj.libs)*;
+ \@set %WOKSteps_obj_objs = *DCube_Objs(obj.arx)*;
+\@set %WOKSteps_obj_lib = *WOKStep_DynamicLibrary(obj.comp, obj.objs)*;
+ \@set %WOKSteps_toolkit_ListWith = *obj.comp obj.objs*;
+\@endif;
+~~~~~
+
+#### Tcl Step Implementation
+
+Customization at the tcl step level requires an understanding of the build process and the WOK dependency tree. Modification at this level is generally used to add elements to the build which are not described in the CDL. For example one possible use is to include external libraries or files into the final shareable library. Refer to <a href="#occt_wok_8_3_4">Writing Tcl Steps for a WOK Build</a> for more details.
+
+@subsection occt_wok_4_9 Source Management Services
+You use the source management services to integrate source files between a root workbench and one of its children. The services are related to a particular workshop.
+
+* *wprepare* - displays a report of the files state in the current workbench (as compared with the files in the root workbench).
+* *wstore* - queues a report for further integration and stores the related files.
+* *wintegre* - performs check-in operations for requested files and updates the root workbench.
+* *wnews* - allows management and use of data stored in the integration journal.
+* *wget* - imports source files to the current workbench.
+
+@subsubsection occt_wok_4_9_1 wprepare
+~~~~~
+wprepare –wb <father workbench> [-ud <ud1,ud2,...,udN>] -o [<filename>]
+wprepare –wb <father workbench> [-ref][-ud <ud1,ud2,...,udN>] -o [<filename>]
+~~~~~
+Prepares a report for integration to a reference (root) Workbench. This command prints a comparison of the state of source files contained in the specified units, <ud1,ud2,...,udN,> of the current workbench.
+
+This workbench must be a direct descendant of the root workbench. If no unit names are specified, all the units in the workbench are processed. By default, the results of the comparison are printed to the standard output. The differences are computed in relation to the root workbench.
+
+For each file, the status is indicated as follows:
+* \# The file has been modified.
+* \= The file was found in the current workbench but was not modified.
+* \- The file has been removed. In other words, the entry was deleted from FILES).
+* \+ The file has been added. In other words, the entry has been added in FILES).
+
+Options:
+* -ref - Creates a report that is used to initialize a base of source files. This report is used with the *wintegre -ref* command.
+* -ud <ud1>, <ud2>, ..., <udN> - Specifies the list of development units to prepare for integration. Separate the unit names with a comma. If no unit names are specified, all the units in the workbench are processed.
+* -o <fileName> - Writes the integration report to the specified file. By default, the report is displayed (i.e. written to standard output).
+* -wb <The name of target workbench> - Specifies the name of target workbench. It should be one of father workbenches with attached integration queue.
+
+@subsubsection occt_wok_4_9_2 wstore
+~~~~~
+wstore –ls –wb <MasterWb>
+wstore -cat <ID>
+wstore [-trig] -rm <ID> [-f] –wb <MasterWb>
+wstore –create –wb <MasterWb>
+wstore [<FileName>]
+~~~~~
+This command manages the queue of pending reports. When a report is queued it is given a unique number also called a report-ID.
+
+Options:
+* <FileName> - Adds a report from the file FileName to the report queue.
+* -trig - Calls a tcl procedure after the report has been processed. This tcl procedure must be located in the admin directory of the workshop and the file must be named wstore_trigger.tcl. An example of a trigger can be found in the file <i>$env(WOK_LIBRARY)/wstore_trigger.example</i>.
+* -ls - Lists pending reports, together with their owners and their IDs. This is a default option. If two files are found with the same name in the same development unit in two different reports the full path of each of these files is displayed.
+* -cat <Report_ID> - Displays the contents of the report <i><Report_ID></i>.
+* -rm - Removes a report from the report queue.
+* -f - Forces deletion. This option must be used with the -rm option when you delete a report that you do not own.
+* -param - Lists queue parameters associated with the workbench.
+* -create –wb <MasterWb> -queue <any/dir> -type SCCS - Creates an integration queue associated with MasterWb workbench, queue should be located at any/dir and specify SCCS type of database.
+
+Possible options for –create are:
+* -queue - Specify the name of directory under which queue is created
+* -type - Specify the type of database (can be SCCS or RSC, SCCS by default)
+* -base - Specify the location where to put the repository (only for SCCS database). Default behavior: creates repository in the adm directory of the master workbench.
+* -counter - Specify the name of directory where the integration counter is located. Default behavior: creates subdirectory adm in directory created using –base option
+* -journal - Specify the location of integration journal. Default behavior: : creates subdirectory adm in directory created using –base option
+* -welcome - If increment contains new development units, by default store will refuse such increment. If you want to be able to add new units to MasterWb through integration mechanism use – welcome option.
+
+#### Example
+
+~~~~~
+wstore ReportName –wb MasterWb
+~~~~~
+Queues the report ReportName and saves a copy of the files mentioned in the report. This copy will be used when the report is actually processed by the command *wintegre*.
+~~~~~
+wstore –wb MasterWb -f -rm Report_ID
+~~~~~
+Removes the report Report_ID from the queue, even if you do not own it.
+
+@subsubsection occt_wok_4_9_3 wintegre
+~~~~~
+wintegre [<reportID>] –wb <MasterWb>
+~~~~~
+Processes a report and removes it from the queue in the current workshop.
+
+Parameters:
+* <reportID> - Number indicating the rank of the report in the integration queue. Use the command *wstore –l* to get this number.
+
+Options:
+* -ref <BaseNumber> - Initializes the version of the elements in the repository.
+* -all - Processes all the reports in the integration queue.
+* -wb - Specify the integration queue of which workbench should be used
+* -norefcopy - Updates the repository but not the target workbench.
+* -nobase - Updates the target workbench but not the repository. This option is rather useful when copying a set of UDs from a workbench into another.
+* -param - Shows the parameters’ current value.
+
+**Note** that the -nobase and -norefcopy options are mutually exclusive.
+
+#### Examples
+
+~~~~~
+wintegre -ref 2 1 –wb ref
+~~~~~
+Uses the report whose ID is 1 to initialize the ref workbench with BaseNumber equal to 2.
+~~~~~
+wintegre 1 –wb ref
+~~~~~
+Integrates the report whose ID is 1 to ref workbench.
+~~~~~
+wintegre -f 8 –wb ref
+~~~~~
+Forces the integration of report 8. Use the –f option if you want report 8 to be processed first.
+
+
+~~~~~
+wprepare -MyWb -o/tmp/MyReport
+wstore /tmp/MyReport (GetID say 3) –wb ref
+wintegre –wb ref -nobase 3
+~~~~~
+Edit the comment and modify <i>/tmp/MyReport</i> if required with current workbench accessed from ref workbench.
+You may use the -nobase option adding the following line in the VC.edl file (Adm of the concerned file):
+~~~~~
+\@set %VC_TYPE = *NOBASE*;
+~~~~~
+@subsubsection occt_wok_4_9_4 wnews
+
+The command has the following syntax:
+~~~~~
+wnews [-x] [-from p1 -to p2] [-headers|-units|-comments|- all] [-command TclCmd]
+wnews -set markname [ -at p ]
+wnews -ls [-bydate]
+wnews -rm markname
+wnews -admin
+wnews -purge
+~~~~~
+
+The *wnews* command allows managing and using the data stored in the integration journal.
+The integration journal is updated via the command *wintegre* each time an integration is performed; it contains all the UDs and files concerned with the integration, as well as the comments provided by the developers (reports).
+
+Every integration is numbered and the associated files are archived with a specific version number.
+Marks can be set on specific zones of the integrations via the wnews command. A mark is a character string which does not contain any dash character (-) and is associated with an integration number. Several marks may point to the same number, but one mark may only point to one number.
+
+**Note** that *BEGIN* and *END* are reserved mark names. You cannot use them.
+
+Options:
+* -from p1 -to p2 - Extracts a portion of the journal file between index p1 and p2, with p1 and p2 integration numbers or marks. If p1 is not specified, reports are extracted from the beginning of the journal file. If p2 is not specified, reports are extracted up to the end of the journal file.
+* -at p - Places a mark at index p, with p being an integration number. If p is not specified, the mark is placed at the end of the journal.
+* -ls [-bydate] - Lists the marks. If -bydate is specified, the marks are listed in the order they were created. Otherwise, they are listed according to their place in the journal file.
+* -rm <markname> - Removes the mark *markname*.
+* -admin - Displays the journal location, date and other information.
+* -purge - Saves the journal file and creates a new empty one.
+
+Additional options:
+* -o file <name> - Redirects output in file. This option is ignored if -command is specified.
+* -ws <shop> - Uses journal of shop instead of the current one. shop must belong to the current factory.
+* -command <MyCommand> - Runs the command *Tcl MyComm* on the specified part of the journal. The syntax is the following: *proc MyComm { comments table args } { ...}*, where *comments* is a string containing all the comments on the integration between n1 and n2, and *table* is a table indexed with the names of the concerned *uds* (each element of the table is a list of UD files with definition of their status and version). Additional arguments may be passed using *userdata* with the argument *args* containing *mydata1, mydata2*.
+
+Wok provides a similar procedure *wnews:cpwb*, which allows to copy UDs from one workbench into another.
+
+**Note** that you may access the associated code of this command by typing *tclsh>cat $env(WOK_LIBRARY)/news_cpwb.tcl*
+
+For example, we can add the following to the file *Me.tcl*:
+~~~~~
+proc MyComm {comments table args} {
+puts *comments = $comments*
+parray table
+puts *args = $args*
+return
+}
+~~~~~
+Then type the following commands:
+~~~~~
+\> source Me.tcl
+\> wnews -x -from n1 -to n2 -command MyComm -userdata wb1 wb2
+~~~~~
+
+Examples
+--------
+~~~~~
+wnews -set BETA_V1.1 -at 345
+~~~~~
+Sets a mark on integration number 345
+~~~~~
+wnews -set RELEASED_V1.1_CLOSED
+~~~~~
+Sets a mark after the last integration performed
+~~~~~
+wnews -ls
+~~~~~
+Lists all the marks set in the journal
+~~~~~
+wnews -x -from INT_DEB -to INT_END -units
+~~~~~
+Gets all the UDs modified between integrations INT_DEB and INT_END. Integration numbers and marks may be mixed as in the following:
+~~~~~
+wnews -x -from INT_DEB -to 856 -comments
+wnews -x -from INT_DEB -to INT_END -comments
+~~~~~
+Gets all the comments from the integrations between *INT_DEB* and *INT_END*
+~~~~~
+source Mycommand.tcl
+wnews -x -from INT_DEB -to INT_END -command Mycommand
+~~~~~
+In a more elaborate way, a Tcl process may be called to get all information on the reports between *INT_DEB* and *INT_END*.
+~~~~~
+wnews -x -from n1 -to n2 -command wnews:cpwb –userdata w1,w2,[ulist, notes]
+~~~~~
+All modified files between n1 and n2 are copied from workbench w1 into workbench w2. New UDs are created in w2 if required If *ulist* is specified, only the UDs contained in this list are Processed. If notes is specified, all comments between n1 and n2 are written into this file.
+
+@subsubsection occt_wok_4_9_5 wget
+~~~~~
+wget [-l] –wh <MasterWb>
+wget [-f] –wb <MasterWb> [-ud <UnitName>] <SourceFile> [-v <Version>]
+wget [-f] –wb <MasterWb> [-ud <UnitName>] <SourceFile1>...<SourceFileN>
+~~~~~
+The *wget* command allows importing source files into the workbench. The files are fetched from the SCCS database of the factory. This operation is known as a check-out operation. You can specify one or more files or a unit name. By default, the latest version of the files is fetched.
+
+Options:
+* <SourceFile> - Fetches a copy of the specified file.
+* -ud <UnitName> Fetches all the source files of the development unit you specified.
+* -f Forces existing files to be overwritten.
+* -v <Version> Fetches <Version> of the file you specified.
+* -l Lists the files of the development unit that can be copied (i.e. that you can **get**). This is a default option.
+
+#### Example
+
+~~~~~
+wget –wb MasteWb –ud MyUd File1.cxx File2.hxx
+~~~~~
+Fetches the latest version of *File1.cxx* and *File2.hxx*.
+
+@subsubsection occt_wok_4_9_6 Installation Procedure
+
+In the new WOK model:
+ * each workbench can have its own database
+ * the version control environment variables are relative to the workbench.
+@image html /dev_guides/wok/images/wok_image014.jpg "Workshop Installation Model"
+@image latex /dev_guides/wok/images/wok_image014.jpg "Workshop Installation Model"
+
+The following procedure explains how to set up the source management environment for a workshop.
+1. Open the factory and the workshop.
+~~~~~
+\> wokcd <factory:workshop> -P Adm
+~~~~~
+2. Define the environment variables for version control by editing the file *VC.edl*. Your entries should respect the following syntax:
+~~~~~
+\@set %VC_TYPE=”SCCS”
+\@set %VC_ROOT=”/dirA/dirB/.../<MyDir>”
+~~~~~
+3. Reopen the workbench that you want to connect to the database.
+~~~~~
+\> wokcd <factory:workshop:workbench>
+~~~~~
+4. Create SCCS database associated with workbench.
+~~~~~
+\> wstore –create –wb <factory:workshop:workbench> -queue <PathToQueue>
+~~~~~
+5. Create a report associated with the root workbench.
+~~~~~
+\> wprepare –wb <workbench> -o ref.report
+~~~~~
+6. Queue this report.
+~~~~~
+\> wstore –wb <workbench> ref.report
+~~~~~
+7. Perform the actual creation of the SCCS database.
+~~~~~
+> wintegre –wb <workbench> < BaseNumber >
+~~~~~
+Here <BaseNumber> is the first digit of the SCCS version numbers.
+
+@subsubsection occt_wok_4_9_7 Integration Procedure
+
+To integrate, proceed as follows:
+1. Create the report for the current workbench.
+~~~~~
+ \> wprepare –wb MasterWb -o MyReport
+~~~~~
+2. If necessary, edit this report to remove lines and append comments. Comments should begin with -- (double hyphen).
+3. Queue the report and store the files.
+~~~~~
+\> wstore –wb MasterWb MyReport
+~~~~~
+By this step, all the files you have modified have been stored and the report has been queued. You can continue with modifying these files.
+4. Examine the state of the integration queue to get the ID of your report.
+~~~~~
+\> wstore –wb MasterWb -ls
+~~~~~
+5. Perform the integration and be sure you can write in the root workbench. This operation is usually reserved for the workshop administrator.
+~~~~~
+\> wintegre –wb MasterWb [ID]
+~~~~~
+
+@subsection occt_wok_4_10 Session Services
+
+A single session service is also available to allow you to query WOK.
+*Sinfo* command returns details of the WOK session.
+~~~~~
+Sinfo -option
+~~~~~
+
+Options:
+* -F Gets factory list
+* -f Gets current factory
+* -s Gets current workshop
+* -w Gets current workbench
+* -u Gets current development unit
+* -t <entity_path> Gets the entity type
+* -E Reserved for internal use. Gets known Entity List
+* -N Reserved for internal use. Gets known Entity Names
+
+#### Example
+
+~~~~~
+Sinfo -F
+~~~~~
+Returns a list of WOK factories.
+
+@subsubsection occt_wok_4_10_2 Convenience Aliases
+
+To ease the upgrade to the new version of WOK a number of aliases, compatible with the old version, have been set up. These convenience aliases include:
+* **fcd** - Moves to the specified factory.
+* **scd** - Moves to the specified workshop.
+* **wcd** - Moves to the *src* directory of the specified development unit.
+* **wdrv** - Moves to the *drv/DBMS/Station* directory of the current development unit.
+* **wls** - Lists the development units in the current workbench.
+* **wsrc** - Moves to the *src* directory of the current development unit.
+
+@section occt_wok_5 Using the Graphic Interface
+The following is an overall description of the IWOK main menu bar. Please, refer to the on-line help to get more detailed information on the various applications accessed via the graphic interface.
+@subsection occt_wok_5_1 Main menu bar
+@image html /dev_guides/wok/images/wok_image015.png
+@image latex /dev_guides/wok/images/wok_image015.png
+@subsubsection occt_wok_5_1_1 Menus
+The main menu bar contains three menus:
+ * **File** to exit the iwok session,
+ * **Windows** to display all windows created in the session,
+ * **Help** to display the associated on-line help.
+
+@subsubsection occt_wok_5_1_2 Application icons
+The four icons on the left are used to access applications:
+ * **wprepare**, allows preparing the integration queue being associated with a given workshop,
+@image html /dev_guides/wok/images/wok_image016.png
+@image latex /dev_guides/wok/images/wok_image016.png
+ * **umake**, gives access to all available umake options plus compilation options,
+@image html /dev_guides/wok/images/wok_image017.png
+@image latex /dev_guides/wok/images/wok_image017.png
+ * **CDL browser**, provides information on the class structure or translated classes,
+@image html /dev_guides/wok/images/wok_image018.png
+@image latex /dev_guides/wok/images/wok_image018.png
+
+ * **parameters**, allows displaying and editing all EDL files.
+@image html /dev_guides/wok/images/wok_image019.png
+@image latex /dev_guides/wok/images/wok_image019.png
+
+
+**Note:** for further information on CDL, refer to the CDL Reference Manual.
+
+@subsubsection occt_wok_5_1_3 Display management
+Click on the logo to either display or not the session in a window just below the main menu bar.
+
+You may choose to display icons in the window, either in **columns**, with the **last modified first**, by **date and size**, or in **rows**.
+
+Use the **go up** icon to navigate through the session and **wokcd** to update the window where the session was started.
+@image html /dev_guides/wok/images/wok_image020.png
+@image latex /dev_guides/wok/images/wok_image020.png
+
+The field **Location** gives the exact address of the item in the session. Use the arrow on the right to select already visited addresses.
+
+@subsection occt_wok_5_2 Popup menus
+Two types of popup menus may be accessed according to the context. Just click MB3 to display the popup menu.
+
+Click on an item in the left window to get the popup menu providing access to applications.
+
+@image html /dev_guides/wok/images/wok_image021.png
+@image latex /dev_guides/wok/images/wok_image021.png
+
+In the right window you get the selection popup menu for the item types:
+
+@image html /dev_guides/wok/images/wok_image022.png
+@image latex /dev_guides/wok/images/wok_image022.png
+
+@section occt_wok_6 Appendix A. Using the Emacs Editor
+
+WOK is operated using the editor Emacs. Emacs is not provided in the Open CASCADE Technology distribution but is available from http://www.gnu.org/software/emacs/#Releases
+
+A CDL mode has been created for Emacs. The .el file for this mode is not provided in the distribution, but is available on request from OPEN CASCADE.
+
+List of Keys and their Bindings in cdl Mode
+-------------------------------------------
+
+|C-c |Command prefix |
+|TAB | cdl-tab |
+|DEL | backward-delete-character-untabify |
+|ESC | Command prefix |
+|C-c C-x | cdl-new-exception |
+|C-c C-e | cdl-new-enumeration |
+|C-c C-b | cdl-new-buffer |
+|C-c C-p | cdl-new-package |
+|C-c C-r | cdl-new-rubric |
+|C-c C-c | cdl-new-class |
+|C-c f | cdl-fill-mode |
+|C-c s | cdl-structure |
+|C-c t | cdl-tabsize |
+|C-c e | cdl-comment-end |
+|ESC k | cdl-find-class |
+|ESC q | cdl-comment-fill |
+|ESC TAB | cdl-untab |
+|ESC-RET | cdl-raw-newline |
+
+@section occt_wok_7 Appendix B. Parameters and EDL Files
+@subsection occt_wok_7_1 EDL language
+@subsection occt_wok_7_1_1 Key Concepts
+
+EDL is a script-like programming language.
+
+**Comment** - text, preceded by two hyphens.
+~~~~~
+-- Comment text....
+~~~~~
+* **Identifier** - any combination of characters in the ranges A-Z, az, 0-9 and _ (underscore).
+* **Variable** - an identifier preceded by % (percent sign).
+* **Actions** The following actions are available:
+~~~~~
+\@string
+\@set
+\@apply
+~~~~~
+* **Execution** <i>@uses</i> is an execution operator.
+* **Input/Output** The following input/output operators are provided:
+~~~~~
+\@file
+\@write
+\@close
+\@cout
+~~~~~
+* **Conditional Operators** The following conditional operators are provided:
+~~~~~
+\@iffile
+\@ifdefined
+\@ifnotdefined
+\@ifnotfile
+\@if
+then
+\@else
+\@endif
+~~~~~
+
+* **Operators** The following operators are available:
+<code>
+==
+!=
+||
+&&
+file
+notfile
+defined
+notdefined
+</code>
+
+**Templates** The following template commands/keywords are available:
+~~~~~
+\@template
+is
+\@end
+\@addtotemplate
+\@cleartemplate
+~~~~~
+**Miscellaneous** The following miscellaneous commands exist:
+~~~~~
+\@verboseon
+\@verboseoff
+~~~~~
+
+@subsubsection occt_wok_7_1_2 Syntax
+The following conventions are used in the explanations below:
+
+| *<Variable>* | refers to a variable, for example: *%myvariable* |
+| *<Id>* | refers to an identifier, for example: *myidentifier* |
+| *“String”* | refers to a string of characters, for example: *“my string of characters”* |
+| *<Condition>* | refers to a condition, for example: *(%mytest == “ok”) || (%mytest == “good”)* |
+| *<Template>* | refers to the name of a template, for example: mytemplate. |
+|{} | indicates possible repetition of what is within the curly brackets. |
+
+@subsubsection occt_wok_7_1_3 EDL Actions
+\@string
+--------
+~~~~~
+\@string <Variable> = {<Variable> or “String”} ;
+\@string <Variable> += {<Variable> or “String”} ;
+~~~~~
+Concatenates the contents of the variables and strings on the right of the equals sign and assigns the result to the variable situated on the left. Using the operator ‘+=’ instead of ‘=’ adds the concatenation to the current contents of the variable on the left.
+
+\@set
+----
+~~~~~
+\@set <Variable> = “ String” ;
+~~~~~
+Sets <Variable> to the value “String”
+
+\@apply
+------
+~~~~~
+\@apply <Variable> = <Template> ;
+~~~~~
+Evaluates the template, <Template>, and sets <Variable> equal to this.
+
+
+\@uses
+-----
+~~~~~
+\@uses <Variable>;
+\@uses “ String”;
+~~~~~
+Runs an EDL file. The name of this file is either contained in the variable <Variable> or is given as a string, <String>.
+
+\@file
+-----
+~~~~~
+\@file <Id> <Variable> ;
+\@file <Id> “String” ;
+~~~~~
+Opens a file and associates it with the identifier <Id>. This <Id> identifies the file until it is closed. The name of the file is given as a string <String>, or using a variable <Variable>.
+
+\@write
+------
+~~~~~
+\@write <Id> <Variable> ;
+~~~~~
+Writes the contents of the variable out to a file indicated by the file <Id>. This <Id> is the identifier allocated to the file when is opened using \@file.
+
+\@close
+------
+~~~~~
+\@close <Id> ;
+~~~~~
+Closes the file identified by <Id>. This <Id> is the identifier allocated to the file when is opened using \@file.
+
+\@cout
+-----
+~~~~~
+\@cout {<Variable> or “String”} ;
+~~~~~
+Concatenates the contents of the variables and strings and displays the result on standard out.
+
+\@iffile
+-------
+~~~~~
+\@iffile ( <Variable> or “String”) then
+\@endif ;
+\@iffile ( <Variable> or “String”) then
+\@else
+\@endif ;
+~~~~~
+Checks for the existence of a file, the name of which is given in the string ‘String”, or else contained in the variable <Variable>.
+If the file exists, the instructions contained in the ‘then’ loop are executed up to the *\@endif*, (or an \@else if one is found before the \@endif ).
+If the files do not exist, the ‘else’ loop is executed (if one exists).
+
+\@ifnotfile
+----------
+~~~~~
+\@ifnotfile ( <Variable> or “String”) then
+\@endif ;
+\@ifnotfile ( <Variable> or “String”) then
+\@else
+\@endif ;
+~~~~~
+Checks for the existence of a file, the name of which is given in the string ‘String”, or else contained in the variable <Variable>.
+If the file does not exist, the instructions contained in the ‘then’ loop are executed up to the \@endif, (or an \@else if one is found before the \@endif).
+If the file does exist, the ‘else’ loop is executed (if one exists).
+
+\@ifdefined
+----------
+~~~~~
+\@ifnotdefined ( <Variable> or <Template>) then
+\@endif ;
+\@ifnotdefined ( <Variable> or <Template>) then
+\@else
+\@endif ;
+~~~~~
+Checks for the existence of a variable or template, the name of which is given by <Template>, or else contained in the variable <Variable>.
+If a variable or a template by this name exists the instructions contained in the ‘then’ loop are executed up to the \@endif, (or an \@else if one is found before the \@endif).
+If neither a variable nor a template exists, the ‘else’ loop is executed (if one exists).
+
+
+\@ifnotdefined
+-------------
+~~~~~
+\@ifnotdefined ( <Variable> or <Template>) then
+\@endif ;
+\@ifnotdefined ( <Variable> or <Template>) then
+\@else
+\@endif ;
+~~~~~
+Checks for the existence of a variable or template, the name of which is given by <Template>, or else contained in the variable <Variable>.
+If neither a variable nor a template by this name exists the instructions contained in the ‘then’ loop are executed up to the \@endif, (or an \@else if one is found before the \@endif).
+If a variable or a template does exist, the ‘else’ loop is executed (if one exists).
+
+\@if
+-----
+~~~~~
+\@if (<Condition>) then
+\@endif ;
+\@if (<Condition>) then
+\@else
+\@endif ;
+~~~~~
+Tests a condition.
+If the condition is true the instructions in the ‘then’ loop are executed up to the \@endif, (or an \@else if one is found before the \@endif).
+If the condition is false, the ‘else’ loop is executed (if one exists).
+
+\@template
+---------
+~~~~~
+\@template <Template> (<Variable>, ... , <Variable>) is
+ $ text...
+ .
+ .
+ $ text...
+\@end;
+~~~~~
+Creates a template, which is a definition that contains variables. The variables on which a template relies are given in parentheses, following the name of the template. These variables are used to evaluate the template, and are referred to as ‘variables of evaluation’. When a template is evaluated (see \@apply) the variables in its definition are replaced by the current values of the ‘variables of evaluation’.
+A template is re-evaluated each time it is used.
+
+\@addtotemplate
+--------------
+~~~~~
+\@addtotemplate <Template> is
+ $ text
+ .
+ .
+ $ text
+\@end;
+~~~~~
+
+Adds the specified lines to an existing template.
+
+\@cleartemplate
+--------------
+~~~~~
+\@cleartemplate <Template> ;
+~~~~~
+Removes all the lines of a template.
+
+\@verboseon
+----------
+~~~~~
+\@verboseon ;
+~~~~~
+Turns on the verbose mode, such that lines of text are displayed on standard out when you run EDL files.
+
+\@verboseoff
+-----------
+~~~~~
+\@verboseoff ;
+~~~~~
+Turns off the verbose mode, such that lines of text are not displayed on standard out when you run EDL files.
+
+@subsubsection occt_wok_7_1_4 EDL Conditions
+Conditions are used with *\@if* commands. Complex and simple conditions are available. The syntax is similar to C++.
+
+#### Simple Conditions
+Simple conditions test for equality, the existence of a particular file and so on. The general format is:
+~~~~~
+\@if(<Condition>) then
+...
+~~~~~
+The syntax of simple conditions is given below.
+~~~~~
+<Variable> == “String” -- (equals)
+<Variable> != “String” -- (does not equal)
+defined(<Variable>) -- (see \@ifdefined)
+defined(<Template>) -- (see \@ifdefined)
+notdefined(<Variable>) -- (see \@ifnotdefined)
+notdefined(<Template>) -- (see \@ifnotdefined)
+file(<Variable>) -- (see \@iffile)
+file(“String”) -- (see \@iffile)
+notfile(<Variable>) -- (see \@ifnotfile)
+notfile(“String”) -- (see \@ifnotfile)
+~~~~~
+
+#### Complex conditions
+
+
+Complex conditions take into account the results of other conditions. Complex conditions use the operators || (logical OR) or the operator (logical AND). There are no restrictions on the formulation of these conditions:
+* (Simple condition) operator (Simple condition)
+* (Complex condition) operator (Simple condition)
+* (Simple condition) operator (Complex condition)
+* (Complex condition) operator (Complex condition)
+
+For example,
+~~~~~
+\@if ((%a == “0” && %b == “1” && %c == “1”) || %d == “1” && ((%a == “1”) && %b == “1”)) then
+ \@cout “CONDITION TRUE”;
+\@else
+ \@cout “CONDITION FALSE”;
+\@endif;
+~~~~~
+
+@subsection occt_wok_7_2 WOK Parameters
+WOK parameters are defined using EDL. There are two types of EDL parameters: Variables and Templates.
+
+Variables have a ‘fixed’ value. By contrast a template relies on the values of other variables, and must re-evaluate itself each time it is used.
+
+@subsubsection occt_wok_7_2_1 Classes of WOK Parameters
+WOK parameters are grouped according to their class. The following classes exist:
+| CODEGEN | Code generator options, for example options for lex and yacc. |
+| CMPLRS | Compiler options. |
+| LDAR | Archive creation options. |
+| ARX | Archive extraction options. |
+| LDEXE | Executable linker options. |
+| LDSHR | Shared linker options. |
+
+@subsubsection occt_wok_7_2_2 Defining WOK Parameters
+The WOK distribution includes a base configuration for each class of parameters. This base configuration is provided in the form of EDL files, one file per a class of parameters. Each file is named according to the parameter class:
+~~~~~
+<ParamClassName>.edl
+~~~~~
+This configuration file sets the values of all the parameters in the class.
+
+For example, consider a parameter class FOO. There are two variable parameters in this class: FOO_Shared and FOO_Name. These two parameters are assigned a value in the FOO.edl file. The file is given as an example below:
+~~~~~
+-- standard protection against multiple execution
+\@ifnotdefined ( %FOO_EDL) then
+\@set %FOO_EDL = **;
+
+-- set %FOO_Shared according to the platform
+\@if ( %LocalArch != *hp* ) then
+\@set %FOO_Shared = *libCPPExt.so*;
+\@endif;
+\@if ( %LocalArch == *hp* ) then
+\@set %FOO_Shared = *libCPPExt.sl*;
+\@endif;
+
+-- set the FOO_Name parameter to FOO
+\@set %FOO_Name = *FOO*;
+\@endif;
+~~~~~
+
+Note that all the parameters in a class take the name of the class as a prefix to their own name. Parameters of type variable are also prefixed by % (percent symbol):
+~~~~~
+%ClassName_VariableParamName
+ClassName_TemplateParamName
+~~~~~
+A simplified template definition is given as an example below. This definition is based on the FOO parameters set in the previous example above.
+
+Let us define the variable parameter(s) to be used in the template and then the template itself:
+~~~~~
+\@set %FOO_Shared = *libCPPExt.so*;
+\@set %FOO_Name = *FOO*;
+
+\@template FOO_Load ( %FOO_Shared, %FOO_Name) is
+$ %FOO_Load_%FOO_Shared %FOO_Name
+\@end;
+~~~~~
+
+@subsubsection occt_wok_7_2_3 Redefining Parameters
+Occasionally you may want to redefine WOK parameters. For example, you can change the compiler options to force ANSI mode compilation, or redefine how external libraries are referenced.
+Before redefining anything, decide on the scope of the redefinition. Is the redefinition to apply to the whole factory, a single workshop, a workbench, or just a development unit? In some cases you may want to redefine parameters within a delivery unit, so that a parcel is delivered with particular options.
+
+The order in which redefinitions are applied (order of precedence) may mean your options are overwritten by subsequent redefinitions.
+
+#### Redefinition Files
+
+Each entity can have an associated redefinition file for each class of parameters. A redefinition file is an EDL file. It always takes the name of the entity to which it belongs, followed by the name of the class of parameters that it applies to:
+~~~~~
+<EntityName>_<ParamClassName>.edl
+~~~~~
+For example, the file MyFactory_CMPLRS.edl redefines one of more of the parameters in the CMPLRS class. The scope of this redefinition is MyFactory. To be taken into account by WOK, this redefinition file must be created in the administration directory of the entity to which it belongs. To find out the pathname of this directory, use the command:
+~~~~~
+wokinfo -p admfile:<EntityName>_<ParamClassName>.edl <EntityPath>
+~~~~~
+To test whether the file exists actually, use the command:
+~~~~~
+wokinfo -p adminfile:WOK_LDAR.edl WOK=> /adv22/wok/adm
+~~~~~
+There is one exception to this rule for file placement. For a development unit, the redefinition file is treated as a *source *file, and consequently it must be located in the src directory of the unit. To find out the path of this directory, use the command:
+~~~~~
+wokinfo -p source:<UnitName>_<ParamClassName>.edl <UnitPath>
+~~~~~
+
+One of the most common reasons to redefine WOK parameters is to modify compiler options. To do this, for example to add a compile option to the package *MyPack*:
+* In the source directory of MyPk, create file *MyPk_CMPLRS.edl*
+* In this file add the definition:
+~~~~~
+\@string %CMPLRS_CXX_Options += * -DMyDefine=string *;
+~~~~~
+
+Order of Precedence for Parameter Redefinitions
+-----------------------------------------------
+WOK takes parameter (re)definitions into account in the following order.
+* WOK
+* Factory
+* Workshop
+* Parcels (within the Workshop configuration, in the order in which they are declared in the parcel configuration).
+* Workbench (in order of inheritance)
+* Development unit
+WOK provides commands to find out what parameter definitions (and redefinitions) are used, and in what order. You can see what compiler parameters are used by WOK in *CMPLRS.edl* file. To find this file, use the command:
+~~~~~
+ wokparam -S CMPLRS.edl
+~~~~~
+Then run the command.
+~~~~~
+wokparam -F CMPLRS EntityPath
+~~~~~
+This command displays a list of all the definition files, for parameters of type compiler, that are taken into account for EntityPath. These file are listed in the order in which they are taken into account. The last definition is the one that is used.
+
+@subsection occt_wok_7_3 Using EDL to Define WOK Parameters
+@subsubsection occt_wok_7_3_1 Modification of Link Options - Example
+
+#### How to add a define to the compilation
+
+To add a define for all C++ files compiled in the package *MyPackage*, *MyPackage_CMPLRS.edl* is declared in the development unit *MyPackage* This file contains:
+~~~~~
+\@string %CMPLRS_CXX_Options =
+%CMPLRS_CXX_Options * -DMYDEFINE*;
+~~~~~
+
+#### How to use a code generator
+
+In this example, a C code generator is used, which takes the input <i><file>.mygen</i> and generates a <i><file>.c</i>. The step *obj.cgen* automatically recognizes all files with the extension mygen and uses the generator on these files. The resulting .c files are compiled by the step *obj.comp*.
+The file *MyUnit_CODEGEN.edl* is written in a nocdlpack development unit *MyUnit*. This file contains the following code:
+
+~~~~~
+-- list of tools recognized by the step obj.cgen
+-- the tool MYGEN is added
+\@ string %CODEGEN_Tools = %CODEGEN_Tools * CODEGEN_MYGEN*;
+
+-- the tool MYGEN is called via the template CODEGEN_MYGEN_CmdLine
+
+\@set %CODEGEN_MYGEN_Template = *CODEGEN_MYGEN_CmdLine*;
+
+-- the extension of files processed by MYGEN is mygen
+
+\@set %CODEGEN_MYGEN_Extensions = *foo.mygen*;
+
+-- the tool MYGEN is the executable /usr/local/bin/mygen
+
+\@set %CODEGEN_MYGEN_Tool = * /usr/local/bin/mygen*;
+
+-- the tool MYGEN produces a .c file
+
+\@template CODEGEN_MYGEN_Production ( %BaseName ) is
+$%BaseName.c
+\@end;
+
+-- the command executed to construct the .c file is:
+
+\@template CODEGEN_MYGEN_CmdLine ( %CODEGEN_MYGEN_Tool,
+%Source, %BaseName, %OutputDir ) is
+$cd %OutputDir
+$%CODEGEN_MYGEN_Tool -f %Source -o %BaseName.c
+\@end;
+~~~~~
+
+@section occt_wok_8 Appendix C. Tcl
+@subsection occt_wok_8_1 Tcl Overview
+Tcl stands for ‘‘tool command language* and is pronounced ‘‘tickle*. It is actually two things: a language and a library.
+
+As a simple textual language, tcl is intended primarily for issuing commands to interactive programs such as text editors, debuggers, illustrators, and shells. It has a simple syntax and is also programmable, so tcl users can write command procedures to provide more powerful commands than those in the built-in set.
+
+As a library package, tcl can be embedded in application programs. The tcl library consists of a parser for the cl language, routines to implement the tcl builtin commands, and procedures that allow each application to extend tcl with additional commands specific to that application. The application program generates tcl commands and passes them to the tcl parser for execution. Commands may be generated by reading characters from an input source, or by associating command strings with elements of the application's user interface, such as menu entries, buttons, or keystrokes.
+
+For Linux platform it is possible to download Tcltk 8.5 or 8.6 from http://www.tcl.tk/software/tcltk/8.6.html
+For Windows platforn it is possible to download ActiveTcl 8.5 or 8.6 from http://www.activestate.com/activetcl/downloads
+
+A help application, tclhelp, is also provided with tcl and can be activated by command *tclhelp*.
+
+@subsection occt_wok_8_2 Tcl and WOK
+The tcl interpreter offers WOK the following advantages:
+* an environment in which both WOK and UNIX commands are available,
+* dynamic loading of WOK as it is needed,
+* a high performance portable environment, in which the user can write customized procedures.
+
+The following tcl commands are most commonly used with WOK: *expr, foreach, glob, if, package, proc, puts, set, source* and *unlink*.
+
+Refer to the tcl documentation, or the tcl help application, for details of these and other tcl commands.
+
+@subsection occt_wok_8_3 Configuring Your Account for Tcl and WOK
+To have access to WOK you must modify the configuration files of your account as described below.
+@subsubsection occt_wok_8_3_1 The cshrc File
+To allow the C shell session to configure tcl add the following line to your .chsrc file:
+~~~~~
+source/<sun|ao1|sgi|hp>_SYSTEM/util_LOG/cshrc_TCL
+~~~~~
+To configure your account to allow access to WOK add the following line to your .cshrc file:
+~~~~~
+if(!$?WOKHOME) then
+setenv WOKHOME /YOURCONTAINER/wok-<version of wok>
+source /<sun|ao1|sgi|hp>_SYSTEM/util_LOG/cshrc_Wok
+~~~~~
+@subsubsection occt_wok_8_3_2 The tclshrc File
+To enable configuration of the tcl interpreter, add the following line to your .tclshrc if it exists (if not create one):
+~~~~~
+source $env(WOKHOME)/site/tclshrc_Wok
+~~~~~
+
+@subsubsection occt_wok_8_3_3 The WOK_SESSIONID Variable
+The *WOK_SESSIONID* environment variable ensures that you start a new WOK session in the same state and with the same parameter values as your previous WOK session. This continuity is provided by using the same WOK_SESSIONID. Note that your *WOK_SESSIONID* does not change, unless you change it manually.
+
+Make sure that *WOK_SESSIONID* points to (a subdirectory of) your home directory.
+
+@subsubsection occt_wok_8_3_4 Writing Tcl Steps for a WOK Build
+There are three advanced WOK commands available for writing umake steps in tcl:
+ * *msgprint*
+ * *stepoutputadd*
+ * *stepaddexecdepitem*
+
+*msgprint [-i|-w|-e|-v|-V Class]* prints a message. The output is directed to a WOK internal process that is in charge of printing messages.
+
+The following options are available:
+| -i | Prints an information message. |
+| -w | Prints a warning message. |
+| -e | Prints an error message. |
+| -v | Prints a verbose message. |
+| -V<Class> | Prints a verbose message for class <Class>. |
+| -c | Prints context of message, i.e. the procedure that called it. |
+
+For example,
+~~~~~
+msgprint -e -c *CCLKernel_GetObjects::Execute* *Cannot locate object file : * $file;
+~~~~~
+Writes an error message, in format:
+~~~~~
+ERROR: CCLKernel_GetObjects::Execute - Cannot locate object file : MyFile
+~~~~~
+*stepoutputadd <options> <OutputFileID> [<filepath>]* adds an output file to the outputs of the step. This file is treated by subsequent steps in the same way as all the other output files of the step. The following options are available:
+
+| -p<path> | Specifies the path where the file is located. |
+| -L | Output can be located (default). |
+| -N | Not a WOK file. Cannot be located. |
+| -F | Physical file (i.e. resides on a disk somewhere). |
+| -M | File is a member of the unit being built (default). |
+| -X | File is not a member of the unit being built. Not a WOK file. Cannot be located. |
+| -P | File is produced by this umake step (i.e. WOK can delete it because it will be regenerated). |
+| -R | File is not produced by this umake step (i.e. WOK must not delete it because it can not be regenerated).
+| -S<StepID> | Reserved for advanced use. Specifies stepID. |
+| -V | Reserved for advanced use. Virtual ‘file’ (i.e. an MSEntity). This option is used for passing keywords between steps for example. |
+
+For example,
+~~~~~
+stepoutputadd -X -R -N -F /usr/myfiles/res.o -p /usr/myfiles/res.o
+~~~~~
+Adds the file */usr/myfiles/res.o* to the outputs of this step. Specifies that this file is not a WOK file, cannot be located automatically by WOK, and is not generated by this step. Here the full file path is used as the unique file identifier. This appears to be duplicated when it is also given as the physical location of the file.
+
+*stepaddexecdepitem <options> <InputFileID> <OutputFileID>* adds a dependency between one file and another. Typically when introducing external object libraries the files are set to be dependent on the CDL file. We do this because the CDL file changes rarely, so the external files are not needlessly reprocessed, but they are always included in the final executable. The following options are available:
+
+| -d | Adds a direct dependency (default). |
+| -i | Adds an indirect dependency. |
+
+For example,
+~~~~~
+stepaddexecdepitem -d MyInFile MyOutFile
+~~~~~
+States that the file *MyOutFile* depends directly on the file *MyInFile*.
+
+@subsubsection occt_wok_8_3_5 Components of a Tcl UMake Step
+
+Each tcl umake step has the following components:
+* *HandleInputFile* - a filter: for each input file this component decides whether or not to accept the file.
+* *OutputDirTypeName* returns one of three strings, according to the dependency of the file:
+ * *tmpfile* = the file is independent (i.e. dependent only on its source);
+ * *dbtmpdir* = the file is dependent on the database profile;
+ * *sttmpdir* = the file is dependent on the station profile.
+* *AdmFileType* returns one of three strings, according to the dependency of the file:
+ * *admfile* = the file is independent (i.e. dependent only on its source);
+ * *Dbadmfile* = the file is dependent on the database profile;
+ * *stadmfile* = the file is dependent on the station profile.
+
+*Execute* processes each input file that is out of date (i.e. has changed since it was last processed, or depends on a file that has changed since it was last processed). Typically this procedure takes the form of a *foreach* loop. Argument: a development unit to process and a list of one or more arguments.
+
+@subsubsection occt_wok_8_3_6 Sample Tcl Steps
+
+#### Sample 1
+
+~~~~~
+# CCLKernel_GetObjects.tcl
+proc CCLKernel_GetObjects::AdmFileType {} {
+ return stadmfile;
+}
+proc CCLKernel_GetObjects::OutputDirTypeName {} {
+ return sttmpdir;
+}
+proc CCLKernel_GetObjects::HandleInputFile { ID } {
+ scan $ID *%\[^:\]:%\[^:\]:%\[^:\]* unit type name
+ return 1;
+ switch [file extension $name] {
+.cdl {
+ return 1;
+ }
+ default {
+ return 0;
+ }
+ }
+}
+proc CCLKernel_GetObjects::Execute { unit args } {
+ msgprint -i -c *CCLKernel_GetObjects::Execute*
+ *Processing unit : $unit*;
+ msgprint -i -c *CCLKernel_GetObjects::Execute*
+ set failed 0;
+ set inid [lindex $args 0]
+ foreach file { Frontal_Ccal_Init_Request.o Frontal_Ccal_Send_Request.o \
+Frontal_Ccal_sd.o Frontal_Get_Response.o Frontal_Ccal_Connect.o } {
+set resid *Frontal:object:$file*
+set path [woklocate -p $resid]
+if { $path == ** } {
+ msgprint -e -c *CCLKernel_GetObjects::Execute*
+*Cannot locate object file : * $file;
+ set failed 1;
+} else {
+ msgprint -i -c *CCLKernel_GetObjects::Execute* *Add
+object $file at * $path
+ stepoutputadd -X -R -L -F $resid
+ stepaddexecdepitem -d $inid $resid
+ }
+}
+if { [wokparam -e %Station] == *sun* } {
+ set file *risc_return.o*
+ set resid *CCLKernel:source:$file*
+ set path [woklocate -p $resid]
+## set path */adv_23/wb/kl/Kernel7/prod/EngineStarter/
+src/risc_return.o*
+ msgprint -i -c *CCLKernel_GetObjects::Execute* *Add
+object $file at * $path
+ stepoutputadd -X -R -N -F $path -p $path
+ stepaddexecdepitem -d $inid $path
+}
+set home [wokparam -e %Ilog_Home]
+if { $home == ** } {
+ msprint -c *CCLKernel_GetObjects::Execute* -e *Cannot
+evaluate parameter : %Ilog_Home
+ return 1;
+}
+foreach file { llstdio.o llfloat.o llfloat31.o cfix.o
+lelisp.o getgloba.o cload.o } {
+ set path *$home/o/$file*
+ msgprint -i -c *CCLKernel_GetObjects::Execute* *Add
+object $file at * $path
+ stepoutputadd -X -R -N -F $path -p $path
+ stepaddexecdepitem -d $inid $path
+}
+set file *lelisp31bin.o*
+set path *$home/lelisp31bin.o*
+msgprint -i -c *CCLKernel_GetObjects::Execute* *Add
+object $file at * $path
+stepoutputadd -X -R -N -F $path -p $path
+stepaddexecdepitem -d $inid $path
+if { $failed } {return 1;}
+return 0;
+}
+~~~~~
+Sample 2
+--------
+# File Name: CCLKernel_core.tcl
+proc CCLKernel_core::AdmFileType {} {
+ return stadmfile;
+}
+proc CCLKernel_core::OutputDirTypeName {} {
+ return sttmpdir;
+}
+proc CCLKernel_core::HandleInputFile { ID } {
+ scan $ID *%\[^:\]:%\[^:\]:%\[^:\]* unit type name
+ switch $type {
+executable {
+ return 1;
+}
+ }
+ switch $name {
+CCL_lelisp.ll {
+ return 1;
+ }
+}
+ return 0;
+ }
+proc CCLKernel_core::Execute { unit args } {
+ global WOK_GLOBALS env
+msgprint -i -c *CCLKernel_core::Execute* *Processing unit : $unit*;
+ msgprint -i -c *CCLKernel_core::Execute*
+ set workbench [wokinfo -N $unit]
+ set unitname [wokinfo -n $unit]
+ set failed 0;
+ set lispbin **
+ set lispfile **
+ set lispbinid **
+ set lispfileid **
+ foreach ID $args {
+scan $ID *%\[^:\]:%\[^:\]:%\[^:\]* Unit type name
+switch $type {
+ executable {
+ set lispbinid $ID
+ set lispbin [stepinputinfo -p $ID]
+ }
+}
+switch $name {
+CCL_lelisp.ll {
+set lispfileid $ID
+set lispfile [stepinputinfo -p $ID]
+}
+}
+}
+if { $lispfile == **} {
+set lispfileid *CCLKernel:source:CCL_lelisp.ll*;
+set lispfile [woklocate -p $lispfileid $workbench]
+}
+if { $lispbin == **} {
+msgprint -e -c *CCLKernel_core::Execute* *Cannot find lelispbin in input*
+return 1;
+}
+msgprint -i -c *CCLKernel_core::Execute* *Using lelisp.bin at * $lispbin
+msgprint -i -c *CCLKernel_core::Execute*
+set config *[wokparam -e %Ilog_Home]/config*
+set tmpdir [wokinfo -p sttmpdir:. $unit]
+set output [wokinfo -p executable:. $unit]
+set lelisppointbin [wokinfo -p executable:lelisp.bin $unit]
+unlink -nocomplain $lelisppointbin
+link -sym $lispbin $lelisppointbin
+msgprint -i -c *CCLKernel_core::Execute* *Setting Environment*
+set WOK_GLOBALS(setenv_proc,tcl) 1
+wokenv -s
+set WOK_GLOBALS(setenv_proc,tcl) 0
+set olddir [pwd]
+cd [wokinfo -p source:. $unit]
+set FrontSIZE *-stack 12 -code 1500 -heap 2048 -number 0 -vector 32 -string 50 -symbol 30 -float 0 -cons *
+msgprint -i -c *CCLKernel_core::Execute* *Exec : $config $tmpdir $lispbin $lispfile $output $FrontSIZE 8*
+puts *exec /bin/env \\
+COREDIR=$output \\
+WBPACKAGE=[wokinfo -n $unit] ILOG_LICENSE_FILE=[wokparam -e %Ilog_LicenseFile] \\
+CSF_EngineStarterList=/usr/local/etc/
+EngineStarter.Hosts \\
+ILOG_LICENSE_FILE=[wokparam -e %Ilog_LicenseFile] \\
+\*FrontSIZE=$FrontSIZE\* \\
+$config $tmpdir $lispbin $lispfile $output $FrontSIZE 8*
+msgprint -i -c *CCLKernel_core::Execute* [eval *exec /bin/env \\
+ COREDIR=$output \\
+ WBPACKAGE=[wokinfo -n $unit] \\
+ ILOG_LICENSE_FILE=[wokparam -e %Ilog_LicenseFile] \\
+ CSF_EngineStarterList=/usr/local/etc/ EngineStarter.Hosts \\
+ \*FrontSIZE=$FrontSIZE\* \\
+$config $tmpdir $lispbin $lispfile $output $FrontSIZE 8*]
+ stepoutputadd -P $unitname:corelisp:$unitname.core
+ stepaddexecdepitem -d $lispbinid
+$unitname:corelisp:$unitname.core
+ stepaddexecdepitem -d $lispfileid
+$unitname:corelisp:$unitname.core
+ cd $olddir
+ return 0;
+}
+~~~~~
\ No newline at end of file
puts $texfile "\\fancyhead\[RO\]{\\fancyplain{}{\\bfseries\\thepage}}"
puts $texfile "\\fancyfoot\[LE\]{\\fancyplain{}{}}"
puts $texfile "\\fancyfoot\[CE\]{\\fancyplain{}{}}"
- puts $texfile "\\fancyfoot\[RE\]{\\fancyplain{}{\\bfseries\\scriptsize © Open CASCADE Technology 2001\-2013}}"
- puts $texfile "\\fancyfoot\[LO\]{\\fancyplain{}{\\bfseries\\scriptsize © Open CASCADE Technology 2001\-2013}}"
+ puts $texfile "\\fancyfoot\[RE\]{\\fancyplain{}{\\bfseries\\scriptsize (c) Open CASCADE Technology 2001\-2013}}"
+ puts $texfile "\\fancyfoot\[LO\]{\\fancyplain{}{\\bfseries\\scriptsize (c) Open CASCADE Technology 2001\-2013}}"
puts $texfile "\\fancyfoot\[CO\]{\\fancyplain{}{}}"
puts $texfile "\\fancyfoot\[RO\]{\\fancyplain{}{}}"
puts $texfile "\\renewcommand{\\footrulewidth}{0.4pt}"
puts $texfile "}"
puts $texfile "\n"
puts $texfile "%===== C O N T E N T S =====\n"
+# puts $texfile "\\DeclareUnicodeCharacter{00A0}{ }"
puts $texfile "\\begin{document}"
puts $texfile ""
puts $texfile "% Titlepage & ToC"
puts $texfile "\\begin{titlepage}"
puts $texfile "\\vspace*{7cm}"
puts $texfile "\\begin{center}%"
- puts $texfile "\\includegraphics\[width=0.75\\textwidth, height=0.2\\textheight\]{occttransparent.png}\\\\\\\\"
+ puts $texfile "\\includegraphics\[width=0.75\\textwidth, height=0.2\\textheight\]{overview_occttransparent.png}\\\\\\\\"
puts $texfile "{\\Large Open C\\-A\\-S\\-C\\-A\\-D\\-E Technology \\\\\[1ex\]\\Large 6.\\-6.\\-0 }\\\\"
puts $texfile "\\vspace*{1cm}"
puts $texfile "{\\Large $docLabel}\\\\"
if {$verboseMode == "YES"} {
puts "INFO: Preprocessing file $TEX"
}
+
+ if {![file exists $TEX]} {
+ puts "file $TEX doesn't exist"
+ return
+ }
+
set IN_F [open "$TEX" r]
set TMPFILENAME "$latexDir/temp.tex"
+
set OUT_F [open $TMPFILENAME w]
while {1} {
}
# Prepare a list of TeX files, generated by Doxygen
+ puts "go to $LATEXDIR"
cd $LATEXDIR
set TEXFILES [glob $LATEXDIR -type f -directory $LATEXDIR -tails "*.tex" ]
set REFMAN_IDX [lsearch $TEXFILES "refman.tex"]
set TEXFILES [lreplace $TEXFILES $REFMAN_IDX $REFMAN_IDX]
- set REFMAN_IDX [lsearch $TEXFILES "index.tex"]
- set TEXFILES [lreplace $TEXFILES $REFMAN_IDX $REFMAN_IDX]
+
set IDX [lsearch $TEXFILES "$LATEXDIR"]
while { $IDX != -1} {
set IDX [lsearch $TEXFILES "$LATEXDIR"]
}
- # Preprocess generated TeX files
+ puts "Preprocess generated TeX files"
OverviewDoc_ProcessTex $TEXFILES $LATEXDIR $verboseMode
- # Generate PDF files from
+ puts "Generate PDF files from"
foreach TEX $TEXFILES {
# Rewrite existing REFMAN.tex file...
set TEX [string range $TEX 0 [ expr "[string length $TEX] - 5"]]
puts "INFO: Generating PDF file from $TEX"
}
# ...and use it to generate PDF from TeX...
+ puts "execute $LATEXDIR/make$PREFIX"
set RESULT [catch {eval exec [auto_execok $LATEXDIR/make$PREFIX] > "$OUTDIR/pdflatex_out.log"} LaTeX_ERROR]
if {$RESULT != 0} {
if {[llength [split $LaTeX_ERROR "\n"]] > 1} {
if { [file exists $PDFDIR/$TEX.pdf] == 1 } {
file delete -force $PDFDIR/$TEX.pdf
}
+
+ if {![file exists "$LATEXDIR/refman.pdf"]} {
+ puts "file $LATEXDIR/refman.pdf doesn't exist"
+ return
+ }
+
file rename $LATEXDIR/refman.pdf "$PDFDIR/$TEX.pdf"
}
if {$verboseMode == "YES"} {
To illustrate the use of classes provided in the 3D geometric modeling toolkits, you will create a bottle as shown:
-
+@image html /overview/tutorial/images/tutorial_image001.png
+@image latex /overview/tutorial/images/tutorial_image001.png
In the tutorial we will create, step-by-step, a function that will model a bottle as shown above. You will find the complete source code of this tutorial, including the very function *MakeBottle* in the distribution of Open CASCADE Technology. The function body is provided in the file samples/qt/Tutorial/src/MakeBottle.cxx.
In addition, we decide that the bottle's profile (base) will be centered on the origin of the global Cartesian coordinate system.
-
+@image html /overview/tutorial/images/tutorial_image002.png
+@image latex /overview/tutorial/images/tutorial_image002.png
This modeling requires four steps:
To create the bottle's profile, you first create characteristic points with their coordinates as shown below in the (XOY) plane. These points will be the supports that define the geometry of the profile.
-
+@image html /overview/tutorial/images/tutorial_image003.png
+@image latex /overview/tutorial/images/tutorial_image003.png
There are two classes to describe a 3D Cartesian point from its X, Y and Z coordinates in Open CASCADE Technology:
@subsection OCCT_TUTORIAL_SUB2_2 Profile: Defining the Geometry
With the help of the previously defined points, you can compute a part of the bottle's profile geometry. As shown in the figure below, it will consist of two segments and one arc.
-
+@image html /overview/tutorial/images/tutorial_image004.png
+@image latex /overview/tutorial/images/tutorial_image004.png
To create such entities, you need a specific data structure, which implements 3D geometric objects. This can be found in the Geom package of Open CASCADE Technology.
In Open CASCADE Technology a package is a group of classes providing related functionality. The classes have names that start with the name of a package they belong to. For example, *Geom_Line* and *Geom_Circle* classes belong to the *Geom* package. The *Geom* package implements 3D geometric objects: elementary curves and surfaces are provided as well as more complex ones (such as *Bezier* and *BSpline*).
* Three edges out of the previously computed curves.
* One wire with these edges.
-
+@image html /overview/tutorial/images/tutorial_image005.png
+@image latex /overview/tutorial/images/tutorial_image005.png
However, the *TopoDS* package provides only the data structure of the topological entities. Algorithm classes available to compute standard topological objects can be found in the *BRepBuilderAPI* package.
To create an edge, you use the BRepBuilderAPI_MakeEdge class with the previously computed curves:
* compute a new wire by reflecting the existing one.
* add the reflected wire to the initial one.
-
+@image html /overview/tutorial/images/tutorial_image006.png
+@image latex /overview/tutorial/images/tutorial_image006.png
To apply a transformation on shapes (including wires), you first need to define the properties of a 3D geometric transformation by using the gp_Trsf class. This transformation can be a translation, a rotation, a scale, a reflection, or a combination of these.
In our case, we need to define a reflection with respect to the X axis of the global coordinate system. An axis, defined with the gp_Ax1 class, is built out of a point and has a direction (3D unitary vector). There are two ways to define this axis.
| Face | Solid |
| Shell | Compound of Solids |
-
+@image html /overview/tutorial/images/tutorial_image007.png
+@image latex /overview/tutorial/images/tutorial_image007.png
Your current profile is a wire. Referring to the Shape/Generates table, you need to compute a face out of its wire to generate a solid.
To create a face, use the *BRepBuilderAPI_MakeFace* class. As previously explained, a face is a part of a surface bounded by a closed wire. Generally, *BRepBuilderAPI_MakeFace* computes a face out of a surface and one or more wires.
* applied on all edges of the shape
* have a radius of *myThickness* / 12
-
+@image html /overview/tutorial/images/tutorial_image008.png
+@image latex /overview/tutorial/images/tutorial_image008.png
To apply fillets on the edges of a shape, you use the *BRepFilletAPI_MakeFillet* class. This class is normally used as follows:
To add a neck to the bottle, you will create a cylinder and fuse it to the body. The cylinder is to be positioned on the top face of the body with a radius of *myThickness* / 4. and a height of *myHeight* / 10.
-
+@image html /overview/tutorial/images/tutorial_image009.png
+@image latex /overview/tutorial/images/tutorial_image009.png
To position the cylinder, you need to define a coordinate system with the *gp_Ax2* class defining a right-handed coordinate system from a point and two directions - the main (Z) axis direction and the X direction (the Y direction is computed from these two).
To align the neck with the center of the top face, being in the global coordinate system (0, 0, *myHeight*), with its normal on the global Z axis, your local coordinate system can be defined as follows:
* Create a parallel wall W2 from W1 at a distance D. If D is positive, W2 will be outside the initial solid, otherwise it will be inside.
* Compute a solid from the two walls W1 and W2.
-
+@image html /overview/tutorial/images/tutorial_image010.png
+@image latex /overview/tutorial/images/tutorial_image010.png
To compute a thick solid, you create an instance of the *BRepOffsetAPI_MakeThickSolid* class by giving the following information:
Using the same coordinate system *neckAx2* used to position the neck, you create two cylindrical surfaces *Geom_CylindricalSurface* with the following radii:
-
+@image html /overview/tutorial/images/tutorial_image011.png
+@image latex /overview/tutorial/images/tutorial_image011.png
Notice that one of the cylindrical surfaces is smaller than the neck. There is a good reason for this: after the thread creation, you will fuse it with the neck. So, we must make sure that the two shapes remain in contact.
* R is the radius of the cylindrical surface.
* U range is [0, 2PI] and V is infinite.
-
+@image html /overview/tutorial/images/tutorial_image012.png
+@image latex /overview/tutorial/images/tutorial_image012.png
The advantage of having such parameterized geometries is that you can compute, for any (U, V) parameters of the surface:
There is another advantage of these parametric equations: you can consider a surface as a 2D parametric space defined with a (U, V) coordinate system. For example, consider the parametric ranges of the neck's surface:
-
+@image html /overview/tutorial/images/tutorial_image013.png
+@image latex /overview/tutorial/images/tutorial_image013.png
Suppose that you create a 2D line on this parametric (U, V) space and compute its 3D parametric curve. Depending on the line definition, results are as follows:
* In V parameter: between 0 and myHeighNeck for the height description
* In U parameter: between 0 and 2PI for the angle description. But, since a cylindrical surface is U periodic, you can decide to extend this angle evolution to 4PI as shown in the following drawing:
-
+@image html /overview/tutorial/images/tutorial_image014.png
+@image latex /overview/tutorial/images/tutorial_image014.png
In this (U, V) parametric space, you will create a local (X, Y) coordinate system to position the curves to be created. This coordinate system will be defined with:
* A center located in the middle of the neck's cylinder parametric space at (2*PI, myNeckHeight / 2) in U, V coordinates.
* A X direction defined with the (2*PI, myNeckHeight/4) vector in U, V coordinates, so that the curves occupy half of the neck's surfaces.
-
+@image html /overview/tutorial/images/tutorial_image015.png
+@image latex /overview/tutorial/images/tutorial_image015.png
To use 2D primitive geometry types of Open CASCADE Technology for defining a point and a coordinate system, you will once again instantiate classes from gp:
You will now define the curves. As previously mentioned, these thread profiles are computed on two cylindrical surfaces. In the following figure, curves on the left define the base (on *aCyl1* surface) and the curves on the right define the top of the thread's shape (on *aCyl2* surface).
-
+@image html /overview/tutorial/images/tutorial_image016.png
+@image latex /overview/tutorial/images/tutorial_image016.png
You have already used the *Geom* package to define 3D geometric entities. For 2D, you will use the *Geom2d* package. As for *Geom*, all geometries are parameterized. For example, a *Geom2d_Ellipse* ellipse is defined from:
* compute the edges of the neck's threading.
* compute two wires out of these edges.
-
+@image html /overview/tutorial/images/tutorial_image017.png
+@image latex /overview/tutorial/images/tutorial_image017.png
Previously, you have built:
There are always faster ways to build a solid when the base topology is defined. You would like to create a solid out of two wires. Open CASCADE Technology provides a quick way to do this by building a loft: a shell or a solid passing through a set of wires in a given sequence.
The loft function is implemented in the *BRepOffsetAPI_ThruSections* class, which you use as follows:
-
+@image html /overview/tutorial/images/tutorial_image018.png
+@image latex /overview/tutorial/images/tutorial_image018.png
* Initialize the algorithm by creating an instance of the class. The first parameter of this constructor must be specified if you want to create a solid. By default, *BRepOffsetAPI_ThruSections* builds a shell.
* Add the successive wires using the AddWire method.
Congratulations! Your bottle is complete. Here is the result snapshot of the Tutorial application:
-
+@image html /overview/tutorial/images/tutorial_image019.png
+@image latex /overview/tutorial/images/tutorial_image019.png
We hope that this tutorial has provided you with a feel for the industrial strength power of Open CASCADE Technology.
If you want to know more and develop major projects using Open CASCADE Technology, we invite you to study our training, support, and consulting services on our site at http://www.opencascade.org/support. Our professional services can maximize the power of your Open CASCADE Technology applications.
@section OCCT_TOVW_SECTION_1 Product Overview
-Open CASCADE Technology is an object-oriented C++ class librarLzlz ljky designed for rapid
-production of sophisticated domain-specific design applications. A typical application
-developed using OCCT deals with two or three-dimensional (2D or 3D) geometric modeling
+Open CASCADE Technology is an object-oriented C++ class librarLzlz ljky designed for rapid production of sophisticated domain-specific design applications. A typical application developed using OCCT deals with two or three-dimensional (2D or 3D) geometric modeling
in general-purpose or specialized Computer Aided Design (CAD) systems, manufacturing
or analysis applications, simulation applications, or illustration tools. OCCT Object
Libraries help you to develop your applications significantly faster.
-
+@image html /technical_overview/images/technical_overview_over.png
+@image latex /technical_overview/images/technical_overview_over.png
The OCCT Library provides the following services:
* Kernel Classes
* Math Utilities
- * Basic Persistence
+ * Basic Persistence
The technical overview provides only a basic description of the libraries. Please, refer for more details to Foundation Classes User's guide
@subsection OCCT_TOVW_SECTION_2_1 Kernel Classes
-Root Classes
-------------
+### Root Classes
+
Root Classes, primarily implemented in the Standard package, are the predefined classes on which
all other Open CASCADE Technology classes are built. They provide:
* Management of exceptions,
* Encapsulation of C++ streams.
-Quantities
------------
+### Quantities
Quantity classes provide the following services:
* Resources to manage color definition
A mathematical quantity is characterized by the name and the value (real).
-A physical quantity is characterized by the name, the value (real) and the unit.
+A physical quantity is characterized by the name, the value (real) and the unit.
The unit may be either an international unit complying with the International Unit System (SI)
or a user defined unit. The unit is managed by the physical quantity user.
<i>Quantity</i> package includes all commonly used basic physical quantities.
-Exceptions
-----------
+### Exceptions
Exception classes list all the exceptions, which can be raised by any OCCT function.
a specific OCCT code is used instead.
-Strings
--------
+### Strings
Strings are classes that handle dynamically sized sequences of characters based on
ASCII/Unicode UTF-8 (normal 8-bit character type)
These classes are implemented in <i>TCollection</i> and <i>NCollection</i> packages.
-Collections
------------
+### Collections
Apart from strings, the <i> TCollection</i> package contains classes of dynamically sized
aggregates of data. They include a wide range of collections.
@subsection OCCT_TOVW_SECTION_2_2 Math Utilities
-Vectors and Matrices
---------------------
+### Vectors and Matrices
+
The <i> Vector</i> and <i> Matrix </i> classes provide commonly used mathematical algorithms which
include:
math_Vector v1(1, 3), v2(0, 2);
v2 = v1; // v1 is copied into v2
- // a modification of v1 does not affect v2
+ // a modification of v1 does not affect v2
~~~
Vector and Matrix elements can be retrieved using indexes, which must be in the range
Some operations on Vector and Matrix objects may not be legal. In this case an exception
is raised. Two standard exceptions are used:
- * <i> Standard_DimensionError </i> exception is raised when two matrices or vectors involved
+ *<i>Standard_DimensionError</i> exception is raised when two matrices or vectors involved
in an operation are of incompatible dimensions.
- * <i> Standard_RangeError </i>exception is raised if an attempt to access outside the range
+ *<i>Standard_RangeError</i>exception is raised if an attempt to access outside the range
defined upon creation of a vector or a matrix is made.
~~~
math_Vector v1(1, 3), v2(1, 2), v3(0, 2);
- v1 = v2; // error:
- // Standard_DimensionError is raised
-
- v1 = v3; // OK: ranges are not equal
- // but dimensions are compatible
-
- v1(0) = 2.0; // error:
- // Standard_RangeError is raised
+ v1 = v2; // error: Standard_DimensionError is raised
+ v1 = v3; // OK: ranges are not equal, but dimensions are compatible
+ v1(0) = 2.0; // error: Standard_RangeError is raised
~~~
-Fundamental Geometry Types
--------------------------
+### Fundamental Geometry Types
The Fundamental Geometry Types component groups the following packages:
-
- * geometric processor package <i> gp</i>;
- * <i>GeomAbs</i> package, which provides enumerations generally used in geometry.
+* geometric processor package <i> gp</i>;
+* <i>GeomAbs</i> package, which provides enumerations generally used in geometry;
<i>gp</i> package is a STEP-compliant implementation of basic geometric and algebraic
entities, used to define and manipulate elementary data structures.
In particular, <i>gp</i> provides:
* descriptions of primitive geometric shapes, such as:
- * Points;
- * Vectors;
- * Lines;
- * Circles and conics;
- * Planes and elementary surfaces;
- * positioning of these shapes in space or in a plane by means of an axis or a coordinate system;
- * definition and application of geometric transformations to these shapes:
- * Translations;
- * Rotations;
- * Symmetries;
- * Scaling transformations;
- * Composed transformations;
- * Tools (coordinates and matrices) for algebraic computation.
+ * Points;
+ * Vectors;
+ * Lines;
+ * Circles and conics;
+ * Planes and elementary surfaces;
+ * positioning of these shapes in space or in a plane by means of an axis or a coordinate system;
+ * definition and application of geometric transformations to these shapes:
+ * Translations;
+ * Rotations;
+ * Symmetries;
+ * Scaling transformations;
+ * Composed transformations;
+ * Tools (coordinates and matrices) for algebraic computation.
These functions are defined in 3D space and in the plane.
simplest data structures, i.e. those of <i> gp</i>. Thus, the <i> ElCLib</i> and <i> ElSLib</i> packages
provide functions to compute:
- * the point of parameter u on a 2D or 3D gp curve,
- * the point of parameter (u,v) on a gp elementary surface, and
- * any derivative vector at this point.
+ * the point of parameter u on a 2D or 3D gp curve,
+ * the point of parameter (u,v) on a gp elementary surface, and
+ * any derivative vector at this point.
Note: the <i> gp</i> entities cannot be shared when they are inside more complex data structures.
-Common Mathematical Algorithms
-----------------------
+### Common Mathematical Algorithms
Common mathematical algorithms provided in OCCT include:
* Algorithms to find roots of one or of a set of non-linear equations,
* An algorithm to find the eigenvalues and eigenvectors of a square matrix.
-
@section OCCT_TOVW_SECTION_3 Modeling Data
Modeling Data supplies data structures to represent 2D and 3D geometric models.
-
+@image html /technical_overview/images/technical_overview_md.png
+@image latex /technical_overview/images/technical_overview_md.png
These services are organized into the following libraries:
<i> Geom2d</i> package provides an implementation of 2D geometric objects complying with
STEP, part 42. In particular, it provides functions for:
-
- * description of points, vectors and curves,
- * their positioning in the plane using coordinate systems,
- * their geometric transformation, by applying translations, rotations, symmetries, scaling transformations and combinations thereof.
+* description of points, vectors and curves,
+* their positioning in the plane using coordinate systems,
+* their geometric transformation, by applying translations, rotations, symmetries, scaling transformations and combinations thereof.
The key characteristic of <i> Geom2d </i> curves is that they are parameterized.
Each class provides functions to work with the parametric equation of the curve,
from the abstract class <i> Geom2d_Conic</i>, while a Bezier curve (concrete class <i> Geom2d_BezierCurve</i>)
is also a bounded curve and inherits from the abstract class <i> Geom2d_BoundedCurve</i>;
both these examples are also curves (abstract class <i>Geom2d_Curve</i>). Curves, points
-and vectors inherit from the abstract class <i> Geom2d_Geometry,<i> which describes the properties
+and vectors inherit from the abstract class <i> Geom2d_Geometry,</i> which describes the properties
common to any geometric object from the <i>Geom2d</i> package.
This inheritance structure is open and it is possible to describe new objects which
* description of points, vectors, curves and surfaces,
* their positioning in 3D space using axis or coordinate systems, and
- * their geometric transformation, by applying translations, rotations, symmetries, scaling transformations and combinations thereof.
+ * their geometric transformation, by applying translations, rotations, symmetries, scaling transformations and combinations thereof.
The key characteristic of Geom curves and surfaces is that they are parameterized.
Each class provides functions to work with the parametric equation of the curve or
surface, and, in particular, to compute:
- * the point of parameter u on a curve, or
- * the point of parameters (u, v) on a surface.
+ * the point of parameter u on a curve, or
+ * the point of parameters (u, v) on a surface.
together with the derivative vectors of order 1, 2, ... N at this point.
Geom objects.
-Adaptors for Curves and Surfaces
------------------
+### Adaptors for Curves and Surfaces
Some Open CASCADE Technology general algorithms may work theoretically on numerous types of curves or surfaces.
To do this, they simply get the services required of the analysed curve or surface through an interface so as to a single API, whatever the type of curve or surface. These interfaces are called adaptors.
When you write an algorithm which operates on geometric objects, use <i> Adaptor3d</i> (or <i> Adaptor2d</i>) objects.
As a result, you can use the algorithm with any kind of object,
-if you provide for this object, an interface derived from Adaptor3d or Adaptor2d.
-These interfaces are easy to use: simply create an adapted curve or surface from a Geom2d curve,
+if you provide for this object, an interface derived from *Adaptor3d* or *Adaptor2d*.
+These interfaces are easy to use: simply create an adapted curve or surface from a *Geom2d* curve,
and then use this adapted curve as an argument for the algorithm which requires it.
* Calculation of points on a 2D or 3D curve;
* Calculation of extrema between two geometries.
-Direct Construction
--------
+### Direct Construction
The <i> gp</i>, <i> Geom2d</i> and <i> Geom</i> packages describe elementary data structures of simple geometric
objects. The constructors of these objects are elementary: the construction arguments
<i> gce</i>, <i> GCE2d</i> and <i> GC </i>each offer a series of classes of construction algorithms.
-For example, the class <i> gce_MakeCirc</i> provides a framework
+For example, the class <i>gce_MakeCirc</i> provides a framework
for defining eight problems encountered in the geometric construction of circles,
and implementing the eight related construction algorithms.
The object created (or implemented) is an algorithm which can be consulted to find out, in particular:
- * its result, which is a </i>gp_Circ</i>, and
- * its status. Here, the status indicates whether or not the construction was successful.
+ * its result, which is a <i>gp_Circ</i>, and
+ * its status. Here, the status indicates whether or not the construction was successful.
If it was unsuccessful, the status gives the reason for the failure.
gp_Pnt P3 (10.,0.,0.);
gce_MakeCirc MC (P1,P2,P3);
if (MC.IsDone()) {
- const gp_Circ& C = MC.Value();
+ const gp_Circ& C = MC.Value();
}
~~~~
Note: classes which construct geometric transformations do not return a status, and
therefore do not inherit from Root.
-Approximations
------------
+### Approximations
Approximation of Curves and Surfaces groups together a variety of functions used in 2D and 3D geometry for:
* The minimal box which includes a set of points
* The mean plane, line or point of a set of coplanar, collinear or coincident points.
-Conversion to and from BSplines
-----------------------------
+### Conversion to and from BSplines
The Conversion to and from BSplines component has the following two distinct purposes:
* Firstly, it provides a homogenous formulation which can be used to describe any curve or surface.
* an algorithm, which converts a BSpline surface into a series of adjacent Bezier surfaces,
* an algorithm, which converts a grid of adjacent Bezier surfaces into a BSpline surface.
-Points on Curves
---------
+### Points on Curves
The Making Points on Curves component comprises high level functions providing an Application Programming Interface for complex algorithms that compute points on a 2D or 3D curve. The functions use various methods.
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.
+ * 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.
@subsection OCCT_TOVW_SECTION_3_5 Properties of Shapes
-Local Properties of Shapes
-----------------------
+### Local Properties of Shapes
<i>BRepLProp</i> package provides the Local Properties of Shapes component,
which contains algorithms computing various local properties on edges and faces in a BRep model.
which provide shapes with an interface for the description of their geometric support.
The base point for local properties is defined by its u parameter value on a curve, or its (u, v) parameter values on a surface.
-Local Properties of Curves and Surfaces
-------------------------------------
+### Local Properties of Curves and Surfaces
+
The "Local Properties of Curves and Surfaces" component provides algorithms for computing various local
properties on a Geom curve (in 2D or 3D space) or a surface. It is composed of:
* the points corresponding to a minimum or a maximum of curvature;
* the inflection points.
-Global Properties of Shapes
-------------------
+### Global Properties of Shapes
+
The Global Properties of Shapes component provides algorithms for computing the global
properties of a composite geometric system in 3D space, and frameworks to query the computed results.
The global properties of several systems may be brought together to give the global properties of the system composed of the sum of all individual systems.
-The Global Properties of Shapes component is composed of :
-
- * seven functions for computing global properties of a shape: one function for lines, two functions for surfaces and four functions for volumes. The choice of functions depends on input parameters and algorithms used for computation (<i> BRepGProp</i> global functions),
- * a framework for computing global properties for a set of points (<i> GProp_PGProps</i>),
- * and a general framework to :
- * bring together the global properties retained by several more elementary frameworks, and
- * provide a general programming interface to consult computed global properties.
+The Global Properties of Shapes component is composed of:
+* seven functions for computing global properties of a shape: one function for lines, two functions for surfaces and four functions for volumes. The choice of functions depends on input parameters and algorithms used for computation (<i>BRepGProp</i> global functions),
+* a framework for computing global properties for a set of points (<i>GProp_PGProps</i>),
+* and a general framework to bring together the global properties retained by several more elementary frameworks, and provide a general programming interface to consult computed global properties.
@subsection OCCT_TOVW_SECTION_3_6 Examples
-How to compute the curve length
-----------------------
+### How to compute the curve length
To compute curve length, use the method <i>AbscissaPoint::Length</i> from <i> GCPnts</i>.
Standard_Real L = myAlgo.Length( C ) ;
~~~~~~~~
-How to check the surface concavity
---------------------------------
+### How to check the surface concavity
To check the concavity of a surface, proceed as follows:
2. If the value of the curvature changes of sign, the surface is concave or convex depending on the point of view.
3. To compute a Gaussian curvature, use the class <i> SLprops</i> from <i> GeomLProp</i>, which instantiates the generic class <i> SLProps </i>from <i> LProp</i> and use the method <i> GaussianCurvature</i>.
-How to approximate a curve with respect to tangencies
---------------------------------------------
+### How to approximate a curve with respect to tangencies
+
To approximate a curve with respect to tangencies, follow these steps:
2. Create an object of type <i> AppDef_MultiLine </i>from the <i> AppDef_MultiPointConstraint</i>.
3. Use <i> AppDef_BSplineCompute</i>, which instantiates <i>Approx_BSplineComputeLine</i> to perform the approximation.
-How to extract the underlying geometry from shapes
---------------------------------------
+### How to extract the underlying geometry from shapes
+
To extract the underlying geometry from a Shape, use the following methods:
Note: you can use also a topological object directly just as if it
were a geometric one by using the services of <i> BRepAdaptor </i>classes.
-How to get the coordinates of a vertex
------------------------------------
+### How to get the coordinates of a vertex
+
To recover the UV coordinates of vertices,
use <i> BRep_Tool::Parameters const TopoDS_Vertex& V,const TopoDS_Face& F), </i>
which returns the U and V parameters of the vertex V on the face F as a <i> gp_Pnt2d</i>.
-How to explore a Wire
----------------------
+### How to explore a Wire
+
To explore the edges of a wire in a contiguous order, use <i> BrepTools_WireExplorer</i> class.
}
~~~~
-How to merge bspline curves
---------------------------
+### How to merge bspline curves
+
To merge joined bspline curves use the following methods:
* Hidden Line Removal
* Shape Healing
-
+@image html /technical_overview/images/technical_overview_ma.png
+@image latex /technical_overview/images/technical_overview_ma.png
The technical overview provides only a basic description of the libraries.
Please, refer for more details to Modeling Algorithms User's guide
* the projections of a 3D point onto a 3D curve or surface
* the projection of a 3D curve onto a surface.
* the planar curve transposition from the 3D to the 2D parametric space of an underlying plane and v. s.
- * the positioning of a 2D gp object in the 3D geometric space.
+ * the positioning of a 2D gp object in the 3D geometric space.
@subsubsection OCCT_TOVW_SECTION_4_1_3 Lines and Circles from Constraints
construction algorithms for 2D circles or lines described with numeric or
geometric constraints in relation to other curves. These constraints enable the following to be imposed:
- * the radius of a circle,
- * the angle that a straight line makes with another straight line,
- * the tangency of a straight line or circle in relation to a curve,
+ * the radius of a circle,
+ * the angle that a straight line makes with another straight line,
+ * the tangency of a straight line or circle in relation to a curve,
* the passage of a straight line or circle through a point,
- * the centering of a circle on a point or curve.
+ * the circle with center in a point or curve.
For example, these algorithms enable to easily construct a circle of a given radius,
centered on a straight line and tangential to another circle.
case of a circle of a given radius (a small one) which is tangential to two secant
circles C1 and C2:
-
+@image html /technical_overview/images/technical_overview_occ_0005.png "Example of a Tangency Constraint"
+@image latex /technical_overview/images/technical_overview_occ_0005.png "Example of a Tangency Constraint"
This diagram clearly shows that there are 8 possible solutions.
it is tangential, can be used in all algorithms for constructing a circle or a straight
line by geometric constraints. Four qualifiers are used, which specify the following:
- * the solution(s) must enclose the argument, or
- * the solution(s) must be enclosed by the argument, or
- * the solution(s) and the argument must be external to one another, or
- * the relative position is not qualified, i.e. all solutions apply.
+ * the solution(s) must enclose the argument, or
+ * the solution(s) must be enclosed by the argument, or
+ * the solution(s) and the argument must be external to one another, or
+ * the relative position is not qualified, i.e. all solutions apply.
These definitions are very easy to interpret on a circle, where it is easy to identify
the interior and exterior sides. In fact, for any kind of curve the interior is defined
OCCT implements several categories of algorithms:
- * analytic algorithms, where solutions are obtained by the resolution of an equation, such algorithms are used when the geometries which are worked on (tangency arguments, position of the center, etc.) are points, lines or circles;
- * geometric algorithms, where the solution is generally obtained by calculating the intersection of parallel or bisecting curves built from geometric arguments;
- * iterative algorithms, where the solution is obtained by a process of iteration.
+ * analytic algorithms, where solutions are obtained by the resolution of an equation, such algorithms are used when the geometries which are worked on (tangency arguments, position of the center, etc.) are points, lines or circles;
+ * geometric algorithms, where the solution is generally obtained by calculating the intersection of parallel or bisecting curves built from geometric arguments;
+ * iterative algorithms, where the solution is obtained by a process of iteration.
For each kind of geometric construction of a constrained line or circle, OCCT provides
two types of access to the user:
- * algorithms from the package <i> Geom2dGcc </i> automatically select the algorithm best suited to the problem to be treated, both in the general case and in all types of specific cases; the arguments used are Geom2d objects; the solutions computed are <i> gp </i> objects;
- * algorithms from the package <i> GccAna</i> resolve the problem analytically, and can only be used when the geometries to be worked on are lines or circles; the arguments used and solutions computed are <i> gp </i> objects.
+ * algorithms from the package <i> Geom2dGcc </i> automatically select the algorithm best suited to the problem to be treated, both in the general case and in all types of specific cases; the arguments used are Geom2d objects; the solutions computed are <i> gp </i> objects;
+ * algorithms from the package <i> GccAna</i> resolve the problem analytically, and can only be used when the geometries to be worked on are lines or circles; the arguments used and solutions computed are <i> gp </i> objects.
The provided algorithms compute all solutions, which correspond to the stated geometric
problem, unless the solution is found by an iterative algorithm.
Iterative algorithms compute only one solution, closest to an initial
position. They can be used in the following cases:
- * to build a circle, when an argument is more complex than a line or a circle, and where
+ * to build a circle, when an argument is more complex than a line or a circle, and where
the radius is not known or difficult to determine: this is the case for a circle tangential
to three geometric elements, or tangential to two geometric elements and centered on a curve;
- * to build a line, when a tangency argument is more complex than a line or a circle.
+ * to build a line, when a tangency argument is more complex than a line or a circle.
Qualified curves (for tangency arguments) are provided either by:
* the <i> GccEnt</i> package, for direct use by <i> GccAna</i> algorithms, or
- * the <i> Geom2dGcc </i> package, for general use by <i> Geom2dGcc </i> algorithms.
+ * the <i> Geom2dGcc </i> package, for general use by <i> Geom2dGcc </i> algorithms.
The <i> GccEnt</i> and <i> Geom2dGcc</i> packages also provide simple functions for building qualified curves in a very efficient way.
The Curves and Surfaces from Constraints component groups together high level functions
used in 2D and 3D geometry for:
- * creation of faired and minimal variation 2D curves
+ * creation of faired and minimal variation 2D curves
* construction of ruled surfaces
- * construction of pipe surfaces
- * filling of surfaces
+ * construction of pipe surfaces
+ * filling of surfaces
* construction of plate surfaces
- * extension of a 3D curve or surface beyond its original bounds.
+ * extension of a 3D curve or surface beyond its original bounds.
+
+#### 2D Curves from constraints
-2D Curves from constraints
-----------------------
Elastic beam curves have their origin in traditional methods of modeling applied
in boat-building, where a long thin piece of wood, a lathe, was forced to pass
The class <i> MinimalVariation</i> produces curves with minimal variation in curvature.
The exact degree of variation is provided by curvature settings.
-Ruled Surfaces
-----------------
+#### Ruled Surfaces
+
A ruled surface is built by ruling a line along the length of two curves.
-Pipe Surfaces
---------------
+#### Pipe Surfaces
+
A pipe is built by sweeping a curve (the section) along another curve (the path).
* pipes with a section evolving between two given curves.
-Surface filling
---------------
+#### Surface filling
It is often convenient to create a surface from two or more curves which will form
the boundaries that define the new surface.
impossible to sew together all the edges of the resulting surfaces. This leaves a
gap in the overall surface of the object which you are constructing.
-
+@image html /technical_overview/images/technical_overview_occ_0006.png "Intersecting filleted edges with differing radiuses"
+@image latex /technical_overview/images/technical_overview_occ_0006.png "Intersecting filleted edges with differing radiuses"
These algorithms allow you to fill this gap from two, three or four curves. This
can be done with or without constraints, and the resulting surface will be either
This package was designed with a view to handling gaps produced during fillet construction.
Satisfactory results cannot be guaranteed for other uses.
-Plate surfaces
-------------------
+#### Plate surfaces
+
In CAD, it is often necessary to generate a surface which has no exact mathematical
definition, but which is defined by respective constraints. These can be of a mathematical,
to deformation. Then, the algorithm is called to calculate the final surface. It
looks for a solution satisfying constraints and minimizing energy input.
-
+@image html /technical_overview/images/technical_overview_occ_0007.png "Surface generated from four curves and a point"
+@image latex /technical_overview/images/technical_overview_occ_0007.png "Surface generated from four curves and a point"
-
+@image html /technical_overview/images/technical_overview_occ_0008.png "Surface generated from two curves and a point"
+@image latex /technical_overview/images/technical_overview_occ_0008.png "Surface generated from two curves and a point"
-Extension of a 3D curve or surface beyond its original bounds
-----------------------------------------
+#### Extension of a 3D curve or surface beyond its original bounds
The extension is performed according to a geometric requirement and a continuity
constraint. It should be a small extension with respect to the size of the original
curve or surface.
-@sub?ubsection OCCT_TOVW_SECTION_4_1_5 Interpolation
+@subsubsection OCCT_TOVW_SECTION_4_1_5 Interpolation
The Interpolation Laws component provides definitions of functions: <i> y=f(x) </i>.
Such functions can be used to define, for example, the evolution law of a fillet along the edge of a shape.
-Warning
--------
The validity of the function built is never checked: the Law package does not know for what
application or to what end the function will be used. In particular, if the function is used
as the evolution law of a fillet, it is important that the function is always positive. The user must check this.
* Old Boolean Operations (BOA) provided by <i>BRepAlgo</i> package designed and developed in Open CASCADE 6x in 2000; its architecture and content are out of date.
* New Boolean Operations (NBOA) provided by <i>BRepAlgoAPI</i> package designed and developed in 2009 and completely revised in 2013.
-Major benefits of New Boolean Operations
-------------------------------------------
+New Boolean Operations provide the following major benefits:
- * The NBOA has an expandable architecture of inner sub-algorithms, which allows to create specific algorithms for the Customers using existing inner sub-algorithms as root algorithms and to reduce the time for the development.
+ * The NBOA have an expandable architecture of inner sub-algorithms, which allows to create specific algorithms for the Customers using existing inner sub-algorithms as root algorithms and to reduce the time for the development.
* The architecture of inner sub-algorithms of NBOA provides their reusability with maximal independence from the environment of NBOA. The fact allows to create specific algorithms for the Customers using these sub-algorithms as they are or as root classes and thus to reduce the time for the development.
* The architecture of NBOA is history-based. The implementation of NBOA internally sets up a correspondence between any sub-shape of the argument and its image in the result. The history is not imposed and thus it is not error-prone as it was in BOA. The fact allows direct and safely usage of the algorithm in parametric modeling.
- * NBOA is a general algorithm. It correctly processes without using the workarounds even the cases that cannot be properly processed by BOA.
+ * NBOA provide a general algorithm. It correctly processes without using the workarounds even the cases that cannot be properly processed by BOA.
* The implementation of NBOA is based on NCollection classes. The usage of opportunities given by local memory allocators ( <i> NCollection_IncAllocator</i>) allows improving memory management and saving memory resources.
- * NBOA uses modern algorithms of OCC as auxiliary tools. For e.g. the algorithm of unbalanced binary tree of overlapped bounding boxes <i> NCollection_UBTree</i>. The usage of the algorithm allows to improve the performance of NBOA if there is a big number of sub-shapes in the arguments.
-
-The shape type of a Boolean Operation result and types of the arguments
--------------------------------------------------
-
-For arguments having the same shape type (e.g. SOLID / SOLID)
-the type of the resulting shape will be a COMPOUND, containing shapes of this type;
-
-For arguments having different shape types (e.g. SHELL / SOLID)
-the type of the resulting shape will be a COMPOUND,
-containing shapes of the type that is the same as that
-of the low type of the argument. Example: For SHELL/SOLID the result is a COMPOUND of SHELLs.
-
-For arguments with different shape types some of Boolean Operations
-can not be done using the default implementation, because of a non-manifold type
-of the result. Example: the FUSE operation for SHELL and SOLID can not be done,
-but the CUT operation can be done, where SHELL is the object and SOLID is the tool.
+ * NBOA use modern algorithms of OCC as auxiliary tools. For e.g. the algorithm of unbalanced binary tree of overlapped bounding boxes <i> NCollection_UBTree</i>. The usage of the algorithm allows to improve the performance of NBOA if there is a big number of sub-shapes in the arguments.
-It is possible to perform Boolean Operations on arguments of the COMPOUND shape type.
-In this case each compound must not be heterogeneous, i.e.
-it must contain equidimensional shapes (EDGEs or/and WIREs, FACEs or/and SHELLs, SOLIDs).
-SOLIDs inside the COMPOUND must not contact (intersect or touch) each other.
-The same condition should be respected for SHELLs or FACEs, WIREs or EDGEs.
-
-It does not support Boolean Operations for COMPSOLID type of shape.
+Boolean Operations have the following types of the arguments and produce the following results:
+* For arguments having the same shape type (e.g. SOLID / SOLID) the type of the resulting shape will be a COMPOUND, containing shapes of this type;
+* For arguments having different shape types (e.g. SHELL / SOLID) the type of the resulting shape will be a COMPOUND, containing shapes of the type that is the same as that of the low type of the argument. Example: For SHELL/SOLID the result is a COMPOUND of SHELLs.
+* For arguments with different shape types some of Boolean Operations can not be done using the default implementation, because of a non-manifold type of the result. Example: the FUSE operation for SHELL and SOLID can not be done, but the CUT operation can be done, where SHELL is the object and SOLID is the tool.
+* It is possible to perform Boolean Operations on arguments of the COMPOUND shape type. In this case each compound must not be heterogeneous, i.e. it must contain equidimensional shapes (EDGEs or/and WIREs, FACEs or/and SHELLs, SOLIDs). SOLIDs inside the COMPOUND must not contact (intersect or touch) each other. The same condition should be respected for SHELLs or FACEs, WIREs or EDGEs.
+* Boolean Operations for COMPSOLID type of shape are not supported.
@subsection OCCT_TOVW_SECTION_4_5 Features
@subsection OCCT_TOVW_SECTION_4_8 Miscellaneous modelling algorithms.
-Fillets and Chamfers
----------------------
+### Fillets and Chamfers
This library provides algorithms to make fillets and chamfers on shape edges.
The following cases are addressed:
If there is a concavity, both surfaces that need to be extended and those, which do not, are processed.
-Offsets, Drafts, Sewing and Sweeps
-----------------------------------
+### Offsets, Drafts, Sewing and Sweeps
These classes provide the following services:
@subsection OCCT_TOVW_SECTION_4_9 Examples
-How to compute the state of a point on a face:
----------------------------------------------
+### How to compute the state of a point on a face:
+
Use <i> BRepTools::Pnt </i> to get the point from your vertex.
Your shape must be of the <i> TopoDS_Shape </i>type.
~~~~~
-How to compute the state of a point in a solid:
----------------------------------------
+### How to compute the state of a point in a solid:
+
Use <i>BRepTools::Pnt </i> to get the point from your vertex.
Your shape must be of the <i> TopoDS_Solid</i> type.
BRepClass3d_SolidClassifier inherits BRepclass3d_SClassifier
~~~~~
-How to connect a set of contiguous but independent faces
-------------------------------------------
+### How to connect a set of contiguous but independent faces
+
A unique topological object can be obtained in this way using the class
<i> Sewing</i> from the <i> BRepOffsetAPI </i>package which produces a shell as a result.
For more information, refer to the entry for this class in reference documentation.
-How to check the orientation of a solid
---------------------------------------
+### How to check the orientation of a solid
If you want to create a solid from a closed shell, you must first check the orientation to determine if you have to reverse the shell or not (for example after creating a closed shell from a sewing operation). To do this, use the <i> PerformInfinitePoint</i> method from the <i> BrepClass3D_SolidClassifier</i> class.
See also: our web site at E-learning and Training.
-
+@image html /technical_overview/images/technical_overview_viz.png
+@image latex /technical_overview/images/technical_overview_viz.png
@subsection OCCT_TOVW_SECTION_5_1 3D Graphics
-3D Graphics provided by <i> Graphic3d </i> package supports three-dimensional manipulation of 3d graphic objects called structures. Structures, are made up of groups that unite primitives, such as polylines, planar polygons with or without holes, text and markers, and attributes, such as color, transparency, reflection, line type, line width, and text font.
+3D Graphics provided by <i>Graphic3d</i> package supports three-dimensional manipulation of 3d graphic objects called structures. Structures, are made up of groups that unite primitives, such as polylines, planar polygons with or without holes, text and markers, and attributes, such as color, transparency, reflection, line type, line width, and text font.
A group is the smallest editable element of a structure.
A structure can be displayed, erased, highlighted and transformed.
Most types of primitives supported by <i> Graphic3d</i> can be dumped to a vector file format such as PDF and PostScript. Export to vector formats is implemented with help of <i> GL2PS</i> library.
-@subsection OCCT_TOVW_SECTION_5_2 3D Visualization
+@subsection OCCT_TOVW_SECTION_5_2 3D Visualization
This library provides services for:
* A graphic attributes manager
* Selection filters
-Interactive Context
--------------------
+### Interactive Context
Interactive context pilots 3D visualizations and selections.
The interactive context allows you to manage, in a transparent way, graphic and "selectable" behavior of interactive objects which is not yet defined in the predefined types of these objects.
AIS have two operating context types. The default neutral point type allows easily visualizing and selecting entire interactive objects, which have been loaded into the context.
Opening a local context allows preparing and using a temporary selection environment to select a part of an interactive object.
-Interactive Objects
--------------------
+### Interactive Objects
Entities which are visualized and selected in the AIS viewer are objects. They connect the underlying reference geometry of a model to its graphic representation in AIS. You can use predefined OCCT classes of standard interactive objects for which all necessary functions have already been programmed, or, in case you are an advanced user, you can implement your own classes of interactive objects.
-Graphic Attributes Manager
---------------------------
+### Graphic Attributes Manager
Graphic attributes manager, or AIS Drawer, stores graphic attributes for specific interactive objects and for interactive objects controlled by interactive context.
When an interactive object is visualized, the required graphic attributes are first taken from its own drawer if one exists, or from the context drawer if no specific drawer for that type of object exists.
-Selection Filters
------------------
+### Selection Filters
An important aspect in selection is the filtering of entities you to select.
Selection filters allow you to refine the dynamic detection context, which you want to put into effect. Some of these filters can be used at the Neutral Point, others in an open local context only. You can also program your own filters and load them into the context.
@subsection OCCT_TOVW_SECTION_5_4 Presentation
-Presentation Management
-----------------------
-
+### Presentation Management
+
<i> PrsMgr</i> package provides low level services and is only to be used when you do not want to use the services provided by AIS. It manages the display through the following services:
* supplying a graphic structure for the object to be presented
* recalculating presentations when required, e.g. by moving the object or changing its color
- * defining the display mode of the object to be presented; in the case of <i> AIS_Shape</i>, for example, this determines whether the object is to be displayed in:
- wireframe 0
- shading 1.
+ * defining the display mode of the object to be presented; in the case of <i> AIS_Shape</i>, for example, this determines whether the object is to be displayed in wireframe (0) or shading (1) mode.
Note that each new Interactive Object must have all its display modes defined.
-Presentations of Geometry
--------------------------
+### Presentations of Geometry
+
The Presentations of Geometry component provides services for advanced programmers to extend the Application Interactive Services component, AIS.
This would prove necessary in situations where new Interactive Objects were required.
The <i> StdPrs </i>package provides standard display tools for specific geometries and topologies whereas <i> Prs3d</i> provides those for generic objects.
Among these classes are definitions of the display of the specific geometry or topology in various display modes such as wireframe, shading or hidden line removal mode.
-Presentation of Dimensions
---------------------------
+### Presentation of Dimensions
+
<i> DsgPrs </i> package provides tools for display of dimensions, relations and XYZ trihedrons.
@subsection OCCT_TOVW_SECTION_5_5 Selection
Selection of 3D data structures is provided using various algorithms.
-Basic Selection
----------------
+### Basic Selection
+
The <i> SelectBasics </i>package provides the following services:
* the root definition of the sensitive primitive, a selectable entity in a view
* the definition of the owner of a sensitive primitive; this entity relates the primitive to the application entity which is to be selected in the view.
-Standard Selections
--------------------
+### Standard Selections
+
The <i> StdSelect</i> package provides the following services:
* recovery of the bounding boxes in the 2D graphic selection space, if required;
* a 3D-2D projector.
-Selection Management
---------------------
+### Selection Management
+
The <i> SelectMgr</i> package provides low level services and the classes
<i> SelectMgr_SelectionManager</i> and <i> SelectMgr_ViewerSelector </i>
@subsection OCCT_TOVW_SECTION_5_8 Images and Drivers
-Images
---------
+### Images
The <i> Image</i> package provides <i> PseudoColorImage</i>
and <i> ColorImage</i> definitions, and a set of key functions from the image fields.
The <i> AlienImage</i> package allows importing images from other formats into OCCT format.
-Drivers
----------
+### Drivers
+
The <i> Xw </i>package contains the common X graphic interface. It uses <i> XWindow </i> bitmap fonts that cannot be modified.
The <i> WNT</i> package contains the common Windows NT graphic interface.
@subsection OCCT_TOVW_SECTION_5_11 Examples
-How to change graphic attributes of an interactive object
-------------------------------------------------
+### How to change graphic attributes of an interactive object
+
The set of graphic attributes of an interactive object is defined in AIS_Drawer.
Each interactive object can have its own visualization attributes.
To set the <i> AIS_Drawer</i> of an object, call method <i> AIS_InteractiveObject::SetLocalAttributes </i>.
-How to dump a scene from the viewer
-----------------------------
+### How to dump a scene from the viewer
You can dump the contents of a <i> V3D_View</i> in a file with the same scale or
with a different scale according to the required paper size (format)
* The time to generate these files is very short with the XWD format but 2 to 4 times longer for the other formats.
* After getting an image file of your view, you can use any standard application for editing or sending the image file to a printer (i.e.: Microsoft Photo Editor on Windows or Image Viewer on SUN system)
-How to add and remove objects from Selections
----------------------------------------------
+### How to add and remove objects from Selections
+
You can add or remove an object from a selection in one of two ways. You can use:
* <i> AddOrRemoveCurrent </i> method if a local context is opened.
-How to detect overlapped objects
---------------------------------
+### How to detect overlapped objects
+
When objects overlap each other and cause difficulties in selection,
you can use the mechanism provided with the <i> AIS_InteractiveContext</i>
-Get mouse coordinates in 3D view
---------------------------------
+### Get mouse coordinates in 3D view
+
To switch from pixel mouse position on the screen to 3D coordinates
in <i> V3d_View</i>, use <i>V3d_View::Convert</i> method.
Where <i> Xp</i>, <i> Yp</i> are the mouse coordinates in pixels and X,Y,Z the real coordinates in 3D space.
-3D Viewer Objects
------------------
-
+### 3D Viewer Objects
+
The <i> V3d </i> package contains the set of commands and services of the 3D Viewer.
It provides a set of high level commands to control views and viewing modes.
This package is complementary to the <i> Visual3D</i> graphic package.
This matter is addressed by Data Exchange Module, which is organized in a modular way.
-
+@image html /technical_overview/images/technical_overview_de.png
+@image latex /technical_overview/images/technical_overview_de.png
Data Exchange interfaces in OCCT allow software based on OCCT
to exchange data with various CAD software, thus ensuring a good level of interoperability.
Data Exchange interfaces function either in accordance with the standards (IGES, STEP),
which can be used by various software packages for CAD, PDM etc., or as direct connectors to proprietary formats.
-Standardized Data Exchange
---------------------------
+### Standardized Data Exchange
+
* STEP (AP203 : Mechanical Design, this covers General 3D CAD; AP214: Automotive Design)
* IGES (up to 5.3)
Data Exchange interfaces (STEP, IGES) allow to query and examine a file,
results of conversion and its validity. They are designed to support extensions (like new standards) in a common modular architecture.
-Extended data exchange
-----------------------
+### Extended data exchange
+
Extended data exchange (XDE) allows you to extend the scope of exchange by translating
additional data attached to geometric ("BREP") data, thereby improving the interoperability with external software.
(i.e. center of gravity, etc.) are supported. These data are stored together with shapes in an OCAF (XCAF) document.
-Proprietary Data Exchange
-------------------------
+### Proprietary Data Exchange
In addition to standard Data Exchange interfaces, separate components are available
to provide direct mapping and data adaptation (using Shape Healing) with CAD software supporting the following formats:
These components are based on the same architecture as interfaces with STEP and IGES.
-Translating a shape to STL Format
----------------------------------
+### Translating a shape to STL Format
+
OCCT includes a module for translating OCCT shapes to STL (Stereolithography) format.
STL is a format designed for rapid prototyping.
to shapes mean references to OCCT shapes unless otherwise explicitly defined.
In addition, sets of faces or unclosed shells may also be translated but visualization in foreign viewers may be incorrect.
-Translating a shape to VRML Format
-----------------------------------
-
-The Virtual Reality Modeling Language (VRML) is a language
-for describing multi-participant interactive simulations
-* virtual worlds networked via the Internet and hyperlinked
-with the World Wide Web. VRML is a format designed for animated visualization of solids.
+### Translating a shape to VRML Format
+The Virtual Reality Modeling Language (VRML) is a language for describing multi-participant interactive simulations, virtual worlds networked via the Internet and hyperlinked with the World Wide Web. VRML is a format designed for animated visualization of solids.
OCCT includes a module for translating OCCT shapes to VRML (Virtual Reality Modeling Language).
OCCT shapes may be translated in two representations (states): shaded or wireframe.
Since shaded VRML format files include only solids described by their mesh structures, the OCCT shapes intended to be written must be solids, components of solids or closed shells with a correct orientation.
The plugin and the resource files of the application will be located in <i> myDirector</i>.
The name of the plugin file must be <i>Plugin</i>.
-Resource File
---------------
+### Resource File
The resource file describes the documents (type and extension) and
the type of data that the application can manipulate
~~~~
-Plugin File
------------
+### Plugin File
The plugin file describes the list of required plug-ins to run the application and the
libraries in which plug-ins are located.
* Function attributes which regenerate any data affected by modifications made in a
document
-Shape Attributes
-----------------
+### Shape Attributes
A topological attribute can be seen as a hook into the topological structure. To
this hook, data can be attached and references defined.
If a shape is newly created, the old shape for the corresponding named shape is an empty
shape. If a shape is deleted, then the new shape in this named shape is empty.
-
+@image html /technical_overview/images/technical_overview_shapeattrib.png
+@image latex /technical_overview/images/technical_overview_shapeattrib.png
-Shape attributes in data framework.
--------------------------------
+### Shape attributes in data framework.
Algorithms can dispose sub-shapes of the result shape at the individual
label depending on necessity:
F1 to F6 of the box each have a hook. Faces F7 to F10, the lateral faces of the protrusion,
share a single hook, and face F11, the top face, has one hook.
-
+@image html /technical_overview/images/technical_overview_occ_0068.png
+@image latex /technical_overview/images/technical_overview_occ_0068.png
This structure raises two problems:
been a slot) and both new faces would have been attached to the same hook.
-Standard Attributes
--------------------
+### Standard Attributes
+
Standard attributes are already existing ready-to-use attributes, which allow you
to create and modify labels and attributes for many basic data types.
~~~~
-Function Attributes
--------------------
+### Function Attributes
+
A model consists of data and algorithms manipulating with data. OCAF attributes store
data. A Function attribute stores data corresponding to a Function (see the white
paper OCAF Function Mechanism User's Guide). This mechanism manipulates with algorithms
computing the model in the optimal way following the modifications.
-@subsection OCCT_TOVW_SECTION_7_2 Persistent Data Storage
+@subsection OCCT_TOVW_SECTION_7_3 Persistent Data Storage
There are three schemas of persistence, which you can use to store and retrieve OCAF data (documents):
Documents.
-@subsubsection OCCT_TOVW_SECTION_7_2_1 Basic Data Storage
+@subsubsection OCCT_TOVW_SECTION_7_3_1 Basic Data Storage
Normally, all data structures provided by Open CASCADE Technology are run-time structures,
in other words, transient data. As transient data, they exist only while an application
Data storage services also provide libraries of persistent classes and translation
functions needed to translate data from transient to persistent state and vice-versa.
-Libraries of persistent classes
--------------------------------
+#### Libraries of persistent classes
Libraries of persistent classes are extensible libraries of elementary classes you
use to define the database schema of your application. They include:
a unique way of creating and handling persistent objects. You create new persistent
classes by inheriting from this base class.
-Translation Functions
----------------------
+#### Translation Functions
Translation functions allow you to convert persistent objects to transient ones and
vice-versa. These translation functions are used to build Storage and Retrieval drivers
topological data structure library, there are corresponding persistent class libraries,
which allow you to translate your data with ease.
-Creation of Persistent Classes
--------------------------------
+#### Creation of Persistent Classes
If you are using Unix platforms as well as WOK and CDL, you can create your own persistent
classes. In this case, data storage is achieved by implementing Storage and Retrieval
*call the function <i> Write </i> from the schema, setting the driver and the <i> Storage_Data </i> instance as parameters,
*close the driver.
-@subsubsection OCCT_TOVW_SECTION_7_2_2 Persistent Collections
+@subsubsection OCCT_TOVW_SECTION_7_3_2 Persistent Collections
Persistent collections are classes which handle dynamically sized collections of
data that can be stored in the database. These collections provide three categories
In addition, <i> PColStd</i> package provides standard,
and frequently used, instantiations of persistent arrays, for very simple objects.
-@subsubsection OCCT_TOVW_SECTION_7_2_3 Persistent Geometry
+@subsubsection OCCT_TOVW_SECTION_7_3_3 Persistent Geometry
The Persistent Geometry component describes geometric data structures which can be
stored in the database. These packages provide a way to convert data from the transient
~~~~
-@subsubsection OCCT_TOVW_SECTION_7_2_4 Persistent Topology
+@subsubsection OCCT_TOVW_SECTION_7_3_4 Persistent Topology
The Persistent Topology component describes topological data structures which can be stored in the database. These packages provide a way to convert data from the transient "world" to the persistent "world".
aShape.Nullify();
~~~~
-@subsubsection OCCT_TOVW_SECTION_7_2_5 Standard Documents
+@subsubsection OCCT_TOVW_SECTION_7_3_5 Standard Documents
Standard documents offer you a ready-to-use document containing a TDF-based data
structure. The documents themselves are contained in a class inheriting from <i> TDocStd_Application</i>
@section OCCT_TOVW_SECTION_8 FAQ
-Dynamic library loading problem
--------------------------------
-
-Open CASCADE Technology uses a dynamic library loading mode.
-Sometimes, the error message such as the following appears:
-
-~~~~
- "cannot map <i>libname.so</i> .. under any of the filenames .."
-~~~~
-
-When this happens, check your <i> PATH </i>under Windows, <i> LD_LIBRARY_PATH</i> under UNIX ,
-<i> SHLIB_PATH </i> under HP-UX or <i> LIBPATH</i> under IBM AIX .
-It should contain the path where the required dynamic library is located.
-
-Running Draw under Windows
----------------------------
-
-When running <i> DRAWEXE</i> and using axo in the Command window you may see the "Invalid command name "axo" " message :
-
-Make sure that the OCCT directory name does not contain any blank spaces.
-It causes some problems when reading the OCCT description TCL Commands files.
-If you have set <i> DRAWHOME</i> and <i> DRAWDEFAULT</i>, replace \ by / in the variable.
-
-Error on application start on Windows
---------------------------------------
-If Windows shows an error message with the text *Application failed to initialize properly*
-upon launching the application, check access rights for all libraries used in the application, in particular, third-party libraries.
-
-Make sure that you have all rights necessary to access these libraries.
-It is recommended to use option *Inherit access rights from parent*.
-
-Problems with 3D viewer
---------------------
-
-If the 3D viewer fails to display the scene properly, or works very slowly, or exhibits
-another problem, make sure to have the latest version of the graphics card driver
-installed. If this is not possible or does not help, try to decrease
-hardware acceleration level (usually found in Troubleshooting section of the graphics card properties).
-
-Fatal error during graphic initialization
-----------------------------------------
-
-If you get the <b>Fatal error during graphic initialization</b> message when running
-an Open CASCADE Technology based application, or if the application crashes
-without displaying error messages, you must set the environment variable <i> CSF_GRAPHICSHR </i> as follows:
-
- * On Windows, if we suppose that OCCT is installed in <i> D:\OpenCASCADE6.3.0 </i>
-
-~~~~
- Set CSF_GraphicShr= D:\OpenCASCADE6.3.1\ros\win32\bin\TkOpenGl.dll
-~~~~
-
- * On Linux or Unix, if we suppose that OCCT is installed in <i> .../mydisk/ OpenCASCADE6.3.0 </i>
-
-~~~~
- Setenv CSF_GraphicsShr /mydisk/ OpenCASCADE6.3.0ros/lin/lib/libTKOpenGl.so
-~~~~
-
@subsection OCCT_TOVW_SECTION_8_1 Memory Management
In a work-session, geometry modeling applications create and delete a certain number
* small memory arrays are grouped into clusters and then recycled (clusters are never released to the system),
* large arrays are allocated and de-allocated through the standard functions of the system (the arrays are released to system when they are no longer used).
-The Reference Counter
--------------------
+### The Reference Counter
+
To lighten usual programming difficulties linked to the management of object life duration, before deleting an object, the user must ensure the object is no longer referenced and the delete function is secured by a reference counter.
-A smart-pointer
-called a Handle automates reference counter management and automatically deletes
-an object when it is no longer referenced \96 the application never calls the delete
-operator explicitly. To benefit from the memory manager in OCCT, transient classes
-must inherit from <i> TShared</i>. The principle of allocation is as follows:
+A smart-pointer called *Handle* automates reference counter management and automatically deletes an object when it is no longer referenced. The application never calls the delete operator explicitly. To benefit from the memory manager in OCCT, transient classes must inherit from <i>TShared</i>. The principle of allocation is as follows:
~~~~
Handle (TColStd_HSequenceOfInteger) H1 = new TColStd_HSequenceOfInteger;
// memory. In this case, there is no allocation of memory.
~~~~
-Cycles
-------
-As cycles are objects which reference one another, memory management is impossible
-if the data structure contains any cycles, particularly if there are back references.
+### Cycles
+
+As cycles are objects which reference one another, memory management is impossible if the data structure contains any cycles, particularly if there are back references.
+
+For example, objects in a graph include primitives and each one of these primitives has to know the graphic object to which it belongs (i.e. a reference to this graphic object). With normal references, the classical handle is used. With back references, a pointer is used.
-For example, objects in a graph include primitives and each one of these primitives
-has to know the graphic object to which it belongs (i.e. a reference to this graphic
-object). With normal references, the classical handle is used. With back references,
-a pointer is used.
+### Memory Consumption
-Memory Consumption
-------------------
-As a general rule, it is advisable to allocate memory through significant blocks.
-In this way, the user can work with blocks of contiguous data and it facilitates
-memory page manager processing.
+As a general rule, it is advisable to allocate memory through significant blocks.
+In this way, the user can work with blocks of contiguous data and it facilitates memory page manager processing.
@subsection OCCT_TOVW_SECTION_8_2 How to define a handled object without CDL
The filter is used to forbid copying a specified type of attribute.
You can also have a look at <i> TDF_Closure*</i>,
-which can be useful to determine the dependencies of the part you want to cut from the document.
\ No newline at end of file
+which can be useful to determine the dependencies of the part you want to cut from the document.
+
+@subsection OCCT_TOVW_SECTION_8_7 Platform-related problems
+
+### Dynamic library loading
+
+Open CASCADE Technology uses a dynamic library loading mode. Sometimes, the error message such as the following appears:
+
+~~~~
+ "cannot map <i>libname.so</i> .. under any of the filenames .."
+~~~~
+
+When this happens, check your <i> PATH </i>under Windows, <i> LD_LIBRARY_PATH</i> under UNIX ,
+<i> SHLIB_PATH </i> under HP-UX or <i> LIBPATH</i> under IBM AIX .
+It should contain the path where the required dynamic library is located.
+
+### Running Draw under Windows
+
+
+When running <i> DRAWEXE</i> and using axo in the Command window you may see the "Invalid command name "axo" " message :
+
+Make sure that the OCCT directory name does not contain any blank spaces.
+It causes some problems when reading the OCCT description TCL Commands files.
+If you have set <i> DRAWHOME</i> and <i> DRAWDEFAULT</i>, replace \ by / in the variable.
+
+### Error on application start on Windows
+
+If Windows shows an error message with the text *Application failed to initialize properly*
+upon launching the application, check access rights for all libraries used in the application, in particular, third-party libraries.
+
+Make sure that you have all rights necessary to access these libraries.
+It is recommended to use option *Inherit access rights from parent*.
+
+### Problems with 3D viewer
+
+
+If the 3D viewer fails to display the scene properly, or works very slowly, or exhibits
+another problem, make sure to have the latest version of the graphics card driver
+installed. If this is not possible or does not help, try to decrease
+hardware acceleration level (usually found in Troubleshooting section of the graphics card properties).
+
+### Fatal error during graphic initialization
+
+
+If you get the <b>Fatal error during graphic initialization</b> message when running
+an Open CASCADE Technology based application, or if the application crashes
+without displaying error messages, you must set the environment variable <i> CSF_GRAPHICSHR </i> as follows:
+
+ * On Windows, if we suppose that OCCT is installed in <i> D:\OpenCASCADE6.3.0 </i>
+
+~~~~
+ Set CSF_GraphicShr= D:\OpenCASCADE6.3.1\ros\win32\bin\TkOpenGl.dll
+~~~~
+
+ * On Linux or Unix, if we suppose that OCCT is installed in <i> .../mydisk/ OpenCASCADE6.3.0 </i>
+
+~~~~
+ Setenv CSF_GraphicsShr /mydisk/ OpenCASCADE6.3.0ros/lin/lib/libTKOpenGl.so
+~~~~
\ No newline at end of file
Each key defines a sequence of either further (nested) keys or a name of the dynamic library. Keys can be nested down to an arbitrary level. However, cyclic dependencies between the keys are not checked.
**Example** (excerpt from DrawPlugin):
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
-OCAF : VISUALIZATION, OCAFKERNEL
-VISUALIZATION : AISV
-OCAFKERNEL : DCAF
+OCAF : VISUALIZATION, OCAFKERNEL
+VISUALIZATION : AISV
+OCAFKERNEL : DCAF
-DCAF : TKDCAF
-AISV : TKViewerTest
+DCAF : TKDCAF
+AISV : TKViewerTest
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsubsection occt_2142243456_177531676033 Activation of commands implemented in the plug-in
pload [-PluginFileName] [[Key1] [Key2]...], where:
--PluginFileName Defines the name of a plug-in resource file (prefix ;-; is mandatory) described above.
+-PluginFileName 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.
+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 $CASROOT/src/DrawResources directory.
**Examples:**
-Draw[] pload -DrawPlugin OCAF
+Draw[] pload -DrawPlugin OCAF
Will search the resource file DrawPlugin using variable CSF_DrawPluginDefaults (and CSF_DrawPluginUserDefaults) and will start with the OCAF key. Since the DrawPlugin is the file shipped with Open CASCADE Technology it will be found in the $CASROOT/src/DrawResources directory (unless this location is redefined by user's variables). The OCAF key will be recursively extracted into two toolkits/plug-ins: TKDCAF and TKViewerTest (e.g. on Windows they correspond to TKDCAF.dll and TKViewerTest.dll). Thus, commands implemented for Visualization and OCAF will be loaded and activated in Test Harness.
-Draw[] pload (equivalent to pload -DrawPlugin DEFAULT).
+Draw[] pload (equivalent to pload -DrawPlugin DEFAULT).
Will find the default DrawPlugin file and the DEFAULT key. The latter finally maps to the TKTopTest toolkit which implements basic modeling commands.
@subsubsection occt_2142243456_166853072961 set, unset
-Syntax: set varname [value]
+Syntax: set varname [value]
unset varname [varname varname ...]
**set **assigns a string value to a variable. If the variable does not already exist, it is ñreated.
@subsubsection occt_2142243456_166853072962 dset, dval
-Syntax dset var1 value1 vr2 value2 ...
+Syntax dset var1 value1 vr2 value2 ...
dval name
**dset **assigns values to Draw numeric variables. The argument can be any numeric expression including Draw numeric variables. Since all Draw commands expect a numeric expression, there is no need to use $ or **expr**. The **dset **command can assign several variables. If there is an odd number of arguments, the last variable will be assigned a value of 0. If the variable does not exist, it will be created.
@subsubsection occt_2142243456_166853072911 if
-Syntax if condition script [elseif script .... else script]
+Syntax if condition script [elseif script .... else script]
**If **evaluates the condition and the script to see whether the condition is true.
**Example**
@subsubsection occt_2142243456_166853072912 while, for, foreach
-Syntax: while condition script
+Syntax: while condition script
for init condition reinit script
foreach varname list script
@subsubsection occt_2142243456_166853072913 break, continue
-Syntax: break
+Syntax: break
continue
Within loops, the **break **and **continue **commands have the same effect as in C.
@subsubsection occt_2142243456_166853072921 proc
-Syntax: proc argumentlist script
+Syntax: proc argumentlist script
**proc **defines a procedure. An argument may have a default value. It is then a list of the form {argument value}. The script is the body of the procedure.
@subsubsection occt_2142243456_166853072922 global, upvar
-Syntax: global varname [varname ...]
+Syntax: global varname [varname ...]
upvar varname localname [varname localname ...]
**global **accesses high level variables. Unlike C, global variables are not visible in procedures.
@subsubsection occt_2142243456_96704938111 help
-Syntax: help [command [helpstring group]]
+Syntax: help [command [helpstring group]]
Provides help or modifies the help information.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsubsection occt_2142243456_96704938112 source
-Syntax: source filename
+Syntax: source filename
Executes a file.
@subsubsection occt_2142243456_96704938113 spy
-Syntax: spy [filename]
+Syntax: spy [filename]
Saves interactive commands in the file. If spying has already been performed, the current file is closed. **spy **without an argument closes the current file and stops spying. If a file already exists, the file is overwritten. Commands are not appended.
If a command returns an error it is saved with a comment mark.
@subsubsection occt_2142243456_96704938114 cpulimit
-Syntax: cpulimit [nbseconds]
+Syntax: cpulimit [nbseconds]
**cpulimit **limits a process after the number of seconds specified in *nbseconds. *It is used in tests to avoid infinite loops. **cpulimit **without arguments removes all existing limits.
**Example**
@subsubsection occt_2142243456_96704938115 wait
-Syntax: wait [nbseconds]
+Syntax: wait [nbseconds]
Suspends execution for the number of seconds specified in *nbseconds*. The default value is ten (10) seconds. This is a useful command for a slide show.
@subsubsection occt_2142243456_96704938116 chrono
-Syntax: chrono [ name start/stop/reset/show]
+Syntax: chrono [ name start/stop/reset/show]
Without arguments, **chrono **activates Draw chronometers. The elapsed time ,cpu system and cpu user times for each command will be printed.
==CPU system time: 0 seconds
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-@subsection occt_2142243456_9670493812 Variable management commands
+@subsection occt_2142243456_9670493812 Variable management commands
@subsubsection occt_2142243456_96704938121 isdraw, directory
-Syntax: isdraw varname
+Syntax: isdraw varname
directory [pattern]
**isdraw **tests to see if a variable is a Draw variable. **isdraw **will return 1 if there is a Draw value attached to the variable.
@subsubsection occt_2142243456_96704938122 whatis, dump
-Syntax: whatis varname [varname ...]
+Syntax: whatis varname [varname ...]
dump varname [varname ...]
**whatis **returns short information about a Draw variable. This is usually the type name.
@subsubsection occt_2142243456_96704938123 rename, copy
-Syntax: rename varname tovarname [varname tovarname ...]
+Syntax: rename varname tovarname [varname tovarname ...]
copy varname tovarname [varname tovarname ...]
**rename **changes the name of a Draw variable. The original variable will no longer exist. Note that the content is not modified. Only the name is changed.
@subsubsection occt_2142243456_96704938124 datadir, save, restore
-Syntax: datadir [directory]
+Syntax: datadir [directory]
save variable [filename]
restore filename [variablename]
@subsubsection occt_2142243456_44562206611 view, delete
-Syntax: view index type [X Y W H]
+Syntax: view index type [X Y W H]
delete [index]
**view **is the basic view creation command: it creates a new view with the given index. If a view with this index already exits, it is deleted. The view is created with default parameters and X Y W H are the position and dimensions of the window on the screen. Default values are 0, 0, 500, 500.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
See also: **axo, pers, top, bottom, left, right, front, back, mu4, v2d, av2d, smallview**
-@subsubsection occt_2142243456_44562206612 axo, pers, top, ...
+@subsubsection occt_2142243456_44562206612 axo, pers, top, ...
-Syntax: axo
+Syntax: axo
pers
...
smallview type
@subsubsection occt_2142243456_44562206613 mu, md, 2dmu, 2dmd, zoom, 2dzoom
-Syntax: mu [index] value
+Syntax: mu [index] value
2dmu [index] value
zoom [index] value
wzoom
@subsubsection occt_2142243456_44562206614 pu, pd, pl, pr, 2dpu, 2dpd, 2dpl, 2dpr
-Syntax: pu [index]
+Syntax: pu [index]
pd [index]
The **p_ **commands are used to pan. **pu **and **pd **pan up and down respectively;**pl **and **pr **pan left and right respectively. Each time the view is displaced by 40 pixels.When no index is given, all views will pan in the direction specified.
@subsubsection occt_2142243456_44562206615 fit, 2dfit
-Syntax: fit [index]
+Syntax: fit [index]
2dfit [index]
**fit **computes the best zoom and pans on the content of the view. The content of the view will be centered and fit the whole window.
@subsubsection occt_2142243456_44562206616 u, d, l, r
-Syntax: u [index]
+Syntax: u [index]
d [index]
l [index]
r [index]
@subsubsection occt_2142243456_44562206617 focal, fu, fd
-Syntax: focal [f]
+Syntax: focal [f]
fu [index]
fd [index]
**focal **changes the vantage point in perspective views. A low f value increases the perspective effect; a high one give a perspective similar to that of an axonometric view. The default value is 500.
@subsubsection occt_2142243456_44562206619 dtext
-Syntax: dtext [x y [z]] string
+Syntax: dtext [x y [z]] string
**dtext **displays a string in all 3d or 2d views. If no coordinates are given, a graphic selection is required. If two coordinates are given, the text is created in a 2d view at the position specified. With 3 coordinates, the text is created in a 3d view.
@subsubsection occt_2142243456_445622066110 hardcopy, hcolor, xwd
-Syntax: hardcopy [index]
+Syntax: hardcopy [index]
hcolor index width gray
xwd [index] filename
@subsubsection occt_2142243456_445622066111 wclick, pick
-Syntax: wclick
+Syntax: wclick
pick index X Y Z b [nowait]
**wclick **defers an event until the mouse button is clicked. The message ;just click; is displayed.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsubsection occt_2142243456_445622066112 autodisplay
-Syntax: autodisplay [0/1]
+Syntax: autodisplay [0/1]
By default, Draw automatically displays any graphic object as soon as it is created. This behavior known as autodisplay can be removed with the command **autodisplay**. Without arguments, **autodisplay **toggles the autodisplay mode. The command always returns the current mode.
@subsubsection occt_2142243456_445622066113 display, donly
-Syntax: display varname [varname ...]
+Syntax: display varname [varname ...]
donly varname [varname ...]
**display **makes objects visible.
@subsubsection occt_2142243456_445622066114 erase, clear, 2dclear
-Syntax: erase [varname varname ...]
+Syntax: erase [varname varname ...]
clear
2dclear
See also: **display**
@subsubsection occt_2142243456_445622066115 repaint, dflush
-Syntax: repaint
+Syntax: repaint
dflush
**repaint **forces repainting of views.
@subsubsection occt_2142243456_44562206621 vinit
-Syntax: vinit
+Syntax: vinit
Creates the 3D viewer window
@subsubsection occt_2142243456_44562206622 vhelp
-Syntax: vhelp
+Syntax: vhelp
Displays help in the 3D viewer window. The help consists in a list of hotkeys and their functionalities.
@subsubsection occt_2142243456_44562206623 vtop
-Syntax: vtop
+Syntax: vtop
Displays top view in the 3D viewer window.
**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsubsection occt_2142243456_44562206624 vaxo
-Syntax: vaxo
+Syntax: vaxo
Displays axonometric view in the 3D viewer window.
**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsubsection occt_2142243456_44562206625 vsetbg
-Syntax: vsetbg imagefile [filltype]
+Syntax: vsetbg imagefile [filltype]
Loads image file as background. **filltype** must be **NONE, CENTERED, TILED or STRETCH**.
**Example**
@subsubsection occt_2142243456_44562206626 vclear
-Syntax: vclear
+Syntax: vclear
Removes all objects from the viewer.
@subsubsection occt_2142243456_44562206627 vrepaint
-Syntax: vrepaint
+Syntax: vrepaint
Forcedly redisplays the shape in the 3D viewer window.
@subsubsection occt_2142243456_44562206628 vfit
-Syntax: vfit
+Syntax: vfit
Automatic zoom/panning. Objects in the view are visualized to occupy the maximum surface.
@subsubsection occt_2142243456_44562206629 vzfit
-Syntax: vzfit
+Syntax: vzfit
Automatic depth panning. Objects in the view are visualized to occupy the maximum 3d space.
@subsubsection occt_2142243456_44562206631 vdisplay
-Syntax: vdisplay name1 [name2] … [name n]
+Syntax: vdisplay name1 [name2] … [name n]
Displays named objects.
**Example**
@subsubsection occt_2142243456_44562206632 vdonly
-Syntax: vdonly [name1] … [name n]
+Syntax: vdonly [name1] … [name n]
Displays only selected or named objects. If there are no selected or named objects, nothing is done.
**Example**
vfit
@subsubsection occt_2142243456_44562206633 vdisplayall
-Syntax: vdisplayall
+Syntax: vdisplayall
Displays all created objects.
**Example**
vfit
@subsubsection occt_2142243456_44562206634 verase
-Syntax: verase [name1] [name2] … [name n]
+Syntax: verase [name1] [name2] … [name n]
Erases some selected or named objects. If there are no selected or named objects, the whole viewer is erased.
**Example**
verase
@subsubsection occt_2142243456_44562206635 veraseall
-Syntax: veraseall
+Syntax: veraseall
Erases all objects displayed in the viewer.
**Example**
@subsubsection occt_2142243456_44562206636 vsetdispmode
-Syntax: vsetdispmode [name] mode(0,1,2,3)
+Syntax: vsetdispmode [name] mode(0,1,2,3)
Sets display mode for all, selected or named objects.
**mode** is **0** (**WireFrame**), **1** (**Shading**), **2** (**Quick HideLineremoval**), **3** (**Exact HideLineremoval**).
vfit
@subsubsection occt_2142243456_44562206637 vdisplaytype
-Syntax: vdisplaytype type
+Syntax: vdisplaytype type
Displays all objects of a given type.
Possible **type**s are **;Point;, ;Axis;, ;Trihedron;, ;PlaneTrihedron;, ;Line;, ;Circle;, ;Plane;, ;Shape;, ;ConnectedShape;, ;MultiConn.Shape;, ;ConnectedInter.;, ;MultiConn.;, ;Constraint; **and** ;Dimension; **(see **vtypes**).
@subsubsection occt_2142243456_44562206638 verasetype
-Syntax: verasetype type
+Syntax: verasetype type
Erases all objects of a given type.
Possible** type**s are **;Point;, ;Axis;, ;Trihedron;, ;PlaneTrihedron;, ;Line;, ;Circle;, ;Plane;, ;Shape;, ;ConnectedShape;, ;MultiConn.Shape;, ;ConnectedInter.;, ;MultiConn.;, ;Constraint; **and **;Dimension; **(see **vtypes**).
@subsubsection occt_2142243456_44562206639 vtypes
-Syntax: vtypes
+Syntax: vtypes
Makes a list of known types and signatures in AIS.
@subsubsection occt_2142243456_445622066310 vsetcolor
-Syntax: vsetcolor [shapename] colorname
+Syntax: vsetcolor [shapename] colorname
Sets color for all, selected or named shapes.
Possible **colorname**s are **;BLACK;, ;MATRAGRAY;, ;MATRABLUE;, ;ALICEBLUE;, ;ANTIQUEWHITE;, ;ANTIQUEWHITE1;, ;ANTIQUEWHITE2;, ;ANTIQUEWHITE3;, ;ANTIQUEWHITE4;, ;AQUAMARINE1;, ;AQUAMARINE2;, ;AQUAMARINE4;, ;AZURE;, ;AZURE2;, ;AZURE3;, ;AZURE4;, ;BEIGE;, ;BISQUE;, ;BISQUE2;, ;BISQUE3;, ;BISQUE4;, ;BLANCHEDALMOND;, ;BLUE1;, ;BLUE2;, ;BLUE3;, ;BLUE4;, ;BLUEVIOLET;, ;BROWN;, ;BROWN1;, ;BROWN2;, ;BROWN3;, ;BROWN4;, ;BURLYWOOD;, ;BURLYWOOD1;, ;BURLYWOOD2;, ;BURLYWOOD3;, ;BURLYWOOD4;, ;CADETBLUE;, ;CADETBLUE1;, ;CADETBLUE2;, ;CADETBLUE3;, ;CADETBLUE4;, ;CHARTREUSE;, ;CHARTREUSE1;, ;CHARTREUSE2;, ;CHARTREUSE3;, ;CHARTREUSE4;, ;CHOCOLATE;, ;CHOCOLATE1;, ;CHOCOLATE2;, ;CHOCOLATE3;, ;CHOCOLATE4;, ;CORAL;, ;CORAL1;, ;CORAL2;, ;CORAL3;, ;CORAL4;, ;CORNFLOWERBLUE;, ;CORNSILK1;, ;CORNSILK2;, ;CORNSILK3;, ;CORNSILK4;, ;CYAN1;, ;CYAN2;, ;CYAN3;, ;CYAN4;, ;DARKGOLDENROD;, ;DARKGOLDENROD1;, ;DARKGOLDENROD2;, ;DARKGOLDENROD3;, ;DARKGOLDENROD4;, ;DARKGREEN;, ;DARKKHAKI;, ;DARKOLIVEGREEN;, ;DARKOLIVEGREEN1;, ;DARKOLIVEGREEN2;, ;DARKOLIVEGREEN3;, ;DARKOLIVEGREEN4;, ;DARKORANGE;, ;DARKORANGE1;, ;DARKORANGE2;, ;DARKORANGE3;, ;DARKORANGE4;, ;DARKORCHID;, ;DARKORCHID1;, ;DARKORCHID2;, ;DARKORCHID3;, ;DARKORCHID4;, ;DARKSALMON;, ;DARKSEAGREEN;, ;DARKSEAGREEN1;, ;DARKSEAGREEN2;, ;DARKSEAGREEN3;, ;DARKSEAGREEN4;, ;DARKSLATEBLUE;, ;DARKSLATEGRAY1;, ;DARKSLATEGRAY2;, ;DARKSLATEGRAY3;, ;DARKSLATEGRAY4;, ;DARKSLATEGRAY;, ;DARKTURQUOISE;, ;DARKVIOLET;, ;DEEPPINK;, ;DEEPPINK2;, ;DEEPPINK3;, ;DEEPPINK4;, ;DEEPSKYBLUE1;, ;DEEPSKYBLUE2;, ;DEEPSKYBLUE3;, ;DEEPSKYBLUE4;, ;DODGERBLUE1;, ;DODGERBLUE2;, ;DODGERBLUE3;, ;DODGERBLUE4;, ;FIREBRICK;, ;FIREBRICK1;, ;FIREBRICK2;, ;FIREBRICK3;, ;FIREBRICK4;, ;FLORALWHITE;, ;FORESTGREEN;, ;GAINSBORO;, ;GHOSTWHITE;, ;GOLD;, ;GOLD1;, ;GOLD2;, ;GOLD3;, ;GOLD4;, ;GOLDENROD;, ;GOLDENROD1;, ;GOLDENROD2;, ;GOLDENROD3;, ;GOLDENROD4;, ;GRAY;, ;GRAY0;, ;GRAY1;, ;GRAY10;, ;GRAY11;, ;GRAY12;, ;GRAY13;, ;GRAY14;, ;GRAY15;, ;GRAY16;, ;GRAY17;, ;GRAY18;, ;GRAY19;, ;GRAY2;, ;GRAY20;, ;GRAY21;, ;GRAY22;, ;GRAY23;, ;GRAY24;, ;GRAY25;, ;GRAY26;, ;GRAY27;, ;GRAY28;, ;GRAY29;, ;GRAY3;, ;GRAY30;, ;GRAY31;, ;GRAY32;, ;GRAY33;, ;GRAY34;, ;GRAY35;, ;GRAY36;, ;GRAY37;, ;GRAY38;, ;GRAY39;, ;GRAY4;, ;GRAY40;, ;GRAY41;, ;GRAY42;, ;GRAY43;, ;GRAY44;, ;GRAY45;, ;GRAY46;, ;GRAY47;, ;GRAY48;, ;GRAY49;, ;GRAY5;, ;GRAY50;, ;GRAY51;, ;GRAY52;, ;GRAY53;, ;GRAY54;, ;GRAY55;, ;GRAY56;, ;GRAY57;, ;GRAY58;, ;GRAY59;, ;GRAY6;, ;GRAY60;, ;GRAY61;, ;GRAY62;, ;GRAY63;, ;GRAY64;, ;GRAY65;, ;GRAY66;, ;GRAY67;, ;GRAY68;, ;GRAY69;, ;GRAY7;, ;GRAY70;, ;GRAY71;, ;GRAY72;, ;GRAY73;, ;GRAY74;, ;GRAY75;, ;GRAY76;, ;GRAY77;, ;GRAY78;, ;GRAY79;, ;GRAY8;, ;GRAY80;, ;GRAY81;, ;GRAY82;, ;GRAY83;, ;GRAY85;, ;GRAY86;, ;GRAY87;, ;GRAY88;, ;GRAY89;, ;GRAY9;, ;GRAY90;, ;GRAY91;, ;GRAY92;, ;GRAY93;, ;GRAY94;, ;GRAY95;, ;GREEN;, ;GREEN1;, ;GREEN2;, ;GREEN3;, ;GREEN4;, ;GREENYELLOW;, ;GRAY97;, ;GRAY98;, ;GRAY99;, ;HONEYDEW;, ;HONEYDEW2;, ;HONEYDEW3;, ;HONEYDEW4;, ;HOTPINK;, ;HOTPINK1;, ;HOTPINK2;, ;HOTPINK3;, ;HOTPINK4;, ;INDIANRED;, ;INDIANRED1;, ;INDIANRED2;, ;INDIANRED3;, ;INDIANRED4;, ;IVORY;, ;IVORY2;, ;IVORY3;, ;IVORY4;, ;KHAKI;, ;KHAKI1;, ;KHAKI2;, ;KHAKI3;, ;KHAKI4;, ;LAVENDER;, ;LAVENDERBLUSH1;, ;LAVENDERBLUSH2;, ;LAVENDERBLUSH3;, ;LAVENDERBLUSH4;, ;LAWNGREEN;, ;LEMONCHIFFON1;, ;LEMONCHIFFON2;, ;LEMONCHIFFON3;, ;LEMONCHIFFON4;, ;LIGHTBLUE;, ;LIGHTBLUE1;, ;LIGHTBLUE2;, ;LIGHTBLUE3;, ;LIGHTBLUE4;, ;LIGHTCORAL;, ;LIGHTCYAN1;, ;LIGHTCYAN2;, ;LIGHTCYAN3;, ;LIGHTCYAN4;, ;LIGHTGOLDENROD;, ;LIGHTGOLDENROD1;, ;LIGHTGOLDENROD2;, ;LIGHTGOLDENROD3;, ;LIGHTGOLDENROD4;, ;LIGHTGOLDENRODYELLOW;, ;LIGHTGRAY;, ;LIGHTPINK;, ;LIGHTPINK1;, ;LIGHTPINK2;, ;LIGHTPINK3;, ;LIGHTPINK4;, ;LIGHTSALMON1;, ;LIGHTSALMON2;, ;LIGHTSALMON3;, ;LIGHTSALMON4;, ;LIGHTSEAGREEN;, ;LIGHTSKYBLUE;, ;LIGHTSKYBLUE1;, ;LIGHTSKYBLUE2;, ;LIGHTSKYBLUE3;, ;LIGHTSKYBLUE4;, ;LIGHTSLATEBLUE;, ;LIGHTSLATEGRAY;, ;LIGHTSTEELBLUE;, ;LIGHTSTEELBLUE1;, ;LIGHTSTEELBLUE2;, ;LIGHTSTEELBLUE3;, ;LIGHTSTEELBLUE4;, ;LIGHTYELLOW;, ;LIGHTYELLOW2;, ;LIGHTYELLOW3;, ;LIGHTYELLOW4;, ;LIMEGREEN;, ;LINEN;, ;MAGENTA1;, ;MAGENTA2;, ;MAGENTA3;, ;MAGENTA4;, ;MAROON;, ;MAROON1;, ;MAROON2;, ;MAROON3;, ;MAROON4;, ;MEDIUMAQUAMARINE;, ;MEDIUMORCHID;, ;MEDIUMORCHID1;, ;MEDIUMORCHID2;, ;MEDIUMORCHID3;, ;MEDIUMORCHID4;, ;MEDIUMPURPLE;, ;MEDIUMPURPLE1;, ;MEDIUMPURPLE2;, ;MEDIUMPURPLE3;, ;MEDIUMPURPLE4;, ;MEDIUMSEAGREEN;, ;MEDIUMSLATEBLUE;, ;MEDIUMSPRINGGREEN;, ;MEDIUMTURQUOISE;, ;MEDIUMVIOLETRED;, ;MIDNIGHTBLUE;, ;MINTCREAM;, ;MISTYROSE;, ;MISTYROSE2;, ;MISTYROSE3;, ;MISTYROSE4;, ;MOCCASIN;, ;NAVAJOWHITE1;, ;NAVAJOWHITE2;, ;NAVAJOWHITE3;, ;NAVAJOWHITE4;, ;NAVYBLUE;, ;OLDLACE;, ;OLIVEDRAB;, ;OLIVEDRAB1;, ;OLIVEDRAB2;, ;OLIVEDRAB3;, ;OLIVEDRAB4;, ;ORANGE;, ;ORANGE1;, ;ORANGE2;, ;ORANGE3;, ;ORANGE4;, ;ORANGERED;, ;ORANGERED1;, ;ORANGERED2;, ;ORANGERED3;, ;ORANGERED4;, ;ORCHID;, ;ORCHID1;, ;ORCHID2;, ;ORCHID3;, ;ORCHID4;, ;PALEGOLDENROD;, ;PALEGREEN;, ;PALEGREEN1;, ;PALEGREEN2;, ;PALEGREEN3;, ;PALEGREEN4;, ;PALETURQUOISE;, ;PALETURQUOISE1;, ;PALETURQUOISE2;, ;PALETURQUOISE3;, ;PALETURQUOISE4;, ;PALEVIOLETRED;, ;PALEVIOLETRED1;, ;PALEVIOLETRED2;, ;PALEVIOLETRED3;, ;PALEVIOLETRED4;, ;PAPAYAWHIP;, ;PEACHPUFF;, ;PEACHPUFF2;, ;PEACHPUFF3;, ;PEACHPUFF4;, ;PERU;, ;PINK;, ;PINK1;, ;PINK2;, ;PINK3;, ;PINK4;, ;PLUM;, ;PLUM1;, ;PLUM2;, ;PLUM3;, ;PLUM4;, ;POWDERBLUE;, ;PURPLE;, ;PURPLE1;, ;PURPLE2;, ;PURPLE3;, ;PURPLE4;, ;RED;, ;RED1;, ;RED2;, ;RED3;, ;RED4;, ;ROSYBROWN;, ;ROSYBROWN1;, ;ROSYBROWN2;, ;ROSYBROWN3;, ;ROSYBROWN4;, ;ROYALBLUE;, ;ROYALBLUE1;, ;ROYALBLUE2;, ;ROYALBLUE3;, ;ROYALBLUE4;, ;SADDLEBROWN;, ;SALMON;, ;SALMON1;, ;SALMON2;, ;SALMON3;, ;SALMON4;, ;SANDYBROWN;, ;SEAGREEN;, ;SEAGREEN1;, ;SEAGREEN2;, ;SEAGREEN3;, ;SEAGREEN4;, ;SEASHELL;, ;SEASHELL2;, ;SEASHELL3;, ;SEASHELL4;, ;BEET;, ;TEAL;, ;SIENNA;, ;SIENNA1;, ;SIENNA2;, ;SIENNA3;, ;SIENNA4;, ;SKYBLUE;, ;SKYBLUE1;, ;SKYBLUE2;, ;SKYBLUE3;, ;SKYBLUE4;, ;SLATEBLUE;, ;SLATEBLUE1;, ;SLATEBLUE2;, ;SLATEBLUE3;, ;SLATEBLUE4;, ;SLATEGRAY1;, ;SLATEGRAY2;, ;SLATEGRAY3;, ;SLATEGRAY4;, ;SLATEGRAY;, ;SNOW;, ;SNOW2;, ;SNOW3;, ;SNOW4;, ;SPRINGGREEN;, ;SPRINGGREEN2;, ;SPRINGGREEN3;, ;SPRINGGREEN4;, ;STEELBLUE;, ;STEELBLUE1;, ;STEELBLUE2;, ;STEELBLUE3;, ;STEELBLUE4;, ;TAN;, ;TAN1;, ;TAN2;, ;TAN3;, ;TAN4;, ;THISTLE;, ;THISTLE1;, ;THISTLE2;, ;THISTLE3;, ;THISTLE4;, ;TOMATO;, ;TOMATO1;, ;TOMATO2;, ;TOMATO3;, ;TOMATO4;, ;TURQUOISE;, ;TURQUOISE1;, ;TURQUOISE2;, ;TURQUOISE3;, ;TURQUOISE4;, ;VIOLET;, ;VIOLETRED;, ;VIOLETRED1;, ;VIOLETRED2;, ;VIOLETRED3;, ;VIOLETRED4;, ;WHEAT;, ;WHEAT1;, ;WHEAT2;, ;WHEAT3;, ;WHEAT4;, ;WHITE;, ;WHITESMOKE;, ;YELLOW;, ;YELLOW1;, ;YELLOW2;, ;YELLOW3;, ;YELLOW4; and ;YELLOWGREEN;**.
@subsubsection occt_2142243456_445622066311 vunsetcolor
-Syntax: vunsetcolor [shapename]
+Syntax: vunsetcolor [shapename]
Sets default color for all, selected or named shapes.
@subsubsection occt_2142243456_445622066312 vsettransparency
-Syntax: vsettransparency [shapename] coeficient
+Syntax: vsettransparency [shapename] coeficient
Sets transparency for all selected or named shapes. The **Coefficient** may be between 0.0 (opaque) and 1.0 (fully transparent). Warning: at 1.0 the shape becomes invisible.
**Example**
@subsubsection occt_2142243456_445622066313 vunsettransparency
-Syntax: vunsettransparency [shapename]
+Syntax: vunsettransparency [shapename]
Sets default transparency (0.0) for all selected or named shapes.
@subsubsection occt_2142243456_445622066314 vsetmaterial
-Syntax: vsetmaterial [shapename] materialname
+Syntax: vsetmaterial [shapename] materialname
Sets material for all selected or named shapes.
**materialname** is ***BRASS*, *BRONZE*, *COPPER*, *GOLD*, *PEWTER*, *PLASTER*, *PLASTIC*, *SILVER*, *STEEL*, *STONE*, *SHINY_PLASTIC*, *SATIN*, *METALIZED*, *NEON_GNC*, *CHROME*, *ALUMINIUM*, *OBSIDIAN*, *NEON_PHC*, *JADE*.**
@subsubsection occt_2142243456_445622066315 vunsetmaterial
-Syntax: vunsetmaterial [shapename]
+Syntax: vunsetmaterial [shapename]
Sets default material for all selected or named shapes.
@subsubsection occt_2142243456_445622066316 vsetwidth
-Syntax: vsetwidth [shapename] coeficient
+Syntax: vsetwidth [shapename] coeficient
Sets width of the edges for all selected or named shapes.
The **Coefficient** may be between 0.0 and 10.0.
@subsubsection occt_2142243456_445622066317 vunsetwidth
-Syntax: vunsetwidth [shapename]
+Syntax: vunsetwidth [shapename]
Sets default width of edges (0.0) for all selected or named shapes.
@subsubsection occt_2142243456_445622066318 vsetshading
-Syntax: vsetshading shapename [coefficient]
+Syntax: vsetshading shapename [coefficient]
Sets deflection coefficient that defines the quality of the shape’s representation in the shading mode. Default coefficient is 0.0008.
**Example**
vsetshading s 0.005
@subsubsection occt_2142243456_445622066319 vunsetshading
-Syntax: vunsetshading [shapename]
+Syntax: vunsetshading [shapename]
Sets default deflection coefficient (0.0008) that defines the quality of the shape’s representation in the shading mode. Default coefficient is 0.0008.
@subsubsection occt_2142243456_445622066320 vsetam
-Syntax: vsetam [shapename] mode
+Syntax: vsetam [shapename] mode
Activates selection mode for all selected or named shapes.
**mode** is **0** for **shape** itself, **1** for **vertices**, **2** for **edges**, **3** for **wires**, **4** for **faces**, **5** for **shells**, **6** for **solids**, **7** for **compounds**.
vsetam b 2
@subsubsection occt_2142243456_445622066321 vunsetam
-Syntax: vunsetam
+Syntax: vunsetam
Deactivates all selection modes for all shapes.
@subsubsection occt_2142243456_445622066322 vdump
-Syntax: vdump filename.{png|xwd|bmp}
+Syntax: vdump filename.{png|xwd|bmp}
Extracts the contents of the viewer window to a png, XWD or BMP file.
@subsubsection occt_2142243456_445622066323 vdir
-Syntax: vdir
+Syntax: vdir
Displays the list of displayed objects.
@subsubsection occt_2142243456_445622066324 vsub
-Syntax: vsub 0/1(on/off)[shapename]
+Syntax: vsub 0/1(on/off)[shapename]
Hilights/unhilights named or selected objects which are displayed at neutral state with subintensity color.
**Example**
@subsubsection occt_2142243456_445622066325 vardis
-Syntax: vardis
+Syntax: vardis
Displays active areas (for each activated sensitive entity, one or several 2D bounding boxes are displayed, depending on the implementation of a particular entity).
@subsubsection occt_2142243456_445622066326 varera
-Syntax: varera
+Syntax: varera
Erases active areas.
@subsubsection occt_2142243456_445622066327 vsensdis
-Syntax: vsensdis
+Syntax: vsensdis
Displays active entities (sensitive entities of one of the standard types corresponding to active selection modes).
@subsubsection occt_2142243456_445622066328 vsensera
-Syntax: vsensera
+Syntax: vsensera
Erases active entities.
@subsubsection occt_2142243456_445622066329 vperf
-Syntax: vperf shapename 1/0 (Transformation/Loacation) 1/0 (Primitives sensibles ON/OFF)
+Syntax: vperf shapename 1/0 (Transformation/Loacation) 1/0 (Primitives sensibles ON/OFF)
Tests the animation of an object along a predefined trajectory.
**Example**
vperf b 1 1
@subsubsection occt_2142243456_445622066330 vr
-Syntax: vr filename
+Syntax: vr filename
Reads shape from BREP-format file and displays it in the viewer.
**Example**
vr myshape.brep
@subsubsection occt_2142243456_445622066330331 vstate
-Syntax: vstate [name1] … [name n]
+Syntax: vstate [name1] … [name n]
Makes a list of the status (**Displayed** or **Not Displayed**) of some selected or named objects.
@subsubsection occt_2142243456_44562206633041 vtrihedron
-Syntax: vtrihedron name [X0] [Y0] [Z0] [Zu] [Zv] [Zw] [Xu] [Xv] [Xw]
+Syntax: vtrihedron name [X0] [Y0] [Z0] [Zu] [Zv] [Zw] [Xu] [Xv] [Xw]
Creates a new AIS_Trihedron object. If no argument is set, the default trihedron (0XYZ) is created.
**Example**
@subsubsection occt_2142243456_44562206633042 vplanetri
-Syntax: vplanetri name
+Syntax: vplanetri name
Creates a plane from a trihedron selection.
@subsubsection occt_2142243456_44562206633043 vsize
-Syntax: vsize [name] [size]
+Syntax: vsize [name] [size]
Changes the size of a named or selected trihedron. If the name is not defined: it affects the selected trihedrons otherwise nothing is done. If the value is not defined, it is set to 100 by default.
**Example**
@subsubsection occt_2142243456_44562206633044 vaxis
-Syntax: vaxis name [Xa Ya Za Xb Yb Zb]
+Syntax: vaxis name [Xa Ya Za Xb Yb Zb]
-Creates an axis. If the values are not defined, an axis is created by interactive selection of two vertices or one edge
+Creates an axis. If the values are not defined, an axis is created by interactive selection of two vertices or one edge
**Example**
vinit
@subsubsection occt_2142243456_44562206633045 vaxispara
-Syntax: vaxispara nom
+Syntax: vaxispara nom
Creates an axis by interactive selection of an edge and a vertex.
@subsubsection occt_2142243456_44562206633046 vaxisortho
-Syntax: vaxisotrho name
+Syntax: vaxisotrho name
Creates an axis by interactive selection of an edge and a vertex. The axis will be orthogonal to the selected edge.
@subsubsection occt_2142243456_44562206633047 vpoint
-Syntax: vpoint name [Xa Ya Za]
+Syntax: vpoint name [Xa Ya Za]
Creates a point from coordinates. If the values are not defined, a point is created by interactive selection of a vertice or an edge (in the center of the edge).
**Example**
@subsubsection occt_2142243456_44562206633048 vplane
-Syntax: vplane name [AxisName] [PointName]
- vplane name [PointName] [PointName] [PointName]
- vplane name [PlaneName] [PointName]
+Syntax: vplane name [AxisName] [PointName]
+ vplane name [PointName] [PointName] [PointName]
+ vplane name [PlaneName] [PointName]
Creates a plane from named or interactively selected entities.
**Example**
@subsubsection occt_2142243456_44562206633049 vplanepara
-Syntax: vplanepara name
+Syntax: vplanepara name
Creates a plane from interactively selected vertex and face.
@subsubsection occt_2142243456_445622066330410 vplaneortho
-Syntax: vplaneortho name
+Syntax: vplaneortho name
Creates a plane from interactive selected face and coplanar edge.
@subsubsection occt_2142243456_445622066330411 vline
-Syntax: vline name [PointName] [PointName]
- vline name [Xa Ya Za Xb Yb Zb]
+Syntax: vline name [PointName] [PointName]
+ vline name [Xa Ya Za Xb Yb Zb]
Creates a line from coordinates, named or interactively selected vertices.
**Example**
@subsubsection occt_2142243456_445622066330412 vcircle
-Syntax: vcircle name [PointName PointName PointName IsFilled]
+Syntax: vcircle name [PointName PointName PointName IsFilled]
vcircle name [PlaneName PointName Radius IsFilled]
Creates a circle from named or interactively selected entities. Parameter IsFilled is defined as 0 or 1.
@subsubsection occt_2142243456_445622066330413 vtri2d
-Syntax: vtri2d name
+Syntax: vtri2d name
Creates a plane with a 2D trihedron from an interactively selected face.
@subsubsection occt_2142243456_445622066330414 vselmode
-Syntax: vselmode [object] mode On/Off
+Syntax: vselmode [object] mode On/Off
Sets the selection mode for an object. If the object value is not defined, the selection mode is set for all displayed objects.
Value On is defined as 1 and Off – as 0.
vtriangle triangle1 p1 p2 p3
@subsubsection occt_2142243456_445622066330415 vconnect, vconnectsh
-Syntax: vconnect name object Xo Yo Zo Xu Xv Xw Zu Zv Zw
- vconnectsh name shape Xo Yo Zo Xu Xv Xw Zu Zv Zw
+Syntax: vconnect name object Xo Yo Zo Xu Xv Xw Zu Zv Zw
+ vconnectsh name shape Xo Yo Zo Xu Xv Xw Zu Zv Zw
Creates and displays an object with input location connected to a named entity.
The difference between these two commands is that the object created by vconnect does not support the selection modes differrent from 0.
@subsubsection occt_2142243456_445622066330416 vtriangle
-Syntax: vtriangle name PointName PointName PointName
+Syntax: vtriangle name PointName PointName PointName
Creates and displays a filled triangle from named points.
**Example**
@subsubsection occt_2142243456_445622066330417 vsegment
-Syntax: vsegment name PointName PointName
+Syntax: vsegment name PointName PointName
Creates and displays a segment from named points.
**Example**
@subsubsection occt_2142243456_44562206633051 meshfromstl
-Syntax: meshfromstl meshname file
+Syntax: meshfromstl meshname file
Creates a MeshVS_Mesh object based on STL file data. The object will be displayed immediately.
**Example**
@subsubsection occt_2142243456_44562206633052 meshdispmode
-Syntax: meshdispmode meshname displaymode
+Syntax: meshdispmode meshname displaymode
Changes the display mode of object **meshname**. The **displaymode** is integer, which can be **1** (for wireframe), **2** (for shading mode) or **3** (for shrink mode).
**Example**
@subsubsection occt_2142243456_44562206633053 meshselmode
-Syntax: meshselmode meshname selectionmode
+Syntax: 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,
@subsubsection occt_2142243456_44562206633054 meshshadcolor
-Syntax: meshshadcolor meshname red green blue
+Syntax: meshshadcolor meshname red green blue
Changes the face interior color of object **meshname**. The **red**, **green** and **blue** are real values between **0** and **1**.
**Example**
@subsubsection occt_2142243456_44562206633055 meshlinkcolor
-Syntax: meshlinkcolor meshname red green blue
+Syntax: meshlinkcolor meshname red green blue
Changes the color of face borders for object **meshname**. The **red**, **green** and **blue** are real values between **0** and **1**.
**Example**
@subsubsection occt_2142243456_44562206633056 meshmat
-Syntax: meshmat meshname material
+Syntax: 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,**
@subsubsection occt_2142243456_44562206633057 meshshrcoef
-Syntax: meshshrcoef meshname shrinkcoefficient
+Syntax: meshshrcoef meshname shrinkcoefficient
Changes the value of shrink coefficient used in the shrink mode. In the shrink mode the face is shown as a congruent part of a usual face, so that **shrinkcoefficient** controls the value of this part. The **shrinkcoefficient** is a positive real number.
**Example**
@subsubsection occt_2142243456_44562206633058 meshshow
-Syntax: meshshow meshname
+Syntax: meshshow meshname
Displays **meshname** in the viewer (if it is erased).
**Example**
@subsubsection occt_2142243456_44562206633059 meshhide
-Syntax: meshhide meshname
+Syntax: meshhide meshname
Hides **meshname** in the viewer.
**Example**
@subsubsection occt_2142243456_445622066330510 meshhidesel
-Syntax: meshhidesel meshname
+Syntax: meshhidesel meshname
Hides only selected entities. The other part of **meshname** remains visible.
@subsubsection occt_2142243456_445622066330511 meshshowsel
-Syntax: meshshowsel meshname
+Syntax: meshshowsel meshname
Shows only selected entities. The other part of **meshname** becomes invisible.
@subsubsection occt_2142243456_445622066330512 meshshowall
-Syntax: meshshowall meshname
+Syntax: meshshowall meshname
Changes the state of all entities to visible for **meshname**.
@subsubsection occt_2142243456_445622066330513 meshdelete
-Syntax: meshdelete meshname
+Syntax: meshdelete meshname
Deletes MeshVS_Mesh object **meshname**.
**Example**
@subsubsection occt_2142243456_44562206633061 v2dinit
-Syntax: v2dinit
+Syntax: v2dinit
**v2dinit **creates the 2D viewer window.
@subsubsection occt_2142243456_44562206633062 v2dsetbg
-Syntax: v2dsetbg imagefile [filletype]
+Syntax: v2dsetbg imagefile [filletype]
**v2dsetbg** loads **imagefile** as background. **filletype** is **NONE**, **CENTERED**, **TILED**, **STRETCH**.
**Example**
@subsubsection occt_2142243456_44562206633063 v2dfit
-Syntax: v2dfit
+Syntax: v2dfit
Fits all shapes to the size of the window.
@subsubsection occt_2142243456_44562206633064 v2drepaint
-Syntax: v2drepaint
+Syntax: v2drepaint
Forcedly repaints all shapes.
@subsubsection occt_2142243456_44562206633065 v2dclear
-Syntax: v2dclear
+Syntax: v2dclear
Clears the 2D viewer window
@subsubsection occt_2142243456_44562206633066 v2dtext
-Syntax: v2dtext text x y [angle scale fontindex]
+Syntax: v2dtext text x y [angle scale fontindex]
Creates a new object with the name **text_i** (i – integer value) and displays **text** at the position** x**, **y.** The text can be displayed at a certain **angle**, on a certain **scale** and with a certain **fontindex**.
Default values are: **angle=0.0, scale=1.0, fontindex=0**.
v2dtext *My text* 10 10
@subsubsection occt_2142243456_44562206633067 v2dsettextcolor
-Syntax: v2dsettextcolor text_name colorindex
+Syntax: v2dsettextcolor text_name colorindex
Changes the color of **text_name** object (**name** must be an integer value).
**Example**
v2dsettextcolor text_0 3
@subsubsection occt_2142243456_44562206633068 v2dpick
-Syntax: v2dpick
+Syntax: v2dpick
Displays mouse coordinates and color after clicking the mouse button in the 2D viewer window.
@subsubsection occt_2142243456_44562206633069 v2dgrid
-Syntax: v2dgrid [type x y xstep ystep angle [drawmode]]
- v2dgrid [type x y radiusstep division angle [drawmode]]
+Syntax: v2dgrid [type x y xstep ystep angle [drawmode]]
+ v2dgrid [type x y radiusstep division angle [drawmode]]
Loads a grid in the 2D viewer window.
**type** is **Rect** or **Circ**.
v2dgrid Rect 0 0 200 200 0 Lines
@subsubsection occt_2142243456_445622066330610 v2rmgrid
-Syntax: v2rmgrid
+Syntax: v2rmgrid
Unloads a grid from the window.
@subsubsection occt_2142243456_445622066330611 v2dpickgrid
-Syntax: v2dpickgrid [mouse_x mouse_y [grid_x grid_y]]
+Syntax: v2dpickgrid [mouse_x mouse_y [grid_x grid_y]]
Gets coordinates of a grid point near the mouse button click in the 2D viewer window and sets it to **grid_x**, **grid_y** variables.
@subsubsection occt_2142243456_445622066330612 v2dpsout
-Syntax: v2dpsout imagefile [scale colorspace]
- [width height [xcenter ycenter]]
+Syntax: v2dpsout imagefile [scale colorspace]
+ [width height [xcenter ycenter]]
Exports **imagefile**. You can set its the scale, width, height and colorspace.
**colorspace** can be **RGB, BlackAndWhite, GreyScale**.
@subsubsection occt_2142243456_445622066330612613 v2ddir
-Syntax: v2ddir
+Syntax: v2ddir
Makes aLlist of the displayed objects.
@subsubsection occt_2142243456_44562206633061271 v2ddisplay
-Syntax: v2ddisplay name [projection]
+Syntax: v2ddisplay name [projection]
Projection: origin_x origin_y origin_z normal_x normal_y normal_z dx_x dx_y dx_z.
v2dfit
@subsubsection occt_2142243456_44562206633061272 v2ddonly
-Syntax: v2ddonly [name1] … [name n]
+Syntax: v2ddonly [name1] … [name n]
Displays only selected or named objects. If there are no selected or named objects, nothing is done.
**Example**
v2dfit
@subsubsection occt_2142243456_44562206633061273 v2ddisplayall
-Syntax: v2ddisplayall
+Syntax: v2ddisplayall
Displays all created objects.
**Example**
v2dfit
@subsubsection occt_2142243456_44562206633061274 v2derase
-Syntax: v2derase name1 [name2] … [name n]
+Syntax: v2derase name1 [name2] … [name n]
Erases some selected or named objects. If there are no selected or named objects, the whole viewer is erased.
**Example**
v2dfit
@subsubsection occt_2142243456_44562206633061275 v2deraseall
-Syntax: v2deraseall
+Syntax: v2deraseall
Erases all objects displayed in the viewer.
**Example**
v2dfit
@subsubsection occt_2142243456_44562206633061276 v2dsetcolor
-Syntax: v2dsetcolor [shapename] colorname
+Syntax: v2dsetcolor [shapename] colorname
Sets color for all, selected or named shapes.
Values of **colorname** see **vsetcolor**.
v2dfit
@subsubsection occt_2142243456_44562206633061277 v2dunsetcolor
-Syntax: v2dunsetcolor [shapename]
+Syntax: v2dunsetcolor [shapename]
Sets default color for all, selected or named shapes.
**Example**
v2dfit
@subsubsection occt_2142243456_44562206633061278 v2dsetbgcolor
-Syntax: v2dsetbgcolor colorname
+Syntax: v2dsetbgcolor colorname
Sets background color.
See **vsetcolor** for the values of **colorname.**.
v2dfit
@subsubsection occt_2142243456_44562206633061279 v2dsetwidth
-Syntax: v2dsetwidth [shapename] widthenum
+Syntax: v2dsetwidth [shapename] widthenum
Set width of the edges for all, selected or named shapes.
**widthenum** may be one of: **THIN, MEDIUM, THICK, VERYTHICK**.
v2dfit
@subsubsection occt_2142243456_445622066330612710 v2dunsetwidth
-Syntax: vunsetwidth [shapename]
+Syntax: vunsetwidth [shapename]
Sets default width of the edges for all, selected or named shapes.
**Example**
@subsubsection occt_2142243456_93038482611 NewDocument
-Syntax: NewDocument docname [format]
+Syntax: NewDocument docname [format]
Creates a new **docname** document with MDTV-Standard or described format.
**Example**
@subsubsection occt_2142243456_93038482612 IsInSession
-Syntax: IsInSession path
+Syntax: IsInSession path
**I**Returns **0**, if **path** document is managed by the application session, **1** – otherwise.
**Example**
@subsubsection occt_2142243456_93038482613 ListDocuments
-Syntax: ListDocuments
+Syntax: ListDocuments
Makes a list of documents handled during the session of the application.
@subsubsection occt_2142243456_93038482614 Open
-Syntax: Open path docname
+Syntax: Open path docname
Retrieves the document of file **docname** in the path **path**. Overwrites the document, if it is already in session.
**Example**
@subsubsection occt_2142243456_93038482615 Close
-Syntax: Close docname
+Syntax: Close docname
Closes **docname** document. The document is no longer handled by the applicative session.
**Example**
@subsubsection occt_2142243456_93038482616 Save
-Syntax: Save docname
+Syntax: Save docname
Saves **docname** active document.
**Example**
@subsubsection occt_2142243456_93038482617 SaveAs
-Syntax: SaveAs docname path
+Syntax: SaveAs docname path
Saves the active document in the file **docname** in the path **path**. Overwrites the file if it already exists.
**Example**
@subsubsection occt_2142243456_930384826521 Label
-Syntax: Label docname entry
+Syntax: Label docname entry
Creates the label expressed by **entry** if it does not exist.
**Example**
@subsubsection occt_2142243456_930384826522 NewChild
-Syntax: NewChild docname [taggerlabel = Root label]
+Syntax: NewChild docname [taggerlabel = Root label]
Finds (or creates) a TagSource attribute located at father label of **taggerlabel** and makes a new child label.
**Example**
@subsubsection occt_2142243456_930384826523 Children
-Syntax: Children docname label
+Syntax: Children docname label
Returns the list of attributes of **label**.
**Example**
@subsubsection occt_2142243456_930384826524 ForgetAll
-Syntax: ForgetAll docname label
+Syntax: ForgetAll docname label
Forgets all attributes of the label.
**Example**
@subsubsection occt_2142243456_930384826531 Main
-Syntax: Main docname
+Syntax: Main docname
Returns the main label of the framework.
**Example**
@subsubsection occt_2142243456_930384826532 UndoLimit
-Syntax: UndoLimit docname [value=0]
+Syntax: UndoLimit docname [value=0]
Sets the limit on the number of Undo Delta stored. 0 will disable Undo on the document. A negative **value** means that there is no limit. Note that by default Undo is disabled. Enabling it will take effect with the next call to NewCommand. Of course, this limit is the same for Redo
@subsubsection occt_2142243456_930384826533 Undo
-Syntax: Undo docname [value=1]
+Syntax: Undo docname [value=1]
Undoes **value** steps.
**Example**
@subsubsection occt_2142243456_930384826534 Redo
-Syntax: Redo docname [value=1]
+Syntax: Redo docname [value=1]
Redoes **value** steps.
**Example**
@subsubsection occt_2142243456_930384826535 OpenCommand
-Syntax: OpenCommand docname
+Syntax: OpenCommand docname
Opens a new command transaction.
**Example**
@subsubsection occt_2142243456_930384826536 CommitCommand
-Syntax: CommitCommand docname
+Syntax: CommitCommand docname
Commits the Command transaction.
**Example**
@subsubsection occt_2142243456_930384826537 NewCommand
-Syntax: NewCommand docname
+Syntax: NewCommand docname
This is a short-cut for Commit and Open transaction.
**Example**
@subsubsection occt_2142243456_930384826538 AbortCommand
-Syntax: AbortCommand docname
+Syntax: AbortCommand docname
Aborts the Command transaction.
**Example**
@subsubsection occt_2142243456_930384826539 Copy
-Syntax: Copy docname entry Xdocname Xentry
+Syntax: Copy docname entry Xdocname Xentry
Copies the contents of **entry** to **Xentry**. No links are registred.
**Example**
@subsubsection occt_2142243456_9303848265310 UpdateLink
-Syntax: UpdateLink docname [entry]
+Syntax: UpdateLink docname [entry]
Updates external reference set at **entry**.
**Example**
@subsubsection occt_2142243456_9303848265311 CopyWithLink
-Syntax: CopyWithLink docname entry Xdocname Xentry
+Syntax: CopyWithLink docname entry Xdocname Xentry
Aborts the Command transaction.
Copies the content of **entry** to **Xentry**. The link is registred with an Xlink attribute at ** Xentry** label.
@subsubsection occt_2142243456_9303848265312 UpdateXLinks
-Syntax: UpdateXLinks docname entry
+Syntax: UpdateXLinks docname entry
Sets modifications on labels impacted by external references to the **entry**. The **document** becomes invalid and must be recomputed
**Example**
@subsubsection occt_2142243456_9303848265313 DumpDocument
-Syntax: DumpDocument docname
+Syntax: DumpDocument docname
Displays parameters of **docname** document.
**Example**
@subsubsection occt_2142243456_930384826541 MakeDF
-Syntax: MakeDF dfname
+Syntax: MakeDF dfname
Creates a new data framework.
**Example**
@subsubsection occt_2142243456_930384826542 ClearDF
-Syntax: ClearDF dfname
+Syntax: ClearDF dfname
Clears a data framework.
**Example**
@subsubsection occt_2142243456_930384826543 CopyDF
-Syntax: CopyDF dfname1 entry1 [dfname2] entry2
+Syntax: CopyDF dfname1 entry1 [dfname2] entry2
Copies a data framework.
**Example**
@subsubsection occt_2142243456_930384826544 CopyLabel
-Syntax: CopyLabel dfname fromlabel tolablel
+Syntax: CopyLabel dfname fromlabel tolablel
Copies a label.
**Example**
@subsubsection occt_2142243456_930384826545 MiniDumpDF
-Syntax: MiniDumpDF dfname
+Syntax: MiniDumpDF dfname
Makes a mini-dump of a data framework.
**Example**
@subsubsection occt_2142243456_930384826546 XDumpDF
-Syntax: XDumpDF dfname
+Syntax: XDumpDF dfname
Makes an extended dump of a data framework.
**Example**
@subsubsection occt_2142243456_930384826551 SetInteger
-Syntax: SetInteger dfname entry value
+Syntax: SetInteger dfname entry value
Finds or creates an Integer attribute at **entry** label and sets **value**.
**Example**
@subsubsection occt_2142243456_930384826552 GetInteger
-Syntax: GetInteger dfname entry [drawname]
+Syntax: GetInteger dfname entry [drawname]
Gets a value of an Integer attribute at **entry** label and sets it to **drawname** variable, if it is defined.
**Example**
@subsubsection occt_2142243456_930384826553 SetReal
-Syntax: SetReal dfname entry value
+Syntax: SetReal dfname entry value
Finds or creates a Real attribute at **entry** label and sets **value**.
**Example**
@subsubsection occt_2142243456_930384826554 GetReal
-Syntax: GetReal dfname entry [drawname]
+Syntax: GetReal dfname entry [drawname]
Gets a value of a Real attribute at **entry** label and sets it to **drawname** variable, if it is defined.
**Example**
@subsubsection occt_2142243456_930384826555 SetIntArray
-Syntax: SetIntArray dfname entry lower upper value1 value2 …
+Syntax: SetIntArray dfname entry lower upper value1 value2 …
Finds or creates an IntegerArray attribute at **entry** label with lower and upper bounds and sets **value1, **.** value2…**
**Example**
@subsubsection occt_2142243456_930384826556 GetIntArray
-Syntax: GetIntArray dfname entry
+Syntax: GetIntArray dfname entry
Gets a value of an IntegerArray attribute at **entry** label.
**Example**
@subsubsection occt_2142243456_930384826557 SetRealArray
-Syntax: SetRealArray dfname entry lower upper value1 value2 …
+Syntax: SetRealArray dfname entry lower upper value1 value2 …
Finds or creates a RealArray attribute at **entry** label with lower and upper bounds and sets **value1, **.** value2…**
**Example**
@subsubsection occt_2142243456_930384826558 GetRealArray
-Syntax: GetRealArray dfname entry
+Syntax: GetRealArray dfname entry
Gets a value of a RealArray attribute at **entry** label.
**Example**
@subsubsection occt_2142243456_930384826559 SetComment
-Syntax: SetComment dfname entry value
+Syntax: SetComment dfname entry value
Finds or creates a Comment attribute at **entry** label and sets **value**.
**Example**
@subsubsection occt_2142243456_9303848265510 GetComment
-Syntax: GetComment dfname entry
+Syntax: GetComment dfname entry
Gets a value of a Comment attribute at **entry** label.
**Example**
@subsubsection occt_2142243456_9303848265511 SetExtStringArray
-Syntax: SetExtStringArray dfname entry lower upper value1 value2 …
+Syntax: SetExtStringArray dfname entry lower upper value1 value2 …
Finds or creates an ExtStringArray attribute at **entry** label with lower and upper bounds and sets **value1, **.** value2…**
**Example**
@subsubsection occt_2142243456_9303848265512 GetExtStringArray
-Syntax: GetExtStringArray dfname entry
+Syntax: GetExtStringArray dfname entry
Gets a value of an ExtStringArray attribute at **entry** label.
**Example**
@subsubsection occt_2142243456_9303848265513 SetName
-Syntax: SetName dfname entry value
+Syntax: SetName dfname entry value
Finds or creates a Name attribute at **entry** label and set **value**.
**Example**
@subsubsection occt_2142243456_9303848265514 GetName
-Syntax: GetName dfname entry
+Syntax: GetName dfname entry
Gets a value of a Name attribute at **entry** label.
**Example**
@subsubsection occt_2142243456_9303848265515 SetReference
-Syntax: SetReference dfname entry reference
+Syntax: SetReference dfname entry reference
Creates a Reference attribute at **entry** label and sets **reference**.
**Example**
@subsubsection occt_2142243456_9303848265516 GetReference
-Syntax: GetReference dfname entry
+Syntax: GetReference dfname entry
Gets a value of a Reference attribute at **entry** label.
**Example**
@subsubsection occt_2142243456_9303848265517 SetUAttribute
-Syntax: SetUAttribute dfname entry localGUID
+Syntax: SetUAttribute dfname entry localGUID
Creates a UAttribute attribute at **entry** label with **localGUID**.
**Example**
@subsubsection occt_2142243456_9303848265518 GetUAttribute
-Syntax: GetUAttribute dfname entry loacalGUID
+Syntax: GetUAttribute dfname entry loacalGUID
Finds a UAttribute at **entry** label with **localGUID**.
**Example**
@subsubsection occt_2142243456_9303848265519 SetFunction
-Syntax: SetFunction dfname entry ID failure
+Syntax: SetFunction dfname entry ID failure
Finds or creates a Function attribute at **entry** label with driver ID and **failure** index.
**Example**
@subsubsection occt_2142243456_9303848265520 GetFunction
-Syntax: GetFunction dfname entry ID failure
+Syntax: GetFunction dfname entry ID failure
Finds a Function attribute at **entry** label and sets driver ID to **ID** variable and failure index to **failure** variable.
**Example**
@subsubsection occt_2142243456_9303848265521 NewShape
-Syntax: NewShape dfname entry [shape]
+Syntax: NewShape dfname entry [shape]
Finds or creates a Shape attribute at **entry** label. Creates or updates the associated NamedShape attribute by **shape** if **shape** is defined.
@subsubsection occt_2142243456_9303848265522 SetShape
-Syntax: SetShape dfname entry shape
+Syntax: SetShape dfname entry shape
Creates or updates a NamedShape attribute at **entry** label by **shape**.
**Example**
@subsubsection occt_2142243456_9303848265523 GetShape
-Syntax: GetShape2 dfname entry shape
+Syntax: GetShape2 dfname entry shape
Sets a shape from NamedShape attribute associated with **entry** label to **shape** draw variable.
**Example**
@subsubsection occt_2142243456_930384826561 SetPoint
-Syntax: SetPoint dfname entry point
+Syntax: SetPoint dfname entry point
Finds or creates a Point attribute at **entry** label and sets **point** as generated in the associated NamedShape attribute.
**Example**
@subsubsection occt_2142243456_930384826562 GetPoint
-Syntax: GetPoint dfname entry [drawname]
+Syntax: GetPoint dfname entry [drawname]
Gets a vertex from NamedShape attribute at **entry** label and sets it to **drawname** variable, if it is defined.
**Example**
@subsubsection occt_2142243456_930384826563 SetAxis
-Syntax: SetAxis dfname entry axis
+Syntax: SetAxis dfname entry axis
Finds or creates an Axis attribute at **entry** label and sets **axis** as generated in the associated NamedShape attribute.
**Example**
@subsubsection occt_2142243456_930384826564 GetAxis
-Syntax: GetAxis dfname entry [drawname]
+Syntax: GetAxis dfname entry [drawname]
Gets a line from NamedShape attribute at **entry** label and sets it to **drawname** variable, if it is defined.
**Example**
@subsubsection occt_2142243456_930384826565 SetPlane
-Syntax: SetPlane dfname entry plane
+Syntax: SetPlane dfname entry plane
Finds or creates a Plane attribute at **entry** label and sets **plane** as generated in the associated NamedShape attribute.
**Example**
@subsubsection occt_2142243456_930384826566 GetPlane
-Syntax: GetPlane dfname entry [drawname]
+Syntax: GetPlane dfname entry [drawname]
Gets a plane from NamedShape attribute at **entry** label and sets it to **drawname** variable, if it is defined.
**Example**
@subsubsection occt_2142243456_930384826567 SetGeometry
-Syntax: SetGeometry dfname entry [type] [shape]
+Syntax: SetGeometry dfname entry [type] [shape]
Creates a Geometry attribute at **entry** label and sets **type** and **shape** as generated in the associated NamedShape attribute if they are defined. **type** must be one of the following: **any/pnt/lin/cir/ell/spl/pln/cyl**.
@subsubsection occt_2142243456_930384826568 GetGeometryType
-Syntax: GetGeometryType dfname entry
+Syntax: GetGeometryType dfname entry
Gets a geometry type from Geometry attribute at **entry** label.
**Example**
@subsubsection occt_2142243456_930384826569 SetConstraint
-Syntax: SetConstraint dfname entry keyword geometrie [geometrie …]
- SetConstraint dfname entry *plane* geometrie
- SetConstraint dfname entry *value* value
+Syntax: SetConstraint dfname entry keyword geometrie [geometrie …]
+ SetConstraint dfname entry *plane* geometrie
+ SetConstraint dfname entry *value* value
1. Creates a Constraint attribute at **entry** label and sets **keyword** constraint between geometry(ies).
**keyword** must be one of the following:
@subsubsection occt_2142243456_9303848265610 GetConstraint
-Syntax: GetConstraint dfname entry
+Syntax: GetConstraint dfname entry
Dumps a Constraint attribute at **entry** label
**Example**
@subsubsection occt_2142243456_9303848265611 SetVariable
-Syntax: SetVariable dfname entry isconstant(0/1) units
+Syntax: SetVariable dfname entry isconstant(0/1) units
Creates a Variable attribute at **entry** label and sets **isconstant** flag and **units** as a string.
**Example**
@subsubsection occt_2142243456_9303848265612 GetVariable
-Syntax: GetVariable dfname entry isconstant units
+Syntax: GetVariable dfname entry isconstant units
Gets an **isconstant** flag and **units** of a Variable attribute at **entry** label.
**Example**
@subsubsection occt_2142243456_930384826571 RootNode
-Syntax: RootNode dfname treenodeentry [ID]
+Syntax: RootNode dfname treenodeentry [ID]
Returns ultimate father of TreeNode attribute identified by its **treenodeentry** and its **ID** (or default ID, if **ID** is not defined).
@subsubsection occt_2142243456_930384826572 SetNode
-Syntax: SetNode dfname treenodeentry [ID]
+Syntax: SetNode dfname treenodeentry [ID]
Creates a TreeNode attribute on the **treenodeentry** label with its tree **ID** (or assigns a default ID, if the **ID** is not defined).
@subsubsection occt_2142243456_930384826573 AppendNode
-Syntax: AppendNode dfname fatherentry childentry [fatherID]
+Syntax: AppendNode dfname fatherentry childentry [fatherID]
Inserts a TreeNode attribute with its tree **fatherID** (or default ID, if **fatherID** is not defined) on **childentry** as last child of **fatherentry**.
@subsubsection occt_2142243456_930384826574 PrependNode
-Syntax: PrependNode dfname fatherentry childentry [fatherID]
+Syntax: PrependNode dfname fatherentry childentry [fatherID]
Inserts a TreeNode attribute with its tree **fatherID** (or default ID, if **fatherID** is not defined) on **childentry** as first child of **fatherentry**.
@subsubsection occt_2142243456_930384826575 InsertNodeBefore
-Syntax: InsertNodeBefore dfname treenodeentry beforetreenode [ID]
+Syntax: InsertNodeBefore dfname treenodeentry beforetreenode [ID]
Inserts a TreeNode attribute with tree **ID** (or default ID, if **ID** is not defined) **beforetreenode** before **treenodeentry**.
@subsubsection occt_2142243456_930384826576 InsertNodeAfter
-Syntax: InsertNodeAfter dfname treenodeentry aftertreenode [ID]
+Syntax: InsertNodeAfter dfname treenodeentry aftertreenode [ID]
Inserts a TreeNode attribute with tree **ID** (or default ID, if **ID** is not defined) **aftertreenode** after **treenodeentry**.
@subsubsection occt_2142243456_930384826577 DetachNode
-Syntax: DetachNode dfname treenodeentry [ID]
+Syntax: DetachNode dfname treenodeentry [ID]
Removes a TreeNode attribute with tree **ID** (or default ID, if **ID** is not defined) from **treenodeentry**.
@subsubsection occt_2142243456_930384826578 ChildNodeIterate
-Syntax: ChildNodeIterate dfname treenodeentry alllevels(0/1) [ID]
+Syntax: ChildNodeIterate dfname treenodeentry alllevels(0/1) [ID]
Iterates on the tree of TreeNode attributes with tree **ID** (or default ID, if **ID** is not defined). If **alllevels** is set to **1** it explores not only the first, but all the sub Step levels.
@subsubsection occt_2142243456_930384826579 InitChildNodeIterator
-Syntax: InitChildNodeIterator dfname treenodeentry alllevels(0/1) [ID]
+Syntax: InitChildNodeIterator dfname treenodeentry alllevels(0/1) [ID]
Initializes the iteration on the tree of TreeNode attributes with tree **ID** (or default ID, if **ID** is not defined). If **alllevels** is set to **1** it explores not only the first, but also all sub Step levels.
InitChildNodeIterate D 0:5 1
set aChildNumber 0
for {set i 1} {$i 100} {incr i} {
- if {[ChildNodeMore] == *TRUE*} {
- puts *Tree node = [ChildNodeValue]*
- incr aChildNumber
- ChildNodeNext
- }
+ if {[ChildNodeMore] == *TRUE*} {
+ puts *Tree node = [ChildNodeValue]*
+ incr aChildNumber
+ ChildNodeNext
+ }
}
puts *aChildNumber=$aChildNumber*
@subsubsection occt_2142243456_9303848265710 ChildNodeMore
-Syntax: ChildNodeMore
+Syntax: ChildNodeMore
Returns TRUE if there is a current item in the iteration.
@subsubsection occt_2142243456_9303848265711 ChildNodeNext
-Syntax: ChildNodeNext
+Syntax: ChildNodeNext
Moves to the next Item.
@subsubsection occt_2142243456_9303848265712 ChildNodeValue
-Syntax: ChildNodeValue
+Syntax: ChildNodeValue
Returns the current treenode of ChildNodeIterator.
@subsubsection occt_2142243456_9303848265713 ChildNodeNextBrother
-Syntax: ChildNodeNextBrother
+Syntax: ChildNodeNextBrother
Moves to the next Brother. If there is none, goes up. This method is interesting only with ;allLevels; behavior.
@subsubsection occt_2142243456_930384826581 AISInitViewer
-Syntax: AISInitViewer docname
+Syntax: AISInitViewer docname
Creates and sets AISViewer attribute at root label, creates AIS viewer window.
**Example**
@subsubsection occt_2142243456_930384826582 AISRepaint
-Syntax: AISRepaint docname
+Syntax: AISRepaint docname
Updates the AIS viewer window.
**Example**
@subsubsection occt_2142243456_930384826583 AISDisplay
-Syntax: AISDisplay docname entry [not_update]
+Syntax: AISDisplay docname entry [not_update]
Displays a presantation of AISobject from **entry** label in AIS viewer. If **not_update** is not defined then AISobject is recomputed and all visualization settings are applied.
@subsubsection occt_2142243456_930384826584 AISUpdate
-Syntax: AISUpdate docname entry
+Syntax: AISUpdate docname entry
Recomputes a presantation of AISobject from **entry** label and applies the visualization setting in AIS viewer.
**Example**
@subsubsection occt_2142243456_930384826585 AISErase
-Syntax: AISErase docname entry
+Syntax: AISErase docname entry
Erases AISobject of **entry** label in AIS viewer.
**Example**
@subsubsection occt_2142243456_930384826586 AISRemove
-Syntax: AISRemove docname entry
+Syntax: AISRemove docname entry
Erases AISobject of **entry** label in AIS viewer, then AISobject is removed from AIS_InteractiveContext.
**Example**
@subsubsection occt_2142243456_930384826587 AISSet
-Syntax: AISSet docname entry ID
+Syntax: AISSet docname entry ID
Creates AISPresentation attribute at **entry** label and sets as driver ID. ID must be one of the following: **A** (axis), **C** (constraint), **NS** (namedshape), **G** (geometry), **PL** (plane), **PT** (point).
@subsubsection occt_2142243456_930384826588 AISDriver
-Syntax: AISDriver docname entry [ID]
+Syntax: AISDriver docname entry [ID]
Returns DriverGUID stored in AISPresentation attribute of an **entry** label or sets a new one. ID must be one of the following: **A** (axis), **C** (constraint), **NS** (namedshape), **G** (geometry), **PL** (plane), **PT** (point).
@subsubsection occt_2142243456_930384826589 AISUnset
-Syntax: AISUnset docname entry
+Syntax: AISUnset docname entry
Deletes AISPresentation attribute (if it exists) of an **entry** label.
**Example**
@subsubsection occt_2142243456_9303848265810 AISTransparency
-Syntax: AISTransparency docname entry [transparency]
+Syntax: AISTransparency docname entry [transparency]
Sets (if **transparency** is defined) or gets the value of transparency for AISPresentation attribute of an **entry** label.
**Example**
@subsubsection occt_2142243456_9303848265811 AISHasOwnTransparency
-Syntax: AISHasOwnTransparency docname entry
+Syntax: AISHasOwnTransparency docname entry
Tests AISPresentation attribute of an **entry** label by own transparency.
**Example**
@subsubsection occt_2142243456_9303848265812 AISMaterial
-Syntax: AISMaterial docname entry [material]
+Syntax: AISMaterial docname entry [material]
Sets (if **material** is defined) or gets the value of transparency for AISPresentation attribute of an **entry** label. **material** is integer from 0 to 20 (see **meshmat**).
@subsubsection occt_2142243456_9303848265813 AISHasOwnMaterial
-Syntax: AISHasOwnMaterial docname entry
+Syntax: AISHasOwnMaterial docname entry
Tests AISPresentation attribute of an **entry** label by own material.
**Example**
@subsubsection occt_2142243456_9303848265814 AISColor
-Syntax: AISColor docname entry [color]
+Syntax: AISColor docname entry [color]
Sets (if **color** is defined) or gets value of color for AISPresentation attribute of an **entry** label. **color** is integer from 0 to 516 (see color names in **vsetcolor**).
**Example**
@subsubsection occt_2142243456_9303848265815 AISHasOwnColor
-Syntax: AISHasOwnColor docname entry
+Syntax: AISHasOwnColor docname entry
Tests AISPresentation attribute of an **entry** label by own color.
**Example**
@subsubsection occt_2142243456_1101404852621 point
-Syntax: point name x y [z]
+Syntax: point name x y [z]
**point **creates a 2d or 3d point, depending on the number of arguments.
<h5>Example</h5>
@subsubsection occt_2142243456_1101404852622 line
-Syntax: line name x y [z] dx dy [dz]
+Syntax: line name x y [z] dx dy [dz]
**line **creates a 2d or 3d line. x y z are the coordinates of the line’s point of origin; dx, dy, dz give the direction vector.
@subsubsection occt_2142243456_1101404852623 circle
-Syntax: circle name x y [z [dx dy dz]] [ux uy [uz]] radius
+Syntax: circle name x y [z [dx dy dz]] [ux uy [uz]] radius
**circle **creates a 2d or a 3d circle.
See also: **circle**
@subsubsection occt_2142243456_1101404852625 hyperbola
-Syntax: hyperbola name x y [z [dx dy dz]] [ux uy [uz]] firstradius secondradius
+Syntax: hyperbola name x y [z [dx dy dz]] [ux uy [uz]] firstradius secondradius
**hyperbola **creates a 2d or 3d conic. The first arguments define the center. The axis system is given by *firstradius*, the major radius, and *secondradius*, the minor radius. Note that the hyperbola has only one branch, that in the X direction.
@subsubsection occt_2142243456_1101404852626 parabola
-Syntax: parabola name x y [z [dx dy dz]] [ux uy [uz]] FocalLength
+Syntax: parabola name x y [z [dx dy dz]] [ux uy [uz]] FocalLength
**parabola **creates a 2d or 3d parabola. in the axis system defined by the first arguments.The origin is the apex of the parabola.
@subsubsection occt_2142243456_1101404852627 beziercurve, dbeziercurve
-Syntax: beziercurve name nbpole pole, [weight]
+Syntax: beziercurve name nbpole pole, [weight]
2dbeziercurve name nbpole pole, [weight]
**beziercurve **creates a 3d rational or non-rational Bezier curve. Give the number of poles (control points,) and the coordinates of the poles (x1 y1 z1 [w1] x2 y2 z2 [w2]). The degree will be nbpoles-1. To create a rational curve, give weights with the poles. You must give weights for all poles or for none. If the weights of all the poles are equal, the curve is polynomial, and therefore non-rational.
@subsubsection occt_2142243456_1101404852628 bsplinecurve, dbsplinecurve, pbsplinecurve, dpbsplinecurve
-Syntax: bsplinecurve name degree nbknots knot, umult pole, weight 2dbsplinecurve name degree nbknots knot, umult pole, weight pbsplinecurve name degree nbknots knot, umult pole, weight(periodic)
+Syntax: bsplinecurve name degree nbknots knot, umult pole, weight 2dbsplinecurve name degree nbknots knot, umult pole, weight pbsplinecurve name degree nbknots knot, umult pole, weight(periodic)
2dpbsplinecurve name degree nbknots knot, umult pole, weight (periodic)
**bsplinecurve **creates 2d or 3d bspline curves; the **pbsplinecurve **and **2dpbsplinecurve **commands create periodic bspline curves.
@subsubsection occt_2142243456_1101404852629 uiso, viso
-Syntax: uiso name surface u
+Syntax: uiso name surface u
viso name surface u
Use these commands to create a U or V isoparametric curve from a surface.
@subsubsection occt_2142243456_11014048526210 tod, tod
-Syntax: to3d name curve2d [plane]
+Syntax: to3d name curve2d [plane]
to2d name curve3d [plane]
The **to3d **and **to2d **commands are used to create respectively a 3d curve from a 2d curve and a 2d curve from a 3d curve. The transformation uses a planar surface to define the XY plane in 3d (by default this plane is the default OXYplane). **to3d **always gives a correct result, but as **to2d **is not a projection, it may surprise you. It is always correct if the curve is planar and parallel to the plane of projection. The points defining the curve are projected on the plane. A circle, however, will remain a circle and will not be changed to an ellipse.
@subsubsection occt_2142243456_11014048526211 project
-Syntax: project name curve3d surface
+Syntax: project name curve3d surface
**project **computes a 2d curve in the parametric space of a surface corresponding to a 3d curve. This can only be used on analytical surfaces.
**Example**
@subsubsection occt_2142243456_1101404852631 plane
-Syntax: plane name [x y z [dx dy dz [ux uy uz]]]
+Syntax: plane name [x y z [dx dy dz [ux uy uz]]]
Uses this command to create an infinite plane. A plane is the same as a 3d coordinate system, x,y,z is the origin, dx, dy, dz is the Z direction and ux, uy, uz is the X direction. The plane is perpendicular to Z and X is the U parameter. dx,dy,dz and ux,uy,uz must not be null and not colinear. ux,uy,uz will be modified to be orthogonal to dx,dy,dz. There are default values for the coordinate system. If no arguments are given, the global system (0,0,0), (0,0,1), (1,0,0). If only the origin is given, the axes are those given by default(0,0,1), (1,0,0). If the origin and the Z axis are given, the X axis is generated perpendicular to the Z axis. Note that this definition will be used for all analytical surfaces.
**Example**
@subsubsection occt_2142243456_1101404852632 cylinder
-Syntax: cylinder name [x y z [dx dy dz [ux uy uz]]] radius
+Syntax: cylinder name [x y z [dx dy dz [ux uy uz]]] radius
A cylinder is defined by a coordinate system, and a radius. The surface generated is an infinite cylinder with the Z axis as the axis. The U parameter is the angle starting from X going in the Y direction.
See also: **plane**
@subsubsection occt_2142243456_1101404852633 cone
-Syntax: cone name [x y z [dx dy dz [ux uy uz]]] semi-angle radius
+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.
See also: **plane**
**Example**
@subsubsection occt_2142243456_1101404852634 sphere
-Syntax: sphere name [x y z [dx dy dz [ux uy uz]]] radius
+Syntax: sphere name [x y z [dx dy dz [ux uy uz]]] radius
Creates a sphere in the local coordinate system defined in the **plane **command. The sphere is centered at the origin. To parameterize the sphere, u is the angle from X to Y, between o and 2*pi. v is the angle in the half-circle at angle u in the plane containing the Z axis. v is between -pi/2 and pi/2. The poles are the points Z = +/- radius; their parameters are u,+/-pi/2 for any u in 0,2*pi.
**Example**
@subsubsection occt_2142243456_1101404852635 torus
-Syntax: torus name [x y z [dx dy dz [ux uy uz]]] major minor
+Syntax: torus name [x y z [dx dy dz [ux uy uz]]] major minor
Creates a torus in the local coordinate system with the given major and minor radii. Z is the axis for the major radius. The major radius may be lower in value than the minor radius.
@subsubsection occt_2142243456_1101404852636 beziersurf
-Syntax: beziersurf name nbupoles nbvolpes pole, [weight]
+Syntax: beziersurf name nbupoles nbvolpes pole, [weight]
Use this command to create a bezier surface, rational or non-rational. First give the numbers of poles in the u and v directions.
See also: **beziercurve**
-@subsubsection occt_2142243456_1101404852637 bsplinesurf, upbsplinesurf, vpbsplinesurf, uvpbsplinesurf
+@subsubsection occt_2142243456_1101404852637 bsplinesurf, upbsplinesurf, vpbsplinesurf, uvpbsplinesurf
-Syntax: bsplinesurf name udegree nbuknots uknot umult ... nbvknot vknot
+Syntax: bsplinesurf name udegree nbuknots uknot umult ... nbvknot vknot
vmult ... x y z w ...
upbsplinesurf ...
vpbsplinesurf ...
@subsubsection occt_2142243456_1101404852638 trim, trimu, trimv
-Syntax: trim newname name [u1 u2 [v1 v2]]
+Syntax: trim newname name [u1 u2 [v1 v2]]
trimu newname name
trimv newname name
@subsubsection occt_2142243456_1101404852639 offset
-Syntax: offset name basename distance [dx dy dz]
+Syntax: offset name basename distance [dx dy dz]
Creates offset curves or surfaces at a given distance from a basis curve or surface. Offset curves and surfaces are classes from the *Geom *package.
offset l1 e 20 0 0 1
@subsubsection occt_2142243456_11014048526310 revsurf
-Syntax: revsurf name curvename x y z dx dy dz
+Syntax: revsurf name curvename x y z dx dy dz
Creates a surface of revolution from a 3d curve. A surface of revolution or revolved surface is obtained by rotating a curve (called the *meridian*) through a complete revolution about an axis (referred to as the *axis of revolution*). The curve and the axis must be in the same plane (the *reference plane* of the surface). Give the point of origin x,y,z and the vector dx,dy,dz to define the axis of revolution. To parameterize a surface of revolution: u is the angle of rotation around the axis. Its origin is given by the position of the meridian on the surface. v is the parameter of the meridian.
**Example**
@subsubsection occt_2142243456_11014048526311 extsurf
-Syntax: extsurf newname curvename dx dy dz
+Syntax: extsurf newname curvename dx dy dz
Use the **extsurf **command to create a surface of linear extrusion from a 3d curve. The basis curve is swept in a given direction,the *direction of extrusion* defined by a vector. In the syntax, dx,dy,dz gives the direction of extrusion. To parameterize a surface of extrusion: u is the parameter along the extruded curve; the v parameter is along the direction of extrusion.
**Example**
@subsubsection occt_2142243456_11014048526312 convert
-Syntax: convert newname name
+Syntax: convert newname name
**convert **creates a 2d or 3d NURBS curve or a NURBS surface from any 2d curve, 3d curve or surface. In other words, conics, beziers and bsplines are turned into NURBS. Offsets are not processed.
**Example**
@subsubsection occt_2142243456_1101404852641 reverse, ureverse, vreverse
-Syntax: reverse curvename
+Syntax: reverse curvename
ureverse surfacename
vreverse surfacename
@subsubsection occt_2142243456_1101404852642 exchuv
-Syntax: exchuv surfacename
+Syntax: exchuv surfacename
For a bezier or bspline surface this command exchanges the u and v parameters.
**Example**
@subsubsection occt_2142243456_1101404852643 segment, segsur
-Syntax: segment curve Ufirst Ulast
+Syntax: segment curve Ufirst Ulast
segsur surface Ufirst Ulast Vfirst Vlast
**segment **and **segsur **segment a bezier curve and a bspline curve or surface respectively. These commands modify the curve to restrict it between the new parameters: the starting point of the modified curve, Ufirst, and the end point, Ulast. Ufirst is less than Ulast.
@subsubsection occt_2142243456_1101404852644 iincudeg, incvdeg
-Syntax: incudeg surfacename newdegree
+Syntax: incudeg surfacename newdegree
incvdeg surfacename newdegree
**incudeg **and **incvdeg **increase the degree in the U or V parameter of a bezier or bspline surface.
@subsubsection occt_2142243456_1101404852645 cmovep, movep, movecolp, moverowp
-Syntax: cmovep curve index dx dy [dz]
+Syntax: cmovep curve index dx dy [dz]
movep surface uindex vindex dx dy dz
movecolp surface uindex dx dy dz
moverowp surface vindex dx dy dz
@subsubsection occt_2142243456_1101404852646 insertpole, rempole, remcolpole, remrowpole
-Syntax: insertpole curvename index x y [z] [weight]
+Syntax: insertpole curvename index x y [z] [weight]
rempole curvename index
remcolpole surfacename index
remrowpole surfacename index
@subsubsection occt_2142243456_1101404852647 insertknot, insertuknot, insertvknot
-Syntax: insertknot name knot [mult = 1] [knot mult ...]
+Syntax: insertknot name knot [mult = 1] [knot mult ...]
insertuknot surfacename knot mult
insertvknot surfacename knot mult
@subsubsection occt_2142243456_1101404852648 remknot, remuknot, remvknot
-Syntax: remknot index [mult] [tol]
+Syntax: remknot index [mult] [tol]
remuknot index [mult] [tol]
remvknot index [mult] [tol]
@subsubsection occt_2142243456_1101404852649 setperiodic, setnotperiodic, setuperiodic, setunotperiodic, setvperiodic, setvnotperiodic
-Syntax: setperiodic curve
+Syntax: setperiodic curve
setnotperiodic curve
setuperiodic surface
setunotperiodic surface
setnotperiodic c1
@subsubsection occt_2142243456_11014048526410 setorigin, setuorigin, setvorigin
-Syntax: setorigin curvename index
+Syntax: setorigin curvename index
setuorigin surfacename index
setuorigin surfacename index
@subsubsection occt_2142243456_1101404852651 translate, dtranslate
-Syntax: translate name [names ...] dx dy dz
+Syntax: translate name [names ...] dx dy dz
2dtranslate name [names ...] dx dy
The **Translate **command translates 3d points, curves and surfaces along a vector dx,dy,dz. You can translate more than one object with the same command.
@subsubsection occt_2142243456_1101404852652 rotate, drotate
-Syntax: rotate name [name ...] x y z dx dy dz angle
+Syntax: rotate name [name ...] x y z dx dy dz angle
2drotate name [name ...] x y angle
The **rotate **command rotates a 3d point curve or surface. You must give an axis of rotation with a point x,y,z, a vector dx,dy,dz, and an angle in degrees.
@subsubsection occt_2142243456_1101404852653 pmirror, lmirror, smirror, dpmirror, dlmirror
-Syntax: pmirror name [names ...] x y z
+Syntax: pmirror name [names ...] x y z
lmirror name [names ...] x y z dx dy dz
smirror name [names ...] x y z dx dy dz
2dpmirror name [names ...] x y
@subsubsection occt_2142243456_1101404852654 pscale, dpscale
-Syntax: pscale name [name ...] x y z s
+Syntax: pscale name [name ...] x y z s
2dpscale name [name ...] x y s
The **pscale **and **2dpscale **commands transform an object by point scaling. You must give the center and the scaling factor. Because other scalings modify the type of the object, they are not provided. For example, a sphere may be transformed into an ellipsoid. Using a scaling factor of -1 is similar to using **pmirror**.
**Example**
@subsubsection occt_2142243456_1101404852661 coord
-Syntax: coord P x y [z]
+Syntax: coord P x y [z]
The **coord **command will set the coordinates of the point P. x, y (and optionally z)
**Example**
coord p x y z
# x value is 15
See also: **point**
-@subsubsection occt_2142243456_1101404852662 cvalue, dcvalue
+@subsubsection occt_2142243456_1101404852662 cvalue, dcvalue
-Syntax: cvalue curve U x y z [d1x d1y d1z [d2x d2y d2z]]
+Syntax: cvalue curve U x y z [d1x d1y d1z [d2x d2y d2z]]
2dcvalue curve U x y [d1x d1y [d2x d2y]]
For a curve at a given parameter, and depending on the number of arguments, **cvalue **computes: the coordinates in x,y,z, the first derivative in d1x,d1y,d1z and the second derivative in d2x,d2y,d2z.
@subsubsection occt_2142243456_1101404852664 localprop, minmaxcurandinf
-Syntax: localprop curvename U
+Syntax: localprop curvename U
minmaxcurandinf curve
The **localprop **command computes the curvature of a curve.
@subsubsection occt_2142243456_1101404852665 parameters
-Syntax: parameters surf/curve x y z U [V]
+Syntax: parameters surf/curve x y z U [V]
The **parameters **command returns the parameters on the surface of the 3d point x,y,z in variables u and v . This command may only be used on analytical surfaces: plane, cylinder, cone, sphere and torus.
**Example**
@subsubsection occt_2142243456_1101404852666 proj, dproj
-Syntax: proj name x y z
+Syntax: proj name x y z
2dproj name xy
Use **proj **to project a point on a 3d curve or a surface and **2dproj **for a 2d curve.
@subsubsection occt_2142243456_1101404852667 surface_radius
-Syntax: surface_radius surface u v [c1 c2]
+Syntax: surface_radius surface u v [c1 c2]
The **surface_radius **command computes the main curvatures of a surface at parameters (u,v). If there are extra arguments, their curvatures are stored in variables c1 and c2.
**Example**
@subsubsection occt_2142243456_1101404852671 intersect
-Syntax: intersect name surface1 surface2
+Syntax: intersect name surface1 surface2
The **intersect **command intersects two surfaces. If there is one intersection curve it will be named ;name;, if there are more than one they will be named ;name_1;, ;name_2;, ...
**Example**
@subsubsection occt_2142243456_1101404852672 dintersect
-Syntax: 2dintersect curve1 curve2
+Syntax: 2dintersect curve1 curve2
**2dintersect **displays the intersection points between two 2d curves.
**Example**
**2dapprox **fits a curve through 2d points, **appro **fits a curve through 3d points, **surfapp **and **grilapp **fits a surface through 3d points, **2dinterpolate **may be used to interpolate a curve.
-@subsubsection occt_2142243456_1101404852681 appro, dapprox
+@subsubsection occt_2142243456_1101404852681 appro, dapprox
-Syntax: appro result nbpoint [curve]
+Syntax: appro result nbpoint [curve]
2dapprox result nbpoint [curve / x1 y1 x2 y2]
These commands fit a curve through a set of points. First give the number of points, then choose one of the three ways available to get the points. If you have no arguments, click on the points. If you have a curve argument or a list of points, the command launches computation of the points on the curve.
@subsubsection occt_2142243456_1101404852692 lintan
-Syntax: lintan name curve curve [angle]
+Syntax: lintan name curve curve [angle]
The **lintan **command will build all 2d lines tangent to two curves. If a third angle argument is given the second curve must be a line and **lintan **will build all lines tangent to the first curve and forming the given angle with the line. The angle is given in degrees. The solutions are named name_1, name_2, etc.
**Example**
@subsubsection occt_2142243456_11014048526101 dmod, discr, defle
-Syntax: dmode name [name ...] u/d
+Syntax: dmode name [name ...] u/d
discr name [name ...] nbintervals
defle name [name ...] deflection
dmode c u
-@subsubsection occt_2142243456_11014048526102 nbiso
+@subsubsection occt_2142243456_11014048526102 nbiso
-Syntax: nbiso name [names...] nuiso nviso
+Syntax: nbiso name [names...] nuiso nviso
**nbiso **changes the number of isoparametric curves displayed on a surface in the U and V directions. On a bspline surface, isoparametric curves are displayed by default at knot values. Use **nbiso **to turn this feature off.
**Example**
@subsubsection occt_2142243456_11014048526103 clpoles, shpoles
-Syntax: clpoles name
+Syntax: clpoles name
shpoles name
On bezier and bspline curves and surfaces, the control polygon is displayed by default: **clpoles **erases it and **shpoles **restores it.
@subsubsection occt_2142243456_11014048526104 clknots, shknots
-Syntax: clknots name
+Syntax: clknots name
shknots name
By default, knots on a bspline curve or surface are displayed with markers at the points with parametric value equal to the knots. **clknots **removes them and **shknots **restores them.
@subsubsection occt_2142243456_1869436669711 isos, discretisation
-Syntax: isos [name ...][nbisos]
+Syntax: isos [name ...][nbisos]
discretisation nbpoints
**isos **determines or changes the number of isoparametric curves on shapes.
@subsubsection occt_2142243456_1869436669712 orientation, complement, invert, normals, range
-Syntax: orientation name [name ...] F/R/E/I
+Syntax: orientation name [name ...] F/R/E/I
complement name [name ...]
invert name
normals s (length = 10), disp normals
@subsubsection occt_2142243456_1869436669713 explode, exwire, nbshapes
-Syntax: explode name [C/So/Sh/F/W/E/V]
+Syntax: explode name [C/So/Sh/F/W/E/V]
exwire name
nbshapes name
@subsubsection occt_2142243456_1869436669714 emptycopy, add, compound
-Syntax: emptycopy [newname] name
+Syntax: emptycopy [newname] name
add name toname
compound [name ...] compoundname
@subsubsection occt_2142243456_1869436669715 checkshape
-Syntax: checkshape [-top] shape [result] [-short]
+Syntax: checkshape [-top] shape [result] [-short]
Where:
*-top* – check only topological validity of a shape.
@subsubsection occt_2142243456_1869436669721 vertex
-Syntax: vertex name [x y z / p edge]
+Syntax: vertex name [x y z / p edge]
Creates a vertex at either a 3d location x,y,z or the point at parameter p on an edge.
**Example**
@subsubsection occt_2142243456_1869436669722 edge, mkedge, uisoedge, visoedge
-Syntax: edge name vertex1 vertex2
+Syntax: edge name vertex1 vertex2
mkedge edge curve [surface] [pfirst plast] [vfirst [pfirst] vlast [plast]]
uisoedge edge face u v1 v2
visoedge edge face v u1 u2
@subsubsection occt_2142243456_1869436669723 wire, polyline, polyvertex
-Syntax: wire wirename e1/w1 [e2/w2 ...]
+Syntax: wire wirename e1/w1 [e2/w2 ...]
polyline name x1 y1 z1 x2 y2 z2 ...
polyvertex name v1 v2 ...
@subsubsection occt_2142243456_1869436669724 profile
-Syntax profile name [code values] [code values] ...
-
-**Code** **Values ** **Action**
-O X Y Z Sets the origin of the plane
-P DX DY DZ UX UY UZ Sets the normal and X of the plane
-F X Y Sets the first point
-X DX Translates a point along X
-Y DY Translates a point along Y
-L DL Translates a point along direction
-XX X Sets point X coordinate
-YY Y Sets point Y coordinate
-T DX DY Translates a point
-TT X Y Sets a point
-R Angle Rotates direction
-RR Angle Sets direction
-D DX DY Sets direction
-IX X Intersects with vertical
-IY Y Intersects with horizontal
-C Radius Angle Arc of circle tangent to direction
+Syntax profile name [code values] [code values] ...
+
+**Code** **Values ** **Action**
+O X Y Z Sets the origin of the plane
+P DX DY DZ UX UY UZ Sets the normal and X of the plane
+F X Y Sets the first point
+X DX Translates a point along X
+Y DY Translates a point along Y
+L DL Translates a point along direction
+XX X Sets point X coordinate
+YY Y Sets point Y coordinate
+T DX DY Translates a point
+TT X Y Sets a point
+R Angle Rotates direction
+RR Angle Sets direction
+D DX DY Sets direction
+IX X Intersects with vertical
+IY Y Intersects with horizontal
+C Radius Angle Arc of circle tangent to direction
<h5>Suffix</h5>
-No suffix Makes a closed face
-W Make a closed wire
-WW Make an open wire
+No suffix Makes a closed face
+W Make a closed wire
+WW Make an open wire
**profile **builds a profile in a plane using a moving point and direction. By default, the profile is closed and a face is created. The original point is 0 0, and direction is 1 0 situated in the XY plane.
profile p F 1 0 x 2 y 1 c 1 45 l 1 tt 1.5 1.5 xx 0.2 yy 2 c 1 290 ix 0 r 90 ix -0.3
-@subsubsection occt_2142243456_1869436669725 bsplineprof
+@subsubsection occt_2142243456_1869436669725 bsplineprof
-Syntax: bsplineprof name [S face] [W WW]
+Syntax: bsplineprof name [S face] [W WW]
for an edge : digitizes ... mouse button 2
to end profile : mouse button 3
Build a profile in the XY plane from digitizes
By default the profile is closed and a face is built.
-W Make a closed wire
-WW Make an open wires
+W Make a closed wire
+WW Make an open wires
**bsplineprof **creates a 2d profile from bspline curves using the mouse as the input. MB1 creates the points, MB2 finishes the current curve and starts the next curve, MB3 closes the profile.
@subsubsection occt_2142243456_1869436669726 mkoffset
-Syntax: mkoffset result face/compound of wires nboffset stepoffset
+Syntax: mkoffset result face/compound of wires nboffset stepoffset
**mkoffset **creates a parallel wire in the same plane using a face or an existing continuous set of wires as a reference. The number of occurences is not limited.
@subsubsection occt_2142243456_1869436669727 mkplane, mkface
-Syntax: mkplane name wire
+Syntax: mkplane name wire
mkface name surface [ufirst ulast vfirst vlast]
**mkplane **generates a face from a planar wire. The planar surface will be constructed with an orientation which keeps the face inside the wire.
@subsubsection occt_2142243456_1869436669728 mkcurve, mksurface
-Syntax: mkcurve curve edge
+Syntax: mkcurve curve edge
mksurface name face
**mkcurve **creates a 3d curve from an edge. The curve will be trimmed to the edge boundaries.
@subsubsection occt_2142243456_1869436669729 pcurve
-Syntax: pcurve [name edgename] facename
+Syntax: pcurve [name edgename] facename
**pcurve **extracts the 2d curve of an edge on a face. If only the face is specified, the command extracts all the curves and colors them according to their orientation. This is useful in checking to see if the edges in a face are correctly oriented, i.e. they turn counterclockwise. To make curves visible, use a fitted 2d view.
**Example**
@subsubsection occt_2142243456_18694366697210 chfid
-Syntax: chfi2d result face [edge1 edge2 (F radius/CDD d1 d2/CDA d ang) ....
+Syntax: chfi2d result face [edge1 edge2 (F radius/CDD d1 d2/CDA d ang) ....
chfi2d creates chamfers and fillets on 2D objects. Select t:wo adjacent edges and:
@subsubsection occt_2142243456_18694366697211 nproject
-Syntax: nproject pj e1 e2 e3 ... surf -g -d [dmax] [Tol
+Syntax: nproject pj e1 e2 e3 ... surf -g -d [dmax] [Tol
[continuity [maxdeg [maxseg]]]
**nproject **creates a shape projection which is normal to the target surface.
@subsubsection occt_2142243456_1869436669731 box, wedge
-Syntax: box name [x y z] dx dy dz
+Syntax: box name [x y z] dx dy dz
wedge name dx dy dz ltx / xmin zmin xmax xmax
**box **creates a box parallel to the axes with dimensions dx,dy,dz. x,y,z is the corner of the box. It is the default origin.
@subsubsection occt_2142243456_1869436669732 pcylinder, pcone, psphere, ptorus
-Syntax: pcylinder name [plane] radius height [angle]
+Syntax: pcylinder name [plane] radius height [angle]
pcone name [plane] radius1 radius2 height [angle]
pcone name [plane] radius1 radius2 height [angle]
psphere name [plane] radius1 [angle1 angle2] [angle]
ptorus to 20 5 0 90
@subsubsection occt_2142243456_1869436669733 halfspace
-Syntax: halfspace result face/shell x y z
+Syntax: halfspace result face/shell x y z
**halfspace **creates an infinite solid volume based on a face in a defined direction. This volume can be used to perform the boolean operation of cutting a solid by a face or plane.
**Example**
@subsubsection occt_2142243456_1869436669741 prism
-Syntax: prism result base dx dy dz [Copy | Inf | SemiInf]
+Syntax: prism result base dx dy dz [Copy | Inf | SemiInf]
**prism **creates a new shape by sweeping a shape in a direction. Any shape can be swept: a vertex gives an edge; an edge gives a face; and a face gives a solid.
@subsubsection occt_2142243456_1869436669742 revol
-Syntax: revol result base x y z dx dy dz angle [Copy]
+Syntax: revol result base x y z dx dy dz angle [Copy]
**revol **creates a new shape by sweeping a base shape through an angle along the axis x,y,z dx,dy,dz. As with the prism command, the shape can be of any type and is not shared if *Copy *is specified.
**Example**
@subsubsection occt_2142243456_1869436669743 pipe
-Syntax: pipe name wire_spine Profile
+Syntax: pipe name wire_spine Profile
**pipe **creates a new shape by sweeping a shape known as the profile along a wire known as the spine.
**Example**
@subsubsection occt_2142243456_1869436669744 mksweep, deletesweep, buildsweep, simulsweep
-Syntax: mksweep wire
+Syntax: mksweep wire
addsweep wire[vertex][-M][-C] [auxiilaryshapedeletesweep wire
setsweep options [arg1 [arg2 [...]]]
@subsubsection occt_2142243456_1869436669745 thrusections
-Syntax: thrusections [-N] result issolid isruled wire1 wire2 [..wire..]
+Syntax: thrusections [-N] result issolid isruled wire1 wire2 [..wire..]
**thrusections **creates a shape using wires that are positioned in different planes. Each wire selected must have the same number of edges and vertices.
A bezier curve is generated between the vertices of each wire. The option [-N] means no check is made on wires for direction.
# create the shape
thrusections th issolid isruled w1 w2 w3
==thrusections th issolid isruled w1 w2 w3
-Tolerances obtenues -- 3d : 0
+Tolerances obtenues -- 3d : 0
-- 2d : 0
* **tmirror**, **tscale **always modify the shape.
-@subsubsection occt_2142243456_1869436669751 tcopy
+@subsubsection occt_2142243456_1869436669751 tcopy
Syntax: tcopy name toname [name toname ...]
ttranslate e2 0 5 0
# now modify the curve, only e1 and e2 will be modified
-@subsubsection occt_2142243456_1869436669752 tmove, treset
+@subsubsection occt_2142243456_1869436669752 tmove, treset
-Syntax: tmove name [name ...] shape
+Syntax: tmove name [name ...] shape
reset name [name ...]
**tmove **and **reset **modify the location, or the local coordinate system of a shape.
reset b1 b2
-@subsubsection occt_2142243456_1869436669753 ttranslate, trotate
+@subsubsection occt_2142243456_1869436669753 ttranslate, trotate
-Syntax: ttranslate [name ...] dx dy dz
+Syntax: ttranslate [name ...] dx dy dz
trotate [name ...] x y z dx dy dz angle
**ttranslate **translates a set of shapes by a given vector, and **trotate **rotates them by a given angle around an axis. Both commands only modify the location of the shape.
source toto.tcl
-@subsubsection occt_2142243456_1869436669754 tmirror, tscale
+@subsubsection occt_2142243456_1869436669754 tmirror, tscale
-Syntax: tmirror name x y z dx dy dz
+Syntax: tmirror name x y z dx dy dz
tscale name x y z scale
**tmirror **makes a mirror copy of a shape about a plane x,y,z dx,dy,dz. **Tscale **applies a central homotopic mapping to a shape.
@subsubsection occt_2142243456_1869436669761 fuse, cut, common
-Syntax: fuse name shape1 shape2
+Syntax: fuse name shape1 shape2
cut name shape1 shape2
common name shape1 shape2
@subsubsection occt_2142243456_1869436669762 section, psection
-Syntax: section result shape1 shape2
+Syntax: section result shape1 shape2
psection name shape plane
**section **creates a compound object consisting of the edges for the intersection curves on the faces of two shapes.
@subsubsection occt_2142243456_1869436669763 sewing
-Syntax: sewing result [tolerance] shape1 shape2 ...
+Syntax: sewing result [tolerance] shape1 shape2 ...
**Sewing **joins shapes by connecting their adjacent or near adjacent edges. Adjacency can be redefined by modifying the tolerance value.
**bopcommon **creates a new shape which contains only whatever is in common between the two original shapes in their intersection.
-Syntax: bop shape1 shape2
+Syntax: bop shape1 shape2
bopcommon result
bopfuse result
bopcut result
**bopsection **creates a compound object consisting of the edges for the intersection curves on the faces of two shapes.
-Syntax: bop shape1 shape2
+Syntax: bop shape1 shape2
bopsection result
**bop** fills data structure (DS) of boolean operation for **shape1** and **shape2**.
**bopsection** command used after **bop** command.
-**-2d** - PCurves are computed on both parts.
+**-2d** - PCurves are computed on both parts.
**-2d1** - PCurves are computed on first part.
**-2d2 **- PCurves are computed on second part.
-**-a** - geometries built are approximated.
+**-a** - geometries built are approximated.
**Example**
@subsubsection occt_2142243456_1869436669773 bopcheck, bopargshape
-Syntax: bopcheck shape
+Syntax: bopcheck shape
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
- **F** (fuse)
- **O** (common)
- **C** (cut)
- **T** (cut21)
- **S** (section)
- **U** (unknown)
+ **F** (fuse)
+ **O** (common)
+ **C** (cut)
+ **T** (cut21)
+ **S** (section)
+ **U** (unknown)
By default a section is made.
- /Test Options
- **R** (disable small edges (shrank range) test)
- **F** (disable faces verification test)
- **T** (disable tangent faces searching test)
- **V** (disable test possibility to merge vertices)
- **E** (disable test possibility to merge edges)
- **I** (disable self-interference test)
- **P** (disable shape type test)
+ /Test Options
+ **R** (disable small edges (shrank range) test)
+ **F** (disable faces verification test)
+ **T** (disable tangent faces searching test)
+ **V** (disable test possibility to merge vertices)
+ **E** (disable test possibility to merge edges)
+ **I** (disable self-interference test)
+ **P** (disable shape type test)
By default all options are enabled.
- #Additional Test Options
- **B** (stop test on first faulty found); default OFF
- **F** (full output for faulty shapes);
+ #Additional Test Options
+ **B** (stop test on first faulty found); default OFF
+ **F** (full output for faulty shapes);
**By **default the output is made in a short format.
- NOTE: Boolean Operation and Test Options are used only for a couple of argument shapes, except for **I** and **P** options that are always used to test a couple of shapes as well as a single shape.
+ NOTE: Boolean Operation and Test Options are used only for a couple of argument shapes, except for **I** and **P** options that are always used to test a couple of shapes as well as a single shape.
**Example**
@subsubsection occt_2142243456_1869436669782 chamf
-Syntax: chamf newname shape edge face S dist
+Syntax: chamf newname shape edge face S dist
chamf newname shape edge face dist1 dist2
chamf newname shape edge face A dist angle
@subsubsection occt_2142243456_1869436669783 blend
-Syntax: blend result object rad1 ed1 rad2 ed2 ... [R/Q/P]
+Syntax: blend result object rad1 ed1 rad2 ed2 ... [R/Q/P]
**blend **creates a new shape by filleting the edges of an existing shape. The edge must be inside the shape. You may use the dot syntax. Note that the blend is propagated to the edges of tangential planar, cylindrical or conical faces.
**Example**
@subsubsection occt_2142243456_1869436669784 fubl
-Syntax: fubl name shape1 shape2 radius
-** **
+Syntax: fubl name shape1 shape2 radius
+** **
**fubl **creates a boolean fusion of two shapes and then blends (fillets) the intersection edges using the given radius.
**Example**
@subsubsection occt_2142243456_1869436669785 mkevol, updatevol, buildevol
-Syntax: mkevol result object (then use updatevol) [R/Q/P]
+Syntax: mkevol result object (then use updatevol) [R/Q/P]
updatevol edge u1 radius1 [u2 radius2 ...]
buildevol
@subsubsection occt_2142243456_1869436669791 lprops, sprops, vprops
-Syntax: lprops shape
+Syntax: lprops shape
sprops shape
vprops shape
Z = 9.9999999941362
Matrix of Inertia :
-366519.141445068 5.71451850691484e-12
+366519.141445068 5.71451850691484e-12
0.257640437382627
-5.71451850691484e-12 366519.141444962
-2.26823064169991e-10 0.257640437382627
-2.26823064169991e-10 314159.265358863
+5.71451850691484e-12 366519.141444962
+2.26823064169991e-10 0.257640437382627
+2.26823064169991e-10 314159.265358863
Moments :
IX = 366519.141446336
-@subsubsection occt_2142243456_1869436669792 bounding
+@subsubsection occt_2142243456_1869436669792 bounding
-Syntax: bounding shape
+Syntax: bounding shape
Displays the bounding box of a shape. The bounding box is a cuboid created with faces parallel to the x, y, and z planes. The command returns the dimension values of the the box, *xmin ymin zmin xmax ymax zmax.*
**Example**
# bounding box of a torus
ptorus t 20 5
bounding t
-==-27.059805107309852 -27.059805107309852 -
+==-27.059805107309852 -27.059805107309852 -
5.0000001000000003
-==27.059805107309852 27.059805107309852
+==27.059805107309852 27.059805107309852
5.0000001000000003
@subsubsection occt_2142243456_1869436669793 distmini
-Syntax: distmini name Shape1 Shape2
+Syntax: distmini name Shape1 Shape2
**distmini **calculates the minimum distance between two shapes. The calculation returns the number of solutions, If more than one solution exists. The options are displayed in the viewer(red) and the results are listed in the shell window. The distmini lines are considered as shapes which have a value v.
**Example**
* filling creates a surface from a group of surfaces.
-@subsubsection occt_2142243456_18694366697101 gplate,
+@subsubsection occt_2142243456_18694366697101 gplate,
Syntax: gplate result nbrcurfront nbrpntconst [SurfInit] [edge 0] [edge tang (1:G1;2:G2) surf]...[point] [u v tang (1:G1;2:G2) surf] ...
Approximation error : 0.000422195884750181
Criterium error : 3.43709808053967e-05
-@subsubsection occt_2142243456_18694366697102 filling, fillingparam
+@subsubsection occt_2142243456_18694366697102 filling, fillingparam
-Syntax: filling result nbB nbC nbP [SurfInit] [edge][face]order...
+Syntax: filling result nbB nbC nbP [SurfInit] [edge][face]order...
edge[face]order... point/u v face order...
**filling **creates a surface between borders. It uses the **gplate **algorithm but creates a surface that is tangential to the adjacent surfaces. The result is a smooth continuous surface based on the G1 criterion.
@subsubsection occt_2142243456_18694366697111 offsetshape, offsetcompshape
-Syntax: offsetshape r shape offset [tol] [face ...]
+Syntax: offsetshape r shape offset [tol] [face ...]
offsetcompshape r shape offset [face ...]
**offsetshape **and **offsetcompshape **assigns a thickness to the edges of a shape. The **offset **value can be negative or positive. This value defines the thickness and direction of the resulting shape. Each face can be removed to create a hollow object.
== b1_1 b1_2 b1_3 b1_4 b1_5 b1_6
offsetcompshape r b1 -1 b1_3
-Syntax: offsetparameter tolerance intersection(c/p) join(a/i)
-offsetload shape offset [face1 face2 …]
-offsetonface face1 offset1 face2 offset2 …
-offsetperform result
+Syntax: offsetparameter tolerance intersection(c/p) join(a/i)
+offsetload shape offset [face1 face2 …]
+offsetonface face1 offset1 face2 offset2 …
+offsetperform result
**offsetparameter** sets the values of parameters and options for the following command **offsetload**:
* *tolerance* defines the coincidence tolerance criterion for generated shapes;
* *intersection* defines the mode of intersection: *c* means complete intersection, *p* means partial intersection;
* *join* defines the mode of connecting new adjacent faces: *a* means GeomAbs_Arc, *i* means GeomAbs_Intersection.
-**offsetload** loads shape, offset value and, if necessary, a set of faces to remove from the shape. These data are later used by command **offsetperform**.
+**offsetload** loads shape, offset value and, if necessary, a set of faces to remove from the shape. These data are later used by command **offsetperform**.
**offsetonface** indicates the faces of shape (loaded earlier by command **offsetload**) that should be shifted with special offset value. This command is optional. **Warning:** this command should be called only after **offsetload** and it takes effect only if parameter join = GeomAbs_Intersection.
**offsetperform** performs the result of 3d-offset algorithm using the data loaded by previous commands.
@subsubsection occt_2142243456_18694366697112 featprism, featdprism, featrevol, featlf, featrf
-Syntax: featprism shape element skface Dirx Diry Dirz Fuse(0/1/2) Modify(0/1)
+Syntax: featprism shape element skface Dirx Diry Dirz Fuse(0/1/2) Modify(0/1)
featdprism shape face skface angle Fuse(0/1/2) Modify(0/1)
featrevol shape element skface Ox Oy Oz Dx Dy Dz Fuse(0/1/2) Modify(0/1)
featlf shape wire plane DirX DirY DirZ DirX DirY DirZ Fuse(0/1/2) Modify(0/1)
@subsubsection occt_2142243456_18694366697114 deform, nurbsconvert
-Syntax: deform newname name CoeffX CoeffY CoeffZ
+Syntax: deform newname name CoeffX CoeffY CoeffZ
**deform **modifies the shape using the x, y, and z coefficients. You can reduce or magnify the shape in the x,y, and z directions.
@subsubsection occt_2142243456_18694366697121 vtexture
-Syntax vtexture NameOfShape TextureFile
+Syntax vtexture NameOfShape TextureFile
vtexture NameOfShape
vtexture NameOfShape ?
vtexture NameOfShape IdOfTexture
@subsubsection occt_2142243456_18694366697122 vtexscale
-Syntax: vtexscale NameOfShape ScaleU ScaleV
+Syntax: vtexscale NameOfShape ScaleU ScaleV
vtexscale NameOfShape ScaleUV
vtexscale NameOfShape
@subsubsection occt_2142243456_18694366697123 vtexorigin
-Syntax vtexorigin NameOfShape UOrigin VOrigin
+Syntax vtexorigin NameOfShape UOrigin VOrigin
vtexorigin NameOfShape UVOrigin
vtexorigin NameOfShape
@subsubsection occt_2142243456_18694366697124 vtexrepeat
-Syntax vtexrepeat NameOfShape URepeat VRepeat
+Syntax vtexrepeat NameOfShape URepeat VRepeat
vtexrepeat NameOfShape UVRepeat
vtexrepeat NameOfShape
@subsubsection occt_2142243456_18694366697125 vtexdefault
-Syntax vtexdefault NameOfShape
+Syntax vtexdefault NameOfShape
**Vtexdefault **sets or resets the texture mapping default parameters.
@subsubsection occt_2142243456_1866931135821 igesread
-Syntax: igesread file_name result_shape_name [selection]
+Syntax: igesread file_name result_shape_name [selection]
Read an IGES file to an OCCT shape.
This command will interactively ask the user to select a set of entities to be converted:
# translation all roots from file
igesread /disk01/files/model.igs a *
-@subsubsection occt_2142243456_1866931135822 tplosttrim
+@subsubsection occt_2142243456_1866931135822 tplosttrim
-Syntax: tplosttrim [IGES_type]
+Syntax: tplosttrim [IGES_type]
Sometimes the trimming contours of IGES faces (i.e., entity 141 for 143, 142 for 144) can be lost during translation due to fails. This command gives us a number of lost trims and the number of corresponding IGES entities.
It outputs the rank and numbers of faces that lost their trims and their numbers for each type (143, 144, 510) and their total number. If a face lost several of its trims it is output only once.
@subsubsection occt_2142243456_1866931135823 brepiges
-Syntax: brepiges shape_name filename.igs
+Syntax: brepiges shape_name filename.igs
Writes an OCCT shape to an IGES file.
**Example**
-
+
# write shape with name aa to IGES file
brepiges aa /disk1/tmp/aaa.igs
== unit (write) : MM
-== mode write : Faces
-== To modifiy : command param
+== mode write : Faces
+== To modifiy : command param
== 1 Shapes written, giving 345 Entities
-== Now, to write a file, command : writeall filename
-== Output on file : /disk1/tmp/aaa.igs
-== Write OK
+== Now, to write a file, command : writeall filename
+== Output on file : /disk1/tmp/aaa.igs
+== Write OK
@subsubsection occt_2142243456_1866931135831 stepread
-Syntax: stepread file_name result_shape_name [selection]
+Syntax: stepread file_name result_shape_name [selection]
Read a STEP file to an OCCT shape.
This command will interactively ask the user to select a set of entities to be converted:
# translation all roots from file
stepread /disk01/files/model.stp a *
-@subsubsection occt_2142243456_1866931135832 stepwrite
+@subsubsection occt_2142243456_1866931135832 stepwrite
-Syntax: stepwrite mode shape_name file_name
+Syntax: stepwrite mode shape_name file_name
Writes an OCCT shape to a STEP file.
The available modes are the following:
- 0 or ‘a’ - ;as is; mode – mode is selected automatically depending on type & geometry of the shape
- 1 or ‘m’ - manifold_solid_brep or brep_with_voids
- 2 or ‘f’ - faceted_brep
- 3 or ‘w’ - geometric_curve_set
- 4 or ‘s’ - shell_based_surface_model
+ 0 or ‘a’ - ;as is; mode – mode is selected automatically depending on type & geometry of the shape
+ 1 or ‘m’ - manifold_solid_brep or brep_with_voids
+ 2 or ‘f’ - faceted_brep
+ 3 or ‘w’ - geometric_curve_set
+ 4 or ‘s’ - shell_based_surface_model
For further information see ;STEP FORMAT User’s Guide ;.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135841 count
-Syntax: count counter [selection]
+Syntax: count counter [selection]
Is used to calculate statistics on the entities in the model.
Gives us a count of entities.
@subsubsection occt_2142243456_1866931135842 data
-Syntax: data symbol
+Syntax: data symbol
Is used to obtain general statistics on the loaded data.
Information printed by this command depends on the symbol specified:
@subsubsection occt_2142243456_1866931135843 elabel
-Syntax: elabel num
+Syntax: elabel num
Entities in the IGES and STEP files are numbered in the succeeding order. An entity can be identified either by its number or by its label. Label is the letter ‘#'(for STEP, for IGES use ‘D’) followed by the rank. This command gives us a label for an entity with a known number.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135844 entity
-Syntax: entity #(D)_or_num level_of_information
+Syntax: entity #(D)_or_num level_of_information
The content of an IGES or STEP entity can be obtained by using this command.
Entity can be determined by its number or label.
@subsubsection occt_2142243456_1866931135845 enum
-Syntax: enum #(D)
+Syntax: enum #(D)
Prints a number for the entity with a given label.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135846 estatus
-Syntax: estatus #(D)_or_num
+Syntax: estatus #(D)_or_num
The list of entities referenced by a given entity and the list of entities referencing to it can be obtained by this command.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135847 fromshape
-Syntax: fromshape shape_name
+Syntax: fromshape shape_name
Gives us the number of an IGES or STEP entity corresponding to an OCCT shape. If no corresponding entity can be found and if OCCT shape is a compound the command explodes it to subshapes and try to find corresponding entities for them.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135848 givecount
-Syntax: givecount selection_name [selection_name]
+Syntax: givecount selection_name [selection_name]
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135849 givelist
-Syntax: givelist selection_name
+Syntax: givelist selection_name
Prints a list of a subset of loaded entities defined by the selection argument:
@subsubsection occt_2142243456_18669311358410 listcount
-Syntax: listcount counter [selection ...]
+Syntax: listcount counter [selection ...]
Prints a list of entities per each type matching the criteria defined by arguments.
Optional selection argument, if specified, defines a subset of entities, which are to be taken into account. Argument counter should be one of the currently defined counters:
@subsubsection occt_2142243456_18669311358411 listitems
-Syntax: listitems
+Syntax: listitems
This command prints a list of objects (counters, selections etc.) defined in the current session.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358412 listtypes
-Syntax: listtypes [selection_name ...]
+Syntax: listtypes [selection_name ...]
Gives a list of entity types which were encountered in the last loaded file (with a number of entities of each type). The list can be shown not for all entities but for a subset of them. This subset is defined by an optional selection argument.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358413 newmodel
-Syntax: newmodel
+Syntax: newmodel
Clears the current model.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358414 param
-Syntax: param [parameter] [value]
+Syntax: param [parameter] [value]
This command is used to manage translation parameters.
Command without arguments gives us a full list of parameters with current values.
@subsubsection occt_2142243456_18669311358415 sumcount
-Syntax: sumcount counter [selection ...]
+Syntax: sumcount counter [selection ...]
Prints only a number of entities per each type matching the criteria defined by arguments.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358416 tpclear
-Syntax: tpclear
+Syntax: tpclear
Clears the map of correspondences between IGES or STEP entities and OCCT shapes.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358417 tpdraw
-Syntax: tpdraw #(D)_or_num
+Syntax: tpdraw #(D)_or_num
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358418 tpent
-Syntax: tpent #(D)_or_num
+Syntax: tpent #(D)_or_num
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358419 tpstat
-Syntax: tpstat [*|?]symbol [selection]
+Syntax: tpstat [*|?]symbol [selection]
Gives all statistics on the last transfer, including the list of transferred entities with mapping from IGES or STEP to OCCT types, as well as fail and warning messages. The parameter *symbol *defines what information will be printed:
@subsubsection occt_2142243456_18669311358420 xload
-Syntax: xload file_name
+Syntax: xload file_name
This command loads an IGES or STEP file into memory (i.e. to fill the model with data from the file) without creation of an OCCT shape.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135861 ReadIges
-Syntax: ReadIges document file_name
+Syntax: ReadIges document file_name
Reads information from an IGES file to an XCAF document.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135862 ReadStep
-Syntax: ReadStep document file_name
+Syntax: ReadStep document file_name
Reads information from a STEP file to an XCAF document.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135863 WriteIges
-Syntax: WriteIges document file_name
+Syntax: WriteIges document file_name
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135864 WriteStep
-Syntax: WriteStep document file_name
+Syntax: WriteStep document file_name
Writes information from an XCAF document to a STEP file.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135865 XFileCur
-Syntax: XFileCur
+Syntax: XFileCur
Returns the name of file which is set as the current one in the Draw session.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135866 XFileList
-Syntax: XFileList
+Syntax: XFileList
-Returns a list all files that were transferred by the last transfer. This command is meant (assigned) for the assemble step file.
+Returns a list all files that were transferred by the last transfer. This command is meant (assigned) for the assemble step file.
<h5>Example</h5>
XFileList
@subsubsection occt_2142243456_1866931135867 XFileSet
-Syntax: XFileSet filename
+Syntax: XFileSet filename
Sets the current file taking it from the components list of the assemble file.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135868 XFromShape
-Syntax: XFromShape shape
+Syntax: XFromShape shape
This command is similar to command *fromshape* (see above) but gives additional information about the name of file. It is useful in the case when a shape was translated from several files.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135871 XNewDoc
-Syntax: XNewDoc document
+Syntax: XNewDoc document
Creates a new XCAF document.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135872 XShow
-Syntax: XShow document [ label1 … ]
+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.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135873 XStat
-Syntax: XStat document
+Syntax: XStat document
Prints common information from an XCAF document.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135874 XWdump
-Syntax: XWdump document filename
+Syntax: XWdump document filename
Saves the contents of the viewer window as an image (XWD, png or BMP file).
filename must have a corresponding extention.
@subsubsection occt_2142243456_1866931135875 Xdump
-Syntax: Xdump document [int deep {0|1}]
+Syntax: Xdump document [int deep {0|1}]
Prints information about the tree structure of the document. If parameter 1 is given, then the tree is printed with a link to shapes.
<h5>Example</h5>
== ASSEMBLY 0:1:1:4 PLATE(0xe8387780)
== ASSEMBLY 0:1:1:5 ROD(0xe8475418)
== ASSEMBLY 0:1:1:6 AS1(0xe8476968)
-== ASSEMBLY 0:1:1:7 L-BRACKET-ASSEMBLY(0xe8476230)
-== ASSEMBLY 0:1:1:1 L-BRACKET(0xe8180448)
-== ASSEMBLY 0:1:1:8 NUT-BOLT-ASSEMBLY(0xe8475ec0)
-== ASSEMBLY 0:1:1:2 NUT(0xe82151e8)
-== ASSEMBLY 0:1:1:3 BOLT(0xe829b000)
+== ASSEMBLY 0:1:1:7 L-BRACKET-ASSEMBLY(0xe8476230)
+== ASSEMBLY 0:1:1:1 L-BRACKET(0xe8180448)
+== ASSEMBLY 0:1:1:8 NUT-BOLT-ASSEMBLY(0xe8475ec0)
+== ASSEMBLY 0:1:1:2 NUT(0xe82151e8)
+== ASSEMBLY 0:1:1:3 BOLT(0xe829b000)
etc.
@subsubsection occt_2142243456_1866931135881 XAddComponent
-Syntax: XAddComponent document label shape
+Syntax: XAddComponent document label shape
Adds a component shape to assembly.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135882 XAddShape
-Syntax: XAddShape document shape [makeassembly=1]
+Syntax: XAddShape document shape [makeassembly=1]
Adds a shape (or an assembly) to a document. If this shape already exists in the document, then prints the label which points to it. By default, a new shape is added as an assembly (i.e. last parameter 1), otherwise it is necessary to pass 0 as the last parameter.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135883 XFindComponent
-Syntax: XFindComponent document shape
+Syntax: XFindComponent document shape
Prints a sequence of labels of the assembly path.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135884 XFindShape
-Syntax: XFindShape document shape
+Syntax: XFindShape document shape
Finds and prints a label with an indicated top-level shape.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135885 XGetFreeShapes
-Syntax: XGetFreeShapes document [shape_prefix]
+Syntax: 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
@subsubsection occt_2142243456_1866931135886 XGetOneShape
-Syntax: XGetOneShape shape document
+Syntax: XGetOneShape shape document
Creates one DRAW shape for all free shapes from a document.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135887 XGetReferredShape
-Syntax: XGetReferredShape document label
+Syntax: XGetReferredShape document label
Prints a label that contains a top-level shape that corresponds to a shape at a given label.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135888 XGetShape
-Syntax: XGetShape result document label
+Syntax: XGetShape result document label
Puts a shape from the indicated label in document to result.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135889 XGetTopLevelShapes
-Syntax: XGetTopLevelShapes document
+Syntax: XGetTopLevelShapes document
Prints labels that contain top-level shapes.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358810 XLabelInfo
-Syntax: XLabelInfo document label
+Syntax: XLabelInfo document label
Prints information about a shape, stored at an indicated label.
**Example**
-
+
XLabelInfo D 0:1:1:6
== There are TopLevel Shape. There are an Assembly. This Shape don’t used.
@subsubsection occt_2142243456_18669311358811 XNewShape
-Syntax: XNewShape document
+Syntax: XNewShape document
Creates a new empty top-level shape.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358812 XRemoveComponent
-Syntax: XRemoveComponent document label
+Syntax: XRemoveComponent document label
Removes a component from the components label.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358813 XRemoveShape
-Syntax: XRemoveShape document label
+Syntax: XRemoveShape document label
Removes a shape from a document (by it’s label).
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358814 XSetShape
-Syntax: XSetShape document label shape
+Syntax: XSetShape document label shape
Sets a shape at the indicated label.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135891 XAddColor
-Syntax: XAddColor document R G B
+Syntax: XAddColor document R G B
Adds color in document to the color table. Parameters R,G,B are real.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135892 XFindColor
-Syntax: XFindColor document R G B
+Syntax: XFindColor document R G B
Finds a label where the indicated color is situated.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135893 XGetAllColors
-Syntax: XGetAllColors document
+Syntax: XGetAllColors document
Prints all colors that are defined in the document.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135894 XGetColor
-Syntax: XGetColor document label
+Syntax: XGetColor document label
Returns a color defined at the indicated label from the color table.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135895 XGetObjVisibility
-Syntax: XGetObjVisibility document {label|shape}
+Syntax: XGetObjVisibility document {label|shape}
Returns the visibility of a shape.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135896 XGetShapeColor
-Syntax: XGetShapeColor document label colortype(s|c)
+Syntax: XGetShapeColor document label colortype(s|c)
Returns the color defined by label. If colortype=’s’ – returns surface color, else – returns curve color.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135897 XRemoveColor
-Syntax: XRemoveColor document label
+Syntax: XRemoveColor document label
Removes a color from the color table in a document.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135898 XSetColor
-Syntax: XSetColor document {label|shape} R G B
+Syntax: XSetColor document {label|shape} R G B
Sets an RGB color to a shape given by label.
<h5>Example</h5>
@subsubsection occt_2142243456_1866931135899 XSetObjVisibility
-Syntax: XSetObjVisibility document {label|shape} {0|1}
+Syntax: XSetObjVisibility document {label|shape} {0|1}
Sets the visibility of a shape.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358910 XUnsetColor
-Syntax: XUnsetColor document {label|shape} colortype
+Syntax: XUnsetColor document {label|shape} colortype
Unset a color given??? type (‘s’ or ‘c’) for the indicated shape.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358101 XAddLayer
-Syntax: XAddLayer document layer
+Syntax: XAddLayer document layer
Adds a new layer in an XCAF document. layer - name of new layer (string).
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358102 XFindLayer
-Syntax: XFindLayer document layer
+Syntax: XFindLayer document layer
Prints a label where a layer is situated.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358103 XGetAllLayers
-Syntax: XGetAllLayers document
+Syntax: XGetAllLayers document
Prints all layers in an XCAF document.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358104 XGetLayers
-Syntax: XGetLayers document {shape|label}
+Syntax: XGetLayers document {shape|label}
Returns names of layers, which are pointed to by links of an indicated shape.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358105 XGetOneLayer
-Syntax: XGetOneLayer document label
+Syntax: XGetOneLayer document label
Prints the name of a layer at a given label.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358106 XIsVisible
-Syntax: XIsVisible document {label|layer}
+Syntax: XIsVisible document {label|layer}
Returns 1 if the indicated layer is visible, else returns 0.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358107 XRemoveAllLayers
-Syntax: XRemoveAllLayers document
+Syntax: XRemoveAllLayers document
Removes all layers from an XCAF document.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358108 XRemoveLayer
-Syntax: XRemoveLayer document {label|layer}
+Syntax: XRemoveLayer document {label|layer}
Removes the indicated layer from an XCAF document.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358109 XSetLayer
-Syntax: XSetLayer document {shape|label} layer
- [shape_in_one_layer {0|1}]
+Syntax: XSetLayer document {shape|label} layer
+ [shape_in_one_layer {0|1}]
Sets a reference between a shape and a layer (adds a layer if it is necessary).
Parameter shape_in_one_layer shows whether a shape could be in a number of layers or only in one (0 by default).
@subsubsection occt_2142243456_186693113581010 XSetVisibility
-Syntax: XSetVisibility document {label|layer} isvisible {0|1}
+Syntax: XSetVisibility document {label|layer} isvisible {0|1}
Sets the visibility of a layer.
<h5>Example</h5>
@subsubsection occt_2142243456_186693113581011 XUnSetAllLayers
-Syntax: XUnSetAllLayers document {label|shape}
+Syntax: XUnSetAllLayers document {label|shape}
Unsets a shape from all layers.
<h5>Example</h5>
@subsubsection occt_2142243456_186693113581012 XUnSetLayer
-Syntax: XUnSetLayer document {label|shape} layer
+Syntax: XUnSetLayer document {label|shape} layer
Unsets a shape from the indicated layer.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358111 XCheckProps
-Syntax: XCheckProps document [ {0|deflection} [shape|label] ]
+Syntax: XCheckProps document [ {0|deflection} [shape|label] ]
Gets properties for a given shape (volume, area and centroid) 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 treated as a deflection. If the deflection is positive the computation is done by triangulations, if it is negative – meshing is forced.
<h5>Example</h5>
# check properties for shapes at label 0:1:1:1 from
# document using standard Open CASCADE Technology tools
XCheckProps D 0 0:1:1:1
-== Label 0:1:1:1 ;L-BRACKET*
-== Area defect: -0.0 ( 0%)
-== Volume defect: 0.0 ( 0%)
-== CG defect: dX=-0.000, dY=0.000, dZ=0.000
+== Label 0:1:1:1 ;L-BRACKET*
+== Area defect: -0.0 ( 0%)
+== Volume defect: 0.0 ( 0%)
+== CG defect: dX=-0.000, dY=0.000, dZ=0.000
@subsubsection occt_2142243456_18669311358112 XGetArea
-Syntax: XGetArea document {shape|label}
+Syntax: XGetArea document {shape|label}
Returns the area of a given shape.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358113 XGetCentroid
-Syntax: XGetCentroid document {shape|label}
+Syntax: XGetCentroid document {shape|label}
Returns the center of gravity coordinates of a given shape.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358114 XGetVolume
-Syntax: XGetVolume document {shape|label}
+Syntax: XGetVolume document {shape|label}
Returns the volume of a given shape.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358115 XSetArea
-Syntax: XSetArea document {shape|label} area
+Syntax: XSetArea document {shape|label} area
Sets new area to attribute list ??? given shape.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358116 XSetCentroid
-Syntax: XSetCentroid document {shape|label} x y z
+Syntax: XSetCentroid document {shape|label} x y z
-Sets new center of gravity to the attribute list ??? given shape.
+Sets new center of gravity to the attribute list ??? given shape.
<h5>Example</h5>
XSetCentroid D 0:1:1:1 0. 0. 100.
@subsubsection occt_2142243456_18669311358117 XSetMaterial
-Syntax: XSetMaterial document {shape|label} name
- density(g/cu sm)
+Syntax: XSetMaterial document {shape|label} name
+ density(g/cu sm)
Adds a new label with material into the material table in a document, and adds a link to this material to the attribute list of agiven shape or a given label. The last parameter sets the density of a pointed material.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358118 XSetVolume
-Syntax: XSetVolume document {shape|label} volume
+Syntax: XSetVolume document {shape|label} volume
Sets new volume to the attribute list ??? given shape.
<h5>Example</h5>
@subsubsection occt_2142243456_18669311358119 XShapeMassProps
-Syntax: XShapeMassProps document [ deflection [{shape|label}] ]
+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.
<h5>Example</h5>
== Shape from label : 0:1:1:1
== Mass = 193.71681469282299
== CenterOfGravity X = 14.594564763807696,Y =
- 20.20271885211281,Z = 49.999999385313245
+ 20.20271885211281,Z = 49.999999385313245
== Shape from label : 0:1:1:2 not have a mass
etc.
@subsubsection occt_2142243456_186693113581110 XShapeVolume
-Syntax: XShapeVolume shape deflection
+Syntax: XShapeVolume shape deflection
Calculates the real volume of a pointed shape with a given deflection.
<h5>Example</h5>
@subsubsection occt_2142243456_1672096717111 bsplres
-Syntax: bsplres result shape tol3d tol2d reqdegree reqnbsegments continuity3d continuity2d PriorDeg RationalConvert
+Syntax: bsplres result shape tol3d tol2d reqdegree reqnbsegments continuity3d continuity2d PriorDeg RationalConvert
Performs approximations of a given shape (BSpline curves and surfaces or other surfaces) to BSpline with given required parameters. The specified continuity can be reduced if the approximation with a specified continuity was not done successfully. Results are put into the shape, which is given as a parameter result. For a more detailed description see the ShapeHealing User’s Guide (operator: BSplineRestriction).
@subsubsection occt_2142243456_1672096717112 checkfclass2d
-Syntax: checkfclass2d face ucoord vcoord
+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.
<h5>Example</h5>
@subsubsection occt_2142243456_1672096717113 checkoverlapedges
-Syntax: checkoverlapedges edge1 edge2 [toler domaindist]
+Syntax: checkoverlapedges edge1 edge2 [toler domaindist]
Checks the overlapping of two given edges. If the distance between two edges is less than the given value of tolerance then edges are overlapped. Parameter domaindist sets length of part of edges on which edges are overlapped.
<h5>Example</h5>
@subsubsection occt_2142243456_1672096717114 comtol
-Syntax: comptol shape [nbpoints] [prefix]
+Syntax: comptol shape [nbpoints] [prefix]
Compares the real value of tolerance on curves with the value calculated by standard (using 23 points). The maximal value of deviation of 3d curve from pcurve at given simple points is taken as a real value (371 is by default). Command returns the maximal, minimal and average value of tolerance for all edges and difference between real values and set values. Edges with the maximal value of tolerance and relation will be saved if the ‘prefix’ parameter is given.
**Example**
-
+
comptol h 871 t
== Edges tolerance computed by 871 points:
== MAX=8.0001130696523449e-008 AVG=6.349346868091096e-009
- MIN=0
+ MIN=0
== Relation real tolerance / tolerance set in edge
== MAX=0.80001130696523448 AVG=0.06349345591805905 MIN=0
== Edge with max tolerance saved to t_edge_tol
@subsubsection occt_2142243456_1672096717115 convtorevol
-Syntax: convtorevol result shape
+Syntax: convtorevol result shape
Converts all elementary surfaces of a given shape into surfaces of revolution.
Results are put into the shape, which is given as theresult parameter.
@subsubsection occt_2142243456_1672096717116 directfaces
-Syntax: directfaces result shape
+Syntax: directfaces result shape
Converts indirect surfaces and returns the results into the shape, which is given as the result parameter.
<h5>Example</h5>
@subsubsection occt_2142243456_1672096717117 expshape
-Syntax: expshape shape maxdegree maxseg
+Syntax: expshape shape maxdegree maxseg
Gives statistics for a given shape. This test command is working with Bezier and BSpline entities.
<h5>Example</h5>
@subsubsection occt_2142243456_1672096717118 fixsmall
-Syntax: fixsmall result shape [toler=1.]
+Syntax: fixsmall result shape [toler=1.]
Fixes small edges in given shape by merging adjacent edges with agiven tolerance. Results are put into the shape, which is given as the result parameter.
<h5>Example</h5>
@subsubsection occt_2142243456_1672096717119 fixsmalledges
-Syntax: fixsmalledges result shape [toler mode maxangle]
+Syntax: fixsmalledges result shape [toler mode maxangle]
-Searches at least one small edge at a given shape. If such edges have been found, then small edges are merged with a given tolerance. If parameter mode is equal to Standard_True (can be given any values, except 2), then small edges, which can not be merged, are removed, otherwise they are to be kept (Standard_False is used by default). Parameter maxangle sets a maximum possible angle for merging two adjacent edges, by default no limit angle is applied (-1).Results are put into the shape, which is given as parameter result.
+Searches at least one small edge at a given shape. If such edges have been found, then small edges are merged with a given tolerance. If parameter mode is equal to Standard_True (can be given any values, except 2), then small edges, which can not be merged, are removed, otherwise they are to be kept (Standard_False is used by default). Parameter maxangle sets a maximum possible angle for merging two adjacent edges, by default no limit angle is applied (-1).Results are put into the shape, which is given as parameter result.
<h5>Example</h5>
fixsmalledges r a 0.1 1
@subsubsection occt_2142243456_16720967171110 fixshape
-Syntax: fixshape result shape [preci [maxpreci]] [{switches}]
+Syntax: fixshape result shape [preci [maxpreci]] [{switches}]
Performs fixes of all sub-shapes (such as Solids, Shells, Faces, Wires and Edges) of a given shape. Parameter preci sets a basic precision value, maxpreci sets the maximal allowed tolerance. Results are put into the shape, which is given as parameter result.
{switches} allows to tune parameters of ShapeFix
@subsubsection occt_2142243456_16720967171111 fixwgaps
-Syntax: fixwgaps result shape [toler=0]
+Syntax: fixwgaps result shape [toler=0]
Fixes gaps between ends of curves of adjacent edges (both 3d and pcurves) in wires in a given shape with a given tolerance. Results are put into the shape, which is given as parameter result.
<h5>Example</h5>
@subsubsection occt_2142243456_16720967171112 offsetcurve, offset2dcurve
-Syntax: offsetcurve result curve offset direction(as point)
- offset2dcurve result curve offset
+Syntax: offsetcurve result curve offset direction(as point)
+ offset2dcurve result curve offset
-Both commands are intended to create a new offset curve by copying the given curve to distance, given by parameter offset. Parameter direction defines direction of the offset curve. It is created as a point. For correct work of these commands the direction of normal of the offset curve must be perpendicular to the plane, the basis curve is located there. Results are put into the curve, which is given as parameter result. **offsetcurve **works with the curve in 3d space, **offset2dcurve **in 2d space accordingly.
+Both commands are intended to create a new offset curve by copying the given curve to distance, given by parameter offset. Parameter direction defines direction of the offset curve. It is created as a point. For correct work of these commands the direction of normal of the offset curve must be perpendicular to the plane, the basis curve is located there. Results are put into the curve, which is given as parameter result. **offsetcurve **works with the curve in 3d space, **offset2dcurve **in 2d space accordingly.
<h5>Example</h5>
point pp 10 10 10
@subsubsection occt_2142243456_16720967171113 projcurve
-Syntax: projcurve edge|curve3d|curve3d first last X Y Z
+Syntax: projcurve edge|curve3d|curve3d first last X Y Z
**projcurve **returns the projection of a given point on a given curve. The curve may be defined by three ways: by giving the edge name, giving the 3D curve and by giving the unlimited curve and limiting it by pointing its start and finish values.
**Example**
-
+
projcurve k_1 0 1 5
==Edge k_1 Params from 0 to 1.3
-==Precision (BRepBuilderAPI) : 9.9999999999999995e-008 ==Projection : 0 1 5
-==Result : 0 1.1000000000000001 0
-==Param = -0.20000000000000001 Gap = 5.0009999000199947
+==Precision (BRepBuilderAPI) : 9.9999999999999995e-008 ==Projection : 0 1 5
+==Result : 0 1.1000000000000001 0
+==Param = -0.20000000000000001 Gap = 5.0009999000199947
@subsubsection occt_2142243456_16720967171114 projface
-Syntax: projface face X Y [Z]
+Syntax: projface face X Y [Z]
Returns the projection of a given point to a given face in 2d or 3d space. If two coordinates (2d space) are given then returns coordinates projection of this point in 3d space and vice versa.
<h5>Example</h5>
projface a_1 10.0 0.0
-== Point UV U = 10 V = 0
-== = proj X = -116 Y = -45 Z = 0
+== Point UV U = 10 V = 0
+== = proj X = -116 Y = -45 Z = 0
@subsubsection occt_2142243456_16720967171115 scaleshape
-Syntax: scaleshape result shape scale
+Syntax: scaleshape result shape scale
<h5>Example</h5>
@subsubsection occt_2142243456_16720967171116 settolerance
-Syntax: settolerance shape [mode=v-e-w-f-a] val(fix value) or
- tolmin tolmax
+Syntax: settolerance shape [mode=v-e-w-f-a] val(fix value) or
+ tolmin tolmax
Sets new values of tolerance for a given shape. If the given second parameter (mode) is given, then the atolerance value is set only for these sub shapes.
<h5>Example</h5>
@subsubsection occt_2142243456_16720967171117 splitface
-Syntax: splitface result face [u usplit1 usplit2...] [v vsplit1 vsplit2 ...]
+Syntax: splitface result face [u usplit1 usplit2...] [v vsplit1 vsplit2 ...]
Splits a given face in parametric space and puts the result into the given parameter result.
Returns the status of split face.
# split face f by parameter u = 5
splitface r f u 5
-== Splitting by U: ,5
-== Status: DONE1
+== Splitting by U: ,5
+== Status: DONE1
@subsubsection occt_2142243456_16720967171118 statshape
-Syntax: statshape shape [particul]
+Syntax: statshape shape [particul]
-Returns the number of sub-shapes, which compose the given shape. For example, the number of solids, number of faces etc. It also returns the number of geometrical objects or sub-shapes with a specified type, example, number of free faces, number of C0 surfaces. The last parameter becomes out of date.
+Returns the number of sub-shapes, which compose the given shape. For example, the number of solids, number of faces etc. It also returns the number of geometrical objects or sub-shapes with a specified type, example, number of free faces, number of C0 surfaces. The last parameter becomes out of date.
<h5>Example</h5>
statshape a
-== Count Item
-== ----- ----
-== 402 Edge (oriented)
-== 402 Edge (Shared)
-== 74 Face
-== 74 Face (Free)
-== 804 Vertex (Oriented)
-== 402 Vertex (Shared)
-== 78 Wire
-== 4 Face with more than one wire
-== 34 bspsur: BSplineSurface
+== Count Item
+== ----- ----
+== 402 Edge (oriented)
+== 402 Edge (Shared)
+== 74 Face
+== 74 Face (Free)
+== 804 Vertex (Oriented)
+== 402 Vertex (Shared)
+== 78 Wire
+== 4 Face with more than one wire
+== 34 bspsur: BSplineSurface
@subsubsection occt_2142243456_16720967171119 tolerance
-Syntax: tolerance shape [mode:D v e f c] [tolmin tolmax:real]
+Syntax: tolerance shape [mode:D v e f c] [tolmin tolmax:real]
-Returns tolerance (maximal, avg and minimal values) of all given shapes and tolerance of their Faces, Edges and Vertices. If parameter tolmin or tolmax or both of them are given, then sub-shapes are returned as a result of analys of this shape, which satisfy the given tolerances. If a particular value of entity (all shapes (D) (v) vertices (e) edges (f) faces (c) combined (faces)) is given as the second parameter then only this group will be analyzed for tolerance.
+Returns tolerance (maximal, avg and minimal values) of all given shapes and tolerance of their Faces, Edges and Vertices. If parameter tolmin or tolmax or both of them are given, then sub-shapes are returned as a result of analys of this shape, which satisfy the given tolerances. If a particular value of entity (all shapes (D) (v) vertices (e) edges (f) faces (c) combined (faces)) is given as the second parameter then only this group will be analyzed for tolerance.
<h5>Example</h5>
tolerance a
== Tolerance MAX=0.31512672416608001 AVG=0.14901359484722074 MIN=9.9999999999999995e-08
-== FACE : MAX=9.9999999999999995e-08 AVG=9.9999999999999995e-08 MIN=9.9999999999999995e-08
-== EDGE : MAX=0.31512672416608001 AVG=0.098691334511810405 MIN=9.9999999999999995e-08
-== VERTEX : MAX=0.31512672416608001 AVG=0.189076074499648 MIN=9.9999999999999995e-08
+== FACE : MAX=9.9999999999999995e-08 AVG=9.9999999999999995e-08 MIN=9.9999999999999995e-08
+== EDGE : MAX=0.31512672416608001 AVG=0.098691334511810405 MIN=9.9999999999999995e-08
+== VERTEX : MAX=0.31512672416608001 AVG=0.189076074499648 MIN=9.9999999999999995e-08
tolerance a v 0.1 0.001
-== Analysing Vertices gives 6 Shapes between tol1=0.10000000000000001 and tol2=0.001 , named tol_1 to tol_6
+== Analysing Vertices gives 6 Shapes between tol1=0.10000000000000001 and tol2=0.001 , named tol_1 to tol_6
@subsubsection occt_2142243456_1672096717121 DT_ClosedSplit
-Syntax: DT_ClosedSplit result shape
+Syntax: 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.
@subsubsection occt_2142243456_1672096717122 DT_ShapeConvert, DT_ShapeConvertRev
-Syntax: DT_ShapeConvert result shape convert2d convert3d
- DT_ShapeConvertRev result shape convert2d convert3d
+Syntax: DT_ShapeConvert result shape convert2d convert3d
+ DT_ShapeConvertRev result shape convert2d convert3d
Both commands are intended for the conversion of 3D, 2D curves to Bezier curves and surfaces to Bezier based surfaces. Parameters convert2d and convert3d take on a value 0 or 1. If the given value is 1, then the conversion will be performed, otherwise it will not be performed. The results are put into the shape, which is given as parameter Result. Command **DT_ShapeConvertRev **differs from **DT_ShapeConvert **by converting all elementary surfaces into surfaces of revolution first.
<h5>Example</h5>
@subsubsection occt_2142243456_1672096717123 DT_ShapeDivide
-Syntax: DT_ShapeDivide result shape tol
+Syntax: DT_ShapeDivide result shape tol
-Divides the shape with C1 criterion and returns the result of geometry conversion of a given shape into the shape, which is given as parameter result. This command illustrates how class ShapeUpgrade_ShapeDivideContinuity works. This class allows to convert geometry with a continuity less than the specified continuity to geometry with target continuity. If conversion is not possible then the geometrical object is split into several ones, which satisfy the given tolerance. It also returns the status shape splitting:
-OK : no splitting was done
+Divides the shape with C1 criterion and returns the result of geometry conversion of a given shape into the shape, which is given as parameter result. This command illustrates how class ShapeUpgrade_ShapeDivideContinuity works. This class allows to convert geometry with a continuity less than the specified continuity to geometry with target continuity. If conversion is not possible then the geometrical object is split into several ones, which satisfy the given tolerance. It also returns the status shape splitting:
+OK : no splitting was done
Done1 : Some edges were split
Done2 : Surface was split
-Fail1 : Some errors occurred
+Fail1 : Some errors occurred
<h5>Example</h5>
DT_ShapeDivide r a 0.001
@subsubsection occt_2142243456_1672096717124 DT_SplitAngle
-Syntax: DT_SplitAngle result shape [MaxAngle=95]
+Syntax: DT_SplitAngle result shape [MaxAngle=95]
Works with all revolved surfaces, like cylinders, surfaces of revolution etc. This command divides given revolved surfaces into segments so that each resulting segment covers not more than the given MaxAngle degrees and puts the result of splitting into the shape, which is given as parameter result. Values of returned status are given above.
This command illustrates how class ShapeUpgrade_ShapeDivideAngle works.
@subsubsection occt_2142243456_1672096717125 DT_SplitCurve
-Syntax: DT_SplitCurve curve tol split(0|1)
+Syntax: DT_SplitCurve curve tol split(0|1)
-Divides the 3d curve with C1 criterion and returns the result of splitting of the given curve into a new curve. If the curve had been divided by segments, then each segment is put to an individual result. This command can correct a given curve at a knot with the given tolerance, if it is impossible, then the given surface is split at that knot. If the last parameter is 1, then 5 knots are added at the given curve, and its surface is split by segments, but this will be performed not for all parametric spaces.
+Divides the 3d curve with C1 criterion and returns the result of splitting of the given curve into a new curve. If the curve had been divided by segments, then each segment is put to an individual result. This command can correct a given curve at a knot with the given tolerance, if it is impossible, then the given surface is split at that knot. If the last parameter is 1, then 5 knots are added at the given curve, and its surface is split by segments, but this will be performed not for all parametric spaces.
<h5>Example</h5>
DT_SplitCurve r c
@subsubsection occt_2142243456_1672096717126 DT_SplitCurve2d
-Syntax: DT_SplitCurve2d Curve Tol Split(0/1)
+Syntax: DT_SplitCurve2d Curve Tol Split(0/1)
Works just as DT_SplitCurve (see above), only with 2d curve.
<h5>Example</h5>
@subsubsection occt_2142243456_1672096717127 DT_SplitSurface
-Syntax: DT_SplitSurface result Surface|GridSurf tol split(0|1)
+Syntax: DT_SplitSurface result Surface|GridSurf tol split(0|1)
-Divides surface with C1 criterion and returns the result of splitting of a given surface into surface, which is given as parameter result. If the surface has been divided into segments, then each segment is put to an individual result. This command can correct a given C0 surface at a knot with a given tolerance, if it is impossible, then the given surface is split at that knot. If the last parameter is 1, then 5 knots are added to the given surface, and its surface is split by segments, but this will be performed not for all parametric spaces.
+Divides surface with C1 criterion and returns the result of splitting of a given surface into surface, which is given as parameter result. If the surface has been divided into segments, then each segment is put to an individual result. This command can correct a given C0 surface at a knot with a given tolerance, if it is impossible, then the given surface is split at that knot. If the last parameter is 1, then 5 knots are added to the given surface, and its surface is split by segments, but this will be performed not for all parametric spaces.
**Example**
-
+
# split surface with name ‘su’
DT_SplitSurface res su 0.1 1
== single surf
@subsubsection occt_2142243456_1672096717128 DT_ToBspl
-Syntax: DT_ToBspl result shape
+Syntax: DT_ToBspl result shape
Converts a surface of linear extrusion, revolution and offset surfaces into BSpline surfaces. Returns the result into the shape, which is given as parameter result.
**Example**
-
+
DT_ToBspl res sh
-== error = 5.20375663162094e-08 spans = 10
-== Surface is aproximated with continuity 2
+== error = 5.20375663162094e-08 spans = 10
+== Surface is aproximated with continuity 2
@section occt_2142243456_1640587828 Performance evaluation commands
@subsubsection occt_2142243456_16405878281.1 VDrawSphere
-Syntax: vdrawsphere shapeName Fineness [X=0.0 Y=0.0 Z=0.0] [Radius=100.0] [ToEnableVBO=1] [NumberOfViewerUpdate=1] [ToShowEdges=0]
+Syntax: vdrawsphere shapeName Fineness [X=0.0 Y=0.0 Z=0.0] [Radius=100.0] [ToEnableVBO=1] [NumberOfViewerUpdate=1] [ToShowEdges=0]
Calculates and displays in a given number of steps a sphere with given coordinates, radius and fineness. Returns the information about the properties of the sphere, the time and the amount of memory required to build it.
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);
...
}
**Examples** (file MyDrawPlugin):
! Hierarchy of plug-ins
-ALL : ADVMODELING, MESHING
-DEFAULT : MESHING
-ADVMODELING : ADVSURF, ADVCURV
+ALL : ADVMODELING, MESHING
+DEFAULT : MESHING
+ADVMODELING : ADVSURF, ADVCURV
! Mapping from naming to toolkits (libraries)
-ADVSURF : TKMyAdvSurf
-ADVCURV : TKMyAdvCurv
-MESHING : TKMyMesh
+ADVSURF : TKMyAdvSurf
+ADVCURV : TKMyAdvCurv
+MESHING : TKMyMesh
For other examples of the plug-in resource file refer to the *;Plug-in resource file;* chapter above or to the $CASROOT/src/DrawPlugin file shipped with Open CASCADE Technology.
Foundation Classes provide a variety of general-purpose services such as automated dynamic memory management (manipulation of objects by handle), collections, exception handling, genericity by downcasting and plug-in creation.
Foundation Classes include the following:
-Root Classes
-------------
+### Root Classes
Root classes are the basic data types and classes on which all the other classes are built. They provide:
* fundamental types such as Boolean, Character, Integer or Real,
* safe handling of dynamically created objects, ensuring automatic deletion of unreferenced objects (see the Standard_Transient class),
* encapsulation of C++ streams.
Root classes are mainly implemented in the **Standard** and **MMgt** packages.
-Strings
--------
+### Strings
Strings are classes that handle dynamically sized sequences of characters based on both ASCII (normal 8-bit character type) and Unicode (16-bit character type).
Strings may also be manipulated by handles, and consequently be shared.
Strings are implemented in the **TCollection** package.
-Collections
------------
+### Collections
Collections are the classes that handle dynamically sized aggregates of data.
Collection classes are *generic*, that is, they define a structure and algorithms allowing to hold a variety of objects which do not necessarily inherit from a unique root class (similarly to C++ templates). When you need to use a collection of a given type of object, you must *instantiate* it for this specific type of element. Once this declaration is compiled, all functions available on the generic collection are available on your *instantiated class*.
Collections include a wide range of generic classes such as run-time sized arrays, lists, stacks, queues, sets and hash maps.
Collections are implemented in the **TCollection** and **NCollection** packages.
-Collections of Standard Objects
-------------------------------
+### Collections of Standard Objects
+
The **TColStd** package provides frequently used instantiations of generic classes from the **TCollection** package with objects from the **Standard** package or strings from the **TCollection** package.
-Vectors and Matrices
----------------------
+### Vectors and Matrices
+
These classes provide commonly used mathematical algorithms and basic calculations (addition, multiplication, transposition, inversion, etc.) involving vectors and matrices.
-Primitive Geometric Types
--------------------------
+### Primitive Geometric Types
+
Open CASCADE Technology primitive geometric types are a STEP-compliant implementation of basic geometric and algebraic entities.
They provide:
* Descriptions of elementary geometric shapes:
* Composed transformations
* Tools (coordinates and matrices) for algebraic computation.
-Common Math Algorithms
-----------------------
+### Common Math Algorithms
Open CASCADE Technology common math algorithms provide a C++ implementation of the most frequently used mathematical algorithms.
These include:
* Algorithms to find roots of one, or of a set, of non-linear equations,
* Algorithms to find the eigen-values and eigen-vectors of a square matrix.
-Exceptions
-----------
+### Exceptions
+
A hierarchy of commonly used exception classes is provided, all based on class Failure, the root of exceptions.
Exceptions describe exceptional situations, which can arise during the execution of a function. With the raising of an exception, the normal course of program execution is abandoned. The execution of actions in response to this situation is called the treatment of the exception.
-Quantities
-----------
+
+### Quantities
+
These are various classes supporting date and time information and fundamental types representing most physical quantities such as length, area, volume, mass, density, weight, temperature, pressure etc.
-Application services
---------------------
+### Application services
+
Foundation Classes also include implementation of several low-level services that facilitate the creation of customizable and user-friendly applications with Open CASCADE Technology. These include:
- * Unit conversion tools, providing a uniform mechanism for dealing with quantities and associated physical units: check unit compatibility, perform conversions of values between different units and so on (see package UnitsAPI).
- * Basic interpreter of expressions that facilitates the creation of customized scripting tools, generic definition of expressions and so on (see package ExprIntrp)
- * Tools for dealing with configuration resource files (see package Resource) and customizable message files (see package Message), making it easy to provide a multi-language support in applications
+ * Unit conversion tools, providing a uniform mechanism for dealing with quantities and associated physical units: check unit compatibility, perform conversions of values between different units and so on (see package *UnitsAPI*).
+ * Basic interpreter of expressions that facilitates the creation of customized scripting tools, generic definition of expressions and so on (see package *ExprIntrp*)
+ * Tools for dealing with configuration resource files (see package *Resource*) and customizable message files (see package *Message*), making it easy to provide a multi-language support in applications
* Progress indication and user break interfaces, giving a possibility even for low-level algorithms to communicate with the user in a universal and convenient way.
@subsection occt_fcug_1_2 Fundamental Concepts
An object-oriented language structures a system around data types rather than around the actions carried out on this data. In this context, an **object** is an **instance** of a data type and its definition determines how it can be used. Each data type is implemented by one or more classes, which make up the basic elements of the system.
+
In Open CASCADE Technology the classes are usually defined using CDL (CASCADE Definition Language) that provides a certain level of abstraction from pure C++ constructs and ensures a definite level of similarity in the implementation of classes. See *CDL User’s Guide* for more details.
+
This chapter introduces some basic concepts most of which are directly supported by CDL and used not only in Foundation Classes, but throughout the whole OCCT library.
@subsubsection occt_fcug_1_2_1 Modules and toolkits
The whole OCCT library is organized in a set of modules. The first module, providing most basic services and used by all other modules, is called Foundation Classes and described by this manual.
+
Every module consists primarily of one or several toolkits (though it can also contain executables, resource units etc.). Physically a toolkit is represented by a shared library (e.g. .so or .dll). The toolkit is built from one or several packages.
+
@subsubsection occt_fcug_1_2_2 Packages
A **package** groups together a number of classes which have semantic links. For example, a geometry package would contain Point, Line, and Circle classes. A package can also contain enumerations, exceptions and package methods (functions). In practice, a class name is prefixed with the name of its package e.g.
*Geom_Circle*.
-Data types described in a package *may *include one or more of the following data types:
+Data types described in a package may include one or more of the following data types:
* Enumerations
* Object classes
* Exceptions
* Pointers to other object classes
-Inside a package, two data types *cannot *bear the same name.
+Inside a package, two data types cannot bear the same name.
-
+@image html /user_guides/foundation_classes/images/foundation_classes_image003.jpg "Contents of a package"
+@image latex /user_guides/foundation_classes/images/foundation_classes_image003.jpg "Contents of a package"
**Methods** are either **functions** or **procedures**. Functions return an object, whereas procedures only communicate by passing arguments. In both cases, when the transmitted object is an instance manipulated by a handle, its identifier is passed. There are three categories of methods:
* **Object constructor** Creates an instance of the described class. A class will have one or more object constructors with various different arguments or none.
@subsubsection occt_fcug_1_2_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).
-Categories of Classes
-------------------------
+#### Categories of Classes
Classes fall into three categories:
* Ordinary classes.
* Deferred classes. A **deferred class** cannot be instantiated. The purpose of having such classes is to have a given behavior shared by a hierarchy of classes and dependent on the implementation of the descendants. This is a way of guaranteeing a certain base of inherited behavior common to all the classes based on a particular deferred class. The C++ equivalent of a deferred CDL class is an abstract class.
* Generic classes. A **generic class** offers a set of functional behaviors to manipulate other data types. Instantiation of a generic class requires that a data type is given for its argument(s). The generic classes in CDL perform the same mission as template classes in C++.
-
-
-
@subsubsection occt_fcug_1_2_4 Genericity
Generic classes are implemented in two steps. First you declare the generic class to establish the model, then you instantiate this class by giving information about the generic types.
-Declaring a Generic Class
----------------------------
+#### Declaring a Generic Class
+
The generic classes in Open CASCADE Technology are similar by their intent to C++ templates with explicit instantiation.
A generic class is declared in CDL as operating on data items of non-fixed types which are declared as arguments of the generic class. It is possible to put a restriction on these data types to be of subtype of some definite class. Definition of the generic class does not create new class type in C++ terms; it only defines a pattern for generation (instantiation) of the real classes.
-Instantiation of a Generic Class
---------------------------------
+#### Instantiation of a Generic Class
+
When a generic class is instantiated, its argument types are substituted by actually existing data types (elementary types or classes). The result of instantiation is a new C++ class with an arbitrary name (specified in the instantiating declaration). By convention, the name of the instantiated class is usually constructed from the name of the generic class and names of actual argument types. As for any other class, the name of the class instantiating a generic type is prefixed by the name of the package in which instantiation is declared.
@code
class Array1OfReal instantiates Array1 from TCollection (Real);
No class can inherit from a generic class.
A generic class can be a deferred class. A generic class can also accept a deferred class as its argument. In both these cases, any class instantiated from it will also be deferred. The resulting class can then be inherited by another class.
-Nested Generic Classes
-----------------------
+#### Nested Generic Classes
+
It often happens that many classes are linked by a common generic type. This is the case when a base structure furnishes an iterator. In this context, it is necessary to make sure that the group of linked generic classes is indeed instantiated for the same type of object. In order to group the instantiation, you may declare certain classes as being nested.
When generic class is instantiated, its nested classes are instantiated as well. The name of the instantiation of the nested class is constructed from the name of that nested class and name of the main generic class, connected by ‘Of’.
@code
@endcode
This declaration in *TColStd* defines not only class *TColStd_MapOfReal*, but also class *TColStd_MapIteratorOfMapOfReal*, which is instantiated from nested class *MapIterator* of the generic class *TCollection_Map*. Note that instantiation of the nested class is separate class, it is not nested class to the instantiation of the main class.
**Nested classes**, even though they are described as non-generic classes, are generic by construction being inside the class they are a member of.
+
@subsubsection occt_fcug_1_2_5 Inheritance
The purpose of inheritance is to reduce the development workload. The inheritance mechanism allows a new class to be declared already containing the characteristics of an existing class. This new class can then be rapidly specialized for the task in hand. This avoids the necessity of developing each component “from scratch”.
For example, having already developed a class *BankAccount* you could quickly specialize new classes: *SavingsAccount, LongTermDepositAccount, MoneyMarketAccount, RevolvingCreditAccount*, etc....
+
The corollary of this is that when two or more classes inherit from a parent (or ancestor) class, all these classes guarantee as a minimum the behavior of their parent (or ancestor). For example, if the parent class BankAccount contains the method Print which tells it to print itself out, then all its descendent classes guarantee to offer the same service.
+
One way of ensuring the use of inheritance is to declare classes at the top of a hierarchy as being **deferred**. In such classes, the methods are not implemented. This forces the user to create a new class which redefines the methods. This is a way of guaranteeing a certain minimum of behavior among descendent classes.
@subsubsection occt_fcug_1_2_6 Categories of Data Types
* Data types manipulated by handle (or reference)
* Data types manipulated by value
-
+@image html /user_guides/foundation_classes/images/foundation_classes_image004.jpg "Manipulation of data types"
+@image latex /user_guides/foundation_classes/images/foundation_classes_image004.jpg "Manipulation of data types"
A data type is implemented as a class. The class not only defines its data representation and the methods available on instances, but it also suggests how the instance will be manipulated.
* A variable of a type manipulated by value contains the instance itself.
* A variable of a type manipulated by handle contains a reference to the instance.
The first examples of types manipulated by values are the predefined **primitive types**: *Boolean, Character, Integer, Real*, etc.
+
A variable of a type manipulated by handle which is not attached to an object is said to be **null**. To reference an object, we instantiate the class with one of its constructors. For example, in C++:
~~~~~
@subsubsection occt_fcug_1_2_7 Exceptions
The behavior of any object is implemented by the methods, which were defined in its class declaration. The definition of these methods includes not only their signature (their programming interface) but also their domain of validity.
+
This domain is expressed by **exceptions**. Exceptions are raised under various error conditions. This mechanism is a safeguard of software quality.
@subsubsection occt_fcug_1_2_8 Persistence and Data Schema
The data schema is the structure used by an application to store its data. Data schemas consist of persistent classes.
-An object is called **persistent** if it can be permanently stored. Thus, the object can be reused at a later date by the application, which created it, or by another application.
+
+An object is called **persistent** if it can be permanently stored. Thus, the object can be reused at a later date by the application, which created it, or by another application.
+
In order for an object to be persistent for CDL, its type must be declared as inheriting from the class *Standard_Persistent* or have a parent class inheriting from the *Standard_Persistent* class. Note that classes inheriting from *Standard_Persistent* are handled by a reference.
+
Objects instantiated from classes which inherit from the Standard_Storable class cannot themselves be stored individually, but they can be stored as fields of an object which inherits from *Standard_Persistent*. Note that objects inheriting from *Standard_Storable* are handled by a value.
@section occt_fcug_2 Basics
@subsubsection occt_fcug_2_1_1 Primitive Types
The primitive types are predefined in the language and they are **manipulated by value**.
Some of these primitives inherit from the **Storable** class. This means they can be used in the implementation of persistent objects, either contained in entities declared within the methods of the object, or they form part of the internal representation of the object.
+
The primitives inheriting from *Standard_Storable* are the following:
* **Boolean** is used to represent logical data. It may have only two values: *Standard_True* and *Standard_False*.
* **Character** designates any ASCII character.
|unsigned int | Standard_Boolean |
|char | Standard_Character |
| short | Standard_ExtCharacter |
-| char* | Standard_CString |
-| void* | Standard_Address |
-|short* | Standard_ExtString |
+| char\* | Standard_CString |
+| void\* | Standard_Address |
+| short\* | Standard_ExtString |
-* pointer
+\* The types with asterisk are pointers.
**Reminder of the classes listed above:**
* Standard_Character: **Character** is a fundamental type representing the normalized ASCII character set. It may be assigned the values of the 128 ASCII characters. **Character** is implemented as a **typedef** of the C++ **char** fundamental type. As such, the ordering and equivalence relations <, <=, ==, !=, >=, > are defined on characters using the order of the ASCII chart (ex: A B).
* Standard_ExtCharacter: **ExtCharacter** is a fundamental type representing the Unicode character set. It is a 16-bit character type. **ExtCharacter** is implemented as a **typedef** of the C++ **short** fundamental type. As such, the ordering and equivalence relations <, <=, ==, !=, >=, > are defined on extended characters using the order of the UNICODE chart (ex: A B).
* Standard_CString: **CString** is a fundamental type representing string literals. A string literal is a sequence of ASCII (8 bits) characters enclosed in double quotes. **CString** is implemented as a **typedef** of the C++ **char* ** fundamental type.
-* Standard_Address : **Address** is a fundamental type representing a generic pointer. **Address** is implemented as a **typedef** of the C++ **void* ** fundamental type.
-* Standard_ExtString : **ExtString** is a fundamental type representing string literals as sequences of Unicode (16 bits) characters. **ExtString** is implemented as a **typedef** of the C++ **short* ** fundamental type.
+* Standard_Address : **Address** is a fundamental type representing a generic pointer. **Address** is implemented as a **typedef** of the C++ *void* fundamental type.
+* Standard_ExtString : **ExtString** is a fundamental type representing string literals as sequences of Unicode (16 bits) characters. **ExtString** is implemented as a **typedef** of the C++ *short* fundamental type.
@subsubsection occt_fcug_2_1_2 Types manipulated by value
There are three categories of types which are manipulated by value:
* Types defined by classes not inheriting from Standard_Persistent or Standard_Transient, whether directly or not.
Types which are manipulated by value behave in a more direct fashion than those manipulated by handle and thus can be expected to perform operations faster, but they cannot be stored independently in a file.
-
-
-Types that are known to the schema (i.e. they are either **primitives**or they inherit from **Storable**) and are manipulated by value, can be stored inside a persistent object as part of the representation. Only in this way can a “manipulated by value” object be stored in a file.
-
+@image html /user_guides/foundation_classes/images/foundation_classes_image005.jpg "Manipulation of a data type by value"
+@image latex /user_guides/foundation_classes/images/foundation_classes_image005.jpg "Manipulation of a data type by value"
+Types that are known to the schema (i.e. they are either **primitives** or they inherit from **Storable**) and are manipulated by value, can be stored inside a persistent object as part of the representation. Only in this way can a “manipulated by value” object be stored in a file.
@subsubsection occt_fcug_2_1_3 Types manipulated by reference (handle)
There are two categories of types which are manipulated by handle:
- * Types defined by classes inheriting from the **Persistent**class, which are therefore storable in a file.
- * Types defined by classes inheriting from the **Transient**class.
+ * Types defined by classes inheriting from the **Persistent** class, which are therefore storable in a file.
+ * Types defined by classes inheriting from the **Transient** class.
-
+@image html /user_guides/foundation_classes/images/foundation_classes_image006.jpg "Manipulation of a data type by reference"
+@image latex /user_guides/foundation_classes/images/foundation_classes_image006.jpg "Manipulation of a data type by reference"
@subsubsection occt_fcug_2_1_4 Summary of properties
@subsection occt_fcug_2_2 Programming with Handles
@subsubsection occt_fcug_2_2_1 Handle Definition
A handle may be compared with a C++ pointer. Several handles can reference the same object. Also, a single handle may reference several objects, but only one at a time. To have access to the object it refers to, the handle must be de-referenced just as with a C++ pointer.
+
Transient and Persistent classes may be manipulated either with handles or with values. Handles which reference non-persistent objects are called non-storable handles; therefore, a persistent object cannot contain a non-storable handle.
Organization of Classes
-----------------------
Classes used with handles are persistent or transient.
+
Classes that inherit from *Standard_Transient* are transient while classes that inherit from *Standard_Persistent* are persistent.
+
In this chapter we will discuss only transient classes and relevant handles. Persistent classes and their handles are organized in a similar manner.
+
Class *Standard_Transient* is a root of a big hierarchy of OCCT classes that are said to be operable by handles. It provides a reference counter field, inherited by all its descendant classes, that is used by associated *Handle()* classes to track a number of handles pointing to this instance of the object.
+
For every class derived (directly or indirectly) from *Transient*, CDL extractor creates associated class *Handle()* whose name is the same as the name of that class prefixed by *Handle_*. Open CASCADE Technology provides pre-processor macro *Handle()* that produces a name of a *Handle()* class for a given transient class name.
Using a Handle
--------------
A handle is characterized by the object it references.
-Before performing any operation on a transient object, you must declare the handle.
-For example, if Point and Line are two transient classes from the Geom package, you would write:
+
+Before performing any operation on a transient object, you must declare the handle. For example, if Point and Line are two transient classes from the Geom package, you would write:
~~~~~
Handle(Geom_Point) p1, p2;
~~~~~
Declaring a handle creates a null handle that does not refer to any object. The handle may be checked to be null by its method *IsNull()*. To nullify a handle, use method *Nullify()*.
+
To initialize a handle, either a new object should be created or the value of another handle can be assigned to it, on condition that their types are compatible.
+
**Note** that handles should only be used for object sharing. For all local operations, it is advisable to use classes manipulated by values.
@subsubsection occt_fcug_2_2_2 Type Management
Open CASCADE Technology provides a means to describe the hierarchy of data types in a generic way, with a possibility to check the exact type of the given object at run-time (similarly to C++ RTTI). For every class type derived from *Standard_Transient*, CDL extractor creates a code instantiating single instance of the class *Standard_Type* (type descriptor) that holds information on that type: its name and list of ancestor types.
That instance (actually, a handle on it) is returned by the virtual method *DynamicType()* of the class derived from *Standard_Transient*. The other virtual method *IsKind()* provides a means to check whether a given object has specified type or inherits it.
+
In order to refer to the type descriptor object for a given class type, use macros *STANDARD_TYPE()* with argument being a name of the class.
Type Conformity
---------------
The type used in the declaration of a handle is the static type of the object, the type seen by the compiler. A handle can reference an object instantiated from a subclass of its static type. Thus, the dynamic type of an object (also called the actual type of an object) can be a descendant of the type which appears in the handle declaration through which it is manipulated.
+
Consider the persistent class *CartesianPoint*, a sub-class of *Point*; the rule of type conformity can be illustrated as follows:
~~~~~
Handle (Geom_Point) p1;
Handle (Geom_CartesianPoint) p2;
p2 = new Geom_CartesianPoint;
-p1 = p2; // OK, the types are compatible
+p1 = p2; // OK, the types are compatible
~~~~~
------------------------
According to the rule of type conformity, it is always possible to go up the class hierarchy through successive assignments of handles. On the other hand, assignment does not authorize you to go down the hierarchy. Consequently, an explicit type conversion of handles is required.
+
A handle can be converted explicitly into one of its sub-types if the actual type of the referenced object is a descendant of the object used to cast the handle. If this is not the case, the handle is nullified (explicit type conversion is sometimes called a “safe cast”). Consider the example below.
~~~~~~
~~~~~~
void MyFunction (const Handle(A) & a)
{
- Handle(B) b = Handle(B)::Downcast(a);
- if (! b.IsNull()) {
- // we can use “b” if class B inherits from A
- }
- else {
- // the types are incompatible
- }
+ Handle(B) b = Handle(B)::Downcast(a);
+ if (! b.IsNull()) {
+ // we can use “b” if class B inherits from A
+ }
+ else {
+ // the types are incompatible
+ }
}
~~~~~~
Downcasting is used particularly with collections of objects of different types; however, these objects should inherit from the same root class.
-For example, with a sequence of SequenceOfTransient transient objects and two classes A and B that both inherit from Standard_Transient, you get the following syntax:
+
+For example, with a sequence of transient objects *SequenceOfTransient* and two classes A and B that both inherit from *Standard_Transient*, you get the following syntax:
~~~~~
Handle (A) a;
// so you downcast:
a = Handle (A)::Downcast (t)
if (! a.IsNull()) {
- // types are compatible, you can use a
+ // types are compatible, you can use a
}
else {
- // the types are incompatible
+ // the types are incompatible
}
~~~~~
@subsubsection occt_fcug_2_2_4 Invoking Methods
Once you have a handle on a persistent or transient object, you can use it like a pointer in C++. To invoke a method which acts on the referenced object, you translate this method by the standard *arrow* operator, or alternatively, by function call syntax when this is available.
+
To test or to modify the state of the handle, the method is translated by the *dot* operator.
The example below illustrates how to access the coordinates of an (optionally initialized) point object:
Handle (Geom_CartesianPoint) centre;
Standard_Real x, y, z;
if (centre.IsNull()) {
- centre = new PGeom_CartesianPoint (0, 0, 0);
+ centre = new PGeom_CartesianPoint (0, 0, 0);
}
centre->Coord(x, y, z);
~~~~~
~~~~~
Handle(Standard_Transient) p = new Geom_CartesianPoint(0.,0.,0.);
if ( p->DynamicType() == STANDARD_TYPE(Geom_CartesianPoint) )
- cout << ;Type check OK; << endl;
+ cout << ;Type check OK; << endl;
else
- cout << ;Type check FAILED; << endl;
+ cout << ;Type check FAILED; << endl;
~~~~~
*NullObject* exception will be raised if a field or a method of an object is accessed via a *Null* handle.
~~~~~
@subsubsection occt_fcug_2_2_5 Handle de-allocation
-Before you delete an object, you must ensure it is no longer referenced. To reduce the programming load related to this management of object life, the delete function in Open CASCADE Technology is secured by a **reference counter** of classes manipulated by handle. A handle automatically deletes an object when it is no longer referenced. Normally you never call the delete operator explicitly on instances of subclasses of Standard_Transient.
+Before you delete an object, you must ensure it is no longer referenced. To reduce the programming load related to this management of object life, the delete function in Open CASCADE Technology is secured by a **reference counter** of classes manipulated by handle. A handle automatically deletes an object when it is no longer referenced. Normally you never call the delete operator explicitly on instances of subclasses of *Standard_Transient*.
+
When a new handle to the same object is created, the reference counter is incremented. When the handle is destroyed, nullified, or reassigned to another object, that counter is decremented. The object is automatically deleted by the handle when reference counter becomes 0.
+
The principle of allocation can be seen in the example below.
~~~~~
...
{
Handle (TColStd_HSequenceOfInteger) H1 = new TColStd_HSequenceOfInteger;
- // H1 has one reference and corresponds to 48 bytes of memory
- {
- Handle (TColStd_HSequenceOfInteger) H2;
- H2 = H1; // H1 has two references
- if (argc == 3) {
- Handle (TColStd_HSequenceOfInteger) H3;
- H3 = H1;
- // Here, H1 has three references
- ...
- }
- // Here, H1 has two references
- }
- // Here, H1 has 1 reference
+ // H1 has one reference and corresponds to 48 bytes of memory
+ {
+ Handle (TColStd_HSequenceOfInteger) H2;
+ H2 = H1; // H1 has two references
+ if (argc == 3) {
+ Handle (TColStd_HSequenceOfInteger) H3;
+ H3 = H1;
+ // Here, H1 has three references
+ ...
+ }
+ // Here, H1 has two references
+ }
+ // Here, H1 has 1 reference
}
// Here, H1 has no reference and the referred TColStd_HSequenceOfInteger object is deleted.
~~~~~
Cycles
------
Cycles appear if two or more objects reference each other by handles (stored as fields). In this condition automatic destruction will not work.
+
Consider for example a graph, whose objects (primitives) have to know the graph object to which they belong, i.e. a primitive must have a reference to complete graph object. If both primitives and the graph are manipulated by handle and they refer to each other by keeping a handle as a field, the cycle appears.
The graph object will not be deleted when the last handle to it is destructed in the application, since there are handles to it stored inside its own data structure (primitives).
+
There are two approaches how to avoid such situation:
* Use C++ pointer for one kind of references, e.g. from a primitive to the graph
* Nullify one set of handles (e.g. handles to a graph in primitives) when a graph object needs to be destroyed
{
. . .
public:
- DEFINE_STANDARD_RTTI(Appli_ExtSurface)
+ DEFINE_STANDARD_RTTI(Appli_ExtSurface)
}
DEFINE_STANDARD_HANDLE(Appli_ExtSurface,Geom_Surface)
~~~~~
@subsubsection occt_fcug_2_3_1. Usage
To use the Open CASCADE Technology memory manager to allocate memory in a C code, just use method *Standard::Allocate()* instead of *malloc()* and method *Standard::Free()* instead of *free()*. In addition, method *Standard::Reallocate()* is provided to replace C function *realloc()*.
+
In C++, operators *new()* and *delete()* for a class may be defined so as to allocate memory using *Standard::Allocate()* and free it using *Standard::Free()*. In that case all objects of that class and all inherited classes will be allocated using the OCCT memory manager.
+
CDL extractor defines *new()* and *delete()* in this way for all classes declared with CDL. Thus all OCCT classes (apart from a few exceptions) are allocated using the OCCT memory manager.
Since operators *new()* and *delete()* are inherited, this is also true for any class derived from an OCCT class, for instance, for all classes derived from *Standard_Transient*.
-**NOTE**
-It is possible (though not recommended unless really unavoidable) to redefine *new()* and *delete()* functions for some class inheriting Standard_Transient. If that is done, the method *Delete()* should be also redefined to apply operator *delete* to *this* pointer. This will ensure that appropriate *delete()* function will be called, even if the object is manipulated by a handle to a base class.
+
+**Note** that it is possible (though not recommended unless really unavoidable) to redefine *new()* and *delete()* functions for some class inheriting Standard_Transient. If that is done, the method *Delete()* should be also redefined to apply operator *delete* to *this* pointer. This will ensure that appropriate *delete()* function will be called, even if the object is manipulated by a handle to a base class.
@subsubsection occt_fcug_2_3_2 Configuring the memory manager
The OCCT memory manager may be configured to apply different optimization techniques to different memory blocks (depending on their size), or even to avoid any optimization and use C functions *malloc()* and *free()* directly.
* *MMGT_THRESHOLD*: defines the maximal size of blocks that are recycled internally instead of being returned to the heap. Default is 40000.
* *MMGT_MMAP*: when set to 1 (default), large memory blocks are allocated using memory mapping functions of the operating system; if set to 0, they will be allocated in the C heap by *malloc()*.
* MMGT_REENTRANT: when set to 1 (default), all calls to the optimized memory manager will be secured against possible simultaneous access from different execution threads. This variable should be set in any multithreaded application that uses an optimized memory manager (*MMGT_OPT=1*) and has more than one thread potentially calling OCCT functions. If set to 0, OCCT memory management and exception handling routines will skip the code protecting from possible concurrency in multi-threaded environment. This can yield some performance gain in some applications, but can lead to unpredictable results if used in a multithreaded application.
-**NOTE**
-For applications that use OCCT memory manager from more than one thread, on multiprocessor hardware, it is recommended to use options *MMGT_OPT=2* and *MMGT_REENTRANT=1*.
+
+**Note** it is recommended to use options *MMGT_OPT=2* and *MMGT_REENTRANT=1* for applications that use OCCT memory manager from more than one thread, on multiprocessor hardware.
+
@subsubsection occt_fcug_2_3_3 Implementation details
When *MMGT_OPT* is set to 1, the following optimization techniques are used:
* Small blocks with a size less than *MMGT_CELLSIZE*, are not allocated separately. Instead, a large pools of memory are allocated (the size of each pool is *MMGT_NBPAGES* pages). Every new memory block is arranged in a spare place of the current pool. When the current memory pool is completely occupied, the next one is allocated, and so on.
+
In the current version memory pools are never returned to the system (until the process finishes). However, memory blocks that are released by the method *Standard::Free()* are remembered in the free lists and later reused when the next block of the same size is allocated (recycling).
+
* Medium-sized blocks, with a size greater than *MMGT_CELLSIZE* but less than *MMGT_THRESHOLD*, are allocated directly in the C heap (using *malloc()* and *free()*). When such blocks are released by the method *Standard::Free()* they are recycled just like small blocks.
+
However, unlike small blocks, the recycled medium blocks contained in the free lists (i.e. released by the program but held by the memory manager) can be returned to the heap by method *Standard::Purge()*.
- * Large blocks with a size greater than *MMGT_THRESHOLD*, including memory pools used for small blocks, are allocated depending on the value of *MMGT_MMAP*: if it is 0, these blocks are allocated in the C heap; otherwise they are allocated using operating-system specific functions managing memory mapped files.
-Large blocks are returned to the system immediately when *Standard::Free()* is called.
-Benefits and drawbacks
-----------------------
+
+ * Large blocks with a size greater than *MMGT_THRESHOLD*, including memory pools used for small blocks, are allocated depending on the value of *MMGT_MMAP*: if it is 0, these blocks are allocated in the C heap; otherwise they are allocated using operating-system specific functions managing memory mapped files. Large blocks are returned to the system immediately when *Standard::Free()* is called.
+
+#### Benefits and drawbacks
+
The major benefit of the OCCT memory manager is explained by its recycling of small and medium blocks that makes an application work much faster when it constantly allocates and frees multiple memory blocks of similar sizes. In practical situations, the real gain on the application performance may be up to 50%.
+
The associated drawback is that recycled memory is not returned to the operating system during program execution. This may lead to considerable memory consumption and even be misinterpreted as a memory leak. To minimize this effect, the method Standard::Purge() shall be called after the completion of memory-intensive operations.
-The overhead expenses induced by the OCCT memory manager are:
+The overhead expenses induced by the OCCT memory manager are:
* size of every allocated memory block is rounded up to 8 bytes (when MMGT_OPT is 0 (default), the rounding is defined by the CRT; the typical value for 32-bit platforms is 4 bytes)
* additional 4 bytes (or 8 on 64-bit platforms) are allocated in the beginning of every memory block to hold its size (or address of the next free memory block when recycled in free list) only when MMGT_OPT is 1
-Note that these overheads may be greater or less than overheads induced by the C heap memory manager, so overall memory consumption may be greater in either optimized or standard modes, depending on circumstances.
+
+
+Note that these overheads may be greater or less than overheads induced by the C heap memory manager, so overall memory consumption may be greater in either optimized or standard modes, depending on circumstances.
+
As a general rule, it is advisable to allocate memory through significant blocks. In this way, you can work with blocks of contiguous data, and processing is facilitated for the memory page manager.
-In multithreaded mode (*MMGT_REENTRANT=1*), the OCCT memory manager uses mutex to lock access to free lists, therefore it may have less performance than non-optimized mode in situations when different threads often make simultaneous calls to the memory manager. The reason is that modern implementations of malloc() and free() employ several allocation arenas and thus avoid delays waiting mutex release, which are possible in such situations.
+
+In multithreaded mode *(MMGT_REENTRANT=1)*, the OCCT memory manager uses mutex to lock access to free lists, therefore it may have less performance than non-optimized mode in situations when different threads often make simultaneous calls to the memory manager. The reason is that modern implementations of *malloc()* and *free()* employ several allocation arenas and thus avoid delays waiting mutex release, which are possible in such situations.
@subsection occt_fcug_2_4 Exception Handling
-Exception handling provides a means of transferring control from a given point in a program being executed to an **exception handler **associated with another point previously executed.
+Exception handling provides a means of transferring control from a given point in a program being executed to an **exception handler** associated with another point previously executed.
+
A method may raise an exception which interrupts its normal execution and transfers control to the handler catching this exception.
+
Open CASCADE Technology provides a hierarchy of exception classes with a root class being class Standard_Failure from the Standard package. The CDL extractor generates exception classes with standardized interface.
-Open CASCADE Technology also provides support for converting system signals (such as access violation or division by zero) to exceptions, so that such situations can be safely handled with the same uniform approach.
+
+Open CASCADE Technology also provides support for converting system signals (such as access violation or division by zero) to exceptions, so that such situations can be safely handled with the same uniform approach.
+
However, in order to support this functionality on various platforms, some special methods and workarounds are used. Though the implementation details are hidden and handling of OCCT exceptions is done basically in the same way as with C++, some peculiarities of this approach shall be taken into account and some rules must be respected.
+
The following paragraphs describe recommended approaches for using exceptions when working with Open CASCADE Technology.
+
@subsubsection occt_fcug_2_4_1 Raising an Exception
-“C++ like” Syntax
------------------
+#### “C++ like” Syntax
+
To raise an exception of a definite type method Raise() of the appropriate exception class shall be used.
~~~~~
DomainError::Raise(“Cannot cope with this condition”);
~~~~~
-
-raises an exception of DomainError type with the associated message “Cannot cope with this condition”, the message being optional. This exception may be caught by a handler of some DomainError type as follows:
+raises an exception of *DomainError* type with the associated message “Cannot cope with this condition”, the message being optional. This exception may be caught by a handler of a *DomainError* type as follows:
~~~~~
try {
- OCC_CATCH_SIGNALS
- // try block
+ OCC_CATCH_SIGNALS
+ // try block
}
catch(DomainError) {
// handle DomainError exceptions here
}
~~~~~
-Regular usage
--------------
+#### Regular usage
+
Exceptions should not be used as a programming technique, to replace a “goto” statement for example, but as a way to protect methods against misuse. The caller must make sure its condition is such that the method can cope with it.
+
Thus,
* No exception should be raised during normal execution of an application.
* A method which may raise an exception should be protected by other methods allowing the caller to check on the validity of the call.
-For example, if you consider the TCollection_Array1 class used with:
- * a Value function to extract an element
- * a Lower function to extract the lower bound of the array
- * an Upper function to extract the upper bound of the array,
-then, the Value function may be implemented as follows:
+
+For example, if you consider the *TCollection_Array1* class used with:
+ * *Value* function to extract an element
+ * *Lower* function to extract the lower bound of the array
+ * *Upper* function to extract the upper bound of the array.
+
+then, the *Value* function may be implemented as follows:
~~~~~
Item TCollection_Array1::Value (const Standard_Integer&index) const
{
- // where r1 and r2 are the lower and upper bounds of the array
- if(index r1 || index > r2) {
- OutOfRange::Raise(“Index out of range in Array1::Value”);
- }
- return contents[index];
+ // where r1 and r2 are the lower and upper bounds of the array
+ if(index r1 || index > r2) {
+ OutOfRange::Raise(“Index out of range in Array1::Value”);
+ }
+ return contents[index];
}
~~~~~
Here validity of the index is first verified using the Lower and Upper functions in order to protect the call.
-Normally the caller ensures the index being in the valid range before calling Value(). In this case the above implementation of Value is not optimal since the test done in Value is time-consuming and redundant.
+Normally the caller ensures the index being in the valid range before calling Value(). In this case the above implementation of Value is not optimal since the test done in Value is time-consuming and redundant.
+
It is a widely used practice to include that kind of protections in a debug build of the program and exclude in release (optimized) build. To support this practice, the macros Raise_if() are provided for every OCCT exception class:
~~~~~
<ErrorTypeName>_Raise_if(condition, “Error message”);
~~~~~
-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.
+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 No_<ErrorTypeName> at compile-time:
~~~~~
~~~~~
Item TCollection_Array1::Value (const Standard_Integer&index) const
- {
- OutOfRange_Raise_if(index r1 || index > r2,
- “index out of range in Array1::Value”);
- return contents[index];
+ {
+ OutOfRange_Raise_if(index r1 || index > r2,
+ “index out of range in Array1::Value”);
+ return contents[index];
}
~~~~~
When an exception is raised, control is transferred to the nearest handler of a given type in the call stack, that is:
* the handler whose try block was most recently entered and not yet exited,
* the handler whose type matches the raise expression.
+
A handler of T exception type is a match for a raise expression with an exception type of E if:
* T and E are of the same type, or
* T is a supertype of E.
+
In order to handle system signals as exceptions, make sure to insert macro OCC_CATCH_SIGNALS somewhere in the beginning of the relevant code. The recommended location for it is first statement after opening brace of try {} block.
-As an example, consider the exceptions of type NumericError, Overflow, Underflow and ZeroDivide where NumericError is the supertype of the three others.
+
+As an example, consider the exceptions of type *NumericError, Overflow, Underflow* and *ZeroDivide*, where *NumericError* is the parent type of the three others.
~~~~~
void f(1)
{
- try {
- OCC_CATCH_SIGNALS
- // try block
- }
- catch(Standard_Overflow) { // first handler
- // ...
- }
- catch(Standard_NumericError) { // second handler
- // ...
- }
+ try {
+ OCC_CATCH_SIGNALS
+ // try block
+ }
+ catch(Standard_Overflow) { // first handler
+ // ...
+ }
+ catch(Standard_NumericError) { // second handler
+ // ...
+ }
}
~~~~~
-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 most distant try block, 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.
~~~~~
void f(1)
{
- int i = 0;
- {
- try {
- OCC_CATCH_SIGNALS
- g(i);// i is accessible
- }
- // statement here will produce compile-time errors !
- catch(Standard_NumericError) {
- // fix up with possible reuse of i
- }
- // statement here may produce unexpected side effect
- }
- . . .
+ int i = 0;
+ {
+ try {
+ OCC_CATCH_SIGNALS
+ g(i);// i is accessible
+ }
+ // statement here will produce compile-time errors !
+ catch(Standard_NumericError) {
+ // fix up with possible reuse of i
+ }
+ // statement here may produce unexpected side effect
+ }
+ . . .
}
~~~~~
-The exceptions form a hierarchy tree completely separated from other user defined classes. One exception of type Failure is the root of the entire exception hierarchy. Thus, using a handler with Failure type catches any OCCT exception. It is recommended to set up such a handler in the main routine.
+The exceptions form a hierarchy tree completely separated from other user defined classes. One exception of type *Failure* is the root of the entire exception hierarchy. Thus, using a handler with *Failure* type catches any OCCT exception. It is recommended to set up such a handler in the main routine.
+
The main routine of a program would look like this:
~~~~~
#include <iostream.h>
int main (int argc, char* argv[])
{
- try {
- OCC_CATCH_SIGNALS
- // main block
- return 0;
- }
- catch(Standard_Failure) {
- Handle(Standard_Failure) error = Standard_Failure::Caught ();
- cout error end1;
- }
- return 1;
+ try {
+ OCC_CATCH_SIGNALS
+ // main block
+ return 0;
+ }
+ catch(Standard_Failure) {
+ Handle(Standard_Failure) error = Standard_Failure::Caught ();
+ cout error end1;
+ }
+ return 1;
}
~~~~~
-In this example function Caught is a static member of Failure that returns an exception object containing the error message built in the raise expression. Note that this method of accessing a raised object is used in Open CASCADE Technology instead of usual C++ syntax (receiving the exception in catch argument).
+In this example function *Caught* is a static member of *Failure* that returns an exception object containing the error message built in the raise expression. Note that this method of accessing a raised object is used in Open CASCADE Technology instead of usual C++ syntax (receiving the exception in catch argument).
-**NOTE**
-Though standard C++ scoping rules and syntax apply to try block and handlers, note that on some platforms Open CASCADE Technology may be compiled in compatibility mode when exceptions are emulated by long jumps (see below). In this mode it is required that no statement precedes or follows any handler. Thus it is highly recommended to always include a try block into additional {} braces. Also this mode requires that header file Standard_ErrorHandler.hxx be included in your program before a try block, otherwise it may fail to handle Open CASCADE Technology exceptions; furthermore catch() statement does not allow passing exception object as argument.
+Though standard C++ scoping rules and syntax apply to try block and handlers, note that on some platforms Open CASCADE Technology may be compiled in compatibility mode when exceptions are emulated by long jumps (see below). In this mode it is required that no statement precedes or follows any handler. Thus it is highly recommended to always include a try block into additional {} braces. Also this mode requires that header file *Standard_ErrorHandler.hxx* be included in your program before a try block, otherwise it may fail to handle Open CASCADE Technology exceptions; furthermore *catch()* statement does not allow passing exception object as argument.
-Catching signals
-----------------
-In order for the application to be able to catch system signals (access violation, division by zero, etc.) in the same way as other exceptions, the appropriate signal handler shall be installed in the runtime by the method
-OSD::SetSignal();
+#### Catching signals
+
+In order for the application to be able to catch system signals (access violation, division by zero, etc.) in the same way as other exceptions, the appropriate signal handler shall be installed in the runtime by the method *OSD::SetSignal()*.
+
Normally this method is called in the beginning of the main() function. It installs a handler that will convert system signals into OCCT exceptions.
-In order to actually convert signals to exceptions, macro OCC_CATCH_SIGNALS shall be inserted in the source code. The typical place where this macro is put is beginning of the try{} block which catches such exceptions.
+
+In order to actually convert signals to exceptions, macro *OCC_CATCH_SIGNALS* needs to be inserted in the source code. The typical place where this macro is put is beginning of the *try{}* block which catches such exceptions.
@subsubsection occt_fcug_2_4_3 Implementation details
-The exception handling mechanism in Open CASCADE Technology is implemented in different ways depending on the preprocessor macros NO_CXX_EXCEPTIONS and OCC_CONVERT_SIGNALS, which shall be consistently defined by compilation procedures for both Open CASCADE Technology and user applications:
+
+The exception handling mechanism in Open CASCADE Technology is implemented in different ways depending on the preprocessor macros *NO_CXX_EXCEPTIONS* and *OCC_CONVERT_SIGNALS*, which shall be consistently defined by compilation procedures for both Open CASCADE Technology and user applications:
1. On Windows and DEC, these macros are not defined by default, and normal C++ exceptions are used in all cases, including throwing from signal handler. Thus the behavior is as expected in C++.
-2. On SUN and Linux, macro OCC_CONVERT_SIGNALS is defined by default. The C++ exception mechanism is used for catching exceptions and for throwing them from normal code. Since it is not possible to throw C++ exception from system signal handler function, that function makes a long jump to the nearest (in the execution stack) invocation of macro OCC_CATCH_SIGNALS, and only there the C++ exception gets actually thrown. The macro OCC_CATCH_SIGNALS is defined in the file Standard_ErrorHandler.hxx. Therefore, including this file is necessary for successful compilation of a code containing this macro.
+2. On SUN and Linux, macro *OCC_CONVERT_SIGNALS* is defined by default. The C++ exception mechanism is used for catching exceptions and for throwing them from normal code. Since it is not possible to throw C++ exception from system signal handler function, that function makes a long jump to the nearest (in the execution stack) invocation of macro *OCC_CATCH_SIGNALS*, and only there the C++ exception gets actually thrown. The macro *OCC_CATCH_SIGNALS* is defined in the file *Standard_ErrorHandler.hxx*. Therefore, including this file is necessary for successful compilation of a code containing this macro.
+
This mode differs from standard C++ exception handling only for signals:
- + macro OCC_CATCH_SIGNALS is necessary (besides call to OSD::SetSignal() described above) for conversion of signals into exceptions;
+ + macro *OCC_CATCH_SIGNALS* is necessary (besides call to *OSD::SetSignal()* described above) for conversion of signals into exceptions;
+ the destructors for automatic C++ objects created in the code after that macro and till the place where signal is raised will not be called in case of signal, since no C++ stack unwinding is performed by long jump.
-3.On SUN and Linux Open CASCADE Technology can also be compiled in compatibility mode (which was default till Open CASCADE Technology 6.1.0). In that case macro NO_CXX_EXCEPTIONS is defined and the C++ exceptions are simulated with C long jumps. As a consequence, the behavior is slightly different from that expected in the C++ standard.
+
+3. On SUN and Linux Open CASCADE Technology can also be compiled in compatibility mode (which was default till Open CASCADE Technology 6.1.0). In that case macro *NO_CXX_EXCEPTIONS* is defined and the C++ exceptions are simulated with C long jumps. As a consequence, the behavior is slightly different from that expected in the C++ standard.
+
While exception handling with NO_CXX_EXCEPTIONS is very similar to C++ by syntax, it has a number of peculiarities that should be taken into account:
- * try and catch are actually macros defined in the file Standard_ErrorHandler.hxx. Therefore, including this file is necessary for handling OCCT exceptions;
- * due to being a macro, catch cannot contain a declaration of the exception object after its type; only type is allowed in the catch statement. Use method Standard_Failure::Caught() to access an exception object;
- * catch macro may conflict with some STL classes that might use catch(…) statements in their header files. So STL headers should not be included after Standard_ErrorHandler.hxx;
+ * try and catch are actually macros defined in the file *Standard_ErrorHandler.hxx*. Therefore, including this file is necessary for handling OCCT exceptions;
+ * due to being a macro, catch cannot contain a declaration of the exception object after its type; only type is allowed in the catch statement. Use method *Standard_Failure::Caught()* to access an exception object;
+ * catch macro may conflict with some STL classes that might use catch(…) statements in their header files. So STL headers should not be included after *Standard_ErrorHandler.hxx*;
* Open CASCADE Technology try/catch block will not handle normal C++ exceptions; however this can be achieved using special workarounds;
* the try macro defines a C++ object that holds an entry point in the exception handler. Therefore if exception is raised by code located immediately after the try/catch block but on the same nesting level as *try*, it may be handled by that *catch*. This may lead to unexpected behavior, including infinite loop. To avoid that, always surround the try/catch block in {} braces;
* the destructors of the C++ objects allocated on the stack after handler initialization are not called by exception raising.
-In general, for writing platform-independent code it is recommended to insert macros OCC_CATCH_SIGNALS in try {} blocks or other code where signals may happen. For compatibility with previous versions of Open CASCADE Technology the limitations described above for NO_CXX_EXCEPTIONS shall be assumed.
+In general, for writing platform-independent code it is recommended to insert macros *OCC_CATCH_SIGNALS* in try {} blocks or other code where signals may happen. For compatibility with previous versions of Open CASCADE Technology the limitations described above for *NO_CXX_EXCEPTIONS* shall be assumed.
@subsection occt_fcug_2_5 Plug-In Management
@subsubsection occt_fcug_2_5_1 Distribution by Plug-Ins
A plug-in is a component that can be loaded dynamically into a client application, not requiring to be directly linked to it. The plug-in is not bound to its client, i.e. the plug-in knows only how its connection mechanism is defined and how to call the corresponding services.
+
A plug-in can be used to:
* implement the mechanism of a *driver*, i.e dynamically changing a driver implementation according to the current transactions (for example, retrieving a document stored in another version of an application),
* restrict processing resources to the minimum required (for example, it does not load any application services at run-time as long as the user does not need them),
* facilitate development de-synchronization (an application can be delivered with base functions while some advanced capabilities will be added as plug-ins when they are available).
+
The plug-in is identified with the help of the global universal identifier (GUID). The GUID includes lower case characters and cannot end with a blank space.
+
Once it has been loaded, the call to the services provided by the plug-in is direct (the client is implemented in the same language as the plug-in).
C++ Plug-In Implementation
---------------------------
The C++ plug-in implements a service as an object with functions defined in an abstract class (this abstract class and its parent classes with the GUID are the only information about the plug-in implemented in the client application). The plug-in consists of a sharable library including a method named Factory which creates the C++ object (the client cannot instantiate this object because the plug-in implementation is not visible).
Foundation classes provide in the package **Plugin** a method named Load(), which enables the client to access the required service through a library.
+
That method reads the information regarding available plug-ins and their locations from the resource file Plugin found by environment variable CSF_PluginDefaults:
~~~~~
$CSF_PluginDefaults/.Plugin
~~~~~
-The Load method looks for the library name in the resource file or registry through its GUID, for example, on UNIX:
+The *Load* method looks for the library name in the resource file or registry through its GUID, for example, on UNIX:
~~~~~
! METADATADRIVER whose value must be OS or DM.
~~~~~
-Then the Load method loads the library according to the rules of the operating system of the host machine (for example, by using environment variables such as LD_LIBRARY_PATH with Unix and PATH with Windows). After that it invokes the Factory method to return the object which supports the required service.
+Then the *Load* method loads the library according to the rules of the operating system of the host machine (for example, by using environment variables such as *LD_LIBRARY_PATH* with Unix and *PATH* with Windows). After that it invokes the *Factory* method to return the object which supports the required service.
The client may then call the functions supported by this object.
C++ Client Plug-In Implementation
----------------------------------
-To invoke one of the services provided by the plug-in, you may call the Plugin::ServiceFactory global function with the Standard_GUID of the requested service as follows:
+To invoke one of the services provided by the plug-in, you may call the *Plugin::ServiceFactory* global function with the *Standard_GUID* of the requested service as follows:
~~~~~
Handle(FADriver_PartStorer)::DownCast
(PlugIn_ServiceId(yourStandardGUID)))
~~~~~
-Let us take **FAFactory.cxx** as an example:
+Let us take *FAFactory.cxx* as an example:
~~~~~
#include <FAFactory.ixx>
PLUGIN(FAFactory)
static Standard_GUID
- StorageDriver(“45b3c690-22f3-11d2-b09e-0000f8791463”);
+ StorageDriver(“45b3c690-22f3-11d2-b09e-0000f8791463”);
static Standard_GUID
- RetrievalDriver(“45b3c69c-22f3-11d2-b09e-0000f8791463”);
+ RetrievalDriver(“45b3c69c-22f3-11d2-b09e-0000f8791463”);
static Standard_GUID
- Schema(“45b3c6a2-22f3-11d2-b09e-0000f8791463”);
+ Schema(“45b3c6a2-22f3-11d2-b09e-0000f8791463”);
//======================================================
// function : Factory
Handle(Standard_Transient) FAFactory::Factory(const Standard_GUID& aGUID)
{
- if(aGUID == StorageDriver) {
- cout “FAFactory : Create store driver” endl;
- static Handle(FADriver_PartStorer) sd = new FADriver_PartStorer();
- return sd;
- }
-
- if(aGUID == RetrievalDriver) {
- cout “FAFactory : Create retrieve driver” endl;
- static Handle(FADriver_PartRetriever)
- rd = new FADriver_PartRetriever();
- return rd;
- }
-
- if(aGUID == Schema) {
- cout “FAFactory : Create schema” endl;
- static Handle(FirstAppSchema) s = new FirstAppSchema();
- return s;
- }
-
- Standard_Failure::Raise(“FAFactory: unknown GUID”);
- Handle(Standard_Transient) t;
- return t;
+ if(aGUID == StorageDriver) {
+ cout “FAFactory : Create store driver” endl;
+ static Handle(FADriver_PartStorer) sd = new FADriver_PartStorer();
+ return sd;
+ }
+
+ if(aGUID == RetrievalDriver) {
+ cout “FAFactory : Create retrieve driver” endl;
+ static Handle(FADriver_PartRetriever)
+ rd = new FADriver_PartRetriever();
+ return rd;
+ }
+
+ if(aGUID == Schema) {
+ cout “FAFactory : Create schema” endl;
+ static Handle(FirstAppSchema) s = new FirstAppSchema();
+ return s;
+ }
+
+ Standard_Failure::Raise(“FAFactory: unknown GUID”);
+ Handle(Standard_Transient) t;
+ return t;
}
~~~~~
-Without using the Software Factory
--------------------------------
+#### Without using the Software Factory
-To create a factory without using the Software Factory, define a **dll **project under Windows or a library under UNIX by using a source file as specified above. The **FAFactory **class is implemented as follows:
+To create a factory without using the Software Factory, define a *dll* project under Windows or a library under UNIX by using a source file as specified above. The *FAFactory* class is implemented as follows:
~~~~~
#include <Handle_Standard_Transient.hxx>
class Standard_GUID;
class FAFactory {
public:
- Standard_EXPORT static Handle_Standard_Transient
- Factory(const Standard_GUID& aGUID) ;
- . . .
+ Standard_EXPORT static Handle_Standard_Transient
+ Factory(const Standard_GUID& aGUID) ;
+ . . .
};
~~~~~
@section occt_fcug_3 Collections, Strings and Unit Conversion
-@subsection occt_fcug_3_1. Collections
+@subsection occt_fcug_3_1 Collections
@subsubsection occt_fcug_3_1_1 Overview
The **Collections** component contains the classes that handle dynamically sized aggregates of data. They include a wide range of collections such as arrays, lists and maps.
-Collections classes are *generic*, that is, they can hold a variety of objects which do not necessarily inherit from a unique root class. When you need to use a collection of a given type of object you must *instantiate* it for this specific type of element. Once this declaration is compiled, all the functions available on the generic collection are available on your *instantiated class*. Note however:
+
+Collections classes are *generic*, that is, they can hold a variety of objects which do not necessarily inherit from a unique root class. When you need to use a collection of a given type of object you must *instantiate* it for this specific type of element. Once this declaration is compiled, all the functions available on the generic collection are available on your *instantiated class*.
+However, note that:
* Each collection directly used as an argument in OCCT public syntax is instantiated in an OCCT component.
- * The **TColStd** package (**Collections of Standard Objects** component) provides numerous instantiations of these generic collections with objects from the **Standard** package or from the **Strings** component.
+ * The *TColStd* package (**Collections of Standard Objects** component) provides numerous instantiations of these generic collections with objects from the **Standard** package or from the **Strings** component.
The **Collections** component provides a wide range of generic collections:
- * *Arrays*are generally used for a quick access to the item, however an array is a fixed sized aggregate.
- * *Sequences* are variable-sized structures, they avoid the use of large and quasi-empty arrays. A sequence item is longer to access than an array item: only an exploration in sequence is effective (but sequences are not adapted for numerous explorations). Arrays and sequences are commonly used as data structures for more complex objects.
- * On the other hand, *maps *are dynamic structures where the size is constantly adapted to the number of inserted items and the access time for an item is effective. Maps structures are commonly used in cases of numerous explorations: they are typically internal data structures for complex algorithms. *Sets *generate the same results as maps but computation time is considerable.
- * *Lists, queues *and *stacks *are minor structures similar to sequences but with other exploration algorithms.
-Most collections follow *value semantics*: their instances are the actual collections, not *handles *to a collection. Only arrays and sequences may also be manipulated by handle, and therefore shared.
+ * **Arrays** are generally used for a quick access to the item, however an array is a fixed sized aggregate.
+ * **Sequences** are variable-sized structures, they avoid the use of large and quasi-empty arrays. A sequence item is longer to access than an array item: only an exploration in sequence is effective (but sequences are not adapted for numerous explorations). Arrays and sequences are commonly used as data structures for more complex objects.
+ * On the other hand, **maps** are dynamic structures where the size is constantly adapted to the number of inserted items and the access time for an item is effective. Maps structures are commonly used in cases of numerous explorations: they are typically internal data structures for complex algorithms. **Sets** generate the same results as maps but computation time is considerable.
+ * **Lists, queues** and **stacks** are minor structures similar to sequences but with other exploration algorithms.
+
+Most collections follow value semantics: their instances are the actual collections, not **handles** to a collection. Only arrays and sequences may also be manipulated by handle, and therefore shared.
@subsubsection occt_fcug_3_1_2 Generic general-purpose Aggregates
-TCollection_Array1
-------------------
-Unidimensional arrays similar to C arrays, i.e. of fixed size but dynamically dimensioned at construction time.
-As with a C array, the access time for an **Array1 **indexed item is constant and is independent of the array size. Arrays are commonly used as elementary data structures for more complex objects.
-**Array1** is a generic class which depends on **Item**, the type of element in the array.
-**Array1** indexes start and end at a user-defined position. Thus, when accessing an item, you must base the index on the lower and upper bounds of the array.
-
-TCollection_Array2
-------------------
-Bi-dimensional arrays of fixed size but dynamically dimensioned at construction time.
-As with a C array, the access time for an **Array2 **indexed item is constant and is independent of the array size. Arrays are commonly used as elementary data structures for more complex objects.
-**Array2 **is a generic class which depends on **Item**, the type of element in the array.
-**Array2 **indexes start and end at a user-defined position. Thus, when accessing an item, you must base the index on the lower and upper bounds of the array.
-
-TCollection_HArray1
--------------------
-Unidimensional arrays similar to C arrays, i.e. of fixed size but dynamically dimensioned at construction time.
-As with a C array, the access time for an **HArray1** or **HArray2** indexed item is constant and is independent of the array size. Arrays are commonly used as elementary data structures for more complex objects.
-**HArray1** objects are *handles *to arrays.
- * **HArray1 **arrays may be shared by several objects.
- * You may use a **TCollection_Array1 **structure to have the actual array.
-**HArray1 **is a generic class which depends on two parameters:
- * **Item**, the type of element in the array,
- * **Array**, the actual type of array handled by **HArray1**. This is an instantiation with **Item **of the **TCollection_Array1 **generic class.
-**HArray1 **indexes start and end at a user-defined position. Thus, when accessing an item, you must base the index on the lower and upper bounds of the array.
-
-TCollection_HArray2
--------------------
-Bi-dimensional arrays of fixed size but dynamically dimensioned at construction time.
-As with a C array, the access time for an **HArray2 **indexed item is constant and is independent of the array size. Arrays are commonly used as elementary data structures for more complex objects.
-**HArray2 **objects are *handles *to arrays.
- * **HArray2 **arrays may be shared by several objects.
- * You may use a **TCollection_Array2 **structure to have the actual array.
-**HArray2 **is a generic class which depends on two parameters:
+#### TCollection_Array1
+
+These are unidimensional arrays similar to C arrays, i.e. of fixed size but dynamically dimensioned at construction time.
+As with a C array, the access time for an *Array1* indexed item is constant and is independent of the array size. Arrays are commonly used as elementary data structures for more complex objects.
+
+*Array1* is a generic class which depends on *Item*, the type of element in the array.
+
+*Array1* indexes start and end at a user-defined position. Thus, when accessing an item, you must base the index on the lower and upper bounds of the array.
+
+#### TCollection_Array2
+
+These are bi-dimensional arrays of fixed size but dynamically dimensioned at construction time.
+
+As with a C array, the access time for an *Array2* indexed item is constant and is independent of the array size. Arrays are commonly used as elementary data structures for more complex objects.
+
+*Array2* is a generic class which depends on *Item*, the type of element in the array.
+
+*Array2* indexes start and end at a user-defined position. Thus, when accessing an item, you must base the index on the lower and upper bounds of the array.
+
+#### TCollection_HArray1
+
+These are unidimensional arrays similar to C arrays, i.e. of fixed size but dynamically dimensioned at construction time.
+As with a C array, the access time for an *HArray1* or *HArray2* indexed item is constant and is independent of the array size. Arrays are commonly used as elementary data structures for more complex objects.
+
+*HArray1* objects are **handles** to arrays.
+ * *HArray1* arrays may be shared by several objects.
+ * You may use a *TCollection_Array1* structure to have the actual array.
+
+*HArray1* is a generic class which depends on two parameters:
* **Item**, the type of element in the array,
- * **Array**, the actual type of array handled by **HArray2**. This is an instantiation with **Item **of the **TCollection_Array2 **generic class.
+ * **Array**, the actual type of array handled by *HArray1*. This is an instantiation with **Item** of the *TCollection_Array1* generic class.
-TCollection_HSequence
----------------------
-
-A sequence of items indexed by an integer.
-Sequences have about the same goal as unidimensional arrays (**TCollection_HArray1**): they are commonly used as elementary data structures for more complex objects. But a sequence is a structure of *variable size*: sequences avoid the use of large and quasi-empty arrays. Exploring a sequence data structure is effective when the exploration is done *in sequence; *elsewhere a sequence item is longer to read than an array item. Note also that sequences are not effective when they have to support numerous algorithmic explorations: a map is better for that.
-**HSequence **objects are *handles *to sequences.
- * **HSequence **sequences may be shared by several objects.
- * You may use a **TCollection_Sequence **structure to have the actual sequence.
-**HSequence **is a generic class which depends on two parameters:
- * **Item**, the type of element in the sequence,
- * **Seq**, the actual type of sequence handled by **HSequence**. This is an instantiation with **Item **of the **TCollection_Sequence **generic class.
+*HArray1* indexes start and end at a user-defined position. Thus, when accessing an item, you must base the index on the lower and upper bounds of the array.
+
+#### TCollection_HArray2
+
+These are bi-dimensional arrays of fixed size but dynamically dimensioned at construction time.
+
+As with a C array, the access time for an *HArray2* indexed item is constant and is independent of the array size. Arrays are commonly used as elementary data structures for more complex objects.
+
+*HArray2* objects are **handles** to arrays.
+ * *HArray2* arrays may be shared by several objects.
+ * You may use a *TCollection_Array2* structure to have the actual array.
-TCollection_HSet
-----------------
-Collection of non-ordered items without any duplicates. At each transaction, the system ckecks to see that there are no duplicates.
-**HSet **objects are *handles *to sets.
-**HSet **is a generic class which depends on two parameters:
- * **Item**, the type of element in the set,
- * **Set**, the actual type of set handled by **HSet**. This is an instantiation with **TCollection_Set **generic class.
+*HArray2* is a generic class which depends on two parameters:
+ * *Item*, the type of element in the array,
+ * *Array*, the actual type of array handled by *HArray2*. This is an instantiation with *Item* of the *TCollection_Array2* generic class.
-TCollection_List
-----------------
-Ordered lists of non-unique objects which can be accessed sequentially using an iterator.
+#### TCollection_HSequence
+
+This is a sequence of items indexed by an integer.
+
+Sequences have about the same goal as unidimensional arrays *TCollection_HArray1*: they are commonly used as elementary data structures for more complex objects. But a sequence is a structure of *variable size*: sequences avoid the use of large and quasi-empty arrays. Exploring a sequence data structure is effective when the exploration is done in sequence; elsewhere a sequence item is longer to read than an array item. Note also that sequences are not effective when they have to support numerous algorithmic explorations: a map is better for that.
+
+*HSequence* objects are **handles** to sequences.
+ * *HSequence* sequences may be shared by several objects.
+ * You may use a *TCollection_Sequence* structure to have the actual sequence.
+
+*HSequence* is a generic class which depends on two parameters:
+ * *Item*, the type of element in the sequence,
+ * *Seq*, the actual type of sequence handled by *HSequence*. This is an instantiation with *Item* of the *TCollection_Sequence* generic class.
+
+#### TCollection_HSet
+
+This is a collection of non-ordered items without any duplicates. At each transaction, the system checks if there are no duplicates.
+*HSet* objects are *handles* to sets.
+*HSet* is a generic class which depends on two parameters:
+ * *Item*, the type of element in the set,
+ * *Set*, the actual type of set handled by *HSet*. This is an instantiation with *TCollection_Set* generic class.
+
+#### TCollection_List
+
+These are ordered lists of non-unique objects which can be accessed sequentially using an iterator.
Item insertion in a list is very fast at any position. But searching for items by value may be slow if the list is long, because it requires a sequential search.
-**List **is a generic class which depends on **Item**, the type of element in the structure.
-Use a **ListIterator **iterator to explore a **List **structure.
-An iterator class is automatically instantiated from the **TCollection_ListIterator **class at the time of instantiation of a **List **structure.
+
+*List* is a generic class, which depends on *Item*, the type of element in the structure.
+Use a *ListIterator* iterator to explore a *List* structure.
+
+An iterator class is automatically instantiated from the *TCollection_ListIterator* class at the time of instantiation of a *List* structure.
+
A sequence is a better structure when searching for items by value.
+
Queues and stacks are other kinds of list with a different access to data.
-TCollection_Queue
------------------
-A structure where items are added at the end and removed from the front. The first item entered will be the first removed (**FIFO** structure: First In First Out). **Queue** is a generic class which depends on **Item**, the type of element in the structure.
+#### TCollection_Queue
-TCollection_Sequence
---------------------
-A sequence of items indexed by an integer.
-Sequences have about the same goal as unidimensional arrays (**TCollection_Array1**): they are commonly used as elementary data structures for more complex objects. But a sequence is a structure of *variable size*: sequences avoid the use of large and quasi-empty arrays. Exploring a sequence data structure is effective when the exploration is done *in sequence*; elsewhere a sequence item is longer to read than an array item. Note also that sequences are not effective when they have to support numerous algorithmic explorations: a map is better for that.
-**Sequence **is a generic class which depends on **Item**, the type of element in the sequence.
+This is a structure, where items are added at the end and removed from the front. The first item entered will be the first removed (**FIFO** structure: First In First Out). *Queue* is a generic class which depends on *Item*, the type of element in the structure.
+
+#### TCollection_Sequence
+
+This is a sequence of items indexed by an integer.
+Sequences have about the same goal as unidimensional arrays (*TCollection_Array1*): they are commonly used as elementary data structures for more complex objects. But a sequence is a structure of *variable size*: sequences avoid the use of large and quasi-empty arrays. Exploring a sequence data structure is effective when the exploration is done *in sequence*; elsewhere a sequence item is longer to read than an array item. Note also that sequences are not effective when they have to support numerous algorithmic explorations: a map is better for that.
+
+*Sequence* is a generic class which depends on *Item*, the type of element in the sequence.
+
+#### TCollection_Set
+
+This is a collection of non-ordered items without any duplicates. At each transaction, the system checks if there are no duplicates.
-TCollection_Set
----------------
-Collection of non-ordered items without any duplicates. At each transaction, the system ckecks there are no duplicates.
A set generates the same result as a map. A map is more effective; so it is advisable to use maps instead of sets.
-**Set **is a generic class which depends on **Item**, the type of element in the set.
-Use a **SetIterator **iterator to explore a **Set **structure.
-TCollection_Stack
-------------------
-A structure where items are added and removed from the top. The last item entered will be the first removed (;**LIFO**; structure: Last In First Out).
-**Stack**is a generic class which depends on **Item**, the type of element in the structure.
-Use a **StackIterator **iterator to explore a **Stack **structure.
+*Set* is a generic class which depends on *Item*, the type of element in the set.
+Use *SetIterator* iterator to explore a *Set* structure.
+
+#### TCollection_Stack
+
+This is a structure where items are added and removed from the top. The last item entered will be the first removed.
+
+*Stack* is a generic class which depends on *Item*, the type of element in the structure.
+Use a *StackIterator* iterator to explore a *Stack* structure.
@subsubsection occt_fcug_3_1_3 Generic Maps
-Maps are dynamically extended data structures where data is quickly accessed with a key. TCollection_BasicMap is a root class for maps.
+Maps are dynamically extended data structures where data is quickly accessed with a key. *TCollection_BasicMap* is a root class for maps.
+
+#### General properties of maps
-General properties of maps
---------------------------
Map items may contain complex non-unitary data, thus it can be difficult to manage them with an array. The map allows a data structure to be indexed by complex data.
+
The size of a map is dynamically extended. So a map may be first dimensioned for a little number of items. Maps avoid the use of large and quasi-empty arrays.
+
The access time for a map item is much better than the one for a sequence, list, queue or stack item. It is comparable with the access time for an array item. It depends on the size of the map and on the quality of the user redefinable function (the *hashing function*) to find quickly where is the item.
The performance of a map exploration may be better of an array exploration because the size of the map is adapted to the number of inserted items.
+
That is why maps are commonly used as internal data structures for algorithms.
-Definitions
------------
+#### Definitions
+
A map is a data structure for which data are addressed by *keys*.
-Once inserted in the map, a map item is referenced as an *entry *of the map.
+
+Once inserted in the map, a map item is referenced as an *entry* of the map.
+
Each entry of the map is addressed by a key. Two different keys address two different entries of the map.
The position of an entry in the map is called a *bucket*.
+
A map is dimensioned by its number of buckets, i.e. the maximum number of entries in the map. The performance of a map is conditioned by the number of buckets.
-The *hashing function *transforms a key into a bucket index. The number of values that can be computed by the hashing function is equal to the number of buckets of the map.
-Both the hashing function and the equality test between two keys are provided by a *hasher *object.
+
+The *hashing function* transforms a key into a bucket index. The number of values that can be computed by the hashing function is equal to the number of buckets of the map.
+
+Both the hashing function and the equality test between two keys are provided by a *hasher* object.
+
A map may be explored by a *map iterator*. This exploration provides only inserted entries in the map (i.e. non empty buckets).
-Collections of generic maps
-------------------------
-The **Collections **component provides numerous generic derived maps.
-These maps include automatic management of the number of *buckets*: they are automatically resized when the number of *keys *exceeds the number of buckets. If you have a fair idea of the number of items in your map, you can save on automatic resizing by specifying a number of buckets at the time of construction, or by using a resizing function. This may be considered for crucial optimization issues.
+#### Collections of generic maps
+
+The *Collections* component provides numerous generic derived maps.
+
+These maps include automatic management of the number of *buckets*: they are automatically resized when the number of *keys* exceeds the number of buckets. If you have a fair idea of the number of items in your map, you can save on automatic resizing by specifying a number of buckets at the time of construction, or by using a resizing function. This may be considered for crucial optimization issues.
+
*Keys, items* and *hashers* are parameters of these generic derived maps.
-**TCollection_MapHasher** class describes the functions required by any *hasher *which is to be used with a map instantiated from the **Collections **component.
-An iterator class is automatically instantiated at the time of instantiation of a map provided by the **Collections **component if this map is to be explored with an iterator. Note that some provided generic maps are not to be explored with an iterator but with indexes (*indexed maps*).
-
-TCollection_DataMap
--------------------
-A map used to store keys with associated items. An entry of **DataMap **is composed of both the key and the item.
-The **DataMap **can be seen as an extended array where the keys are the indexes.
-**DataMap **is a generic class which depends on three parameters:
- * **Key **is the type of key for an entry in the map,
- * **Item **is the type of element associated with a key in the map,
- * **Hasher **is the type of hasher on keys.
-Use a **DataMapIterator **iterator to explore a DataMap map.
-An iterator class is automatically instantiated from the
-**TCollection_DataMapIterator **generic class at the time of instantiation of a **DataMap **map.
-**TCollection_MapHasher **class describes the functions required for a **Hasher **object.
-
-TCollection_DoubleMap
----------------------
-A map used to bind pairs of keys (Key1,Key2) and retrieve them in linear time.
-Key1 is referenced as the *first key *of the **DoubleMap **and Key2 as the *second key*.
-An entry of a **DoubleMap **is composed of a pair of two keys: the first key and the second key.
-**DoubleMap **is a generic class which depends on four parameters:
- * **Key1 **is the type of the first key for an entry in the map,
- * **Key2 **is the type of the second key for an entry in the map,
- * **Hasher1 **is the type of hasher on first keys,
- * **Hasher2 **is the type of hasher on second keys.
-Use a **DoubleMapIterator **to explore a **DoubleMap **map.
-An iterator class is automatically instantiated from the **TCollection_DoubleMapIterator **class at the time of instantiation of a **DoubleMap **map.
-**TCollection_MapHasher **class describes the functions required for a **Hasher1 **or a **Hasher2 **object.
-
-TCollection_IndexedDataMap
---------------------------
-A map to store keys with associated items and to bind an index to them.
-Each new key stored in the map is assigned an index. Indexes are incremented as keys (and items) stored in the map. A key can be found by the index, and an index can be found by the key. No key but the last can be removed, so the indexes are in the range 1...Upper where Upper is the number of keys stored in the map. An item is stored with each key.
-An entry of an **IndexedDataMap **is composed of both the key, the item and the index. An **IndexedDataMap **is an ordered map, which allows a linear iteration on its contents. It combines the interest:
+
+*TCollection_MapHasher* class describes the functions required by any *hasher*, which is to be used with a map instantiated from the **Collections** component.
+
+An iterator class is automatically instantiated at the time of instantiation of a map provided by the *Collections* component if this map is to be explored with an iterator. Note that some provided generic maps are not to be explored with an iterator but with indexes (*indexed maps*).
+
+##### TCollection_DataMap
+
+This is a map used to store keys with associated items. An entry of **DataMap** is composed of both the key and the item.
+The *DataMap* can be seen as an extended array where the keys are the indexes.
+
+*DataMap* is a generic class which depends on three parameters:
+ * **Key** is the type of key for an entry in the map,
+ * **Item** is the type of element associated with a key in the map,
+ * **Hasher*is the type of hasher on keys.
+
+Use a *DataMapIterator* iterator to explore a *DataMap* map.
+
+An iterator class is automatically instantiated from the *TCollection_DataMapIterator* generic class at the time of instantiation of a *DataMap* map.
+
+*TCollection_MapHasher* class describes the functions required for a *Hasher* object.
+
+##### TCollection_DoubleMap
+
+This is a map used to bind pairs of keys (Key1,Key2) and retrieve them in linear time.
+
+*Key1* is referenced as the first key of the *DoubleMap* and *Key2* as the second key.
+
+An entry of a *DoubleMap* is composed of a pair of two keys: the first key and the second key.
+
+*DoubleMap* is a generic class which depends on four parameters:
+ * *Key1* is the type of the first key for an entry in the map,
+ * *Key2* is the type of the second key for an entry in the map,
+ * *Hasher1* is the type of hasher on first keys,
+ * *Hasher2* is the type of hasher on second keys.
+
+Use *DoubleMapIterator* to explore a *DoubleMap* map.
+
+An iterator class is automatically instantiated from the *TCollection_DoubleMapIterator* class at the time of instantiation of a *DoubleMap* map.
+
+*TCollection_MapHasher* class describes the functions required for a *Hasher1* or a *Hasher2* object.
+
+##### TCollection_IndexedDataMap
+
+This is map to store keys with associated items and to bind an index to them.
+
+Each new key stored in the map is assigned an index. Indexes are incremented as keys (and items) stored in the map. A key can be found by the index, and an index can be found by the key. No key but the last can be removed, so the indexes are in the range 1...Upper, where *Upper* is the number of keys stored in the map. An item is stored with each key.
+
+An entry of an *IndexedDataMap* is composed of both the key, the item and the index. An *IndexedDataMap* is an ordered map, which allows a linear iteration on its contents. It combines the interest:
* of an array because data may be accessed with an index,
* and of a map because data may also be accessed with a key.
-**IndexedDataMap **is a generic class which depends on three parameters:
- * **Key **is the type of key for an entry in the map,
- * **Item **is the type of element associated with a key in the map,
- * **Hasher **is the type of hasher on keys.
+*IndexedDataMap* is a generic class which depends on three parameters:
+ * *Key* is the type of key for an entry in the map,
+ * *Item* is the type of element associated with a key in the map,
+ * *Hasher* is the type of hasher on keys.
+
+##### TCollection_IndexedMap
+
+This is map used to store keys and to bind an index to them.
-TCollection_IndexedMap
-----------------------
-A map used to store keys and to bind an index to them.
Each new key stored in the map is assigned an index. Indexes are incremented as keys stored in the map. A key can be found by the index, and an index by the key. No key but the last can be removed, so the indexes are in the range 1...Upper where Upper is the number of keys stored in the map.
-An entry of an **IndexedMap **is composed of both the key and the index. An **IndexedMap **is an ordered map, which allows a linear iteration on its contents. But no data is attached to the key. An **IndexedMap **is typically used by an algorithm to know if some action is still performed on components of a complex data structure.
-**IndexedMap **is a generic class which depends on two parameters:
- * **Key **is the type of key for an entry in the map,
- * **Hasher **is the type of hasher on keys.
-TCollection_Map
----------------
+An entry of an *IndexedMap* is composed of both the key and the index. An *IndexedMap* is an ordered map, which allows a linear iteration on its contents. But no data is attached to the key. An *IndexedMap* is typically used by an algorithm to know if some action is still performed on components of a complex data structure.
+
+*IndexedMap* is a generic class which depends on two parameters:
+ * *Key* is the type of key for an entry in the map,
+ * *Hasher* is the type of hasher on keys.
+
+##### TCollection_Map
+
+This is a basic hashed map, used to store and retrieve keys in linear time.
+
+An entry of a *Map* is composed of the key only. No data is attached to the key. A *Map* is typically used by an algorithm to know if some action is still performed on components of a complex data structure.
+
+*Map* is a generic class which depends on two parameters:
+ * *Key* is the type of key in the map,
+ * *Hasher* is the type of hasher on keys.
+
+Use a *MapIterator* iterator to explore a *Map* map.
-A basic hashed map, used to store and retrieve keys in linear time.
-An entry of a **Map **is composed of the key only. No data is attached to the key. A **Map **is typically used by an algorithm to know if some action is still performed on components of a complex data structure.
-**Map **is a generic class which depends on two parameters:
- * **Key **is the type of key in the map,
- * **Hasher **is the type of hasher on keys.
-Use a **MapIterator **iterator to explore a **Map **map.
+##### TCollection_MapHasher
+
+This is a hasher on the *keys* of a map instantiated from the *Collections* component.
-TCollection_MapHasher
----------------------
-A hasher on the *keys *of a map instantiated from the **Collections **component.
A hasher provides two functions:
- * The *hashing function *(**HashCode**) transforms a *key *into a *bucket *index in the map. The number of values that can be computed by the hashing function is equal to the number of buckets in the map.
- * **IsEqual **is the equality test between two keys. Hashers are used as parameters in generic maps provided by the **Collections **component.
-**MapHasher **is a generic class which depends on the type of keys, providing that **Key **is a type from the **Standard **package. In such cases **MapHasher **may be directly instantiated with **Key**. Note that the package **TColStd **provides some of these instantiations.
-Elsewhere, if **Key **is not a type from the **Standard **package you must consider **MapHasher **as a template and build a class which includes its functions, in order to use it as a hasher in a map instantiated from the **Collections **component.
-Note that **TCollection_AsciiString **and **TCollection_ExtendedString **classes correspond to these specifications, in consequence they may be used as hashers: when **Key **is one of these two types you may just define the hasher as the same type at the time of instantiation of your map.
+* *HashCode()* function transforms a key into a bucket index in the map. The number of values that can be computed by the hashing function is equal to the number of buckets in the map.
+* *IsEqual* is the equality test between two keys. Hashers are used as parameters in generic maps provided by the **Collections** component.
+
+*MapHasher* is a generic class which depends on the type of keys, providing that *Key* is a type from the *Standard* package. In such cases *MapHasher* may be directly instantiated with *Key*. Note that the package *TColStd* provides some of these instantiations.
+
+Elsewhere, if *Key* is not a type from the *Standard* package you must consider *MapHasher* as a template and build a class which includes its functions, in order to use it as a hasher in a map instantiated from the *Collections* component.
+
+Note that *TCollection_AsciiString* and *TCollection_ExtendedString* classes correspond to these specifications, in consequence they may be used as hashers: when *Key* is one of these two types you may just define the hasher as the same type at the time of instantiation of your map.
@subsubsection occt_fcug_3_1_4 Iterators
-TCollection_BasicMapIterator
-----------------------------
-Root class for map iterators. A map iterator provides a step by step exploration of all the entries of a map.
+#### TCollection_BasicMapIterator
-TCollection_DataMapIterator
----------------------------
-Functions used for iterating the contents of a **DataMap **map.
-A map is a non-ordered data structure. The order in which entries of a map are explored by the iterator depends on its contents and change when the map is edited.
-It is not recommended to modify the contents of a map during the iteration: the result is unpredictable.
+This is a root class for map iterators. A map iterator provides a step by step exploration of all the entries of a map.
-TCollection_DoubleMapIterator
------------------------------
-Functions used for iterating the contents of a **DoubleMap **map.
+#### TCollection_DataMapIterator
-TCollection_ListIterator
-------------------------
-Functions used for iterating the contents of a **List **data structure.
-A **ListIterator **object can be used to go through a list sequentially, and as a bookmark to hold a position in a list. It is not an index, however. Each step of the iteration gives the *current position *of the iterator, to which corresponds the *current item *in the list. The *current position *is *undefined *if the list is empty, or when the exploration is finished.
-An iterator class is automatically instantiated from this generic class at the time of instantiation of a **List **data structure.
+These are functions used for iterating the contents of a *DataMap* map.
-TCollection_MapIterator
-------------------------
-Functions used for iterating the contents of a **Map **map.
-An iterator class is automatically instantiated from this generic class at the time of instantiation of a **Map **map.
+A map is a non-ordered data structure. The order in which entries of a map are explored by the iterator depends on its contents and change when the map is edited. It is not recommended to modify the contents of a map during the iteration: the result is unpredictable.
-TCollection_SetIterator
------------------------
-Functions used for iterating the contents of a **Set **data structure.
-An iterator class is automatically instantiated from this generic class at the time of instantiation of a **Set **structure.
+#### TCollection_DoubleMapIterator
+
+These are functions used for iterating the contents of a *DoubleMap* map.
+
+#### TCollection_ListIterator
+
+These are unctions used for iterating the contents of a *List* data structure.
+
+A *ListIterator* object can be used to go through a list sequentially, and as a bookmark to hold a position in a list. It is not an index, however. Each step of the iteration gives the current position of the iterator, to which corresponds the current item in the list. The current position is not defined if the list is empty, or when the exploration is finished.
+
+An iterator class is automatically instantiated from this generic class at the time of instantiation of a *List* data structure.
+
+#### TCollection_MapIterator
+
+These are functions used for iterating the contents of a *Map* map.
+An iterator class is automatically instantiated from this generic class at the time of instantiation of a *Map* map.
+
+#### TCollection_SetIterator
+
+These are functions used for iterating the contents of a *Set* data structure.
+An iterator class is automatically instantiated from this generic class at the time of instantiation of a *Set* structure.
-TCollection_StackIterator
--------------------------
-Functions used for iterating the contents of a **Stack **data structure.
-An iterator class is automatically instantiated from this generic class at the time of instantiation of a **Stack **structure.
+#### TCollection_StackIterator
+
+These are functions used for iterating the contents of a **Stack **data structure.
+
+An iterator class is automatically instantiated from this generic class at the time of instantiation of a *Stack* structure.
@subsection occt_fcug_3_2 Collections of Standard Objects
@subsubsection occt_fcug_3_2_1 Overview
-While generic classes of the **TCollection **package are the root classes that describe the generic purpose of every type of collection, classes effectively used are extracted from the **TColStd **package.
-The **TColStd **and **TShort **packages provide frequently used instantiations of generic classes with objects from the **Standard **package or strings from the **TCollection **package.
+While generic classes of the *TCollection* package are the root classes that describe the generic purpose of every type of collection, classes effectively used are extracted from the *TColStd* package.
+The *TColStd* and *TShort* packages provide frequently used instantiations of generic classes with objects from the *Standard* package or strings from the *TCollection* package.
@subsubsection occt_fcug_3_2_2 Description
These instantiations are the following:
- * Unidimensional arrays: instantiations of the **TCollection_Array1 **generic class with **Standard **Objects and **TCollection **strings.
- * Bidimensional arrays: instantiations of the **TCollection_Array2 **generic class with **Standard **Objects.
- * Unidimensional arrays manipulated by handles: instantiations of the **TCollection_HArray1 **generic class with **Standard **Objects and **TCollection **strings.
- * Bidimensional arrays manipulated by handles: instantiations of the **TCollection_HArray2 **generic class with **Standard **Objects.
- * Sequences: instantiations of the **TCollection_Sequence **generic class with **Standard **objects and **TCollection **strings.
- * Sequences manipulated by handles: instantiations of the **TCollection_HSequence **generic class with **Standard **objects and **TCollection **strings.
- * Lists: instantiations of the **TCollection_List **generic class with **Standard **objects.
- * Queues: instantiations of the **TCollection_Queue **generic class with **Standard **objects.
- * Sets: instantiations of the **TCollection_Set **generic class with **Standard **objects.
- * Sets manipulated by handles: instantiations of the **TCollection_HSet **generic class with **Standard **objects.
- * Stacks: instantiations of the **TCollection_Stack **generic class with **Standard **objects.
- * Hashers on map keys: instantiations of the **TCollection_MapHasher **generic class with **Standard **objects.
- * Basic hashed maps: instantiations of the **TCollection_Map **generic class with **Standard **objects.
- * Hashed maps with an additional item: instantiations of the **TCollection_DataMap **generic class with **Standard **objects.
- * Basic indexed maps: instantiations of the **TCollection_IndexedMap **generic class with **Standard **objects.
- * Indexed maps with an additional item: instantiations of the **TCollection_IndexedDataMap **generic class with **Standard_Transient **objects.
- * Class **TColStd_PackedMapOfInteger** provides alternative implementation of map of integer numbers, optimized for both performance and memory usage (it uses bit flags to encode integers, which results in spending only 24 bytes per 32 integers stored in optimal case). This class also provides Boolean operations with maps as sets of integers (union, intersection, subtraction, difference, checks for equality and containment).
+ * Unidimensional arrays: instantiations of the **TCollection_Array1* generic class with *Standard* Objects and *TCollection*strings.
+ * Bidimensional arrays: instantiations of the *TCollection_Array2* generic class with *Standard* Objects.
+ * Unidimensional arrays manipulated by handles: instantiations of the *TCollection_HArray1* generic class with *Standard* Objects and *TCollection* strings.
+ * Bidimensional arrays manipulated by handles: instantiations of the *TCollection_HArray2* generic class with *Standard* Objects.
+ * Sequences: instantiations of the *TCollection_Sequence* generic class with *Standard* objects and *TCollection* strings.
+ * Sequences manipulated by handles: instantiations of the *TCollection_HSequence* generic class with *Standard* objects and *TCollection* strings.
+ * Lists: instantiations of the *TCollection_List* generic class with *Standard* objects.
+ * Queues: instantiations of the *TCollection_Queue* generic class with *Standard* objects.
+ * Sets: instantiations of the *TCollection_Set* generic class with *Standard* objects.
+ * Sets manipulated by handles: instantiations of the *TCollection_HSet* generic class with *Standard* objects.
+ * Stacks: instantiations of the *TCollection_Stack* generic class with *Standard* objects.
+ * Hashers on map keys: instantiations of the *TCollection_MapHasher* generic class with *Standard* objects.
+ * Basic hashed maps: instantiations of the *TCollection_Map* generic class with *Standard* objects.
+ * Hashed maps with an additional item: instantiations of the *TCollection_DataMap* generic class with *Standard* objects.
+ * Basic indexed maps: instantiations of the *TCollection_IndexedMap* generic class with *Standard* objects.
+ * Indexed maps with an additional item: instantiations of the *TCollection_IndexedDataMap* generic class with *Standard_Transient* objects.
+ * Class *TColStd_PackedMapOfInteger* provides alternative implementation of map of integer numbers, optimized for both performance and memory usage (it uses bit flags to encode integers, which results in spending only 24 bytes per 32 integers stored in optimal case). This class also provides Boolean operations with maps as sets of integers (union, intersection, subtraction, difference, checks for equality and containment).
@subsection occt_fcug_3_3 NCollections
@subsubsection occt_fcug_3_3_1 Overview
-NCollection package allows to not use WOK development environment in projects. Though it is quite natural to develop a code based on OCCT in any environment accepted in the industry, there is still one limitation: the so-called OCCT generic classes provided in TCollection package require compilation of the definitions in the CDL language and therefore can only be instantiated in WOK development environment.
+*NCollection* package allows to not use WOK development environment in projects. Though it is quite natural to develop a code based on OCCT in any environment accepted in the industry, there is still one limitation: the so-called OCCT generic classes provided in TCollection package require compilation of the definitions in the CDL language and therefore can only be instantiated in WOK development environment.
The NCollection library provides a full replacement of all TCollection generic classes so that any OCCT collection could be instantiated via C++ template or macro definitions. It can be used in WOK as a package development unit, or in any other configuration, since it only uses the standard capabilities of C++ compiler.
-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.
+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
-Now we are going to implement the definitions from NCollection in the code, taking as an example a sequence of points (analogue of *TColgp_SequenceOfPnt*).
+Now we are going to implement the definitions from *NCollection* in the code, taking as an example a sequence of points (analogue of *TColgp_SequenceOfPnt*).
-Definition of a new collection class
-------------------------------------
+#### Definition of a new collection class
Let the header file be *MyPackage_SequenceOfPnt.hxx* :
DEFINE_BASECOLLECTION(MyPackage_BaseCollPnt, gp_Pnt)
~~~~~
-The following line defines the class MyPackage_SequenceOfPnt
+The following line defines the class *MyPackage_SequenceOfPnt*
~~~~~
DEFINE_SEQUENCE (MyPackage_SequenceOfPnt, MyPackage_BaseCollPnt , gp_Pnt)
~~~~~
-Definition of a new collection class managed by Handle
-------------------------------------------------------
+#### Definition of a new collection class managed by Handle
It is necessary to provide relevant statements both in the header ( .hxx file) and the C++ source ( .cxx file).
DEFINE_BASECOLLECTION(MyPackage_BaseCollPnt, gp_Pnt)
~~~~~
-The following line defines the class MyPackage_SequenceOfPnt
+The following line defines the class *MyPackage_SequenceOfPnt*
~~~~~
DEFINE_SEQUENCE (MyPackage_SequenceOfPnt, MyPackage_BaseCollPnt, gp_Pnt)
~~~~~
-The following line defines the classes MyPackage_HSequenceOfPnt and Handle(MyPackage_HSequenceOfPnt)
+The following line defines the classes *MyPackage_HSequenceOfPnt* and *Handle(MyPackage_HSequenceOfPnt)*
~~~~~
DEFINE_HSEQUENCE (MyPackage_HSequenceOfPnt, MyPackage_SequenceOfPnt)
~~~~~
-Source code file will be MyPackage_HSequenceOfPnt.cxx or any other .cxx file (once in the whole project):
+Source code file will be *MyPackage_HSequenceOfPnt.cxx* or any other .cxx file (once in the whole project):
~~~~~
IMPLEMENT_HSEQUENCE (MyPackage_HSequenceOfPnt)
@subsubsection occt_fcug_3_3_3 Class architecture
-Architecture
-------------
-To understand the basic architecture of the classes instantiated from NCollection macros, please refer to the documentation on TCollection package, particularly to CDL files. Almost all API described there is preserved in NCollection. Changes are described in corresponding NCollection_Define*.hxx files.
+To understand the basic architecture of the classes instantiated from *NCollection* macros, please refer to the documentation on *TCollection* package, particularly to CDL files. Almost all API described there is preserved in *NCollection*. Changes are described in corresponding *NCollection_Define\*.hxx* files.
-Nevertheless the internal structure of NCollection classes is more complex than that of TCollection ones, providing more capabilities. The advanced layer of architecture is described in the next chapter Features.
+Nevertheless the internal structure of NCollection classes is more complex than that of *TCollection* ones, providing more capabilities. The advanced layer of architecture is described in the next chapter Features.
There are two principal changes:
-* In TCollection some classes ( Stack, List, Set, Map, DataMap, DoubleMap ) define the Iterator type, the name of Iterator being like MyPackage_DoubleMapIteratorOfDoubleMapOfIntegerReal. In NCollection each Iterator is always defined as subtype of the collection (MyPackage_DoubleMapOfIntegerReal::Iterator).
-* Hashed collections (of type Map* ) require in TCollection that the special class Map*Hasher is defined. In NCollection it is only required that the global functions IsEqual and HashCode are defined.
+* In *TCollection* some classes ( Stack, List, Set, Map, DataMap, DoubleMap ) define the Iterator type, the name of Iterator being like *MyPackage_DoubleMapIteratorOfDoubleMapOfIntegerReal*. In *NCollection* each Iterator is always defined as subtype of the collection *MyPackage_DoubleMapOfIntegerReal::Iterator*.
+* Hashed collections (of type Map\* ) require in *TCollection* that the special class *Map\*Hasher* is defined. In *NCollection* it is only required that the global functions *IsEqual* and *HashCode* are defined.
+
+#### Interface to classes defined in CDL
-Interface to classes defined in CDL
------------------------------------
-The classes defined above can be used as types for fields, parameters of methods and return values in CDL definitions. In our example, if MyPackage is a CDL package, you will need to create the file MyPackage_SequenceOfPnt.hxx containing or including the above definitions, and then to add the line: imported SequenceOfPnt to file MyPackage.cdl;
+The classes defined above can be used as types for fields, parameters of methods and return values in CDL definitions. In our example, if MyPackage is a CDL package, you will need to create the file *MyPackage_SequenceOfPnt.hxx* containing or including the above definitions, and then to add the line: imported *SequenceOfPnt* to file *MyPackage.cdl*;
Then the new collection type can be used in any CDL definition under the name *SequenceOfPnt* from *MyPackage*.
@subsubsection occt_fcug_3_3_4 New collection types
There are 4 collection types provided as template classes:
-* NCollection_Vector
-* NCollection_UBTree
-* NCollection_SparseArray
-* NCollection_CellFilter
+* *NCollection_Vector*
+* *NCollection_UBTree*
+* *NCollection_SparseArray*
+* *NCollection_CellFilter*
-Type Vector
------------
+#### Vector
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.
* _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.
-* Like in Array1, the methods Value() and ChangeValue() return a contained object by index. Also, these methods have the form of overloaded operator ().
+* Like in *List*, the method *Clear()* destroys all contained objects and releases the allocated memory.
+* Like in *Array1*, the methods *Value()* and *ChangeValue()* return a contained object by index. Also, these methods have the form of overloaded operator ().
-Type UBTree
------------
+#### UBTree
The name of this type stands for “Unbalanced Binary Tree”. It stores the members in a binary tree of overlapped bounding objects (boxes or else).
Once the tree of boxes of geometric objects is constructed, the algorithm is capable of fast geometric selection of objects. The tree can be easily updated by adding to it a new object with bounding box.
The time of adding to the tree of one object is O(log(N)), where N is the total number of objects, so the time of building a tree of N objects is O(N(log(N)). The search time of one object is O(log(N)).
-Defining various classes inheriting NCollection_UBTree::Selector we can perform various kinds of selection over the same b-tree object.
+Defining various classes inheriting *NCollection_UBTree::Selector* we can perform various kinds of selection over the same b-tree object.
-The object may be of any type allowing copying. Among the best suitable solutions there can be a pointer to an object, handled object or integer index of object inside some collection. The bounding object may have any dimension and geometry. The minimal interface of TheBndType (besides public empty and copy constructor and operator =) used in UBTree algorithm as follows:
+The object may be of any type allowing copying. Among the best suitable solutions there can be a pointer to an object, handled object or integer index of object inside some collection. The bounding object may have any dimension and geometry. The minimal interface of *TheBndType* (besides public empty and copy constructor and operator =) used in UBTree algorithm as follows:
~~~~~
class MyBndType
inline Standard_Real SquareExtent() const;
// Computes the squared maximal linear extent of me (for a box it is the squared diagonal of the box).
};
+~~~~~
+
-This interface is implemented in types of Bnd package: Bnd_Box, Bnd_Box2d, Bnd_B2x, Bnd_B3x.
+This interface is implemented in types of Bnd package: *Bnd_Box, Bnd_Box2d, Bnd_B2x, Bnd_B3x*.
-To select objects you need to define a class derived from UBTree::Selector that should redefine the necessary virtual methods to maintain the selection condition. Usually this class instance is also used to retrieve selected objects after search.
-The class UBTreeFiller is used to randomly populate an UBTree instance. The quality of a tree is better (considering the speed of searches) if objects are added to it in a random order trying to avoid the addition of a chain of nearby objects one following another.
-Instantiation of UBTreeFiller collects objects to be added, and then adds them at once to the given UBTree instance in a random order using the Fisher-Yates algorithm.
-Below is the sample code that creates an instance of NCollection_UBTree indexed by 2D boxes (Bnd_B2f), then a selection is performed returning the objects whose bounding boxes contain the given 2D point.
+To select objects you need to define a class derived from *UBTree::Selector* that should redefine the necessary virtual methods to maintain the selection condition. Usually this class instance is also used to retrieve selected objects after search.
+The class *UBTreeFiller* is used to randomly populate a *UBTree* instance. The quality of a tree is better (considering the speed of searches) if objects are added to it in a random order trying to avoid the addition of a chain of nearby objects one following another.
+Instantiation of *UBTreeFiller* collects objects to be added, and then adds them at once to the given UBTree instance in a random order using the Fisher-Yates algorithm.
+Below is the sample code that creates an instance of *NCollection_UBTree* indexed by 2D boxes (Bnd_B2f), then a selection is performed returning the objects whose bounding boxes contain the given 2D point.
~~~~~
typedef NCollection_UBTree<MyData, Bnd_B2f> UBTree;
~~~~~
-Type SparseArray
-----------------
+#### SparseArray
+
This type has almost the same features as Vector but it allows to store items having scattered indices. In Vector, if you set an item with index 1000000, the container will allocate memory for all items with indices in the range 0-1000000. In SparseArray, only one small block of items will be reserved that contains the item with index 1000000.
-This class can be also seen as equivalence of DataMap<int,TheItemType> with the only one practical difference: it can be much less memory-expensive if items are small (e.g. Integer or Handle).
+This class can be also seen as equivalence of *DataMap<int,TheItemType>* with the only one practical difference: it can be much less memory-expensive if items are small (e.g. Integer or Handle).
This type has both interfaces of DataMap and Vector to access items.
-Type CellFilter
----------------
+#### CellFilter
This class represents a data structure for sorting geometric objects in n-dimensional space into cells, with associated algorithm for fast checking of coincidence (overlapping, intersection, etc.) with other objects. It can be considered as a functional alternative to UBTree, as in the best case it provides the direct access to an object like in an n-dimensional array, while search with UBTree provides logarithmic law access time.
NCollection defines some specific features, in addition to the public API inherited from TCollection classes.
-Iterators
----------
+#### Iterators
+
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;
....
}
}
-This feature is present only for some classes in TCollection (Stack, List, Set, Map, DataMap, DoubleMap). In NCollection it is generalized.
+~~~~~
+
+This feature is present only for some classes in *TCollection (Stack, List, Set, Map, DataMap, DoubleMap)*. In *NCollection* it is generalized.
-Class BaseCollection
---------------------
+#### Class BaseCollection
-There is a common abstract base class for all collections for a given item type (e.g., gp_Pnt). Developer X can arbitrarily name this base class like MyPackage_BaseCollPnt in the examples above. This name is further used in the declarations of any (non-abstract) collection class to designate the C++ inheritance.
+There is a common abstract base class for all collections for a given item type (e.g., gp_Pnt). Developer X can arbitrarily name this base class like *MyPackage_BaseCollPnt* in the examples above. This name is further used in the declarations of any (non-abstract) collection class to designate the C++ inheritance.
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;
+* *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:
The common point between them is that it is possible to create any number of both types of iterators on the same collection object.
-Heterogeneous Assign
---------------------
+#### Heterogeneous Assign
The semantics of the method Assign() has been changed in comparison to TCollection. In NCollection classes the method Assign() is virtual and it receives the object of the abstract BaseCollection class (see the previous section). Therefore this method can be used to assign any collection type to any other if only these collections are instantiated on the same ItemType.
Objects of classes parameterised with two types (DoubleMap, DataMap and IndexedDataMap) cannot be assigned. Their method Assign throws the exception Standard_TypeMismatch (because it is impossible to check if the passed BaseCollection parameter belongs to the same collection type).
-Allocator
----------
+#### Allocator
All constructors of NCollection classes receive the Allocator Object as the last parameter. This is an object of a type managed by Handle, inheriting NCollection_BaseAllocator, with the following (mandatory) methods redefined:
@subsection occt_fcug_3_4 Strings
-The **Strings **component provides services to manipulate character strings.
+The **Strings** component provides services to manipulate character strings.
**Strings** are classes that handle dynamically sized sequences of characters based on both ASCII (normal 8-bit character type) and Unicode (16-bit character type). They provide editing operations with built-in memory management which make the relative objects easier to use than ordinary character arrays.
-*Strings *may also be manipulated by *handle*, and therefore shared.
+*Strings* may also be manipulated by *handle*, and therefore shared.
@subsubsection occt_fcug_3_4_1 Examples
-TCollection_AsciiString
------------------------
-A variable-length sequence of ASCII characters (normal 8-bit character type). It provides editing operations with built-in memory management to make **AsciiString **objects easier to use than ordinary character arrays.
-**AsciiString **objects follow ;value semantics;, that is, they are the actual strings, not handles to strings, and are copied through assignment. You may use **HAsciiString **objects to get handles to strings.
-TCollection_ExtendedString
---------------------------
-A variable-length sequence of ;extended; (UNICODE) characters (16-bit character type). It provides editing operations with built-in memory management to make **ExtendedString **objects easier to use than ordinary extended character arrays.
-**ExtendedString **objects follow ;value semantics;, that is, they are the actual strings, not handles to strings, and are copied through assignment. You may use **HExtendedString **objects to get handles to strings.
-TCollection_HAsciiString
-------------------------
-A variable-length sequence of ASCII characters (normal 8-bit character type). It provides editing operations with built-in memory management to make **HAsciiString **objects easier to use than ordinary character arrays.
-**HAsciiString **objects are *handles *to strings.
- * **HAsciiString **strings may be shared by several objects.
- * You may use an **AsciiString **object to get the actual string.
-**HAsciiString **objects use an **AsciiString **string as a field.
-TCollection_HExtendedString
----------------------------
-A variable-length sequence of ;extended; (UNICODE) characters (16-bit character type). It provides editing operations with built-in memory management to make **ExtendedString **objects easier to use than ordinary extended character arrays.
-**HExtendedString **objects are *handles *to strings.
- * **HExtendedString **strings may be shared by several objects.
- * You may use an **ExtendedString **object to get the actual string.
-**HExtendedString **objects use an **ExtendedString **string as a field.
+#### TCollection_AsciiString
+
+A variable-length sequence of ASCII characters (normal 8-bit character type). It provides editing operations with built-in memory management to make *AsciiString* objects easier to use than ordinary character arrays.
+*AsciiString* objects follow value semantics;, that is, they are the actual strings, not handles to strings, and are copied through assignment. You may use *HAsciiString* objects to get handles to strings.
+
+#### TCollection_ExtendedString
+
+A variable-length sequence of ;extended; (UNICODE) characters (16-bit character type). It provides editing operations with built-in memory management to make *ExtendedString* objects easier to use than ordinary extended character arrays.
+
+*ExtendedString* objects follow value semantics;, that is, they are the actual strings, not handles to strings, and are copied through assignment. You may use *HExtendedString* objects to get handles to strings.
+
+#### TCollection_HAsciiString
+
+A variable-length sequence of ASCII characters (normal 8-bit character type). It provides editing operations with built-in memory management to make *HAsciiString* objects easier to use than ordinary character arrays.
+*HAsciiString* objects are *handles* to strings.
+ * *HAsciiString* strings may be shared by several objects.
+ * You may use an *AsciiString* object to get the actual string.
+*HAsciiString* objects use an *AsciiString* string as a field.
+
+#### TCollection_HExtendedString
+
+A variable-length sequence of extended; (UNICODE) characters (16-bit character type). It provides editing operations with built-in memory management to make *ExtendedString* objects easier to use than ordinary extended character arrays.
+*HExtendedString* objects are *handles* to strings.
+ * *HExtendedString* strings may be shared by several objects.
+ * You may use an *ExtendedString* object to get the actual string.
+*HExtendedString* objects use an *ExtendedString* string as a field.
@subsubsection occt_fcug_3_4_2 Conversion
Resource_Unicode
----------------
-Functions used to convert a non-ASCII *C string *given in ANSI, EUC, GB or SJIS
+Functions used to convert a non-ASCII *C string* given in ANSI, EUC, GB or SJIS
format, to a Unicode string of extended characters, and vice versa.
@subsection occt_fcug_3_5 Unit Conversion
-The **UnitsAPI **global functions are used to convert a value from any unit into another unit. Conversion is executed among three unit systems:
+The *UnitsAPI* global functions are used to convert a value from any unit into another unit. Conversion is executed among three unit systems:
* the **SI System**,
* the user’s **Local System**,
* the user’s **Current System**.
-The **SI System **is the standard international unit system. It is indicated by *SI *in the signatures of the **UnitsAPI **functions.
-The OCCT (former MDTV) System corresponds to the SI international standard but *the length unit and all its derivatives use the millimeter *instead of the meter.
-Both systems are proposed by Open CASCADE Technology; the SI System is the standard option. By selecting one of these two systems, you define your **Local System **through the **SetLocalSystem **function. The **Local System **is indicated by *LS *in the signatures of the **UnitsAPI **functions.
-The Local System units can be modified in the working environment. You define your **Current System **by modifying its units through the **SetCurrentUnit **function. The Current System is indicated by *Current *in the signatures of the **UnitsAPI **functions.
+The **SI System** is the standard international unit system. It is indicated by *SI* in the signatures of the *UnitsAPI* functions.
+
+The OCCT (former MDTV) System corresponds to the SI international standard but the length unit and all its derivatives use the millimetre instead of the meter.
+
+Both systems are proposed by Open CASCADE Technology; the SI System is the standard option. By selecting one of these two systems, you define your **Local System** through the *SetLocalSystem* function. The **Local System** is indicated by *LS* in the signatures of the *UnitsAPI* functions.
+The Local System units can be modified in the working environment. You define your **Current System** by modifying its units through the **SetCurrentUnit** function. The Current System is indicated by *Current* in the signatures of the **UnitsAPI** functions.
A physical quantity is defined by a string (example: LENGTH).
* Vectors and matrices
* Geometric primitives
* Math algorithms
+
@subsection occt_occt_fcug_4_2 Vectors and Matrices
The Vectors and Matrices component provides a C++ implementation of the fundamental types Matrix and Vector, currently used to define more complex data structures. The Vector and Matrix classes support vectors and matrices of real values with standard operations such as addition, multiplication, transposition, inversion etc.
Vectors and matrices have arbitrary ranges which must be defined at declaration time and cannot be changed after declaration.
~~~~~
Some operations on Vector and Matrix objects may not be legal. In this case an exception is raised. Two standard exceptions are used:
- * Standard_DimensionError exception is raised when two matrices or vectors involved in an operation are of incompatible dimensions.
- * Standard_RangeError exception is raised if an access outside the range definition of a vector or of a matrix is attempted.
+ * *Standard_DimensionError* exception is raised when two matrices or vectors involved in an operation are of incompatible dimensions.
+ * *Standard_RangeError* exception is raised if an access outside the range definition of a vector or of a matrix is attempted.
~~~~~~
math_Vector v1(1, 3), v2(1, 2), v3(0, 2);
~~~~~~
@subsection occt_occt_fcug_4_3 Primitive Geometric Types
-@subsubsection occt_occt_fcug_4_3_1 Overview
Before creating a geometric object, you must decide whether you are in a 2d or in a 3d context and how you want to handle the object.
-The *gp *package offers classes for both 2d and 3d objects which are handled by value rather than by reference. When this sort of object is copied, it is copied entirely. Changes in one instance will not be reflected in another.
-@subsubsection occt_occt_fcug_4_3_2 gp
-The *gp *package defines the basic non-persistent geometric entities used for algebraic calculation and basic analytical geometry in 2d & 3d space. It also provides basic transformations such as identity, rotation, translation, mirroring, scale transformations, combinations of transformations, etc. Entities are handled by value.
+The *gp* package offers classes for both 2d and 3d objects which are handled by value rather than by reference. When this sort of object is copied, it is copied entirely. Changes in one instance will not be reflected in another.
+The *gp* package defines the basic non-persistent geometric entities used for algebraic calculation and basic analytical geometry in 2d & 3d space. It also provides basic transformations such as identity, rotation, translation, mirroring, scale transformations, combinations of transformations, etc. Entities are handled by value.
The available geometric entities are:
* 2d & 3d Cartesian coordinates (x, y, z)
* Matrices
* Conical surface.
@subsection occt_occt_fcug_4_4 Collections of Primitive Geometric Types
+
Before creating a geometric object, you must decide whether you are in a 2d or in a 3d context and how you want to handle the object.
If you do not need a single instance of a geometric primitive but a set of them then the package which deals with collections of this sort of object, *TColgp*, will provide the necessary functionality.
-In particular, this package provides standard and frequently used instantiations of generic classes with geometric objects.
-@subsubsection occt_occt_fcug_4_4_1 TColgp
-The *TColgp *package provides instantiations of the TCollection classes with the classes from *gp *i.e. *XY*, *XYZ*, *Pnt*, *Pnt2d*, *Vec*, *Vec2d*, *Lin*, *Lin2d*, *Circ*, *Circ2d.*
+In particular, this package provides standard and frequently used instantiations of generic classes with geometric objects, i.e. *XY*, *XYZ*, *Pnt*, *Pnt2d*, *Vec*, *Vec2d*, *Lin*, *Lin2d*, *Circ*, *Circ2d.*
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.
-The *Precision *package describes functions for defining the precision criterion used to compare two numbers.
-@subsubsection occt_occt_fcug_4_5_1 EICLib
-Methods for analytic curves. A library of simple computations on curves from the *gp *package (Lines, Circles and Conics). Computes points with a given parameter. Computes the parameter for a point.
-@subsubsection occt_occt_fcug_4_5_2 EISLib
-Methods for analytic surfaces . A library of simple computations on surfaces from the package *gp *(Planes, Cylinders, Spheres, Cones, Tori). Computes points with a given pair of parameters. Computes the parameter for a point. There is a library for calculating normals on curves and surfaces.
-@subsubsection occt_occt_fcug_4_5_3 Bnd
-Package Bnd provides a set of classes and tools to operate with bounding boxes of geometric objects in 2d and 3d space.
+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.
+
+Additionally, *Bnd* package provides a set of classes and tools to operate with bounding boxes of geometric objects in 2d and 3d space.
+
@subsection occt_occt_fcug_4_6 Common Math Algorithms
The common math algorithms library provides a C++ implementation of the most frequently used mathematical algorithms. These include:
* Algorithms to solve a set of linear algebraic equations,
* Algorithms to find the minimum of a function of one or more independent variables,
* Algorithms to find roots of one, or of a set, of non-linear equations,
* An algorithm to find the eigenvalues and eigenvectors of a square matrix.
-@subsubsection occt_occt_fcug_4_6_1 Implementation of Algorithms
+
All mathematical algorithms are implemented using the same principles. They contain:
A constructor performing all, or most of, the calculation, given the appropriate arguments. All relevant information is stored inside the resulting object, so that all subsequent calculations or interrogations will be solved in the most efficient way.
-A function IsDone returning the boolean true if the calculation was successful.
+
+A function *IsDone* returning the boolean true if the calculation was successful.
A set of functions, specific to each algorithm, enabling all the various results to be obtained.
-Calling these functions is legal only if the function IsDone answers true, otherwise the exception StdFail_NotDone is raised.
-The example below demonstrates the use of the Gauss class, which implements the Gauss solution for a set of linear equations.The following definition is an extract from the header file of the class math_Gauss:
+Calling these functions is legal only if the function *IsDone* answers **true**, otherwise the exception *StdFail_NotDone* is raised.
+
+The example below demonstrates the use of the Gauss class, which implements the Gauss solution for a set of linear equations.The following definition is an extract from the header file of the class *math_Gauss*:
~~~~~~
class Gauss {
public:
- Gauss (const math_Matrix& A);
- Standard_Boolean IsDone() const;
- void Solve (const math_Vector& B,
- math_Vector& X) const;
+ Gauss (const math_Matrix& A);
+ Standard_Boolean IsDone() const;
+ void Solve (const math_Vector& B,
+ math_Vector& X) const;
};
~~~~~~
#include <math_Matrix.hxx>
main ()
{
- math_Vector a(1, 3, 1, 3);
- math_Vector b1(1, 3), b2(1, 3);
- math_Vector x1(1, 3), x2(1, 3);
- // a, b1 and b2 are set here to the appropriate values
- math_Gauss sol(a); // computation of the
- // LU decomposition of A
- if(sol.IsDone()) { // is it OK ?
- sol.Solve(b1, x1); // yes, so compute x1
- sol.Solve(b2, x2); // then x2
- ...
- }
- else { // it is not OK:
- // fix up
- sol.Solve(b1, x1); // error:
- // StdFail_NotDone is raised
- }
+ math_Vector a(1, 3, 1, 3);
+ math_Vector b1(1, 3), b2(1, 3);
+ math_Vector x1(1, 3), x2(1, 3);
+ // a, b1 and b2 are set here to the appropriate values
+ math_Gauss sol(a); // computation of the
+ // LU decomposition of A
+ if(sol.IsDone()) { // is it OK ?
+ sol.Solve(b1, x1); // yes, so compute x1
+ sol.Solve(b2, x2); // then x2
+ ...
+ }
+ else { // it is not OK:
+ // fix up
+ sol.Solve(b1, x1); // error:
+ // StdFail_NotDone is raised
+ }
}
~~~~~
-The next example demonstrates the use of the BissecNewton class, which implements a combination of the Newton and Bissection algorithms to find the root of a function known to lie between two bounds.The definition is an extract from the header file of the class math_BissecNewton:
+The next example demonstrates the use of the *BissecNewton* class, which implements a combination of the Newton and Bissection algorithms to find the root of a function known to lie between two bounds. The definition is an extract from the header file of the class *math_BissecNewton*:
~~~~~
class BissecNewton {
};
~~~~~
-The abstract class math_FunctionWithDerivative describes the services which have to be implemented for the function f which is to be used by a BissecNewton algorithm. The following definition corresponds to the header file of the abstract class math_FunctionWithDerivative:
+The abstract class *math_FunctionWithDerivative* describes the services which have to be implemented for the function f which is to be used by a *BissecNewton* algorithm. The following definition corresponds to the header file of the abstract class *math_FunctionWithDerivative*:
~~~~~
class math_FunctionWithDerivative {
};
~~~~~
-Now the test sample uses the BissecNewton class to find the root of the equation f(x)=x**2-4 in the interval [1.5, 2.5]:the function to solve is implemented in the class myFunction which inherits from the class math_FunctionWithDerivative,then the main program finds the required root.
+Now the test sample uses the *BissecNewton* class to find the root of the equation *f(x)=x**2-4* in the interval [1.5, 2.5]: the function to solve is implemented in the class *myFunction* which inherits from the class *math_FunctionWithDerivative*, then the main program finds the required root.
~~~~~
#include <math_BissecNewton.hxx>
#include <math_FunctionWithDerivative.hxx>
class myFunction : public math_FunctionWithDerivative
{
- Standard_Real coefa, coefb, coefc;
-
- public:
- myFunction (const Standard_Real a, const Standard_Real b,
- const Standard_Real c) :
- coefa(a), coefb(b), coefc(c)
- {}
-
- virtual Standard_Boolean Value (const Standard_Real x,
- Standard_Real& f)
- {
- f = coefa * x * x + coefb * x + coefc;
- }
-
- virtual Standard_Boolean Derivative (const Standard_Real x,
- Standard_Real& d)
- {
- d = coefa * x * 2.0 + coefb;
- }
-
- virtual Standard_Boolean Values (const Standard_Real x,
- Standard_Real& f, Standard_Real& d)
- {
- f = coefa * x * x + coefb * x + coefc;
- d = coefa * x * 2.0 + coefb;
- }
+ Standard_Real coefa, coefb, coefc;
+
+ public:
+ myFunction (const Standard_Real a, const Standard_Real b,
+ const Standard_Real c) :
+ coefa(a), coefb(b), coefc(c)
+ {}
+
+ virtual Standard_Boolean Value (const Standard_Real x,
+ Standard_Real& f)
+ {
+ f = coefa * x * x + coefb * x + coefc;
+ }
+
+ virtual Standard_Boolean Derivative (const Standard_Real x,
+ Standard_Real& d)
+ {
+ d = coefa * x * 2.0 + coefb;
+ }
+
+ virtual Standard_Boolean Values (const Standard_Real x,
+ Standard_Real& f, Standard_Real& d)
+ {
+ f = coefa * x * x + coefb * x + coefc;
+ d = coefa * x * 2.0 + coefb;
+ }
};
main()
{
- myFunction f(1.0, 0.0, 4.0);
- math_BissecNewton sol(F, 1.5, 2.5, 0.000001);
+ myFunction f(1.0, 0.0, 4.0);
+ math_BissecNewton sol(F, 1.5, 2.5, 0.000001);
if(Sol.IsDone()) { // is it OK ?
- Standard_Real x = sol.Root(); // yes.
- }
- else { // no
- }
+ Standard_Real x = sol.Root(); // yes.
+ }
+ else { // no
+ }
~~~~~
@subsection occt_occt_fcug_4_7 Precision
On the OCCT platform, each object stored in the database should carry its own precision value. This is important when dealing with systems where objects are imported from other systems as well as with various associated precision values.
-The *Precision *package addresses the daily problem of the geometric algorithm developer: what precision setting to use to compare two numbers. Real number equivalence is clearly a poor choice. The difference between the numbers should be compared to a given precision setting.
+
+The *Precision* package addresses the daily problem of the geometric algorithm developer: what precision setting to use to compare two numbers. Real number equivalence is clearly a poor choice. The difference between the numbers should be compared to a given precision setting.
+
Do not write _if (X1 == X2),_ instead write _if (Abs(X1-X2) < Precision)._
+
Also, to order real numbers, keep in mind that _if (X1 < X2 - Precision)_ is incorrect.
-_if (X2 - X1 > Precision)_ is far better when *X1 *and *X2 *are high numbers.
+_if (X2 - X1 > Precision)_ is far better when *X1* and *X2* are high numbers.
+
This package proposes a set of methods providing precision settings for the most commonly encountered situations.
+
In Open CASCADE Technology, precision is usually not implicit; low-level geometric algorithms accept precision settings as arguments. Usually these should not refer directly to this package.
+
High-level modeling algorithms have to provide a precision setting to the low level geometric algorithms they call. One way is to use the settings provided by this package. The high-level modeling algorithms can also have their own strategy for managing precision. As an example the Topology Data Structure stores precision values which are later used by algorithms. When a new topology is created, it takes the stored value.
-Different precision settings offered by this package cover the most common needs of geometric algorithms such as *Intersection *and *Approximation*.
+Different precision settings offered by this package cover the most common needs of geometric algorithms such as *Intersection* and *Approximation*.
The choice of a precision value depends both on the algorithm and on the geometric space. The geometric space may be either:
- * a ;real; space, 3d or 2d where the lengths are measured in meters, micron, inches, etc.
- * a ;parametric; space, 1d on a curve or 2d on a surface where numbers have no dimension.
+ * a real space, 3d or 2d where the lengths are measured in meters, micron, inches, etc.
+ * a parametric space, 1d on a curve or 2d on a surface where numbers have no dimension.
The choice of precision value for parametric space depends not only on the accuracy of the machine, but also on the dimensions of the curve or the surface.
This is because it is desirable to link parametric precision and real precision. If you are on a curve defined by the equation *P(t)*, you would want to have equivalence between the following:
~~~~~
@subsubsection occt_occt_fcug_4_7_1 The Precision package
-The Precision package offers a number of package methods and default precisions for use in dealing with angles, distances, intersections, approximations, and parametric space.
+The *Precision* package offers a number of package methods and default precisions for use in dealing with angles, distances, intersections, approximations, and parametric space.
It provides values to use in comparisons to test for real number equalities.
* Angular precision compares angles.
* Confusion precision compares distances.
* Intersection precision is used by intersection algorithms.
* Approximation precision is used by approximation algorithms.
* Parametric precision gets a parametric space precision from a 3D precision.
- * *Infinite *returns a high number that can be considered to be infinite. Use *-Infinite *for a high negative number.
+ * *Infinite* returns a high number that can be considered to be infinite. Use *-Infinite* for a high negative number.
@subsubsection occt_occt_fcug_4_7_2 Standard Precision values
This package provides a set of real space precision values for algorithms. The real space precisions are designed for precision to *0.1* nanometers. The only unit available is the millimeter.
-The parametric precisions are derived from the real precisions by the *Parametric *function. This applies a scaling factor which is the length of a tangent to the curve or the surface. You, the user, provide this length. There is a default value for a curve with *[0,1] *parameter space and a length less than 100 meters.
+The parametric precisions are derived from the real precisions by the *Parametric* function. This applies a scaling factor which is the length of a tangent to the curve or the surface. You, the user, provide this length. There is a default value for a curve with *[0,1]* parameter space and a length less than 100 meters.
The geometric packages provide Parametric precisions for the different types of curves.
-The Precision package provides methods to test whether a real number can be considered to be infinite.
+The *Precision* package provides methods to test whether a real number can be considered to be infinite.
+
+#### Precision::Angular
-Precision::Angular
-------------------
This method is used to compare two angles. Its current value is *Epsilon(2 * PI) *i.e. the smallest number *x *such that *2*PI + x *is different of *2* PI*.
It can be used to check confusion of two angles as follows:
It is also possible to check parallelism of two vectors (_Vec_ from _gp_) as follows _V1.IsParallel(V2,Precision::Angular())_
-Note that *Precision::Angular()* can be used on both dot and cross products because for small angles the *Sine* and the *Angle* are equivalent. So to test if two directions of type *gp*_*Dir* are perpendicular, it is legal to use the following code:
+Note that *Precision::Angular()* can be used on both dot and cross products because for small angles the *Sine* and the *Angle* are equivalent. So to test if two directions of type *gp\*_\*Dir* are perpendicular, it is legal to use the following code:
_Abs(D1 * D2) < Precision::Angular()_
-Precision::Confusion
---------------------
+#### Precision::Confusion
+
This method is used to test 3D distances. The current value is *1.e-7*, in other words, 1/10 micron if the unit used is the millimeter.
It can be used to check confusion of two points (_Pnt_ from _gp_) as follows:
It is also possible to find a vector of null length (_Vec_ from _gp_) :
_V.Magnitude() < Precision::Confusion()_
-Precision::Intersection
------------------------
+#### Precision::Intersection
+
This is reasonable precision to pass to an Intersection process as a limit of refinement of Intersection Points. *Intersection* is high enough for the process to converge quickly. *Intersection* is lower than *Confusion* so that you still get a point on the intersected geometries. The current value is *Confusion() / 100*.
-Precision::Approximation
-------------------------
+#### Precision::Approximation
+
This is a reasonable precision to pass to an approximation process as a limit of refinement of fitting. The approximation is greater than the other precisions because it is designed to be used when the time is at a premium. It has been provided as a reasonable compromise by the designers of the Approximation algorithm. The current value is *Confusion() * 10*.
Note that Approximation is greater than Confusion, so care must be taken when using Confusion in an approximation process.
@section occt_fcug_5 Data Storage
@subsection occt_fcug_5_1 Saving and Opening Files
-
+@image html /user_guides/foundation_classes/images/foundation_classes_image007.jpg "Example of Saving-Opening workflow"
+@image latex /user_guides/foundation_classes/images/foundation_classes_image007.jpg "Example of Saving-Opening workflow"
In the example, the roots of the transferable transient objects *TopoDS_Shape, Geom_Geometry* and *Geom2d_Geometry* are used in algorithms, they contain data and temporary results.
-The associated objects in the persistent domain are here PTopoDS_HShape, PGeom_Geometry and PGeom2d_Geometry. They contain a real data structure which is stored in a file.
+The associated objects in the persistent domain are *PTopoDS_HShape, PGeom_Geometry* and *PGeom2d_Geometry*. They contain a real data structure which is stored in a file.
Note that when an object is stored, if it contains another stored object, the references to the contained object are also managed.
-
+@image html /user_guides/foundation_classes/images/foundation_classes_image008.jpg "Saving-Opening mechanism"
+@image latex /user_guides/foundation_classes/images/foundation_classes_image008.jpg "Saving-Opening mechanism"
@subsection occt_fcug_5_2 Basic Storage Procedures
-That is how the storage and retrieval mechanisms work on shapes.
@subsubsection occt_fcug_5_2_1 Saving
~~~~~
Handle(ShapeSchema) s = new ShapeSchema;
~~~~~
-
-3.Create a persistent shape from a transient shape.
+3. Create a persistent shape from a transient shape.
~~~~~
TopoDS_Shape aShape;
PTColStd_TransientPersistentMap aMap;
Handle(PTopoDS_HShape) aPShape = MgtBRep::Translate
(aShape, aMap, MgtBRep_WithoutTriangle);
~~~~~
-
-4.Create a new container and fill it using the *AddRoot()* method.
+4. Create a new container and fill it using the *AddRoot()* method.
~~~~~
Handle(Storage_Data) d = new Storage_Data;
d -> AddRoot (“ObjectName”, aPShape);
~~~~~
You may add as many objects as you want in this container.
-
5. Save to the archive.
~~~~~
s -> Write (f,d);
The retrieval mechanism is the opposite of the storage mechanism. The procedure for retrieving an object is as follows:
1. Create an I/O driver and instance a data schema (if not done).
-2. Read the persistent object from the archive and get the list of objects using Roots() method.
+2. Read the persistent object from the archive and get the list of objects using *Roots()* method.
~~~~~
Handle(Storage_Data) d = s -> Read(f);
Handle(Storage_HSeqOfRoot) roots = d-> Roots();
~~~~~
-3. Loop on root objects to get Standard_Persistent objects (the following sequence only gets the first root).
+3. Loop on root objects to get *Standard_Persistent* objects (the following sequence only gets the first root).
~~~~~
Handle(Standard_Persistent) p;
Handle(Standard_Root) r;
if(roots -> Length() >= 1) {
- r = roots -> Value(1);
- p = r -> Object();
+ r = roots -> Value(1);
+ p = r -> Object();
}
~~~~~
-4. DownCast the persistent object to a PTopoDS_Hshape.
+4. DownCast the persistent object to a *PTopoDS_Hshape*.
~~~~~
Handle(PTopoDS_HShape) aPShape;
aPShape = Handle(PTopoDS_HShape)::DownCast(p);
~~~~~
-5. Create the TopoDS_Shape.
+5. Create the *TopoDS_Shape*.
~~~~~
TopoDS_Shape aShape;
-PTColStd_PersistentTransientMap aMap;
+PTColStd_PersistentTransientMap aMap;
MgtBRep::Translate (aPShape, aMap, aShape, MgtBRep_WithoutTriangle);
~~~~~
IGES Support {#user_guides__iges}
==================
-@section occt_1856844696_591811643 Introduction
+@section occt_iges_1 Introduction
+
-@subsection occt_1856844696_591811643_1 The IGES-Open CASCADE Technology processor
This manual explains how to convert an IGES file to an Open CASCADE Technology (**OCCT**) shape and vice versa. It provides basic documentation on conversion. For advanced information on conversion, see our offerings on our web site at <a href="http://www.opencascade.org/support/training/">www.opencascade.org/support/training/</a>
IGES files up to and including IGES version 5.3 can be read. IGES files that are produced by this interface conform to IGES version 5.3 (Initial Graphics Exchange Specification, IGES 5.3. ANS US PRO/IPO-100-1996).
+
This manual principally deals with two OCCT classes:
* The Reader class, which loads IGES files and translates their contents to OCCT shapes,
* The Writer class, which translates OCCT shapes to IGES entities and then writes these entities to IGES files.
+
File translation is performed in the programming mode, via C++ calls, and the resulting OCCT objects are shapes.
+
All definitions in IGES version 5.3 are recognized but only 3D geometric entities are translated. When the processor encounters data, which is not translated, it ignores it and writes a message identifying the types of data, which was not handled. This message can be written either to a log file or to screen output.
-@section occt_1856844696_804874798 Reading IGES
-@subsection occt_1856844696_804874798_1 Procedure
+
+@section occt_iges_2 Reading IGES
+@subsection occt_iges_2_1 Procedure
You can translate an IGES file to an OCCT shape by following the steps below:
-# Load the file,
-# Check file consistency,
-# Set the translation parameters,
-# Perform the file translation,
-# Fetch the results.
-@subsection occt_1856844696_804874798_2 Domain covered
-@subsubsection occt_1856844696_804874798_21 Translatable entities
+@subsection occt_iges_2_2 Domain covered
+@subsubsection occt_iges_2_2_1 Translatable entities
The types of IGES entities, which can be translated, are:
* Points
* Lines
* Structure entities (groups). Each entity in the group outputs a shape. There can be a group of groups.
* Subfigures. Each entity defined in a subfigure outputs a shape
* Transformation Matrix.
-***NOTE***
-*All non-millimeter length unit values in the IGES file are converted to millimeters.*
-@subsubsection occt_1856844696_804874798_22 Attributes
+
+**Note** that all non-millimeter length unit values in the IGES file are converted to millimeters.
+
+@subsubsection occt_iges_2_2_2 Attributes
Entity attributes in the Directory Entry Section of the IGES file (such as layers, colors and thickness) are translated to Open CASCADE Technology using XDE.
-@subsubsection occt_1856844696_804874798_23 Administrative data
+@subsubsection occt_iges_2_2_3 Administrative data
Administrative data, in the Global Section of the IGES file (such as the file name, the name of the author, the date and time a model was created or last modified) is not translated to Open CASCADE Technology. Administrative data can, however, be consulted in the IGES file.
-@subsection occt_1856844696_804874798_3 Description of the process
-@subsubsection occt_1856844696_804874798_31 Loading the IGES file
+@subsection occt_iges_2_3 Description of the process
+@subsubsection occt_iges_2_3_1 Loading the IGES file
Before performing any other operation, you have to load the file using the syntax below.
+~~~~~
IGESControl_Reader reader;
IFSelect_ReturnStatus stat = reader.ReadFile(“filename.igs”);
+~~~~~
The loading operation only loads the IGES file into computer memory; it does not translate it.
-@subsubsection occt_1856844696_804874798_32 Checking the IGES file
+
+@subsubsection occt_iges_2_3_2 Checking the IGES file
This step is not obligatory. Check the loaded file with:
+~~~~~
Standard_Boolean ok = reader.Check(Standard_True);
+~~~~~
The variable “ok is True” is returned if no fail message was found; “ok is False” is returned if there was at least one fail message.
+~~~~~
reader.PrintCheckLoad (failsonly, mode);
+~~~~~
Error messages are displayed if there are invalid or incomplete IGES entities, giving you information on the cause of the error.
+~~~~~
Standard_Boolean failsonly = Standard_True or Standard_False;
+~~~~~
If you give True, you will see fail messages only. If you give False, you will see both fail and warning messages.
-Your analysis of the file can be either message-oriented or entity-oriented. Choose your preference with:
-IFSelect_PrintCount mode = IFSelect_xxx
-Where xxx can be any of the following:
-ItemsByEntity gives a sequential list of all messages per IGES entity.
-CountByItem gives the number of IGES entities with their types per message.
-ShortByItem gives the number of IGES entities with their types per message and displays rank numbers of the first five IGES entities per message.
-ListByItem gives the number of IGES entities with their type and rank numbers per message.
-EntitiesByItem gives the number of IGES entities with their types, rank numbers and Directory Entry numbers per message.
-
-@subsubsection occt_1856844696_804874798_33 Setting translation parameters
+
+Your analysis of the file can be either message-oriented or entity-oriented. Choose your preference with *IFSelect_PrintCount mode = IFSelect_xxx*, where *xxx* can be any of the following:
+* *ItemsByEntity* gives a sequential list of all messages per IGES entity.
+* *CountByItem* gives the number of IGES entities with their types per message.
+* *ShortByItem* gives the number of IGES entities with their types per message and displays rank numbers of the first five IGES entities per message.
+* *ListByItem* gives the number of IGES entities with their type and rank numbers per message.
+* *EntitiesByItem* gives the number of IGES entities with their types, rank numbers and Directory Entry numbers per message.
+
+@subsubsection occt_iges_2_3_3 Setting translation parameters
The following parameters can be used to translate an IGES file to an OCCT shape. If you give a value that is not within the range of possible values, it will be ignored.
+
<h4>read.iges.bspline.continuity</h4>
manages the continuity of BSpline curves (IGES entities 106, 112 and 126) after translation to Open CASCADE Technology (Open CASCADE Technology requires that the curves in a model be at least C1 continuous; no such requirement is made by IGES).
-0: no change; the curves are taken as they are in the IGES file. C0 entities of Open CASCADE Technology may be produced.
-1: if an IGES BSpline, Spline or CopiousData curve is C0 continuous, it is broken down into pieces of C1 continuous Geom_BSplineCurve.
-2: This option concerns IGES Spline curves only. IGES Spline curves are broken down into pieces of C2 continuity. If C2 cannot be ensured, the Spline curves will be broken down into pieces of C1 continuity.
+* 0: no change; the curves are taken as they are in the IGES file. C0 entities of Open CASCADE Technology may be produced.
+* 1: if an IGES BSpline, Spline or CopiousData curve is C0 continuous, it is broken down into pieces of C1 continuous *Geom_BSplineCurve*.
+* 2: This option concerns IGES Spline curves only. IGES Spline curves are broken down into pieces of C2 continuity. If C2 cannot be ensured, the Spline curves will be broken down into pieces of C1 continuity.
+
Read this parameter with:
-Standard_Integer ic = Interface_Static::IVal(;read.iges.bspline.continuity;);
+~~~~~
+Standard_Integer ic = Interface_Static::IVal("read.iges.bspline.continuity");
+~~~~~
Modify this value with:
-if (!Interface_Static::SetIVal (;read.iges.bspline.continuity;,2))
+~~~~~
+if (!Interface_Static::SetIVal ("read.iges.bspline.continuity",2))
.. error ..;
+~~~~~
Default value is 1.
-*This parameter does not change the continuity of curves that are used in the construction of IGES BRep entities. In this case, the parameter does not influence the continuity of the resulting OCCT curves (it is ignored). *
+
+This parameter does not change the continuity of curves that are used in the construction of IGES BRep entities. In this case, the parameter does not influence the continuity of the resulting OCCT curves (it is ignored).
+
+
<h4>read.precision.mode</h4>
reads the precision value.
- ;File; (0) the precision value is read in the IGES file header (default).
- ;User; (1) the precision value is that of the read.precision.val parameter.
+* File (0) the precision value is read in the IGES file header (default).
+* User (1) the precision value is that of the read.precision.val parameter.
+
Read this parameter with:
-Standard_Integer ic = Interface_Static::IVal(;read.precision.mode;);
+~~~~~
+Standard_Integer ic = Interface_Static::IVal("read.precision.mode");
+~~~~~
Modify this value with:
-if (!Interface_Static::SetIVal (;read.precision.mode;,1))
+~~~~~
+if (!Interface_Static::SetIVal ("read.precision.mode",1))
.. error ..;
-Default value is ;File; (0).
+~~~~~
+Default value is *File* (0).
+
<h4>read.precision.val</h4>
-user precision value. This parameter gives the precision used during translation when the read.precision.mode parameter value is 1.
- 0.0001: default.
- any real positive (non null) value.
-This value is a basis value for computation tolerances for TopoDS_Vertex, TopoDS_Edge and TopoDS_Face entities.
+User defined precision value. This parameter gives the precision for shape construction when the read.precision.mode parameter value is 1. By default it is 0.0001, but can be any real positive (non null) value.
+
This value is in the measurement unit defined in the IGES file header.
+
Read this parameter with:
-Standard_Real rp = Interface_Static::RVal(;read.precision.val;);
+~~~~~
+Standard_Real rp = Interface_Static::RVal("read.precision.val");
+~~~~~
Modify this parameter with:
-if (!Interface_Static::SetRVal (;read.precision.val;,0.001))
+~~~~~
+if (!Interface_Static::SetRVal ("read.precision.val",0.001))
.. error ..;
+~~~~~
Default value is 0.0001.
-*The value given to this parameter is a target value that is applied to TopoDS_Vertex, TopoDS_Edge and TopoDS_Face entities. The processor does its best to reach it. Under certain circumstances, the value you give may not be attached to all of the entities concerned at the end of processing. IGES-to-OCCT translation does not improve the quality of the geometry in the original IGES file. This means that the value you enter may be impossible to attain the given quality of geometry in the IGES file.*
-Value of tolerance used for computation is calculated by multiplying the value of read.precision.val and the value of coefficient of transfer from the file units to millimeters.
+
+The value given to this parameter is a target value that is applied to *TopoDS_Vertex, TopoDS_Edge* and *TopoDS_Face* entities. The processor does its best to reach it. Under certain circumstances, the value you give may not be attached to all of the entities concerned at the end of processing. IGES-to-OCCT translation does not improve the quality of the geometry in the original IGES file. This means that the value you enter may be impossible to attain the given quality of geometry in the IGES file.
+
+Value of tolerance used for computation is calculated by multiplying the value of *read.precision.val* and the value of coefficient of transfer from the file units to millimeters.
+
<h4>read.maxprecision.mode</h4>
defines the mode of applying the maximum allowed tolerance. Its possible values are:
-;Preferred;(0) maximum tolerance is used as a limit but sometimes it can be exceeded (currently, only for deviation of a 3D curve of an edge from its pcurves and from vertices of such edge) to ensure shape validity
-;Forced;(1) maximum tolerance is used as a rigid limit, i.e. it can not be exceeded and, if this happens, tolerance is trimmed to suit the maximum-allowable value.
+
+* *Preferred(0)* maximum tolerance is used as a limit but sometimes it can be exceeded (currently, only for deviation of a 3D curve of an edge from its pcurves and from vertices of such edge) to ensure shape validity;
+* *Forced(1)* maximum tolerance is used as a rigid limit, i.e. it can not be exceeded and, if this happens, tolerance is trimmed to suit the maximum-allowable value.
+
Read this parameter with:
-Standard_Integer mv = Interface_Static::IVal(;read.maxprecision.mode;);
+~~~~~
+Standard_Integer mv = Interface_Static::IVal("read.maxprecision.mode");
+~~~~~
Modify this parameter with:
-if (!Interface_Static::SetIVal (;read.maxprecision.mode;,1))
+~~~~~
+if (!Interface_Static::SetIVal ("read.maxprecision.mode",1))
.. error ..;
-Default value is ;Preferred; (0).
+~~~~~
+Default value is *Preferred (0)*.
<h4>read.maxprecision.val</h4>
-defines the maximum allowable tolerance (in mm) of the shape. It should be not less than the basis value of tolerance set in processor (either Resolution from the file or read.precision.val). Actually, the maximum between read.maxprecision.val and basis tolerance is used to define maximum allowed tolerance.
+defines the maximum allowable tolerance (in mm) of the shape. It should be not less than the basis value of tolerance set in processor (either Resolution from the file or *read.precision.val*). Actually, the maximum between *read.maxprecision.val* and basis tolerance is used to define maximum allowed tolerance.
Read this parameter with:
-Standard_Real rp = Interface_Static::RVal(;read.maxprecision.val;);
+~~~~~
+Standard_Real rp = Interface_Static::RVal("read.maxprecision.val");
+~~~~~
Modify this parameter with:
-if (!Interface_Static::SetRVal (;read.maxprecision.val;,0.1))
+~~~~~
+if (!Interface_Static::SetRVal ("read.maxprecision.val",0.1))
.. error ..;
+~~~~~
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.
-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 IGES file or modified by BRepLib::SameParameter.
+defines the using of *BRepLib::SameParameter*. Its possible values are:
+* 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:
-Standard_Integer mv = Interface_Static::IVal(;read.stdsameparameter.mode;);
+~~~~~
+Standard_Integer mv = Interface_Static::IVal("read.stdsameparameter.mode");
+~~~~~
Modify this parameter with:
-if (!Interface_Static::SetIVal (;read.stdsameparameter.mode;,1))
+~~~~~
+if (!Interface_Static::SetIVal ("read.stdsameparameter.mode",1))
.. error ..;
-Deafault value is 0 (;Off;).
+~~~~~
+Deafault value is 0 (Off).
<h4>read.surfacecurve.mode</h4>
preference for the computation of curves in case of 2D/3D inconsistency in an entity which has both 2D and 3D representations.
-Here we are talking about entity types 141 (Boundary), 142 (CurveOnSurface) and 508 (Loop). These are entities representing a contour lying on a surface, which is translated to a TopoDS_Wire, formed by TopoDS_Edges. Each TopoDS_Edge must have a 3D curve and a 2D curve that reference the surface.
+
+Here we are talking about entity types 141 (Boundary), 142 (CurveOnSurface) and 508 (Loop). These are entities representing a contour lying on a surface, which is translated to a *TopoDS_Wire*, formed by *TopoDS_Edges*. Each *TopoDS_Edge* must have a 3D curve and a 2D curve that reference the surface.
+
The processor also decides to re-compute either the 3D or the 2D curve even if both curves are translated successfully and seem to be correct, in case there is inconsistency between them. The processor considers that there is inconsistency if any of the following conditions is satisfied:
* the number of sub-curves in the 2D curve is different from the number of sub-curves in the 3D curve. This can be either due to different numbers of sub-curves given in the IGES file or because of splitting of curves during translation.
- * 3D or 2D curve is a Circular Arc (entity type 100) starting and ending in the same point (note that this case is incorrect according to the IGES standard)
-The parameter read.surfacecurve.mode defines which curve (3D or 2D) is used for re-computing the other one:
-1. ;Default; (0): use the preference flag value in the entity's Parameter Data section. The flag values are:
+ * 3D or 2D curve is a Circular Arc (entity type 100) starting and ending in the same point (note that this case is incorrect according to the IGES standard).
+
+The parameter *read.surfacecurve.mode* defines which curve (3D or 2D) is used for re-computing the other one:
+* *Default(0)* use the preference flag value in the entity's Parameter Data section. The flag values are:
* 0: no preference given,
* 1: use 2D for 142 entities and 3D for 141 entities,
* 2: use 3D for 142 entities and 2D for 141 entities,
* 3: both representations are equally preferred.
-2. ;2DUse_Preferred; (2): the 2D is used to rebuild the 3D in case of their inconsistency,
-3. ;2DUse_Forced; (-2): the 2D is always used to rebuild the 3D (even if 2D is present in the file),
-4. ;3DUse_Preferred; (3): the 3D is used to rebuild the 2D in case of their inconsistency,
-5. ;3DUse_Forced; (-3): the 3D is always used to rebuild the 2D (even if 2D is present in the file),
-If no preference is defined (if the value of read.surfacecurve.mode is ;Default; and the value of the preference flag in the entity's Parameter Data section is 0 or 3), an additional analysis is performed.
+* *2DUse_Preferred (2)* : the 2D is used to rebuild the 3D in case of their inconsistency,
+* *2DUse_Forced (-2)*: the 2D is always used to rebuild the 3D (even if 2D is present in the file),
+* *3DUse_Preferred (3)*: the 3D is used to rebuild the 2D in case of their inconsistency,
+* *3DUse_Forced (-3)*: the 3D is always used to rebuild the 2D (even if 2D is present in the file),
+
+If no preference is defined (if the value of *read.surfacecurve.mode* is *Default* and the value of the preference flag in the entity's Parameter Data section is 0 or 3), an additional analysis is performed.
+
The 3D representation is preferred to the 2D in two cases:
* if 3D and 2D contours in the file have a different number of curves,
* if the 2D curve is a Circular Arc (entity type 100) starting and ending in the same point and the 3D one is not.
+
In any other case, the 2D representation is preferred to the 3D.
If either a 3D or a 2D contour is absent in the file or cannot be translated, then it is re-computed from another contour. If the translation of both 2D and 3D contours fails, the whole curve (type 141 or 142) is not translated. If this curve is used for trimming a face, the face will be translated without this trimming and will have natural restrictions.
+
Read this parameter with:
-Standard_Integer ic = Interface_Static::IVal(;read.surfacecurve.mode;);
+~~~~~
+Standard_Integer ic = Interface_Static::IVal("read.surfacecurve.mode");
+~~~~~
Modify this value with:
-if (!Interface_Static::SetIVal (;read.surfacecurve.mode;,3))
+~~~~~
+if (!Interface_Static::SetIVal ("read.surfacecurve.mode",3))
.. error ..;
-Default value is ;Default; (0).
+~~~~~
+Default value is Default (0).
+
<h4>read.encoderegularity.angle</h4>
-This parameter is used within the BRepLib::EncodeRegularity() function which is called for a shape read from an IGES or a STEP file at the end of translation process. This function sets the regularity flag of an edge in a shell when this edge is shared by two faces. This flag shows the continuity, which these two faces are connected with at that edge.
+This parameter is used within the *BRepLib::EncodeRegularity()* function which is called for a shape read from an IGES or a STEP file at the end of translation process. This function sets the regularity flag of an edge in a shell when this edge is shared by two faces. This flag shows the continuity, which these two faces are connected with at that edge.
+
Read this parameter with:
-Standard_Real era = Interface_Static::RVal(;read.encoderegularity.angle;);
+~~~~~
+Standard_Real era = Interface_Static::RVal("read.encoderegularity.angle");
+~~~~~
Modify this parameter with:
-if (!Interface_Static::SetRVal (;read.encoderegularity.angle;,0.1))
+~~~~~
+if (!Interface_Static::SetRVal ("read.encoderegularity.angle",0.1))
.. error ..;
+~~~~~
Default value is 0.01.
+
<h4>read.iges.bspline.approxd1.mode</h4>
This parameter is obsolete (it is rarely used in real practice). If set to True, it affects the translation of bspline curves of degree 1 from IGES: these curves (which geometrically are polylines) are split by duplicated points, and the translator attempts to convert each of the obtained parts to a bspline of a higher continuity.
+
Read this parameter with:
-Standard_Real bam = Interface_Static::CVal(;read.iges.bspline.approxd1.mode;);
+~~~~~
+Standard_Real bam = Interface_Static::CVal("read.iges.bspline.approxd1.mode");
+~~~~~
Modify this parameter with:
-if (!Interface_Static::SetRVal (;read.encoderegularity.angle;,;On;))
+~~~~~
+if (!Interface_Static::SetRVal ("read.encoderegularity.angle","On"))
.. error ..;
+~~~~~
Default value is Off.
-<h4>read.iges.resource.name</h4>
-<h4>read.iges.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 IGES translator. The Shape Processing is a user-configurable step, which is performed after the translation and consists in application of a set of operators to a resulting shape. This is a very powerful tool allowing to customize the shape and to adapt 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 IGES translator.
-Please find an example of the resource file for IGES (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 %CASROOT%/src/XSTEPResource/IGES ($CASROOT/src/XSTEPResource/IGES).
-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.
+
+
+<h4>read.iges.resource.name and read.iges.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 IGES translator. The Shape Processing is a user-configurable step, which is performed after the translation and consists in application of a set of operators to a resulting shape. This is a very powerful tool allowing to customize the shape and to adapt it to the needs of a receiving application. By default, the sequence consists of a single operator *ShapeFix* that calls Shape Healing from the IGES translator.
+
+Please find an example of the resource file for IGES (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/IGES</i> .
+
+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.
+
<h4>read.scale.unit</h4>
-This parameter is obsolete (the parameter xstep.cascade.unit should be used instead when necessary). If it is set to 'M', the shape is scaled 0.001 times (as if it were in meters) after translation from IGES or STEP.
-Default value is MM.
+This parameter is obsolete (the parameter *xstep.cascade.unit* should be used instead when necessary). If it is set to 'M', the shape is scaled 0.001 times (as if it were in meters) after translation from IGES or STEP.
+
+Default value is MM.
+
<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.
+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.
+
Default value is MM.
-@subsubsection occt_1856844696_804874798_34 Selecting entities
-A list of entities can be formed by invoking the method IGESControl_Reader::GiveList.
+
+@subsubsection occt_iges_2_3_4 Selecting entities
+
+A list of entities can be formed by invoking the method *IGESControl_Reader::GiveList*.
+~~~~~
Handle(TColStd_HSequenceOfTransient) list = reader.GiveList();
+~~~~~
Several predefined operators can be used to select a list of entities of a specific type.
-To make a selection, you use the method IGESControl_Reader::GiveList with the selection type in quotation marks as an argument. You can also make cumulative selections. For example, you would use the following syntax:
-1. Requesting the faces in the file:
-faces = Reader.GiveList(;iges-faces;);
-2. Requesting the visible roots in the file
-visibles = Reader.GiveList(;iges-visible-roots;);
-3. Requesting the visible faces
-visfac = Reader.GiveList(;iges-visible-roots;,faces);
+To make a selection, you use the method *IGESControl_Reader::GiveList* with the selection type in quotation marks as an argument. You can also make cumulative selections. For example, you would use the following syntax:
+1. Requesting the faces in the file:
+~~~~~
+faces = Reader.GiveList("iges-faces");
+~~~~~
+2. Requesting the visible roots in the file:
+~~~~~
+visibles = Reader.GiveList(iges-visible-roots);
+~~~~~
+3. Requesting the visible faces:
+~~~~~
+visfac = Reader.GiveList(iges-visible-roots,faces);
+~~~~~
Using a signature, you can define a selection dynamically, filtering the string by means of a criterion. When you request a selection using the method GiveList, you can give either a predefined selection or a selection by signature. You make your selection by signature using the predefined signature followed by your criterion in parentheses as shown in the example below. The syntaxes given are equivalent to each other.
+~~~~~
faces = Reader.GiveList(“xst-type(SurfaceOfRevolution)”);
faces = Reader.GiveList(“iges-type(120)”);
+~~~~~
You can also look for:
* values returned by your signature which match your criterion exactly
+~~~~~
faces = Reader.GiveList(“xst-type(=SurfaceOfRevolution)”);
+~~~~~
* values returned by your signature which do not contain your criterion
+~~~~~
faces = Reader.GiveList(“xst-type(!SurfaceOfRevolution)”);
+~~~~~
* values returned by your signature which do not exactly match your criterion.
+~~~~~
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.
-@subsubsection occt_1856844696_804874798_35 Performing the IGES file translation
+ * *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:
-1. Translate an entity identified by its rank with:
+1. Translate an entity identified by its rank with:
+~~~~~
Standard_Boolean ok = reader.Transfer (rank);
--# 2. Translate an entity identified by its handle with:
+~~~~~
+2. Translate an entity identified by its handle with:
+~~~~~
Standard_Boolean ok = reader.TransferEntity (ent);
-3. Translate a list of entities in one operation with:
+~~~~~
+3. Translate a list of entities in one operation with:
+~~~~~
Standard_Integer nbtrans = reader.TransferList (list);
reader.IsDone();
- nbtrans returns the number of items in the list that produced a shape.
- reader.IsDone() indicates whether at least one entity was translated.
-4. Translate a list of entities, entity by entity:
+~~~~~
+where *nbtrans* returns the number of items in the list that produced a shape and *reader.IsDone()* indicates whether at least one entity was translated.
+4. Translate a list of entities, entity by entity:
+~~~~~
Standard_Integer i,nb = list-Length();
- for (i = 1; i = nb; i ++) {
- Handle(Standard_Transient) ent = list-Value(i);
- Standard_Boolean OK = reader.TransferEntity (ent);
- }
-5. Translate the whole file (all entities or only visible entities) with:
+for (i = 1; i = nb; i ++) {
+ Handle(Standard_Transient) ent = list-Value(i);
+ Standard_Boolean OK = reader.TransferEntity (ent);
+}
+~~~~~
+5. Translate the whole file (all entities or only visible entities) with:
+~~~~~
Standard_Boolean onlyvisible = Standard_True or Standard_False;
reader.TransferRoots(onlyvisible)
-@subsubsection occt_1856844696_804874798_36 Getting the translation results
+~~~~~
+
+@subsubsection occt_iges_2_36 Getting the translation results
Each successful translation operation outputs one shape. A series of translations gives a series of shapes.
-Each time you invoke TransferEntity, Transfer or Transferlist, their results are accumulated and NbShapes increases. You can clear the results (Clear function) between two translation operations, if you do not do this, the results from the next translation will be added to the accumulation. TransferRoots operations automatically clear all existing results before they start.
+Each time you invoke *TransferEntity, Transfer* or *Transferlist*, their results are accumulated and NbShapes increases. You can clear the results (Clear function) between two translation operations, if you do not do this, the results from the next translation will be added to the accumulation. *TransferRoots* operations automatically clear all existing results before they start.
+~~~~~
Standard_Integer nbs = reader.NbShapes();
+~~~~~
returns the number of shapes recorded in the result.
+~~~~~
TopoDS_Shape shape = reader.Shape(num);,
-returns the result num, where num is an integer between 1 and NbShapes.
+~~~~~
+returns the result *num,* where *num* is an integer between 1 and *NbShapes*.
+~~~~~
TopoDS_Shape shape = reader.Shape();
+~~~~~
returns the first result in a translation operation.
+~~~~~
TopoDS_Shape shape = reader.OneShape();
+~~~~~
returns 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.
+~~~~~
reader.Clear();
+~~~~~
erases the existing results.
+~~~~~
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.
-@subsection occt_1856844696_804874798_4 Mapping of IGES entities to Open CASCADE Technology shapes
-***NOTE***
-*IGES entity types that are not given in the following tables are not translatable.*
-@subsubsection occt_1856844696_804874798_41 Points
-@subsubsection occt_1856844696_804874798_42 Curves
-Curves, which form the 2D of face boundaries, are translated as Geom2D_Curves (Geom2D circles, etc.).
+~~~~~
+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.
+
+@subsection occt_iges_2_4 Mapping of IGES entities to Open CASCADE Technology shapes
+
+*NOTE* that IGES entity types that are not given in the following tables are not translatable.
-The type of OCCT shapes (either TopDS_Edges or TopoDS_Wires) that result from the translation of IGES entities 106, 112 and 126 depends on the continuity of the curve in the IGES file and the value of the read.iges.bspline.continuity translation parameter.
-@subsubsection occt_1856844696_804874798_43 Surfaces
+@subsubsection occt_iges_2_4_1 Points
+
+| IGES entity type | CASCADE shape | Comments |
+
+| ----------------: | -------------: | ---------: |
+
+| 116: Point | TopoDS_Vertex |
+
+@subsubsection occt_iges_2_4_2 Curves
+Curves, which form the 2D of face boundaries, are translated as *Geom2D_Curves* (Geom2D circles, etc.).
+
+IGES entity type CASCADE shape Comments
+100: Circular Arc TopoDS_Edge
+ The geometrical support is:
+- a Geom_Circle,
+- or a Geom_TrimmedCurve.
+A Geom_TrimmedCurve is output if the arc is not closed.
+102: Composite Curve
+ TopoDS_Wire
+ The resulting shape is always a TopoDS_Wire that is built from a set of TopoDS_Edges.
+Each TopoDS_Edge is connected to the preceding and to the following edge by a common TopoDS_Vertex.
+104: Conic Arc TopoDS_Edge The geometric support depends on whether the IGES entity's form is:
+- 0 (Geom_Circle),
+- 1 (Geom_Ellipse),
+- 2 (Geom_Hyperbola),
+- or 3 (Geom_Parabola).
+A Geom_TrimmedCurve is output if the arc is not closed.
+106: Copious Data TopoDS_Edge or TopoDS_Wire IGES entity Copious Data (type 106, forms 1-3) is translated just as the IGES entities Linear Path (106/11-13) and the Simple Closed Planar Curve (106/63). Vectors applying to forms other than 11,12 or 63 are ignored.
+The Geom_BSplineCurve (geometrical support) has C0 continuity.
+If the Copious Data has vectors (DataType = 3) they will be ignored.
+110: Line TopoDS_Edge The supporting curve is a Geom_TrimmedCurve whose basis curve is a Geom_Line.
+112: Parametric Spline Curve TopoDS_Edge or TopoDS_Wire The geometric support is a Geom_BsplineCurve.
+126: BSpline Curve TopoDS_Edge or TopoDS_Wire
+130: Offset Curve TopoDS_Edge or TopoDS_Wire
+ The resulting shape is a TopoDS_Edge or a TopoDS_Wire (depending on the translation of the basis curve) whose geometrical support is a Geom_OffsetCurve built from a basis Geom_Curve.
+Limitation: The IGES Offset Type value must be 1.
+141: Boundary TopoDS_Wire Same behavior as for the Curve On Surface (see below).
+The translation of a non-referenced Boundary IGES entity in a BoundedSurface IGES entity outputs a TopoDS_Edge or a TopoDS_Wire with a Geom_Curve.
+142: Curve On Surface TopoDS_Wire Each TopoDS_Edge is defined by a 3D curve and by a 2D curve that references the surface.
+
+The type of OCCT shapes (either *TopDS_Edges* or *TopoDS_Wires*) that result from the translation of IGES entities 106, 112 and 126 depends on the continuity of the curve in the IGES file and the value of the *read.iges.bspline.continuity* translation parameter.
+
+@subsubsection occt_iges_2_4_3 Surfaces
Translation of a surface outputs either a TopoDS_Face or a TopoDS_Shell.
If a TopoDS_Face is output, its geometrical support is a Geom_Surface and its outer and inner boundaries (if it has any) are TopoDS_Wires.
-@subsubsection occt_1856844696_804874798_44 Boundary Representation Solid Entities
-@subsubsection occt_1856844696_804874798_45 Structure Entities
-@subsubsection occt_1856844696_804874798_46 Subfigures
+IGES entity type CASCADE shape Comments
+108: Plane
+ TopoDS_Face
+ The geometrical support for the TopoDS_Face is a Geom_Plane and the orientation of its TopoDS_Wire depends on whether it is an outer TopoDS_Wire or whether it is a hole.
+114: Parametric Spline Surface TopoDS_Face The geometrical support of a TopoDS_Face is a Geom_BSplineSurface.
+118: Ruled Surface
+ TopoDS_Face
+ or
+TopoDS_Shell The translation of a Ruled Surface outputs:
+- a TopoDS_Face if the profile curves become TopoDS_Edges,
+- a TopoDS_Shell if the profile curves become TopoDS_Wires.
+
+Limitation: This translation cannot be completed when these two TopoDS_Wires are oriented in different directions.
+120: Surface Of Revolution TopoDS_Face
+ or
+TopoDS_Shell
+ The translation of a Surface Of Revolution outputs:
+- a TopoDS_Face if the generatrix becomes a TopoDS_Edge,
+- a TopoDS_Shell if the generatrix becomes a TopoDS_Wire.
+The geometrical support may be:
+ - a Geom_CylindricalSurface,
+ - a Geom_ConicalSurface,
+ - a Geom_SphericalSurface,
+ - a Geom_ToroidalSurface
+ - or a Geom_SurfaceOfRevolution
+depending on the result of the CASCADE computation (based on the generatrix type).
+122: Tabulated Cylinder TopoDS_Face
+ or
+TopoDS_Shell
+ The translation outputs:
+- a TopoDS_Face if the base becomes a TopoDS_Edge,
+- a TopoDS_Shell if the base becomes a TopoDS_Wire.
+
+The geometrical support may be:
+- a Geom_Plane,
+- a Geom_Cylindrical Surface,
+- a Geom_SurfaceOfLinearExtrusion
+depending on the result of the CASCADE computation (based on the generatrix type).
+The Geom_Surface geometrical support is limited according to the generatrix.
+128: BSpline Surface TopoDS_Face The geometrical support of the TopoDS_Face is a Geom_BsplineSurface.
+140: Offset Surface TopoDS_Face
+
+ The translation of an Offset Surface outputs a TopoDS_Face whose geometrical support is a Geom_OffsetSurface.
+
+Limitations:
+For OCCT algorithms, the original surface must be C1-continuous so that the Geom_OffsetSurface can be created.
+If the basis surface is not C1-continuous, its translation outputs a TopoDS_Shell and only the first TopoDS_Face in the TopoDS_Shell is offset.
+143: Bounded Surface TopoDS_Face or TopoDS_Shell If the basis surface outputs a TopoDS_Shell (that has more than one TopoDS_Face), the IGES boundaries are not translated.
+
+Limitations:
+If the bounding curves define holes, natural bounds are not created.
+If the orientation of the contours is wrong, it is not corrected.
+144: Trimmed Surface TopoDS_Face
+or TopoDS_Shell
+ For the needs of interface processing, the basis surface must be a face.
+Shells are only processed if they are single-face.
+The contours (wires that are correctly oriented according to the definition of the IGES 142: Curve On Surface entity) are added to the face that is already created.
+If the orientation of the contours is wrong, it is corrected.
+190: Plane Surface TopoDS_Face
+ This type of IGES entity can only be used in BRep entities in place of an IGES 108 type entity.
+The geometrical support of the face is a Geom_Plane.
+
+
+
+@subsubsection occt_iges_2_4_4 Boundary Representation Solid Entities
+
+IGES entity type CASCADE shape Comments
+186: ManifoldSolid TopoDS_Solid
+514: Shell TopoDS_Shell
+510: Face TopoDS_Face This is the lowest IGES entity in the BRep structure that can be specified as a starting point for translation.
+508: Loop TopoDS_Wire
+504: Edge List
+502: Vertex List
+
+
+@subsubsection occt_iges_2_4_5 Structure Entities
+
+IGES entity type CASCADE shape Comments
+402/1: Associativity Instance: Group with back pointers
+ TopoDS_Compound
+402/7: Associativity Instance: Group without back pointers TopoDS_Compound
+402/9: Associativity Instance: Single Parent
+ TopoDS_Face
+ The translation of a SingleParent entity is only performed for 402 form 9 with entities 108/1 and 108/-1.
+The geometrical support for the TopoDS_Face is a Geom_Plane with boundaries:
+- the parent plane defines the outer boundary,
+- child planes define the inner boundaries.
+
+
+
+@subsubsection occt_iges_2_4_6 Subfigures
+
+IGES entity type CASCADE shape Comments
+308: Subfigure Definition TopoDS_Compound This IGES entity is only translated when there are no Singular Subfigure Instance entities.
+408: Singular Subfigure Instance TopoDS_Compound This shape has the Subfigure Definition Compound as its origin and is positioned in space by its translation vector and its scale factor.
-@subsubsection occt_1856844696_804874798_47 Transformation Matrix
-@subsection occt_1856844696_804874798_5 Messages
+
+
+@subsubsection occt_iges_2_4_7 Transformation Matrix
+
+IGES entity type CASCADE shape Comments
+124: Transformation Matrix Geom_Transformation This entity is never translated alone. It must be included in the definition of another entity.
+
+
+@subsection occt_iges_2_5 Messages
Messages are displayed concerning the normal functioning of the processor (transfer, loading, etc.).
You must declare an include file:
+~~~~~
#includeInterface_DT.hxx
+~~~~~
+
You have the choice of the following options for messages:
+~~~~~
IDT_SetLevel (level);
+~~~~~
level modifies the level of messages:
* 0: no messages
* 1: raise and fail messages are displayed, as are messages concerning file access,
* 2: warnings are also displayed.
+~~~~~
IDT_SetFile (“tracefile.log”);
+~~~~~
prints the messages in a file,
+~~~~~
IDT_SetStandard();
+~~~~~
restores screen output.
-@subsection occt_1856844696_804874798_6 Tolerance management
-@subsubsection occt_1856844696_804874798_61 Values used for tolerances during reading IGES
+
+@subsection occt_iges_2_6 Tolerance management
+@subsubsection occt_iges_2_6_1 Values used for tolerances during reading IGES
+
During the transfer of IGES to Open CASCADE Technology several parameters are used as tolerances and precisions for different algorithms. Some of them are computed from other using specific functions.
+
<h4>3D (spatial) tolerances</h4>
-<h5>Package method Precision::Confusion</h5>
-The value is 10-7. It is used as a minimal distance between points, which are considered distinct.
-<h5>Resolution in the IGES file</h5>
-This parameter is defined in the Global section of an IGES file. It is used as a fundamental value of precision during the transfer.
-<h5>User-defined variable read.precision.val</h5>
-It is to be used instead of resolution from the file when parameter read.precision.mode is 1 (“User”).
-<h5>Field EpsGeom of the class IGESToBRep_CurveAndSurface</h5>
-This value is a basic precision for translating an IGES object. It is set for each object of class IGESToBRep_CurveAndSurface and its derived classes. It is initialized for the root of transfer either by value of resolution from the file or by value of read.precision.val*,* depending on the value of read.precision.mode parameter. Returned by call to method IGESToBRep_CurvAndSurface::GetEpsGeom*.*
-NOTE: Since this value is in measurement units of the IGES file, it is usually multiplied by the coefficient UnitFactor (returned by method IGESToBRep_CurvAndSurface::GetUnitFactor) to convert it to Open CASCADE Technology units.
-<h5>Field MaxTol of the class IGESToBRep_CurveAndSurface</h5>
-This value is used as the maximum tolerance for some algorithms.
-Currently, it is computed as the maximum between 1 and GetEpsGeom*GetUnitFactor.
-This field is returned by method IGESToBRep_CurvAndSurface::GetMaxTol*.*
+
+* Package method *Precision::Confusion* equal to 10<sup>-7</sup> is used as a minimal distance between points, which are considered distinct.
+* Resolution in the IGES file is defined in the Global section of an IGES file. It is used as a fundamental value of precision during the transfer.
+* User-defined variable *read.precision.val* can be used instead of resolution from the file when parameter *read.precision.mode* is set to 1 ("User").
+* Field *EpsGeom* of the class *IGESToBRep_CurveAndSurface* is a basic precision for translating an IGES object. It is set for each object of class *IGESToBRep_CurveAndSurface* and its derived classes. It is initialized for the root of transfer either by value of resolution from the file or by value of *read.precision.val*, depending on the value of *read.precision.mode* parameter. It is returned by call to method *IGESToBRep_CurvAndSurface::GetEpsGeom*. As this value belongs to measurement units of the IGES file, it is usually multiplied by the coefficient *UnitFactor* (returned by method *IGESToBRep_CurvAndSurface::GetUnitFactor*) to convert it to Open CASCADE Technology units.
+* Field *MaxTol* of the class *IGESToBRep_CurveAndSurface* is used as the maximum tolerance for some algorithms. Currently, it is computed as the maximum between 1 and <i>GetEpsGeom*GetUnitFactor</i>. This field is returned by method *IGESToBRep_CurvAndSurface::GetMaxTol*.
+
<h4>2D (parametric) tolerances</h4>
-<h5>Package method Precision::PConfusion</h5>
-This is value 0.01*Precision::Confusion = 10-9. It is used to compare parametric bounds of curves.
-<h5>Field EpsCoeff of the class IGESToBRep_CurveAndSurface</h5>
-This value is a parametric precision for translating an IGES object. It is set for each object of class IGESToBRep_CurveAndSurface and its derived classes. Currently, it always has its default value 10-6. It is returned by call to method IGESToBRep_CurvAndSurface::GetEpsCoeff*.* This value is used for translating 2d objects (for instance, parametric curves).
-<h5>Methods UResolution(tolerance3d), VResolution(tolerance3d) of the class GeomAdaptor_Surface or BRepAdaptor_Surface</h5>
-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.*
-<h5>Methods Resolution(tolerance3d) of the class GeomAdaptor_Curve or BRepAdaptor_Curve</h5>
-Return tolerance in the parametric space of a curve computed from 3d tolerance.
+
+* Package method *Precision::PConfusion* equal to <i> 0.01*Precision::Confusion</i>, i.e. 10<sup>-9</sup>. It is used to compare parametric bounds of curves.
+* Field *EpsCoeff* of the class *IGESToBRep_CurveAndSurface* is a parametric precision for translating an IGES object. It is set for each object of class *IGESToBRep_CurveAndSurface* and its derived classes. Currently, it always has its default value 10<sup>-6</sup>. It is returned by call to method *IGESToBRep_CurvAndSurface::GetEpsCoeff*. This value is used for translating 2d objects (for instance, parametric curves).
+* Methods *UResolution(tolerance3d)* 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 the parametric space of a curve computed from 3d tolerance.
+
<h4>Zero-dimensional tolerances</h4>
-<h5>Field Epsilon of the class IGESToBRep_CurveAndSurface</h5>
-Value is set for each object of class IGESToBRep_CurveAndSurface. Returned by call to method GetEpsilon*.* It is used in comparing angles and converting transformation matrices. In most cases, it is reset to a fixed value (10-5 - 10-3) right before use. Default value is 10-4.
-@subsubsection occt_1856844696_804874798_62 Initial setting of tolerances in translating objects
-Transfer starts from one entity treated as a root (either the actual root in the IGES file or an entity selected by the user). The function which performs the transfer (that is IGESToBRep_Actor::Transfer or IGESToBRep_Reader::Transfer) creates an object of the type IGESToBRep_CurveAndSurface, which is intended for translating geometry.
-This object contains three tolerances: Epsilon, EpsGeom and EpsCoeff.
-Parameter Epsilon is set by default to value 10-4. In most cases when it is used in the package IGESToBRep, it is reset to a fixed value, either 10-5 or 10-4 or 10-3. It is used as precision when comparing angles and transformation matrices and does not have influence on the tolerance of the resulting shape.
-Parameter EpsGeom is set right after creating a IGESToBRep_CurveAndSurface object to the value of resolution, taken either from the Global section of an IGES file, or from the XSTEP.readprecision.val parameter*,* depending on the value of XSTEP.readprecision.mode.
-Parameter EpsCoeff is set by default to 10-6 and is not changed.
-During the transfer of a shape, new objects of type IGESToBRep_CurveAndSurface are created for translating subshapes. All of them have the same tolerances as the root object.
-@subsubsection occt_1856844696_804874798_63 Transfer process
+* Field *Epsilon* of the class *IGESToBRep_CurveAndSurface* is set for each object of class *IGESToBRep_CurveAndSurface* and returned by call to method *GetEpsilon*. It is used in comparing angles and converting transformation matrices. In most cases, it is reset to a fixed value (10<sup>-5</sup> - 10<sup>-3</sup>) right before use. The default value is 10<sup>-4</sup>.
+
+@subsubsection occt_iges_2_6_2 Initial setting of tolerances in translating objects
+
+Transfer starts from one entity treated as a root (either the actual root in the IGES file or an entity selected by the user). The function which performs the transfer (that is *IGESToBRep_Actor::Transfer* or *IGESToBRep_Reader::Transfer*) creates an object of the type *IGESToBRep_CurveAndSurface*, which is intended for translating geometry.
+
+This object contains three tolerances: *Epsilon, EpsGeom* and *EpsCoeff*.
+
+Parameter *Epsilon* is set by default to value 10<sup>-4</sup>. In most cases when it is used in the package *IGESToBRep*, it is reset to a fixed value, either 10<sup>-5</sup> or 10<sup>-4</sup> or 10<sup>-3</sup>. It is used as precision when comparing angles and transformation matrices and does not have influence on the tolerance of the resulting shape.
+
+Parameter *EpsGeom* is set right after creating a *IGESToBRep_CurveAndSurface* object to the value of resolution, taken either from the Global section of an IGES file, or from the *XSTEP.readprecision.val* parameter, depending on the value of *XSTEP.readprecision.mode*.
+
+Parameter *EpsCoeff* is set by default to 10<sup>-6</sup> and is not changed.
+
+During the transfer of a shape, new objects of type *IGESToBRep_CurveAndSurface* are created for translating subshapes. All of them have the same tolerances as the root object.
+
+@subsubsection occt_iges_2_6_3 Transfer process
<h4>Translating into Geometry</h4>
-Geometrical entities are translated by classes IGESToBRep_BasicCurve and IGESToBRep_BasicSurface. Methods of these classes convert curves and surfaces of an IGES file to Open CASCADE Technology geometry objects:
-Geom_Curve, Geom_Surface, Geom_Transformation
+Geometrical entities are translated by classes *IGESToBRep_BasicCurve* and *IGESToBRep_BasicSurface*. Methods of these classes convert curves and surfaces of an IGES file to Open CASCADE Technology geometry objects: *Geom_Curve, Geom_Surface,* and *Geom_Transformation*.
+
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:
-<h5>Class IGESToBRep_BasicCurve</h5>
-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-3 (in the IGESToBRep_BasicCurve::TransferTransformation the value 10-5 is used).
- * IGESToBRep_BasicCurve::TransferBSplineCurve
-All weights of BSplineCurve are assumed to be more than Precision::PConfusion (else the curve is not translated).
-<h5>Class IGESToBRep_BasicSurface</h5>
-All parameters and points are compared with precision EpsGeom.
-All transformations are fulfilled with precision Epsilon, which is set to 10-3.
- * 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>
+
IGES entities represented as topological shapes and geometrical objects are translated into OCCT shapes by use of the following classes:
IGESToBRep_TopoCurve, IGESToBRep_TopoSurface, IGESToBRep_BRepEntity, ShapeFix_Wire
Class IGESToBRep_BRepEntity is intended for transferring BRep entities (IGES version ³ 5.1) while the two former are used for translating geometry and topology defined in IGES 5.1. Methods from IGESToBRep_BRepEntity call methods from IGESToBRep_TopoCurve and IGESToBRep_TopoSurface, while those call methods from IGESToBRep_BasicCurve and IGESToBRep_BasicSurface in order to translate IGES geometry into OCCT geometry.
After performing a simple mapping, shape-healing algorithms are called (class ShapeFix_Shape) by IGESToBRep_Actor::Transfer(). A shape-healing algorithm performs the correction of a resulting OCCT shape.
Class ShapeFix_Wire can increase the tolerance of a shape. This class is used in IGESToBRep_BRepEntity::TransferLoop*,* IGESToBRep_TopoCurve::TransferBoundaryOnFace and IGESToBRep_TopoCurve::TransferCurveOnFace for correcting a wire. The maximum possible tolerance which edges or vertices will have after invoking the methods of this class is MaxTolerance (set by method ShapeFix_Wire::MaxTolerance()).
-@subsection occt_1856844696_804874798_7 Code architecture
-@subsubsection occt_1856844696_804874798_71 List of the classes
+@subsection occt_iges_2_7 Code architecture
+@subsubsection occt_iges_2_71 List of the classes
<h5>Package IGESControl</h5>
IGESControl_Reader
<h5>Package IGESToBRep</h5>
IGESToBRep_BRepEntity
<h5>Package IGESConvGeom</h5>
For description of classes, refer to CDL.
-@subsubsection occt_1856844696_804874798_72 List of API classes
+@subsubsection occt_iges_2_72 List of API classes
<h5>package IGESControl</h5>
IGESControl_Reader
<h5>package IGESToBRep</h5>
class IGESData_IGESModel
class IGESData_IGESEntity
For details, refer to 4 API for reading/writing IGES and CDL.
-@subsubsection occt_1856844696_804874798_73 Graph of calls
+@subsubsection occt_iges_2_73 Graph of calls
The following diagram illustrates the structure of calls in reading IGES.
The highlighted classes produce OCCT geometry.
-
+@image html /user_guides/iges/images/iges_image003.jpg
+@image latex /user_guides/iges/images/iges_image003.jpg
-@subsection occt_1856844696_804874798_8 Example
+@subsection occt_iges_2_8 Example
#include “IGESControl_Reader.hxx”
#include “TColStd_HSequenceOfTransient.hxx”
#include “TopoDS_Shape.hxx”
nTransFaces = myIgesReader.TransferList(myList);
//translates MyList,
-cout“IGES Faces: “nIgesFaces“ Transferred:”nTransFacesendl;
+cout“IGES Faces: “nIgesFaces“ Transferred:”nTransFacesendl;
TopoDS_Shape sh = myIgesReader.OneShape();
//and obtains the results in an OCCT shape.
}
<h4>write.iges.brep.mode: </h4>
gives the choice of the write mode. You can choose the following write modes:
-;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 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.
Read this parameter with:
Standard_Integer byvalue = Interface_Static::IVal(;write.iges.brep.mode;);
Modify this parameter with:
Default value is ;; (empty).
<h4>write.precision.mode:</h4>
specifies the mode of writing the resolution value into the IGES file.
-;Least; (-1): resolution value is set to the minimum tolerance of all edges and all vertices in an OCCT shape,
-;Average; (0): resolution value is set to average between the average tolerance of all edges and the average tolerance of all vertices in an OCCT shape (default),
-;Greatest; (1): resolution value is set to the maximum tolerance of all edges and all vertices in an OCCT shape,
-;Session; (2): resolution value is that of the write.precision.val parameter.
+;Least; (-1): resolution value is set to the minimum tolerance of all edges and all vertices in an OCCT shape,
+;Average; (0): resolution value is set to average between the average tolerance of all edges and the average tolerance of all vertices in an OCCT shape (default),
+;Greatest; (1): resolution value is set to the maximum tolerance of all edges and all vertices in an OCCT shape,
+;Session; (2): resolution value is that of the write.precision.val parameter.
Read this parameter with:
Standard_Integer ic = Interface_Static::IVal(;write.precision.mode;);
Modify this parameter with:
Default value is ;Average; (0).
<h4>write.precision.val:</h4>
user precision value. This parameter gives the resolution value for an IGES file when the write.precision.mode parameter value is 1.
- 0.0001: default
- any real positive (non null) value.
+ 0.0001: default
+ any real positive (non null) value.
Read this parameter with:
Standard_Real rp = Interface_Static::RVal(;write.precision.val;);
Modify this parameter with:
@subsubsection occt_1856844696_87424368363 Graph of calls
The following diagram illustrates the class structure in writing IGES.
The highlighted classes are intended to translate geometry.
- <table>
- <tr>
- <td>
-
- </td>
- </tr>
- <tr>
- <td>
-
- </td>
- <td>
- 
- </td>
- </tr>
-</table>
+
+ @image html /user_guides/iges/images/iges_image004.jpg
+ @image latex /user_guides/iges/images/iges_image004.jpg
+
@subsection occt_1856844696_8742436837 Example
#include IGESControl_Controller.hxx
#include IGESControl_Writer.hxx
#include TopoDS_Shape.hxx
Standard_Integer main()
{
- IGESControl_Controller::Init();
- IGESControl_Writer ICW (;MM;, 0);
- //creates a writer object for writing in Face mode with millimeters
- TopoDS_Shape sh;
- ICW.AddShape (sh);
- //adds shape sh to IGES model
- ICW.ComputeModel();
- Standard_Boolean OK = ICW.Write (;MyFile.igs;);
- //writes a model to the file MyFile.igs
+ IGESControl_Controller::Init();
+ IGESControl_Writer ICW (;MM;, 0);
+ //creates a writer object for writing in Face mode with millimeters
+ TopoDS_Shape sh;
+ ICW.AddShape (sh);
+ //adds shape sh to IGES model
+ ICW.ComputeModel();
+ Standard_Boolean OK = ICW.Write (;MyFile.igs;);
+ //writes a model to the file MyFile.igs
}
@section occt_1856844696_1288309531 API for reading/writing IGES
@subsection occt_1856844696_12883095311 Overview
Purpose: Initializes the use of IGES (if modefnes is False) or FNES (if modefnes is True) norm.
<h5>Method for performing initialization</h5>
IGESControl:: Init
-static Standard_Boolean Init() ;
+static Standard_Boolean Init() ;
Purpose: Performs standard initialization creating controller objects for both IGES and FNES norm.
Returns True when done, False if an error occurred.
<h5>Method for creating IGES model</h5>
Purpose: Returns the actor object for reading (actually, it is of type IGESToBRep_Actor) with a set parameter of spline continuity taken from static parameter.
<h5>Method for translating an Open CASCADE Technology shape</h5>
IGESControl:: TransferWriteShape
-virtual IFSelect_ReturnStatus TransferWriteShape(const TopoDS_Shape& shape, const Handle(Transfer_FinderProcess)& FP, const Handle(Interface_InterfaceModel)& model, const Standard_Integer modetrans = 0) const;
+virtual IFSelect_ReturnStatus TransferWriteShape(const TopoDS_Shape& shape, const Handle(Transfer_FinderProcess)& FP, const Handle(Interface_InterfaceModel)& model, const Standard_Integer modetrans = 0) const;
Purpose: Translates shape into the interface model.
modetrans: 0 - group of Faces (IGES 5.1) , 1 - for BRep (IGES = 5.1)
Returns:
-IFSelect_RetDone: OK,
+IFSelect_RetDone: OK,
IFSelect_RetError: if modetrans is not equal to 0 or 1, or model is not an IGES model.
-IFSelect_Fail: if shape is null.
+IFSelect_Fail: if shape is null.
@subsubsection occt_1856844696_128830953123 Class IGESControl_Reader
<h4>General description</h4>
<h4>Methods</h4>
<h5>Constructors: </h5>
* IGESControl_Reader ();
-Purpose: Creates a reader from scratch and with a new WorkSession object.
+Purpose: Creates a reader from scratch and with a new WorkSession object.
* IGESControl_Reader (const Handle(XSControl_WorkSession)& WS,
- const Standard_Boolean scratch);
+ const Standard_Boolean scratch);
Purpose: Defines work session for the reader. If scratch is True the new model will be created in the work session.
<h5>Methods for dealing with WorkSession object </h5>
* IGESControl_Reader::SetWS
void SetWS ( const Handle(XSControl_WorkSession)& WS,
- const Standard_Boolean scratch = Standard_True);
+ const Standard_Boolean scratch = Standard_True);
Purpose: Defines the work session for the reader.
- If scratch is True the new model will be created in the work session object.
+ If scratch is True the new model will be created in the work session object.
* IGESControl_Reader::WS
Handle_XSControl_WorkSession() const;
Purpose: Returns the used work session object.
IFSelect_ReturnStatus ReadFile(const Standard_CString filename);
Purpose: Loads and memorizes an IGES file in memory.
Returns:
-IFSelect_RetDone: the file was successfully read
-IFSelect_RetVoid: no file found
+IFSelect_RetDone: the file was successfully read
+IFSelect_RetVoid: no file found
IFSelect_RetError: an error occurred during reading
See also:
- IGESToBRep_Reader::LoadFile()
+ IGESToBRep_Reader::LoadFile()
<h5>Methods for selecting entities to transfer</h5>
* IGESControl_Reader::GiveList
* if first is a name of a selection in work session and second is not defined - the standard result of this selection,
* if first is a name of a selection and second is defined - the criterion defined by second is applied to result of first selection
Remarks:
- if second is erroneous it is ignored.
+ if second is erroneous it is ignored.
Handle_TColStd_HSequenceOfTransient GiveList( const Standard_CString first, const Handle(Standard_Transient)& ent) ;
Purpose: Returns a list of entities from the model according to the following rules:
- * if first is a selection name and second is an entity or a list of entities (as a HSequenceOfTransient) - the standard result of this selection is applied to this list.
+ * if first is a selection name and second is an entity or a list of entities (as a HSequenceOfTransient) - the standard result of this selection is applied to this list.
Remarks:
- if first is erroneous, a null handle is returned.
+ if first is erroneous, a null handle is returned.
<h5>Methods for performing translation</h5>
* IGESControl_Reader::TransferEntity
Standard_Boolean TransferEntity(const Handle(Standard_Transient)& start) ;
* IGESControl_Reader:: PrintCheckLoad
void PrintCheckLoad( const Standard_Boolean failsonly, const IFSelect_PrintCount mode) const ;
Purpose: Displays the check results on file entities.
-If failsonly is True prints only « Fail » messages, otherwise all messages.
+If failsonly is True prints only "Fail" messages, otherwise all messages.
mode determines the contents and the order of messages:
-IFSelect_ItemsByEntity - sequential list of messages per entity,
-IFSelect_CountByItem - counts the number of entities per message,
-IFSelect_ShortByItem - the same function but also of the first five entities,
-IFSelect_ListByItem - the same but displays the rank numbers of all (not only five) entities,
+IFSelect_ItemsByEntity - sequential list of messages per entity,
+IFSelect_CountByItem - counts the number of entities per message,
+IFSelect_ShortByItem - the same function but also of the first five entities,
+IFSelect_ListByItem - the same but displays the rank numbers of all (not only five) entities,
IFSelect_EntitiesByItem - the same plus it displays the Directory Entry number for each entity
* IGESControl_Reader:: PrintCheckTransfer
void PrintCheckTransfer( const Standard_Boolean failsonly, const IFSelect_PrintCount mode) const;
Purpose: Creates a writer object with the default unit and write mode (Face).
* IGESControl_Writer( const Standard_CString unit, const Standard_Integer modecr = 0 );
Purpose: Creates a writer object with the given values for the unit and write mode.
-unit is the name of the units that are accepted by IGES in the upper case (« IN » or « INCH » for inches, « MM » for millimeters and so on),
+unit is the name of the units that are accepted by IGES in the upper case ("IN" or "INCH" for inches, "MM" for millimeters and so on),
modecr corresponds to write mode:
0 - Face (default),
1 - BRep
* IGESControl_Writer( const Handle(IGESData_IGESModel)& model,
- const Standard_Integer modecr = 0);
+ const Standard_Integer modecr = 0);
Purpose: Creates a writer object with an already prepared IGES model and write mode.
<h5>Methods dealing with IGES models</h5>
* IGESControl_Writer:: Model
Purpose: Performs the translation of an entity specified by its rank number.
Creates an object of class IGESToBRep_CurveAndSurface and sets:
3D precision (taking its value either from the file or from the work session in accordance with the static parameter read.precision.mode),
-the approximation mode parameter in accordance with static the parameter read.iges.bspline.approxd1.mode,
+the approximation mode parameter in accordance with static the parameter read.iges.bspline.approxd1.mode,
the mode for a preferred computation of curves on a surface in accordance with the static parameter read.surfacecurve.mode,
the spline continuity parameter in accordance with the static parameter read.iges.bspline.continuity,
the transfer process object taken from itself.
Once all the fields have been filled out this method calls method TransferGeometry() with the IGES entity calculated by its rank number to obtain the OCCT shape.
-Like method TransferRoots() this one also limits the tolerance if the static parameter read.maxprecision.mode is set to 1.
+Like method TransferRoots() this one also limits the tolerance if the static parameter read.maxprecision.mode is set to 1.
Returns False if num is greater than the number of entities in the model or less than 1, otherwise returns True even if there was an exception during the transfer.
<h5>Methods for fetching the results</h5>
* IGESToBRep_Reader:: IsDone
Purpose: Clears the Start section.
* IGESData_IGESModel::SetStartSection
void SetStartSection(const Handle(TColStd_HSequenceOfHAsciiString)& list, const Standard_Boolean copy = Standard_True) ;
-Purpose: Sets a new Start section from the list of strings list, copying it if copy is True (by default) or pointing to the list if copy is False.
+Purpose: Sets a new Start section from the list of strings list, copying it if copy is True (by default) or pointing to the list if copy is False.
* IGESData_IGESModel::AddStartLine
void AddStartLine(const Standard_CString line, const Standard_Integer atnum = 0) ;
Purpose: Adds a new string to the end of the existing Start section if atnum is 0 or not given, or before the atnum-th line.
Purpose: Sets the Color. If ent is null the DefColor is set to rank, otherwise it is set to a negative value.
* IGESData_IGESEntity::InitStatus
void InitStatus( const Standard_Integer blank,
- const Standard_Integer subordinate,
- const Standard_Integer useflag,
- const Standard_Integer hierarchy) ;
+ const Standard_Integer subordinate,
+ const Standard_Integer useflag,
+ const Standard_Integer hierarchy) ;
Purpose: Sets the flags of the Directory Part.
* IGESData_IGESEntity::SetLabel
void SetLabel( const Handle(TCollection_HAsciiString)& label, const Standard_Integer sub = -1) ;
Purpose: Sets a new Label to an Entity. If sub is given, it sets the value of SubScriptNumber, else SubScriptNumber is erased.
* IGESData_IGESEntity::InitMisc
void InitMisc( const Handle(IGESData_IGESEntity)& str,
- const Handle(IGESData_LabelDisplayEntity)& lab,
- const Standard_Integer weightnum) ;
+ const Handle(IGESData_LabelDisplayEntity)& lab,
+ const Standard_Integer weightnum) ;
Purpose: Sets data or erases it if it is given as null (zero for weightnum):
- str for Structure,
- lab for LabelDisplay,
- weightnum for WeightNumber
+ str for Structure,
+ lab for LabelDisplay,
+ weightnum for WeightNumber
* IGESData_IGESEntity::SetLineWeight
void SetLineWeight( const Standard_Real defw,
- const Standard_Real maxw,
- const Standard_Integer gradw) ;
-Purpose: Computes and sets the ;true; line weight according to IGES rules from the global data MaxLineWeight (maxw) and LineWeightGrad (gradw), or sets it to defw (Default) if LineWeightNumber is null
+ const Standard_Real maxw,
+ const Standard_Integer gradw) ;
+Purpose: Computes and sets the ;true; line weight according to IGES rules from the global data MaxLineWeight (maxw) and LineWeightGrad (gradw), or sets it to defw (Default) if LineWeightNumber is null
Remarks: If gradw is zero, there is division by zero in this method.
<h5>Methods for querying the corresponding fields of an IGES entity. </h5>
* IGESData_IGESEntity::IGESType
* IGESData_IGESEntity::DirFieldEntity
Handle_IGESData_IGESEntity DirFieldEntity(const Standard_Integer fieldnum) const;
Purpose: Returns the Entity that is recorded for a given Field Number fieldnum where:
- 3 - Structure
- 4 - LineFont
- 5 - LevelList
- 6 - View
- 7 - Transf(ormation Matrix)
- 8 - LabelDisplay
- 13 - Color.
- In a case of other values it returns a null handle.
+ 3 - Structure
+ 4 - LineFont
+ 5 - LevelList
+ 6 - View
+ 7 - Transf(ormation Matrix)
+ 8 - LabelDisplay
+ 13 - Color.
+ In a case of other values it returns a null handle.
* IGESData_IGESEntity::HasStructure
Standard_Boolean HasStructure() const;
Purpose: Returns LineFont definition as an integer if it is defined as Rank. If LineFont is defined as an Entity, returns a negative value
* IGESData_IGESEntity::LineFont
Handle_IGESData_LineFontEntity LineFont() const;
-Purpose: Returns LineFont as an entity if it is defined as Reference. Returns a null handle if DefLineFont is not ;DefReference;.
+Purpose: Returns LineFont as an entity if it is defined as Reference. Returns a null handle if DefLineFont is not ;DefReference;.
* IGESData_IGESEntity::DefLevel
IGESData_DefList DefLevel() const;
Purpose: Returns the definition status of Level.
Purpose: Returns Level definition as an integer.
* IGESData_IGESEntity::LevelList
Handle_IGESData_LevelListEntity LevelList() const;
-Purpose: Returns LevelList if Level is defined as List. Returns a null handle if DefLevel is not ;DefSeveral;.
+Purpose: Returns LevelList if Level is defined as List. Returns a null handle if DefLevel is not ;DefSeveral;.
* IGESData_IGESEntity::DefView
IGESData_DefList DefView() const;
Purpose: Returns the definition status of View (None,One or Several).
* IGESData_IGESEntity::SingleView
Handle_IGESData_ViewKindEntity SingleView() const;
-Purpose: Returns View as Single, if defined as One. Returns a null handle if DefView is not ;DefOne;.
+Purpose: Returns View as Single, if defined as One. Returns a null handle if DefView is not ;DefOne;.
* IGESData_IGESEntity::ViewList
Handle_IGESData_ViewKindEntity ViewList() const;
Purpose: Returns View as a List. Returns a null handle if DefView is not ;DefSeveral;.
* IGESData_IGESEntity::LineWeight
Standard_Real LineWeight() const;
-Purpose: Returns ;true; LineWeight, computed from LineWeightNumber and the global parameter of the Model by call to SetLineWeight.
+Purpose: Returns ;true; LineWeight, computed from LineWeightNumber and the global parameter of the Model by call to SetLineWeight.
* IGESData_IGESEntity::DefColor
IGESData_DefType DefColor() const;
Purpose: Returns the definition status of Color.
Purpose: Returns the Color definition as an Integer (if defined as Rank). If Color is defined as an Entity, returns a negative value.
* IGESData_IGESEntity::Color
Handle_IGESData_ColorEntity Color() const;
-Purpose: Returns the Color as an Entity (if defined as Reference) or a null handle if Color Definition is not ;DefReference;.
+Purpose: Returns the Color as an Entity (if defined as Reference) or a null handle if Color Definition is not ;DefReference;.
* IGESData_IGESEntity::CResValues
Standard_Boolean CResValues( const Standard_CString res1,
- const Standard_CString res2) const;
-Purpose: Fills res1 and res2 with inner ;reserved; alphanumeric fields theRes1 and theRes2. Returns False if both are blank, otherwise returns True.
+ const Standard_CString res2) const;
+Purpose: Fills res1 and res2 with inner ;reserved; alphanumeric fields theRes1 and theRes2. Returns False if both are blank, otherwise returns True.
Warning: Both must be of a length equal to at least 9 characters. The contents of res1 and res2 are modofied. The 9-th character becomes null.
* IGESData_IGESEntity::HasShortLabel
Standard_Boolean HasShortLabel() const;
Purpose: Returns the Translation part of a local location (as for Location).
* IGESData_IGESEntity::CompoundLocation()
gp_GTrsf CompoundLocation() const;
-Purpose: Returns the location of this object combined with CompoundLocation of its Parent (i.e. can be recursive). If the Parent is not single (see HasOneParent) returns Location.
+Purpose: Returns the location of this object combined with CompoundLocation of its Parent (i.e. can be recursive). If the Parent is not single (see HasOneParent) returns Location.
* IGESData_IGESEntity::HasName()
Standard_Boolean HasName() const;
-Purpose: Says if a Name is defined as Short Label or as Name Property. (Property is looked for first, otherwise ShortLabel is considered).
+Purpose: Says if a Name is defined as Short Label or as Name Property. (Property is looked for first, otherwise ShortLabel is considered).
* IGESData_IGESEntity::NameValue()
Handle_TCollection_HAsciiString NameValue() const;
-Purpose: Returns the Name value as a String (Property Name or ShortLabel). If SubNumber is defined, it is concatenated after ShortLabel as follows - label (number). Ignored in case of Property Name.
+Purpose: Returns the Name value as a String (Property Name or ShortLabel). If SubNumber is defined, it is concatenated after ShortLabel as follows - label (number). Ignored in case of Property Name.
<h5>Methods for dealing with associativities and properties.</h5>
* IGESData_IGESEntity::ArePresentAssociativities()
Standard_Boolean ArePresentAssociativities() const;
Purpose: Returns the Associativity List in the form of an EntityIterator.
* IGESData_IGESEntity::NbTypedAssociativities
Standard_Integer NbTypedAssociativities
- const Handle(Standard_Type)& atype) const;
+ const Handle(Standard_Type)& atype) const;
Purpose: Returns information on how many Associativities have the given type.
* IGESData_IGESEntity::TypedAssociativity
Handle_IGESData_IGESEntity TypedAssociativity
- (const Handle(Standard_Type)& atype) const;
+ (const Handle(Standard_Type)& atype) const;
Purpose: Returns the Associativity of a given Type (if one exists)
Exceptions: Interface_InterfaceError if there is none or more than one associativity.
* IGESData_IGESEntity::AddAssociativity
Purpose: Returns the Property List in the form of an EntityIterator
* IGESData_IGESEntity::NbTypedProperties
Standard_Integer NbTypedProperties
- (const Handle(Standard_Type)& atype) const;
+ (const Handle(Standard_Type)& atype) const;
Purpose: Returns information on how many Properties have a given type
* IGESData_IGESEntity::TypedProperty
Handle_IGESData_IGESEntity TypedProperty
- (const Handle(Standard_Type)& atype) const;
+ (const Handle(Standard_Type)& atype) const;
Purpose: Returns the Property of a given Type (if only one exists)
Exceptions: Interface_InterfaceError if there is none or more than one Properties.
* IGESData_IGESEntity::AddProperty
@subsubsection occt_1856844696_33248912314 Performing the translation of an IGES file to XDE
The following function performs a translation of the whole document:
Standard_Boolean ok = reader.Transfer(doc);
-where ;doc; is a variable which contains a handle to the output document and should have a type Handle(TDocStd_Document).
+where ;doc; is a variable which contains a handle to the output document and should have a type Handle(TDocStd_Document).
@subsubsection occt_1856844696_33248912315 Initializing the process of translation from XDE to IGES
Here is how the process is initialized:
IGESCAFControl_Writer aWriter(XSDRAW::Session(),Standard_False);
@subsubsection occt_1856844696_33248912317 Performing the translation of an XDE document to IGES
You can perform the translation of a document by calling the function:
IFSelect_ReturnStatus aRetSt = aWriter.Transfer(doc);
-where ;doc; is a variable which contains a handle to the input document for transferring and should have a type Handle(TDocStd_Document).
+where ;doc; is a variable which contains a handle to the input document for transferring and should have a type Handle(TDocStd_Document).
@subsubsection occt_1856844696_33248912318 Writing an IGES file
Write an IGES file with:
IFSelect_ReturnStatus statw = aWriter.WriteFile(;filename.igs;);
@subsection occt_modalg_1_2 The Topology API
-The Topology API of Open CASCADE Technology (**OCCT**) includes the following six packages:
+The Topology API of Open CASCADE Technology (**OCCT**) includes the following six packages:
* BRepAlgoAPI
* BRepBuilderAPI
E = ME.Edge();
~~~~~
-This instruction tells the C++ compiler that there is an **implicit casting **of a BRepBuilderAPI_MakeEdge into a TopoDS_Edge using the Edge method. It means this method is automatically called when a BRepBuilderAPI_MakeEdge is found where a TopoDS_Edge is required.
+This instruction tells the C++ compiler that there is an **implicit casting** of a *BRepBuilderAPI_MakeEdge* into a *TopoDS_Edge* using the *Edge* method. It means this method is automatically called when a *BRepBuilderAPI_MakeEdge* is found where a *TopoDS_Edge* is required.
This feature allows you to provide classes, which have the simplicity of function calls when required and the power of classes when advanced processing is necessary. All the benefits of this approach are explained when describing the topology programming interface classes.
The second situation is supposed to become increasingly exceptional as a system is debugged and it is handled by the **exception mechanism**. Using exceptions avoids handling error statuses in the call to a method: a very cumbersome style of programming.
-In the first situation, an exception is also supposed to be raised because the calling method should have verified the arguments and if it did not do so, there is a bug. For example if before calling MakeEdge you are not sure that the two points are non-identical, this situation must be tested.
+In the first situation, an exception is also supposed to be raised because the calling method should have verified the arguments and if it did not do so, there is a bug. For example if before calling *MakeEdge* you are not sure that the two points are non-identical, this situation must be tested.
Making those validity checks on the arguments can be tedious to program and frustrating as you have probably correctly surmised that the method will perform the test twice. It does not trust you.
As the test involves a great deal of computation, performing it twice is also time-consuming.
-Consequently, you might be tempted to adopt the *highly inadvisable *style of programming illustrated in the following example:
+Consequently, you might be tempted to adopt the highly inadvisable style of programming illustrated in the following example:
~~~~~
#include <Standard_ErrorHandler.hxx>
}
~~~~~
-To help the user, the Topology API classes only raise the exception **StdFail_NotDone**. Any other exception means that something happened which was unforeseen in the design of this API.
+To help the user, the Topology API classes only raise the exception *StdFail_NotDone*. Any other exception means that something happened which was unforeseen in the design of this API.
-The **NotDone **exception is only raised when the user tries to access the result of the computation and the original data is corrupted. At the construction of the class instance, if the algorithm cannot be completed, the internal flag NotDone is set. This flag can be tested and in some situations a more complete description of the error can be queried. If the user ignores the NotDone status and tries to access the result, an exception is raised.
+The *NotDone* exception is only raised when the user tries to access the result of the computation and the original data is corrupted. At the construction of the class instance, if the algorithm cannot be completed, the internal flag *NotDone* is set. This flag can be tested and in some situations a more complete description of the error can be queried. If the user ignores the *NotDone* status and tries to access the result, an exception is raised.
~~~~~
BRepBuilderAPI_MakeEdge ME(P1,P2);
@subsection occt_modalg_2_2 Intersections
-The *Geom2dAPI_InterCurveCurve *class allows the evaluation of the intersection points (*gp_Pnt2d*) between two geometric curves (*Geom2d_Curve*)* *and the evaluation of the points of self-intersection of a curve.
+The *Geom2dAPI_InterCurveCurve* class allows the evaluation of the intersection points (*gp_Pnt2d*) between two geometric curves (*Geom2d_Curve*) and the evaluation of the points of self-intersection of a curve.
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image003.jpg "Intersection and self-intersection of curves"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image003.jpg "Intersection and self-intersection of curves"
In both cases, the algorithm requires a value for the tolerance (Standard_Real) for the confusion between two points. The default tolerance value used in all constructors is *1.0e-6.*
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image004.jpg "Intersection and tangent intersection"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image004.jpg "Intersection and tangent intersection"
The algorithm returns a point in the case of an intersection and a segment in the case of tangent intersection.
gp_Pnt2d P = Intersector.Point(Index);
~~~~~
+To call the number of intersection segments, use
~~~~~
Standard_Integer M = Intersector.NbSegments();
~~~~~
-Calls the number of intersection segments.
-
To select the desired intersection segment pass integer index values in argument.
~~~~~
Handle(Geom2d_Curve) Seg1, Seg2;
~~~~~
@subsubsection occt_modalg_2_2_2 Intersection of Curves and Surfaces
-The *GeomAPI_IntCS *class is used to compute the intersection points between a curve and a surface.
+The *GeomAPI_IntCS* class is used to compute the intersection points between a curve and a surface.
This class is instantiated as follows:
~~~~~
gp_Pnt& P = Intersector.Point(Index);
~~~~~
-Where *Index *is an integer between *1 *and *nb*, calls the intersection points.
+Where *Index* is an integer between 1 and *nb*, calls the intersection points.
@subsubsection occt_modalg_2_2_3 Intersection of two Surfaces
-The *GeomAPI_IntSS *class is used to compute the intersection of two surfaces from *Geom_Surface *with respect to a given tolerance.
+The *GeomAPI_IntSS* class is used to compute the intersection of two surfaces from *Geom_Surface* with respect to a given tolerance.
This class is instantiated as follows:
~~~~~
GeomAPI_IntSS Intersector(S1, S2, Tolerance);
~~~~~
-Once the *GeomAPI_IntSS *object has been created, it can be interpreted.
+Once the *GeomAPI_IntSS* object has been created, it can be interpreted.
~~~~~
Standard_Integer nb = Intersector. NbLines();
~~~~~
Handle(Geom_Curve) C = Intersector.Line(Index)
~~~~~
-Where *Index *is an integer between *1 *and *nb*, calls the intersection curves.
+Where *Index* is an integer between 1 and *nb*, calls the intersection curves.
@subsection occt_modalg_2_3 Interpolations
*Interpolation* provides functionalities for interpolating BSpline curves, whether in 2D, using *Geom2dAPI_Interpolate*, or 3D using *GeomAPI_Interpolate*.
@subsubsection occt_modalg_2_3_1 Geom2dAPI_Interpolate
-This class is used to interpolate a BSplineCurve passing through an array of points. If tangency is not requested at the point of interpolation, continuity will be *C2 *. If tangency is requested at the point, continuity will be *C1*. If Periodicity is requested, the curve will be closed and the junction will be the first point given. The curve will then have a continuity of *C1* only.
+This class is used to interpolate a BSplineCurve passing through an array of points. If tangency is not requested at the point of interpolation, continuity will be *C2*. If tangency is requested at the point, continuity will be *C1*. If Periodicity is requested, the curve will be closed and the junction will be the first point given. The curve will then have a continuity of *C1* only.
This class may be instantiated as follows:
~~~~~
Geom2dAPI_Interpolate
const Standard_Real Tolerance);
Geom2dAPI_Interpolate Interp(Points, Standard_False,
- Precision::Confusion());
+ Precision::Confusion());
~~~~~
Handle(Geom2d_BSplineCurve) C = Interp.Curve();
~~~~~
-Note that the *Handle(Geom2d_BSplineCurve)* operator has been redefined by the method Curve(). Consequently, it is unnecessary to pass via the construction of an intermediate object of the *Geom2dAPI_Interpolate *type and the following syntax is correct.
+Note that the *Handle(Geom2d_BSplineCurve)* operator has been redefined by the method *Curve()*. Consequently, it is unnecessary to pass via the construction of an intermediate object of the *Geom2dAPI_Interpolate* type and the following syntax is correct.
~~~~~
Handle(Geom2d_BSplineCurve) C =
Geom2dAPI_Interpolate(Points,
- Standard_False,
- Precision::Confusion());
+ Standard_False,
+ Precision::Confusion());
~~~~~
@subsubsection occt_modalg_2_3_2 GeomAPI_Interpolate
const Standard_Real Tolerance);
GeomAPI_Interpolate Interp(Points, Standard_False,
- Precision::Confusion());
+ Precision::Confusion());
~~~~~
It is possible to call the BSpline curve from the object defined above it.
~~~~~
Handle(Geom_BSplineCurve) C = Interp.Curve();
~~~~~
-Note that the *Handle(Geom_BSplineCurve)* operator has been redefined by the method Curve(). Thus, it is unnecessary to pass via the construction of an intermediate object of the GeomAPI_Interpolate type and the following syntax is correct.
+Note that the *Handle(Geom_BSplineCurve)* operator has been redefined by the method *Curve()*. Thus, it is unnecessary to pass via the construction of an intermediate object of the *GeomAPI_Interpolate* type and the following syntax is correct.
Handle(Geom_BSplineCurve) C =
GeomAPI_Interpolate(Points,
@subsection occt_modalg_2_4 Lines and Circles from Constraints
-There are two packages to create lines and circles from constraints: *Geom2dGcc *and *GccAna*. *Geom2dGcc* deals with reference-handled geometric objects from the *Geom2d *package while *GccAna* deals with value-handled geometric objects from the *gp* package.
+There are two packages to create lines and circles from constraints: *Geom2dGcc* and *GccAna*. *Geom2dGcc* deals with reference-handled geometric objects from the *Geom2d* package, while *GccAna* deals with value-handled geometric objects from the *gp* package.
The *Geom2dGcc* package solves geometric constructions of lines and circles expressed by constraints such as tangency or parallelism, that is, a constraint expressed in geometric terms. As a simple example the following figure shows a line which is constrained to pass through a point and be tangent to a circle.
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image005.jpg "A constrained line"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image005.jpg "A constrained line"
-The *Geom2dGcc *package focuses on algorithms; it is useful for finding results, but it does not offer any management or modification functions, which could be applied to the constraints or their arguments. This package is designed to offer optimum performance, both in rapidity and precision. Trivial cases (for example, a circle centered on one point and passing through another) are not treated.
+The *Geom2dGcc* package focuses on algorithms; it is useful for finding results, but it does not offer any management or modification functions, which could be applied to the constraints or their arguments. This package is designed to offer optimum performance, both in rapidity and precision. Trivial cases (for example, a circle centered on one point and passing through another) are not treated.
-The *Geom2dGcc *package deals only with 2d objects from the *Geom2d *package. These objects are the points, lines and circles available.
+The *Geom2dGcc* package deals only with 2d objects from the *Geom2d* package. These objects are the points, lines and circles available.
-All other lines such as Bezier curves and conic sections - with the exception of circles -are considered general curves and must be differentiable twice.
+All other lines such as Bezier curves and conic sections except for circles are considered general curves and must be differentiable twice.
-The *GccAna *package deals with points, lines, and circles from the *gp *package. Apart from constructors for lines and circles, it also allows the creation of conics from the bisection of other geometric objects.
+The *GccAna* package deals with points, lines, and circles from the *gp* package. Apart from constructors for lines and circles, it also allows the creation of conics from the bisection of other geometric objects.
@subsection occt_modalg_2_5 Provided algorithms
@subsubsection occt_modalg_2_8_1 Exterior/Interior
It is not hard to define the interior and exterior of a circle. As is shown in the following diagram, the exterior is indicated by the sense of the binormal, that is to say the right side according to the sense of traversing the circle. The left side is therefore the interior (or "material").
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image006.jpg "Exterior/Interior of a Circle"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image006.jpg "Exterior/Interior of a Circle"
By extension, the interior of a line or any open curve is defined as the left side according to the passing direction, as shown in the following diagram:
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image007.jpg "Exterior/Interior of a Line and a Curve"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image007.jpg "Exterior/Interior of a Line and a Curve"
@subsubsection occt_modalg_2_8_2 Orientation of a Line
It is sometimes necessary to define in advance the sense of travel along a line to be created. This sense will be from first to second argument.
The following figure shows a line, which is first tangent to circle C1 which is interior to the line, and then passes through point P1.
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image008.jpg "An Oriented Line"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image008.jpg "An Oriented Line"
@subsection occt_modalg_2_9 Examples
**Example 1 Case 1**
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image009.jpg "Both circles outside"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image009.jpg "Both circles outside"
Constraints:
Tangent and Exterior to C1.
**Example 1 Case 2**
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image010.jpg "Both circles enclosed"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image010.jpg "Both circles enclosed"
Constraints:
Tangent and Including C1.
**Example 1 Case 3**
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image011.jpg "C1 enclosed, C2 outside"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image011.jpg "C1 enclosed, C2 outside"
Constraints:
Tangent and Including C1.
**Example 1 Case 4**
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image012.jpg "C1 outside, C2 enclosed"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image012.jpg "C1 outside, C2 enclosed"
Constraints:
Tangent and Exterior to C1.
Tangent and Including C2.
**Example 1 Case 5**
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image013.jpg "With no qualifiers specified"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image013.jpg "With no qualifiers specified"
Constraints:
Tangent and Undefined with respect to C1.
The following four diagrams show the four cases in using qualifiers in the creation of a circle.
**Example 2 Case 1**
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image014.jpg "Both solutions outside"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image014.jpg "Both solutions outside"
Constraints:
Tangent and Exterior to C1.
**Example 2 Case 2**
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image015.jpg "C2 encompasses C1"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image015.jpg "C2 encompasses C1"
Constraints:
Tangent and Exterior to C1.
~~~~~
**Example 2 Case 3**
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image016.jpg "Solutions enclose C2"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image016.jpg "Solutions enclose C2"
Constraints:
Tangent and Exterior to C1.
~~~~~
**Example 2 Case 4**
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image017.jpg "Solutions enclose C1"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image017.jpg "Solutions enclose C1"
Constraints:
Tangent and Enclosing C1.
~~~~~
**Example 2 Case 5**
-The following syntax will give all the circles of radius *Rad, *which are tangent to *C1 *and *C2 *without discrimination of relative position:
+
+The following syntax will give all the circles of radius *Rad*, which are tangent to *C1* and *C2* without discrimination of relative position:
~~~~~
GccAna_Circ2d2TanRad Solver(GccEnt::Unqualified(C1),
* A distinction is made between the trivial case of the center at a point and the complex case of the center on a line.
@subsubsection occt_modalg_2_10_3 Analytic Algorithms
-GccAna package implements analytic algorithms. It deals only with points, lines, and circles from gp package. Here is a list of the services offered:
+*GccAna* package implements analytic algorithms. It deals only with points, lines, and circles from *gp* package. Here is a list of the services offered:
+
+#### Creation of a Line
-Creation of a Line
-------------------
~~~~~
Tangent ( point | circle ) & Parallel ( line )
Bisector( line | line )
~~~~~
-Creation of Conics
-------------------
+#### Creation of Conics
+
~~~~~
Bisector ( point | point )
Bisector ( circle | circle )
~~~~~
-Creation of a Circle
---------------------
+#### Creation of a Circle
+
~~~~~
Tangent ( point | line | circle ) & Center ( point )
Tangent ( 3 { point | line | circle } )
*Geom2dGcc *package offers algorithms, which produce 2d lines or circles with geometric constraints. For arguments, it takes curves for which an approximate solution is not requested. A tolerance value on the result is given as a starting parameter. The following services are provided:
-Creation of a Circle
---------------------
+#### Creation of a Circle
~~~~~
Tangent ( curve ) & Center ( point )
All calculations will be done to the highest precision available from the hardware.
@subsubsection occt_modalg_2_10_5 Iterative Algorithms
-Geom2dGcc package offers iterative algorithms find a solution by refining an approximate solution. It produces 2d lines or circles with geometric constraints. For all geometric arguments except points, an approximate solution may be given as a starting parameter. The tolerance or angular tolerance value is given as an argument. The following services are provided:
+*Geom2dGcc* package offers iterative algorithms find a solution by refining an approximate solution. It produces 2d lines or circles with geometric constraints. For all geometric arguments except points, an approximate solution may be given as a starting parameter. The tolerance or angular tolerance value is given as an argument. The following services are provided:
+
+#### Creation of a Line
-Creation of a Line
-------------------
~~~~~
Tangent ( curve ) & Oblique ( line )
Tangent ( curve , { point | circle | curve } )
~~~~~
-Creation of a Circle
---------------------
+#### Creation of a Circle
~~~~~
Tangent ( curve , 2 { point | circle | curve } )
*FairCurve* package provides a set of classes to create faired 2D curves or 2D curves with minimal variation in curvature.
-Creation of Batten Curves
--------------------------
+#### Creation of Batten Curves
+
The class Batten allows producing faired curves defined on the basis of one or more constraints on each of the two reference points. These include point, angle of tangency and curvature settings.
The following constraint orders are available:
Only 0 and 1 constraint orders are used.
The function Curve returns the result as a 2D BSpline curve.
-Creation of Minimal Variation Curves
-------------------------------------
-The class MinimalVariation allow producing curves with minimal variation in curvature at each reference point. The following constraint orders are available:
+#### Creation of Minimal Variation Curves
+
+The class *MinimalVariation* allows producing curves with minimal variation in curvature at each reference point. The following constraint orders are available:
* 0 the curve must pass through a point
* 1 the curve must pass through a point and have a given tangent
The function *Curve* returns the result as a 2D BSpline curve.
-Specifying the length of the curve
-----------------------------------
+#### Specifying the length of the curve
+
If you want to give a specific length to a batten curve, use:
~~~~~
~~~~~
where *b* is the name of the batten curve object
-Limitations
------------
+#### Limitations
+
Free sliding is generally more aesthetically pleasing than constrained sliding.
However, the computation can fail with values such as angles greater than p/2, because in this case, the length is theoretically infinite.
In other cases, when sliding is imposed and the sliding factor is too large, the batten can collapse.
-Computation Time
-----------------
+#### Computation Time
+
The constructor parameters, *Tolerance* and *NbIterations*, control how precise the computation is, and how long it will take.
@subsubsection occt_modalg_2_11_2 Surfaces from Boundary Curves
The *GeomFill* package provides the following services for creating surfaces from boundary curves:
-Creation of Bezier surfaces
----------------------------
+#### Creation of Bezier surfaces
+
The class *BezierCurves* allows producing a Bezier surface from contiguous Bezier curves. Note that problems may occur with rational Bezier Curves.
-Creation of BSpline surfaces
-----------------------------
+#### Creation of BSpline surfaces
+
The class *BSplineCurves* allows producing a BSpline surface from contiguous BSpline curves. Note that problems may occur with rational BSplines.
-Creation of a Pipe
-------------------
-The class *Pipe* allows you producing a pipe by sweeping a curve (the section) along another curve (the path). The result is a BSpline surface.
+#### Creation of a Pipe
+
+The class *Pipe* allows producing a pipe by sweeping a curve (the section) along another curve (the path). The result is a BSpline surface.
+
+#### Filling a contour
-Filling a contour
-----------------
The class *GeomFill_ConstrainedFilling* allows filling a contour defined by two, three or four curves as well as by tangency constraints. The resulting surface is a BSpline.
-Creation of a Boundary
-----------------------
+#### Creation of a Boundary
+
The class *GeomFill_SimpleBound* allows you defining a boundary for the surface to be constructed.
-Creation of a Boundary with an adjoining surface
-------------------------------------------------
+#### Creation of a Boundary with an adjoining surface
+
The class *GeomFill_BoundWithSurf* allows defining a boundary for the surface to be constructed. This boundary will already be joined to another surface.
-Filling styles
---------------
+#### Filling styles
+
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.
-![](/user_guides/modeling_algos/images/modeling_algos_image018.jpg "Intersecting filleted edges with different radii leave a gap, is filled by a surface)
+@image html /user_guides/modeling_algos/images/modeling_algos_image018.jpg "Intersecting filleted edges with different radii leave a gap, is filled by a surface"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image018.jpg "Intersecting filleted edges with different radii leave a gap, is filled by a surface"
@subsubsection occt_modalg_2_11_3 Surfaces from curve and point constraints
The *GeomPlate* package provides the following services for creating surfaces respecting curve and point constraints:
-Definition of a Framework
--------------------------
+#### Definition of a Framework
+
The class *BuildPlateSurface* allows creating a framework to build surfaces according to curve and point constraints as well as tolerance settings. The result is returned with the function *Surface*.
Note that you do not have to specify an initial surface at the time of construction. It can be added later or, if none is loaded, a surface will be computed automatically.
-Definition of a Curve Constraint
---------------------------------
+#### Definition of a Curve Constraint
+
The class *CurveConstraint* allows defining curves as constraints to the surface, which you want to build.
-Definition of a Point Constraint
---------------------------------
+#### Definition of a Point Constraint
+
The class *PointConstraint* allows defining points as constraints to the surface, which you want to build.
-Applying Geom_Surface to Plate Surfaces
---------------------------------------
+#### Applying Geom_Surface to Plate Surfaces
+
The class *Surface* allows describing the characteristics of plate surface objects returned by **BuildPlateSurface::Surface** using the methods of *Geom_Surface*
-Approximating a Plate surface to a BSpline
-------------------------------------------
-The class *MakeApprox* allows converting a *GeomPlate* surface into a *Geom_BSplineSurface*.
+#### Approximating a Plate surface to a BSpline
-
+The class *MakeApprox* allows converting a *GeomPlate* surface into a *Geom_BSplineSurface*.
-**Example**
+@image html /user_guides/modeling_algos/images/modeling_algos_image019.jpg "Surface generated from four curves and a point"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image019.jpg "Surface generated from four curves and a point"
-Create a Plate surface and approximate it from a polyline as a curve constraint and a point constraint
+Let us create a Plate surface and approximate it from a polyline as a curve constraint and a point constraint
~~~~~
Standard_Integer NbCurFront=4,
*Geom2dAPI_ProjectPointOnCurve* allows calculation of all the normals projected from a point (*gp_Pnt2d*) onto a geometric curve (*Geom2d_Curve*). The calculation may be restricted to a given domain.
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image020.jpg "Normals from a point to a curve"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image020.jpg "Normals from a point to a curve"
+
-Note
-----
The curve does not have to be a *Geom2d_TrimmedCurve*. The algorithm will function with any
class inheriting Geom2d_Curve.
~~~~~
Having thus created the *Geom2dAPI_ProjectPointOnCurve* object, we can now interrogate it.
-Calling the number of solution points
--------------------------------------
+#### Calling the number of solution points
+
~~~~~
Standard_Integer NumSolutions = Projector.NbPoints();
~~~~~
-Calling the location of a solution point
-----------------------------------------
+#### Calling the location of a solution point
+
The solutions are indexed in a range from *1* to *Projector.NbPoints()*. The point, which corresponds to a given *Index* may be found:
~~~~~
gp_Pnt2d Pn = Projector.Point(Index);
~~~~~
-Calling the parameter of a solution point
------------------------------------------
+#### Calling the parameter of a solution point
+
For a given point corresponding to a given *Index*:
~~~~~
Projector.Parameter(Index,U);
~~~~~
-Calling the distance between the start and end points
------------------------------------------------------
+#### Calling the distance between the start and end points
+
We can find the distance between the initial point and a point, which corresponds to the given *Index*:
~~~~~
Standard_Real D = Projector.Distance(Index);
~~~~~
-Calling the nearest solution point
----------------------------------
+#### Calling the nearest solution point
+
This class offers a method to return the closest solution point to the starting point. This solution is accessed as follows:
~~~~~
gp_Pnt2d P1 = Projector.NearestPoint();
~~~~~
-Calling the parameter of the nearest solution point
----------------------------------------------------
+#### Calling the parameter of the nearest solution point
+
~~~~~
Standard_Real U = Projector.LowerDistanceParameter();
~~~~~
-Calling the minimum distance from the point to the curve
--------------------------------------------------------
+#### Calling the minimum distance from the point to the curve
+
~~~~~
Standard_Real D = Projector.LowerDistance();
~~~~~
~~~~~
Having thus created the *GeomAPI_ProjectPointOnCurve* object, you can now interrogate it.
-Calling the number of solution points
--------------------------------------
+#### Calling the number of solution points
+
~~~~~
Standard_Integer NumSolutions = Projector.NbPoints();
~~~~~
-Calling the location of a solution point
-----------------------------------------
+#### Calling the location of a solution point
+
The solutions are indexed in a range from 1 to *Projector.NbPoints()*. The point, which corresponds to a given index, may be found:
~~~~~
gp_Pnt Pn = Projector.Point(Index);
~~~~~
-Calling the parameter of a solution point
------------------------------------------
+#### Calling the parameter of a solution point
+
For a given point corresponding to a given index:
~~~~~
Projector.Parameter(Index,U);
~~~~~
-Calling the distance between the start and end point
-----------------------------------------------------
+#### Calling the distance between the start and end point
+
The distance between the initial point and a point, which corresponds to a given index, may be found:
~~~~~
Standard_Real D = Projector.Distance(Index);
~~~~~
-Calling the nearest solution point
-----------------------------------
+#### Calling the nearest solution point
+
This class offers a method to return the closest solution point to the starting point. This solution is accessed as follows:
~~~~~
gp_Pnt P1 = Projector.NearestPoint();
~~~~~
-Calling the parameter of the nearest solution point
----------------------------------------------------
+#### Calling the parameter of the nearest solution point
+
~~~~~
Standard_Real U = Projector.LowerDistanceParameter();
~~~~~
-Calling the minimum distance from the point to the curve
---------------------------------------------------------
+#### Calling the minimum distance from the point to the curve
+
~~~~~
Standard_Real D = Projector.LowerDistance();
~~~~~
-Redefined operators
---------------------
+#### Redefined operators
+
Some operators have been redefined to find the nearest solution.
*Standard_Real()* returns the minimum distance from the point to the curve.
~~~~~
In the second case, however, no intermediate *GeomAPI_ProjectPointOnCurve* object is created, and it is impossible to access other solutions points.
-Access to lower-level functionalities
--------------------------------------
-If you want to use the wider range of functionalities available from the Extrema package, a call to the *Extrema()* method will return the algorithmic object for calculating the extrema. For example:
+#### Access to lower-level functionalities
+
+If you want to use the wider range of functionalities available from the *Extrema* package, a call to the *Extrema()* method will return the algorithmic object for calculating the extrema. For example:
~~~~~
Extrema_ExtPC& TheExtrema = Projector.Extrema();
*GeomAPI_ProjectPointOnSurf* class allows calculation of all normals projected from a point from *gp_Pnt* onto a geometric surface from Geom_Surface.
+@image html /user_guides/modeling_algos/images/modeling_algos_image021.jpg "Projection of normals from a point to a surface"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image021.jpg "Projection of normals from a point to a surface"
-
-
-Note
-----
Note that the surface does not have to be of *Geom_RectangularTrimmedSurface* type.
The algorithm will function with any class inheriting Geom_Surface.
~~~~~
Having thus created the *GeomAPI_ProjectPointOnSurf* object, you can interrogate it.
-Calling the number of solution points
--------------------------------------
+#### Calling the number of solution points
~~~~~
Standard_Integer NumSolutions = Proj.NbPoints();
~~~~~
-Calling the location of a solution point
-----------------------------------------
+#### Calling the location of a solution point
+
The solutions are indexed in a range from 1 to *Proj.NbPoints()*. The point corresponding to the given index may be found:
~~~~~
gp_Pnt Pn = Proj.Point(Index);
~~~~~
-Calling the parameters of a solution point
-------------------------------------------
+#### Calling the parameters of a solution point
+
For a given point corresponding to the given index:
~~~~~
Proj.Parameters(Index, U, V);
~~~~~
-Calling the distance between the start and end point
-----------------------------------------------------
+#### Calling the distance between the start and end point
+
The distance between the initial point and a point corresponding to the given index may be found:
~~~~~
Standard_Real D = Projector.Distance(Index);
~~~~~
-Calling the nearest solution point
-----------------------------------
+#### Calling the nearest solution point
+
This class offers a method, which returns the closest solution point to the starting point. This solution is accessed as follows:
~~~~~
gp_Pnt P1 = Proj.NearestPoint();
~~~~~
-Calling the parameters of the nearest solution point
-----------------------------------------------------
+#### Calling the parameters of the nearest solution point
+
~~~~~
Standard_Real U,V;
Proj.LowerDistanceParameters (U, V);
~~~~~
-Calling the minimum distance from a point to the surface
---------------------------------------------------------
+#### Calling the minimum distance from a point to the surface
+
~~~~~
Standard_Real D = Proj.LowerDistance();
~~~~~
-Redefined operators
--------------------
+#### Redefined operators
+
Some operators have been redefined to help you find the nearest solution.
*Standard_Real()* returns the minimum distance from the point to the surface.
@subsubsection occt_modalg_2_12_7 Access to lower-level functionalities
-If you want to use the wider range of functionalities available from the Extrema package, a call to the Extrema() method will return the algorithmic object for calculating the extrema as follows:
+If you want to use the wider range of functionalities available from the *Extrema* package, a call to the *Extrema()* method will return the algorithmic object for calculating the extrema as follows:
~~~~~
Extrema_ExtPS& TheExtrema = Proj.Extrema();
@subsubsection occt_modalg_2_12_8 Switching from 2d and 3d Curves
The To2d and To3d methods are used to;
- * build a 2d curve from a 3d Geom_Curve lying on a gp_Pln plane
- * build a 3d curve from a Geom2d_Curve and a gp_Pln plane.
+ * build a 2d curve from a 3d *Geom_Curve* lying on a *gp_Pln* plane
+ * build a 3d curve from a *Geom2d_Curve* and a *gp_Pln* plane.
These methods are called as follows:
~~~~~
Use *BRepBuilderAPI_MakeEdge* to create from a curve and vertices. The basic method is to construct an edge from a curve, two vertices, and two parameters. All other constructions are derived from this one. The basic method and its arguments are described first, followed by the other methods. The BRepBuilderAPI_MakeEdge class can provide extra information and return an error status.
-Basic Edge construction
------------------------
+#### Basic Edge construction
~~~~~
Handle(Geom_Curve) C = ...; // a curve
where C is the domain of the edge; V1 is the first vertex oriented FORWARD; V2 is the second vertex oriented REVERSED; p1 and p2 are the parameters for the vertices V1 and V2 on the curve. The default tolerance is associated with this edge.
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image022.jpg "Basic Edge Construction"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image022.jpg "Basic Edge Construction"
The following rules apply to the arguments:
The figure below illustrates two special cases, a semi-infinite edge and an edge on a periodic curve.
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image023.jpg "Infinite and Periodic Edges"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image023.jpg "Infinite and Periodic Edges"
-Other Edge constructions
-------------------------
+#### Other Edge constructions
+
*BRepBuilderAPI_MakeEdge* class provides methods, which are all simplified calls of the previous one:
* The parameters can be omitted. They are computed by projecting the vertices on the curve.
Six methods (the five above and the basic method) are also provided for curves from the gp package in place of Curve from Geom. The methods create the corresponding Curve from Geom and are implemented for the following classes:
-*gp_Lin* creates a *Geom_Line*
-*gp_Circ* creates a *Geom_Circle*
-*gp_Elips* creates a *Geom_Ellipse*
-*gp_Hypr* creates a *Geom_Hyperbola*
-*gp_Parab* creates a *Geom_Parabola*
+*gp_Lin* creates a *Geom_Line*
+*gp_Circ* creates a *Geom_Circle*
+*gp_Elips* creates a *Geom_Ellipse*
+*gp_Hypr* creates a *Geom_Hyperbola*
+*gp_Parab* creates a *Geom_Parabola*
There are also two methods to construct edges from two vertices or two points. These methods assume that the curve is a line; the vertices or points must have different locations.
E = BRepBuilderAPI_MakeEdge(P1,P2);
~~~~~
-Other information and error status
-----------------------------------
-If BRepBuilderAPI_MakeEdge is used as a class, it can provide two vertices. This is useful when the vertices were not provided as arguments, for example when the edge was constructed from a curve and parameters. The two methods Vertex1 and Vertex2 return the vertices. Note that the returned vertices can be null if the edge is open in the corresponding direction.
+#### Other information and error status
+
+If *BRepBuilderAPI_MakeEdge* is used as a class, it can provide two vertices. This is useful when the vertices were not provided as arguments, for example when the edge was constructed from a curve and parameters. The two methods *Vertex1* and *Vertex2* return the vertices. Note that the returned vertices can be null if the edge is open in the corresponding direction.
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:
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.
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image024.jpg "Creating a Wire"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image024.jpg "Creating a Wire"
~~~~~
#include <BRepBuilderAPI_MakeEdge.hxx>
TopoDS_Wire W = BRepBuilderAPI_MakePolygon(P1,P2,P3,P4);
~~~~~
-BRepBuilderAPI_MakePolygon class maintains a current wire. The current wire can be extracted at any moment and the construction can proceed to a longer wire. After each point insertion, the class maintains the last created edge and vertex, which are returned by the methods Edge, FirstVertex and LastVertex.
+*BRepBuilderAPI_MakePolygon* class maintains a current wire. The current wire can be extracted at any moment and the construction can proceed to a longer wire. After each point insertion, the class maintains the last created edge and vertex, which are returned by the methods *Edge, FirstVertex* and *LastVertex*.
-When the added point or vertex has the same location as the previous one it is not added to the current wire but the most recently created edge becomes Null. The **Added** method can be used to test this condition. The MakePolygon class never raises an error. If no vertex has been added, the Wire is Null. If two vertices are at the same location, no edge is created.
+When the added point or vertex has the same location as the previous one it is not added to the current wire but the most recently created edge becomes Null. The *Added* method can be used to test this condition. The *MakePolygon* class never raises an error. If no vertex has been added, the *Wire* is *Null*. If two vertices are at the same location, no edge is created.
@subsubsection occt_modalg_3_1_5 Face
Use *BRepBuilderAPI_MakeFace* class to create a face from a surface and wires. An underlying surface is constructed from a surface and optional parametric values. Wires can be added to the surface. A planar surface can be constructed from a wire. An error status can be returned after face construction.
-Basic face construction
------------------------
+#### Basic face construction
A face can be constructed from a surface and four parameters to determine a limitation of the UV space. The parameters are optional, if they are omitted the natural bounds of the surface are used. Up to four edges and vertices are created with a wire. No edge is created when the parameter is infinite.
TopoDS_Face F = BRepBuilderAPI_MakeFace(S,umin,umax,vmin,vmax);
~~~~~
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image025.jpg "Basic Face Construction"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image025.jpg "Basic Face Construction"
To make a face from the natural boundary of a surface, the parameters are not required:
~~~~~
Constraints on the parameters are similar to the constraints in *BRepBuilderAPI_MakeEdge*.
- * umin,umax (vmin,vmax) must be in the range of the surface and must be increasing.
- * On a U (V) periodic surface umin and umax (vmin,vmax) are adjusted.
- * umin, umax, vmin, vmax can be infinite. There will be no edge in the corresponding direction.
+ * *umin,umax (vmin,vmax)* must be in the range of the surface and must be increasing.
+ * On a *U (V)* periodic surface *umin* and *umax (vmin,vmax)* are adjusted.
+ * *umin, umax, vmin, vmax* can be infinite. There will be no edge in the corresponding direction.
+
+#### Other face constructions
-Other face constructions
-------------------------
The two basic constructions (from a surface and from a surface and parameters) are implemented for all the gp package surfaces, which are transformed in the corresponding Surface from Geom.
-*gp_Pln* creates a *Geom_Plane*
-*gp_Cylinder* creates a *Geom_CylindricalSurface*
-*gp_Cone* creates a *Geom_ConicalSurface*
-*gp_Sphere* creates a *Geom_SphericalSurface*
-*gp_Torus* creates a *Geom_ToroidalSurface*
+| :------------------- | :----------- | :------------- |
+| *gp_Pln* | | *Geom_Plane* |
+| *gp_Cylinder* | | *Geom_CylindricalSurface* |
+| *gp_Cone* | creates a | *Geom_ConicalSurface* |
+| *gp_Sphere* | | *Geom_SphericalSurface* |
+| *gp_Torus* | | *Geom_ToroidalSurface* |
Once a face has been created, a wire can be added using the Add method. For example, the following code creates a cylindrical surface and adds a wire.
TopoDS_Face F = MF;
~~~~~
-More than one wire can be added to a face, provided that they do not cross each other and they define only one area on the surface. (Note that this is not checked). The edges on a Face must have a parametric curve description.
+More than one wire can be added to a face, provided that they do not cross each other and they define only one area on the surface. (Note that this is not checked). The edges on a Face must have a parametric curve description.
If there is no parametric curve for an edge of the wire on the Face it is computed by projection.
}
~~~~~
-The last use of MakeFace is to copy an existing face to add new wires. For example the following code adds a new wire to a face:
+The last use of *MakeFace* is to copy an existing face to add new wires. For example the following code adds a new wire to a face:
~~~~~
TopoDS_Face F = ...; // a face
F = BRepBuilderAPI_MakeFace(F,W);
~~~~~
-To add more than one wire an instance of the *BRepBuilderAPI_MakeFace* class can be created with the face and the first wire and the new wires inserted with the Add method.
+To add more than one wire an instance of the *BRepBuilderAPI_MakeFace* class can be created with the face and the first wire and the new wires inserted with the Add method.
Error status
------------
* *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.
+* *ParametersOutOfRange* - the parameters *umin, umax, vmin, vmax* are out of the surface.
@subsubsection occt_modalg_3_1_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.
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.
+*DisconnectedWire* - the last added edge was not connected to the wire.
*NonManifoldWire* - the wire with some singularity.
@subsubsection occt_modalg_3_1_7 Shell
@subsubsection occt_modalg_3_2_2 Duplication
-Use the BRepBuilderAPI_Copy class to duplicate a shape. A new shape is thus created.
+Use the *BRepBuilderAPI_Copy* class to duplicate a shape. A new shape is thus created.
In the following example, a solid is copied:
~~~~~
The four methods to build a box are shown in the figure:
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image026.jpg "Making Boxes"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image026.jpg "Making Boxes"
@subsubsection occt_modalg_4_1_2 Wedge
-BRepPrimAPI_MakeWedge class allows building a wedge, which is a slanted box, i.e. a box with angles. The wedge is constructed in much the same way as a box i.e. from three dimensions dx,dy,dz plus arguments or from an axis system, three dimensions, and arguments.
+*BRepPrimAPI_MakeWedge* class allows building a wedge, which is a slanted box, i.e. a box with angles. The wedge is constructed in much the same way as a box i.e. from three dimensions dx,dy,dz plus arguments or from an axis system, three dimensions, and arguments.
The following figure shows two ways to build wedges. One is to add an ltx dimension, which is the length in x of the face at dy. The second is to add xmin, xmax, zmin, zmax to describe the face at dy.
The first method is a particular case of the second with xmin = 0, xmax = ltx, zmin = 0, zmax = dz.
To make a centered pyramid you can use xmin = xmax = dx / 2, zmin = zmax = dz / 2.
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image027.jpg "Making Wedges"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image027.jpg "Making Wedges"
@subsubsection occt_modalg_4_1_3 Rotation object
-BRepPrimAPI_MakeOneAxis is a deferred class used as a root class for all classes constructing rotational primitives. Rotational primitives are created by rotating a curve around an axis. They cover the cylinder, the cone, the sphere, the torus, and the revolution, which provides all other curves.
+*BRepPrimAPI_MakeOneAxis* is a deferred class used as a root class for all classes constructing rotational primitives. Rotational primitives are created by rotating a curve around an axis. They cover the cylinder, the cone, the sphere, the torus, and the revolution, which provides all other curves.
The particular constructions of these primitives are described, but they all have some common arguments, which are:
The result of the OneAxis construction is a Solid, a Shell, or a Face. The face is the face covering the rotational surface. Remember that you will not use the OneAxis directly but one of the derived classes, which provide improved constructions. The following figure illustrates the OneAxis arguments.
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image028.jpg "MakeOneAxis arguments"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image028.jpg "MakeOneAxis arguments"
@subsubsection occt_modalg_4_1_4 Cylinder
-BRepPrimAPI_MakeCylinder class allows creating cylindrical primitives. A cylinder is created either in the default coordinate system or in a given coordinate system (gp_Ax2). There are two constructions:
+*BRepPrimAPI_MakeCylinder* class allows creating cylindrical primitives. A cylinder is created either in the default coordinate system or in a given coordinate system (gp_Ax2). There are two constructions:
* Radius and height, to build a full cylinder.
* Radius, height and angle to build a portion of a cylinder.
TopoDS_Face F =
BRepPrimAPI_MakeCylinder(axes,R,DY,PI/2.);
~~~~~
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image029.jpg "Cylinder"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image029.jpg "Cylinder"
@subsubsection occt_modalg_4_1_5 Cone
-BRepPrimAPI_MakeCone class allows creating conical primitives. Like a cylinder, a cone is created either in the default coordinate system or in a given coordinate system (gp_Ax2). There are two constructions:
+*BRepPrimAPI_MakeCone* class allows creating conical primitives. Like a cylinder, a cone is created either in the default coordinate system or in a given coordinate system (gp_Ax2). There are two constructions:
* Two radii and height, to build a full cone. One of the radii can be null to make a sharp cone.
* Radii, height and angle to build a truncated cone.
TopoDS_Solid S = BRepPrimAPI_MakeCone(R1,R2,H);
~~~~~
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image030.jpg "Cone"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image030.jpg "Cone"
@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:
+*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).
Note that we could equally well choose to create Shells instead of Solids.
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image031.jpg "Examples of Spheres"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image031.jpg "Examples of Spheres"
@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:
+*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.
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image032.gif "Examples of Tori"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image032.gif "Examples of Tori"
The following code builds four toroidal shells from two radii and three angles.
Note that we could equally well choose to create Solids instead of Shells.
@subsubsection occt_modalg_4_1_8 Revolution
-BRepPrimAPI_MakeRevolution class allows building a uniaxial primitive from a curve. As other uniaxial primitives it can be created in the default coordinate system or in a given coordinate system.
+*BRepPrimAPI_MakeRevolution* class allows building a uniaxial primitive from a curve. As other uniaxial primitives it can be created in the default coordinate system or in a given coordinate system.
The curve can be any *Geom_Curve*, provided it is planar and lies in the same plane as the Z-axis of local coordinate system. There are four modes of construction:
It is forbidden to sweep Solids and Composite Solids. A Compound generates a Compound with the sweep of all its elements.
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image033.jpg "Generating a sweep"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image033.jpg "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
@subsubsection occt_modalg_4_2_2 Prism
-BRepPrimAPI_MakePrism class allows creating a linear **prism** from a shape and a vector or a direction.
+*BRepPrimAPI_MakePrism* class allows creating a linear **prism** from a shape and a vector or a direction.
* A vector allows creating a finite prism;
* A direction allows creating an infinite or semi-infinite prism. The semi-infinite or infinite prism is toggled by a Boolean argument. All constructors have a boolean argument to copy the original shape or share it (by default).
+
The following code creates a finite, an infinite and a semi-infinite solid using a face, a direction and a length
.
~~~~~
// semi-infinite
~~~~~
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image034.jpg "Finite, infinite, and semi-infinite prisms"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image034.jpg "Finite, infinite, and semi-infinite prisms"
@subsubsection occt_modalg_4_2_3 Rotation
-BRepPrimAPI_MakeRevol class allows creating a rotational sweep from a shape, an axis (gp_Ax1), and an angle. The angle has a default value of 2*PI which means a closed revolution.
+*BRepPrimAPI_MakeRevol* class allows creating a rotational sweep from a shape, an axis (gp_Ax1), and an angle. The angle has a default value of 2*PI which means a closed revolution.
-BRepPrimAPI_MakeRevol constructors have a last argument to copy or share the original shape. The following code creates a a full and a partial rotation using a face, an axis and an angle.
+*BRepPrimAPI_MakeRevol* constructors have a last argument to copy or share the original shape. The following code creates a a full and a partial rotation using a face, an axis and an angle.
~~~~~
TopoDS_Face F = ...; // the profile
TopoDS_Solid R2 = BRepPrimAPI_MakeRevol(F,axis,ang);
~~~~~
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image035.jpg "Full and partial rotation"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image035.jpg "Full and partial rotation"
@section occt_modalg_5 Boolean Operations
Boolean operations are used to create new shapes from the combinations of two shapes.
-|Fuse | all points in S1 or S2 |
-|Common | all points in S1 and S2 |
-|Cut S1 by S2| all points in S1 and not in S2 |
+
+| Fuse | all points in S1 or S2 |
+| Common | all points in S1 and S2 |
+| Cut S1 by S2| all points in S1 and not in S2 |
BRepAlgoAPI_BooleanOperation class is the deferred root class for Boolean operations.
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image036.jpg "Boolean Operations"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image036.jpg "Boolean Operations"
@subsection occt_modalg_5_1 Fuse
-BRepAlgoAPI_Fuse performs the Fuse operation.
+*BRepAlgoAPI_Fuse* performs the Fuse operation.
~~~~~
TopoDS_Shape A = ..., B = ...;
TopoDS_Shape S = BRepAlgoAPI_Fuse(A,B);
~~~~~
@subsection occt_modalg_5_2 Common
-BRepAlgoAPI_Common performs the Common operation.
+*BRepAlgoAPI_Common* performs the Common operation.
~~~~~
TopoDS_Shape A = ..., B = ...;
~~~~~
@subsection occt_modalg_5_3 Cut
-BRepAlgoAPI_Cut performs the Cut operation.
+*BRepAlgoAPI_Cut* performs the Cut operation.
~~~~~
TopoDS_Shape A = ..., B = ...;
@subsection occt_modalg_5_4 Section
-BRepAlgoAPI_Section performs the section, described as a *TopoDS_Compound* made of *TopoDS_Edge*.
+*BRepAlgoAPI_Section* performs the section, described as a *TopoDS_Compound* made of *TopoDS_Edge*.
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image037.jpg "Section operation"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image037.jpg "Section operation"
~~~~~
TopoDS_Shape A = ..., TopoDS_ShapeB = ...;
*BRepFilletAPI_MakeFillet* class allows filleting a shape.
To produce a fillet, it is necessary to define the filleted shape at the construction of the class and add fillet descriptions using the *Add* method.
-A fillet description contains an edge and a radius. The edge must be shared by two faces. The fillet is automatically extended to all edges in a smooth continuity with the original edge.
-It is not an error to Add a fillet twice, the last description holds.
-
+A fillet description contains an edge and a radius. The edge must be shared by two faces. The fillet is automatically extended to all edges in a smooth continuity with the original edge. It is not an error to add a fillet twice, the last description holds.
+
+@image html /user_guides/modeling_algos/images/modeling_algos_image038.jpg "Filleting two edges using radii r1 and r2."
+@image latex /user_guides/modeling_algos/images/modeling_algos_image038.jpg "Filleting two edges using radii r1 and r2."
In the following example a filleted box with dimensions a,b,c and radius r is created.
-Constant radius
-----------------
+### Constant radius
+
~~~~~
#include <TopoDS_Shape.hxx>
}
~~~~~
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image039.jpg "Fillet with constant radius"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image039.jpg "Fillet with constant radius"
+
+#### Changing radius
-Changing radius
----------------
~~~~~
void CSampleTopologicalOperationsDoc::OnEvolvedblend1()
}
~~~~~
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image040.jpg "Fillet with changing radius"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image040.jpg "Fillet with changing radius"
@subsection occt_modalg_6_1_2 Chamfer
A chamfer is a rectilinear edge replacing a sharp vertex of the face.
The use of *BRepFilletAPI_MakeChamfer* class is similar to the use of *BRepFilletAPI_MakeFillet*, except for the following:
-
-*The surfaces created are ruled and not smooth.
-*The *Add* syntax for selecting edges requires one or two distances, one edge and one face (contiguous to the edge):
+* The surfaces created are ruled and not smooth.
+* The *Add* syntax for selecting edges requires one or two distances, one edge and one face (contiguous to the edge).
~~~~~
Add(dist, E, F)
Add(d1, d2, E, F) with d1 on the face F.
~~~~~
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image041.jpg "Chamfer"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image041.jpg "Chamfer"
@subsection occt_modalg_6_1_3 Fillet on a planar face
-BRepFilletAPI_MakeFillet2d class allows constructing fillets and chamfers on planar faces.
+*BRepFilletAPI_MakeFillet2d* class allows constructing fillets and chamfers on planar faces.
To create a fillet on planar face: define it, indicate, which vertex is to be deleted, and give the fillet radius with *AddFillet* method.
+
A chamfer can be calculated with *AddChamfer* method. It can be described by
* two edges and two distances
* one edge, one vertex, one distance and one angle.
Tol);
~~~~~
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image042.jpg "Shelling"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image042.jpg "Shelling"
@subsection occt_modalg_7_2 Draft Angle
*BRepOffsetAPI_DraftAngle* class allows modifying a shape by applying draft angles to its planar, cylindrical and conical faces.
-The class is created or initialized from a shape, then faces to be modified are added; for each face, three arguments are used:
+
+The class is created or initialized from a shape, then faces to be modified are added; for each face, three arguments are used:
* Direction: the direction with which the draft angle is measured
* Angle: value of the angle
* Neutral plane: intersection between the face and the neutral plane is invariant.
}
~~~~~
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image043.jpg "DraftAngle"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image043.jpg "DraftAngle"
@subsection occt_modalg_7_3 Pipe Constructor
*BRepOffsetAPI_MakePipe* class allows creating a pipe from a Spine, which is a Wire and a Profile which is a Shape. This implementation is limited to spines with smooth transitions, sharp transitions are precessed by *BRepOffsetAPI_MakePipeShell*. To be more precise the continuity must be G1, which means that the tangent must have the same direction, though not necessarily the same magnitude, at neighboring edges.
+
The angle between the spine and the profile is preserved throughout the pipe.
~~~~~
TopoDS_Shape Pipe = BRepOffsetAPI_MakePipe(Spine,Profile);
~~~~~
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image044.jpg "Example of a Pipe"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image044.jpg "Example of a Pipe"
@subsection occt_modalg_7_4 Evolved Solid
*BRepOffsetAPI_MakeEvolved* class allows creating an evolved solid from a Spine (planar face or wire) and a profile (wire).
+
The evolved solid is an unlooped sweep generated by the spine and the profile.
+
The evolved solid is created by sweeping the profile’s reference axes on the spine. The origin of the axes moves to the spine, the X axis and the local tangent coincide and the Z axis is normal to the face.
The reference axes of the profile can be defined following two distinct modes:
*BRepOffsetAPI_Sewing* class allows sewing TopoDS Shapes together along their common edges. The edges can be partially shared as in the following example.
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image045.jpg "Shapes with partially shared edges"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image045.jpg "Shapes with partially shared edges"
-The constructor takes as arguments the tolerance (default value is 10-6) and a flag, which is used to mark the degenerate shapes.
+The constructor takes as arguments the tolerance (default value is 10-6) and a flag, which is used to mark the degenerate shapes.
+
The following methods are used in this class:
* *Add* adds shapes, as it is needed;
* *Perform* forces calculation of the sewed shape.
* *SewedShape* returns the result.
+
Additional methods can be used to give information on the number of free boundaries, multiple edges and degenerate shapes.
@subsection occt_modalg_8_2 Find Contiguous Edges
*BRepOffsetAPI_FindContiguousEdges* class is used to find edges, which coincide among a set of shapes within the given tolerance; these edges can be analyzed for tangency, continuity (C1, G2, etc.)...
The constructor takes as arguments the tolerance defining the edge proximity (10-6 by default) and a flag used to mark degenerated shapes.
+
The following methods are used in this class:
* *Add* adds shapes, which are to be analyzed;
* *NbEdges* returns the total number of edges;
@section occt_modalg_9 Features
@subsection occt_modalg_9_1 The BRepFeat Classes and their use
-BRepFeat package is used to manipulate extensions of the classical boundary representation of shapes closer to features. In that sense, BRepFeat is an extension of BRepBuilderAPI package.
+*BRepFeat* package is used to manipulate extensions of the classical boundary representation of shapes closer to features. In that sense, *BRepFeat* is an extension of *BRepBuilderAPI* package.
@subsubsection occt_modalg_9_1_1 Form classes
-The Form from BRepFeat class is a deferred class used as a root for form features. It inherits MakeShape from BRepBuilderAPI and provides implementation of methods keep track of all sub-shapes.
+The *Form* from *BRepFeat* class is a deferred class used as a root for form features. It inherits *MakeShape* from *BRepBuilderAPI* and provides implementation of methods keep track of all sub-shapes.
-MakePrism
----------
-MakePrism from BRepFeat class is used to build a prism interacting with a shape. It is created or initialized from
+#### MakePrism
+
+*MakePrism* from *BRepFeat* class is used to build a prism interacting with a shape. It is created or initialized from
* a shape (the basic shape),
* the base of the prism,
* a face (the face of sketch on which the base has been defined and used to determine whether the base has been defined on the basic shape or not),
There are six Perform methods:
-|Perform(Height) | The resulting prism is of the given length. |
-|Perform(Until) | The prism is defined between the position of the base and the given face. |
-|Perform(From, Until) | The prism is defined between the two faces From and Until. |
-|PerformUntilEnd() | The prism is semi-infinite, limited by the actual position of the base. |
-|PerformFromEnd(Until) | The prism is semi-infinite, limited by the face Until. |
-| PerformThruAll() | The prism is infinite. In the case of a depression, the result is similar to a cut with an infinite prism. In the case of a protrusion, infinite parts are not kept in the result. |
+| ---------------------- | ------------------------------------- |
+| *Perform(Height)* | The resulting prism is of the given length. |
+| *Perform(Until)* | The prism is defined between the position of the base and the given face. |
+| *Perform(From, Until)* | The prism is defined between the two faces From and Until. |
+| *PerformUntilEnd()* | The prism is semi-infinite, limited by the actual position of the base. |
+| *PerformFromEnd(Until)* | The prism is semi-infinite, limited by the face Until. |
+| *PerformThruAll()* | The prism is infinite. In the case of a depression, the result is similar to a cut with an infinite prism. In the case of a protrusion, infinite parts are not kept in the result. |
-**Note** *Add* method can be used before *Perform* methods to indicate that a face generated by an edge slides onto a face of the base shape.
+**Note** that *Add* method can be used before *Perform* methods to indicate that a face generated by an edge slides onto a face of the base shape.
In the following sequence, a protrusion is performed, i.e. a face of the shape is changed into a prism.
~~~~~
-TopoDS_Shape Sbase = ...; // an initial shape
+TopoDS_Shape Sbase = ...; // an initial shape
TopoDS_Face Fbase = ....; // a base of prism
gp_Dir Extrusion (.,.,.);
}
~~~~~
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image047.jpg "Fusion with MakePrism"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image047.jpg "Fusion with MakePrism"
+
+@image html /user_guides/modeling_algos/images/modeling_algos_image048.jpg "Creating a prism between two faces with Perform(From, Until)"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image048.jpg "Creating a prism between two faces with Perform(From, Until)"
-
+#### MakeDPrism
-MakeDPrism
-----------
-MakeDPrism from BRepFeat class is used to build draft prism topologies interacting with a basis shape . These can be depressions or protrusions. A class object is created or initialized from
+*MakeDPrism* from *BRepFeat* class is used to build draft prism topologies interacting with a basis shape . These can be depressions or protrusions. A class object is created or initialized from
* a shape (basic shape),
* the base of the prism,
* a face (face of sketch on which the base has been defined and used to determine whether the base has been defined on the basic shape or not),
TopoDS_Shape res1 = MKDP.Shape();
~~~~~
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image049.jpg "A tapered prism"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image049.jpg "A tapered prism"
+
+#### MakeRevol
-MakeRevol
----------
-The MakeRevol from BRepFeat class is used to build a revolution interacting with a
+The *MakeRevol* from *BRepFeat* class is used to build a revolution interacting with a
shape. It is created or initialized from
* a shape (the basic shape,)
* another boolean indicating whether the self-intersections have to be found (not used in every case).
There are four Perform methods:
-|Perform(Angle) | The resulting revolution is of the given magnitude. |
-|Perform(Until) |The revolution is defined between the actual position of the base and the given face. |
-|Perform(From, Until) | The revolution is defined between the two faces, From and Until. |
-|PerformThruAll() | The result is similar to Perform(2*PI). |
-**Note** *Add* method can be used before *Perform* methods to indicate that a face generated by an edge slides onto a face of the base shape.
+| *Perform(Angle)* | The resulting revolution is of the given magnitude. |
+| *Perform(Until)* | The revolution is defined between the actual position of the base and the given face. |
+| *Perform(From, Until)* | The revolution is defined between the two faces, From and Until. |
+| *PerformThruAll()* | The result is similar to Perform(2*PI). |
+
+**Note** that *Add* method can be used before *Perform* methods to indicate that a face generated by an edge slides onto a face of the base shape.
In the following sequence, a face is revolved and the revolution is limited by a face of the base shape.
~~~~~
-TopoDS_Shape Sbase = ...; // an initial shape
+TopoDS_Shape Sbase = ...; // an initial shape
TopoDS_Face Frevol = ....; // a base of prism
TopoDS_Face FUntil = ....; // face limiting the revol
}
~~~~~
-MakePipe
---------
+#### MakePipe
+
This method constructs compound shapes with pipe features: depressions or protrusions. A class object is created or initialized from
* a shape (basic shape),
* a base face (profile of the pipe)
There are three Perform methods:
-| Perform() | The pipe is defined along the entire path (spine wire) |
-| Perform(Until) | The pipe is defined along the path until a given face |
-| Perform(From, Until) | The pipe is defined between the two faces From and Until |
+| *Perform()* | The pipe is defined along the entire path (spine wire) |
+| *Perform(Until)* | The pipe is defined along the path until a given face |
+| *Perform(From, Until)* | The pipe is defined between the two faces From and Until |
~~~~~
TopoDS_Shape S = BRepPrimAPI_MakeBox(400.,250.,300.);
TopoDS_Shape res1 = MKPipe.Shape();
~~~~~
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image050.jpg "Pipe depression"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image050.jpg "Pipe depression"
+
+
@subsubsection occt_modalg_9_1_2 Linear Form
---------------
+
*MakeLinearForm* class creates a rib or a groove along a planar surface.
+
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.
* a Boolean indicating the type of operation (fusion=rib or cut=groove) on the basic shape;
* another Boolean indicating if self-intersections have to be found (not used in every case).
-There is one Perform() method, which performs a prism from the wire along the direction1 and direction2 interacting base shape Sbase. The height of the prism is Magnitude(Direction1)+Magnitude(direction2).
+There is one *Perform()* method, which performs a prism from the wire along the *direction1* and *direction2* interacting with base shape *Sbase*. The height of the prism is *Magnitude(Direction1)+Magnitude(direction2)*.
~~~~~
BRepBuilderAPI_MakeWire mkw;
mkw.Add(BRepBuilderAPI_MakeEdge(p2,gp_Pnt(0.,0.,0.)));
TopoDS_Shape S = BRepBuilderAPI_MakePrism(BRepBuilderAPI_MakeFace
(mkw.Wire()),gp_Vec(gp_Pnt(0.,0.,0.),gp_P
- nt(0.,100.,0.)));
+ nt(0.,100.,0.)));
TopoDS_Wire W = BRepBuilderAPI_MakeWire(BRepBuilderAPI_MakeEdge(gp_Pnt
(50.,45.,100.),
gp_Pnt(100.,45.,50.)));
TopoDS_Shape res = aform.Shape();
~~~~~
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image051.jpg "Creating a rib"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image051.jpg "Creating a rib"
@subsubsection occt_modalg_9_1_3 Gluer
-The Gluer from BRepFeat class allows gluing two solids along faces. The contact faces of the glued shape must not have parts outside the contact faces of the basic shape.
+The *Gluer* from *BRepFeat* class allows gluing two solids along faces. The contact faces of the glued shape must not have parts outside the contact faces of the basic shape.
The class is created or initialized from two shapes: the “glued” shape and the basic shape (on which the other shape is glued).
-Two Bind methods are used to bind a face of the glued shape to a face of the basic shape and an edge of the glued shape to an edge of the basic shape.
+Two *Bind* methods are used to bind a face of the glued shape to a face of the basic shape and an edge of the glued shape to an edge of the basic shape.
-**Note** Every face and edge has to be bounded, if two edges of two glued faces are coincident they must be explicitly bounded.
+**Note** that every face and edge has to be bounded, if two edges of two glued faces are coincident they must be explicitly bounded.
~~~~~
TopoDS_Shape Sbase = ...; // the basic shape
}
~~~~~
-@subsubsection occt_modalg_9_1_3 Split Shape
+@subsubsection occt_modalg_9_1_4 Split Shape
-SplitShape from BRepFeat class is used to split faces of a shape with wires or edges. The shape containing the new entities is rebuilt, sharing the unmodified ones.
+*SplitShape* from *BRepFeat* class is used to split faces of a shape with wires or edges. The shape containing the new entities is rebuilt, sharing the unmodified ones.
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.
To provide the precision required in industrial design, drawings need to offer the possibility of removing lines, which are hidden in a given projection.
-For this the Hidden Line Removal component provides two algorithms: HLRBRep_Algo and HLRBRep_PolyAlgo.
+For this the Hidden Line Removal component provides two algorithms: *HLRBRep_Algo* and *HLRBRep_PolyAlgo*.
These algorithms are based on the principle of comparing each edge of the shape to be visualized with each of its faces, and calculating the visible and the hidden parts of each edge. Note that these are not the algorithms used in generating shading, which calculate the visible and hidden parts of each face in a shape to be visualized by comparing each face in the shape with every other face in the same shape.
These algorithms operate on a shape and remove or indicate edges hidden by faces. For a given projection, they calculate a set of lines characteristic of the object being represented. They are also used in conjunction with extraction utilities, which reconstruct a new, simplified shape from a selection of the results of the calculation. This new shape is made up of edges, which represent the shape visualized in the projection.
-HLRBRep_Algo takes the shape itself into account whereas HLRBRep_PolyAlgo works with a polyhedral simplification of the shape. When you use HLRBRep_Algo, you obtain an exact result, whereas, when you use HLRBRep_PolyAlgo, you reduce the computation time.
+*HLRBRep_Algo* takes the shape itself into account whereas *HLRBRep_PolyAlgo* works with a polyhedral simplification of the shape. When you use *HLRBRep_Algo*, you obtain an exact result, whereas, when you use *HLRBRep_PolyAlgo*, you reduce the computation time.
-No smoothing algorithm is provided. Consequently, a polyhedron will be treated as such and the algorithms will give the results in form of line segments conforming to the mathematical definition of the polyhedron. This is always the case with HLRBRep_PolyAlgo.
+No smoothing algorithm is provided. Consequently, a polyhedron will be treated as such and the algorithms will give the results in form of line segments conforming to the mathematical definition of the polyhedron. This is always the case with *HLRBRep_PolyAlgo*.
-HLRBRep_Algo and HLRBRep_PolyAlgo can deal with any kind of object, for example, assemblies of volumes, surfaces, and lines, as long as there are no unfinished objects or points within it.
+*HLRBRep_Algo* and *HLRBRep_PolyAlgo* can deal with any kind of object, for example, assemblies of volumes, surfaces, and lines, as long as there are no unfinished objects or points within it.
However, there some restrictions in HLR use:
* Points are not processed;
* Infinite faces or lines are not processed.
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image052.jpg "Sharp, smooth and sewn edges in a simple screw shape"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image052.jpg "Sharp, smooth and sewn edges in a simple screw shape"
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image053.jpg "Outline edges and isoparameters in the same shape"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image053.jpg "Outline edges and isoparameters in the same shape"
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image054.jpg "A simple screw shape seen with shading"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image054.jpg "A simple screw shape seen with shading"
-
+@image html /user_guides/modeling_algos/images/modeling_algos_image055.jpg "An extraction showing hidden sharp edges"
+@image latex /user_guides/modeling_algos/images/modeling_algos_image055.jpg "An extraction showing hidden sharp edges"
-@subsection occt_modalg_10_2 Services
The following services are related to Hidden Lines Removal :
-Loading Shapes
---------------
+### Loading Shapes
+
To pass a *TopoDS_Shape* to an *HLRBRep_Algo* object, use *HLRBRep_Algo::Add*. With an *HLRBRep_PolyAlgo* object, use *HLRBRep_PolyAlgo::Load*. If you wish to add several shapes, use Add or Load as often as necessary.
-Setting view parameters
------------------------
-HLRBRep_Algo::Projector and HLRBRep_PolyAlgo::Projector set a projector object which defines the parameters of the view. This object is an HLRAlgo_Projector.
+### Setting view parameters
+
+*HLRBRep_Algo::Projector* and *HLRBRep_PolyAlgo::Projector* set a projector object which defines the parameters of the view. This object is an *HLRAlgo_Projector*.
+
+### Computing the projections
+
+*HLRBRep_PolyAlgo::Update* launches the calculation of outlines of the shape visualized by the *HLRBRep_PolyAlgo* framework.
-Computing the projections
--------------------------
-HLRBRep_PolyAlgo::Update launches the calculation of outlines of the shape visualized by the HLRBRep_PolyAlgo framework.
-In the case of HLRBRep_Algo, use HLRBRep_Algo::Update. With this algorithm, you must also call the method HLRBRep_Algo::Hide to calculate visible and hidden lines of the shape to be visualized. With an HLRBRep_PolyAlgo object, visible and hidden lines are computed by HLRBRep_PolyHLRToShape.
+In the case of *HLRBRep_Algo*, use *HLRBRep_Algo::Update*. With this algorithm, you must also call the method *HLRBRep_Algo::Hide* to calculate visible and hidden lines of the shape to be visualized. With an *HLRBRep_PolyAlgo* object, visible and hidden lines are computed by *HLRBRep_PolyHLRToShape*.
-Extracting edges
-----------------
-The classes HLRBRep_HLRToShape and HLRBRep_PolyHLRToShape present a range of extraction filters for an HLRBRep_Algo object and an HLRBRep_PolyAlgo object, respectively. They highlight the type of edge from the results calculated by the algorithm on a shape. With both extraction classes, you can highlight the following types of output:
+### Extracting edges
+
+The classes *HLRBRep_HLRToShape* and *HLRBRep_PolyHLRToShape* present a range of extraction filters for an *HLRBRep_Algo object* and an *HLRBRep_PolyAlgo* object, respectively. They highlight the type of edge from the results calculated by the algorithm on a shape. With both extraction classes, you can highlight the following types of output:
* visible/hidden sharp edges;
* visible/hidden smooth edges;
* visible/hidden sewn edges;
* visible/hidden outline edges.
To perform extraction on an *HLRBRep_PolyHLRToShape* object, use *HLRBRep_PolyHLRToShape::Update* function.
+
For an *HLRBRep_HLRToShape* object built from an *HLRBRepAlgo* object you can also highlight:
* visible isoparameters and
* hidden isoparameters.
-@subsection occt_modalg_10_3 Examples
+@subsection occt_modalg_10_1 Examples
+
+### HLRBRep_Algo
-HLRBRep_Algo
-------------
~~~~~
// Build The algorithm object
myAlgo = new HLRBRep_Algo();
HLRBRep_HLRToShape aHLRToShape(myAlgo);
// extract the results :
-TopoDS_Shape VCompound = aHLRToShape.VCompound();
-TopoDS_Shape Rg1LineVCompound =
+TopoDS_Shape VCompound = aHLRToShape.VCompound();
+TopoDS_Shape Rg1LineVCompound =
aHLRToShape.Rg1LineVCompound();
-TopoDS_Shape RgNLineVCompound =
+TopoDS_Shape RgNLineVCompound =
aHLRToShape.RgNLineVCompound();
-TopoDS_Shape OutLineVCompound =
+TopoDS_Shape OutLineVCompound =
aHLRToShape.OutLineVCompound();
-TopoDS_Shape IsoLineVCompound =
+TopoDS_Shape IsoLineVCompound =
aHLRToShape.IsoLineVCompound();
-TopoDS_Shape HCompound = aHLRToShape.HCompound();
-TopoDS_Shape Rg1LineHCompound =
+TopoDS_Shape HCompound = aHLRToShape.HCompound();
+TopoDS_Shape Rg1LineHCompound =
aHLRToShape.Rg1LineHCompound();
-TopoDS_Shape RgNLineHCompound =
+TopoDS_Shape RgNLineHCompound =
aHLRToShape.RgNLineHCompound();
-TopoDS_Shape OutLineHCompound =
+TopoDS_Shape OutLineHCompound =
aHLRToShape.OutLineHCompound();
-TopoDS_Shape IsoLineHCompound =
+TopoDS_Shape IsoLineHCompound =
aHLRToShape.IsoLineHCompound();
~~~~~
-HLRBRep_PolyAlgo
-----------------
+### HLRBRep_PolyAlgo
+
~~~~~
aPolyHLRToShape.OutLineHCompound();
~~~~~
-@section occt_modalg_10_4 Meshing of Shapes
+@section occt_modalg_10_2 Meshing of Shapes
The *HLRBRep_PolyAlgo* algorithm works with triangulation of shapes. This is provided by the function *BRepMesh::Mesh*, which adds a triangulation of the shape to its topological data structure. This triangulation is computed with a given deflection.
@section occt_modat_1 Introduction
-Modeling Data supplies data structures to represent 2D and 3D geometric models. This manual explains how to use Modeling Data. For advanced information on modeling data, see our offerings on our web site at <a href="http://www.opencascade.org/support/training/">www.opencascade.org/support/training/</a>
+Modeling Data supplies data structures to represent 2D and 3D geometric models. This manual explains how to use Modeling Data. For advanced information on modeling data, see our offerings on our web site at <a href="http://www.opencascade.org/support/training/">www.opencascade.org/support/training/</a>
Packages *Geom2dAPI* and *GeomAPI* provide simple methods for approximation and interpolation with minimal programming
-2D Interpolation
-----------------
+#### 2D Interpolation
+
The class *Interpolate* from *Geom2dAPI* package allows building a constrained 2D BSpline curve, defined by a table of points through which the curve passes. If required, the parameter values and vectors of the tangents can be given for each point in the table.
-3D Interpolation
-----------------
+#### 3D Interpolation
+
The class *Interpolate* from *GeomAPI* package allows building a constrained 3D BSpline curve, defined by a table of points through which the curve passes. If required, the parameter values and vectors of the tangents can be given for each point in the table.
-
+@image html /user_guides/modeling_data/images/modeling_data_image003.jpg "Approximation of a BSpline from scattered points"
+@image latex /user_guides/modeling_data/images/modeling_data_image003.jpg "Approximation of a BSpline from scattered points"
This class may be instantiated as follows:
~~~~~
Handle(Geom_BSplineCurve) C = Interp.Curve();
~~~~~
-2D Approximation
-----------------
+#### 2D Approximation
+
The class *PointsToBSpline* from *Geom2dAPI* package allows building a 2DBSpline curve, which approximates a set of points. You have to define the lowest and highest degree of the curve, its continuity and a tolerance value for it.The tolerance value is used to check that points are not too close to each other, or tangential vectors not too small. The resulting BSpline curve will beC2 or second degree continuous, except where a tangency constraint is defined on a point through which the curve passes. In this case, it will be only C1continuous.
-3D Approximation
----------------
+#### 3D Approximation
+
The class *PointsToBSpline* from GeomAPI package allows building a 3D BSplinecurve, which approximates a set of points. It is necessary to define the lowest and highest degree of the curve, its continuity and tolerance. The tolerance value is used to check that points are not too close to each other,or that tangential vectors are not too small.
The resulting BSpline curve will be C2 or second degree continuous, except where a tangency constraint is defined on a point, through which the curve passes. In this case, it will be only C1 continuous. This class is instantiated as follows:
Handle(Geom_BSplineCurve) K = Approx.Curve();
~~~~~
-Surface Approximation
----------------------
+#### Surface Approximation
+
The class **PointsToBSplineSurface** from GeomAPI package allows building a BSpline surface, which approximates or interpolates a set of points.
@subsubsection occt_modat_1_1_3 Advanced Approximation
Packages *AppDef* and *AppParCurves* provide low-level functions, allowing more control over the approximations.
-Approximation by multiple point constraints
--------------------------------------------
+#### Approximation by multiple point constraints
+
*AppDef* package provides low-level tools to allow parallel approximation of groups of points into Bezier or B-Spline curves using multiple point constraints.
The following low level services are provided:
* Definition of an array of point constraints:
The class *MultiLine* allows defining a given number of multipoint constraints in order to build the multi-line, multiple lines passing through ordered multiple point constraints.
-
+@image html /user_guides/modeling_data/images/modeling_data_image004.jpg "Definition of a MultiLine using Multiple Point Constraints"
+@image latex /user_guides/modeling_data/images/modeling_data_image004.jpg "Definition of a MultiLine using Multiple Point Constraints"
In this image:
* *Pi*, *Qi*, *Ri* ... *Si* can be 2D or 3Dpoints.
* Definition of Variational Criteria:
The class *TheVariational* allows fairing the approximation curve to a given number of points using a least squares method in conjunction with a variational criterion, usually the weights at each constraint point.
-Approximation by parametric or geometric constraints
-----------------------------------------------------
+#### Approximation by parametric or geometric constraints
+
*AppParCurves* package provides low-level tools to allow parallel approximation of groups of points into Bezier or B-Spline curve with parametric or geometric constraints, such as a requirement for the curve to pass through given points, or to have a given tangency or curvature at a particular point.
It is possible to create a point using a *gce* package class, then question it to recover the corresponding *gp* object.
-**Example **
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
gp_Pnt2d Point1,Point2;
...
gp_Lin2d l = L.Value();
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-This is useful if you are uncertain as to whether the arguments can create the *gp* object without raising an exception. In the case above, if *Point1* and *Point2* are closer than the tolerance value required by *MakeLin2d*, the function *Status* will return the enumeration *gce_ConfusedPoint*. This tells you why the *gp* object cannot be created. If you know that the points *Point1* and *Point2*are separated by the value exceeding the tolerance value, then you may create the *gp* object directly, as follows:
-**Example **
+This is useful if you are uncertain as to whether the arguments can create the *gp* object without raising an exception. In the case above, if *Point1* and *Point2* are closer than the tolerance value required by *MakeLin2d*, the function *Status* will return the enumeration *gce_ConfusedPoint*. This tells you why the *gp* object cannot be created. If you know that the points *Point1* and *Point2* are separated by the value exceeding the tolerance value, then you may create the *gp* object directly, as follows:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
gp_Lin2d l = gce_MakeLin2d(Point1,Point2);
- *UniformAbscissa* calculates a set of points at a given abscissa on a curve.
- *UniformDeflection* calculates a set of points at maximum constant deflection between the curve and the polygon that results from the computed points.
-Example: Visualizing a curve.
------------------------------
+### Example: Visualizing a curve.
+
Let us take an adapted curve **C**, i.e. an object which is an interface between the services provided by either a 2D curve from the package Geom2d (in case of an Adaptor_Curve2d curve) or a 3D curve from the package Geom (in case of an Adaptor_Curve curve), and the services required on the curve by the computation algorithm. The adapted curve is created in the following way:
-**case 2D:**
+**2D case :**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
Handle(Geom2d_Curve) mycurve = ... ;
Geom2dAdaptor_Curve C (mycurve) ;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-**case 3D:**
+**3D case :**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
Handle(Geom_Curve) mycurve = ... ;
GeomAdaptor_Curve C (mycurve) ;
{
Standard_Integer nbr = myAlgo.NbPoints() ;
Standard_Real param ;
- for ( Standard_Integer i = 1 ; i = nbr ; i++ )
+ for ( Standard_Integer i = 1 ; i = nbr ; i++ )
{
param = myAlgo.Parameter (i) ;
...
- 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.
- *TopLoc_Datum3D* class provides the elementary reference coordinate, represented by a right-handed orthonormal system of axes or by a right-handed unitary transformation.
- *TopLoc_Location* class provides the composite reference coordinate made from elementary ones. It is a marker composed of a chain of references to elementary markers. The resulting cumulative transformation is stored in order to avoid recalculating the sum of the transformations for the whole list.
-
+@image html /user_guides/modeling_data/images/modeling_data_image005.jpg "Structure of TopLoc_Location"
+@image latex /user_guides/modeling_data/images/modeling_data_image005.jpg "Structure of TopLoc_Location"
Two reference coordinates are equal if they are made up of the same elementary coordinates in the same order. There is no numerical comparison. Two coordinates can thus correspond to the same transformation without being equal if they were not built from the same elementary coordinates.
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.
The terms of the enumeration appear in order from the most complex to the most simple, because objects can contain simpler objects in their description. For example, a face references its wires, edges, and vertices.
-
+@image html /user_guides/modeling_data/images/modeling_data_image006.jpg "ShapeEnum"
+@image latex /user_guides/modeling_data/images/modeling_data_image006.jpg "ShapeEnum"
@subsubsection occt_modat_5_2_2 Orientation
Based on this default region the orientation allows definition of the region to be kept, which is called the *interior* or *material*. There are four orientations defining the interior.
-|FORWARD | The interior is the default region.|
-|REVERSED | The interior is the region complementary to the default.|
-|INTERNAL | The interior includes both regions. The boundary lies inside the material. For example a surface inside a solid.|
-|EXTERNAL | The interior includes neither region. The boundary lies outside the material. For example an edge in a wire-frame model.|
+| FORWARD | The interior is the default region. |
+| REVERSED | The interior is the region complementary to the default. |
+| INTERNAL | The interior includes both regions. The boundary lies inside the material. For example a surface inside a solid. |
+| EXTERNAL | The interior includes neither region. The boundary lies outside the material. For example an edge in a wire-frame model. |
-
+@image html /user_guides/modeling_data/images/modeling_data_image007.jpg "Four Orientations"
+@image latex /user_guides/modeling_data/images/modeling_data_image007.jpg "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:
-|FORWARD | Entering |
-|REVERSED | Exiting |
-|INTERNAL | Touching from inside |
-|EXTERNAL | Touching from outside |
+| FORWARD | Entering |
+| REVERSED | Exiting |
+| INTERNAL | Touching from inside |
+| EXTERNAL | Touching from outside |
-
+@image html /user_guides/modeling_data/images/modeling_data_image008.jpg "Four orientations of intersection vertices"
+@image latex /user_guides/modeling_data/images/modeling_data_image008.jpg "Four orientations of intersection vertices"
Along with the Orientation enumeration the *TopAbs* package defines four methods:
@subsubsection occt_modat_5_2_3 State
The **TopAbs_State** enumeration described the position of a vertex or a set of vertices with respect to a region. There are four terms:
-|IN | The point is interior. |
-|OUT | The point is exterior. |
-|ON | The point is on the boundary(within tolerance). |
-|UNKNOWN | The state of the point is indeterminate. |
+
+|IN | The point is interior. |
+|OUT | The point is exterior. |
+|ON | The point is on the boundary(within tolerance). |
+|UNKNOWN | The state of the point is indeterminate. |
+
The UNKNOWN term has been introduced because this enumeration is often used to express the result of a calculation, which can fail. This term can be used when it is impossible to know if a point is inside or outside, which is the case with an open wire or face.
-
+@image html /user_guides/modeling_data/images/modeling_data_image009.jpg "The four states"
+@image latex /user_guides/modeling_data/images/modeling_data_image009.jpg "The four states"
The State enumeration can also be used to specify various parts of an object. The following figure shows the parts of an edge intersecting a face.
-
+@image html /user_guides/modeling_data/images/modeling_data_image010.jpg "State specifies the parts of an edge intersecting a face"
+@image latex /user_guides/modeling_data/images/modeling_data_image010.jpg "State specifies the parts of an edge intersecting a face"
@subsection occt_modat_5_3 Manipulating shapes and sub-shapes
The class representing the underlying abstract shape is never referenced directly. The *TopoDS_Shape* class is always used to refer to it.
-The information specific to each shape (the geometric support) is always added by inheritance to classes deriving from **TopoDS_TShape**.The following figures show the example of a shell formed from two faces connected by an edge.
+The information specific to each shape (the geometric support) is always added by inheritance to classes deriving from **TopoDS_TShape**. The following figures show the example of a shell formed from two faces connected by an edge.
-
+@image html /user_guides/modeling_data/images/modeling_data_image011.jpg "Structure of a shell formed from two faces"
+@image latex /user_guides/modeling_data/images/modeling_data_image011.jpg "Structure of a shell formed from two faces"
-
+@image html /user_guides/modeling_data/images/modeling_data_image012.jpg "Data structure of the above shell"
+@image latex /user_guides/modeling_data/images/modeling_data_image012.jpg "Data structure of the above shell"
In the previous diagram, the shell is described by the underlying shape TS, and the faces by TF1 and TF2. There are seven edges from TE1 to TE7 and six vertices from TV1 to TV6.
The following figure shows a data structure containing two versions of a solid. The second version presents a series of identical holes bored at different positions. The data structure is compact and yet keeps all information on the sub-elements.
The three references from *TSh2* to the underlying face *TFcyl* have associated local coordinate systems, which correspond to the successive positions of the hole.
-
+@image html /user_guides/modeling_data/images/modeling_data_image013.jpg "Data structure containing two versions of a solid"
+@image latex /user_guides/modeling_data/images/modeling_data_image013.jpg "Data structure containing two versions of a solid"
Classes inheriting TopoDS_Shape
------------------------------
The following example shows a routine receiving an argument of the *TopoDS_Shape* type, then putting it into a variable V if it is a vertex or calling the method ProcessEdge if it is an edge.
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
#include TopoDS_Vertex.hxx
#include TopoDS_Edge.hxx
The Explorer visits the whole structure in order to find the shapes of the requested type not contained in the type to avoid. The example below shows how to find all faces in the shape *S*:
-**Example**
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
void test() {
TopoDS_Shape S;
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-To find all the vertices which are not in an edge:
+Find all the vertices which are not in an edge
-**Example **
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
for (Ex.Init(S,TopAbs_VERTEX,TopAbs_EDGE); ...)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-To find all the faces in a SHELL, then all the faces not in a SHELL:
-
+Find all the faces in a SHELL, then all the faces not in a SHELL:
-**Example **
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
void test() {
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The Explorer presumes that objects contain only objects of an equal or inferior type. For example, if searching for faces it does not lookat wires, edges, or vertices to see if they contain faces.
+The Explorer presumes that objects contain only objects of an equal or inferior type. For example, if searching for faces it does not look at wires, edges, or vertices to see if they contain faces.
The *MapShapes* method from *TopExp* package allows filling a Map. An exploration using the Explorer class can visit an object more than once if it is referenced more than once. For example, an edge of a solid is generally referenced by two faces. To process objects only once, they have to be placed in a Map.
In the following example all faces and all edges of an object are drawn in accordance with the following rules:
- The faces are represented by a network of *NbIso* iso-parametric lines with *FaceIsoColor* color.
- The edges are drawn in a color, which indicates the number of faces sharing the edge:
-1. FreeEdgeColor for edges, which do not belong to a face (i.e. wireframe element).
-2. BorderEdgeColor for an edge belonging to a single face.
-3. SharedEdgeColor for an edge belonging to more than one face.
-- The methods **DrawEdge** and **DrawFaceIso** are also available to display individual edges and faces.
+ - *FreeEdgeColor* for edges, which do not belong to a face (i.e. wireframe element).
+ - *BorderEdgeColor* for an edge belonging to a single face.
+ - *SharedEdgeColor* for an edge belonging to more than one face.
+- The methods *DrawEdge* and *DrawFaceIso* are also available to display individual edges and faces.
The following steps are performed:
1. Storing the edges in a map and create in parallel an array of integers to count the number of faces sharing the edge. This array is initialized to zero.
3. Exploring the edges and for each of them increment the counter of faces in the array.
4. From the Map of edges, drawing each edge with the color corresponding to the number of faces.
-
-**Example **
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
void DrawShape ( const TopoDS_Shape& aShape,
const Standard_Integer nbIsos,
| *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 program counts the size of a data structure as a number of TShapes.
+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*.
+
-**Example **
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
#include TopoDS_Iterator.hxx
Standard_Integer Size(const TopoDS_Shape& aShape)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This program is incorrect if there is sharing in the data structure.
-Thus for a contour of four edges it should count 1 wire + 4 edges +4 vertices
-with the result 9, but as the vertices are each shared by two edges this program will return 13.
-One solution is to put all the Shapes in a Map so as to avoid counting them twice, as in the following example:
-**Example **
+Thus for a contour of four edges it should count 1 wire + 4 edges +4 vertices with the result 9, but as the vertices are each shared by two edges this program will return 13. One solution is to put all the Shapes in a Map so as to avoid counting them twice, as in the following example:
+
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
#include TopoDS_Iterator.hxx
#includeTopTools_MapOfShape.hxx
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-**Note** For more details about Maps see the TCollection documentation.(Foundation Classes Reference Manual)
+**Note** For more details about Maps please, refer to the TCollection documentation. (Foundation Classes Reference Manual)
-The following example is more ambitious and writes a program which copies a data structure using an IndexedMap. The copy is an identical structure but it shares nothing with the original. The principal algorithm is as follows:
-- All Shapes in the structure are put into an IndexedMap.
+The following example is more ambitious and writes a program which copies a data structure using an *IndexedMap*. The copy is an identical structure but it shares nothing with the original. The principal algorithm is as follows:
+- All Shapes in the structure are put into an *IndexedMap*.
- A table of Shapes is created in parallel with the map to receive the copies.
- The structure is copied using the auxiliary recursive function,which copies from the map to the array.
-**Example **
-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
#include TopoDS_Shape.hxx
#include TopoDS_Iterator.hxx
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-In the above example, the index *i* is that of the first object not treated in the Map. When *i* reaches the same size as the Map this means that everything has been treated. The treatment consists of inserting in the Map all the sub-objects, if they are not yet in the Map, they are inserted with an index greater than *i*.
+In the above example, the index *i* is that of the first object not treated in the Map. When *i* reaches the same size as the Map this means that everything has been treated. The treatment consists in inserting in the Map all the sub-objects, if they are not yet in the Map, they are inserted with an index greater than *i*.
**Note** that the objects are inserted with a local reference set to the identity and a FORWARD orientation. Only the underlying TShape is of great interest.
-**Example **
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
//Create an array to store the copies.
TopTools_Array1OfShapetheCopies(1,theMap.Extent());
Below is the auxiliary function, which copies the element of rank *i* from the map to the table. This method checks if the object has been copied; if not copied, then an empty copy is performed into the table and the copies of all the sub-elements are inserted by finding their rank in the map.
-**Example **
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
void AuxiliaryCopy(Standard_Integer index,
const TopTools_IndexedMapOfShapes&sources,
For example, in the wire in the image we want to recuperate the edges in the order {e1, e2, e3,e4, e5} :
-
+@image html /user_guides/modeling_data/images/modeling_data_image014.jpg "A wire composed of 6 edges."
+@image latex /user_guides/modeling_data/images/modeling_data_image014.jpg "A wire composed of 6 edges.
-TopExp_Explorer, however, recuperates the lines in any order.
+*TopExp_Explorer*, however, recuperates the lines in any order.
-**Example **
-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
TopoDS_Wire W = ...;
BRepTools_WireExplorer Ex;
The relationship between OCAF and the Open CASCADE Technology (**OCCT**) Object Libraries can be seen in the image below.
-
+@image html /user_guides/ocaf/images/ocaf_image003.png "OCAF Architecture"
+@image latex /user_guides/ocaf/images/ocaf_image003.png "OCAF Architecture"
In the image, the OCAF (Open CASCADE Application Framework) is shown with black rectangles and OCCT Object Libraries required by OCAF are shown with white rectangles.
The reference keys of a model - in the form of labels - have to be kept together in a single container. This container is called a document.
-|opology-driven approach | reference key-driven approach |
-|-----------------------:|------------------------------:|
-
-
+@image html /user_guides/ocaf/images/ocaf_image004.png "Topology-driven vs. reference key-driven approaches"
+@image latex /user_guides/ocaf/images/ocaf_image004.png "Topology-driven vs. reference key-driven approaches"
@subsection occt_ocaf_2_2 Applications and documents
* Brothers cannot share the same tag;
* A label is uniquely defined by an entry expressed as a list of tags (entry) of fathers from the root: this list of tags is written from right to left: tag of label, tag of its father, tag of father of its father,..., 0 (tag of the root label).
-
+@image html /user_guides/ocaf/images/ocaf_image005.png "A simple framework model"
+@image latex /user_guides/ocaf/images/ocaf_image005.png "A simple framework model"
In the above figure inside the circles are the tags of corresponding labels. Under the circles are the lists of tags. The root label always has a zero tag.
The children of a root label are middle-level labels with tags 1 and 3. These labels are brothers.
-List of tags of the right-bottom label is «0:3:4»: this label has tag 4, its father (with entry «0:3») has tag 3, father of father has tag 0 (the root label always has «0» entry).
+List of tags of the right-bottom label is "0:3:4": this label has tag 4, its father (with entry "0:3") has tag 3, father of father has tag 0 (the root label always has "0" entry).
For example, an application for designing table lamps will first allocate a label for the lamp unit (the lamp is illustrated below). The root label never has brother labels, so, for a lot of lamps in the framework allocation, one of the root label sub-labels for the lamp unit is used. By doing so, you would avoid any confusion between table lamps in the data framework. Parts of the lamp have different material, color and other attributes, so, for each sub-unit of the lamp a child label of the lamp label with specified tags is allocated:
The thing to remember is 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 what you wanted to use in your design, the part name could be integrated into the framework as an attribute.
-
+@image html /user_guides/ocaf/images/ocaf_image006.png
+@image latex /user_guides/ocaf/images/ocaf_image006.png
So, after the user changes the lamp design, only corresponding attributes are changed, but the label structure is maintained. The lamp shape must be recreated by new attribute values and attributes of the lamp shape must refer to a new shape.
-
+@image html /user_guides/ocaf/images/ocaf_image007.png
+@image latex /user_guides/ocaf/images/ocaf_image007.png
The previous figure shows the table-lamps document structure: each child of the root label contains a lamp shape attribute and refers to the sub-labels, which contain some design information about corresponding sub-units.
Note that the root label can have attributes too, usually global attributes: the name of the document, for example.
-As in the case of the table lamp example above, OCAF documents aggregate a battery of ready-to-use attributes, which represent typical data used in CAD. This data includes not only the Shape attribute, but a wide range of Standard attributes corresponding to the following types (see paragraph 6):
+As in the case of the table lamp example above, OCAF documents aggregate a battery of ready-to-use attributes, which represent typical data used in CAD. This data includes not only the Shape attribute, but a wide range of Standard attributes corresponding to the following types:
* Geometric attributes
* General attributes
Where the document manages the notification of changes, a function manages propagation of these changes. The function mechanism provides links between functions and calls to various algorithms.
-
+@image html /user_guides/ocaf/images/ocaf_image008.png "Document structure"
+@image latex /user_guides/ocaf/images/ocaf_image008.png "Document structure"
-@section occt_ocaf_3_ Data Framework Services
+@section occt_ocaf_3 Data Framework Services
@subsection occt_ocaf_3_1 Overview
The most important property is that a label’s entry is its persistent address in the data framework.
-
+@image html /user_guides/ocaf/images/ocaf_image009.png "Contents of a document"
+@image latex /user_guides/ocaf/images/ocaf_image009.png "Contents of a document"
@subsection occt_ocaf_3_2 The Tag
In relative identification, a label’s tag has a meaning relative to the father label only. For a specific label, you might, for example, have four child labels identified by the tags 2, 7, 18, 100. In using relative identification, you ensure that you have a safe scope for setting attributes.
-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 you to retrieve the entry for a specific label.
+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.
@subsubsection occt_ocaf_3_2_1 Creating child labels using random delivery of tags
-To append and return a new child label, you use TDF_TagSource::NewChild. In the example below, the argument *level2, which is passed to NewChild,* is a TDF_Label.
+To append and return a new child label, you use *TDF_TagSource::NewChild*. In the example below, the argument *level2*, which is passed to *NewChild,* is a *TDF_Label*.
+
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TDF_Label child1 = TDF_TagSource::NewChild (level2);
TDF_Label child2 = TDF_TagSource::NewChild (level2);
The other way to create a child label from a tag is by user delivery. In other words, you specify the tag, which you want your child label to have.
-To retrieve a child label from a tag which you have specified yourself, you need to use TDF_Label::FindChild and TDF_Label::Tag as in the example below. Here, the integer 3 designates the tag of the label you are interested in, and the Boolean false is the value for the argument *create*. When this argument is set to *false*, no new child label is created.
+To retrieve a child label from a tag which you have specified yourself, you need to use *TDF_Label::FindChild* and *TDF_Label::Tag* as in the example below. Here, the integer 3 designates the tag of the label you are interested in, and the Boolean false is the value for the argument *create*. When this argument is set to *false*, no new child label is created.
+
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TDF_Label achild = root.FindChild(3,Standard_False);
if (!achild.IsNull()) {
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 (refer to the following figure):
-
+@image html /user_guides/ocaf/images/ocaf_image007.png
+@image latex /user_guides/ocaf/images/ocaf_image007.png
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.
@subsubsection occt_ocaf_3_3_1 Label creation
-Labels can be created on any labels, compared with brother labels and retrieved. You can also find their depth in the data framework (depth of the root label is 0, depth of child labels of the root is 1 and so on), whether they have children or not, relative placement of labels, data framework of this label. It is the class TDF_Label that offers the above services.
+Labels can be created on any labels, compared with brother labels and retrieved. You can also find their depth in the data framework (depth of the root label is 0, depth of child labels of the root is 1 and so on), whether they have children or not, relative placement of labels, data framework of this label. The class *TDF_Label* offers the above services.
@subsubsection occt_ocaf_3_3_2 Creating child labels
-To create a new child label in the data framework using explicit delivery of tags, use TDF_Label::FindChild.
+To create a new child label in the data framework using explicit delivery of tags, use *TDF_Label::FindChild*.
+
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
//creating a label with tag 10 at Root
TDF_Label lab1 = aDF->Root().FindChild(10);
TDF_Label lab3 = lab1.FindChild(2);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-You could also use the same syntax but add the Boolean *true *as a value of the argument **create**. This ensures that a new child label will be created if none is found. Note that in the previous syntax, this was also the case since *create *is *true *by default.
+You could also use the same syntax but add the Boolean *true* as a value of the argument **create**. This ensures that a new child label will be created if none is found. Note that in the previous syntax, this was also the case since **create** is *true* by default.
+
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
TDF_Label level1 = root.FindChild(3,Standard_True);
TDF_Label level2 = level1.FindChild(1,Standard_True);
You can retrieve child labels of your current label by iteration on the first level in the scope of this label.
-**Example**
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
TDF_Label current;
//
//
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Using TDF_Tool::Entry with TDF_ChildIterator you can retrieve the entries of your current label’s child labels as well.
+Using *TDF_Tool::Entry* with *TDF_ChildIterator* you can retrieve the entries of your current label’s child labels as well.
-**Example**
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
void DumpChildren(const TDF_Label& aLabel)
{
Retrieving the father label of a current label.
-**Example**
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
TDF_Label father = achild.Father();
isroot = father.IsRoot();
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.
+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.
@subsubsection occt_ocaf_3_4_1 Retrieving an attribute from a label
-To retrieve an attribute from a label, you use TDF_Label::FindAttribute. In the example below, the GUID for integer attributes, and *INT*, a handle to an attribute are passed as arguments to FindAttribute for the current label.
+To retrieve an attribute from a label, you use *TDF_Label::FindAttribute*. In the example below, the GUID for integer attributes, and *INT*, a handle to an attribute are passed as arguments to *FindAttribute* for the current label.
+
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
if(current.FindAttribute(TDataStd_Integer::GetID(),INT))
{
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsubsection occt_ocaf_3_4_2 Identifying an attribute using a GUID
-You can create a new instance of an attribute and retrieve its GUID. In the example below, a new integer attribute is created, and its GUID is passed to the variable *guid *by the method ID inherited from TDF_Attribute.
+You can create a new instance of an attribute and retrieve its GUID. In the example below, a new integer attribute is created, and its GUID is passed to the variable *guid* by the method ID inherited from *TDF_Attribute*.
+
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
Handle(TDataStd_Integer) INT = new TDataStd_Integer();
Standard_GUID guid = INT->ID();
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
@subsubsection occt_ocaf_3_4_3 Attaching an attribute to a label
-To attach an attribute to a label, you use TDF_Label::Add. Repetition of this syntax raises an error message because there is already an attribute with the same GUID attached to the current label.
+To attach an attribute to a label, you use *TDF_Label::Add*. Repetition of this syntax raises an error message because there is already an attribute with the same GUID attached to the current label.
+
+*TDF_Attribute::Label* for *INT* then returns the label *attach* to which *INT* is attached.
-TDF_Attribute::Label for *INT *then returns the label *attach *which *INT *is attached to.
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
current.Add (INT); // INT is now attached to current
current.Add (INT); // causes failure
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsubsection occt_ocaf_3_4_4 Testing the attachment to a label
-You can test whether an attribute is attached to a label or not by using TDF_Attribute::IsA with the GUID of the attribute as an argument. In the example below, you test whether the current label has an integer attribute, and then, if that is so, how many attributes are attached to it. TDataStd_Integer::GetID provides the GUID argument needed by the method IsAttribute.
+You can test whether an attribute is attached to a label or not by using *TDF_Attribute::IsA* with the GUID of the attribute as an argument. In the example below, you test whether the current label has an integer attribute, and then, if that is so, how many attributes are attached to it. *TDataStd_Integer::GetID* provides the GUID argument needed by the method IsAttribute.
+
+*TDF_Attribute::HasAttribute* tests whether there is an attached attribute, and *TDF_Tool::NbAttributes* returns the number of attributes attached to the label in question, e.g. *current*.
-TDF_Attribute::HasAttribute tests whether there is an attached attribute, and TDF_Tool::NbAttributes returns the number of attributes attached to the label in question, *current *here,
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
// Testing of attribute attachment
//
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsubsection occt_ocaf_3_4_5 Removing an attribute from a label
-To remove an attribute from a label, you use TDF_Label::Forget with the GUID of the deleted attribute. To remove all attributes of a label, TDF_Label::ForgetAll.
+To remove an attribute from a label, you use *TDF_Label::Forget* with the GUID of the deleted attribute. To remove all attributes of a label, *TDF_Label::ForgetAll*.
+
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
current.Forget(TDataStd_Integer::GetID());
// integer attribute is now not attached to current label
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsubsection occt_ocaf_3_4_6 Specific attribute creation
-If the set of existing and ready to use attributes implementing standard data types does not cover the needs of a specific data presentation task, the user can build his own data type and the corresponding new specific attribute implementing this new data type.
+If the set of existing and ready to use attributes implementing standard data types does not cover the needs of a specific data presentation task, the user can build his own data type and the corresponding new specific attribute implementing this new data type.
-There are two ways to implement a new data type: create a new attribute (standard approach), or use the notion of User Attribute by means of a combination of standard attributes (alternative way)
+There are two ways to implement a new data type: create a new attribute (standard approach), or use the notion of User Attribute by means of a combination of standard attributes (alternative way)
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)
+* 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)
* 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.
+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.
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:
- * 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
- * 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).
- * 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).
- * M... package must contain AddStorageDrivers(aDriverSeq : ASDriverHSequence from MDF) and AddRetrievalDrivers(aDriverSeq : ASDriverHSequence from MDF) methods, which append to the given sequence <aDriverSeq> of drivers a sequence of all new attribute drivers (see the previous point), which will be used for the attributes storage/retrieval.
- * Use the standard schema (StdSchema unit) or create a new one to add your P-package and compile it.
+ 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).
+ 4. M... package must contain *AddStorageDrivers(aDriverSeq : ASDriverHSequence* from MDF) and *AddRetrievalDrivers(aDriverSeq : ASDriverHSequence* from MDF) methods, which append to the given sequence *<aDriverSeq>* of drivers a sequence of all new attribute drivers (see the previous point), which will be used for the attributes storage/retrieval.
+ 5 Use the standard schema (*StdSchema* unit) or create a new one to add your P-package and compile it.
If you use the XML format, do the following:
- * Create a new package with the name Xml[package name] (for example XmlMyAttributePackage) containing class XmlMyAttributePackage_MyAttributeDriver. The new class inherits XmlMDF_ADriver class and contains the translation functionality: from transient to persistent and vice versa (see the realization of the standard attributes in the packages XmlMDataStd, for example). Add package method AddDrivers which adds your class to a driver table (see below).
- * Create a new package (or do it in the current one) with two package methods: Factory, which loads the document storage and retrieval drivers; and AttributeDrivers, which calls the methods AddDrivers for all packages responsible for persistence of the document.
- * Create a plug-in implemented as an executable (see example XmlPlugin). It calls a macro PLUGIN with the package name where you implemented the method Factory.
+ 1. Create a new package with the name Xml[package name] (for example *XmlMyAttributePackage*) containing class *XmlMyAttributePackage_MyAttributeDriver*. The new class inherits *XmlMDF_ADriver* class and contains the translation functionality: from transient to persistent and vice versa (see the realization of the standard attributes in the packages *XmlMDataStd*, for example). Add package method AddDrivers which adds your class to a driver table (see below).
+ 2. Create a new package (or do it in the current one) with two package methods:
+ * Factory, which loads the document storage and retrieval drivers; and
+ * AttributeDrivers, which calls the methods AddDrivers for all packages responsible for persistence of the document.
+ 3. Create a plug-in implemented as an executable (see example *XmlPlugin*). It calls a macro PLUGIN with the package name where you implemented the method Factory.
If you use the binary format, do the following:
- * Create a new package with name Bin[package name] (for example BinMyAttributePackage) containing a class BinMyAttributePackage_MyAttributeDriver. The new class inherits BinMDF_ADriver class and contains the translation functionality: from transient to persistent and vice versa (see the realization of the standard attributes in the packages BinMDataStd, for example). Add package method AddDrivers which adds your class to a driver table (see below).
- * Create a new package (or do it in the current one) with two package methods: Factory, which loads the document storage and retrieval drivers; and AttributeDrivers, which calls the methods AddDrivers for all packages responsible for persistence of the document.
- * Create a plug-in implemented as an executable (see example BinPlugin). It calls a macro PLUGIN with the package name where you implemented the method Factory.
+ 1. Create a new package with name Bin[package name] (for example *BinMyAttributePackage*) containing a class *BinMyAttributePackage_MyAttributeDriver*. The new class inherits *BinMDF_ADriver* class and contains the translation functionality: from transient to persistent and vice versa (see the realization of the standard attributes in the packages *BinMDataStd*, for example). Add package method *AddDrivers*, which adds your class to a driver table (see below).
+ 2. Create a new package (or do it in the current one) with two package methods:
+ * Factory, which loads the document storage and retrieval drivers; and
+ * AttributeDrivers, which calls the methods AddDrivers for all packages responsible for persistence of the document.
+ 3. Create a plug-in implemented as an executable (see example *BinPlugin*). It calls a macro PLUGIN with the package name where you implemented the method Factory.
+See <a href="#occt_ocaf_4_3_3">Saving the document</a> and <a href="#occt_ocaf_4_3_4">Opening the document from a file</a> for the description of document save/open mechanisms.
-See «Saving the document» on page 23 and «Opening the document from a file» on page 25 for the description of a document save/open mechanisms.
+If you decided to use the alternative way (create a new attribute by means of *UAttribute* and a combination of other standard attributes), do the following:
+ 1. Set a *TDataStd_UAttribute* with a unique GUID attached to a label. This attribute defines the semantics of the data type (identifies the data type).
+ 2. Create child labels and allocate all necessary data through standard attributes at the child labels.
+ 3. Define an interface class for access to the data of the child labels.
-If you decided to use the alternative way (create a new attribute by means of UAttribute and a combination of other standard attributes), do the following:
- * Set a TDataStd_UAttribute with a unique GUID attached to a label. This attribute defines the semantics of the data type (identifies the data type).
- * Create child labels and allocate all necessary data through standard attributes at the child labels.
- * Define an interface class for access to the data of the child labels.
+Choosing the alternative way of implementation of new data types allows to forget about creating persistence classes for your new data type. Standard persistence classes will be used instead. Besides, this way allows separating the data and the methods for access to the data (interfaces). It can be used for rapid development in all cases when requirements to application performance are not very high.
-Choosing the alternative way of implementation of new data types allows to forget about creating persistence classes for your new data type. Standard persistence classes will be used instead.Besides, this way allows separating the data and the methods for access to the data (interfaces). It can be used for rapid development in all cases when requirements to application performance are not very high.
+Let’s study the implementation of the same data type in both ways by the example of transformation represented by *gp_Trsf* class. The class *gp_Trsf* defines the transformation according to the type (*gp_TrsfForm*) and a set of parameters of the particular type of transformation (two points or a vector for translation, an axis and an angle for rotation, and so on).
-Let’s study the implementation of the same data type in both ways by the example of transformation represented by gp_Trsf class. The class gp_Trsf defines the transformation according to the type (gp_TrsfForm) and a set of parameters of the particular type of transformation (two points or a vector for translation, an axis and an angle for rotation, and so on).
-
-1. The first way: creation of a new attribute. The implementation of the transformation by creation of a new attribute is represented in the <a href="#_10._APPENDIX">Appendix</a>.
+1. The first way: creation of a new attribute. The implementation of the transformation by creation of a new attribute is represented in the <a href="#occt_ocaf_11">Samples</a>.
2. The second way: creation of a new data type by means of combination of standard attributes. Depending on the type of transformation it may be kept in data framework by different standard attributes. For example, a translation is defined by two points. Therefore the data tree for translation looks like this:
* Type of transformation (gp_Translation) as TDataStd_Integer;
* First point as TDataStd_RealArray (three values: X1, Y1 and Z1);
* Second point as TDataStd_RealArray (three values: X2, Y2 and Z2).
-
+@image html /user_guides/ocaf/images/ocaf_image010.png "Data tree for translation"
+@image latex /user_guides/ocaf/images/ocaf_image010.png "Data tree for translation"
If the type of transformation is changed to rotation, the data tree looks like this:
* Type of transformation (gp_Rotation) as TDataStd_Integer;
* Axis of rotation as TDataStd_RealArray (three values: DX, DY and DZ);
* Angle of rotation as TDataStd_Real.
-
+@image html /user_guides/ocaf/images/ocaf_image011.png "Data tree for rotation"
+@image latex /user_guides/ocaf/images/ocaf_image011.png "Data tree for rotation"
The attribute TDataStd_UAttribute with the chosen unique GUID identifies the data type. The interface class initialized by the label of this attribute allows access to the data container (type of transformation and the data of transformation according to the type).
@subsection occt_ocaf_4_2 The Application
-As a container for your data framework, you need a document, and your document must be contained in your application. This application will be a class inheriting from TDocStd_Application.
+As a container for your data framework, you need a document, and your document must be contained in your application. This application will be a class inheriting from *TDocStd_Application*.
@subsubsection occt_ocaf_4_2_1 Creating an application
To create an application, use the following syntax.
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
Handle(TDocStd_Application) app
= new MyApplication_Application ();
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Note that MyApplication_Application is a class, which you have to create and which will inherit from TDocStd_Application.
+Note that *MyApplication_Application* is a class, which you have to create and which will inherit from *TDocStd_Application*.
@subsubsection occt_ocaf_4_2_2 Creating a new document
-To the application which you declared in the previous example (4.2.1), you must add the document *doc *as an argument of TDocStd_Application::NewDocument.
+To the application which you declared in the previous example (4.2.1), you must add the document *doc* as an argument of *TDocStd_Application::NewDocument*.
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
Handle(TDocStd_Document) doc;
app->NewDocument("NewDocumentFormat", doc);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
@subsubsection occt_ocaf_4_2_3 Retrieving the application to which the document belongs
To retrieve the application containing your document, you use the syntax below.
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
app = Handle(TDocStd_Application)::DownCast
(doc->Application());
@subsubsection occt_ocaf_4_3_1 Accessing the main label of the framework
-To access the main label in the data framework, you use TDocStd_Document::Main as in the example below. The main label is the first child of the root label in the data framework, and has the entry 0:1.
+To access the main label in the data framework, you use *TDocStd_Document::Main* as in the example below. The main label is the first child of the root label in the data framework, and has the entry 0:1.
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
TDF_Label label = doc->Main();
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsubsection occt_ocaf_4_3_2 Retrieving the document from a label in its framework
To retrieve the document from a label in its data framework, you use TDocStd_Document::Get as in the example below. The argument *label *passed to this method is an instantiation of TDF_Label.
-
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
doc = TDocStd_Document::Get(label);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
@subsubsection occt_ocaf_4_3_3 Saving the document
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 <theFormats> 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:
+* In your application class (which inherits class *TDocStd_Application*) implement two methods:
+ + Formats (TColStd_SequenceOfExtendedString& theFormats), which append to a given sequence <theFormats> 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:
~~~~~
formatlist:NewDocumentFormat
NewDocumentFormat.AttributeRetrievalPlugin:57b0b827-d931-11d1-b5da-00a0c9064368
~~~~~
-* Create the resource file «Plugin» with GUIDs and corresponding plugin libraries, which looks like this:
+* Create the resource file "Plugin" with GUIDs and corresponding plugin libraries, which looks like this:
**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
57b0b827-d931-11d1-b5da-00a0c9064368.Location: libPAppStdPlugin.so
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-In order to set the paths for these files it is necessary to set the environments: CSF_PluginDefaults and CSF_NewFormatDefaults. For example, set the files in the directory "MyApplicationPath/MyResources":
+In order to set the paths for these files it is necessary to set the environments: *CSF_PluginDefaults* and *CSF_NewFormatDefaults*. For example, set the files in the directory *MyApplicationPath/MyResources*:
~~~~~
setenv CSF_PluginDefaults MyApplicationPath/MyResources
setenv CSF_NewFormatDefaults MyApplicationPath/MyResources
~~~~~
-Once these steps are taken you may run your application, create documents and Save/Open them. These resource files already exist in the OCAF (format «Standard»).
+Once these steps are taken you may run your application, create documents and Save/Open them. These resource files already exist in the OCAF (format "Standard").
-If you use your specific attributes from packages, for example, P-, M- and TMyAttributePackage, see «Specific attribute creation» on page 20; you must take some additional steps for the new plugin implementation:
+If you use your specific attributes from packages, for example, P-, M- and TMyAttributePackage, see "Specific attribute creation" on page 20; you must take some additional steps for the new plugin implementation:
-* Add our «P» package to the standard schema. You can get an already existing (in Open CASCADE Technology sources) schema from StdSchema unit and add your package string to the cdl-file: «package PMyAttributePackage».
-* Next step consists of implementation of an executable, which will connect our documents to our application and open/save them. Copy the package PAppStdPlugin and change its name to MyTheBestApplicationPlugin. In the PLUGIN macros type the name of your factory which will be defined in the next step.
-* Factory is a method, which returns drivers (standard drivers and our defined drivers from the "M" package) by a GUID. Copy the package where the standard factory is defined (it is PAppStd in the OCAF sources). Change its name to MyTheBestSchemaLocation. The Factory() method of the PappStd package checks the GUID set as its argument and returns the corresponding table of drivers. Set two new GUIDs for your determined storage and retrieval drivers. Append two "if" declarations inside the Factory() method which should check whether the set GUID coincides with GUIDs defined by the Factory() method as far as our storage and retrieval drivers are concerned. If the GUID coincides with one of them, the method should return a table of storage or retrieval drivers respectively.
-* Recompile all. Add the strings with GUIDs – in accordance with your plugin library GUID - to the «Plugin» file.
+1. Add our "P" package to the standard schema. You can get an already existing (in Open CASCADE Technology sources) schema from StdSchema unit and add your package string to the cdl-file: "package PMyAttributePackage".
+2. Next step consists of implementation of an executable, which will connect our documents to our application and open/save them. Copy the package PAppStdPlugin and change its name to MyTheBestApplicationPlugin. In the PLUGIN macros type the name of your factory which will be defined in the next step.
+3. Factory is a method, which returns drivers (standard drivers and our defined drivers from the "M" package) by a GUID. Copy the package where the standard factory is defined (it is PAppStd in the OCAF sources). Change its name to MyTheBestSchemaLocation. The Factory() method of the PappStd package checks the GUID set as its argument and returns the corresponding table of drivers. Set two new GUIDs for your determined storage and retrieval drivers. Append two "if" declarations inside the Factory() method which should check whether the set GUID coincides with GUIDs defined by the Factory() method as far as our storage and retrieval drivers are concerned. If the GUID coincides with one of them, the method should return a table of storage or retrieval drivers respectively.
+4. Recompile all. Add the strings with GUIDs – in accordance with your plugin library GUID - to the "Plugin" file.
@subsubsection occt_ocaf_4_3_4 Opening the document from a file
To open the document from a file where it has been previously saved, you use TDocStd_Application::Open as in the example below. The arguments are the path of the file and the document saved in this file.
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
app->Open("/tmp/example.caf", doc);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsection occt_ocaf_4_4 External Links
-External links refer from one document to another. They allow you to update the copy of data framework later on.
+External links refer from one document to another. They allow you to update the copy of data framework later on.
-
+@image html /user_guides/ocaf/images/ocaf_image012.png "External links between documents"
+@image latex /user_guides/ocaf/images/ocaf_image012.png "External links between documents"
Note that documents can be copied with or without a possibility of updating an external link.
@subsubsection occt_ocaf_4_4_1 Copying the document
-With a possibility of updating it later
----------------------------------------
+#### With the possibility of updating it later
To copy a document with a possibility of updating it later, you use TDocStd_XLinkTool::CopyWithLink.
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
Handle(TDocStd_Document) doc1;
Handle(TDocStd_Document) doc2;
In the example below, something has changed in the source document. As a result, you need to update the copy in the target document. This copy is passed to TDocStd_XLinkTool::UpdateLink as the argument *target*.
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
XLinkTool.UpdateLink(target);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-With no link between the copy and the original
-----------------------------------------------
+#### 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.*
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
XLinkTool.Copy(target, source);
If a shape is newly created, then the old shape of a corresponding named shape is an empty shape. If a shape is deleted, then the new shape in this named shape is empty.
-
+@image html /user_guides/ocaf/images/ocaf_image013.png
+@image latex /user_guides/ocaf/images/ocaf_image013.png
Different algorithms may dispose sub-shapes of the result shape at the individual labels depending on whether it is necessary to do so:
Consider the following example. Two boxes (solids) are fused into one solid (the result one). Initially each box was placed to the result label as a named shape, which has evolution PRIMITIVE and refers to the corresponding shape of the TNaming_UsedShapes map. The box result label has a material attribute and six child labels containing named shapes of Box faces.
-
+@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).
Named shapes, which contain information about modified faces, belong to the fuse result sub-labels: sub-label with tag 1 – modified faces of the first box, sub-label with tag 2 – generated faces of the box 2.
-
+@image html /user_guides/ocaf/images/ocaf_image015.png
+@image latex /user_guides/ocaf/images/ocaf_image015.png
This is necessary and sufficient information for the functionality of the right naming mechanism: any sub-shape of the result can be identified unambiguously by name type and set of labels, which contain named shapes:
- * face F1’ as a modification of F11 face
+ * face F1’ as a modification of F11 face
* face F1’’ as generation of F12 face
* edges as an intersection of two contiguous faces
* vertices as an intersection of three contiguous faces
When using TNaming_NamedShape to create attributes, the following fields of an attribute are filled:
-* 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.
+* 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: a term of the TNaming_Evolution enumeration:
* 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 )
+* 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; it is
+* SELECTED – a named shape with this evolution has no effect on the history of the topology; it is
used for the selected shapes that are placed to the separate label
Only pairs of shapes with equal evolution can be stored in one named shape.
The class TNaming_Builder allows you to create a named shape attribute. It has a label of a future attribute as an argument of the constructor. Respective methods are used for the evolution and setting of shape pairs. If for the same TNaming_Builder object a lot of pairs of shapes with the same evolution are given, then these pairs would be placed in the resulting named shape. After the creation of a new object of the TNaming_Builder class, an empty named shape is created at the given label.
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
-// a new empty named shape is created at «label»
+// a new empty named shape is created at "label"
TNaming_Builder builder(label);
// set a pair of shapes with evolution GENERATED
builder.Generated(oldshape1,newshape1);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsubsection occt_ocaf_5_2_3 Reading the contents of a named shape attribute
-You can use TNaming_NamedShape class to get evolution of this named shape (method TNaming_NamedShape::Evolution()) and «value» of the named shape – compound of new shapes of all pairs of this named shape (method TNaming_NamedShape::Get()).
-
+You can use TNaming_NamedShape class to get evolution of this named shape (method TNaming_NamedShape::Evolution()) and "value" of the named shape – compound of new shapes of all pairs of this named shape (method TNaming_NamedShape::Get()).
+
More detailed information about the contents of the named shape or about the modification history of a topology can be obtained with the following:
* TNaming_Tool provides a common high-level functionality for access to the named shapes contents:
* NamedShape(TopoDS_Shape,TDF_Label) method returns a named shape, which contains a given shape as a new shape. Given label is any label from the data framework – it just gives access to it
* TNaming_Iterator given access to the named shape hooks pairs.
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
// create an iterator for a named shape
TNaming_Iterator iter(namedshape);
* Access the named shape
* Update this naming
-Selector places a new named shape with evolution SELECTED to the given label. By the given context shape (main shape, which contains a selected sub-shape), its evolution and naming structure the selector creates a «name» of the selected shape – unique description how to find a selected topology.
+Selector places a new named shape with evolution SELECTED to the given label. By the given context shape (main shape, which contains a selected sub-shape), its evolution and naming structure the selector creates a "name" of the selected shape – unique description how to find a selected topology.
After any modification of a context shape and updating of the corresponding naming structure, you must call the TNaming_Selector::Solve method. If the naming structure is right, then the selector automatically updates the selected shape in the corresponding named shape, else it fails.
If you need to create a topological attribute for existing data, use the method NamedShape.
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
class MyPkg_MyClass
{
* Relationship attributes
* Auxiliary attributes
-Geometric attributes
---------------------
+### 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
+ * 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
+ * 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)
+ * 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
-------------------
+### General attributes
+
* AsciiString – contains AsciiString value
* BooleanArray – contains an array of Boolean
* 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
+ * 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, 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
+ * 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 «is constraint» flag and a string of used units («mm», «m»...)
+ * Variable – simply identifies, that a variable belongs to this label; contains the "is constraint" flag 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
------------------------
+### 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.
-Auxiliary attributes
---------------------
+### Auxiliary attributes
+
* Directory – hi-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.
To access the GUID of an attribute, you can use two methods:
- * Method **GetID**: this is the static method of a class. It returns the GUID of any attribute, which is an object of a specified class (for example, TDataStd_Integer returns the GUID of an integer attribute). Only two classes from the list of standard attributes do not support these methods: TDataStd_TreeNode and TDataStd_Uattribute, because the GUIDs of these attributes are variable.
- * Method **ID**: this is the method of an object of an attribute class. It returns the GUID of this attribute. Absolutely all attributes have this method: only by this identifier you can discern the type of an attribute.
+ * Method *GetID* is the static method of a class. It returns the GUID of any attribute, which is an object of a specified class (for example, TDataStd_Integer returns the GUID of an integer attribute). Only two classes from the list of standard attributes do not support these methods: TDataStd_TreeNode and TDataStd_Uattribute, because the GUIDs of these attributes are variable.
+ * Method *ID* is the method of an object of an attribute class. It returns the GUID of this attribute. Absolutely all attributes have this method: only by this identifier you can discern the type of an attribute.
@subsubsection occt_ocaf_6_2_2 Conventional Interface of Standard Attributes
It is usual to create standard named methods for the attributes:
- * Method Set(label, [value]) – it is the static method, which allows to add an attribute to a given label. If an attribute is characterized by one value this method may set it.
- * Method Get() returns the value of an attribute if it is characterized by one value.
- * Method Dump(Standard_OStream) outputs debug information about a given attribute to a given stream.
+ * Method *Set(label, [value])* is the static method, which allows to add an attribute to a given label. If an attribute is characterized by one value this method may set it.
+ * Method *Get()* returns the value of an attribute if it is characterized by one value.
+ * Method *Dump(Standard_OStream)* outputs debug information about a given attribute to a given stream.
-@section occt_ocaf_7_ Visualization Attributes
+@section occt_ocaf_7 Visualization Attributes
@subsection occt_ocaf_7_1 Overview
@subsubsection occt_ocaf_7_2_1 Defining an interactive viewer attribute
-The class TPrsStd_AISViewer allows you to define an interactive viewer attribute. There may be only one such attribute per one data framework and it is always placed to the root label. So, it could be set or found by any label («access label») of the data framework. Nevertheless the default architecture can be easily extended and the user can manage several Viewers per one framework by himself.
+The class TPrsStd_AISViewer allows you to define an interactive viewer attribute. There may be only one such attribute per one data framework and it is always placed to the root label. So, it could be set or found by any label ("access label") of the data framework. Nevertheless the default architecture can be easily extended and the user can manage several Viewers per one framework by himself.
To initialize the AIS viewer as in the example below, use method Find.
-**Example**
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
-// «access» is any label of the data framework
+// "access" is any label of the data framework
Handle(TPrsStd_AISViewer) viewer = TPrsStd_AISViewer::Find(access)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@subsection occt_ocaf_7_2_2 Defining a presentation attribute
-The class TPrsStd_AISPresentation allows you to define the visual presentation of document labels contents. In addition to various visual fields (color, material, transparency, «isDisplayed», etc.), this attribute contains its driver GUID. This GUID defines the functionality, which will update the presentation every time when needed.
+The class TPrsStd_AISPresentation allows you to define the visual presentation of document labels contents. In addition to various visual fields (color, material, transparency, "isDisplayed", etc.), this attribute contains its driver GUID. This GUID defines the functionality, which will update the presentation every time when needed.
@subsubsection occt_ocaf_7_2_3 Creating your own driver
The abstract class TPrsStd_Driver allows you to define your own driver classes. Simply redefine the Update method in your new class, which will rebuild the presentation.
If your driver is placed to the driver table with the unique driver GUID, then every time the viewer updates presentations with a GUID identical to your driver’s GUID, the Update method of your driver for these presentations must be called:
-
+@image html /user_guides/ocaf/images/ocaf_image016.png
+@image latex /user_guides/ocaf/images/ocaf_image016.png
As usual, the GUID of a driver and the GUID of a displayed attribute are the same.
// here, attach the AISPresentation to NS.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-@section occt_ocaf_8_ Function Services
-
-@subsection occt_ocaf_8_1 Overview
+@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.
Take, for example, the case of a modeling sequence made up of a box with the application of a fillet on one of its edges. If you change the height of the box, the fillet will need to be regenerated as well.
-@subsection occt_ocaf_8_2 Services provided
-
-@subsubsection occt_ocaf_8_2_1 Finding functions, their owners and roots
+@subsection occt_ocaf_8_1 Finding functions, their owners and roots
The class TFunction_Function is an attribute, which stores a link to a function driver in the data framework. In the static table TFunction_DriverTable correspondence links between function attributes and drivers are stored.
Then the solver algorithm of a data model can find the Function attribute on a corresponding label and call the Execute driver method to update the result of the function.
-@subsubsection occt_ocaf_8_2_2 Storing and accessing information about function status
+@subsection occt_ocaf_8_2 Storing and accessing information about function status
For updating algorithm optimization, each function driver has access to the TFunction_Logbook object that is a container for a set of touched, impacted and valid labels. Using this object a driver gets to know which arguments of the function were modified.
-@subsubsection occt_ocaf_8_2_3 Propagating modifications
+@subsection occt_ocaf_8_3 Propagating modifications
An application must implement its functions, function drivers and the common solver for parametric model creation. For example, check the following model (see the following illustration):
-
+@image html /user_guides/ocaf/images/ocaf_image017.png
+@image latex /user_guides/ocaf/images/ocaf_image017.png
The procedure of its creation is as follows:
* create a rectangular planar face F with height 100 and width 200
* change the width of F from 200 to 300:
* the solver for the function of face F starts
* the solver detects that an argument of the face *F* function has been modified
- * the solver calls the driver of the face F function for a regeneration of the face
+ * 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 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 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 calls the L function driver
* the driver rebuilds fillet L and adds the label of the fillet to the logbook as impacted
* **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.
-OCAF Attributes Representation
--------------------------------
+### OCAF Attributes Representation
In XML documents, OCAF attributes are elements whose name identifies the OCAF attribute type. These elements may have a simple (string or number) or complex (sub-elements) structure, depending on the architecture of OCAF attribute. Every XML type for OCAF attribute possesses a unique positive integer "id" XML attribute identifying the OCAF attribute throughout the document. To ensure "id" uniqueness, the attribute name "id" is reserved and is only used to indicate and identify elements which may be referenced from other parts of the OCAF XML document.
For every standard OCAF attribute, its XML name matches the name of a C++ class in Transient data model. Generally, the XML name of OCAF attribute can be specified in the corresponding attribute driver.
XML types for OCAF attributes are declared with XML W3C Schema in a few XSD files where OCAF attributes are grouped by the package where they are defined.
-Example of resulting XML 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 Schema definitions are not used by OCAF XML Persistence algorithms when saving and restoring XML documents. There are internal checks to ensure validity when processing every type of data.
-Management of Namespaces
-------------------------
+### Management of Namespaces
+
Both the XML format and the XML OCAF persistence code are extensible in the sense that every new development can reuse everything that has been created in previous projects. For the XML format, this extensibility is supported by assigning names of XML objects (elements) to different XML Namespaces. Hence, XML elements defined in different projects (in different persistence libraries) can easily be combined into the same XML documents. An example is the XCAF XML persistence built as an extension to the Standard OCAF XML persistence [File XmlXcaf.xsd]. For the correct management of Namespaces it is necessary to:
-* Define targetNamespace in the new XSD file describing the format.
+* Define *targetNamespace* in the new XSD file describing the format.
* Declare (in XSD files) all elements and types in the targetNamespace to appear without a namespace prefix; all other elements and types use the appropriate prefix (such as "ocaf:").
-* Add (in the new DocumentStorageDriver) the targetNamespace accompanied with its prefix, using method XmlDrivers_DocumentStorageDriver::AddNamespace. The same is done for all namespaces objects which are used by the new persistence, with the exception of the "ocaf" namespace.
-* Pass (in every OCAF attribute driver) the namespace prefix of the targetNamespace to the constructor of XmlMDF_ADriver.
+* Add (in the new *DocumentStorageDriver*) the *targetNamespace* accompanied with its prefix, using method *XmlDrivers_DocumentStorageDriver::AddNamespace*. The same is done for all namespaces objects which are used by the new persistence, with the exception of the "ocaf" namespace.
+* Pass (in every OCAF attribute driver) the namespace prefix of the *targetNamespace* to the constructor of *XmlMDF_ADriver*.
@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:
-* 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.
+* **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.
+
-**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
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.
+* **GUID** - Global Universal ID. A string of 37 characters intended to uniquely identify an object.
-**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.
+* **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.
-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.
-See also: modified
-
-@section occt_ocaf_11 Implementation of attribute Transformation (in a CDL file).
+@section occt_ocaf_11 Samples
+@subsection occt_ocaf_11_1 Implementation of Attribute Transformation in a CDL file
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
class Transformation from MyPackage inherits Attribute from TDF
- ---Purpose: This attribute implements a transformation data container.
+ ---Purpose: This attribute implements a transformation data container.
uses
- Attribute from TDF,
- Label from TDF,
- GUID from Standard,
- RelocationTable from TDF,
- Pnt from gp,
- Ax1 from gp,
- Ax2 from gp,
- Ax3 from gp,
- Vec from gp,
- Trsf from gp,
- TrsfForm from gp
+ Attribute from TDF,
+ Label from TDF,
+ GUID from Standard,
+ RelocationTable from TDF,
+ Pnt from gp,
+ Ax1 from gp,
+ Ax2 from gp,
+ Ax3 from gp,
+ Vec from gp,
+ Trsf from gp,
+ TrsfForm from gp
is
- ---Category: Static methods
- -- ===============
-
- GetID (myclass)
- ---C++: return const &
- ---Purpose: The method returns a unique GUID of this attribute.
- -- By means of this GUID this attribute may be identified
- -- among other attributes attached to the same label.
- returns GUID from Standard;
-
- Set (myclass; theLabel : Label from TDF)
- ---Purpose: Finds or creates the attribute attached to <theLabel>.
- -- The found or created attribute is returned.
- returns Transformation from MyPackage;
-
-
- ---Category: Methods for access to the attribute data
- -- ========================================
-
- Get (me)
- ---Purpose: The method returns the transformation.
- returns Trsf from gp;
-
-
- ---Category: Methods for setting the data of transformation
- -- ==============================================
-
- SetRotation (me : mutable;
- theAxis : Ax1 from gp;
- theAngle : Real from Standard);
- ---Purpose: The method defines a rotation type of transformation.
-
- SetTranslation (me : mutable;
- theVector : Vec from gp);
- ---Purpose: The method defines a translation type of transformation.
-
- SetMirror (me : mutable;
- thePoint : Pnt from gp);
- ---Purpose: The method defines a point mirror type of transformation
- -- (point symmetry).
-
- SetMirror (me : mutable;
- theAxis : Ax1 from gp);
- ---Purpose: The method defines an axis mirror type of transformation
- -- (axial symmetry).
-
- SetMirror (me : mutable;
- thePlane : Ax2 from gp);
- ---Purpose: The method defines a point mirror type of transformation
- -- (planar symmetry).
-
- SetScale (me : mutable;
- thePoint : Pnt from gp;
- theScale : Real from Standard);
- ---Purpose: The method defines a scale type of transformation.
-
- SetTransformation (me : mutable;
- theCoordinateSystem1 : Ax3 from gp;
- theCoordinateSystem2 : Ax3 from gp);
- ---Purpose: The method defines a complex type of transformation
- -- from one co-ordinate system to another.
-
-
- ---Category: Overridden methods from TDF_Attribute
- -- =====================================
-
- ID (me)
- ---C++: return const &
- ---Purpose: The method returns a unique GUID of the attribute.
- -- By means of this GUID this attribute may be identified
- -- among other attributes attached to the same label.
- returns GUID from Standard;
-
- Restore (me: mutable;
- theAttribute : Attribute from TDF);
- ---Purpose: The method is called on Undo / Redo.
- -- It copies the content of <theAttribute>
- -- into this attribute (copies the fields).
-
- NewEmpty (me)
- ---Purpose: It creates a new instance of this attribute.
- -- It is called on Copy / Paste, Undo / Redo.
- returns mutable Attribute from TDF;
-
- Paste (me;
- theAttribute : mutable Attribute from TDF;
- theRelocationTable : mutable RelocationTable from TDF);
- ---Purpose:: The method is called on Copy / Paste.
- -- It copies the content of this attribute into
- -- <theAttribute> (copies the fields).
-
- Dump(me; anOS : in out OStream from Standard)
- ---C++: return;
- ---Purpose: Prints the content of this attribute into the stream.
- returns OStream from Standard is redefined;
-
-
- ---Category: Constructor
- -- ===========
-
- Create
- ---Purpose: The C++ constructor of this atribute class.
- -- Usually it is never called outside this class.
- returns mutable Transformation from MyPackage;
+ ---Category: Static methods
+ -- ===============
+
+ GetID (myclass)
+ ---C++: return const &
+ ---Purpose: The method returns a unique GUID of this attribute.
+ -- By means of this GUID this attribute may be identified
+ -- among other attributes attached to the same label.
+ returns GUID from Standard;
+
+ Set (myclass; theLabel : Label from TDF)
+ ---Purpose: Finds or creates the attribute attached to <theLabel>.
+ -- The found or created attribute is returned.
+ returns Transformation from MyPackage;
+
+
+ ---Category: Methods for access to the attribute data
+ -- ========================================
+
+ Get (me)
+ ---Purpose: The method returns the transformation.
+ returns Trsf from gp;
+
+
+ ---Category: Methods for setting the data of transformation
+ -- ==============================================
+
+ SetRotation (me : mutable;
+ theAxis : Ax1 from gp;
+ theAngle : Real from Standard);
+ ---Purpose: The method defines a rotation type of transformation.
+
+ SetTranslation (me : mutable;
+ theVector : Vec from gp);
+ ---Purpose: The method defines a translation type of transformation.
+
+ SetMirror (me : mutable;
+ thePoint : Pnt from gp);
+ ---Purpose: The method defines a point mirror type of transformation
+ -- (point symmetry).
+
+ SetMirror (me : mutable;
+ theAxis : Ax1 from gp);
+ ---Purpose: The method defines an axis mirror type of transformation
+ -- (axial symmetry).
+
+ SetMirror (me : mutable;
+ thePlane : Ax2 from gp);
+ ---Purpose: The method defines a point mirror type of transformation
+ -- (planar symmetry).
+
+ SetScale (me : mutable;
+ thePoint : Pnt from gp;
+ theScale : Real from Standard);
+ ---Purpose: The method defines a scale type of transformation.
+
+ SetTransformation (me : mutable;
+ theCoordinateSystem1 : Ax3 from gp;
+ theCoordinateSystem2 : Ax3 from gp);
+ ---Purpose: The method defines a complex type of transformation
+ -- from one co-ordinate system to another.
+
+
+ ---Category: Overridden methods from TDF_Attribute
+ -- =====================================
+
+ ID (me)
+ ---C++: return const &
+ ---Purpose: The method returns a unique GUID of the attribute.
+ -- By means of this GUID this attribute may be identified
+ -- among other attributes attached to the same label.
+ returns GUID from Standard;
+
+ Restore (me: mutable;
+ theAttribute : Attribute from TDF);
+ ---Purpose: The method is called on Undo / Redo.
+ -- It copies the content of <theAttribute>
+ -- into this attribute (copies the fields).
+
+ NewEmpty (me)
+ ---Purpose: It creates a new instance of this attribute.
+ -- It is called on Copy / Paste, Undo / Redo.
+ returns mutable Attribute from TDF;
+
+ Paste (me;
+ theAttribute : mutable Attribute from TDF;
+ theRelocationTable : mutable RelocationTable from TDF);
+ ---Purpose:: The method is called on Copy / Paste.
+ -- It copies the content of this attribute into
+ -- <theAttribute> (copies the fields).
+
+ Dump(me; anOS : in out OStream from Standard)
+ ---C++: return;
+ ---Purpose: Prints the content of this attribute into the stream.
+ returns OStream from Standard is redefined;
+
+
+ ---Category: Constructor
+ -- ===========
+
+ Create
+ ---Purpose: The C++ constructor of this atribute class.
+ -- Usually it is never called outside this class.
+ returns mutable Transformation from MyPackage;
fields
- -- Type of transformation
- myType : TrsfForm from gp;
+ -- Type of transformation
+ myType : TrsfForm from gp;
- -- Axes (Ax1, Ax2, Ax3)
- myAx1 : Ax1 from gp;
- myAx2 : Ax2 from gp;
- myFirstAx3 : Ax3 from gp;
- mySecondAx3 : Ax3 from gp;
-
- -- Scalar values
- myAngle : Real from Standard;
- myScale : Real from Standard;
-
- -- Points
- myFirstPoint : Pnt from gp;
- mySecondPoint : Pnt from gp;
+ -- Axes (Ax1, Ax2, Ax3)
+ myAx1 : Ax1 from gp;
+ myAx2 : Ax2 from gp;
+ myFirstAx3 : Ax3 from gp;
+ mySecondAx3 : Ax3 from gp;
+
+ -- Scalar values
+ myAngle : Real from Standard;
+ myScale : Real from Standard;
+
+ -- Points
+ myFirstPoint : Pnt from gp;
+ mySecondPoint : Pnt from gp;
end Transformation;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-@subsection occt_1564296469_5683787762 Implementation of attribute Transformation, (CPP file).
+@subsection occt_ocaf_11_2 Implementation of Attribute Transformation in a CPP file
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
#include MyPackage_Transformation.ixx;
//=======================================================================
//function : GetID
-//purpose : The method returns a unique GUID of this attribute.
-// By means of this GUID this attribute may be identified
-// among other attributes attached to the same label.
+//purpose : The method returns a unique GUID of this attribute.
+// By means of this GUID this attribute may be identified
+// among other attributes attached to the same label.
//=======================================================================
const Standard_GUID& MyPackage_Transformation::GetID()
{
- static Standard_GUID ID("4443368E-C808-4468-984D-B26906BA8573");
- return ID;
+ static Standard_GUID ID("4443368E-C808-4468-984D-B26906BA8573");
+ return ID;
}
//=======================================================================
//function : Set
-//purpose : Finds or creates the attribute attached to <theLabel>.
-// The found or created attribute is returned.
+//purpose : Finds or creates the attribute attached to <theLabel>.
+// The found or created attribute is returned.
//=======================================================================
Handle(MyPackage_Transformation) MyPackage_Transformation::Set(const TDF_Label& theLabel)
{
- Handle(MyPackage_Transformation) T;
- if (!theLabel.FindAttribute(MyPackage_Transformation::GetID(), T))
- {
- T = new MyPackage_Transformation();
- theLabel.AddAttribute(T);
- }
- return T;
+ Handle(MyPackage_Transformation) T;
+ if (!theLabel.FindAttribute(MyPackage_Transformation::GetID(), T))
+ {
+ T = new MyPackage_Transformation();
+ theLabel.AddAttribute(T);
+ }
+ return T;
}
//=======================================================================
//function : Get
-//purpose : The method returns the transformation.
+//purpose : The method returns the transformation.
//=======================================================================
gp_Trsf MyPackage_Transformation::Get() const
{
- gp_Trsf transformation;
- switch (myType)
- {
- case gp_Identity:
- {
- break;
- }
- case gp_Rotation:
- {
- transformation.SetRotation(myAx1, myAngle);
- break;
- }
- case gp_Translation:
- {
- transformation.SetTranslation(myFirstPoint, mySecondPoint);
- break;
- }
- case gp_PntMirror:
- {
- transformation.SetMirror(myFirstPoint);
- break;
- }
- case gp_Ax1Mirror:
- {
- transformation.SetMirror(myAx1);
- break;
- }
- case gp_Ax2Mirror:
- {
- transformation.SetMirror(myAx2);
- break;
- }
- case gp_Scale:
- {
- transformation.SetScale(myFirstPoint, myScale);
- break;
- }
- case gp_CompoundTrsf:
- {
- transformation.SetTransformation(myFirstAx3, mySecondAx3);
- break;
- }
- case gp_Other:
- {
- break;
- }
- }
- return transformation;
+ gp_Trsf transformation;
+ switch (myType)
+ {
+ case gp_Identity:
+ {
+ break;
+ }
+ case gp_Rotation:
+ {
+ transformation.SetRotation(myAx1, myAngle);
+ break;
+ }
+ case gp_Translation:
+ {
+ transformation.SetTranslation(myFirstPoint, mySecondPoint);
+ break;
+ }
+ case gp_PntMirror:
+ {
+ transformation.SetMirror(myFirstPoint);
+ break;
+ }
+ case gp_Ax1Mirror:
+ {
+ transformation.SetMirror(myAx1);
+ break;
+ }
+ case gp_Ax2Mirror:
+ {
+ transformation.SetMirror(myAx2);
+ break;
+ }
+ case gp_Scale:
+ {
+ transformation.SetScale(myFirstPoint, myScale);
+ break;
+ }
+ case gp_CompoundTrsf:
+ {
+ transformation.SetTransformation(myFirstAx3, mySecondAx3);
+ break;
+ }
+ case gp_Other:
+ {
+ break;
+ }
+ }
+ return transformation;
}
//=======================================================================
//function : SetRotation
-//purpose : The method defines a rotation type of transformation.
+//purpose : The method defines a rotation type of transformation.
//=======================================================================
void MyPackage_Transformation::SetRotation(const gp_Ax1& theAxis, const Standard_Real theAngle)
{
- Backup();
- myType = gp_Rotation;
- myAx1 = theAxis;
- myAngle = theAngle;
+ Backup();
+ myType = gp_Rotation;
+ myAx1 = theAxis;
+ myAngle = theAngle;
}
//=======================================================================
//function : SetTranslation
-//purpose : The method defines a translation type of transformation.
+//purpose : The method defines a translation type of transformation.
//=======================================================================
void MyPackage_Transformation::SetTranslation(const gp_Vec& theVector)
{
- Backup();
- myType = gp_Translation;
- myFirstPoint.SetCoord(0, 0, 0);
- mySecondPoint.SetCoord(theVector.X(), theVector.Y(), theVector.Z());
+ Backup();
+ myType = gp_Translation;
+ myFirstPoint.SetCoord(0, 0, 0);
+ mySecondPoint.SetCoord(theVector.X(), theVector.Y(), theVector.Z());
}
//=======================================================================
//function : SetMirror
-//purpose : The method defines a point mirror type of transformation
-// (point symmetry).
+//purpose : The method defines a point mirror type of transformation
+// (point symmetry).
//=======================================================================
void MyPackage_Transformation::SetMirror(const gp_Pnt& thePoint)
{
- Backup();
- myType = gp_PntMirror;
- myFirstPoint = thePoint;
+ Backup();
+ myType = gp_PntMirror;
+ myFirstPoint = thePoint;
}
//=======================================================================
//function : SetMirror
-//purpose : The method defines an axis mirror type of transformation
-// (axial symmetry).
+//purpose : The method defines an axis mirror type of transformation
+// (axial symmetry).
//=======================================================================
void MyPackage_Transformation::SetMirror(const gp_Ax1& theAxis)
{
- Backup();
- myType = gp_Ax1Mirror;
- myAx1 = theAxis;
+ Backup();
+ myType = gp_Ax1Mirror;
+ myAx1 = theAxis;
}
//=======================================================================
//function : SetMirror
-//purpose : The method defines a point mirror type of transformation
-// (planar symmetry).
+//purpose : The method defines a point mirror type of transformation
+// (planar symmetry).
//=======================================================================
void MyPackage_Transformation::SetMirror(const gp_Ax2& thePlane)
{
- Backup();
- myType = gp_Ax2Mirror;
- myAx2 = thePlane;
+ Backup();
+ myType = gp_Ax2Mirror;
+ myAx2 = thePlane;
}
//=======================================================================
//function : SetScale
-//purpose : The method defines a scale type of transformation.
+//purpose : The method defines a scale type of transformation.
//=======================================================================
void MyPackage_Transformation::SetScale(const gp_Pnt& thePoint, const Standard_Real theScale)
{
- Backup();
- myType = gp_Scale;
- myFirstPoint = thePoint;
- myScale = theScale;
+ Backup();
+ myType = gp_Scale;
+ myFirstPoint = thePoint;
+ myScale = theScale;
}
//=======================================================================
//function : SetTransformation
-//purpose : The method defines a complex type of transformation
-// from one co-ordinate system to another.
+//purpose : The method defines a complex type of transformation
+// from one co-ordinate system to another.
//=======================================================================
void MyPackage_Transformation::SetTransformation(const gp_Ax3& theCoordinateSystem1,
- const gp_Ax3& theCoordinateSystem2)
+ const gp_Ax3& theCoordinateSystem2)
{
- Backup();
- myFirstAx3 = theCoordinateSystem1;
- mySecondAx3 = theCoordinateSystem2;
+ Backup();
+ myFirstAx3 = theCoordinateSystem1;
+ mySecondAx3 = theCoordinateSystem2;
}
//=======================================================================
//function : ID
-//purpose : The method returns a unique GUID of the attribute.
-// By means of this GUID this attribute may be identified
-// among other attributes attached to the same label.
+//purpose : The method returns a unique GUID of the attribute.
+// By means of this GUID this attribute may be identified
+// among other attributes attached to the same label.
//=======================================================================
const Standard_GUID& MyPackage_Transformation::ID() const
{
- return GetID();
+ return GetID();
}
//=======================================================================
//function : Restore
-//purpose : The method is called on Undo / Redo.
-// It copies the content of <theAttribute>
-// into this attribute (copies the fields).
+//purpose : The method is called on Undo / Redo.
+// It copies the content of <theAttribute>
+// into this attribute (copies the fields).
//=======================================================================
void MyPackage_Transformation::Restore(const Handle(TDF_Attribute)& theAttribute)
{
- Handle(MyPackage_Transformation) theTransformation = Handle(MyPackage_Transformation)::DownCast(theAttribute);
- myType = theTransformation->myType;
- myAx1 = theTransformation->myAx1;
- myAx2 = theTransformation->myAx2;
- myFirstAx3 = theTransformation->myFirstAx3;
- mySecondAx3 = theTransformation->mySecondAx3;
- myAngle = theTransformation->myAngle;
- myScale = theTransformation->myScale;
- myFirstPoint = theTransformation->myFirstPoint;
- mySecondPoint = theTransformation->mySecondPoint;
+ Handle(MyPackage_Transformation) theTransformation = Handle(MyPackage_Transformation)::DownCast(theAttribute);
+ myType = theTransformation->myType;
+ myAx1 = theTransformation->myAx1;
+ myAx2 = theTransformation->myAx2;
+ myFirstAx3 = theTransformation->myFirstAx3;
+ mySecondAx3 = theTransformation->mySecondAx3;
+ myAngle = theTransformation->myAngle;
+ myScale = theTransformation->myScale;
+ myFirstPoint = theTransformation->myFirstPoint;
+ mySecondPoint = theTransformation->mySecondPoint;
}
//=======================================================================
//function : NewEmpty
-//purpose : It creates a new instance of this attribute.
-// It is called on Copy / Paste, Undo / Redo.
+//purpose : It creates a new instance of this attribute.
+// It is called on Copy / Paste, Undo / Redo.
//=======================================================================
Handle(TDF_Attribute) MyPackage_Transformation::NewEmpty() const
-{
- return new MyPackage_Transformation();
+{
+ return new MyPackage_Transformation();
}
//=======================================================================
//function : Paste
-//purpose : The method is called on Copy / Paste.
-// It copies the content of this attribute into
-// <theAttribute> (copies the fields).
+//purpose : The method is called on Copy / Paste.
+// It copies the content of this attribute into
+// <theAttribute> (copies the fields).
//=======================================================================
void MyPackage_Transformation::Paste(const Handle(TDF_Attribute)& theAttribute,
- const Handle(TDF_RelocationTable)& ) const
+ const Handle(TDF_RelocationTable)& ) const
{
- Handle(MyPackage_Transformation) theTransformation = Handle(MyPackage_Transformation)::DownCast(theAttribute);
- theTransformation->myType = myType;
- theTransformation->myAx1 = myAx1;
- theTransformation->myAx2 = myAx2;
- theTransformation->myFirstAx3 = myFirstAx3;
- theTransformation->mySecondAx3 = mySecondAx3;
- theTransformation->myAngle = myAngle;
- theTransformation->myScale = myScale;
- theTransformation->myFirstPoint = myFirstPoint;
- theTransformation->mySecondPoint = mySecondPoint;
+ Handle(MyPackage_Transformation) theTransformation = Handle(MyPackage_Transformation)::DownCast(theAttribute);
+ theTransformation->myType = myType;
+ theTransformation->myAx1 = myAx1;
+ theTransformation->myAx2 = myAx2;
+ theTransformation->myFirstAx3 = myFirstAx3;
+ theTransformation->mySecondAx3 = mySecondAx3;
+ theTransformation->myAngle = myAngle;
+ theTransformation->myScale = myScale;
+ theTransformation->myFirstPoint = myFirstPoint;
+ theTransformation->mySecondPoint = mySecondPoint;
}
//=======================================================================
//function : Dump
-//purpose : Prints the content of this attribute into the stream.
+//purpose : Prints the content of this attribute into the stream.
//=======================================================================
Standard_OStream& MyPackage_Transformation::Dump(Standard_OStream& anOS) const
-{
- anOS = "Transformation: ";
- switch (myType)
- {
- case gp_Identity:
- {
- anOS = "gp_Identity";
- break;
- }
- case gp_Rotation:
- {
- anOS = "gp_Rotation";
- break;
- }
- case gp_Translation:
- {
- anOS = "gp_Translation";
- break;
- }
- case gp_PntMirror:
- {
- anOS = "gp_PntMirror";
- break;
- }
- case gp_Ax1Mirror:
- {
- anOS = "gp_Ax1Mirror";
- break;
- }
- case gp_Ax2Mirror:
- {
- anOS = "gp_Ax2Mirror";
- break;
- }
- case gp_Scale:
- {
- anOS = "gp_Scale";
- break;
- }
- case gp_CompoundTrsf:
- {
- anOS = "gp_CompoundTrsf";
- break;
- }
- case gp_Other:
- {
- anOS = "gp_Other";
- break;
- }
- }
- return anOS;
+{
+ anOS = "Transformation: ";
+ switch (myType)
+ {
+ case gp_Identity:
+ {
+ anOS = "gp_Identity";
+ break;
+ }
+ case gp_Rotation:
+ {
+ anOS = "gp_Rotation";
+ break;
+ }
+ case gp_Translation:
+ {
+ anOS = "gp_Translation";
+ break;
+ }
+ case gp_PntMirror:
+ {
+ anOS = "gp_PntMirror";
+ break;
+ }
+ case gp_Ax1Mirror:
+ {
+ anOS = "gp_Ax1Mirror";
+ break;
+ }
+ case gp_Ax2Mirror:
+ {
+ anOS = "gp_Ax2Mirror";
+ break;
+ }
+ case gp_Scale:
+ {
+ anOS = "gp_Scale";
+ break;
+ }
+ case gp_CompoundTrsf:
+ {
+ anOS = "gp_CompoundTrsf";
+ break;
+ }
+ case gp_Other:
+ {
+ anOS = "gp_Other";
+ break;
+ }
+ }
+ return anOS;
}
//=======================================================================
//function : MyPackage_Transformation
-//purpose : A constructor.
+//purpose : A constructor.
//=======================================================================
MyPackage_Transformation::MyPackage_Transformation():myType(gp_Identity){
}
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
\ No newline at end of file
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+@subsection occt_ocaf_11_3 Implementation of typical actions with standard OCAF attributes.
+
+There are four sample files provided in the directory 'OpenCasCade\ros\samples\ocafsamples'. They present typical actions with OCAF services (mainly for newcomers).
+The method *Sample()* of each file is not dedicated for execution 'as is', it is rather a set of logical actions using some OCAF services.
+
+### TDataStd_Sample.cxx
+This sample contains templates for typical actions with the following standard OCAF attributes:
+- Starting with data framework;
+- TDataStd_Integer attribute management;
+- TDataStd_RealArray attribute management;
+- TDataStd_Comment attribute management;
+- TDataStd_Name attribute management;
+- TDataStd_UAttribute attribute management;
+- TDF_Reference attribute management;
+- TDataXtd_Point attribute management;
+- TDataXtd_Plane attribute management;
+- TDataXtd_Axis attribute management;
+- TDataXtd_Geometry attribute management;
+- TDataXtd_Constraint attribute management;
+- TDataStd_Directory attribute management;
+- TDataStd_TreeNode attribute management.
+
+### TDocStd_Sample.cxx
+This sample contains template for the following typical actions:
+- creating application;
+- creating the new document (document contains a framework);
+- retrieving the document from a label of its framework;
+- filling a document with data;
+- saving a document in the file;
+- closing a document;
+- opening the document stored in the file;
+- copying content of a document to another document with possibility to update the copy in the future.
+
+### TPrsStd_Sample.cxx
+This sample contains template for the following typical actions:
+- starting with data framework;
+- setting the TPrsStd_AISViewer in the framework;
+- initialization of aViewer;
+- finding TPrsStd_AISViewer attribute in the DataFramework;
+- getting AIS_InteractiveContext from TPrsStd_AISViewer;
+- adding driver to the map of drivers;
+- getting driver from the map of drivers;
+- setting TNaming_NamedShape to <ShapeLabel>;
+- setting the new TPrsStd_AISPresentation to <ShapeLabel>;
+- displaying;
+- erasing;
+- updating and displaying presentation of the attribute to be displayed;
+- setting a color to the displayed attribute;
+- getting transparency of the displayed attribute;
+- modify attribute;
+- updating presentation of the attribute in viewer.
+
+### TNaming_Sample.cxx
+This sample contains template for typical actions with OCAF Topological Naming services.
+The following scenario is used:
+- data framework initialization;
+- creating Box1 and pushing it as PRIMITIVE in DF;
+- creating Box2 and pushing it as PRIMITIVE in DF;
+- moving Box2 (applying a transformation);
+- pushing the selected edges of the top face of Box1 in DF;
+- creating a Fillet (using the selected edges) and pushing the result as a modification of Box1;
+- creating a Cut (Box1, Box2) as a modification of Box1 and push it in DF;
+- recovering the result from DF.
+
**Shape Healing** currently includes several packages that are designed to help you to:
* analyze shape characteristics and, in particular, identify shapes that do not comply with Open CASCADE Technology validity rules
* fix some of the problems shapes may have
- * upgrade shape characteristics for users needs, for example a C0 supporting surface can be upgraded so that it becomes C1 continuous.
+ * upgrade shape characteristics for users needs, for example a C0 supporting surface can be upgraded so that it becomes C1 continuous.
The following diagram shows dependencies of API packages:
-
+@image html /user_guides/shape_healing/images/shape_healing_image009.png "Shape Healing packages"
+@image latex /user_guides/shape_healing/images/shape_healing_image009.png "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);
+* 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.
+* 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.
+
Tools responsible for analysis, fixing and upgrading of shapes can give the information about how these operations were performed. This information can be obtained by the user with the help of mechanism of status querying.
@subsection occt_shg_1_1 Querying the statuses
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. |
~~~~~
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_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
-Algorithms for fixing problematic (violating the OCCT requirements) shapes are placed in package ShapeFix.
-Each class of package ShapeFix deals with one certain type of shapes or with some family of problems.
-There is no necessity for you to detect problems before using ShapeFix because all components of package ShapeFix make an analysis of existing problems before fixing them by a corresponding tool from package of ShapeAnalysis and then fix the discovered problems.
-The ShapeFix package currently includes functions that:
+Algorithms for fixing problematic (violating the OCCT requirements) shapes are placed in package *ShapeFix*.
+
+Each class of package *ShapeFix* deals with one certain type of shapes or with some family of problems.
+
+There is no necessity for you to detect problems before using *ShapeFix* because all components of package *ShapeFix* make an analysis of existing problems before fixing them by a corresponding tool from package of *ShapeAnalysis* and then fix the discovered problems.
+
+The *ShapeFix* package currently includes functions that:
* add a 2D curve or a 3D curve where one is missing,
* correct a deviation of a 2D curve from a 3D curve when it exceeds a given tolerance value,
* limit the tolerance value of shapes within a given range,
The sequence of actions is as follows :
1. Create tool *ShapeFix_Shape* and initialize it by shape:
-
~~~~~
Handle(ShapeFix_Shape) sfs = new ShapeFix_Shape;
sfs->Init ( shape );
~~~~~
-
2. Set the basic precision and the maximum allowed tolerance:
-
~~~~~
sfs->SetPrecision ( Prec );
sfs->SetMaxTolerance ( maxTol );
~~~~~
-
-Where *Prec* – basic precision, *maxTol* – maximum allowed tolerance.
-
+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. If a value larger than the maximum allowed tolerance is necessary for correcting a detected problem the problem can not be fixed.
-
3. Launch fixing:
-
~~~~~
sfs->Perform();
~~~~~
-
4. Get the result:
-
~~~~~
TopoDS_Shape aResult = sfs-Shape();
~~~~~
-
In some cases using only *ShapeFix_Shape* can be insufficient. It is possible to use tools for merging and removing small edges and fixing gaps between 2D and 3D curves.
-
5. Create *ShapeFix_Wireframe* tool and initialize it by shape:
-
~~~~~
Handle(ShapeFix_Wirefarme) SFWF = new ShapeFix_Wirefarme(shape);
Or
Handle(ShapeFix_Wirefarme) SFWF = new ShapeFix_Wirefarme;
SFWF->Load(shape);
~~~~~
-
6. Set the basic precision and the maximum allowed tolerance:
~~~~~
sfs->SetPrecision ( Prec );
sfs->SetMaxTolerance ( maxTol );
~~~~~
-
-See the description for Prec and maxTol above.
-
+See the description for *Prec* and *maxTol* above.
7. Merge and remove small edges:
~~~~~
SFWF-DropSmallEdgesMode() = Standard_True;
SFWF-FixSmallEdges();
~~~~~
-
**Note:** Small edges are not removed with the default mode, but in many cases removing small edges is very useful for fixing a shape.
-
8. Fix gaps for 2D and 3D curves
~~~~~
SFWF-FixWireGaps();
~~~~~
-
9. Get the result
~~~~~
TopoDS_Shape Result = SFWF-Shape();
@subsection occt_shg_2_2 Shape Correction.
If you do not want to make fixes on the whole shape or make a definite set of fixes you can set flags for separate fix cases (marking them ON or OFF) and you can also use classes for fixing specific types of sub-shapes such as solids, shells, faces, wires, etc.
+
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
* fix the subshape;
* get the resulting whole shape containing a new corrected subshape.
-For example, in the following way it is possible to fix face Face1 of shape Shape1
+For example, in the following way it is possible to fix face *Face1* of shape *Shape1*:
~~~~~
//create tools for fixing a face
-Handle(ShapeFix_Face) SFF= new ShapeFix_Face;
+Handle(ShapeFix_Face) SFF= new ShapeFix_Face;
// create tool for rebuilding a shape and initialize it by shape
-Handle(ShapeBuild_ReShape) Context = new ShapeBuild_ReShape;
+Handle(ShapeBuild_ReShape) Context = new ShapeBuild_ReShape;
Context-Apply(Shape1);
//set a tool for rebuilding a shape in the tool for fixing
SFF-SetContext(Context);
-
+
//initialize the fixing tool by one face
SFF-Init(Face1);
//fix the set face
SFF-Perform();
-
+
//get the result
-TopoDS_Shape NewShape = Context-Apply(Shape1);
+TopoDS_Shape NewShape = Context-Apply(Shape1);
//Resulting shape contains the fixed face.
~~~~~
The following sequence of actions should be applied to perform fixes:
1. Create a tool.
2. Set the following values:
- + the working precision by method *SetPrecision()* (default 1.e-7)
+ + the working precision by method *SetPrecision()* (default 1.e-7)
+ set the maximum allowed tolerance by method *SetMaxTolerance()* (by default it is equal to the working precision).
+ set the minimum tolerance by method *SetMinTolerance()* (by default it is equal to the working precision).
+ set a tool for rebuilding shapes after the modification (tool *ShapeBuild_ReShape*) by method *SetContext()*. For separate faces, wires and edges this tool is set optionally.
@subsubsection occt_shg_2_3_3 Repairing tool for shapes
-Class ShapeFix_Shape allows using repairing tools for all sub-shapes of a shape. It provides access to all repairing tools for fixing sub-shapes of the specified shape and to all control flags from these tools.
+Class *ShapeFix_Shape* allows using repairing tools for all sub-shapes of a shape. It provides access to all repairing tools for fixing sub-shapes of the specified shape and to all control flags from these tools.
For example, it is possible to force the removal of invalid 2D curves from a face.
* *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.
+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
-Class ShapeFix_Face allows fixing the problems connected with wires of a face. It allows controlling the creation of a face (adding wires), and fixing wires by means of tool *ShapeFix_Wire*.
+Class *ShapeFix_Face* allows fixing the problems connected with wires of a face. It allows controlling the creation of a face (adding wires), and fixing wires by means of tool *ShapeFix_Wire*.
When a wire is added to a face, it can be reordered and degenerated edges can be fixed. This is performed or not depending on the user-defined flags (by default, False).
The following fixes are available:
* fixing of wires orientation on the face. If the face has no wire, the natural bounds are computed. If the face is on a spherical surface and has two or more wires on it describing holes, the natural bounds are added. In case of a single wire, it is made to be an outer one. If the face has several wires, they are oriented to lay one outside another (if possible). If the supporting surface is periodic, 2D curves of internal wires can be shifted on integer number of periods to put them inside the outer wire.
- * 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 Open CASCADE Technology). In that case, these wires are connected by means of seam edges into the same wire.
+ * 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.
+* *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.
+* *FixSmallAreaWireMode* - mode to fix a small-area wire, False by default. If True, drops wires bounding small areas.
~~~~~
TopoDS_Face newface = sff.Face();
~~~~~
-@subsubsection occt_shg_2_3_7 Repairing tool for wires ()
+@subsubsection occt_shg_2_3_7 Repairing tool for wires
-Class ShapeFix_Wire allows fixing a wire. Its method Perform() performs all the available fixes in addition to the geometrical filling of gaps. The geometrical filling of gaps can be made with the help of the tool for fixing the wireframe of shape *ShapeFix_Wireframe*.
+Class *ShapeFix_Wire* allows fixing a wire. Its method *Perform()* performs all the available fixes in addition to the geometrical filling of gaps. The geometrical filling of gaps can be made with the help of the tool for fixing the wireframe of shape *ShapeFix_Wireframe*.
The fixing order and the default behavior of *Perform()* is as follows:
- * Edges in the wire *FixReorder* are reordered; in case it is forbidden, the analysis of whether the wire is ordered or not is performed anyway (this information is used for determining the default behavior of other methods).
- * Small edges *FixSmall *are removed.
- * Edges in the wire are connected (topologically) *FixConnected* (if the wire is ordered).
- * Edges (3Dcurves and 2D curves) *FixEdgeCurves* (without *FixShifted* if the wire is not ordered) are fixed.
- * Degenerated edges *FixDegenerated* are added (if the wire is ordered).
- * Self-intersection *FixSelfIntersection* is fixed (if the wire is ordered and *ClosedMode* is True).
- * Lacking edges *FixLacking* are fixed (if the wire is ordered).
-
-Most of fixing methods expect edges in a wire to be ordered, so it is necessary to make call to *FixReorder()* before making any other fixes.
+ * Edges in the wire are reordered by *FixReorder*. Most of fixing methods expect edges in a wire to be ordered, so it is necessary to make call to *FixReorder()* before making any other fixes. Even if it is forbidden, the analysis of whether the wire is ordered or not is performed anyway.
+ * Small edges are removed by *FixSmall* .
+ * Edges in the wire are connected (topologically) by *FixConnected* (if the wire is ordered).
+ * Edges (3Dcurves and 2D curves) are fixed by *FixEdgeCurves* (without *FixShifted* if the wire is not ordered).
+ * Degenerated edges are added by *FixDegenerated*(if the wire is ordered).
+ * Self-intersection is fixed by *FixSelfIntersection* (if the wire is ordered and *ClosedMode* is True).
+ * Lacking edges are fixed by *FixLacking* (if the wire is ordered).
+
+ The flag *ClosedWireMode* specifies whether the wire is (or should be) closed or not. If that flag is True (by default), fixes that require or force connection between edges are also executed for the last and the first edges.
+
+The fixing methods can be turned on/off by using their corresponding control flags:
+* *FixReorderMode,*
+* *FixSmallMode,*
+* *FixConnectedMode,*
+* *FixEdgeCurvesMode,*
+* *FixDegeneratedMode,*
+* *FixSelfIntersectionMode*
Some fixes can be made in three ways:
* Increasing the tolerance of an edge or a vertex.
* 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).
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.
-
-The methods of this class correct the following problems. They:
- * fix disordered edges in the wire (reorder),
- * fix small edges (remove edges with a length less than the given value),
- * fix disconnected edges (adjacent edges having different vertices),
- * fix the consistency of edge curves,
- * fix degenerated edges,
- * fix intersections of 2D curves of the edges,
- * fix lacking edges to fill gaps in the parametrical space of a surface,
- * fix gaps in 2D and 3D wires by means of geometrical filling.
+* *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
------------------------
-This fix is necessary for most other fixes (but is not necessary for Open CASCADE Technology). It checks whether edges in the wire go in a sequential order (the end of a preceding edge is the start of a following one). If it is not so, an attempt to reorder the edges is made.
+#### Fixing disordered edges
+
+*FixReorder* is necessary for most other fixes (but is not necessary for Open CASCADE Technology). It checks whether edges in the wire go in a sequential order (the end of a preceding edge is the start of a following one). If it is not so, an attempt to reorder the edges is made.
-Fixing small edges
-------------------
-This fixing method searches for the edges, which have a length less than the given value (degenerated edges are ignored). If such an edge is found, it is removed provided that one of the following conditions is satisfied:
+#### Fixing small edges
+
+*FixSmall* method searches for the edges, which have a length less than the given value (degenerated edges are ignored). If such an edge is found, it is removed provided that one of the following conditions is satisfied:
* both end vertices of that edge are one and the same vertex,
* end vertices of the edge are different, but the flag *ModifyTopologyMode* is True. In the latter case, method *FixConnected* is applied to the preceding and the following edges to ensure their connection.
-Fixing disconnected edges
--------------------------
-This method forces two adjacent edges to share the same common vertex (if they do not have a common one). It checks whether the end vertex of the preceding edge coincides with the start vertex of the following edge with the given precision, and then creates a new vertex and sets it as a common vertex for the fixed edges. At that point, edges are copied, hence the wire topology is changed (regardless of the *ModifyTopologyMode* flag). If the vertices do not coincide, this method fails.
-
-Fixing the consistency of edge curves
--------------------------------------
-This method performs a set of fixes dealing with 3D curves and 2D curves of edges in a wire.
-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,
- * removing a wrong 2D curve by call to *ShapeFix_Edge::FixRemovePCurve* - only if forced,
- * fixing a missing 2D curve by call to *ShapeFix_Edge::FixAddPCurve* - if not forbidden,
- * removing a wrong 3D curve by call to *ShapeFix_Edge::FixRemoveCurve3d* - only if forced,
- * fixing a missing 3D curve by call to *ShapeFix_Edge::FixAddCurve3d* - if not forbidden,
- * fixing 2D curves of seam edges - if not forbidden.
- * fixing 2D curves which can be shifted at an integer number of periods on the closed surface - if not forbidden. 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 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.
+#### Fixing disconnected edges
+
+*FixConnected* method forces two adjacent edges to share the same common vertex (if they do not have a common one). It checks whether the end vertex of the preceding edge coincides with the start vertex of the following edge with the given precision, and then creates a new vertex and sets it as a common vertex for the fixed edges. At that point, edges are copied, hence the wire topology is changed (regardless of the *ModifyTopologyMode* flag). If the vertices do not coincide, this method fails.
+
+#### Fixing the consistency of edge curves
+
+*FixEdgeCurves* method performs a set of fixes dealing with 3D curves and 2D curves of edges in a wire.
+
+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*.
+
+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 degenerated edges
-------------------------
-This method checks whether an edge in a wire lies on a degenerated point of the supporting surface, or whether there is a degenerated point between the edges. If one of these cases is detected for any edge, a new degenerated edge is created and it replaces the current edge in the first case or is added to the wire in the second case. The newly created degenerated edge has a straight 2D curve, which goes from the end of the 2D curve of the preceding edge to the start of the following one.
+#### Fixing degenerated edges
+
+*FixDegenerated* method checks whether an edge in a wire lies on a degenerated point of the supporting surface, or whether there is a degenerated point between the edges. If one of these cases is detected for any edge, a new degenerated edge is created and it replaces the current edge in the first case or is added to the wire in the second case. The newly created degenerated edge has a straight 2D curve, which goes from the end of the 2D curve of the preceding edge to the start of the following one.
-Fixing intersections of 2D curves of the edges
-----------------------------------------------
-This method detects and fixes the following problems:
+#### Fixing intersections of 2D curves of the edges
+
+*FixSelfIntersection* method detects and fixes the following problems:
* self-intersection of 2D curves of individual edges. If the flag *ModifyGeometryMode()* is False this fix will be performed by increasing the tolerance of one of end vertices to a value less then *MaxTolerance()*.
* intersection of 2D curves of each of the two adjacent edges (except the first and the last edges if the flag ClosedWireMode is False). If such intersection is found, the common vertex is modified in order to comprise the intersection point. If the flag *ModifyTopologyMode* is False this fix will be performed by increasing the tolerance of the vertex to a value less then *MaxTolerance()*.
- * intersection of 2D curves of non-adjacent edges. If such intersection is found the tolerance of the nearest vertex is increased to comprise the intersection point. If such increase cannot be done with a tolerance less than MaxTolerance this fix will not be performed.
-
+ * intersection of 2D curves of non-adjacent edges. If such intersection is found the tolerance of the nearest vertex is increased to comprise the intersection point. If such increase cannot be done with a tolerance less than *MaxTolerance* this fix will not be performed.
-Fixing a lacking edge
----------------------
-This 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.
+#### Fixing a lacking edge
-Fixing gaps in 2D and 3D wire by geometrical filling
-----------------------------------------------------
-These methods check gaps between the ends of 2D or 3D curves of adjacent edges. Boolean flag *FixGapsByRanges* is used to activate an additional mode applied before converting to B-Splines. When this mode is on, methods try to find the most precise intersection of curves, or the most precise projection of a target point, or an extremity point between two curves (to modify their parametric range accordingly). This mode is off by default. Independently of the additional mode described above, if gaps remain, these methods convert curves to B-Spline form and shift their ends if a gap is detected.
-Method *FixGap2d* moves the ends of 2D curves to the middle point. Method *FixGaps3d* moves the ends of 3D curves to a common vertex.
+*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.
+
+#### 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:
+* Method *FixGap2d* moves the ends of 2D curves to the middle point.
+* Method *FixGaps3d* moves the ends of 3D curves to a common vertex.
+
+Boolean flag *FixGapsByRanges* is used to activate an additional mode applied before converting to B-Splines. When this mode is on, methods try to find the most precise intersection of curves, or the most precise projection of a target point, or an extremity point between two curves (to modify their parametric range accordingly). This mode is off by default. Independently of the additional mode described above, if gaps remain, these methods convert curves to B-Spline form and shift their ends if a gap is detected.
+
+#### Example: A custom set of fixes
-This tool has the following control flags:
-* *ClosedWireMode* -specifies whether the wire is (or should be) closed or not. If that flag is True (by default), fixes that require or force connection between edges are executed for the last and the first edges also, otherwise they are not.
-* *FixReorderMode, *
-* *FixSmallMode, *
-* *FixConnectedMode, *
-* *FixEdgeCurvesMode, *
-* *FixDegeneratedMode, *
-* *FixSelfIntersectionMode,*
-* *FixLackingMode.*
-
-The following flags are defined for method *FixEdgeCurves()*:
-* *FixReversed2dMode, *
-* *FixRemovePCurveMode, *
-* *FixRemoveCurve3dMode, *
-* *FixAddPCurveMode, *
-* *FixAddCurve3dMode, *
-* *FixSeamMode, *
-* *FixShiftedMode, *
-* *FixSameParameterMode. *
-
-The following flags are defined for method *FixSelfIntersection()*:
-* *FixSelfIntersectingEdgeMode, *
-* *FixIntersectingEdgesMode*.
-
-Example: A custom set of fixes
-------------------------------
Let us create a custom set of fixes as an example.
~~~~~
//the same vertex
Standard_Boolean LockVertex = Standard_True;
if (sfw.FixSmall (LockVertex, precision)) {
- //Removes all edges which are shorter than
- //the given precision and have the same vertex at both ends
+ //Removes all edges which are shorter than
+ //the given precision and have the same vertex at both ends
}
if (sfw.FixSelfIntersection()) {
- //Fixes self-intersecting edges and intersecting
- //adjacent edges
- cout;Wire was slightly self-intersecting. Repaired;endl;
+ //Fixes self-intersecting edges and intersecting
+ //adjacent edges
+ cout;Wire was slightly self-intersecting. Repaired;endl;
}
if ( sfw.FixLacking ( Standard_False ) ) {
- //Inserts edges to connect adjacent
- //non-continuous edges
+ //Inserts edges to connect adjacent
+ //non-continuous edges
}
TopoDS_Wire newwire = sfw.Wire();
//Returns the corrected wire
~~~~~
-Example: Correction of a wire
------------------------------
+#### Example: Correction of a wire
Let us correct the following wire:
-
+@image html /user_guides/shape_healing/images/shape_healing_image013.png "Initial shape"
+@image latex /user_guides/shape_healing/images/shape_healing_image013.png "Initial shape"
-It is necessary to apply the <a href="occt_shg_3_1_2">Tools for the analysis of validity of wires</a> to check that:
+It is necessary to apply the <a href="#_3_1_2">Tools for the analysis of validity of wires</a> to check that:
* the edges are correctly oriented;
* there are no edges that are too short;
* there are no intersecting adjacent edges;
As the result all failures have been fixed.
-
+@image html /user_guides/shape_healing/images/shape_healing_image014.png "Resulting shape"
+@image latex /user_guides/shape_healing/images/shape_healing_image014.png "Resulting shape"
@subsubsection occt_shg_2_3_8 Repairing tool for edges
Class *ShapeFix_Edge* provides tools for fixing invalid edges. The following geometrical and/or topological inconsistencies are detected and fixed:
* missing 3D curve or 2D curve,
* mismatching orientation of a 3D curve and a 2D curve,
- * incorrect SameParameter flag (curve deviation is greater than the edge tolerance).
+ * incorrect SameParameter flag (curve deviation is greater than the edge tolerance).
Each fixing method first checks whether the problem exists using methods of the *ShapeAnalysis_Edge* class. If the problem is not detected, nothing is done.
This tool does not have the method *Perform()*.
To see how this tool works, it is possible to take an edge, where the maximum deviation between the 3D curve and 2D curve P1 is greater than the edge tolerance.
-
+@image html /user_guides/shape_healing/images/shape_healing_image011.png "Initial shape"
+@image latex /user_guides/shape_healing/images/shape_healing_image011.png "Initial shape"
-First it is necessary to apply the <a href="occt_shg_3_1_3">Tool for checking the validity of edges</a> to find that maximum deviation between pcurve and 3D curve is greater than tolerance. Then we can use the repairing tool to increase the tolerance and make the deviation acceptable.
+First it is necessary to apply the <a href="#_3_1_3">Tool for checking the validity of edges</a> to find that maximum deviation between pcurve and 3D curve is greater than tolerance. Then we can use the repairing tool to increase the tolerance and make the deviation acceptable.
~~~~~
ShapeAnalysis_Edge sae;
}
~~~~~
-
+@image html /user_guides/shape_healing/images/shape_healing_image012.png "Resulting shape"
+@image latex /user_guides/shape_healing/images/shape_healing_image012.png "Resulting shape"
As the result, the edge tolerance has been increased.
TopoDS_Shape resShape = sff.FixShape();
~~~~~
-@subsubsection occt_shg_2_3_11 Tool to modify tolerances of shapes (Class ShapeFix_ShapeTolerance).
+@subsubsection occt_shg_2_3_11 Tool to modify tolerances of shapes (Class ShapeFix_ShapeTolerance).
This tool provides a functionality to set tolerances of a shape and its sub-shapes.
In Open CASCADE Technology only vertices, edges and faces have tolerances.
@section occt_shg_3 Analysis
-@section occt_shg_3_1 Analysis of shape validity
+@subsection occt_shg_3_1 Analysis of shape validity
The *ShapeAnalysis* package provides tools for the analysis of topological shapes.
It is not necessary to check a shape by these tools before the execution of repairing tools because these tools are used for the analysis before performing fixes inside the repairing tools.
However, if you want, these tools can be used for detecting some of shape problems independently from the repairing tools.
- It can be done in the following way:
+
+ It can be done in the following way:
* create an analysis tool.
* initialize it by shape and set a tolerance problems will be detected with if it is necessary.
* check the problem that interests you.
ShapeAnalysis_Edge sae;
//Creates a tool for analyzing an edge
for(TopExp_Explorer Exp(face,TopAbs_EDGE);Exp.More();Exp.Next()) {
- TopoDS_Edge edge = TopoDS::Edge (Exp.Current());
- if (!sae.HasCurve3d (edge)) {
- cout *Edge has no 3D curve* endl; }
+ TopoDS_Edge edge = TopoDS::Edge (Exp.Current());
+ if (!sae.HasCurve3d (edge)) {
+ cout *Edge has no 3D curve* endl; }
}
~~~~~
* 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.
-*Note* that all checking operations except for the first one are based on the assumption that edges in the wire are ordered. Thus, if the wire is detected as non-ordered it is necessary to order it before calling other checking operations. This can be done, for example, with the help of the *ShapeFix_Wire::FixOrder()* method.
+**Note** that all checking operations except for the first one are based on the assumption that edges in the wire are ordered. Thus, if the wire is detected as non-ordered it is necessary to order it before calling other checking operations. This can be done, for example, with the help of the *ShapeFix_Wire::FixOrder()* method.
+
This tool should be initialized with wire, face (or a surface with a location) or precision.
Once the tool has been initialized, it is possible to perform the necessary checking operations. In order to obtain all information on a wire at a time the global method *Perform* is provided. It calls all other API checking operations to check each separate case.
+
API methods check for corresponding cases only, the value and the status they return can be analyzed to understand whether the case was detected or not.
+
Some methods in this class are:
* *CheckOrder* checks whether edges in the wire are in the right order
* *CheckConnected* checks whether edges are disconnected
* *CheckSmall* checks whether there are edges that are shorter than the given value
* *CheckSelfIntersection* checks, whether there are self-intersecting or adjacent intersecting edges. If the intersection takes place due to nonadjacent edges, it is not detected.
-This class maintains status management. Each API method stores the status of its last execution which can be queried by the corresponding Status..() method. In addition, each API method returns a Boolean value, which is True when a case being analyzed is detected (with the set ShapeExtend_DONE status), otherwise it is False.
+
+This class maintains status management. Each API method stores the status of its last execution which can be queried by the corresponding *Status..()* method. In addition, each API method returns a Boolean value, which is True when a case being analyzed is detected (with the set *ShapeExtend_DONE* status), otherwise it is False.
~~~~~
TopoDS_Face face = ...;
ShapeAnalysis_Wire saw (wire, face, precision);
//Creates a tool and loads objects into it
if (saw.CheckOrder()) {
- cout*Some edges in the wire need to be reordered*endl;
- cout*Please ensure that all the edges are correctly
+ cout*Some edges in the wire need to be reordered*endl;
+ cout*Please ensure that all the edges are correctly
ordered before further analysis*endl;
- return;
+ return;
}
if (saw.CheckSmall (precision)) {
- cout*Wire contains edge(s) shorter than *precisionendl;
+ cout*Wire contains edge(s) shorter than *precisionendl;
}
if (saw.CheckConnected()) {
- cout*Wire is disconnected*endl;
+ cout*Wire is disconnected*endl;
}
if (saw.CheckSelfIntersection()) {
- cout*Wire has self-intersecting or intersecting
+ cout*Wire has self-intersecting or intersecting
adjacent edges* endl;
}
~~~~~
ShapeAnalysis_Edge sae;
//Creates a tool for analyzing an edge
for(TopExp_Explorer Exp(face,TopAbs_EDGE);Exp.More();Exp.Next()) {
- TopoDS_Edge edge = TopoDS::Edge (Exp.Current());
- if (!sae.HasCurve3d (edge)) {
- cout *Edge has no 3D curve* endl;
- }
- Handle(Geom2d_Curve) pcurve;
- Standard_Real cf, cl;
- if (sae.PCurve (edge, face, pcurve, cf, cl, Standard_False)) {
- //Returns the pcurve and its range on the given face
- cout*Pcurve range [*cf*, *cl*]* endl;
- }
- Standard_Real maxdev;
- if (sae.CheckSameParameter (edge, maxdev)) {
- //Checks the consistency of all the curves
- //in the edge
- cout*Incorrect SameParameter flag*endl;
- }
- cout*Maximum deviation *maxdev*, tolerance*
- BRep_Tool::Tolerance(edge)endl;
+ TopoDS_Edge edge = TopoDS::Edge (Exp.Current());
+ if (!sae.HasCurve3d (edge)) {
+ cout *Edge has no 3D curve* endl;
+ }
+ Handle(Geom2d_Curve) pcurve;
+ Standard_Real cf, cl;
+ if (sae.PCurve (edge, face, pcurve, cf, cl, Standard_False)) {
+ //Returns the pcurve and its range on the given face
+ cout*Pcurve range [*cf*, *cl*]* endl;
+ }
+ Standard_Real maxdev;
+ if (sae.CheckSameParameter (edge, maxdev)) {
+ //Checks the consistency of all the curves
+ //in the edge
+ cout*Incorrect SameParameter flag*endl;
+ }
+ cout*Maximum deviation *maxdev*, tolerance*
+ BRep_Tool::Tolerance(edge)endl;
}
//checks the overlapping of two edges
if(sae.CheckOverlapping(edge1,edge2,prec,dist)) {
cout*Maximum tolerance of the vertices is *MaxOnVertexendl;
Standard_Real MaxAllowed = 0.1;
if (MaxOnVertex MaxAllowed) {
- cout*Maximum tolerance of the vertices exceeds
- maximum allowed*endl;
+ cout*Maximum tolerance of the vertices exceeds
+ maximum allowed*endl;
}
~~~~~
~~~~~
ShapeAnalysis_FreeBounds safb(shape);
~~~~~
+
When connecting edges into wires this algorithm tries to build wires of maximum length. Two options are provided for the user to extract closed sub-contours out of closed and/or open contours. Free bounds are returned as two compounds, one for closed and one for open wires. To obtain a result it is necessary to use methods:
~~~~~
-TopoDS_Compound ClosedWires = safb.GetClosedWires();
+TopoDS_Compound ClosedWires = safb.GetClosedWires();
TopoDS_Compound OpenWires = safb.GetOpenWires();
~~~~~
This class also provides some static methods for advanced use: connecting edges/wires to wires, extracting closed sub-wires from wires, distributing wires into compounds for closed and open wires.
@subsubsection occt_shg_3_2_3 Analysis of shape contents
-Class ShapeAnalysis_ShapeContents provides tools counting the number of sub-shapes and selecting a sub-shape by the following criteria:
+Class *ShapeAnalysis_ShapeContents* provides tools counting the number of sub-shapes and selecting a sub-shape by the following criteria:
+
Methods for getting the number of sub-shapes:
* number of solids,
* number of shells,
* number of faces,
* number of edges,
* number of vertices.
+
Methods for calculating the number of geometrical objects or sub-shapes with a specified type:
* number of free faces,
* number of free wires,
* number of C0 surfaces,
* number of C0 curves,
* number of BSpline surfaces,… etc
+
and selecting sub-shapes by various criteria.
The corresponding flags should be set to True for storing a shape by a specified criteria:
* convert to Bezier surfaces and Bezier curves,
* split closed faces,
* convert C0 BSpline curve to a sequence of C1 BSpline curves.
+
All tools for particular cases are based on general tools for shape splitting but each of them has its own tools for splitting or converting geometry in accordance with the specified criteria.
General tools for shape splitting are:
* tool for splitting the whole shape,
* tool for splitting a face,
* tool for splitting wires.
+
Tools for shape splitting use tools for geometry splitting:
* tool for splitting surfaces,
* tool for splitting 3D curves,
@subsubsection occt_shg_4_1_2 Using tools available for shape splitting.
If it is necessary to split a shape by a specified continuity, split closed faces in the shape, split surfaces of revolution in the shape by angle or to convert all surfaces, all 3D curves, all 2D curves in the shape to Bezier, it is possible to use the existing/available tools.
+
The usual way to use these tools exception for the tool of converting a C0 BSpline curve is the following:
* a tool is created and initialized by shape.
* work precision for splitting and the maximum allowed tolerance are set
TopoDS_Shape result = ShapeDivideCont.GetResult();
//get the history of modifications made to faces
for(TopExp_Explorer aExp(initShape,TopAbs_FACE); aExp.More(0; aExp.Next()) {
- TopoDS_Shape modifShape = ShapeDivideCont.GetContext()-
+ TopoDS_Shape modifShape = ShapeDivideCont.GetContext()-
Apply(aExp.Current());
}
~~~~~
@subsubsection occt_shg_4_1_3 Creation of a new tool for splitting a shape.
-To create a new splitting tool it is necessary to create tools for geometry splitting according to a desirable criterion. These new tools should be inherited from basic tools for geometry splitting. Then these new tools should be set into corresponding tools for shape splitting.
- * a new tool for surface splitting should be set into the tool for face splitting
- * new tools for splitting of 3D and 2D curves should be set into the splitting tool for wires.
-In order to be able to change the value of criterion of shape splitting it is necessary to create a new tool for shape splitting that should be inherited from the general splitting tool for shapes.
+To create a new splitting tool it is necessary to create tools for geometry splitting according to a desirable criterion. The new tools should be inherited from basic tools for geometry splitting. Then the new tools should be set into corresponding tools for shape splitting.
+ * a new tool for surface splitting should be set into the tool for face splitting
+ * new tools for splitting of 3D and 2D curves should be set into the splitting tool for wires.
+
+To change the value of criterion of shape splitting it is necessary to create a new tool for shape splitting that should be inherited from the general splitting tool for shapes.
Let us split a shape according to a specified criterion.
Handle(MyTools_SplitCurve2DTool) MySplitCurve2Dtool =
new MyTools_SplitCurve2DTool;
-//creation of a tool for splitting the shape and initialization of //that tool by shape.
+//creation of a tool for splitting the shape and initialization of //that tool by shape.
TopoDS_Shape initShape
MyTools_ShapeDivideTool ShapeDivide (initShape);
WireDivide-SetSplitCurve2dTool(MySplitCurve2DTool);
//setting of the value criterion.
- ShapeDivide.SetValCriterion(val);
-
+ ShapeDivide.SetValCriterion(val);
+
//shape splitting
ShapeDivide.Perform();
@subsubsection occt_shg_4_2_1 General tool for shape splitting
-Class *ShapeUpgrade_ShapeDivide* provides shape splitting and converting according to the given criteria. It performs these operations for each face with the given tool for face splitting (*ShapeUpgrade_FaceDivide* by default).
-This tool provides access to the tool for dividing faces with the help of the following methods:
-*SetSplitFaceTool*;
-*GetSpliFaceTool.*
+Class *ShapeUpgrade_ShapeDivide* provides shape splitting and converting according to the given criteria. It performs these operations for each face with the given tool for face splitting (*ShapeUpgrade_FaceDivide* by default).
+
+This tool provides access to the tool for dividing faces with the help of the methods *SetSplitFaceTool* and *GetSpliFaceTool.*
@subsubsection occt_shg_4_2_2 General tool for face splitting
-Class *ShapeUpgrade_FaceDivide* divides a Face (edges in the wires, by splitting 3D and 2D curves, as well as the face itself, by splitting the supporting surface) according to the given criteria.
+
+Class *ShapeUpgrade_FaceDivide* divides a Face (edges in the wires, by splitting 3D and 2D curves, as well as the face itself, by splitting the supporting surface) according to the given criteria.
+
The area of the face intended for division is defined by 2D curves of the wires on the Face.
All 2D curves are supposed to be defined (in the parametric space of the supporting surface).
The result is available after the call to the *Perform* method. It is a Shell containing all resulting Faces. All modifications made during the splitting operation are recorded in the external context (*ShapeBuild_ReShape*).
-This tool provides access to the tool for wire division and surface splitting by means of methods:
-*SetWireDivideTool,*
-*GetWireDivideTool,*
-*SetSurfaceSplitTool,*
-*GetSurfaceSplitTool*.
+
+This tool provides access to the tool for wire division and surface splitting by means of the following methods:
+* *SetWireDivideTool,*
+* *GetWireDivideTool,*
+* *SetSurfaceSplitTool,*
+* *GetSurfaceSplitTool*.
@subsubsection occt_shg_4_2_3 General tool for wire splitting
Class *ShapeUpgrade_WireDivide* divides edges in the wire lying on the face or free wires or free edges with a given criterion. It splits the 3D curve and 2D curve(s) of the edge on the face. Other 2D curves, which may be associated with the edge, are simply copied. If the 3D curve is split then the 2D curve on the face is split as well, and vice-versa. The original shape is not modified. Modifications made are recorded in the context (*ShapeBuild_ReShape*).
-This tool provides access to the tool for dividing and splitting 3D and 2D curves by means of methods:
-*SetEdgeDivdeTool,*
-*GetEdgeDivideTool,*
-*SetSplitCurve3dTool,*
-*GetSplitCurve3dTool,*
-*SetSplitCurve2dTool,*
-*GetSplitCurve2dTool*
-and it also provides access to the mode for splitting edges by methods:
-*SetEdgeMode,*
-*GetEdgeMode*
+
+This tool provides access to the tool for dividing and splitting 3D and 2D curves by means of the following methods:
+* *SetEdgeDivdeTool,*
+* *GetEdgeDivideTool,*
+* *SetSplitCurve3dTool,*
+* *GetSplitCurve3dTool,*
+* *SetSplitCurve2dTool,*
+* *GetSplitCurve2dTool*
+
+and it also provides access to the mode for splitting edges by methods *SetEdgeMode* and *GetEdgeMode*.
+
This mode sets whether only free edges, only shared edges or all edges are split.
-@subsubsection occt_shg_4_2_4 General tool for edge splitting
+@subsubsection occt_shg_4_2_4 General tool for edge splitting
+
Class *ShapeUpgrade_EdgeDivide* divides edges and their geometry according to the specified criteria. It is used in the wire-dividing tool.
+
This tool provides access to the tool for dividing and splitting 3D and 2D curves by the following methods:
-*SetSplitCurve3dTool,*
-*GetSplitCurve3dTool,*
-*SetSplitCurve2dTool,*
-*GetSplitCurve2dTool*.
+* *SetSplitCurve3dTool,*
+* *GetSplitCurve3dTool,*
+* *SetSplitCurve2dTool,*
+* *GetSplitCurve2dTool*.
@subsubsection occt_shg_4_2_5 General tools for geometry splitting
There are three general tools for geometry splitting.
* General tool for surface splitting.(*ShapeUpgrade_SplitSurface*)
* General tool for splitting 3D curves.(*ShapeUpgrade_SplitCurve3d*)
* General tool for splitting 2D curves.(*ShapeUpgrade_SplitCurve2d*)
+
All these tools are constructed the same way:
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.
+ + *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 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*).
Standard_EXPORT ShapeUpgrade_SplitSurfaceContinuity();
//methods to set the criterion and the tolerance into the splitting //tool
-Standard_EXPORT void SetCriterion(const GeomAbs_Shape Criterion) ;
-Standard_EXPORT void SetTolerance(const Standard_Real Tol) ;
+Standard_EXPORT void SetCriterion(const GeomAbs_Shape Criterion) ;
+Standard_EXPORT void SetTolerance(const Standard_Real Tol) ;
//re-definition of method Compute
Standard_EXPORT virtual void Compute(const Standard_Boolean Segment) ;
Handle(ShapeBuild_ReShape) ctx = sdc.Context();
.. on a given shape
if (ctx.IsRecorded (sh)) {
- TopoDS_Shape newsh = ctx->Value (sh);
+ TopoDS_Shape newsh = ctx->Value (sh);
// if there are several results, they are re-recorded inside a Compound
// .. process as needed
}
@subsubsection occt_shg_4_3_3 Conversion of 2D, 3D curves and surfaces to Bezier
-Class *ShapeUpgrade_ShapeConvertToBezier* is an API tool for performing a conversion of 3D, 2D curves to Bezier curves and surfaces to Bezier based surfaces (Bezier surface, surface of revolution based on Bezier curve, offset surface based on any of previous types).
+Class *ShapeUpgrade_ShapeConvertToBezier* is an API tool for performing a conversion of 3D, 2D curves to Bezier curves and surfaces to Bezier based surfaces (Bezier surface, surface of revolution based on Bezier curve, offset surface based on any of previous types).
+
This tool provides access to various flags for conversion of different types of curves and surfaces to Bezier by methods:
-For 3D curves:
-*Set3dConversion,*
-*Get3dConversion,*
-*Set3dLineConversion,*
-*Get3dLineConversion,*
-*Set3dCircleConversion,*
-*Get3dCircleConversion,*
-*Set3dConicConversion,*
-*Get3dConicConversion*
-For 2D curves:
-*Set2dConversion,*
-*Get2dConversion*
-For surfaces :
-*GetSurfaceConversion,*
-*SetPlaneMode,*
-*GetPlaneMode,*
-*SetRevolutionMode,*
-*GetRevolutionMode,*
-*SetExtrusionMode,*
-*GetExtrusionMode,*
-*SetBSplineMode,*
-*GetBSplineMode,*
+* For 3D curves:
+ * *Set3dConversion,*
+ * *Get3dConversion,*
+ * *Set3dLineConversion,*
+ * *Get3dLineConversion,*
+ * *Set3dCircleConversion,*
+ * *Get3dCircleConversion,*
+ * *Set3dConicConversion,*
+ * *Get3dConicConversion*
+* For 2D curves:
+ * *Set2dConversion,*
+ * *Get2dConversion*
+* For surfaces :
+ * *GetSurfaceConversion,*
+ * *SetPlaneMode,*
+ * *GetPlaneMode,*
+ * *SetRevolutionMode,*
+ * *GetRevolutionMode,*
+ * *SetExtrusionMode,*
+ * *GetExtrusionMode,*
+ * *SetBSplineMode,*
+ * *GetBSplineMode,*
Let us attempt to produce a conversion of planes to Bezier surfaces.
~~~~~
SCB.SetPlaneMode(Standard_True);
SCB.Perform();
If(SCB.Status(ShapeExtend_DONE)
- TopoDS_Shape result = SCB.GetResult();
+ TopoDS_Shape result = SCB.GetResult();
~~~~~
@subsubsection occt_shg_4_3_4 Tool for splitting closed faces
Standard_Integer NbSplitPoints = …;
tool.SetNbSplitPoints(num);
if ( ! tool.Perform() && tool.Status (ShapeExtend_FAIL) ) {
- cout;Splitting of closed faces failed;endl;
- . . .
+ cout;Splitting of closed faces failed;endl;
+ . . .
}
TopoDS_Shape aResult = tool.Result();
~~~~~
@subsubsection occt_shg_4_3_6 Tool for splitting faces
*ShapeUpgrade_ShapeDivideArea* can work with compounds, solids, shells and faces.
-During the work this tool examines each face of a specified shape and if the face area exceeds the specified maximal area, this face is divided. Face splitting is performed in the parametric space of this face. The values of splitting in U and V directions are calculated with the account of translation of the bounding box form parametric space to 3D space. Such calculations are necessary to avoid creation of strip faces. In the process of splitting the holes on the initial face are taken into account. After the splitting all new faces are checked by area again and the splitting procedure is repeated for the faces whose area still exceeds the max allowed area. Sharing between faces in the shape is preserved and the resulting shape is of the same type as the source shape.
+During the work this tool examines each face of a specified shape and if the face area exceeds the specified maximal area, this face is divided. Face splitting is performed in the parametric space of this face. The values of splitting in U and V directions are calculated with the account of translation of the bounding box form parametric space to 3D space.
+
+Such calculations are necessary to avoid creation of strip faces. In the process of splitting the holes on the initial face are taken into account. After the splitting all new faces are checked by area again and the splitting procedure is repeated for the faces whose area still exceeds the max allowed area. Sharing between faces in the shape is preserved and the resulting shape is of the same type as the source shape.
+
An example of using this tool is presented in the figures below:
-
+@image html /user_guides/shape_healing/images/shape_healing003.jpg "Source Face"
+@image latex /user_guides/shape_healing/images/shape_healing003.jpg "Source Face"
-
+@image html /user_guides/shape_healing/images/shape_healing004.jpg "Resulting shape"
+@image latex /user_guides/shape_healing/images/shape_healing004.jpg "Resulting shape"
*ShapeUpgrade_ShapeDivideArea* is inherited from the base class *ShapeUpgrade_ShapeDivide* and should be used in the following way:
tool.MaxArea() = aMaxArea;
tool.Perform();
if(tool.Status(ShapeExtend_DONE)) {
- TopoDS_Shape ResultShape = tool.Result();
- ShapeFix::SameParameter ( ResultShape, Standard_False );
+ TopoDS_Shape ResultShape = tool.Result();
+ ShapeFix::SameParameter ( ResultShape, Standard_False );
}
~~~~~
**Note** that the use of method *ShapeFix::SameParameter* is necessary, otherwise the parameter edges obtained as a result of splitting can be different.
-Additional methods
-------------------
+#### Additional methods
+
* Class *ShapeUpgrade_FaceDivideArea* inherited from *ShapeUpgrade_FaceDivide* is intended for splitting a face by the maximal area criterion.
* Class *ShapeUpgrade_SplitSurfaceArea* inherited from *ShapeUpgrade_SplitSurface* calculates the parameters of face splitting in the parametric space.
TopoDS_Shape resultShape = ShapeCustom::DirectFaces(initialShape);
~~~~~
-@subsubsection occt_shg_4_2_1 Conversion of indirect surfaces.
+@subsubsection occt_shg_4_4_1 Conversion of indirect surfaces.
~~~~~
ShapeCustom::DirectFaces
This method provides conversion of indirect elementary surfaces (elementary surfaces with left-handed coordinate systems) in the shape into direct ones. New 2d curves (recomputed for converted surfaces) are added to the same edges being shared by both the resulting shape and the original shape S.
-@subsubsection occt_shg_4_2_2 Shape Scaling
+@subsubsection occt_shg_4_4_2 Shape Scaling
~~~~~
ShapeCustom::ScaleShape
This method returns a new shape, which is a scaled original shape with a coefficient equal to the specified value of scale. It uses the tool *ShapeCustom_TrsfModification*.
-@subsubsection occt_shg_4_2_3 Conversion of curves and surfaces to BSpline
-*ShapeCustom_BSplineRestriction.* allows approximation of surfaces, curves and 2D curves with a specified degree, max number of segments, 2d tolerance and 3d tolerance. If the approximation result cannot be achieved with the specified continuity, the latter can be reduced.
+@subsubsection occt_shg_4_4_3 Conversion of curves and surfaces to BSpline
+
+*ShapeCustom_BSplineRestriction* allows approximation of surfaces, curves and 2D curves with a specified degree, maximum number of segments, 2d tolerance and 3d tolerance. If the approximation result cannot be achieved with the specified continuity, the latter can be reduced.
The method with all parameters looks as follows:
~~~~~
const Handle(ShapeCustom_RestrictionParameters)& aParameters)
~~~~~
-Returns a new shape with all surfaces, curves and 2D curves which type is BSpline/Bezier or based on the two latter, converted with Degree less than MaxDegree or with a number of spans less then *NbMaxSegment* depending on priority parameter Degree. If this parameter is equal to True then Degree will be increased to the value *GmaxDegree*, otherwise *NbMaxSegments* will be increased to the value *GmaxSegments*. *GmaxDegree* and *GMaxSegments* are the maximum possible degree and the number of spans correspondingly. These values will be used in those cases when an approximation with specified parameters is impossible and one of *GmaxDegree* or *GMaxSegments* is selected depending on priority.
+It returns a new shape with all surfaces, curves and 2D curves of BSpline/Bezier type or based on them, converted with a degree less than *MaxDegree* or with a number of spans less then *NbMaxSegment* depending on the priority parameter *Degree*. If this parameter is equal to True then *Degree* will be increased to the value *GmaxDegree*, otherwise *NbMaxSegments* will be increased to the value *GmaxSegments*. *GmaxDegree* and *GMaxSegments* are the maximum possible degree and the number of spans correspondingly. These values will be used in cases when an approximation with specified parameters is impossible and either *GmaxDegree* or *GMaxSegments* is selected depending on the priority.
+
Note that if approximation is impossible with *GMaxDegree*, even then the number of spans can exceed the specified *GMaxSegment*. Rational specifies whether Rational BSpline/Bezier should be converted into polynomial B-Spline.
+
Also note that the continuity of surfaces in the resulting shape can be less than the given value.
-Flags
------
+#### Flags
+
To convert other types of curves and surfaces to BSpline with required parameters it is necessary to use flags from class ShapeCustom_RestrictionParameters, which is just a container of flags.
The following flags define whether a specified-type geometry has been converted to BSpline with the required parameters:
-*ConvertPlane, *
-*ConvertBezierSurf, *
-*ConvertRevolutionSurf*
-*ConvertExtrusionSurf,.*
-*ConvertOffsetSurf,*
-*ConvertCurve3d,*
-*ConvertOffsetCurv3d,*
-*ConvertCurve2d,*
-*ConvertOffsetCurv2d,*
-*SegmentSurfaceMode*
+* *ConvertPlane, *
+* *ConvertBezierSurf, *
+* *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.
-Parameters *ConvertCurve3d* and *ConvertCurve2d* are responsible for conversion of all types of 3D and 2D curves.
-Parameters *ConvertOffsetCurv3d* and *ConvertOffsetCurv2d* are responsible for conversion of offset 3D and 2D curves.
-Parameter *SegmentSurfaceMode* defines whether the surface would be approximated within the boundaries of the face lying on this surface.
-@subsubsection occt_shg_4_2_4 Conversion of elementary surfaces into surfaces of revolution
+
+@subsubsection occt_shg_4_4_4 Conversion of elementary surfaces into surfaces of revolution
~~~~~
ShapeCustom::ConvertToRevolution()
TopoDS_Shape ShapeCustom::ConvertToRevolution(const TopoDS_Shape& S) ;
~~~~~
-This method returns a new shape with all elementary periodic surfaces converted to *Geom_SurfaceOfRevolution*. It uses the tool *ShapeCustom_ConvertToRevolution.*
+This method returns a new shape with all elementary periodic surfaces converted to *Geom_SurfaceOfRevolution*. It uses the tool *ShapeCustom_ConvertToRevolution*.
-@subsubsection occt_shg_4_2_5 Conversion of elementary surfaces into Bspline surfaces
+@subsubsection occt_shg_4_4_5 Conversion of elementary surfaces into Bspline surfaces
~~~~~
ShapeCustom::ConvertToBSpline()
const Standard_Boolean extrMode,
const Standard_Boolean revolMode,
const Standard_Boolean offsetMode);
-This method returns a new shape with all surfaces of linear extrusion, revolution and offset surfaces converted according to flags to Geom_BSplineSurface (with the same parameterization). It uses the tool *ShapeCustom_ConvertToBSpline.*
+~~~~~
+
+This method returns a new shape with all surfaces of linear extrusion, revolution and offset surfaces converted according to flags to *Geom_BSplineSurface* (with the same parameterization). It uses the tool *ShapeCustom_ConvertToBSpline*.
-@subsubsection occt_shg_4_2_6 Getting the history of modification of sub-shapes.
+@subsubsection occt_shg_4_4_6 Getting the history of modification of sub-shapes.
If, in addition to the resulting shape, you want to get the history of modification of sub-shapes you should not use the package methods described above and should use your own code instead:
1. Create a tool that is responsible for the necessary modification.
-2. Create the tool BRepTools_Modifier that performs a specified modification in the shape.
+2. Create the tool *BRepTools_Modifier* that performs a specified modification in the shape.
3. To get the history and to keep the assembly structure use the method *ShapeCustom::ApplyModifier*.
//To do this, enter:
for(TopTools_DataMapIteratorOfDataMapOfShapeShape
iter(context);iter(more ();iter.next ()) {
- TopoDs_Shape oneshape = iter.key ();
- TopoDs_Shape oneres = iter.value ();
+ TopoDs_Shape oneshape = iter.key ();
+ TopoDs_Shape oneres = iter.value ();
}
~~~~~
-@subsubsection occt_shg_4_2_7 Remove internal wires
+@subsubsection occt_shg_4_4_7 Remove internal wires
*ShapeUpgrade_RemoveInternalWires* tool removes internal wires with contour area less than the specified minimal area. It can work with compounds, solids, shells and faces.
+
If the flag *RemoveFaceMode* is set to TRUE, separate faces or a group of faces with outer wires, which consist only of edges that belong to the removed internal wires, are removed (seam edges are not taken into account). Such faces can be removed only for a sewed shape.
+
Internal wires can be removed by the methods *Perform*. Both methods *Perform* can not be carried out if the class has not been initialized by the shape. In such case the status of *Perform* is set to FAIL .
+
The method *Perform* without arguments removes from all faces in the specified shape internal wires whose area is less than the minimal area.
+
The other method *Perform* has a sequence of shapes as an argument. This sequence can contain faces or wires.
If the sequence of shapes contains wires, only the internal wires are removed.
+
If the sequence of shapes contains faces, only the internal wires from these faces are removed.
+
* The status of the performed operation can be obtained using method *Status()*;
* The resulting shape can be obtained using method *GetResult()*.
An example of using this tool is presented in the figures below:
-
-
+@image html /user_guides/shape_healing/images/shape_healing005.jpg "Source Face"
+@image latex /user_guides/shape_healing/images/shape_healing005.jpg "Source Face"
+@image html /user_guides/shape_healing/images/shape_healing006.jpg "Resulting shape"
+@image latex /user_guides/shape_healing/images/shape_healing006.jpg "Resulting shape"
After the processing three internal wires with contour area less than the specified minimal area have been removed. One internal face has been removed. The outer wire of this face consists of the edges belonging to the removed internal wires and a seam edge.
Two other internal faces have not been removed because their outer wires consist not only of edges belonging to the removed wires.
-
-
+@image html /user_guides/shape_healing/images/shape_healing007.jpg "Source Face"
+@image latex /user_guides/shape_healing/images/shape_healing007.jpg "Source Face"
+
+@image html /user_guides/shape_healing/images/shape_healing008.jpg "Resulting shape"
+@image latex /user_guides/shape_healing/images/shape_healing008.jpg "Resulting shape"
After the processing six internal wires with contour area less than the specified minimal area have been removed. Six internal faces have been removed. These faces can be united into groups of faces. Each group of faces has an outer wire consisting only of edges belonging to the removed internal wires. Such groups of faces are also removed.
aTool-Perform();
//check status set after method Perform
if(aTool-Status(ShapeExtend_FAIL) {
- cout*Operation failed* ;;\n;;
- return;
+ cout*Operation failed* ;;\n;;
+ return;
}
if(aTool-Status(ShapeExtend_DONE1)) {
- const TopTools_SequenceOfShape& aRemovedWires =aTool-RemovedWires();
- coutaRemovedWires.Length(); internal wires were removed;;\n;;
-
- }
+ const TopTools_SequenceOfShape& aRemovedWires =aTool-RemovedWires();
+ coutaRemovedWires.Length(); internal wires were removed;;\n;;
+
+ }
- if(aTool-Status(ShapeExtend_DONE2)) {
- const TopTools_SequenceOfShape& aRemovedFaces =aTool-RemovedFaces();
- coutaRemovedFaces.Length(); small faces were removed;;\n;;
-
- }
- //getting result shape
- TopoDS_Shape res = aTool-GetResult();
+ if(aTool-Status(ShapeExtend_DONE2)) {
+ const TopTools_SequenceOfShape& aRemovedFaces =aTool-RemovedFaces();
+ coutaRemovedFaces.Length(); small faces were removed;;\n;;
+
+ }
+ //getting result shape
+ TopoDS_Shape res = aTool-GetResult();
~~~~~
-@subsubsection occt_shg_4_2_8 Conversion of surfaces
+@subsubsection occt_shg_4_4_8 Conversion of surfaces
Class ShapeCustom_Surface allows:
* converting BSpline and Bezier surfaces to the analytical form (using method *ConvertToAnalytical())*
Handle(Geom_Surface) initSurf;
ShapeCustom_Surface ConvSurf(initSurf);
//conversion to analytical form
-Handle(Geom_Surface) newSurf = ConvSurf.ConvertToAnalytical(allowedtol,Standard_False);
+Handle(Geom_Surface) newSurf = ConvSurf.ConvertToAnalytical(allowedtol,Standard_False);
//or conversion to a periodic surface
-Handle(Geom_Surface) newSurf = ConvSurf.ConvertToPeriodic(Standard_False);
+Handle(Geom_Surface) newSurf = ConvSurf.ConvertToPeriodic(Standard_False);
//getting the maximum deviation of the new surface from the initial surface
Standard_Real maxdist = ConvSurf.Gap();
~~~~~
@subsection occt_shg_5_1 Tool for rebuilding shapes
*ShapeBuild_ReShape* rebuilds a shape by making pre-defined substitutions on some of its components. During the first phase, it records requests to replace or remove some individual shapes. For each shape, the last given request is recorded. Requests may be applied as *Oriented* (i.e. only to an item with the same orientation) or not (the orientation of the replacing shape corresponds to that of the original one). Then these requests may be applied to any shape, which may contain one or more of these individual shapes.
+
This tool has a flag for taking the location of shapes into account (for keeping the structure of assemblies) (*ModeConsiderLocation*). If this mode is equal to Standard_True, the shared shapes with locations will be kept. If this mode is equal to Standard_False, some different shapes will be produced from one shape with different locations after rebuilding. By default, this mode is equal to Standard_False.
+
To use this tool for the reconstruction of shapes it is necessary to take the following steps:
1. Create this tool and use method *Apply()* for its initialization by the initial shape. Parameter *until* sets the level of shape type and requests are taken into account up to this level only. Sub-shapes of the type standing beyond the *line* set by parameter until will not be rebuilt and no further exploration will be done
2. Replace or remove sub-shapes of the initial shape. Each sub-shape can be replaced by a shape of the same type or by shape containing shapes of that type only (for example, *TopoDS_Edge* can be replaced by *TopoDS_Edge, TopoDS_Wire* or *TopoDS_Compound* containing *TopoDS_Edges*). If an incompatible shape type is encountered, it is ignored and flag FAIL1 is set in Status.
@subsection occt_shg_5_2 Status definition
*ShapExtend_Status* is used to report the status after executing some methods that can either fail, do something, or do nothing. The status is a set of flags DONEi, FAILi, any combination of them can be set at the same time. For exploring the status, enumeration is used.
+
The values have the following meaning:
-|*OK,* | Nothing is done, everything OK |
-|*DONE1,* | Something was done, case 1 |
-|*DONE8*, | Something was done, case 8 |
-|*DONE*, | Something was done (any of DONE#) |
-|*FAIL1*, | The method failed, case 1 |
-|*FAIL8*, | The method failed, case 8 |
-|*FAIL* | The method failed (any of FAIL# occurred) |
+|*OK,* | Nothing is done, everything OK |
+|*DONE1,* | Something was done, case 1 |
+|*DONE8*, | Something was done, case 8 |
+|*DONE*, | Something was done (any of DONE#) |
+|*FAIL1*, | The method failed, case 1 |
+|*FAIL8*, | The method failed, case 8 |
+|*FAIL* | The method failed (any of FAIL# occurred) |
@subsection occt_shg_5_3 Tool representing a wire
Class *ShapeExtend_WireData* provides a data structure necessary to work with the wire as with an ordered list of edges, and that is required for many algorithms. The advantage of this class is that it allows to work with incorrect wires.
+
The object of the class *ShapeExtend_WireData* can be initialized by *TopoDS_Wire* and converted back to *TopoDS_Wire*.
+
An edge in the wire is defined by its rank number. Operations of accessing, adding and removing an edge at/to the given rank number are provided. Operations of circular permutation and reversing (both orientations of all edges and the order of edges) are provided on the whole wire as well.
+
This class also provides a method to check if the edge in the wire is a seam (if the wire lies on a face).
+
Let us remove edges from the wire and define whether it is seam edge
~~~~~
const Message_ListOfMsg &msglist = msgmap.Find (Shape1);
for (Message_ListIteratorOfListOfMsg iter (msglist);
iter.More(); iter.Next()) {
- Message_Msg msg = iter.Value();
- }
- }
+ Message_Msg msg = iter.Value();
+ }
+ }
~~~~~
@subsection occt_shg_5_6 Tools for performance measurement
@subsection occt_shg_6_1 Usage Workflow
The Shape Processing module allows defining and applying the general Shape Processing as a customizable sequence of Shape Healing operators. The customization is implemented via the user-editable resource file, which defines the sequence of operators to be executed and their parameters.
+
The Shape Processing functionality is implemented with the help of the *XSAlgo* interface. The main function *XSAlgo_AlgoContainer::ProcessShape()* does shape processing with specified tolerances and returns the resulting shape and associated information in the form of *Transient*.
This function is used in the following way:
Let us create a custom sequence of operations:
-1. Create a resource file with the name ResourceFile, which includes the following string:
+1. Create a resource file with the name *ResourceFile*, which includes the following string:
~~~~~
-NameSequence.exec.op: MyOper
+NameSequence.exec.op: MyOper
~~~~~
where *MyOper* is the name of operation.
-
2. Input a custom parameter for this operation in the resource file, for example:
~~~~~
NameSequence.MyOper.Tolerance: 0.01
~~~~~
-
-where Tolerance is the name of the parameter and 0.01 is its value.
-
+where *Tolerance* is the name of the parameter and 0.01 is its value.
3. Add the following string into *void ShapeProcess_OperLibrary::Init()*:
-
~~~~~
ShapeProcess::RegisterOperator(;MyOper;,
new ShapeProcess_UOperator(myfunction));
~~~~~
where *myfunction* is a function which implements the operation.
-
4. Create this function in *ShapeProcess_OperLibrary* as follows:
~~~~~
static Standard_Boolean myfunction (const
{
Handle(ShapeProcess_ShapeContext) ctx =
Handle(ShapeProcess_ShapeContext)::DownCast(context);
- if(ctx.IsNull()) return Standard_False;
- TopoDS_Shape aShape = ctx->Result();
- //receive our parameter:
- Standard_Real toler;
- ctx->GetReal(;Tolerance;, toler);
+ if(ctx.IsNull()) return Standard_False;
+ TopoDS_Shape aShape = ctx->Result();
+ //receive our parameter:
+ Standard_Real toler;
+ ctx->GetReal(;Tolerance;, toler);
~~~~~
-
-Now it is possible to make the necessary operations with *aShape* using the received value of parameter *Tolerance* from the resource file.
-
+5. Make the necessary operations with *aShape* using the received value of parameter *Tolerance* from the resource file.
~~~~~
- return Standard_True;
+ return Standard_True;
}
~~~~~
-
-It is possible to define some operations (with their parameters) *MyOper1, MyOper2, MyOper3*, etc. and describe the corresponding functions in *ShapeProcess_OperLibrary*. After that it will be possible to perform the required sequence using the specified name of operations and values of parameters in the resource file.
+6. Define some operations (with their parameters) *MyOper1, MyOper2, MyOper3*, etc. and describe the corresponding functions in *ShapeProcess_OperLibrary*.
+7. Perform the required sequence using the specified name of operations and values of parameters in the resource file.
For example: input of the following string:
~~~~~
-NameSequence.exec.op: MyOper1,MyOper3
+NameSequence.exec.op: MyOper1,MyOper3
~~~~~
means that the corresponding functions from *ShapeProcess_OperLibrary* will be performed with the original shape *(aShape)* using parameters defined for *MyOper1* and *MyOper3* in the resource file.
+
It is necessary to note that these operations will be performed step by step and the result obtained after performing the first operation will be used as the initial shape for the second operation.
@subsection occt_shg_6_2 Operators
-**DirectFaces** sets all faces based on indirect surfaces, defined with left-handed coordinate systems as direct faces. This concerns surfaces defined by Axis Placement (Cylinders, etc). Such Axis Placement may be indirect, which is allowed in Cascade, but not allowed in some other systems. This operator reverses indirect placements and recomputes PCurves accordingly.
-**SameParameter** is required after calling some other operators, according to the computations they do. Its call is explicit, so each call can be removed according to the operators, which are either called or not afterwards. This mainly concerns splitting operators that can split edges.
-The operator applies the computation *SameParameter* which ensures that various representations of each edge (its 3d curve, the pcurve on each of the faces on which it lies) give the same 3D point for the same parameter, within a given tolerance. For each edge coded as ;same parameter;, deviation of curve representation is computed and if the edge tolerance is less than that deviation, the tolerance is increased so that it satisfies the deviation. No geometry modification, only an increase of tolerance is possible. For each edge coded as ;not same parameter; the deviation is computed like 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*.
+
+### DirectFaces
+This operator sets all faces based on indirect surfaces, defined with left-handed coordinate systems as direct faces. This concerns surfaces defined by Axis Placement (Cylinders, etc). Such Axis Placement may be indirect, which is allowed in Cascade, but not allowed in some other systems. This operator reverses indirect placements and recomputes PCurves accordingly.
+
+### SameParameter
+This operator is required after calling some other operators, according to the computations they do. Its call is explicit, so each call can be removed according to the operators, which are either called or not afterwards. This mainly concerns splitting operators that can split edges.
+
+The operator applies the computation *SameParameter* which ensures that various representations of each edge (its 3d curve, the pcurve on each of the faces on which it lies) give the same 3D point for the same parameter, within a given tolerance.
+* For each edge coded as *same parameter*, deviation of curve representation is computed and if the edge tolerance is less than that deviation, the tolerance is increased so that it satisfies the deviation. No geometry modification, only an increase of tolerance is possible.
+* 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.
-**BSplineRestriction** is used for conversion of surfaces, curves 2d curves to BSpline surfaces with a specified degree and a specified number of spans.
-This operator performs approximations on surfaces, curves and 2d curves with a specified degree, max number of segments, 2d tolerance, 3d tolerance. The specified continuity can be reduced if the approximation with a specified continuity was not done successfully.
+ * *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
+
+This operator is used for conversion of surfaces, curves 2d curves to BSpline surfaces with a specified degree and a specified number of spans. It performs approximations on surfaces, curves and 2d curves with a specified degree, maximum number of segments, 2d tolerance, 3d tolerance. The specified continuity can be reduced if the approximation with a specified continuity was not done successfully.
+
This operator can be called with the following parameters:
* *Boolean : SurfaceMode* allows considering the surfaces;
* *Boolean : Curve3dMode* allows considering the 3d curves;
* *Boolean : PreferDegree* if true, *RequiredDegree* has a priority, else *RequiredNbSegments* has a priority;
* *Boolean : RationalToPolynomial* serves for conversion of BSplines to polynomial form;
* *Integer : MaxDegree* gives the maximum allowed Degree, if *RequiredDegree* cannot be reached;
-* *Integer : MaxNbSegments* gives the maximum allowed NbSegments, if *RequiredNbSegments* cannot be reached;
+* *Integer : MaxNbSegments* gives the maximum allowed NbSegments, if *RequiredNbSegments* cannot be reached.
-The following flags allow to manage the conversion of special types of curves or surfaces, in addition to BSpline. They are controlled by *SurfaceMode, Curve3dMode* or *Curve2dMode* respectively. By default, only BSplines and Bezier Geometries are considered.
-*Boolean : OffsetSurfaceMode*
-*Boolean : LinearExtrusionMode*
-*Boolean : RevolutionMode*
-*Boolean : OffsetCurve3dMode*
-*Boolean : OffsetCurve2dMode*
-*Boolean : PlaneMode*
-*Boolean : BezierMode*
-*Boolean : ConvCurve3dMode*
-*Boolean : ConvCurve2dMode*
-For each of the Mode parameters listed above, if it is True, the specified geometry is converted to BSpline, otherwise only its basic geometry is checked and converted (if necessary) keeping the original type of geometry (revolution, offset, etc.).
-*Boolean :SegmentSurfaceMode* has effect only for Bsplines and Bezier surfaces. When False a surface will be replaced by a Trimmed Surface, else new geometry will be created by splitting the original Bspline or Bezier surface.
-
-**ElementaryToRevolution** converts elementary periodic surfaces to SurfaceOfRevolution.
-
-**SplitAngle** 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.
-This operator can be called with the following parameters:
+The following flags allow managing the conversion of special types of curves or surfaces, in addition to BSpline. They are controlled by *SurfaceMode, Curve3dMode* or *Curve2dMode* respectively; by default, only BSplines and Bezier Geometries are considered:
+* *Boolean : OffsetSurfaceMode*
+* *Boolean : LinearExtrusionMode*
+* *Boolean : RevolutionMode*
+* *Boolean : OffsetCurve3dMode*
+* *Boolean : OffsetCurve2dMode*
+* *Boolean : PlaneMode*
+* *Boolean : BezierMode*
+* *Boolean : ConvCurve3dMode*
+* *Boolean : ConvCurve2dMode*
+
+For each of the Mode parameters listed above, if it is True, the specified geometry is converted to BSpline, otherwise only its basic geometry is checked and converted (if necessary) keeping the original type of geometry (revolution, offset, etc).
+
+* *Boolean :SegmentSurfaceMode* has effect only for Bsplines and Bezier surfaces. When False a surface will be replaced by a Trimmed Surface, else new geometry will be created by splitting the original Bspline or Bezier surface.
+
+### ElementaryToRevolution
+
+This operator converts elementary periodic surfaces to SurfaceOfRevolution.
+
+### SplitAngle
+
+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.
-**SurfaceToBSpline** converts some specific types of Surfaces, to BSpline (according to parameters).
-This operator can be called with the following parameters:
+### SurfaceToBSpline
+This operator converts some specific types of Surfaces, to BSpline (according to parameters).
+It can be called with the following parameters:
* *Boolean : LinearExtrusionMode* allows converting surfaces of Linear Extrusion;
* *Boolean : RevolutionMode* allows converting surfaces of Revolution;
* *Boolean : OffsetMode* allows converting Offset Surfaces
-**ToBezier** is used for data supported as Bezier only and converts various types of geometries to Bezier
-This operator can be called with the following parameters used in computation of conversion :
+### ToBezier
+
+This operator is used for data supported as Bezier only and converts various types of geometries to Bezier. It can be called with the following parameters used in computation of conversion :
* *Boolean : SurfaceMode*
* *Boolean : Curve3dMode*
* *Boolean : Curve2dMode*
* *Real : MaxTolerance*
-*Boolean : SegmentSurfaceMode* (default is True) has effect only for Bsplines and Bezier surfaces. When False a surface will be replaced by a Trimmed Surface, else new geometry will be created by splitting the original Bspline or Bezier surface.
+* *Boolean : SegmentSurfaceMode* (default is True) has effect only for Bsplines and Bezier surfaces. When False a surface will be replaced by a Trimmed Surface, else new geometry will be created by splitting the original Bspline or Bezier surface.
The following parameters are controlled by *SurfaceMode, Curve3dMode* or *Curve2dMode* (according to the case):
* *Boolean : Line3dMode*
* *Boolean : ExtrusionMode*
* *Boolean : BSplineMode*
-**SplitContinuity** splits a shape in order to have each geometry (surface, curve 3d, curve 2d) correspond the given criterion of continuity.
-This operator can be called with the following parameters:
+### SplitContinuity
+This operator splits a shape in order to have each geometry (surface, curve 3d, curve 2d) correspond the given criterion of continuity. It can be called with the following parameters:
* *Real : Tolerance3d*
* *Integer (GeomAbs_Shape ) : CurveContinuity*
* *Integer (GeomAbs_Shape ) : SurfaceContinuity*
* *Real : MaxTolerance*
-
Because of algorithmic limitations in the operator *BSplineRestriction* (in some particular cases, this operator can produce unexpected C0 geometry), if *SplitContinuity* is called, it is recommended to call it after *BSplineRestriction*.
Continuity Values will be set as *GeomAbs_Shape* (i.e. C0 G1 C1 G2 C2 CN) besides direct integer values (resp. 0 1 2 3 4 5).
-**SplitClosedFaces** splits faces, which are closed even if they are not revolutionary or cylindrical, conical, spherical, toroidal. This corresponds to BSpline or Bezier surfaces which can be closed (whether periodic or not), hence they have a seam edge. As a result, no more seam edges remain. The number of points allows to control the minimum count of faces to be produced per input closed face.
+### SplitClosedFaces
+This operator splits faces, which are closed even if they are not revolutionary or cylindrical, conical, spherical, toroidal. This corresponds to BSpline or Bezier surfaces which can be closed (whether periodic or not), hence they have a seam edge. As a result, no more seam edges remain. The number of points allows to control the minimum count of faces to be produced per input closed face.
+
This operator can be called with the following parameters:
* *Integer : NbSplitPoints* gives the number of points to use for splitting (the number of intervals produced is *NbSplitPoints+1*);
* *Real : CloseTolerance* tolerance used to determine if a face is closed;
* *Real : MaxTolerance* is used in the computation of splitting.
-**FixGaps** must be called when **FixFaceSize** and/or **DropSmallEdges** are called. Using Surface Healing may require an additional call to **BSplineRestriction** to ensure that modified geometries meet the requirements for BSpline.
+### FixGaps
+
+This operator must be called when *FixFaceSize* and/or *DropSmallEdges* are called. Using Surface Healing may require an additional call to *BSplineRestriction* to ensure that modified geometries meet the requirements for BSpline.
This operators repairs geometries which contain gaps between edges in wires (always performed) or gaps on faces, controlled by parameter *SurfaceMode*, Gaps on Faces are fixed by using algorithms of Surface Healing
This operator can be called with the following parameters:
* *Real : Tolerance3d* sets the tolerance to reach in 3d. If a gap is less than this value, it is not fixed.
This operator may change the original geometry. In addition, it is CPU consuming, and it may fail in some cases. Also **FixGaps** can help only when there are gaps obtained as a result of removal of small edges that can be removed by **DropSmallEdges** or **FixFaceSize**.
-**FixFaceSize** removes faces, which are small in all directions (spot face) or small in one direction (strip face)
-This operator can be called with the parameter *Real : Tolerance*, which sets the minimal dimension, which is used to consider a face, is small enough to be removed.
+### FixFaceSize
+This operator removes faces, which are small in all directions (spot face) or small in one direction (strip face). It can be called with the parameter *Real : Tolerance*, which sets the minimal dimension, which is used to consider a face, is small enough to be removed.
+
+### DropSmallEdges
+This operator drops edges in a wire, and merges them with adjacent edges, when they are smaller than the given value (*Tolerance3d*) and when the topology allows such merging (i.e. same adjacent faces for each of the merged edges). Free (non-shared by adjacent faces) small edges can be also removed in case if they share the same vertex Parameters.
+
+It can be called with the parameter *Real : Tolerance3d*, which sets the dimension used to determine if an edge is small.
-**DropSmallEdges** drops edges in a wire, and merges them with adjacent edges, when they are smaller than the given value (*Tolerance3d*) and when the topology allows such merging (i.e. same adjacent faces for each of the merged edges). Free (non-shared by adjacent faces) small edges can be also removed in case if they share the same vertex Parameters.
-This operator can be called with the parameter *Real : Tolerance3d*, which sets the dimension used to determine if an edge is small.
+### FixShape
+
+This operator may be added for fixing invalid shapes. It performs various checks and fixes, according to the modes listed hereafter. Management of a set of fixes can be performed by flags as follows:
+* if the flag for a fixing tool is set to 0 , it is not performed;
+* if set to 1 , it is performed in any case;
+* if not set, or set to -1 , for each shape to be applied on, a check is done to evaluate whether a fix is needed. The fix is performed if the check is positive.
+
+By default, the flags are not set, the checks are carried out each individual shape.
-**FixShape** may be added for fixing invalid shapes. It performs various checks and fixes, according to the modes listed hereafter. Management of a set of fixes can be performed by flags as follows:
-if the flag for a fixing tool is set to 0 , it is not performed if set to 1 , it is performed in any case if not set, or set to -1 , for each shape to be applied on, a check is done to evaluate whether a fix is needed. The fix is performed if the check is positive
-By default, they are not set, i.e. evaluated for each individual shape.
This operator can be called with the following parameters:
* *Real : Tolerance3d* sets basic tolerance used for fixing;
* *Real : MaxTolerance3d* sets maximum allowed value for the resulting tolerance;
* *Boolean : FixIntersectingEdgesMode*
* *Boolean : FixNonAdjacentIntersectingEdgesMode*
-**SplitClosedEdges** handles closed edges i.e. edges with one vertex. Such edges are not supported in some receiving systems. This operator splits topologically closed edges (i.e. edges having one vertex) into two edges. Degenerated edges and edges with a size of less than Tolerance are not processed.
+### SplitClosedEdges
+This operator handles closed edges i.e. edges with one vertex. Such edges are not supported in some receiving systems. This operator splits topologically closed edges (i.e. edges having one vertex) into two edges. Degenerated edges and edges with a size of less than Tolerance are not processed.
@section occt_shg_7_ Messaging mechanism
Various messages about modification, warnings and fails can be generated in the process of shape fixing or upgrade. The messaging mechanism allows generating messages, which will be sent to the chosen target medium a file or the screen. The messages may report failures and/or warnings or provide information on events such as analysis, fixing or upgrade of shapes.
-@subsection occt_shg_7_2 Message Gravity
+@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.
-@subsection occt_shg_7_3 Tool for loading a message file into memory
+@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.
-Format of the message file
---------------------------
+### Format of the message file
+
The message file is an ASCII file, which defines a set of messages. Each line of the file must have a length of less than 255 characters.
All lines in the file starting with the exclamation sign (perhaps preceded by spaces and/or tabs) are considered as comments and are ignored.
A message file may contain several messages. Each message is identified by its key (string).
!End of message file
~~~~~
-Loading the message file
-------------------------
+### Loading the message file
+
A custom file can be loaded into memory using the method *Message_MsgFile::LoadFile*, taking as an argument the path to your file as in the example below:
~~~~~
Standard_CString MsgFilePath = ;(path)/sample.file;;
Message_MsgFile::LoadFile (MsgFilePath);
~~~~~
-@subsection occt_shg_7_4 Tool for managing filling messages
+@subsection occt_shg_7_3 Tool for managing filling messages
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).
~~~~~
-@subsection occt_shg_7_5 Tool for managing trace files
+@subsection occt_shg_7_4 Tool for managing trace files
Class *Message_TraceFile* is intended to manage the trace file (or stream) for outputting messages and the current trace level. Trace level is an integer number, which is used when messages are sent. Generally, 0 means minimum, 0 various levels. If the current trace level is lower than the level of the message it is not output to the trace file. The trace level is to be managed and used by the users.
There are two ways of using trace files:
The default trace level can be changed by using method *SetDefLevel*. In this way, the information received in the log file is modified.
It is possible to close the log file and set the default trace output to the screen display instead of the log file using the method *SetDefault* without any arguments.
-
-@section occt_211336372_61271129 Appendix B
-@subsection occt_211336372_612711291 Examples of use
-@subsubsection occt_211336372_6127112911 ShapeAnalysis_Edge and ShapeFix_Edge
- <table>
- <tr>
- <td>
-
- </td>
- </tr>
- <tr>
- <td>
-
- </td>
- <td>
- 
- </td>
- </tr>
-</table> In this example an edge is shown where the maximum deviation between the 3D curve and 2D curve P1 is greater than the edge tolerance.
-
-<h5>Example</h5>
-ShapeAnalysis_Edge sae;
-TopoDS_Face face = ...;
-TopoDS_Wire wire = ...;
-Standard_Real precision = 1e-04;
-ShapeFix_Edge sfe;
-Standard_Real maxdev;
-if (sae.CheckSameParameter (edge, maxdev)) {
- cout*Incorrect SameParameter flag*endl;
- cout*Maximum deviation *maxdev *, tolerance *
-BRep_Tool::Tolerance(edge)endl;
- // Maximum deviation between pcurve and
- // 3D curve is greater than tolerance
- sfe.FixSameParameter();
- cout*New tolerance *BRep_Tool::Tolerance(edge)endl;
- // Tolerance is increased to englobe the deviation
-}
-
- <table>
- <tr>
- <td>
-
- </td>
- </tr>
- <tr>
- <td>
-
- </td>
- <td>
- 
- </td>
- </tr>
-</table> The result is an increased edge tolerance:
-
-@subsubsection occt_211336372_6127112912 ShapeAnalysis_Wire and ShapeFix_Wire
-This wire is first analyzed to check that:
- * the edges are correctly oriented
- * there are no edges that are too short and
- * that there are no intersecting adjacent edges.
-
-
- <table>
- <tr>
- <td>
-
- </td>
- </tr>
- <tr>
- <td>
-
- </td>
- <td>
- 
- </td>
- </tr>
-</table>
-<h5>Example</h5>
-
-ShapeAnalysis_Edge sae;
-TopoDS_Face face = ...;
-TopoDS_Wire wire = ...;
-Standard_Real precision = 1e-04;
-ShapeFix_Edge sfe;
-Standard_Real maxdev;
-if (sae.CheckSameParameter (edge, maxdev)) {
- cout<<“Incorrect SameParameter flag”<<endl;
- cout<<“Maximum deviation “<<maxdev<< “, tolerance “
-<<BRep_Tool::Tolerance(edge)<<endl;
- // Maximum deviation between pcurve and
- // 3D curve is greater than tolerance
- sfe.FixSameParameter();
- cout<<“New tolerance “<<BRep_Tool::Tolerance(edge)<<endl;
- // Tolerance is increased to englobe the deviation
-}
-
-
-
-ShapeAnalysis_Wire saw (wire, face, precision);
-ShapeFix_Wire sfw (wire, face, precision);
-if (saw.CheckOrder()) {
- cout*Some edges in the wire need to be reordered*endl;
- // Two edges are incorrectly oriented
- sfw.FixReorder();
- cout*Reordering is done*endl;
-}
-// their orientation is corrected
-if (saw.CheckSmall (precision)) {
- cout*Wire contains edge(s) shorter than *precisionendl;
- // An edge that is shorter than the given
- // tolerance is found
- Standard_Boolean LockVertex = Standard_True;
- if (sfw.FixSmall (LockVertex, precision)) {
- cout*Edges shorter than *precision* have been removed*
-endl;
- //The edge is removed
- }
-}
-if (saw.CheckSelfIntersection()) {
- cout*Wire has self-intersecting or intersecting
-adjacent edges*endl;
- // Two intersecting adjacent edges are found
- if (sfw.FixSelfIntersection()) {
- cout*Wire was slightly self-intersecting. Repaired*endl;
- // The edges are cut at the intersection point so
- // that they no longer intersect
- }
-}
-Here is the result:
-
-@subsubsection occt_211336372_6127112913 MoniTool_Timer
-Using timers in XSDRAWIGES.cxx and IGESBRep_Reader.cxx for analysis performance command ;igesbrep;:
-
-XSDRAWIGES.cxx
- ...
- #include MoniTool_Timer.hxx
- #include MoniTool_TimerSentry.hxx
- ...
- MoniTool_Timer::ClearTimers();
- ...
- MoniTool_TimerSentry MTS(;IGES_LoadFile;);
- Standard_Integer status = Reader.LoadFile(fnom.ToCString());
- MTS.Stop();
- ...
- MoniTool_Timer::DumpTimers(cout);
- return;
-
-
-IGESBRep_Reader.cxx
- ...
- #include MoniTool_TimerSentry.hxx
- ...
- Standard_Integer nb = theModel-NbEntities();
- ...
- for (Standard_Integer i=1; i=nb; i++) {
- MoniTool_TimerSentry MTS(;IGESToBRep_Transfer;);
- ...
- try {
- TP.Transfer(ent);
- shape = TransferBRep::ShapeResult (theProc,ent);
- }
- ...
- }
-
-**Result**
-DumpTimer() after translation file:
\ No newline at end of file
STEP processor {#user_guides__step}
========================
-@section occt_1624647986_1317425384 Overview
+@section occt_step_1 Overview
This manual is intended to provide technical documentation on the Open CASCADE Technology (**OCCT**) STEP processor and to help Open CASCADE Technology users with the use of the STEP processor (to read and write STEP files). STEP files conforming to AP 214, AP 203 and partially AP 209 can be read. STEP files that are produced by this interface conform to STEP AP 214 or AP 203, according to the user option.
-Only geometrical, topological STEP entities (shapes) and assembly structures are translated by the basic translator described in sections 2 to 6. Data that cannot be translated on this level are also loaded from a STEP file and can be translated later. XDE STEP translator (see section 7 *<a href="#_Reading_from_and_writing to XDE">Reading from and writing to XDE</a>*) translates names, colors, layers, validation properties and other data associated with shapes and assemblies into XDE document.
+
+Only geometrical, topological STEP entities (shapes) and assembly structures are translated by the basic translator described in sections 2 to 6. Data that cannot be translated on this level are also loaded from a STEP file and can be translated later. XDE STEP translator (see section 7 <a href="#occt_step_7">Reading from and writing to XDE</a>) translates names, colors, layers, validation properties and other data associated with shapes and assemblies into XDE document.
+
File translation is performed in the programming mode, via C++ calls.
-For testing the STEP component in DRAW Test Harness, a set of commands for reading and writing STEP files and analysis of relevant data are provided by the TKXSDRAW plugin.
-@section occt_1624647986_24898012 Reading STEP
-@subsection occt_1624647986_248980121 Procedure
+For testing the STEP component in DRAW Test Harness, a set of commands for reading and writing STEP files and analysis of relevant data are provided by the *TKXSDRAW* plugin.
+
+@section occt_step_2 Reading STEP
+@subsection occt_step_2_1 Procedure
You can translate a STEP file into an OCCT shape in the following steps:
1. load the file,
2. check file consistency,
3. set the translation parameters,
4. perform the translation,
5. fetch the results.
-@subsection occt_1624647986_248980122 Domain covered
-@subsubsection occt_1624647986_2489801221 Assemblies
-The ;ProSTEP Round Table Agreement Log; (version July 1998), item 21, defines two alternatives for the implementation of assembly structure representations: using mapped_item entities and using representation_relationship_with_transformation entities. Both these alternative representations are recognized and processed at reading. On writing, the second alternative is always employed.
+@subsection occt_step_2_2 Domain covered
+@subsubsection occt_step_2_2_1 Assemblies
+The **ProSTEP Round Table Agreement Log** (version July 1998), item 21, defines two alternatives for the implementation of assembly structure representations: using mapped_item entities and using representation_relationship_with_transformation entities. Both these alternative representations are recognized and processed at reading. On writing, the second alternative is always employed.
+
Handling of assemblies is implemented in two separate levels: firstly STEP assembly structures are translated into OCCT shapes, and secondly the OCCT shape representing the assembly is converted into any data structure intended for representing assemblies (for example, OCAF).
+
The first part of this document describes the basic STEP translator implementing translation of the first level, i.e. translation to OCCT Shapes. On this level, the acyclic graph representing the assembly structure in a STEP file is mapped into the structure of nested TopoDS_Compounds in Open CASCADE Technology. The (sub)assemblies become (sub)compounds containing shapes which are the results of translating components of that (sub)assembly. The sharing of components of assemblies is preserved as Open CASCADE Technology sharing of subshapes in compounds.
+
The attributive information attached to assembly components in a STEP file (such as names and descriptions of products, colors, layers etc.) can be translatd after the translation of the shape itself by parsing the STEP model (loaded in memory). Several tools from the package STEPConstruct provide functionalities to read styles (colors), validation properties, product information etc.
-Implementation of the second level of translation (conversion to XDE data structure) is provided by XDE STEP translator and is described in section 7.
-@subsubsection occt_1624647986_2489801222 Shape representations
+Implementation of the second level of translation (conversion to XDE data structure) is provided by XDE STEP translator.
+
+@subsubsection occt_step_2_2_2 Shape representations
Length units, plane angle units and the uncertainty value are taken from shape_representation entities. This data is used in the translation process.
+
The types of STEP representation entities that are recognized are:
* advanced_brep_shape_representation
* faceted_brep_shape_representation
* geometrically_bounded_wireframe_shape_representation
* geometrically_bounded_surface_shape_representation
* hybrid representations (shape_representation containing models of different type)
-@subsubsection occt_1624647986_2489801223 Topological entities
+
+@subsubsection occt_step_2_2_3 Topological entities
The types of STEP topological entities that can be translated are:
* vertices
* edges
* faces
* shells
* solids
-For further information see 2.4 Mapping STEP entities to Open CASCADE Technology shapes.
-@subsubsection occt_1624647986_2489801224 Geometrical entities
+For further information see <a href="#occt_step_2_4">Mapping STEP entities to Open CASCADE Technology shapes</a>.
+
+@subsubsection occt_step_2_2_4 Geometrical entities
The types of STEP geometrical entities that can be translated are:
* points
* vectors
* directions
* curves
* surfaces
+
For further information see 2.4 Mapping STEP entities to Open CASCADE Technology shapes.
-@subsection occt_1624647986_248980123 Description of the process
-@subsubsection occt_1624647986_2489801231 Loading the STEP file
+
+@subsection occt_step_2_3 Description of the process
+@subsubsection occt_step_2_3_1 Loading the STEP file
+
Before performing any other operation you have to load the file with:
+~~~~~
STEPControl_Reader reader;
IFSelect_ReturnStatus stat = reader.ReadFile(;filename.stp;);
+~~~~~
Loading the file only memorizes the data, it does not translate it.
-@subsubsection occt_1624647986_2489801232 Checking the STEP file
+
+@subsubsection occt_step_2_3_2 Checking the STEP file
This step is not obligatory. Check the loaded file with:
+~~~~~
reader.PrintCheckLoad(failsonly,mode);
+~~~~~
Error messages are displayed if there are invalid or incomplete STEP entities, giving you the information on the cause of error.
-Only fail messages are displayed if failsonly is true. All messages are displayed if failsonly is false. Your analysis of the file can be either message-oriented or entity-oriented. Choose your preference with:
+
+If *failsonly* is true only fail messages are displayed. All messages are displayed if *failsonly* is false. Your analysis of the file can be either message-oriented or entity-oriented. Choose your preference with:
+~~~~~
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
-@subsubsection occt_1624647986_2489801233 Setting the translation parameters
+* *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.
+
If you give a value that is not within the range of possible values it will simply be ignored.
+
<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:
-Standard_Integer ic = Interface_Static::IVal(;read.precision.mode;);
+
+~~~~~
+Standard_Integer ic = Interface_Static::IVal("read.precision.mode");
+~~~~~
Modify this parameter with:
-if(!Interface_Static::SetIVal(;read.precision.mode;,1))
+~~~~~
+if(!Interface_Static::SetIVal("read.precision.mode",1))
.. error ..
-Default value is ;File; (0).
+~~~~~
+Default value is File (0).
+
<h4>read.precision.val:</h4>
-User defined precision value. This parameter gives the precision for shape construction when the read.precision.mode parameter value is 1.
- 0.0001: default
- any real positive (non null) value.
+User defined precision value. This parameter gives the precision for shape construction when the read.precision.mode parameter value is 1. By default it is 0.0001, but can be any real positive (non null) value.
+
This value is a basic value of tolerance in the processor. The value is in millimeters, independently of the length unit defined in the STEP file.
+
Read this parameter with:
-Standard_Real rp = Interface_Static::RVal(;read.precision.val;);
+~~~~~
+Standard_Real rp = Interface_Static::RVal("read.precision.val");
+~~~~~
Modify this parameter with:
-if(!Interface_Static::SetRVal(;read.precision.val;,0.01))
+~~~~~
+if(!Interface_Static::SetRVal("read.precision.val",0.01))
.. error ..
-Default value is 0.0001.
+~~~~~
+By default this value is 0.0001.
+
The value given to this parameter is a basic value for ShapeHealing algorithms and the processor. It does its best to reach it. Under certain circumstances, the value you give may not be attached to all of the entities concerned at the end of processing. STEP-to-OpenCASCADE translation does not improve the quality of the geometry in the original STEP file. This means that the value you enter may be impossible to attach to all shapes with the given quality of the geometry in the STEP file.
+
<h4>read.maxprecision.val</h4>
-Defines the maximum allowed tolerance (in mm) of the shape. It should be not less than the basic value of tolerance set in the processor (either the uncertainty from the file or read.precision.val). Actually, the maximum between read.maxprecision.val and the basis tolerance is used to define the maximum allowed tolerance.
+Defines the maximum allowed tolerance (in mm) of the shape. It should be not less than the basic value of tolerance set in the processor (either the uncertainty from the file or *read.precision.val*). Actually, the maximum between *read.maxprecision.val* and the basis tolerance is used to define the maximum allowed tolerance.
+
Read this parameter with:
-Standard_Real rp = Interface_Static::RVal(;read.maxprecision.val;);
+~~~~~
+Standard_Real rp = Interface_Static::RVal("read.maxprecision.val");
+~~~~~
Modify this parameter with:
-if(!Interface_Static::SetRVal(;read.maxprecision.val;,0.1))
+~~~~~
+if(!Interface_Static::SetRVal("read.maxprecision.val",0.1))
.. error ..
+~~~~~
+
Default value is 1.
Note that maximum tolerance even explicitly defined by the user may be insufficient to ensure the validity of the shape (if real geometry is of bad quality). Therefore the user is provided with an additional parameter, which allows him to choose: either he prefers to ensure the shape validity or he rigidly sets the value of maximum tolerance. In the first case there is a possibility that the tolerance will not have any upper limit, in the second case the shape may be invalid.
+
<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:
-Standard_Integer ic = Interface_Static::IVal(;read.maxprecision.mode;);
+~~~~~
+Standard_Integer ic = Interface_Static::IVal("read.maxprecision.mode");
+~~~~~
Modify this parameter with:
-if(!Interface_Static::SetIVal(;read.maxprecision.mode;,1))
+~~~~~
+if(!Interface_Static::SetIVal("read.maxprecision.mode",1))
.. error ..
-Default value is 0 (;Preferred;).
+~~~~~
+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.
-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.
+defines the use of *BRepLib::SameParameter*. Its possible values are:
+
+* 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:
-Standard_Integer mv = Interface_Static::IVal(;read.stdsameparameter.mode;);
+~~~~~
+Standard_Integer mv = Interface_Static::IVal("read.stdsameparameter.mode");
+~~~~~
Modify this parameter with:
-if (!Interface_Static::SetIVal (;read.stdsameparameter.mode;,1))
+~~~~~
+if (!Interface_Static::SetIVal ("read.stdsameparameter.mode",1))
.. error ..;
-Deafault value is 0 (;Off;).
+~~~~~
+Default value is 0 (;Off;).
+
<h4>read.surfacecurve.mode:</h4>
a preference for the computation of curves in an entity which has both 2D and 3D representation.
-Each TopoDS_Edge in TopoDS_Face must have a 3D and 2D curve that references the surface.
+Each *TopoDS_Edge* in *TopoDS_Face* must have a 3D and 2D curve that references the surface.
+
If both 2D and 3D representation of the entity are present, the computation of these curves depends on the following values of parameter:
-;Default; (0): no preference, both curves are taken (default value),
-;3DUse_Preferred; (3): 3D curves are used to rebuild 2D ones.
+* *Default (0)* : no preference, both curves are taken (default value),
+* *3DUse_Preferred (3)* : 3D curves are used to rebuild 2D ones.
+
Read this parameter with:
-Standard_Integer rp = Interface_Static::IVal(;read.surfacecurve.mode;);
+~~~~~
+Standard_Integer rp = Interface_Static::IVal("read.surfacecurve.mode");
+~~~~~
Modify this parameter with:
-if(!Interface_Static::SetIVal(;read.surfacecurve.mode;,3))
+~~~~~
+if(!Interface_Static::SetIVal("read.surfacecurve.mode",3))
.. error ..
+~~~~~
Default value is (0).
+
<h4>read.encoderegularity.angle</h4>
-This parameter is used for call to BRepLib::EncodeRegularity() function which is called for the shape read from an IGES or a STEP file at the end of translation process. This function sets the regularity flag of the edge in the shell when this edge is shared by two faces. This flag shows the continuity these two faces are connected with at that edge.
+
+This parameter is used for call to *BRepLib::EncodeRegularity()* function which is called for the shape read from an IGES or a STEP file at the end of translation process. This function sets the regularity flag of the edge in the shell when this edge is shared by two faces. This flag shows the continuity these two faces are connected with at that edge.
Read this parameter with:
-Standard_Real era = Interface_Static::RVal(;read.encoderegularity.angle;);
+~~~~~
+Standard_Real era = Interface_Static::RVal("read.encoderegularity.angle");
+~~~~~
Modify this parameter with:
-if (!Interface_Static::SetRVal (;read.encoderegularity.angle;,0.1))
+~~~~~
+if (!Interface_Static::SetRVal ("read.encoderegularity.angle",0.1))
.. error ..;
+~~~~~
Default value is 0.01.
+
<h4>step.angleunit.mode</h4>
This parameter is obsolete (it was required in the past for STEP files with a badly encoded angle unit). It indicates what angle units should be used when a STEP file is read: the units from file (default), or forced RADIANS or DEGREES.
+
Default value is File
-<h4>read.step.resource.name</h4>
-<h4>read.step.sequence</h4>
+
+<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.
-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 %CASROOT%/src/XSTEPResource/STEP ($CASROOT/src/XSTEPResource/STEP).
-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.
+
+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.
+
<h4>read.scale.unit</h4>
-This parameter is obsolete (the parameter xstep.cascade.unit should be used instead when necessary). If it is set to 'M', the shape is scaled 0.001 times (as if it were in meters) after translation from IGES or STEP.
+This parameter is obsolete (the parameter *xstep.cascade.unit* should be used instead when necessary). If it is set to 'M', the shape is scaled 0.001 times (as if it were in meters) after translation from IGES or STEP.
Default value is MM.
+
<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.
+
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:
-Standard_Integer ic = Interface_Static::IVal(;read.step.product.mode;);
+~~~~~
+Standard_Integer ic = Interface_Static::IVal("read.step.product.mode");
+~~~~~
+
Modify this parameter with:
-if(!Interface_Static::SetIVal(;read.step.product.mode;,1))
+~~~~~
+if(!Interface_Static::SetIVal("read.step.product.mode",1))
.. error ..
-Default value is 1 (;ON;).
-Note that the following parameters have effect only if read.step.product.mode is ON.
+~~~~~
+Default value is 1 (ON).
+
+Note that the following parameters have effect only if *read.step.product.mode* is ON.
+
<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;) - translate all products
-2 (;design;) - translate only products that have PRODUCT_DEFINITION_CONTEXT with field life_cycle_stage set to ‘design’
-3 (*analysis*) - translate 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.
+
Read this parameter with:
-Standard_Integer ic = Interface_Static::IVal(;read.step.product.context;);
+~~~~~
+Standard_Integer ic = Interface_Static::IVal("read.step.product.context");
+~~~~~
+
Modify this parameter with:
+~~~~~
if(!Interface_Static::SetIVal(;read.step.product.context;,1))
.. error ..
-Default value is 1 (;all;).
+~~~~~
+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).
-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
+* 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
+
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.
+
Read this parameter with:
-Standard_Integer ic = Interface_Static::IVal(;read.step.shape.repr;);
+~~~~~
+Standard_Integer ic = Interface_Static::IVal("read.step.shape.repr");
+~~~~~
Modify this parameter with:
-if(!Interface_Static::SetIVal(;read.step.shape.repr;,1))
+~~~~~
+if(!Interface_Static::SetIVal("read.step.shape.repr",1))
.. error ..
-Default value is 1 (;All;).
+~~~~~
+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:
-Standard_Integer ic = Interface_Static::IVal(;read.step.assembly.level;);
+~~~~~
+Standard_Integer ic = Interface_Static::IVal("read.step.assembly.level");
+~~~~~
Modify this parameter with:
-if(!Interface_Static::SetIVal(;read.step.assembly.level ;,1))
+~~~~~
+if(!Interface_Static::SetIVal("read.step.assembly.level",1))
.. error ..
-Default value is 1 (;All;).
+~~~~~
+
+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
+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
+
Read this parameter with:
-Standard_Integer ic = Interface_Static::IVal(;read.step.shape.relationship;);
+~~~~~
+Standard_Integer ic = Interface_Static::IVal("read.step.shape.relationship");
+~~~~~
Modify this parameter with:
+~~~~~
if(!Interface_Static::SetIVal(;read.step.shape.relationship;,1))
.. error ..
-Default value is 1 (;ON;).
+~~~~~
+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
+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
+
Read this parameter with:
-Standard_Integer ic = Interface_Static::IVal(;read.step.shape.aspect;);
+~~~~~
+Standard_Integer ic = Interface_Static::IVal("read.step.shape.aspect");
+~~~~~
+
Modify this parameter with:
+~~~~~
if(!Interface_Static::SetIVal(;read.step.shape.aspect;,1))
.. error ..
-Default value is 1 (;ON;).
-@subsubsection occt_1624647986_2489801234 Performing the STEP file translation
+~~~~~
+Default value is 1 (ON).
+
+@subsubsection occt_step_2_3_4 Performing the STEP file translation
+
Perform the translation according to what you want to translate. You can choose either root entities (all or selected by the number of root), or select any entity by its number in the STEP file. There is a limited set of types of entities that can be used as starting entities for translation. Only the following entities are recognized as transferable:
* product_definition
* next_assembly_usage_occurrence
* subtypes of face_surface (including advanced_face)
* subtypes of shape_representation_relationship
* context_dependent_shape_representation
-<h5>The following methods are used for translation:</h5>
- * Translate a root entity identified by its rank with:
-Standard_Boolean ok = reader.TransferRoot(rank);
- * Translate an entity identified by its rank with:
-Standard_Boolean ok = reader.TransferOne(rank);
- * Translate a list of entities in one operation with (this method returns the number of successful translations):
-Standard_Integer num = reader.TransferList(list);
- * Translate all transferable roots with:
-Standard_Integer NbRoots = reader.NbRootsForTransfer();
-Standard_Integer num = reader.TransferRoots();
-@subsubsection occt_1624647986_2489801235 Getting the translation results
+
+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.
+
+@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.
-Each time you invoke TransferOne(), TransferRoot() or TransferList(), their results are accumulated and the counter of results increases. You can clear the results with:
+
+Each time you invoke *TransferOne(), TransferRoot()* or *TransferList()*, their results are accumulated and the counter of results increases. You can clear the results with:
+~~~~~
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.
- * Get the number of shapes recorded in the result with:
-Standard_Integer num = reader.NbShapes();
- * Get the result identified by its rank, where rank is an integer between 1 and NbShapes, with:
-TopoDS_Shape shape = reader.Shape(rank);
- * Get the first result of translation with:
-TopoDS_Shape shape = reader.Shape();
- * Get all of 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.
-TopoDS_Shape shape = reader.OneShape();
+
+*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:
+ * 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.
+
<h5>Clearing the accumulation of results</h5>
-If several individual translations follow each other, the results give a list that can be purged with:
-reader.ClearShapes();
-which erases the existing results.
+
+If several individual translations follow each other, the results give a list that can be purged with *reader.ClearShapes()*, which erases the existing results.
+
<h5>Checking that translation was correctly performed</h5>
-Each time you invoke Transfer… or TransferRoots(), you can display the related messages with the help of:
+Each time you invoke *Transfer* or *TransferRoots()*, you can display the related messages with the help of:
+~~~~~
reader.PrintCheckTransfer(failsonly,mode);
-This check concerns the last invocation of Transfer… or TransferRoots() only.
-@subsubsection occt_1624647986_2489801236 Selecting STEP entities for translation
+~~~~~
+
+This check concerns the last invocation of *Transfer* or *TransferRoots()* only.
+
+@subsubsection occt_step_2_3_6 Selecting STEP entities for translation
+
<h4>Selection possibilities</h4>
+
There are three selection possibilities. You can select:
* the whole file,
* a list of entities,
* one entity.
-<h4>Whole file</h4>
+
+<h5>Whole file</h5>
+
Transferring the whole file means transferring all root entities. The number of roots can be evaluated when the file is loaded:
+~~~~~
Standard_Integer NbRoots = reader.NbRootsForTransfer();
Standard_Integer num = reader.TransferRoots();
-<h4>Lists of entities</h4>
-A list of entities can be formed by invoking STEP214Control_Reader::GiveList (this is a method of the parent class).
+~~~~~
+
+<h4>List of entities</h4>
+A list of entities can be formed by invoking *STEP214Control_Reader::GiveList* (this is a method of the parent class).
+
Here is a simple example of how a list is translated:
+~~~~~
Handle(TColStd_HSequenceOfTransient) list = reader.GiveList();
-The result is a TColStd_HSequenceOfTransient.
+~~~~~
+The result is a *TColStd_HSequenceOfTransient*.
You can either translate a list entity by entity or all at once. An entity-by-entity operation lets you check each individual entity translated.
+
<h5>Translating a whole list in one operation</h5>
+~~~~~
Standard_Integer nbtrans = reader.TransferList (list);
-nbtrans gives the number of items in the list that produced a shape.
+~~~~~
+*nbtrans* gives the number of items in the list that produced a shape.
+
<h5>Translating a list entity by entity:</h5>
-Standard_Integer i,nb = list-Length();
-for (i = 1; i = nb; i ++) {
- Handle(Standard_Transient) ent = list-Value(i);
- Standard_Boolean OK = reader.TransferEntity (ent);
-}
+~~~~~
+Standard_Integer i,nb = list->Length();
+for (i = 1; i <= nb; i ++) {
+ Handle(Standard_Transient) ent = list->Value(i);
+ Standard_Boolean OK = reader.TransferEntity (ent);
+}
+~~~~~
+
<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.
-Cumulative lists can be used too.
-<h4>Single entities</h4>
-You can select an entity either by its rank or by its handle (an entity’s handle can be obtained by invoking the StepData_StepModel::Entity function).
+ * *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>
+You can select an entity either by its rank or by its handle (an entity’s handle can be obtained by invoking the *StepData_StepModel::Entity* function).
+
<h5>Selection by rank</h5>
-Use method StepData_StepModel::NextNumberForLabel to find its rank with the following:
+Use method *StepData_StepModel::NextNumberForLabel* to find its rank with the following:
+~~~~~
Standard_CString label = ‘#...’;
StepData_StepModel model = reader.StepModel();
-rank = model-NextNumberForLabe(label, 0, Standard_False);
+rank = model->NextNumberForLabe(label, 0, Standard_False);
+~~~~~
Translate an entity specified by its rank:
+~~~~~
Standard_Boolean ok = reader.Transfer (rank);
+~~~~~
+
<h5>Direct selection of an entity</h5>
-ent is the entity. The argument is a Handle(Standard_Transient).
+*ent* is the entity. The argument is a *Handle(Standard_Transient)*.
+~~~~~
Standard_Boolean ok = reader.TransferEntity (ent);
-@subsection occt_1624647986_248980124 Mapping STEP entities to Open CASCADE Technology shapes
+~~~~~
+
+@subsection occt_step_2_4 Mapping STEP entities to Open CASCADE Technology shapes
Tables given in this paragraph show the mapping of STEP entities to OCCT objects. Only topological and geometrical STEP entities and entities defining assembly structures are described in this paragraph. For a full list of STEP entities please refer to Appendix A.
-@subsubsection occt_1624647986_2489801241 Assembly structure representation entities
+
+@subsubsection occt_step_2_4_1 Assembly structure representation entities
Not all entities defining the assembly structure in the STEP file are translated to OCCT shapes, but they are used to identify the relationships between assemblies and their components. Since the graph of ‘natural’ dependencies of entities based on direct references between them does not include the references from assemblies to their components, these dependencies are introduced in addition to the former ones. This is made basing on the analysis of the following entities describing the structure of the assembly.
-@subsubsection occt_1624647986_2489801242 Models
+| STEP entity type | CASCADE shape | Comments |
+
+product_definition For assemblies, a TopoDS_Compound,
+for components, a CASCADE shape corresponding to the type of component Each assembly or component has its own product_definition. It is used as a starting point for translation when read.step.product.mode is ON
+product_definition_shape This entity provides a link between product_definition and corresponding shape_definition_representation, or between next_assembly_usage_occurence and corresponding context_dependent_shape_representation
+shape_definition_representation For assemblies, a TopoDS_Compound,
+for components, a CASCADE shape corresponding to the type of component Each assembly or component has its own shape_definition_representation. The graph of dependencies is modified in such a way that shape_definition_representations of all components of the assembly are referred by the shape_definition_representation of the assembly.
+next_assembly_usage_occurence This entity defines a relationship between the assembly and its component. It is used to introduce (in the dependencies graph) the links between shape_definition_representation of the assembly and shape_definition_representations and context_dependent_shape_representations of all its components.
+mapped_item TopoDS_Shape This entity defines a mapping of the assembly component into the shape_representation of the assembly. The result of translation is a CASCADE shape translated from the component, to which transformation defined by the mapped_item is applied.
+context_dependent_shape_representation TopoDS_Shape This entity is associated with the next_assembly_usage_occurence entity and defines a placement of the component in the assembly. The graph of dependencies is modified so that each context_dependent_shape_representation is referred by shape_definition_representation of the corresponding assembly.
+shape_representation_relationship_with_transformation This entity is associated with context_dependent_shape_representation and defines a transformation necessary to apply to the component in order to locate it in its place in the assembly.
+item_defined_transformation This entity defines a transformation operator used by shape_representation_relationship_with_transformation or mapped_item entity
+cartesian_transformation_operator This entity defines a transformation operator used by shape_representation_relationship_with_transformation or mapped_item entity
+
+@subsubsection occt_step_2_4_2 Models
+STEP entity type CASCADE shape Comments
+Solid Models
+brep_with_voids TopoDS_Solid
+faceted_brep TopoDS_Solid
+manifold_solid_brep TopoDS_Solid
+Surface Models
+shell_based_surface_model TopoDS_Compound shell_based_surface_model is translated into one or more TopoDS_Shell grouped in a TopoDS_Compound
+geometric_set TopoDS_Compound TopoDS_Compound contains only TopoDS_Faces, TopoDS_Wires, TopoDS_Edges and/or TopoDS_Vertices
+Wireframe Models
+geometric_curve_set TopoDS_Compound TopoDS_Compound contains only TopoDS_Wires, TopoDS_Edges and/or TopoDS_Vertices
-@subsubsection occt_1624647986_2489801243 Topological entities
+@subsubsection occt_step_2_4_3 Topological entities
+STEP entity type CASCADE shape Comments
+Vertices
+vertex_point TopoDS_Vertex
+Edges
+oriented_edge TopoDS_Edge
+edge_curve TopoDS_Edge
+Loops
+face_bound TopoDS_Wire
+face_outer_bound TopoDS_Wire
+edge_loop TopoDS_Wire
+poly_loop TopoDS_Wire Each segment of poly_loop is translated into TopoDS_Edge with support of Geom_Line
+vertex_loop TopoDS_Wire Resulting TopoDS_Wire contains only one degenerated TopoDS_Edge
+Faces
+face_surface TopoDS_Face
+advanced_face TopoDS_Face
+Shells
+connected_face_set TopoDS_Shell
+oriented_closed_shell TopoDS_Shell
+closed_shell TopoDS_Shell
+open_shell TopoDS_Shell
-@subsubsection occt_1624647986_2489801244 Geometrical entities
+@subsubsection occt_step_2_4_4 Geometrical entities
3D STEP entities are translated into geometrical objects from the Geom package while 2D entities are translated into objects from the Geom2d package.
+STEP entity type CASCADE object Comments
+Points
+cartesian_point Geom_CartesianPoint
+ Geom2d_CartesianPoint
+Directions
+direction Geom_Direction
+ Geom2d_Direction
+Vectors
+vector Geom_VectorWithMagnitude
+ Geom2d_VectorWithMagnitude
+Placements
+axis1_placement Geom_Axis1Placement
+axis2_placement_2d Geom2d_AxisPlacement
+axis2_placement_3d Geom_Axis2Placement
+Curves
+circle Geom_Circle
+ Geom2d_Circle
+ Geom2d_BsplineCurve Circle is translated into Geom2d_BSplineCurve when it references the surface of revolution (spherical surface, conical surface, etc.)
+ellipse Geom_Ellipse
+ Geom2d_Ellipse
+ Geom2d_BsplineCurve Ellipse is translated into Geom2d_BSplineCurve when it references the surface of revolution (spherical surface, conical surface, etc.)
+hyperbola Geom_Hyperbola
+ Geom2d_Hyperbola
+line Geom_Line
+ Geom2d_Line
+parabola Geom_Parabola
+ Geom2d_Parabola
+pcurve Geom2d_Curve Pcurve in edge
+curve_replica Geom_Curve Depending on the type of basis curve
+ Geom2d_Curve
+offset_curve_3d Geom_OffsetCurve
+trimmed_curve Geom_TrimmedCurve
+ Geom2d_BsplineCurve Only trimmed_curves trimmed by parameters are translated. All trimmed_curves are converted to Geom2d_BSplineCurve.
+b_spline_curve Geom_BsplineCurve
+ Geom2d_BsplineCurve
+b_spline_curve_with_
+knots Geom_BsplineCurve
+ Geom2d_BsplineCurve
+bezier_curve Geom_BsplineCurve
+ Geom2d_BsplineCurve
+rational_b_spline_curve Geom_BsplineCurve
+ Geom2d_BsplineCurve
+uniform_curve Geom_BsplineCurve
+ Geom2d_BsplineCurve
+quasi_ uniform_curve Geom_BsplineCurve
+ Geom2d_BsplineCurve
+surface_curve TopoDS_Edge surface_curve defines geometrical support of an edge and its pcurves.
+seam_curve TopoDS_Edge the same as surface_curve
+composite_curve_segment TopoDS_Edge as a segment of composite_curve
+composite_curve TopoDS_Wire
+composite_curve_on_surface TopoDS_Wire
+boundary_curve TopoDS_Wire
+Surfaces
+b_spline_surface Geom_BsplineSurface
+b_spline_surface_with_knots Geom_BsplineSurface
+bezier_surface Geom_BSplineSurface
+conical_surface Geom_ConicalSurface
+cylindrical_surface Geom_CylindricalSurface
+offset_surface Geom_OffsetSurface
+surface_replica Geom_Surface Depending on the type of basis surface
+plane Geom_Plane
+rational_b_spline_surface Geom_BSplineSurface
+rectangular_trimmed_
+surface Geom_RectangularTrimmedSurface
+spherical_surface Geom_SphericalSurface
+surface_of_linear_extrusion Geom_SurfaceOfLinearExtrusion
+surface_of_revolution Geom_SurfaceOfRevolution
+toroidal_surface Geom_ToroidalSurface
+degenerate_toroidal_surface Geom_ToroidalSurface
+uniform_surface Geom_BSplineSurface
+quasi_uniform_surface Geom_BSplineSurface
+rectangular_composite_surface TopoDS_Compound Contains TopoDS_Faces
+curve_bounded_surface TopoDS_Face
+
+
+@subsection occt_step_2_5 Tolerance management
+@subsubsection occt_step_2_5_1 Values used for tolerances during reading STEP
-@subsection occt_1624647986_248980125 Tolerance management
-@subsubsection occt_1624647986_2489801251 Values used for tolerances during reading STEP
During the STEP = OCCT translation several parameters are used as tolerances and precisions for different algorithms. Some of them are computed from other tolerances using specific functions.
+
<h4>3D (spatial) tolerance</h4>
-<h5>Package method Precision::Confusion()</h5>
-Value is 10-7. It is used as the minimal distance between points, which are considered to be distinct.
-<h5>Uncertainty in STEP file</h5>
-This 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.
-<h5>User - defined variable read.precision.val</h5>
-It is used instead of uncertainty from a STEP file when parameter read.precision.mode is 1 (*User*).
+* 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).
+
<h4>2D (parametric) tolerances</h4>
-<h5>Package method Precision::PConfusion()</h5>
-This is a value of 0.01* Precision::Confusion(). It is used to compare parametric bounds of curves.
-<h5>Methods UResolution, VResolution (tolerance3d) of the class GeomAdaptor_Surface or BRepAdaptor_Surface</h5>
-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.
-<h4>Methods Resolution (tolerance3d) of the class GeomAdaptor_Curve or BRepAdaptor_Curve</h4>
-Returns tolerance in parametric space of a curve computed from 3d tolerance.
-@subsubsection occt_1624647986_2489801252 Initial setting of tolerances in translating objects
-In the STEP processor, the basic value of tolerance is set in method STEPControl_ActorRead::Transfer() to either value of uncertainty in shape_representation in STEP file (if parameter read.precision.mode is 0), or to a value of parameter read.precision.val (if read.precision.mode is 1 or if the uncertainty is not attached to the current entity in the STEP file).
-Translation starts from one entity translated as a root. Function which performs the translation (STEPControl_ActorRead::Transfer() ) creates an object of the type StepToTopoDS_Builder, which is intended to translate topology.
-This object gets the initial tolerance value that is equal to read.precision.val or the uncertainty from shape_representation. During the translation of the entity, new objects of types StepToTopoDS_Translate... are created for translating sub-entities. All of them use the same tolerances as a StepToTopoDS_Builder object.
-@subsubsection occt_1624647986_2489801253 Transfer process
+* 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 *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
+In the STEP processor, the basic value of tolerance is set in method *STEPControl_ActorRead::Transfer()* to either value of uncertainty in shape_representation in STEP file (if parameter *read.precision.mode* is 0), or to a value of parameter *read.precision.val* (if *read.precision.mode* is 1 or if the uncertainty is not attached to the current entity in the STEP file).
+
+Translation starts from one entity translated as a root. *STEPControl_ActorRead::Transfer()*, function which performs the translation creates an object of the type *StepToTopoDS_Builder*, which is intended to translate topology.
+
+This object gets the initial tolerance value that is equal to *read.precision.val* or the uncertainty from shape_representation. During the translation of the entity, new objects of types *StepToTopoDS_Translate*... are created for translating sub-entities. All of them use the same tolerances as a *StepToTopoDS_Builder* object.
+
+@subsubsection occt_step_2_5_3 Transfer process
+
<h4>Evolution of shape tolerances during transfer</h4>
Let us follow the evolution of tolerances during the translation of STEP entities into an OCCT shape.
-If the starting STEP entity is a geometric_curve_set all the edges and vertices are constructed with Precision::Confusion().
+
+If the starting STEP entity is a geometric_curve_set all the edges and vertices are constructed with *Precision::Confusion()*.
+
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:
-1.ShapeFix::SameParameter() - the tolerance of edge shows real deviation of the 3D curve and pcurves.
-2.ShapeFix_Wire::FixSelfIntersection() in case if a pcurve of a self-intersecting edge is modified.
+ * 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_Wire::FixSelfIntersection()* if a pcurve of a self-intersecting edge is modified.
* vertices are constructed with Precision::Confusion(). It can be modified later by:
-1.StepToTopoDS_TranslateEdge
-2.ShapeFix::SameParameter()
-3.ShapeFix_Wire::FixSelfIntersection()
-4.ShapeFix_Wire::FixLacking()
-5.ShapeFix_Wire::Connected()
+ *StepToTopoDS_TranslateEdge*
+ *ShapeFix::SameParameter()*
+ *ShapeFix_Wire::FixSelfIntersection()*
+ *ShapeFix_Wire::FixLacking()*
+ *ShapeFix_Wire::Connected()*
+
So, the final tolerance of sub-shapes shows the real local geometry of shapes (distance between vertices of adjacent edges, deviation of a 3D curve of an edge and its parametric curves and so on) and may be less or greater than the basic value of tolerance in the STEP processor.
+
<h4>Translating into Geometry</h4>
-Geometrical entities are translated by classes StepToGeom_Make... Methods of these classes translate STEP geometrical entities into OCCT geometrical objects. Since these objects are not BRep objects, they do not have tolerances. Tolerance is used only as precision for detecting bad cases (such as points coincidence).
+
+Geometrical entities are translated by classes *StepToGeom_Make...* Methods of these classes translate STEP geometrical entities into OCCT geometrical objects. Since these objects are not BRep objects, they do not have tolerances. Tolerance is used only as precision for detecting bad cases (such as points coincidence).
+
<h4>Translating into Topology</h4>
-STEP topological entities are translated into OCCT shapes by use of the following classes (package StepToTopoDS):
- * StepToTopoDS_TranslateVertex
- * StepToTopoDS_TranslateEdge
- * StepToTopoDS_TranslateVertexLoop
- * StepToTopoDS_TranslateEdgeLoop
- * StepToTopoDS_TranslatePolyLoop
- * StepToTopoDS_TranslateFace
- * StepToTopoDS_TranslateShell
- * StepToTopoDS_TranslateCompositeCurve
- * StepToTopoDS_TranslateCurveBoundedSurface
- * StepToTopoDS_Builder
- * StepToTopoDS_MakeTransformed
+STEP topological entities are translated into OCCT shapes by use of classes from package *StepToTopoDS*.
+
Although in a STEP file the uncertainty value is assigned to shape_representation entities and this value is applied to all entities in this shape_representation, OCCT shapes are produced with different tolerances. As a rule, updating the tolerance is fulfilled according to the local geometry of shapes (distance between vertices of adjacent edges, deviation of edge's 3D curve and its parametric curves and so on) and may be either less or greater than the uncertainty value assigned to the entity.
-The following paragraphs show what default tolerances are used when creating shapes and how they are updated during translation.
-<h5>Class StepToTopoDS_TranslateVertex</h5>
-TopoDS_Vertex is constructed from a STEP vertex_point entity with Precision::Confusion().
-<h5>Class StepToTopoDS_TranslateVertexLoop</h5>
-Degenerated TopoDS_Edge in TopoDS_Wire is created with tolerance Precision::Confusion(). TopoDS_Vertex of a degenerated edge is constructed with the initial value of tolerance.
-<h5>Class StepToTopoDS_TranslateEdge</h5>
-TopoDS_Edge is constructed only on the basis of 3D curve with Precision::Confusion().. Tolerance of the vertices can be increased up to a distance between their positions and ends of 3D curve.
-<h5>Class StepToTopoDS_TranslateEdgeLoop</h5>
-TopoDS_Edges in TopoDS_Wire are constructed with the help of class StepToTopoDS_TranslateEdge. Pcurves from a STEP file are translated if they are present and read.surfacecurve.mode is 0. For each edge method ShapeFix_Edge::FixSameParameter() is called. If the resulting tolerance of the edge is greater than the maximum value between 1.0 and 2*Value of basis precision, then the pcurve is recomputed. The best of the original and the recomputed pcurve is put into TopoDS_Edge. The resulting tolerance of TopoDS_Edge is a maximal deviation of its 3D curve and its pcurve(s).
-<h5>Class StepToTopoDS_TranslatePolyLoop</h5>
-TopoDS_Edges in TopoDS_Wire are constructed with the help of class StepToTopoDS_TranslateEdge. Their tolerances are not modified inside this method.
-<h5>Class StepToTopoDS_TranslateFace</h5>
-TopoDS_Face is constructed with the initial value of tolerance.
-TopoDS_Wire on TopoDS_Face is constructed with the help of classes StepToTopoDS_TranslatePolyLoop, StepToTopoDS_TranslateEdgeLoop or StepToTopoDS_TranslateVertexLoop.
-<h5>Class StepToTopoDS_TranslateShell</h5>
-This class calls StepToTopoDS_TranslateFace::Init for each face. This class does not modify the tolerance value.
-<h5>Class StepToTopoDS_TranslateCompositeCurve</h5>
-TopoDS_Edges in TopoDS_Wire are constructed with the help of class BRepAPI_MakeEdge and have a tolerance 10-7. Pcurves from a STEP file are translated if they are present and if read.surfacecurve.mode is not -3. The connection between segments of a composite curve (edges in the wire) is ensured by call to method ShapeFix_Wire::FixConnected() with a precision equal to the initial value of tolerance.
-<h5>Class StepToTopoDS_TranslateCurveBoundedSurface</h5>
-TopoDS_Face is constructed with tolerance Precision::Confusion().
-TopoDS_Wire on TopoDS_Face is constructed with the help of class StepToTopoDS_TranslateCompositeCurve. Missing pcurves are computed using projection algorithm with the help of method ShapeFix_Face::FixPcurves(). For resulting face method ShapeFix::SameParameter() is called. It calls standard BRepLib::SameParameter for each edge in each wire, which can either increase or decrease the tolerances of the edges and vertices. SameParameter writes the tolerance corresponding to the real deviation of pcurves from 3D curve which can be less or greater than the tolerance in a STEP file.
-<h5>Class StepToTopoDS_Builder</h5>
-Class StepToTopoDS_Builder is a high level class. Its methods perform translation with the help of the classes listed above. If the value of read.maxprecision.mode is set to 1 then the tolerance of subshapes of the resulting shape is limited by 0 and read.maxprecision.val. Else this class does not change the tolerance value.
-<h5>Class StepToTopoDS_MakeTransformed</h5>
-This class performs a translation of mapped_item entity and indirectly uses class StepToTopoDS_Builder. The tolerance of the resulting shape is not modified inside this method.
+
+The following default tolerances are used when creating shapes and how they are updated during translation.
+* *StepToTopoDS_TranslateVertex* constructs *TopoDS_Vertex* from a STEP *vertex_point* entity with *Precision::Confusion()*.
+* *StepToTopoDS_TranslateVertexLoop* creates degenerated *TopoDS_Edge* in *TopoDS_Wire* with tolerance *Precision::Confusion()*. *TopoDS_Vertex* of a degenerated edge is constructed with the initial value of tolerance.
+* *StepToTopoDS_TranslateEdge* constructs *TopoDS_Edge* only on the basis of 3D curve with *Precision::Confusion()*. Tolerance of the vertices can be increased up to a distance between their positions and ends of 3D curve.
+* *StepToTopoDS_TranslateEdgeLoop* constructs *TopoDS_Edges* in *TopoDS_Wire* with help of class *StepToTopoDS_TranslateEdge*. Pcurves from a STEP file are translated if they are present and *read.surfacecurve.mode* is 0. For each edge method *ShapeFix_Edge::FixSameParameter()* is called. If the resulting tolerance of the edge is greater than the maximum value between 1.0 and 2*Value of basis precision, then the pcurve is recomputed. The best of the original and the recomputed pcurve is put into *TopoDS_Edge*. The resulting tolerance of *TopoDS_Edge* is a maximal deviation of its 3D curve and its pcurve(s).
+* *StepToTopoDS_TranslatePolyLoop* constructs *TopoDS_Edges* in *TopoDS_Wire* with help of class *StepToTopoDS_TranslateEdge*. Their tolerances are not modified inside this method.
+* *StepToTopoDS_TranslateFace* constructs *TopoDS_Face* with the initial value of tolerance. *TopoDS_Wire* on *TopoDS_Face* is constructed with the help of classes *StepToTopoDS_TranslatePolyLoop, StepToTopoDS_TranslateEdgeLoop* or *StepToTopoDS_TranslateVertexLoop*.
+* *StepToTopoDS_TranslateShell* calls *StepToTopoDS_TranslateFace::Init* for each face. This class does not modify the tolerance value.
+* *StepToTopoDS_TranslateCompositeCurve* constructs *TopoDS_Edges* in *TopoDS_Wire* with help of class *BRepAPI_MakeEdge* and have a tolerance 10-7. Pcurves from a STEP file are translated if they are present and if *read.surfacecurve.mode* is not -3. The connection between segments of a composite curve (edges in the wire) is provided by calling method *ShapeFix_Wire::FixConnected()\** with a precision equal to the initial value of tolerance.
+* *StepToTopoDS_TranslateCurveBoundedSurface* constructs *TopoDS_Face* with tolerance *Precision::Confusion()*. *TopoDS_Wire* on *TopoDS_Face* is constructed with the help of class *StepToTopoDS_TranslateCompositeCurve*. Missing pcurves are computed using projection algorithm with the help of method *ShapeFix_Face::FixPcurves()*. For resulting face method *ShapeFix::SameParameter()* is called. It calls standard *BRepLib::SameParameter* for each edge in each wire, which can either increase or decrease the tolerances of the edges and vertices. *SameParameter* writes the tolerance corresponding to the real deviation of pcurves from 3D curve which can be less or greater than the tolerance in a STEP file.
+* *StepToTopoDS_Builder* a high level class. Its methods perform translation with the help of the classes listed above. If the value of *read.maxprecision.mode* is set to 1 then the tolerance of subshapes of the resulting shape is limited by 0 and *read.maxprecision.val*. Else this class does not change the tolerance value.
+* *StepToTopoDS_MakeTransformed* performs a translation of mapped_item entity and indirectly uses class *StepToTopoDS_Builder*. The tolerance of the resulting shape is not modified inside this method.
+
<h4>Healing of resulting shape in ShapeHealing component</h4>
-<h5>Class ShapeFix_Wire</h5>
-1. ShapeFix_Wire::FixSelfIntersection()
-This method is intended for detecting and fixing self-intersecting edges and intersections of adjacent edges in a wire. It fixes self-intersections by cutting edges at the intersection point and/or by increasing the tolerance of the vertex (so that the vertex comprises the point of intersection). There is a maximum tolerance that can be set by this method transmitted as a parameter, currently is read.maxprecision.value.
+##### ShapeFix_Wire::FixSelfIntersection()
+This method is intended for detecting and fixing self-intersecting edges and intersections of adjacent edges in a wire. It fixes self-intersections by cutting edges at the intersection point and/or by increasing the tolerance of the vertex (so that the vertex comprises the point of intersection). There is a maximum tolerance that can be set by this method transmitted as a parameter, currently is *read.maxprecision.value*.
+
When a self-intersection of one edge is found, it is fixed by one of the two methods:
* tolerance of the vertex of that edge which is nearest to the point of self-intersection is increased so that it comprises both its own old position and the intersection point
* the self-intersecting loop on the pcurve is cut out and a new pcurve is constructed. This can increase the tolerance of the edge.
+
The method producing a smaller tolerance is selected.
+
When an intersection of two adjacent edges is detected, edges are cut at that point. Tolerance of the common vertex of these edges is increased in order to comprise both the intersection point and the old position.
-This method can increase the tolerance of the vertex up to a value of read.maxprecision.value.
-2. ShapeFix_Wire::FixLacking()
+
+This method can increase the tolerance of the vertex up to a value of *read.maxprecision.value*.
+
+##### ShapeFix_Wire::FixLacking()
This method is intended to detect gaps between pcurves of adjacent edges (with the precision of surface UVResolution computed from tolerance of a corresponding vertex) and to fix these gaps either by increasing the tolerance of the vertex, or by inserting a new degenerated edge (straight in parametric space).
+
If it is possible to compensate a gap by increasing the tolerance of the vertex to a value of less than the initial value of tolerance, the tolerance of the vertex is increased. Else, if the vertex is placed in a degenerated point then a degenerated edge is inserted.
-3. ShapeFix_Wire::FixConnected()
-This method is intended to force two adjacent edges in the wire to share the same vertex. This method can increase the tolerance of the vertex. The maximal value of tolerance is read.maxprecision.value.
-@subsection occt_1624647986_248980126 Code architecture
-@subsubsection occt_1624647986_2489801261 List of the classes
-<h4>package STEPControl </h4>
-STEPControl_Reader
-STEPControl_ActorRead
-<h4>package StepToTopoDS </h4>
-StepToTopoDS_Builder
-StepToTopoDS_MakeTransformed
-StepToTopoDS_TranslateShell
-StepToTopoDS_TranslateFace
-StepToTopoDS_TranslateEdgeLoop
-StepToTopoDS_TranslatePolyLoop
-StepToTopoDS_TranslateVertexLoop
-StepToTopoDS_TranslateEdge
-StepToTopoDS_TranslateVertex
-<h4>package StepToGeom </h4>
-StepToGeom_MakeCartesianPoint
-StepToGeom_MakeCurve
-StepToGeom_MakeLine
-StepToGeom_MakeSurface
-For more information refer to CDL.
-@subsubsection occt_1624647986_2489801262 API classes
-<h4>package STEPControl </h4>
- STEPControl_Controller
- STEPControl_Reader
- STEPControl_ActorRead
-
-For a description of these classes refer to the chapter 4. API for reading/writing STEP.
-@subsubsection occt_1624647986_2489801263 Graph of calls
-The following diagram illustrates the structure of calls in reading STEP.
-
-
-@subsection occt_1624647986_248980127 Example
+
+##### ShapeFix_Wire::FixConnected()
+This method is intended to force two adjacent edges in the wire to share the same vertex. This method can increase the tolerance of the vertex. The maximal value of tolerance is *read.maxprecision.value*.
+
+@subsection occt_step_2_6 Code architecture
+
+The following diagram illustrates the structure of calls in reading STEP. The highlighted classes are intended to translate geometry
+
+@image html /user_guides/step/images/step_image003.jpg "The structure of calls in reading STEP"
+@image latex /user_guides/step/images/step_image003.jpg "The structure of calls in reading STEP"
+
+@subsection occt_step_2_7 Example
+~~~~~
#include STEPControl_Reader.hxx
#include TopoDS_Shape.hxx
#include BRepTools.hxx
Standard_Integer main()
{
- STEPControl_Reader reader;
- reader.ReadFile(;MyFile.stp;);
+ STEPControl_Reader reader;
+ reader.ReadFile(;MyFile.stp;);
- // Loads file MyFile.stp
- Standard_Integer NbRoots = reader.NbRootsForTransfer();
+ // Loads file MyFile.stp
+ Standard_Integer NbRoots = reader.NbRootsForTransfer();
- // gets the number of transferable roots
- cout;Number of roots in STEP file: ; NbRootsendl;
+ // gets the number of transferable roots
+ cout;Number of roots in STEP file: ; NbRootsendl;
- Standard_Integer NbTrans = reader.TransferRoots();
- // translates all transferable roots, and returns the number of //successful translations
- cout;STEP roots transferred: ; NbTransendl;
- cout;Number of resulting shapes is: ;reader.NbShapes()endl;
+ Standard_Integer NbTrans = reader.TransferRoots();
+ // translates all transferable roots, and returns the number of //successful translations
+ cout;STEP roots transferred: ; NbTransendl;
+ cout;Number of resulting shapes is: ;reader.NbShapes()endl;
- TopoDS_Shape result = reader.OneShape();
- // obtain the results of translation in one OCCT shape
+ TopoDS_Shape result = reader.OneShape();
+ // obtain the results of translation in one OCCT shape
- . . .
+ . . .
}
+~~~~~
-@section occt_1624647986_604379675 Writing STEP
-@subsection occt_1624647986_6043796751 Procedure
+
+@section occt_step_3 Writing STEP
+@subsection occt_step_3_1 Procedure
You can translate OCCT shapes into STEP entities in the following steps:
- 1.initialize the process,
- 2.set the translation parameters,
- 3.perform the shape translation,
- 4.write the output file.
+ 1.initialize the process,
+ 2.set the translation parameters,
+ 3.perform the shape translation,
+ 4.write the output file.
+
You can translate several shapes before writing a file. All these translations output a separate shape_representation entity in STEP file.
-The user-defined option (parameter ;write.step.schema;) is provided to define which version of schema (AP214 CD or DIS, or AP203) is used for the output STEP file.
-@subsection occt_1624647986_6043796752 Domain covered
-@subsubsection occt_1624647986_60437967521 Writing geometry and topology
+
+The user-defined option (parameter *write.step.schema*) is provided to define which version of schema (AP214 CD or DIS, or AP203) is used for the output STEP file.
+
+@subsection occt_step_3_2 Domain covered
+@subsubsection occt_step_3_2_1 Writing geometry and topology
There are two families of OCCT objects that can be translated:
* geometrical objects,
* topological shapes.
-@subsubsection occt_1624647986_60437967522 Writing assembly structures
-The shapes organized in a structure of nested compounds can be translated either as simple compound shapes, or into the assembly structure, depending on the parameter ;write.step.assembly;, which is described below.
+
+@subsubsection occt_step_3_2_2 Writing assembly structures
+The shapes organized in a structure of nested compounds can be translated either as simple compound shapes, or into the assembly structure, depending on the parameter *write.step.assembly*, which is described below.
The assembly structure placed in the produced STEP file corresponds to the structure described in the ProSTEP Agreement Log (item 21) as the second alternative (assembly structure through representation_relationship / item_defined_transformation). To represent an assembly it uses entities of the representation_relationship_with_transformation type. Transformation operators used for locating assembly components are represented by item_defined_transformation entities.
If mode ;write.step.assembly; is set to the values ON or Auto then an OCC shape consisting of nested compounds will be written as an assembly, otherwise it will be written as separate solids.
-Please see also the sub-chapter ;Mapping OCCT shapes to STEP entities;.
-@subsection occt_1624647986_6043796753 Description of the process
-@subsubsection occt_1624647986_60437967531 Initializing the process
+Please see also <a href="#occt_step_3_4">Mapping OCCT shapes to STEP entities</a>
+
+@subsection occt_step_3_3 Description of the process
+@subsubsection occt_step_3_3_1 Initializing the process
Before performing any other operation you have to create a writer object:
+~~~~~
STEPControl_Writer writer;
-@subsubsection occt_1624647986_60437967532 Setting the translation parameters
+~~~~~
+@subsubsection occt_step_3_3_2 Setting the translation parameters
+
The following parameters are used for the OCCT-to-STEP translation.
+
<h4>write.precision.mode</h4>
+
writes the precision value.
-;Least; (-1) : the uncertainty value is set to the minimum tolerance of an OCCT shape
-;Average; (0) : the uncertainty value is set to the average tolerance of an OCCT shape.
-;Greatest; (1) : the uncertainty value is set to the maximum tolerance of an OCCT shape
-;Session; (2) : the uncertainty value is that of the write.precision.val parameter.
+* Least (-1) : the uncertainty value is set to the minimum tolerance of an OCCT shape
+* Average (0) : the uncertainty value is set to the average tolerance of an OCCT shape.
+* Greatest (1) : the uncertainty value is set to the maximum tolerance of an OCCT shape
+* Session (2) : the uncertainty value is that of the write.precision.val parameter.
+
Read this parameter with:
-Standard_Integer ic = Interface_Static::IVal(;write.precision.mode;);
+
+Standard_Integer ic = Interface_Static::IVal("write.precision.mode");
Modify this parameter with:
-if(!Interface_Static::SetIVal(;write.precision.mode;,1))
+~~~~~
+if(!Interface_Static::SetIVal("write.precision.mode",1))
.. error ..
+~~~~~
Default value is 0.
+
<h4>write.precision.val</h4>
a user-defined precision value. This parameter gives the uncertainty for STEP entities constructed from OCCT shapes when the write.precision.mode parameter value is 1.
* 0.0001: default
* any real positive (non null) value.
+
This value is stored in shape_representation in a STEP file as an uncertainty.
+
Read this parameter with:
-Standard_Real rp = Interface_Static::RVal(;write.precision.val;);
+~~~~~
+Standard_Real rp = Interface_Static::RVal("write.precision.val");
+~~~~~
+
Modify this parameter with:
-if(!Interface_Static::SetRVal(;write.precision.val;,0.01))
+~~~~~
+if(!Interface_Static::SetRVal("write.precision.val",0.01))
.. error ..
+~~~~~
Default value is 0.0001.
+
<h4>write.step.assembly</h4>
writing assembly mode.
-0 (Off) : (default) writes STEP files without assemblies.
-1 (On) : writes all shapes in the form of STEP assemblies.
-2 (Auto) : writes shapes having a structure of (possibly nested) TopoDS_Compounds in the form of STEP assemblies, single shapes are written without assembly structures.
+* 0 (Off) : (default) writes STEP files without assemblies.
+* 1 (On) : writes all shapes in the form of STEP assemblies.
+* 2 (Auto) : writes shapes having a structure of (possibly nested) *TopoDS_Compounds* in the form of STEP assemblies, single shapes are written without assembly structures.
+
Read this parameter with:
-Standard_Integer rp = Interface_Static::IVal(;write.step.assembly;);
+~~~~~
+Standard_Integer rp = Interface_Static::IVal("write.step.assembly");
+~~~~~
Modify this parameter with:
-if(!Interface_Static::SetIVal(;write.step.assembly;,1))
+~~~~~
+if(!Interface_Static::SetIVal("write.step.assembly",1))
.. error ..
+~~~~~
Default value is 0.
+
<h4>write.step.schema</h4>
defines the version of schema used for the output STEP file:
- 1 or ;AP214CD; (default): AP214, CD version (dated 26 November 1996),
- 2 or ;AP214DIS;: AP214, DIS version (dated 15 September 1998).
- 3 or ;AP203;: AP203, possibly with modular extensions (depending on data written to a file).
- 4 or *AP214IS*: AP214, IS version (dated 2002)
+ * 1 or ;AP214CD; (default): AP214, CD version (dated 26 November 1996),
+ * 2 or ;AP214DIS;: AP214, DIS version (dated 15 September 1998).
+ * 3 or ;AP203;: AP203, possibly with modular extensions (depending on data written to a file).
+ * 4 or *AP214IS*: AP214, IS version (dated 2002)
This parameter affects the following entities written to the STEP file:
-
+AP214, CD version AP214, DIS version AP214,IS version AP203
+FILE_SCHEMA( (`AUTOMOTIVE_DESIGN_CC2 { 1 2 10303 214 -1 1 5 4}')) FILE_SCHEMA( (`AUTOMOTIVE_DESIGN { 1 2 10303 214 0 1 1 1}')) FILE_SCHEMA(
+('AUTOMOTIVE_DESIGN
+ { 1 0 10303 214 1 1 1 1 }')) FILE_SCHEMA( (`CONFIG_CONTROL_DESIGN'))
+APPLICATION_PROTOCOL_ DEFINITION
+`committee draft',
+`automotive_design'
+,1997,##) APPLICATION_PROTOCOL_ DEFINITION(
+'draft international standard',
+'automotive_design',
+1998,##) APPLICATION_PROTOCOL_DEFINITION
+('international standard', ‘automotive_design',
+2000,##); APPLICATION_PROTOCOL_ DEFINITION
+('international standard', 'config_control_design',1994,##)
+APPLICATION_CONTEXT( 'core data for automotive mechanical design processes') APPLICATION_CONTEXT( ‘configuration controlled 3D designs of mechanical parts and assemblies' )
+PRODUCT_TYPE(`part',$,(##)) PRODUCT_RELATED_PRODUCT_CATEGORY( `part',$,(##))
+MECHANICAL_CONTEXT(`',##, 'mechanical') PRODUCT_CONTEXT(`',##, 'mechanical') PRODUCT_CONTEXT('',##,'mechanical'); MECHANICAL_CONTEXT(`',##, 'mechanical')
In addition, in AP203 mode more product and organizational entities are generated (entities like PERSON_AND_ORGANIZATION, SECURITY_CLASSIFICATION etc., as required by AP203).
Read this parameter with:
-TCollection_AsciiString schema = Interface_Static::CVal(;write.step.schema;);
+~~~~~
+TCollection_AsciiString schema = Interface_Static::CVal("write.step.schema");
+~~~~~
Modify this parameter with:
-if(!Interface_Static::SetCVal(;write.step.schema;,;DIS;))
+~~~~~
+if(!Interface_Static::SetCVal("write.step.schema","DIS"))
.. error ..
+~~~~~
Default value is 1 (;CD;).
-For the parameter ;write.step.schema; to take effect, method STEPControl_Writer::Model(Standard_True) should be called after changing this parameter (corresponding command in DRAW is ;newmodel;).
+For the parameter *write.step.schema* to take effect, method *STEPControl_Writer::Model(Standard_True)* should be called after changing this parameter (corresponding command in DRAW is *newmodel*).
+
<h4>write.step.product.name</h4>
Defines the text string that will be used for field ‘name’ of PRODUCT entities written to the STEP file.
-Default value: *OCCT STEP translator 6.1* (the 6.1 stands for Open CASCADE Technology version number).
+
+Default value: OCCT STEP translator (current OCCT version number).
+
<h4>write.surfacecurve.mode</h4>
This parameter indicates whether parametric curves (curves in parametric space of surface) should be written into the STEP file. This parameter can be set to Off in order to minimize the size of the resulting STEP file.
-Off (0) : writes STEP files without pcurves. This mode decreases the size of the resulting STEP file .
-On (1) : (default) writes pcurves to STEP file
+
+* Off (0) : writes STEP files without pcurves. This mode decreases the size of the resulting STEP file .
+* On (1) : (default) writes pcurves to STEP file
+
Read this parameter with:
-Standard_Integer wp = Interface_Static::IVal(;write.surfacecurve.mode;);
+~~~~~
+Standard_Integer wp = Interface_Static::IVal("write.surfacecurve.mode");
+~~~~~
Modify this parameter with:
-if(!Interface_Static::SetIVal(;write.surfacecurve.mode;,1))
+~~~~~
+if(!Interface_Static::SetIVal("write.surfacecurve.mode",1))
.. error ..
+~~~~~
Default value is On.
+
<h4>write.step.unit</h4>
Defines a unit in which the STEP file should be written. If set to unit other than MM, the model is converted to these units during the translation.
+
Default value is MM.
-<h4>write.step.resource.name</h4>
-<h4>write.step.sequence</h4>
+
+<h4>write.step.resource.name and write.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 before translating a shape to a STEP file. Shape Processing is a user-configurable step, which is performed before the 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 two operators: SplitCommonVertex and DirectFaces, which convert some geometry and topological constructs valid in Open CASCADE Technology but not in STEP to equivalent definitions conforming to STEP format.
+
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.
-@subsubsection occt_1624647986_60437967533 Performing the Open CASCADE Technology shape translation
+
+Default values:
+* read.step.resource.name - STEP,
+* read.step.sequence - ToSTEP.
+
+@subsubsection occt_step_3_3_3 Performing the Open CASCADE Technology shape translation
An OCCT shape can be translated to STEP using one of the following models (shape_representations):
* manifold_solid_brep (advanced_brep_shape_representation)
* brep_with_voids (advanced_brep_shape_representation)
* faceted_brep (faceted_brep_shape_representation)
* shell_based_surface_model (manifold_surface_shape_representation)
* geometric_curve_set (geometrically_bounded_wireframe_shape_representation)
-The enumeration **STEPControl_StepModelType** is intended to define a particular transferring model.
+
+The enumeration **TEPControl_StepModelType* is intended to define a particular transferring model.
The following values of enumeration are allowed:
+* *STEPControl_AsIs* Translator selects the resulting representation automatically, according to the type of CASCADE shape to translate it in its highest possible model;
+* *STEPControl_ManifoldSolidBrep* resulting entity is manifold_solid_brep or brep_with_voids
+* *STEPControl_FacetedBrep* resulting entity is *faceted_brep* or *faceted_brep_and_brep_with_voids* Note that only planar-face shapes with linear edges can be written;
+* *STEPControl_ShellBasedSurfaceModel* resulting entity is *shell_based_surface_model*;
+* *STEPControl_GeometricCurveSet* resulting entity is *geometric_curve_set*;
The following table shows which shapes can be translated in which mode:
-If TopoDS_Compound contains any other types besides the ones mentioned in the table, these sub-shapes will be ignored.
+* *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.
+
In case if an OCCT shape cannot be translated according to its mode the result of translation is void.
-For further information see *Mapping Open CASCADE Technology shapes to STEP entities* below.
+~~~~~
STEP214Control_StepModelTope mode = STEP214Control_ManifoldSolidBrep;
IFSelect_ReturnStatus stat = writer.Transfer(shape,mode);
-@subsubsection occt_1624647986_60437967534 Writing the STEP file
+~~~~~
+
+@subsubsection occt_step_3_3_4 Writing the STEP file
Write the STEP file with:
-IFSelect_ReturnStatus stat = writer.Write(;filename.stp;);
+~~~~~
+IFSelect_ReturnStatus stat = writer.Write("filename.stp");
+~~~~~
to give the file name.
-@subsection occt_1624647986_6043796754 Mapping Open CASCADE Technology shapes to STEP entities
+
+@subsection occt_step_3_4 Mapping Open CASCADE Technology shapes to STEP entities
Only STEP entities that have a corresponding OCCT object and mapping of assembly structures are described in this paragraph. For a full list of STEP entities please refer to Appendix A.
-@subsubsection occt_1624647986_60437967541 Assembly structures and product information
-The assembly structures are written to the STEP file if parameter write.step.assembly is 1 or 2.
-Each TopoDS_Compound is written as an assembly with subshapes of that compound being components of the assembly. The structure of nested compounds is translated to the structure of nested assemblies. Shared subshapes are translated into shared components of assemblies. Shapes that are not compounds are translated into subtypes of shape_representation according to their type (see the next subchapter for details).
+
+@subsubsection occt_step_3_4_1 Assembly structures and product information
+The assembly structures are written to the STEP file if parameter *write.step.assembly* is 1 or 2.
+Each *TopoDS_Compound* is written as an assembly with subshapes of that compound being components of the assembly. The structure of nested compounds is translated to the structure of nested assemblies. Shared subshapes are translated into shared components of assemblies. Shapes that are not compounds are translated into subtypes of shape_representation according to their type (see the next subchapter for details).
+
A set of STEP entities describing general product information is written to the STEP file together with the entities describing the product geometry, topology and assembly structure. Most of these entities are attached to the entities being subtypes of shape_representation, but some of them are created only one per STEP file.
+
The table below describes STEP entities, which are created when the assembly structure and product information are written to the STEP file, and shows how many of these entities are created. Note that the appearance of some of these entities depends on the version of the schema (AP214, CD, DIS or IS, or AP203).
-
-@subsubsection occt_1624647986_60437967542 Topological shapes
-@subsubsection occt_1624647986_60437967543 Geometrical objects
+CASCADE shape STEP entity Comments
+ application_protocol_definition One per STEP file, defines the application protocol used (depends on the schema version)
+ application_context One per STEP file, defines the application generating the file (AP214 or AP203)
+TopoDS_Compound shape_representation Empty shape_representation describing the assembly. The components of that assembly are written as subtypes of shape_representation and are included to the assembly using next_assembly_usage_occurence entities.
+TopoDS_Shape subtypes of shape_representation Depending on the shape type, see the tables below for mapping details
+ next_assembly_usage_occurence Describes the instance of component in the assembly by referring corresponding product_definitions. If the same component is included in the assembly several times (for example, with different locations), several next_assembly_usage_occurences are created.
+ context_dependent_shape_representation Describes the placement of a component in the assembly. One context_dependent_shape_ representation corresponds to each next_assembly_usage_occurence entity.
+ shape_representation_relationship_with_transformation Together with the context_dependent_shape_ representation describes the location of a component in the assembly.
+ item_defined_transformation Defines a transformation used for the location of a component in the assembly. Is referred by shape_representation_relationship_with_transformation
+ shape_definition_representation One per shape_representation
+ product_definition_shape One per shape_definition_representation and context_dependent_shape_representation
+ product_definition Defines a product, one per shape_definition_representation
+ product_definition_formation One per product_definition. All product_definition_formations in the STEP file have unique names.
+ Product One per product_definition_formation. All products in the STEP file have unique names.
+ product_type (CD) or product_related_product_category (DIS,IS) One per product
+ Mechanical_context (CD) or product_context (DIS,IS) One per product.
+ product_definition_context One per product_definition.
+
+
+@subsubsection occt_step_3_4_2 Topological shapes
+CASCADE shape STEP entity Comments
+TopoDS_Compound geometric_curve_set If the write mode is STEP214Control_GeometricCurveSet only 3D curves of the edges found in TopoDS_Compound and all its subshapes are translated
+ manifold_solid_brep If the write mode is STEP214Control_AsIs and TopoDS_Compound consists only of TopoDS_Solids
+ shell_based_surface_model If the write mode is STEP214Control_AsIs and TopoDS_Compound consists of TopoDS_Solids, TopoDS_Shells and TopoDS_Faces
+ geometric_curve_set If the write mode is STEP214Control_AsIs and TopoDS_Compound contains TopoDS_Wires, TopoDS_Edges, TopoDS_Vertices
+ If the write mode is not STEP214Control_AsIs or STEP214Control_GeometricCurveSet TopoDS_Solids, TopoDS_Shells and TopoDS_Faces are translated according to this table.
+TopoDS_Solid manifold_solid_brep If the write mode is STEP214Control_AsIs or STEP214Control_ManifoldSolidBrep and CASCADE TopoDS_Solid has no voids.
+ faceted_brep If the write mode is STEP214Control_FacetedBrep.
+ brep_with_voids If the write mode is STEP214Control_AsIs or STEP214Control_ManifoldSolidBrep and CASCADE TopoDS_Solid has voids.
+ shell_based_surface_model If the write mode is STEP214Control_ShellBasedSurfaceModel.
+ geometric_curve_set If the write mode is STEP214Control_GeometricCurveSet. Only 3D curves of the edges are translated.
+TopoDS_Shell in a TopoDS_Solid closed_shell If TopoDS_Shell is closed shell.
+TopoDS_Shell manifold_solid_brep If the write mode is STEP214Control_ManifoldSolidBrep.
+ shell_based_surface_model If the write mode is STEP214Control_AsIs or STEP214Control_ShellBasedSurfaceModel.
+ geometric_curve_set If the write mode is STEP214Control_GeometricCurveSet. Only 3D curves of the edges are translated.
+TopoDS_Face advanced_face
+TopoDS_Wire in a TopoDS_Face face_bound The resulting face_bound contains poly_loop if write mode is faceted_brep or edge_loop if not .
+TopoDS_Wire geometric_curve_set If the write mode is STEP214Control_GeometricCurveSet. Only 3D curves of the edges are translated.
+TopoDS_Edge oriented_edge
+TopoDS_Vertex vertex_point
-@subsection occt_1624647986_6043796755 Tolerance management
+@subsubsection occt_step_3_4_3 Geometrical objects
+CASCADE object STEP entity Comments
+Points
+Geom_CartesianPoint cartesian_point
+Geom2d_CartesianPoint
+TColgp_Array1OfPnt polyline
+TColgp_Array1OfPnt2d
+Placements
+Geom_Axis1Plasement axis1_placement
+Geom2d_AxisPlacement
+Geom_Axis2Placement axis2_placement_3d
+Directions
+Geom_Direction direction
+Geom2d_Direction
+Vectors
+Geom_Vector vector
+Geom2d_Vector
+Curves
+Geom_Circle circle
+Geom2d_Circle circle
+ rational_b_spline_curve
+Geom_Ellipse Ellipse
+Geom2d_Ellipse Ellipse
+ rational_b_spline_curve
+Geom_Hyperbola Hyperbola
+Geom2d_Hyperbola
+Geom_Parabola Parabola
+Geom2d_Parabola
+Geom_BSplineCurve b_spline_curve_with_knots
+ rational_b_spline_curve if Geom_BsplineCurve is a rational BSpline
+Geom2d_BSplineCurve b_spline_curve_with_knots
+ b_spline_curve_with_knots_ and_rational_b_spline_curve if Geom2d_BSplineCurve is a rational Bspline
+Geom_BezierCurve b_spline_curve_with_knots
+Geom_Line Line
+Geom2d_Line
+Surfaces
+Geom_Plane Plane
+Geom_OffsetSurface offset_surface
+Geom_ConicalSurface conical_surface
+Geom_CylindricalSurface cylindrical_surface
+Geom_OffsetSurface offset_surface
+Geom_RectangularTrimmedSurface rectangular_trimmed_surface
+Geom_SphericalSurface spherical_surface
+Geom_SurfaceOfLinear Extrusion surface_of_linear_extrusion
+Geom_SurfaceOf Revolution surface_of_revolution
+Geom_ToroidalSurface toroidal_surface
+ degenerate_toroidal_surface if the minor radius is greater then the major one
+Geom_BezierSurface b_spline_surface_with_knots
+Geom_BsplineSurface b_spline_surface_with_knots
+ b_spline_surface_with_knots_ and_rational_b_spline_surface if Geom_BSplineSurface is a rational Bspline
+
+
+@subsection occt_step_3_5 Tolerance management
There are four possible values for the uncertainty when writing a STEP file:
* user-defined value of the uncertainty
* minimal value of sub-shapes tolerances
* average value of sub-shapes tolerances
* maximal value of sub-shapes tolerances
+
The chosen value of the uncertainty is the final value that will be written into the STEP file.
-See parameter write.precision.mode.
-@subsection occt_1624647986_6043796756 Code architecture
-@subsubsection occt_1624647986_60437967561 List of the classes
-<h4>package STEPControl </h4>
-STEPControl_Controller
-STEPControl_Writer
-STEPControl_ActorWrite
-<h4>package TopoDSToStep</h4>
-TopoDSToStep_Builder
-TopoDSToStep_WireframeBuilder
-TopoDSToStep_MakeBrepWithVoids
-TopoDSToStep_MakeFacetedBrep
-TopoDSToStep_MakeFacetedBrepAndBrepWithVoids
-TopoDSToStep_MakeGeometricCurveSet
-TopoDSToStep_MakeManifoldSolidBrep
-TopoDSToStep_MakeShellBasedSurfaceModel
-TopoDSToStep_FacetedTool
-TopoDSToStep_MakeStepFace
-TopoDSToStep_MakeStepWire
-TopoDSToStep_MakeStepEdge
-TopoDSToStep_MakeStepVertex
-<h4>package GeomToStep </h4>
-GeomToStep_MakeCartesianPoint
-GeomToStep_MakeCurve
-GeomToStep_MakePolyline
-GeomToStep_MakeSurface
-For more information refer to CDL.
-@subsubsection occt_1624647986_60437967562 API classes
-<h4>package STEPControl </h4>
-STEPControl_Controller
-STEPControl_Writer
-STEPControl_ActorWrite
-
-For a description of these classes refer to the chapter 4. API for reading/writing STEP.
-@subsubsection occt_1624647986_60437967563 Graph of calls
+See parameter *write.precision.mode*.
+
+
+@subsection occt_step_3_6 Code architecture
+
+@subsubsection occt_step_3_6_1 Graph of calls
The following diagram illustrates the structure of calls in writing STEP.
The highlighted classes are intended to translate geometry.
+@image html /user_guides/step/images/step_image004.jpg "The structure of calls in writing STEP"
+@image latex /user_guides/step/images/step_image004.jpg "The structure of calls in writing STEP"
- <table>
- <tr>
- <td>
-
- </td>
- </tr>
- <tr>
- <td>
-
- </td>
- <td>
- 
- </td>
- </tr>
-</table>
-@subsection occt_1624647986_6043796757 Example
+
+@subsection occt_step_3_7 Example
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
#include STEPControl.hxx
#include STEPControl_Writer.hxx
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-@section occt_1624647986_1430038387 API for reading/writing STEP
-@subsection occt_1624647986_14300383871 Overview
-This chapter contains a description of packages, which provide API for translating OCCT shapes into STEP files and vice versa.
-Package STEPControl provides API for reading and writing STEP files. This package deals with OCCT shapes. It includes five API classes:
- * STEPControl_Controller - for initializing the STEP norm,
- * STEPControl_Reader - for reading STEP files,
- * STEPControl_Writer - for writing STEP files,
- * STEPControl_ActorRead - actor which performs translation of a STEP entity into an OCCT shape,
- * STEPControl_ActorWrite – actor, which performs translation of an OCCT shape into a STEP entity.
-@subsection occt_1624647986_14300383872 Package STEPControl
-@subsubsection occt_1624647986_143003838721 General description
-This package provides tools to translate STEP entities to OCCT shapes and vice versa.
-STEP AP 214 and AP 203 entities can be read and translated.
-File that is produced by this component conforms to either STEP AP214 (CD, DIS or IS version) or AP203 schema, according to parameter write.step.schema.
-The result of importing a STEP file is an OCCT shape. The result of exporting an OCCT geometrical or topological object is a STEP file that conforms to AP 214 or AP203.
-The package contains the following classes:
-class STEPControl_Controller
-class STEPControl_Reader
-class STEPControl_Writer
-class STEPControl_ActorRead
-class STEPControl_ActorWrite
-@subsubsection occt_1624647986_143003838722 Enumeration STEPControl_StepModelType
-enum STEPControl_StepModelType {
-STEPControl_AsIs,
-STEPControl_ManifoldSolidBrep,
-STEPControl_BrepWithVoids,
-STEPControl_FacetedBrep,
-STEPControl_FacetedBrepAndBrepWithVoids,
-STEPControl_ShellBasedSurfaceModel,
-STEPControl_GeometricCurveSet,
-STEPControl_Hybrid
-}
-Purpose: This enumeration is intended to define a particular transferring model for writing STEP. The following values of enumeration are allowed:
-
-@subsubsection occt_1624647986_143003838723 Class STEPControl_Controller
-<h4>General description</h4>
-This class is intended to provide an appropriate initialization of the STEP norm, namely it includes a set of necessary parameters for STEP translation.
-After completing the initialization the STEP norm can be used.
-Inheritance
-XSControl_Controller
-MMgt_TShared
-Standard_Trancient
-
-<h4>Methods</h4>
-<h5>Constructors</h5>
- * STEPControl_Controller();
-Purpose: Initializes the use of the STEP norm in the first call. Creates an object with default parameters.
-<h5>Method for performing initialization </h5>
- * STEPControl_Controller::Init
-static Standard_Boolean Init();
-Purpose: Performs standard initialization creating a controller object for the STEP norm. Returns True.
-<h5>Method for creating a STEP Model object </h5>
- * STEPControl_Controller::NewModel
-Handle_Interface_InterfaceModel NewModel() const;
-Purpose: Creates a new empty model ready to receive data of the STEP norm. Sets the Header of the model to default values from the STEP template).
-.
-<h5>Method for getting the actor object</h5>
- * STEPControl_Controller::ActorRead
-Handle_Transfer_ActorOfTransientProcess ActorRead(
-const Handle(Interface_InterfaceModel)& model) const;
-Purpose: Returns the actor object for reading (actually, it is of the type STEPControl_ActorRead).
-<h5>Method for translating an Open CASCADE Technology shape </h5>
- * STEPControl_Controller::TransferWriteShape
-virtual IFSelect_ReturnStatus TransferWriteShape(const TopoDS_Shape& shape,
-const Handle(Transfer_FinderProcess)& FP,
-const Handle(Interface_InterfaceModel)& model,
-const Standard_Integer modetrans = 0) const;
-Purpose: Translates an OCCT shape into a STEP entity and adds it to the interface model model. modetrans defines the type of the resulting STEP entity:
-0 - autodetect according to the type of the shape.
-1 - faceted_brep
-2 - shell_based_surface_model
-3 - manifold_solid_brep
-4 - geometric_curve_set
-Returns:
- IFSelect_RetDone: OK
- IFSelect_RetError: if modetrans is not equal to 0,1,2,3,4, or model is not a STEP one.
- IFSelect_Fail: if result is null.
-@subsubsection occt_1624647986_143003838724 Class STEPControl_Reader
-<h4>General description</h4>
-This high level class performs the reading of a STEP file and translating its contents into an OCCT shape. Only geometrical and topological entities conformant to the STEP AP 214 and the AP 203 formats can be translated into OCCT shapes. The result of translation is an OCCT topological shape.
-Inheritance
-XSControl_Reader
-This class complements the XSControl_Reader class (deals directly with WorkSession object).
-<h4>Methods</h4>
-<h5>Constructors </h5>
-STEPControl_Reader();
-Purpose: Creates a reader and initializes a new controller with the help of STEPControl_Controller::Init().
-STEPControl_Reader( const Handle(XSControl_WorkSession)& WS,
-const Standard_Boolean scratch = Standard_True);
-Purpose: Creates a reader and defines its work session. If scratch is true the method sets a new interface model.
-<h5>Method for dealing with STEP Model </h5>
- * STEPControl_Reader::StepModel
-Handle_StepData_StepModel StepModel() const;
-Purpose: Returns a STEP Model.
-<h5>Method for performing translation </h5>
- * STEPControl_Reader::TransferRoot
-Standard_Boolean TransferRoot(const Standard_Integer num = 1)
-Purpose: Translates a STEP root specified by its rank. Performs translation with the help of method XSControl_Reader::TransferOneRoot.
-@subsubsection occt_1624647986_143003838725 Class STEPControl_Writer
-<h4>General description</h4>
-This class is intended to create and write a file compliant to STEP AP 214 or to AP203 out of OCCT shapes. The file produced by this component conforms to STEP AP214 or AP203. This component gives a possibility to write a STEP file containing the following models (shape_representations):
- faceted_brep
- shell_based_surface_model
- manifold_solid_brep
- geometric_curve_set
-The write mode is selected by specifying the appropriate parameter.
-Export into a STEP file can be performed on the basis of either an already existing STEP model (its representation in the memory) or a new one.
-The translation of OCCT shapes (which can be a 2D or a 3D geometrical or topological object) into a STEP file is fulfilled in the following steps:
- * Setting the translation parameters
- * The translation. It can be performed in one or several operations. Each operation defines a root in the STEP file.
- * Writing the STEP file. The output file is specified by its name.
-<h4>Methods</h4>
-<h5>Constructors </h5>
-STEPControl_Writer();
-Purpose: Creates a writer, initializes a default STEPControl_Controller and sets a new work session.
-STEPControl_Writer( const Handle(XSControl_WorkSession)& WS,
-const Standard_Boolean scratch = Standard_True);
-Purpose: Creates a writer, initializes a default STEPControl_Controller with an already existing WorkSession object. If scratch if True, this method clears the already recorded data.
-<h5>Methods for dealing with the uncertainty value </h5>
- * STEPControl_Writer::SetTolerance
-void SetTolerance(const Standard_Real Tol) ;
-Purpose: Sets the value of tolerance, which will be written into a file as a value of uncertainty.
- * STEPControl_Writer::UnsetTolerance
-void UnsetTolerance() ;
-Purpose: Unsets the tolerance set by method SetTolerance. The value of uncertainty will be then calculated as an average tolerance of the OCCT shape.
-<h5>Methods for dealing with a WorkSession object</h5>
- * STEPControl_Writer::SetWS
-void SetWS( const Handle(XSControl_WorkSession)& WS,
-const Standard_Boolean scratch = Standard_True) ;
-Purpose: Sets an existing WorkSession WS.
- * STEPControl_Writer::WS
-Handle_XSControl_WorkSession WS() const;
-Purpose: Returns a current WorkSession object.
-<h5>Method for obtaining a model object </h5>
- * STEPControl_Writer::Model
-Handle_StepData_StepModel Model(
-const Standard_Boolean newone = Standard_False) ;
-Purpose: Returns a produced Model. Produces a new one if such is not yet produced or if newone is True.
-<h5>Method for performing the transfer process </h5>
- * STEPControl_Writer::Transfer
-IFSelect_ReturnStatus Transfer( const TopoDS_Shape& sh,
-const STEPControl_StepModelType mode) ;
-Purpose: Translates a shape sh to STEP entities. Allowed modes are:
-STEPControl_AsIs to select the resulting entity type automatically, according to the type of the OCCT shape to translate it into its highest possible model,
-STEPControl_ManifoldSolidBrep to translate into manifold_solid_brep or brep_with_voids,
-STEPControl_ShellBasedSurfaceModel to translate into shell_based_surface_model,
-STEPControl_FacetedBrep to translate into faceted_brep,
-STEPControl_GeometricCurveSet to translate into geometric_curve_set.
-Returns the transfer status (see Controller from STEPControl)
-<h5>Method for creating a STEP file </h5>
- * STEPControl_Writer::Write
-IFSelect_ReturnStatus Write(const Standard_CString filename) ;
-Purpose: Writes a model into the file filename. Performs this operation with the help of method XSControl_WorkSession::SendAll.
-<h5>Method for obtaining statistics</h5>
- * STEPControl_Writer::PrintStatsTransfer
-void PrintStatsTransfer( const Standard_Integer what,
-const Standard_Integer mode = 0) const;
-Purpose: Intended to display all statistics on the last translation performed. Calls method XSControl_TransferWriter::PrintStats.
-@subsubsection occt_1624647986_143003838726 Class STEPControl_ActorRead
-<h4>General description</h4>
-This class is intended for translation of AP214 and AP203 entities of the following types:
- faceted_brep
- brep_wiht_voids
- manifold_solid_brep
- shell_based_surface_model
- geometric_curve_set
- mapped_item
- face_surface
-It can also translate assembly structures, shape_definition_representation and shape_representation referencing to the mentioned entities.
-The result of translation is Transfer Binder with the resulting OCCT shape.
-Inheritance
-Transfer_ActorOfTransientProcess
-Transfer_ActorOfProcessForTransient
-MMgt_TShared
-Standard_Trancient
-<h4>Methods</h4>
-<h5>Constructor</h5>
-STEPControl_ActorRead();
-Purpose: Empty constructor.
-<h5>Method for recognizing entities </h5>
- * STEPControl_ActorRead::Recognize
-virtual Standard_Boolean Recognize(
-const Handle(Standard_Transient)& start) ;
-Purpose: Returns True if entity start can be translated by this Actor class, i.e. if entity type is one of the types listed above.
-<h5>Method for performing translation </h5>
- * STEPControl_ActorRead::Transfer
-virtual Handle_Transfer_Binder Transfer(
-const Handle(Standard_Transient)& start,
-const Handle(Transfer_TransientProcess)& TP) ;
-Purpose: Performs access to transferable entities and translates them with the help of the class StepToTopoDS_Builder. Sets translation parameters with the help of method PrepareUnits.
- * STEPControl_ActorRead::PrepareUnits
-void PrepareUnits( const Handle(Standard_Transient)& start,
-const Handle(Transfer_TransientProcess)& TP) ;
-Purpose: If start is shape_definition_representation or shape_repesentation entity, this method sets the length and plane angle units taken from entity for performing translation. Sets the tolerance value to uncertainty if read.precision.mode is ;File;.
-@subsubsection occt_1624647986_143003838727 Class STEPControl_ActorWrite
-<h4>General description</h4>
-This class provides an actor for performing the translation of OCCT shapes to STEP AP203 or AP214 entities according to the write mode and schema version (CD , DIS or IS).
-An OCCT shape can be translated to STEP using one of the following models (shape_representations):
- manifold_solid_brep (advanced_brep_shape_representation)
- brep_with_voids (advanced_brep_shape_representation)
- faceted_brep (faceted_brep_shape_representation)
- shell_based_surface_model (manifold_surface_shape_representation)
- geometric_curve_set (geometrically_bounded_wireframe_shape_representation)
-During the translation the actor computes the uncertainty value to be applied to the resulting model (shape_representation).
-This actor also writes STEP assembly structures (according to group mode, which is initialised by the value of parameter write.step.assembly).
-This parameter is used to create a STEP entity with or without assemblies. If write.step.assembly is 1, assemblies are created, if it is 0 assemblies are not created. If it is 2, assemblies are created for compound shapes containing more than one component.
-The transfer mode is enumeration STEPControl_StepModeType, which defiles the resulting model.
-Inheritance
-Transfer_ActorOfFinderProcess
-Transfer_ActorOfProcessForFinder
-MMgt_TShared
-Standard_Transient
-<h4>Methods</h4>
-<h5>Constructors </h5>
-STEPControl_ActorWrite();
-Purpose: Sets the write mode to shell_based_surface_model, group mode to 0 and the default value for the uncertainty that will be computed as an average tolerance for each shape.
-<h5>Method for setting and obtaining translation parameters: </h5>
- * STEPControl_ActorWrite::SetMode
-void SetMode(const STEPControl_StepModelType M) ;
-Purpose: Sets the write mode. M can be of the following values:
-STEPControl_AsIs to select the resulting entity type automatically, according to the type of OCCT shape to translate it into its highest possible model,
-STEPControl_ManifoldSolidBrep to translate into manifold_solid_brep or brep_with_voids,
-STEPControl_ShellBasedSurfaceModel to translate into shell_based_surface_model,
-STEPControl_FacetedBrep to translate into faceted_brep,
-STEPControl_GeometricCurveSet to translate into geometric_curve_set.
- * STEPControl_ActorWrite::Mode
-STEPControl_StepModelType Mode();
-Purpose: Returns the write mode.
- * STEPControl_ActorWrite::SetGroupMode
-void SetGroupMode(const Standard_Integer mode) ;
-Purpose. Sets the group mode, which determines whether assemblies should be created or not. mode can be one of the following values:
-0 - result of translating OCCT shape does not contain assemblies,
-1 - result of translating OCCT shape contains assemblies,
-1 - result of translating OCCT shape can either contain assemblies or not, depending on the original shape.
- * STEPControl_ActorWrite::GroupMode
-Standard_Integer GroupMode() const;
-Purpose: Returns the group mode.
- * STEPControl_ActorWrite::SetTolerance
-void SetTolerance(const Standard_Real Tol) ;
-Purpose: Sets the value of uncertainty for STEP entities. If Tol is more than zero, then Tol will be taken as an uncertainty, if Tol is less than the zero value of the uncertainty it will be calculated as an average tolerance of the shape.
-<h5>Method for recognizing entities </h5>
- * STEPControl_ActorWrite::Recognize
-virtual Standard_Boolean Recognize(const Handle(Transfer_Finder)& start) ;
-Purpose. Checks whether a shape can be translated into a STEP entity according to a defined model. This method returns True if the shape referenced by start can be translated and False if it cannot.
-TopoDS_Solid, TopoDS_Shell can be translated into manifold_solid_brep.
-TopoDS_Solid can be translated into brep_with_voids.
-TopoDS_Solid can be translated into faceted_brep if all its surfaces are planes and all its curves are lines.
-TopoDS_Solid, TopoDS_Shell, TopoDS_Face can be translated into shell_based_surface_model.
-Any OCCT shape can be translated into geometric_curve_set.
-<h5>Method for performing the translation</h5>
- * STEPControl_ActorWrite::Transfer
-virtual Handle_Transfer_Binder Transfer(
-const Handle(Transfer_Finder)& start,
-const Handle(Transfer_FinderProcess)& FP) ;
-Purpose: Translates a single OCCT shape referenced by start into a STEP entity according to the tolerance, the write mode and the group mode.
-Performs translation with the help of package TopoDSToStep and its Make... classes. Returns the transfer binder.
-See also: Package TopoDSToStep, classes TopoDSToStep_Make...
-@subsection occt_1624647986_14300383873 Package STEPConstruct
-@subsubsection occt_1624647986_143003838731 General description
-This package defines tools for creation and investigation of specific STEP constructs used for representing various kinds of data, such as product and assembly structure, unit contexts, and associated information. These structures are created according to the current schema (AP203, AP214 CD2, DIS or IS), which is defined by the parameter write.step.schema.
-The package contains the following classes:
-class STEPConstruct_Styles
-class STEPConstruct_Part
-@subsubsection occt_1624647986_143003838732 Class STEPConstruct_Styles
-<h4>General description</h4>
-This class provides a mechanism for reading and writing shape styles (such as color) to and from a STEP file. This tool maintains a list of styles, either taking them from the STEP model (when reading), or filling it by calls to AddStyle or directly (for writing). Some methods deal with general structures of styles and presentations in STEP, but there are methods dealing with a particular implementation of colors (implemented in accordance with the ;Recommended Practices for colors and layers;).
-<h4>Methods</h4>
-<h5>Constructors </h5>
-STEPConstruct_Styles();
-Purpose: Empty constructor
-STEPConstruct_Styles(const Handle(XSControl_WorkSession)& WS);
-Purpose: Creates an object and calls Init
-<h5>Method for initializing the object </h5>
- * STEPConstruct_Styles::Init
-Standard_Boolean Init(const Handle(XSControl_WorkSession)& WS) ;
-Purpose: Initializes a tool; returns True if succeeded. The XSControl_WorkSession object is used to access data
-<h5>Methods for dealing with styles </h5>
- * STEPConstruct_Styles::NbStyles
-Standard_Integer NbStyles() const;
-Purpose: Returns the number of defined styles.
- * STEPConstruct_Styles::Style
-Handle_StepVisual_StyledItem Style(const Standard_Integer i) const;
-Purpose: Returns a style with a given index
- * STEPConstruct_Styles::ClearStyles
-void ClearStyles() ;
-Purpose: Clears all defined styles
- * STEPConstruct_Styles::AddStyle
-void AddStyle(const Handle(StepVisual_StyledItem)& style) ;
-Purpose: Adds a style to a sequence (defines a style).
- * STEPConstruct_Styles::AddStyle
-Handle_StepVisual_StyledItem AddStyle(
-const Handle(StepRepr_RepresentationItem)& item,
-const Handle(StepVisual_PresentationStyleAssignment)& PSA,
-const Handle(StepVisual_StyledItem)& Override) ;
-Purpose: Creates a style linking giving PSA (presentation_style_assignment) to the item, and adds it to the sequence of stored styles. If Override is not Null, then the resulting style will be of the subtype overriding_styled_item (else just simple styled_item).
- * STEPConstruct_Styles::AddStyle
-Handle_StepVisual_StyledItem AddStyle( const TopoDS_Shape& Shape,
-const Handle(StepVisual_PresentationStyleAssignment)& PSA,
-const Handle(StepVisual_StyledItem)& Override) ;
-Purpose: Creates a style linking giving PSA (presentation_style_assignment) to the Shape, and adds it to the sequence of stored styles. If Override is not Null, then the resulting style will be of the subtype overriding_styled_item (else just simple styled_item). The Shape is used to find a corresponding STEP entity by call to STEPConstruct::FindEntity(), then the previous method is called.
- * STEPConstruct_Styles::CreateMDGPR
-Standard_Boolean CreateMDGPR(const Handle(StepRepr_RepresentationContext)& Context) ;
-Purpose: Creates MDGPR (MECHANICAL_DESIGN_GEOMETRIC_PRESENTATION_ REPRESENTATION), fills it with all the styles previously defined, and adds it to the model.
- * STEPConstruct_Styles::FindContext
-Handle_StepRepr_RepresentationContext FindContext(const TopoDS_Shape& Shape) const;
-Purpose: Searches the STEP model for the RepresentationContext in which given shape is defined. This context (if found) can be used then in call to CreateMDGPR()
- * STEPConstruct_Styles::LoadStyles
-Standard_Boolean LoadStyles() ;
-Purpose: Searches the STEP model for the MDGPR (MECHANICAL_DESIGN_GEOMETRIC_ PRESENTATION_REPRESENTATION) or DM (draughting_model) entities (which bring styles) and reads styles from these entities, thus filling the sequence of styles.
-<h5>Methods for dealing with colors </h5>
- * STEPConstruct_Styles::MakeColorPSA
-Handle_StepVisual_PresentationStyleAssignment MakeColorPSA(
-const Handle(StepRepr_RepresentationItem)& item,
-const Handle(StepVisual_Colour)& SurfCol,
-const Handle(StepVisual_Colour)& CurveCol) const;
-Purpose: Creates a presentation_style_assignment entity defining two colors (for filling surfaces and curves)
- * STEPConstruct_Styles::GetColorPSA
-Handle_StepVisual_PresentationStyleAssignment GetColorPSA(
-const Handle(StepRepr_RepresentationItem)& item,
-const Handle(StepVisual_Colour)& Col) ;
-Purpose: Returns a PresentationStyleAssignment entity, which defines the surface and curve colors as Col. This PSA is either created or taken from the internal map where all PSAs are created by this method are remembered.
- * STEPConstruct_Styles::GetColors
-Standard_Boolean GetColors(
-const Handle(StepVisual_StyledItem)& style,
-Handle(StepVisual_Colour)& SurfCol,
-Handle(StepVisual_Colour)& BoundCol,
-Handle(StepVisual_Colour)& CurveCol) const;
-Purpose: Extract color definitions from the style entity. For each type of color supported, the result can be either NULL if it is not defined by that style, or the last definition (if they are one or more)
-<h5>Methods for converting a STEP and Open CASCADE Technology color definition </h5>
- * STEPConstruct_Styles::EncodeColor
-Handle_StepVisual_Colour EncodeColor(const Quantity_Color& Col) ;
-Purpose: Creates a STEP color entity from a given Quantity_Color. The analysis is performed for whether the color corresponds to the one of standard colors predefined in STEP. In that case, draughting_predefined_colour entity is created instead of rgb_colour.
- * STEPConstruct_Styles::DecodeColor
-Standard_Boolean DecodeColor(const Handle(StepVisual_Colour)& Colour,Quantity_Color& Col) ;
-Purpose: Decodes STEP color and fills the Quantity_Color. Returns True if OK or False if color is not recognized
-@subsubsection occt_1624647986_143003838733 Class STEPConstruct_Part
-<h4>General description</h4>
-Provides tools for creating STEP structures associated with shape_definition_representation, such as product, product_definition_formation etc., as required by the current schema (parameter write.step.schema). Also allows investigating and modifying this data.
-<h4>Methods</h4>
-<h5>Constructors </h5>
-STEPConstruct_Part();
-Purpose: Empty constructor
-<h5>Methods for initializing and obtaining shape_definition_representation </h5>
- * STEPConstruct_Part::MakeSDR
-void MakeSDR( const Handle(StepShape_ShapeRepresentation)& aShape,
-const Handle(TCollection_HAsciiString)& aName,
-const Handle(StepBasic_ApplicationContext)& AC) ;
-Purpose: Creates shape_definition_representation according to the currently active schema (AP203 or AP214 CD2, DIS or IS), which is taken from parameter write.step.schema. Creates all necessary product description entities as well.
- * STEPConstruct_Part::ReadSDR
-void ReadSDR(const Handle(StepShape_ShapeDefinitionRepresentation)& aSDR) ;
-Purpose: Sets the current SDR (shape_definition_representation) to the specified shape_definition_ representation aSDR
- * STEPConstruct_Part::SDRValue
-Handle_StepShape_ShapeDefinitionRepresentation SDRValue() const;
-Purpose: Returns the current SDR or Null if no SDR is set or created
-<h5>Method for obtaining the done status </h5>
- * STEPConstruct_Part::IsDone
-Standard_Boolean IsDone() const;
-Purpose: Returns the done status
-<h5>Method for obtaining shape_representation </h5>
- * STEPConstruct_Part::SRValue
-Handle_StepShape_ShapeRepresentation SRValue() const;
-Purpose: Returns used_representation from the current SDR or Null if not done
-<h5>Methods for dealing with product_context </h5>
- * STEPConstruct_Part::PC
-Handle_StepBasic_ProductContext PC() const;
-Purpose: Returns the product_context associated with the current SDR
- * STEPConstruct_Part::PCname
-Handle_TCollection_HAsciiString PCname() const;
-Purpose: Returns the Name of the product_context associated with the current SDR
- * STEPConstruct_Part::PCdisciplineType
-Handle_TCollection_HAsciiString PCdisciplineType() const;
-Purpose: Returns the discipline type of the product_context associated with the current SDR
- * STEPConstruct_Part::SetPCname
-void SetPCname(const Handle(TCollection_HAsciiString)& name) ;
-Purpose: Sets the Name of the product_context associated with the current SDR
- * STEPConstruct_Part::SetPCdisciplineType
-void SetPCdisciplineType(const Handle(TCollection_HAsciiString)& label);
-Purpose: Sets the discipline type of the product_context associated with the current SDR
-<h5>Methods dealing with application_context </h5>
- * STEPConstruct_Part::AC
-Handle_StepBasic_ApplicationContext AC() const;
-Purpose: Returns the application_context associated with the current SDR
- * STEPConstruct_Part::ACapplication
-Handle_TCollection_HAsciiString ACapplication() const;
-Purpose: Returns the application of the application_context associated with the current SDR
- * STEPConstruct_Part::SetACapplication
-void SetACapplication(const Handle(TCollection_HAsciiString)& text) ;
-Purpose: Sets the application of the application_context associated with the current SDR
- * STEPConstruct_Part::PDC
-Handle_StepBasic_ProductDefinitionContext PDC() const;
-Purpose: Returns the product_definition_context associated with the current SDR
- * STEPConstruct_Part::PDCname
-Handle_TCollection_HAsciiString PDCname() const;
-Purpose: Returns the name of the product_definition_context associated with the current SDR
- * STEPConstruct_Part::PDCstage
-Handle_TCollection_HAsciiString PDCstage() const;
-Purpose: Returns the life cycle stage of the product_definition_context associated with the current SDR
- * STEPConstruct_Part::SetPDCname
-void SetPDCname(const Handle(TCollection_HAsciiString)& label) ;
-Purpose: Sets the name of the product_definition_context associated with the current SDR
- * STEPConstruct_Part::SetPDCstage
-void SetPDCstage(const Handle(TCollection_HAsciiString)& label) ;
-Purpose: Sets the life cycle stage of the product_definition_context associated with the current SDR
-<h5>Methods dealing with the product </h5>
- * STEPConstruct_Part::Product
-Handle_StepBasic_Product Product() const;
-Purpose: Returns the product associated with the current SDR
- * STEPConstruct_Part::Pid
-Handle_TCollection_HAsciiString Pid() const;
-Purpose: Returns ID of the product associated with the current SDR
- * STEPConstruct_Part::Pname
-Handle_TCollection_HAsciiString Pname() const;
-Purpose: Returns the name of the product associated with the current SDR
- * STEPConstruct_Part::Pdescription
-Handle_TCollection_HAsciiString Pdescription() const;
-Purpose: Returns the description of the product associated with the current SDR
- * STEPConstruct_Part::SetPid
-void SetPid(const Handle(TCollection_HAsciiString)& id) ;
-Purpose: Sets ID of the product associated with the current SDR
- * STEPConstruct_Part::SetPname
-void SetPname(const Handle(TCollection_HAsciiString)& label) ;
-Purpose: Sets the name of the product associated with the current SDR
- * STEPConstruct_Part::SetPdescription
-void SetPdescription(const Handle(TCollection_HAsciiString)& text) ;
-Purpose: Sets the description of the product associated with the current SDR
-<h5>Methods dealing with product_definition_formation </h5>
- * STEPConstruct_Part::PDF
-Handle_StepBasic_ProductDefinitionFormation PDF() const;
-Purpose: Returns the product_definition_formation associated with the current SDR
- * STEPConstruct_Part::PDFid
-Handle_TCollection_HAsciiString PDFid() const;
-Purpose: Returns the ID of the product_definition_formation associated with the current SDR
- * STEPConstruct_Part::PDFdescription
-Handle_TCollection_HAsciiString PDFdescription() const;
-Purpose: Returns the description of the product_definition_formation associated with the current SDR
- * STEPConstruct_Part::SetPDFid
-void SetPDFid(const Handle(TCollection_HAsciiString)& id) ;
-Purpose: Sets the ID of the product_definition_formation associated with the current SDR
- * STEPConstruct_Part::SetPDFdescription
-void SetPDFdescription(const Handle(TCollection_HAsciiString)& text) ;
-Purpose: Sets the description of the product_definition_formation associated with the current SDR
-<h5>Methods dealing with product_definition </h5>
- * STEPConstruct_Part::PD
-Handle_StepBasic_ProductDefinition PD() const;
-Purpose: Returns the product_definition associated with the current SDR
- * STEPConstruct_Part::PDdescription
-Handle_TCollection_HAsciiString PDdescription() const;
-Purpose: Returns the description of the product_definition associated with the current SDR
- * STEPConstruct_Part::SetPDdescription
-void SetPDdescription(const Handle(TCollection_HAsciiString)& text) ;
-Purpose: Sets the description of the product_definition associated with the current SDR
-<h5>Methods dealing with product_definition_shape </h5>
- * STEPConstruct_Part::PDS
-Handle_StepRepr_ProductDefinitionShape PDS() const;
-Purpose: Returns the product_definition_shape associated with the current SDR
- * STEPConstruct_Part::PDSname
-Handle_TCollection_HAsciiString PDSname() const;
-Purpose: Returns the name of the product_definition_shape associated with the current SDR
- * STEPConstruct_Part::PDSdescription
-Handle_TCollection_HAsciiString PDSdescription() const;
-Purpose: Returns the description of the product_definition_shape associated with the current SDR
- * STEPConstruct_Part::SetPDSname
-void SetPDSname(const Handle(TCollection_HAsciiString)& label) ;
-Purpose: Sets the name of the product_definition_shape associated with the current SDR
- * STEPConstruct_Part::SetPDSdescription
-void SetPDSdescription(const Handle(TCollection_HAsciiString)& text) ;
-Purpose: Sets the description of the product_definition_shape associated with the current SDR
-<h5>Methods dealing with product_related_product_category </h5>
- * STEPConstruct_Part::PRPC
-Handle_StepBasic_ProductRelatedProductCategory PRPC() const;
-Purpose: Returns the product_related_product_category associated with the current SDR
- * STEPConstruct_Part::PRPCname
-Handle_TCollection_HAsciiString PRPCname() const;
-Purpose: Returns the name of the product_related_product_category associated with the current SDR
- * STEPConstruct_Part::PRPCdescription
-Handle_TCollection_HAsciiString PRPCdescription() const;
-Purpose: Returns the description of the product_related_product_category associated with the current SDR
- * STEPConstruct_Part::SetPRPCname
-void SetPRPCname(const Handle(TCollection_HAsciiString)& label) ;
-Purpose: Sets the name of the product_related_product_category associated with the current SDR
- * STEPConstruct_Part::SetPRPCdescription
-void SetPRPCdescription(const Handle(TCollection_HAsciiString)& text) ;
-Purpose: Sets the description of the product_related_product_category associated with the current SDR
-@section occt_1624647986_383610185 Physical STEP file reading and writing
-The following paragraphs describe the loading of data from a physical STEP file into a STEP model and data writing from a STEP model to a STEP file.
-@subsection occt_1624647986_3836101851 Architecture of STEP Read and Write classes
-@subsubsection occt_1624647986_38361018511 General principles
+
+@section occt_step_4 Physical STEP file reading and writing
+
+@subsection occt_step_4_1 Architecture of STEP Read and Write classes
+@subsubsection occt_step_4_1_1 General principles
+
To perform data loading from a STEP file and to translate this data it is necessary to create correspondence between the EXPRESS schema and the structure of CDL classes. There are two possibilities to organize such correspondence: the so-called early binding and late binding.
-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.
+* 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.
-@subsubsection occt_1624647986_38361018512 Complex entities
+
+@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.
-@subsection occt_1624647986_3836101852 Physical file reading
+
+@subsection occt_step_4_2 Physical file reading
Physical file reading consists of the following steps:
- 1.Loading a STEP file and syntactic analysis of its contents
- 2.Mapping STEP entities to the array of strings
- 3.Creating empty OCCT objects representing STEP entities
- 4.Initializing OCCT objects
- 5.Building a references graph
-@subsubsection occt_1624647986_38361018521 Loading a STEP file and syntactic analysis of its contents
+ 1.Loading a STEP file and syntactic analysis of its contents
+ 2.Mapping STEP entities to the array of strings
+ 3.Creating empty OCCT objects representing STEP entities
+ 4.Initializing OCCT objects
+ 5.Building a references graph
+
+@subsubsection occt_step_4_2_1 Loading a STEP file and syntactic analysis of its contents
In the first phase, a STEP file is syntactically checked and loaded in memory as a sequence of strings.
-Syntactic check is performed on the basis of rules defined in step.lex and step.yacc files. Files step.lex and step.yacc are located in the StepFile nocdlpack development unit. These files describe text encoding of STEP data structure (for additional information see ISO 10303 Part 21). The step.lex file describes the lexical structure of the STEP file. It describes identifiers, numbers, delimiters, etc. The step.yacc file describes the syntactic structure of the file, such as entities, parameters, and headers.
+
+Syntactic check is performed on the basis of rules defined in *step.lex* and *step.yacc* files. Files *step.lex* and *step.yacc* are located in the StepFile nocdlpack development unit. These files describe text encoding of STEP data structure (for additional information see ISO 10303 Part 21). The *step.lex* file describes the lexical structure of the STEP file. It describes identifiers, numbers, delimiters, etc. The *step.yacc* file describes the syntactic structure of the file, such as entities, parameters, and headers.
+
These files have been created only once and need to be updated only when norm ISO 10303-21 is changed.
-@subsubsection occt_1624647986_38361018522 Mapping STEP entities to arrays of strings
+
+@subsubsection occt_step_4_2_2 Mapping STEP entities to arrays of strings
For each entity specified by its rank number the arrays storing its identifier, STEP type and parameters are filled.
-@subsubsection occt_1624647986_38361018523 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_1624647986_38361018524 Initializing Open CASCADE Technology objects
+@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.
-@subsubsection occt_1624647986_38361018525 Building a graph
+@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_1624647986_3836101853 How to add a new entity in scope of the STEP processor
+@subsection occt_step_4_3 How to add a new entity in scope of the STEP processor
If it is necessary to read and translate a new entity by the STEP processor the Reader and Actor scope should be enhanced. Note that some actions to be made for adding a new type are different for simple and complex types.
The following steps should be taken:
-1. Create a CDL class representing a new entity. This can be the Stepxxx_NewEntity class where xxx currently are the following:
- Basic
- Geom
- Shape
- Visual
- Repr
- AP214
- AP203
+* Create a CDL class representing a new entity. This can be *Stepxxx_NewEntity* class where xxx can be one of the following:
+ * Basic
+ * Geom
+ * Shape
+ * Visual
+ * Repr
+ * AP214
+ * AP203
Each field of a STEP entity should be represented by a corresponding field of this class. The class should have methods for initializing, setting and obtaining fields and it should also have the default constructor.
-2. Create the RWStepxxx_RWNewEntity class with a default constructor and methods ReadStep(), WriteStep() and if the entity references other entities, then method Share().
-3. Update file StepAP214_Protocol.cxx. In the constructor StepAP214_Protocol:: StepAP214_Protocol() add the new type to the map of registered types and associate the unique integer identifier with this type.
-4. Update file RWStepAP214_ReadWriteModule.cxx. The changes should be the following:
- For simple types:
- * Add a static object of class TCollection_AsciiString with name Reco_NewEntity and initialize it with a string containing the STEP type.
- * In constructor RWStepAP214_ReadWriteModule::RWStepAP214_ReadWriteModule() add this object onto the list with the unique integer identifier of the new entity type.
- * In function RWStepAP214_ReadWriteModule::StepType() add a new C++ case operator for this identifier.
- For complex types:
- * In the method RWStepAP214_ReadWriteModule::CaseStep() add a code for recognition the new entity type returning its unique integer identifier.
- * In the method RWStepAP214_ReadWriteModule::IsComplex() return True for this type.
- * In the method RWStepAP214_ReadWriteModule::ComplexType() fill the list of subtypes composing this complex type.
- For both simple and complex types:
- * In function RWStepAP214_ReadWriteModule::ReadStep() add a new C++ case operator for the new identifier and call the RWStepxxx_RWNewEntity class, method ReadStep to initialize the new class.
-5. Update file RWStepAP214_GeneralModule.cxx. Add new C++ case operators to functions NewVoid() and FillSharedCase(), and in the method CategoryNumber() add a line defining a category of the new type.
-6. Enhance the STEPControl_ActorRead class (methods Recognize() and Transfer()), or class(es) translating some entities, to translate the new entity into an OCCT shape.
-@subsection occt_1624647986_3836101854 Physical file writing
+* Create the *RWStepxxx_RWNewEntity* class with a default constructor and methods *ReadStep()*, *WriteStep()* and if the entity references other entities, then method *Share()*.
+* Update file *StepAP214_Protocol.cxx*. In the constructor *StepAP214_Protocol::StepAP214_Protocol()* add the new type to the map of registered types and associate the unique integer identifier with this type.
+* Update file *RWStepAP214_ReadWriteModule.cxx*. The changes should be the following:
+ * For simple types:
+ * Add a static object of class *TCollection_AsciiString* with name *Reco_NewEntity* and initialize it with a string containing the STEP type.
+ * In constructor *WStepAP214_ReadWriteModule::RWStepAP214_ReadWriteModule()* add this object onto the list with the unique integer identifier of the new entity type.
+ * In function *RWStepAP214_ReadWriteModule::StepType()* add a new C++ case operator for this identifier.
+ * For complex types:
+ * In the method *RWStepAP214_ReadWriteModule::CaseStep()* add a code for recognition the new entity type returning its unique integer identifier.
+ * In the method *RWStepAP214_ReadWriteModule::IsComplex()* return True for this type.
+ * In the method *RWStepAP214_ReadWriteModule::ComplexType()* fill the list of subtypes composing this complex type.
+ * For both simple and complex types:
+ * In function *RWStepAP214_ReadWriteModule::ReadStep()* add a new C++ case operator for the new identifier and call the *RWStepxxx_RWNewEntity* class, method *ReadStep* to initialize the new class.
+* Update file *RWStepAP214_GeneralModule.cxx*. Add new C++ case operators to functions *NewVoid()* and *FillSharedCase()*, and in the method *CategoryNumber()* add a line defining a category of the new type.
+* Enhance the *STEPControl_ActorRead class* (methods *Recognize()* and *Transfer()*), or class(es) translating some entities, to translate the new entity into an OCCT shape.
+
+@subsection occt_step_4_4 Physical file writing
Physical file writing consists of the following steps:
- 1.Building a references graph
- 2.Transferring data from a model to a sequence of strings
- 3.Writing the sequence of strings into the file
-@subsubsection occt_1624647986_38361018541 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.
-@subsubsection occt_1624647986_38361018542 Transferring data from the 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.
-@subsubsection occt_1624647986_38361018543 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.
-@subsection occt_1624647986_3836101855 How to add a new entity to write in the STEP file.
+ 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.
+ 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.
+
+
+@subsection occt_step_4_5 How to add a new entity to write in the STEP file.
+
If it is necessary to write and translate an OCCT shape into a new entity by the STEP processor the Writer and Actor scope should be enhanced.
-For a description of steps, which should be taken for adding a new entity type to the STEP processor, see the previous chapter ;Physical file reading;. Then, enhance the STEPControl_ActorWrite class i.e. methods Recognize() and Transfer(), or other classes from TopoDSToStep, to translate the OCCT shape into a new STEP entity.
-@section occt_1624647986_1896912212 Using DRAW
-@subsection occt_1624647986_18969122121 DRAW STEP Commands Overview
-TKXSDRAW toolkit provides commands for testing XSTEP interfaces interactively in the DRAW environment. It provides an additional set of DRAW commands specific for data exchange tasks, which allows loading and writing data files and an analysis of the resulting data structures and shapes.
+
+For a description of steps, which should be taken for adding a new entity type to the STEP processor, see <a href="#occt_step_4_2">Physical file reading</a>. Then, enhance the *STEPControl_ActorWrite* class i.e. methods *Recognize()* and *Transfer()*, or other classes from *TopoDSToStep*, to translate the OCCT shape into a new STEP entity.
+
+@section occt_step_6 Using DRAW
+@subsection occt_step_6_1 DRAW STEP Commands Overview
+*TKXSDRAW* toolkit provides commands for testing XSTEP interfaces interactively in the DRAW environment. It provides an additional set of DRAW commands specific for data exchange tasks, which allows loading and writing data files and an analysis of the resulting data structures and shapes.
+
This section is divided into five parts. Two of them deal with reading and writing a STEP file and are specific for the STEP processor. The first and the forth parts describe some general tools for setting parameters and analyzing the data. Most of them are independent of the norm being tested. Additionally, a table of mentioned DRAW commands is provided.
-In the description of commands, square brackets ([]) are used to indicate optional parameters. Parameters given in the angle brackets () and sharps (#) are to be substituted by an appropriate value. When several exclusive variants are possible, a vertical dash (|) is used.
-@subsection occt_1624647986_18969122122 Setting the interface parameters
+
+In the description of commands, square brackets ([]) are used to indicate optional parameters. Parameters given in the angle brackets (\<\>) and sharps (#) are to be substituted by an appropriate value. When several exclusive variants are possible, a vertical dash (|) is used.
+
+@subsection occt_step_6_2 Setting the interface parameters
A set of parameters for importing and exporting STEP data is defined in the XSTEP resource file. In XSDRAW, these parameters can be viewed or changed using the command
-Draw: param [parameter_name [value]]
-Command param with no arguments gives a list of all parameters with their values. When the argument parameter_name is specified, information about this parameter is printed (current value and short description).
+~~~~~
+Draw:> param [<parameter_name> [<value>]]
+~~~~~
+Command param with no arguments gives a list of all parameters with their values. When the argument *parameter_name* is specified, information about this parameter is printed (current value and short description).
+
The third argument is used to set a new value of the given parameter. The result of the setting is printed immediately.
+
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; and
-Draw: xtrace .
-- directs all messages to the standard output.
-@subsection occt_1624647986_18969122123 Reading a STEP file
-For a description of parameters used in reading a STEP file refer to 2.3.3
-For reading a STEP file, the following parameters are defined (see above, the command param):
+* *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
+
+For a description of parameters used in reading a STEP file refer to <a href="#occt_step_2_3_3">Setting the translation parameters</a> section.
+
+For reading a STEP file, the following parameters are defined (see above, <a href="#occt_step_6_2">the command *param*</a>):
+
+Description Name Values Meaning
+Precision for input entities read.precision.mode 0 or 1 If 0 (File), precision of the input STEP file will be used for the loaded shapes
+If 1 (Session), the following parameter will be used as the precision value
+ read.precision.val real Value of precision (used if the previous parameter is 1)
+Surface curves read.surfacecurve.mode 0 or 3 Defines a preferable way of representing surface curves (2d or 3d representation).
+If 0, no preference.
+Maximal tolerance read.maxprecision.mode 0 or 1 If 1, maximum tolerance is used as a rigid limit
+If 0, maximum tolerance is used as a limit but can be exceeded by some algorithms
+ read.maxprecision.val real Value of maximum precision
+
+
It is possible either only to load a STEP file into memory (i.e. fill the *InterfaceModel* with data from the file), or to read it (i.e. load and convert all entities to OCCT shapes).
Loading is done by the command
-Draw: xload file_name
+~~~~~
+Draw:> xload <file_name>
+~~~~~
Once the file is loaded, it is possible to investigate the structure of the loaded data. To find out how you do it, look in the beginning of the analysis subsection.
Reading a STEP file is done by the command
-Draw: stepread file_name result_shape_name [selection]
+~~~~~
+Draw:> stepread <file_name> <result_shape_name> [selection]
+~~~~~
Here a dot can be used instead of a filename if the file is already loaded by xload or stepread.
The optional selection (see below for a description of selections) specifies a set of entities to be translated. If an asterisk `*' is given, all transferable roots are translated. If a selection is not given, the user is prompted to define a scope of transfer interactively:
+
+N Mode Description
+0 End Finish transfer and exit stepread
+1 root with rank 1 Transfer first root
+2 root by its rank Transfer root specified by its rank
+3 One entity Transfer entity with a number provided by the user
+4 Selection Transfer only entities contained in selection
+
* root is an entity in the STEP file which is not referenced by another entities
Second parameter of the stepread command defines the name of the loaded shape.
+
During the STEP translation, a map of correspondence between STEP entities and OCCT shapes is created.
-To get information on the result of translation of a given STEP entity use the command
-Draw: tpent #
-is used.
-To create an OCCT shape, corresponding to a STEP entity, use the command
-Draw: tpdraw #
-is used.
-To get the number of a STEP entity, corresponding to an OCCT shape, use the command
-Draw: fromshape shape_name
-is used.
-To clear the map of correspondences between STEP entities and OCCT shapes the command
-Draw: tpclear
-is used.
-@subsection occt_1624647986_18969122124 Analyzing the data transferred
+
+To get information on the result of translation of a given STEP entity use the command *Draw:> tpent \#*.
+
+To create an OCCT shape, corresponding to a STEP entity, use the command *Draw:> tpdraw \#*.
+To get the number of a STEP entity, corresponding to an OCCT shape, use the command *Draw:> fromshape <shape_name>*.
+
+To clear the map of correspondences between STEP entities and OCCT shapes use the command *Draw:> tpclear*.
+
+@subsection occt_step_6_4 Analyzing the transferred data
The procedure of analysis of data import can be divided into two stages:
- 1.to check the file contents,
- 2.to estimate the translation results (conversion and validated ratios).
-@subsubsection occt_1624647986_189691221241 Checking file contents
+ 1.to check the file contents,
+ 2.to estimate the translation results (conversion and validated ratios).
+
+@subsubsection occt_step_6_4_1 Checking file contents
General statistics on the loaded data can be obtained by using the command
-Draw: data symbol
+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
+
There is a set of special objects, which can be used to operate with a loaded model. They can be of the following types:
-A list of these objects defined in the current session can be printed in DRAW by command
-Draw: listitems
-Command
-Draw: givelist selection_name
-prints a list of a subset of loaded entities defined by the selection argument:
+* 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 *Draw:> listitems*.
+Command *Draw:> givelist <selection_name>* prints a list of a subset of loaded entities defined by the selection argument:
-The command listtypes gives a list of entity types, which were encountered in the last loaded file (with a number of STEP entities of each type).
-The list cannot be shown for all entities but for a subset of them. This subset is defined by an optional selection argument (for the list of possible values for STEP, see the table above).
+* *xst-model-all* all entities of the model;
+* *xst-model-roots* all roots;
+* *xst-pointed* (Interactively) pointed entities (not used in DRAW);
+* *xst-transferrable-all* all transferable (recognized) entities;
+* *xst-transferrable-roots* Transferable roots.
+
+The command *listtypes* gives a list of entity types, which were encountered in the last loaded file (with a number of STEP entities of each type).
+
+The list cannot be shown for all entities but for a subset of them. This subset is defined by an optional selection argument (for the list of possible values for STEP, see the table above).
+
Two commands are used to calculate statistics on the entities in the model:
-Draw: count counter [selection]
-Draw: listcount counter [selection]
+~~~~~
+Draw:> count <counter> [<selection>]
+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:
-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. To get a label for an entity with a known number, command
-Draw: elab #
-can be used.
-In the same way, command
-Draw: enum #
-prints a number for the entity with a given label.
-The contents of a STEP entity can be obtained by command
-Draw: entity # level_of_information
-The list of entities referenced by a given entity and the list of entities referencing to it can be obtained by command
-Draw: estat #
-A STEP assembly can be printed as a tree using the following DRAW command:
-Draw: dumpassembly
-Information about product names, next_assembly_usage_occurence, shape_definition_representation, context_dependent_shape_representation or mapped_item entities that are involved into the assembly structure will be printed.
-@subsubsection occt_1624647986_189691221242 Estimating the results of reading STEP
+* *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.
+* *Draw:> enum \#* prints a number for the entity with a given label.
+* *Draw:> entity \# <level_of_information>* outputs the contents of a STEP entity.
+* *Draw: estat \#* outputs the list of entities referenced by a given entity and the list of entities referencing to it.
+* *Draw: dumpassembly* prints a STEP assembly as a tree.
+
+Information about product names, *next_assembly_usage_occurence, shape_definition_representation, context_dependent_shape_representation* or *mapped_item entities* that are involved into the assembly structure will be printed.
+
+@subsubsection occt_step_6_4_2 Estimating the results of reading STEP
All the following commands are available only after data is converted into OCCT shapes (i.e. after command 214read).
-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 symbol defines what information will be printed:
-The sign `*' before 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.
-Optional argument selection can limit the action of the command to the selection, not to all entities.
+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 symbol 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
+
+The sign \* before 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.
+
+Optional argument <selection> can limit the action of the command to the selection, not to all entities.
+
To get help, run this command without arguments.
-Example: The following command gives statistics on the result of translation of different types of entities (taking check messages into account) and calculates summary translation ratios.
-Draw: tpstat *l
-To get information on OCCT shape contents the command
-Draw: statshape shape_name
-is used.
-It outputs the number of each kind of shapes (vertex, edge, wire, etc.) in the shape and some geometrical data (number of C0 surfaces, curves, indirect surfaces, etc.).
+
+The command *Draw:> tpstat \*1* gives statistics on the result of translation of different types of entities (taking check messages into account) and calculates summary translation ratios.
+
+To get information on OCCT shape contents use command *Draw:> statshape <shape_name>* . It outputs the number of each kind of shapes (vertex, edge, wire, etc.) in the shape and some geometrical data (number of C0 surfaces, curves, indirect surfaces, etc.).
+
The number of faces is returned as a number of references. To obtain the number of single instances, the standard command (from TTOPOLOGY executable) nbshapes can be used.
-To analyze the internal validity of the shape, command
-Draw: checkbrep shape_name expurged_shape_name
-is used. It checks shape geometry and topology for different cases of inconsistency, like self-intersecting wires or wrong orientation of trimming contours. If an error is found, it copies bad parts of the shape with the names ;expurged_subshape_name _#; and generates an appropriate message. If possible this command also tries to find STEP entities the OCCT shape was produced from.
-expurged_shape_name will contain the original shape without invalid subshapes.
-To get information on tolerances of the shape the command
-Draw: tolerance shape_name [min [max] [symbol]]
-is used. It outputs maximum, average and minimum values of tolerances for each kind of subshapes having tolerances and for the whole shape in general.
+
+To analyze the internal validity of the shape, use command *Draw:> checkbrep <shape_name> <expurged_shape_name>*. It checks shape geometry and topology for different cases of inconsistency, like self-intersecting wires or wrong orientation of trimming contours. If an error is found, it copies bad parts of the shape with the names <i>expurged_subshape_name _\#</i> and generates an appropriate message. If possible this command also tries to find STEP entities the OCCT shape was produced from.
+
+<i><expurged_shape_name></i> will contain the original shape without invalid subshapes.
+To get information on tolerances of the shape use command <i>Draw:> tolerance <shape_name> [<min> [<max>] [<symbol>]] </i>. It outputs maximum, average and minimum values of tolerances for each kind of subshapes having tolerances and for the whole shape in general.
+
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.
-Symbol 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.
-@subsection occt_1624647986_18969122125 Writing a STEP file
-For writing shapes to a STEP file, the following parameters are defined (see above, the command param):
-Several shapes can be written in one file. To start writing a new file, enter command
-Draw: newmodel
-Actually, command newmodel will clear the InterfaceModel to empty it, and the next command will convert the specified shape to STEP entities and add them to the InterfaceModel:
-Draw: stepwrite mode shape_name [file_name]
+
+<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.
+
+@subsection occt_step_6_5 Writing a STEP file
+For writing shapes to a STEP file, the following parameters are defined (see above, <a href="#occt_step_6_2">the command *param*</a>):
+
+
+Description Name Values Meaning
+Uncertainty for resulting entities Write.precision.mode -1, 0, 1 or 2 If -1 the uncertainty value is set to the minimal tolerance of CASCADE subshapes.
+If 0 the uncertainty value is set to the average tolerance of CASCADE subshapes.
+If 1 the uncertainty value is set to the maximal tolerance of CASCADE subshapes.
+If 2 the uncertainty value is set to write.precision.val
+Value of uncertainty Write.precision.val real Value of uncertainty (used if previous parameter is 2)
+
+
+Several shapes can be written in one file. To start writing a new file, enter command *Draw:> newmodel*.
+Actually, command *newmodel* will clear the *InterfaceModel* to empty it, and the next command will convert the specified shape to STEP entities and add them to the *InterfaceModel*:
+~~~~~
+Draw:> stepwrite <mode> <shape_name> [<file_name>]
+~~~~~
The available modes are following:
- a - ;as is; mode
- m - manifold_solid_brep or brep_with_voids
- f - faceted_brep
- w - geometric_curve_set
- s - shell_based_surface_model
-For further information, see ;Performing the OCCT shape translation;.
+ * *a* - as is;
+ * *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:
+~~~~~
execution status : 1
Mode (0 end, 1 file) :
-It is necessary to call command
-newmodel
-in order to perform a new translation of the next OCCT shape.
-@subsection occt_1624647986_18969122126 Index of useful XSDRAW commands
+~~~~~
+It is necessary to call command *newmodel* to perform a new translation of the next OCCT shape.
+
+@section occt_step_7 Reading from and writing to XDE
+The *STEPCAFControl* package (TKXDESTEP toolkit) provides tools to read and write STEP files to and from XDE format (see XDE User’s Guide).
-@section occt_1624647986_241758891 Reading from and writing to XDE
-The STEPCAFControl package (TKXDESTEP toolkit) provides tools to read and write STEP files to and from XDE format (see XDE User’s Guide).
In addition to the translation of shapes implemented in basic translator, it provides the following:
- * STEP assemblies, read as OCCT compounds by basic translator, are translated to XDE assemblies
- * Names of products are translated and assigned to assembly components and instances in XDE
- * STEP external references are recognized and translated (if external documents are STEP files)
- * Colors, layers, materials and validation properties assigned to parts or subparts are translated
- * STEP dimensional tolerances are translated
-@subsection occt_1624647986_2417588911 Description of the process
-@subsubsection occt_1624647986_24175889111 Loading a STEP file
+ * STEP assemblies, read as OCCT compounds by basic translator, are translated to XDE assemblies;
+ * Names of products are translated and assigned to assembly components and instances in XDE;
+ * STEP external references are recognized and translated (if external documents are STEP files);
+ * Colors, layers, materials and validation properties assigned to parts or subparts are translated;
+ * STEP dimensional tolerances are translated.
+
+@subsection occt_step_7_1 Description of the process
+
+@subsubsection occt_step_7_1_1 Loading a STEP file
Before performing any other operation, you must load a STEP file with:
+~~~~~
STEPCAFControl_Reader reader(XSDRAW::Session(), Standard_False);
-IFSelect_ReturnStatus stat = reader.ReadFile(*filename.stp*);
+IFSelect_ReturnStatus stat = reader.ReadFile("filename.stp");
+~~~~~
Loading the file only memorizes the data, it does not translate it.
-@subsubsection occt_1624647986_24175889112 Checking the loaded STEP file
-This step is not obligatory. See a description of this step in paragraph 2.3.2.
-@subsubsection occt_1624647986_24175889113 Setting the parameters for translation to XDE
-See a description of this step in paragraph 2.3.3.
+
+@subsubsection occt_step_7_1_2 Checking the loaded STEP file
+This step is not obligatory. See a description of this step in section <a href="#occt_step_2_3_2">Checking the STEP file</a>.
+
+@subsubsection occt_step_7_1_3 Setting the parameters for translation to XDE
+See a description of this step in section <a href="#occt_step_2_3_3">Setting the translation parameters</a>.
+
In addition, the following parameters can be set for XDE translation of attributes:
* Parameter for transferring colors:
+~~~~~
reader.SetColorMode(mode);
// mode can be Standard_True or Standard_False
+~~~~~
* Parameter for transferring names:
+~~~~~
reader.SetNameMode(mode);
// mode can be Standard_True or Standard_False
-@subsubsection occt_1624647986_24175889114 Performing the translation of a STEP file to XDE
+~~~~~
+@subsubsection occt_step_7_1_4 Performing the translation of a STEP file to XDE
The following function performs a translation of the whole document:
+~~~~~
Standard_Boolean ok = reader.Transfer(doc);
-where ;doc; is a variable which contains a handle to the output document and should have a type Handle(TDocStd_Document).
-@subsubsection occt_1624647986_24175889115 Initializing the process of translation from XDE to STEP
+~~~~~
+where *doc* is a variable which contains a handle to the output document and should have a type *Handle(TDocStd_Document)*.
+@subsubsection occt_step_7_1_5 Initializing the process of translation from XDE to STEP
Here is how to initialize the process:
+~~~~~
STEPCAFControl_Writer aWriter(XSDRAW::Session(),Standard_False);
-@subsubsection occt_1624647986_24175889116 Setting the parameters for translation from XDE to STEP
+~~~~~
+@subsubsection occt_step_7_1_6 Setting the parameters for translation from XDE to STEP
+
The following parameters can be set for a translation of attributes to STEP:
* Parameter for transferring colors:
+~~~~~
aWriter.SetColorMode(mode);
// mode can be Standard_True or Standard_False
+~~~~~
* Parameter for transferring names:
+~~~~~
aWriter.SetNameMode(mode);
// mode can be Standard_True or Standard_False
-@subsubsection occt_1624647986_24175889117 Performing the translation of an XDE document to STEP
+~~~~~
+@subsubsection occt_step_7_1_7 Performing the translation of an XDE document to STEP
You can perform the translation of document by calling the function:
+~~~~~
IFSelect_ReturnStatus aRetSt = aWriter.Transfer(doc);
-where ;doc; is a variable, which contains a handle to the input document for transferring and should have a type Handle(TDocStd_Document).
-@subsubsection occt_1624647986_24175889118 Writing a STEP file
+~~~~~
+where *doc* is a variable, which contains a handle to the input document for transferring and should have a type *Handle(TDocStd_Document)*.
+
+@subsubsection occt_step_7_18 Writing a STEP file
Write a STEP file with:
-IFSelect_ReturnStatus statw = aWriter.WriteFile(;filename.stp;);
+~~~~~
+IFSelect_ReturnStatus statw = aWriter.WriteFile("filename.stp");
+~~~~~
or
+~~~~~
IFSelect_ReturnStatus statw = writer.WriteFile (S);
-where S is OStream
+~~~~~
+where *S* is *OStream*.
TObj Package {#user_guides__tobj}
==================
-@section occt_1746122829_591811643 Introduction
+@section occt_tobj_1 Introduction
This document describes the package TObj, which is an add-on
to the Open CASCADE Application Framework (OCAF).
+
This package provides a set of classes and auxiliary tools facilitating
the creation of object-oriented data models on top of low-level OCAF data structures.
This includes:
This document describes basic principles of logical and physical organization
of TObj-based data models and typical approaches to implementation of classes representing model objects.
-@subsection occt_1746122829_5918116431 Applicability
+@subsection occt_tobj_1_1 Applicability
The main purpose of the *TObj* data model is rapid development
of the object-oriented data models for applications, using the existing
functionality provided by OCAF (Undo/Redo and persistence)
without the necessity to re-develop such functionality from scratch.
+
As opposed to using bare OCAF (at the level of labels and attributes),
TObj facilitates dealing with higher level abstracts, which are closer
to the application domain. It works best when the application data are naturally
organized in hierarchical structures, and is especially useful for complex data
models with dependencies between objects belonging to different parts of the model.
+
It should be noted that *TObj* is efficient for representing data structures containing
a limited number of objects at each level of the data structure (typically less than 1000).
-A greater number of objects causes performance problems due to list-based organization of OCAF documents.
-Therefore, other methods of storage, such as arrays, are advisable for data models or their
-sub-parts containing a great number of uniform objects. However, these methods
+A greater number of objects causes performance problems due to list-based organization of OCAF documents. Therefore, other methods of storage, such as arrays, are advisable for data models or their sub-parts containing a great number of uniform objects. However, these methods
can be combined with the usage of *TObj* to represent the high-level structure of the model.
-@section occt_1746122829_361293797 *TObj* Model
+@section occt_tobj_2 *TObj* Model
-@subsection occt_1746122829_3612937971 *TObj* Model structure
+@subsection occt_tobj_2_1 *TObj* Model structure
In the *TObj* data model the data are separated from the interfaces that manage them.
-It should be emphasized that *TObj* package defines only the interfaces and the basic structure of the model and objects,
-while the actual contents and structure of the model of a particular application
-are defined by its specific classes inherited from *TObj* classes. The
-implementation can add its own features or even change the default behaviour
-and the data layout, though this is not recommended. Logically the *TObj* data model is represented as a tree of model
-objects, with upper-level objects typically being collections of other objects
-(called *partitions*, represented by the class *TObj_Partition*). The root object of the model
-is called the *Main partition* and is maintained by the model itself. This partition contains a list
-of sub-objects called its *children* each sub-object may contain its own children (according to its type), etc.
-
+It should be emphasized that *TObj* package defines only the interfaces and the basic structure of the model and objects, while the actual contents and structure of the model of a particular application are defined by its specific classes inherited from *TObj* classes. The implementation can add its own features or even change the default behaviour and the data layout, though this is not recommended.
-Picture 1 *TObj* Data Model
+Logically the *TObj* data model is represented as a tree of model objects, with upper-level objects typically being collections of other objects (called *partitions*, represented by the class *TObj_Partition*). The root object of the model is called the *Main partition* and is maintained by the model itself. This partition contains a list of sub-objects called its *children* each sub-object may contain its own children (according to its type), etc.
+
+@image html /user_guides/tobj/images/tobj_image003.png "TObj Data Model"
+@image latex /user_guides/tobj/images/tobj_image003.png "TObj Data Model"
As the *TObj* Data Model is based on OCAF (Open CASCADE Application Framework) technology,
it stores its data in the underlying OCAF document. The OCAF document consists of a tree of
Generally the structure of the OCAF tree of the *TObj* data
model corresponds to the logical structure of the model and can be presented as in the following picture:
-
+@image html /user_guides/tobj/images/tobj_image004.jpgb "TObj Data Model mapped on OCAF document"
+@image latex /user_guides/tobj/images/tobj_image004.jpg "TObj Data Model mapped on OCAF document"
-Picture 2 *TObj* Data Model mapped on OCAF document
All data of the model are stored in the root label (0:1) of the OCAF document.
-An attribute TObj_TModel is located in this root label. It
+An attribute *TObj_TModel* is located in this root label. It
stores the object of type *TObj_Model*. This object serves as a main interface tool
to access all data and functionalities of the data model.
models, not vice-versa. Provided that the correct order of loading and closing
of the models is ensured, the *TObj* classes will maintain references between the objects automatically.
-@subsection occt_1746122829_3612937972 Data Model basic features
+@subsection occt_tobj_2_2 Data Model basic features
The class *TObj_Model* describing the data model provides the following functionalities:
* Interface to check and update the model if necessary (method *Update*)
* Support of several data models in one application. For this feature use OCAF multi-transaction manager, unique names and GUIDs of the data model (methods *GetModelName*, *GetGUID*)
-@subsection occt_1746122829_3612937973 Model Persistence
+@subsection occt_tobj_2_3 Model Persistence
The persistent representation of any OCAF model is contained in an XML or a binary file,
which is defined by the format string returned by the method *GetFormat*.
The other available format is *XmlOcaf*. The class **TObj_Model** declares and provides a default
implementation of two virtual methods:
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+~~~~~{.cpp}
virtual Standard_Boolean Load (const char* theFile);
virtual Standard_Boolean SaveAs (const char* theFile);
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~
which retrieve and store the model from or
in the OCAF file. The descendants
should define the following protected method to support Load and Save operations:
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+~~~~~{.cpp}
virtual Standard_Boolean initNewModel (const Standard_Boolean IsNew);
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~
This method is called by *Load* after creation of a new model
or after its loading from the file; its purpose is to perform
To avoid memory leaks, the *TObj_Model* class destructor invokes *Close* method
which clears the OCAF document and removes all data from memory before the model is destroyed.
+
For XML and binary persistence of the *TObj* data model the corresponding drivers are implemented
in *BinLDrivers*, *BinMObj* and *XmlLDrivers*, *XmlMObj* packages.
These packages contain retrieval and storage drivers for the model, model objects and custom attributes
facilitate the storage of the data specific to the application.
In this case the schema should be extended using the standard OCAF mechanism.
-@subsection occt_1746122829_3612937974 Access to the objects in the model
+@subsection occt_tobj_2_4 Access to the objects in the model
All objects in the model are stored in the main partition and accessed by iterators.
To access all model objects use:
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+~~~~~{.cpp}
virtual Handle(TObj_ObjectIterator) GetObjects () const;
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~
This method returns a recursive iterator on all objects stored in the model.
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+~~~~~{.cpp}
virtual Handle(TObj_ObjectIterator) GetChildren () const;
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~
This method returns an iterator on child objects of the main partition.
Use the following method to get the main partition:
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+~~~~~{.cpp}
Handle(TObj_Partition) GetMainPartition() const;
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~
To receive the iterator on objects of a specific type *AType* use the following call:
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+~~~~~{.cpp}
GetMainPartition()->GetChildren(STANDARD_TYPE(AType) );
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~
The set of protected methods is provided for descendant classes to deal with partitions:
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
- virtual Handle(TObj_Partition) getPartition (const TDF_Label, const Standard_Boolean theHidden) const;
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~{.cpp}
+ virtual Handle(TObj_Partition) getPartition (const TDF_Label, const Standard_Boolean theHidden) const;
+~~~~~
This method returns (creating if necessary) a partition in the specified label of the document.
The partition can be created as hidden (*TObj_HiddenPartition* class).
in the sub-label of the specified label in the document
(the label of the main partition for the second method) and with the given name:
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
- virtual Handle(TObj_Partition) getPartition (const TDF_Label, const Standard_Integer theIndex, const TCollection_ExtendedString& theName, const Standard_Boolean theHidden) const;
- virtual Handle(TObj_Partition) getPartition (const Standard_Integer theIndex, const TCollection_ExtendedString& theName, const Standard_Boolean theHidden) const;
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~{.cpp}
+ virtual Handle(TObj_Partition) getPartition (const TDF_Label, const Standard_Integer theIndex, const TCollection_ExtendedString& theName, const Standard_Boolean theHidden) const;
+ virtual Handle(TObj_Partition) getPartition (const Standard_Integer theIndex, const TCollection_ExtendedString& theName, const Standard_Boolean theHidden) const;
+~~~~~
If the default object naming and the name register mechanism
is turned on, the object can be found in the model by its unique name:
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+~~~~~{.cpp}
Handle(TObj_Object) FindObject (const Handle(TCollection_HExtendedString)& theName, const Handle(TObj_TNameContainer)& theDictionary) const;
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~
-@subsection occt_1746122829_3612937975 Own model data
+@subsection occt_tobj_2_5 Own model data
The model object can store its own data in the Data label
of its main partition, however, there is no standard API for
in *TObj_Model* to avoid conflict of data labels used by this class
and its descendants, similarly to objects (see below).
-@subsection occt_1746122829_3612937976 Object naming
+@subsection occt_tobj_2_6 Object naming
The basic implementation of *TObj_Model* provides the default
naming mechanism: all objects must have unique names,
*AfterRetrieval* of the *TObj_Object* class and skip the registration of the object name.
Use the following methods for the naming mechanism:
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+~~~~~{.cpp}
Standard_Boolean IsRegisteredName (const Handle(TCollection_HExtendedString)& theName, const Handle(TObj_TNameContainer)& theDictionary ) const;
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~
Returns **True** if the object name is already registered in the indicated (or model) dictionary.
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+~~~~~{.cpp}
void RegisterName (const Handle(TCollection_HExtendedString)& theName, const TDF_Label& theLabel, const Handle(TObj_TNameContainer)& theDictionary ) const;
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~
Registers the object name with the indicated label where the object
is located in the OCAF document. Note that the default implementation
of the method *SetName* of the object registers the new name automatically
(if the name is not yet registered for any other object)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+~~~~~{.cpp}
void UnRegisterName (const Handle(TCollection_HExtendedString)& theName, const Handle(TObj_TNameContainer)& theDictionary ) const;
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~
Unregisters the name from the dictionary. Ther names of *TObj* model
objects are removed from the dictionary when the objects are deleted from the model.
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
+~~~~~{.cpp}
Handle(TObj_TNameContainer) GetDictionary() const;
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+~~~~~~
Returns a default instance of the model dictionary (located at the model root label).
The default implementation works only with one dictionary.
it is recommended to redefine the corresponding virtual method of TObj_Object
that returns the dictionary where names of objects should be registered.
-@subsection occt_1746122829_3612937977 API for transaction mechanism
+@subsection occt_tobj_2_7 API for transaction mechanism
Class *TObj_Model* provides the API for transaction mechanism (supported by OCAF):
Changes the modified status by force. For synchronization of transactions
within several *TObj_Model* documents use class *TDocStd_MultiTransactionManager*.
-@subsection occt_1746122829_3612937978 Model format and version
+@subsection occt_tobj_28 Model format and version
Class *TObj_Model* provides the descendant classes with a means to control
the format of the persistent file by choosing the schema used to store or retrieve operations.
low-level format of data files (such as the storage format of a specific OCAF attribute).
If the format of data files changes, a specific treatment on a case-by-case basis will be required.
-@subsection occt_1746122829_3612937979 Model update
+@subsection occt_tobj_2_9 Model update
The following methods are used for model update to ensure its consistency
with respect to the other models in case of cross-model dependencies:
of the indicated object after the retrieval of the model from file
(see data model - object relationship chapter for more details)
-@subsection occt_1746122829_36129379710 Model copying
+@subsection occt_tobj_2_10 Model copying
To copy the model between OCAF documents use the following methods:
Copies the references from the current model to the target model.
-@subsection occt_1746122829_36129379711 Messaging
+@subsection occt_tobj_2_11 Messaging
The messaging is organised using Open CASCADE Messenger from the package Message.
The messenger is stored as the field of the model instance
This file should be loaded at the start of the application
by call to the appropriate method of the class *Message_MsgFile*.
-@section occt_1746122829_87267338 Model object
+@section occt_tobj_3 Model object
Class *TObj_Object* provides basic interface and default implementation
of important features of *TObj* model objects. This implementation defines
basic approaches that are recommended for all descendants,
and provides tools to facilitate their usage.
-
-
-Picture 3 *TObj* objects hierarchy
+@image html /user_guides/tobj/images/tobj_image005.png "TObj objects hierarchy"
+@image latex /user_guides/tobj/images/tobj_image005.png "TObj objects hierarchy"
-@subsection occt_1746122829_872673381 Separation of data and interface
+@subsection occt_tobj_3_1 Separation of data and interface
In the *TObj* data model, the data are separated from the interfaces that manage them.
The data belonging to a model object are stored in its root label and sub-labels
in the form of standard OCAF attributes. This allows using standard OCAF mechanisms
for work with these data, and eases the implementation of the persistence mechanism.
+
The instance of the interface which serves as an API for managing object data
(e.g. represents the model object) is stored in the root label of the object,
and typically does not bring its own data. The interface classes are organized in a hierarchy
corresponding to the natural hierarchy of the model objects according to the application.
+
In the text below the term 'object' is used to denote either the instance
of the interface class or the object itself (both interface and data stored in OCAF).
+
The special type of attribute *TObj_TObject* is used for storing instances of objects interfaces
in the OCAF tree. *TObj_TObject* is a simple container for the object of type *TObj_Object*.
-All objects (interfaces) of the data model inherit this class.
+All objects (interfaces) of the data model inherit this class.
-
+@image html /user_guides/tobj/images/tobj_image006.png "*TObj* object stored on OCAF label"
+@image latex /user_guides/tobj/images/tobj_image006.png "*TObj* object stored on OCAF label"
-Picture 4 *TObj* object stored on OCAF label
-@subsection occt_1746122829_872673382 Basic features
+@subsection occt_tobj_3_2 Basic features
The *TObj_Object* class provides some basic features that can be inherited (or, if necessary, redefined) by the descendants:
* Supports references (and back references) to other objects in the same or in another model (methods *getReference*, *setReference*, *addReference*, *GetReferences*, *GetBackReferences*, *AddBackReference*, *RemoveBackReference*, *ReplaceReference*)
* Provides the ability to contain child objects, as it is actual for partition objects (methods *GetChildren*, *GetFatherObject*)
* Organizes its data in the OCAF structure by separating the sub-labels of the main label intended for various kinds of data and providing tools to organize these data (see <a href="../../../../Documents%20and%20Settings/TEMP/obj-inher">below</a>). The kinds of data stored separately are:
- * Child objects stored in the label returned by the method *GetChildLabel*
- * References to other objects stored in the label returned by the method* GetReferenceLabel*
- * Other data, both common to all objects and specific for each subtype of the model object, are stored in the label returned by the method *GetDataLabel*
+ * Child objects stored in the label returned by the method *GetChildLabel*
+ * References to other objects stored in the label returned by the method* GetReferenceLabel*
+ * Other data, both common to all objects and specific for each subtype of the model object, are stored in the label returned by the method *GetDataLabel*
* Provides unique names of all objects in the model (methods *GetDictionary*, *GetName*, *SetName*)
* Provides unified means to maintain persistence (implemented in descendants with the help of macros *DECLARE_TOBJOCAF_PERSISTENCE* and *IMPLEMENT_TOBJOCAF_PERSISTENCE*)
- * Allows an object to remove itself from the OCAF document and check the depending objects can be deleted according to the back references (method *Detach*)
+ * Allows an object to remove itself from the OCAF document and check the depending objects can be deleted according to the back references (method *Detach*)
* Implements methods for identification and versioning of objects
* Manages the object interaction with OCAF Undo/Redo mechanism (method *IsAlive*, *AfterRetrieval*, *BeforeStoring*)
* Allows make a clone (methods *Clone*, *CopyReferences*, *CopyChildren*, *copyData*)
static Standard_Boolean GetObj ( const TDF_Label& theLabel, Handle(TObj_Object)& theResObject, const Standard_Boolean isSuper = Standard_False );
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Returns **True** if the object has been found in the indicated label (or in the upper level label if isSuper is **True)**.
+Returns *True* if the object has been found in the indicated label (or in the upper level label if *isSuper* is *True*).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
Handle(TObj_Object) GetFatherObject ( const Handle(Standard_Type)& theType = NULL ) const;
Returns the father object of the indicated type
for the current object (the direct father object if the type is NULL).
-@subsection occt_1746122829_872673383 Data layout and inheritance
+@subsection occt_tobj_3_3 Data layout and inheritance
As far as the data objects are separated from the interfaces and stored in the OCAF tree,
the functionality to support inheritance is required. Each object has its own data
and references stored in the labels in the OCAF tree. All data are stored in the sub-tree
of the main object label. If it is necessary to inherit a class from the base class,
the descendant class should use different labels for data and references than its ancestor.
+
Therefore each *TObj* class can reserve the range of tags in each of
*Data*, *References*, and *Child* sub-labels.
The reserved range is declared by the enumeration defined
(theRank2-th sub-label of theRank1-th data label).
This is useful when the data to be stored are represented by multiple OCAF attributes
of the same type (e.g. sequences of homogeneous data or references).
+
The get/set methods allow easily accessing the data located in the specified data label
for the most widely used data types (*Standard_Real*, *Standard_Integer*, *TCollection_HExtendedString*,
*TColStd_HArray1OfReal*, *TColStd_HArray1OfInteger*, *TColStd_HArray1OfExtendedString*).
individually according to the type of object, *TObj_Object* provides methods
to manipulate (check, remove, iterate) the existing references in the uniform way, as described below.
-@subsection occt_1746122829_872673384 Persistence
+@subsection occt_tobj_3_4 Persistence
The persistence of the *TObj* Data Model is implemented with the help
of standard OCAF mechanisms (a schema defining necessary plugins, drivers, etc.).
This implies the possibility to store/retrieve all data that are stored
as standard OCAF attributes., The corresponding handlers are added
to the drivers for *TObj*-specific attributes.
+
The special tool is provided for classes inheriting from *TObj_Object*
to add the new types of persistence without regeneration of the OCAF schema.
The class *TObj_Persistence* provides basic means for that:
When the type is restored the handler dynamically recognizes the type
and creates the corresponding object using mechanisms provided by *TObj_Persistence*.
-@subsection occt_1746122829_872673385 Names of objects
+@subsection occt_tobj_35 Names of objects
-All *TObj* model objects have names by which the user can refer to the object.
+All *TObj* model objects have names by which the user can refer to the object.
Upon creation, each object receives a default name, constructed
from the prefix corresponding to the object type (more precisely, the prefix is defined
by the partition to which the object belongs), and the index of the object in the current partition.
This default implementation of *TObj* package works with a single instance of the name container (dictionary)
for name registration of objects and it is enough in most simple projects.
If necessary, it is easy to redefine a couple of object methods
-(for instance *GetDictionary*()) and to take care of construction and initialization of containers.
+(for instance *GetDictionary*()) and to take care of construction and initialization of containers.
+
This functionality is provided by the following methods:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
virtual Standard_Boolean SetName ( const Handle(TCollection_HExtendedString)& theName ) const;
- Standard_Boolean SetName ( const Handle(TCollection_HAsciiString)& theName ) const;
- Standard_Boolean SetName ( const Standard_CString theName ) const;
+ Standard_Boolean SetName ( const Handle(TCollection_HAsciiString)& theName ) const;
+ Standard_Boolean SetName ( const Standard_CString theName ) const;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Attributes a new name to the object and returns **True** if the name has been attributed successfully.
Returns False if the name has been already attributed to another object.
The last two methods are short-cuts to the first one.
-@subsection occt_1746122829_872673386 References between objects
+@subsection occt_tobj_36 References between objects
Class *TObj_Object* allows creating references to other objects in the model.
Such references describe relations among objects which are not adequately reflected
by the hierarchical objects structure in the model (parent-child relationship).
+
The references are stored internally using the attribute TObj_TReference.
This attribute is located in the sub-label of the referring object (called *master*)
and keeps reference to the main label of the referred object.
At the same time the referred object can maintain the back reference to the master object.
-
+@image html /user_guides/tobj/images/tobj_image007.png "Objects relationship"
+@image latex /user_guides/tobj/images/tobj_image007.png "Objects relationship"
+
-Picture 5 Objects relationship
The back references are stored not in the OCAF document but as a transient field
of the object; they are created when the model is restored from file,
and updated automatically when the references are manipulated.
The class *TObj_TReference* allows storing references between objects
from different *TObj* models, facilitating the construction of complex relations between objects.
+
The most used methods for work with references are:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
The argument theType restricts the types of master objects, or does not if it is NULL.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
- virtual void ReplaceReference ( const Handle(TObj_Object)& theOldObject, const Handle(TObj_Object)& theNewObject );
+ virtual void ReplaceReference ( const Handle(TObj_Object)& theOldObject, const Handle(TObj_Object)& theNewObject );
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Replaces the reference to theOldObject by the reference to *theNewObject*.
The handle theNewObject may be NULL to remove the reference.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
- virtual Standard_Boolean RelocateReferences ( const TDF_Label& theFromRoot, const TDF_Label& theToRoot, const Standard_Boolean theUpdateackRefs = Standard_True );
+ virtual Standard_Boolean RelocateReferences ( const TDF_Label& theFromRoot, const TDF_Label& theToRoot, const Standard_Boolean theUpdateackRefs = Standard_True );
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Replaces all references to a descendant label of *theFromRoot*
either the referred object will not be removed, or both the referred
and the master objects will be removed (depends on the deletion mode in the method **Detach**)
-@subsection occt_1746122829_872673387 Creation and deletion of objects
+@subsection occt_tobj_3_7 Creation and deletion of objects
It is recommended that all objects inheriting from *TObj_Object*
should implement the same approach to creation and deletion.
+
The object of the *TObj* data model cannot be created independently
of the model instance, as far as it stores the object data in OCAF data structures.
Therefore an object class cannot be created directly as its constructor is protected.
+
Instead, each object should provide a static method *Create*(), which accepts the model,
with the label, which stores the object and other type-dependent parameters
necessary for proper definition of the object. This method creates a new object with its data
(a set of OCAF attributes) in the specified label, and returns a handle to the object's interface.
+
The method *Detach*() is provided for deletion of objects from OCAF model.
Object data are deleted from the corresponding OCAF label; however,
the handle on object remains valid. The only operation available after object deletion
-is the method *IsAlive*() checking whether the object has been deleted or not,
+is the method *IsAlive*() checking whether the object has been deleted or not,
which returns False if the object has been deleted.
When the object is deleted from the data model, the method checks
Unlinks references from removed objects.
Returns **True** if the objects have been successfully deleted.
-@subsection occt_1746122829_872673388 Transformation and replication of object data
+@subsection occt_tobj_3_8 Transformation and replication of object data
-*TObj_Object* provides a number of special virtual methods to support replications of objects. These methods should be redefined by descendants when necessary.
+*TObj_Object* provides a number of special virtual methods to support replications of objects. These methods should be redefined by descendants when necessary.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
virtual Handle(TObj_Object) Clone (const TDF_Label& theTargetLabel, Handle(TDF_RelocationTable) theRelocTable = 0);
Copies the children of an object to the target child label.
-@subsection occt_1746122829_872673389 Object flags
+@subsection occt_tobj_3_9 Object flags
-Each instance of TObj_Object stores a set of bit flags,
+Each instance of *TObj_Object* stores a set of bit flags,
which facilitate the storage of auxiliary logical information assigned to the objects
-(object state). Several typical state flags are defined in the enumeration ObjectState:
+(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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The default implementation returns the flag **Visible**
-defined in the enumeration TypeFlags. This flag is used to define visibility
-of the object for the user browsing the model (see class TObj_HiddenPartition).
+defined in the enumeration *TypeFlags*. This flag is used to define visibility
+of the object for the user browsing the model (see class *TObj_HiddenPartition*).
Other flags can be added by the applications.
-@subsection occt_1746122829_8726733810 Partitions
+@subsection occt_tobj_310 Partitions
The special kind of objects defined by the class *TObj_Partition*
(and its descendant *TObj_HiddenPartition*) is provided for partitioning
of other objects. Each *TObj* model contains the main partition that is placed
in the same OCAF label as the model object, and serves as a root of the object's tree.
A hidden partition is a simple partition with a predefined hidden flag.
+
The main partition object methods:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
Allocates and returns a new label for creation of a new child object.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
- void SetNamePrefix ( const Handle(TCollection_HExtendedString)& thePrefix);
+ void SetNamePrefix ( const Handle(TCollection_HExtendedString)& thePrefix);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Defines the prefix for automatic generation of names of the newly created objects.
Sets the last reserved index.
-@section occt_1746122829_819520128 Auxiliary classes
+@section occt_tobj_4 Auxiliary classes
Apart from the model and the object, package *TObj* provides a set of auxiliary classes:
- * TObj_Application - defines OCAF application supporting existence and operation with *TObj* documents.
- * TObj_Assistant – class provides an interface to the static data to be used during save and load operations on models. In particular, in case of cross-model dependencies it allows passing information on the parent model to the OCAF loader to correctly resolve the references when loading a dependent model.
- * TObj_TReference - OCAF attribute describes the references between objects in the *TObj* model(s). This attribute stores the label of the referred model object, and provides transparent cross-model references. At runtime, these references are simple Handles; in persistence mode, the cross-model references are automatically detected and processed by the persistence mechanism of TObj_TReference attribute.
- * Other classes starting with TObj_T... - define OCAF attributes used to store TObj-specific classes and some types of data on OCAF labels.
- * Iterators – a set of classes implementing TObj_ObjectIterator interface, used for iterations on *TObj* objects:
- * TObj_ObjectIterator – a basic abstract class for other *TObj* iterators. Iterates on TObj_Object instances.
- * TObj_LabelIterator – iterates on object labels in the *TObj* model document
- * TObj_ModelIterator – iterates on all objects in the model. Works with sequences of other iterators.
- * TObj_OcafObjectIterator – Iterates on *TObj* data model objects. Can iterate on objects of a specific type.
- * TObj_ReferenceIterator – iterates on object references.
- * TObj_SequenceIterator – iterates on a sequence of *TObj* objects.
- * TObj_CheckModel - a tool that checks the internal consistency of the model. The basic implementation checks only the consistency of references between objects.
+ * *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:
-
+@image html /user_guides/tobj/images/tobj_image008.png "Hierarchy of iterators"
+@image latex /user_guides/tobj/images/tobj_image008.png "Hierarchy of iterators"
-Picture 6: Hierarchy of iterators
-@section occt_1746122829_579029274 Packaging
+@section occt_tobj_5 Packaging
The *TObj* sources are distributed in the following packages:
- * TObj - defines basic classes that implement *TObj* interfaces for OCAF-based modelers.
- * BinLDrivers, XmlLDrivers – binary and XML driver of *TObj* package
- * BinLPlugin, XmlLPlugin – 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* – 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
User Guides {#user_guides}
===========
-\subpage user_guides__foundation_classes "user_guides__foundation_classes"
+## Foundation Classes
+**short description**
-\subpage user_guides__modeling_data "user_guides__modeling_data"
+\subpage user_guides__foundation_classes
-\subpage user_guides__modeling_algos "user_guides__modeling_algos"
+## Modeling Data
+**short description**
-\subpage user_guides__visualization "user_guides__visualization"
+\subpage user_guides__modeling_data
-\subpage user_guides__iges "user_guides__iges"
-\subpage user_guides__step "user_guides__step"
-\subpage user_guides__xde "user_guides__xde"
+## Modeling Algorithms
+**short description**
-\subpage user_guides__ocaf "user_guides__ocaf"
-\subpage user_guides__tobj "user_guides__tobj"
+\subpage user_guides__modeling_algos
-\subpage user_guides__shape_healing "user_guides__shape_healing"
+## Visualization
+**short description**
-\subpage user_guides__test_harness "user_guides__test_harness"
+\subpage user_guides__visualization
-\subpage user_guides__wok "user_guides__wok"
+## IGES Support
+**short description**
+
+\subpage user_guides__iges
+
+## STEP processor
+**short description**
+
+\subpage user_guides__step
+
+## Extended Data Exchange (XDE)
+**short description**
+
+\subpage user_guides__xde
+
+## OCAF
+**short description**
+
+\subpage user_guides__ocaf
+
+## TObj Package
+**short description**
+
+\subpage user_guides__tobj
+
+## Shape Healing
+**short description**
+
+\subpage user_guides__shape_healing
+
+## Draw Test Harness
+**short description**
+
+\subpage user_guides__test_harness
\ No newline at end of file
This manual explains how to use Open CASCADE Technology Visualization. It provides basic documentation on setting up and using Visualization. For advanced information on Visualization and its applications, see our offerings on our web site
-(Training and E-Learning) at <a href="http://www.opencascade.org/support/training/">http://www.opencascade.org/support/training/</a>
+(Training and E-Learning) at <a href="http://www.opencascade.org/support/training/">http://www.opencascade.org/support/training/</a>
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
Figure 1 below presents a schematic overview of the relations between the key concepts and packages in visualization. AIS stands for both AIS and AIS2D packages. Naturally, *Geometry & Topology* is just an example of application data that can be handled by AIS, and application-specific interactive objects can deal with any kind of data.
-
+@image html /user_guides/visualization/images/visualization_image003.jpg
+@image latex /user_guides/visualization/images/visualization_image003.jpg
**Figure 1. Key concepts and packages in visualization**
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, *AIS: Application Interactive Services*.
* If the services provided do not satisfy your requirements - if for example, you need a selection filter on another type of entity - you should read chapter 2 *Fundamental Concepts*, chapter 3 *AIS: Application Interactive Services*, and possibly chapters 4 and 5 *3D Presentations *and *3D Resources*. You may want to begin with the chapter presenting AIS.
* If your display will be in 2D, you should read chapter 1 *Fundamental Concepts*, chapter 6 *2D Presentations* and chapter 7 *2D Resources*.
-@section occt_1621831385_1633708282 Fundamental Concepts
+@section occt_1621831385_1633708282 Fundamental Concepts
@subsection occt_1621831385_16337082821 Presentation
@subsubsection occt_1621831385_163370828211 Key difference in implementation of 2D and 3D visualization
Current implementation of 3D visualization services is based on OpenGL.
2D visualization packages use native window system API (Win32 GDI API on Windows, Xlib API on Unix and Linux).
-@subsubsection occt_1621831385_163370828212 Structure of the Presentation
+@subsubsection occt_1621831385_163370828212 Structure of the Presentation
Displaying an object on the screen involves three kinds of entity:
* a presentable object, the *AIS_InteractiveObject *
* an interactive context, the *AIS_InteractiveContext*.
<h4>The presentable object </h4>
-The purpose of a presentable object is to provide the graphical representation of an object in the form of Graphic2d or Graphic3d structure. On the first display request, it creates this structure by calling the appropriate algorithm and retaining this framework for further display.
+The purpose of a presentable object is to provide the graphical representation of an object in the form of Graphic2d or Graphic3d structure. On the first display request, it creates this structure by calling the appropriate algorithm and retaining this framework for further display.
Standard presentation algorithms are provided in the StdPrs and Prs3d packages. You can, however, write specific presentation algorithms of your own, provided that they create presentations made of structures from the Graphic2d or Graphic3d packages. You can also create several presentations of a single presentable object: one for each visualization mode supported by your application.
Each object to be presented individually must be presentable or associated with a presentable object.
The *Prs3d* package provides some generic presentation algorithms such as wireframe, shading and hidden line removal associated with a Drawer class which controls the attributes of the presentation to be created in terms of color, line type, thickness, and so on.
<h4>Graphic2d and Graphic3d </h4>
-The *Graphic2d* and *Graphic3d* packages provide resources to create 2D and 3D graphic structures (please refer to chapters on 3D Resources and 2D Resources for more information).
+The *Graphic2d* and *Graphic3d* packages provide resources to create 2D and 3D graphic structures (please refer to chapters on 3D Resources and 2D Resources for more information).
@subsubsection occt_1621831385_163370828213 A Basic Example: How to display a 3D object
<h4>Example </h4>
-Void Standard_Real dx = ...; //Parameters Void Standard_Real dy = ...; //to build a wedge Void Standard_Real dz = ...; Void Standard_Real ltx = ...;
+Void Standard_Real dx = ...; //Parameters Void Standard_Real dy = ...; //to build a wedge Void Standard_Real dz = ...; Void Standard_Real ltx = ...;
Handle(V3d_Viewer)aViewer = ...; Handle(AIS_InteractiveContext)aContext; aContext = new AIS_InteractiveContext(aViewer);
BRepPrimAPI_MakeWedge w(dx, dy, dz, ltx); TopoDS_Solid & = w.Solid(); Handle(AIS_Shape) anAis = new AIS_Shape(S); //creation of the presentable object aContext - Display(anAis); //Display the presentable object in the 3d viewer.
The shape is created using the *BRepPrimAPI_MakeWedge* command. An AIS_Shape is then created from the shape. When calling the *Display *command, the interactive context calls the Compute method of the presentable object to calculate the presentation data and transfer it to the viewer. See Figure 2 below.
-** **
+** **
+
+@image html /user_guides/visualization/images/visualization_image004.png
+@image latex /user_guides/visualization/images/visualization_image004.png
-
-
+@image html /user_guides/visualization/images/visualization_image005.png
+@image latex /user_guides/visualization/images/visualization_image005.png
**Figure 2. Processes involved in displaying a presentable shape**
@subsection occt_1621831385_16337082822 Selection
Objects that may be selected graphically, are displayed as sets of sensitive primitives, which provide sensitive zones in 2D graphic space. These zones are sorted according to their position on the screen when starting the selection process.
The position of the mouse is also associated with a sensitive zone. When moving within the window where objects are displayed, the areas touched by the zone of the mouse are analyzed. The owners of these areas are then highlighted or signaled by other means such as the name of the object highlighted in a list. That way, you are informed of the identity of the element detected.
-
+@image html /user_guides/visualization/images/visualization_image006.jpg
+@image latex /user_guides/visualization/images/visualization_image006.jpg
**Figure 3. A model **
-
+@image html /user_guides/visualization/images/visualization_image007.jpg
+@image latex /user_guides/visualization/images/visualization_image007.jpg
**Figure 4. Modeling faces with sensitive primitives **
-
+@image html /user_guides/visualization/images/visualization_image008.jpg
+@image latex /user_guides/visualization/images/visualization_image008.jpg
**Figure 5. In a dynamic selection, each sensitive polygon is represented by its bounding rectangle**
-
+@image html /user_guides/visualization/images/visualization_image009.jpg
+@image latex /user_guides/visualization/images/visualization_image009.jpg
Figure 6. Reference to the sensitive primitive, then to the owner
@subsubsection occt_1621831385_163370828222 The Sensitive Primitive
The sensitive line segment below proposes a bounding box to the selector. During selection, positions 1 and 2 of the mouse detect the box but after sorting, only position 2 retains the line segment as selected by the algorithm.
-
+@image html /user_guides/visualization/images/visualization_image010.jpg
+@image latex /user_guides/visualization/images/visualization_image010.jpg
**Figure 7. Example of sensitive primitives **
When the 2D box associated with the position of the mouse intersects the 2D box of a sensitive primitive, the owner of the sensitive primitive is called and its presentation is highlighted.
Dynamic selection causes objects in a view to be automatically highlighted as the mouse cursor moves over them. This allows the user to be certain that the picked object is the correct one. Dynamic Selection is based on the following two concepts:
* a Selectable Object (see *AIS_InteractiveObject*)
- * an Interactive Context
+ * an Interactive Context
<h4>Selectable Object </h4>
A selectable object presents a given number of selection modes which can be redefined, and which will be activated or deactivated in the selection manager’s selectors.
@subsubsection occt_1621831385_163370828224 Methodology
Several operations must be performed prior to using dynamic selection:
-**1. **Implement specific sensitive primitives if those defined in Select2D and Select3D are not sufficient. These primitives must inherit from *SensitiveEntity* from *SelectBasics* or from a suitable Select3D sensitive entity class when a projection from 3D to 2D is necessary.
-**2. **Define all the owner types, which will be used, and the classes of selectable objects, i.e. the number of possible selection modes for these objects and the calculation of the decomposition of the object into sensitive primitives of all the primitives describing this mode. It is possible to define only one default selection mode for a selectable object if this object is to be selectable in a unique way.
-**3. **Install the process, which provides the user with the identity of the owner of the detected entities in the selection loop.
+**1. **Implement specific sensitive primitives if those defined in Select2D and Select3D are not sufficient. These primitives must inherit from *SensitiveEntity* from *SelectBasics* or from a suitable Select3D sensitive entity class when a projection from 3D to 2D is necessary.
+**2. **Define all the owner types, which will be used, and the classes of selectable objects, i.e. the number of possible selection modes for these objects and the calculation of the decomposition of the object into sensitive primitives of all the primitives describing this mode. It is possible to define only one default selection mode for a selectable object if this object is to be selectable in a unique way.
+**3. **Install the process, which provides the user with the identity of the owner of the detected entities in the selection loop.
When all these steps have been carried out, follow the procedure below:
-**1. **Create an interactive context.
-**2. **Create the selectable objects and calculate their various possible selections.
-**3. **Load these selectable objects in the interactive context. The objects may be common to all the selectors, i.e. they will be seen by all the selectors in the selection manager, or local to one selector or more.
-**4. **Activate or deactivate the objects’ selection modes in the selector(s). When activating a selection mode in a selector for a given object, the manager sends the order to make the sensitive primitives in this selector selectable. If the primitives are to projected from 3D to 2D, the selector calls the specific method used to carry out this projection.
+**1. **Create an interactive context.
+**2. **Create the selectable objects and calculate their various possible selections.
+**3. **Load these selectable objects in the interactive context. The objects may be common to all the selectors, i.e. they will be seen by all the selectors in the selection manager, or local to one selector or more.
+**4. **Activate or deactivate the objects’ selection modes in the selector(s). When activating a selection mode in a selector for a given object, the manager sends the order to make the sensitive primitives in this selector selectable. If the primitives are to projected from 3D to 2D, the selector calls the specific method used to carry out this projection.
At this stage, the selection of selectable entities in the selectors is available.
The selection loop informs constantly the selectors with the position of the mouse and questions them about the detected entities.
You have to write the method, which calculates the four selections above, i.e. the sensitive primitives which are activated when the mode is.
You must define the class *Owner* specific to your application. This class will contain the reference to the house element it represents: wall, door or room. It inherits from *EntityOwner* from *SelectMgr*.
For example, let’s consider a house with the following representation:
-
+@image html /user_guides/visualization/images/visualization_image011.jpg
+@image latex /user_guides/visualization/images/visualization_image011.jpg
**Figure 8. Selection of the rooms of a house**
To build the selection, which corresponds to the mode *selection of the rooms* (selection 2 in the list of selection modes) use the following procedure:
Void House::ComputeSelection
(Const Handle(SelectMgr_Selection)& Sel,
- const Standard_Integer mode {
- switch(mode){ case 0: //Selection of the rooms { for(Standard_Integer i = 1; i = myNbRooms; i++) { //for every room, create an instance of the owner
- //along with the given room and its name. Handle(RoomOwner) aRoomOwner = new RoomOwner (Room(i), NameRoom(i)); //Room() returns a room and NameRoom() returns its name.
+ const Standard_Integer mode {
+ switch(mode){ case 0: //Selection of the rooms { for(Standard_Integer i = 1; i = myNbRooms; i++) { //for every room, create an instance of the owner
+ //along with the given room and its name. Handle(RoomOwner) aRoomOwner = new RoomOwner (Room(i), NameRoom(i)); //Room() returns a room and NameRoom() returns its name.
Handle(Select3d_SensitiveBox) aSensitiveBox;
aSensitiveBox = new Select3d_SensitiveBox
(aRoomOwner, Xmin, Ymin, Zmin, Xmax, Ymax, Zmax);
- Sel - Add(aSensitiveBox); } break; Case 1: ... //Selection of the doors } //Switch
+ Sel - Add(aSensitiveBox); } break; Case 1: ... //Selection of the doors } //Switch
) // ComputeSelection
-
+@image html /user_guides/visualization/images/visualization_image012.jpg
+@image latex /user_guides/visualization/images/visualization_image012.jpg
**Figure 9. Activated sensitive boxes corresponding to selection mode 0 (selection of the rooms)**
-
-
+@image html /user_guides/visualization/images/visualization_image013.jpg
+@image latex /user_guides/visualization/images/visualization_image013.jpg
+
+@image html /user_guides/visualization/images/visualization_image014.jpg
+@image latex /user_guides/visualization/images/visualization_image014.jpg
**Figure 11. Activated sensitive polygons corresponding to selection mode 1.**
**(selection of the doors)**
-
+@image html /user_guides/visualization/images/visualization_image015.jpg
+@image latex /user_guides/visualization/images/visualization_image015.jpg
**Figure 12. Sensitive rectangles in the selector during dynamic selection in view 2**
-@section occt_1621831385_810308609 AIS: Application Interactive Services
+@section occt_1621831385_810308609 AIS: Application Interactive Services
Application Interactive Services (**AIS**) offers a set of general services beyond those offered by basic Selection and Presentation packages such as **PrsMgr**, **SelectMgr** and **StdSelect**. These allow you to manage presentations and dynamic selection in a viewer simply and transparently. To use these services optimally, you should know various rules and conventions. Section I provides an overview of the important classes which you need to manipulate AIS well. Sections 2 and 3 explain in detail how to use them and how to implement them, as well as the rules and conventions to respect. The annexes offer various standard Interactive Objects in AIS, an example of an implementation of AIS and a reminder of how to manage presentation and selection.
@subsection occt_1621831385_8103086091 Overview
@subsubsection occt_1621831385_81030860913 Graphic Attributes Manager or *Drawer*
-
+@image html /user_guides/visualization/images/visualization_image016.jpg
+@image latex /user_guides/visualization/images/visualization_image016.jpg
An Interactive Object can have a certain number of graphic attributes specific to it (such as visualization mode, color and material) By the same token, the Interactive Context has a drawer which is valid by default for the objects it controls. When an interactive object is visualized, the required graphic attributes are first taken from its own Drawer if it has the ones required, or from the context drawer if it does not have them.
@subsubsection occt_1621831385_81030860914 Selection Filters
-
+@image html /user_guides/visualization/images/visualization_image017.jpg
+@image latex /user_guides/visualization/images/visualization_image017.jpg
An important need in selection is the filtering of entities, which you want to select. Consequently there are FILTER entities, which allow you to refine the dynamic detection context, which you want to put into effect. Some of these filters can be used at the Neutral Point, others only in an open local context. A user will be able to program his own filters and load them into the interactive context.
@subsection occt_1621831385_8103086092 Rules and Conventions Governing Interactive Objects
- An interactive object is a *virtual* entity, which can be presented and selected. It can also have its own visualization aspects such as color, material, and mode of visualization. In order to create and manipulate the interactive objects with ease, you must know the rules and conventions, which have been established. Several *virtual* functions must be implemented for these objects to have the behavior expected of them. A certain number of standard interactive objects, which respect the rules and conventions described below, have been implemented in AIS. The current list of them can be found in ANNEX I. The services that concern manipulation of presentations, selection and graphic attributes will be treated separately.
+ An interactive object is a *virtual* entity, which can be presented and selected. It can also have its own visualization aspects such as color, material, and mode of visualization. In order to create and manipulate the interactive objects with ease, you must know the rules and conventions, which have been established. Several *virtual* functions must be implemented for these objects to have the behavior expected of them. A certain number of standard interactive objects, which respect the rules and conventions described below, have been implemented in AIS. The current list of them can be found in ANNEX I. The services that concern manipulation of presentations, selection and graphic attributes will be treated separately.
@subsubsection occt_1621831385_81030860921 Presentations:
-
+@image html /user_guides/visualization/images/visualization_image018.jpg
+@image latex /user_guides/visualization/images/visualization_image018.jpg
*Conventions *
* Either in 2D or in 3D, an interactive object can have as many presentations as its creator wants to give it.
* 3D presentations are managed by PresentationManager3D; 2D presentations by PresentationManager2D. As this is transparent in AIS, the user does not have to worry about it.
void PackageName_ClassName::Compute
(const Handle(PrsMgr_PresentationManager2d)&
aPresentationManager,
- const Handle(Graphic2d_GraphicObject)& aGraphicObject,
- const Standard_Integer aMode = 0);
+ const Handle(Graphic2d_GraphicObject)& aGraphicObject,
+ const Standard_Integer aMode = 0);
* **For 3D: **
<h4>Example </h4>
void PackageName_ClassName::Compute
(const Handle(PrsMgr_PresentationManager3d)&
aPresentationManager,
- const Handle(Prs3d_Presentation)& aPresentation,
- const Standard_Integer aMode = 0);
+ const Handle(Prs3d_Presentation)& aPresentation,
+ const Standard_Integer aMode = 0);
* **For hidden line removal (HLR) mode in 3D (*): **
<h4>Example </h4>
void PackageName_ClassName::Compute
(const Handle(Prs3d_Projector)& aProjector,
- const Handle(Prs3d_Presentation)& aPresentation);
+ const Handle(Prs3d_Presentation)& aPresentation);
*WARNING (*) *
-As its call is automatically ordered by a view, this function requires explanation; the view has two states: degenerate mode (normal mode) and non-degenerate mode (Hidden line mode). When the latter is active, the view looks for all presentations displayed in normal mode, which have been signaled as accepting hidden line mode. An internal mechanism allows us to call the interactive object’s own *Compute*, that is, projector, function. How do you declare that such and such a presentation will accept an *equivalent* in hidden line mode? By convention, it is the Interactive Object, which accepts or rejects the representation of hidden-line mode. You can make this declaration in one of two ways, either initially by using one of the values of the enumeration PrsMgr_TypeOfPresentation:
+As its call is automatically ordered by a view, this function requires explanation; the view has two states: degenerate mode (normal mode) and non-degenerate mode (Hidden line mode). When the latter is active, the view looks for all presentations displayed in normal mode, which have been signaled as accepting hidden line mode. An internal mechanism allows us to call the interactive object’s own *Compute*, that is, projector, function. How do you declare that such and such a presentation will accept an *equivalent* in hidden line mode? By convention, it is the Interactive Object, which accepts or rejects the representation of hidden-line mode. You can make this declaration in one of two ways, either initially by using one of the values of the enumeration PrsMgr_TypeOfPresentation:
* PrsMgr_TOP_AllView,
* PrsMgr_TOP_ProjectorDependant
* AIS_InteractiveObject::Type
* AIS_InteractiveObject::Signature.
-
+
<h4>WARNING </h4>
Some signatures have already been used by *standard* objects delivered in AIS. (see the list of standard objects, Annex I.)
myPk_IShape::myPK_IShape
(const TopoDS_Shape& SH, PrsMgr_TypeOfPresentation aType):
-AIS_InteractiveObject(aType), myShape(SH), myDrwr(new AIS_Drawer()) {
+AIS_InteractiveObject(aType), myShape(SH), myDrwr(new AIS_Drawer()) {
SetHilightMode(0);
-}
+}
void myPk_IShape::Compute
-(const Handle(PrsMgr_PresentationManager3d) & PM, const Handle(Prs3d_Presentation)& P, const Standard_Integer TheMode)
+(const Handle(PrsMgr_PresentationManager3d) & PM, const Handle(Prs3d_Presentation)& P, const Standard_Integer TheMode)
{
switch (TheMode){
* In the *AIS_InteractiveObject* abstract class, several standard attributes have been privileged. These include: color, thickness of line, material, and transparency. Consequently, a certain number of virtual functions, which allow us to act on these attributes, have been proposed. Each new class of interactive object can redefine these functions in order to bring about the changes it should produce in the behavior of the class.
-
+@image html /user_guides/visualization/images/visualization_image019.jpg
+@image latex /user_guides/visualization/images/visualization_image019.jpg
**Figure 13. Redefinition of virtual functions for changes in AIS_Point **
-
+@image html /user_guides/visualization/images/visualization_image020.jpg
+@image latex /user_guides/visualization/images/visualization_image020.jpg
**Figure 14. **Redefinition** of virtual functions for changes in AIS_Shape.**
The virtual functions concerned here allow you to provide settings for:
* AIS_InteractiveObject::SetWidth
* AIS_InteractiveObject::UnsetWidth
* AIS_InteractiveObject::SetMaterial (const Graphic3d_NameOfPhysicalMaterial & aName)
- * AIS_InteractiveObject::SetMaterial (const Graphic3d_MaterialAspect & aMat)
+ * AIS_InteractiveObject::SetMaterial (const Graphic3d_MaterialAspect & aMat)
* AIS_InteractiveObject::UnsetMaterial
* AIS_InteractiveObject::SetTransparency
* AIS_InteractiveObject::UnsetTransparency
The following method allows you to set up the polygon offsets:
* void AIS_InteractiveObject::SetPolygonOffsets
(const Standard_Integer aMode,
- const Standard_Real aFactor,
- const Standard_Real aUnits)
+ const Standard_Real aFactor,
+ const Standard_Real aUnits)
The parameter aMode can contain various combinations of Aspect_PolygonOffsetMode enumeration elements. The enumeration has the following elements:
* Aspect_POM_None
* Aspect_POM_Off
* Aspect_POM_Point
* Aspect_POM_All
-The combination of these elements defines the polygon display modes that will use the given offsets. You can switch off the polygon offsets by passing the Aspect_POM_Off. Passing Aspect_POM_None allows you to change the aFactor and aUnits values without changing the mode. If aMode is different from Aspect_POM_Off, the aFactor and aUnits arguments are used by the graphics renderer to calculate the depth offset value:
+The combination of these elements defines the polygon display modes that will use the given offsets. You can switch off the polygon offsets by passing the Aspect_POM_Off. Passing Aspect_POM_None allows you to change the aFactor and aUnits values without changing the mode. If aMode is different from Aspect_POM_Off, the aFactor and aUnits arguments are used by the graphics renderer to calculate the depth offset value:
offset = aFactor * m + aUnits * r,
where m – maximum depth slope for the polygons currently being displayed, r – minimum depth resolution (implementation-specific)
You can use the following functions to obtain the current settings for polygon offsets:
* void AIS_InteractiveObject::PolygonOffsets
(Standard_Integer &aMode,
- Standard_Real &aFactor,
- Standard_Real &aUnits)
+ Standard_Real &aFactor,
+ Standard_Real &aUnits)
* Standard_Boolean
AIS_InteractiveObject::HasPolygonOffsets()
The same operation could be performed for the interactive object known by the AIS_InteractiveContext with the following methods:
* void AIS_InteractiveContext::SetPolygonOffsets
(const Handle(AIS_InteractiveObject) &anObj,
- const Standard_Integer aMode,
- const Standard_Real aFactor,
- const Standard_Real aUnits)
+ const Standard_Integer aMode,
+ const Standard_Real aFactor,
+ const Standard_Real aUnits)
* void AIS_InteractiveContext::PolygonOffsets
(const Handle(AIS_InteractiveObject) &anObj,
- Standard_Integer &aMode,
- Standard_Real &aFactor,
- Standard_Real &aUnits)
+ Standard_Integer &aMode,
+ Standard_Real &aFactor,
+ Standard_Real &aUnits)
* Standard_Boolean AIS_InteractiveContext::HasPolygonOffsets
(const Handle(AIS_InteractiveObject) &anObj)
@subsubsection occt_1621831385_810308609662 Groups of functions
You must distinguish two states in the Interactive Context:
-§ No Open Local Context; which will be referred to as Neutral Point.
-§ One or several open local contexts, each representing a temporary state of selection and presentation.
+* No Open Local Context; which will be referred to as Neutral Point.
+* One or several open local contexts, each representing a temporary state of selection and presentation.
Some functions can only be used in open Local Context; others in closed local context; others do not have the same behavior in one state as in the other.
* AIS_InteractiveContext::Display
(const Handle(AIS_InteractiveObject)& anIobj,
- const Standard_Boolean updateviewer=Standard_True);
+ const Standard_Boolean updateviewer=Standard_True);
* AIS_InteractiveContext::Display
(const Handle(AIS_InteractiveObject)& anIobj,
- const Standard_Integer amode,
- const Standard_Integer aSelectionMode,
- const Standard_Boolean
+ const Standard_Integer amode,
+ const Standard_Integer aSelectionMode,
+ const Standard_Boolean
updateviewer = Standard_True,
- const Standard_Boolean
+ const Standard_Boolean
allowdecomposition = Standard_True);
* AIS_InteractiveContext::Erase
* AIS_InteractiveContext::Activate
* AIS_InteractiveContext::Deactivate.
-
+
* AIS_InteractiveContext::AddFilter
to add a filter passed as an argument.
-
+
* AIS_InteractiveContext::RemoveFilter
to remove a filter passed as an argument.
Handle(StdSelect_FaceFilter) Fil1= new
StdSelect_FaceFilter(StdSelect_Revol);
Handle(StdSelect_FaceFilter) Fil2= new
- StdSelect_FaceFilter(StdSelect_Plane);
+ StdSelect_FaceFilter(StdSelect_Plane);
myContext-AddFilter(Fil1); myContext-AddFilter(Fil2); //only faces of revolution or planar faces will be selected
*
{
TopoDS_Shape ashape = myAISCtx-SelectedShape();
// to be able to use the picked shape
- }
+ }
else
{
Handle_AIS_InteractiveObject aniobj = myAISCtx-Interactive();
You can highlight and remove highlighting from a current object, and empty the list of current objects.
- * AIS_InteractiveContext::HilightCurrents
- * AIS_InteractiveContext::UnhilightCurrents
- * AIS_InteractiveContext::ClearCurrents
+ * AIS_InteractiveContext::HilightCurrents
+ * AIS_InteractiveContext::UnhilightCurrents
+ * AIS_InteractiveContext::ClearCurrents
When you are in open Local Context, you may be lead to keep *temporary* interactive objects. This is possible using the following functions:
AIS_InteractiveContext::DisplayedObjects
(const AIS_KindOfInteractive WhichKind,
- const Standard_Integer WhichSignature,
+ const Standard_Integer WhichSignature,
AIS_ListOfInteractive& aListOfIO) const;
At this stage, you only have to load the functions Load, Activate, and so on.
myIHMEditor::myIHMEditor
(const Handle(AIS_InteractiveContext)& Ctx,
- ....) :
- myCtx(Ctx),
+ ....) :
+ myCtx(Ctx),
...
{
//the filters
Handle(AIS_SignatureFilter) F1 = new
- AIS_SignatureFilter(AIS_KOI_Datum,AIS_SD_Point);
+ AIS_SignatureFilter(AIS_KOI_Datum,AIS_SD_Point);
//filter on the points
Handle(AIS_SignatureFilter) F2 = new
//filters on the axes.
Handle(StdSelect_FaceFilter) F3 = new
- StdSelect_FaceFilter(AIS_Cylinder);
+ StdSelect_FaceFilter(AIS_Cylinder);
//cylindrical face filters
//...
{ myCTX-MoveTo(xpix,ypix,vue); // the highlight of what is detected is automatic. }
Standard_Boolean myIHMEditor::Select() { // returns true if you should continue the selection
myCTX-Select(); myCTX-InitSelected(); if(myCTX-MoreSelected())
- { if(myCTX-HasSelectedShape())
+ { if(myCTX-HasSelectedShape())
{ const TopoDS_Shape& sh = myCTX-SelectedShape();
if( vertex){
if(myFirstV...)
// the filter on the AIS_Points
myFirstV = Standard_False;
return Standard_True;
- } else {
- mypoint2 =...;
+ } else {
+ mypoint2 =...;
// construction of the axis return Standard_False;
}
- }
- else
- {
+ }
+ else
+ {
//it is a cylindrical face : you recover the axis; visualize it; and stock it.
return Standard_False;
}
- }
+ }
// it is not a shape but is no doubt a point.
else
{
You can add/remove builders using the following methods:
* MeshVS_Mesh::AddBuilder
(const Handle (MeshVS_PrsBuilder) &Builder,
- Standard_Boolean TreatAsHilighter)
+ Standard_Boolean TreatAsHilighter)
* MeshVS_Mesh::RemoveBuilder (const Standard_Integer Index)
* MeshVS_Mesh::RemoveBuilderById
(const Standard_Integer Id)
**// use default presentation builder**
Handle (MeshVS_MeshPrsBuilder) aBuilder =
- new MeshVS_MeshPrsBuilder (aMesh);
+ new MeshVS_MeshPrsBuilder (aMesh);
aMesh-AddBuilder (aBuilder, Standard_True);
MeshVS_NodalColorPrsBuilder allows you to represent a mesh with a color scaled texture mapped on it. To do this you should define a color map for the color scale, pass this map to the presentation builder, and define an appropriate value in the range of 0.0 – 1.0 for every node.
**// assign nodal builder to the mesh**
Handle (MeshVS_NodalColorPrsBuilder) aBuilder =
- new MeshVS_NodalColorPrsBuilder
- (aMesh,MeshVS_DMF_NodalColorDataPrs | MeshVS_DMF_OCCMask);
+ new MeshVS_NodalColorPrsBuilder
+ (aMesh,MeshVS_DMF_NodalColorDataPrs | MeshVS_DMF_OCCMask);
aBuilder-UseTexture (Standard_True);
**// prepare color map**
**// assign color scale map values (0..1) to nodes**
TColStd_DataMapOfIntegerReal aScaleMap;
**…**
-** // iterate through the nodes and add an node id and an appropriate **
-** // value to the map**
- aScaleMap.Bind (anId, aValue);
-
+** // iterate through the nodes and add an node id and an appropriate **
+** // value to the map**
+ aScaleMap.Bind (anId, aValue);
+
**// pass color map and color scale values to the builder**
aBuilder-SetColorMap (aColorMap);
aBuilder-SetInvalidColor (Quantity_NOC_BLACK);
aBuilder-SetTextureCoords (aScaleMap);
aMesh-AddBuilder (aBuilder, Standard_True);
-@subsection occt_1621831385_810308609666 ANNEX II : Principles of Dynamic Selection
+@subsection occt_1621831385_810308609666 ANNEX II : Principles of Dynamic Selection
The idea of dynamic selection is to represent the entities, which you want to select by a bounding box in the actual 2D space of the selection view. The set of these zones is ordered by a powerful sorting algorithm. To then find the applicative entities actually detected at this position, all you have to do is read which rectangles are touched at mouse position (X,Y) of the view, and judiciously reject some of the entities which have provided these rectangles.
A set of standard sensitive primitives exists in Select3D packages for 3D primitives, and Select2D for 2D primitives.
The owner is the entity, which makes it possible to link the sensitive primitives and the objects that you really wanted to detect. It stocks the diverse information, which makes it possible to find objects. An owner has a priority (*5* by default), which you can modulate, so as to make one entity more selectable than another.
-
+@image html /user_guides/visualization/images/visualization_image021.jpg
+@image latex /user_guides/visualization/images/visualization_image021.jpg
@subsubsection occt_1621831385_81030860912341 Implementation in an interactive/selectable object
* mode 0: location of the whole box.
* mode 1: location of the edges on the box.
- For the first mode, all sensitive primitives will have the same owner, which will represent the interactive object. In the second case, we have to create an owner for each edge, and this owner will have to contain the index for the edge, which it represents. You will create a class of owner, which derives from *SelectMgr_EntityOwner*.
+ For the first mode, all sensitive primitives will have the same owner, which will represent the interactive object. In the second case, we have to create an owner for each edge, and this owner will have to contain the index for the edge, which it represents. You will create a class of owner, which derives from *SelectMgr_EntityOwner*.
The *ComputeSelection* function for the interactive box can have the following form:
void InteractiveBox::ComputeSelection
(const Handle(SelectMgr_Selection)& Sel,
- const Standard_Integer Mode)
+ const Standard_Integer Mode)
{
switch(Mode)
{ case 0: //locating the whole box by making its faces sensitive...
{
Handle(SelectMgr_EntityOwner) Ownr = new
- SelectMgr_EntityOwner(this,5);
+ SelectMgr_EntityOwner(this,5);
for(Standard_Integer I=1;I=Nbfaces;I++)
{
//Array is a TColgp_Array1OfPnt: which represents the array of vertices. Sensitivity is
Select3D_SensitiveFace(Ownr,Array,Sensitivity));
}
break;
- }
- case 1:
-// locates the edges { for(Standard_Integer i=1;i=12;i++)
+ }
+ case 1:
+// locates the edges { for(Standard_Integer i=1;i=12;i++)
{
// 1 owner per edge...
Handle(mypk_EdgeOwner) Ownr =
new mypk_EdgeOwner(this,i,6);
//6-priority
Sel-Add(new Select3D_SensitiveSegment
- (Ownr,firstpt(i),lastpt(i)));
+ (Ownr,firstpt(i),lastpt(i)));
}
break;
}
{
VS-Picked();
// picking of all owners detected
- }
+ }
SM-Deactivate(box1);
// deactivate all active modes of box1
-
+@image html /user_guides/visualization/images/visualization_image022.jpg
+@image latex /user_guides/visualization/images/visualization_image022.jpg
1st activation of the box’s mode 1: calculation of sensitive primitives + 3D/2D projection + sorting
deactivation of mode: only updated by sorting
rotation of the view: only projection + sorting of active primitives
-modification of the box - Recalculation of the active selection, recalculation flag on the inactive ones + 3D/2D projection + sorting
+modification of the box - Recalculation of the active selection, recalculation flag on the inactive ones + 3D/2D projection + sorting
@section occt_1621831385_1539918866 3D Presentations
@subsubsection occt_1621831385_153991886612 From V3d
-** **
+** **
@subsection occt_1621831385_15399188662 Creating a 3D scene
myViewer - SetLightOn ();
@subsubsection occt_1621831385_153991886623 Create a 3D view (a Windows example)
-It is assumed that a valid Windows window may already be accessed via the method GetSafeHwnd().
+It is assumed that a valid Windows window may already be accessed via the method GetSafeHwnd().
<h4>Example </h4>
Standard_Integer anIndex;
for (anIndex = 1; anIndex = aNbTria; nt++)
{
- aTriangles-AddVertex(anIndex * 5., 0., 0., 1., 1., 1.);
- aTriangles-AddVertex(anIndex * 5 + 5, 0., 0., 1., 1., 1.);
- aTriangles-AddVertex(anIndex * 5 + 2.5, 5., 0., 1., 1., 1.);
+ aTriangles-AddVertex(anIndex * 5., 0., 0., 1., 1., 1.);
+ aTriangles-AddVertex(anIndex * 5 + 5, 0., 0., 1., 1., 1.);
+ aTriangles-AddVertex(anIndex * 5 + 2.5, 5., 0., 1., 1., 1.);
}
TheGroup-BeginPrimitives ();
mygroup-AddPrimitiveArray(aTriangles);
Create text and markers in group TheGroup.
<h4>Example </h4>
-static char *texte[3] = { *Application title*,
+static char *texte[3] = { *Application title*,
*My company*,
*My company address.* };
Graphic3d_Array1OfVertex Tpts8 (0, 1);
Graphic3d_Vertex Marker (0.0, 0.0, 0.0);
for (i=0; i=2; i++) {
- Marker.SetCoord (-(Standard_Real)i*4 + 30,
- (Standard_Real)i*4,
- -(Standard_Real)i*4);
- TheGroup-Text (texte[i], Marker, 20.);
+ Marker.SetCoord (-(Standard_Real)i*4 + 30,
+ (Standard_Real)i*4,
+ -(Standard_Real)i*4);
+ TheGroup-Text (texte[i], Marker, 20.);
}
@section occt_1621831385_1435012457 3D Resources
* Graphic objects, groups, and structures.
@subsubsection occt_1621831385_143501245713 About the primitives
-** **
-** **Markers** **
+** **
+** **Markers** **
* Have one or more vertices,
* Have a type, a scale factor, and a color,
* Have a size, shape, and orientation independent of transformations.
**// get the graphic driver**
Handle (Aspect_GraphicDriver) aDriver =
- myAISContext-CurrentViewer()-Device()-GraphicDriver();
+ myAISContext-CurrentViewer()-Device()-GraphicDriver();
**// disable VBO support**
Handle (Graphic3d_GraphicDriver)::
- DownCast (aDriver)-EnableVBO (Standard_False);
+ DownCast (aDriver)-EnableVBO (Standard_False);
**Please note** that the use of Vertex Buffer Objects requires the application level primitive data provided by the Graphic3d_ArrayOfPrimitives to be transferred to the video memory. TKOpenGl transfers the data and releases the Graphic3d_ArrayOfPrimitives internal pointers to the primitive data. Thus it might be necessary to pay attention to such kind of behaviour, as the pointers could be modified (nullified) by the TKOpenGl.
* void Graphic3d_ArrayOfPrimitives::SetVertexNormal
* void Graphic3d_ArrayOfPrimitives::SetVertexTexel
* gp_Pnt Graphic3d_ArrayOfPrimitives::Verticie
- * gp_Dir Graphic3d_ArrayOfPrimitives::VertexNormal
+ * gp_Dir Graphic3d_ArrayOfPrimitives::VertexNormal
* gp_Pnt2d Graphic3d_ArrayOfPrimitives::VertexTexel
* Quantity_Color Graphic3d_ArrayOfPrimitives::VertexColor
* void Graphic3d_ArrayOfPrimitives::Verticie
**// create an array**
Handle (Graphic3d_ArrayOfPoints) anArray =
- new Graphic3d_ArrayOfPoints (aVerticiesMaxCount);
+ new Graphic3d_ArrayOfPoints (aVerticiesMaxCount);
**// add vertices to the array**
anArray-AddVertex (10.0, 10.0, 10.0);
aGroup-EndPrimitives ();
If the primitives share the same vertices (polygons, triangles, etc) then you can define them as indices of the vertices array. The following method allows you to define the primitives by the indices:
- * Standard_Integer Graphic3d_ArrayOfPrimitives::AddEdge
+ * Standard_Integer Graphic3d_ArrayOfPrimitives::AddEdge
This method adds an *edge* in the range [1, VertexNumber() ] in the array.
It is also possible to query the vertex defined by an edge:
**// create an array**
Standard_Boolean IsNormals = Standard_False;
-Standard_Boolean IsColors = Standard_False;
+Standard_Boolean IsColors = Standard_False;
Standard_Boolean IsTextureCrds = Standard_False;
Handle (Graphic3d_ArrayOfTriangles) anArray =
- new Graphic3d_ArrayOfTriangles (aVerticesMaxCount,
- aEdgesMaxCount,
- IsNormals,
- IsColors,
- IsTextureCrds);
+ new Graphic3d_ArrayOfTriangles (aVerticesMaxCount,
+ aEdgesMaxCount,
+ IsNormals,
+ IsColors,
+ IsTextureCrds);
**// add vertices to the array**
-anArray-AddVertex (-1.0, 0.0, 0.0); **// vertex 1**
-anArray-AddVertex ( 1.0, 0.0, 0.0); **// vertex 2**
-anArray-AddVertex ( 0.0, 1.0, 0.0); **// vertex 3**
-anArray-AddVertex ( 0.0,-1.0, 0.0); **// vertex 4**
+anArray-AddVertex (-1.0, 0.0, 0.0); **// vertex 1**
+anArray-AddVertex ( 1.0, 0.0, 0.0); **// vertex 2**
+anArray-AddVertex ( 0.0, 1.0, 0.0); **// vertex 3**
+anArray-AddVertex ( 0.0,-1.0, 0.0); **// vertex 4**
**// add edges to the array**
-anArray-AddEdge (1); **// first triangle**
+anArray-AddEdge (1); **// first triangle**
anArray-AddEdge (2);
anArray-AddEdge (3);
-anArray-AddEdge (1); **// second triangle**
+anArray-AddEdge (1); **// second triangle**
anArray-AddEdge (2);
anArray-AddEdge (4);
**// add the array to the structure**
Handle (Graphic3d_Group) aGroup =
- Prs3d_Root::CurrentGroup (aPrs);
+ Prs3d_Root::CurrentGroup (aPrs);
aGroup-BeginPrimitives ();
aGroup-AddPrimitiveArray (anArray);
aGroup-EndPrimitives ();
<h4>Example </h4>
**// create an array**
-Standard_Boolean IsNormals = Standard_False;
+Standard_Boolean IsNormals = Standard_False;
Standard_Boolean IsVertexColors = Standard_False;
-Standard_Boolean IsFaceColors = Standard_False;
-Standard_Boolean IsTextureCrds = Standard_False;
+Standard_Boolean IsFaceColors = Standard_False;
+Standard_Boolean IsTextureCrds = Standard_False;
Handle (Graphic3d_ArrayOfPolygons) anArray =
- new Graphic3d_ArrayOfPolygons (aVerticesMaxCount,
+ new Graphic3d_ArrayOfPolygons (aVerticesMaxCount,
aBoundsMaxCount,
aEdgesMaxCount,
IsNormals,
- IsVertexColors,
+ IsVertexColors,
IsFaceColors,
IsTextureCrds);
**// add bounds to the array, first polygon**
anArray-AddBound (3);
-anArray-AddVertex (-1.0, 0.0, 0.0);
-anArray-AddVertex ( 1.0, 0.0, 0.0);
-anArray-AddVertex ( 0.0, 1.0, 0.0);
+anArray-AddVertex (-1.0, 0.0, 0.0);
+anArray-AddVertex ( 1.0, 0.0, 0.0);
+anArray-AddVertex ( 0.0, 1.0, 0.0);
**// add bounds to the array, second polygon**
anArray-AddBound (4);
-anArray-AddVertex (-1.0, 0.0, 0.0);
-anArray-AddVertex ( 1.0, 0.0, 0.0);
-anArray-AddVertex ( 1.0,-1.0, 0.0);
-anArray-AddVertex (-1.0,-1.0, 0.0);
+anArray-AddVertex (-1.0, 0.0, 0.0);
+anArray-AddVertex ( 1.0, 0.0, 0.0);
+anArray-AddVertex ( 1.0,-1.0, 0.0);
+anArray-AddVertex (-1.0,-1.0, 0.0);
**// add the array to the structure **
Handle (Graphic3d_Group) aGroup =
- Prs3d_Root::CurrentGroup (aPrs);
+ Prs3d_Root::CurrentGroup (aPrs);
aGroup-BeginPrimitives ();
aGroup-AddPrimitiveArray (anArray);
aGroup-EndPrimitives ();
There are also several helper methods. You can get the type of the primitive array:
- * Graphic3d_TypeOfPrimitiveArray Graphic3d_ArrayOfPrimitives::Type
+ * Graphic3d_TypeOfPrimitiveArray Graphic3d_ArrayOfPrimitives::Type
* Standard_CString Graphic3d_ArrayOfPrimitives::StringType
and check if the primitive array provides normals, vertex colors, vertex texels (texture coordinates):
- * Standard_Boolean Graphic3d_ArrayOfPrimitives::HasVertexNormals
- * Standard_Boolean Graphic3d_ArrayOfPrimitives::HasVertexColors
- * Standard_Boolean Graphic3d_ArrayOfPrimitives::HasVertexTexels
+ * Standard_Boolean Graphic3d_ArrayOfPrimitives::HasVertexNormals
+ * Standard_Boolean Graphic3d_ArrayOfPrimitives::HasVertexColors
+ * Standard_Boolean Graphic3d_ArrayOfPrimitives::HasVertexTexels
or get the number of vertices, edges and bounds:
- * Standard_Integer Graphic3d_ArrayOfPrimitives::VertexNumber
- * Standard_Integer Graphic3d_ArrayOfPrimitives::EdgeNumber
- * Standard_Integer Graphic3d_ArrayOfPrimitives::BoundNumber
+ * Standard_Integer Graphic3d_ArrayOfPrimitives::VertexNumber
+ * Standard_Integer Graphic3d_ArrayOfPrimitives::EdgeNumber
+ * Standard_Integer Graphic3d_ArrayOfPrimitives::BoundNumber
@subsubsection occt_1621831385_143501245715 About materials
The text attributes for the group could be defined with the Graphic3d_AspectText3d attributes group.
To add any text to the graphic structure you can use the following methods:
- * void Graphic3d_Group::Text
+ * void Graphic3d_Group::Text
(const Standard_CString AText,
- const Graphic3d_Vertex& APoint,
- const Standard_Real AHeight,
- const Quantity_PlaneAngle AAngle,
- const Graphic3d_TextPath ATp,
- const Graphic3d_HorizontalTextAlignment AHta,
- const Graphic3d_VerticalTextAlignment AVta,
- const Standard_Boolean EvalMinMax),
+ const Graphic3d_Vertex& APoint,
+ const Standard_Real AHeight,
+ const Quantity_PlaneAngle AAngle,
+ const Graphic3d_TextPath ATp,
+ const Graphic3d_HorizontalTextAlignment AHta,
+ const Graphic3d_VerticalTextAlignment AVta,
+ const Standard_Boolean EvalMinMax),
AText parameter is the text string, APoint is the three-dimensional position of the text, AHeight is the text height, AAngle is the orientation of the text (at the moment, this parameter has no effect, but you can specify the text orientation through the Graphic3d_AspectText3d attributes).
ATp parameter defines the text path, AHta is the horizontal alignment of the text, AVta is the vertical alignment of the text.
You can pass Standard_False as EvalMinMax if you don’t want the graphic3d structure boundaries to be affected by the text position.
* void Graphic3d_Group::Text
(const Standard_CString AText,
- const Graphic3d_Vertex& APoint,
- const Standard_Real AHeight,
- const Standard_Boolean EvalMinMax)
+ const Graphic3d_Vertex& APoint,
+ const Standard_Real AHeight,
+ const Standard_Boolean EvalMinMax)
* void Graphic3d_Group::Text
(const TCcollection_ExtendedString &AText,
const Graphic3d_Vertex& APoint,
- const Standard_Real AHeight,
- const Quantity_PlaneAngle AAngle,
- const Graphic3d_TextPath ATp,
- const Graphic3d_HorizontalTextAlignment AHta,
- const Graphic3d_VerticalTextAlignment AVta,
- const Standard_Boolean EvalMinMax)
+ const Standard_Real AHeight,
+ const Quantity_PlaneAngle AAngle,
+ const Graphic3d_TextPath ATp,
+ const Graphic3d_HorizontalTextAlignment AHta,
+ const Graphic3d_VerticalTextAlignment AVta,
+ const Standard_Boolean EvalMinMax)
* void Graphic3d_Group::Text
(const TCcollection_ExtendedString &AText,
- const Graphic3d_Vertex& APoint,
- const Standard_Real AHeight,
- const Standard_Boolean EvalMinMax)
+ const Graphic3d_Vertex& APoint,
+ const Standard_Real AHeight,
+ const Standard_Boolean EvalMinMax)
<h4>Example </h4>
**// get the group**
Handle (Graphic3d_Group) aGroup =
- Prs3d_Root::CurrentGroup (aPrs);
+ Prs3d_Root::CurrentGroup (aPrs);
**// change the text aspect**
Handle(Graphic3d_AspectText3d) aTextAspect =
- new Graphic3d_AspectText3d ();
+ new Graphic3d_AspectText3d ();
aTextAspect-SetTextZoomable (Standard_True);
aTextAspect-SetTextAngle (45.0);
aGroup-SetPrimitivesAspect (aTextAspect);
new Xw_Window(GD,*Test V3d*,0.5,0.5,0.5,0.5) ;
**// Map this Window to this screen**
- W-Map() ;
+ W-Map() ;
**// Create a Perspective View in this Viewer**
Handle(V3d_PerspectiveView) V =
@subsubsection occt_1621831385_143501245725 Management of perspective projection
The perspective projection allows definition of viewing volume as a truncated pyramid (frustum) with apex at the Projection Reference Point. In the View Reference Coordinate system it can be presented by the following picture:
-
+@image html /user_guides/visualization/images/visualization_image023.png
+@image latex /user_guides/visualization/images/visualization_image023.png
+
+@image html /user_guides/visualization/images/visualization_image024.png
+@image latex /user_guides/visualization/images/visualization_image024.png
Figure 1 View Reference Coordinate System, perspective viewing volume and view mapping parameters
During panning, window limits are changed, as if a sort of *frame* through which the user sees a portion of the view plane was moved over the view. The perspective frustum itself remains unchanged.
As an alternative to manual setting of perspective parameters the *V3d_View::DepthFitAll* function can be used.
<h4>Example </h4>
-**// Display shape in Viewer VM**
+**// Display shape in Viewer VM**
Handle(AIS_InteractiveContext) aContext =
new AIS_InteractiveContext(VM);
aContext-Display(shape);
**// redefined method of V3d_LayerMgr**
void MyLayerMgr::Redraw ()
{
- Quantity_Color aRed (Quantity_NOC_RED);
- myOverlayLayer-SetColor (aRed);
- myOverlayLayer-DrawRectangle (0, 0, 100, 100);
+ Quantity_Color aRed (Quantity_NOC_RED);
+ myOverlayLayer-SetColor (aRed);
+ myOverlayLayer-DrawRectangle (0, 0, 100, 100);
}
The layer contains layer items that will be displayed on view redraw. Such items are the Visual3d_LayerItem entities. To manipulate Visual3d_LayerItem entities assigned to the layer’s internal list you can use the following methods:
* void Visual3d_Layer::AddLayerItem
(const Handle (Visual3d_LayerItem)& Item)
* void Visual3d_Layer::RemoveLayerItem
-(const Handle (Visual3d_LayerItem)& Item)
+(const Handle (Visual3d_LayerItem)& Item)
* void Visual3d_Layer::RemoveAllLayerItems ()
* const Visual3d_NListOfLayerItem&
-Visual3d_Layer::GetLayerItemList ()
+Visual3d_Layer::GetLayerItemList ()
The layer’s items are rendered when the following method is called by the graphical driver:
* void Visual3d_Layer::RenderLayerItems ()
**// tell V3d_ColorScale to draw itself**
void V3d_ColorScaleLayerItem::RedrawLayerPrs ()
{
- Visual3d_LayerItem::RedrawLayerPrs ()
- if (!MyColorScale.IsNull ())
- MyColorScale-DrawScale ();
+ Visual3d_LayerItem::RedrawLayerPrs ()
+ if (!MyColorScale.IsNull ())
+ MyColorScale-DrawScale ();
}
**// V3d_ColorScale has a reference to a LayerMgr**
void V3d_ColorScale::DrawScale ()
{
- **// calls *V3d_ColorScale::PaintRect, V3d_ColorScale::PaintText*, etc …**
+ **// calls *V3d_ColorScale::PaintRect, V3d_ColorScale::PaintText*, etc …**
}
**// PaintRect method uses overlay layer of LayerMgr to draw a rectangle **
void V3d_ColorScale::PaintRect
- (const Standard_Integer X, const Standard_Integer Y,
- const Standard_Integer W, const Standard_Integer H,
- const Quantity_Color aColor,
- const Standard_Boolean aFilled)
+ (const Standard_Integer X, const Standard_Integer Y,
+ const Standard_Integer W, const Standard_Integer H,
+ const Quantity_Color aColor,
+ const Standard_Boolean aFilled)
{
- const Handle (Visual3d_Layer)& theLayer =
+ const Handle (Visual3d_Layer)& theLayer =
myLayerMgr-Overlay ();
** …**
-** **theLayer-SetColor (aColor);
- theLayer-DrawRectangle (X, Y, W, H);
+** **theLayer-SetColor (aColor);
+ theLayer-DrawRectangle (X, Y, W, H);
** …**
}
To set solid color for the background you can use the following methods:
* void V3d_View::SetBackgroundColor
(const Quantity_TypeOfColor Type,
- const Quantity_Parameter V1,
- const Quantity_Parameter V2,
- const Quantity_Parameter V3)
+ const Quantity_Parameter V1,
+ const Quantity_Parameter V2,
+ const Quantity_Parameter V3)
This method allows you to specify the background color in RGB (red, green, blue) or HLS (hue, lightness, saturation) color spaces, so the appropriate values of the Type parameter are Quantity_TOC_RGB and Quantity_TOC_HLS. **Note** that the color value parameters V1,V2,V3 should be in the range between 0.0-1.0.
* void V3d_View::SetBackgroundColor
The gradient background style could be set up with the following methods:
* void V3d_View::SetBgGradientColors
(const Quantity_Color& Color1,
- const Quantity_Color& Color2,
- const Aspect_GradientFillMethod FillStyle,
- const Standard_Boolean update)
+ const Quantity_Color& Color2,
+ const Aspect_GradientFillMethod FillStyle,
+ const Standard_Boolean update)
* void V3d_View::SetBgGradientColors
(const Quantity_NameOfColor Color1,
- const Quantity_NameOfColor Color2,
- const Aspect_GradientFillMethod FillStyle,
- const Standard_Boolean update)
+ const Quantity_NameOfColor Color2,
+ const Aspect_GradientFillMethod FillStyle,
+ const Standard_Boolean update)
The Color1 and Color2 parameters define the boundary colors of interpolation, the FillStyle parameter defines the direction of interpolation. You can pass Standard_True as the last parameter to update the view.
The fill style can be also set with the following method:
To get the current background color you can use the following methods:
* void V3d_View::BackgroundColor
(const Quantity_TypeOfColor Type,
- Quantity_Parameter &V1,
- Quantity_Parameter &V2,
- Quantity_Parameter &V3)
+ Quantity_Parameter &V1,
+ Quantity_Parameter &V2,
+ Quantity_Parameter &V3)
* Quantity_Color V3d_View::BackgroundColor()
* void V3d_View::GradientBackgroundColors
(Quantity_Color& Color1,
- Quantity_Color& Color2)
+ Quantity_Color& Color2)
* Aspect_GradientBackground GradientBackground()
To set the image as a background and change the background image style you can use the following methods:
* void V3d_View::SetBackgroundImage
(const Standard_CString FileName,
- const Aspect_FillMethod FillStyle,
- const Standard_Boolean update)
+ const Aspect_FillMethod FillStyle,
+ const Standard_Boolean update)
* void V3d_View::SetBgImageStyle
(const Aspect_FillMethod FillStyle,
- const Standard_Boolean update)
+ const Standard_Boolean update)
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: draw the image in the default position
+ * Aspect_FM_NONE: draw the image in the default position
* Aspect_FM_CENTERED: draw the image at the center of the view
* Aspect_FM_TILED: tile the view with the image
* Aspect_FM_STRETCH: stretch the image over the view
The V3d_Plane class provides the services of clipping planes: it holds the plane equation coefficients and provides its graphical representation. To set and get plane equation coefficients you can use the following methods:
* void V3d_Plane::SetPlane
(const Quantity_Parameter A,
- const Quantity_Parameter B,
- const Quantity_Parameter C,
- const Quantity_Parameter D)
+ const Quantity_Parameter B,
+ const Quantity_Parameter C,
+ const Quantity_Parameter D)
* void V3d_Plane::Plane
(Quantity_Parameter& A,
- Quantity_Parameter& B,
- Quantity_Parameter& C,
- Quantity_Parameter& D)
+ Quantity_Parameter& B,
+ Quantity_Parameter& C,
+ Quantity_Parameter& D)
- V3d_Plane also provides display services:
+ V3d_Plane also provides display services:
* void V3d_Plane::Display
(const Handle(V3d_View)& aView,
- const Quantity_Color& aColor)
+ const Quantity_Color& aColor)
* void V3d_Plane::Erase ()
* Standard_Boolean V3d_Plane::IsDisplayed ()
The Display method could be redefined to provide custom representation of the clipping plane.
Handle(V3d_Plane) aCustomPlane;
myView-InitActivePlanes ();
if (myView-MoreActivePlanes ())
- aCustomPlane = myView-ActivePlane ();
+ aCustomPlane = myView-ActivePlane ();
else
- aCustomPlane = new V3d_Plane ();
+ aCustomPlane = new V3d_Plane ();
**// calculate new coefficients**
Standard_Real a, b, c, d;
The V3d_View has the following methods for dumping the 3D scene:
* Standard_Boolean V3d_View::Dump
(const Standard_CString theFile,
- const Image_TypeOfImage theBufferType)
+ const Image_TypeOfImage theBufferType)
* Standard_Boolean V3d_View::Dump
(const Standard_CString theFile,
- const Aspect_FormatOfSheetPaper theFormat,
- const Image_TypeOfImage theBufferType)
+ const Aspect_FormatOfSheetPaper theFormat,
+ const Image_TypeOfImage theBufferType)
These methods dump the 3D scene into an image file passed by its name and path as theFile.
The raster image data handling algorithm is based on the Image_PixMap class. The supported extensions are *.png*, *.bmp*, *.jpg*, *.png*.
The first method dumps the scene into an image file with the view dimensions. The second method allows you to make the dimensions of the output image compatible to a certain format of printing paper passed by theFormat argument.
* Handle_Image_PixMap V3d_View::ToPixMap
(const Standard_Integer theWidth,
- const Standard_Integer theHeight,
- const Image_TypeOfImage theBufferType,
- const Standard_Boolean theForceCentered)
+ const Standard_Integer theHeight,
+ const Image_TypeOfImage theBufferType,
+ const Standard_Boolean theForceCentered)
This method allows you to dump the displayed 3d scene into a pixmap with a width and height passed as theWidth and theHeight arguments.
The value passed as theBufferType argument defines the type of the buffer for a pixmap (RGB, RGBA, floating-point, RGBF, RGBAF).
The last parameter allows you to center the 3D scene on dumping.
**// create a graphic device**
Handle (WNT_GraphicDevice) aDevice =
- new Graphic3d_WNTGraphicDevice ();
+ new Graphic3d_WNTGraphicDevice ();
**// create a window**
-Standard_Integer aDefWidth = 800;
+Standard_Integer aDefWidth = 800;
Standard_Integer aDefHeight = 600;
Handle (WNT_WClass) aWClass =
- new WNT_WClass (*Virtual Class*,DefWindowProc,
+ new WNT_WClass (*Virtual Class*,DefWindowProc,
CS_VREDRAW | CS_HREDRAW, 0, 0,
::LoadCursor (NULL, IDC_ARROW));
Handle (WNT_Window) aWindow =
- new WNT_Window (aDevice, *VirtualWnd*, aWClass,
+ new WNT_Window (aDevice, *VirtualWnd*, aWClass,
WS_OVERLAPPEDWINDOW, 0, 0,
aDefWidth, aDefHeight);
The following method prints the view contents:
* void V3d_View::Print
(const Aspect_Handle hPrnDC,
- const Standard_Boolean showDialog,
- const Standard_Boolean showBackground,
- const Standard_CString filename,
- const Aspect_PrintAlgo printAlgorithm)
+ const Standard_Boolean showDialog,
+ const Standard_Boolean showBackground,
+ const Standard_CString filename,
+ const Aspect_PrintAlgo printAlgorithm)
The hPrnDC is the printer device handle. You can pass your own printer handle or *NULL* to select the printer by the default dialog. In that case you can use the default dialog or pass *Standard_False* as the showDialog argument to select the default printer automatically.
You can define the filename for the printer driver if you want to print out the result into a file.
If you do not want to print the background, you can pass *Standard_False* as the showBackground argument.
The following method of Visual3d_View class allows you to export your 3D scene:
* void Visual3d_View::Export
(const Standard_CString FileName,
- const Graphic3d_ExportFormat Format,
- const Graphic3d_SortType aSortType,
- const Standard_Real Precision,
- const Standard_Address ProgressBarFunc,
- const Standard_Address ProgressObject)
+ const Graphic3d_ExportFormat Format,
+ const Graphic3d_SortType aSortType,
+ const Standard_Real Precision,
+ const Standard_Address ProgressBarFunc,
+ const Standard_Address ProgressObject)
The FileName defines the output image file name and the Format argument defines the output file format:
* Graphic3d_EF_PostScript (PS),
* Graphic3d_EF_EhnPostScript (EPS),
The marker map defines a set of markers available to the application. Markers may be predefined, Aspect_Tom_X for example, or user-defined.
-
+@image html /user_guides/visualization/images/visualization_image025.jpg
+@image latex /user_guides/visualization/images/visualization_image025.jpg
Figure 15. Markers.
The markers are manipulated by an index.
Maps are created for color, line type, line width, and text font. A map is used to reference a given attribute by an integer value.
-
+@image html /user_guides/visualization/images/visualization_image026.jpg
+@image latex /user_guides/visualization/images/visualization_image026.jpg
Figure 16. Attributes
The color map
@subsubsection occt_1621831385_109097682126 Creating the presentable object
Follow the procedure below to compute the presentable object.
-**1. **Build a presentable object inheriting from AIS_InteractiveObject (refer to Chapter 1 Fundamental Concepts, Section Presentable objects)
-**2. **Re-use the graphic object provided as an argument of the Compute method for your presentable object.
+**1. **Build a presentable object inheriting from AIS_InteractiveObject (refer to Chapter 1 Fundamental Concepts, Section Presentable objects)
+**2. **Re-use the graphic object provided as an argument of the Compute method for your presentable object.
<h4>Example </h4>
void
rectangle-SetTypeOfPolygonFilling(Graphic2d_TOPF_FILLED); rectangle-SetDrawEdge(Standard_True);
*A given primitive can only be assigned to a single graphic object.*
-
+@image html /user_guides/visualization/images/visualization_image027.jpg
+@image latex/user_guides/visualization/images/visualization_image027.jpg
Figure 17. Graphic object and view mapping in the space model.
@subsection occt_1621831385_10909768213 Dealing with images
(aGrObj, 0.03, -0.03, 0.01, 0.0, 0.01);
window-Clear ();
-
+@image html /user_guides/visualization/images/visualization_image028.jpg
+@image latex /user_guides/visualization/images/visualization_image028.jpg
Figure 18. Figure of zoom and attachment point of a marker.
A **buffer** is used to draw very quickly a partial area of the scene without deleting the background context.
A buffer contains a set of graphic objects or primitives which are to be moved, rotated or scaled above the scene in the front planes of the view (in this case, double-buffering is not active). For example:
-**1. **Draw a very complex scene in the view.
-**2. **Create a buffer of primitives with the primitive color index 10 and the font index 4:
+**1. **Draw a very complex scene in the view.
+**2. **Create a buffer of primitives with the primitive color index 10 and the font index 4:
buffer = new Graphic2d_Buffer (view, 0., 0., 10, 4);
-**3. **Add graphic objects or primitives:
+**3. **Add graphic objects or primitives:
buffer-Add (go);
buffer-Add (tcircle[1]);
buffer-Add (t1);
-**4. **Post the buffer in the view:
+**4. **Post the buffer in the view:
buffer-Post ();
-**5. **Move, rotate or scale the buffer above the view:
+**5. **Move, rotate or scale the buffer above the view:
buffer-Move (x,y); buffer-Rotate (alpha);
buffer-Scale (zoom_factor);
-**6. **Unpost the buffer from the view:
+**6. **Unpost the buffer from the view:
buffer-Unpost ();
@section occt_1621831385_86393950 2D Resources
-The 2D resources include the Graphic2d, Image, AlienImage, and V2d packages.
+The 2D resources include the Graphic2d, Image, AlienImage, and V2d packages.
@subsection occt_1621831385_863939501 Graphic2d
* Zoom, rotating, translating, simple and refining transformations.
* Set position and size.
* Transpose, shift, clip, shift, clear.
- * * Draw line and rectangle.
+ * * Draw line and rectangle.
**PixMap **provides support for system-independent bitmaps:
* Supports different kinds of raster images, such as 24-bit, 32-bit, 96-bit, 128-bit, or RGB, RGBA, floating-point RGB and RGBA.
* Provides direct access to the pixel buffer.
* Provides image dump services. The use of FreeImage library enhances these services with the capability of saving raster images into different image file formats. **Note** that without FreeImage library support, the raster images could be dumped into the PPM format only.
* PixMaps could be used for handling system bitmaps and dumping window contents.
-
+
**Convertor** is used to:
* Change an image from a ColorImage to a PseudoColorImage. Select between two dithering algorithms for the change.
* Change an image from a PseudoColorImage to a ColorImage.
+++ /dev/null
-Workshop Organisation Toolkit {#user_guides__wok}
-==============================
-
-@section occt_wok_1_ Introduction Glossary
-
-@subsection occt_wok_1_1 About the Development Environment
-
-Open CASCADE Technology (**OCCT**) development environment is able to accommodate large numbers of developers working on a variety of products. Within this environment developers can produce multiple versions of products for various hardware and software platforms, including versions corresponding to particular marketing requirements. At the same time, OCCT development environment enables the maximum possible reuse of software components. In other words, OCCT development environment is designed to facilitate industrial scale development.
-@subsection occt_wok_1_2 Brief Overview of Open CASCADE Technology Development Environment
-The following diagram shows OPEN CASCADE tools and resources, the development method, and the architecture of applications that you can develop with Open CASCADE Technology.
-
-
-
-The application developer goes about creating his application by editing his source code and producing the final application using a set of intelligent construction tools. These tools are available within a structured development environment called the **software factory**.
-The developer defines new software components in CDL, Component Description Language, and uses a CDL compiler to derive their C++ implementations. These components are then compiled into packages.
-@subsection occt_wok_1_3 WOK Components
-@subsubsection occt_wok_1_3_1 Entities
-The WOK environment is made up of entities, for example software factories and development units. A full list of WOK entities is provided in the *Glossary* section.
-@subsubsection occt_wok_1_3_2 Files
-WOK manages two different types of files: user source files and WOK administration files. To support this, each entity has a home directory, which contains its administration directory. This is called *adm *and stores the administration files that WOK needs. In addition development units have a source directory called *src *which contains both .cdl and .cxx source files, and a header file directory called *inc *which contains .hxx files.
-@subsection occt_wok_1_4 Glossary
-@subsubsection occt_wok_1_4_1 Development Units
-A **development unit** is the smallest unit that can be subject to basic development operations such as modifying, compiling, linking and building.
-The following list contains all types of development units. The letter in parentheses indicates the letter key by commands such as ucreate and umake. In the rest of the manual, this letter key is referred to as the *short key*.
-* package (p) A set of related classes and methods along with their CDL definitions.
-* schema (s) A set of persistent data types.
-* executable (x) An executable is used for unit and integration test purposes. It is based on one or more packages.
-* nocdlpack (n) A package without a CDL definition. Used for low-level programming or for incorporating foreign resources.
-* interface (i) A specific set of services available for wrapping (an interface contains packages, classes, and methods).
-* jni (j) A development unit used to wrap C++ classes to Java. It is based on one or more interfaces.
-* toolkit (t) A set of packages. Useful in grouping packages together when there is a large number of packages based around a particular subject.
-* delivery (d) A development unit for publishing development units.
-* resource (r) A development unit containing miscellaneous files.
-
-@subsubsection occt_wok_1_4_2 Workbenches
-A workbench is a specialized directory structure where the user creates, modifies, and uses development units. A workbench is likely to be the personal property of one user or at most a small team of developers.
-
-
-@subsubsection occt_wok_1_4_3 Workshops
-A workshop is a tree of workbenches. It provides the development team with an independent workspace inside which the complete cycle of software production can be carried out.
-The root workbench is in a valid state and contains the working versions of the development units.
-Development units in a root workbench are visible in its child workbenches.
-
-For example, the schema below shows a workshop containing three workbenches. Workbenches B and C are the children of workbench A. Development units in A are visible in both B and C
-
-
-Workshops are fully independent of each other. They are organized in such a way that development units can be grouped into a delivery and placed in a warehouse. Communication between workshops is carried out by means of these deliveries. A warehouse belongs to a factory and is visible from all workshops in that factory. In this way, development units can be shared between a group of development teams.
-
-
-
-@subsubsection occt_wok_1_4_4 Factories
-A factory is a set of workshops and their corresponding warehouse. There is a single warehouse in any factory. The continuous upgrading and improvement of a product is carried out in a specific factory.
-To create a new version of an application within the factory, you establish a new workshop dedicated to creation and support of the new version.
-
-
-@section occt_wok_2_ Elements of the Platform
-@subsection occt_wok_2_1 Development Units
-A **development unit** is the basic element of WOK development. It includes the following three entities:
- * A directory structure (a minor component)
- * Source files, also called primary files
- * The result of the build process (compilation, etc.), also called derived files.
-
-@subsubsection occt_wok_2_1_1 Directory Structure of a Development Unit
-The directory structure of a development unit consists of a tree of directories, which are created when the development unit is initialized. Refer to the *Workbenches* section for further details on the workbench structure.
-@subsubsection occt_wok_2_1_2 Files in a Development Unit
-
-Source Files
-------------
-Source files are written by the developer in the source section (the **src **directory) of the development unit.
-Each development unit maintains the description of its own source files, and this description is stored in one or more files within the *src *directory. The details of how the description is stored vary according to development unit type as shown below:
-* package (p) The names of all source files are worked out from the CDL description, following the conventions described in the *C++ Programming Guide*. This list of files can be supplemented by additional files listed in the file called FILES. This file must be stored in the unit’s src directory. Whenever header files are included in the *src *directory of a development unit, they *must *be specified in FILES so that the C++ preprocessor will take them into account. This reduces compilation time by 10 to 40 percent.
-* schema (s) No description of the source files is needed. There is a single source file: schema.cdl.
-* executable (x) The names of all source files are worked out from the CDL description. The format of this file is described in the *Building an Executable* section.
-* nocdlpack (n) The list of source files is contained in the FILES file stored in the unit’s src directory.
-interface (i). No description of the source files is needed. There is a single source file: interface.cdl.
-* jni (j). No description of the source files is needed. There is a single source file: jni.cdl.
-* toolkit (t) The description is given by the file called PACKAGES which is stored in the unit’s src directory. FILES must also exist in this directory, and must include PACKAGES in its list of files.
-* delivery (d) The description is given by two files stored in the unit’s src directory: FILES and a file called COMPONENTS. FILES must include COMPONENTS in its list of files.
-* resource (r) A resource unit is used in a delivery. FILES contains a list of the unit’s files, one per line in the following format: *atype:::afilename* Here, filename is the name of a file, which the compiler will look for in the src directory of the unit, and atype is a WOK type. To display a list of all available WOK types, use the command: *wokinfo -T*.
-
-Derived files
--------------
-Derived files created by compilation are automatically placed in the derived section of the development unit. These may be executable files or archives of compilation results.
-
-@subsubsection occt_wok_2_1_3 Package
-A package is a development unit that defines a set of classes, which share a number of common features such as similar data structure or a set of complementary algorithmic services. Packages help to manage creation and the use of large hierarchies of software components.
-To create a package, you write a .cdl file describing it in the src directory of the package development unit. The description includes classes and global methods, which comprise it. Each class is also described in a separate .cdl file. The package .cdl file also lists the packages used in the specification of its classes and methods.
-C++ implementation files are also stored in the src subdirectory of the package development unit. These implementation files are:
- * .cxx for an ordinary class
- * .lxx for any inline methods
- * .pxx for any private declarations
- * .gxx for a generic class
-
-To create the Development Unit structure for a package use the following syntax:
-~~~~~
-ucreate –p MyPackage
-~~~~~
-
-The package description has the following CDL syntax:
-~~~~~
-package PackageName
-[uses AnotherPackage {‘,’ YetAnotherPackage}]
-is
-[{type-declaration}]
-[{package-method}]
-end [PackageName]’:’
-~~~~~
-
-For example:
-~~~~~
-package CycleModel
-uses
-Pcollection
-Tcollection
-BREpPrimAPI
-TopExp
-Geom
-Pgeom
-is
-deferred class Element;
-class Wheel;
-class Frame;
-class LocalReference;
-Adjust(awheel: wheel from CycleModel;
- aframe: Frame from CycleModel);
-end CycleModel;
-~~~~~
-For full details on the CDL syntax, refer to the *CDL User’s Guide*.
-
-@subsubsection occt_wok_2_1_4 Schema
-
-A schema is a development unit that defines the set of all data types, which your application is likely to need in order to read and write files. Such data types are **persistent**.
-To create a schema, write a .cdl file that lists all the packages, which contain all persistent data types used by the application. Note that only persistent classes are taken into account during compilation; transient classes are ignored.
-Note that you don’t have to put dependencies in all packages and classes. You only have to write the highest level dependencies. In other words, the *uses *keyword in the schema file allows you to list packages. Any package similarly listed in the package files for these packages are also incorporated into the schema.
-
-To create the Development Unit structure for a schema use the syntax below:
-~~~~~
-ucreate –s MySchema
-~~~~~
-
-The schema description has the following CDL syntax :
-
-~~~~~
-schema SchemaName
-is
-ListOfPackagesContainingPersistentClasses;
-ListOfPersistentClasses;
-end;
-~~~~~
-
-For example:
-~~~~~
-schema MyCycleSchema
-is
-class Wheel from package CycleModel;
-class Frame from package CycleModel;
-..
-class Spanner from package CycleTools;
-end;
-~~~~~
-For full details on the CDL syntax, refer to the *CDL User’s Guide*.
-@subsubsection occt_wok_2_1_5 Executable
-The purpose of an executable is to make executable programs. The executable can use services from one or more packages and is described in a .cdl file as a set of packages.
-To create an executable, you write one or more MyExe.cxx files in the src subdirectory of the unit. This file will contain the main function. Then it is possible to compile the executable.
-
-To create the Development Unit structure for an executable, use the syntax below:
-~~~~~
-ucreate –x MyExec
-~~~~~
-
-The executable description has the following CDL syntax:
-~~~~~
-executable ExecName
-is
-executable BinaryFile
-uses
-LibFile as external
-is
-C++File;
-end;
-end;
-~~~~~
-
-For example:
-~~~~~
-executable MyExecUnit’
-is
-executable myexec
-uses
-Tcl_Lib as external
-is
-myexec;
-end;
-executable myex2
-is
-myex2;
-end;
-end;
-~~~~~
-For full details on the CDL syntax, refer to the *CDL Reference Manual*.
-
-@subsubsection occt_wok_2_1_6 Toolkit
-A toolkit is a development unit that groups a set of packages to create a shareable library. An example of a toolkit is the ModelingData module. Toolkits serve for the following purposes:
- * Linking of large numbers of packages
- * Faster loading of executable files that use toolkits such as test files.
-A toolkit has no CDL definition. Creating a toolkit involves writing a PACKAGES file in the src subdirectory of its development unit. This file lists all the packages needed in the toolkit. You then create a definition of this file to the FILES.
-You then compile the toolkit to create a shareable library.
-@subsubsection occt_wok_2_1_7 Nocdlpack
-A **nocdlpack **is a development unit that has no CDL definition. It is compiled directly from source files written in C, C++, Fortran, or in sources to be treated by the lex or yacc tools. A nocdlpack is useful when you write a low-level interface with another product, for example, a network application.
-To define a nocdlpack, you create a file called FILES in the src subdirectory of the nocdlpack development unit. In this file, you list the Fortran, C, C++, lex, and yacc files that compose the pack. You list the files one per line.
-On compilation, the result is a shareable library.
-
-@subsubsection occt_wok_2_1_8 Interface
-An interface is a development unit that defines a set of services available for wrapping into Java.
-An interface is defined in a .cdl file as a list of packages, package methods, classes, and methods. It makes these available to a jni unit.
-
-To create the Development Unit structure for an interface, use the syntax below:
-~~~~~
-ucreate -i MyInterface
-~~~~~
-
-The interface description has the following CDL syntax:
-
-~~~~~
-interface InterfaceName
-is
-ListOfPackages
-ListOfClasses
-ListOfMethods
-end;
-~~~~~
-
-For example:
-~~~~~
-interface MyInterface
-is
- package TopoDS;
- class Shape from ShapeFix;
-end ;
-~~~~~
-
-@subsubsection occt_wok_2_1_9 Jni
-A jni is a development unit that wraps declared services into Java using JNI (Java Native Interface).
-A jni creates Java classes that are used as C++ counterparts when developing in Java.
-
-To create the Development Unit structure for an Jni, use the syntax below:
-ucreate -j MyJni
-
-The interface description has the following CDL syntax:
-~~~~~
-client JniName
-is
-{interface InterfaceName;}
-end;
-~~~~~
-
-For example :
-~~~~~
-client MyJni
-is
- interface MyInterface;
- interface MyAnotherInterface;
-end ;
-~~~~~
-
-@subsubsection occt_wok_2_1_10 Delivering Parcels
-The delivery process allows creating parcels. These parcels group together the development work done within a given workshop. You can ship these parcels to other workshops called client workshops.
-A delivery is autonomous. Once the delivery development unit is compiled, a parcel is stored in the factory warehouse and has no more connection with the workshop where it was created. A parcel has its own directory structure.
-All Open CASCADE Technology resources are seen as parcels.
-
-
-
-You create a delivery unit under a specified workbench.
-You are **strongly advised** to create delivery units under the *root *workbench of the workshop. Child workbenches could be deleted in the future, whereas the root workbench is likely to remain untouched. In other words, you safeguard the delivery by creating it in the root workbench.
-**Note** If you do not specify a workbench when you make a delivery, it is created under the current workbench.
-@subsection occt_wok_2_2 Workbenches
-A workbench is generally the place where one particular developer or a team of developers works on a particular development. A workbench is composed of a public part and a private part.
-@subsubsection occt_wok_2_2_1 Roots
-The following roots are used in the structure of a workbench:
-* Home Workbench root containing various administration files of the workbench.
-* Src Root of the workbench sources, which facilitates the integration into WOK of version management software such as CVS.
-* DBMS Root of the derived files dependent on the extraction profile (.hxx, _0.cxx files, etc.).
-* DBMS_Station Roots of the derived files dependent on the extraction profile and on the platform (.o, .so files, etc.).
-Roots are defined for each profile and platform supported by the workbench. For example, a workbench supporting the DFLT profile on Sun and SGI platforms has the following roots:
-Home Workbench root,
- Src Root of the source files,
- DFLT Root of the derived files,
- DFLT_sun Root of the files built on Sun platforms,
- DFLT_sil Root of the files built on SGI platforms,
-For a workbench additionally supporting *ObjectStore*, the following additional roots are also found: *OBJS, OBJS_sun, OBJS_sil*.
-
-These roots are defined in the workbench definition file *MyWorkbench.edl* as the parameter *%MyWorkbench_RootName*.
-
-**Note** that default values help to define various roots.
-
-@subsubsection occt_wok_2_2_2 Directories
-Under each root, a hierarchy of directories allows to store various files.
-Under the Home root are found:
- * work, the private workbench directory reserved for the developer
- * Adm, the directory reserved for administration files.
-Src contains:
- * src/MyUD, the directory containing the source files of the development unit MyUD.
-DBMS contains:
- * inc, containing the public header files of the workbench UDs
- * drv/MyUD, containing the private extracted files of MyUD
- * drv/MyUD/.adm, containing the administration files dependent on the extraction profile
- * drv/MyUD/.tmp, containing the temporary files dependent on the extraction profile.
-DBMS_Station contains:
- * <station>/lib with all the libraries produced in the workbench
- * <station>/bin with all the binaries produced in the workbench
- * <station>/MyUD with all the station dependent files which are private to the development unit such as objects
- * <station>/MyUD/.adm with all the station dependent administration files
- * <station>/MyUD/.tmp with all the temporary files constructed in the development unit.
-
-
-
-
-@subsection occt_wok_2_23 Workshops
-A **workshop**is an independent workspace inside which the complete cycle of software production is carried out. Workbenches inside a workshop are organized so that development units can be shared either by being published in a father workbench or by being placed in reference in the root workbench.
-
-
-
-In this image:
- * **A** is the development unit A from Grandchild 11 placed in reference in root. It is visible throughout the workshop.
- * **B** is the development unit B from Grandchild 12 published in ancestor Child 1. It is visible to Child 1, Grandchild 11 and Grandchild 12.
-
-
-In a large-scale development that involves one or more teams of developers, you should decide how you are going to structure a workshop right at the beginning. If need be, you can review your decision later.
-An existing workshop can be duplicated and the original workshop can be used as the basis for maintaining the present version of a product. The new workshop can then be used to develop and maintain a new version of the product.
-When creating a new workshop, you specify - in the form of parcels – which resources are to be available within the workshop.
-
-@subsection occt_wok_2_2_4 Factories
-A factory contains a number of workshops and a warehouse. When Open CASCADE Technology is installed, the system administrator creates a single factory. This contains a single workshop as well as the warehouse containing OCCT resources in the form of parcels.
-There is no theoretical limit to the number of workshops that can be added to a factory. However, a single factory should be enough.
-
-@section occt_wok_3 Development Process
-@subsection occt_wok_3_1 WOK Environment
-The WOK interface is based on tcl, a command language provided by the Regents of the University of California and Sun Microsystems, Inc. The WOK development environment is in fact a tcl session. Before you run a tcl session you must make sure that your account is configured for using tcl, see the *Configuring Your Account for Tcl and WOK* section.
-
-To start a tcl session use the command:
-~~~~~
-% tclsh
-~~~~~
-Within this session, all WOK commands are available as well as standard tcl commands. You can also use tcl language extensions, if these are installed.
-To exit from a tcl session use the command:
-~~~~~
-> exit
-~~~~~
-Online help is provided with tcl. To access this, use the following command:
-~~~~~
-% tclhelp
-~~~~~
-Online help is also available for all WOK commands. To display help on a particular WOK command, give the command name followed by the -h flag, as in the following example:
-~~~~~
-> wokcd -h
-~~~~~
-
-@subsection occt_wok_3_2 Steps
-Implementation of an application is based on the following steps:
-1. Enter the software factory using the command wokcd MyFactory
-2. Enter a workshop using the command wokcd MyWorkshop
-3. Open a workbench using the command wokcd MyWorkbench
-4. Search for the data types required among the existing OCCT libraries
-5. Define one or more packages which will contain the classes
-6. Define new data types as classes
-7. Implement the methods of those classes in C++
-8. Implement any package methods in C++
-9. Unite the test packages
-10. Define any nocdlpacks (if any)
-11. Test the components
-
-**Note:** Steps 1-3 can be performed with a single WOK command:
-~~~~~
-> wokcd MyFactory:MyWorkshop:MyWorkbench
-~~~~~
-
-@subsection occt_wok_3_3 Getting Started
-@subsubsection occt_wok_3_3_1 Entity Names
-Before you start, the following restrictions on WOK entity names must be noted:
- * Entity names may only contain alphanumeric characters and dashes.
- * Entity names must be unique within a hierarchy. For example, you must not have two workbenches called MyBench in the same Workshop. Likewise, you may not have a workshop called CSF in a factory of the same name.
- * Do not use upper and lower case characters to distinguish between two entity names, for example ENT1 and eNt1. This restriction is for reasons of portability.
- * Parcel names must be unique.
-
-@subsubsection occt_wok_3_3_2 Entering the Factory
-When you start work you go to the factory using the following command:
-~~~~~
-> wokcd <MyFactory>
-~~~~~
-@subsubsection occt_wok_3_3_3 Creating a New Workshop
-If you don’t want to work in a workshop already present in the factory, you can create a new one. To do this, use the following command:
-~~~~~
-> screate –d <MyWorkshop>
-~~~~~
-This creates the new workshop **MyWorkshop** in the current factory. To create the same workshop in a different factory use the syntax below:
-~~~~~
-> screate –d <MyFactory:MyWorkshp>
-~~~~~
-
-When you create a new workshop, it is empty.
-
-@subsubsection occt_wok_3_3_4 Selecting Parcels
-When you create a workshop, you select existing OCCT resources, for example, parcels, to use in it. To do this, you create the workshop and add the parcels using the following syntax:
-~~~~~
-> screate –d <MyWorkshop> -DparcelConfig=Parcel1,Parcel2…
-~~~~~
-To display available OCCT resources, in other words, to see what parcels are available, you use the following command:
-~~~~~
-Winfo –p <WarehouseName>
-~~~~~
-**Note:** parcel configuration rarely needs to change. If it does, only the workshop administrator should make them.
-@subsubsection occt_wok_3_3_5 Opening a Workshop
-To open a workshop, you use the following command:
-~~~~~
-> wokcd <MyWorkshop>
-~~~~~
-@subsubsection occt_wok_3_3_6 Creating a New Workbench
-When you create a new workshop, it is empty. In other words, it does not contain any workbenches.
-To create the root workbench of a new workshop, you use the following command:
-~~~~~
-> wcreate -d <MyWorkbench>
-~~~~~
-This creates a tree of workbench subdirectories.
-If workbenches already exist in your workshop, but you do not want to work in any of these, create a new workbench as a child of an existing one. You do this using the following syntax:
-~~~~~
-> wcreate –d <MyWorkbench> -f <ParentWorkbench>
-~~~~~
-@subsubsection occt_wok_3_3_7 Opening a Workbench
-To open a workbench, you use the command below:
-~~~~~
-> wokcd <MyWorkbench>
-~~~~~
-This automatically takes you to the root directory of the workbench
-
-@subsubsection occt_wok_3_3_8 Using Existing Resources
-Before creating new data types, you should look for existing components that you can reuse. In particular, you should look through the existing resources of your Open CASCADE Technology platform to see if any of the required components already exist, or if any existing generic components can be suitably implemented. This search can be conducted using the online documentation. You should note the packages and classes, which you can reuse.
-@subsection occt_wok_3_4 Creating Software Components
-@subsubsection occt_wok_3_4_1 Creating a Package
-To develop new software components, you usually need to create one or more packages. You do this, by using the following command:
-~~~~~
-> ucreate –p <MyPackage>
-~~~~~
-Because the key -p defines the default value for the *ucreate* command, you do not need to specify it. The following syntax, for example, will also create a package:
-~~~~~
- > ucreate <MyPackage>
-~~~~~
-Enter a Package or other Development Unit Structure
-----------------------------------------------------
-Enter the package or any other development unit structure using the *wokcd* command as in the syntax below:
-~~~~~
-> wokcd MyPackage
-~~~~~
-The current directory is now:
-~~~~~
-MyWorkbenchRoot/src/MyPackage
-~~~~~
-
-Writing the Package and Class Specifications in CDL
----------------------------------------------------
-Write the descriptions of the software components in CDL using an editor of your choice. Write each class in its own .cdl file and write one .cdl file (MyPackage.cdl) to specify the package that contains those classes.
-CDL Compilation of the Package
-------------------------------
-Compile and check the package and its classes using:
-~~~~~
- > umake –e xcpp
-~~~~~
-This command also extracts the C++ header files (.hxx) and stores them in the derived files directory.
-
-Implementing Methods in C++
----------------------------
-A package will contain methods, which may be:
- * Instance methods
- * Class methods
- * Package methods.
-Extract **prototypes** for the C++ methods using the following command:
-~~~~~
- > umake -o xcpp.fill -o xcpp.template
-~~~~~
-
-You should not confuse this syntax with the template feature of C++ used to implement the genericity.
-The *umake -o xcpp.template* command creates a skeleton C++ file for:
- * Each class
- * All the package methods.
-The packages methods will be created in a file called package.cxx.template. This command is *not *included in the umbrella command MyPackage.
-You will need to use an editor to implement these methods in C++.
-Compiling the Package
----------------------
-To compile the package, use the command:
-~~~~~
- > umake -o obj <MyPackage>
-~~~~~
-If you do not specify a package, the current development unit is compiled.
-
-Sample Construction of a Package
----------------------------------
-
-In the following example a workbench named **MyWb** is created as a child of an existing workbench **Topo**. MyWb is used for working on the package **MyPack**. Commands preceded by an asterisk below are used only once per session:
-1. Create the MyWb workbench as a child of Topo.
-~~~~~
- > wcreate MyWb -f Topo -d
-~~~~~
-2. Create MyPack in MyWb.
-~~~~~
- > ucreate MyPack
-~~~~~
-3. Move to the source directory of MyPack.
-~~~~~
- > wokcd MyPack
-~~~~~
-4. Edit the source files (MyPack.cdl etc.). You do this outside tcl, using the editor of your choice.
-5. Start the extraction of MyPack.
-~~~~~
- > umake -e xcpp
-~~~~~
-6. Generate the .cxx templates for MyPack: MyPack.cxx.template
-~~~~~
- > umake -o xcpp.fill -o xcpp.template -t
-~~~~~
-7. Edit the source files (MyPack.cxx etc). You do this outside tcl, using the editor of your choice.
-
-**Note*** *umake* command used without arguments will carry out all the above *umake* steps. You can also use it with specific arguments as above to go through the development process step by step.
-
-Package Files
--------------
-* Primary Files for a Package
-+ <Package>.cdl Primary package file.
-+ <Package>_<Class>.cdl Primary class file.
-* C++ Files for a Package
-+ <Package>.cxx Primary package source file.
-+ <Package>_[1..9[0..9]*].cxx Secondary package source files.
-+ <Package>.lxx Inline package methods source file.
-+ <Package>.pxx Private instructions source file.
-* C++ Files for a Class
-+ <Package>_<Class>.cxx Primary class source file.
-+ <Package>_<Class>_[1..9[0..9]*].cxx
-* Secondary class source files.
-+ <Package>_<Class>.gxx Generic class methods source file. This is an alternative to the .cxx file(s), you do not have both.
-+ <Package>_<Class>.lxx Inline methods source file.
-+ <Package>_<Class>.pxx Private instructions source file.
-* Derived C++ Files for a Package
-+ <Package>.hxx User header file.
-+ <Package>.ixx User header file included in <Package>.cxx.
-+ <Package>.jxx User header file included in <Package>_[1-9].cxx.
-* Derived C++ files for a class
-+ <Package>_<Class>.hxx User header file.
-+ <Package>_<Class>.ixx User header file included in <Package>_<Class>.cxx.
-+ <Package>_<Class>.jxx User header file in <Package>_<Class>_[1..9[0..9]*].cxx.
-+ Handle_<Package>_<Class>.hxx Persistent or Transient class header file.
-+ <Package>_<Class>_0.cxx For instantiated classes.
-
-Umake Steps for a Package
--------------------------
-The umake steps for development units of package type are explained below.
-* src Processes the file MyPackage.cdl to generate a list of all the CDL files in the development unit. Processes FILES to list source files.
-* xcpp.fill Compiles the internal data structure to prepare for subsequent extractions.
-* xcpp.src Lists the source files (.cxx, .gxx, .lxx) deduced from the CDL files.
-* xcpp.header Extracts header files for the classes in the development unit.
-* xcpp.template (Hidden step.) Extracts a template for implementation of methods.
-* obj.inc Based on the list of source files generated by the src and xcpp.src steps, this step publishes the include files for the development unit so that other units can use them.
-* obj.cgen Processes the source files to generate code.
-* obj.comp Compiles each file that can be compiled.
-* obj.idep Generates dependency information for the unit. This comprises:
- + Includes performed by unit compilation (Unit.MakeState)
- + Implementation dependencies in terms of the unit suppliers (Unit.ImplDep)
-* obj.lib Generates the shared library for the development unit.
-@subsubsection occt_wok_3_4_2 Creating a Nocdlpack
-If your executable requires the use of a nocdlpack, create a development unit of nocdlpack type and move to its structure using the commands below:
-~~~~~
- > ucreate -n <MyNoCDLPack>
- > wokcd <MyNoCDLPack>
-~~~~~
-Use an editor to write FILES. This file must list all the C, C++, Fortran, lex, and yacc sources.
-Build the nocdlpack using the following command:
-~~~~~
- > umake [<MyNoCDLPack>]
-~~~~~
-**Note** that a nocdlpack unit is not intended to perform tests. Use an executable unit instead.
-
-
-*FILES: * Is a nomenclature file for a nocdlpack. It is a list of Fortran, C, C++, lex, and yacc files (one per line).
-
-Sample Construction of a Nocdlpack
------------------------------------
-In the following example a nocdlpack, MyNocdlpack, is created. Commands preceded by an asterisk below are used only once per session:
-1. \*Create MyNocdlpack in MyWb.
-~~~~~
-> ucreate -n <MyNoCDLPack>
-~~~~~
-2. Move to the source directory of MyNocdlpack.
-~~~~~
-> wokcd <MyNoCDLPack>
-~~~~~
-3. Write the FILES list. You do this outside tcl, using the editor of your choice.
-4. Write the source code.
-5. Build MyNocdlpack.
-~~~~~
-> umake [<MyNoCDLPack>]
-~~~~~
-
-Umake Steps for a Nocdlpack
----------------------------
-The *umake* steps for development units of nocdlpack type are explained below.
-* src Processes FILES to list source files.
-* obj.cgen Processes the source files to generate code.
-* obj.inc Based on the list of source files, this step publishes the header files for the unit so that other units can use them.
-* obj.comp Compiles each file that can be compiled.
-* obj.idep Generates dependency information for the unit. This comprises:
- + Includes performed by unit compilation. (Unit.MakeState)
- + Implementation dependencies in terms of the unit suppliers. (Unit.ImplDep)
-* obj.lib Generates the shared library for the unit.
-@subsubsection occt_wok_3_3_3 Creating a Schema
-If the application, which you intend to build, stores data in a file, you need to define a schema for the persistent data types that are known.
-You create a schema and go to its root directory using the commands:
-~~~~~
-> ucreate -n <MySchema>
-> wokcd <MySchema>
-~~~~~
-Using the editor of your choice, write a .cdl file to define the schema. This schema file lists all the packages that contain persistent data types used in the implementation of your application. It has the following format:
-~~~~~
- schema MySchema
- is
-class <MyClass> from <Package>;
- end;
-~~~~~
-
-Building a Schema
-~~~~~~~~~~~~~~~~~
-Compile and check the coherence of the CDL specification for the schema:
-~~~~~
-> umake -e xcpp.fill
-~~~~~
-Extract the C++ description:
-~~~~~
-> umake -o xcpp
-~~~~~
-Compile the C++ description of the schema:
-~~~~~
-> umake -o obj
-~~~~~
-Alternatively, the above three steps can all be carried out by one command:
-~~~~~
-> umake
-~~~~~
-Sample Construction of a Schema
--------------------------------
-In the following example the schema *MySchema* is created. It contains all the schemas of the persistent classes of your own packages and the packages they depend on. Commands preceded by an asterisk below are used only once per session:
-1. Create MySchema in MyWb.
-~~~~~
- > ucreate -s MySchema
-~~~~~
-2. Move to the source directory of MySchema.
-~~~~~
-> wokcd MySchema
-~~~~~
-3. Edit the source file MySchema.cdl. You do this outside tcl, using the editor of your choice.
-4. Derive implementation files.
-~~~~~
- > umake -e xcpp.sch
-~~~~~
-5. Derive application schema files.
-~~~~~
- > umake -o xcpp.ossg
-~~~~~
-6. Compile the schema.
-~~~~~
- > umake -o obj
-~~~~~
-Schema Files
-------------
-* Primary Files for a Schema
-+ <Schema>.cdl Primary schema file.
-* Derived C++ Files for a Schema
-+ <Schema>.hxx User header files.
-+ <Schema>.cxx Schema implementation files.
-+ <Sch_MyPack_MyClass>.cxx Schema implementation files.
-
-Umake Steps for a Schema
-------------------------
-The umake steps for development units of schema type are explained below.
-* src Processes MySchema.cdl to generate a list of CDL files for the development unit. Processes the FILES file to list source files.
-* xcpp.fill Compiles the internal data structure to prepare for subsequent extractions.
-* xcpp.sch Extracts the schema implementation code.
-* obj.comp Compiles the extracted files that can be compiled.
-* obj.lib Generates the shared library for the unit.
-* obj.idep Generates dependency information for the schema.
-
-@subsection occt_wok_3_5 Building an Executable
-@subsubsection occt_wok_3_5_1 Creating an Executable
-To make an executable from one or more of the packages, which you have created, write a .cdl file to specify the packages to use.
-Writing an Executable
----------------------
-Refer to the *CDL User’s Guide *for full details. A simple example is given below.
- executable <MyExec> // the executable unit
-is
- executable myexec // the binary file
-uses
-Tcl_Lib as external
-is
- myexec; // the C++ file
-end; // several binaries can be specified in one .cdl file.
-executable myex2
-is
- myex2;
-end;
- end;
-Write the C++ file(s). For the example above you write the files: myexec.cxx and myex2.cxx.
-Building the Executable
------------------------
-To build the executable, use the command:
- > umake
-
-Construction of an Executable
------------------------------
-In the following example an executable, MyExec, is created in the workbench MyWb. Commands preceded by an asterisk below are used only once per session:
-1. \*Create MyExec in MyWb.
- > ucreate -x MyExec
-2. Move to the source directory of MyExec.
- > wokcd MyExec
-3. Edit the cdl source file (MyExec.cdl). You do this outside tcl, using the editor of your choice.
-4. Edit the C++ files (AnExe.cxx etc.). You do this outside tcl, using the editor of your choice.
-5. Build MyExec.
- > umake
-6. Run the executable file.
- > wokcd -PLib
- > MyExec
-
-Executable Files
-----------------
-* Primary Files for an Executable
-+ <Exec>.cdl Primary executable file
-* C++ Files for an Executable
-+ <AnExe>.cxx Source file
-+ <AnExe>_[1-9].cxx Other source files
-Umake Steps for an Executable
------------------------------
-The umake steps for development units of executable type are explained below.
-* src Processes MyExe.cdl to generate a list of CDL files for the development unit. Processes FILES to list source files.
-* src.list Based on MyExe.cdl, works out the list of parts and the source files involved for each part.
-* exec.comp Compiles the files that can be compiled for each part of the executable.
-* exec.idep Generates dependency information for each part of the executable.
-* exec.libs Computes full implementation dependency to prepare for linking for each part of the executable.
-* exec.tks Performs toolkit substitution according to TOOLKITS for each part of the executable.
-* exec.link Links each part of the executable.
-@subsection occt_wok_3_6 Test Environments
-@subsubsection occt_wok_3_3_1 Testing an Executable
-To test an executable, you create an executable development unit and move to its structure. See the *Building an Executable* section for details.
-When you write the .cdl file for your test executable, specify the packages to test, for example:
-~~~~~
-executable MyTest // the executable unit
- is
-executable mytest1 // the binary file
-is
- mytest1; //the C++ file
-end; // several binaries can be specified in one .cdl file.
-executable mytest2
-is
- mytest2;
-end;
- end;
-~~~~~
-Write the C++ test file(s), in the example, *mytest1.cxx* and *mytest2.cxx*.
-Building the Executable
------------------------
-To build the executable use the command:
-~~~~~
-> umake
-~~~~~
-
-Sample Construction of a Test Executable
-----------------------------------------
-The overall process of constructing a test executable is the same as for any other executable. For a sample, refer to the *Construction of an Executable* section.
-
-Setting up a Test Environment
------------------------------
-To set up a test environment, move to the * /drv* subdirectory that corresponds to the current profile (e.g. the directory: * /MyExec/drv/DFLT/sun* directory) and run the executable test file.
-~~~~~
-> wokcd -PLib
-> wokenv -s
-> myApp
-~~~~~
-The command *wokenv* is used with -s option to configure the test environment.
-The command *wokenv –s* uses the current workbench to decide what actions are needed to configure the tcl shell for use as your test environment.
-WOK sets the following environment variables:
-
-* *$STATION* - The current station.
-* *$TARGET_DBMS* - The current database platform.
-* *$PATH* - The current path, plus the bin directories of the parcels.
-* *$LD_LIBRARY_PATH* The current path, plus the lib directories of the parcels.
-WOK then sets a variable for each parcel listed in the parcel configuration of the current workshop. This variable is the original name of the delivery unit in the uppercase, with the suffix *HOME*. *$ORIGDELIVUNITHOME* is set as the root directory of the parcel.
-WOK then sources the following files:
- * MyFactory.tcl, found in the admin directory of the factory.
- * MyWorkshop.tcl found in the admin directory of the workshop.
-Then for each Workbench, WOK sources according to the hierarchy of the workbenches:
- * Workbench.tcl, found in the /Adm directory of the workbench.
-After the environment is set up, you are at a C shell prompt and can run the executable.
-**Note** Environment variables are only set when the command is used with the option *-s*. Thus, if you change a workbench or a factory within WOK and then return to the test environment you must use *wokenv -s* *to ensure that the set environment variables configuration is correct for the current WOK state.
-The configuration actions that WOK performs can be written to a file and saved as a script. You can then edit this script to suit it to your own needs, and generate a personalized test environment. To create the script file use the following command:
-~~~~~
- > wokenv -f <ScriptFile> -t csh
-~~~~~
-This commands generates a file, ScriptFile, which configures a C shell to mirror the current WOK environment. An example script file is given below.
-~~~~~
-setenv STATION *sil*
-setenv TARGET_DBMS *DFLT*
-setenv KERNELHOME */adv_22/WOK/BAG/KERNEL-K1-2-WOK*
-setenv LD_LIBRARY_PATH */adv_22/WOK/BAG/wok-K1-2/lib/sil:/adv_22/WOK/BAG/KERNEL-K1-2-WOK/sil/lib/*
-setenv PATH */usr/tcltk/bin:/usr/bin:/bin:/usr/bin/X11:/lib:.:/SGI_SYSTEM/util_MDTV/factory_proc:/adv_22/WOK/BAG/KERNEL-K1-2-WOK/sil/bin/*
-source /adv_22/WOK/BAG/KERNEL-K1-2-WOK/adm/Kernel.csh
-~~~~~
-
-@subsection occt_wok_3_7 Building a Toolkit
-@subsubsection occt_wok_3_7_1 Creating a Toolkit
-
-You create and enter a toolkit development unit using the following commands:
-~~~~~
- > ucreate -t <TKMyToolkit>
- > wokcd <TKMyToolkit>
-~~~~~
-Write the Nomenclature File for the Toolkit
--------------------------------------------
-Using an editor, write a nomenclature file called PACKAGES which lists all the packages, one per line, that make up the toolkit. Add PACKAGES to FILES.
-Build the shareable library for this toolkit as follows:
-~~~~~
-> umake [<TKMyToolkit>]
-~~~~~
-**Note:** when one of the packages in the toolkit is modified, recompile the toolkit. A package should belong to one toolkit only.
-
-Sample Construction of a Toolkit
---------------------------------
-In the following example, the toolkit **TKMyToolkit** is created. Commands preceded by an asterisk below are used only once per session:
-1. \*Create MyToolkit in MyWb.
-~~~~~
- > ucreate -t TKMyToolkit
-~~~~~
-2. Move to the source directory of MyToolkit.
-~~~~~
- > wokcd TKMyToolkit
-~~~~~
-3. Edit the nomenclature files, PACKAGES and FILES. You do this outside tcl, using the editor of your choice.
-4. \*Create the library for MyToolkit
-~~~~~
- > umake TKMyToolkit
-~~~~~
-Umake Steps for a Toolkit
--------------------------
-The umake steps for development units of toolkit type are explained below.
-* src Processes FILES to list source files.
-* lib.list Works out the objects and archive library to add to the toolkit shared library.
-* lib.limit Manages the build process strategy within the limitations of a particular platform.
-* lib.arch Builds archives according to the building strategy.
-* lib.uncomp Decompresses third party archives.
-* lib.arx Extracts object files from archives.
-* lib.build Generates the shared library for the toolkit.
-Building strategy depends on the platform. The following step sequences apply:
- * On Sun (Solaris):
-~~~~~
-src
-lib.list
-lib.arx
-lib.build
-~~~~~
- * On sil (IRIX):
-~~~~~
-src
-lib.list
-lib.uncomp
-lib.build
-~~~~~
-
-The TOOLKITS File
------------------
-When executables are compiled, a TOOLKITS file is used to determine which toolkits are included. This file is located in the src directory of the entity being compiled. The process is as follows:
-No TOOLKITS file found:
-All toolkits are candidates for substitution. To find out which toolkits are candidates, use the command *w_info -k*.
-Empty TOOLKITS file found:
-No toolkit is a candidate for substitution.
-Non-empty TOOLKITS file found:
-Only those toolkits listed in the TOOLKITS file are candidates for substitution.
-
-Toolkit Substitution
---------------------
-Toolkit substitution is performed as follows:
-MyEngine uses:
- A, B and C
-The toolkit TK provides:
- A and D
- D uses: E
-Compilation of *MyEngine* includes:
-TK, B C and E
-Here, for simplicity, assume that additional toolkits are not substituted for B, C and E.
-@subsection occt_wok_3_8 Building a Delivery Unit
-@subsubsection occt_wok_3_8_1 Creating a Delivery Unit
-> ucreate -d <MyDeliveryUnit>
-Writing the COMPONENTS File
----------------------------
-Create a file named COMPONENTS in the src subdirectory of the delivery development unit. List in this file the prerequisites of the delivery and the components that are part of the delivery. Use the syntax shown below.
-Note that keywords and default options are shown in bold.
-
-~~~~~
-**Name** ParcelName
-Put path
-Put include
-Put lib
-**Requires** DeliveryName\*
-**Package** MyPack **[CDL][LIBRARY][INCLUDES][SOURCES]**
-**Nocdlpack** MyNcdl **[LIBRARY][INCLUDES][SOURCES]**
-**Executable** MyExec **[CDL][DYNAMIC][SOURCES]**
-**Interface** MyIntf **[CDL][STUB_SERVER][SOURCES]**
-**Client** MyClient **[CDL]**[STUB_CLIENT][SOURCES]
-**Engine** MyEng **[CDL][DYNAMIC][SOURCES]**
-**Schema** MyShma **[CDL][LIBRARY][SOURCES][DOC]**
-**Toolkit** MyTk **[LIBRARY][SOURCES]**
-**Get** DevelopmentUnitName::Type:::File
-~~~~~
-\* Without mention of the version
-If no keywords are specified then all default arguments shown in bold are taken into account. To select arguments, list the ones required explicitly. The arguments are explained below:
-**Name** The full name of the current delivery, including a version number. This is the name of the parcel.
-**Put path** Requires that the delivery be inserted in the user path (bin directory).
-**[CDL]** Copy the cdl files to the delivery.
-**[LIBRARY]** Generate the static library. Copy the shareable library to the delivery. Copy the list of objects of the library.
-**[INCLUDES]** Generate includes.origin. Copy the includes to the delivery. Copy the ddl to the delivery.
-**[DYNAMIC]** Select to copy the static or dynamic executable file.
-**[SOURCES]** Copy the source files.
-
-Build the Delivery
------------------
-To build the delivery unit, use the command:
-~~~~~
-> umake <MyDeliveryUnit>
-~~~~~
-The result of building a delivery unit is a **parcel**, which can be installed in a warehouse and used by other workbenches.
-
-Sample Delivery of a Parcel
----------------------------
-In the following example a delivery is created, compiled and made into a parcel. Commands preceded by an asterisk below are used only once per session:
-1. Move to the root workbench under which the parcel is to be made.
-~~~~~
-> wokcd MyRootWb
-~~~~~
-2. \*Create MyDelivery in MyRootwb.
-~~~~~
-> ucreate -d MyDelivery
-~~~~~
-3. Move to the source directory of MyDelivery.
-~~~~~
-> wokcd MyDelivery
-~~~~~
-4. Use an editor to list all the prerequisites and components of the delivery in the COMPONENTS files using the appropriate syntax.
-5. Build MyDelivery.
-~~~~~
-> umake MyDelivery
-~~~~~
-The output of the umake process is a parcel
-
-Umake Steps for a Delivery Unit
--------------------------------
-The umake steps for development units of type delivery are explained below.
-* src Processes FILES to list source files.
-* base Creates directories, defines the list of units, copies the parcels and the release notes.
-* get.list Lists files to get (using Get, Resource).
-* get.copy Copy the files listed by get.list.
-* cdl.list Lists CDL files to copy.
-* cdl.copy Copies the files listed by cdl.list.
-* source.list Lists units from which sources are to be copied.
-* source.build Creates a file for sources (in the format: unit.type.Z).
-* inc.list Lists includes to copy.
-* inc.copy Copies files listed by inc.list.
-* lib.shared Works out the inputs for building or copying shareable libraries.
-* lib.shared.build Copies or builds (depending on the platform) the shareable libraries.
-* lib.server.list Lists interface files to copy.
-* exec.list Lists inputs for executable delivery.
-* exec.build Creates executable in the parcel.
-* files Works out the list of files delivered in the parcel.
-@subsubsection occt_wok_3_8_2 Installing a Parcel
-You open the root workbench of the workshop where you want to install the parcel using the following command:
-~~~~~
-> wokcd <MyWorkshop>
-~~~~~
-To install the parcel, use the following syntax:
-~~~~~
-> pinstall <MyParcel>
-~~~~~
-@subsection occt_wok_3_9 Working with Resource
-Building a Resource
--------------------
-There is a single umake step for development units of resource type.
-* src Processes FILES to list source files.
-
-@subsection occt_wok_3_10 Java wrapping
-@subsubsection occt_wok_3_10_1 Creating an interface
-
-To create an interface development unit and move to its structure, use commands:
-~~~~~
-> ucreate -i <MyInterface>
-> wokcd <MyInterface>
-~~~~~
-
-Writing an Interface
---------------------
-Having created the interface, you select the classes and packages that you wish to make available for Java wrapping in the jni units. Use an editor of your choice to write a .cdl interface file that specifies these exported services. This file has the format:
-
-~~~~~
-interface MyInterface
-uses
- ListOfPackages;
-is
- ListOfPackages;
- ListOfClasses;
- ListOfMethods;
-end;
-~~~~~
-
-Building an Interface
----------------------
-To make the services of the interface available for further wrapping, build the interface, using the command:
-~~~~~
-> umake [<MyInterface>] -o src
-~~~~~
-
-Sample Construction of an Interface
-----------------------------------
-In the following example a workbench, MyWb, is used for working on the interface MyInterface. Commands preceded by * (asterisk) are used only once during a session.
-
-1. \*Create MyInterface in MyWb.
-~~~~~
->ucreate -i MyInterface
-~~~~~
-2. Move to the source directory of MyInterface.
-~~~~~
->wokcd MyInterface
-~~~~~
-3. Edit the source file MyInterface.cdl. You do this outside tcl, using an editor of your choice.
-4. Build the interface.
-~~~~~
-> umake -o src
-~~~~~
-
-Interface Files
----------------
-Primary files for an interface
-
-<Interface>.cdl - primary interface file
-
-Umake Steps for an Interface
-----------------------------
-The umake steps for development units of type interface are explained below.
-
-* src - processes MyInt.cdl to list the CDL files for the development unit. Processes the FILES file to list source files.
-
-**Note** Make sure you only use the *src* step of umake. Using umake without arguments will lead to an attempt of launching other steps relevant to the interface unit. However these steps will fail and anyway are not required for use in Java wrapping.
-
-@subsubsection occt_wok_3_10_2 Creating a jni
-To create a development unit of type jni and move to its structure, use commands:
-~~~~~
-> ucreate -j <MyJni>
-> wokcd <MyJni>
-~~~~~
-
-Writing a Jni
--------------
-Use an editor to write a .cdl file that specifies the interface or interfaces required by the jni. This file has the following format:
-~~~~~
-client MyJni
-is
-{interface MyInterface;}
-{interface YourInterface;}
-end;
-~~~~~
-
-Building a Jni
---------------
-To wrap services exported by the interfaces to Java, build the jni, using the command:
-~~~~~
- > umake [MyJni]
-~~~~~
-
-Sample Construction of a Jni
-----------------------------
-In the following example a workbench, MyWb, is used for working on the jni, MyJni. Commands preceded by * (asterisk) are used only once during a session.
-
-1. \*Create MyJni in MyWb.
-~~~~~
-> ucreate -j MyJni
-~~~~~
-2. Move to the source directory of MyJni.
-~~~~~
-> wokcd MyJni
-~~~~~
-3. Edit the source file MyJni.cdl. You do this outside tcl, using an editor of your choice.
-
-4. Derive Java files (.java and .class files) and C++ files (.h and .cxx) used for wrapping.
-~~~~~
- > umake -e xcpp
-~~~~~
-5. Compile the sources.
-~~~~~
-> umake -o obj
-~~~~~
-6. Link the object files.
-~~~~~
-> umake -o exec
-~~~~~
-Jni Files
----------
-Primary jni file is *Jni.cdl*
-
-Derived Java files for a Jni
-----------------------------
-*<Package>_<Class>.java* - Java source file of the class to be wrapped.
-*<Package>_<Class>.class* - Compiled java source file.
-
-Derived C++ files for a Jni
----------------------------
-*<Jni>_<Package>_<Class>_java.h* - Include file for the C++ implementation of JNI.
-*<Jni>_<Package>_<Class>_java.cxx* - C++ implementation of JNI.
-
-Umake Steps for a Jni
----------------------
-The umake steps for development units of type jni are explained below.
-
-* src Processes MyJni.cdl to list the CDL files for the development unit. Processes the FILES file to list source files.
-* xcpp.fill Compiles the internal data structure to prepare for subsequent extractions.
-* xcpp.client Extracts the services declared in included interface unit(s) into Java and creates .java and *_java.cxx files.
-* xcpp.javac Compiles .java files into .class files.
-* xcpp.javah Creates .h header files.
-* obj.comp Compiles generated C++ files.
-* obj.idep Generates dependency information for the unit.
-* exec.libs Computes full implementation dependency to prepare for linking.
-* exec.tks Performs toolkit substitution.
-* exec.link Generates the shared library for the development unit.
-
-@subsection occt_wok_3_11 More Advanced Use
-@subsubsection occt_wok_3_11_1 Default User Profile
-There is a default user profile. If you wish to change this profile the command wokprofile is available.
-You display the current profile using the command *> wokprofile*
-An example profile is given below.
-~~~~~
- Info : Profile in : WOK:k1dev:ref
- Info : Extractor : DFLT
- Info : Compile Mode : Optimized
- Info : Station Type : sil
-~~~~~
-@subsubsection occt_wok_3_11_2 Changing Parcel Configuration
-Parcel configuration rarely needs changes. However, if you do need to modify the list of resources, you can do so by editing the admin parameter file of the factory. This file is found in the admin directory of the factory and is named after the workshop. It has the suffix .edl. Its full name has the following format:
-~~~~~
-<MyWorkshop>.edl.
-~~~~~
-
-Move to the admin directory of the factory:
-~~~~~
-> wokcd <MyFactory> -PAdm
-~~~~~
-
-Then use the editor of your choice to edit the admin parameter file, MyWorkshop.edl.
-In this file, the parcel configuration is defined by an entry of the form:
-~~~~~
-\@set %<MyWorkshop>_ParcelConfig = “Parcel1 Parcel2...Parceln”;
-~~~~~
-The resources are listed within quotation marks. They are separated by spaces.
-Edit this list as required. Save the file and close it.
-To validate and take into account your changes use the command:
-~~~~~
-> wokclose -a
-~~~~~
-This command closes and reopens all the entities. Without the -a option, *wokclose* only applies to the current entity.
-@section occt_wok_4_ Available Services
-@subsection occt_wok_4_1 Synopsis
-WOK provides sets of services, which can be grouped according to the entity they apply to:
- * General Services
- * Factories
- * Warehouses
- * Parcels
- * Workshops
- * Workbenches
- * Development Units
- * Source Management Services
- * Session Services
-@subsubsection occt_wok_4_1_1 Common Command Syntax
-Command Names
--------------
-All WOK commands follow a common naming convention. This is based on a set of common command names and a group of prefixes, which denote entity type. The command name takes a prefix representing the entity to which it applies.
-The following prefixes exist:
- * f: for factories
- * s: for workshops
- * w: for workbenches
- * u: for development units
- * W: for warehouses
- * p: for parcels
- * wok: for commands that apply to any type of entity
-These prefixes are followed by a command that determines the action to be executed. Examples of such commands are:
- * create: create an entity
- * rm: delete an entity
- * info: request information
-Consequently, the command ucreate creates a development unit. The command wrm removes a workbench.
-Command Options
----------------
-All command options are expressed using a dash (-) followed by one or more key letters and, if applicable, an argument. For example:
-~~~~~
-> umake -f -o <argument> MyUnit
-~~~~~
-The compact version of this syntax is also valid:
-~~~~~
- umake -fo argument MyUnit
-~~~~~
-This syntax conforms to the POSIX recommendations for UNIX commands.
-For all commands, there is a –h option, which displays help on usage.
-
-Presentation of Commands
-------------------------
-The general syntax of the commands is presented in this document as follows:
-~~~~~
-CommandName [option(s) [<argument(s)>] [<Entity>]]
-~~~~~
-Consequently, there are four general cases for a command:
-~~~~~
-CommandName <Entity>
-CommandName <option(s)> [<argument(s)>] <Entity>
-CommandName <option(s)> [<argument(s)>]
-CommandName
-~~~~~
-**Note** a few commands described in this chapter do not completely respect this syntax; for example, *create* and *rm*.
-As a rule, where an *<EntityPath>* is given as an argument it specifies which entity the command applies to. Where no *<EntityPath>* is specified, the command applies to the nearest appropriate entity. The *create* and *rm* commands are notable exceptions: you **must** specify an entity path with these commands.
-
-@subsection occt_wok_4_2 General Services
-General services are commands that apply to any entity manipulated by WOK.
-This includes commands for:
- * Navigation
- * Managing parameters
- * Managing profiles.
-wokcd **Navigates** between different WOK entities.
-wokclose **Closes **and reopens entities.
-wokenv **Gets information **about the current WOK environment.
-wokinfo **Displays **information common to all entities.
-woklocate **Locates **files within the development units.
-wokparam **Queries **parameters.
-wokprofile **Modifies **the parameters of the session.
-
-@subsubsection occt_wok_4_2_1 wokcd
-~~~~~
-wokcd
-wokcd <EntityPath>
-wokcd -P <ParamSuffix> [<EntityPath>]
-~~~~~
-
-Navigates between different WOK entities and changes the current working directory. Without any arguments wokcd lists the current position (the WOK equivalent of ‘pwd’). With an argument, wokcd moves to the specified location.
-Options:
-<EntityPath> Moves to the home directory of the entity specified by <EntityPath>, i.e. moves to the location given by the parameter: %wokcd <EntityPath>_Home.
--P <ParamSuffix> [<EntityPath>]
-Moves to the <ParamSuffix> directory of the entity specified by <EntityPath>. i.e. moves to the location given by the parameter: %<EntityPath>_<ParamSuffix>. If no entity path is specified, this command moves to the <ParamSuffix> directory of the current entity.
-
-Possible values for <ParamSuffix> are: Home, Adm and Src.
-Use the following commands to change directories within a development unit:
-**wsrc **To access the source files.
-**winc **To access the include files.
-**wobj **To access objects.
-**wlib **To access shareable libraries.
-**wbin **To access executables.
-**wadm **To access the workbench administration files.
-
-Examples
---------
-*wokcd* - Lists the current position.
-*wokcd MODEL:GTI:gti:gp* - Moves to the home directory of the gp package of the gti workbench in the GTI workshop in the MODEL factory.
-*wokcd -P Adm* - Moves to the administration directory of the current entity.
-@subsubsection occt_wok_4_2_2 wokclose
-~~~~~
-wokclose [-a]
-~~~~~
-Closes and reopens entities, i.e. reloads them into memory thus taking any changes into account.
-Options:
-**-a** Closes and reloads all entities.
-
-Examples
---------
-~~~~~
-wokclose
-~~~~~
-Closes and reopens the current entity.
-~~~~~
-wokclose -a
-~~~~~
-Closes and reopens all the entities.
-@subsubsection occt_wok_4_2_3 wokenv
-
-wokenv -f <ScriptFile> -t csh
-Creates the file <ScriptFile>. This file is a script, which configures a C shell to mirror the current WOK environment. See the *Test Environments* section for more details.
-Options:
-**-f** <ScriptFile> - Specifies the name of the file to produce.
-**-t csh** - Produces a file for configuring a C shell.
-**-s** - Sets up environment variables for application launching.
-Example
--------
-~~~~~
-> wokenv -f MyTestEnvScript -t csh
-~~~~~
-Generates the shell script MyTestEnvScript to configure a C shell so that it mirrors the current WOK environment.
-@subsubsection occt_wok_4_2_4 wokinfo
-~~~~~
-wokinfo -<option> [<EntityPath>]
-wokinfo -<option> <argument> [<EntityPath>]
-~~~~~
-Displays information about <EntityPath>. The information displayed is common to all the entities. If no <EntityPath> is specified, information about the current entity is returned.
-This command can be used to find the path of a file.
-Options:
-**-t** - Returns the type of entity (factory, warehouse, parcel, workbench, development unit).
-**-T** - Lists the types of files known in the entity.
-**-f** - Gets factory from path.
-**-N** - Gets the nesting path, i.e. where the current entity is nested.
-**-n** - Gets entity name.
-**-P** - Gets parcel from path.
-**-s** - Gets workshop from path.
-**-u** - Gets development unit from path.
-**-W** - Gets warehouse from path.
-**-w** - Gets workbench from path.
-**-x** - Tests if entity exists.
-**-d** <type> - Gets type definition.
-**-a** <type> - Gets type arguments.
-**-p** <type>:<filename> - Gets the path for a file, which is of the type type that depends on %File. In other words, the path for a file of this type depends on the file name, <filename>.
-**-p** <type> - Gets the path for a file, which is of the type <type> that is not %File dependent, for example EXTERNLIB.
-
-Examples
---------
-~~~~~
-wokinfo -p source:gp.cdl MODEL:GTI:gti:gp
-~~~~~
-Returns the path of the source file gp.cdl in the MODEL:GTI:gti:gp.
-~~~~~
-wokinfo -t MODEL:GTI:gti:gp
-~~~~~
-Returns the development unit.
-
-@subsubsection occt_wok_4_2_5 woklocate
-~~~~~
-woklocate -<option> <argument> [<WorkbenchPath>]
-woklocate -P [<WorkbenchPath>]
-~~~~~
-Using WorkbenchPath as the starting point, this command locates files associated with the development unit and specified by the argument argument.
-Options are:
-**-f** <Unit:Type:File> - Locates a file and gives its ID.
-**-p** <Unit:Type:File> - Locates a file and gives its path.
-**-u** <Unit> - Locates a development unit.
-**-P** - Displays all available WOK public types.
-
-Example
--------
-~~~~~
-woklocate <MyFile>
-~~~~~
-Displays the location of the file, MyFile.
-
-@subsubsection occt_wok_4_2_6 wokparam
-~~~~~
-wokparam -<option> [<EntityPath>]
-wokparam -<option> <argument> [<EntityPath>]
-~~~~~
-Queries system parameters such as variables and templates. For more information about parameters refer to the appendix *Parameters and EDL Files* at the end of this User’s Guide. If an <EntityPath> is specified this indicates the entity to which the command applies.
-Options:
-**-L** - Lists the directories used to search for the parameter files.
-**-C** - Displays the subclasses list.
-**-a** <TemplateName> - Gets arguments for the template TemplateName.
-**-e** <ParamName> - Evaluates the parameter ParamName.
-**-F** <ClassName> - Displays the files comprising the definition of the class ClassName.
-**-l** <Class> - Lists parameters concerning class (prefix) class.
-**-S** <FileName> - Finds the first file FileName in the list of directories cited afterwards.
-**-t** <Name> - Tests if the variable Name is set.
-**-v** <ParamName> - Displays the value of the parameter ParamName.
-**-s** <Name>=<Value> Reserved for advanced use. Sets the variable Name to value Value.
-**-u** <Name> Reserved for advanced use. Unsets the variable Name.
-
-Examples
---------
-~~~~~
-wokparam -L MODEL:GTI:gti
-~~~~~
-Returns a list of directories used for parameters by the gti workbench.
-~~~~~
-wokparam -S CSF.edl
-~~~~~
-Locates the nearest CSF.edl file used by the current entity.
-~~~~~
-wokparam MODEL:GTI:gti:gp -e %WOKUMake_Steps
-~~~~~
-Displays the value of the %WOKUMake_Steps parameter in the gp package. The %WOKUMake_Steps parameter contains a description of the steps used by umake.
-@subsubsection occt_wok_4_2_7 wokprofile
-~~~~~
-wokprofile
-wokprofile -<option> [<argument>]
-~~~~~
-Modifies session parameters. This command changes the mode of the current compilation and the profile of the current database. It also displays the current value of the session parameters. If no argument is specified, it displays the values of different parameters in the current session as well as the current position *wokprofile -v*.
-Options:
-**-b** - Returns the current database profile (OBJS, DFLT).
-**-d** - Switches to compilation with debug.
-**-m** - Returns the current compilation mode.
-**-o** - Switches to optimized compilation.
-**-s** - Returns the current station type
-**-v** - Switches to wokprofile verbose mode. In this mode all the parameters of the session are displayed. Running this command displays the current/changed profile.
-
-Examples
---------
-~~~~~
-wokprofile
-~~~~~
-Displays all the session parameters.
-~~~~~
-wokprofile -b
-~~~~~
-Displays the current database profile.
-~~~~~
-wokprofile -v -o
-~~~~~
-Switches to optimized compilation and displays the parameters of the current session after the change has been made.
-~~~~~
-wokprofile -o -v
-~~~~~
-Switches to optimized compilation and displays the parameters of the current session after the change has been made. Note that the order in which these options are specified does not affect the result.
-@subsection occt_wok_4_3 Services Associated with Factories
-There is a dedicated list of commands for the management of factories. The commands to create and destroy factories are reserved for the exclusive use of the site administrator.
-* *fcreate* Creates a factory.
-* *finfo* Displays information about the factory.
-* *frm* Deletes a factory if it is empty.
-
-@subsubsection occt_wok_4_3_1 fcreate
-*Reserved for administrator’s use*
-~~~~~
-fcreate -<option> [-D <Suffix>=<Value>]* <EntityPath>
-~~~~~
-Creates a factory. The name of the factory to create is specified by EntityPath. You can also specify the entity that will contain the entity to be created.
-Once the creation is completed, a file containing the parameters of the creation of the factory is created in the administration directory of the container to which the factory belongs.
-Parameters:
-The following parameters are mandatory when a factory is created:
-**Adm** - Path name for administration directory
-**Home** - Path name for home directory
-**Stations** - List of supported stations
-**DBMSystems** - List of supported dbms
-**Warehouse** - Name of factory warehouse.
-Options:
-**-P** - Propose defaults. Returns a list of default values for the parameters necessary for the creation of the factory. No entity is created if this option is used.
-**-d** Use default. Uses default values to create the factory.
-**-D**<Suffix>=<Value> - Defines parameter(s). Specifies the value to use for the given parameter(s) explicitly. This option can be used in conjunction with the –d option to take default values for all the mandatory parameters except the parameter(s) explicitly specified here.
-
-Examples
---------
-~~~~~
-fcreate -P NewFactoryName
-~~~~~
-Returns a list of default values for the parameters that are mandatory when creating a factory.
-~~~~~
-fcreate MyFactory -d -DHome=/fred/myfactory
-~~~~~
-Creates the factory MyFactory using default values for all mandatory parameters, except for Home, which is set to: /fred/myfactory
-
-@subsubsection occt_wok_4_3_2 finfo
-~~~~~
-finfo -<option> [<EntityPath>]
-~~~~~
-Displays details about the factory. If an EntityPath is specified this determines the factory to apply to. If no entity path is given, the command applies to the nearest factory.
-Options:
-**-s** - Displays a list of workshops in the factory.
-**-W** - Displays the name of the warehouse in the factory.
-**-S** - Displays the name of the source repository.
-Examples
---------
-~~~~~
-finfo -s
-~~~~~
-Displays a list of workshops in the nearest factory.
-~~~~~
-finfo MyFactory -W
-~~~~~
-Displays the name of the warehouse in MyFactory.
-@subsubsection occt_wok_4_3_3 frm
-*Reserved for administrator’s use*
-~~~~~
-frm <EntityPath>
-~~~~~
-Deletes the factory specified by EntityPath if it is empty.
-*You must not be in the factory you intend to destroy.*
-
-Example
--------
-~~~~~
-frm MyFactory
-~~~~~
-Deletes the factory MyFactory provided that it is empty.
-
-@subsection occt_wok_4_4 Services Associated with Warehouses
-A warehouse contains the parcels that are available in a factory. There is a dedicated list of commands for management of warehouses.
-The commands you use to create and destroy the warehouses are reserved for the exclusive use of the site administrator.
-*Wcreate* **Creates** a warehouse.
-*Winfo* **Displays** information about the warehouse
-*Wrm* **Deletes** a warehouse if it is empty.
-*Wdeclare* **Declares** a parcel in the warehouse.
-
-@subsubsection occt_wok_4_4_1 Wcreate
-*Reserved for administrator’s use.*
-~~~~~
-Wcreate [-<option>] -D<Suffix>=<Value>* <WarehouseName>
-Wcreate -<option> [-D <Suffix>=<Value>]* <WarehouseName>
-~~~~~
-Creates a warehouse. The name of the warehouse to create is given by *<WarehouseName>*. You can also specify the factory that will contain the warehouse.
-Once the creation is completed, a file containing the parameters of warehouse creation is in its turn created in the administration directory of the factory to which the warehouse belongs.
-Parameters:
-The following parameters are mandatory when a warehouse is created:
-**Adm** - Path name for administration directory.
-**Home** - Path name for home directory.
-**Stations** - List of supported stations.
-**DBMSystems** - List of supported dbms.
-Options:
-**-P** - (Propose defaults.) Returns a list of default values for the parameters necessary for the creation of a warehouse. No entity is created if this option is used.
-**-d** - (Use defaults.) Uses default values to create the warehouse.
-**-D** Suffix=Value (Define parameter.) Explicitly specifies the value to use for this parameter. This option can be used in conjunction with the –d option to take default values for all the mandatory parameters except the parameter(s) explicitly specified here.
-Examples
---------
-~~~~~
-Wcreate -P MyWarehouse
-~~~~~
-Returns a list of default values for the parameters that are mandatory when creating a warehouse.
-~~~~~
-Wcreate MyWarehouse -d
-~~~~~
-Creates the warehouse MyWarehouse using default values for all mandatory parameters.
-@subsubsection occt_wok_4_4_2 Winfo
-~~~~~
-Winfo -p [<EntityPath>]
-~~~~~
-Displays details about the warehouse and its contents. If an EntityPath is specified, this determines the warehouse to apply to.
-Options:
-**-p** Displays the parcels in the warehouse.
-Example
--------
-~~~~~
-Winfo -p
-~~~~~
-Displays a list of parcels in the current warehouse.
-@subsubsection occt_wok_4_4_3 Wrm
-*Reserved for Administrator’s Use.*
-~~~~~
-Wrm <EntityPath>
-~~~~~
-Deletes the warehouse specified by EntityPath if it is empty. *You should not be in the warehouse you intend to destroy.*
-Example
--------
-~~~~~
-Wrm MyWarehouse
-~~~~~
-Deletes the warehouse MyWarehouse provided that it is empty.
-@subsubsection occt_wok_4_4_4 Wdeclare
-*Reserved for administrator’s use*
-~~~~~
-Wdeclare -p<Parcel> [-d] [-D<ParamName>=<Value>]* <House>
-~~~~~
-Declares the parcel, Parcel. This command adds the parcel to the list of parcels available in the warehouse House.
-Note that a factory has a default list of deliveries (which are represented by parcels) available to it. This list only needs to be modified when moving to a new version of the delivery. This is done using the Wdeclare command, and then by editing the .edl file of the appropriate workshop.
-
-The following parameters are mandatory when declaring parcels:
-**Adm** - Path name for administration directory of a parcel.
-**Home** - Path name for home directory of a parcel.
-**Stations** - List of available stations.
-**DBMSystems** - List of available dbms.
-**Delivery** - Delivery name.
-Options:
-**-p** <Parcel> Defines the name of the parcel to declare. This name must be given with the option.
-**-d** Creates a parcel using defaults.
-**-P** Proposes defaults.
-
-Example
--------
-~~~~~
-Wdeclare -pMyParcel -d MyWarehouse
-~~~~~
-Adds the parcel MyParcel to the warehouse MyWarehouse.
-@subsection occt_wok_4_5 Services Associated with Parcels
-A parcel is a receptacle for development units. You use it to group together the units, which comprise a delivery unit. There is a dedicated list of commands for management of parcels. Only the site administrator should perform installation of parcels in a warehouse.
-pinfo **Displays** information about the contents of the parcel
-pinstall **Installs** the parcel in a Warehouse.
-@subsubsection occt_wok_4_5_1 pinfo
-pinfo -<option> [<ParcelPath>]
-Displays details about the contents of the parcel. If ParcelPath is specified this determines the parcel to apply to. If no parcel path is specified the command applies to the nearest parcel.
-Options:
-**-d** - Displays the delivery contained in the parcel.
-**-l** - Displays the development units in the parcel.
-**-a** - Lists the development units in the parcel together with their types.
-Examples
---------
-~~~~~
-pinfo -l MyParcel
-~~~~~
-Displays a list of units in the parcel MyParcel.
-
-@subsubsection occt_wok_4_5_2 pinstall
-*Reserved for administrator’s use*
-~~~~~
-pinstall <ParcelName>
-~~~~~
-Installs the parcel *<ParcelName>* in the current warehouse. The process of installing a parcel sets up various paths and variables to ensure that the application can locate necessary resources and so on.
-The administrator must perform *pinstall* for each platform used.
-
-Example
--------
-~~~~~
-pinstall MyParcel
-~~~~~
-Installs the parcel MyParcel in the current warehouse.
-
-@subsection occt_wok_4_6 Services Associated with Workshops
-A workshop is a tree of workbenches using the same parcel configuration. There is a dedicated list of commands for management of workshops. The commands to create and destroy workshops are reserved for the exclusive use of the site administrator.
-*screate* **Creates** a workshop.
-*sinfo* **Displays** information about the workshop
-*srm* **Deletes** a workshop if it is empty.
-
-@subsubsection occt_wok_4_6_1 screate
-*Reserved for administrator’s use*
-~~~~~
-screate [-<option>] {-D<Suffix>=<Value>}* <WorkshopName>
-screate -<option> <WorkshopName>
-~~~~~
-Creates a workshop, *<WorkshopName>*. You can also specify the factory that contains this workshop.
-Once the creation is completed, a file containing the parameters for the creation of the workshop is generated in the administration directory of the factory to which it belongs.
-
-The following parameters are mandatory when creating a workshop:
-**Adm** - Path name for administration directory.
-**Home** - Path name for home directory.
-**Stations** - List of supported stations.
-**DBMSystems** - List of supported dbms.
-**ParcelConfig** - List of parcels used.
-**Workbenchlist** - Path name for the list of workbenches.
-Options:
-**-P** (Propose defaults.) Returns a list of default values for the parameters necessary for the creation of a workshop. No entity is created if this option is used.
-**-d** (Use defaults.) Uses default values to create the workshop.
--D <Suffix>=<Value> (Define parameter.) Specifies the value to use for this parameter explicitly. This option can be used in conjunction with the –d option to accept default values for all the mandatory parameters except the parameter(s) explicitly specified here.
-Examples
----------
-~~~~~
-screate -P <WorkshopName>
-~~~~~
-Returns a list of default values for the parameters that are mandatory for creating a workshop.
-~~~~~
-screate MyFactory:MyWorkshop -d
-~~~~~
-Creates the workshop *MyWorkshop* in the factory *MyFactory*, using default values for all mandatory parameters.
-~~~~~
-screate -DParcelConfig=Parcel1,Parcel2 MyFactory:MyWorkshop -d
-~~~~~
-Creates the workshop *MyWorkshop* in the factory *MyFactory*, using default values for all mandatory parameters except for *ParcelConfig*, which is set to *Parcel1 Parcel2*.
-
-@subsubsection occt_wok_4_6_2 sinfo
-~~~~~
-sinfo -<option> [WorkshopName]
-~~~~~
-Displays details about the workshop. If *WorkshopName* is specified this determines the workshop this command is applied to. If no workshop is specified the command applies to the nearest workshop.
-Options:
-**-w** - Displays a list of workbenches in the workshop.
-**-p** - Displays the parcel configuration of the workshop.
-Example
--------
-~~~~~
-sinfo -w
-~~~~~
-Displays a list of workbenches in the nearest workshop.
-
-@subsubsection occt_wok_4_6_3 srm
-*Reserved for administrator’s use*
-~~~~~
-srm WorkshopName
-~~~~~
-Deletes the workshop <WorkshopName> if it is empty. *You must not be in the workshop you intend to destroy.*
-Example
--------
-~~~~~
-srm MyWorkshop
-~~~~~
-Deletes the workshop MyWorkshop provided that it is empty.
-
-@subsection occt_wok_4_7 Services Associated with Workbenches
-A workbench is the place where a developer (or a team of developers) works on a particular product. There is a dedicated list of commands for management of workbenches.
-*wcreate* **Creates **a workbench.
-*w_info* **Displays **information about a workbench.
-*wrm* **Deletes **a workbench if it is empty.
-*wmove* **Moves **a workbench to a new location.
-
-@subsubsection occt_wok_4_7_1 wcreate
-~~~~~
-wcreate -f <ParentWB> [-D <Suffix>=<Value>]* <WBName>
-wcreate -f <ParentWB> -P|d [-D <Suffix>=<Value>]* <WBName>
-wcreate -f <ParentWB> -P|d <WBName>
-~~~~~
-Creates the workbench <WBName> as a child of the workbench <ParentWB>. The result of this creation is a directory structure.
-Compared to the creation of other entities, creating a workbench requires an additional piece of information: you must specify the parent of the workbench to create.
-Once the creation is completed, a file containing the parameters of the creation of this workbench is created in the administration directory of the workshop that contains it.
-Parameters:
-The following parameters are mandatory when creating a workbench:
-**Adm** Path name for administration directory.
-**Home** Path name for home directory.
-**Stations** List of supported stations.
-**DBMSystems** List of supported dbms.
-
-Options:
-**-f** - Specifies the parent workbench.
-**-P** - (Propose defaults.) Returns a list of default values for the parameters necessary for the creation of the workbench. No entity is created if this option is used.
-**-d** - (Use defaults.) Uses default values to create the workbench.
-**-D** <Suffix>=<Value> - (Define parameter.) Specifies the value to use for this parameter explicitly. This option can be used in conjunction with the –d option to take default values for all the mandatory parameters except the parameter(s) explicitly specified here.
-
-Example
--------
-~~~~~
-wcreate -P WorkBenchName
-~~~~~
-Returns a list of default values for the mandatory parameters to create a workbench.
-~~~~~
-wcreate MyWorkbench -d
-~~~~~
-Creates the workbench MyWorkbench using default values for all mandatory parameters.
-**Note** The *–f* option of this command is not obligatory. The system administrator can create the root workbench of a workshop without specifying a parent workbench.
-
-@subsubsection occt_wok_4_7_2 w_info
-~~~~~
-w_info -option[Workbench]
-w_info -option argument[Workbench]
-~~~~~
-The *w_info* command is the exception to the common command syntax. The form w_info is used instead of winfo because the latter already exists as a tcl/tk command and cannot be reused as a name by WOK. If <Workbench> is specified, this determines the workbench to apply to. If no <Workbench> is specified, the nearest workbench is used.
-Using the tcl winfo command by mistake generates an error message, but does not cause any damage.
-Options:
-**-l** - Lists the development units in the workbench.
-**-a** - Lists the development units in the workbench along with their respective types.
-**-f** - Displays the parent workbench.
-**-A** - Lists all the ancestors of the workbench.
-**-k** - Lists visible toolkits.
-**-S** <arg> - Lists suppliers of the unit <arg> within the visibility of the workbench.
-**-S** <execname:partname> - Lists the suppliers of the component executable partname within an executable development unit execname.
-**-I** <arg1, arg2 ... argN> - Lists the development units, sorted by order of implementation dependency.
-Example
--------
-~~~~~
-w_info -S MyDevUnit
-~~~~~
-
-Returns a list of suppliers of the development unit MyDevUnit within the visibility of the current workbench.
-
-@subsubsection occt_wok_4_7_3 wrm
-~~~~~
-wrm Workbench
-~~~~~
-Deletes the workbench, provided that it is empty and has no children. You must not be in a workbench you intend to destroy.
-Example
--------
-~~~~~
-wrm MyWorkbench
-~~~~~
-Deletes MyWorkbench, provided that it is empty and has no children.
-
-@subsubsection occt_wok_4_7_4 wmove
-*Reserved for advanced use*
-wmove -f <NewParentWorkbench> <Workbench>
-Moves the *Workbench* (and its children), to a different parent *NewParentWorkbench* within the same workshop.
-Options:
-**-f** <argument> Specifies the new parent workbench.
-Example
--------
-~~~~~
-wmove -f MyOtherWorkbench MyWorkbench
-~~~~~
-Moves the *MyWorkbench* under *MyOtherWorkbench*.
-@subsubsection occt_wok_4_7_5 wprocess
-~~~~~
-wprocess <WorkbenchName> <options>
-~~~~~
-Allows automatic reconstruction of a workbench.
-
-Options:
-**-DGroups**=Obj,Lib,Exec - Selects groups Obj, Lib and Exec.
-**-DUnits **= MyUd1,MyUd2,... - Selects the development units MyUd1, MyUd2 etc.
-**-DXGroups **=Src,Deliv - Excludes groups Obj and Deliv.
-**-DXUnits**=MyUd1,MyUd2,... - Excludes units MyUd1, MyUd2 etc.
-**-B** <Profile> - Selects the extraction profile.
-**-f** - Forces all selected steps.
-**-d | -o** - Switches between debug and optimized modes.
-**-P** - Prints out the selected steps.
-**-S** - Silent mode (no print of the banner).
-**-L** - Logs output to MyUD_<step code>. Log in step administration directory. Valid group names are: Src, Xcpp, Obj, Dep, Lib, Exec, Deliv.
-
-Example
--------
-~~~~~
-wprocess -DGroups=Src,Xcpp,Obj,Lib,Exec
-~~~~~
-Compiles the whole workbench
-
-@subsection occt_wok_4_8 Services Associated with Development Units
-The development unit is the basic building block of development work in the WOK environment. It is the base component of Open CASCADE Technology architecture. For a list of available types of development units refer to the *Development Units* section. There is a dedicated list of commands for management of development units.
-
-ucreate **Creates** a development unit.
-uinfo **Displays** information about the development unit.
-urm **Deletes** a development unit.
-umake **Builds** a development unit.
-
-@subsubsection occt_wok_4_8_1 ucreate
-~~~~~
-ucreate [-<TypeCode>] <UnitName>
-ucreate -P
-~~~~~
-Creates a development unit named <UnitName> of type <TypeCode>.
-Once the creation is completed, a file containing the parameters of the creation of the development unit is generated in the administration directory of the workbench to which the development unit belongs.
-TypeCodes:
-**-p** - Creates a development unit of type package. This is the default option. Where no option is specified, a development unit of type package is created.
-**-n** - Creates a development unit of type nocdlpack.
-**-s** - Creates a development unit of type schema.
-**-t** - Creates a development unit of type toolkit.
-**-d** - Creates a development unit of type delivery.
-**-x** - Creates a development unit of type executable.
-**-f** - Creates a development unit of type frontal.
-**-r** - Creates a development unit of type resource.
-**-P** - Displays ucreate creation possibilities in format: <TypeCode> <TypeName>.
-Examples
---------
-~~~~~
-ucreate -p MyWorkbench:MyPackage
-~~~~~
-Creates the development unit *MyPackage* in *MyWorkbench*. The unit is of package type.
-
-@subsubsection occt_wok_4_8_2 uinfo
-uinfo -t|c [<UnitPath>]
-uinfo -f|F|p [-<FilterOption> [<Type>]]* [<UnitPath>]
-Displays details about the development unit. Where no <UnitPath> is specified, details of the current unit are displayed. Filter options are available for use in conjunction with the options -f, -F, -p to filter the file list. Combinations of filter options can be used.
-Note that the uinfo command is based on the results of construction using umake. As a consequence, the list of files displayed by uinfo is only valid if the construction has completed normally. Similarly, the list of files derived from the CDL is only valid if the CDLs of the unit have been translated successfully.
-Options:
-**-t** - Displays the type of the development unit as a string.
-**-c** - Displays the typecode of the development unit, i.e. a single character, as used by **ucreate** to indicate package (p), schema (s) and so on.
-**-f** - Displays a list of file names associated with the unit.
-**-F** - Displays a list of file names associated with the unit, together with their respective types. Types of files include for example: *source*, *library*, *executable*, and *pubinclude*. To display a full list of file types, use the command *ucreate*.
-**-p** - Displays the full paths of the files associated with the unit.
-Filter Options:
-**-T** - <Type> Displays files of type <Type> only.
-**-i** - Displays only *independent* files, i.e. files that are not specific to a DBMS, for example sources.
-**-s** - Displays only station dependent files.
-**-b** - Displays only DBMS dependent files.
-**-B** - Displays only files that are dependent on *both *DBMS and Station.
-**-l** - Displays only files that are local to the workbench.
-**-m** - Displays only missing files, i.e. files that are listed, but not found.
-**-e** - Displays only existing files, i.e. files that are listed and found.
-Examples
---------
-~~~~~
-uinfo -Fp
-~~~~~
-Displays the types, paths and names of all files associated with the unit.
-~~~~~
-uinfo -f -Tpubinclude MyWorkbench:MyUnit
-~~~~~
-Lists the names of the header files associated with the unit MyUnit which is in MyWorkbench.
-
-\@subsubsection occt_wok_4_8_3 urm
-~~~~~
-urm <UnitPath>
-~~~~~
-Deletes the development unit <UnitPath> with its directory structure and its files, even if the unit is referenced by another one.
-
-Example
--------
-~~~~~
-urm MyWorkBench:MyPack
-~~~~~
-Deletes the development unit *MyPack* found in *MyWorkBench*.
-
-@subsubsection occt_wok_4_8_4 umake
-~~~~~
-umake -S [<UnitPath>]
-umake [-f][<UnitPath>]
-umake [-f]-o<step> [-t<target>]* [-o<step> [-t<target>]*]*[<UnitPath>]
-umake [-f][-s <step>] [-e <step>][<UnitPath>]
-umake
-~~~~~
-Builds a development unit. The build process includes compilations, links, and various other actions, which make the development unit usable. The build process is specific for each type of development unit, refer to chapter 3 for details.
-The following properties apply:
-1. There are steps identified by a keyword.
-2. The steps involved and their content depends on the type of development unit being treated.
-3. You can ask for single step execution using the -o option.
-4. Unless explicitly requested using the –f option, the operations are carried out in those steps where necessary.
-5. Only the processed development unit is modified.
-
-Used without any arguments the *umake* command carries out all of the steps appropriate for the development unit to be constructed. Using keywords and arguments you can perform the build process step by step.
-
-Options:
-**-S** - Displays the list of steps.
-**-s** <step> - Starts the build process at the step specified.
-**-e** <step> - Ends the build process at the step specified.
-**-o** <step> - Only executes the step specified.
-**-t** <target> - Specifies the target to build.
-**-f** - Forces the build process, skipping the verification of dependencies.
-Example
--------
-~~~~~
-umake gp
-~~~~~
-Builds the gp package.
-
-Specifying Targets (-t)
------------------------
-The umake command is also used to specify build targets and extract C++ method prototypes. src, xcpp and obj units can be targeted. The syntax is explained below.
-For delivery units (for all options apart from *.list) the syntax is as follows:
-~~~~~
--\*.\* -t MyDU
-umake MyDeliv -olib.shared.build -tMyUD.
-~~~~~
-**src** This target computes a source file list as in the example below:
-~~~~~
-umake -o src MyUnit
-~~~~~
-**xcpp** Extracts C++ header files. For -xcpp.\* (with the exception of \*.fill), the syntax is as follows:
-~~~~~
-umake -o -xcpp.* -t MyPack_MyClass
-~~~~~
-You extract the method prototypes using the following command:
-~~~~~
-umake -o xcpp.template [-t<class>|-t<package>]
-~~~~~
-This syntax of *umake* command is only used with packages. It extracts the C++ prototypes of the methods of the classes contained in the package.
-The generated files are placed in the src directory of the current package. These files always have a .template suffix. With each extraction of a class, these files will contain all the methods of the class.
-Prototypes are extracted for:
- * Ordinary classes (non-instantiated)
- * Generic classes (including nested generic classes)
- * Package methods
-Classes, which are instantiations of generic classes, are not extracted. Nor are other CDL types (exceptions, alias, etc.) which have no user implementation.
-For each class, we extract the prototypes of:
- * Instance methods
- * Class methods
- * Constructors
-The extracted files are the following:
- * for an ordinary class C
- + C.cxx.template for the non-inline class methods.
- + C.lxx.template for the inline class methods.
- * for a generic class G
- * G.gxx.template for the non-inline class methods.
- * G.lxx.template for the inline class methods.
- * for a package method P
- * P.cxx.template for the non-inline package methods.
- * P.lxx.template for the inline package methods.
-**obj** Specifying the target, obj compiles the object files for one or more files. The syntax for -obj.* is as follows:
-~~~~~
-umake -o -obj.* -t MyPack_MyClass.cxx
-~~~~~
-In a package, the following command executes all construction steps up to and including obj, doing for each of them only what is strictly necessary:
-~~~~~
-umake -s obj
-~~~~~
-The following command will recompile all the primary sources of a package which are out of date:
-~~~~~
-umake -o obj
-~~~~~
-@subsubsection occt_wok_4_8_5 Customizing umake
-You can use three levels of umake customization for a development unit.
- * Compiler and link options, EXTERNLIB
- * Step definition
- * Tcl umake step implementation
-These different levels of complexity correspond to the needs of regular users and more advanced users.
-
-Modification of Compiler and Link Options and EXTERNLIB
--------------------------------------------------------
-Customization at this level involves setting parameters of existing umake steps using an .edl file. This file is taken into account each time umake is performed. It contains a series of assignments or appended variables used when creating the development unit. These commands can be preceded by instructions dedicated to the preprocessor in order to adjust its behavior within the actual context.
-EXTERNLIB uses resources contained in Open CASCADE Technology prerequisites. To avoid referencing the path of these resources more than one time, the user may use the component EXTERNLIB to include these resources automatically via the link. The file contains the name of parameters, which are set independently.
-The umake command does not generate actual dependencies. To avoid any cumbersome dependencies, for example, if you do not want the shareable library file for a package but the package enumeration only, use the INTERNLIB component listed in FILES, to get only the given dependencies.
-In practice, the generated file, <myUD>.ImplDep, in the /drv/adm directory, is copied into INTERNLIB. INTERNLIB contains lines of enumerations, as below:
-~~~~~
-Dependence 1
-Dependence 2
-...
-~~~~~
-The example below illustrates how you can modify your WOK compiler options. Refer to *Using EDL to Define WOK Parameters* for an example of how to set link options as well as for more details about available parameters and .edl files.
-~~~~~
--- File Name: Kernel_CMPLRS.edl
--- Copyright: Matra Datavision 1996
-#---------------------------------
-#// First, ensure that we only execute this file once
-\@ifnotdefined ( %Kernel_CMPLRS_EDL ) then
- \@set %Kernel_CMPLRS_EDL = **;
-#// Then set C++ compilation options, based on workstation type:
- \@if( %Station == *sil* ) then
-\@set %ModeOpt = * *;
- \@endif;
- \@if( %Station == *ao1* ) then
-\@set %ModeOpt = *-g *;
- \@endif;
- \@if( %Station == *hp* ) then
-\@string %CMPLRS_C_Options += * -Aa -D_HPUX_SOURCE +e*;
- \@endif;
-\@endif;
-
-Step Definition
----------------
-The WOK umake command uses a dependency tree. This dependency tree is a graph that shows the umake steps, their inputs and their dependencies. You use it to perform the build, for example to ensure that only files, which have changed, and the files, which depend on these modified files, are recompiled.
-This dependency tree is defined in an .edl file. The steps are listed in an order. Each is assigned a name and has its inputs specified. The output of one or more steps is the input to another step.
-The following steps are standard for WOK umakes: src, src.list, exec.comp and exec.link. Any new step that you insert into the tree must be associated with a tcl program, which will be responsible for performing the step. You supply these tcl programs. For more details of tcl programming refer to the examples below and also to the *Tcl Overview* section.
-The following example defines a umake dependency tree and introduces two new steps: exec.kerobj and exec.core. Each of these steps is then associated with a tcl program.
-~~~~~
--- File Name: DCube_WOKSteps.edl
-
-\@ifnotdefined (%DCube_WOKSteps_EDL) then
- \@set %DCube_WOKSteps_EDL = **;
- \@string %WOKSteps_ObjGroup += *obj.libs obj.arx obj.objs *;
----\@set %WOKUmake_Steps =**src obj.inc(src) objc.cgen(src) obj.comp(src, obj.cgen) obj.libs(src) obj.arx(obj.libs) obj.objs(obj.arx) obj.lib(obj.comp, obj.objs) obj.idep(obj.comp,src)*;
- \@set %WOKSteps_obj_libs = *DCube_Libs(src)*;
- \@set %WOKSteps_obj_arx = *WOKStep_LibExtract(obj.libs)*;
- \@set %WOKSteps_obj_objs = *DCube_Objs(obj.arx)*;
-\@set %WOKSteps_obj_lib = *WOKStep_DynamicLibrary(obj.comp, obj.objs)*;
- \@set %WOKSteps_toolkit_ListWith = *obj.comp obj.objs*;
-\@endif;
-~~~~~
-Tcl Step Implementation
-------------------------
-Customization at the tcl step level requires an understanding of the build process and the WOK dependency tree. Modification at this level is generally used to add elements to the build which are not described in the CDL. For example one possible use is to include external libraries or files into the final shareable library. Refer to *Writing Tcl Steps for a WOK Build* for more details.
-
-@subsection occt_wok_4_9 Source Management Services
-You use the source management services to integrate source files between a root workbench and one of its children. The services are related to a particular workshop.
-*wprepare* **Displays a report** of the files state in the current workbench (as compared with the files in the root workbench).
-*wstore* **Queues a report** for further integration and stores the related files.
-*wintegre* **Performs check-in operations** for requested files and updates the root workbench.
-*wnews* **Allows management and use** of data stored in the integration journal.
-*wget* **Imports source files** to the current workbench.
-
-@subsubsection occt_wok_4_9_1 wprepare
-~~~~~
-wprepare –wb <father workbench> [-ud <ud1,ud2,...,udN>] -o [<filename>]
-wprepare –wb <father workbench> [-ref][-ud <ud1,ud2,...,udN>] -o [<filename>]
-~~~~~
-Prepares a report for integration to a reference (root) Workbench. This command prints a comparison of the state of source files contained in the specified units, <ud1,ud2,...,udN,> of the current workbench.
-This workbench must be a direct descendant of the root workbench. If no unit names are specified, all the units in the workbench are processed. By default, the results of the comparison are printed to the standard output. The differences are computed in relation to the root workbench.
-For each file, the status is indicated as follows:
-\# The file has been modified.
-\= The file was found in the current workbench but was not modified.
-\- The file has been removed. In other words, the entry was deleted from FILES).
-\+ The file has been added. In other words, the entry has been added in FILES).
-Options:
-**-ref** - Creates a report that is used to initialize a base of source files. This report is used with the wintegre -ref command.
-**-ud** <ud1>, <ud2>, ..., <udN> - Specifies the list of development units to prepare for integration. Separate the unit names with a comma. If no unit names are specified, all the units in the workbench are processed.
-**-o** <fileName> - Writes the integration report to the specified file. By default, the report is displayed (i.e. written to standard output).
-**-wb** <The name of target workbench> - Specifies the name of target workbench. It should be one of father workbenches with attached integration queue.
-
-@subsubsection occt_wok_4_9_2 wstore
-~~~~~
-wstore –ls –wb <MasterWb>
-wstore -cat <ID>
-wstore [-trig] -rm <ID> [-f] –wb <MasterWb>
-wstore –create –wb <MasterWb>
-wstore [<FileName>]
-~~~~~
-This command manages the queue of pending reports. When a report is queued it is given a unique number also called a report-ID.
-Options:
-**<FileName>** - Adds a report from the file FileName to the report queue.
-**-trig** - Calls a tcl procedure after the report has been processed. This tcl procedure must be located in the admin directory of the workshop and the file must be named wstore_trigger.tcl. An example of a trigger can be found in the file *$env(WOK_LIBRARY)/wstore_trigger.example*.
-**-ls** - Lists pending reports, together with their owners and their IDs. This is a default option. If two files are found with the same name in the same development unit in two different reports the full path of each of these files is displayed.
-**-cat** <Report_ID> - Displays the contents of the report <Report_ID>.
-**-rm** - Removes a report from the report queue.
-**-f** - Forces deletion. This option must be used with the *-rm* option when you delete a report that you do not own.
-**-param** - List queue parameters associated with the workbench.
-**-create** –wb <MasterWb> -queue <any/dir> -type SCCS - Creates an integration queue associated with MasterWb workbench, queue should be located at any/dir and specify SCCS type of database.
-Possible options for –create are:
-*-queue* - Specify the name of directory under which queue is created
-*-type* - Specify the type of database (can be SCCS or RSC, SCCS by default)
-*-base* - Specify the location where to put the repository (only for SCCS database). Default behavior: creates repository in the adm directory of the master workbench.
-*-counter* - Specify the name of directory where the integration counter is located. Default behavior: creates subdirectory adm in directory created using –base option
-*-journal* - Specify the location of integration journal. Default behavior: : creates subdirectory adm in directory created using –base option
-*-welcome* - If increment contains new development units, by default store will refuse such increment. If you want to be able to add new units to MasterWb through integration mechanism use – welcome option.
-Example
--------
-~~~~~
-wstore ReportName –wb MasterWb
-~~~~~
-Queues the report ReportName and saves a copy of the files mentioned in the report. This copy will be used when the report is actually processed by the command *wintegre*.
-~~~~~
-wstore –wb MasterWb -f -rm Report_ID
-~~~~~
-Removes the report Report_ID from the queue, even if you do not own it.
-
-@subsubsection occt_wok_4_9_3 wintegre
-~~~~~
-wintegre [<reportID>] –wb <MasterWb>
-~~~~~
-Processes a report and removes it from the queue in the current workshop.
-Parameters:
-<reportID> - Number indicating the rank of the report in the integration queue. Use the command wstore –l to get this number.
-Options:
-**-ref** <BaseNumber> - Initializes the version of the elements in the repository.
-**-all** - Processes all the reports in the integration queue.
-**-wb** - Specify the integration queue of which workbench should be used
-**-norefcopy** - Updates the repository but not the target workbench.
-**-nobase** - Updates the target workbench but not the repository. This option is rather useful when copying a set of UDs from a workbench into another.
-**-param** - Shows the parameters’ current value.
-
-**Note** The -nobase and -norefcopy options are mutually exclusive.
-
-Examples
---------
-~~~~~
-wintegre -ref 2 1 –wb ref
-~~~~~
-Uses the report whose ID is 1 to initialize the ref workbench with BaseNumber equal to 2.
-~~~~~
-wintegre 1 –wb ref
-~~~~~
-Integrates the report whose ID is 1 to ref workbench.
-~~~~~
-wintegre -f 8 –wb ref
-~~~~~
-Forces the integration of report 8. Use the –f option if you want report 8 to be processed first.
-
-
-~~~~~
-wprepare -MyWb -o/tmp/MyReport
-wstore /tmp/MyReport (GetID say 3) –wb ref
-wintegre –wb ref -nobase 3
-~~~~~
-Edit the comment and modify */tmp/MyReport* if required with current workbench accessed from ref workbench.
-You may use the -nobase option adding the following line in the VC.edl file (Adm of the concerned file):
-~~~~~
-\@set %VC_TYPE = *NOBASE*;
-~~~~~
-@subsubsection occt_wok_4_9_4 wnews
-
-The command has the following syntax:
-~~~~~
-wnews [-x] [-from p1 -to p2] [-headers|-units|-comments|- all] [-command TclCmd]
-wnews -set markname [ -at p ]
-wnews -ls [-bydate]
-wnews -rm markname
-wnews -admin
-wnews -purge
-~~~~~
-The *wnews* command allows managing and using the data stored in the integration journal.
-The integration journal is updated via the command *wintegre* each time an integration is performed; it contains all the UDs and files concerned with the integration, as well as the comments provided by the developers (reports).
-Every integration is numbered and the associated files are archived with a specific version number.
-Marks can be set on specific zones of the integrations via the wnews command. A mark is a character string which does not contain any dash character (-) and is associated with an integration number. Several marks may point to the same number, but one mark may only point to one number.
-**Note** BEGIN and END are reserved mark names. You cannot use them.
-Options:
-**-from p1 -to p2** - Extracts a portion of the journal file between index p1 and p2, with p1 and p2 integration numbers or marks. If p1 is not specified, reports are extracted from the beginning of the journal file. If p2 is not specified, reports are extracted up to the end of the journal file.
-**-at p** - Places a mark at index p, with p being an integration number. If p is not specified, the mark is placed at the end of the journal.
-**-ls **[-bydate] - Lists the marks. If *-bydate* is specified mark are listed in the order they were created. Otherwise, they are listed in order according to their place in the journal file.
-**-rm** <markname> - Removes the mark *markname*.
-**-admin** - Displays the journal location, date and other information.
-**-purge** - Saves the journal file and creates a new empty one.
-
-Additional options:
-**-o file** <name> - Redirects output in file. This option is ignored if **-command** is specified.
-**-ws** <shop> - Uses journal of shop instead of the current one. shop must belong to the current factory.
-**-command**<MyCommand> _ Runs the command *Tcl MyComm* on the specified part of the journal. The syntax is the following: *proc MyComm { comments table args } { ...}* with **comments **being a string containing all the comments on the integration between n1 and n2, and **table**, a table indexed with the names of the concerned uds (each element of the table is a list of UD files with definition of their status and version). Additional arguments may be passed using userdata with the argument args containing *mydata1, mydata2*. Wok provides a similar procedure *wnews:cpwb*, which allows to copy UDs from one workbench into another.
-
-**Note** You may access the associated code of this command by typing **tclsh>cat $env(WOK_LIBRARY)/news_cpwb.tcl**
-
-For example, we can add the following to file *Me.tcl*:
-~~~~~
-proc MyComm {comments table args} {
-puts *comments = $comments*
-parray table
-puts *args = $args*
-return
-}
-~~~~~
-Then type the following commands:
-~~~~~
-> source Me.tcl
-> wnews -x -from n1 -to n2 -command MyComm -userdata wb1 wb2
-~~~~~
-
-Examples
---------
-~~~~~
-wnews -set BETA_V1.1 -at 345
-~~~~~
-Sets a mark on integration number 345
-~~~~~
-wnews -set RELEASED_V1.1_CLOSED
-~~~~~
-Sets a mark after the last integration performed
-~~~~~
-wnews -ls
-~~~~~
-Lists all the marks set in the journal
-~~~~~
-wnews -x -from INT_DEB -to INT_END -units
-~~~~~
-Gets all the UDs modified between integrations INT_DEB and INT_END. Integration numbers and marks may be mixed as in the following:
-~~~~~
-wnews -x -from INT_DEB -to 856 -comments
-wnews -x -from INT_DEB -to INT_END -comments
-~~~~~
-Gets all the comments from the integrations between *INT_DEB* and *INT_END*
-~~~~~
-source Mycommand.tcl
-wnews -x -from INT_DEB -to INT_END -command Mycommand
-~~~~~
-In a more elaborate way, a Tcl process may be called to get all information on the reports between *INT_DEB* and *INT_END*.
-~~~~~
-wnews -x -from n1 -to n2 -command wnews:cpwb –userdata w1,w2,[ulist, notes]
-~~~~~
-All modified files between n1 and n2 are copied from workbench w1 into workbench w2. New UDs are created in w2 if required If *ulist* is specified, only the UDs contained in this list are Processed. If notes is specified, all comments between n1 and n2 are written into this file.
-
-@subsubsection occt_wok_4_9_5 wget
-~~~~~
-wget [-l] –wh <MasterWb>
-wget [-f] –wb <MasterWb> [-ud <UnitName>] <SourceFile> [-v <Version>]
-wget [-f] –wb <MasterWb> [-ud <UnitName>] <SourceFile1>...<SourceFileN>
-~~~~~
-The *wget* command allows importing source files into the workbench. The files are fetched from the SCCS database of the factory. This operation is known as a check-out operation. You can specify one or more files or a unit name. By default, the latest version of the files is fetched.
-Options:
-**<SourceFile>** - Fetches a copy of the specified file.
-**-ud** <UnitName> Fetches all the source files of the development unit you specified.
-**-f** Forces existing files to be overwritten.
-**-v** <Version> Fetches <Version> of the file you specified.
-**-l** Lists the files of the development unit that can be copied (i.e. that you can **get**). This is a default option.
-Example
--------
-~~~~~
-wget –wb MasteWb –ud MyUd File1.cxx File2.hxx
-~~~~~
-Fetches the latest version of *File1.cxx* and *File2.hxx*.
-
-@subsubsection occt_wok_4_9_6 Installation Procedure
-
-In the new WOK model:
- * each workbench can have its own database
- * the version control environment variables are relative to the workbench.
-
-
-The following enumeration explains how to set up the source management environment for a workshop.
-1. Open the factory and the workshop.
-~~~~~
-> wokcd <factory:workshop> -P Adm
-~~~~~
-2. Define the environment variables for version control by editing the file *VC.edl*. Your entries should respect the following syntax:
-~~~~~
-\@set %VC_TYPE=”SCCS”
-\@set %VC_ROOT=”/dirA/dirB/.../<MyDir>”
-~~~~~
-
-3. Reopen the workbench that you want to connect to the database.
-~~~~~
-> wokcd <factory:workshop:workbench>
-~~~~~
-4. Create SCCS database associated with workbench.
-~~~~~
-> wstore –create –wb <factory:workshop:workbench> -queue <PathToQueue>
-~~~~~
-5. Create a report associated with the root workbench.
-~~~~~
-> wprepare –wb <workbench> -o ref.report
-~~~~~
-6. Queue this report.
-~~~~~
-> wstore –wb <workbench> ref.report
-~~~~~
-7. Perform the actual creation of the SCCS database.
-~~~~~
-> wintegre –wb <workbench> < BaseNumber >
-~~~~~
-Here <BaseNumber> is the first digit of the SCCS version numbers.
-
-@subsubsection occt_wok_4_9_7 Integration Procedure
-
-To integrate, proceed as follows:
-1. Create the report for the current workbench.
-~~~~~
- > wprepare –wb MasterWb -o MyReport
-~~~~~
-2. If necessary, edit this report to remove lines and append comments. Comments should begin with -- (double hyphen).
-3. Queue the report and store the files.
-~~~~~
-> wstore –wb MasterWb MyReport
-~~~~~
-By this step, all the files you have modified have been stored and the report has been queued. You can continue with modifying these files.
-
-4. Examine the state of the integration queue to get the ID of your report.
-~~~~~
-> wstore –wb MasterWb -ls
-~~~~~
-5. Perform the integration and be sure you can write in the root workbench. This operation is usually reserved for the workshop administrator.
-~~~~~
-> wintegre –wb MasterWb [ID]
-~~~~~
-
-@subsection occt_wok_4_10 Session Services
-
-A single session service is also available to allow you to query WOK.
-*Sinfo* command returns details of the WOK session.
-~~~~~
-Sinfo -option
-~~~~~
-Options:
-**-F** Gets factory list
-**-f** Gets current factory
-**-s** Gets current workshop
-**-w** Gets current workbench
-**-u** Gets current development unit
-**-t** <entity_path> Gets the entity type
-**-E** Reserved for internal use. Gets known Entity List
-**-N** Reserved for internal use. Gets known Entity Names
-
-Example
--------
-~~~~~
-Sinfo -F
-~~~~~
-Returns a list of WOK factories.
-
-@subsubsection occt_wok_4_10_2 Convenience Aliases
-
-To ease the upgrade to the new version of WOK a number of aliases, compatible with the old version, have been set up. These convenience aliases include:
-**fcd** - Moves to the specified factory.
-**scd** - Moves to the specified workshop.
-**wcd** - Move to the src directory of the specified development unit.
-**wdrv** - Move to the drv/DBMS/Station directory of the current development unit.
-**wls** - List the development units in the current workbench.
-**wsrc** - Move to the src directory of the current development unit.
-
-@section occt_wok_5 Using the Graphic Interface
-The following is an overall description of the IWOK main menu bar. Please, refer to the on-line help to get more detailed information on the various applications accessed via the graphic interface.
-@subsection occt_wok_5_1 Main menu bar
-
-
-@subsubsection occt_wok_5_1_1 Menus
-The main menu bar contains three menus:
- * **File** to exit the iwok session,
- * **Windows** to display all windows created in the session,
- * **Help** to display the associated on-line help.
-
-@subsubsection occt_wok_5_1_2 Application icons
-The four icons on the left are used to access applications:
- * **wprepare**, allows preparing the integration queue being associated with a given workshop,
-
- * **umake**, gives access to all available umake options plus compilation options,
-
- * **CDL browser**, provides information on the class structure or translated classes,
-
- * **parameters**, allows displaying and editing all EDL files.
-
-
-**Note:** for further information on CDL, refer to the CDL Reference Manual.
-
-@subsubsection occt_wok_5_1_3 Display management
-Click on the Matra Datavision logo to either display or not the session in a window just below the main menu bar.
-You may choose to display icons in the window, either in **columns**, with the **last modified first**, by **date and size**, or in **rows**.
-Use the **go up** icon to navigate through the session and **wokcd** to update the window where the session was started.
-
-
-The field **Location **gives the exact address of the item in the session. Use the arrow on the right to select already visited addresses.
-
-@subsection occt_wok_5_2 Popup menus
-Two types of popup menus may be accessed according to the context. Just click MB3 to display the popup menu.
-Click on an item in the left window to get the popup menu providing access to applications.
-
-In the right window you get the selection popup menu for the item types:
-
-
-@section occt_wok_6 Appendix A. Using the Emacs Editor
-
-WOK is operated using the editor Emacs. Emacs is not provided in the Open CASCADE Technology distribution but is available from http://www.gnu.org/software/emacs/#Releases
-A CDL mode has been created for Emacs. The .el file for this mode is not provided in the distribution, but is available on request from OPEN CASCADE.
-List of Keys and their Bindings in cdl Mode
--------------------------------------------
-
-|C-c |Command prefix |
-|TAB | cdl-tab |
-|DEL | backward-delete-character-untabify |
-|ESC | Command prefix |
-|C-c C-x | cdl-new-exception |
-|C-c C-e | cdl-new-enumeration |
-|C-c C-b | cdl-new-buffer |
-|C-c C-p | cdl-new-package |
-|C-c C-r | cdl-new-rubric |
-|C-c C-c | cdl-new-class |
-|C-c f | cdl-fill-mode |
-|C-c s | cdl-structure |
-|C-c t | cdl-tabsize |
-|C-c e | cdl-comment-end |
-|ESC k | cdl-find-class |
-|ESC q | cdl-comment-fill |
-|ESC TAB | cdl-untab |
-|ESC-RET | cdl-raw-newline |
-
-@section occt_wok_7 Appendix B. Parameters and EDL Files
-@subsection occt_wok_7_1 EDL language
-@subsection occt_wok_7_1_1 Key Concepts
-
-EDL is a script-like programming language.
-
-**Comment** - text, preceded by two hyphens.
-~~~~~
--- Comment text....
-~~~~~
-**Identifier** - any combination of characters in the ranges A-Z, az, 0-9 and _ (underscore).
-**Variable** - an identifier preceded by % (percent sign).
-**Actions** The following actions are available:
-~~~~~
-\@string
-\@set
-\@apply
-~~~~~
-**Execution** *\@uses* is an execution operator.
-**Input/Output** The following input/output operators are provided:
-~~~~~
-\@file
-\@write
-\@close
-\@cout
-~~~~~
-**Conditional Operators** The following conditional operators are provided:
-~~~~~
-\@iffile
-\@ifdefined
-\@ifnotdefined
-\@ifnotfile
-\@if
-then
-\@else
-\@endif
-~~~~~
-
-**Operators** The following operators are available:
-~~~~~
-==
-!=
-||
-\&\&
-file
-notfile
-defined
-notdefined
-~~~~~
-**Templates** The following template commands/keywords are available:
-~~~~~
-\@template
-is
-\@end
-\@addtotemplate
-\@cleartemplate
-~~~~~
-**Miscellaneous** The following miscellaneous commands exist:
-~~~~~
-\@verboseon
-\@verboseoff
-~~~~~
-
-@subsubsection occt_wok_7_1_2 Syntax
-The following conventions are used in the explanations below:
-| *<Variable>* | refers to a variable, for example: *%myvariable* |
-| *<Id>* | refers to an identifier, for example: *myidentifier* |
-| *“String”* | refers to a string of characters, for example: *“my string of characters”* |
-| *<Condition>* | refers to a condition, for example: *(%mytest == “ok”) || (%mytest == “good”)* |
-| *<Template>* | refers to the name of a template, for example: mytemplate. |
-|{} | indicates possible repetition of what is within the curly brackets. |
-
-\@subsubsection occt_wok_7_1_3 EDL Actions
-\@string
---------
-~~~~~
-\@string <Variable> = {<Variable> or “String”} ;
-\@string <Variable> += {<Variable> or “String”} ;
-~~~~~
-Concatenates the contents of the variables and strings on the right of the equals sign and assigns the result to the variable situated on the left. Using the operator ‘+=’ instead of ‘=’ adds the concatenation to the current contents of the variable on the left.
-
-\@set
-----
-~~~~~
-\@set <Variable> = “ String” ;
-~~~~~
-Sets <Variable> to the value “String”
-
-\@apply
-------
-~~~~~
-\@apply <Variable> = <Template> ;
-~~~~~
-Evaluates the template, <Template>, and sets <Variable> equal to this.
-
-
-\@uses
------
-~~~~~
-\@uses <Variable>;
-\@uses “ String”;
-~~~~~
-Runs an EDL file. The name of this file is either contained in the variable <Variable> or is given as a string, <String>.
-
-\@file
------
-~~~~~
-\@file <Id> <Variable> ;
-\@file <Id> “String” ;
-~~~~~
-Opens a file and associates it with the identifier <Id>. This <Id> identifies the file until it is closed. The name of the file is given as a string <String>, or using a variable <Variable>.
-
-\@write
-------
-~~~~~
-\@write <Id> <Variable> ;
-~~~~~
-Writes the contents of the variable out to a file indicated by the file <Id>. This <Id> is the identifier allocated to the file when is opened using \@file.
-
-\@close
-------
-~~~~~
-\@close <Id> ;
-~~~~~
-Closes the file identified by <Id>. This <Id> is the identifier allocated to the file when is opened using \@file.
-
-\@cout
------
-~~~~~
-\@cout {<Variable> or “String”} ;
-~~~~~
-Concatenates the contents of the variables and strings and displays the result on standard out.
-
-\@iffile
--------
-~~~~~
-\@iffile ( <Variable> or “String”) then
-\@endif ;
-\@iffile ( <Variable> or “String”) then
-\@else
-\@endif ;
-~~~~~
-Checks for the existence of a file, the name of which is given in the string ‘String”, or else contained in the variable <Variable>.
-If the file exists, the instructions contained in the ‘then’ loop are executed up to the *\@endif*, (or an \@else if one is found before the \@endif ).
-If the files do not exist, the ‘else’ loop is executed (if one exists).
-
-\@ifnotfile
-----------
-~~~~~
-\@ifnotfile ( <Variable> or “String”) then
-\@endif ;
-\@ifnotfile ( <Variable> or “String”) then
-\@else
-\@endif ;
-~~~~~
-Checks for the existence of a file, the name of which is given in the string ‘String”, or else contained in the variable <Variable>.
-If the file does not exist, the instructions contained in the ‘then’ loop are executed up to the \@endif, (or an \@else if one is found before the \@endif).
-If the file does exist, the ‘else’ loop is executed (if one exists).
-
-\@ifdefined
-----------
-~~~~~
-\@ifnotdefined ( <Variable> or <Template>) then
-\@endif ;
-\@ifnotdefined ( <Variable> or <Template>) then
-\@else
-\@endif ;
-~~~~~
-Checks for the existence of a variable or template, the name of which is given by <Template>, or else contained in the variable <Variable>.
-If a variable or a template by this name exists the instructions contained in the ‘then’ loop are executed up to the \@endif, (or an \@else if one is found before the \@endif).
-If neither a variable nor a template exists, the ‘else’ loop is executed (if one exists).
-
-
-\@ifnotdefined
--------------
-~~~~~
-\@ifnotdefined ( <Variable> or <Template>) then
-\@endif ;
-\@ifnotdefined ( <Variable> or <Template>) then
-\@else
-\@endif ;
-~~~~~
-Checks for the existence of a variable or template, the name of which is given by <Template>, or else contained in the variable <Variable>.
-If neither a variable nor a template by this name exists the instructions contained in the ‘then’ loop are executed up to the \@endif, (or an \@else if one is found before the \@endif).
-If a variable or a template does exist, the ‘else’ loop is executed (if one exists).
-
-\@if
------
-~~~~~
-\@if (<Condition>) then
-\@endif ;
-\@if (<Condition>) then
-\@else
-\@endif ;
-~~~~~
-Tests a condition.
-If the condition is true the instructions in the ‘then’ loop are executed up to the \@endif, (or an \@else if one is found before the \@endif).
-If the condition is false, the ‘else’ loop is executed (if one exists).
-
-\@template
----------
-~~~~~
-\@template <Template> (<Variable>, ... , <Variable>) is
- $ text...
- .
- .
- $ text...
-\@end;
-~~~~~
-Creates a template, which is a definition that contains variables. The variables on which a template relies are given in parentheses, following the name of the template. These variables are used to evaluate the template, and are referred to as ‘variables of evaluation’. When a template is evaluated (see \@apply) the variables in its definition are replaced by the current values of the ‘variables of evaluation’.
-A template is re-evaluated each time it is used.
-
-\@addtotemplate
---------------
-~~~~~
-\@addtotemplate <Template> is
- $ text
- .
- .
- $ text
-\@end;
-Adds the specified lines to an existing template.
-
-\@cleartemplate
---------------
-~~~~~
-\@cleartemplate <Template> ;
-~~~~~
-Removes all the lines of a template.
-
-\@verboseon
-----------
-~~~~~
-\@verboseon ;
-~~~~~
-Turns on the verbose mode, such that lines of text are displayed on standard out when you run EDL files.
-
-\@verboseoff
------------
-~~~~~
-\@verboseoff ;
-~~~~~
-Turns off the verbose mode, such that lines of text are not displayed on standard out when you run EDL files.
-
-@subsubsection occt_wok_7_1_4 EDL Conditions
-Conditions are used with *\@if* commands. Complex and simple conditions are available. The syntax is similar to C++.
-Simple Conditions
------------------
-Simple conditions test for equality, the existence of a particular file and so on. The general format is:
-~~~~~
-\@if(<Condition>) then
-...
-~~~~~
-The syntax of simple conditions is given below.
-~~~~~
-<Variable> == “String” -- (equals)
-<Variable> != “String” -- (does not equal)
-defined(<Variable>) -- (see \@ifdefined)
-defined(<Template>) -- (see \@ifdefined)
-notdefined(<Variable>) -- (see \@ifnotdefined)
-notdefined(<Template>) -- (see \@ifnotdefined)
-file(<Variable>) -- (see \@iffile)
-file(“String”) -- (see \@iffile)
-notfile(<Variable>) -- (see \@ifnotfile)
-notfile(“String”) -- (see \@ifnotfile)
-~~~~~
-Complex conditions
-------------------
-
-Complex conditions take into account the results of other conditions. Complex conditions use the operators || (logical OR) or the operator (logical AND). There are no restrictions on the formulation of these conditions:
- (Simple condition) operator (Simple condition)
- (Complex condition) operator (Simple condition)
- (Simple condition) operator (Complex condition)
- (Complex condition) operator (Complex condition)
-
-For example,
-~~~~~
-\@if ((%a == “0” && %b == “1” && %c == “1”) || %d == “1” && ((%a == “1”) && %b == “1”)) then
- \@cout “CONDITION TRUE”;
-\@else
- \@cout “CONDITION FALSE”;
-\@endif;
-~~~~~
-
-@subsection occt_wok_7_2 WOK Parameters
-WOK parameters are defined using EDL. There are two types of EDL parameters: Variables and Templates.
-Variables have a ‘fixed’ value. By contrast a template relies on the values of other variables, and must re-evaluate itself each time it is used.
-@subsubsection occt_wok_7_2_1 Classes of WOK Parameters
-WOK parameters are grouped according to their class. The following classes exist:
-| CODEGEN | Code generator options, for example options for lex and yacc. |
-| CMPLRS | Compiler options. |
-| LDAR | Archive creation options. |
-| ARX | Archive extraction options. |
-| LDEXE | Executable linker options. |
-| LDSHR | Shared linker options. |
-
-@subsubsection occt_wok_7_2_2 Defining WOK Parameters
-The WOK distribution includes a base configuration for each class of parameters. This base configuration is provided in the form of EDL files, one file per a class of parameters. Each file is named according to the parameter class:
-~~~~~
-<ParamClassName>.edl
-~~~~~
-This configuration file sets the values of all the parameters in the class.
-For example, consider a parameter class FOO. There are two variable parameters in this class: FOO_Shared and FOO_Name. These two parameters are assigned a value in the FOO.edl file. The file is given as an example below:
-~~~~~
--- standard protection against multiple execution
-\@ifnotdefined ( %FOO_EDL) then
-\@set %FOO_EDL = **;
-
--- set %FOO_Shared according to the platform
-\@if ( %LocalArch != *hp* ) then
-\@set %FOO_Shared = *libCPPExt.so*;
-\@endif;
-\@if ( %LocalArch == *hp* ) then
-\@set %FOO_Shared = *libCPPExt.sl*;
-\@endif;
-
--- set the FOO_Name parameter to FOO
-\@set %FOO_Name = *FOO*;
-\@endif;
-~~~~~
-
-Note that all the parameters in a class take the name of the class as a prefix to their own name. Parameters of type variable are also prefixed by % (percent symbol):
-~~~~~
-%ClassName_VariableParamName
-ClassName_TemplateParamName
-~~~~~
-A simplified template definition is given as an example below. This definition is based on the FOO parameters set in the previous example above.
-Let us define the variable parameter(s) to be used in the template and then the template itself:
-~~~~~
-\@set %FOO_Shared = *libCPPExt.so*;
-\@set %FOO_Name = *FOO*;
-
-\@template FOO_Load ( %FOO_Shared, %FOO_Name) is
-$ %FOO_Load_%FOO_Shared %FOO_Name
-\@end;
-~~~~~
-
-@subsubsection occt_wok_7_2_3 Redefining Parameters
-Occasionally you may want to redefine WOK parameters. For example, you can change the compiler options to force ANSI mode compilation, or redefine how external libraries are referenced.
-Before redefining anything, decide on the scope of the redefinition. Is the redefinition to apply to the whole factory, a single workshop, a workbench, or just a development unit? In some cases you may want to redefine parameters within a delivery unit, so that a parcel is delivered with particular options.
-The order in which redefinitions are applied (order of precedence) may mean your options are overwritten by subsequent redefinitions.
-
-Redefinition Files
-------------------
-Each entity can have an associated redefinition file for each class of parameters. A redefinition file is an EDL file. It always takes the name of the entity to which it belongs, followed by the name of the class of parameters that it applies to:
-~~~~~
-<EntityName>_<ParamClassName>.edl
-~~~~~
-For example, the file MyFactory_CMPLRS.edl redefines one of more of the parameters in the CMPLRS class. The scope of this redefinition is MyFactory. To be taken into account by WOK, this redefinition file must be created in the administration directory of the entity to which it belongs. To find out the pathname of this directory, use the command:
-~~~~~
-wokinfo -p admfile:<EntityName>_<ParamClassName>.edl <EntityPath>
-~~~~~
-To test whether the file exists actually, use the command:
-~~~~~
-wokinfo -p adminfile:WOK_LDAR.edl WOK=> /adv22/wok/adm
-~~~~~
-There is one exception to this rule for file placement. For a development unit, the redefinition file is treated as a *source *file, and consequently it must be located in the src directory of the unit. To find out the path of this directory, use the command:
-~~~~~
-wokinfo -p source:<UnitName>_<ParamClassName>.edl <UnitPath>
-~~~~~
-
-One of the most common reasons to redefine WOK parameters is to modify compiler options. To do this, for example to add a compile option to the package *MyPack*:
-* In the source directory of MyPk, create file *MyPk_CMPLRS.edl*
-* In this file add the definition:
-~~~~~
-\@string %CMPLRS_CXX_Options += * -DMyDefine=string *;
-~~~~~
-
-Order of Precedence for Parameter Redefinitions
------------------------------------------------
-WOK takes parameter (re)definitions into account in the following order.
-* WOK
-* Factory
-* Workshop
-* Parcels (within the Workshop configuration, in the order in which they are declared in the parcel configuration).
-* Workbench (in order of inheritance)
-* Development unit
-WOK provides commands to find out what parameter definitions (and redefinitions) are used, and in what order. You can see what compiler parameters are used by WOK in *CMPLRS.edl* file. To find this file, use the command:
-~~~~~
- wokparam -S CMPLRS.edl
-~~~~~
-Then run the command.
-~~~~~
-wokparam -F CMPLRS EntityPath
-~~~~~
-This command displays a list of all the definition files, for parameters of type compiler, that are taken into account for EntityPath. These file are listed in the order in which they are taken into account. The last definition is the one that is used.
-
-@subsection occt_wok_7_3 Using EDL to Define WOK Parameters
-@subsubsection occt_wok_7_3_1 Modification of Link Options - Example
-
-How to add a define to the compilation
--------------------------------
-To add a define for all C++ files compiled in the package *MyPackage*, *MyPackage_CMPLRS.edl* is declared in the development unit *MyPackage* This file contains:
-~~~~~
-\@string %CMPLRS_CXX_Options =
-%CMPLRS_CXX_Options * -DMYDEFINE*;
-~~~~~
-How to use a code generator**
-In this example, a C code generator is used, which takes the input *<file>.mygen* and generates a *<file>.c*. The step *obj.cgen* automatically recognizes all files with the extension mygen and uses the generator on these files. The resulting .c files are compiled by the step *obj.comp*.
-The file *MyUnit_CODEGEN.edl* is written in a nocdlpack development unit *MyUnit*. This file contains the following code:
-
-~~~~~
--- list of tools recognized by the step obj.cgen
--- the tool MYGEN is added
-\@ string %CODEGEN_Tools = %CODEGEN_Tools * CODEGEN_MYGEN*;
-
--- the tool MYGEN is called via the template CODEGEN_MYGEN_CmdLine
-
-\@set %CODEGEN_MYGEN_Template = *CODEGEN_MYGEN_CmdLine*;
-
--- the extension of files processed by MYGEN is mygen
-
-\@set %CODEGEN_MYGEN_Extensions = *foo.mygen*;
-
--- the tool MYGEN is the executable /usr/local/bin/mygen
-
-\@set %CODEGEN_MYGEN_Tool = * /usr/local/bin/mygen*;
-
--- the tool MYGEN produces a .c file
-
-\@template CODEGEN_MYGEN_Production ( %BaseName ) is
-$%BaseName.c
-\@end;
-
--- the command executed to construct the .c file is:
-
-\@template CODEGEN_MYGEN_CmdLine ( %CODEGEN_MYGEN_Tool,
-%Source, %BaseName, %OutputDir ) is
-$cd %OutputDir
-$%CODEGEN_MYGEN_Tool -f %Source -o %BaseName.c
-\@end;
-~~~~~
-
-@section occt_wok_8 Appendix C. Tcl
-@subsection occt_wok_8_1 Tcl Overview
-Tcl stands for ‘‘tool command language* and is pronounced ‘‘tickle*. It is actually two things: a language and a library.
-As a simple textual language, tcl is intended primarily for issuing commands to interactive programs such as text editors, debuggers, illustrators, and shells. It has a simple syntax and is also programmable, so tcl users can write command procedures to provide more powerful commands than those in the built-in set.
-As a library package, tcl can be embedded in application programs. The tcl library consists of a parser for the cl language, routines to implement the tcl builtin commands, and procedures that allow each application to extend tcl with additional commands specific to that application. The application program generates tcl commands and passes them to the tcl parser for execution. Commands may be generated by reading characters from an input source, or by associating command strings with elements of the application's user interface, such as menu entries, buttons, or keystrokes.
-
-For Linux platform it is possible to download Tcltk 8.5 or 8.6 from http://www.tcl.tk/software/tcltk/8.6.html
-For Windows platforn it is possible to download ActiveTcl 8.5 or 8.6 from http://www.activestate.com/activetcl/downloads
-
-A help application, tclhelp, is also provided with tcl and can be activated by command *tclhelp*.
-
-@subsection occt_wok_8_2 Tcl and WOK
-The tcl interpreter offers WOK the following advantages:
-an environment in which both WOK and UNIX commands are available,
-dynamic loading of WOK as it is needed,
-a high performance portable environment, in which the user can write customized procedures.
-The following tcl commands are most commonly used with WOK: *expr, foreach, glob, if, package, proc, puts, set, source* and *unlink*.
-
-Refer to the tcl documentation, or the tcl help application, for details of these and other tcl commands.
-@subsection occt_wok_8_3 Configuring Your Account for Tcl and WOK
-To have access to WOK you must modify the configuration files of your account as described below.
-@subsubsection occt_wok_8_3_1 The cshrc File
-To allow the C shell session to configure tcl add the following line to your .chsrc file:
-~~~~~
-source/<sun|ao1|sgi|hp>_SYSTEM/util_LOG/cshrc_TCL
-~~~~~
-To configure your account to allow access to WOK add the following line to your .cshrc file:
-~~~~~
-if(!$?WOKHOME) then
-setenv WOKHOME /YOURCONTAINER/wok-<version of wok>
-source /<sun|ao1|sgi|hp>_SYSTEM/util_LOG/cshrc_Wok
-~~~~~
-@subsubsection occt_wok_8_3_2 The tclshrc File
-To enable configuration of the tcl interpreter, add the following line to your .tclshrc if it exists (if not create one):
-~~~~~
-source $env(WOKHOME)/site/tclshrc_Wok
-~~~~~
-
-\@subsubsection occt_wok_8_3_3 The WOK_SESSIONID Variable
-The *WOK_SESSIONID* environment variable ensures that you start a new WOK session in the same state and with the same parameter values as your previous WOK session. This continuity is provided by using the same WOK_SESSIONID. Note that your *WOK_SESSIONID* does not change, unless you change it manually.
-Make sure that *WOK_SESSIONID* points to (a subdirectory of) your home directory.
-
-\@subsubsection occt_wok_8_3_4 Writing Tcl Steps for a WOK Build
-There are three advanced WOK commands available for writing umake steps in tcl:
- * *msgprint*
- * *stepoutputadd*
- * *stepaddexecdepitem*
-
-*msgprint [-i|-w|-e|-v|-V Class]* prints a message. The output is directed to a WOK internal process that is in charge of printing messages. The following options are available:
-| -i | Prints an information message. |
-| -w | Prints a warning message. |
-| -e | Prints an error message. |
-| -v | Prints a verbose message. |
-| -V<Class> | Prints a verbose message for class <Class>. |
-| -c | Prints context of message, i.e. the procedure that called it. |
-
-For example,
-~~~~~
-msgprint -e -c *CCLKernel_GetObjects::Execute* *Cannot locate object file : * $file;
-~~~~~
-Writes an error message, in format:
-~~~~~
-ERROR: CCLKernel_GetObjects::Execute - Cannot locate object file : MyFile
-~~~~~
-*stepoutputadd <options> <OutputFileID> [<filepath>]* adds an output file to the outputs of the step. This file is treated by subsequent steps in the same way as all the other output files of the step. The following options are available:
-
-| -p<path> | Specifies the path where the file is located. |
-| -L | Output can be located (default). |
-| -N | Not a WOK file. Cannot be located. |
-| -F | Physical file (i.e. resides on a disk somewhere). |
-| -M | File is a member of the unit being built (default). |
-| -X | File is not a member of the unit being built. Not a WOK file. Cannot be located. |
-| -P | File is produced by this umake step (i.e. WOK can delete it because it will be regenerated). |
-| -R | File is not produced by this umake step (i.e. WOK must not delete it because it can not be regenerated).
-| -S<StepID> | Reserved for advanced use. Specifies stepID. |
-| -V | Reserved for advanced use. Virtual ‘file’ (i.e. an MSEntity). This option is used for passing keywords between steps for example. |
-
-For example,
-~~~~~
-stepoutputadd -X -R -N -F /usr/myfiles/res.o -p /usr/myfiles/res.o
-~~~~~
-Adds the file */usr/myfiles/res.o* to the outputs of this step. Specifies that this file is not a WOK file, cannot be located automatically by WOK, and is not generated by this step. Here the full file path is used as the unique file identifier. This appears to be duplicated when it is also given as the physical location of the file.
-
-*stepaddexecdepitem <options> <InputFileID> <OutputFileID>* adds a dependency between one file and another. Typically when introducing external object libraries the files are set to be dependent on the CDL file. We do this because the CDL file changes rarely, so the external files are not needlessly reprocessed, but they are always included in the final executable. The following options are available:
-
-| -d | Adds a direct dependency (default). |
-| -i | Adds an indirect dependency. |
-
-For example,
-~~~~~
-stepaddexecdepitem -d MyInFile MyOutFile
-~~~~~
-States that the file *MyOutFile* depends directly on the file *MyInFile*.
-
-@subsubsection occt_wok_8_3_5 Components of a Tcl UMake Step
-
-Each tcl umake step has the following components:
-*HandleInputFile* - a filter: for each input file this component decides whether or not to accept the file. Argument: a file ID.
-*OutputDirTypeName* returns one of three strings, according to the dependency of the file:
- *tmpfile* = the file is independent (i.e. dependent only on its source).
- *dbtmpdir* = the file is dependent on the database profile
- *sttmpdir* = the file is dependent on the station profile
-Argument: none.
-*AdmFileType* returns one of three strings, according to the dependency of the file:
- *admfile* = the file is independent (i.e. dependent only on its source).
- *Dbadmfile* = the file is dependent on the database profile
- *stadmfile* = the file is dependent on the station profile
-Argument: none.
-*Execute* processes each input file that is out of date (i.e. has changed since it was last processed, or depends on a file that has changed since it was last processed). Typically this procedure takes the form of a *foreach* loop. Argument: a development unit to process and a list of one or more arguments.
-
-@subsubsection occt_wok_8_3_6 Sample Tcl Steps
-
-Sample 1
---------
-# CCLKernel_GetObjects.tcl
-proc CCLKernel_GetObjects::AdmFileType {} {
- return stadmfile;
-}
-proc CCLKernel_GetObjects::OutputDirTypeName {} {
- return sttmpdir;
-}
-proc CCLKernel_GetObjects::HandleInputFile { ID } {
- scan $ID *%\[^:\]:%\[^:\]:%\[^:\]* unit type name
- return 1;
- switch [file extension $name] {
-.cdl {
- return 1;
- }
- default {
- return 0;
- }
- }
-}
-proc CCLKernel_GetObjects::Execute { unit args } {
- msgprint -i -c *CCLKernel_GetObjects::Execute*
- *Processing unit : $unit*;
- msgprint -i -c *CCLKernel_GetObjects::Execute*
- set failed 0;
- set inid [lindex $args 0]
- foreach file { Frontal_Ccal_Init_Request.o Frontal_Ccal_Send_Request.o \
-Frontal_Ccal_sd.o Frontal_Get_Response.o Frontal_Ccal_Connect.o } {
-set resid *Frontal:object:$file*
-set path [woklocate -p $resid]
-if { $path == ** } {
- msgprint -e -c *CCLKernel_GetObjects::Execute*
-*Cannot locate object file : * $file;
- set failed 1;
-} else {
- msgprint -i -c *CCLKernel_GetObjects::Execute* *Add
-object $file at * $path
- stepoutputadd -X -R -L -F $resid
- stepaddexecdepitem -d $inid $resid
- }
-}
-if { [wokparam -e %Station] == *sun* } {
- set file *risc_return.o*
- set resid *CCLKernel:source:$file*
- set path [woklocate -p $resid]
-## set path */adv_23/wb/kl/Kernel7/prod/EngineStarter/
-src/risc_return.o*
- msgprint -i -c *CCLKernel_GetObjects::Execute* *Add
-object $file at * $path
- stepoutputadd -X -R -N -F $path -p $path
- stepaddexecdepitem -d $inid $path
-}
-set home [wokparam -e %Ilog_Home]
-if { $home == ** } {
- msprint -c *CCLKernel_GetObjects::Execute* -e *Cannot
-evaluate parameter : %Ilog_Home
- return 1;
-}
-foreach file { llstdio.o llfloat.o llfloat31.o cfix.o
-lelisp.o getgloba.o cload.o } {
- set path *$home/o/$file*
- msgprint -i -c *CCLKernel_GetObjects::Execute* *Add
-object $file at * $path
- stepoutputadd -X -R -N -F $path -p $path
- stepaddexecdepitem -d $inid $path
-}
-set file *lelisp31bin.o*
-set path *$home/lelisp31bin.o*
-msgprint -i -c *CCLKernel_GetObjects::Execute* *Add
-object $file at * $path
-stepoutputadd -X -R -N -F $path -p $path
-stepaddexecdepitem -d $inid $path
-if { $failed } {return 1;}
-return 0;
-}
-
-Sample 2
---------
-# File Name: CCLKernel_core.tcl
-proc CCLKernel_core::AdmFileType {} {
- return stadmfile;
-}
-proc CCLKernel_core::OutputDirTypeName {} {
- return sttmpdir;
-}
-proc CCLKernel_core::HandleInputFile { ID } {
- scan $ID *%\[^:\]:%\[^:\]:%\[^:\]* unit type name
- switch $type {
-executable {
- return 1;
-}
- }
- switch $name {
-CCL_lelisp.ll {
- return 1;
- }
-}
- return 0;
- }
-proc CCLKernel_core::Execute { unit args } {
- global WOK_GLOBALS env
-msgprint -i -c *CCLKernel_core::Execute* *Processing unit : $unit*;
- msgprint -i -c *CCLKernel_core::Execute*
- set workbench [wokinfo -N $unit]
- set unitname [wokinfo -n $unit]
- set failed 0;
- set lispbin **
- set lispfile **
- set lispbinid **
- set lispfileid **
- foreach ID $args {
-scan $ID *%\[^:\]:%\[^:\]:%\[^:\]* Unit type name
-switch $type {
- executable {
- set lispbinid $ID
- set lispbin [stepinputinfo -p $ID]
- }
-}
-switch $name {
-CCL_lelisp.ll {
-set lispfileid $ID
-set lispfile [stepinputinfo -p $ID]
-}
-}
-}
-if { $lispfile == **} {
-set lispfileid *CCLKernel:source:CCL_lelisp.ll*;
-set lispfile [woklocate -p $lispfileid $workbench]
-}
-if { $lispbin == **} {
-msgprint -e -c *CCLKernel_core::Execute* *Cannot find lelispbin in input*
-return 1;
-}
-msgprint -i -c *CCLKernel_core::Execute* *Using lelisp.bin at * $lispbin
-msgprint -i -c *CCLKernel_core::Execute*
-set config *[wokparam -e %Ilog_Home]/config*
-set tmpdir [wokinfo -p sttmpdir:. $unit]
-set output [wokinfo -p executable:. $unit]
-set lelisppointbin [wokinfo -p executable:lelisp.bin $unit]
-unlink -nocomplain $lelisppointbin
-link -sym $lispbin $lelisppointbin
-msgprint -i -c *CCLKernel_core::Execute* *Setting Environment*
-set WOK_GLOBALS(setenv_proc,tcl) 1
-wokenv -s
-set WOK_GLOBALS(setenv_proc,tcl) 0
-set olddir [pwd]
-cd [wokinfo -p source:. $unit]
-set FrontSIZE *-stack 12 -code 1500 -heap 2048 -number 0 -vector 32 -string 50 -symbol 30 -float 0 -cons *
-msgprint -i -c *CCLKernel_core::Execute* *Exec : $config $tmpdir $lispbin $lispfile $output $FrontSIZE 8*
-puts *exec /bin/env \\
-COREDIR=$output \\
-WBPACKAGE=[wokinfo -n $unit] ILOG_LICENSE_FILE=[wokparam -e %Ilog_LicenseFile] \\
-CSF_EngineStarterList=/usr/local/etc/
-EngineStarter.Hosts \\
-ILOG_LICENSE_FILE=[wokparam -e %Ilog_LicenseFile] \\
-\*FrontSIZE=$FrontSIZE\* \\
-$config $tmpdir $lispbin $lispfile $output $FrontSIZE 8*
-msgprint -i -c *CCLKernel_core::Execute* [eval *exec /bin/env \\
-COREDIR=$output \\
-WBPACKAGE=[wokinfo -n $unit] \\
-ILOG_LICENSE_FILE=[wokparam -e %Ilog_LicenseFile] \\
-CSF_EngineStarterList=/usr/local/etc/ EngineStarter.Hosts \\
-\*FrontSIZE=$FrontSIZE\* \\
-$config $tmpdir $lispbin $lispfile $output $FrontSIZE 8*]
-stepoutputadd -P $unitname:corelisp:$unitname.core
-stepaddexecdepitem -d $lispbinid $unitname:corelisp:$unitname.core
-stepaddexecdepitem -d $lispfileid
-$unitname:corelisp:$unitname.core
-cd $olddir
-return 0;
-}
\ No newline at end of file
Extended Data Exchange (XDE) {#user_guides__xde}
============================
-@section occt_1819379545_842050006 Introduction
-@subsection occt_1819379545_8420500061 Overview of the Extended Data Exchange (XDE)
-This manual explains how to use the Extended Data Exchange (XDE). It provides basic documentation on setting up and using XDE. For advanced information on XDE and its applications, see our offerings on our web site at <a href="http://www.opencascade.com/support/training.html">http://www.opencascade.com/support/training.html</a> * *
+@section occt_xde_1_ Introduction
+@subsection occt_xde_1_1 Overview of the Extended Data Exchange (XDE)
+This manual explains how to use the Extended Data Exchange (XDE). It provides basic documentation on setting up and using XDE. For advanced information on XDE and its applications, see our offerings at <a href="http://www.opencascade.com/services/support/">on our web site</a>.
+
Based on document architecture, XDE allows processing of various types of data to and from external files.
-XDE is available for users of Open CASCADE Technology on all supported platforms (Linux, Windows).
-@subsubsection occt_1819379545_84205000611 Prerequisite
+
+XDE is available for users of Open CASCADE Technology on all supported platforms (Linux, Windows).
+
+@subsubsection occt_xde_1_1_1 Prerequisite
The Extended Data Exchange (XDE) component requires Advanced Shape Healing for operation.
-@subsubsection occt_1819379545_84205000612 Environment variables
+
+@subsubsection occt_xde_1_1_2 Environment variables
To use XDE you have to set the environment variables properly. Make sure that two important environment variables are set as follows:
- * CSF_PluginDefaults points to sources of %CASROOT%/src/XCAFResources ($CASROOT/src/XCAFResources).
- * CSF_XCAFDefaults points to sources of %CASROOT%/src/XCAFResources ($CASROOT/src/XCAFResources).
-@subsubsection occt_1819379545_84205000613 Basic terms
+ * *CSF_PluginDefaults* points to sources of *\%CASROOT%/src/XCAFResources ($CASROOT/src/XCAFResources)*.
+ * *CSF_XCAFDefaults* points to sources of *\%CASROOT%/src/XCAFResources ($CASROOT/src/XCAFResources)*.
+@subsubsection occt_xde_1_1_3 Basic terms
For better understanding of XDE, certain key terms are defined:
- * **Shape **A (simple) shape is a standalone shape, which does not belong to the assembly structure.
- * **Instance **An instance (of a shape) is a replication of another shape with a location that can be the same location or a different one.
-*Assembly *An assembly defines a construction that is either a root or a sub-assembly.
-@subsubsection occt_1819379545_84205000614 XDE Data Types
+* **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.
+@subsubsection occt_xde_1_1_4 XDE Data Types
The following types of data are currently supported:
* assemblies
* validation properties
* colors
* layers
It is also possible to add new types of data by using tools as prototypes. This makes XDE a basically extensible framework.
+
In addition, XDE provides reading and writing tools to read and write the data supported by STEP and IGES files.
-@subsubsection occt_1819379545_84205000615 XDE Organization
+@subsubsection occt_xde_1_1_5 XDE Organization
The basis of XDE, called XCAF, is a framework based on OCAF (Open CASCADE Technology Application Framework) and is intended to be used with assemblies and with various kinds of attached data (attributes). Attributes can be Individual attributes for a shape, specifying some characteristics of a shape, or they can be Grouping attributes, specifying that a shape belongs to a given group whose definition is specified apart from the shapes.
+
XDE works in an OCAF document with a specific organization defined in a dedicated XCAF module. This organization is used by various functions of XDE to exchange standardized data other than shapes and geometry.
-The Assembly Structure and attributes assigned to shapes are stored in the OCAF tree. It is possible to obtain TopoDS representation for each level of the assembly in the form of TopoDS_Compound or TopoDS_Shape using the API.
+
+The Assembly Structure and attributes assigned to shapes are stored in the OCAF tree. It is possible to obtain TopoDS representation for each level of the assembly in the form of *TopoDS_Compound* or *TopoDS_Shape* using the API.
+
Basic elements used by XDE are introduced in the XCAF sub-module by the package XCAFDoc. These elements consist in descriptions of commonly used data structures (apart from the shapes themselves) in normalized data exchanges. They are not attached to specific applications and do not bring specific semantics, but are structured according to the use and needs of data exchanges.
-The Document used by XDE usually starts as a TDocStd_Document.
-@subsubsection occt_1819379545_84205000616 Assemblies
+The Document used by XDE usually starts as a *TDocStd_Document*.
+
+@subsubsection occt_xde_1_1_6 Assemblies
XDE supports assemblies by separating shape definitions and their locations. Shapes are simple OCAF objects without a location definition. An assembly consists of several components. Each of these components references one and the same specified shape with different locations. All this provides an increased flexibility in working on multi-level assemblies.
+
For example, a mechanical assembly can be defined as follows:
-
-
-Figure 1. Assembly Description and View
+@image html /user_guides/xde/images/xde_image003.jpg "Assembly Description"
+@image latex /user_guides/xde/images/xde_image003.jpg "Assembly Description"
+
+
+@image html /user_guides/xde/images/xde_image004.jpg "Assembly View"
+@image latex /user_guides/xde/images/xde_image004.jpg "Assembly View"
+
XDE defines the specific organization of the assembly content. Shapes are stored on sub-labels of label 0:1:1. There can be one or more roots (called free shapes) whether they are true trees or simple shapes. A shape can be considered to be an Assembly (such as AS1 under 0:1:1:1 in Figure1) if it is defined with Components (sub-shapes, located or not).
-XCAFDoc_ShapeTool is a tool that allows you to manage the Shape section of the XCAF document. This tool is implemented as an attribute and located at the root label of the shape section.
-@subsubsection occt_1819379545_84205000617 Validation Properties
+
+*XCAFDoc_ShapeTool* is a tool that allows you to manage the Shape section of the XCAF document. This tool is implemented as an attribute and located at the root label of the shape section.
+
+@subsubsection occt_xde_1_1_7 Validation Properties
Validation properties are geometric characteristics of Shapes (volume, centroid, surface area) written to STEP files by the sending system. These characteristics are read by the receiving system to validate the quality of the translation. This is done by comparing the values computed by the original system with the same values computed by the receiving system on the resulting model.
+
Advanced Data Exchange supports both reading and writing of validation properties, and provides a tool to check them.
- <table>
- <tr>
- <td>
-
- </td>
- </tr>
- <tr>
- <td>
-
- </td>
- <td>
- 
- </td>
- </tr>
-</table>
-Figure 2. Validation Property Descriptions
+
+ @image html /user_guides/xde/images/xde_image005.jpg "Validation Property Descriptions"
+ @image latex /user_guides/xde/images/xde_image005.jpg "Validation Property Descriptions"
+
+
Check logs contain deviations of computed values from the values stored in a STEP file. A typical example appears as follows:
+Label Area defect Volume defect dX dY DZ Name
+0:1:1:1 312.6 (0%) -181.7 (0%) 0.00 0.00 0.00 "S1"
+0:1:1:2 -4.6 (0%) -191.2 (0%) -0.00 0.00 -0.00 "MAINBODY"
+0:1:1:3 -2.3 (0%) -52.5 (0%) -0.00 0.00 0.00 "MAIN_BODY_BACK"
+0:1:1:4 -2.3 (0%) -51.6 (0%) 0.00 0.00 -0.00 "MAIN_BODY_FRONT"
+0:1:1:5 2.0 (0%) 10.0 (0%) -0.00 0.00 -0.00 "HEAD"
+0:1:1:6 0.4 (0%) 0.0 (0%) 0.00 -0.00 -0.00 "HEAD_FRONT"
+0:1:1:7 0.4 (0%) 0.0 (0%) 0.00 -0.00 -0.00 "HEAD_BACK"
+0:1:1:8 -320.6 (0%) 10.9 (0%) -0.00 0.00 0.00 "TAIL"
+0:1:1:9 0.0 (0%) 0.0 (0%) -0.00 -0.00 0.00 "TAIL_MIDDLE"
+0:1:1:10 -186.2 (0%) 4.8 (0%) -0.00 0.00 -0.00 "TAIL_TURBINE"
+0:1:1:11 0.3 (0%) -0.0 (0%) -0.00 -0.00 0.00 "FOOT"
+0:1:1:12 0.0 (0%) -0.0 (0%) 0.00 -0.00 -0.00 "FOOT_FRONT"
+0:1:1:13 0.0 (0%) 0.0 (0%) -0.00 0.00 0.00 "FOOT_BACK"
+
+
In our example, it can be seen that no errors were detected for either area, volume or positioning data.
-@subsubsection occt_1819379545_84205000618 Names
+
+@subsubsection occt_xde_1_1_8 Names
XDE supports reading and writing the names of shapes to and from IGES and STEP file formats. This functionality can be switched off if you do not need this type of data, thereby reducing the size of the document.
-@subsubsection occt_1819379545_84205000619 Colors and Layers
-XDE can read and write colors and layers assigned to shapes or their subparts (down to the level of faces and edges) to and from both IGES and STEP formats. Three types of colors are defined in the enumeration XCAFDoc_ColorType:
- * generic color (XCAFDoc_ColorGen)
- * surface color (XCAFDoc_ColorSurf)
- * curve color (XCAFDoc_ColorCurv)
- <table>
- <tr>
- <td>
-
- </td>
- </tr>
- <tr>
- <td>
-
- </td>
- <td>
- 
- </td>
- </tr>
-</table>
-Figure 3. Colors and Layers
-
-@section occt_1819379545_1936904462 Basic Concepts
-@subsection occt_1819379545_19369044621 Overview
-As explained in the last chapter, XDE uses TDocStd_Documents as a starting point. The general purpose of XDE is:
+@subsubsection occt_xde_1_1_9 Colors and Layers
+XDE can read and write colors and layers assigned to shapes or their subparts (down to the level of faces and edges) to and from both IGES and STEP formats. Three types of colors are defined in the enumeration *XCAFDoc_ColorType*:
+ * generic color *(XCAFDoc_ColorGen)*
+ * surface color *(XCAFDoc_ColorSurf)*
+ * curve color *(XCAFDoc_ColorCurv)*
+
+ @image html /user_guides/xde/images/xde_image006.jpg "Colors and Layers"
+ @image latex /user_guides/xde/images/xde_image006.jpg "Colors and Layers"
+
+
+
+@section occt_xde_2_ Basic Concepts
+@subsection occt_xde_2_1 Overview
+As explained in the last chapter, XDE uses *TDocStd_Documents* as a starting point. The general purpose of XDE is:
* Checking if an existing document is fit for XDE
* Getting an application and initialized document
* Initializing a document to fit it for XDE
* Querying and managing shapes
* Attaching properties to shapes
The Document used by XDE usually starts as a TDocStd_Document.
-@subsubsection occt_1819379545_193690446211 General Check
+@subsubsection occt_xde_2_1_1 General Check
Before working with shapes, properties, and other types of information, the global organization of an XDE Document can be queried or completed to determine if an existing Document is actually structured for use with XDE.
-To find out if an existing TDocStd_Document is suitable for XDE, use:
+
+To find out if an existing *TDocStd_Document* is suitable for XDE, use:
+~~~~~
Handle(TDocStd_Document) doc...
if ( XCAFDoc_DocumentTool::IsXCAFDocument (doc) ) { .. yes .. }
-If the Document is suitable for XDE, you can perform operations and queries explained in this guide. However, if a Document is not fully structured for XDE, it must be initialized. See 2.2.1 Initializing an XDE Document (Shapes).
-@subsubsection occt_1819379545_193690446212 Getting an Application or an Initialized Document
+~~~~~
+If the Document is suitable for XDE, you can perform operations and queries explained in this guide. However, if a Document is not fully structured for XDE, it must be initialized.
+
+@subsubsection occt_xde_2_1_2 Getting an Application or an Initialized Document
If you want to retrieve an existing application or an existing document (known to be correctly structured for XDE), use:
+~~~~~
Handle(TDocStd_Document) aDoc;
Handle(XCAFApp_Application) anApp =
XCAFApp_Application::GetApplication();
-anApp-NewDocument(;MDTV-XCAF;,aDoc);
-@subsection occt_1819379545_19369044622 Shapes and Assemblies
-@subsubsection occt_1819379545_193690446221 Initializing an XDE Document (Shapes)
-An XDE Document begins with a TDocStd_Document. Assuming you have a TDocStd_Document already created, you can ensure that it is correctly structured for XDE by initializing the XDE structure as follows:
+anApp->NewDocument(;MDTV-XCAF;,aDoc);
+~~~~~
+@subsection occt_xde_2_2 Shapes and Assemblies
+@subsubsection occt_xde_2_2_1 Initializing an XDE Document (Shapes)
+An XDE Document begins with a *TDocStd_Document*. Assuming you have a *TDocStd_Document* already created, you can ensure that it is correctly structured for XDE by initializing the XDE structure as follows:
+~~~~~
Handle(TDocStd_Document) doc...
Handle (XCAFDoc_ShapeTool) myAssembly =
XCAFDoc_DocumentTool::ShapeTool (Doc-Main());
-TDF_Label aLabel = myAssembly-NewShape()
-*NOTE **The method XCAFDoc_DocumentTool::ShapeTool* *returns the XCAFDoc_ShapeTool**. The first time this method is used, it creates the XCAFDoc_ShapeTool**. In our example, a handle is used for the TDocStd_Document**.*
-@subsubsection occt_1819379545_193690446222 Getting a Node considered as an Assembly
-To get a node considered as an Assembly from an XDE structure, you can use the Label of the node. Assuming that you have a properly initialized TDocStd_Document, use:
+TDF_Label aLabel = myAssembly->NewShape()
+~~~~~
+**Note** that the method *XCAFDoc_DocumentTool::ShapeTool* returns the *XCAFDoc_ShapeTool*. The first time this method is used, it creates the *XCAFDoc_ShapeTool*. In our example, a handle is used for the *TDocStd_Document*.
+
+@subsubsection occt_xde_2_2_2 Getting a Node considered as an Assembly
+To get a node considered as an Assembly from an XDE structure, you can use the Label of the node. Assuming that you have a properly initialized *TDocStd_Document*, use:
+~~~~~
Handle(TDocStd_Document) doc...
Handle(XCAFDoc_ShapeTool) myAssembly =
XCAFDoc_DocumentTool::ShapeTool (aLabel);
-In the previous example, you can also get the Main Item of an XDE document, which records the root shape representation (as a Compound if it is an Assembly) by using ShapeTool(Doc-Main()) instead of ShapeTool(aLabel).
-You can then query or edit this Assembly node, the Main Item or another one (myAssembly in our examples).
-*NOTE **For the examples in the rest of this guide, myAssembly* *is always presumed to be accessed this way, so this information will not be repeated.*
-@subsubsection occt_1819379545_193690446223 Updating the Assembly after Filling or Editing
+~~~~~
+In the previous example, you can also get the Main Item of an XDE document, which records the root shape representation (as a Compound if it is an Assembly) by using *ShapeTool(Doc-Main())* instead of *ShapeTool(aLabel)*.
+
+You can then query or edit this Assembly node, the Main Item or another one (*myAssembly* in our examples).
+
+**Note** that for the examples in the rest of this guide, *myAssembly* is always presumed to be accessed this way, so this information will not be repeated.
+
+@subsubsection occt_xde_2_2_3 Updating the Assembly after Filling or Editing
Some actions in this chapter affect the content of the document, considered as an Assembly. As a result, you will sometimes need to update various representations (including the compounds).
+
To update the representations, use:
+~~~~~
myAssembly-UpdateAssembly(aLabel);
+~~~~~
Since this call is always used by the editing functions, you need not apply it for such functions. However, you will need this call if special edits, not using XCAF functions, are used on the document.
-@subsubsection occt_1819379545_193690446224 Adding or Setting Top Level Shapes
+
+@subsubsection occt_xde_2_2_4 Adding or Setting Top Level Shapes
+
Shapes can be added as top-level shapes. Top level means that they can be added to an upper level assembly or added on their own at the highest level as a component or referred by a located instance. Therefore two types of top-level shapes can be added:
* shapes with upper level references
* free shapes (that correspond to roots) without any upper reference
-*NOTE **Several top-level shapes can be added to the same component.*
+
+**Note** that several top-level shapes can be added to the same component.
+
A shape to be added can be defined as a compound (if required), with the following interpretations:
- * The Shape is a compound
-According to the user choice, it may or may not be interpreted as representing an Assembly. If it is an Assembly, each of its subshapes defines a sub-label.
- * The Shape is not a compound
- The Shape is taken as a whole, without breaking it down.
+ * If the Shape is a compound, according to the user choice, it may or may not be interpreted as representing an Assembly. If it is an Assembly, each of its sub-shapes defines a sub-label.
+ * If the Shape is not a compound, it is taken as a whole, without breaking it down.
+
To break down a Compound in the assembly structure, use:
+~~~~~
Standard_Boolean makeAssembly;
// True to interpret a Compound as an Assembly,
// False to take it as a whole
aLabel = myAssembly-AddShape(aShape, makeAssembly);
+~~~~~
Each node of the assembly therefore refers to its sub-shapes.
+
Concerning located instances of sub-shapes, the corresponding shapes, (without location) appear at distinct sub-labels. They are referred to by a shape instance, which associates a location.
-@subsubsection occt_1819379545_193690446225 Setting a given Shape at a given Label
+
+@subsubsection occt_xde_2_2_5 Setting a given Shape at a given Label
A top-level shape can be changed. In this example, no interpretation of compound is performed:
+~~~~~
Standard_CString LabelString ...;
// identifies the Label (form ;0:i:j...;)
TDF_Label aLabel...;
// A label must be present
myAssembly-SetShape(aLabel, aShape);
-@subsubsection occt_1819379545_193690446226 Getting a Shape from a Label
+~~~~~
+
+@subsubsection occt_xde_2_2_6 Getting a Shape from a Label
To get a shape from its Label from the top-level, use:
-TDF_Label aLabel...
-// A label must be present
+~~~~~
+TDF_Label aLabel...
+// A label must be present
if (aLabel.IsNull()) {
- // no such label : abandon
-}
-TopoDS_Shape aShape;
-aShape = myAssembly-GetShape(aLabel);
-if (aShape.IsNull()) {
- // this label is not for a Shape
-}
-*NOTE: **If the label corresponds to an assembly, then the result is a compound.*
-@subsubsection occt_1819379545_193690446227 Getting a Label from a Shape
-To get a Label which is attached to a Shape from the top-level, use:
+ // no such label : abandon
+}
+TopoDS_Shape aShape;
+aShape = myAssembly->GetShape(aLabel);
+if (aShape.IsNull()) {
+ // this label is not for a Shape
+}
+~~~~~
+**Note** that if the label corresponds to an assembly, the result is a compound.
+
+@subsubsection occt_xde_2_2_7 Getting a Label from a Shape
+To get a Label, which is attached to a Shape from the top-level, use:
+~~~~~
Standard_Boolean findInstance = Standard_False;
-// (this is default value)
-aLabel = myAssembly-FindShape(aShape [,findInstance]);
+// (this is default value)
+aLabel = myAssembly->FindShape(aShape [,findInstance]);
if (aLabel.IsNull()) {
- // no label found for this shape
-}
-If findInstance is True, a search is made for the shape with the same location. If False (default value), a search is made among original, non-located shapes.
-@subsubsection occt_1819379545_193690446228 Other Queries on a Label
+ // no label found for this shape
+}
+~~~~~
+If *findInstance* is True, a search is made for the shape with the same location. If it is False (default value), a search is made among original, non-located shapes.
+
+@subsubsection occt_xde_2_2_8 Other Queries on a Label
+
Various other queries can be made from a Label within the Main Item of XDE:
-<h4>Main Shapes</h4>
+#### Main Shapes
+
To determine if a Shape is recorded (or not), use:
+~~~~~
if ( myAssembly-IsShape(aLabel) ) { .. yes .. }
+~~~~~
-To determine if the shape is ;top-level; (was added by the AddShape method), use:
-if ( myAssembly-IsTopLevel(aLabel) ) { .. yes .. }
+To determine if the shape is top-level, i.e. was added by the *AddShape* method, use:
+~~~~~
+if ( myAssembly->IsTopLevel(aLabel) ) { .. yes .. }
+~~~~~
-To get a list of top-level shapes (added by the AddShape method), use:
+To get a list of top-level shapes added by the *AddShape* method, use:
+~~~~~
TDF_LabelSequence frshapes;
myAssembly-GetShapes(frshapes);
+~~~~~
To get all free shapes at once if the list above has only one item, use:
+~~~~~
TopoDS_Shape result = myAssembly-GetShape(frshapes.Value(1));
+~~~~~
If there is more than one item, you must create and fill a compound, use:
+
+~~~~~
TopoDS_Compound C;
BRep_Builder B;
B.MakeCompound(C);
for(Standard_Integer i=1; i=frshapes.Length(); i++) {
- TopoDS_Shape S = myAssembly-GetShape(frshapes.Value(i));
- B.Add(C,S);
+ TopoDS_Shape S = myAssembly->GetShape(frshapes.Value(i));
+ B.Add(C,S);
}
+~~~~~
In our example, the result is the compound C.
To determine if a shape is a free shape (no reference or super-assembly), use:
+
+~~~~~
if ( myAssembly-IsFree(aLabel) ) { .. yes .. }
+~~~~~
To get a list of Free Shapes (roots), use:
+
+~~~~~
TDF_LabelSequence frshapes;
-myAssembly-GetFreeShapes(frshapes);
+myAssembly->GetFreeShapes(frshapes);
+~~~~~
To get the shapes, which use a given shape as a component, use:
+~~~~~
TDF_LabelSequence users;
Standard_Integer nbusers = myAssembly-GetUsers(aLabel,users);
-The count of users is contained with nbusers. It contains 0 if there are no users.
-<h4>Assembly and Components</h4>
+~~~~~
+The count of users is contained with *nbusers*. It contains 0 if there are no users.
+
+#### Assembly and Components
To determine if a label is attached to the main part or to a sub-part (component), use:
+~~~~~
if (myAssembly-IsComponent(aLabel)) { .. yes .. }
-
+~~~~~
To determine whether a label is a node of a (sub-) assembly or a simple shape, use:
+~~~~~
if ( myAssembly-IsAssembly(aLabel) ) { .. yes .. }
+~~~~~
If the label is a node of a (sub-) assembly, you can get the count of components, use:
+~~~~~
Standard_Boolean subchilds = Standard_False; //default
Standard_Integer nbc = myAssembly-NbComponents (aLabel
[,subchilds]);
-If subchilds is True, commands also consider sub-levels. By default, only level one is checked.
+~~~~~
+
+If *subchilds* is True, commands also consider sub-levels. By default, only level one is checked.
To get component Labels themselves, use:
+~~~~~
Standard_Boolean subchilds = Standard_False; //default
TDF_LabelSequence comps;
Standard_Boolean isassembly = myAssembly-GetComponents
(aLabel,comps[,subchilds]);
-@subsubsection occt_1819379545_193690446229 Instances and References for Components
+~~~~~
+@subsubsection occt_xde_2_2_9 Instances and References for Components
To determine if a label is a simple shape, use:
-if ( myAssembly-IsSimpleShape(aLabel) ) { .. yes .. }
-
+~~~~~
+if ( myAssembly->IsSimpleShape(aLabel) ) { .. yes .. }
+~~~~~
To determine if a label is a located reference to another one, use:
+~~~~~
if ( myAssembly-IsReference(aLabel) ) { .. yes .. }
-
+~~~~~
If the label is a located reference, you can get the location, use:
+~~~~~
TopLoc_Location loc = myAssembly-GetLocation (aLabel);
-
+~~~~~
To get the label of a referenced original shape (also tests if it is a reference), use:
+~~~~~
Standard_Boolean isref = myAssembly-GetReferredShape
(aLabel, refLabel);
-*NOTE **isref* *returns False if aLabel* *is not for a reference.*
-@subsection occt_1819379545_19369044623 Editing Shapes
-In addition to the previously described AddShape and SetShape, several shape edits are possible.
+~~~~~
+
+**Note** *isref* returns False if *aLabel* is not for a reference.
+
+@subsection occt_xde_2_3 Editing Shapes
+In addition to the previously described *AddShape* and *SetShape*, several shape edits are possible.
To remove a Shape, and all its sub-labels, use:
+~~~~~
Standard_Boolean remsh = myAssembly-RemoveShape(aLabel);
// remsh is returned True if done
-*NOTE: **This operation will fail if the shape is neither free nor top level.*
+~~~~~
+This operation will fail if the shape is neither free nor top level.
To add a Component to the Assembly, from a new shape, use:
+~~~~~
Standard_Boolean expand = Standard_False; //default
-TDF_Label aLabel = myAssembly-AddComponent (aShape
-[,expand]);
-If expand is True and if aShape is a Compound, it is broken down to produce sub-components, one for each of its sub-shapes.
+TDF_Label aLabel = myAssembly->AddComponent (aShape [,expand]);
+~~~~~
+If *expand* is True and *aShape* is a Compound, *aShape* is broken down to produce sub-components, one for each of its sub-shapes.
To add a component to the assembly, from a previously recorded shape (the new component is defined by the label of the reference shape, and its location), use:
+~~~~~
TDF_Label refLabel ...; // the label of reference shape
TopLoc_Location loc ...; // the desired location
-TDF_Label aLabel = myAssembly-AddComponent (refLabel, loc);
-
+TDF_Label aLabel = myAssembly->AddComponent (refLabel, loc);
+~~~~~
To remove a component from the assembly, use:
-myAssembly-RemoveComponent (aLabel);
-@subsection occt_1819379545_19369044624 Management of Sub-Shapes
-In addition to components of a (sub-)assembly, it is possible to have individual identification of some sub-shapes inside any shape. Therefore, you can attach specific attributes such as Colors. Some additional actions can be performed on sub-shapes that are neither top-level, nor components:
+~~~~~
+myAssembly->RemoveComponent (aLabel);
+~~~~~
+@subsection occt_xde_2_4 Management of Sub-Shapes
+In addition to components of a (sub-)assembly, it is possible to have individual identification of some sub-shapes inside any shape. Therefore, you can attach specific attributes such as Colors. Some additional actions can be performed on sub-shapes that are neither top-level, nor components:
To add a sub-shape to a given Label, use:
-TDF_Label subLabel = myAssembly-AddSubShape (aLabel,
-subShape);
+~~~~~
+TDF_Label subLabel = myAssembly->AddSubShape (aLabel, subShape);
+~~~~~
To find the Label attached to a given sub-shape, use:
+~~~~~
TDF_Label subLabel; // new label to be computed
-if ( myAssembly- FindSubShape (aLabel, subShape,
-subLabel)) { .. yes .. }
-If the sub-shape is found (yes), subLabel is filled by the correct value.
+if ( myAssembly- FindSubShape (aLabel, subShape, subLabel)) { .. yes .. }
+~~~~~
+If the sub-shape is found (yes), *subLabel* is filled by the correct value.
To find the top-level simple shape (not a compound whether free or not), which contains a given sub-shape, use:
-TDF_Label mainLabel = myAssembly-FindMainShape(subShape);
-*NOTE: **There should be only one shape for a valid model. In any case, the search stops on the first one found.*
+~~~~~
+TDF_Label mainLabel = myAssembly->FindMainShape(subShape);
+~~~~~
+**Note** that there should be only one shape for a valid model. In any case, the search stops on the first one found.
To get the sub-shapes of a shape, which are recorded under a label, use:
+~~~~~
TDF_LabelSequence subs;
-Standard_Boolean hassubs = myAssembly-GetSubShapes
-(aLabel,subs);
-@subsection occt_1819379545_19369044625 Properties
+Standard_Boolean hassubs = myAssembly->GetSubShapes (aLabel,subs);
+~~~~~
+@subsection occt_xde_2_5 Properties
Some properties can be attached directly to shapes. These properties are:
* Name (standard definition from OCAF)
* Centroid (for validation of transfer)
* By attaching an item from the table.
* Adding the color directly.
When the color is added directly, a search is performed in the table of contents to determine if it contains the requested color. Once this search and initialize operation is done, the first way of attaching a color to a shape is used.
-@subsubsection occt_1819379545_193690446251 Name
-Name is implemented and used as a TDataStd_Name, which can be attached to any label. Before proceeding, consider that:
- * In IGES, every entity can have a name with an optional numeric part called a Subscript Label. For example, ;MYCURVE; is a name, and ;MYCURVE(60); is a name with a Subscript Label.
+@subsubsection occt_xde_2_5_1 Name
+Name is implemented and used as a *TDataStd_Name*, which can be attached to any label. Before proceeding, consider that:
+ * In IGES, every entity can have a name with an optional numeric part called a Subscript Label. For example, *MYCURVE* is a name, and *MYCURVE(60)* is a name with a Subscript Label.
* In STEP, there are two levels: Part Names and Entity Names:
-Part Names are attached to ;main shapes; such as parts and assemblies. These Part Names are specifically supported by XDE.
-Entity Names can be attached to every Geometric Entity. This option is rarely used, as it tends to overload the exploitation of the data structure. Only some specific cases justify using this option: for example, when the sending system can really ensure the stability of an entity name after each STEP writing. If such stability is ensured, you can use this option to send an Identifier for external applications using a database.
-*NOTE: **Both IGES or STEP files handle names as pure ASCII strings.*
+ * Part Names are attached to ;main shapes; such as parts and assemblies. These Part Names are specifically supported by XDE.
+ * Entity Names can be attached to every Geometric Entity. This option is rarely used, as it tends to overload the exploitation of the data structure. Only some specific cases justify using this option: for example, when the sending system can really ensure the stability of an entity name after each STEP writing. If such stability is ensured, you can use this option to send an Identifier for external applications using a database.
+**Note** that both IGES or STEP files handle names as pure ASCII strings.
+
These considerations are not specific to XDE. What is specific to data exchange is the way names are attached to entities.
To get the name attached to a label (as a reminder using OCAF), use:
+~~~~~
Handle(TDataStd_Name) N;
if ( !aLabel.FindAttribute(TDataStd_Name::GetID(),N)) {
- // no name is attached
+ // no name is attached
}
-TCollection_ExtendedString name = N-Get();
+TCollection_ExtendedString name = N->Get();
+~~~~~
+
Don't forget to consider Extended String as ASCII, for the exchange file.
To set a name to a label (as a reminder using OCAF), use:
+~~~~~
TCollection_ExtendedString aName ...;
// contains the desired name for this Label (ASCII)
TDataStd_Name::Set (aLabel, aName);
-@subsubsection occt_1819379545_193690446252 Centroid
-A Centroid is defined by a Point to fix its position. It is handled as a property, item of the class XCAFDoc_Centroid, sub-class of TDF_Attribute. However, global methods give access to the position itself.
-This notion has been introduced in STEP, together with that of Volume, and Area, as defining the ;Validation Properties;: this feature allows exchanging the geometries and some basic attached values, in order to perform a synthetic checking on how they are maintained after reading and converting the exchange file. This exchange depends on reliable exchanges of Geometry and Topology. Otherwise, these values can be considered irrelevant.
-Along with Volume (see 2.5.4), it can be determined at any level of an assembly, thereby allowing a check of both individual simple shapes and their combinations including locations.
+~~~~~
+
+@subsubsection occt_xde_2_5_2 Centroid
+A Centroid is defined by a Point to fix its position. It is handled as a property, item of the class *XCAFDoc_Centroid*, sub-class of *TDF_Attribute*. However, global methods give access to the position itself.
+
+This notion has been introduced in STEP, together with that of Volume, and Area, as defining the Validation Properties: this feature allows exchanging the geometries and some basic attached values, in order to perform a synthetic checking on how they are maintained after reading and converting the exchange file. This exchange depends on reliable exchanges of Geometry and Topology. Otherwise, these values can be considered irrelevant.
+
+A centroid can be determined at any level of an assembly, thereby allowing a check of both individual simple shapes and their combinations including locations.
+
To get a Centroid attached to a Shape, use:
+~~~~~
gp_Pnt pos;
Handle(XCAFDoc_Centroid) C;
aLabel.FindAttribute ( XCAFDoc_Centroid::GetID(), C );
-if ( !C.IsNull() ) pos = C-Get();
+if ( !C.IsNull() ) pos = C->Get();
+~~~~~
To set a Centroid to a Shape, use:
+~~~~~
gp_Pnt pos (X,Y,Z);
// the position previously computed for the centroid
XCAFDoc_Centroid::Set ( aLabel, pos );
-@subsubsection occt_1819379545_193690446253 Area
-An Area is defined by a Real, it corresponds to the computed Area of a Shape, provided that it contains surfaces. It is handled as a property, item of the class XCAFDoc_Area, sub-class of TDF_Attribute.
+~~~~~
+
+@subsubsection occt_xde_2_5_3 Area
+An Area is defined by a Real, it corresponds to the computed Area of a Shape, provided that it contains surfaces. It is handled as a property, item of the class *XCAFDoc_Area*, sub-class of *TDF_Attribute*.
This notion has been introduced in STEP but it is usually disregarded for a Solid, as Volume is used instead. In addition, it is attached to simple shapes, not to assemblies.
To get an area attached to a Shape, use:
+~~~~~
Standard_Real area;
Handle(XCAFDoc_Area) A;
L.FindAttribute ( XCAFDoc_Area::GetID(), A );
-if ( !A.IsNull() ) area = A-Get();
+if ( !A.IsNull() ) area = A->Get();
To set an area value to a Shape, use:
Standard_Real area ...;
// value previously computed for the area
XCAFDoc_Area::Set ( aLabel, area );
-@subsubsection occt_1819379545_193690446254 Volume
-A Volume is defined by a Real and corresponds to the computed volume of a Shape, provided that it contains solids. It is handled as a property, an item of the class XCAFDoc_Volume, sub-class of TDF_Attribute.
-This notion has been introduced in STEP. It may be attached to simple shapes or their assemblies for computing cumulated volumes and centers of gravity (see also 2.5.2 Centroid).
+~~~~~
+@subsubsection occt_xde_2_5_4 Volume
+A Volume is defined by a Real and corresponds to the computed volume of a Shape, provided that it contains solids. It is handled as a property, an item of the class *XCAFDoc_Volume*, sub-class of *TDF_Attribute*.
+This notion has been introduced in STEP. It may be attached to simple shapes or their assemblies for computing cumulated volumes and centers of gravity.
To get a Volume attached to a Shape, use:
+~~~~~
Standard_Real volume;
Handle(XCAFDoc_Volume) V;
L.FindAttribute ( XCAFDoc_Volume::GetID(), V );
-if ( !V.IsNull() ) volume = V-Get();
+if ( !V.IsNull() ) volume = V->Get();
+~~~~~
To set a volume value to a Shape, use:
+~~~~~
Standard_Real volume ...;
// value previously computed for the volume
XCAFDoc_Volume::Set ( aLabel, volume );
-@subsection occt_1819379545_19369044626 Colors
-In an XDE document, colors are managed by the class XCAFDoc_ColorTool. This is done with the same principles as for ShapeTool with Shapes, and with the same capability of having a tool on the Main Label, or on any sub-label. The Property itself is defined as an XCAFDoc_Color, sub-class of TDF_Attribute.
+~~~~~
+@subsection occt_xde_2_6 Colors
+In an XDE document, colors are managed by the class *XCAFDoc_ColorTool*. This is done with the same principles as for ShapeTool with Shapes, and with the same capability of having a tool on the Main Label, or on any sub-label. The Property itself is defined as an *XCAFDoc_Color*, sub-class of *TDF_Attribute*.
+
Colors are stored in a child of the starting document label: it is the second level (0.1.2), while Shapes are at the first level. Each color then corresponds to a dedicated label, the property itself is a Quantity_Color, which has a name and value for Red, Green, Blue. A Color may be attached to Surfaces (flat colors) or to Curves (wireframe colors), or to both. A Color may be attached to a sub-shape. In such a case, the sub-shape (and its own sub-shapes) takes its own Color as a priority.
+
Colors and Shapes are related to by Tree Nodes.
+
These definitions are common to various exchange formats, at least for STEP and IGES.
-@subsubsection occt_1819379545_193690446261 Initialization
+
+@subsubsection occt_xde_2_6_1 Initialization
To query, edit, or initialize a Document to handle Colors of XCAF, use:
+~~~~~
Handle(XCAFDoc_ColorTool) myColors =
XCAFDoc_DocumentTool::ColorTool(Doc-Main ());
+~~~~~
This call can be used at any time. The first time it is used, a relevant structure is added to the document. This definition is used for all the following color calls and will not be repeated for these.
-@subsubsection occt_1819379545_193690446262 Adding a Color
+
+@subsubsection occt_xde_2_6_2 Adding a Color
There are two ways to add a color. You can:
- * add a new Color defined as Quantity_Color and then directly set it to a Shape (anonymous Color)
+ * add a new Color defined as *Quantity_Color* and then directly set it to a Shape (anonymous Color)
* define a new Property Color, add it to the list of Colors, and then set it to various shapes.
-When the Color is added by its value Quantity_Color, it is added only if it has not yet been recorded (same RGB values) in the Document.
+When the Color is added by its value *Quantity_Color*, it is added only if it has not yet been recorded (same RGB values) in the Document.
-To set a Color to a Shape using a label, use:
+To set a Color to a Shape using a label, use:
+~~~~~
Quantity_Color Col (red,green,blue);
XCAFDoc_ColorType ctype ..;
// can take one of these values :
// XCAFDoc_ColorSurf : surfaces only
// XCAFDoc_ColorCurv : curves only
myColors-SetColor ( aLabel, Col, ctype );
-
+~~~~~
Alternately, the Shape can be designated directly, without using its label, use:
-myColors-SetColor ( aShape, Col, ctype );
+~~~~~
+myColors->SetColor ( aShape, Col, ctype );
// Creating and Adding a Color, explicitly
Quantity_Color Col (red,green,blue);
-TDF_Label ColLabel = myColors-AddColor ( Col );
-*NOTE: **this Color can then be named, allowing later retrieval by its Name instead of its Value.*
+TDF_Label ColLabel = myColors->AddColor ( Col );
+~~~~~
+**Note** that this Color can then be named, allowing later retrieval by its Name instead of its Value.
To set a Color, identified by its Label and already recorded, to a Shape, use:
-XCAFDoc_ColorType ctype ..; // see above
-if ( myColors-SetColors ( aLabel, ColLabel, ctype) ) {
-.. it is done .. }
-In this example, aLabel can be replaced by aShape directly.
-@subsubsection occt_1819379545_193690446263 Queries on Colors
+~~~~~
+XCAFDoc_ColorType ctype ..; // see above
+if ( myColors->SetColors ( aLabel, ColLabel, ctype) ) {.. it is done .. }
+~~~~~
+In this example, *aLabel* can be replaced by *aShape* directly.
+
+@subsubsection occt_xde_2_6_3 Queries on Colors
Various queries can be performed on colors. However, only specific queries are included in this section, not general queries using names.
To determine if a Color is attached to a Shape, for a given color type (ctype), use:
-if ( myColors-IsSet (aLabel , ctype)) {
- // yes, there is one ..
+~~~~~
+if ( myColors->IsSet (aLabel , ctype)) {
+ // yes, there is one ..
}
-In this example, aLabel can be replaced by aShape directly.
+~~~~~
+In this example, *aLabel* can be replaced by *aShape* directly.
To get the Color attached to a Shape (for any color type), use:
+~~~~~
Quantity_Color col;
-// will receive the recorded value (if there is some)
-if ( !myColors-GetColor(aLabel, col) ) {
+// will receive the recorded value (if there is some)
+if ( !myColors->GetColor(aLabel, col) ) {
// sorry, no color ..
-}
-// color name can also be queried from : col.StringName
-// or col.Name
-In this example, aLabel can be replaced by aShape directly.
+}
+~~~~~
+
+Color name can also be queried from *col.StringName* or *col.Name*.
+In this example, *aLabel* can be replaced by *aShape* directly.
To get the Color attached to a Shape, with a specific color type, use:
+~~~~~
XCAFDoc_ColorType ctype ..;
-// the desired color type
Quantity_Color col;
// will receive the recorded value (if there is some)
-if ( !myColors-GetColor(aLabel, ctype, col) ) {
+if ( !myColors->GetColor(aLabel, ctype, col) ) {
// sorry, no color ..
}
+~~~~~
+
To get all the Colors recorded in the Document, use:
+
+~~~~~
Quantity_Color col; // to receive the values
TDF_LabelSequence ColLabels;
-myColors-GetColors(ColLabels);
+myColors->GetColors(ColLabels);
Standard_Integer i, nbc = ColLabels.Length();
for (i = 1; i = nbc; i ++) {
- aLabel = Labels.Value(i);
- if ( !myColors-GetColor(aLabel, col) ) continue;
- // col receives the color n0 i ..
+ aLabel = Labels.Value(i);
+ if ( !myColors->GetColor(aLabel, col) ) continue;
+ // col receives the color n0 i ..
}
+~~~~~
To find a Color from its Value, use:
+~~~~~
Quantity_Color Col (red,green,blue);
TDF_Label ColLabel = myColors-FindColor (Col);
if ( !ColLabel.IsNull() ) { .. found .. }
-@subsubsection occt_1819379545_193690446264 Editing Colors
+~~~~~
+
+@subsubsection occt_xde_2_64 Editing Colors
Besides adding colors, the following attribute edits can be made:
To unset a Color on a Shape, use:
+~~~~~
XCAFDoc_ColorType ctype ...;
// desired type (XCAFDoc_ColorGen for all )
-myColors-UnSetColor (aLabel,ctype);
-
+myColors->UnSetColor (aLabel,ctype);
+~~~~~
To remove a Color and all the references to it (so that the related shapes will become colorless), use:
-myColors-RemoveColor(ColLabel);
-@subsection occt_1819379545_19369044627 Layers
-Layers are handled using the same principles as for Colors (see 2.6 Colors). Simply replace ;Color; with ;Layer; when dealing with Layers. Layers are supported by the class XCAFDoc_LayerTool.
-The class of the property is XCAFDoc_Layer, sub-class of TDF_Attribute while its definition is a TCollection_ExtendedString. Integers are generally used when dealing with Layers. The general cases are:
- * IGES has LevelList as a list of Layer Numbers (not often used)
+~~~~~
+myColors->RemoveColor(ColLabel);
+~~~~~
+@subsection occt_xde_2_7 Layers
+Layers are handled using the same principles as for Colors. Simply replace **Color** with **Layer** when dealing with Layers. Layers are supported by the class *XCAFDoc_LayerTool*.
+The class of the property is *XCAFDoc_Layer*, sub-class of *TDF_Attribute* while its definition is a *TCollection_ExtendedString*. Integers are generally used when dealing with Layers. The general cases are:
+ * IGES has *LevelList* as a list of Layer Numbers (not often used)
* STEP identifies a Layer (not by a Number, but by a String), to be more general.
-@subsection occt_1819379545_19369044628 Reading and Writing STEP or IGES
+
+@subsection occt_xde_2_8 Reading and Writing STEP or IGES
Note that saving and restoring the document itself are standard OCAF operations. As the various previously described definitions enter into this frame, they will not be explained any further.
The same can be said for Viewing: presentations can be defined from Shapes and Colors.
+
There are several important points to consider:
* Previously defined Readers and Writers for dealing with Shapes only, whether Standard or Advanced, remain unchanged in their form and in their dependencies. In addition, functions other than mapping are also unchanged.
* XDE provides mapping with data other than Shapes. Names, Colors, Layers, Validation Properties (Centroid, Volume, Area), and Assembly Structure are hierarchic with rigid motion.
* XDE mapping is relevant for use within the Advanced level of Data Exchanges, rather than Standard ones, because a higher level of information is better suited to a higher quality of shapes. In addition, this allows to avoid the multiplicity of combinations between various options. Note that this choice is not one of architecture but of practical usage and packaging.
* Reader and Writer classes for XDE are generally used like those for Shapes. However, their use is adapted to manage a Document rather than a Shape.
-The packages to manage this are IGESCAFControl for IGES, and STEPCAFControl for STEP.
-@subsubsection occt_1819379545_193690446281 Reading a STEP file
+
+The packages to manage this are *IGESCAFControl* for IGES, and *STEPCAFControl* for STEP.
+@subsubsection occt_xde_2_8_1 Reading a STEP file
To read a STEP file by itself, use:
+
+~~~~~
STEPCAFControl_Reader reader;
IFSelect_ReturnStatus readstat = reader.ReadFile(filename);
// The various ways of reading a file are available here too :
// properly initialized.
// Now, the transfer itself
if ( !reader.Transfer ( doc ) ) {
- cout;Cannot read any relevant data from the STEP file;endl;
- // abandon ..
+ cout;Cannot read any relevant data from the STEP file;endl;
+ // abandon ..
}
// Here, the Document has been filled from a STEP file,
// it is ready to use
+~~~~~
+
In addition, the reader provides methods that are applicable to document transfers and for directly querying of the data produced.
-@subsubsection occt_1819379545_193690446282 Writing a STEP file
+@subsubsection occt_xde_2_8_2 Writing a STEP file
To write a STEP file by itself, use:
+
+~~~~~
STEPControl_StepModelType mode =
STEPControl_AsIs;
// Asis is the recommended value, others are available
STEPCAFControl_Writer writer ( WS, scratch );
// Translating document (conversion) to STEP
if ( ! writer.Transfer ( Doc, mode ) ) {
- cout;The document cannot be translated or gives no result;endl;
- // abandon ..
+ cout;The document cannot be translated or gives no result;endl;
+ // abandon ..
}
// Writing the File
IFSelect_ReturnStatus stat = writer.Write(file-name);
-@subsubsection occt_1819379545_193690446283 Reading an IGES File
-Use the same procedure as for a STEP file but with IGESCAFControl instead of STEPCAFControl.
-@subsubsection occt_1819379545_193690446284 Writing an IGES File
+~~~~~
+
+@subsubsection occt_xde_2_8_3 Reading an IGES File
Use the same procedure as for a STEP file but with IGESCAFControl instead of STEPCAFControl.
-@subsection occt_1819379545_19369044629 Using an XDE Document
+@subsubsection occt_xde_2_8_4 Writing an IGES File
+Use the same procedure as for a STEP file but with IGESCAFControl instead of STEPCAFControl.
+
+@subsection occt_xde_2_9 Using an XDE Document
There are several ways of exploiting XDE data from an application, you can:
--# 1. Get the data relevant for the application by mapping XDE/Appli, then discard the XDE data once it has been used.
--# 2. Create a reference from the Application Document to the XDE Document, to have its data available as external data.
--# 3. Embed XDE data inside the Application Document (see the following section for details).
--# 4. Directly exploit XDE data such as when using file checkers.
-@subsubsection occt_1819379545_193690446291 XDE Data inside an Application Document
+ 1. Get the data relevant for the application by mapping XDE/Appli, then discard the XDE data once it has been used.
+ 2. Create a reference from the Application Document to the XDE Document, to have its data available as external data.
+ 3. Embed XDE data inside the Application Document (see the following section for details).
+ 4. Directly exploit XDE data such as when using file checkers.
+@subsubsection occt_xde_2_91 XDE Data inside an Application Document
To have XCAF data elsewhere than under label 0.1, you use the DocLabel of XDE. The method DocLabel from XCAFDoc_DocumentTool determines the relevant Label for XCAF. However, note that the default is 0.1.
+
In addition, as XDE data is defined and managed in a modular way, you can consider exclusively Assembly Structure, only Colors, and so on.
+
As XDE provides an extension of the data structure, for relevant data in standardized exchanges, note the following:
* This data structure is fitted for data exchange, rather than for use by the final application.
* The provided definitions are general, for common use and therefore do not bring strongly specific semantics.
+
As a result, if an application works on Assemblies, on Colors or Layers, on Validation Properties (as defined in STEP), it can rely on all or a part of the XDE definitions, and include them in its own data structure.
-In addition, if an application has a data structure far from these notions, it can get data (such as Colors and Names on Shapes) according to its needs, but without having to consider the whole.
-@section occt_1819379545_685425104 Package XCAFDoc
-@subsection occt_1819379545_6854251041 General description
-This package is intended for definition of general structure of an XDE document and tools to work with it.
-The document is composed of sections, each section storing its own kind of data and managing by a corresponding tool.
-The API enumeration is
- * XCAFDoc_ColorType.
-The API classes are the following:
- * XCAFDoc_DocumentTool
- * XCAFDoc_Location
- * XCAFDoc_Color
- * XCAFDoc_Volume
- * XCAFDoc_ Area
- * XCAFDoc_ Centroid
- * XCAFDoc_ ShapeTool
- * XCAFDoc_ ColorTool
- * XCAFDoc_ LayerTool
- * XCAFDoc_ GraphNode
-@subsection occt_1819379545_6854251042 Enumeration XCAFDoc_ColorType
-Definition:
-enumeration ColorType is
-ColorGen, -- simple color
-ColorSurf, -- color of surfaces
-ColorCurv -- color of curves
-end ColorType;
-Purpose: Defines types of color assignments.
-@subsection occt_1819379545_6854251043 Class XCAFDoc_DocumentTool
-@subsubsection occt_1819379545_68542510431 General description
-Purpose: Attribute marking an OCAF document as being an XDE document.
-Creates the sections structure of the document.
-@subsubsection occt_1819379545_68542510432 Methods
-The methods are the following:
-<h4>Constructors</h4>
-XCAFDoc_DocumentTool()
-Purpose: Empty constructor
-<h4>Methods:</h4>
- * XCAFDoc_DocumentTool::Init
-void XCAFDoc_DocumentTool::Init() const
-Purpose: To be called when reading this attribute from a file.
- * XCAFDoc_DocumentTool::Set
-Handle(XCAFDoc_DocumentTool) XCAFDoc_DocumentTool::Set(
-const TDF_Label& L, const Standard_Boolean IsAcces)
- * Purpose: Creates (if does not exist) a DocumentTool attribute on 0.1 label if IsAcces is true, else on L label. This label will be returned by DocLabel(); If the attribute is already set it will not be reset on L even if IsAcces is false. ColorTool and ShapeTool attributes are also set by this method. Returns DocumentTool from XCAFDoc;
- * XCAFDoc_DocumentTool::DocLabel
-TDF_Label XCAFDoc_DocumentTool::DocLabel(
-const TDF_Label& acces)
- * Purpose: Returns the label where the DocumentTool attribute is or *0.1* if DocumentTool is not yet set.
- * XCAFDoc_DocumentTool::ShapesLabel
-TDF_Label XCAFDoc_DocumentTool::ShapesLabel(
-const TDF_Label& acces)
-Purpose: Returns the shapes sub-label of DocLabel().
- * XCAFDoc_DocumentTool::ColorsLabel
-TDF_Label XCAFDoc_DocumentTool::ColorsLabel(
-const TDF_Label& acces)
-Purpose: Returns the colors sub-label of DocLabel().
- * XCAFDoc_DocumentTool::LayersLabel
-TDF_Label XCAFDoc_DocumentTool::LayersLabel(
-const TDF_Label& acces)
-Purpose: Returns the layers sub-label of DocLabel().
- * XCAFDoc_DocumentTool::ShapeTool
-Handle(XCAFDoc_ShapeTool) XCAFDoc_DocumentTool::ShapeTool(
-const TDF_Label& acces)
-Purpose: Creates (if does not exist) a ShapeTool attribute on ShapesLabel().
- * XCAFDoc_DocumentTool::ColorTool
-Handle(XCAFDoc_ColorTool) XCAFDoc_DocumentTool::ColorTool (
-const TDF_Label& acces)
-Purpose: Creates (if does not exist) a ColorTool attribute on ColorsLabel().
- * XCAFDoc_DocumentTool::LayerTool
-Handle(XCAFDoc_LayerTool) XCAFDoc_DocumentTool::LayerTool (
-const TDF_Label& acces)
-Purpose: Creates (if does not exist) a LayerTool attribute on LayersLabel().
-@subsection occt_1819379545_6854251044 Class XCAFDoc_Location
-@subsubsection occt_1819379545_68542510441 General description
-Purpose: Attribute to store TopLoc_Location.
-Inherits Attribute from TDF
-@subsubsection occt_1819379545_68542510442 Methods
-The methods are the following:
-<h4>Constructors</h4>
-XCAFDoc_Location()
-Purpose: Empty constructor.
-<h4>Methods:</h4>
- * XCAFDoc_Location::Set
-void XCAFDoc_Location::Set(const TopLoc_Location& Loc)
-Purpose: Sets a Location attribute.
-Handle(XCAFDoc_Location) XCAFDoc_Location::Set(
-const TDF_Label& L,const TopLoc_Location& Loc)
- * Purpose: Finds or creates a Location attribute and sets its value. The Location attribute is returned.
- * XCAFDoc_Location::Get
-TopLoc_Location XCAFDoc_Location::Get() const
-Purpose: Returns Location from TopLoc.
-@subsection occt_1819379545_6854251045 Class XCAFDoc_Color
-@subsubsection occt_1819379545_68542510451 General description
-Purpose: Attribute to store color.
-Inherits Attribute from TDF
-@subsubsection occt_1819379545_68542510452 Methods
-The methods are the following:
-<h4>Constructors</h4>
-XCAFDoc_Color()
-Purpose: Empty constructor.
-<h4>Methods:</h4>
- * XCAFDoc_Color::Set
-void XCAFDoc_Color::Set(const Quantity_Color& C)
-void XCAFDoc_Color::Set(const Quantity_NameOfColor C)
-void XCAFDoc_Color::Set(const Standard_Real R,
-const Standard_Real G, const Standard_Real B)
-Purpose: Sets a Color attribute.
-Handle(XCAFDoc_Color) XCAFDoc_Color::Set(
-const TDF_Label& L, const Quantity_Color& C)
-Handle(XCAFDoc_Color) XCAFDoc_Color::Set(
-const TDF_Label& L, const Quantity_NameOfColor C)
-Handle(XCAFDoc_Color) XCAFDoc_Color::Set(
-const TDF_Label& L, const Standard_Real R,
-const Standard_Real G, const Standard_Real B)
-Purpose: Finds or creates a Color attribute and sets its value. The Color attribute is returned.
- * XCAFDoc_Color::GetColor
-Quantity_Color XCAFDoc_Color::GetColor() const
-Purpose: Returns a Color attribute.
- * XCAFDoc_Color::GetNOC
-Quantity_NameOfColor XCAFDoc_Color::GetNOC() const
-Purpose: Returns a Name of Color.
- * XCAFDoc_Color::GetRGB
-void XCAFDoc_Color::GetRGB(Standard_Real& R,
-Standard_Real& G, Standard_Real& B) const
-Purpose: Returns RGB.
-@subsection occt_1819379545_6854251046 Class XCAFDoc_Volume
-@subsubsection occt_1819379545_68542510461 General description
-Purpose: Attribute to store volume.
-Inherits Attribute from TDF
-
-
-
-@subsubsection occt_1819379545_68542510462 Methods
-The methods are the following:
-<h4>Constructors</h4>
-XCAFDoc_Volume()
-Purpose: Empty constructor.
-<h4>Methods:</h4>
- * XCAFDoc_Volume::Set
-void XCAFDoc_Volume::Set (const Standard_Real V)
-Purpose: Sets a value of Volume.
-Handle(XCAFDoc_Volume) XCAFDoc_Volume::Set (
-const TDF_Label& L,const Standard_Real V)
-Purpose: Finds or creates a Volume attribute and sets its value.
- * XCAFDoc_Volume::Get
-Standard_Real XCAFDoc_Volume::Get() const
-Purpose: Returns a value of Volume
-Standard_Boolean XCAFDoc_Volume::Get(
-const TDF_Label& label,Standard_Real& vol)
-Purpose: Returns Volume as argument. Returns false if there is no such attribute at the label.
-@subsection occt_1819379545_6854251047 Class XCAFDoc_Area
-@subsubsection occt_1819379545_68542510471 General description
-Purpose: Attribute to store area.
-Inherits Attribute from TDF
-@subsubsection occt_1819379545_68542510472 Methods
-The methods are the following:
-<h4>Constructors</h4>
-XCAFDoc_Area()
-Purpose: Empty constructor.
-<h4>Methods:</h4>
- * XCAFDoc_Area::Set
-void XCAFDoc_Area::Set (const Standard_Real V)
-Purpose: Sets a value of area.
-Handle(XCAFDoc_Area) XCAFDoc_Area::Set (
-const TDF_Label& L,const Standard_Real V)
-Purpose: Finds or creates an Area attribute and sets its value.
- * XCAFDoc_Area::Get
-Standard_Real XCAFDoc_Area::Get() const
-Purpose: Returns a value of area.
-Standard_Boolean XCAFDoc_Area::Get(
-const TDF_Label& label, Standard_Real& area)
-Purpose: Returns the volume of area as an argument and success status returns false if there is no such attribute at the label.
-@subsection occt_1819379545_6854251048 Class XCAFDoc_Centroid
-@subsubsection occt_1819379545_68542510481 General description
-Purpose: Attribute to store Centroid.
-Inherits Attribute from TDF
-@subsubsection occt_1819379545_68542510482 Methods
-The methods are the following:
-<h4>Constructors</h4>
-XCAFDoc_Centroid()
-Purpose: Empty constructor.
-<h4>Methods:</h4>
- * XCAFDoc_Centroid::Set
-void XCAFDoc_Centroid::Set(const gp_Pnt& pnt)
-Purpose: Sets a Centroid attribute.
-Handle(XCAFDoc_Centroid) XCAFDoc_Centroid::Set(
-const TDF_Label& L, const gp_Pnt& pnt)
-Purpose: Finds or creates a Centroid attribute and sets its value. The Centroid attribute is returned.
- * XCAFDoc_Area::Get
-gp_Pnt XCAFDoc_Centroid::Get() const
-Purpose: Returns a Centroid attribute.
-Standard_Boolean XCAFDoc_Centroid::Get(
-const TDF_Label& label,gp_Pnt& pnt)
-Purpose: Returns a point as an argument. Returns false if there is no such attribute at the label.
-@subsection occt_1819379545_6854251049 Class XCAFDoc_ShapeTool
-@subsubsection occt_1819379545_68542510491 General description
- Purpose: attribute containing the Shapes section of an XDE document.
-Provides tools for management of the Shapes section.
-@subsubsection occt_1819379545_68542510492 Methods
-The methods are the following:
-<h4>Constructors</h4>
-XCAFDoc_ShapeTool()
-Purpose: Empty constructor.
-<h4>Method Set</h4>
- * XCAFDoc_ ShapeTool::Set
-Handle(XCAFDoc_ShapeTool) XCAFDoc_ShapeTool::Set(const TDF_Label& L)
-Purpose: Creates (if does not exist) ShapeTool from XCAFDoc on L.
-<h4>Methods for work with top-level structure of shapes </h4>
- * XCAFDoc_ShapeTool::Search
-Standard_Boolean XCAFDoc_ShapeTool::Search (
-const TopoDS_Shape &S, TDF_Label &L,
-const Standard_Boolean findInstance,
-const Standard_Boolean findComponent,
-const Standard_Boolean findSubShape) const
-Purpose: General tool to find a (sub) shape in the document
-- If findInstance is True, and S has a non-null location, first tries to find the shape among the top-level shapes with this location
-- If not found, and findComponent is True, tries to find the shape among the components of assemblies
-- If not found, tries to find the shape without location among top-level shapes
-- If not found and findSubshape is True, tries to find a shape as a subshape of top-level simple shapes
-Returns False if nothing is found.
- * XCAFDoc_ShapeTool::FindShape
-Standard_Boolean XCAFDoc_ShapeTool::FindShape (
-const TopoDS_Shape& S, TDF_Label& L,
-const Standard_Boolean findInstance) const
-Purpose. Returns the label corresponding to shape S (searches among top-level shapes, not including subcomponents of assemblies). If findInstance is False (default), searches for the non-located shape (i.e. among original shapes). If findInstance is True, searches for the shape with the same location, including shape instances. Returns True if S is found.
-TDF_Label XCAFDoc_ShapeTool::FindShape (const TopoDS_Shape& S,
-const Standard_Boolean findInstance) const
-Purpose: Does the same as the previous method. Returns the Null label if not found.
- * XCAFDoc_ShapeTool::GetShape
-Standard_Boolean XCAFDoc_ShapeTool::GetShape (
-const TDF_Label& L, TopoDS_Shape& S)
-Purpose: To get TopoDS_Shape from the shape's label. For component, returns a new shape with a correct location. Returns False if the label does not contain a shape.
-TopoDS_Shape XCAFDoc_ShapeTool::GetShape(const TDF_Label& L)
-Purpose: To get TopoDS_Shape from the shape's label. For component, returns a new shape with a correct location. Returns a Null shape if the label does not contain a shape.
- * XCAFDoc_ShapeTool::NewShape
-TDF_Label XCAFDoc_ShapeTool::NewShape() const
-Purpose: Creates a new (empty) top-level shape. Initially it holds an empty TopoDS_Compound.
- * XCAFDoc_ShapeTool::SetShape
-void XCAFDoc_ShapeTool::SetShape (const TDF_Label& L,
-const TopoDS_Shape& S) const
-Purpose: Sets representation (TopoDS_Shape) for the top-level shape.
- * XCAFDoc_ShapeTool::AddShape
-TDF_Label XCAFDoc_ShapeTool::AddShape (const TopoDS_Shape& S,
-const Standard_Boolean makeAssembly) const
-Purpose: Adds a new top-level (creates and returns a new label). If makeAssembly is True, treats TopAbs_COMPOUND shapes as assemblies (creates assembly structure).
- * XCAFDoc_ShapeTool::RemoveShape
-Standard_Boolean XCAFDoc_ShapeTool::RemoveShape (
-const TDF_Label& L) const
-Purpose: Removes a shape (whole label and all its sublabels). Returns False (and does nothing) if the shape is not free or is not a top-level shape.
- * XCAFDoc_ShapeTool::GetShapes
-void XCAFDoc_ShapeTool::GetShapes (TDF_LabelSequence& Labels) const
-Purpose: Returns a sequence of all top-level shapes.
- * XCAFDoc_ShapeTool::GetFreeShapes
-void XCAFDoc_ShapeTool::GetFreeShapes (
-TDF_LabelSequence& FreeLabels) const
-Purpose: Returns a sequence of all top-level shapes, which are free (i.e. not referred by any other shape).
- * XCAFDoc_ShapeTool::GetUsers
-Standard_Integer XCAFDoc_ShapeTool::GetUsers (const TDF_Label& L,
-TDF_LabelSequence& Labels,
-const Standard_Boolean getsubchilds)
-Purpose: Returns a list of labels, which refer to shape L as a component. Returns the number of users (0 if the shape is free).
- * XCAFDoc_ShapeTool::GetLocation
-TopLoc_Location XCAFDoc_ShapeTool::GetLocation (const TDF_Label& L)
-Purpose: Returns the location of instance.
- * XCAFDoc_ShapeTool::GetReferredShape
-Standard_Boolean XCAFDoc_ShapeTool::GetReferredShape (
-const TDF_Label& L, TDF_Label& Label)
-Purpose: Returns the label, which corresponds to a shape referred by L. Returns False if the label is not a reference.
-<h4>Methods for analysis</h4>
- * XCAFDoc_ShapeTool::IsTopLevel
-Standard_Boolean XCAFDoc_ShapeTool::IsTopLevel (const TDF_Label& L) const
-Purpose: Returns True if the label is a label of a top-level shape, as opposed to a component of an assembly or a subshape.
- * XCAFDoc_ShapeTool::IsShape
-Standard_Boolean XCAFDoc_ShapeTool::IsShape (const TDF_Label& L)
-Purpose: Returns True if the label represents a shape (simple shape, assembly or reference).
- * XCAFDoc_ShapeTool::IsSimpleShape
-Standard_Boolean XCAFDoc_ShapeTool::IsSimpleShape (const TDF_Label& L)
-Purpose: Returns True if the label is a label of a simple shape.
- * XCAFDoc_ShapeTool::IsReference
-Standard_Boolean XCAFDoc_ShapeTool::IsReference (const TDF_Label& L)
-Purpose: Returns true if L is a located instance of another shape i.e. a reference.
-XCAFDoc_ShapeTool::IsAssembly
-Standard_Boolean XCAFDoc_ShapeTool::IsAssembly (const TDF_Label& L)
-Purpose: Returns True if the label is a label of assembly, i.e. contains sublabels which are assembly components. This is relevant only if IsShape() is True.
- * XCAFDoc_ShapeTool::IsComponent
-Standard_Boolean XCAFDoc_ShapeTool::IsComponent (const TDF_Label& L)
-Purpose: Returns true if L is a reference serving as a component of an assembly.
- * XCAFDoc_ShapeTool::IsSubShape
-Standard_Boolean XCAFDoc_ShapeTool::IsSubShape (const TDF_Label& L)
-Purpose: Returns true if L is a subshape of a top-level shape.
-Standard_Boolean XCAFDoc_ShapeTool::IsSubShape (
-const TDF_Label &shapeL,
-const TopoDS_Shape &sub) const
-Purpose: Checks whether shape sub is a subshape of a shape stored on label shapeL.
- * XCAFDoc_ShapeTool::IsFree
-Standard_Boolean XCAFDoc_ShapeTool::IsFree (const TDF_Label& L)
-Purpose: Returns True if the label is not used by any assembly, i.e. contains sublabels which are assembly components. This is relevant only if IsShape() is True (There is no Father TreeNode on this L).
-<h4>Methods for work with assembly structure </h4>
- * XCAFDoc_ShapeTool::NbComponents
-Standard_Integer XCAFDoc_ShapeTool::NbComponents (const TDF_Label& L,
-const Standard_Boolean getsubchilds)
-Purpose: Returns the number of Assembles components.
- * XCAFDoc_ShapeTool::GetComponents
-Standard_Boolean XCAFDoc_ShapeTool::GetComponents (const TDF_Label& L,
-TDF_LabelSequence& Labels,
-const Standard_Boolean getsubchilds)
-Purpose: Returns a list of components of an assembly. Returns False if the label is not an assembly.
- * XCAFDoc_ShapeTool::AddComponent
-TDF_Label XCAFDoc_ShapeTool::AddComponent (const TDF_Label& assembly,
-const TDF_Label& compL, const TopLoc_Location &Loc) const
-Purpose: Adds a component given by its label and location to the assembly. Note: the assembly must be IsAssembly() or IsSimpleShape().
- * XCAFDoc_ShapeTool::AddComponent
-TDF_Label XCAFDoc_ShapeTool::AddComponent (const TDF_Label& assembly,
-const TopoDS_Shape& comp,
-const Standard_Boolean expand) const
-Purpose: Adds a shape (located) as a component to the assembly. If necessary, creates an additional top-level shape for the component and returns the Label of component. If expand is True and the component is Compound, it will be created as an assembly also. Note: the assembly must be IsAssembly() or IsSimpleShape().
- * XCAFDoc_ShapeTool::RemoveComponent
-void XCAFDoc_ShapeTool::RemoveComponent (const TDF_Label& comp) const
-Purpose: Removes a component from its assembly.
- * XCAFDoc_ShapeTool::UpdateAssembly
-void XCAFDoc_ShapeTool::UpdateAssembly (const TDF_Label& L) const
-Purpose: Updates an assembly at label L.
-<h4>Methods for work with sub-shapes of shape</h4>
- * XCAFDoc_ShapeTool::FindSubShape
-Standard_Boolean XCAFDoc_ShapeTool::FindSubShape (
-const TDF_Label &shapeL, const TopoDS_Shape &sub,
-TDF_Label &L) const
-Purpose: Finds a label for subshape sub of the shape stored on label shapeL. Returns a Null label if it is not found.
- * XCAFDoc_ShapeTool::AddSubShape
-TDF_Label XCAFDoc_ShapeTool::AddSubShape (const TDF_Label &shapeL,
-const TopoDS_Shape &sub) const
-Purpose: Adds a label for subshape sub of the shape stored on label shapeL. Returns a Null label if it is not a subshape.
- * XCAFDoc_ShapeTool::FindMainShape
-TDF_Label XCAFDoc_ShapeTool::FindMainShape (
-const TopoDS_Shape &sub) const
-Purpose: Performs a search among top-level shapes to find the shape containing sub as a subshape. Checks only simple shapes, and returns the first found label (which should be the only one for valid model).
- * XCAFDoc_ShapeTool::GetSubShapes
-Standard_Boolean XCAFDoc_ShapeTool::GetSubShapes (
-const TDF_Label &L, TDF_LabelSequence& Labels)
-Purpose: Returns the list of labels identifying subshapes of the given shape. Returns False if no subshapes are placed on that label.
-<h4>Auxiliary methods</h4>
- * XCAFDoc_ShapeTool::MakeReference
-void XCAFDoc_ShapeTool::MakeReference (const TDF_Label &L,
-const TDF_Label &refL, const TopLoc_Location &loc)
-Purpose: Makes a shape on label L to be a reference to shape refL with location loc.
- * XCAFDoc_ShapeTool::BaseLabel
-TDF_Label XCAFDoc_ShapeTool::BaseLabel () const
-Purpose: returns the label under which shapes are stored.
-@subsection occt_1819379545_68542510410 Class XCAFDoc_ColorTool
-@subsubsection occt_1819379545_685425104101 General description
-Purpose: Attribute containing Colors section of an XDE document.
-Provides tools for management of the Colors section of a document.
-@subsubsection occt_1819379545_685425104102 Methods
-The methods are the following:
-<h4>Constructors</h4>
-XCAFDoc_ShapeTool()
-Purpose: Empty constructor.
-<h4>Method Set</h4>
- * XCAFDoc_ColorTool::Set
-Handle(XCAFDoc_ColorTool) XCAFDoc_ColorTool::Set(const TDF_Label& L)
-Purpose: Creates (if does not exist) a ColorTool.
-<h4>Methods for general structure</h4>
- * XCAFDoc_ColorTool::BaseLabel
-TDF_Label XCAFDoc_ColorTool::BaseLabel() const
-Purpose: Returns the label under which colors are stored
- * XCAFDoc_ColorTool::ShapeTool
-const Handle(XCAFDoc_ShapeTool)& XCAFDoc_ColorTool::ShapeTool()
-Purpose: Returns the internal XCAFDoc_ShapeTool tool
-<h4>Methods for color table management</h4>
- * XCAFDoc_ColorTool::IsColor
-Standard_Boolean XCAFDoc_ColorTool::IsColor (const TDF_Label& lab) const
-Purpose: Returns True if the label belongs to a colortable and is a color definition
- * XCAFDoc_ColorTool::GetColor
-Standard_Boolean XCAFDoc_ColorTool::GetColor (const TDF_Label& lab,
-Quantity_Color& col) const
-Purpose: Returns a color defined by label lab. Returns False if the label is not in the colortable or does not define a color.
- * XCAFDoc_ColorTool::FindColor
-Standard_Boolean XCAFDoc_ColorTool::FindColor (
-const Quantity_Color& col,
-TDF_Label& lab) const
-Purpose: Finds a color definition in the colortable and returns its label if found. Returns False if the color is not found in the colortable.
- * XCAFDoc_ColorTool::FindColor
-TDF_Label XCAFDoc_ColorTool::FindColor (const Quantity_Color& col) const
-Purpose: Finds a color definition in the colortable and returns its label if found (or Null label otherwise)
- * XCAFDoc_ColorTool::AddColor
-TDF_Label XCAFDoc_ColorTool::AddColor (const Quantity_Color& col) const
-Purpose: Adds a color definition to the colortable and returns its label (returns the existing label if the same color is already defined).
- * XCAFDoc_ColorTool::RemoveColor
-void XCAFDoc_ColorTool::RemoveColor (const TDF_Label& lab) const
-Purpose: Removes color from the colortable.
- * XCAFDoc_ColorTool::GetColors
-void XCAFDoc_ColorTool::GetColors (TDF_LabelSequence& Labels) const
-Purpose: Returns a sequence of colors currently stored in the colortable.
-<h4>Methods for assignment of colors to labels</h4>
- * XCAFDoc_ColorTool::SetColor
-void XCAFDoc_ColorTool::SetColor (const TDF_Label& L,
-const TDF_Label& colorL, const XCAFDoc_ColorType type) const
-Purpose: Sets a link with a GUID defined by type (see XCAFDoc::ColorRefGUID()) from label L to a color defined by colorL.
-void XCAFDoc_ColorTool::SetColor (const TDF_Label& L,
-const Quantity_Color& Color,
-const XCAFDoc_ColorType type) const
-Purpose: Sets a link with a GUID defined by type (see XCAFDoc::ColorRefGUID()) from label L to color Color in the colortable. Adds a color as necessary.
- * XCAFDoc_ColorTool::UnSetColor
-void XCAFDoc_ColorTool::UnSetColor (const TDF_Label& L,
-const XCAFDoc_ColorType type) const
-Purpose: Removes a link with a GUID defined by type (see XCAFDoc::ColorRefGUID()) from label L to color Color.
- * XCAFDoc_ColorTool::IsSet
-Standard_Boolean XCAFDoc_ColorTool::IsSet (const TDF_Label& L,
-const XCAFDoc_ColorType type) const
-Purpose: Returns True if label L has a color assignment of the type type.
- * XCAFDoc_ColorTool::GetColor
-Standard_Boolean XCAFDoc_ColorTool::GetColor (const TDF_Label& L,
-const XCAFDoc_ColorType type, TDF_Label& colorL)
-Purpose: Returns a label with a color assigned to L as type. Returns False if no such color is assigned.
-Standard_Boolean XCAFDoc_ColorTool::GetColor (const TDF_Label& L,
-const XCAFDoc_ColorType type, Quantity_Color& color)
-Purpose: Returns a color assigned to L as type. Returns False if no such color is assigned.
-<h4>Methods for assignment of colors to shapes in the Shapes section</h4>
- * XCAFDoc_ColorTool::SetColor
-Standard_Boolean XCAFDoc_ColorTool::SetColor (const TopoDS_Shape& S,
-const TDF_Label& colorL, const XCAFDoc_ColorType type)
-Purpose: Sets a link with a GUID defined by type (see XCAFDoc::ColorRefGUID()) from label L to the color defined by colorL. Returns False if cannot find a label for shape S.
-Standard_Boolean XCAFDoc_ColorTool::SetColor (const TopoDS_Shape& S,
-const Quantity_Color& Color, const XCAFDoc_ColorType type)
-Purpose: Sets a link with a GUID defined by type (see XCAFDoc::ColorRefGUID()) from label L to color Color in the colortable. Adds a color as necessary. Returns False if cannot find a label for shape S.
- * XCAFDoc_ColorTool::UnSetColor
-Standard_Boolean XCAFDoc_ColorTool::UnSetColor (const TopoDS_Shape& S,
-const XCAFDoc_ColorType type)
-Purpose: Removes a link with a GUID defined by type (see XCAFDoc::ColorRefGUID()) from label L to color Color. Returns True if such link existed.
- * XCAFDoc_ColorTool::IsSet
-Standard_Boolean XCAFDoc_ColorTool::IsSet (const TopoDS_Shape& S,
-const XCAFDoc_ColorType type)
-Purpose: Returns True if label L has a color assignment of the type type.
- * XCAFDoc_ColorTool::GetColor
-Standard_Boolean XCAFDoc_ColorTool::GetColor (const TopoDS_Shape& S,
-const XCAFDoc_ColorType type, TDF_Label& colorL)
-Purpose: Returns label with a color assigned to L as type. Returns False if no such color is assigned.
-Standard_Boolean XCAFDoc_ColorTool::GetColor (const TopoDS_Shape& S,
-const XCAFDoc_ColorType type, Quantity_Color& color)
-Purpose: Returns a color assigned to L as type. Returns False if no such color is assigned.
-@subsection occt_1819379545_68542510411 Class XCAFDoc_LayerTool;
-@subsubsection occt_1819379545_685425104111 General description
-Purpose: Attribute containing Layers section of an XDE document.
-Provides tools for management of the Layers section of a document.
-@subsubsection occt_1819379545_685425104112 Methods
-The methods are the following:
-<h4>Constructors</h4>
-XCAFDoc_LayerTool()
-Purpose: Empty constructor.
-<h4>Method Set</h4>
- * XCAFDoc_LayerTool::Set
-Handle(XCAFDoc_LayerTool) XCAFDoc_LayerTool::Set(const TDF_Label& L)
-<h4>Method of general structure</h4>
- * XCAFDoc_LayerTool::BaseLabel
-TDF_Label XCAFDoc_LayerTool::BaseLabel() const
-Purpose: Returns the label under which Layers are stored.
- * XCAFDoc_LayerTool::ShapeTool
-const Handle(XCAFDoc_ShapeTool)& XCAFDoc_LayerTool::ShapeTool()
-Purpose: Returns the internal XCAFDoc_ShapeTool tool.
-<h4>Methods for Layer table management</h4>
- * XCAFDoc_LayerTool::IsLayer
-Standard_Boolean XCAFDoc_LayerTool::IsLayer(const TDF_Label& lab) const
-Purpose: Returns True if a label belongs to the Layertable and is a Layer definition.
- * XCAFDoc_LayerTool::GetLayer
-Standard_Boolean XCAFDoc_LayerTool::GetLayer (const TDF_Label& lab,
-TCollection_ExtendedString& aLayer) const
-Purpose: Returns a Layer defined by label lab. Returns False if the label is not in Layertable or does not define aLayer.
- * XCAFDoc_LayerTool::FindLayer
-Standard_Boolean XCAFDoc_LayerTool::FindLayer (
-const TCollection_ExtendedString& aLayer,
-TDF_Label& lab) const
-Purpose: Finds a Layer definition in theLayertable and returns its label if found. Returns False if the Layer is not found in the Layertable.
-TDF_Label XCAFDoc_LayerTool::FindLayer(
-const TCollection_ExtendedString& aLayer) const
-Purpose: Finds a Layer definition in the Layertable and returns its label if found (or the Null label otherwise).
- * XCAFDoc_LayerTool::AddLayer
-TDF_Label XCAFDoc_LayerTool::AddLayer(
-const TCollection_ExtendedString& aLayer) const
-Purpose: Adds a Layer definition to the Layertable and returns its label (returns the existing label if the same Layer is already defined).
- * XCAFDoc_LayerTool::RemoveLayer
-void XCAFDoc_LayerTool::RemoveLayer(const TDF_Label& lab) const
-Purpose: Removes a Layer from the Layertable.
- * XCAFDoc_LayerTool::GetLayerLabels
-void XCAFDoc_LayerTool::GetLayerLabels(TDF_LabelSequence& Labels) const
-Purpose: Returns a sequence of Layers currently stored in the Layertable.
- * XCAFDoc_LayerTool::SetLayer
-void XCAFDoc_LayerTool::SetLayer(const TDF_Label& L,
-const TDF_Label& LayerL,
-const Standard_Boolean shapeInOneLayer) const
-Purpose: Sets a link from label L to a Layer defined by LayerL, an optional parameter shapeInOneLayer shows whether a shape could be in a number of layers or only in one.
-void XCAFDoc_LayerTool::SetLayer(const TDF_Label& L,
-const TCollection_ExtendedString& aLayer,
-const Standard_Boolean shapeInOneLayer) const
-Purpose: Sets a link from label L to Layer aLayer in the Layertable. Adds aLayer as necessary; an optional parameter shapeInOneLayer shows whether a shape could be in a number of layers or only in one.
- * XCAFDoc_LayerTool::UnSetLayers
-void XCAFDoc_LayerTool::UnSetLayers(const TDF_Label& L) const
-Purpose: Removes a link from label L to all layers.
- * XCAFDoc_LayerTool::UnSetOneLayer
-Standard_Boolean XCAFDoc_LayerTool::UnSetOneLayer(
-const TDF_Label& L,
-const TCollection_ExtendedString& aLayer) const
-Purpose: Removes a link from label L and Layer aLayer. Returns FALSE if no such layer exists.
- * XCAFDoc_LayerTool::IsSet
-Standard_Boolean XCAFDoc_LayerTool::IsSet(const TDF_Label& L,
-const TCollection_ExtendedString& aLayer) const
-Purpose: Returns True if label L has a Layer associated with the aLayer.
- * XCAFDoc_LayerTool::GetLayers
-Standard_Boolean XCAFDoc_LayerTool::GetLayers(const TDF_Label& L,
-Handle(TColStd_HSequenceOfExtendedString)& aLayerS)
-Purpose: Returns a sequence of strings aLayerS that are associated with label L.
-Handle(TColStd_HSequenceOfExtendedString) XCAFDoc_LayerTool::GetLayers(
-const TDF_Label& L)
-Purpose: Returns a sequence of strings that are associated with label L.
- * XCAFDoc_LayerTool::GetShapesOfLayer
-void XCAFDoc_LayerTool::GetShapesOfLayer(const TDF_Label& layerL,
-TDF_LabelSequence& ShLabels) const
-Purpose: Returns a sequence of shape labels that are assigned with layers to ShLabels.
- * XCAFDoc_LayerTool::IsVisible
-Standard_Boolean XCAFDoc_LayerTool::IsVisible (
-const TDF_Label& layerL) const
-Purpose: Return TRUE if a layer is visible, FALSE if it is invisible.
- * XCAFDoc_LayerTool::SetVisibility
-void XCAFDoc_LayerTool::SetVisibility (const TDF_Label& layerL,
-const Standard_Boolean isvisible) const
-Purpose: Set the visibility of a layer. If a layer is invisible when on its layer will set UAttribute with a corresponding GUID.
-<h4>Methods for assignment of Layers to shapes in the Shapes section</h4>
- * XCAFDoc_LayerTool::SetLayer
-Standard_Boolean XCAFDoc_LayerTool::SetLayer(const TopoDS_Shape& Sh,
-const TDF_Label& LayerL,
-const Standard_Boolean shapeInOneLayer)
-Purpose: Sets a link from a label containing shape Sh with a layer situated at label LayerL. An optional parameter shapeInOneLayer shows whether a shape could be in a number of layers or only in one. Returns FALSE if no such shape Sh or label LayerL exists.
-Standard_Boolean XCAFDoc_LayerTool::SetLayer(const TopoDS_Shape& Sh,
-const TCollection_ExtendedString& aLayer,
-const Standard_Boolean shapeInOneLayer)
-Purpose: Sets a link from a label containing shape Sh with layer aLayer. Adds aLayer to LayerTable if necessary. An optional parameter shapeInOneLayer shows whether a shape could be in a number of layers or only in one. Returns FALSE if no such shape Sh exists.
- * XCAFDoc_LayerTool::UnSetLayers
-Standard_Boolean XCAFDoc_LayerTool::UnSetLayers(const TopoDS_Shape& Sh)
-Purpose: Removes a link between shape Sh and all Layers at the LayerTable. Returns FALSE if no such shape Sh exists in XCAF Document.
- * XCAFDoc_LayerTool::UnSetOneLayer
-Standard_Boolean XCAFDoc_LayerTool::UnSetOneLayer(
-const TopoDS_Shape& Sh,
-const TCollection_ExtendedString& aLayer)
-Purpose: Removes a link between shape Sh and layer aLayer. Returns FALSE if no such layer aLayer or shape Sh exists.
- * XCAFDoc_LayerTool::IsSet
-Standard_Boolean XCAFDoc_LayerTool::IsSet(const TopoDS_Shape& Sh,
-Purpose: Returns True if shape Sh has a Layer associated with the aLayer.
- * XCAFDoc_LayerTool::GetLayers
-Standard_Boolean XCAFDoc_LayerTool::GetLayers(const TopoDS_Shape& Sh,
-Handle(TColStd_HSequenceOfExtendedString)& aLayerS)
-Purpose: Returns a sequence of strings aLayerS associated with shape Sh.
-Handle(TColStd_HSequenceOfExtendedString) XCAFDoc_LayerTool::GetLayers(
-const TopoDS_Shape& Sh)
-Purpose: Returns a sequence of strings associated with shape Sh.
-@subsection occt_1819379545_68542510412 Class XCAFDoc_GraphNode;
-@subsubsection occt_1819379545_685425104121 General description
-Purpose: Attribute containing a sequence of father and child labels.
-Creates and allows to work with Graph in XCAFDocument.
-@subsubsection occt_1819379545_685425104122 Methods
-The methods are the following:
-<h4>Constructors</h4>
-XCAFDoc_GraphNode()
-Purpose: Empty constructor.
-<h4>Class methods working on the node </h4>
- * XCAFDoc_GraphNode::Find
-Standard_Boolean XCAFDoc_GraphNode::Find(const TDF_Label& L,
-Handle(XCAFDoc_GraphNode)& G)
-Purpose: Shortcut to search a Graph node attribute with a default GraphID. Returns true if found.
- * XCAFDoc_GraphNode::GetDefaultGraphID
-const Standard_GUID& XCAFDoc_GraphNode::GetDefaultGraphID()
-Purpose: Returns a default Graph ID. This ID is used by the Set method without an explicit tree ID.
- * XCAFDoc_GraphNode::Set
-Handle(XCAFDoc_GraphNode) XCAFDoc_GraphNode::Set(const TDF_Label& L)
-Purpose: Finds or Creates a GraphNode attribute on the label L with a default Graph ID, returned by the method GetDefaultGraphID(). Returns the created/found GraphNode attribute.
-Handle(XCAFDoc_GraphNode) XCAFDoc_GraphNode::Set (const TDF_Label& L,
-const Standard_GUID& explicitID)
-Purpose: Finds or Creates a GraphNode attribute on the label L, with an explicit tree ID. ExplicitGraphID is the ID returned by the TDF_Attribute::ID() method. Returns the found/created GraphNode attribute.
-<h4>Instance methods</h4>
- * XCAFDoc_GraphNode::SetFather
-Standard_Integer XCAFDoc_GraphNode::SetFather(
-const Handle(XCAFDoc_GraphNode)& F)
-Purpose: Sets GraphNode F as the father of this attribute and returns an index of F in a sequence containing Father GraphNodes. Returns an index of F from GraphNodeSequnece.
- * XCAFDoc_GraphNode::SetChild
-Standard_Integer XCAFDoc_GraphNode::SetChild(
-const Handle(XCAFDoc_GraphNode)& Ch)
-Purpose: Sets GraphNode Ch as a child of this attribute and returns an index of Ch in a sequence containing Children GraphNodes. Returns an index of Ch from GraphNodeSequnece.
- * XCAFDoc_GraphNode::UnSetFather
-void XCAFDoc_GraphNode::UnSetFather(const Handle(XCAFDoc_GraphNode)& F)
-Purpose: Removes F from Fathers GraphNodeSequence and removes the link between the father and the child.
-void XCAFDoc_GraphNode::UnSetFather(const Standard_Integer Findex)
-Purpose: Removes Father GraphNode by index from Fathers GraphNodeSequence and removes the link between the father and the child.
- * XCAFDoc_GraphNode::UnSetFatherlink
-void XCAFDoc_GraphNode::UnSetFatherlink(
-const Handle(XCAFDoc_GraphNode)& F)
-Purpose: Removes the link between the father and the child.
- * XCAFDoc_GraphNode::UnSetChild
-void XCAFDoc_GraphNode::UnSetChild(const Handle(XCAFDoc_GraphNode)& Ch)
-Purpose: Removes Ch from GraphNodeSequence and removes the link between the father and the child.
-void XCAFDoc_GraphNode::UnSetChild(const Standard_Integer Chindex)
-Purpose: Removes Child GraphNode by index from Children GraphNodeSequence and removes the link between the father and the child.
- * XCAFDoc_GraphNode::UnSetChildlink
-void XCAFDoc_GraphNode::UnSetChildlink(
-const Handle(XCAFDoc_GraphNode)& Ch)
-Purpose: Removes the link between the father and the child.
- * XCAFDoc_GraphNode::GetFather
-Handle(XCAFDoc_GraphNode) XCAFDoc_GraphNode::GetFather(
-const Standard_Integer Findex) const
-Purpose: Returns GraphNode by index from GraphNodeSequence.
- * XCAFDoc_GraphNode::GetChild
-Handle(XCAFDoc_GraphNode) XCAFDoc_GraphNode::GetChild(
-const Standard_Integer Chindex) const
-Purpose: Returns GraphNode by index from GraphNodeSequence.
- * XCAFDoc_GraphNode::FatherIndex
-Standard_Integer XCAFDoc_GraphNode::FatherIndex(
-const Handle(XCAFDoc_GraphNode)& F) const
-Purpose: Returns the index of F, or zero if there is no such Graphnode.
- * XCAFDoc_GraphNode::ChildIndex
-Standard_Integer XCAFDoc_GraphNode::ChildIndex(
-const Handle(XCAFDoc_GraphNode)& Ch) const
-Purpose: Returns the index of Ch, or zero if there is no such Graphnode.
- * XCAFDoc_GraphNode::IsFather
-Standard_Boolean XCAFDoc_GraphNode::IsFather(
-const Handle(XCAFDoc_GraphNode)& Ch) const
-Purpose: Returns True if this attribute is the father of Ch.
- * XCAFDoc_GraphNode::IsChild
-Standard_Boolean XCAFDoc_GraphNode::IsChild(
-const Handle(XCAFDoc_GraphNode)& F) const
-Purpose: Returns True if this attribute is a child of F.
- * XCAFDoc_GraphNode::NbFathers
-Standard_Integer XCAFDoc_GraphNode::NbFathers() const
-Purpose: Returns the Number of Father GraphNodes.
- * XCAFDoc_GraphNode::NbChildren
-Standard_Integer XCAFDoc_GraphNode::NbChildren() const
-Purpose: Returns the Number of Children GraphNodes.
-@subsection occt_1819379545_68542510413 Package methods
-Purpose: Definition of GUIDs
-<h4>Methods:</h4>
- * XCAFDoc::AssemblyGUID
-Standard_GUID XCAFDoc::AssemblyGUID ()
-Purpose: Returns a GUID for UAttribute identifying the assembly
- * XCAFDoc::ShapeRefGUID
-Standard_GUID XCAFDoc::ShapeRefGUID ()
-Purpose: Returns a GUID for TreeNode representing an assembly link.
- * XCAFDoc::ColorRefGUID
-Standard_GUID XCAFDoc::ColorRefGUID (const XCAFDoc_ColorType type)
-Purpose: Returns a GUID for TreeNode representing specified types of colors.
- * XCAFDoc::LayerRefGUID
-Standard_GUID XCAFDoc::LayerRefGUID ()
-Purpose: Returns a GUID from Standard.
- * XCAFDoc::InvisibleGUID
-Standard_GUID XCAFDoc::InvisibleGUID ()
-Purpose: Returns a GUID from Standard;
- * XCAFDoc::ExternRefGUID
-Standard_GUID XCAFDoc::ExternRefGUID ()
-Purpose: Returns a GUID for UAttribute identifying an external reference.
+In addition, if an application has a data structure far from these notions, it can get data (such as Colors and Names on Shapes) according to its needs, but without having to consider the whole.
projects / occt-copy.git / commitdiff
