diff --git a/.gitattributes b/.gitattributes index 4c8bc7bf98..e805ec9760 100644 --- a/.gitattributes +++ b/.gitattributes @@ -34,6 +34,7 @@ *.brep eol=lf *.rle eol=lf *.vrml eol=lf +*.md eol=lf FILES eol=lf PACKAGES eol=lf EXTERNLIB eol=lf diff --git a/.gitignore b/.gitignore index 63daa70aeb..d28e2cee45 100644 --- a/.gitignore +++ b/.gitignore @@ -7,6 +7,7 @@ /ao1 /sil /wnt +/doc /drv /inc /work @@ -45,8 +46,6 @@ Release /*.am /*.m4 /*.ac -/*.sh -/*.bat /autom4te.cache /build_configure /configure diff --git a/LICENSE b/LICENSE index 0fe1d8bbac..77b310c566 100644 --- a/LICENSE +++ b/LICENSE @@ -120,14 +120,16 @@ END OF THE TERMS AND CONDITIONS OF THIS LICENSE -Open CASCADE S.A.S. is a French socit par actions simplifie having its main offices at 1, place des Frres Montgolfier, 78280 Guyancourt, France. Its web site is located at the following address www.opencascade.com +Open CASCADE S.A.S. is a French socit par actions simplifie having its main offices at 1, place in Frres Montgolfier, 78280 Guyancourt, France. Its web site is located at the following address www.opencascade.com Open CASCADE Technology Public License Schedule "A" -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 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 Frres Montgolfier, 78280 Guyancourt, France. The Original Code is copyright Open CASCADE S.A.S., 2001. All rights reserved. diff --git a/dox/DoxygenLayout.xml b/dox/DoxygenLayout.xml new file mode 100644 index 0000000000..21d15aaef8 --- /dev/null +++ b/dox/DoxygenLayout.xml @@ -0,0 +1,188 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/dox/FILES.txt b/dox/FILES.txt new file mode 100644 index 0000000000..0dbc6e01f0 --- /dev/null +++ b/dox/FILES.txt @@ -0,0 +1,31 @@ +overview/overview.md +overview/tutorial/tutorial.md +technical_overview/technical_overview.md + +user_guides/user_guides.md +user_guides/foundation_classes/foundation_classes.md +user_guides/modeling_data/modeling_data.md +user_guides/modeling_algos/modeling_algos.md +user_guides/visualization/visualization.md +user_guides/iges/iges.md +user_guides/step/step.md +user_guides/xde/xde.md +user_guides/ocaf/ocaf.md +user_guides/tobj/tobj.md +user_guides/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/building/automake.md +dev_guides/building/cmake.md +dev_guides/building/code_blocks.md +dev_guides/building/msvc.md +dev_guides/building/xcode.md + +overview/license.md \ No newline at end of file diff --git a/dox/Overview/LICENSE.md b/dox/Overview/LICENSE.md new file mode 100644 index 0000000000..afb9b4b517 --- /dev/null +++ b/dox/Overview/LICENSE.md @@ -0,0 +1,157 @@ +License {#occt_pubic_license} +======= + +## Open CASCADE Technology Public License + +*License version: 6.6* @htmlonly
@endhtmlonly +*March, 2013* + +Open CASCADE S.A.S. releases and makes publicly available the source code of the software Open CASCADE Technology to the free software development community under the terms and conditions of this license. + +It is not the purpose of this license to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this license has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice. + + +Please read this license carefully and completely before downloading this software. By downloading, using, modifying, distributing and sublicensing this software, you indicate your acceptance to be bound by the terms and conditions of this license. If you do not want to accept or cannot accept for any reasons the terms and conditions of this license, please do not download or use in any manner this software. + +### 1. Definitions + +Unless there is something in the subject matter or in the context inconsistent therewith, the capitalized terms used in this License shall have the following meaning. + +"Applicable Intellectual Property Rights" means (a) with respect to the Initial Developer, any rights under patents or patents applications or other intellectual property rights that are now or hereafter acquired, owned by or assigned to the Initial Developer and that cover subject matter contained in the Original Code, but only to the extent necessary to use, reproduce, modify, distribute or sublicense the Original Code without infringement; and (b) with respect to You or any Contributor, any rights under patents or patents applications or other intellectual property rights that are now or hereafter acquired, owned by or assigned to You or to such Contributor and that cover subject matter contained in Your Modifications or in such Contributor's Modifications, taken alone or in combination with Original Code. + +"Contributor" means each individual or legal entity that creates or contributes to the creation of any Modification, including the Initial Developer. + +"Derivative Program": means a new program combining the Software or portions thereof with other source code not governed by the terms of this License. + +"Initial Developer": means Open CASCADE S.A.S., with main offices at 1, place des Frères Montgolfier, 78280 Guyancourt, France. + +"Modifications": mean any addition to, deletion from or change to the substance or the structure of the Software. When source code of the Software is released as a series of files, a Modification is: (a) any addition to, deletion from or change to the contents of a file containing the Software or (b) any new file or other representation of computer program statements that contains any part of the Software. By way of example, Modifications include any debug of, or improvement to, the Original Code or any of its components or portions as well as its next versions or releases thereof. + +"Original Code": means (a) the source code of the software Open CASCADE Technology originally made available by the Initial Developer under this License, including the source code of any updates or upgrades of the Original Code and (b) the object code compiled from such source code and originally made available by Initial Developer under this License. + +"Software": means the Original Code, the Modifications, the combination of Original Code and any Modifications or any respective portions thereof. + +"You" or "Your": means an individual or a legal entity exercising rights under this License. + + +### 2. Acceptance of license + +By using, reproducing, modifying, distributing or sublicensing the Software or any portion thereof, You expressly indicate Your acceptance of the terms and conditions of this License and undertake to act in accordance with all the provisions of this License applicable to You. + + +### 3. Scope and purpose + +This License applies to the Software and You may not use, reproduce, modify, distribute, sublicense or circulate the Software, or any portion thereof, except as expressly provided under this License. Any attempt to otherwise use, reproduce, modify, distribute or sublicense the Software is void and will automatically terminate Your rights under this License. + + +### 4. Contributor license + +Subject to the terms and conditions of this License, the Initial Developer and each of the Contributors hereby grant You a world-wide, royalty-free, irrevocable and non-exclusive license under the Applicable Intellectual Property Rights they own or control, to use, reproduce, modify, distribute and sublicense the Software provided that: + +You reproduce in all copies of the Software the copyright and other proprietary notices and disclaimers of the Initial Developer as they appear in the Original Code and attached hereto as Schedule "A" and any other notices or disclaimers attached to the Software and keep intact all notices in the Original Code that refer to this License and to the absence of any warranty; +You include a copy of this License with every copy of the Software You distribute; +If you distribute or sublicense the Software (as modified by You or on Your behalf as the case may be), You cause such Software to be licensed as a whole, at no charge, to all third parties, under the terms and conditions of the License, making in particular available to all third parties the source code of the Software; +You document all Your Modifications, indicate the date of each such Modifications, designate the version of the Software You used, prominently include a file carrying such information with respect to the Modifications and duplicate the copyright and other proprietary notices and disclaimers attached hereto as Schedule "B" or any other notices or disclaimers attached to the Software with your Modifications. + +For greater certainty, it is expressly understood that You may freely create Derivative Programs (without any obligation to publish such Derivative Program) and distribute same as a single product. In such case, You must ensure that all the requirements of this License are fulfilled for the Software or any portion thereof. + + +### 5. Your license + +You hereby grant all Contributors and anyone who becomes a party under this License a world-wide, non-exclusive, royalty-free and irrevocable license under the Applicable Intellectual Property Rights owned or controlled by You, to use, reproduce, modify, distribute and sublicense all Your Modifications under the terms and conditions of this License. + + +### 6. Software subject to license + +Your Modifications shall be governed by the terms and conditions of this License. You are not authorized to impose any other terms or conditions than those prevailing under this License when You distribute and/or sublicense the Software, save and except as permitted under Section 7 hereof. + + +### 7. Additional terms + +You may choose to offer, on a non-exclusive basis, and to charge a fee for any warranty, support, maintenance, liability obligations or other rights consistent with the scope of this License with respect to the Software (the "Additional Terms") to the recipients of the Software. However, You may do so only on Your own behalf and on Your sole and exclusive responsibility. You must obtain the recipient's agreement that any such Additional Terms are offered by You alone, and You hereby agree to indemnify, defend and hold the Initial Developer and any Contributor harmless for any liability incurred by or claims asserted against the Initial Developer or any Contributors with respect to any such Additional Terms. + + +### 8. Disclaimer of warranty + +The Software is provided under this License on an "as is" basis, without warranty of any kind, including without limitation, warranties that the Software is free of defects, merchantable, fit for a particular purpose or non-infringing. The entire risk as to the quality and performance of the Software is with You. + + +### 9. Liability + +Under no circumstances shall You, the Initial Developer or any Contributor be liable to any person for any direct or indirect damages of any kind including, without limitation, damages for loss of goodwill, loss of data, work stoppage, computer failure or malfunction or any and all other commercial damages or losses resulting from or relating to this License or indirectly to the use of the Software. + + +### 10. Trademark + +This License does not grant any rights to use the trademarks, trade names and domain names "MATRA", "EADS Matra Datavision", "CAS.CADE", "Open CASCADE", "opencascade.com" and "opencascade.org" or any other trademarks, trade names or domain names used or owned by the Initial Developer. + + +### 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. + + +### 12. Term + +This License is granted to You for a term equal to the remaining period of protection covered by the intellectual property rights applicable to the Original Code. + + +### 13. Termination + +In case of termination, as provided in Section 3 above, You agree to immediately stop any further use, reproduction, modification, distribution and sublicensing of the Software and to destroy all copies of the Software that are in Your possession or control. All sublicenses of the Software which have been properly granted prior to termination shall survive any termination of this License. In addition, Sections 5, 8 to 11, 13.2 and 15.2 of this License, in reason of their nature, shall survive the termination of this License for a period of fifteen (15) years. + + +### 14. Versions of the license + +The Initial Developer may publish new versions of this License from time to time. Once Original Code has been published under a particular version of this License, You may choose to continue to use it under the terms and conditions of that version or use the Original Code under the terms of any subsequent version of this License published by the Initial Developer. + + +### 15. Miscellaneous + +#### 15.1 Relationship of Parties + +This License will not be construed as creating an agency, partnership, joint venture or any other form of legal association between You and the Initial Developer, and You will not represent to the contrary, whether expressly, by implication or otherwise. + +#### 15.2 Independent Development + +Nothing in this License will impair the Initial Developer's right to acquire, license, develop, have others develop for it, market or distribute technology or products that perform the same or similar functions as, or otherwise compete with, Modifications, Derivative Programs, technology or products that You may develop, produce, market or distribute. + +#### 15.3 Severability + +If for any reason a court of competent jurisdiction finds any provision of this License, or portion thereof, to be unenforceable, that provision of the License will be enforced to the maximum extent permissible so as to effect the economic benefits and intent of the parties, and the remainder of this License will continue in full force and extent. + + +@htmlonly
@endhtmlonly +#### END OF THE TERMS AND CONDITIONS OF THIS LICENSE + +Open CASCADE S.A.S. is a French société par actions simplifiée having its main offices at 1, place in Frères Montgolfier, 78280 Guyancourt, France. Its web site is located at the following address http://www.opencascade.com + + +#### Open CASCADE Technology Public License + +#### Schedule "A" + +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 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. + +Please see the License for the specific terms and conditions governing rights and limitations under the License". + +#### End of Schedule "A" + + +#### Open CASCADE Technology Public License + +#### 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. + +Modifications to the Original Code have been made by ________________________. Modifications are copyright © [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". + +#### End of Schedule "B" + +@htmlonly
@endhtmlonly \ No newline at end of file diff --git a/dox/Overview/Overview.md b/dox/Overview/Overview.md new file mode 100644 index 0000000000..eb119f0966 --- /dev/null +++ b/dox/Overview/Overview.md @@ -0,0 +1,604 @@ +Overview {#mainpage} +======== + +@section OCCT_OVW_SECTION_1 Welcome + +Welcome to Open CASCADE Technology version 6.6.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. + +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 +applications on Windows and Linux platforms. + +@htmlonly
@endhtmlonly http://www.opencascade.org + +![](/overview/images/overview_occttransparent.png) + +Copyright © 2001-2013 OPEN CASCADE S.A.S. + +![](/resources/occt_logo.png) + +@htmlonly
@endhtmlonly + +@section OCCT_OVW_SECTION_2 Copyrights + +Copyright© 2001-2013 by OPEN CASCADE S.A.S. All rights reserved. + + Trademark information +---------------------- + +You are hereby informed that all software is a property of its respective authors and is protected by +international and domestic laws on intellectual property and trademarks. +Should you need further information, please directly contact the authors. + +CAS.CADE and Open CASCADE are registered trademarks of OPEN CASCADE S.A.S. + + Acknowledgement +------------------ + +The following parties are acknowledged for producing tools which are used within +Open CASCADE Technology libraries or for release preparation. + +You are hereby informed that all rights to the software listed below belong to its respective +authors and such software may not be freely available and/or be free of charge for any kind +of use or purpose. We strongly recommend that you carefully read the license of these products +and, in case you need any further information, directly contact their authors. + +**Qt** is a cross-platform application framework that is widely used for developing application software +with graphical user interface (GUI). Qt is free and open source software distributed under +the terms of the GNU Lesser General Public License. In OCCT Qt is used for programming samples. +If you need further information on Qt, please, refer to Qt Homepage (qt.digia.com). + +**Tcl** is a high-level programming language. Tk is a graphical user interface (GUI) toolkit, +with buttons, menus, listboxes, scrollbars, and so on. Taken together Tcl and Tk provide a solution +to develop cross-platform graphical user interfaces with a native look and feel. Tcl/Tk is under copyright by +Scriptics Corp., Sun Microsystems, and other companies. However, Tcl/Tk is an open source, and +the copyright allows you to use, modify, and redistribute Tcl/Tk for any purpose, without an +explicit license agreement and without paying any license fees or royalties. +To use Tcl/Tk, please refer to the Licensing Terms (http://www.tcl.tk/software/tcltk/license.html). + +**Robert Boehne** has developed **GNU Autoconf**, **Automake** and **Libtool** scripts and makefiles +for the Open CASCADE project http://sourceforge.net/projects/autoopencas/, +which became an initial groundwork for the build scripts based on respective GNU tools +(autoconf, automake and libtool) in Open CASCADE Technology version 4.0. +These scripts are now maintained by the OPEN CASCADE company. + +**GL2PS** is developed by Christophe Geuzaine and others. It is OpenGL to PostScript printing library. +The library is licensed under GL2PS LICENSE http://www.geuz.org/gl2ps/COPYING.GL2PS Version 2, November 2003. + +**FreeType 2** is developed by Antoine Leca, David Turner, Werner Lemberg and others. +It is a software font engine that is designed to be small, efficient, highly customizable and +portable while capable of producing high-quality output (glyph images). This product +can be used in graphic libraries, display servers, font conversion tools, +text image generation tools, and many other products. + +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. +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. +TBB is available under GPLv2 license with the runtime exception. + +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 +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. + +**Graphviz** is open source graph visualization software developed by John Ellson, Emden Gansner, Yifan Hu and Arif Bilgin. +Graph visualization is representiation of structured information as diagrams of abstract graphs and networks. +This product is used together with Doxygen in Open CASCADE Technology for automatic creation of Technical Documentation +(generation of dependency graphs). Current versions of Graphviz are licensed on an open source +basis only under The Eclipse Public License (EPL) (http://www.graphviz.org/License.php). + +**Inno Setup** is a free script-driven installation system created in CodeGear Delphi by Jordan Russell. +In OCCT Inno Setup is used to create Installation Wizard on Windows. +It is licensed under Inno Setup License (http://www.jrsoftware.org/files/is/license.txt). + +**FreeImage** is an Open Source library supporting popular graphics image formats, such as PNG, BMP, JPEG, TIFF +and others used by multimedia applications. This library is developed by Hervé Drolon and Floris van den Berg. +FreeImage is easy to use, fast, multithreading safe, compatible with all 32-bit or 64-bit versions of Windows, +and cross-platform (works both with Linux and Mac OS X). FreeImage is licensed under the +GNU General Public License, version 2.0 (GPLv2) and +the FreeImage Public License (FIPL) (http://freeimage.sourceforge.net/freeimage-license.txt). + +Adobe Systems, Inc. provides **Adobe Acrobat Professional**, which is a software to view, create, manipulate, +print and manage files in Portable Document Format (PDF). +This product is used in OCCT for the development and update of User's Guides. + +The same developer provides **Robohelp HTML** that allows developing online Help for applications that are run on the Web and on Intranets. +**Robohelp HTML X5.0.2** is used in OCCT for the development and update of OCCT Overview. + +**Linux** is a registered trademark of Linus Torvalds. + +**Windows** is a registered trademark of Microsoft Corporation in the United States and other countries. + +**Mac** and the Mac logo are trademarks of Apple Inc., registered in the U.S. and other countries. + + +@section OCCT_OVW_SECTION_3 Introduction + + +This document is just an introduction to Open CASCADE Technology (OCCT) dealing with +compatibility and installation issues and providing a general description of OCCT modules +and other features. All modules and development tools are described in User's Guides, available in +Adobe Portable Document Format (PDF). To read this format, you need Adobe Acrobat Reader, +which is a freeware and can be downloaded from the Adobe site. +All user guides can be accessed directly from this help. + +Alongside with PDF User Guides, OCCT suggests its users full reference documentation on all +implementation classes automatically generated by Doxygen software. +This Doxygen generated documentation is supplied in the form of a separate package, +in a usual html file format. + +Reference documentation is presented in **Modules --> Toolkits --> Packages --> Classes** +logic structure with cross-references to all OCCT classes and complete in-browser search by all classes. + +**Recommendation for generation of reference documentation** + +Reference documentation can be generated by OCCT binary WOK package that +is available for downloading from www.opencascade.org and dev.opencascade.org sites. + +Prerequisites: + + * Doxygen version 1.7.4 or higher + * Graphviz version 2.28.0 or higher + +Run WOK (cd \/site folder): + +* Using WOK TCL shell: + > wok_tclsh.sh + +* Using Emacs editor: + > wok_emacs.sh + +In the WOK prompt, step into your workbench: + + >wokcd + +In your workbench, use **wgendoc** command with –h argument to get information about arguments of **wgendoc** command: + + >wgendoc -h + +then run **wgendoc** command with required arguments + +e.g., wgendoc –output=d:/occt/doc {–m=Draw Visualization} -chm + + +@section OCCT_OVW_SECTION_4 Installation + +Open CASCADE Technology can be installed with binaries precompiled by +Visual C++ 2008 using Installation Procedure under Windows platform only + +The source package and the building tools are available for self-dependent +preparation binary files on Unix and Windows platforms. + +@subsection OCCT_OVW_SECTION_4_1 Windows + +**Recommendation:** + +If you have a previous version of OCCT installed on your station, +and you do not plan to use it along with the new version, you might want to uninstall +the previous version (using Control Panel, Add/Remove Programs) before +the installation of this new version, to avoid possible problems +(conflict of system variables, paths, etc). + +**Attention:** For full installation OCCT requires approximately 650 Mb of disk space, +but during the installation process you will need 1,2 Gb of free disk space. + +OCCT installation with reference documentation requires 1,4 Gb on disk. + + * Download the OCCT installer from OPEN CASCADE web site using the link. you have been provided + * Launch the installer and follow the instructions. + +### Third-party tools + + +The includes and binaries of third-party libraries necessary for building and launching +OCCT are included into binary distribution (built with Visual C++ 2008). +To recompile OCCT libraries with other Visual C++ versions, +it is necessary to install headers and libraries of these third-party products. + +The recommended way to do this is to download each of the third-party tools from its web site +and build it using the relevant tools. For additional convenience of the users, +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): + +![](/overview/images/overview_installation.png) + +### Description of directory tree + + + * **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; + + +@subsection OCCT_OVW_SECTION_4_2 System Environment Variables + +To run any Open CASCADE Technology application you need to set the environment variables. + +### On Windows + + +You can define the environment variables with env.bat script located in the +OpenCACADE/ros folder. This script accepts two arguments to be used: +the version of Visual Studio (vc8, vc9, or vc10) and the architecture (win32 or win64). + +The additional environment settings necessary for compiling OCCT libraries and samples +by Microsoft Visual Studio can be set using script custom.bat located in the same folder. +You might need to edit this script to correct the paths to third-party libraries +if they are installed on your system in a non-default location. + +Script msvc.bat can be used with the same arguments for immediate launch of Visual Studio for (re)compiling OCCT. + +### On Unix + + + If OCCT was built by Code::Blocks, you can define the environment variables with env_cbp.sh or custom_cbp.sh script. + + If OCCT was built by Automake, you can define the environment variables with env_amk.sh or custom_amk.sh script. + +The scripts are located in the OpenCACADE/ros folder of the source package. + + +### Description of system variables: + + + * **CASROOT** is used to define the root directory of Open CASCADE Technology; + * **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 + 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; + if set to 0, memory block is returned as it is; + * **MMGT_CELLSIZE** defines the maximal size of blocks allocated in large pools of memory. Default is 200; + * **MMGT_NBPAGES** defines the size of memory chunks allocated for small blocks in pages + (operating-system dependent). Default is 10000; + * **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; + +**Special 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. + + * **CSF_LANGUAGE** is required to define the default language of messages; + * **CSF_EXCEPTION_PROMPT** – if defined and set to 1 then a diagnostic message is displayed in case of an exception; + * **CSF_MDTVFontDirectory** accesses the fonts that can be used in OCCT; + * **CSF_MDTVTexturesDirectory** defines the directory for available textures when using texture mapping; + * **CSF_UnitsDefinition** and **CSF_UnitsLexicon** are required by programs considering units; + * **CSF_SHMessage** is required in order to define the path to the messages file for *ShapeHealing*; + * **CSF_XSMessage** is required in order to define the path to the messages file for **STEP** and **IGES** translators; + * **CSF_StandardDefaults** and **CSF_PluginDefaults** are required in order to maintain CASCADE Persistence mechanism to make possible any open/save operations with OCAF documents; + * **CSF_StandardLiteDefaults** is required in order to maintain *OCCT Persistence mechanism* to make possible any open/save operations with Lite OCAF documents; + * **CSF_XCAFDefaults** any open/save operations for **XDE** documents; + * **CSF_GraphicShr** is required to define the path to the *TKOpenGl* library; + * **CSF_IGESDefaults** and **CSF_STEPDefaults** are required for **IGES** and **STEP** translators correspondingly in order to define the path to the resource files; + * **CSF_XmlOcafResource** is required in order to set the path to **XSD** resources, which defines XML grammar. + +As part of XML persistence support, these definitions can be used by end users +in XML validators or editors, together with persistent XmlOcaf documents; + +* **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 +Release Notes +@endhtmlonly (PDF) + + +@section OCCT_OVW_SECTION_7 Getting Started + + +@subsection OCCT_OVW_SECTION_7_1 Draw Test Harness + +Draw is a command interpreter based on TCL and a graphical system used for testing and demonstrating OCCT modeling libraries. + +Draw can be used interactively to create, display and modify objects such as curves, surfaces and topological shapes. + +![](/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. + +Draw contains: + + * A command interpreter based on TCL command language. + * A 2D an 3D graphic viewer with support of operations such as zoom, pan, rotation and full-screen views. + * An optional set of geometric commands to create and modify curves and surfaces and to use OCCT geometry algorithms. + * A set of topological commands to create and modify BRep shapes and to use OCCT topology algorithms. + * A set of graphic commands for view and display operations including Mesh Visualization Service. + * A set of Application framework commands for handling of files and attributes. + * A set of Data Exchange commands for translation of files from various formats (IGES,STEP) into OCCT shapes. + * A set of Shape Healing commands: check of overlapping edges, approximation of a shape to BSpline, etc. + +You can add new custom test harness commands to Draw in order to test +or demonstrate a new functionality, which you are developing. + +Currently DRAW Test Harness is a single executable called DRAWEXE. + +Commands grouped in toolkits can be loaded at run-time thereby implementing dynamically loaded plug-ins. +Thus you can work only with the commands that suit your needs adding +the commands dynamically without leaving the Test Harness session. + +Declaration of available plug-ins is done through special resource file(s). +The pload command loads the plug-in in accordance with +the specified resource file and activates the commands implemented in the plug-in. + +The whole process of using the plug-in mechanism as well as the instructions for extending Test Harness is described in the +@htmlonly +User's Guide/ +@endhtmlonly + +Draw Test Harness provides an environment for OCCT automated testing system. Please, consult its +@htmlonly +User's Guide / +@endhtmlonly +for details. + +Remarks: + +* The DRAWEXE executable is delivered with the installation procedure on Windows platform only. +* To start it, launch DRAWEXE executable from Open CASCADE Technology//Draw Test Harness item of the Start\\Programs menu. + +@subsection OCCT_OVW_SECTION_7_2 Experimenting with Draw Test Harness + + Running Draw +------------ + +**On Linux:** + +1. If OCCT was built by Code::Blocks * use $CASROOT/draw_cbp.sh file to launch DRAWEXE executable; +2. If OCCT was built by Automake * use $CASROOT/draw_amk.sh file to launch DRAWEXE executable; + +Draw[1]> prompt appears in the command window + +Type pload ALL + +**On Windows:** + +Launch Draw executable from Open CASCADE Technology\\Test Harness\\Draw Test Harness +item of the Start\\Programs menu or Use $CASROOT\\draw.bat file to launch DRAWEXE executable. + +Draw[1]> prompt appears in the command window + +Type pload ALL + +**Creating your first geometric objects** + +1. In the command window, type axo to create an axonometric view +2. Type box b -10 -10 -10 20 20 20 to create a cube b of size 20, + parallel to the X Y Z axis and centered on the origin. + The cube will be displayed in the axonometric view in wireframe mode +3. Type fit to fill the viewer with the cube +4. Type pcylinder c 2 30 to create a cylinder c of radius 2 and height 30. + The cylinder will be displayed in addition to the cube + +**Manipulating the view** + +1. Type clear to erase the view +2. Type donly c to display the cylinder only +3. Type donly b to display the cube only +4. Type hlr hlr b to display the cube in the hidden line removal mode + +**Running demonstration files** + +1. Type cd ..//.. to return to the root directory +2. Type cd src//DrawResources to reach the DrawResources directory +3. Type source "Available Demo File" to run the demonstration provided with Open CASCADE +4. The following demonstration files are available: + * DataExchangeDemo.tcl + * ModelingDemo.tcl + * OCAFDemo.tcl + * VisualizationDemo.tcl + +**Getting Help** + +1. Type help to see all available commands +2. Type help command-name to find out the arguments for a given command + +@subsection OCCT_OVW_SECTION_7_3 Programming Samples + +@subsubsection OCCT_OVW_SECTION_7_3_1 MFC + +Visual C++ programming samples containing 10 Visual C++ projects +illustrating how to use a particular module or functionality. + +The list of MFC samples: + + * Geometry + * Modeling + * Viewer2d + * Viewer3d + * ImportExport + * Ocaf + * Triangulation + * HLR + * Animation + * Convert + +![](/overview/images/overview_mvc.png "") + +**Remarks:** + + * MFC samples are available only on Windows platform; + * To start a sample use Open CASCADE Technology\\Samples\\Mfc\\ item of the Start\\Programs menu; + * Read carefully readme.txt to learn about launching and compilation options. + +@subsubsection OCCT_OVW_SECTION_7_3_2 Qt + +OCCT contains three samples based on Qt application framework + + Import Export +------------- + + Import Export programming sample contains 3D Viewer and Import // Export functionality. + +![](/overview/images/overview_qt.png "") + + Tutorial +--------- + +The Qt programming tutorial teaches how to use Open CASCADE Technology services to model a 3D object. +The purpose of the tutorial is not to explain all OCCT classes but +to help start thinking in terms of the Open CASCADE Technology. + +This tutorial assumes that the user has experience in using and setting up C++. +From the viewpoint of programming, Open CASCADE Technology is designed +to enhance user's C++ tools with high performance modeling classes, methods and functions. +The combination of these resources allows creating substantial applications. + +**See also:** @subpage overview__tutorial "3D Object Tutorial" + + Voxel +------ + +This is a demonstration application showing OCCT voxel models. +It also includes a set of non-regression tests and other commands +for testing this functionality (accessible only through TEST pre-processor definition). + +**See also:** + @htmlonly +Voxels User's guide (PDF) +@endhtmlonly + +**Remarks:** + + * Qt samples are available on all supported platforms; + * To start a sample on Windows use Open CASCADE Technology\\Samples\\Qt\\ item of the Start\\Programs menu. + +@subsubsection OCCT_OVW_SECTION_7_3_3 C# + +C# sample containing 3D Viewer and Import // Export functionality. + +![](/overview/images/overview_c__ie.png "") + +Import: + + * BRep + * Iges + * Step + +Export: + + * Brep + * Iges + * Step + * Stl + * Vrml + +**Remarks:** + + * C# sample is available only on Windows platform; + * It is delivered in source code only and must be built with Microsoft Visual C++ 2005. diff --git a/dox/dev_guides/building/automake.md b/dox/dev_guides/building/automake.md new file mode 100644 index 0000000000..e03ceb7fe1 --- /dev/null +++ b/dox/dev_guides/building/automake.md @@ -0,0 +1,69 @@ +Building with Automake {#dev_guides__building__automake} +====================== + +This file describes steps to build OCCT libraries from complete source +archive on Linux with GNU build system (Autotools). + +If you are building OCCT from bare sources (as in Git repository), or do some +changes affecting CDL files, you need to use WOK to re-generate header files +and build scripts / projects. See file \ref wok "WOK" for instructions. + +Before building OCCT, you need to install required third-party libraries; see +OCCT_Build3rdParty_Linux.pdf for instructions. + +Note that during compilation by makefiles on some Linux OS on a station with +NVIDIA video card you may experience problems because the installation +procedure of NVIDIA video driver removes library libGL.so included in package +libMesaGL from directory /usr/X11R6/lib and places this library libGL.so in +directory /usr/lib. However, libtool expects to find the library in directory +/usr/X11R6/lib, which causes compilation crash (See /usr/X11R6/lib/libGLU.la). + +To prevent this, suggest making links: + + ln -s /usr/lib/libGL.so /usr/X11R6/lib/libGL.so + ln -s /usr/lib/libGL.la /usr/X11R6/lib/libGL.la + + 1.In OCCT root folder, launch build_configure script + + This will generate files configure and Makefile.in for your system. + + 2.Go to the directory where OCCT will be built, and run configure to generate + makefiles. + + $CASROOT/configure \ + + Where \ is a set of options. + The following flags are mandatory: + + * --with-tcl= defines location of tclConfig.sh + * --with-tk= defines location of tkConfig.sh + * --with-freetype= defines location of installed FreeType product + * --prefix= defines location for the installation of OCCT binaries + + Additional flags: + + * --with-gl2ps= defines location of installed gl2ps product + * --with-freeimage= defines location of installed FreeImage product + * --with-tbb-include= defines location of tbb.h + * --with-tbb-library= defines location of libtbb.so + * --enable-debug= yes: includes debug information, no: does not include debug information + * --enable-production= yes: switches code optimization, no: switches off code optimization + * --disable-draw - allows OCCT building without Draw. + + If location of FreeImage, TBB, and Gl2Ps is not specified, OCCT will be + built without these optional libraries. + + + Attention: 64-bit platforms are detected automatically. + + Example: + + > ./configure -prefix=/PRODUCTS/occt-6.5.5 --with-tcl=/PRODUCTS/tcltk-8.5.8/lib --with-tk=/PRODUCTS/tcltk-8.5.8/lib --with-freetype=/PRODUCTS/freetype-2.4.10 --with-gl2ps=/PRODUCTS/gl2ps-1.3.5 --with-freeimage=/PRODUCTS/freeimage-3.14.1 --with-tbb-include=/PRODUCTS/tbb30_018oss/include --with-tbb-library=/PRODUCTS/tbb30_018oss/lib/ia32/cc4.1.0_libc2.4_kernel2.6.16.21 + + 3.If configure exits successfully, you can build OCCT with make command. + + > make -j8 install + +To start DRAW, launch + + > draw.sh diff --git a/dox/dev_guides/building/cmake.md b/dox/dev_guides/building/cmake.md new file mode 100644 index 0000000000..4f648e6b6e --- /dev/null +++ b/dox/dev_guides/building/cmake.md @@ -0,0 +1,77 @@ +Building with CMake {#dev_guides__building__cmake} +=================== + +This file describes steps to build OCCT libraries from complete source package +with CMake. CMake is free software that can create GNU Makefiles, KDevelop, +XCode, and Visual Studio project files. Version 2.6 or above of CMake is +required. + +If you are building OCCT from bare sources (as in Git repository), or do some +changes affecting CDL files, you need to use WOK to re-generate header files +and build scripts / projects. See file \ref wok "WOK" for instructions. + +Before building OCCT, you need to install required third-party libraries; see +instructions for your platform on Resources page at http://dev.opencascade.org + +1. Decide on location of build and install directories. + + The build directory is the one where intermediate files will be created + (projects / makefiles, objects, binaries). + The install directory is the one where binaries will be installed after + build, along with header files and resources required for OCCT use in + applications. + + OCCT CMake scripts assume use of separate build and one install directories + for each configuration (Debug or Release). + + It is recommended to separate build and install directories from OCCT + source directory, for example: + + /user/home/occt/ros - sources + /user/home/tmp/occt-build-release - intermediate files (release) + /user/home/occt-install-release - installed binaries (release) + +2. Run CMake indicating path to OCCT sources (ros subdirectory) and selected build directory. + It is recommended to use GUI tools provided by CMake: cmake-gui on Windows + and Mac, ccmake on Linux. + + Example: + + Linux> cd /user/home/occt-install-release + Linux> ccmake /user/home/occt/ros + +3. Run Configure + + You will likely get CMake errors due to missing paths to 3rd-party + libraries. This is normal; proceed with configuration as follows. + +4. Check parameters shown by CMake, set them in accordance with your + environment, and repeat Configure until it runs without error: + + - 3RDPARTY_DIR: path to directory whethe 3rd-party libraries are installed + (for the cases when they are not in default locations, or on Windows) + - 3RDPARTY_USE_\: select to use optional libraries + - Other options in 3RDPARTY group can be used to fine-tune paths to + 3rd-party libraries + + - BUILD_TYPE: configuration to build (Debug or Release) + - BUILD_BITNESS: bitness (32 or 64) + - BUILD_TOOLKITS: optional string containing list of toolkits to be built + in addition to those included in completely built modueles + - BUILD_\: select to build corresponding OCCT module + + - INSTALL_DIR: directory to install OCCT + - INSTALL_\: select to copy corresponding 3rd-party library to OCCT + install dir + +5. Run Generate + + This will create makefiles or project files for your build system. + +6. Build OCCT: + + - on Windows with MSVC: open solution OCCT.sln and build it, when build project INSTALL_ALL explicitly to have binaries and headers installed + - on Linux with make files: run 'make install' + + + \ No newline at end of file diff --git a/dox/dev_guides/building/code_blocks.md b/dox/dev_guides/building/code_blocks.md new file mode 100644 index 0000000000..919edc222a --- /dev/null +++ b/dox/dev_guides/building/code_blocks.md @@ -0,0 +1,64 @@ +Building with Code::Blocks on Mac OS X {#dev_guides__building__code_blocks} +====================================== + +This file describes steps to build OCCT libraries from complete source package +on Mac OS X with Code::Blocks. + +If you are building OCCT from bare sources (as in Git repository), or do some +changes affecting CDL files, you need to use WOK to re-generate header files +and build scripts / projects. See file \ref wok "WOK" for instructions. + +Before building OCCT, you need to install required third-party libraries; see +OCCT_Build3rdParty_OSX.pdf for details. + +1. Add paths to the mandatory 3rd-party products (Tcl/Tk and FreeType) in file + custom.sh located in \. For this: + + 1.1. Add paths to the includes in variable "CSF_OPT_INC"; + + 1.2. Add paths to the binary libraries in variable "CSF_OPT_LIB64"; + + All paths should be separated by ":" symbol. + +2. Add paths to the optional 3rd-party libraries (TBB, gl2ps and FreeImage) + in the aforementioned environment variables "CSF_OPT_INC" and + "CSF_OPT_LIB64" from file custom.sh. + + If you want to build OCCT without the optional libraries perform the + following steps: + + 2.1 Disable unnecessary library in custom.sh by setting the corresponding + variable HAVE_\ to "false". + + export HAVE_GL2PS=false + + 2.2 Remove this library from Linker settings in Code::Blocks for each project + that uses it: right click on the required project, choose "Build options", + go to "Linker settings" tab in the opened window , select unnecessary + libraries and click "Delete" button. + +3. Open Terminal application + +4. Enter \: + + cd \ + +5. To start Code::Blocks, run the command /codeblocks.sh + +6. To build all toolkits, click "Build->Build workspace" in the menu bar. + + +To start DRAWEXE, which has been built with Code::Blocks on Mac OS X, perform +the following steps: + +1. Open Terminal application + +2. Enter \: + + cd \ + +3. Run script + + ./draw_cbp.sh cbp [d] + + Option "d" is used if OCCT has been built in Debug mode. diff --git a/dox/dev_guides/building/msvc.md b/dox/dev_guides/building/msvc.md new file mode 100644 index 0000000000..3a84422ae0 --- /dev/null +++ b/dox/dev_guides/building/msvc.md @@ -0,0 +1,31 @@ +Building with MS Visual C++ {#dev_guides__building__msvc} +=========================== + +This file describes steps to build OCCT libraries from complete source +archive on Windows with MS Visual C++. + +If you are building OCCT from bare sources (as in Git repository), or do some +changes affecting CDL files, you need to use WOK to re-generate header files +and build scripts / projects. See file \ref wok "WOK" for instructions. + +Before building OCCT, you need to install required third-party libraries; see +OCCT_Build3rdParty_Windows.pdf for instructions. + +1. Edit file custom.bat to define environment: + + - VCVER - version of Visual Studio (vc8, vc9, vc10 or vc11), + and relevant VCVARS path + - ARCH - architecture (32 or 64), affects only PATH variable for execution + - HAVE_* - flags to enable or disable use of optional third-party products + - CSF_OPT_* - paths to search for includes and binaries of all used + third-party products + +2. Launch msvc.bat to start Visual Studio with all necessary environment + variables defined. + + Note: the MSVC project files are located in folders adm\\msvc\\vc[9-11]. + Binaries are produced in win32 or win64 folders. + +3. Build with Visual Studio + +To start DRAW, launch draw.bat. diff --git a/dox/dev_guides/building/xcode.md b/dox/dev_guides/building/xcode.md new file mode 100644 index 0000000000..e1ba093f9a --- /dev/null +++ b/dox/dev_guides/building/xcode.md @@ -0,0 +1,71 @@ +Building with Xcode {#dev_guides__building__xcode} +=================== + +This file describes steps to build OCCT libraries from complete source package +on Mac OS X with Xcode. + +If you are building OCCT from bare sources (as in Git repository), or do some +changes affecting CDL files, you need to use WOK to re-generate header files +and build scripts / projects. See file \ref wok "WOK" for instructions. + +Before building OCCT, you need to install required third-party libraries; see +OCCT_Build3rdParty_OSX.pdf for details. + +1. Add paths to the mandatory 3rd-party products (Tcl/Tk and FreeType) + in file custom.sh located in \. For this: + + 1.1. Add paths to the includes in variable "CSF_OPT_INC"; + + 1.2. Add paths to the binary libraries in variable "CSF_OPT_LIB64"; + + All paths should be separated by ":" symbol. + +2. Add paths to the optional 3rd-party libraries (TBB, gl2ps and FreeImage) + in the aforementioned environment variables "CSF_OPT_INC" and + "CSF_OPT_LIB64" from file custom.sh. + + If you want to build OCCT without the optional libraries perform the + following steps: + + 2.1 Disable unnecessary library in custom.sh by setting the corresponding + variable HAVE_ to "false". + + export HAVE_GL2PS=false + + 2.2 Remove this library from Project navigator in Xcode for each project that + uses it: choose the required project, right click on the unnecessary + library and select "Delete" button. + +3. Open Terminal application. + +4. Enter \: + + cd \ + +5. To start Xcode, run the command /xcode.sh + +6. To build a certain toolkit, select it in "Scheme" drop-down list in Xcode + toolbar, press "Product" in the menu and click "Build" button. + + To build the entire OCCT, create a new empty project (select "File -> + New -> Project -> "Empty project" in the menu. Input the project name, + e.g. "OCCT", click "Next" and "Create" buttons). Drag and drop the "OCCT" + folder in the created "OCCT" project in the Project navigator. Select + "File -> New -> Target -> Aggregate" in the menu. Enter the project name + (e.g. "OCCT") and click "Finish". The "Build Phases" tab will open. + Click "+" button to add the necessary toolkits to the target project. + It is possible to select all toolkits by pressing "Command+A" combination. + +To start DRAWEXE, which has been built with Xcode on Mac OS X, perform the following steps: + +1. Open Terminal application + +2. Enter \: + + cd \ + +3. Run script + + ./draw_cbp.sh xcd [d] + + Option "d" is used if OCCT has been built in Debug mode. diff --git a/dox/dev_guides/cdl/cdl.md b/dox/dev_guides/cdl/cdl.md new file mode 100644 index 0000000000..bde49759c6 --- /dev/null +++ b/dox/dev_guides/cdl/cdl.md @@ -0,0 +1,1876 @@ + Component Definition Language (CDL) {#dev_guides__cdl} +============================== + +@section occt_1819379591_354121062 CDL and Application Architecture + +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. These and other components, which you can define using CDL include the following: + + * Class (including enumeration, exception) + * Package + * Schema + * Executable + * Client. +A** class** is the fundamental software component in object-oriented development. Because of a very large number of resources used in large-scale applications, the **class **itself is too small to be used as a basic management unit. + +So, while the class is the basic data component defined in CDL, this language also provides a way to group classes, **enumerations**, and **exceptions **together – the **package**. 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. In practice, a class name is prefixed with the name of its package e.g. Geom_Circle. + +Using the services described in the **packages**, you can construct an **executable**. You can also group together services provided by **packages**. + +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. + + + + + + + + + +
+ +
+ + + ![](/devs_guide/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 can use CDL to **define data **in the Open CASCADE Technology environment. CDL allows you to define various kinds of data types supporting the application architecture and development methodology, which you envision. CDL is neither an analysis formalism (e.g. Booch methodology) nor a data manipulation language (e.g. C++). + +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. + + + + + + + + + +
+ +
+ + + ![](/devs_guide/cdl/images/cdl_image004.jpg) +
+ +Figure 2. The Development Process + +From a structural point of view, CDL is an object-oriented language. It is centered on the notion of the **class **- a data type, which represents an elementary concept. CDL offers various means of organizing classes, mostly under the fundamental form of **packages**. A package contains a set of classes, which share some semantic relationship. This greatly simplifies your task of managing individual classes when confronted with a very large number of them. + +Once you have defined the classes and packages using CDL, you can implement their **methods **- i.e., their functionality - in one of the data manipulation languages supported by the OCCT environment (currently C++). + +Even though you can describe classes directly in C++ and save them as header files (.hxx), to do so would forfeit all the advantages of using CDL. These are: + + * Precise, complete, and easy-to-read description of the software components. + * Creation of a link with the database; object persistence forms part of the predefined environment of the language. + * Multi-language access to the services of an application engine – a specific architectural form created using the CDL tools, which serves as the motor of an application. +@subsection occt_1819379591_98643723722 Overview of CDL + +CDL is an object-oriented language. In other words, it structures a system around data types rather than around the actions carried out on them. In this context, an **object **is an **instance **of a data type, and its definition determines how you can use it. Each data type is implemented by one or more classes, which make up the basic elements of the system. +@subsubsection occt_1819379591_986437237221 Classes + +A class is an implementation of a **data type**. It defines its **behavior **and its **representation**. + +The behavior of a class is its programming interface - the services offered by its **methods**. The representation of a class is its data structure - the **fields**,** **which store its data. + +Every object is an **instance **of its class. For example, the object *p *of the data type *Point *is an instance of the class Point. + +The class Point could be defined as in the example below: + +@code +class Point from GeomPack +@endcode +@code + ---Purpose: represents a point in 3D space. +@endcode +@code + is +@endcode +@code + Create returns Point; +@endcode +@code +fields +@endcode +@code + x, y, z : Real; +@endcode +@code +end Point; +@endcode + +The definition of this class comprises two sections: + + * one starting with the keywords **is** + * one starting with the keyword **fields**. + +The first section contains a list of methods available to the clients of the class. The second section defines the way in which instances are represented. Once this class has been compiled you could **instantiate **its data type in a C++ test program as in the example below: + + + +@code +GeomPack_Point p; +@endcode +@subsubsection occt_1819379591_986437237222 Categories of Types + +You declare the variables of a **data manipulation language **as being of certain data types. These fall into two categories: + + * Data types manipulated by handle (or reference) + * Data types manipulated by value + + + + + + + + +
+ +
+ + + ![](/devs_guide/cdl/images/cdl_image005.jpg) +
+ +Figure 3. Manipulation of data types + + +As seen above, you implement data types using classes. However, classes not only define their data representation and methods available for their instances, but they also define how the instances will be manipulated: + * A data type manipulated by value contains the instance itself. + * A data type manipulated by handle contains a reference to the instance. + +The most obvious examples of data types manipulated by value are the predefined **primitive types**: Boolean, Character, Integer, Real ... + +A variable of a data type manipulated by handle, which is not attached to an object, is said to be **null**. To reference an object, you need to instantiate the class with one of its constructors. This is done in C++ as in the following syntax: + + + +@subsubsection occt_1819379591_986437237223 Persistence + +An object is called **persistent **if it can be permanently stored. In other words, you can use the object again at a later date, both in the application, which created it, and in another application. + +In order to make an object persistent, you need to declare it in CDL as inheriting from the **Persistent** class, or to have one of its parent classes inheriting from the **Persistent **class. + +Note that the classes inheriting from the Persistent class are handled by reference. + +**Example** + +In this example, building the application, you add the Watch class to the corresponding schema of data types. +If, running the application, you instantiate an object of the Watch class, you have the possibility of storing it in a file. +You cannot store objects instantiated from classes, which inherit from the **Storable** class. However, you can store them as fields of an object, which inherits from Persistent. + +Note that the objects inheriting from Storable are handled by value. +**Example** + +If +class WatchSpring inherits Storable +//then this could be stored as a field of a Watch +//object: +class Watch inherits Persistent +is...... +fields +name : ConstructorName; +powersource : WatchSpring; +end; + + +@subsubsection occt_1819379591_986437237224 Packages + +In large-scale long-term development the task of marshalling potentially thousands of classes is likely to quickly prove unmanageable. CDL introduces the notion of **package **of classes containing a set of classes, which have some semantic or syntactic relationship. For example, all classes representing a particular set of electronic components might make up a package called Diode. + +As the package name prefixes the class name when implementing such class (in C++ for example), classes belonging to different packages can have the same name. For example, two packages, one dealing with finance and the other dealing with aircraft maneuvers, might both contain a class called Bank, without any possibility of confusion. +**Example** + +Finance_Bank +Attitude_Bank + + + +@subsubsection occt_1819379591_986437237225 Inheritance + +The purpose of inheritance is to reduce development workload. The inheritance mechanisms allow you to declare a new class as already containing the characteristics of an existing class. This new class can then be rapidly specialized for a task at hand. This eliminates the necessity of developing each component “from scratch”. + +For example, having already developed a class BankAccount, you can quickly specialize new classes - SavingsAccount, LongTermDepositAccount, MoneyMarketAccount, RevolvingCreditAccount, etc.. + +As a consequence, when two or more classes inherit from a parent (or ancestor) class, all these classes surely inherit the behavior of their parent (or ancestor). For example, if the parent class BankAccount contains the method Print that tells it to print itself out, then all its descendent classes 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 inherited methods are not implemented. This forces you to create a new class used to redefine the methods. In this way, you guarantee a certain minimum common behavior among descendent classes. +**Example** + +deferred class BankAccount inherits Persistent +is +....... +fields +name : AccountHolderName; +balance : CreditBalance; +end; + + +@subsubsection occt_1819379591_986437237226 Genericity + +You will often wish to model a certain type of behavior as a class. For example, you will need a list modeled as a class. + +In order to be able to list different objects, the class **List **must be able to accept different data types as parameters. This is where genericity comes in: you first declare a list declared as the generic class **List**, willing to accept any data type (or only a particular set of acceptable data types). Then, when you want to make a list of a certain type of object, you instantiate the class **List **with the appropriate data type. +**Example** + +generic class NewList (Item) +inherits OldList +is +..... +end ; + +Items may be of any type, an Integer or a Real for example. + +When defining the package, add the following line: +**Example** + +class NewListOfInteger instantiates +NewList (Integer); + + +@subsubsection occt_1819379591_986437237227 Exceptions + +The behavior of any object is implemented by methods, which you define in its class declaration. The definition of these methods includes not only their signature (their programming interface) but also their domain of validity. + +In CDL, this domain is expressed by **exceptions**. Exceptions are raised under various error conditions. This mechanism is a safeguard of software quality. +@subsubsection occt_1819379591_986437237228 Completeness + +You use CDL to define data types. Such definitions are not considered complete unless they contain the required amount of structured commentary. + +The compiler does not enforce this required degree of completeness, so it is the responsibility of the developer to ensure that all CDL codes are properly annotated. + +Completeness is regarded as an essential component of long-term viability of a software component. + + +@subsection occt_1819379591_98643723723 Lexical Conventions +@subsubsection occt_1819379591_986437237231 Syntax notation + +In this manual, CDL declarations are described using a simple variant of the Backus-Naur formalism. Note the following: + + * Italicized words, which may also be hyphenated, denote syntactical categories, for example: + +*declaration-of-a-non-generic-class* + + * Keywords appear in bold type: + +**class** + + * Brackets enclose optional elements: + +identifier [**from **package-name] + + * Curly braces enclose repeated elements. The element may appear zero or many times: + +integer ::= digit{digit} + + * Vertical bars separate alternatives: + +passing-method ::= [**in**] | **out **| **in out** + + * Two apostrophes enclose a character or a string of characters, which must appear: + +exponent ::= ’E’[’+’]integer | ’E-’ integer + +NOTE +So as to introduce ideas progressively, the examples presented in this manual may be incomplete, and thus not compilable by the CDL compiler. + + +@subsubsection occt_1819379591_986437237232 Lexical elements + +A CDL source is composed of text from one or more compiled units. The text of each compiled unit is a string of separate lexical elements: **identifiers**, **keywords**, **constants**, and **separators**. The separators (blank spaces, end of line, format characters) are ignored by the CDL compiler, but these are often necessary for separating identifiers, keywords, and constants. + + +@subsubsection occt_1819379591_986437237233 Comments + +With CDL, you cannot use the expression of all useful information about a development unit. In particular, certain information is more easily expressed in natural language. You can add such information to the CDL description of a data type. + +Rubrics and free comments are to be differentiated: + +**Free comments **are preceded by the characters “--” (two hyphens), and they terminate at the end of the line in which they appear. +**Example** + +--This is a comment + +Unlike rubrics, free comments can appear before or after any lexical element. The first written character of the comment itself *must not *be a hyphen. If a hyphen is necessary make sure it is preceded by a blank. +**Example** + +-- -List item + +**Rubrics **are various types of comments attached to CDL components. A rubric is a comment made up of three hyphens, name of the rubric (without any intermediary space) and then a colon and a space. It is terminated by the beginning of the following rubric, or by the end of the commentary. +**Example** + +---Purpose:This is an example of a +--rubric composed of a +--comment which extends to +--four lines. + +The different categories of rubrics and the form of their content do not depend on the Component Description Language, but on the tool for which it is intended. + +The use of commentary is generally governed by the internal programming standards of an enterprise. You are encouraged to use various well-defined rubrics, such as Purpose, Warning, Example, References, Keywords, etc. + +These rubrics can be attached to: + + * Packages + * Classes + * Methods + * Schemas + * Executables + * Clients + +@subsubsection occt_1819379591_986437237234 Identifiers + +An identifier is an arbitrary chain of characters, either letters or digits, but it must begin with a letter. + +The underscore “_” is considered to be a letter as long as it doesn’t appear at the beginning or the end of an identifier. +Capital and small letters are not equivalent (i.e. AB, Ab, aB, ab are four different identifiers). + + +@subsubsection occt_1819379591_986437237235 Keywords + +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 + +In a CDL file, the following characters are used as punctuation: +; : , = ( ) [ ] ‘ “ + +@subsubsection occt_1819379591_986437237236 Constants + +There are three categories of constants: + + * Numeric + * Literal + * Named + +***Numeric Constants*** + +There are two types of numeric constants: integer and real. +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 + +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 + +***Literal Constants*** + +Literal constants include individual characters and strings of characters. + +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’      ‘&’      ‘*’      ‘’’ ‘‘ + +A **string **constant is composed of printable characters enclosed by quotation marks. +**Examples** + +’’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** + +’’This film was originally called \’’Gone with the Tide\’’.’’ + +***Named Constants*** + +Named constants are sub-divided into two categories: Booleans and enumerations. + +**Booleans **can be of two types: True or False. + +An **enumeration **constant is an identifier, which appears in the description of an enumeration. + +@section occt_1819379591_1718435309 3. Software Components + + + +@subsection occt_1819379591_171843530931 Predefined Resources +@subsubsection occt_1819379591_1718435309311 Primitive types + +Primitive types are predefined in the language and they are **manipulated by value**. + +Four of these primitives are known to the schema of the database because they inherit from the class **Storable**. In other words, they can be used in the implementation of persistent objects, either when contained in entities declared within the methods of the object, or when they form part of the internal representation of the object. + +The primitives inheriting from Storable are the following: + +**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. + +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. + +The services offered by each of these types are described in the Standard Package. + + +@subsubsection occt_1819379591_1718435309312 Manipulating types by reference (by handle) + +Two types are manipulated by handle: + + * Types defined using classes inheriting from the **Persistent **class are storable in a file. + + * Types defined using classes inheriting from the **Transient **class. +These types are not storable as such in a file. + +![](/devs_guide/cdl/images/cdl_image006.jpg) + +Figure 4. Manipulation of a data type by reference + + +@subsubsection occt_1819379591_1718435309313 Manipulating types by value + +Types, which are manipulated by value, behave in a more direct fashion than those manipulated by handle. As a consequence, they can be expected to perform operations faster, but they cannot be stored independently in a file. + +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. + + + + + + + + + + +
+ +
+ + + ![](/devs_guide/cdl/images/cdl_image007.jpg) +
+Figure 5. Manipulation of a data type by value +Three types are manipulated by value: + + * Primitive types + * Enumerated types + * Types defined by classes not inheriting from Persistent or Transient, whether directly or not + +@subsubsection occt_1819379591_1718435309314 Summary of properties + +**Figure 6. Summary of the relationship for the various data** +**types between how they are handled and their storability.** + + +@subsection occt_1819379591_171843530932 Classes + +@subsubsection occt_1819379591_1718435309321 Class declaration + +The class is the main system for creating data types under CDL. By analyzing any CDL-based software, you find that classes are the modular units that make up packages. When you describe a new class, you introduce a new data type. + +Whatever the category of the described type (manipulated by value, Storable or not, manipulated by handle, Persistent or not) the structure of the class definition remains the same. The syntax below illustrates it: +**Example** + +-- declaration-of-a-simple-class ::= +class class-name from package-name +[uses data-type { ’,’ data-type } ] +[raises exception-name { ’,’ exception-name} ] +is class-definition +end [ class-name ] ’;’ +data-type ::= enumeration-name | class-name | +exception-name | primitive-type +package-name ::= identifier +class-name ::= identifier +class-definition ::= +[{member-method}] +[declaration-of-fields] +[declaration-of-friends] + +Class name becomes a new data type, which you can use inside its own definition. Other types appearing in the definition must either be primitive types, previously declared classes, exceptions, or enumerations. + +Apart from the types defined in the Standard Package, which are **implicitly visible **everywhere, you need to declare the data types after the keyword **uses**. This concerns both the class behavior and its internal representation. + +**Exceptions **are declared after the word **raises**. +**Example** + +class Line from GeomPack +usesPoint, Direction, Transformation +raisesNullDirection, IdenticalPoints +is-- class definition follows here +-- using Point, Direction and +-- Transformation objects,and the +-- NullDirection and Identical- +-- -Points exceptions. +end Line; + +The elements, which make up the definition of a class, are divided into four parts: + + * the behavior + * the invariants + * the internal representation + * the friend methods and friend classes. + + + + + + + + +
+ +
+ + + ![](/devs_guide/cdl/images/cdl_image009.jpg) +
+**Figure 7. Contents of a class** +*** a deferred class does not have to contain a constructor** + + +@subsubsection occt_1819379591_1718435309322 Categories of classes + +Classes fall into three categories: + + * Ordinary classes + * Deferred classes + * Generic classes + +

Deferred classes

+ +The principal characteristic of a **deferred class **is that you cannot instantiate it. Its purpose is to provide you with a given behavior shared by a hierarchy of classes and dependent on the implementation of the descendents. This allows you to guarantee a certain base of inherited behavior common to all classes based on a particular deferred class. Deferred classes are declared as in the following syntax: +**Example** + +-- declaration-of-a-deferred-class ::= +deferred class class-name +[inherits class-name {’,’ class-name}] +[uses data-type {’,’ data-type}] +[raises exception-name {’,’ exception-name}] +is class-definition +end [class-name]’;’ + + +

Generic classes

+ +The principal characteristic of a **generic class **is that it offers you a set of functional behavior allowing you to manipulate other data types. To instantiate a generic class you need to pass a data type in argument. Generic classes are declared as in the following syntax: +**Example** + +-- declaration-of-a-generic-class ::= +[deferred] generic class class-name ’(’generic-type +{’,’ generic-type}’)’ +[inheritsclass-name {’,’ class-name}] +[usesdata-type {’,’ data-type}] +[raisesexception-name {’,’ exception-name}] +[{[visibility] declaration-of-a-class}] +is class-definition +end [class-name]’;’ +generic-type ::= identifier as type-constraint +identifier ::= letter{[underscore]alphanumeric} +type-constraint ::= any | class-name [’(’data-type {’,’ +data-type}’)’] + + + +@subsection occt_1819379591_171843530933 Packages + +@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. +** ** +**Example** + +-- package-declaration ::= +**package **package-name +[**uses **package-name {’,’ package-name}] +**is **package-definition +**end **[package-name]’;’ +-- package-name ::= +identifier +-- package-definition ::= +[{type-declaration}] +[{package-method}] +-- type-declaration ::= +[**private**] declaration-of-an-enumeration | +[**private**] declaration-of-a-class | +declaration-of-an-exception +-- package-method ::= +identifier [simple-formal-part][returned-type +-declaration] +[error-declaration] +[***is private***]’;’ + +The 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 *have the same name. + +You declare data types before using them in the definition of other data types. + +When two classes are **mutually recursive**, one of the two *must *be first declared in an incomplete fashion. + +Grouped behind the keyword **uses **are the names of all the packages containing definitions of classes of which the newly introduced data types are clients. + +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**. + +![](/devs_guide/cdl/images/cdl_image010.jpg) +Figure 8. Contents of a package + +The example of the package below includes some of the basic data structures: +**Example** + +package Collection +uses +Standard +is +exception NoSuchObject inherits Failure; +exception NoMoreObject inherits Failure; +generic class SingleList; +generic class Set; +end Collection; + +Note that the class Set is declared after the declarations of the NoSuchObject and NoMoreObject exceptions and the SingleList class of which Set is a client. In the same way, the classes Failure, Persistent, and the exception NoSuchObject are defined before they are used. They are defined in the Standard package, which appears after the keyword **uses**. + +@subsubsection occt_1819379591_1718435309332 Name space + +The **name space **or **scope **of a class extends from the beginning of its declaration up to the end of the package in which it appears. + +Sometimes, two classes, which come from separate packages, are both visible to a third package and carry the same name. For example, there might be two different classes both called “Window” in a screen generator package and in an architectural package. As a client of a data type, you can find yourself in the position of having to remove the ambiguity over the origin of this type; you do this by means of the keyword **from**. +**Example** + +-- class-name ::= +identifier [**from **package-name] +-- exception-name ::= +identifier [**from **package-name] +-- enumeration-name ::= +identifier [**from **package-name] + +You can use the keyword **from **everywhere the name of a class, exception, or enumeration appears. As a consequence, as a client of the class “Window” you could write wherever necessary: +**Example** + +Window from ScreenGenerator +-- or +Window from ArchitecturalFeatures + +NOTES +***Within the description of a package the keyword *****from**** *must be used when referencing any data type that is not defined in this package.*** + +Here is a further example: +**Example** + +class Line from Geom +uses +Point from Geom2d, +Point from Geom3d +is +-- class definition using +-- Point from AppropriatePackage +-- wherever Point appears +end; + + +@subsubsection occt_1819379591_1718435309333 Declaration of classes + +You cannot describe a package in one single file. You need to describe it in different units and send them separately to the CDL compiler. Each compilation unit can contain the declaration of a class or of a package. When you describe a class in a unit different than that, which describes its package, you need to specify which package the class belongs to. You do this using the keyword **from**. + +If the **from **clause appears in the **uses **clause of the package, it does not need to be repeated elsewhere. + +The following example takes the package “Collection” which was presented above, but this time it is divided into three compilation units. +**Example** + +-- First compilation unit, the package “Collection” : +package Collection +uses +Standard +is +exception NoMoreObject inherits Failure from Standard; +exception NoSuchObject inherits Failure from Standard; +generic class SingleList; +generic class Set, Node, Iterator; +end Collection; +-- Second compilation unit, the class “SingleList” : +generic class SingleList from Collection (Item as +Storable) +inherits +Persistent from Standard +raises +NoSuchObject from Collection +is +-- definition of the SingleList class +end SingleList; +-- Third compilation unit, the class “Set” : +generic class Set from Collection (Item as Storable) +  inherits +Persistent from Standard; +raises +NoSuchObject from Collection, +NoMoreObject from Collection +private class Node instantiates SingleList +from Collection (Item); +-- etc.... + end Set; + + +NOTE +It is not explicitly stated that the “Node” class belongs to the “Collection” package. In fact any nested class necessarily belongs to the package of the class, which encompasses it. + +Note that a package can hide certain classes (just as it can hide methods) by declaring them **private**. To make a class private, you prefix its description with the keyword **private**. In the example of the “Collection” package, the “SingleList” class serves only to implement the “Set” class. It is recommended to make it private. You write this as in the following syntax: +**Example** + +package Collection +uses +Standard +is +generic class Set, Node, Iterator; +private generic class SingleList; +exception NoMoreObject inherits Failure from Standard; +end Collection; + + + + +@subsection occt_1819379591_171843530934 Other Data Types + +These are: + + * Enumerations + * Imports + * Aliases + * Exceptions + * Pointers + +@subsubsection occt_1819379591_1718435309341 Enumerations + +The **enumerated types **are the second type, which is manipulated by value. Unlike the primitive types they are extensible because they are defined by the user under the form of enumerations. An enumeration is an ordered sequence of named whole constant values called enumeration constants. +**Example** + +declaration-of-an-enumeration ::= +**numeration **enumeration-name +**is **identifier {’,’ identifier} +[**end **[enumeration-name]]’;’ +enumeration-name ::= identifier + +The declaration of an enumeration creates an enumerated type. An object of this type can successively take the value of any one of the constants cited in the list. +**Example** + +enumeration MagnitudeSign is Negative, Null, Positive; + + +Inside a package, two enumeration constants cannot have the same name, even if they belong to different enumerated types. +**Example** + +enumeration Cars is +Honda, +Ford, +Volkswagen, +Renault +end; +enumeration AmericanPresidents is +Nixon, +Reagan, +Ford, -- Error: ‘Ford’ already defined +Carter +end; + + +@subsubsection occt_1819379591_1718435309342 Imports + +An **imported type **is one of which which has not been defined in CDL. It is up to the supplier of this data type to ensure compatibility with the CDL language by providing services which allow CDL to recognize the imported data type. + +The CDL syntax for declaring an imported type is: + +declaration-of-an-imported-type::= +[**private**] **imported **typename ; +**Example** + +-- You can define an imported type as follows: +-- In the MyPack.cdl file, you declare the imported +type: +-- package MyPack +.... +imported MyImport; +.... +end Mypack; +-- In the MyPack_MyImport.hxx file, you write the +following +-- C++ code: +#ifndef _MyPack_MyImport_HeaderFile +#define _MyPack_MyImport_HeaderFile +#include Standard_Type.hxx +typedef unsigned long MyPack_MyImport; +extern const Handle(Standard_Type)& TYPE +(MyPack_MyImport); +-- In the MyPack_MyImport.cxx file, you write the +following +-- C++ code: +#ifndef _MyPack_MyImport_HeaderFile +#include MyPack_MyImport.hxx +#endif +const Handle(Standard_Type)& TYPE (MyPack_MyImport) + +{ +static Handle(Standard_Type) _aType = +new Standard_Type (“MyPack_MyImport”,sizeof +(MyPack_MyImport)) + 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. + + +@subsubsection occt_1819379591_1718435309343 Aliases + +An **alias **is an extra name for a type, which is already known. It is declared as in the following syntax: + +declaration-of-an-alias::= +[**private**] **alias **type1 **is **type2 [**from **apackage] ; +**Example** + +alias Mass is Real; +---Purpose: +-- Defined as a quantity of matter. +-- Gives rise to the inertial and +-- gravitational properties of a body. +-- It is measured in kilograms. + +Having defined *Mass *as a type of *Real*, you can use either *Mass *or *Real *to type an argument when defining a method. + + +@subsubsection occt_1819379591_1718435309344 Exceptions + +In the model recommended by CDL, the principal characteristic of errors is that they are treated in a different place from the place where they appear. In other words, the methods recovering and those raising a given exception are written independently from each other. + +Subsequently this poses the problem of communication between the two programs. The principle adopted consists in viewing the exception as both a class and an object. The exception class (by means of one of its instances) is used to take control of an exception, which has been raised. + +Consequently, error conditions are defined by means of **classes of exceptions**. Exception classes are arranged hierarchically so as to be able to recover them in groups. They are all descendents of a single root class called “Failure”, and it is at the level of this class that the behavior linked to the raising of exceptions is implemented. + +declaration-of-an-exception ::= +**exception **exception-name **inherits **exception-name + +All exceptions share identical behavior, that of the class “Failure”. Here are some examples of exception classes: +exception NumericError inherits Failure; +exception Overflow inherits NumericError; +exception Underflow inherits NumericError; + +The use of exceptions as a means to interrupt the normal execution of one program and then take control of another one depends on the programming language used to implement the methods. See the following chapter “Defining the Software Components” on page 32. + + +@subsection occt_1819379591_171843530935 Schemas + +The purpose of a **schema **is to list persistent data types, which will be stored in files by the application. A schema groups together persistent packages. A persistent package is one, which contains at least one persistent class. + +declaration-of-a-schema ::= +**schema **SchemaName +is +{**package **PackageName;} +{**class **ClassName;} +**end**; +**Example** + +schema Bicycle +---Purpose: Defines the Bicycle schema. +is +package FrameComponents; +package WheelComponents; +end; + +***NOTE*** +Note that it is unnecessary to specify all the dependencies of the packages. It is sufficient to specify the highest level ones. The others on which they depend are automatically supplied. +@subsection occt_1819379591_171843530936 Executables + +The purpose of an **executable **is to make an executable program without a front-end. It can be used to test more than one package at a time. An executable is written in a .cdl file as a set of packages. +**Example** + +definition-of-an-executable ::= +executable ExecutableName +is +{ +executable ExecutablePart +[uses [Identifier as external] +[{’,’ Identifier as external}] +[UnitName as library] +[{’,’ UnitName as library}] +is +{FileName [as C++|c|fortran|object];} +end; +} +end; +**Example** + +executable MyExecUnit +---Purpose: +-- Describes the executable MyExecUnit +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; + +@section occt_1819379591_1972310108 4. Defining the Software Components + +@subsection occt_1819379591_197231010841 Behavior + +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. + +**Instance method               **Operates on the instance which owns it. + +**Class method                    **Does not work on individual instances, only on the class                                                     itself. + +@subsubsection occt_1819379591_1972310108411 Object Constructors + +A constructor is a function, which allows the **creation of instances **of the class it describes. +**Example** + +constructor-declaration ::= +Create [ simple-formal-part ] declaration-ofconstructed- +type +[ exception-declarations ] +simple-formal-part ::= +’(’ initialization-parameter {’;’ initialization parameter}’)’ +initialization-parameter ::= +identifier {’,’ identifier} ’:’ parameter-access datatype +[ ’=’ initial-value ] +parameter-access ::= +**mutable **| [ **immutable **] +initial_value ::= +numeric-constant | literal-constant | named-constant +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. + +For example, the constructor of the class “Point” +**Example** + +Create (X, Y, Z : Real) +returns mutable Point; + +With the exception of the types predefined by the language, all types of initialization parameters *must *appear in the **uses **clause of the class of which the constructor is a member. + +When an initialization parameter is of a type which is manipulated by a handle, an access right *must *be associated with it so as to express if the internal representation of the referenced object is modifiable (**mutable**) or not (**immutable**). The default option is **immutable**. For example, the constructor of the persistent class “Line”. +**Example** + +Create (P : mutable Point; D : mutable Direction) +returns mutable Line; + +In the above example “P” and “D” must be mutable because the constructor stores them in the internal representation of the created line, which is mutable itself. An alternative would be to accept immutable initialization parameters and then copy them into the constructor in a mutable form. + +The parameters of a native type can have a default value: this is expressed by assigning a constant of the same type to the parameter concerned. Parameters, which have a default value, may not be present when the call to the constructor is made, in which case they take the value specified in the declaration. For this reason, they must all be grouped at the end of the list. For example, the constructor of the persistent class “Vector”. +**Example** + +Create (D : mutable Direction; M : Real = 1.0) +returns mutable Vector; + +A class can have many constructors (in this case, you say they are **overloaded**) provided that they differ in their syntax and that the presence of parameters having default values does not create ambiguities. + +The restrictions on their use are expressed by a list of **exceptions **against which each constructor is protected. + +Each class must have at least one constructor to be able to create objects of its type. +@subsubsection occt_1819379591_1972310108412 Instance Methods + +An instance method is a function or procedure, which applies to any instance of the class, which describes it. +**Example** + +declaration-of-an-instance-method ::= +identifier formal-part-of-instance-method +[ declaration-of-returned-type ] +[ exception-declaration ] +formal-part-of-instance-method ::= + ’(’ me [’:’ passing-mode parameter-access ] {’;’ +parameter}’)’ +parameter ::= +identifier {’,’ identifier} ’:’ passing-mode +parameter-access +data-type [ ’=’ initial-value ] +passing-mode ::= +[ in ] | out | in out +parameter-access ::= +mutable | [immutable] +declaration-of-returned-type ::= +returns return-access data-type +return-access ::= +mutable |[ immutable ]| any + +The name **me **denotes the object to which the method is applied: you call this the “principal object” of the method. The passing mode expresses whether the direct content of the principal object or a parameter is either: + + * read + * created and returned + * read then updated and returned by the method. + +Remember that the direct content of an argument of a type which is manipulated by value contains the internal representation of the object itself. Thus, when the argument is of this type, **out **and **in out **mean that the content of the object will undergo a modification. When the method is a function (as is the case for constructors), all the arguments must be **in **(read). This is the default mode. + +In case of an argument of a type manipulated by a handle, the direct content being an object identifier, the passing mode addresses itself to the handle, and no longer to the internal representation of the object, the modification of which is controlled by the access right. An argument of this type declared **mutable **may see its internal representation modified. If declared **immutable**, it is protected. When a parameter is both **in out **and **mutable**, the identifiers passed and returned denote two distinct modifiable objects. + +When the returned object is manipulated by a handle it can be declared modifiable or not, or indeterminate (**any**). To return an object with an indeterminate access right means that the method transmits the identifier without changing its state and that the method has no right to alter the access right. This functionality is particularly useful in the case of collections; temporarily storing an object in a structure and unable to modify its state. + +With the exception of the types predefined by the language, all types of parameters and returned objects, whether manipulated by a handle or by value, *must *appear in the **uses **clause of the class of which the method is a member. +As is the case for constructors, some parameters can have a default value, provided that they are of primitive or enumerated type. They are passed in the **in **mode, and they are found at the end of the list of arguments. + +Overloading of instance methods and use of exceptions and post-conditions is allowed and respects the same rules than constructors. + +Note the overloading of “Coord” in the following example of instance methods associated with the persistent class “Point”: +**Example** + +Coord (me; X, Y, Z : out Real); +---Purpose: returns the coordinates of me + +Coord (me; i : Integer) returns Real; +---Purpose: returns the abscissa (i=1), the +-- ordinate (i=2) or the value (i=3) of me + +SetCoord (me : mutable; X, Y, Z : Real); +---Purpose: modifies the coordinates of me + +Distance (me; P : Point) returns Real +---Purpose: returns the distance to a point + +In all these cases, **me **is implicitly an object of type Point. Only “SetCoord” is able to modify the internal representation of a point. + +@subsubsection occt_1819379591_1972310108413 Class Methods + +A class method is a function or procedure relative to the class it describes, but does not apply to a particular instance of the class. + +declaration-of-a-class-method ::= +identifier formal-part-of-class-method +[ declaration-of-returned-type ] +[ exception-declaration ] +formal-part-of-class-method ::= +’(’ **myclass **{’;’ parameter}’)’ + +The first parameter **myclass **indicates that the method does not apply to a previously created instance, but to the class itself. The rest of the syntax is identical to that of the instance methods. In particular, access rights (**mutable**, **immutable**, **any**) and the argument passing mode (**in**, **out**, **in out**) must remain unchanged. With the exception of the types predefined by the language, all types of parameters must appear in the **uses **clause of the class of which the method is a member. Overloading of class methods and the use of exceptions and post-conditions is allowed, and it follows the same rules as for constructors and instance methods. +Examples of class methods associated with the class “Real”: +**Example** + +First (myclass) returns Real; +---Purpose: returns lower limit of reals + +Last (myclass) returns Real; +---Purpose: returns upper limit of reals + + +@subsubsection occt_1819379591_1972310108414 Package Methods + +Package methods are methods which are members of a package. They are frequently used for library or application initialization, or for offering an application programming interface to the sources to the package. They are sometimes methods used for development purposes but which are not made available to final end-users of the package. + +package-method ::= +identifier [simple-formal-part][returned-type-declaration] +[exception-declaration] +[**is private**]’;’ + + +@subsubsection occt_1819379591_1972310108415 Sensitivity to Overloading + +When there is more than one method of a class, several methods share the same name but have different syntax, you say the method is overloaded. + +In order that the methods can be considered distinct, they must differ either in the number of parameters, or one of their parameters must be of a different type. In particular, you *cannot *overload a method if you merely modify it as follows: + + * The type of the returned object when the method behaves as a function + * The name or the mode of passing a parameter +(**in**, **out**, or **in out**) + * The mutability of passed objects +(**mutable**, **immutable**, **any**) + * Default value of a parameter. +@subsection occt_1819379591_197231010842 Internal Representation + +Each object contains its own state in a private space in the memory. This state consists of a set of **fields**,** **which include or reference other objects. +**Example** + +declaration-of-the-internal-representation-of-a-class +::= +**fields **field {field} +field ::= +identifier {’,’ identifier} ’:’ data-type [’[’integer +{’,’integer}’]’]’;’ + +A copy of all the defined fields exists locally in each instance of the class. This group of fields will be initialized by the class constructors when the object is instantiated. + +Fields *must not *have the same name as any method of the class in which they appear. When the field type is followed by a list of integer constants between square brackets, the data will take the form of a multi-dimensional array containing objects of this type. + +The following example shows two equivalent ways of describing three fields of the “Real” type: +**Example** + +fields +x, y, z: Real; +coord: Real[3]; + +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. + +exception-treatment ::= **raises **exception-name {’,’ +exception-name} + +Each exception name corresponds to a class of exceptions previously defined as being susceptible to being raised by the method under which it appears. Exception classes must all appear in the **raises **clause of the class of which the method is a member. The class of exceptions is analogous to the class of objects described in this manual. + +Take for example the method which returns the x, y, or z coordinate of a point. +**Example** + +Coord (me; i : Integer) returns Real +---Purpose: +-- Returns the abscissa (i=1) +-- the ordinate (i=2) +-- or the value (i=3) +-- of me. +raises OutOfRange; +-- if i is not equal to 1, 2, or 3. + +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. + +**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. + +These exceptions are described in the Standard Package (System Toolkits). + + +@subsection occt_1819379591_197231010844 Inheritance + +@subsubsection occt_1819379591_1972310108441 Overview + +The notion of inheritance comes from a development strategy according to which you begin by modeling data in the most general fashion. Then you specialize it more and more so as to correspond to more and more precise cases. + +For example, to develop a basic geometry, you can first of all consider the group of geometric objects, and then differentiate the points, vectors, and curves. You can specialize the latter into conic sections, and then decompose them into circles, ellipses, and hyperbolae. Then, the class of conics is considered as a sub-class of curves, and a super-class of circles. + +A sub-class has at least the behavior of its super-classes. Thus, a circle could be viewed as a conic, a curve, or even as a geometric object. In each case, the applicable methods belong to the level where you view the class. In this case, you say that the sub-class inherits the behavior from its super-classes. +**Example** + +declaration-of-a-sub-class ::= +**class **class-name +**inherits **class-name +[**uses **data-type {’,’ data-type}] +[**raises **exception-name {’,’ exception-name}] +**is **class-definition +**end **[class-name]’;’ + +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. + +NOTE +Note that constructors and class methods are never inherited. + + +@subsubsection occt_1819379591_1972310108442 Redefining methods + +Certain inherited methods can be redefined. +**Example** + +declaration-of-a-redefined-method ::= +identifier formal-part-of-instance-method [returnedtype- +declaration] +[declaration-of-exceptions] +**  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. + +The **redefined **attribute can be applied neither to a constructor, nor to a class method, since neither of them can be inherited. If the redefined method is private or protected, the visibility must be exactly repeated in the redefinition. For further details on visibility, refer to “Visibility” on page 48. +**Example** + +SquareDistance (me; P : Point) returns Real +is redefined private; + +With regards to the internal representation, all fields defined in the super-classes are, by default, inherited, but they can also be redefined. + +@subsubsection occt_1819379591_1972310108443 Non-redefinable methods + +Instance methods, which are declared virtual are redefinable in descendent classes, and you can force this redefinition by making a method **deferred**. For more details, see the next section. +**Example** + +declaration-of-a-non-redefinable-method ::= +identifier formal-part-of-instance-method [returnedtype- +declaration] +[declaration-of-exceptions] +** is virtual **[visibility]’;’ + +All methods are static by default. To enable redefinition in all the child classes, add “**is virtual;**“ when declaring the method. + +You must also be able to forbid redefinition. A redefinable method can become non-redefinable if you declare: **is redefined static**. + + +@subsubsection occt_1819379591_1972310108444 Deferred Classes and Methods + +The presence of certain classes in the inheritance graph can be justified purely by their ability to force certain behavior on other classes, in other words, to make other classes provide various services. + +The CDL language allows you to describe a class, which introduces methods without implementing them, so as to force its descendent classes to define them. These are called **deferred classes**; the non-implemented methods are also termed **deferred methods**. +**Example** + +declaration-of-a-deferred-class ::= +**deferred class **class-name + [**inherits **class-name +[**uses **data-type {’,’ data-type}] +[**raises **exception-name {’,’ exception-name}] +**is **class-definition +**end **[class-name]’;’ +declaration-of-a-deferred-method ::= +identifier formal-part-of-instance-method [returnedtype- +declaration] +[declaration-of-exceptions] +**is deferred **[visibility]’;’ + +Only instance methods can be deferred. + +It is sufficient for a class to contain one deferred method for it to be a deferred class. It can contain any number of deferred methods (or none). + +A deferred class may still have an internal representation but one or more **non-** **protected **constructors would be necessary to initialize them. The constructors must be visible in the sub-classes. + +The constructors of a deferred class are called **Initialize **(not **Create**). They are **protected **by default, and do not return any object. You cannot create an object of a deferred class type. +For example, consider the class “Point”, and its declaration as deferred. +**Example** + +deferred class Point inherits Geometry is +Initialize; +---Purpose: Initializes the point. +Coord (me; X, Y, Z : out Real) +---Purpose: Returns the coordinates +is deferred; +SetCoord (me : mutable; X, Y, Z : Real) +---Purpose: Modifies the coordinates +is deferred; +Distance (me; P : Point) returns Real; +---Purpose: Returns the distance from the point P +end Point; + +Notice that the function “Distance” is not deferred. Although this class contains no representation, this method is programmable by calling “Coord”. + +In a sub-class of a deferred class, all deferred methods, which have been inherited, *must *be implemented, then redeclared (the attribute **redefined **is useless for this purpose), unless the sub-class is itself deferred. + +A non-deferred method can be redefined as a deferred one, in which case it will be declared as follows: **is redefined deferred**. + +The notion of deferred class is very useful. The advantage of introducing it, as was previously shown in the deferred class “Point”, is that the corresponding resources will be available even before being implemented. Later, you can add different representations to Point (for example, spherical or Cartesian coordinates) without having to modify client programs. + +Thanks to the possibility of redefining methods, this approach does not have any negative impact on performance: a method implemented at the level of a deferred class can be reprogrammed in one of its sub-classes while taking into account the data representation. +@subsubsection occt_1819379591_1972310108445 Declaration by Association + +At the heart of a class hierarchy, object identifiers are compatible in the ascendant sense. Since the Conic class is descended from the Curve class, an identifier of type Curve can reference an object of type Conic (remember that the behavior of Curve is applicable to Conic). In other words, you can assign a reference to a Conic to an identifier of type Curve, but *not *vice versa. + +For example, once the classes have been compiled you could write a C++ test program in which you instantiate a Conic but reference it with a handle to a Curve: + +**Example** + +Handle(Curve) c = new Conic + +This same rule applies to parameters of methods; that is to say, you can call a method with identifiers corresponding to a sub-type of that specified in its declaration. To illustrate this, you go back to the “Distance” method of the “Point” class: +**Example** + +Distance (me; P : point) returns Real; + +Conforming to the rule of type compatibility, you could make a call to the method “Distance” with reference to an object from a class descended from “Point”. Consequently, if “SphericPoint” is a sub-class of “Point” and therefore inherits this method, it will be possible to calculate the distance between two “SphericPoint”, or between a “SphericPoint” and a “Point”, without having to redefine the method. + +On the other hand, sometimes you may want to force two parameters to be exactly of the same type, and thus not apply the rule of type compatibility. To do this, you need to associate the type of the concerned parameters in the method declaration. +**Example** + +association-typing ::= +**like **associated-parameter +associated-parameter ::= +**me **| identifier + + +NOTE +***Note that identifier is the name of a parameter, which appears*** +***first in the formal part of the declaration of the method.*** + + +You can use this technique, which consists in declaring by association, to declare a method that will exchange the content of two objects, or a method, which copies another object: +**Example** + +Swap (me : mutable; With : mutable like me); +DeepCopy (me) returns mutable like me; + +Make sure *not *to write the Swap method as in the syntax below: + +**Example** + +Swap (me : mutable; With : mutable Point); + +In this case **me **may be a CartesianPoint or a SphericalPoint, while “With” can only be a Point. +@subsubsection occt_1819379591_1972310108446 Redefinition of Fields + +The creation of a hierarchy of classes should be viewed as a means to specialize their behavior, (e.g. a circle is more specialized than a conic section). The more you specialize the object classes, the more it is justified to call into question the inherited fields in order to obtain greater optimization. So, in the description of the internal representation of a sub-class, it is possible not to inherit all of the fields of the super-classes. You then say the fields have been redefined. +**Example** + +redefinition-of-the-representation-of-a-class ::= +**redefined **redefinition-of-a-field {’,’ redefinition-of-a- +field}’,’ +redefinition-of-a-field ::= +[field-name] **from **[**class**] class-name + +Redefinition of fields can *only *be done in classes manipulated by a handle. + +This declaration appears at the beginning of the definition of the internal representation of the sub-class, which breaks the field inheritance. The non-inherited fields are all those which come from the class specified behind the rubric **from**. + + +@subsection occt_1819379591_197231010845 Genericity + +@subsubsection occt_1819379591_1972310108451 Overview + +Inheritance is a powerful mechanism for extending a system, but it does not always allow you to avoid code duplication, particularly in the case where two classes differ only in the type of objects they manipulate (you certainly encounter this phenomenon in all basic structures). In such cases, it is convenient to send arbitrary parameters representing types to a class. Such a class is called a **generic class**. Its parameters are the generic types of the class. + +Generic classes are implemented in two steps. You first declare the generic class to establish the model, and then instantiate this class by giving information about the generic types. + +@subsubsection occt_1819379591_1972310108452 Declaration of a Generic Class + +The syntax is as follows: +**Example** + +declaration-of-a-generic-class ::= +[**deferred**] **generic class **class-name ’(’generic-type +{’,’generic-type}’)’ +[**inherits **class-name +[**uses **data-type {’,’ data-type}] +[**raises **exception-name {’,’ exception-name}] +**is **class-definition +**end **[class-name]’;’ +generic-type ::= +identifier **as **type-constraint +type-constraint ::= +**any **| class-name [’(’data-type {’,’data-type}’)’] + +The names of generic types become new types, which are usable in the definition of a class, both in its behavior (methods) and its representation (fields). The generic type is only visible inside the generic class introducing it. As a result, it is possible to have another generic class using the same generic type within the same package. +When you specify the type constraint under the form of a class name, you impose a minimum set of behavior on the manipulated object. + +This shows that the generic type has as a minimum the services defined in the class. This can be any kind of a previously defined class, including another generic class, in which case you state exactly with what types they are instantiated. + +When the generic type is constrained by the attribute **any**, the generic class is intended to be used for any type at all, and thus corresponds to classes whether manipulated by a handle or by value. + +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. + +Below is a partial example of a generic class: a persistent singly linked list. +**Example** + +generic class SingleList (Item as Storable) +inherits Persistent +raises NoSuchObject +is +Create returns mutable SingleList; +    ---Purpose: Creates an empty list +IsEmpty (me) returns Boolean; +    ---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 +-- Exception NoSuchObject raised when me is +empty +raises NoSuchObject; +   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 +---Purpose: Returns the tail of the list me +-- Exception NoSuchObject raised when me is +empty +raises NoSuchObject; +   fields +Data : Item; +   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** + +generic class Sequence(Item as any, Node as +SingleList(Item)) +inherits Object +. . . +end Sequence + +In the above example, there are two generic types: Item & Node. The first imposes no restriction. The second must at least have available the services of the class SingleList instantiated with the type with which Sequence will itself be instantiated. + +In the **incomplete declaration of a generic class**, the keyword **generic **must appear. +**Example** + +generic class SingleList; +generic class Sequence; +@subsubsection occt_1819379591_1972310108453 Instantiation of a Generic Class + +The syntax is as follows: +**Example** + +instantiation-of-a-generic-class ::= +[**deferred**] **class **class-name +**     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. + +For example, let’s instantiate the class “Sequence” for the type “Point”: +**Example** + +class SingleListOfPoint instantiates SingleList(Point); +class Sequence instantiates +Sequence(Point,SingleListOfPoint); + +The instantiation of a generic deferred class is a deferred class (the **deferred **attribute must be present during instantiation). An instantiated class cannot be declared in an incomplete fashion. + +@subsubsection occt_1819379591_1972310108454 Nested Generic Classes + +It often happens that many classes are linked by a common generic type. This is the case when a base structure provides an iterator, for example, in the class “Graph”. A graph is made up of arcs, which join together the nodes, which reference objects of any type. This type is generic both for the graph and for the node. 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. So as to group the instantiation, CDL allows the declaration of certain classes to be nested. +**Example** + +declaration-of-a-generic-class ::= +   [**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 +**end **[class-name]’;’ +   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. + +Nested classes are, by default, **public**. In other words, they can be used by the clients of the encompassing class. On the other hand, when one of the nested classes is declared **private **or **protected**, this class *must not *appear in any of the public methods of the other classes. It cannot be used in a protected field because then it could be used in a sub-class, which implies it would not be private. + +The following example shows how to write the Set class with its iterator. +**Example** + +generic class Set (Item as Storable) +inherits Persistent +private class Node instantiates SingleList (Item); +class 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; +---Purpose: Returns true if there are still elements +   -- to explore +   Next (me) raises NoMoreObject; +---Purpose: Passes to the following element +   Value (me) returns any Item raises NoSuchObject; +---Purpose: Returns the current element +   fields +   Current : Node; +end Iterator; +is +   Create returns mutable Set; +---Purpose: Creates an empty group +   IsEmpty (me) returns Boolean; +---Purpose: Returns true if the group is empty +   Add (me : mutable; T : Item); +---Purpose: Adds an item to the group me +   Remove (me : mutable; T : item) raises +NoSuchObject; +---Purpose: Removes an item from the group me +   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. + +The instantiation of a generic class containing nested classes remains unchanged. The same declaration is used to instantiate the encompassing class and the nested classes. These latter will have their name suffixed by the name supplied at instantiation, separated by “Of”. For example, you instantiate the class “Set” described above for the type “Point” as follows: +**Example** + +class SetOfPoint instantiates Set(Point); + +In doing so, you implicitly describe the classes “NodeOfSetOfPoint” and “IteratorOfSetOfPoint”, which are respectively the result of the concatenation of “Node” and “Iterator” with “Of” then “SetOfPoint”. + +Note that in the incomplete declaration of an encompassing class, all the names of the nested classes *must *appear behind that of the encompassing class. + +incomplete-declaration-of-a-generic-class ::= +[**deferred**] **generic **class-name {’,’ class-name}; + +For example, an incomplete declaration of the above class “Set” would be as in the example below: +**Example** + +generic class Set, Node, Iterator; + +Only the encompassing class can be deferred. In the above example only the class “Set” can be deferred. + + + +@subsection occt_1819379591_197231010846 Visibility + +@subsubsection occt_1819379591_1972310108461 Overview + +A field, method, class, or package method is only available for use if it is **visible**. +Each of these components has a default visibility, which can be explicitly modified during class or package declaration. The three possible states of visibility are: + + * Public + * Private + * Protected + +@subsubsection occt_1819379591_1972310108462 Visibility of Fields + +A field is **private**. It can never be public - this would destroy the whole concept of data encapsulation. The attribute **private **is redundant when it is applied to a field. This means that a field is only visible to methods within its own class. +A field can be declared **protected **which means that it becomes visible in subclasses of its own class. Its contents can be modified by methods in subclasses. + +field ::= +identifier {’,’ identifier} ’:’ data-type +[’[’integer{’,’integer}’]’] +[**is protected**]’;’ +Example + +fields +   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. + +**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. + +If you want to restrict the usage of a method, you associate with it a visibility as follows : + +-- declaration-of-the-visibility ::= +**is **visibility +visibility ::= **private **| **protected** + +The declaration of the visibility of a method appears at the end of its definition, before the final semi-colon. The attribute **private **indicates that the method will only be visible to the behavior of the class of which the method is a member; **protected **will propagate the visibility among the sub-classes of this class. + +For example, add to the class “Line” an internal method allowing the calculation of the perpendicular distance to the power of two, from the line to a point. +**Example** + +SquareDistance (me; P : Point) returns Real +@subsubsection occt_1819379591_1972310108464 Visibility of Classes, Exceptions, & Enumerations + +The visibility of a class is the facility to be able to use this class in the definition of another class. The visibility of a class extends from the beginning of its declaration up to the end of the package in which it appears. You have seen that the keyword **uses **allows extension of this visibility to other packages. + +As was explained in the section on “Name Space”, any ambiguity, which arises from having two classes with the same name coming from different packages, is dealt with by the use of the keyword **from**. + +A class declared **private **is only available within its own package. + +@subsubsection occt_1819379591_1972310108465 Friend Classes & Methods + +In certain cases, methods need to have direct access to the private or protected parts of classes of which they are clients. Such a method is called a **friend **of the class, which is accessed. For example, you declare a method to be a friend when a service can only be obtained via the use of another non-descendent class, or perhaps when this will help to improve performance. + +Classes can also be declared friends of other classes. In this case all the methods of the friend class will have access to the fields and methods of the host class. The right is **not reciprocal**. + +Friend classes or methods are declared inside the class, which reveals its private and protected data or methods to them. This helps in managing the continuing evolution of a class, helping to recognize and to avoid the creation of side effects. +**Example** + +declaration-of-friends ::= +**friends **friend {’,’friend} +   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 + +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”. + +As an example, take a method, which calculates the perpendicular distance between a line and a point. Suppose this method needs to access the fields of the point. In the class “Point” you would write: +**Example** + +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. + + + + + + + + +
+ +
+ + + ![](/devs_guide/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 + + + +This summary of the CDL syntax will aid in the comprehension of the language, but does *not *constitute an exact definition thereof. In particular, the grammar described here accepts a super-set of CDL constructors semantically validated. + +(1) capital ::= +’A’ | ’B’ | ’C’ | ’D’ | ’E’ | ’F’ | ’G’ | ’H’ | +’I’ | ’J’ | ’K’ | ’L’ | ’M’ | ’N’ | +’O’ | ’P’ | ’Q’ | ’R’ | ’S’ | ’T’ | ’U’ | ’V’ | +’W’ | ’X’ | ’Y’ | ’Z’ + +(2) non-capital ::= +’a’ | ’b’ | ’c’ | ’d’ | ’e’ | ’f’ | ’g’ | ’h’ | +’i’ | ’j’ | ’k’ | ’l’ | ’m’ | ’n’ | +’o’ | ’p’ | ’q’ | ’r’ | ’s’ | ’t’ | ’u’ | ’v’ | +’w’ | ’x’ | ’y’ | ’z’ + +(3) digit ::= +’0’ | ’1’ | ’2’ | ’3’ | ’4’ | ’5’ | ’6’ | ’7’ | +’8’ | ’9’ + +(4) underscore ::= +’_’ + +(5) special character ::= +’ ’ | ’!’ | ’”’ | ’#’ | ’$’ | ’%’ | ’&’ | ’’’ | +’(’ | ’)’ | ’*’ | ’+’ | ’,’ | ’-’ | +’.’ | ’/’ | ’:’ | ’;’ | ’’ | ’=’ | ’’ | ’?’ | +’@’ | ’[’ | ’\’ | ’]’ | ’^’ | ’‘’ | +’{’ | ’|’ | ’}’ | ’~’ + +(6) printable character::= +capitals | non-capitals | digits | underscore | +special characters + +(7) letter ::= +capital | non-capital + +(8) alphanumeric ::= +letter | digit + +(9) identifier ::= +letter{[underscore]alphanumeric} + +(10) integer ::= +digit{digit} + +(11) exponent ::= +’E’[’+’]integer | ’E-’integer + +(12) numeric-constant ::= +[’+’]integer ’.’ integer[exponent] | ’-’integer +’.’ integer[exponent] + + +(13) literal-constant ::= +’’’printable character’’’ | ’~’{printable +character}’~’ + +(14) package-name ::= +identifier + +(15) enumeration-name ::= +identifier [**from**** **package-name] + +(16) class-name ::= +identifier [**from**** **package-name] + +(17) exception-name ::= +identifier [**from**** **package-name] + +(18) constructor-name ::= +’Create’ | ’Initialize’ + +(19) primitive-type ::= +’Boolean’ | ’Character’ | ’Integer’ | ’Real’ + +(20) data-type ::= +enumeration-name | class-name | exception-name +| primitive-type + +(21) passed-type ::= +data-type | **like me**** **| **like**** **identifier + +(22) passing-mode ::= +[**in**] | **out**** **| **in out** + +(23) parameter-access ::= +**mutable**** **| [**immutable**] + +(23A) return-access ::= +**mutable**** **| [**immutable**]| **any** + +(24) value ::= +numeric-constant | literal-constant | +identifier + +(25) parameter ::= +identifier {’,’ identifier} ’:’ passing-mode +access-right passed-type [’=’ value] + +(26) simple-formal-part ::= +’(’parameter {’;’ parameter}’)’ + +(27) formal-part-of-instance-method ::= +’(’**me**** **[’:’ passing-mode access-right] {’;’ +parameter}’)’ + +(28) formal-part-of-class-method ::= +’(’**myclass**** **{’;’ parameter}’)’ + +(29) visibility ::= +**private**** **| **protected** +(30) redefinition ::= +**static**** **| **deferred** +(31) definition-level ::= +redefinition |** ****redefined**** **[redefinition] + +(32) declaration-of-constructed-type ::= +**returns**** **[**mutable**] class-name + +(33) declaration-of-returned-type ::= +**returns**** **return-access passed-type + +(34) declaration-of-errors ::= +**raises**** **exception-name {’,’ exception-name} + +(35) declaration-of-visibility ::= +**is****  **visibility + +(36) declaration-of-attributes-of-instance-method ::= +**is**** **visibility | **is **definition-of-level +[visibility] + +(37) constructor ::= +constructor-name [simple-formal-part] +[declaration-of-constructed-type] +[declaration-of-errors] +[declaration-of-visibility]’;’ + +(38) instance-method ::= +identifier formal-part-of-instance-method +[declaration of returned type] +[declaration-of-errors] +[declaration-of-attributes-of-instancemethod]’;’ + +(39) class-method ::= +identifier formal-part-of-the-class-method +[declaration of returned type] +[declaration-of-errors] +[declaration-of-visibility]’;’ + +(40) package-method ::= +identifier [simple-formal-part] +[declaration-of-returned-type] +[declaration-of-errors] +[**is private**]’;’ + +(41) member-method ::= +constructor | instance-method | class-method + +(42) formal-part ::= +simple-formal-part | +formal-part-of-instance-method| +formal-part-of-class-method + +(43) friend ::= +identifier **from**** **[**class**] class-name [formal-part] +| +identifier **from**** **[**package**] package-name [formal- +part] | +[**class**] class-name + +(44) field ::= +identifier {’,’ identifier} ’:’ data-type +[’[’integer {’,’ integer}’]’] +[**is protected**]’;’ + +45) redefinition-of-field ::= +[field-name] **from**** **[**class**] class-name + +(46) declaration-of-fields ::= +**fields**** **[**redefined**** **redefinition-of-field {’,’ +redefinition-of-field}’;’] +field {field} + +(47) declaration-of-an-alias::= +[**private**] **alias**** **class-name1 **is**** **class-name2 [**from** +package-name] + +(48) declaration-of-friends ::= +**friends**** **friend {’,’ friend} + +(49) class-definition ::= +[{member-method}] +[declaration-of-fields] +[declaration-of-friends] + +(50) declaration-of-an-exception ::= +**exception**** **exception-name +**inherits**** **exception-name + +(51) declaration-of-an-enumeration ::= +**enumeration**** **enumeration-name +**is**** **identifier {’,’ identifier} +[**end**** **[enumeration-name]]’;’ + +(52) incomplete-declaration-of-a-non-generic-class ::= +[**deferred**] **class**** **class-name’;’ + +(53) incomplete-declaration-of-a-generic-class ::= +[**deferred**] **generic class**** **class-name {’,’ class-name}’;’ + +(54) declaration-of-a-non-generic-class ::= +[**deferred**] **class**** **class-name +[**inherits**** **class-name +[**uses**** **data-type {’,’ data-type}] +[**raises**** **exception-name {’,’ exception-name}] +**   is **definition-of-a-class +**end **[class-name]’;’ + +(55) type-constraint ::= +**any**** **| class-name [’(’data-type {’,’ data-type}’)’] + +(56) generic-type ::= +identifier **as**** **type-constraint +@section occt_1819379591_2139552861 Appendix B. + + + +@subsection occt_1819379591_213955286151 Comparison of CDL & C++ Syntax for Data Types manipulated by Handle and by Value + + + + + + + + + +
+ +
+ + + ![](/devs_guide/cdl/images/cdl_image012.jpg) +
+ diff --git a/dox/dev_guides/cdl/images/cdl_image001.jpg b/dox/dev_guides/cdl/images/cdl_image001.jpg new file mode 100644 index 0000000000..0e782cab77 Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image001.jpg differ diff --git a/dox/dev_guides/cdl/images/cdl_image002.jpg b/dox/dev_guides/cdl/images/cdl_image002.jpg new file mode 100644 index 0000000000..5f87a335b2 Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image002.jpg differ diff --git a/dox/dev_guides/cdl/images/cdl_image003.jpg b/dox/dev_guides/cdl/images/cdl_image003.jpg new file mode 100644 index 0000000000..15de92cd35 Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image003.jpg differ diff --git a/dox/dev_guides/cdl/images/cdl_image004.jpg b/dox/dev_guides/cdl/images/cdl_image004.jpg new file mode 100644 index 0000000000..87a293d833 Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image004.jpg differ diff --git a/dox/dev_guides/cdl/images/cdl_image005.jpg b/dox/dev_guides/cdl/images/cdl_image005.jpg new file mode 100644 index 0000000000..04f85ee40e Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image005.jpg differ diff --git a/dox/dev_guides/cdl/images/cdl_image006.jpg b/dox/dev_guides/cdl/images/cdl_image006.jpg new file mode 100644 index 0000000000..7573c614df Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image006.jpg differ diff --git a/dox/dev_guides/cdl/images/cdl_image007.jpg b/dox/dev_guides/cdl/images/cdl_image007.jpg new file mode 100644 index 0000000000..370ed264af Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image007.jpg differ diff --git a/dox/dev_guides/cdl/images/cdl_image008.jpg b/dox/dev_guides/cdl/images/cdl_image008.jpg new file mode 100644 index 0000000000..6648804378 Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image008.jpg differ diff --git a/dox/dev_guides/cdl/images/cdl_image009.jpg b/dox/dev_guides/cdl/images/cdl_image009.jpg new file mode 100644 index 0000000000..b07ee6c143 Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image009.jpg differ diff --git a/dox/dev_guides/cdl/images/cdl_image010.jpg b/dox/dev_guides/cdl/images/cdl_image010.jpg new file mode 100644 index 0000000000..b471c0a0de Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image010.jpg differ diff --git a/dox/dev_guides/cdl/images/cdl_image011.jpg b/dox/dev_guides/cdl/images/cdl_image011.jpg new file mode 100644 index 0000000000..d67dff7e0b Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image011.jpg differ diff --git a/dox/dev_guides/cdl/images/cdl_image012.jpg b/dox/dev_guides/cdl/images/cdl_image012.jpg new file mode 100644 index 0000000000..e60fdd6fa1 Binary files /dev/null and b/dox/dev_guides/cdl/images/cdl_image012.jpg differ diff --git a/dox/dev_guides/dev_guides.md b/dox/dev_guides/dev_guides.md new file mode 100644 index 0000000000..e72a1dc8b9 --- /dev/null +++ b/dox/dev_guides/dev_guides.md @@ -0,0 +1,102 @@ + Developer Guides {#dev_guides} +================ + +@section OCCT_OVW_SECTION1 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 +exchange, and visualization. OCCT can be best applied in development of +software dealing with 3D modeling (CAD), manufacturing / measuring (CAM) or +numerical simulation (CAE). + +The OCCT code is subject to the Open CASCADE Technology Public License Version +6.6 (the "License"). You may not use the content of the relevant files except in +compliance with the License. Please see the LICENSE file or obtain a copy of the +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 + +OCCT automatic testing system is integrated with @ref draw "DRAW Test Harness", +a console application based on Tcl (a scripting language). +All tests are run from DRAW command prompt (run **draw.bat** or +**draw.sh** to start it). + +Standard OCCT tests are located in subdirectory **tests** of the OCCT root +folder. This location is set as default at DRAW start (see environment variable +_CSF_TestScriptsPath_ defined in **src/DrawResources/DrawDefaults**). + +The tests are organized in three levels: +- Group: a group of related test grids, usually testing a particular subset of OCCT functionality (e.g. *blend*). +- Grid: a set of test cases within a group, usually aimed at testing a particular aspect or mode of execution of the relevant functionality (e.g. *buildevol*). +- Test case: a script implementing an individual test (e.g. *K4*). + +To run all tests, type command *testgrid*: + + Draw[]\> testgrid + +For running only a group or a grid of tests, give additional arguments indicating the group and (if needed) the grid name: + + Draw[]\> testgrid blend simple + +As the tests progress, the result of each test case is reported. +At the end of the log a summary of test cases is output, including the list of +detected regressions and improvements, if any. +The tests are considered as non-regressive if only OK, BAD (i.e. known problem), +and SKIPPED (i.e. not executed, typically because of lack of a data file) +statuses are reported. + +To run a single test, type command 'test' followed by the names of +group, grid, and test case. + + Draw[1]\> test blend simple A1 + CASE blend simple A1: OK + +To see intermediate commands and their output during the test execution, +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" + +@section OCCT_OVW_SECTION1112 CDL Overview + +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. + +For more information consult \subpage dev_guides__cdl "Component Definition Language Developer's Guide" + +@section OCCT_OVW_SECTION1113 Documentation Overview + +\subpage dev_guides__documentation "Documentation Developer's Guide" diff --git a/dox/dev_guides/documentation/documentation.md b/dox/dev_guides/documentation/documentation.md new file mode 100644 index 0000000000..d8965dd884 --- /dev/null +++ b/dox/dev_guides/documentation/documentation.md @@ -0,0 +1,531 @@ + Documentation {#dev_guides__documentation} +================= + +@section OCCT_DM_SECTION_1 Introduction + +This document provides practical guidenes for generation and editing of OCCT user documentation. + +@section OCCT_DM_SECTION_2 Prerequisites + +Tcl/Tk +The lates version: http://www.tcl.tk/software/tcltk/download.html + +Doxygen ( >= 1.8.4 ) +The latest version: http://www.stack.nl/~dimitri/doxygen/download.html + +MathJax (used for rendering math formulas in browser). Download it for local installation or use the MathJax Content Delivery Network. \(read +@htmlonly Formulas @endhtmlonly paragraph for more detailed description\). +The latest version: http://www.mathjax.org/download/ + +MiKTeX or equivalent tool (used for PDF document creation) +Latest version: http://miktex.org/download + +@section OCCT_DM_SECTION_2_1 Documentation Generation + +Run gendoc.bat from OCCT directory to generate all articles are defined in FILES.txt: + +gendoc.bat options: + + * -html : To generate HTML files (cannot be used with -pdf); + * -pdf : To generate PDF files (cannot be used with -html); + * -m= : Specifies list of articles to generate. If it is not specified, all files, mentioned in FILES.txt are processed; + * -l= : Specifies the article caption for a single document; + * -h : Prints help message; + * -v : Specifies the Verbose mode (info on all script actions is shown). + +If you run the command without arguments (like example above) it will generate HTML documentation +for all articles are defined into FILES.txt. + +**Note**: the generation process generates PDF files for each article, +but in html case it generates common Html page with references to the ones. + +For generation of specific article you need: + * have it's name with relative path (from \%OCCDIR\%/dox/ to the file) contained in FILES.txt + (is located into \%OCCDIR\%/dox/ directory). + +@verbatim +devs_guid/documentation/documentation.md +@endverbatim + +where documentation .md is name of article and devs_guid/documentation/ is relative path of it + + * use this name with -m option in the generation process: + +@verbatim +% gen.bat -html -m=devs_guid/documentation/documentation.md +@endverbatim + +Multiple files are separated with comma: + +@verbatim +% gen.bat -html -m=MD_FILE_1,MD_FILE_2 +@endverbatim + +To sepcify a article name with -l option, use tcl list to prevent whitespaces incorrect interpretation: + +@verbatim +% gen.bat -pdf -m=MD_FILE_1 -l=[list MD File 1 Label] +@endverbatim + +@section OCCT_DM_SECTION_3 Documentation Conventions + +This section contains information about conventions in the field of OCCT documentation file format, +structure of documentation directories, etc. + +@subsection OCCT_DM_SECTION_3_1 File Format + +It is proposed to use MarkDown file format for easy maintainance of generic text documents. +The MarkDown files have a "*.md" extension and are based on rules desribed in +@htmlonly Document Syntax @endhtmlonly section. + +@subsection OCCT_DM_SECTION_3_2 Directory Structure + +![](/devs_guide/documentation/images/documentation_image001.png) + +Every separate article has own folder if images are used in it. These images +are stored into "images" subfolder. + +If you want to use the same image for several articles, you can place the one into "dox/resources" folder. + +**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 +![](/devs_guide/snv/images/snv_image001.svg) +@endverbatim + +Result of generation of the documentation is: + +%OCCT_DIR% / doc - a folder for generated articles; + * html/ - a directory for generated HTML pages; + * pdf/ - a directory for generated PDF files. + +@section OCCT_DM_SECTION_4 Adding a New Article + + - 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 +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 + + - Update dox/FILES.txt to add relative path to svn.md. For instance +@verbatim +devs_guide/snv/svn.md +@endverbatim + +**Note**: the place of the relative path to an article is connected with the place +into treeview of html version. + + +Note, that you should specify a file tag, not the document name. +See Header section for details. + +@section OCCT_DOC_SECTION_5 Additional Resources + +More information about OCCT can be found at http://www.opencascade.org + +The information on formula syntax can be found at: +http://en.wikipedia.org/wiki/Help:Displaying_a_formula + +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 + Doxygen Configuration file + @endhtmlonly +@endverbatim + +to get a link to paragraph : @htmlonly Doxygen configuration @endhtmlonly + +@subsection OCCT_DM_SECTION_A_7 Images + +To insert image into document the developer can write the following code(in Doxygen-style): +@verbatim +![alt-caption](relative/path/to/image/image001.svg "Image Caption") +@endverbatim + +This code tells Doxygen to insert a picture right in the place this code was written. Like this: +@verbatim +![](/resources/occt_logo.png "OCCT logo") +@endverbatim + +![](/resources/occt_logo.png "OCCT logo") + +@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 \ block has to contain + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.html} + + + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +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 +Directory Structure @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} + + + + + + + + + + + + + + + + + + + + + + + + ... + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The tag \ 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. diff --git a/dox/dev_guides/documentation/images/documentation_image001.png b/dox/dev_guides/documentation/images/documentation_image001.png new file mode 100644 index 0000000000..770587ec3b Binary files /dev/null and b/dox/dev_guides/documentation/images/documentation_image001.png differ diff --git a/dox/dev_guides/tests/images/tests_image001.png b/dox/dev_guides/tests/images/tests_image001.png new file mode 100644 index 0000000000..e57173249b Binary files /dev/null and b/dox/dev_guides/tests/images/tests_image001.png differ diff --git a/dox/dev_guides/tests/tests.md b/dox/dev_guides/tests/tests.md new file mode 100644 index 0000000000..731e2a64cb --- /dev/null +++ b/dox/dev_guides/tests/tests.md @@ -0,0 +1,593 @@ + Automated Testing System {#dev_guides__tests} +====================================== + +@section testmanual_1 Introduction + +This document provides overview and practical guidelines for work with OCCT automatic testing system. +Reading this section *Introduction* should be sufficient for OCCT developers to use the test system +to control non-regression of the modifications they implement in OCCT. Other sections provide +more in-depth description of the test system, required for modifying the tests and adding new test cases. + +@subsection testmanual_1_1 Basic Information + +OCCT automatic testing system is organized around DRAW Test Harness [1], +a console application based on Tcl (a scripting language) interpreter extended by OCCT-related commands. +Standard OCCT tests are included with OCCT sources and are located in subdirectory *tests* + of the OCCT root folder. Other test folders can be included in the scope of the test system, + e.g. for testing applications based on OCCT. +Logically the tests are organized in three levels: + + * Group: group of related test grids, usually relating to some part of OCCT functionality (e.g. blend) + * Grid: set of test cases within a group, usually aimed at testing some particular aspect or mode of execution of the relevant functionality (e.g. buildevol) + * Test case: script implementing individual test (e.g. K4) + +Some tests involve data files (typically CAD models) which are located separately + and are not included with OCCT code. The archive with publicly available + test data files should be downloaded and installed independently on OCCT code from dev.opencascade.org. + +@subsection testmanual_1_2 Intended Use of Automatic Tests + +Each modification made in OCCT code must be checked for non-regression +by running the whole set of tests. The developer who does the modification +is responsible for running and ensuring non-regression on the tests that are available to him. +Note that many tests are based on data files that are confidential and thus available only at OPEN CASCADE. +Thus official certification testing of the changes before integration to master branch +of official OCCT Git repository (and finally to the official release) is performed by OPEN CASCADE in any case. + +Each new non-trivial modification (improvement, bug fix, new feature) in OCCT +should be accompanied by a relevant test case suitable for verifying that modification. +This test case is to be added by developer who provides the modification. +If a modification affects result of some test case(s), +either the modification should be corrected (if it causes regression) +or affected test cases should be updated to account for the modification. + +The modifications made in the OCCT code and related test scripts +should be included in the same integration to master branch. + +@subsection testmanual_1_3 Quick Start + +@subsubsection testmanual_1_3_1 Setup + +Before running tests, make sure to define environment variable CSF_TestDataPath +pointing to the directory containing test data files. +(The publicly available data files can be downloaded +from http://dev.opencascade.org separately from OCCT code.) +The recommended way for that is adding a file *DrawInitAppli* +in the directory which is current at the moment of starting DRAWEXE (normally it is $CASROOT). +This file is evaluated automatically at the DRAW start. Example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} +set env(CSF_TestDataPath) d:/occt/tests_data +return ;# this is to avoid an echo of the last command above in cout +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +All tests are run from DRAW command prompt, thus first run draw.tcl or draw.sh to start DRAW. + +@subsubsection testmanual_1_3_2 Running Tests + +To run all tests, type command *testgrid* followed by path +to the new directory where results will be saved. +It is recommended that this directory should be new or empty; +use option –overwrite to allow writing logs in existing non-empty directory. + +Example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + Draw[]> testgrid d:/occt/results-2012-02-27 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If empty string is given as log directory name, the name will be generated automatically +using current date and time, prefixed by *results_*. Example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + Draw[]> testgrid {} +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +For running only some group or a grid of tests, +give additional arguments indicating group and (if needed) grid. Example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + Draw[]> testgrid d:/occt/results-2012-02-28 blend simple +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +As the tests progress, the result of each test case is reported. +At the end of the log summary of test cases is output, +including list of detected regressions and improvements, if any. Example: + + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + Tests summary + + CASE 3rdparty export A1: OK + ... + CASE pipe standard B1: BAD (known problem) + CASE pipe standard C1: OK + No regressions + Total cases: 208 BAD, 31 SKIPPED, 3 IMPROVEMENT, 1791 OK + Elapsed time: 1 Hours 14 Minutes 33.7384512019 Seconds + Detailed logs are saved in D:/occt/results_2012-06-04T0919 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The tests are considered as non-regressive if only OK, BAD (i.e. known problem), +and SKIPPED (i.e. not executed, e.g. because of lack of data file) statuses are reported. +See Grid’s *cases.list* file chapter for details. + +The detailed logs of running tests are saved in the specified directory and its sub-directories. +Cumulative HTML report summary.html provides links to reports on each test case. +An additional report TESTS-summary.xml is output in JUnit-style XML format +that can be used for integration with Jenkins or other continuous integration system. +Type *help testgrid* in DRAW prompt to get help on additional options supported by testgrid command. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + Draw[3]> help testgrid + testgrid: Run all tests, or specified group, or one grid + Use: testgrid logdir [group [grid]] [options...] + Allowed options are: + -verbose {0-2}: verbose level, 0 by default, can be set to 1 or 2 + -parallel N: run in parallel with up to N processes (default 0) + -refresh N: save summary logs every N seconds (default 60) + -overwrite: force writing logs in existing non-empty directory +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@subsubsection testmanual_1_3_3 Running Single Test + +To run single test, type command *test*’ followed by names of group, grid, and test case. + +Example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + Draw[1]> test blend simple A1 + CASE blend simple A1: OK + Draw[2]> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Note that normally intermediate output of the script is not shown. +To see intermediate commands and their output, type command *decho on* +before running the test case. (Type ‘decho off’ to disable echoing when not needed.) +The detailed log of the test can also be obtained after the test execution by command *dlog get*. + +@section testmanual_2 Organization of Test Scripts + +@subsection testmanual_2_1 General Layout + +Standard OCCT tests are located in subdirectory tests of the OCCT root folder ($CASROOT). +Additional test folders can be added to the test system +by defining environment variable CSF_TestScriptsPath. +This should be list of paths separated by semicolons (*;*) on Windows +or colons (*:*) on Linux or Mac. Upon DRAW launch, +path to tests sub-folder of OCCT is added at the end of this variable automatically. +Each test folder is expected to contain: + + * Optional file parse.rules defining patterns for interpretation of test results, common for all groups in this folder + * One or several test group directories. + +Each group directory contains: + + * File grids.list that identifies this test group and defines list of test grids in it. + * Test grids (sub-directories), each containing set of scripts for test cases, and optional files cases.list, parse.rules, begin, and end. + * Optional sub-directory data + * Optional file parse.rules + * Optional files begin and end + +By convention, names of test groups, grids, and cases should contain no spaces and be lowercase. +Names begin, end, data, parse.rules, grids.list, cases.list are reserved. +General layout of test scripts is shown on Figure 1. + +![](/devs_guide/tests/images/tests_image001.png "") + +Figure 1. Layout of tests folder + +@subsection testmanual_2_2 Test Groups + +@subsubsection testmanual_2_2_1 Group Names + +Test folder usually contains several directories representing test groups (Group 1, Group N). +Each directory contains test grids for certain OCCT functionality. +The name of directory corresponds to this functionality. +Example: + +@verbatim + caf + mesh + offset +@endverbatim + +@subsubsection testmanual_2_2_2 Group's *grids.list* File + +The test group must contain file *grids.list* file +which defines ordered list of grids in this group in the following format: + +~~~~~~~~~~~~~~~~~ +001 gridname1 +002 gridname2 +... +NNN gridnameN +~~~~~~~~~~~~~~~~~ + +Example: + +~~~~~~~~~~~~~~~~~ + 001 basic + 002 advanced +~~~~~~~~~~~~~~~~~ + +@subsubsection testmanual_2_2_3 Group's *begin* File + +The file *begin* is a Tcl script. It is executed before every test in current group. +Usually it loads necessary Draw commands, sets common parameters and defines +additional Tcl functions used in test scripts. +Example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + pload TOPTEST ;# load topological command + set cpulimit 300 ;# set maximum time allowed for script execution +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@subsubsection testmanual_2_2_4 Group's *end* File + +The file end is a TCL script. It is executed after every test in current group. +Usually it checks the results of script work, makes a snap-shot +of the viewer and writes *TEST COMPLETED* to the output. +Note: *TEST COMPLETED* string should be presented in output +in order to signal that test is finished without crash. +See Creation And Modification Of Tests chapter for more information. +Example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + if { [isdraw result] } { + checkshape result + } else { + puts *Error: The result shape can not be built* + } + puts *TEST COMPLETED* +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@subsubsection testmanual_2_2_5 Group’s *parse.rules* File + +The test group may contain *parse.rules* file. +This file defines patterns used for analysis of the test execution log +and deciding the status of the test run. +Each line in the file should specify a status (single word), +followed by a regular expression delimited by slashes (*/*) +that will be matched against lines in the test output log to check if it corresponds to this status. +The regular expressions support subset of the Perl re syntax. +The rest of the line can contain a comment message +which will be added to the test report when this status is detected. +Example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + FAILED /\b[Ee]xception\b/ exception + FAILED /\bError\b/ error + SKIPPED /Cannot open file for reading/ data file is missing + SKIPPED /Could not read file .*, abandon/ data file is missing +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Lines starting with a *#* character and blank lines are ignored to allow comments and spacing. +See Interpretation of test results chapter for details. + +If a line matches several rules, the first one applies. +Rules defined in the grid are checked first, then rules in group, +then rules in the test root directory. This allows defining some rules on the grid level +with status IGNORE to ignore messages that would otherwise be treated as errors due to the group level rules. +Example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + FAILED /\bFaulty\b/ bad shape + IGNORE /^Error [23]d = [\d.-]+/ debug output of blend command + IGNORE /^Tcl Exception: tolerance ang : [\d.-]+/ blend failure +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@subsection testmanual_2_3 Test Grids + +@subsubsection testmanual_2_3_1 Grid Names + +Group folder can have several sub-directories (Grid 1… Grid N) defining test grids. +Each test grid directory contains a set of related test cases. +The name of directory should correspond to its contents. + +Example: + +caf + basic + bugs + presentation + +Where **caf** is the name of test group and *basic*, *bugs*, *presentation*, etc are the names of grids. + +@subsubsection testmanual_2_3_2 Grid’s *begin* File + +The file *begin* is a TCL script. It is executed before every test in current grid. +Usually it sets variables specific for the current grid. +Example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + set command bopfuse ;# command tested in this grid +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@subsubsection testmanual_2_3_3 Grid’s *end* File + +The file *end* is a TCL script. It is executed after every test in current grid. +Usually it executes specific sequence of commands common for all tests in the grid. +Example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + vdump $logdir/${casename}.gif ;# makes a snap-shot of AIS viewer +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@subsubsection testmanual_2_3_4 Grid’s *cases.list* File + +The grid directory can contain an optional file cases.list +defining alternative location of the test cases. +This file should contain singe line defining the relative path to collection of test cases. + +Example: + +../data/simple + +This option is used for creation of several grids of tests with the same data files +and operations but performed with differing parameters. +The common scripts are usually located place in common +subdirectory of the test group (data/simple as in example). +If cases.list file exists then grid directory should not contain any test cases. +The specific parameters and pre- and post-processing commands +for the tests execution in this grid should be defined in the begin and end files. + +@subsection testmanual_2_4 Test Cases + +The test case is TCL script which performs some operations using DRAW commands +and produces meaningful messages that can be used to check the result for being valid. +Example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + pcylinder c1 10 20 ;# create first cylinder + pcylinder c2 5 20 ;# create second cylinder + ttranslate c2 5 0 10 ;# translate second cylinder to x,y,z + bsection result c1 c2 ;# create a section of two cylinders + checksection result ;# will output error message if result is bad +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The test case can have any name (except reserved names begin, end, data, cases.list, parse.rules). +For systematic grids it is usually a capital English letter followed by a number. + +Example: + +@verbatim + A1 + A2 + B1 + B2 +@endverbatim + +Such naming facilitates compact representation of results +of tests execution in tabular format within HTML reports. + +@subsection testmanual_2_5 Directory *data* + +The test group may contain subdirectory data. +Usually it contains data files used in tests (BREP, IGES, STEP, etc.) +and / or test scripts shared by different test grids +(in subdirectories, see Grid’s *cases.list* file chapter). + +@section testmanual_3 Creation And Modification Of Tests + +This section describes how to add new tests and update existing ones. + +@subsection testmanual_3_1 Choosing Group, Grid, and Test Case Name + +The new tests are usually added in context of processing some bugs. +Such tests in general should be added to group bugs, in the grid +corresponding to the affected OCCT functionality. +New grids can be added as necessary to contain tests on functionality not yet covered by existing test grids. +The test case name in the bugs group should be prefixed by ID +of the corresponding issue in Mantis (without leading zeroes). +It is recommended to add a suffix providing a hint on the situation being tested. +If more than one test is added for a bug, they should be distinguished by suffixes; +either meaningful or just ordinal numbers. + +Example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + 12345_coaxial + 12345_orthogonal_1 + 12345_orthogonal_2 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In the case if new test corresponds to functionality for which +specific group of tests exists (e.g. group mesh for BRepMesh issues), +this test can be added (or moved later by OCC team) to this group. + +@subsection testmanual_3_2 Adding Data Files Required for a Test + +It is advisable that tests scripts should be made self-contained whenever possible, +so as to be usable in environments where data files are not available. +For that simple geometric objects and shapes can be created using DRAW commands in the test script itself. +If test requires some data file, it should be put to subdirectory data of the test grid. +Note that when test is integrated to master branch, +OCC team can move data file to data files repository, +so as to keep OCCT sources repository clean from big data files. +When preparing a test script, try to minimize size of involved data model. +For instance, if problem detected on a big shape can be reproduced on a single face +extracted from that shape, use only this face in the test. + +@subsection testmanual_3_3 Implementation of the Script + +Test should run commands necessary to perform the operations being tested, +in a clean DRAW session. This includes loading necessary functionality by *pload* command, +if this is not done by *begin* script. The messages produced by commands in standard output +should include identifiable messages on the discovered problems if any. +Usually the script represents a set of commands that a person would run interactively +to perform the operation and see its results, with additional comments to explain what happens. +Example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + # Simple test of fusing box and sphere + box b 10 10 10 + sphere s 5 + bfuse result b s + checkshape result +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Make sure that file parse.rules in the grid or group directory contains +regular expression to catch possible messages indicating failure of the test. +For instance, for catching errors reported by *checkshape* command +relevant grids define a rule to recognize its report by the word *Faulty*: FAILED /\bFaulty\b/ bad shape +For the messages generated in the script the most natural way is to use the word *Error* in the message. +Example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + set expected_length 11 + if { [expr $actual_length - $expected_length] > 0.001 } { + puts *Error: The length of the edge should be $expected_length* + } +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +At the end, the test script should output *TEST COMPLETED* string +to mark successful completion of the script. +This is often done by the end script in the grid. +When test script requires data file, use Tcl procedure *locate_data_file* +to get path to the data file, rather than explicit path. +This will allow easy move of the data file from OCCT repository +to the data files repository without a need to update test script. +Example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + stepread [locate_data_file CAROSKI_COUPELLE.step] a * +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +When test needs to produce some snapshots or other artifacts, +use Tcl variable logdir as location where such files should be put. +Command *testgrid* sets this variable to the subdirectory of the results folder +corresponding to the grid. Command *test* sets it to $CASROOT/tmp unless it is already defined. +Use Tcl variable casename to prefix all the files produced by the test. +This variable is set to the name of the test case. +Example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + xwd $logdir/${casename}.gif + vdisplay result; vfit + vdump $logdir/${casename}-axo.gif + vfront; vfit + vdump $logdir/${casename}-front.gif +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +could produce: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + A1.gif + A1-axo.gif + A1-front.gif +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@subsection testmanual_3_4 Interpretation of Test Results + +The result of the test is evaluated by checking its output against patterns +defined in the files parse.rules of the grid and group. +The OCCT test system recognizes five statuses of the test execution: + + * SKIPPED: reported if line matching SKIPPED pattern is found (prior to any FAILED pattern). This indicates that the test cannot be run in the current environment; most typical case is absence of the required data file. + * FAILED: reported if some line matching pattern with status FAILED is found (unless it is masked by preceding IGNORE pattern or a TODO statement, see below), or if message TEST COMPLETED is not found at the end. This indicates that test produces bad or unexpected result, and usually highlights a regression. + * BAD: reported if test script output contains one or several TODO statements and corresponding number of matching lines in the log. This indicates a known problem (see 3.5). The lines matching TODO statements are not checked against other patterns and thus will not cause a FAILED status. + * IMPROVEMENT: reported if test script output contains TODO statement for which no corresponding line is found. This is possible indication of improvement (known problem disappeared). + * OK: If none of the above statuses have been assigned. This means test passed without problems. + +Other statuses can be specified in the parse.rules files, these will be classified as FAILED. +Before integration of the change to OCCT repository, all tests should return either OK or BAD status. +The new test created for unsolved problem should return BAD. +The new test created for a fixed problem should return FAILED without the fix, and OK with the fix. + +@subsection testmanual_3_5 Marking BAD Cases + +If the test produces invalid result at a certain moment then the corresponding bug +should be created in the OCCT issue tracker [3], and the problem should be marked as TODO in the test script. +The following statement should be added to such test script: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + puts *TODO BugNumber ListOfPlatforms: RegularExpression* +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +where: + + * BugNumber is an ID of the bug in the tracker. For example: #12345 + * ListOfPlatform is a list of platforms at which the bug is reproduced (e.g. Mandriva2008, Windows or All). + +*Note: the platform name is custom for the OCCT test system;* +*it can be consulted as value of environment variable os_type defined in DRAW.* + +Example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + Draw[2]> puts $env(os_type) + windows +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + + * RegularExpression is a regular expression which should be matched against the line indicating the problem in the script output. +Example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + puts *TODO #22622 Mandriva2008: Abort .* an exception was raised* +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Parser checks the output of the test and if an output line matches +the RegularExpression then it will be assigned a BAD status instead of FAILED. +For each output line matching to an error expression a separate TODO line +must be added to mark the test as BAD. +If not all the TODO statements are found in the test log, +the test will be considered as possible improvement. +To mark the test as BAD for an incomplete case +(when final TEST COMPLETE message is missing) +the expression *TEST INCOMPLETE* should be used instead of regular expression. + +Example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + puts *TODO OCC22817 All: exception.+There are no suitable edges* + puts *TODO OCC22817 All: \\*\\* Exception \\*\\** + puts *TODO OCC22817 All: TEST INCOMPLETE* +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@section testmanual_4 Extended Use + +@subsection testmanual_4_1 Running Tests on Older Versions of OCCT + +Sometimes it might be necessary to run tests on previous versions of OCCT (up to to 6.5.3) +that do not include this test system. This can be done by adding DRAW configuration file DrawAppliInit +in the directory which is current by the moment of DRAW startup, +to load test commands and define necessary environment. Example +(assume that d:/occt contains up-to-date version of OCCT sources +with tests, and test data archive is unpacked to d:/test-data): + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + set env(CASROOT) d:/occt + set env(CSF_TestScriptsPath) $env(CASROOT)/tests + source $env(CASROOT)/src/DrawResources/TestCommands.tcl + set env(CSF_TestDataPath) d:/test-data + return +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Note that on older versions of OCCT the tests are run in compatibility mode +and not all output of the test command can be captured; +this can lead to absence of some error messages (can be reported as improvement). + +@subsection testmanual_4_2 Adding Custom Tests + +You can extend the test system by adding your own tests. +For that it is necessary to add paths to the directory where these tests are located, +and additional data directory(ies), to the environment variables CSF_TestScriptsPath and CSF_TestDataPath. +The recommended way for doing this is using DRAW configuration file DrawAppliInit +located in the directory which is current by the moment of DRAW startup. + +Use Tcl command *_path_separator* to insert platform-dependent separator to the path list. +Example: +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + set env(CSF_TestScriptsPath) \ + $env(TestScriptsPath)[_path_separator]d:/MyOCCTProject/tests + set env(CSF_TestDataPath) \ + d:/occt/test-data[_path_separator]d:/MyOCCTProject/tests + return ;# this is to avoid an echo of the last command above in cout +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@section testmanual_5 References + +-# DRAW Test Harness User’s Guide +-# Perl regular expressions, http://perldoc.perl.org/perlre.html +-# OCCT MantisBT issue tracker, http://tracker.dev.opencascade.org diff --git a/dox/dev_guides/wok/images/wok_image001.jpg b/dox/dev_guides/wok/images/wok_image001.jpg new file mode 100644 index 0000000000..37fd7350d4 Binary files /dev/null and b/dox/dev_guides/wok/images/wok_image001.jpg differ diff --git a/dox/dev_guides/wok/images/wok_image002.jpg b/dox/dev_guides/wok/images/wok_image002.jpg new file mode 100644 index 0000000000..b805c9b218 Binary files /dev/null and b/dox/dev_guides/wok/images/wok_image002.jpg differ diff --git a/dox/dev_guides/wok/images/wok_image003.jpg b/dox/dev_guides/wok/images/wok_image003.jpg new file mode 100644 index 0000000000..bc3844af55 Binary files /dev/null and b/dox/dev_guides/wok/images/wok_image003.jpg differ diff --git a/dox/dev_guides/wok/images/wok_image004.jpg b/dox/dev_guides/wok/images/wok_image004.jpg new file mode 100644 index 0000000000..260d032425 Binary files /dev/null and b/dox/dev_guides/wok/images/wok_image004.jpg differ diff --git a/dox/dev_guides/wok/wok.md b/dox/dev_guides/wok/wok.md new file mode 100644 index 0000000000..808868d930 --- /dev/null +++ b/dox/dev_guides/wok/wok.md @@ -0,0 +1,153 @@ +WOK {#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. + +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: + + ![](/devs_guide/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: + + ![](/devs_guide/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 . + + * Perform the following commands assuming that you have unpacked WOK distributive archive into : + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + cd /site + wok_confgui.sh + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + Define all necessary paths to third-party products in the dialog window: + + ![](/devs_guide/wok/images/wok_image003.jpg "") + + * Run the following commands to create WOK LOC factory: + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + cd /site + wok_init.sh + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + * Your installation procedure is over. To run WOK use one the following commands: + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + cd /site + wok_emacs.sh + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + or + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + cd /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. . + + * Browse in the Finder to the folder /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: + + ![](/devs_guide/wok/images/wok_image004.jpg "") + + * Run the following commands to create WOK LOC factory: + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl} + cd /site + wok_init.sh + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + * Your installation procedure is over. To run WOK in Emacs navigate in the Finder to the folder /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 Users 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= ] [ -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/ /cbp + * for cmake - $CASROOT/adm/cmake + * for amk - $CASROOT/adm/lin/amk + * xcd - $CASROOT/adm//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 diff --git a/dox/occdoc.tcl b/dox/occdoc.tcl new file mode 100644 index 0000000000..2d493f8437 --- /dev/null +++ b/dox/occdoc.tcl @@ -0,0 +1,690 @@ +# ----------------------------------------------------------------------- +# Script name: CompileDocs.tcl +# This script compiles OCCT documents from *.md files to HTML pages +# Author: omy +# ----------------------------------------------------------------------- + +# Generates Doxygen configuration file for Overview documentation +proc OverviewDoc_MakeDoxyfile {casDir outDir tagFileDir {doxyFileName} {generatorMode ""} DocFilesList verboseMode} { + + if {$verboseMode == "YES"} { + puts "INFO: Doxygen is now generating Doxyfile..." + } + + set doxyFile [open $doxyFileName "w"] + set casroot $casDir + set inputDir $casDir/dox + + # Common configs + puts $doxyFile "DOXYFILE_ENCODING = UTF-8" + puts $doxyFile "PROJECT_NAME = \"Open CASCADE Technology\"" + puts $doxyFile "PROJECT_NUMBER = 6.6.0" + puts $doxyFile "PROJECT_BRIEF = " + puts $doxyFile "PROJECT_LOGO = $inputDir/resources/occt_logo.png" + + puts $doxyFile "OUTPUT_DIRECTORY = $outDir" + puts $doxyFile "CREATE_SUBDIRS = NO" + puts $doxyFile "OUTPUT_LANGUAGE = English" + puts $doxyFile "ABBREVIATE_BRIEF = \"The \$name class\" \ + \"The \$name widget\" \ + \"The \$name file\" \ + is \ + provides \ + specifies \ + contains \ + represents \ + a \ + an \ + the" + + puts $doxyFile "FULL_PATH_NAMES = YES" + puts $doxyFile "INHERIT_DOCS = YES" + puts $doxyFile "TAB_SIZE = 4" + puts $doxyFile "MARKDOWN_SUPPORT = YES" + puts $doxyFile "EXTRACT_ALL = YES" + puts $doxyFile "CASE_SENSE_NAMES = NO" + puts $doxyFile "INLINE_INFO = YES" + puts $doxyFile "SORT_MEMBER_DOCS = YES" + puts $doxyFile "WARNINGS = YES" + puts $doxyFile "WARN_IF_UNDOCUMENTED = YES" + puts $doxyFile "WARN_IF_DOC_ERROR = YES" + puts $doxyFile "WARN_NO_PARAMDOC = NO" + puts $doxyFile "WARN_FORMAT = \"\$file:\$line: \$text\"" + puts $doxyFile "INPUT_ENCODING = UTF-8" + puts $doxyFile "FILE_PATTERNS = *.md *.dox " + puts $doxyFile "RECURSIVE = YES" + puts $doxyFile "SOURCE_BROWSER = NO" + puts $doxyFile "INLINE_SOURCES = YES" + puts $doxyFile "COLS_IN_ALPHA_INDEX = 5" + + # Generation options + puts $doxyFile "GENERATE_DOCSET = NO" + puts $doxyFile "GENERATE_HTMLHELP = NO" + puts $doxyFile "GENERATE_CHI = NO" + puts $doxyFile "GENERATE_QHP = NO" + puts $doxyFile "GENERATE_ECLIPSEHELP = NO" + puts $doxyFile "GENERATE_RTF = NO" + puts $doxyFile "GENERATE_MAN = NO" + puts $doxyFile "GENERATE_XML = NO" + puts $doxyFile "GENERATE_DOCBOOK = NO" + puts $doxyFile "GENERATE_AUTOGEN_DEF = NO" + puts $doxyFile "GENERATE_PERLMOD = NO" + + set PARAM_INPUT "INPUT = " + set PARAM_IMAGEPATH "IMAGE_PATH = $inputDir/resources/ " + + foreach docFile $DocFilesList { + set NEW_IMG_PATH [file normalize [file dirname "$inputDir/$docFile"]] + if { [string compare $NEW_IMG_PATH $casroot] != 0 } { + if {[file isdirectory "$NEW_IMG_PATH/images"]} { + append PARAM_IMAGEPATH " " "$NEW_IMG_PATH/images" + } + } + append PARAM_INPUT " " $inputDir/$docFile + } + puts $doxyFile $PARAM_INPUT + puts $doxyFile $PARAM_IMAGEPATH + + if { $generatorMode == "PDF_ONLY"} { + set PARAM_LATEX_EF "LATEX_EXTRA_FILES =" + foreach docFile $DocFilesList { + set NEW_LEF_PATH [file normalize [file dirname "$inputDir/$docFile"]] + if { [string compare $NEW_LEF_PATH $casroot] != 0 } { + append PARAM_LATEX_EF " " "$NEW_LEF_PATH/images" + } + } + puts $doxyFile $PARAM_LATEX_EF + } + + if { $generatorMode == "HTML_ONLY"} { + # Set a reference to a TAGFILE + if { $tagFileDir != "" } { + if {[file exists $tagFileDir/OCCT.tag] == 1} { + set tagPath [OverviewDoc_GetRelPath $tagFileDir $outDir/html] + puts $doxyFile "TAGFILES = $tagFileDir/OCCT.tag=$tagPath/html" + } + } + + # HTML Output + puts $doxyFile "GENERATE_LATEX = NO" + puts $doxyFile "GENERATE_HTML = YES" + puts $doxyFile "HTML_COLORSTYLE_HUE = 220" + puts $doxyFile "HTML_COLORSTYLE_SAT = 100" + puts $doxyFile "HTML_COLORSTYLE_GAMMA = 80" + puts $doxyFile "HTML_TIMESTAMP = YES" + puts $doxyFile "HTML_DYNAMIC_SECTIONS = YES" + puts $doxyFile "HTML_INDEX_NUM_ENTRIES = 100" + puts $doxyFile "DISABLE_INDEX = YES" + puts $doxyFile "GENERATE_TREEVIEW = YES" + puts $doxyFile "ENUM_VALUES_PER_LINE = 8" + puts $doxyFile "TREEVIEW_WIDTH = 250" + puts $doxyFile "EXTERNAL_PAGES = NO" + puts $doxyFile "SEARCHENGINE = YES" + puts $doxyFile "SERVER_BASED_SEARCH = NO" + puts $doxyFile "EXTERNAL_SEARCH = NO" + puts $doxyFile "SEARCHDATA_FILE = searchdata.xml" + puts $doxyFile "SKIP_FUNCTION_MACROS = YES" + # Formula options + puts $doxyFile "FORMULA_FONTSIZE = 12" + puts $doxyFile "FORMULA_TRANSPARENT = YES" + puts $doxyFile "USE_MATHJAX = YES" + puts $doxyFile "MATHJAX_FORMAT = HTML-CSS" + puts $doxyFile "MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest" + + } elseif { $generatorMode == "PDF_ONLY"} { + + puts $doxyFile "GENERATE_HTML = NO" + puts $doxyFile "DISABLE_INDEX = YES" + puts $doxyFile "GENERATE_TREEVIEW = NO" + puts $doxyFile "PREDEFINED = PDF_ONLY" + puts $doxyFile "GENERATE_LATEX = YES" + puts $doxyFile "COMPACT_LATEX = YES" + puts $doxyFile "PDF_HYPERLINKS = YES" + puts $doxyFile "USE_PDFLATEX = YES" + puts $doxyFile "LATEX_BATCHMODE = YES" + puts $doxyFile "LATEX_OUTPUT = latex" + puts $doxyFile "LATEX_CMD_NAME = latex" + puts $doxyFile "MAKEINDEX_CMD_NAME = makeindex" + } + + close $doxyFile +} + +# Returns the relative path between two directories +proc OverviewDoc_GetRelPath {targetFile currentpath} { + set cc [file split [file normalize $currentpath]] + set tt [file split [file normalize $targetFile]] + + if {![string equal [lindex $cc 0] [lindex $tt 0]]} { + # not on *n*x then + return -code error "$targetFile not on same volume as $currentpath" + } + while {[string equal [lindex $cc 0] [lindex $tt 0]] && [llength $cc] > 0} { + # discard matching components from the front + set cc [lreplace $cc 0 0] + set tt [lreplace $tt 0 0] + } + set prefix "" + if {[llength $cc] == 0} { + # just the file name, so targetFile is lower down (or in same place) + set prefix "." + } + # step up the tree + for {set i 0} {$i < [llength $cc]} {incr i} { + append prefix " .." + } + # stick it all together (the eval is to flatten the targetFile list) + return [eval file join $prefix $tt] +} + +# Prints Help message +proc OverviewDoc_PrintHelpMessage {} { + puts "\nUsage : occdoc \[-h\] \[-html\] \[-pdf\] \[-m=\] \[-l=\] \[-v\]" + puts "" + puts " Options are : " + puts " -html : To generate HTML files" + puts " (cannot be used with -pdf)" + puts " -pdf : To generate PDF files" + puts " (cannot be used with -html)" + puts " -m= : Specifies list of documents to generate." + puts " If it is not specified, all files, " + puts " mentioned in FILES.txt are processed." + puts " -l= : Specifies the document caption " + puts " for a single document" + puts " -h : Prints help message" + puts " -v : Specifies the Verbose mode" + puts " (info on all script actions is shown)" +} + +# Parses command line arguments +proc OverviewDoc_ParseArguments {arguments} { + global args_names + global args_values + set args_names {} + array set args_values {} + + foreach arg $arguments { + if {[regexp {^(-)[a-z]+$} $arg] == 1} { + set name [string range $arg 1 [string length $arg]-1] + lappend args_names $name + set args_values($name) "NULL" + continue + } elseif {[regexp {^(-)[a-z]+=.+$} $arg] == 1} { + set equal_symbol_position [string first "=" $arg] + set name [string range $arg 1 $equal_symbol_position-1] + lappend args_names $name + set value [string range $arg $equal_symbol_position+1 [string length $arguments]-1] + + # To parse a list of values for -m parameter + if { [string first "," $value] != -1 } { + set value [split $value ","]; + } + set args_values($name) $value + } else { + puts "Error in argument $arg" + return 1 + } + } + return 0 +} + +# Loads a list of docfiles from file FILES.txt +proc OverviewDoc_LoadFilesList {} { + + set INPUTDIR [file normalize [file dirname [info script]]] + + global available_docfiles + set available_docfiles {} + + # Read data from file + if { [file exists "$INPUTDIR/FILES.txt"] == 1 } { + set FILE [open "$INPUTDIR/FILES.txt" r] + while {1} { + set line [gets $FILE] + if {$line != ""} { + lappend available_docfiles $line + } + + if {[eof $FILE]} { + close $FILE + break + } + } + } else { + return -1 + } + return 0 +} + +# Writes new tex file for conversion from tex to pdf for a specific doc +proc OverviewDoc_MakeRefmanTex {fileName latexDir docLabel verboseMode} { + + if {$verboseMode == "YES"} { + puts "INFO: Making refman.tex file for $fileName" + } + set DOCNAME "$latexDir/refman.tex" + if {[file exists $DOCNAME] == 1} { + file delete -force $DOCNAME + } + set texfile [open $DOCNAME w] + + puts $texfile "\\batchmode" + puts $texfile "\\nonstopmode" + puts $texfile "\\documentclass\[oneside\]{article}" + puts $texfile "\n% Packages required by doxygen" + puts $texfile "\\usepackage{calc}" + puts $texfile "\\usepackage{doxygen}" + puts $texfile "\\usepackage{graphicx}" + puts $texfile "\\usepackage\[utf8\]{inputenc}" + puts $texfile "\\usepackage{makeidx}" + puts $texfile "\\usepackage{multicol}" + puts $texfile "\\usepackage{multirow}" + puts $texfile "\\usepackage{textcomp}" + puts $texfile "\\usepackage{amsmath}" + puts $texfile "\\usepackage\[table\]{xcolor}" + puts $texfile "\\usepackage{indentfirst}" + puts $texfile "" + puts $texfile "% Font selection" + puts $texfile "\\usepackage\[T1\]{fontenc}" + puts $texfile "\\usepackage{mathptmx}" + puts $texfile "\\usepackage\[scaled=.90\]{helvet}" + puts $texfile "\\usepackage{courier}" + puts $texfile "\\usepackage{amssymb}" + puts $texfile "\\usepackage{sectsty}" + puts $texfile "\\renewcommand{\\familydefault}{\\sfdefault}" + puts $texfile "\\allsectionsfont{%" + puts $texfile " \\fontseries{bc}\\selectfont%" + puts $texfile " \\color{darkgray}%" + puts $texfile "}" + puts $texfile "\\renewcommand{\\DoxyLabelFont}{%" + puts $texfile " \\fontseries{bc}\\selectfont%" + puts $texfile " \\color{darkgray}%" + puts $texfile "}" + puts $texfile "" + puts $texfile "% Page & text layout" + puts $texfile "\\usepackage{geometry}" + puts $texfile "\\geometry{%" + puts $texfile " a4paper,%" + puts $texfile " top=2.5cm,%" + puts $texfile " bottom=2.5cm,%" + puts $texfile " left=2.5cm,%" + puts $texfile " right=2.5cm%" + puts $texfile "}" + puts $texfile "\\tolerance=750" + puts $texfile "\\hfuzz=15pt" + puts $texfile "\\hbadness=750" + puts $texfile "\\setlength{\\emergencystretch}{15pt}" + puts $texfile "\\setlength{\\parindent}{0.75cm}" + puts $texfile "\\setlength{\\parskip}{0.2cm}" + puts $texfile "\\makeatletter" + puts $texfile "\\renewcommand{\\paragraph}{%" + puts $texfile " \@startsection{paragraph}{4}{0ex}{-1.0ex}{1.0ex}{%" + puts $texfile "\\normalfont\\normalsize\\bfseries\\SS@parafont%" + puts $texfile " }%" + puts $texfile "}" + puts $texfile "\\renewcommand{\\subparagraph}{%" + puts $texfile " \\@startsection{subparagraph}{5}{0ex}{-1.0ex}{1.0ex}{%" + puts $texfile "\\normalfont\\normalsize\\bfseries\\SS@subparafont%" + puts $texfile " }%" + puts $texfile "}" + puts $texfile "\\makeatother" + puts $texfile "" + puts $texfile "% Headers & footers" + puts $texfile "\\usepackage{fancyhdr}" + puts $texfile "\\pagestyle{fancyplain}" + puts $texfile "\\fancyhead\[LE\]{\\fancyplain{}{\\bfseries\\thepage}}" + puts $texfile "\\fancyhead\[CE\]{\\fancyplain{}{}}" + puts $texfile "\\fancyhead\[RE\]{\\fancyplain{}{\\bfseries\\leftmark}}" + puts $texfile "\\fancyhead\[LO\]{\\fancyplain{}{\\bfseries\\rightmark}}" + puts $texfile "\\fancyhead\[CO\]{\\fancyplain{}{}}" + 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\[CO\]{\\fancyplain{}{}}" + puts $texfile "\\fancyfoot\[RO\]{\\fancyplain{}{}}" + puts $texfile "\\renewcommand{\\footrulewidth}{0.4pt}" + puts $texfile "\\renewcommand{\\sectionmark}\[1\]{%" + puts $texfile " \\markright{\\thesection\\ #1}%" + puts $texfile "}" + puts $texfile "" + puts $texfile "% Indices & bibliography" + puts $texfile "\\usepackage{natbib}" + puts $texfile "\\usepackage\[titles\]{tocloft}" + puts $texfile "\\renewcommand{\\cftsecleader}{\\cftdotfill{\\cftdotsep}}" + puts $texfile "\\setcounter{tocdepth}{3}" + puts $texfile "\\setcounter{secnumdepth}{5}" + puts $texfile "\\makeindex" + puts $texfile "" + puts $texfile "% Hyperlinks (required, but should be loaded last)" + puts $texfile "\\usepackage{ifpdf}" + puts $texfile "\\ifpdf" + puts $texfile " \\usepackage\[pdftex,pagebackref=true\]{hyperref}" + puts $texfile "\\else" + puts $texfile " \\usepackage\[ps2pdf,pagebackref=true\]{hyperref}" + puts $texfile "\\fi" + puts $texfile "\\hypersetup{%" + puts $texfile " colorlinks=true,%" + puts $texfile " linkcolor=black,%" + puts $texfile " citecolor=black,%" + puts $texfile " urlcolor=blue,%" + puts $texfile " unicode%" + puts $texfile "}" + puts $texfile "" + puts $texfile "% Custom commands" + puts $texfile "\\newcommand{\\clearemptydoublepage}{%" + puts $texfile " \\newpage{\\pagestyle{empty}\\cleardoublepage}%" + puts $texfile "}" + puts $texfile "\n" + puts $texfile "%===== C O N T E N T S =====\n" + puts $texfile "\\begin{document}" + puts $texfile "" + puts $texfile "% Titlepage & ToC" + puts $texfile "\\hypersetup{pageanchor=false}" + puts $texfile "\\pagenumbering{roman}" + 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 "{\\Large Open C\\-A\\-S\\-C\\-A\\-D\\-E Technology \\\\\[1ex\]\\Large 6.\\-6.\\-0 }\\\\" + puts $texfile "\\vspace*{1cm}" + puts $texfile "{\\Large $docLabel}\\\\" + puts $texfile "\\vspace*{1cm}" + puts $texfile "{\\large Generated by Doxygen 1.8.4}\\\\" + puts $texfile "\\vspace*{0.5cm}" + puts $texfile "{\\small \\today}\\" + puts $texfile "\\end{center}" + puts $texfile "\\end{titlepage}" + puts $texfile "\\clearpage" + puts $texfile "\\pagenumbering{roman}" + puts $texfile "\\tableofcontents" + puts $texfile "\\newpage" + puts $texfile "\\pagenumbering{arabic}" + puts $texfile "\\hypersetup{pageanchor=true}" + puts $texfile "" + puts $texfile "\\hypertarget{$fileName}{}" + puts $texfile "\\input{$fileName}" + puts $texfile "" + puts $texfile "% Index" + puts $texfile "\\newpage" + puts $texfile "\\phantomsection" + puts $texfile "\\addcontentsline{toc}{part}{Index}" + puts $texfile "\\printindex\n" + puts $texfile "\\end{document}" + + close $texfile +} + +# Postprocesses generated TeX files +proc OverviewDoc_ProcessTex {{texFiles {}} {latexDir} verboseMode} { + + foreach TEX $texFiles { + if {$verboseMode == "YES"} { + puts "INFO: Preprocessing file $TEX" + } + set IN_F [open "$TEX" r] + set TMPFILENAME "$latexDir/temp.tex" + set OUT_F [open $TMPFILENAME w] + + while {1} { + set line [gets $IN_F] + if { [string first "\\includegraphics" $line] != -1 } { + # Center images in TeX files + set line "\\begin{center}\n $line\n\\end{center}" + } elseif { [string first "\\subsection" $line] != -1 } { + # Replace \subsection with \section tag + regsub -all "\\\\subsection" $line "\\\\section" line + } elseif { [string first "\\subsubsection" $line] != -1 } { + # Replace \subsubsection with \subsection tag + regsub -all "\\\\subsubsection" $line "\\\\subsection" line + } elseif { [string first "\\paragraph" $line] != -1 } { + # Replace \paragraph with \subsubsection tag + regsub -all "\\\\paragraph" $line "\\\\subsubsection" line + } + puts $OUT_F $line + + if {[eof $IN_F]} { + close $IN_F + close $OUT_F + break + } + } + file delete -force $TEX + file rename $TMPFILENAME $TEX + } +} + +# Main procedure for documents compilation +proc OverviewDoc_Main { {docfiles {}} generatorMode docLabel verboseMode} { + + set INDIR [file normalize [file dirname [info script]]] + set CASROOT [file normalize [file dirname "$INDIR/../../"]] + set OUTDIR $CASROOT/doc + set PDFDIR $OUTDIR/overview/pdf + set HTMLDIR $OUTDIR/overview/html + set LATEXDIR $OUTDIR/overview/latex + set TAGFILEDIR $OUTDIR/refman + set DOXYFILE $OUTDIR/OCCT.cfg + + # Create or clean the output folders + if {[file exists $OUTDIR] == 0} { + file mkdir $OUTDIR + } + if {[file exists $HTMLDIR] == 0} { + file mkdir $HTMLDIR + } + if {[file exists $LATEXDIR] == 0} { + file mkdir $LATEXDIR + } + if {[file exists $PDFDIR] == 0} { + file mkdir $PDFDIR + } + + # Run tools to compile documents + puts "" + puts " [clock format [clock seconds] -format {%Y.%m.%d %H:%M}] Generation process started..." + puts "" + puts " Please, wait while Doxygen finishes it\'s work" + OverviewDoc_MakeDoxyfile $CASROOT "$OUTDIR/overview" $TAGFILEDIR $DOXYFILE $generatorMode $docfiles $verboseMode + + # Run doxygen tool + if { $generatorMode == "HTML_ONLY"} { + puts " [clock format [clock seconds] -format {%Y.%m.%d %H:%M}] Doxygen is now generating HTML files...\n" + } + set RESULT [catch {exec doxygen $DOXYFILE > $OUTDIR/doxygen_out.log} DOX_ERROR] + if {$RESULT != 0} { + if {[llength [split $DOX_ERROR "\n"]] > 1} { + if {$verboseMode == "YES"} { + puts "INFO: See Doxygen messages in $OUTDIR/doxygen_warnings_and_errors.log" + } + set DOX_ERROR_FILE [open "$OUTDIR/doxygen_warnings_and_errors.log" "w"] + puts $DOX_ERROR_FILE $DOX_ERROR + close $DOX_ERROR_FILE + } else { + puts $DOX_ERROR + } + } + # Close the Doxygen application + after 300 + + # Start PDF generation routine + if { $generatorMode == "PDF_ONLY" } { + puts "" + puts " [clock format [clock seconds] -format {%Y.%m.%d %H:%M}] Doxygen is now generating PDF files...\n" + + set OS $::tcl_platform(platform) + if { $OS == "unix" } { + set PREFIX ".sh" + } elseif { $OS == "windows" } { + set PREFIX ".bat" + } + + # Prepare a list of TeX files, generated by Doxygen + 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 TEXFILES [lreplace $TEXFILES $IDX $IDX] + set IDX [lsearch $TEXFILES "$LATEXDIR"] + } + + # Preprocess generated TeX files + OverviewDoc_ProcessTex $TEXFILES $LATEXDIR $verboseMode + + # Generate PDF files from + foreach TEX $TEXFILES { + # Rewrite existing REFMAN.tex file... + set TEX [string range $TEX 0 [ expr "[string length $TEX] - 5"]] + OverviewDoc_MakeRefmanTex $TEX $LATEXDIR $docLabel $verboseMode + + if {$verboseMode == "YES"} { + puts "INFO: Generating PDF file from $TEX" + } + # ...and use it to generate PDF from TeX... + 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} { + set LaTeX_ERROR_FILE [open "$OUTDIR/pdflatex_warnings_and_errors.log" "w"] + puts $LaTeX_ERROR_FILE $LaTeX_ERROR + close $LaTeX_ERROR_FILE + } else { + puts $DOX_ERROR + } + } + + # ...and place it to the specific folder + if { [file exists $PDFDIR/$TEX.pdf] == 1 } { + file delete -force $PDFDIR/$TEX.pdf + } + file rename $LATEXDIR/refman.pdf "$PDFDIR/$TEX.pdf" + } + if {$verboseMode == "YES"} { + puts "INFO: See LaTeX messages in $OUTDIR/pdflatex_warnings_and_errors.log" + } + } + + cd $INDIR + puts " [clock format [clock seconds] -format {%Y.%m.%d %H:%M}] Generation process finished..." + puts "" + puts "--------------------------------------------------------------------" + if { $generatorMode == "HTML_ONLY" } { + puts " You can look at generated HTML pages by opening: " + set RESFILE $OUTDIR/overview/html/index.html + puts " $RESFILE" + } + if { $generatorMode == "PDF_ONLY" } { + puts " You can look at generated PDF files in: " + puts " $OUTDIR/overview/pdf folder" + } + puts "" + puts " Copyright \u00a9 Open CASCADE Technology 2001-2013" + puts "--------------------------------------------------------------------\n" +} + +# A command for User Documentation compilation +proc occdoc {args} { + # Programm options + set GEN_HTML "NO" + set GEN_PDF "NO" + set DOCFILES {} + set DOCLABEL "Default OCCT Document" + set VERB_MODE "NO" + set GEN_MODE "DEFAULT" + global available_docfiles + global args_names + global args_values + + # Load list of docfiles + if { [OverviewDoc_LoadFilesList] != 0 } { + puts "ERROR: File FILES.txt was not found" + return + } + + # Parse CL arguments + if {[OverviewDoc_ParseArguments $args] == 1} { + return + } + if {$args_names == {}} { + set GEN_HTML "YES" + set VERB_MODE "YES" + } else { + foreach arg_n $args_names { + if {$arg_n == "h"} { + OverviewDoc_PrintHelpMessage + return + } elseif {$arg_n == "html"} { + set GEN_HTML "YES" + } elseif {$arg_n == "pdf"} { + set GEN_PDF "YES" + } elseif {$arg_n == "v"} { + set VERB_MODE "YES" + } elseif {$arg_n == "m"} { + if {$args_values(m) != "NULL"} { + set DOCFILES $args_values(m) + } else { + puts "Error in argument m" + return + } + # Check if all chosen docfiles are correct + foreach docfile $DOCFILES { + if { [lsearch $available_docfiles $docfile] == -1 } { + puts "File \"$docfile\" is not presented in the list of available docfiles" + puts "Please, specify the correct docfile name" + return + } else { + puts "File $docfile is presented in FILES.TXT" + } + } + } elseif {$arg_n == "l"} { + if { [llength $DOCFILES] <= 1 } { + if {$args_values(l) != "NULL"} { + set DOCLABEL $args_values(l) + } else { + puts "Error in argument l" + return + } + } + } else { + puts "\nWrong argument: $arg_n" + OverviewDoc_PrintHelpMessage + return + } + } + } + + # Specify generation mode + if {$GEN_HTML == "YES" && $GEN_PDF == "NO"} { + set GEN_MODE "HTML_ONLY" + } elseif {$GEN_PDF == "YES"} { + set GEN_MODE "PDF_ONLY" + } + # Check if -v is the only option + if {$GEN_MODE == "DEFAULT"} { + if { $VERB_MODE == "YES" } { + puts "\nArgument -v can't be used without -pdf or -html argument" + OverviewDoc_PrintHelpMessage + } + return + } + + # Specify verbose mode + if { $GEN_PDF != "YES" && [llength $DOCFILES] > 1 } { + set DOCLABEL "" + } + + # If we don't specify list for docfiles with -m argument, + # we assume that we have to generate all docfiles + if { [llength $DOCFILES] == 0 } { + set DOCFILES $available_docfiles + } + + # Start main activities + OverviewDoc_Main $DOCFILES $GEN_MODE $DOCLABEL $VERB_MODE +} diff --git a/dox/overview/images/overview_c__ie.png b/dox/overview/images/overview_c__ie.png new file mode 100644 index 0000000000..3cfc12e82c Binary files /dev/null and b/dox/overview/images/overview_c__ie.png differ diff --git a/dox/overview/images/overview_draw.png b/dox/overview/images/overview_draw.png new file mode 100644 index 0000000000..27cd5cda1d Binary files /dev/null and b/dox/overview/images/overview_draw.png differ diff --git a/dox/overview/images/overview_installation.png b/dox/overview/images/overview_installation.png new file mode 100644 index 0000000000..cd01944f41 Binary files /dev/null and b/dox/overview/images/overview_installation.png differ diff --git a/dox/overview/images/overview_mvc.png b/dox/overview/images/overview_mvc.png new file mode 100644 index 0000000000..f4104834e6 Binary files /dev/null and b/dox/overview/images/overview_mvc.png differ diff --git a/dox/overview/images/overview_occttransparent.png b/dox/overview/images/overview_occttransparent.png new file mode 100644 index 0000000000..ce18b6e0ed Binary files /dev/null and b/dox/overview/images/overview_occttransparent.png differ diff --git a/dox/overview/images/overview_qt.png b/dox/overview/images/overview_qt.png new file mode 100644 index 0000000000..e4c688585c Binary files /dev/null and b/dox/overview/images/overview_qt.png differ diff --git a/dox/overview/tutorial/images/tutorial_image001.png b/dox/overview/tutorial/images/tutorial_image001.png new file mode 100644 index 0000000000..5fd0189eac Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image001.png differ diff --git a/dox/overview/tutorial/images/tutorial_image002.png b/dox/overview/tutorial/images/tutorial_image002.png new file mode 100644 index 0000000000..801c5eaa2f Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image002.png differ diff --git a/dox/overview/tutorial/images/tutorial_image003.png b/dox/overview/tutorial/images/tutorial_image003.png new file mode 100644 index 0000000000..b08eeb88be Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image003.png differ diff --git a/dox/overview/tutorial/images/tutorial_image004.png b/dox/overview/tutorial/images/tutorial_image004.png new file mode 100644 index 0000000000..b10ce22b3c Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image004.png differ diff --git a/dox/overview/tutorial/images/tutorial_image005.png b/dox/overview/tutorial/images/tutorial_image005.png new file mode 100644 index 0000000000..bfbe42cc08 Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image005.png differ diff --git a/dox/overview/tutorial/images/tutorial_image006.png b/dox/overview/tutorial/images/tutorial_image006.png new file mode 100644 index 0000000000..d5a119fcb1 Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image006.png differ diff --git a/dox/overview/tutorial/images/tutorial_image007.png b/dox/overview/tutorial/images/tutorial_image007.png new file mode 100644 index 0000000000..1391895b4f Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image007.png differ diff --git a/dox/overview/tutorial/images/tutorial_image008.png b/dox/overview/tutorial/images/tutorial_image008.png new file mode 100644 index 0000000000..85efc0e311 Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image008.png differ diff --git a/dox/overview/tutorial/images/tutorial_image009.png b/dox/overview/tutorial/images/tutorial_image009.png new file mode 100644 index 0000000000..3fb60f5ff0 Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image009.png differ diff --git a/dox/overview/tutorial/images/tutorial_image010.png b/dox/overview/tutorial/images/tutorial_image010.png new file mode 100644 index 0000000000..899e224749 Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image010.png differ diff --git a/dox/overview/tutorial/images/tutorial_image011.png b/dox/overview/tutorial/images/tutorial_image011.png new file mode 100644 index 0000000000..741a6714ac Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image011.png differ diff --git a/dox/overview/tutorial/images/tutorial_image012.png b/dox/overview/tutorial/images/tutorial_image012.png new file mode 100644 index 0000000000..4d68528a0d Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image012.png differ diff --git a/dox/overview/tutorial/images/tutorial_image013.png b/dox/overview/tutorial/images/tutorial_image013.png new file mode 100644 index 0000000000..af84d793de Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image013.png differ diff --git a/dox/overview/tutorial/images/tutorial_image014.png b/dox/overview/tutorial/images/tutorial_image014.png new file mode 100644 index 0000000000..f9635174f9 Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image014.png differ diff --git a/dox/overview/tutorial/images/tutorial_image015.png b/dox/overview/tutorial/images/tutorial_image015.png new file mode 100644 index 0000000000..5dc55b9974 Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image015.png differ diff --git a/dox/overview/tutorial/images/tutorial_image016.png b/dox/overview/tutorial/images/tutorial_image016.png new file mode 100644 index 0000000000..8ea559a9a6 Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image016.png differ diff --git a/dox/overview/tutorial/images/tutorial_image017.png b/dox/overview/tutorial/images/tutorial_image017.png new file mode 100644 index 0000000000..5beaf94eda Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image017.png differ diff --git a/dox/overview/tutorial/images/tutorial_image018.png b/dox/overview/tutorial/images/tutorial_image018.png new file mode 100644 index 0000000000..0ac10c975a Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image018.png differ diff --git a/dox/overview/tutorial/images/tutorial_image019.png b/dox/overview/tutorial/images/tutorial_image019.png new file mode 100644 index 0000000000..c5e2eedf21 Binary files /dev/null and b/dox/overview/tutorial/images/tutorial_image019.png differ diff --git a/dox/overview/tutorial/tutorial.md b/dox/overview/tutorial/tutorial.md new file mode 100644 index 0000000000..ea2a9cf3a3 --- /dev/null +++ b/dox/overview/tutorial/tutorial.md @@ -0,0 +1,843 @@ + Tutorial {#overview__tutorial} +======= + +@section sec1 Overview + + +This tutorial will teach you how to use Open CASCADE Technology services to model a 3D object. The purpose of this tutorial is not to describe all Open CASCADE Technology classes but to help you start thinking in terms of Open CASCADE Technology as a tool. + + +@subsection OCCT_TUTORIAL_SUB1_1 Prerequisites + +This tutorial assumes that you have experience in using and setting up C++. +From a programming standpoint, Open CASCADE Technology is designed to enhance your C++ tools with 3D modeling classes, methods and functions. The combination of all these resources will allow you to create substantial applications. + +@subsection OCCT_TUTORIAL_SUB1_2 The Model + +To illustrate the use of classes provided in the 3D geometric modeling toolkits, you will create a bottle as shown: + +![](/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. + +@subsection OCCT_TUTORIAL_SUB1_3 Model Specifications + +We first define the bottle specifications as follows: + +| Object Parameter | Parameter Name | Parameter Value | +| :--------------: | :------------: | :-------------: | +| Bottle height | MyHeight | 70mm | +| Bottle width | MyWidth | 50mm | +| Bottle thickness | MyThickness | 30mm | + +In addition, we decide that the bottle's profile (base) will be centered on the origin of the global Cartesian coordinate system. + +![](/overview/tutorial/images/tutorial_image002.png "") + +This modeling requires four steps: + + * build the bottle's Profile + * build the bottle's Body + * build the Threading on the bottle's neck + * build the result compound + + +@section sec2 Building the Profile + +@subsection OCCT_TUTORIAL_SUB2_1 Defining Support Points + +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. + +![](/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: + + * the primitive geometric *gp_Pnt* class + * the transient *Geom_CartesianPoint* class manipulated by handle + +A handle is a type of smart pointer that provides automatic memory management. +To choose the best class for this application, consider the following: + + * *gp_Pnt* is manipulated by value. Like all objects of its kind, it will have a limited lifetime. + * *Geom_CartesianPoint* is manipulated by handle and may have multiple references and a long lifetime. + +Since all the points you will define are only used to create the profile's curves, an object with a limited lifetime will do. Choose the *gp_Pnt* class. +To instantiate a *gp_Pnt* object, just specify the X, Y, and Z coordinates of the points in the global cartesian coordinate system: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + gp_Pnt aPnt1(-myWidth / 2., 0, 0); + gp_Pnt aPnt2(-myWidth / 2., -myThickness / 4., 0); + gp_Pnt aPnt3(0, -myThickness / 2., 0); + gp_Pnt aPnt4(myWidth / 2., -myThickness / 4., 0); + gp_Pnt aPnt5(myWidth / 2., 0, 0); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Once your objects are instantiated, you can use methods provided by the class to access and modify its data. For example, to get the X coordinate of a point: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +Standard_Real xValue1 = aPnt1.X(); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@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. + +![](/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*). +However, the *Geom* package provides only the data structure of geometric entities. You can directly instantiate classes belonging to *Geom*, but it is easier to compute elementary curves and surfaces by using the *GC* package. +This is because the *GC* provides two algorithm classes which are exactly what is required for our profile: + + * Class *GC_MakeSegment* to create a segment. One of its constructors allows you to define a segment by two end points P1 and P2 + * Class *GC_MakeArcOfCircle* to create an arc of a circle. A useful constructor creates an arc from two end points P1 and P3 and going through P2. + +Both of these classes return a *Geom_TrimmedCurve* manipulated by handle. This entity represents a base curve (line or circle, in our case), limited between two of its parameter values. For example, circle C is parameterized between 0 and 2PI. If you need to create a quarter of a circle, you create a *Geom_TrimmedCurve* on C limited between 0 and M_PI/2. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + Handle(Geom_TrimmedCurve) aArcOfCircle = GC_MakeArcOfCircle(aPnt2,aPnt3,aPnt4); + Handle(Geom_TrimmedCurve) aSegment1 = GC_MakeSegment(aPnt1, aPnt2); + Handle(Geom_TrimmedCurve) aSegment2 = GC_MakeSegment(aPnt4, aPnt5); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +All *GC* classes provide a casting method to obtain a result automatically with a function-like call. Note that this method will raise an exception if construction has failed. To handle possible errors more explicitly, you may use the *IsDone* and *Value* methods. For example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + GC_MakeSegment mkSeg (aPnt1, aPnt2); + Handle(Geom_TrimmedCurve) aSegment1; + if(mkSegment.IsDone()){ + aSegment1 = mkSeg.Value(); + } + else { + // handle error + } +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +@subsection OCCT_TUTORIAL_SUB2_3 Profile: Defining the Topology + + +You have created the support geometry of one part of the profile but these curves are independent with no relations between each other. +To simplify the modeling, it would be right to manipulate these three curves as a single entity. +This can be done by using the topological data structure of Open CASCADE Technology defined in the *TopoDS* package: it defines relationships between geometric entities which can be linked together to represent complex shapes. +Each object of the *TopoDS* package, inheriting from the *TopoDS_Shape* class, describes a topological shape as described below: + +| Shape | Open CASCADE Technology Class | Description | +| :-------- | :---------------------------- | :------------------------------------------------------------ | +| Vertex | TopoDS_Vertex | Zero dimensional shape corresponding to a point in geometry. | +| Edge | TopoDS_Edge | One-dimensional shape corresponding to a curve and bounded by a vertex at each extremity.| +| Wire | TopoDS_Wire | Sequence of edges connected by vertices. | +| Face | TopoDS_Face | Part of a surface bounded by a closed wire(s). | +| Shell | TopoDS_Shell | Set of faces connected by edges. | +| Solid | TopoDS_Solid | Part of 3D space bounded by Shells. | +| CompSolid | TopoDS_CompSolid | Set of solids connected by their faces. | +| Compound | TopoDS_Compound | Set of any other shapes described above. | + +Referring to the previous table, to build the profile, you will create: + + * Three edges out of the previously computed curves. + * One wire with these edges. + +![](/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: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + TopoDS_Edge aEdge1 = BRepBuilderAPI_MakeEdge(aSegment1); + TopoDS_Edge aEdge2 = BRepBuilderAPI_MakeEdge(aArcOfCircle); + TopoDS_Edge aEdge3 = BRepBuilderAPI_MakeEdge(aSegment2); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In Open CASCADE Technology, you can create edges in several ways. One possibility is to create an edge directly from two points, in which case the underlying geometry of this edge is a line, bounded by two vertices being automatically computed from the two input points. For example, aEdge1 and aEdge3 could have been computed in a simpler way: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + TopoDS_Edge aEdge1 = BRepBuilderAPI_MakeEdge(aPnt1, aPnt3); + TopoDS_Edge aEdge2 = BRepBuilderAPI_MakeEdge(aPnt4, aPnt5); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To connect the edges, you need to create a wire with the *BRepBuilderAPI_MakeWire* class. There are two ways of building a wire with this class: + + * directly from one to four edges + * by adding other wire(s) or edge(s) to an existing wire (this is explained later in this tutorial) + +When building a wire from less than four edges, as in the present case, you can use the constructor directly as follows: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + TopoDS_Wire aWire = BRepBuilderAPI_MakeWire(aEdge1, aEdge2, aEdge3); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +@subsection OCCT_TUTORIAL_SUB2_4 Profile: Completing the Profile + + +Once the first part of your wire is created you need to compute the complete profile. A simple way to do this is to: + + * compute a new wire by reflecting the existing one. + * add the reflected wire to the initial one. + +![](/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. +The first way is to define it from scratch, using its geometric definition: + + * X axis is located at (0, 0, 0) - use the *gp_Pnt* class. + * X axis direction is (1, 0, 0) - use the *gp_Dir* class. A *gp_Dir* instance is created out of its X, Y and Z coordinates. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + gp_Pnt aOrigin(0, 0, 0); + gp_Dir xDir(1, 0, 0); + gp_Ax1 xAxis(aOrigin, xDir); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The second and simplest way is to use the geometric constants defined in the gp package (origin, main directions and axis of the global coordinate system). To get the X axis, just call the *gp::OX* method: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + gp_Ax1 xAxis = gp::OX(); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +As previously explained, the 3D geometric transformation is defined with the *gp_Trsf* class. There are two different ways to use this class: + + * by defining a transformation matrix by all its values + * by using the appropriate methods corresponding to the required transformation (SetTranslation for a translation, SetMirror for a reflection, etc.): the matrix is automatically computed. + +Since the simplest approach is always the best one, you should use the SetMirror method with the axis as the center of symmetry. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + gp_Trsf aTrsf; + aTrsf.SetMirror(xAxis); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You now have all necessary data to apply the transformation with the BRepBuilderAPI_Transform class by specifying: + + * the shape on which the transformation must be applied. + * the geometric transformation + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + BRepBuilderAPI_Transform aBRepTrsf(aWire, aTrsf); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +*BRepBuilderAPI_Transform* does not modify the nature of the shape: the result of the reflected wire remains a wire. But the function-like call or the *BRepBuilderAPI_Transform::Shape* method returns a *TopoDS_Shape* object: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + TopoDS_Shape aMirroredShape = aBRepTrsf.Shape(); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +What you need is a method to consider the resulting reflected shape as a wire. The *TopoDS* global functions provide this kind of service by casting a shape into its real type. To cast the transformed wire, use the *TopoDS::Wire* method. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + TopoDS_Wire aMirroredWire = TopoDS::Wire(aMirroredShape); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The bottle's profile is almost finished. You have created two wires: *aWire* and *aMirroredWire*. You need to concatenate them to compute a single shape. To do this, you use the *BRepBuilderAPI_MakeWire* class as follows: + + * create an instance of *BRepBuilderAPI_MakeWire*. + * add all edges of the two wires by using the *Add* method on this object. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + BRepBuilderAPI_MakeWire mkWire; + mkWire.Add(aWire); + mkWire.Add(aMirroredWire); + TopoDS_Wire myWireProfile = mkWire.Wire(); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +@section sec3 Building the Body + + +@subsection OCCT_TUTORIAL_SUB3_1 Prism the Profile + + +To compute the main body of the bottle, you need to create a solid shape. The simplest way is to use the previously created profile and to sweep it along a direction. The *Prism* functionality of Open CASCADE Technology is the most appropriate for that task. It accepts a shape and a direction as input and generates a new shape according to the following rules: + +| Shape | Generates | +| :----- | :----------------- | +| Vertex | Edge | +| Edge | Face | +| Wire | Shell | +| Face | Solid | +| Shell | Compound of Solids | + +![](/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. +When the wire lies on a plane, the surface is automatically computed. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + TopoDS_Face myFaceProfile = BRepBuilderAPI_MakeFace(myWireProfile); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The *BRepPrimAPI* package provides all the classes to create topological primitive constructions: boxes, cones, cylinders, spheres, etc. Among them is the *BRepPrimAPI_MakePrism* class. As specified above, the prism is defined by: + + * the basis shape to sweep; + * a vector for a finite prism or a direction for finite and infinite prisms. + +You want the solid to be finite, swept along the Z axis and to be myHeight height. The vector, defined with the *gp_Vec* class on its X, Y and Z coordinates, is: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + gp_Vec aPrismVec(0, 0, myHeight); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +All the necessary data to create the main body of your bottle is now available. Just apply the *BRepPrimAPI_MakePrism* class to compute the solid: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + TopoDS_Shape myBody = BRepPrimAPI_MakePrism(myFaceProfile, aPrismVec); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +@subsection OCCT_TUTORIAL_SUB3_2 Applying Fillets + + +The edges of the bottle's body are very sharp. To replace them by rounded faces, you use the *Fillet* functionality of Open CASCADE Technology. +For our purposes, we will specify that fillets must be: + + * applied on all edges of the shape + * have a radius of *myThickness* / 12 + +![](/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: + + * Specify the shape to be filleted in the *BRepFilletAPI_MakeFillet* constructor. + * Add the fillet descriptions (an edge and a radius) using the *Add* method (you can add as many edges as you need). + * Ask for the resulting filleted shape with the *Shape* method. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +BRepFilletAPI_MakeFillet mkFillet(myBody); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To add the fillet description, you need to know the edges belonging to your shape. The best solution is to explore your solid to retrieve its edges. This kind of functionality is provided with the *TopExp_Explorer* class, which explores the data structure described in a *TopoDS_Shape* and extracts the sub-shapes you specifically need. +Generally, this explorer is created by providing the following information: + + * the shape to explore + * the type of sub-shapes to be found. This information is given with the *TopAbs_ShapeEnum* enumeration. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +TopExp_Explorer anEdgeExplorer(myBody, TopAbs_EDGE); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +An explorer is usually applied in a loop by using its three main methods: + + * *More()* to know if there are more sub-shapes to explore. + * *Current()* to know which is the currently explored sub-shape (used only if the *More()* method returns true). + * *Next()* to move onto the next sub-shape to explore. + + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + while(anEdgeExplorer.More()){ + TopoDS_Edge anEdge = TopoDS::Edge(anEdgeExplorer.Current()); + //Add edge to fillet algorithm + ... + anEdgeExplorer.Next(); + } +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In the explorer loop, you have found all the edges of the bottle shape. Each one must then be added in the *BRepFilletAPI_MakeFillet* instance with the *Add()* method. Do not forget to specify the radius of the fillet along with it. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + mkFillet.Add(myThickness / 12., anEdge); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Once this is done, you perform the last step of the procedure by asking for the filleted shape. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + myBody = mkFillet.Shape(); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +@subsection OCCT_TUTORIAL_SUB3_3 Adding the Neck + + +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. + +![](/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: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + gp_Pnt neckLocation(0, 0, myHeight); + gp_Dir neckAxis = gp::DZ(); + gp_Ax2 neckAx2(neckLocation, neckAxis); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To create a cylinder, use another class from the primitives construction package: the *BRepPrimAPI_MakeCylinder* class. The information you must provide is: + + * the coordinate system where the cylinder will be located; + * the radius and height. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + Standard_Real myNeckRadius = myThickness / 4.; + Standard_Real myNeckHeight = myHeight / 10; + BRepPrimAPI_MakeCylinder MKCylinder(neckAx2, myNeckRadius, myNeckHeight); + TopoDS_Shape myNeck = MKCylinder.Shape(); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You now have two separate parts: a main body and a neck that you need to fuse together. +The *BRepAlgoAPI* package provides services to perform Boolean operations between shapes, and especially: *common* (Boolean intersection), *cut* (Boolean subtraction) and *fuse* (Boolean union). +Use *BRepAlgoAPI_Fuse* to fuse the two shapes: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + myBody = BRepAlgoAPI_Fuse(myBody, myNeck); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +@subsection OCCT_TUTORIAL_SUB3_4 Creating a Hollowed Solid + + +Since a real bottle is used to contain liquid material, you should now create a hollowed solid from the bottle's top face. +In Open CASCADE Technology, a hollowed solid is called a *Thick* *Solid* and is internally computed as follows: + + * Remove one or more faces from the initial solid to obtain the first wall W1 of the hollowed solid. + * 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. + +![](/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: + + * The shape, which must be hollowed. + * The tolerance used for the computation (tolerance criterion for coincidence in generated shapes). + * The thickness between the two walls W1 and W2 (distance D). + * The face(s) to be removed from the original solid to compute the first wall W1. + +The challenging part in this procedure is to find the face to remove from your shape - the top face of the neck, which: + + * has a plane (planar surface) as underlying geometry; + * is the highest face (in Z coordinates) of the bottle. + +To find the face with such characteristics, you will once again use an explorer to iterate on all the bottle's faces to find the appropriate one. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + for(TopExp_Explorer aFaceExplorer(myBody, TopAbs_FACE) ; aFaceExplorer.More() ; aFaceExplorer.Next()){ + TopoDS_Face aFace = TopoDS::Face(aFaceExplorer.Current()); + } +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +For each detected face, you need to access the geometric properties of the shape: use the *BRep_Tool* class for that. The most commonly used methods of this class are: + + * *Surface* to access the surface of a face; + * *Curve* to access the 3D curve of an edge; + * *Point* to access the 3D point of a vertex. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +Handle(Geom_Surface) aSurface = BRep_Tool::Surface(aFace); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +As you can see, the *BRep_Tool::Surface* method returns an instance of the *Geom_Surface* class manipulated by handle. However, the *Geom_Surface* class does not provide information about the real type of the object *aSurface*, which could be an instance of *Geom_Plane*, *Geom_CylindricalSurface*, etc. +All objects manipulated by handle, like *Geom_Surface*, inherit from the *Standard_Transient* class which provides two very useful methods concerning types: + + * *DynamicType* to know the real type of the object + * *IsKind* to know if the object inherits from one particular type + +DynamicType returns the real type of the object, but you need to compare it with the existing known types to determine whether *aSurface* is a plane, a cylindrical surface or some other type. +To compare a given type with the type you seek, use the *STANDARD_TYPE* macro, which returns the type of a class: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + if(aSurface->DynamicType() == STANDARD_TYPE(Geom_Plane)){ + // + } +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If this comparison is true, you know that the *aSurface* real type is *Geom_Plane*. You can then convert it from *Geom_Surface* to *Geom_Plane* by using the *DownCast()* method provided by each class inheriting *Standard_Transient*. As its name implies, this static method is used to downcast objects to a given type with the following syntax: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + Handle(Geom_Plane) aPlane = Handle(Geom_Plane)::DownCast(aSurface); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Remember that the goal of all these conversions is to find the highest face of the bottle lying on a plane. Suppose that you have these two global variables: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + TopoDS_Face faceToRemove; + Standard_Real zMax = -1; +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You can easily find the plane whose origin is the biggest in Z knowing that the location of the plane is given with the *Geom_Plane::Location* method. For example: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + gp_Pnt aPnt = aPlane->Location(); + Standard_Real aZ = aPnt.Z(); + if(aZ > zMax){ + zMax = aZ; + faceToRemove = aFace; + } +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You have now found the top face of the neck. Your final step before creating the hollowed solid is to put this face in a list. Since more than one face can be removed from the initial solid, the *BRepOffsetAPI_MakeThickSolid* constructor takes a list of faces as arguments. +Open CASCADE Technology provides many collections for different kinds of objects: see *TColGeom* package for collections of objects from *Geom* package, *TColgp* package for collections of objects from gp package, etc. +The collection for shapes can be found in the *TopTools* package. As *BRepOffsetAPI_MakeThickSolid* requires a list, use the *TopTools_ListOfShape* class. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + TopTools_ListOfShape facesToRemove; + facesToRemove.Append(faceToRemove); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +All the necessary data are now available so you can create your hollowed solid by calling the *BRepOffsetAPI_MakeThickSolid* constructor: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + MyBody = BRepOffsetAPI_MakeThickSolid(myBody, facesToRemove, -myThickness / 50, 1.e-3); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +@section sec4 Building the Threading + + +@subsection OCCT_TUTORIAL_SUB4_1 Creating Surfaces + + +Up to now, you have learned how to create edges out of 3D curves. +You will now learn how to create an edge out of a 2D curve and a surface. +To learn this aspect of Open CASCADE Technology, you will build helicoidal profiles out of 2D curves on cylindrical surfaces. The theory is more complex than in previous steps, but applying it is very simple. +As a first step, you compute these cylindrical surfaces. You are already familiar with curves of the *Geom* package. Now you can create a cylindrical surface (*Geom_CylindricalSurface*) using: + + * a coordinate system; + * a radius. + +Using the same coordinate system *neckAx2* used to position the neck, you create two cylindrical surfaces *Geom_CylindricalSurface* with the following radii: + +![](/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. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + Handle(Geom_CylindricalSurface) aCyl1 = new Geom_CylindricalSurface(neckAx2, myNeckRadius * 0.99); + + Handle(Geom_CylindricalSurface) aCyl2 = new Geom_CylindricalSurface(neckAx2, myNeckRadius * 1.05); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +@subsection OCCT_TUTORIAL_SUB4_2 Defining 2D Curves + + +To create the neck of the bottle, you made a solid cylinder based on a cylindrical surface. You will create the profile of threading by creating 2D curves on such a surface. +All geometries defined in the *Geom* package are parameterized. This means that each curve or surface from Geom is computed with a parametric equation. +A *Geom_CylindricalSurface* surface is defined with the following parametric equation: + +P(U, V) = O + R * (cos(U) * xDir + sin(U) * yDir) + V * zDir, where : + + * P is the point defined by parameters (U, V). + * O, *Dir, yDir and zDir are respectively the origin, the X direction, Y direction and Z direction of the cylindrical surface local coordinate system. + * R is the radius of the cylindrical surface. + * U range is [0, 2PI] and V is infinite. + +![](/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: + + * the 3D point; + * the derivative vectors of order 1, 2 to N at this point. + +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: + +![](/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: + +| Case | Parametric Equation | Parametric Curve | +| :------------ | :----------------------------------------------------------- | :---------------------------------------------------------------------------- | +| U = 0 | P(V) = O + V * zDir | Line parallel to the Z direction | +| V = 0 | P(U) = O + R * (cos(U) * xDir + sin(U) * yDir) | Circle parallel to the (O, X, Y) plane | +| U != 0 V != 0 | P(U, V) = O + R * (cos(U) * xDir + sin(U) * yDir) + V * zDir | Helicoidal curve describing the evolution of height and angle on the cylinder | + +The helicoidal curve type is exactly what you need. On the neck's surface, the evolution laws of this curve will be: + + * 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: + +![](/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. + +![](/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: + + * To define a 2D point from its X and Y coordinates, use the *gp_Pnt2d* class. + * To define a 2D direction (unit vector) from its X and Y coordinates, use the gp_Dir2d class. The coordinates will automatically be normalized. + * To define a 2D right-handed coordinate system, use the *gp_Ax2d* class, which is computed from a point (origin of the coordinate system) and a direction - the X direction of the coordinate system. The Y direction will be automatically computed. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + gp_Pnt2d aPnt(2. * M_PI, myNeckHeight / 2.); + gp_Dir2d aDir(2. * M_PI, myNeckHeight / 4.); + gp_Ax2d anAx2d(aPnt, aDir); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +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). + +![](/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: + + * a coordinate system whose origin is the ellipse center; + * a major radius on the major axis defined by the X direction of the coordinate system; + * a minor radius on the minor axis defined by the Y direction of the coordinate system. + +Supposing that: + + * Both ellipses have the same major radius of 2*PI, + * Minor radius of the first ellipse is myNeckHeight / 10, + * And the minor radius value of the second ellipse is a fourth of the first one, + +Your ellipses are defined as follows: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + Standard_Real aMajor = 2. * M_PI; + Standard_Real aMinor = myNeckHeight / 10; + Handle(Geom2d_Ellipse) anEllipse1 = new Geom2d_Ellipse(anAx2d, aMajor, aMinor); + Handle(Geom2d_Ellipse) anEllipse2 = new Geom2d_Ellipse(anAx2d, aMajor, aMinor / 4); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To describe portions of curves for the arcs drawn above, you define *Geom2d_TrimmedCurve* trimmed curves out of the created ellipses and two parameters to limit them. +As the parametric equation of an ellipse is P(U) = O + (MajorRadius * cos(U) * XDirection) + (MinorRadius * sin(U) * YDirection), the ellipses need to be limited between 0 and M_PI. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + Handle(Geom2d_TrimmedCurve) anArc1 = new Geom2d_TrimmedCurve(anEllipse1, 0, M_PI); + Handle(Geom2d_TrimmedCurve) anArc2 = new Geom2d_TrimmedCurve(anEllipse2, 0, M_PI); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The last step consists in defining the segment, which is the same for the two profiles: a line limited by the first and the last point of one of the arcs. +To access the point corresponding to the parameter of a curve or a surface, you use the Value or D0 method (meaning 0th derivative), D1 method is for first derivative, D2 for the second one. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + gp_Pnt2d anEllipsePnt1 = anEllipse1->Value(0); + gp_Pnt2d anEllipsePnt2; + anEllipse1->D0(M_PI, anEllipsePnt2); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +When creating the bottle's profile, you used classes from the *GC* package, providing algorithms to create elementary geometries. +In 2D geometry, this kind of algorithms is found in the *GCE2d* package. Class names and behaviors are similar to those in *GC*. For example, to create a 2D segment out of two points: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + Handle(Geom2d_TrimmedCurve) aSegment = GCE2d_MakeSegment(anEllipsePnt1, anEllipsePnt2); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +@subsection OCCT_TUTORIAL_SUB4_3 Building Edges and Wires + + +As you did when creating the base profile of the bottle, you can now: + + * compute the edges of the neck's threading. + * compute two wires out of these edges. + +![](/overview/tutorial/images/tutorial_image017.png "") + +Previously, you have built: + + * two cylindrical surfaces of the threading + * three 2D curves defining the base geometry of the threading + +To compute the edges out of these curves, once again use the *BRepBuilderAPI_MakeEdge* class. One of its constructors allows you to build an edge out of a curve described in the 2D parametric space of a surface. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + TopoDS_Edge anEdge1OnSurf1 = BRepBuilderAPI_MakeEdge(anArc1, aCyl1); + TopoDS_Edge anEdge2OnSurf1 = BRepBuilderAPI_MakeEdge(aSegment, aCyl1); + TopoDS_Edge anEdge1OnSurf2 = BRepBuilderAPI_MakeEdge(anArc2, aCyl2); + TopoDS_Edge anEdge2OnSurf2 = BRepBuilderAPI_MakeEdge(aSegment, aCyl2); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Now, you can create the two profiles of the threading, lying on each surface. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + TopoDS_Wire threadingWire1 = BRepBuilderAPI_MakeWire(anEdge1OnSurf1, anEdge2OnSurf1); + TopoDS_Wire threadingWire2 = BRepBuilderAPI_MakeWire(anEdge1OnSurf2, anEdge2OnSurf2); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Remember that these wires were built out of a surface and 2D curves. +One important data item is missing as far as these wires are concerned: there is no information on the 3D curves. Fortunately, you do not need to compute this yourself, which can be a difficult task since the mathematics can be quite complex. +When a shape contains all the necessary information except 3D curves, Open CASCADE Technology provides a tool to build them automatically. In the BRepLib tool package, you can use the *BuildCurves3d* method to compute 3D curves for all the edges of a shape. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + BRepLib::BuildCurves3d(threadingWire1); + BRepLib::BuildCurves3d(threadingWire2); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +@subsection OCCT_TUTORIAL_SUB4_4 Creating Threading + + +You have computed the wires of the threading. The threading will be a solid shape, so you must now compute the faces of the wires, the faces allowing you to join the wires, the shell out of these faces and then the solid itself. This can be a lengthy operation. +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: + +![](/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. + * Use the *CheckCompatibility* method to activate (or deactivate) the option that checks whether the wires have the same number of edges. In this case, wires have two edges each, so you can deactivate this option. + * Ask for the resulting loft shape with the Shape method. + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + BRepOffsetAPI_ThruSections aTool(Standard_True); + aTool.AddWire(threadingWire1); aTool.AddWire(threadingWire2); + aTool.CheckCompatibility(Standard_False); + TopoDS_Shape myThreading = aTool.Shape(); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +@section sec5 Building the Resulting Compound + + +You are almost done building the bottle. Use the *TopoDS_Compound* and *BRep_Builder* classes to build single shape from *myBody* and *myThreading*: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + TopoDS_Compound aRes; + BRep_Builder aBuilder; + aBuilder.MakeCompound (aRes); + aBuilder.Add (aRes, myBody); + aBuilder.Add (aRes, myThreading); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Congratulations! Your bottle is complete. Here is the result snapshot of the Tutorial application: + +![](/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 sec6 Appendix + + +Complete definition of MakeBottle function (defined in the file src/MakeBottle.cxx of the Tutorial): + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + TopoDS_Shape MakeBottle(const Standard_Real myWidth, const Standard_Real myHeight, + const Standard_Real myThickness) + { + // Profile : Define Support Points + gp_Pnt aPnt1(-myWidth / 2., 0, 0); + gp_Pnt aPnt2(-myWidth / 2., -myThickness / 4., 0); + gp_Pnt aPnt3(0, -myThickness / 2., 0); + gp_Pnt aPnt4(myWidth / 2., -myThickness / 4., 0); + gp_Pnt aPnt5(myWidth / 2., 0, 0); + + // Profile : Define the Geometry + Handle(Geom_TrimmedCurve) anArcOfCircle = GC_MakeArcOfCircle(aPnt2,aPnt3,aPnt4); + Handle(Geom_TrimmedCurve) aSegment1 = GC_MakeSegment(aPnt1, aPnt2); + Handle(Geom_TrimmedCurve) aSegment2 = GC_MakeSegment(aPnt4, aPnt5); + + // Profile : Define the Topology + TopoDS_Edge anEdge1 = BRepBuilderAPI_MakeEdge(aSegment1); + TopoDS_Edge anEdge2 = BRepBuilderAPI_MakeEdge(anArcOfCircle); + TopoDS_Edge anEdge3 = BRepBuilderAPI_MakeEdge(aSegment2); + TopoDS_Wire aWire = BRepBuilderAPI_MakeWire(anEdge1, anEdge2, anEdge3); + + // Complete Profile + gp_Ax1 xAxis = gp::OX(); + gp_Trsf aTrsf; + + aTrsf.SetMirror(xAxis); + BRepBuilderAPI_Transform aBRepTrsf(aWire, aTrsf); + TopoDS_Shape aMirroredShape = aBRepTrsf.Shape(); + TopoDS_Wire aMirroredWire = TopoDS::Wire(aMirroredShape); + + BRepBuilderAPI_MakeWire mkWire; + mkWire.Add(aWire); + mkWire.Add(aMirroredWire); + TopoDS_Wire myWireProfile = mkWire.Wire(); + + // Body : Prism the Profile + TopoDS_Face myFaceProfile = BRepBuilderAPI_MakeFace(myWireProfile); + gp_Vec aPrismVec(0, 0, myHeight); + TopoDS_Shape myBody = BRepPrimAPI_MakePrism(myFaceProfile, aPrismVec); + + // Body : Apply Fillets + BRepFilletAPI_MakeFillet mkFillet(myBody); + TopExp_Explorer anEdgeExplorer(myBody, TopAbs_EDGE); + while(anEdgeExplorer.More()){ + TopoDS_Edge anEdge = TopoDS::Edge(anEdgeExplorer.Current()); + //Add edge to fillet algorithm + mkFillet.Add(myThickness / 12., anEdge); + anEdgeExplorer.Next(); + } + + myBody = mkFillet.Shape(); + + // Body : Add the Neck + gp_Pnt neckLocation(0, 0, myHeight); + gp_Dir neckAxis = gp::DZ(); + gp_Ax2 neckAx2(neckLocation, neckAxis); + + Standard_Real myNeckRadius = myThickness / 4.; + Standard_Real myNeckHeight = myHeight / 10.; + + BRepPrimAPI_MakeCylinder MKCylinder(neckAx2, myNeckRadius, myNeckHeight); + TopoDS_Shape myNeck = MKCylinder.Shape(); + + myBody = BRepAlgoAPI_Fuse(myBody, myNeck); + + // Body : Create a Hollowed Solid + TopoDS_Face faceToRemove; + Standard_Real zMax = -1; + + for(TopExp_Explorer aFaceExplorer(myBody, TopAbs_FACE); aFaceExplorer.More(); aFaceExplorer.Next()){ + TopoDS_Face aFace = TopoDS::Face(aFaceExplorer.Current()); + // Check if is the top face of the bottle's neck + Handle(Geom_Surface) aSurface = BRep_Tool::Surface(aFace); + if(aSurface->DynamicType() == STANDARD_TYPE(Geom_Plane)){ + Handle(Geom_Plane) aPlane = Handle(Geom_Plane)::DownCast(aSurface); + gp_Pnt aPnt = aPlane->Location(); + Standard_Real aZ = aPnt.Z(); + if(aZ > zMax){ + zMax = aZ; + faceToRemove = aFace; + } + } + } + + TopTools_ListOfShape facesToRemove; + facesToRemove.Append(faceToRemove); + myBody = BRepOffsetAPI_MakeThickSolid(myBody, facesToRemove, -myThickness / 50, 1.e-3); + // Threading : Create Surfaces + Handle(Geom_CylindricalSurface) aCyl1 = new Geom_CylindricalSurface(neckAx2, myNeckRadius * 0.99); + Handle(Geom_CylindricalSurface) aCyl2 = new Geom_CylindricalSurface(neckAx2, myNeckRadius * 1.05); + + // Threading : Define 2D Curves + gp_Pnt2d aPnt(2. * M_PI, myNeckHeight / 2.); + gp_Dir2d aDir(2. * M_PI, myNeckHeight / 4.); + gp_Ax2d anAx2d(aPnt, aDir); + + Standard_Real aMajor = 2. * M_PI; + Standard_Real aMinor = myNeckHeight / 10; + + Handle(Geom2d_Ellipse) anEllipse1 = new Geom2d_Ellipse(anAx2d, aMajor, aMinor); + Handle(Geom2d_Ellipse) anEllipse2 = new Geom2d_Ellipse(anAx2d, aMajor, aMinor / 4); + Handle(Geom2d_TrimmedCurve) anArc1 = new Geom2d_TrimmedCurve(anEllipse1, 0, M_PI); + Handle(Geom2d_TrimmedCurve) anArc2 = new Geom2d_TrimmedCurve(anEllipse2, 0, M_PI); + gp_Pnt2d anEllipsePnt1 = anEllipse1->Value(0); + gp_Pnt2d anEllipsePnt2 = anEllipse1->Value(M_PI); + + Handle(Geom2d_TrimmedCurve) aSegment = GCE2d_MakeSegment(anEllipsePnt1, anEllipsePnt2); + // Threading : Build Edges and Wires + TopoDS_Edge anEdge1OnSurf1 = BRepBuilderAPI_MakeEdge(anArc1, aCyl1); + TopoDS_Edge anEdge2OnSurf1 = BRepBuilderAPI_MakeEdge(aSegment, aCyl1); + TopoDS_Edge anEdge1OnSurf2 = BRepBuilderAPI_MakeEdge(anArc2, aCyl2); + TopoDS_Edge anEdge2OnSurf2 = BRepBuilderAPI_MakeEdge(aSegment, aCyl2); + TopoDS_Wire threadingWire1 = BRepBuilderAPI_MakeWire(anEdge1OnSurf1, anEdge2OnSurf1); + TopoDS_Wire threadingWire2 = BRepBuilderAPI_MakeWire(anEdge1OnSurf2, anEdge2OnSurf2); + BRepLib::BuildCurves3d(threadingWire1); + BRepLib::BuildCurves3d(threadingWire2); + + // Create Threading + BRepOffsetAPI_ThruSections aTool(Standard_True); + aTool.AddWire(threadingWire1); + aTool.AddWire(threadingWire2); + aTool.CheckCompatibility(Standard_False); + + TopoDS_Shape myThreading = aTool.Shape(); + + // Building the Resulting Compound + TopoDS_Compound aRes; + BRep_Builder aBuilder; + aBuilder.MakeCompound (aRes); + aBuilder.Add (aRes, myBody); + aBuilder.Add (aRes, myThreading); + + return aRes; + } +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/dox/resources/occt_logo.png b/dox/resources/occt_logo.png new file mode 100644 index 0000000000..0e5a04cacb Binary files /dev/null and b/dox/resources/occt_logo.png differ diff --git a/dox/start.tcl b/dox/start.tcl new file mode 100644 index 0000000000..c44be9fb2c --- /dev/null +++ b/dox/start.tcl @@ -0,0 +1,5 @@ +# Command-line starter for occdoc command, use it as follows: +# tclsh> source dox/start.tcl [arguments] + +source [file join [file dirname [info script]] occdoc.tcl] +occdoc {*}$argv \ No newline at end of file diff --git a/dox/technical_overview/images/technical_overview_over.png b/dox/technical_overview/images/technical_overview_over.png new file mode 100644 index 0000000000..a24710aaa3 Binary files /dev/null and b/dox/technical_overview/images/technical_overview_over.png differ diff --git a/dox/technical_overview/technical_overview.md b/dox/technical_overview/technical_overview.md new file mode 100644 index 0000000000..dbe751f2f5 --- /dev/null +++ b/dox/technical_overview/technical_overview.md @@ -0,0 +1,3017 @@ +Technical Overview {#technical_overview} +======================================== + +@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 +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. + +![](/technical_overview/images/technical_overview_over.png "") + +The OCCT Library provides the following services: + + + * 2D and 3D geometric modeling toolkits which allow you to model any type of object: + * Creating primitives such as prism, cylinder, cone and torus + * Performing Boolean operations (addition, subtraction and intersection) + * Tweaking constructions using fillets, chamfers and drafts + * Modeling constructions using offsets, shelling, hollowing and sweeps + * Computing properties such as surface, volume, center of gravity, curvature + * Computing geometry using projection, interpolation, approximation + * Visualization services that allow you to manage object display and manipulate views, for example: + * 3D rotation + * Zoom + * Shading + * The application framework features: + * Association between non-geometric application data and geometry + * Parameterization of models + * Java Application Desktop (JAD), a framework for creating your Graphical User Interfaces (GUI) + * Data exchange providing import and export functions of OCCT models to and from standard formats such as IGES and STEP + +OCCT Library is developed and marketed by OPEN CASCADE Company. The library is designed +to be truly modular and extensible. As such, they separate C++ classes for: + + * Defining data structures (geometric modeling, display and graphic selection) + * Implementing complex algorithms + * Providing Application Programming Interfaces (APIs) + + +Related classes are grouped into packages to prevent any class-name conflicts; +C++ class-names are prefixed by a package name. For example, all classes defining +3D geometric objects belong to the Geompackage. +In Geom, the class implementing Bezier surfaces is called BezierSurface, and its full name is Geom_BezierSurface. + +Packages are then archived into libraries, to which you can link your application. + +Finally, libraries are grouped into six modules: Foundation Classes, +Modeling Data, Modeling Algorithms, Visualization, Data Exchange and Application Framework. + +In addition Draw Test Harness (Draw) provides testing tools for the Visualization, +Modeling Algorithms, Application Framework and Data Exchange modules. +These tools include a wide range of interpreted commands which allow experimenting with OCCT. + +Refer to the Technical Overview and OCCT documentation for details about the services provided in each module. + +@section OCCT_TOVW_SECTION_2 Foundation Classes + + +Foundation Classes provide a variety of general-purpose services such as: + + * Primitive types, strings and various types of quantities + * Automated management of heap memory + * Exception handling + * Classes for manipulating data collections + * Math tools such as vectors, matrices and primitive geometric types + * Basic services for saving data in ASCII files + +These services are organized into the following libraries: + + * Kernel Classes + * Math Utilities + * Basic Persistence + +The technical overview provides only a basic description of the libraries. Please, refer for more details to Foundation Classes User's guide + +See also: our web site at E-learning and Training. + +@subsection OCCT_TOVW_SECTION_2_1 Kernel 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: + + * Primitive types such as Boolean, Character, Integer or Real + * Memory manager based on reference counting for optimizing the allocation and deallocation of large numbers of small C++ objects + * Standard_Transient class automating memory management through smart pointers + * OCCT Handle; most of OCCT classes inherit from this base class. + * Management of exceptions, + * Encapsulation of C++ streams. + +Quantities +----------- + +Quantity classes provide the following services: + + * Definition of primitive types representing most of mathematical and physical quantities + * Unit conversion tools. + * Resources to manage time information such as dates and time periods + * 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) andthe 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. + +The fact that both physical and mathematical quantities are manipulated as real +values means that : + + * They are defined as aliases of real values, so all functions provided by the Standard_Real class are available on each quantity. + * It is possible to mix several physical quantities in a mathematical or physical formula involving real values. + +Quantity package includes all commonly used basic physical quantities. + +Exceptions +---------- + +Exception classes list all the exceptions, which can be raised by any OCCT function. + +Each exception inherits from Standard_Failure either directly or by inheriting from +another exception. + +Exceptions describe anomalies which can occur during the execution of a method. 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. + + +The methods try & catch are redefined in OCCT to work properly on any platform. Nevertheless +they call native mechanisms each time it is possible. The only reason not to use +native exceptions is that they may not work properly on some compilers. In this case, +a specific OCCT code is used instead. + + +Strings +------- + +Strings are classes that handle dynamically sized sequences of characters based on +ASCII/Unicode UTF-8 (normal 8-bit character type) +and UTF-16/UCS-2 (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. + +String classes provide the following services to manipulate character strings: + * Editing operations on string objects, using a built-in string manager + * Handling of dynamically-sized sequences of characters + * Conversion from/to ASCII and UTF-8 strings. + +Strings may also be manipulated by handles and therefore, can be shared. + +These classes are implemented in TCollection and NCollection packages. + + +Collections +----------- + +Apart from strings, the TCollection package contains classes of dynamically sized +aggregates of data. They include a wide range of collections. + + * Arrays (unidimensional and bidimensional) are generally used for quick access to an item. + Note that an array is a fixed-sized aggregate. + * Sequences are ordered collections of non-unique objects. + A sequence item is longer to access than an array item: only an exploration in sequence + is efficient (but sequences are not adapted for numerous explorations). + Arrays and sequences are commonly used as data structures for more complex objects. + * Maps are dynamic structures where the size is constantly adapted to the number of inserted + items and access to an item is the fastest. 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, which are minor structures similar to sequences but with different + algorithms to explore them + * Specific iterators for sequences, maps, and stacks. + +Most collections follow value semantics: their instances are the actual collections, +not handles to a collection. Only arrays, sequences and sets may also be manipulated +by handle, and therefore shared. + + +Collection classes are generic (C++ template-like), so they can contain +a variety of objects which do not necessarily inherit from +a unique root class. When you need to use a collection of a given object type, you +must instantiate the collection for this specific type. Once the code for this declaration +is compiled, all functions available on the generic collection are available on your +instantiated class. + +Each collection directly used as an argument in Open CASCADE Technology public syntax +is instantiated in an OCCT component using the corresponding generic class in package + TCollection, by means of compiling the CDL declaration of the instance. +Thus OCCT generic classes require compilation of definitions in the CDL language and therefore +can only be instantiated in WOK. + +If you are not using CDL in your project (CDL compilation under WOK is necessary +to instantiate any generic Collection from package TCollection), then you should +use the Collections defined in NCollection package. It contains definitions of the +same generic collection classes described above, but in a form of C++ templates. +Therefore, to instantiate any collection type no additional support is required beyond +the ANSI C++ compiler. + +@subsection OCCT_TOVW_SECTION_2_2 Math Utilities + + +Vectors and Matrices +-------------------- + +The Vector and Matrix classes provide commonly used mathematical algorithms which +include: + + * Basic calculations involving vectors and matrices; + * Computation of eigenvalues and eigenvectors of a square matrix; + * Solvers for a set of linear algebraic equations; + * Algorithms to find the roots of a set of non-linear equations; + * Algorithms to find the minimum function of one or more independent variables. + +These classes also provide a data structure to represent any expression, +relation, or function used in mathematics, including the assignment of variables. + +Vectors and matrices have arbitrary ranges which must be defined at declaration time +and cannot be changed after declaration. + +~~~ + math_Vector v(1, 3); + // a vector of dimension 3 with range (1..3) + + math_Matrix m(0, 2, 0, 2); + // a matrix of dimension 3x3 with range (0..2, 0..2) + + math_Vector v(N1, N2); + // a vector of dimension N2-N1+1 with range (N1..N2) +~~~ + +Vector and Matrix objects follow "value semantics", that is, they cannot be shared +and are copied though assignment. + +~~~ + math_Vector v1(1, 3), v2(0, 2); + + v2 = v1; // v1 is copied into v2 + // a modification of v1 does not affect v2 +~~~ + +Vector and Matrix elements can be retrieved using indexes, which must be in the range +defined upon Vector/Matrix creation. The elements can be initialized with some numerical +value upon creation as well. + +~~~ + math_Vector v(1, 3); + math_Matrix m(1, 3, 1, 3); + Standard_Real value; + + v(2) = 1.0; + value = v(1); + m(1, 3) = 1.0; + value = m(2, 2); +~~~ + +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 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 +~~~ + + +Fundamental Geometry Types +------------------------- + +The Fundamental Geometry Types component groups the following packages: + + *geometric processor package gp; + *GeomAbs package, which provides enumerations generally used in geometry. + +gp package is a STEP-compliant implementation of basic geometric and algebraic +entities, used to define and manipulate elementary data structures. + +In particular, gp 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. + +These functions are defined in 3D space and in the plane. + + gp curves and surfaces are analytic: there is no parameterization and no orientation +on gp entities, i.e. these entities do not provide functions which work with these properties. +If you need, you may use more evolved data structures provided by Geom +(in 3D space) and Geom2d (in the plane). However, the definition of gp entities +is identical to the one of equivalent Geom and Geom2d entities, and they are located +in the plane or in space with the same kind of positioning systems. +They implicitly contain the orientation, which they express +on the Geom and Geom2d entities, and they induce the definition of their parameterization. + + +Therefore, it is easy to give an implicit parameterization to gp curves and surfaces, +which is the parametarization of the equivalent Geom or Geom2d entity. This property +is particularly useful when computing projections or intersections, or for operations +involving complex algorithms where it is particularly important to manipulate the +simplest data structures, i.e. those of gp. Thus, the ElCLib and ElSLib 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. + +Note: the gp entities cannot be shared when they are inside more complex data structures. + + +Common Mathematical Algorithms +---------------------- + +Common mathematical algorithms provided in OCCT 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. + + +@section OCCT_TOVW_SECTION_3 Modeling Data + +Modeling Data supplies data structures to represent 2D and 3D geometric models. + +![](/technical_overview/images/technical_overview_md.png "") + +These services are organized into the following libraries: + + * 2D Geometry + * 3D Geometry + * Geometry Utilities + * Topology + +The technical overview provides only a basic description of the libraries. Please, +refer for more details to Modeling Data User's guide + +3D geometric models are stored in OCCT native BREP format. It is possible to learn +more about it in BREP Format Description White Paper + +See also: our web site at E-learning and Training. + +@subsection OCCT_TOVW_SECTION_3_1 2D Geometry Types + + Geom2d 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. + +The key characteristic of Geom2d curves is that they are parameterized. +Each class provides functions to work with the parametric equation of the curve, +and, in particular, to compute the point of parameter u on a curve and the derivative vectors of order 1, 2.., N at this point. + +As a consequence of the parameterization, a Geom2d curve is naturally oriented. + +Parameterization and orientation differentiate elementary Geom2d curves from their +equivalent as provided by gp package. Geom2d package provides conversion +functions to transform a Geom2d object into a gp object, and vice-versa, when this is possible. + +Moreover, Geom2d package provides more complex curves, including Bezier curves, +BSpline curves, trimmed curves and offset curves. + + Geom2d objects are organized according to an inheritance structure over several levels. +Thus, an ellipse (specific class Geom2d_Ellipse) is also a conical curve and inherits +from the abstract class Geom2d_Conic, while a Bezier curve (concrete class Geom2d_BezierCurve) +is also a bounded curve and inherits from the abstract class Geom2d_BoundedCurve; +both these examples are also curves (abstract class Geom2d_Curve). Curves, points +and vectors inherit from the abstract class Geom2d_Geometry, which describes the properties +common to any geometric object from the Geom2d package. + +This inheritance structure is open and it is possible to describe new objects which +inherit from those provided in the Geom2d package, provided that they respect the +behavior of the classes from which they are to inherit. + +Finally, Geom2d objects can be shared within more complex data structures. +This is why they are used within topological data structures, for example. + + Geom2d package uses the services of the gp package to: + + * implement elementary algebraic calculus and basic analytic geometry, + * describe geometric transformations which can be applied to Geom2d objects, + * describe the elementary data structures of Geom2d objects. + +However, the Geom2d package essentially provides data structures and not algorithms. +You can refer to the GCE2d package to find more evolved construction algorithms for Geom2d objects. + +@subsection OCCT_TOVW_SECTION_3_2 3D Geometry Types + +The Geom package provides an implementation of 3D geometric objects complying with +STEP, part 42. In particular, it provides functions for: + + * 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. + +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. + +together with the derivative vectors of order 1, 2, ... N at this point. + +As a consequence of this parameterization, a Geom curve or surface is naturally oriented. + +Parameterization and orientation differentiate elementary Geom curves and surfaces from the classes of the same (or similar) names found in the gp package. +The Geom package also provides conversion functions to transform a Geom object into a gp object, and vice-versa, when such transformation is possible. + +Moreover, the Geom package provides more complex curves and surfaces, including: + * Bezier and BSpline curves and surfaces, + * swept surfaces, for example surfaces of revolution and surfaces of linear extrusion, + * trimmed curves and surfaces, and + * offset curves and surfaces. + +Geom objects are organized according to an inheritance structure over several levels. +Thus, a sphere (concrete class Geom_SphericalSurface) is also an elementary surface and inherits from the abstract class Geom_ElementarySurface, while a Bezier surface (concrete class Geom_BezierSurface) is also a bounded surface and inherits from the abstract class Geom_BoundedSurface; both these examples are also surfaces (abstract class Geom_Surface). Curves, points and vectors inherit from the abstract class Geom_Geometry, which describes the properties common to any geometric object from the Geom package. + +This inheritance structure is open and it is possible to describe new objects, which inherit from those provided in the Geom package, on the condition that they respect the behavior of the classes from which they are to inherit. + +Finally, Geom objects can be shared within more complex data structures. This is why they are used within topological data structures, for example. + +The Geom package uses the services of the gp package to: + * implement elementary algebraic calculus and basic analytic geometry, + * describe geometric transformations which can be applied to Geom objects, + * describe the elementary data structures of Geom objects. + +However, the Geom package essentially provides data structures and not algorithms. +You can refer to the GC package to find more evolved construction algorithms for +Geom objects. + + +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. +For example, Adaptor3d_Curve is the abstract class which provides the required services by an algorithm which uses any 3d curve. + + GeomAdaptor package provides interfaces: + + * On a Geom curve; + * On a curve lying on a Geom surface; + * On a Geom surface; + + Geom2dAdaptor package provides interfaces : + + * On a Geom2d curve. + + BRepAdaptor package provides interfaces: + + * On a Face + * On an Edge + +When you write an algorithm which operates on geometric objects, use Adaptor3d (or Adaptor2d) objects. +As a result, you can use the algorithm with any kind of object, +if you provide for this object, an interface derived from Adaptor3d or Adaptor2d. +These interfaces are easy to use: simply create an adapted curve or surface from a Geom2d curve, +and then use this adapted curve as an argument for the algorithm which requires it. + + +@subsection OCCT_TOVW_SECTION_3_3 Geometry Utilities + +This library provides standard high-level functions in 2D and 3D geometry such as: + + * Direct construction of algorithms; + * Approximation of curves and surfaces from points; + * Conversion of more elementary geometry to BSpline curves and surfaces; + * Calculation of points on a 2D or 3D curve; + * Calculation of extrema between two geometries. + +Direct Construction +------- + +The gp, Geom2d and Geom packages describe elementary data structures of simple geometric +objects. The constructors of these objects are elementary: the construction arguments +are fields by which the objects are represented in their data structure. + + +On the other hand, the gce, GCE2d and GC packages provided +by the Direct Construction component construct the same types of objects +as gp, Geom2d and Geom respectively. +However, the former implement geometric construction algorithms that translate the +constructor's arguments into the data structure specific to each object. + + +Algorithms implemented by these packages are simple: there is no creation of objects +defined by advanced positional constraints (for more information on this subject, +see Geom2dGcc and GccAna which describe geometry by constraints). + + + gce, GCE2d and GC each offer a series of classes of construction algorithms. + + +For example, the class gce_MakeCirc 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 gp_Circ, 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 P1 (0.,0.,0.); + gp_Pnt P2 (0.,10.,0.); + gp_Pnt P3 (10.,0.,0.); + gce_MakeCirc MC (P1,P2,P3); + if (MC.IsDone()) { + const gp_Circ& C = MC.Value(); + } +~~~~ + +In addition, gce, GCE2d and GC each have a Root class. This class is the root of +all the classes in the package which return a status. The returned status (successful +construction or construction error) is described by the enumeration gce_ErrorType. + +Note: classes which construct geometric transformations do not return a status, and +therefore do not inherit from Root. + +Approximations +----------- + +Approximation of Curves and Surfaces groups together a variety of functions used in 2D and 3D geometry for: + + * the interpolation of a set of 2D points using a 2D BSpline or Bezier curve; + * the approximation of a set of 2D points using a 2D BSpline or Bezier curve; + * the interpolation of a set of 3D points using a 3D BSpline or Bezier curve, or a BSpline surface; + * the approximation of a set of 3D points using a 3D BSpline or Bezier curve, or a BSpline surface. + +You can program approximations in two ways: + + * Using high-level functions, designed to provide a simple method for obtaining approximations with minimal programming, + * Using low-level functions, designed for users requiring more control over the approximations. + +The low-level functions provide a second API with functions to: + + * Define compulsory tangents for an approximation. These tangents have origins and extremities. + * Approximate a set of curves in parallel to respect identical parameterization. + * Smooth approximations. This is to produce a faired curve. + +The classes AppDef_MultiPointConstraints and AppDef_MultiLines allow organizing the data. +The classes AppDef_Compute, AppDef_BSplineCompute and AppDef_TheVariational +classes perform the approximation itself using Bezier curves, BSpline curves, and smooth BSpline curves, respectively. + +You can also find functions to compute: + + * 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 +---------------------------- + +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. + This is useful for writing algorithms for a single data structure model. + The BSpline formulation can be used to represent most basic geometric objects provided + by the components which describe geometric data structures ("Fundamental Geometry Types", "2D Geometry Types" and "3D Geometry Types" components). + * Secondly, it can be used to divide a BSpline curve or surface into a series of curves or surfaces, + thereby providing a higher degree of continuity. This is useful for writing algorithms + which require a specific degree of continuity in the objects to which they are applied. + Discontinuities are situated on the boundaries of objects only. + +The "Conversion to and from BSplines" component is composed of three packages. + +The Convert package provides algorithms to convert the following into a BSpline curve or surface: + + * a bounded curve based on an elementary 2D curve (line, circle or conic) from the gp package, + * a bounded surface based on an elementary surface (cylinder, cone, sphere or torus) from the gp package, + * a series of adjacent 2D or 3D Bezier curves defined by their poles. + +These algorithms compute the data needed to define the resulting BSpline curve or surface. +This elementary data (degrees, periodic characteristics, poles and weights, knots and multiplicities) +may then be used directly in an algorithm, or can be used to construct the curve or the surface +by calling the appropriate constructor provided by the classes Geom2d_BSplineCurve, Geom_BSplineCurve or Geom_BSplineSurface. + +The Geom2dConvert package provides the following: + + * a global function which is used to construct a BSpline curve from a bounded curve based on a 2D curve from the Geom2d package, + * a splitting algorithm which computes the points at which a 2D BSpline curve should be cut in order to obtain arcs with the same degree of continuity, + * global functions used to construct the BSpline curves created by this splitting algorithm, or by other types of segmentation of the BSpline curve, + * an algorithm which converts a 2D BSpline curve into a series of adjacent Bezier curves. + +The GeomConvert package also provides the following: + + * a global function used to construct a BSpline curve from a bounded curve based on a curve from the Geom package, + * a splitting algorithm, which computes the points at which a BSpline curve should be cut in order to obtain arcs with the same degree of continuity, + * global functions to construct BSpline curves created by this splitting algorithm, or by other types of BSpline curve segmentation, + * an algorithm, which converts a BSpline curve into a series of adjacent Bezier curves, + * a global function to construct a BSpline surface from a bounded surface based on a surface from the Geom package, + * a splitting algorithm, which determines the curves along which a BSpline surface should be cut in order to obtain patches with the same degree of continuity, + * global functions to construct BSpline surfaces created by this splitting algorithm, or by other types of BSpline surface segmentation, + * 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 +-------- + +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. + +The algorithms result in the following: + + * a point on a curve, situated at a given curvilinear distance from another point on the curve + * a distribution of points situated at constant curvilinear intervals along a curve + * a distribution of points at a constant rise (i.e. respecting a criterion of maximum rise between the curve and the polygon that results from the computed points) along a curve + * the length of a curve. + +@subsection OCCT_TOVW_SECTION_3_4 Topology + +Topological library allows you to build pure topological data structures.. + +Topology defines relationships between simple geometric entities. In this way, +you can model complex shapes as assemblies of simpler entities. +Due to a built-in non-manifold (or mixed-dimensional) feature, you can build models mixing: + + * 0D entities such as points; + * 1D entities such as curves; + * 2D entities such as surfaces; + * 3D entities such as volumes. + +You can, for example, represent a single object made of several distinct bodies +containing embedded curves and surfaces connected or non-connected to an outer boundary. + +Abstract topological data structure describes a basic entity - a shape, +which can be divided into the following component topologies: + + * Vertex * a zero-dimensional shape corresponding to a point in geometry; + * Edge * a shape corresponding to a curve, and bound by a vertex at each extremity; + * Wire * a sequence of edges connected by their vertices; + * Face * part of a plane (in 2D geometry) or a surface (in 3D geometry) bounded by a closed wire; + * Shell * a collection of faces connected by some edges of their wire boundaries; + * Solid * a part of 3D space bound by a shell; + * Compound solid * a collection of solids. + +The wire and the solid can be either infinite or closed. + +A face with 3D underlying geometry may also refer to a collection of connected triangles +that approximate the underlying surface. The surfaces can be undefined +leaving the faces represented by triangles only. If so, the model is purely polyhedral. + +Topology defines the relationship between simple geometric entities, +which can thus be linked together to represent complex shapes. + +Abstract Topology is provided by six packages. +The first three packages describe the topological data structure used in Open CASCADE Technology: + + * TopAbs package provides general resources for topology-driven applications. It contains enumerations that are used to describe basic topological notions: topological shape, orientation and state. It also provides methods to manage these enumerations. + * TopLoc package provides resources to handle 3D local coordinate systems: Datum3Dand Location. Datum3D describes an elementary coordinate system, while Location comprises a series of elementary coordinate systems. + * TopoDS package describes classes to model and build data structures that are purely topological. + +Three additional packages provide tools to access and manipulate this abstract topology: + + * TopTools package provides basic tools to use on topological data structures. + * TopExp package provides classes to explore and manipulate the topological data structures described in the TopoDS package. + * BRepTools package provides classes to explore, manipulate, read and write BRep data structures. These more complex data structures combine topological descriptions with additional geometric information, and include rules for evaluating equivalence of different possible representations of the same object, for example, a point. + +@subsection OCCT_TOVW_SECTION_3_5 Properties of Shapes + +Local Properties of Shapes +---------------------- + +BRepLProp package provides the Local Properties of Shapes component, +which contains algorithms computing various local properties on edges and faces in a BRep model. + +The local properties which may be queried are: + + * for a point of parameter u on a curve which supports an edge : + * the point, + * the derivative vectors, up to the third degree, + * the tangent vector, + * the normal, + * the curvature, and the center of curvature; + * for a point of parameter (u, v) on a surface which supports a face : + * the point, + * the derivative vectors, up to the second degree, + * the tangent vectors to the u and v isoparametric curves, + * the normal vector, + * the minimum or maximum curvature, and the corresponding directions of curvature; + * the degree of continuity of a curve which supports an edge, built by the concatenation of two other edges, at their junction point. + +Analyzed edges and faces are described as BRepAdaptor curves and surfaces, +which provide shapes with an interface for the description of their geometric support. +The base point for local properties is defined by its u parameter value on a curve, or its (u, v) parameter values on a surface. + +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: + + * Geom2dLProp package, which provides local properties on 2D curves + * GeomLProp package, which provides local properties on 3D curves and surfaces + * LProp package, which provides an enumeration used to characterize a particular point on a 2D curve. + +Curves are either Geom_Curve curves (in 3D space) or Geom2d_Curve curves (in the plane). +Surfaces are Geom_Surface surfaces. The point on which local properties are calculated +is defined by its u parameter value on a curve, and its (u,v) parameter values on a surface. + +It is possible to query the same local properties for points as mentioned above, and additionally for 2D curves: + + * the points corresponding to a minimum or a maximum of curvature; + * the inflection points. + +Global Properties of Shapes +------------------ +The Global Properties of Shapes component provides algorithms for computing the global +properties of a composite geometric system in 3D space, and frameworks to query the computed results. + +The global properties computed for a system are : + + * mass, + * mass center, + * matrix of inertia, + * moment about an axis, + * radius of gyration about an axis, + * principal properties of inertia such as principal axis, principal moments, and principal radius of gyration. + +Geometric systems are generally defined as shapes. Depending on the way they are analyzed, these shapes will give properties of: + + * lines induced from the edges of the shape, + * surfaces induced from the faces of the shape, or + * volumes induced from the solid bounded by the shape. + +The global properties of several systems may be brought together to give the global properties of the system composed of the sum of all individual systems. + +The Global Properties of Shapes component is composed of : + + * seven functions for computing global properties of a shape: one function for lines, two functions for surfaces and four functions for volumes. The choice of functions depends on input parameters and algorithms used for computation ( BRepGProp global functions), + * a framework for computing global properties for a set of points ( GProp_PGProps), + * 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 +---------------------- + +To compute curve length, use the method AbscissaPoint::Length from GCPnts. + +This function is used only for initializing a framework to compute the length of a curve (or a series of curves). + +The adapted curves are: + + * Adaptor_Curve2d for 2D curves + * Adaptor_Curve for 3D curves. + +The adapted curve is created in the following way: + +In 2D: + +~~~~~~~~~~~ + Handle(Geom2d_Curve) mycurve = ... ; + Geom2dAdaptor_Curve C (mycurve) ; +~~~~~~~~~~~ + +In 3D: + +~~~~~~~~~ + Handle(Geom_Curve) mycurve = ... ; + GeomAdaptor_Curve C (mycurve) ; +~~~~~~~~~ + + +The length of the curve is then computed using this curve object: + +~~~~~~~~ + GCPnts_AbscissaPoint myAlgo () ; + Standard_Real L = myAlgo.Length( C ) ; +~~~~~~~~ + +How to check the surface concavity +-------------------------------- + +To check the concavity of a surface, proceed as follows: + + 1. Sample the surface and compute at each point the Gaussian curvature. + 2. If the value of the curvature changes of sign, the surface is concave or convex depending on the point of view. + 3. To compute a Gaussian curvature, use the class SLprops from GeomLProp, which instantiates the generic class SLProps from LProp and use the method GaussianCurvature. + +How to approximate a curve with respect to tangencies +-------------------------------------------- + +To approximate a curve with respect to tangencies, follow these steps: + + 1. Create an object of type AppDef_MultiPointConstraints from the set of points to approximate and use the method SetTang to set the tangency vectors. + 2. Create an object of type AppDef_MultiLine from the AppDef_MultiPointConstraint. + 3. Use AppDef_BSplineCompute, which instantiates Approx_BSplineComputeLine to perform the approximation. + +How to extract the underlying geometry from shapes +-------------------------------------- + +To extract the underlying geometry from a Shape, use the following methods: + + * BRep_Tool::Surface to get the geometric surface from a face. + * BRep_Tool::Curve to get the 3d geometric curve from an edge. + * BRep_Tool::CurveOnSurface to get the 2d geometric curve of an edge, defined in the parametric space of a face. + * BRep_Tool::Pnt to get the 3D point from a vertex. + +Some of these methods have a location as argument. + +For example, when you use S1 = BRep_Tool::Surface(F,L), you then get the surface stored in TShape. + +To use this surface in the same position as the face, you have to apply +a transformation to it corresponding to the location of the face as follows: + +~~~~~~~~~~~~ + gp_Trsf T(L) ; + S2 = S1->Moved(T) ; +~~~~~~~~~~~~ + +The same method used without location as argument is S3 = BRep_Tool : : Surface(F) +returns a Surface in position, according to the location. S3 and S2 are geometrically equivalent surfaces. + +Warning: with the first method, you get a pointer on the surface stored in the shape. +Do not modify the surface because you will modify the shape and may produce an inconsistent model. +With the second method, you get a copy of the surface on which the location has been applied. +Note: you can use also a topological object directly just as if it +were a geometric one by using the services of BRepAdaptor classes. + +How to get the coordinates of a vertex +----------------------------------- + +To recover the UV coordinates of vertices, +use BRep_Tool::Parameters const TopoDS_Vertex& V,const TopoDS_Face& F), +which returns the U and V parameters of the vertex V on the face F as a gp_Pnt2d. + +How to explore a Wire +--------------------- + +To explore the edges of a wire in a contiguous order, use BrepTools_WireExplorer class. + +~~~~ + TopoDS_Wire myWire =&ldots;. + BRepTools_WireExplorer Ex; + for (Ex.Init(myWire); Ex.More(); Ex.Next()) { + TopoDS_Edge currentedge = Ex.Current(); + // Process current edge + } +~~~~ + +How to merge bspline curves +-------------------------- + +To merge joined bspline curves use the following methods: + +~~~~ + void GeomConvert::ConcatG1 + TColGeom_Array1OfBSplineCurve& ArrayOfCurves, + const TColStd_Array1OfReal& ArrayOfToler, + Handle(TColGeom_HArray1OfBSplineCurve) & ArrayOfConcatenated, + const Standard_Boolean ClosedG1Flag, + const Standard_Real ClosedTolerance) +~~~~ + +This method concatenates according to G1 (tangency continuity along the curve) the +ArrayOfCurves as far as possible. The following arguments are used: + + * ArrayOfCurves must have dimension bounds [0, N-1], N * number of curves to be merged. + * ArrayOfToler contains the biggest tolerance of the two points shared by two consecutive curves. Its dimension is: [0, N-2]. + * ArrayOfConcatenated contains results of operation: one or more, when impossible to merge all curves from ArrayOfCurves into one, new bspline curves are created. + * ClosedG1Flag indicates if the ArrayOfCurves is closed or not. + * If ClosedG1Flag = Standard_True, ClosedTolerance contains the biggest tolerance of the two points which are at the closure, otherwise its value is 0.0. + +~~~~ + void GeomConvert::ConcatC1 + TColGeom_Array1OfBSplineCurve& ArrayOfCurves, + const TColStd_Array1OfReal& ArrayOfToler, + Handle(TColStd_HArray1OfInteger)& ArrayOfIndices, + Handle(TColGeom_HArray1OfBSplineCurve)& ArrayOfConcatenated, + const Standard_Boolean ClosedG1Flag, + const Standard_Real ClosedTolerance, + const Standard_Real AngularTolerance) +~~~~ + +This method concatenates according to C1 (first derivative continuity along the curve) the +ArrayOfCurves as far possible. The following arguments are used (additionally to the mentioned above): + +* ArrayOfIndices contains indices that define curves from ArrayOfCurves which are beginning curves for each group of curves merged into a new curve. +* AngularTolerance is used to check the continuity of tangencies. + +~~~~ + void GeomConvert::ConcatC1 + TColGeom_Array1OfBSplineCurve& ArrayOfCurves, + const TColStd_Array1OfReal& ArrayOfToler, + Handle(TColStd_HArray1OfInteger)& ArrayOfIndices, + Handle(TColGeom_HArray1OfBSplineCurve)& ArrayOfConcatenated, + const Standard_Boolean ClosedG1Flag, + const Standard_Real ClosedTolerance) +~~~~ +This method is the same as the previous one, except for that AngularTolerance = Precision::Angular() + +It is also possible to use class GeomConvert_CompCurveToBSplineCurve. +This class provides methods to concatenate several restricted curves to a bspline curve. +Non-bspline curves are converted to bspline before concatenation. + +Constructor: +~~~~~~~~~~ + GeomConvert_CompCurveToBSplineCurve:: + GeomConvert_CompCurveToBSplineCurve(const Handle(Geom_BoundedCurve)& BasisCurve, const Convert_ParameterisationType Parameterization) + BasisCurve * beginning curve; +~~~~~~~~~~ + +Parameterization defines the ways of conversion in bspline (by default Convert_TgtThetaOver2). + +The method to add a new curve is: +~~~~ + Standard_Boolean GeomConvert_CompCurveToBSplineCurve:: + Add(const Handle(Geom_BoundedCurve)& NewCurve, + const Standard_Real Tolerance, + const Standard_Boolean After, + const Standard_Boolean WithRatio, + const Standard_Integer MinM) +~~~~ + +It returns False if the curve is not C0 with the BSplineCurve. + +Tolerance is used to check the continuity and decrease the Multiplicity +at the common Knot until MinM . If MinM = 0 , the common Knot can be removed. + +The parameter after defines the place for a new curve when it is possible to put +the new curve before or after the BasisCurve (in fact, it is case when concatenated curve can be closed). +It does not change the shape of the curve, but defines its first and last points. + +If WithRatio = Standard_True the algorithm tries to reach C1 continuity. + +The method to get a result is Handle(Geom_BSplineCurve) GeomConvert_CompCurveToBSplineCurve::BSplineCurve() const + +@section OCCT_TOVW_SECTION_4 Modeling Algorithms + +Modeling Algorithms module groups a wide range of +topological algorithms used in modeling and geometric algorithms, called by them. + +These services are organized into the following libraries: + + * Geometric Tools + * Topological Tools + * Construction of Primitives + * Boolean Operations + * Fillets and Chamfers + * Offsets and Drafts + * Features + * Hidden Line Removal + * Shape Healing + +![](/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 + +See also: our web site at E-learning and Training. + +@subsection OCCT_TOVW_SECTION_4_1 Geometric Tools + +This library provides algorithms to: + + * Calculate the intersection of two 2D curves, surfaces, or a 3D curve and a surface; + * Project points onto 2D and 3D curves, points onto surfaces, and 3D curves onto surfaces; + * Construct lines and circles from constraints; + * Construct curves and surfaces from constraints; + * Construct curves and surfaces by interpolation + +OPEN CASCADE company also provides a product known as Surfaces from Scattered Points +(SSP), which allows constructing surfaces from scattered points. This algorithm accepts +or constructs an initial B-Spline surface and looks for its deformation (finite elements +method) which would satisfy the constraints. Using optimized computation methods, +this algorithm is able to construct a surface from more than 500 000 points. + +SSP product is not supplied with Open CASCADE Technology, but can be purchased separately. + +@subsubsection OCCT_TOVW_SECTION_4_1_1 Intersections + +The Intersections component is used to compute intersections between 2D or 3D geometrical +objects: + + * the intersections between two 2D curves + * the self-intersections of a 2D curve + * the intersection between a 3D curve and a surface + * the intersection between two surfaces. + +@subsubsection OCCT_TOVW_SECTION_4_1_2 Projections + +The Projections component provides functionality for 2D and 3D geometry objects for computing the following: + + * the projections of a 2D point onto a 2D curve + * 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. + +@subsubsection OCCT_TOVW_SECTION_4_1_3 Lines and Circles from Constraints + +The Lines and Circles from Constraints component provides numerous +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 passage of a straight line or circle through a point, + *the centering of a circle on 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. + +The implemented algorithms are more complex than those provided +by the Direct Constructions component for building 2D circles or lines. + +The expression of a tangency problem generally leads to several results, according +to the relative positions of the solution and the circles or straight lines in relation +to which the tangency constraints are expressed. For example, consider the following +case of a circle of a given radius (a small one) which is tangential to two secant +circles C1 and C2: + +![](/technical_overview/images/technical_overview_occ_0005.png "Example of a Tangency Constraint") + +This diagram clearly shows that there are 8 possible solutions. + +In order to limit the number of solutions, we can try to express the relative position +of the required solution in relation to the circles to which it is tangential. For +example, if we specify that the solution is inside the circle C1 and outside the +circle C2, only two solutions referenced 3 and 4 on the diagram respond to the problem +posed. + +This technique of qualification of a solution, in relation to the curves to which +it is tangential, can be used in all algorithms for constructing a circle or a straight +line by geometric constraints. Four qualifiers are used, 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. + +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 +as the left-hand side of the curve in relation to its orientation. + +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. + +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 Geom2dGcc 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 gp objects; + *algorithms from the package GccAna 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 gp 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 + 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. + +Qualified curves (for tangency arguments) are provided either by: + + * the GccEnt package, for direct use by GccAna algorithms, or + *the Geom2dGcc package, for general use by Geom2dGcc algorithms. + +The GccEnt and Geom2dGcc packages also provide simple functions for building qualified curves in a very efficient way. + +The GccAna package also provides algorithms for constructing bisecting loci between +circles, lines or points. Bisecting loci between two geometric objects are such that +each of their points is at the same distance from the two geometric objects. They +are typically curves, such as circles, lines or conics for GccAna algorithms. +Each elementary solution is given as an elementary bisecting locus object (line, circle, +ellipse, hyperbola, parabola), described by the GccInt package. + +Note: Curves used by GccAna algorithms to define the geometric problem to be solved, +are 2D lines or circles from the gp package: they are not explicitly parameterized. +However, these lines or circles retain an implicit parameterization, corresponding +to that which they induce on equivalent Geom2d objects. This induced parameterization +is the one used when returning parameter values on such curves, for instance with +the functions Tangency1, Tangency2, Tangency3, Intersection2 and CenterOn3 provided +by construction algorithms from the GccAna or Geom2dGcc packages. + +@subsubsection OCCT_TOVW_SECTION_4_1_4 Curves and Surfaces from Constraints + +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 + * construction of ruled surfaces + *construction of pipe surfaces + *filling of surfaces + * construction of plate surfaces + *extension of a 3D curve or surface beyond its original bounds. + +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 +between two sets of nails and in this way, take the form of a curve based on the +two points, the directions of the forces applied at those points, and the properties +of the wooden lathe itself. + +Maintaining these constraints requires both longitudinal and transversal forces to +be applied to the beam in order to compensate for its internal elasticity. The longitudinal +forces can be a push or a pull and the beam may or may not be allowed to slide over +these fixed points. + +The class Batten produces curves defined on the basis of one or more constraints +on each of the two reference points. These include point and angle of tangency settings. +The class MinimalVariation produces curves with minimal variation in curvature. +The exact degree of variation is provided by curvature settings. + +Ruled Surfaces +---------------- +A ruled surface is built by ruling a line along the length of two curves. + +Pipe Surfaces +-------------- + +A pipe is built by sweeping a curve (the section) along another curve (the path). + +The following types of construction are available: + * pipes with a circular section of constant radius, + * pipes with a constant section, + * pipes with a section evolving between two given curves. + + +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. + +A case in point is the intersection of two fillets at a corner. If the radius of +the fillet on one edge is different from that of the fillet on another, it becomes +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. + +![](/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 +a Bezier or a BSpline surface in one of a range of filling styles. + + +This package was designed with a view to handling gaps produced during fillet construction. +Satisfactory results cannot be guaranteed for other uses. + +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, +a technical or an aesthetic order. + + +Essentially, a plate surface is constructed by deforming a surface so that it conforms +to a given number of curve or point constraints. In the figure below, you can see +four segments of the outline of the plane, and a point which have been used as the +curve constraints and the point constraint respectively. The resulting surface can +be converted into a BSpline surface by using the function MakeApprox . + + +The surface is built using a variational spline algorithm. It uses the principle +of deformation of a thin plate by localised mechanical forces. If not already given +in the input, an initial surface is calculated. This corresponds to the plate prior +to deformation. Then, the algorithm is called to calculate the final surface. It +looks for a solution satisfying constraints and minimizing energy input. + +![](/technical_overview/images/technical_overview_occ_0007.png "Surface generated from four curves and a point") + +![](/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 +---------------------------------------- + +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 + +The Interpolation Laws component provides definitions of functions: y=f(x) . + +In particular, it provides definitions of: + + * a linear function, + * an S function, and + * an interpolation function for a range of values. + +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. + +@subsection OCCT_TOVW_SECTION_4_2 Topological Tools + +This library provides algorithms to: + + * Tessellate shapes + * Validate shapes + * Determine the local properties of shapes + * Determine the global properties of shapes + * Perform geometric transformations + * Find planes in which edges are located + * Convert shapes to NURBS geometry. + +It also furnishes a complete brep data structure for topological data structures defined +in the Topology library of the Modeling Data module. +This linAllows you to create standard topological objects such as: + + * Vertices + * Edges + * Faces + * Wires + * Polygonal wires + * Shells + * Solids. + +The API provides classes to build objects: + + * The constructors of classes provide different construction methods; + * The class retains different tools used to build objects as fields; + * The class provides a casting method to obtain the result automatically with a function-like call. + +For example, to build a vertex V on a point P, you can use: + +~~~ + V = BRepBuilderAPI_MakeVertex(P); +~~~ +or + +~~~ + BRepBuilderAPI_MakeVertex MV(P); + V = MV.Vertex(); +~~~ + +For error handling, the BRepBuilderAPI commands raise only the + 0StdFail_NotDone exception. When IsDone is false for a command, +the error description can be requested from the command. + +@subsection OCCT_TOVW_SECTION_4_3 Construction of Primitives + +This library contained in BRepPrimAPI package provides an API (Application Programming Interface) for: + + * Construction of primitives such as: + * Boxes; + * Cones; + * Cylinders; + * Prisms. + * Construction by sweeping along a profile: + * Linear; + * Rotational (through an angle of rotation). + +Sweeps are objects obtained by sweeping a profile along a path. +The profile can be any topology and the path is usually a curve or a wire. +The profile generates objects according to the following rules: + + * Vertices generate Edges + * Edges generate Faces. + * Wires generate Shells. + * Faces generate Solids. + * Shells generate Composite Solids. + +It is not allowed to sweep Solids and Composite Solids. + +Swept constructions along complex profiles such as +BSpline curves are also available in the BRepOffsetAPI package. + +This API provides simple, high level calls for the most common operations. + +@subsection OCCT_TOVW_SECTION_4_4 Boolean Operations + +Boolean operations to create new shapes from old ones by using: + + * Common + * Cut + * Fuse + * Section + +There are two libraries for Boolean Operations: + + * Old Boolean Operations (BOA) provided by BRepAlgo package designed and developed in Open CASCADE 6x in 2000; its architecture and content are out of date. + * New Boolean Operations (NBOA) provided by BRepAlgoAPI package designed and developed in 2009 and completely revised in 2013. + +Major benefits of New Boolean Operations +------------------------------------------ + + * 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 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. + * The implementation of NBOA is based on NCollection classes. The usage of opportunities given by local memory allocators ( NCollection_IncAllocator) 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 NCollection_UBTree. 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. + +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. + +@subsection OCCT_TOVW_SECTION_4_5 Features + +This library contained in BRepFeat package is necessary for the creation +and manipulation of both form and mechanical features in a Boundary Representation framework. + +The form features are depressions or protrusions including the following types: + + * Cylinder; + * Draft Prism; + * Prism; + * Revolved feature; + * Pipe. + +Depending on whether you wish to make a depression or a protrusion, +you can choose either to remove matter (Boolean cut: Fuse equal to 0) or to add it (Boolean fusion: Fuse equal to 1). + +The semantics of form feature creation is based on the construction of shapes: + + * for a certain length in a certain direction; + * up to the limiting face; + * from the limiting face at a height; + * above and/or below a plane. + +The shape defining the construction of a feature can be +either a supporting edge or a concerned area of a face. + +In case of supporting edge, this contour can be attached to a face +of the basis shape by binding. When the contour is bound to this face, +the information that the contour will slide on the face becomes available +to the relevant class methods. In case of the concerned area of a face, you could, +for example, cut it out and move it at a different height, +which will define the limiting face of a protrusion or depression. + +Topological definition with local operations of this sort makes calculations simpler +and faster than a global operation. The latter would entail a second phase +of removing unwanted matter to get the same result. + +Mechanical features include ribs, protrusions and grooves (or slots), +depressions along planar (linear) surfaces or revolution surfaces. + +The semantics of mechanical features is based on giving thickness to a contour. +This thickness can either be + + * unilateral + * on one side of the contour + * or bilateral + * on both sides. + +As in the semantics of form features, the thickness is defined +by construction of shapes in specific contexts. + +However, in case of mechanical features, development contexts differ. +Here they include extrusion: + + * to a limiting face of the basis shape; + * to or from a limiting plane; + * to a height. + +@subsection OCCT_TOVW_SECTION_4_6 Hidden Line Removal + +This library provides two algorithms: HLRBRep_Algo and HLRBRep_PolyAlgo to define the lines of a shape hidden in a given projection. These lines can be shown or hidden to have the precision required in industrial design. To do this, the Hidden Line Removal component provides + +These algorithms remove or indicate lines hidden by surfaces. +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 calculation results. +This new shape is made up of edges, which represent the lines of the visualized shape in a plane. This plane is the projection plane. + +The algorithm HLRBRep_Algo allows working with the shape itself, while HLRBRep_PolyAlgo works with its polyhedral simplification. When you use HLRBRep_Algo, you obtain an exact result, whereas, when you use HLRBRep_PolyAlgo, you reduce computation time but obtain polygonal segments. + +@subsection OCCT_TOVW_SECTION_4_7 Shape Healing + +Shape Healing library provides algorithms to modify the geometry and topology of OCCT shapes. +Shape Healing adapts shapes to make them maximally appropriate for use by OCCT, for example: + + * analyze shape characteristics and, in particular, identify the shapes that do not comply with OCCT validity rules; + * fix incorrect or problem shapes; + * upgrade and change shape characteristics if needed, for example a C0 supporting surface can become C1 continuous. + +It has several sub-domains, each with its own scope of functionality: + + * analysis - exploring shape properties, computing shape features, detecting violation of OCCT requirements (the 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 OCCT 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 (the shape is not modified, only the form of its representation is modified); + * processing - mechanism of shape modification via a user-editable resource file. + +The technical overview provides only a basic description of the libraries. Please, refer for more details to Shape Healing User's guide + +See also: our web site at E-learning and Training. + + +@subsection OCCT_TOVW_SECTION_4_8 Miscellaneous modelling algorithms. + +Fillets and Chamfers +--------------------- + +This library provides algorithms to make fillets and chamfers on shape edges. +The following cases are addressed: + + * Corners and apexes with different radii; + * Corners and apexes with different concavity. + +If there is a concavity, both surfaces that need to be extended and those, which do not, are processed. + +Offsets, Drafts, Sewing and Sweeps +---------------------------------- + +These classes provide the following services: + + * Creation of offset shapes and their variants such as: + * Hollowing; + * Shelling; + * Lofting; + * Creation of tapered shapes using draft angles + * Sewing + * Creation of sweeps + + +@subsection OCCT_TOVW_SECTION_4_9 Examples + +How to compute the state of a point on a face: +--------------------------------------------- + +Use BRepTools::Pnt to get the point from your vertex. +Your shape must be of the TopoDS_Shape type. +If it is, you can use BRepTopAdaptor_FClass2d class. For example: + +~~~~~ + BRepTopAdaptor_FClass2d::Load (to load the solid ) + BRepTopAdaptor_FClass2d::Perform (to compute the state of the point ) + BRepTopAdaptor_FClass2d::State (to get the TopAbs_State). +~~~~~ + + +How to compute the state of a point in a solid: +--------------------------------------- + +Use BRepTools::Pnt to get the point from your vertex. +Your shape must be of the TopoDS_Solid type. + +If it is, you can use the BRepClass3d_SolidClassifier class, for example: + +~~~~~ + BRepClass3d_SolidClassifier::Load (to load the solid) + BRepClass3d_SolidClassifier::Perform (to compute the state of the point) + BRepClass3d_SolidClassifier::State (to get a TopAbs_State object) + BRepClass3d_SolidClassifier inherits BRepclass3d_SClassifier +~~~~~ + +How to connect a set of contiguous but independent faces +------------------------------------------ + +A unique topological object can be obtained in this way using the class + Sewing from the BRepOffsetAPI package which produces a shell as a result. + +~~~~~ + BRepOffsetAPI_Sewing Sew; + Sew.Add(Face1); + Sew.Add(Face2); + ... + Sew.Add(Facen); + Sew.Perform(); + TopoDS_Shape result= Sew.SewedShape(); +~~~~~ + +@note The sewing algorithm uses a tolerance to assemble the faces by sewing them along common edges. You must therefore check the gap between faces before sewing or adjust the value of the tolerance according to the real gap of the geometry. + +If all faces have been sewed correctly, the result is a shell. Otherwise, it is a compound. After a successful sewing operation all faces have a coherent orientation. + +For more information, refer to the entry for this class in reference documentation. + +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 PerformInfinitePoint method from the BrepClass3D_SolidClassifier class. + +~~~~~ + BRepClass3d_SolidClassifier clas3d(aShell); + clas3d.PerformInfinitePoint(Precision::Confusion()); + if (clas3d.State() == TopAbs_IN) + newShell.Reverse(); + BRepBuilderAPI_MakeSolid aSolid(aShell); +~~~~~ + +@section OCCT_TOVW_SECTION_5 Visualization + +Visualization in Open CASCADE Technology is based on the separation of modeling data you want to display and select, and on the graphical presentation of its structure. + +For visualizing data structures, OCCT provides ready-to-use algorithms, which create graphic presentations from geometric models. These data structures may be used with the viewers supplied, and can be customized to take the specificity of your application into account. + +Displaying is managed through presentation services, and selection in its turn is managed through selection services. With these services, data structures and algorithms are provided to display objects of an application, and to support graphical selection of these objects. + +Application Interactive Services (AIS) are provided to manage displaying, detection and selection of graphical presentations. These services associate data structures and interactive objects. + +Please, refer for more details to Visualization User's guide + +See also: our web site at E-learning and Training. + +![](/technical_overview/images/technical_overview_viz.png "") + +@subsection OCCT_TOVW_SECTION_5_1 3D Graphics + +3D Graphics provided by Graphic3d 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. +Structures can be connected to form a hierarchy of structures, composed by transformations. +The viewer can perform global manipulation of structures. + + Visual3d package contains the group of classes required to implement commands for 3D viewer. The viewer manages views and light sources. + +Most types of primitives supported by Graphic3d can be dumped to a vector file format such as PDF and PostScript. Export to vector formats is implemented with help of GL2PS library. + +@subsection OCCT_TOVW_SECTION_5_2 3D Visualization + +This library provides services for: + + * Selection of 3D data structures + * Presentation of 3D data structures + +Access to 3D presentation and selection is provided through AIS (Application Interactive Services). +This package is a high-level interface that offers access to the lower-level presentation and selection services. +AIS expand this underlying functionality with standard 3D selection attributes, presentation management, and standard 3D presentation attributes, and manages it in the definition of GUI viewers. To implement these services, AIS package includes the following: + + * Interactive context + * Interactive objects + * A graphic attributes manager + * Selection filters + +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 +------------------- + +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, or AIS Drawer, stores graphic attributes for specific interactive objects and for interactive objects controlled by interactive context. + +Initially, all drawer attributes are filled out with the predefined values which will define the default 3D object appearance. + +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 +----------------- + +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_3 Application Interactive Services (AIS) + +Application Interactive Services provide the means to create links between an application GUI viewer and the packages which are used to manage selection and presentation. The tools AIS defined for this include different sorts of entities: the selectable viewable objects themselves and the context and attribute managers to define their selection and display. + +To orient the user as he works in a modeling environment, views and selections must be comprehensible. +There must be several different sorts of selectable and viewable object defined. +These must also be interactive, that is, connecting graphic representation and the underlying reference geometry. These entities are called Interactive Objects, and are divided into four types: + * the Datum + * the Relation + * the Object + * None. + +The Datum groups together the construction elements such as lines, circles, points, trihedrons, plane trihedrons, planes and axes. +The Relation is made up of constraints on one or more interactive shapes and the corresponding reference geometry. For example, you might want to constrain two edges in a parallel relation. This constraint is considered as an object in its own right, and is shown as a sensitive primitive. This takes the graphic form of a perpendicular arrow marked with the || symbol and lying between the two edges. + +The Object type includes topological shapes, and connections between shapes. + +None, in order not to eliminate the object, tells the application to look further until it finds an object definition in its generation which is accepted. + +Inside these categories, you have the possibility of an additional characterization by means of a signature. The signature provides an index to the further characterization. By default, the Interactive Object has a None type and a signature of 0 (equivalent to None.) +If you want to give a particular type and signature to your interactive object, you must redefine the two virtual methods: Type and Signature. + +In the C++ inheritance structure of the package, each class representing a specific Interactive Object inherits AIS_InteractiveObject. Among these inheriting classes, AIS_Relation functions as the abstract mother class for inheriting classes defining display of specific relational constraints and types of dimension. Some of these include: + + * display of constraints based on relations of symmetry, tangency, parallelism and concentricity + * display of dimensions for angles, offsets, diameters, radii and chamfers. + +No viewer can show everything at once with any coherence or clarity. +Views must be managed carefully both sequentially and at any given instant. +Another function of the view is that of a context to carry out design in. +The design changes are applied to the objects in the view and then extended +to the underlying reference geometry by a solver. +To make sense of this complicated visual data, several display and selection tools are required. +To facilitate management, each object and each construction element has a selection priority. +There are also means to modify the default priority. + +To define an environment of dynamic detection, you can use standard filter classes or create your own. +A filter questions the owner of the sensitive primitive in local context to determine +if it has the desired qualities. If it answers positively, it is kept. If not, it is rejected. + +The standard filters supplied in AIS include: + + * AIS_AttributeFilter + * AIS_SignatureFilter + * AIS_TypeFilter. + +Only the type filter can be used in the default operating mode, the neutral point. +The others can only be used in open local contexts. + +Neutral point and local context constitute the two operating modes of the +central entity which pilots visualizations and selections, the Interactive Context. +It is linked to a main viewer and if you like, a trash bin viewer as well. + +The neutral point, which is the default mode, allows you to easily visualize and select interactive objects which have been loaded into the context. Opening local contexts allows you to prepare and use a temporary selection environment without disturbing the neutral point. +A set of functions allows you to choose the interactive objects which you want to act on, the selection modes which you want to activate, and the temporary visualizations which you will execute. When the operation is finished, you close the current local context and return to the state in which you were before opening it (neutral point or previous local context). + +An interactive object can have a certain number of graphic attributes, which are specific to it, such as visualization mode, color, and material. By the same token, the interactive context has a set of graphic attributes, the 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 the object's own Drawer if one exists, or from the context drawer for the others. + + +@subsection OCCT_TOVW_SECTION_5_4 Presentation + +Presentation Management +---------------------- + + PrsMgr 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 AIS_Shape, for example, this determines whether the object is to be displayed in: + wireframe 0 + shading 1. + +Note that each new Interactive Object must have all its display modes defined. + +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 StdPrs package provides standard display tools for specific geometries and topologies whereas Prs3d 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 +-------------------------- + DsgPrs 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 +--------------- + +The SelectBasics 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 +------------------- + +The StdSelect package provides the following services: + + * definition of selection modes for topological shapes + * definition of several filter standard Selection2d.ap classes + * 3D viewer selectors. + +Note that each new Interactive Object must have all its selection modes defined. +The Select3D package provides the following services: + + * definition of standard 3D sensitive primitives such as points, curves and faces; + * recovery of the bounding boxes in the 2D graphic selection space, if required; + * a 3D-2D projector. + +Selection Management +-------------------- + +The SelectMgr package provides low level services and the classes + SelectMgr_SelectionManager and SelectMgr_ViewerSelector +in particular are only to be used when you do not want to use the services provided by AIS. + + SelectMgr manages the process of dynamic selection through the following services: + + * activating and deactivating selection modes for Interactive Objects + * adding and removing viewer selectors + * definitions of abstract filter classes + +The principle of graphic selection consists in representing the objects which you want +to select by a bounding box in the selection view. +The object is selected when you use the mouse to designate the zone produced by the object. + +To realize this, the application creates a selection structure +which is independent of the point of view. This structure is made up +of sensitive primitives which have one owner object associated to each of them. +The role of the sensitive primitive is to reply to the requests of the selection algorithm +whereas the owner's purpose is to make the link between +the sensitive primitive and the object to be selected. +Each selection structure corresponds to a selection mode which defines the elements that can be selected. + +For example, to select a complete geometric model, +the application can create a sensitive primitive for each face +of the interactive object representing the geometric model. +In this case, all the primitives share the same owner. +On the other hand, to select an edge in a model, +the application must create one sensitive primitive per edge. + +~~~~ + +void InteractiveBox::ComputeSelection + (const Handle(SelectMgr_Selection)& Sel, + 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); + for(Standard_Integer I=1;I<=Nbfaces;I++){ + Sel->Add(new Select3D_SensitiveFace + (Ownr,[array of the vertices] face I); + break; + } + +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)); + } + } +} + +~~~~ + +The algorithms for creating selection structures store the sensitive primitives in a + SelectMgr_Selection object. To do this, a set of ready-made sensitive primitives is supplied +in the Select2D and Select3D packages. New sensitive primitives can be defined through inheritance +from SensitiveEntity. For the application to make its own objects selectable, + it must define owner classes inheriting SelectMgr_EntityOwner. + +For any object inheriting from AIS_InteractiveObject, you redefine +its ComputeSelection functions. In the example below there are different modes +of selection on the topological shape contained within the interactive object, +selection of the shape itself, the vertices, the edges, the wires, the faces. + +~~~~ + void MyPack_MyClass::ComputeSelection( + const Handle(SelectMgr_Selection)& aSelection, + const Standard_Integer aMode) + { + switch(aMode){ + case 0: + StdSelect_BRepSelectionTool::Load( + aSelection,this,myShape,TopAbs_SHAPE); + break; + } + case 1: + StdSelect_BRepSelectionTool::Load( + aSelection,this,myShape,TopAbs_VERTEX); + break; + } + case 2: + StdSelect_BRepSelectionTool::Load( + aSelection,this,myShape,TopAbs_EDGE); + break; + } + case 3: + StdSelect_BRepSelectionTool::Load( + aSelection,this,myShape,TopAbs_WIRE); + break; + } + case 4: + StdSelect_BRepSelectionTool::Load( + aSelection,this,myShape,TopAbs_FACE); + break; + } + } +~~~~ + +The StdSelect_BRepSelectionTool object provides a high level service +which will make the shape myShape selectable when the AIS_InteractiveContext is asked to display your object. + +Note: + +The traditional way of highlighting selected entity owners +adopted by Open CASCADE Technology assumes that each entity owner +highlights itself on its own. This approach has two drawbacks: + + * each entity owner has to maintain its own Prs3d_Presentation object, that results in large memory overhead for thousands of owners; + * drawing selected owners one by one is not efficient from the OpenGL usage viewpoint. + +That is why a different method has been introduced. +On the basis of SelectMgr_EntityOwner::IsAutoHilight() return value + AIS_LocalContext object either uses the traditional way of highlighting +( IsAutoHilight() returned true) or groups such owners according to their +Selectable Objects and finally calls SelectMgr_SelectableObject::HilightSelected() or + ClearSelected(), passing a group of owners as an argument. + +Hence, an application can derive its own interactive object and redefine HilightSelected(), + ClearSelected() and HilightOwnerWithColor() virtual methods + to take advantage of such OpenGL technique as arrays of primitives. + In any case, these methods should at least have empty implementation. + + The AIS_LocalContext::UpdateSelected(const Handle(AIS_InteratciveObject)&, Standard_Boolean) + method can be used for efficient redrawing a selection presentation for a given interactive object from an application code. + +Additionally, the SelectMgr_SelectableObject::ClearSelections() +method now accepts an optional Boolean argument. +This parameter defines whether all object selections should be flagged for further update or not. +This improved method can be used to re-compute an object selection (without redisplaying the object completely) +when some selection mode is activated not for the first time. + + +@subsection OCCT_TOVW_SECTION_5_6 Attribute Management + +The Attribute Management tool-kit 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 Prs3d package provides the following services: + + * a presentation object (the context for all modifications to the display, its presentation will be displayed in every view of an active viewer) + * an attribute manager governing how objects such as color, width, and type of line are displayed; these are generic objects, whereas those in StdPrs are specific geometries and topologies. + * generic algorithms providing default settings for objects such as points, curves, surfaces and shapes + * a root object which provides the abstract framework for the DsgPrs definitions at work in display of dimensions, relations and trihedrons. + + +@subsection OCCT_TOVW_SECTION_5_7 Mesh Visualization Services + + MeshVS (Mesh Visualization Service) component extends 3D visualization capabilities +of Open CASCADE Technology. It provides flexible means of displaying meshes along with associated pre- and post-processor data. + +From a developer's point of view, it is easy to integrate the MeshVS component i +nto any mesh-related application with the help of the following guidelines: + +Derive a data source class from the MeshVS_DataSource class. +Re-implement its virtual methods, so as to give the MeshVS component access +to the application data model. This is the most important part of the job, +since visualization performance is affected by performance of data retrieval methods of your data source class. + +Create an instance of the MeshVS_Mesh class. + +Create an instance of your data source class and pass it to a MeshVS_Mesh object through the SetDataSource() method. + +Create one or several objects of MeshVS_PrsBuilder-derived classes +(either standard, included in the MeshVS package, or your custom ones). +Each PrsBuilder is responsible for drawing a MeshVS_Mesh presentation +in certain display mode(s) specified as a PrsBuilder constructor's argument. +Display mode is treated by MeshVS classes as a combination of bit flags +(two least significant bits are used to encode standard display modes: wireframe, shading and shrink). +Pass these objects to the MeshVS_Mesh::AddBuilder() method. MeshVS_Mesh +takes advantage of improved selection highlighting mechanism: it highlights its selected entities itself, +with the help of so called "highlighter" object. You can set one of PrsBuilder +objects to act as a highlighter with the help of a corresponding argument of the AddBuilder() method. + +Visual attributes of the MeshVS_Mesh object (such as shading color, shrink coefficient and so on) +are controlled through MeshVS_Drawer object. It maintains a map "Attribute ID --> attribute value" +and can be easily extended with any number of custom attributes. + +In all other respects, MeshVS_Mesh is very similar to any other class derived +from AIS_InteractiveObject and it should be used accordingly +(refer to the description of AIS package in the documentation). + +@subsection OCCT_TOVW_SECTION_5_8 Images and Drivers + +Images +-------- + +The Image package provides PseudoColorImage +and ColorImage definitions, and a set of key functions from the image fields. + +The AlienImage package allows importing images from other formats into OCCT format. + +Drivers +--------- +The Xw package contains the common X graphic interface. It uses XWindow bitmap fonts that cannot be modified. + +The WNT package contains the common Windows NT graphic interface. + +The Cocoa package provides interaction with Cocoa API on Mac OS X. + +@subsection OCCT_TOVW_SECTION_5_9 New Interactive Services (NIS) + +New Interactive Services package provides the API similar to the traditional AIS but with some important differences/improvements: + + * Each type of InteractiveObject should have a corresponding Drawer class that defines the presentation of the Object type using direct OpenGl calls. This is a much faster way to display 3D objects, providing for more than 1 million separate selectable entities in one view. + * The abstract type NIS_InteractiveObject does not support any properties (color, material, other aspects). The relevant properties should be defined in the specializations of the Drawer class, and the API to set/modify should be implemented in the specializations of InteractiveObject class. + * Interactive selection is managed by InteractiveObject methods instead of special selector classes and data types. This is possible since in NIS the selection is based on 3D representation (by a ray or a box corresponding to the view direction) without intermediate 2D projection. + * Many InteractiveContext instances can be attached to a V3d_View, these instances being independent containers of interactive objects; removal (detaching) of InteractiveContext instance destroys the contained objects. + * All data types and algorithms are designed to provide the best performance for both OpenGl (server side) and application. On the other hand, the API is open to any feature supported by any version of OpenGl. This allows building custom presentations quickly and efficiently. + * Standard NIS_View subclasses V3d_View thus providing all its public API, such as scene definition (view orientation, lights, background, etc.) and the standard view transformations (pan/zoom/rotate,fitAll,...). The traditional AIS-based presentations (e.g., AIS_Shape) are also supported, they can be rendered together with NIS presentations in the same view window. + +The DRAW test plugin, TKViewerTest, has been modified +to manage AIS_InteractiveContext and NIS_InteractiveContext together in one view window. + +@subsection OCCT_TOVW_SECTION_5_10 Voxels + +A voxel is a sub-volume box with constant scalar/vector value. +The object in voxel representation is split into many small sub-volumes (voxels) and its properties are distributed through voxels. + +Voxels are used for analysis and visualization of 3D-dimensional distribution of data. +Medicine (mainly, tomography), computational physics (hydrodynamics, aerodynamics, nuclear physics) +and many other industries use voxels for 3D data visualization and analysis of physical processes. + +Open CASCADE Technology provides several basic data containers for voxels +with fast access to the data and optimal allocation of data in memory. +Also, a special visualization toolkit allows visualizing voxels +as colored or black/white points and cubes, displaying only the voxels visible from the user's point of view. + +Please, see for more information Voxels User's Guide white paper. + +@subsection OCCT_TOVW_SECTION_5_11 Examples + +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. + +By default, the interactive object takes the graphic attributes of +the interactive context in which it is visualized +(visualization mode, deflection, values for the calculation of presentations, +number of isoparametric lines, color, type of line, material, etc.) + +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 virtual functions which allow us to act on these attributes have been proposed. +Each new class of interactive object can use them as they are or +can redefine these functions to bring about the changes it should produce in the behavior of the class. + +Other attributes can be changed by acting directly on the drawer of the object. +An interactive object has a specific drawer as soon as you change an attribute on it. +If you do not modify any graphic attribute on it, the default drawer of the interactive context is referenced and used. + +To get the AIS_Drawer of an object, call method AIS_InteractiveObject::Attributes . + +To set the AIS_Drawer of an object, call method AIS_InteractiveObject::SetLocalAttributes . + +How to dump a scene from the viewer +---------------------------- + +You can dump the contents of a V3D_View in a file with the same scale or +with a different scale according to the required paper size (format) +and the aspect ratio of the view. This is provided by method V3d_View::Dump. For example: + +~~~~ +CString filename ("myView3D.bmp"); +myView->Dump (filename, Aspect_FOSP_A4); +~~~~ + + myView is a V3d_View, where OCCT objects are displayed using, for example, AIS services. + +Please, note: + + * The file name extension can be any among ".xwd", ".png", or ".bmp" formats both on UNIX or NT. + * Be careful about dump time requirements of the resulting file, especially for the A formats. + * The GIF format generates very small files, BMP and XWD generates much larger files (4 to 6 times the size of a GIF). + * 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 +--------------------------------------------- + +You can add or remove an object from a selection in one of two ways. You can use: + + * AIS_InteractiveContext::AddOrRemoveCurrentObject method at neutral points; + * AddOrRemoveCurrent method if a local context is opened. + + +How to detect overlapped objects +-------------------------------- + +When objects overlap each other and cause difficulties in selection, +you can use the mechanism provided with the AIS_InteractiveContext +to successively highlight all the objects found under the selection. +This allows you to choose and validate the required object. + +~~~~ + If ( myAISContext->HasNextDetected()) { + + // if up key is pressed + myAISContext ->HilightNextDetected(myView); + + // if down key is pressed + myAISContext ->HilightPreviousDetected(myView); + + } +~~~~ + + + +Get mouse coordinates in 3D view +-------------------------------- + +To switch from pixel mouse position on the screen to 3D coordinates +in V3d_View, use V3d_View::Convert method. + +~~~~ + Handle(V3d_View) aview + aView->Convert(Xp,Yp,X,Y,Z) +~~~~ + +Where Xp, Yp are the mouse coordinates in pixels and X,Y,Z the real coordinates in 3D space. + +3D Viewer Objects +----------------- + +The V3d 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 Visual3D graphic package. + + CSF_WALKTHROUGH variable enables you to manage the perspective of the view +in the viewer by defining setenv CSF_WALKTHROUGH "Yes". + +If you use the syntax unsetenv CSF_WALKTHROUGH , you make sure that the variable +is deactivated. In this case, the eye is located outside the 3D bounding box of the view. +This is the default behavior for managing the view perspective. + +@section OCCT_TOVW_SECTION_6 Data Exchange + +Data Exchange is a key factor in using Open CASCADE Technology (as well as applications based thereon) +concurrently with other software such as CAD systems. It provides the openness of OCCT in a multi-software environment, +by allowing it to process external data and providing a good level of integration. + +This means obtaining results of good quality, and covering the needs of exchanges +from OCCT-based applications regardless of external data quality or requirements, +in particular in respect of allowed data types and arrangements between them, accepted gaps between geometries. + +This matter is addressed by Data Exchange Module, which is organized in a modular way. + +![](/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 +-------------------------- + +* STEP (AP203 : Mechanical Design, this covers General 3D CAD; AP214: Automotive Design) +* IGES (up to 5.3) +* STL +* VRML + +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 (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. +Data types such as colors, assembly descriptions and validation properties +(i.e. center of gravity, etc.) are supported. These data are stored together with shapes in an OCAF (XCAF) document. + + +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: + +* ACIS SAT +* Parasolid X_T +* DXF + +These components are based on the same architecture as interfaces with STEP and IGES. + +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. +It is intended to send geometric data (volumic) to stereolithography machines, +which can read and interpret such data. These machines can transform a volumic model +to a physical prototype made of plastic, by using laser to coagulate material, +which corresponds to the volume, and set free the material around. +STL defines these surfaces by triangles. +Thus, no machining is required to switch from a virtual model to a physical one. + +Since STL files can only include solids described by their mesh structures, +OCCT shapes, which are intended to be written, must be solids, +components of solids or closed shells with a correct orientation. + +When translating shapes to STL format, remember that all references +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. + +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. + +@subsection OCCT_TOVW_SECTION_6_1 General Definitions + +OCCT general definitions for Data Exchange include several enumerations and classes used by IGES and STEP data exchange interfaces. + +To define translation parameters and file headers, you can use: + + * Interface_InterfaceModel + * Interface_Static + +To manage Message display, use class Mesage_Messenger. + +To define the type of analysis of the source file, and to ensure the success +of the loading operation, you use the following enumerations from the IFSelect package: + + * PrintCount + * ReturnStatus + +To read and write attributes such as names, colors, layers for IGES and STEP +and validation properties and structure of assemblies for STEP, you can use an XDE document. + +It is possible to learn more about XDE documents from XDE User's guide + +See also: our web site at E-learning and Training. + + +@subsection OCCT_TOVW_SECTION_6_2 IGES + +The IGES interface reads IGES files and translates them to Open CASCADE Technology models. +IGES files produced in accordance with IGES standard versions up to and including version 5.3 can be read. +The interface is able to translate one entity, a group of entities or a whole file. +Before beginning a translation, you can set a range of parameters to manage the translation process. +If you like, you can also check file consistency before translation. + +The IGES interface also translates OCCT models to IGES files. +IGES files produced by this component conform to IGES standard version 5.3. + +Other kinds of data such as colors and names can be read or written +with the help of XDE tools IGESCAFControl_Reader and IGESCAFControl_Writer. + +Please, note: + + * an IGES model is an IGES file that has been loaded into memory. + * an IGES entity is an entity in the IGES normal sense. + * a root entity is the highest level entity of any given type, e.g. type 144 for surfaces and type 186 for solids. Roots are not referenced by other entities. + +It is possible to learn more about the IGES interface from IGES User's guide + +See also: our web site at E-learning and Training. + +@subsection OCCT_TOVW_SECTION_6_3 STEP + +The STEP interface reads STEP files produced in accordance with STEP Application Protocol 214 +(Conformance Class 2 both CD and DIS versions of schema) and translates them +to Open CASCADE Technology models. STEP Application Protocol 203 is also supported. + +The STEP interface also translates OCCT models to STEP files. STEP files that are produced +by this interface conform to STEP AP 203 or AP 214 ( +Conformance Class 2, either CD or DIS version of the schema) depending on the user's option. + +Basic interface reads and writes geometrical, topological STEP data and assembly structures. + +The interface is able to translate one entity, a group of entities or a whole file. + +Other kinds of data such as colors, validation properties, layers, names +and the structure of assemblies can be read or written +with the help of XDE tools - STEPCAFControl_Reader and STEPCAFControl_Writer. + +To choose a translation mode when exporting to a STEP format, use STEPControl_STEPModelType. + +There is a set of parameters that concern the translation and can be set before the beginning of the translation. + +Please, note: +* a STEP model is a STEP file that has been loaded into memory; +* all references to shapes indicate OCCT shapes unless otherwise explicitly stated; +* a root entity is the highest level entity of any given type, i.e. an entity that is not referenced by any other one. + +It is possible to learn more about the STEP interface from STEP User's guide +See also: our web site at E-learning and Training. + +@subsection OCCT_TOVW_SECTION_6_4 STL + +The STL component translates Open CASCADE Technology shapes to STL files. STL (Stereolithography) format is widely used for rapid prototyping. + +As STL files can only include solids described by their mesh structure, +the OCCT shapes to be written must be solids, components of solids or closed shells with a correct orientation. + +Note All references to shapes indicate OCCT shapes unless otherwise explicitly stated. + +Sets of faces or unclosed shells may also be translated to STL format but visualization with foreign viewers may be incorrect. + +@subsection OCCT_TOVW_SECTION_6_5 VRML + +The VRML component translates Open CASCADE Technology shapes to VRML 1.0 files +(Virtual Reality Modeling Language). OCCT shapes may be translated in two representations: +shaded or wireframe. A shaded representation present shapes as sets of triangles +computed by a mesh algorithm while a wireframe representation present shapes as sets of curves. + +As shaded VRML format files only include solids described by their mesh structures, +the OCCT shapes to be written must be solids, components of solids or closed shells with a correct orientation. + +Please, note: + + * all references to shapes indicate OCCT shapes unless otherwise explicitly stated; + * sets of faces or unclosed shells may also be translated to shaded VRML format but visualization with foreign viewers may be incorrect. + +@section OCCT_TOVW_SECTION_7 Application Framework + +The Application Framework uses an associativity engine to simplify the development of a CAD application. +Based on application/document architecture, it does this due to the following features: + + * Application data is handled by the mechanism of attributes + * Attributes may be organized according to your development needs + * Multiple documents can be managed by an application + * Ready-to-use modeling data attributes common to CAD/CAM applications + * Document modification and recomputation + * Data storage services + * A ready-to-use Undo-Redo and Copy-Paste functions + +Since OCAF handles your application structure, your only major development task is the creation +of application-specific data and GUIs. It is the organization of application data +due to which OCAF differs from any other CAD framework. In OCAF, data structures are not shape-driven, +but reference-key driven. In this respect, attributes such as shape data, color, material, +are attached to a deeper invariant structure of a model than the shapes themselves. +Then OCAF organizes and embeds these attributes in a document. +For example, a geometry becomes the value of the Shape attribute, +in the same way as a number is the value of the Integer attribute and a string is the value of the Name attribute. + +OCAF documents are in their turn managed by an OCAF application. + +Please, refer for more details to OCAF User's guide and the OCAF white papers: +* Application Framework +* Distribution of Data through OCAF Tree +* Application Framework Function Mechanism + +See also: our web site at E-learning and Training. + +@subsection OCCT_TOVW_SECTION_7_1 How to start working with OCAF + +To create a useful OCAF-based application, it is necessary to redefine the following +two deferred methods: Formats and ResourcesName + +In the Formats method, it is necessary to add the format +of the documents to be read by the application and which may have been built in other applications. + +For example: + +~~~~ + void myApplication::Formats(TColStd_SequenceOfExtendedString& Formats) + { + Formats.Append(TCollection_ExtendedString ("OCAF-myApplication")); + } +~~~~ + +In the ResourcesName method, you only define the name of the resource file. This +file contains several definitions for the saving and opening mechanisms associated +with each format and calling of the plug-in file. + +~~~~ + Standard_CString myApplication::ResourcesName() + { + return Standard_CString ("Resources"); + } +~~~~ + +To obtain the saving and opening mechanisms, it is necessary to set two environment +variables: CSF_PluginDefaults, which defines the path of the plug-in file and CSF_ResourcesDefault, which defines the resource file: + +~~~~ + SetEnvironmentVariable ( "CSF_ResourcesDefaults",myDirectory); + SetEnvironmentVariable ( "CSF_PluginDefaults",myDirectory); +~~~~ + +The plugin and the resource files of the application will be located in myDirector. +The name of the plugin file must be Plugin. + +Resource File +-------------- + +The resource file describes the documents (type and extension) and +the type of data that the application can manipulate +by identifying the storage and retrieval drivers appropriate for this data. + +Each driver is unique and identified by a GUID generated, for example, with the uuidgen tool in Windows. + +Five drivers are required to use all standard attributes provided within OCAF: + + * the schema driver (ad696002-5b34-11d1-b5ba-00a0c9064368) + * the document storage driver (ad696000-5b34-11d1-b5ba-00a0c9064368) + * the document retrieval driver (ad696001-5b34-11d1-b5ba-00a0c9064368) + * the attribute storage driver (47b0b826-d931-11d1-b5da-00a0c9064368) + * the attribute retrieval driver (47b0b827-d931-11d1-b5da-00a0c9064368) + +These drivers are provided as plug-ins and are located in the PappStdPlugin library. + + +For example, this is a resource file, which declares a new model document OCAF-MyApplication: + +~~~~ +formatlist:OCAF-MyApplication +OCAF-MyApplication.Description: MyApplication Document Version 1.0 +OCAF-MyApplication.FileExtension: sta +OCAF-MyApplication.StoragePlugin: ad696000-5b34-11d1-b5ba-00a0c9064368 +OCAF-MyApplication.RetrievalPlugin: ad696001-5b34-11d1-b5ba-00a0c9064368 +OCAF-MyApplicationSchema: ad696002-5b34-11d1-b5ba-00a0c9064368 +OCAF-MyApplication.AttributeStoragePlugin: 47b0b826-d931-11d1-b5da-00a0c9064368 +OCAF-MyApplication.AttributeRetrievalPlugin: 47b0b827-d931-11d1-b5da-00a0c9064368 +~~~~ + + +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. + +You need at least the FWOSPlugin and the plug-in drivers to run an OCAF application. + +The syntax of each item is Identification.Location Library_Name, where: +* Identification is GUID. +* Location defines the location of the Identification (where its definition is found). +* Library_Name is the name (and path to) the library, where the plug-in is located. + +For example, this is a Plugin file: + +~~~~ +a148e300-5740-11d1-a904-080036aaa103.Location: FWOSPlugin +! base document drivers plugin +ad696000-5b34-11d1-b5ba-00a0c9064368.Location: PAppStdPlugin +ad696001-5b34-11d1-b5ba-00a0c9064368.Location: PAppStdPlugin +ad696002-5b34-11d1-b5ba-00a0c9064368.Location: PAppStdPlugin +47b0b826-d931-11d1-b5da-00a0c9064368.Location: PAppStdPlugin +47b0b827-d931-11d1-b5da-00a0c9064368.Location: PAppStdPlugin +~~~~ + +@subsection OCCT_TOVW_SECTION_7_2 Data Attributes + +The following ready-to-use attributes are provided: + * Shape attributes, which contain shapes and their evolution + * Standard attributes, a collection of common CAD/CAM attributes including: + * Real + * Integer + * Name + * Constrain + * Visualization attributes implement the Application Interactive Services in the context of Open CASCADE Application Framework. + * Function attributes which regenerate any data affected by modifications made in a +document + +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. + + +It is used for keeping and access to topological objects and their evolution. All +topological objects are stored in the one user-protected TNaming_UsedShapes attribute +at the root label of the data framework. This attribute contains map with all topological +shapes, used in this document. + +TNaming_NamedShape attribute can be added to any other attribute. This attribute contains +references (hooks) to shapes from the TNaming_UsedShapes attribute and evolution +of these shapes. TNaming_NamedShape attribute contains a set of pairs of hooks: old +shape and new shape (see the figure below). It allows not only get the topological +shapes by the labels, but also trace evolution of the shapes and correctly resolve +dependent shapes by the changed one. + +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. + +![](/technical_overview/images/technical_overview_shapeattrib.png "") + + +Shape attributes in data framework. +------------------------------- + +Algorithms can dispose sub-shapes of the result shape at the individual +label depending on necessity: + + * If a sub-shape must have some extra attributes (material of each face or color of each edge). In this case a specific sub-shape is placed to the separate label (usually, sub-label of the result shape label) with all attributes of this sub-shape. + * If topological naming is needed, a necessary and sufficient (for selected sub-shapes identification) set of sub-shapes is placed to the child labels of the result shape label. As usual, as far as basic solids and closed shells are concerned, all faces of the shape are disposed. Edges and vertices sub-shapes can be identified as intersection of contiguous faces. Modified/generated shapes may be placed to one named shape and identified as this named shape and source named shape that also can be identified with used algorithms. + + TNaming_NamedShape may contain a few pairs of hooks with the same evolution. In this +case topology shape, which belongs to the named shape, is a compound of new shapes. + +The data model contains both the topology and the hooks, and functions handle both +topological entities and hooks. Consider the case of a box function, which creates +a solid with six faces and six hooks. Each hook is attached to a face. If you want, +you can also have this function create hooks for edges and vertices as well as for +faces. + +Not all functions can define explicit hooks for all topological entities they create, +but all topological entities can be turned into hooks when necessary. This is where +topological naming is necessary. + +Consider the following example. A box defines six hooks for the six faces, but a +protrusion created on a face of the box can only define two hooks, one for the top +face, and one for all the lateral faces. As the basic wire defining the protrusion +may change in the future the protrusion function cannot designate the lateral faces +without ambiguity, their number may change. Figure 6 illustrates this example, faces +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. + +![](/technical_overview/images/technical_overview_occ_0068.png "") + +This structure raises two problems: + + * the value of the face F6 attribute-hook has changed; + * no data can be attached to F7. + +When a hook designates multiple faces like F7-F10 (or the hook on F6 if F6 was split) +it is impossible to attach data to an individual face like F7. + +In fact, the protrusion has a trimmed face F6. As a result, the value of this face +has changed and the current value of the hook attached to it needs to be found. Note +that this face could have been split in two faces (for example if the function had +been a slot) and both new faces would have been attached to the same hook. + + +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. + +To find an attribute attached to a specific label, you use the GUID of the type of +attribute you are looking for. For this, find this information using the method + GetID and the method Find for the label as follows: + +~~~~ + Standard_GUID anID = MyAttributeClass::GetID(); + Standard_Boolean HasAttribute = aLabel.Find(anID,anAttribute); +~~~~ + + +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 + +There are three schemas of persistence, which you can use to store and retrieve OCAF data (documents): + + * Standard persistence schema, compatible with previous OCAF applications + * XmlOcaf persistence, allowing the storage of all OCAF data in XML form + * BinOcaf persistence, allowing the storage of all OCAF data in binary format form + + +All schemes are independent of each other, but they guarantee that the standard OCAF +attributes stored and retrieved by one schema will be storable and retrievable by +the other. Therefore in any OCAF application you can use any persistence schema or +even all three of them. The choice is made by the Format string of stored OCAF documents +or automatically by the file header data - * on retrieval. + +Persistent data storage in OCAF using the Standard package is presented in: + + * Basic Data Storage + * Persistent Collections + +Persistent storage of shapes is presented in the following chapters: + + * Persistent Geometry + * Persistent Topology + +Finally, information about opening and saving persistent data is presented in Standard +Documents. + + +@subsubsection OCCT_TOVW_SECTION_7_2_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 +is running and are not stored permanently. However, the Data Storage module provides +resources, which enable an application to store data on disk as persistent data. + +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 are extensible libraries of elementary classes you +use to define the database schema of your application. They include: +* Unicode (8-bit or 16-bit character type) strings +* Collections of any kind of persistent data such as arrays, stacks, queues, and graphs. + +All persistent classes are derived from the \b Persistent base class, which defines +a unique way of creating and handling persistent objects. You create new persistent +classes by inheriting from this base class. + +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 +of an application. + +For each class of 2D and 3D geometric types, and for the general shape class in the +topological data structure library, there are corresponding persistent class libraries, +which allow you to translate your data with ease. + +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 +drivers. + +The Storage package is used to write and read persistent objects. +These objects are read and written by a retrieval or storage algorithm +( Storage_Schema object) in a container (disk, memory, network ...). +Drivers ( FSD_File objects) assign a physical container for data to be stored or retrieved. + +The standard procedure for an application in reading a container is as follows: + + *open the driver in reading mode, + *call the Read function from the schema, setting the driver as a parameter. This function returns an instance of the Storage_Data class which contains the data being read, + *close the driver. + +The standard procedure for an application in writing a container is as follows: + + *open the driver in writing mode, + *create an instance of the Storage_Data class, then add the persistent data to write with the function AddRoot , + *call the function Write from the schema, setting the driver and the Storage_Data instance as parameters, + *close the driver. + +@subsubsection OCCT_TOVW_SECTION_7_2_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 +of service: + + * persistent strings, + * generic arrays of data, + * commonly used instantiations of arrays. + +Persistent strings are concrete classes that handle sequences of characters based +on both ASCII (normal 8-bit) and Unicode (16-bit) character sets. + +Arrays are generic classes, that is, they can hold a variety of objects not necessarily +inheriting from a unique root class. These arrays can be instantiated with any kind +of storable or persistent object, and then inserted into the persistent data model +of a user application. + +The purpose of these data collections is simply to convert transient data into its +persistent equivalent so that it can be stored in the database. To this end, the +collections are used to create the persistent data model and assure the link with +the database. They do not provide editing or query capabilities because it is more +efficient, within the operative data model of the application, to work with transient +data structures (from the TCollection package). + +For this reason: + + * the persistent strings only provide constructors and functions to convert between transient and persistent strings, and + * the persistent data collections are limited to arrays. In other words, PCollection does not include sequences, lists, queues, sets, stacks and so on (unlike TCollection). + +Persistent string and array classes are found in the PCollection package. +In addition, PColStd package provides standard, +and frequently used, instantiations of persistent arrays, for very simple objects. + +@subsubsection OCCT_TOVW_SECTION_7_2_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 +"world" to the persistent "world". + +Persistent Geometry consists of a set of atomic data models parallel to the geometric +data structures described in the geometry packages. Geometric data models, independent +of each other, can appear within the data model of any application. The system provides +the means to convert each atomic transient data model into a persistent one, but +it does not provide a way for these data models to share data. + +Consequently, you can create a data model using these components, store data in, +and retrieve it from a file or a database, using the geometric components provided +in the transient and persistent "worlds". In other words, you customize the system +by declaring your own objects, and the conversion of the geometric components from +persistent to transient and vice versa is automatically managed for you by the system. + +However, these simple objects cannot be shared within a more complex data model. +To allow data to be shared, you must provide additional tools. + +Persistent Geometry is provided by several packages. + +The PGeom package describes geometric persistent objects in 3D space, such as points, +vectors, positioning systems, curves and surfaces. + +These objects are persistent versions of those provided by the Geom package: for +each type of transient object provided by Geom there is a corresponding type of persistent +object in the PGeom package. In particular the inheritance structure is parallel. + +However the PGeom package does not provide any functions to construct, edit or access +the persistent objects. Instead the objects are manipulated as follows: + + * Persistent objects are constructed by converting the equivalent transient Geom objects. To do this you use the MgtGeom::Translate function. + * Persistent objects created in this way are used to build persistent data structures that are then stored in a file or database. + * When these objects are retrieved from the file or database, they are converted back into the corresponding transient objects from the Geom package. To do this, you use MgtGeom::Translate function. + +In other words, you always edit or query transient data structures within the transient +data model supplied by the session. +Consequently, the documentation for the PGeom package consists simply of a list of available objects. + +The PGeom2d package describes persistent geometric objects in 2D space, such as points, +vectors, positioning systems and curves. This package provides the same type of services +as the PGeom package, but for the 2D geometric objects provided by the Geom2d package. +Conversions are provided by the MgtGeom::Translate function. + +~~~~ +//Create a coordinate system +Handle(Geom_Axis2Placement) aSys; + + +//Create a persistent coordinate PTopoDS_HShape.cdlsystem +Handle(PGeom_Axis2placement) + aPSys = MgtGeom::Translate(aSys); + +//Restore a transient coordinate system +Handle(PGeom_Axis2Placement) aPSys; + +Handle(Geom_Axis2Placement) + aSys = MgtGeom::Translate(aPSys); +~~~~ + + +@subsubsection OCCT_TOVW_SECTION_7_2_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". + +Persistent Topology is based on the BRep concrete data model provided by the topology packages. Unlike the components of the Persistent Geometry package, topological components can be fully shared within a single model, as well as between several models. + +Each topological component is considered to be a shape: a TopoDS_Shape object. The system's capacity to convert a transient shape into a persistent shape and vice-versa applies to all objects, irrespective of their complexity: vertex, edge, wire, face, shell, solid, and so on. + +When a user creates a data model using BRep shapes, he uses the conversion functions that the system provides to store the data in, and retrieve it from the database. The data can also be shared. + +Persistent Topology is provided by several packages. + +The PTopoDS package describes the persistent data model associated with any BRep shape; it is the persistent version of any shape of type TopoDS_Shape. As is the case for persistent geometric models, this data structure is never edited or queried, it is simply stored in or retrieved from the database. It is created or converted by the MgtBRep::Translate function. + +The MgtBRepAbs and PTColStd packages provide tools used by the conversion functions of topological objects. + +~~~~ +//Create a shape +TopoDS_Shape aShape; + +//Create a persistent shape +PtColStd_DoubleTransientPersistentMap aMap; + +Handle(PTopoDS_HShape) aPShape = + aMap.Bind2(MgtBRep::Translate + aShape,aMap,MgtBRepAbs_WithTriangle)); + +aPShape.Nullify(); + +//Restore a transient shape +Handle(PTopoDS_HShape) aPShape; + +Handle(TopoDS_HShape) aShape = + aMap.Bind1(MgtBRep::Translate + (aPShape,aMap,MgtBRepAbs_WithTriangle)); + +aShape.Nullify(); +~~~~ + +@subsubsection OCCT_TOVW_SECTION_7_2_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 TDocStd_Application +which manages creation, storage and retrieval of documents. + +You can implement undo and redo in your document, and refer from the data framework +of one document to that of another one. This is done by means of external link attributes, +which store the path and the entry of external links. To sum up, standard documents +alone provide access to the data framework. They also allow you to: +*Update external links; +*Manage the saving and opening of data; +*Manage undo/redo functionality. + +@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 libname.so .. under any of the filenames .." +~~~~ + +When this happens, check your PATH under Windows, LD_LIBRARY_PATH under UNIX , + SHLIB_PATH under HP-UX or LIBPATH under IBM AIX . +It should contain the path where the required dynamic library is located. + +Running Draw under Windows +--------------------------- + +When running DRAWEXE 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 DRAWHOME and DRAWDEFAULT, 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 Fatal error during graphic initialization message when running +an Open CASCADE Technology based application, or if the application crashes +without displaying error messages, you must set the environment variable CSF_GRAPHICSHR as follows: + + * On Windows, if we suppose that OCCT is installed in D:\OpenCASCADE6.3.0 + +~~~~ + Set CSF_GraphicShr= D:\OpenCASCADE6.3.1\ros\win32\bin\TkOpenGl.dll +~~~~ + + * On Linux or Unix, if we suppose that OCCT is installed in .../mydisk/ OpenCASCADE6.3.0 + +~~~~ + 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 +of C++ objects. In this context, memory allocation and de-allocation standard functions +are not suited to the system's requirements and for this reason a specialized Memory +Manager is implemented into Open CASCADE Technology. The Memory Manager is based +on the following principles: + + * 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 +------------------- +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 the application never calls the delete +operator explicitly. To benefit from the memory manager in OCCT, transient classes +must inherit from TShared. The principle of allocation is as follows: + +~~~~ + 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 + } + // Here, H1 has no reference but the 48 bytes of memory are kept. + Handle (TColStd_HSequenceOfInteger) H1 = new TColStd_HSequenceOfInteger; + // Here, H1 has one reference and corresponds to the preceding 48 bytes of + // 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. + +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 +------------------ + +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 + +You can create a class manipulated by handle even if you do not use CDL (Open CASCADE Definition Language). +To do that you have to use the Define_Standard_Handle macro which is defined in the include file Standard_DefineHandle.hxx. + +Here is an example which shows how to define a class SamplePoint manipulated by handle. + +~~~~ + +Sample_Point.hxx: +--------------- + + #ifndef _Sample_Point_HeaderFile + #define _Sample_Point_HeaderFile + #ifndef _Standard_Macro_HeaderFile + #include + #endif + #include + #include + // Handle definition + // + + DEFINE_STANDARD_HANDLE(Sample_Point,MMgt_TShared) + class Sample_Point: public MMgt_TShared { + public: + Sample_Point(); + Sample_Point(const Standard_Real, const + Standard_Real); + void SetX(const Standard_Real x) { + myX = x; + } + void SetY(const Standard_Real y) { + myY = y; + } + Standard_Real X() const { + return myX; + } + Standard_Real Y() const { + return myY; + } + // some methods like DynamicType() or + IsKind() + // + DEFINE_STANDARD_RTTI(Sample_Point) + private: + Standard_Real myX; + Standard_Real myY; + }; + #endif + +Sample_Point.cxx: +---------------- + + #include + + // Implementation of Handle and type mgt + + IMPLEMENT_STANDARD_HANDLE(Sample_Point,MMgt_TShared) + IMPLEMENT_STANDARD_RTTI(Sample_Point,MMgt_TShared) + + // For ancestors, we add a IMPLEMENT_STANDARD_SUPERTYPE and + // a IMPLEMENT_STANDARD_SUPERTYPE_ARRAY_ENTRY macro. + // We must respect the order: from the direct ancestor class to the base class. + + IMPLEMENT_STANDARD_TYPE(Sample_Point) + IMPLEMENT_STANDARD_SUPERTYPE(MMgt_TShared) + IMPLEMENT_STANDARD_SUPERTYPE(Standard_Transient) + IMPLEMENT_STANDARD_SUPERTYPE_ARRAY() + IMPLEMENT_STANDARD_SUPERTYPE_ARRAY_ENTRY(MMgt_TShared) + IMPLEMENT_STANDARD_SUPERTYPE_ARRAY_ENTRY(Standard_Transient) + IMPLEMENT_STANDARD_SUPERTYPE_ARRAY_END() + IMPLEMENT_STANDARD_TYPE_END(Sample_Point) + + // Constructors implementation + + Sample_Point::Sample_Point(const + Standard_Real x, const Standard_Real y) + { + myX = x; + myY = y; + } + Sample_Point::Sample_Point() + { + myX = 0.0; + myY = 0.0; + } +~~~~ + +@subsection OCCT_TOVW_SECTION_8_3 When is it necessary to use a handle? + +When designing an object, the user is faced with the choice of manipulating that +object by value, or by handle. + + * If your object may have a long lifetime within the application and you want to make multiple references to it, it would be preferable to manipulate this object with a handle. The memory for the object will be allocated on the heap. The handle which points to that memory is a light object which can be rapidly passed in argument. This avoids the penalty of copying a large object. + * If your object will have a limited lifetime, for example, used within a single algorithm, it would be preferable to manipulate this object by value, non-regarding its size, because this object is allocated on the stack and the allocation and de-allocation of memory is extremely rapid, which avoids the implicit calls to 'new' and 'delete' occasioned by allocation on the heap. + * Finally, if an object will be created only once during, but will exist throughout the lifetime of the application, the best choice may be a class manipulated by handle or a value declared as a global variable. + + +@subsection OCCT_TOVW_SECTION_8_4 How to cast shape handle to void + +You can easily cast a reference to the handle object to void* by defining the following: + +~~~~ + void *pointer; + Handle(Some_class) aHandle; + // Here only a pointer will be copied + Pointer = &aHandle; + // Here the Handle object will be copied + aHandle = * (Handle(Some_Class) *)pointer; +~~~~ + +@subsection OCCT_TOVW_SECTION_8_5 How to test correct ending of OCCT algorithms + +Generally OCCT algorithms implement IsDone method, which returns true +if computation has been performed successfully from beginning to end or false if computation has failed. + +When IsDone returns true, the computation is successful regarding +to the input data, but it does not necessary mean that you get a result. For example, if +you perform a cut algorithm between two shapes without any common part, the IsDone +method will return true, but the result will be empty. + +So, in some cases, it can be necessary to analyse the structure of a result before +using it again in following computations. These tests are not done systematically +into algorithms to get faster computations. The application performs necessary tests +depending on the context. + +@subsection OCCT_TOVW_SECTION_8_6 How to cut, copy and paste inside a document + +To cut, copy and paste inside a document, you must use the CopyLabel class from the TDF package. +In fact, you must define a Label which contains the temporary value a cut or +copy operation (say, in Lab_Clipboard). You must also define two other labels: + +* One containing the data (e.g. Lab_source) +* One for the destination of the copy (e.g. Lab_ Target ) + +~~~~ + Copy = copy (Lab_Source => Lab_Clipboard) + Cut = copy + Lab_Source.ForgetAll() // command clear the contents of LabelSource. + Paste = copy (Lab_Clipboard => Lab_target) +~~~~ + +So we need a tool to copy all (or a part) of the content of a label and its sub-label, +to another place defined by a label. + +~~~~ + TDF_CopyLabel aCopy; + TDF_IDFilter aFilter (Standard_False); + + //Don't copy TDataStd_TreeNode attribute + + aFilter.Ignore(TDataStd_TreeNode::GetDefaultTreeID()); + aCopy.Load(aSource, aTarget); aCopy.UseFilter(aFilter); aCopy.Perform(); + + // copy the data structure to clipboard + + return aCopy.IsDone(); } +~~~~ + +The filter is used to forbid copying a specified type of attribute. +You can also have a look at TDF_Closure*, +which can be useful to determine the dependencies of the part you want to cut from the document. \ No newline at end of file diff --git a/dox/user_guides/draw_test_harness/draw_test_harness.md b/dox/user_guides/draw_test_harness/draw_test_harness.md new file mode 100644 index 0000000000..85ed40da9f --- /dev/null +++ b/dox/user_guides/draw_test_harness/draw_test_harness.md @@ -0,0 +1,7457 @@ +Draw Test Harness {#user_guides__test_harness} +=============================== + +@section occt_2142243456_1775316760 Introduction + +This manual explains how to use Draw, the test harness for Open CASCADE Technology (**OCCT**). It provides basic documentation on using Draw. For advanced information on Draw and its applications, see our offerings on our web site at http://www.opencascade.org/support/training + +Draw is a command interpreter based on TCL and a graphical system used to test and demonstrate Open CASCADE Technology modeling libraries. + + +@subsection occt_2142243456_17753167601 Overview + +Draw is a test harness for Open CASCADE Technology. It provides a flexible and easy to use means of testing and demonstrating the OCCT modeling libraries. + +Draw can be used interactively to create, display and modify objects such as curves, surfaces and topological shapes. + +Scripts may be written to customize Draw and perform tests. New types of objects and new commands may be added using the C++ programing language. + +Draw consists of: + + * A command interpreter based on the TCL command language. + * A 3d graphic viewer based on the X system. + * A basic set of commands covering scripts, variables and graphics. + * A set of geometric commands allowing the user to create and modify curves and surfaces and to use OCCT geometry algorithms. This set of commands is optional. + * A set of topological commands allowing the user to create and modify BRep shapes and to use the OCCT topology algorithms. + + +There is also a set of commands for each delivery unit in the modeling libraries: + +GEOMETRY, TOPOLOGY, ADVALGOS, GRAPHIC, PRESENTATION. + + +@subsection occt_2142243456_17753167602 Contents of this documentation + +This documentation describes: + + * The command language. + * The basic set of commands. + * The graphical commands. + * The Geometry set of commands. + * The Topology set of commands. + +This document does not describe other sets of commands and does not explain how to extend Draw using C++. + +This document is a reference manual. It contains a full description of each command. All descriptions have the format illustrated below for the exit command. +**Example** + +**exit** +Syntax: exit + +Terminates the Draw, TCL session. If the commands are read from a file using the source command, this will terminate the file. + +**Example** + +# this is a very short example +exit + + + +@subsection occt_2142243456_17753167603 Getting started + +Install Draw and launch Emacs. Get a command line in Emacs using *Esc x *and key in *woksh*. + +Since version 5.1.1 Open CASCADE Technology introduces a single executable in the DRAW Test Harness that supersedes the several separate executables that existed before. Respectively the user does not need to have his own executables to activate his custom commands. All he needs to do is to implement the commands themselves, they will be activated in the common executable. This executable is now called **DRAWEXE**. + +Commands grouped in toolkits can now be loaded at run-time thereby implementing dynamically loaded plug-ins. Thus, the user can work only with those commands that suit his needs adding these commands dynamically without leaving the Test Harness session. + +Declaration of available plug-ins is done through the special resource file(s). The **pload** command loads the plug-in in accordance with the specified resource file and activates the commands implemented in the plug-in. +The whole process of using new advantages of the plug-in mechanism as well as instructions for extending Test Harness are described below. + + +@subsubsection occt_2142243456_177531676031 Launching DRAW Test Harness + +Test Harness executable DRAWEXE is located in the $CASROOT/platform/bin directory (where platform is win32 for Windows, SunOS for Sun Solaris and Linux for Linux operating systems). Prior to launching it is important to make sure the environment is correctly set-up (usually this is done automatically after the installation process on Windows or after launching specific scripts on Unix/Linux) - refer to Technical Documentation for details. + + +@subsubsection occt_2142243456_177531676032 Plug-in resource file + +Open CASCADE Technology is shipped with the DrawPlugin resource file located in the $CASROOT/src/DrawResources directory. +The format of the file is compliant with standard Open CASCADE Technology resource files (see the Resource_Manager.cdl file for details). + +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 + +DCAF               : TKDCAF +AISV               : TKViewerTest +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@subsubsection occt_2142243456_177531676033 Activation of commands implemented in the plug-in + +To load a plug-in declared in the resource file and to activate the commands the following command must be used in Test Harness: + +pload [-PluginFileName] [[Key1] [Key2]...], where: + +-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. +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 +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). +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_177531676034 Mapping between former separate Test Harness executables and the new plug-ins + +Before version 5.1.1 Open CASCADE Technology used to be shipped with several separate executables providing different sets of commands. The following table represents the mapping between former executables and new plug-ins. + + +For instance, in order to activate commands available in the former AISViewer executable, now it is enough to use the command pload VISUALIZATION. + +When you have the tclsh prompt, key in the library references: + +*wokcd MDL:k1deb:ref:DRAWEXE*. At the prompt, key in the environment +(*@@ -setenv *in Unix). Draw displays a prompt. Here is a sample session: + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# create two views, one 2d the other axonometric. Use either the command line or the Draw taskbar (*Views/av2d*). +Draw[1]av2d + +# create a 2d circle +Draw[2]circle c 0 0 1 0 5 +# trim the circle and dump it +Draw[3] trim c c 0 pi/2 +Draw[4] dump c +==***** Dump of c ***** +==Trimmed curve +==Parameters : 0 1.5707963267949 +==Basis curve : +==Circle +== Center :0, 0 +== XAxis :1, 0 +== YAxis :-0, 1 +== Radius :5 +# make a 3d circle from it, and turn it into a bspline +Draw[6] to3d c1 c +Draw[7] fit +Draw[8] convert c2 c1 +Draw[9] dump c2 +***** Dump of c2 ***** +BSplineCurve rational +Degree 2, 3 Poles, 2 Knots +Poles : +1 : 5, 0, 0 1 +2 : 5, 5, 0 0.707106781186548 +3 : 3.06161699786838e-16, 5, 0 1 +Knots : +1 : 0 3 +2 : 1.5707963267949 3 + +# make a surface of revolution from the spline +Draw[10] fit +Draw[11] help rev +reverse : reverse name ... +revsurf : revsurf name curvename x y z dx dy dz +# here you must click on the curve with the mouse +Draw[12] revsurf s . 5 5 0 -1 1 0 +Pick an object +Draw[13] fit +# rotate the view +Draw[14] u +Draw[15] erase c +# make a bspline surface and intersect with a plane +Draw[20] convert s s +Draw[21] fit +Draw[22] plane p 5 5 5 1 1 1 1 0 0 +Draw[23] intersect c p s +# pick one of the intersection curves +# you may get c_2 onstead of c_1 +Draw[24] whatis . +Pick an object +c_1 is a a 3d curve +Draw[25] clear +Draw[27] rename c_1 c +Draw[28] fit +# save the curve, use datadir (p. 32) to specify the +directory you want to save your file in. +Draw[29] save c +Draw[30] exit +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +In this example some geometrical operations have been performed. Objects displayed and written to files. +@section occt_2142243456_1668530729 The Command Language + + + + + +@subsection occt_2142243456_16685307294 Overview + +The command language used in Draw is Tcl. Tcl[1] documentation such as ;TCL and the TK Toolkit; by John K. Ousterhout (Addison-Wesley) will prove useful if you intend to use Draw extensively. + +This chapter is designed to give you a short outline of both the TCL language and some extensions included in Draw. The following topics are covered: + + * Syntax of the TCL language. + * Accessing variables in TCL and Draw. + * Control structures. + * Procedures. + +@subsection occt_2142243456_16685307295 Syntax of TCL + +TCL is an interpreted command language, not a structured language like C, Pascal, LISP or Basic. It uses a shell similar to that of csh. TCL is, however, easier to use than csh because control structures and procedures are easier to define. As well, because TCL does not assign a process to each command, it is faster than csh. + +The basic program for TCL is a script. A script consists of one or more commands. Commands are separated by new lines or semicolons. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +set a 24 +set b 15 +set a 25; set b 15 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Each command consists of one or more *words*; the first word is the name of a command and additional words are arguments to that command. + +Words are separated by spaces or tabs. In the preceding example each of the four commands has three words. A command may contain any number of words and each word is a string of arbitrary length. + +The evaluation of a command by TCL is done in two steps. In the first step, the command is parsed and broken into words. Some substitutions are also performed. In the second step, the command procedure corresponding to the first word is called and the other words are interpreted as arguments. In the first step, there is only string manipulation, The words only acquire *meaning* in the second step by the command procedure. + +The following substitutions are performed by TCL: + +**1. **Variable substitution is triggered by the $ character (as with csh), the content of the variable is substitued; { } may be used as in csh to enclose the name of the variable. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# set a variable value +set file documentation +puts $file #to display file contents on the screen + +# a simple substitution, set psfile to documentation.ps +set psfile $file.ps +puts $psfile + +# another substitution, set pfile to documentationPS +set pfile ${file}PS + +# a last one, +# delete files NEWdocumentation and OLDdocumentation +foreach prefix {NEW OLD} {rm $prefix$file} +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +**2. **Command substitution is triggered by the [ ] characters. The brackets must enclose a valid script. The script is evaluated and the result is substituted. +Compare command construction in csh. + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +set degree 30 +set pi 3.14159265 +# expr is a command evaluating a numeric expression +set radian [expr $pi*$degree/180] +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +**3. **Backslash substitution is triggered by the backslash character. It is used to insert special characters like $, [ , ] , etc. It is also useful to insert a new line, a backslash terminated line is continued on the following line. +TCL uses two forms of *quoting* to prevent substitution and word breaking. + +**4. **Double quote *quoting* enables the definition of a string with space and tabs as a single word. Substitutions are still performed inside the inverted commas ; ;. + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# set msg to ;the price is 12.00; +set price 12.00 +set msg ;the price is $price; +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +**5. **Braces *quoting* prevents all substitutions. Braces are also nested. The main use of braces is to defer evaluation when defining procedures and control structures. Braces are used for a clearer presentation of TCL scripts on several lines. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +set x 0 +# this will loop for ever +# because while argument is ;0 3; +while ;$x 3; {set x [expr $x+1]} +# this will terminate as expected because +# while argument is {$x 3} +while {$x 3} {set x [expr $x+1]} +# this can be written also +while {$x 3} { +set x [expr $x+1] +} +# the following cannot be written +# because while requires two arguments +while {$x 3} +{ +set x [expr $x+1] +} +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Comments start with a # character as the first non-blank character in a command. To add a comment at the end of the line, the comment must be preceded by a semi-colon to end the preceding command. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# This is a comment +set a 1 # this is not a comment +set b 1; # this is a comment +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The number of words is never changed by substitution when parsing in TCL. For example, the result of a substitution is always a single word. This is different from csh but convenient as the behavior of the parser is more predictable. It may sometimes be necessary to force a second round of parsing. **eval **accomplishes this: it accepts several arguments, concatenates them and executes the resulting script. + + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +# I want to delete two files + +set files ;foo bar; + +# this will fail because rm will receive only one argument +# and complain that ;foo bar; does not exit + +exec rm $files + +# a second evaluation will do it +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@subsection occt_2142243456_16685307296 Accessing variables in TCL and Draw + +TCL variables have only string values. Note that even numeric values are stored as string literals, and computations using the **expr **command start by parsing the strings. Draw, however, requires variables with other kinds of values such as curves, surfaces or topological shapes. + +TCL provides a mechanism to link user data to variables. Using this functionality, Draw defines its variables as TCL variables with associated data. + +The string value of a Draw variable is meaningless. It is usually set to the name of the variable itself. Consequently, preceding a Draw variable with a *$ *does not change the result of a command. The content of a Draw variable is accessed using appropriate commands. + +There are many kinds of Draw variables, and new ones may be added with C++. Geometric and topological variables are described below. + +Draw numeric variables can be used within an expression anywhere a Draw command requires a numeric value. The **expr **command is useless in this case as the variables are stored not as strings but as floating point values. + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# dset is used for numeric variables +# pi is a predefined Draw variable +dset angle pi/3 radius 10 +point p radius*cos(angle) radius*sin(angle) 0 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +It is recommended that you use TCL variables only for strings and Draw for numerals. That way, you will avoid the **expr **command. As a rule, Geometry and Topology require numbers but no strings. + +@subsubsection occt_2142243456_166853072961 set, unset + +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. + +Without a value, **set **returns the content of the variable. + +**unset **deletes variables. It is is also used to delete Draw variables. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +set a ;Hello world; +set b ;Goodbye; +set a +== ;Hello world; +unset a b +set a +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +

NOTE

+*The set command can set only one variable, unlike the dset command.* + + +See also: **dset**, **dval** + + +@subsubsection occt_2142243456_166853072962 dset, dval + +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. + +**dval **evaluates an expression containing Draw numeric variables and returns the result as a string, even in the case of a single variable. This is not used in Draw commands as these usually interpret the expression. It is used for basic TCL commands expecting strings. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# z is set to 0 +dset x 10 y 15 z +== 0 + +# no $ required for Draw commands +point p x y z + +# *puts* prints a string +puts ;x = [dval x], cos(x/pi) = [dval cos(x/pi)]; +== x = 10, cos(x/pi) = -0.99913874099467914 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +

NOTE

+*In TCL, parentheses are not considered to be special characters. Do not forget to quote an expression if it contains spaces in order to avoid parsing different words. (a + b) is parsed as three words:;(a + b); or (a+b) are correct.* + +See also: **set**, **unset** + + + +@subsection occt_2142243456_16685307297 lists + +TCL uses lists. A list is a string containing elements separated by spaces or tabs. If the string contains braces, the braced part accounts as one element. + +This allows you to insert lists within lists. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# a list of 3 strings +;a b c; + +# a list of two strings the first is a list of 2 +;{a b} c; +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Many TCL commands return lists and **foreach **is a useful way to create loops on list elements. + +@subsubsection occt_2142243456_166853072971 Control Structures + +TCL allows looping using control structures. The control structures are implemented by commands and their syntax is very similar to that of their C counterparts (**if**, **while**, **switch**, etc.). In this case, there are two main differences between TCL and C: + +2. You use braces instead of parentheses to enclose conditions. +3. You do not start the script on the next line of your command. + + +@subsubsection occt_2142243456_166853072911 if + +Syntax       if condition script [elseif script .... else script] + +**If **evaluates the condition and the script to see whether the condition is true. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +if {$x 0} { +puts ;positive; +} elseif {$x == 0} { +puts ;null; +} else { +puts ;negative; +} +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@subsubsection occt_2142243456_166853072912 while, for, foreach + +Syntax:                  while condition script +for init condition reinit script +foreach varname list script + +The three loop structures are similar to their C or csh equivalent. It is important to use braces to delay evaluation. **foreach **will assign the elements of the list to the variable before evaluating the script. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# while example +dset x 1.1 +while {[dval x] 100} { + circle c 0 0 x + dset x x*x +} +# for example +# incr var d, increments a variable of d (default 1) +for {set i 0} {$i 10} {incr i} { + dset angle $i*pi/10 + point p$i cos(angle0 sin(angle) 0 +} +# foreach example +foreach object {crapo tomson lucas} {display $object} +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +See also: **break**, **continue** + + +@subsubsection occt_2142243456_166853072913 break, continue + +Syntax:                  break +continue + +Within loops, the **break **and **continue **commands have the same effect as in C. + +**break **interrupts the innermost loop and **continue **jumps to the next iteration. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# search the index for which t$i has value ;secret; +for {set i 1} {$i = 100} {incr i} { + if {[set t$i] == ;secret;} break; +} +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +@subsection occt_2142243456_16685307292 Procedures + +TCL can be extended by defining procedures using the **proc **command, which sets up a context of local variables, binds arguments and executes a TCL script. + +The only problematic aspect of procedures is that variables are strictly local, and as they are implicitly created when used, it may be difficult to detect errors. + +There are two means of accessing a variable outside the scope of the current procedures: **global **declares a global variable (a variable outside all procedures); **upvar **accesses a variable in the scope of the caller. Since arguments in TCL are always string values, the only way to pass Draw variables is by reference, i.e. passing the name of the variable and using the **upvar **command as in the following examples. + +As TCL is not a strongly typed language it is very difficult to detect programing errors and debugging can be tedious. TCL procedures are, of course, not designed for large scale software development but for testing and simple command or interactive writing. + + +@subsubsection occt_2142243456_166853072921 proc + +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. + +**return **gives a return value to the procedure. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# simple procedure +proc hello {} { + puts ;hello world; +} +# procedure with arguments and default values +proc distance {x1 y1 {x2 0} {y2 0}} { + set d [expr (x2-x1)*(x2-x1) + (y2-y1)*(y2-y1)] + return [expr sqrt(d)] +} +proc fact n { + if {$n == 0} {return 1} else { + return [expr n*[fact [expr n -1]]] + } +} +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +See also: **global**, **upvar** + + +@subsubsection occt_2142243456_166853072922 global, upvar + +Syntax:                  global varname [varname ...] +upvar varname localname [varname localname ...] + +**global **accesses high level variables. Unlike C, global variables are not visible in procedures. + +**upvar **gives a local name to a variable in the caller scope. This is useful when an argument is the name of a variable instead of a value. This is a call by reference and is the only way to use Draw variables as arguments. + +

NOTE

+*Note in the following examplesthat the $ character is always* +*necessarily used to access the arguments.* +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# convert degree to radian +# pi is a global variable +proc deg2rad (degree} { + return [dval pi*$degree/2.] +} +# create line with a point and an angle +proc linang {linename x y angle} { + upvar linename l + line l $x $y cos($angle) sin($angle) +} +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@section occt_2142243456_967049381 Basic Commands + +This chapter describes all the commands defined in the basic Draw package. Some are TCL commands, but most of them have been formulated in Draw. These commands are found in all Draw applications. The commands are grouped into four sections: + + * General commands, which are used for Draw and TCL management. + * Variable commands, which are used to manage Draw variables such as storing and dumping. + * Graphic commands, which are used to manage the graphic system, and so pertain to views. + * Variable display commands, which are used to manage the display of objects within given views. + +Note that Draw also features a GUI taskbar providing an alternative way to give certain general, graphic and display commands + + + +@subsection occt_2142243456_9670493811 General commands + +This section describes several useful commands: **help **to get information, **source **to eval a script from a file, **spy **to capture the commands in a file, **cpulimit **to limit the process cpu time, **wait **to waste some time, **chrono **to time commands. + + +@subsubsection occt_2142243456_96704938111 help + +Syntax:                  help [command [helpstring group]] + +Provides help or modifies the help information. + +**help **without arguments lists all groups and the commands in each group. + +Specifying the command returns its syntax and in some cases, information on the command, The joker,*, is automatically added at the end so that all completing commands are returned as well. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# Gives help on all commands starting with *a* +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +@subsubsection occt_2142243456_96704938112 source + +Syntax:                  source filename + +Executes a file. + +The **exit **command will terminate the file. + +See also: exit + + +@subsubsection occt_2142243456_96704938113 spy + +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. + +The file created by **spy **can be executed with the **source **command. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# all commands will be saved in the file ;session; +spy session +# the file ;session; is closed and commands are not saved +spy +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +See also: **source** + + +@subsubsection occt_2142243456_96704938114 cpulimit + +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** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +#limit cpu to one hour +cpulimit 3600 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@subsubsection occt_2142243456_96704938115 wait + +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. + +
Example
+ +# You have ten seconds ... +wait + +@subsubsection occt_2142243456_96704938116 chrono + +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. + +With arguments, **chrono **is used to manage activated chronometers. You can perform the following actions with a chronometer. + + * run the chronometer (start). + * stop the chronometer (stop). + * reset the chronometer to 0 (reset). + * display the current time (show). + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +chrono +==Chronometers activated. +ptorus t 20 5 +==Elapsed time: 0 Hours 0 Minutes 0.0318 Seconds +==CPU user time: 0.01 seconds +==CPU system time: 0 seconds +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@subsection occt_2142243456_9670493812  Variable management commands + +@subsubsection occt_2142243456_96704938121 isdraw, directory + +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. +Use **directory **to return a list of all Draw global variables matching a pattern. + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +set a 1 +isdraw a +=== 0 + +dset a 1 +isdraw a +=== 1 + +circle c 0 0 1 0 5 +isdraw c +=== 1 + +# to destroy all Draw objects with name containing curve +foreach var [directory *curve*] {unset $var} +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +See also: **whatis** + + +@subsubsection occt_2142243456_96704938122 whatis, dump + +Syntax:                  whatis varname [varname ...] +dump varname [varname ...] + +**whatis **returns short information about a Draw variable. This is usually the type name. + +**dump **returns a brief type description, the coordinates, and if need be, the parameters of a Draw variable. + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +circle c 0 0 1 0 5 +whatis c +c is a 2d curve + +dump c + +***** Dump of c ***** +Circle +Center :0, 0 +XAxis :1, 0 +YAxis :-0, 1 +Radius :5 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +

NOTE

+*The behavior of whatis on other variables (not Draw) is not* +*excellent.* + + +@subsubsection occt_2142243456_96704938123 rename, copy + +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. + +**copy **creates a new variable with a copy of the content of an existing variable. The exact behavior of **copy **is type dependent; in the case of certain topological variables, the content may still be shared. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +circle c1 0 0 1 0 5 +rename c1 c2 + +# curves are copied, c2 will not be modified +copy c2 c3 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@subsubsection occt_2142243456_96704938124 datadir, save, restore + +Syntax:                  datadir [directory] +save variable [filename] +restore filename [variablename] + +**datadir **without arguments prints the path of the current data directory. +**datadir **with an argument sets the data directory path. +If the path starts with a dot (.) only the last directory name will be changed in the path. + +**save **writes a file in the data directory with the content of a variable. By default the name of the file is the name of the variable. To give a different name use a second argument. + +**restore **reads the content of a file in the data directory in a local variable. By default, the name of the variable is the name of the file. To give a different name, use a second argument. + +The exact content of the file is type-dependent. They are usually ASCII files and so, architecture independent. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# note how TCL accesses shell environment variables +# using $env() +datadir +==. + +datadir $env(WBCONTAINER)/data/default +==/adv_20/BAG/data/default + +box b 10 20 30 +save b theBox +==/adv_20/BAG/data/default/theBox + +# when TCL does not find a command it tries a shell command +ls [datadir] +== theBox + +restore theBox +== theBox +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +@subsection occt_2142243456_9670493813 User defined commands + +DrawTrSurf provides commands to create and display a Draw **geometric **variable from a Geom_Geometry object and also get a Geom_Geometry object from a Draw geometric variable name. + +DBRep provides commands to create and display a Draw **topological **variable from a TopoDS_Shape object and also get a TopoDS_Shape object from a Draw topological variable name. + +@subsubsection occt_2142243456_96704938131 set + +**DrawTrSurf Package:** +Syntax: + +void Set(Standard_CString& Name,const gp_Pnt& G) ; +void Set(Standard_CString& Name,const gp_Pnt2d& G) ; +void Set(Standard_CString& Name, +const Handle(Geom_Geometry)& G) ; +void Set(Standard_CString& Name, +const Handle(Geom2d_Curve)& C) ; +void Set(Standard_CString& Name, +const Handle(Poly_Triangulation)& T) ; +void Set(Standard_CString& Name, +const Handle(Poly_Polygon3D)& P) ; +void Set(Standard_CString& Name, +const Handle(Poly_Polygon2D)& P) ; + +**DBRep Package:** +Syntax: + +void Set(const Standard_CString Name, +const TopoDS_Shape& S) ; + +**Example: DrawTrSurf** + +Handle(Geom2d_Circle) C1 = new Geom2d_Circle +(gce_MakeCirc2d (gp_Pnt2d(50,0,) 25)); +DrawTrSurf::Set(char*, C1); + +**Example: DBRep** + +TopoDS_Solid B; +B = BRepPrimAPI_MakeBox (10,10,10); +DBRep::Set(char*,B); + +See also: **get** + +@subsubsection occt_2142243456_96704938132 get + +**DrawTrSurf Package:** +Syntax: + +Handle_Geom_Geometry Get(Standard_CString& Name) ; + +**DBRep Package:** +Syntax: + +TopoDS_Shape Get(Standard_CString& Name, +const TopAbs_ShapeEnum Typ = TopAbs_SHAPE, +const Standard_Boolean Complain += Standard_True) ; +**Example: DrawTrSurf** + +Standard_Integer MyCommand +(Draw_Interpretor& theCommands, +Standard_Integer argc, char** argv) +{...... +// Creation of a Geom_Geometry from a Draw geometric +// name +Handle (Geom_Geometry) aGeom= DrawTrSurf::Get(argv[1]); +} + +**Example: DBRep** + +Standard_Integer MyCommand +(Draw_Interpretor& theCommands, +Standard_Integer argc, char** argv) +{...... +// Creation of a TopoDS_Shape from a Draw topological +// name +TopoDS_Solid B = DBRep::Get(argv[1]); +} +See also: **set** + +@section occt_2142243456_445622066 Graphic Commands + +Graphic commands are used to manage the Draw graphic system. Draw provides a 2d and a 3d viewer with up to 30 views. Views are numbered and the index of the view is displayed in the window’s title. Objects are displayed in all 2d views or in all 3d views, depending on their type. 2d objects can only be viewed in 2d views while 3d objects – only in 3d views correspondingly. + +@subsection occt_2142243456_4456220661 Axonometric viewer + +@subsubsection occt_2142243456_44562206611 view, delete + +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. + +As a rule it is far simpler either to use the procedures **axo**, **top**, **left **or to click on the desired view type in the menu under *Views *in the taskbar.. + +**delete **deletes a view. If no index is given, all the views are deleted. + +Type selects from the following range: + + * AXON: Axonometric view + * PERS: Perspective view + * +X+Y: View on both axes (i.e. a top view), other codes are -X+Y, +Y-Z etc. + * -2D- : 2d view + +The index, the type, the current zoom are displayed in the window title . +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# this is the content of the mu4 procedure +proc mu4 {} { +delete +view 1 +X+Z 320 20 400 400 +view 2 +X+Y 320 450 400 400 +view 3 +Y+Z 728 20 400 400 +view 4 AXON 728 450 400 400 +} +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +See also: **axo, pers, top, bottom, left, right, front, back, mu4, v2d, av2d, smallview** + +@subsubsection occt_2142243456_44562206612  axo, pers, top, ... + +Syntax:      axo +pers +... +smallview type + +All these commands are procedures used to define standard screen layout. They delete all existing views and create new ones. The layout usually complies with the European convention, i.e. a top view is under a front view. + + * **axo **creates a large window axonometric view. + * **pers **creates a large window perspective view. + * **top**, **bottom**, **left**, **right**, **front**, **back **create a large window axis view + * **mu4 **creates four small window viewsview: front, left, top and axo. + * **v2d**: creates a large window 2d view. + * **av2d **creates two small window views, one 2d and one axo +**smallview **creates a view at the bottom right of the screen of the given type. + +See also: **view**, **delete** + + +@subsubsection occt_2142243456_44562206613 mu, md, 2dmu, 2dmd, zoom, 2dzoom + +Syntax:                  mu [index] value +2dmu [index] value +zoom [index] value +wzoom + +**mu **(magnify up) increases the zoom in one or several views by a factor of 10%. +**md **(magnify down) decreases the zoom by the inverse factor. **2dmu **and **2dmd** +perform the same on one or all 2d views. + +**zoom **and **2dzoom **set the zoom factor to a value specified by you. The current +zoom factor is always displayed in the window’s title bar. Zoom 20 represents a +full screen view in a large window; zoom 10, a full screen view in a small one. + +**wzoom **(window zoom) allows you to select the area you want to zoom in on with the mouse. You will be prompted to give two of the corners of the area that you want to magnify and the rectangle so defined will occupy the window of the view. + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# set a zoom of 2.5 +zoom 2.5 + +# magnify by 10% +mu 1 + +# magnify by 20% +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +See also: **fit**, **2dfit** + + +@subsubsection occt_2142243456_44562206614 pu, pd, pl, pr, 2dpu, 2dpd, 2dpl, 2dpr + +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. + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# you have selected one anonometric view +pu +# or +pu 1 + +# you have selected an mu4 view; the object in the third +# view will pan up +pu 3 +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +See also: **fit**, **2dfit** + + +@subsubsection occt_2142243456_44562206615 fit, 2dfit + +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. + +When fitting all views a unique zoom is computed for all the views. All views are on the same scale. + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# fit only view 1 +fit 1 +# fit all 2d views +2dfit +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +See also: **zoom**, **mu**, **pu** + + +@subsubsection occt_2142243456_44562206616 u, d, l, r + +Syntax:      u [index] +d [index] +l [index] +r [index] + +**u**, **d**, **l**, **r **Rotate the object in view around its axis by five degrees up, down, left or right respectively. This command is restricted to axonometric and perspective views. + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# rotate the view up +u +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@subsubsection occt_2142243456_44562206617 focal, fu, fd + +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. + +Use **fu **and **fd **to increase or decrease the focal value by 10%. **fd **makes the eye closer to the object. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +pers +repeat 10 fd +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +*NOTE* +*Do not use a negative or null focal value.* + +See also: **pers** + + +@subsubsection occt_2142243456_44562206618 color + +Syntax: color index name + +**color **sets the color to a value. The index of the color is a value between 0 and 15. The name is an X window color name. The list of these can be found in the file rgb.txt in the X library directory. + +The default values are 0 White, 1 Red, 2 Green, 3 Blue, 4 Cyan, 5 Gold, 6 Magenta, 7 Marron, 8 Orange, 9 Pink, 10 Salmon, 11 Violet, 12 Yellow, 13 Khaki, 14 Coral. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# change the value of blue +color 3 ;navy blue; +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +

NOTE

+*The color change will be visible on the next redraw of the* +*views, for example after fit or mu, etc.* + + +@subsubsection occt_2142243456_44562206619 dtext + +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. + +The coordinates are real space coordinates. + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# mark the origins +dtext 0 0 bebop +dtext 0 0 0 bebop +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@subsubsection occt_2142243456_445622066110 hardcopy, hcolor, xwd + +Syntax:      hardcopy [index] +hcolor index width gray +xwd [index] filename + +**hardcopy **creates a postcript file called a4.ps in the current directory. This file contains the postscript description of the view index, and will allow you to print the view. + +**hcolor **lets you change the aspect of lines in the postscript file. It allows to specify a width and a gray level for one of the 16 colors. **width **is measured in points with default value as 1, **gray **is the gray level from 0 = black to 1 = white with default value as 0. All colors are bound to the default values at the beginning. + +**xwd **creates an X window xwd file from an active view. By default, the index is set to1. To visualize anxwd file, use the unix command **xwud**. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# all blue lines (color 3) +# will be half-width and gray +hcolor 3 0.5 + +# make a postscript file and print it +hardcopy +lpr a4.ps + +# make an xwd file and display it +xwd theview +xwud -in theview +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +

NOTE

+*When more than one view is present, specify the index of the view.* +*Only use a postscript printer to print postscript files.* + +See also: **color** + + +@subsubsection occt_2142243456_445622066111 wclick, pick + +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. + +Use the **pick **command to get graphic input. The arguments must be names for variables where the results are stored. + + * index: index of the view where the input was made. + * X,Y,Z: 3d coordinates in real world. + * b: b is the mouse button 1,2 or 3. + +When there is an extra argument, its value is not used and the command does not wait for a click; the value of b may then be 0 if there has not been a click. + +This option is useful for tracking the pointer. + +*NOTE* +*The results are stored in Draw numeric variables.* +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# make a circle at mouse location +pick index x y z b +circle c x y z 0 0 1 1 0 0 0 30 + +# make a dynamic circle at mouse location +# stop when a button is clicked +# (see the repaint command) + +dset b 0 +while {[dval b] == 0} { +pick index x y z b nowait +circle c x y z 0 0 1 1 0 0 0 30 +repaint +} +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +See also: **repaint** + + +Draw provides commands to manage the display of objects. **display**, **donly **are used to display, **erase**, **clear**, **2dclear **to erase. The **autodisplay **command is used to check whether variables are displayed when created. + +The variable name ;.; (dot) has a special status in Draw. Any Draw command expecting a Draw object as argument can be passed a dot. The meaning of the dot is the following. + + * If the dot is an input argument, a graphic selection will be made. Instead of getting the object from a variable, Draw will ask you to select an object in a view. + * If the dot is an output argument, an unnamed object will be created. Of course this makes sense only for graphic objects: if you create an unnamed number you will not be able to access it. This feature is used when you want to create objects for display only. + * If you do not see what you expected while executing loops or sourcing files, use the **repaint **and **dflush **commands. + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# OK use dot to dump an object on the screen +dump . + +point . x y z + +#Not OK. display points on a curve c +# with dot no variables are created +for {set i 0} {$i = 10} {incr i} { +cvalue c $i/10 x y z +point . x y z +} + +# point p x y z +# would have displayed only one point +# because the precedent variable content is erased + +# point p$i x y z +# is an other solution, creating variables +# p0, p1, p2, .... + +# give a name to a graphic object +rename . x +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +@subsubsection occt_2142243456_445622066112 autodisplay + +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. + +When **autodisplay **is off, using the dot return argument is ineffective. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# c is displayed +circle c 0 0 1 0 5 + +# toggle the mode +autodisplay +== 0 +circle c 0 0 1 0 5 + +# c is erased, but not displayed +display c +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +See also: **display** + +@subsubsection occt_2142243456_445622066113 display, donly + +Syntax:      display varname [varname ...] +donly varname [varname ...] + +**display **makes objects visible. + +**donly **(*display only*) makes objects visible and erases all other objects. It is very useful to extract one object from a messy screen. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# to see all objects +foreach var [directory] {display $var} + +# to select two objects and erase the other ones +donly . . +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +See also: **erase** + + +@subsubsection occt_2142243456_445622066114 erase, clear, 2dclear + +Syntax:      erase [varname varname ...] +clear +2dclear + +**erase **removes objects from all views. **erase **without arguments erases everything in 2d and 3d. + +**clear **erases only 3d objects and **2dclear, **only 2d objects. **erase **without arguments is similar to ; clear; 2dclear;. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# erase eveerything with a name starting with c_ +foreach var [directory c_*] {erase $var} + +# clear 2d views +2d clear +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +See also: **display** +@subsubsection occt_2142243456_445622066115 repaint, dflush + +Syntax:      repaint +dflush + +**repaint **forces repainting of views. + +**dflush **flushes the graphic buffers. + +These commands are useful within loops or in scripts. + +When an object is modified or erased, the whole view must be repainted. To avoid doing this too many times, Draw sets up a flag and delays the repaint to the end of the command in which the new prompt is issued. In a script, you may want to display the result of a change immediately. If the flag is raised, **repaint **will repaint the views and clear the flag. + +Graphic operations are buffered by Draw (and also by the X system). Usually the buffer is flushed at the end of a command and before graphic selection. If you want to flush the buffer from inside a script, use the **dflush **command. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +# See the example with the pick command +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +See also: **pick** + +@subsection occt_2142243456_4456220662 AIS viewer – view commands + + +@subsubsection occt_2142243456_44562206621 vinit + +Syntax:                  vinit + +Creates the 3D viewer window + +@subsubsection occt_2142243456_44562206622 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 + +Displays top view in the 3D viewer window. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +vinit +box b 10 10 10 +vdisplay b +vfit +vtop +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +@subsubsection occt_2142243456_44562206624 vaxo + +Syntax:                  vaxo + +Displays axonometric view in the 3D viewer window. +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +vinit +box b 10 10 10 +vdisplay b +vfit +vaxo +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +@subsubsection occt_2142243456_44562206625 vsetbg + +Syntax:                  vsetbg imagefile [filltype] + +Loads image file as background. **filltype** must be **NONE, CENTERED, TILED or STRETCH**. +**Example** + +vinit +vsetbg myimage.brep CENTERED + +@subsubsection occt_2142243456_44562206626 vclear + +Syntax:                  vclear + +Removes all objects from the viewer. + +@subsubsection occt_2142243456_44562206627 vrepaint + +Syntax:                  vrepaint + +Forcedly redisplays the shape in the 3D viewer window. + +@subsubsection occt_2142243456_44562206628 vfit + +Syntax:                  vfit + +Automatic zoom/panning. Objects in the view are visualized to occupy the maximum surface. + +@subsubsection occt_2142243456_44562206629 vzfit + +Syntax:                  vzfit + +Automatic depth panning. Objects in the view are visualized to occupy the maximum 3d space. + + +@subsection occt_2142243456_4456220663 AIS viewer – display commands + +@subsubsection occt_2142243456_44562206631 vdisplay + +Syntax:                  vdisplay name1 [name2] … [name n] + +Displays named objects. +**Example** + +vinit +box b 40 40 40 10 10 10 +psphere s 20 +vdisplay s b +vfit + + +@subsubsection occt_2142243456_44562206632 vdonly + +Syntax:                  vdonly [name1] … [name n] + +Displays only selected or named objects. If there are no selected or named objects, nothing is done. +**Example** + +vinit +box b 40 40 40 10 10 10 +psphere s 20 +vdonly b +vfit +@subsubsection occt_2142243456_44562206633 vdisplayall + +Syntax:                  vdisplayall + +Displays all created objects. +**Example** + +vinit +box b 40 40 40 10 10 10 +psphere s 20 +vdisplayall +vfit +@subsubsection occt_2142243456_44562206634 verase + +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** + +vinit +box b1 40 40 40 10 10 10 +box b2 -40 -40 -40 10 10 10 +psphere s 20 +vdisplayall +vfit +# erase only first box +verase b1 +# erase second box and sphere +verase +@subsubsection occt_2142243456_44562206635 veraseall + +Syntax:                  veraseall + +Erases all objects displayed in the viewer. +**Example** +vinit +box b1 40 40 40 10 10 10 +box b2 -40 -40 -40 10 10 10 +psphere s 20 +vdisplayall +vfit +# erase only first box +verase b1 +# erase second box and sphere +verseall + +@subsubsection occt_2142243456_44562206636 vsetdispmode + +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**). +**Example** + +vinit +box b 10 10 10 +vdisplay b +vsetdispmode 1 +vfit +@subsubsection occt_2142243456_44562206637 vdisplaytype + +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 + +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 + +Makes a list of known types and signatures in AIS. + +@subsubsection occt_2142243456_445622066310 vsetcolor + +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] + +Sets default color for all, selected or named shapes. + +@subsubsection occt_2142243456_445622066312 vsettransparency + +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** + +vinit +box b 10 10 10 +psphere s 20 +vdisplay b s +vfit +vsetdispmode 1 +vsettransparency b 0.5 + +@subsubsection occt_2142243456_445622066313 vunsettransparency + +Syntax:                  vunsettransparency [shapename] + +Sets default transparency (0.0) for all selected or named shapes. + +@subsubsection occt_2142243456_445622066314 vsetmaterial + +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*.** +**Example** + +vinit +psphere s 20 +vdisplay s +vfit +vsetdispmode 1 +vsetmaterial s JADE + +@subsubsection occt_2142243456_445622066315 vunsetmaterial + +Syntax:                  vunsetmaterial [shapename] + +Sets default material for all selected or named shapes. + +@subsubsection occt_2142243456_445622066316 vsetwidth + +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. +**Example** + +vinit +box b 10 10 10 +vdisplay b +vfit +vsetwidth b 5 + +@subsubsection occt_2142243456_445622066317 vunsetwidth + +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] + +Sets deflection coefficient that defines the quality of the shape’s representation in the shading mode. Default coefficient is 0.0008. +**Example** + +vinit +psphere s 20 +vdisplay s +vfit +vsetdispmode 1 +vsetshading s 0.005 +@subsubsection occt_2142243456_445622066319 vunsetshading + +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 + +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**. +**Example** + +vinit +box b 10 10 10 +vdisplay b +vfit +vsetam b 2 +@subsubsection occt_2142243456_445622066321 vunsetam + +Syntax:                  vunsetam + +Deactivates all selection modes for all shapes. + +@subsubsection occt_2142243456_445622066322 vdump + +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 + +Displays the list of displayed objects. + +@subsubsection occt_2142243456_445622066324 vsub + +Syntax:                  vsub 0/1(on/off)[shapename] + +Hilights/unhilights named or selected objects which are displayed at neutral state with subintensity color. +**Example** + +vinit +box b 10 10 10 +psphere s 20 +vdisplay b s +vfit +vsetdispmode 1 +vsub b 1 + +@subsubsection occt_2142243456_445622066325 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 + +Erases active areas. + +@subsubsection occt_2142243456_445622066327 vsensdis + +Syntax:                  vsensdis + +Displays active entities (sensitive entities of one of the standard types corresponding to active selection modes). + +Standard entity types are those defined in Select3D package: + * sensitive box + * sensitive face + * sensitive curve + * sensitive segment + * sensitive circle + * sensitive point + * sensitive triangulation + * sensitive triangle +Custom (application-defined) sensitive entity types are not processed by this command. + +@subsubsection occt_2142243456_445622066328 vsensera + +Syntax:                  vsensera + +Erases active entities. + +@subsubsection occt_2142243456_445622066329 vperf + +Syntax:                  vperf shapename 1/0 (Transformation/Loacation) 1/0 (Primitives sensibles ON/OFF) + +Tests the animation of an object along a predefined trajectory. +**Example** + +vinit +box b 10 10 10 +psphere s 20 +vdisplay b s +vfit +vsetdispmode 0 +vperf b 1 1 +@subsubsection occt_2142243456_445622066330 vr + +Syntax:                  vr filename + +Reads shape from BREP-format file and displays it in the viewer. +**Example** + +vinit +vr myshape.brep +@subsubsection occt_2142243456_445622066330331 vstate + +Syntax:                  vstate [name1] … [name n] + +Makes a list of the status (**Displayed** or **Not Displayed**) of some selected or named objects. + + + +@subsection occt_2142243456_4456220663304 AIS viewer – object commands + +@subsubsection occt_2142243456_44562206633041 vtrihedron + +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** + +vinit +vtrihedron tr + +@subsubsection occt_2142243456_44562206633042 vplanetri + +Syntax:                  vplanetri name + +Creates a plane from a trihedron selection. + + +@subsubsection occt_2142243456_44562206633043 vsize + +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** + +vinit +vtrihedron tr1 +vtrihedron tr2 0 0 0 1 0 0 1 0 0 +vsize tr2 400 + +@subsubsection occt_2142243456_44562206633044 vaxis + +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 +**Example** + +vinit +vtrihedron tr +vaxis axe1 0 0 0 1 0 0 + +@subsubsection occt_2142243456_44562206633045 vaxispara + +Syntax:                  vaxispara nom + +Creates an axis by interactive selection of an edge and a vertex. + +@subsubsection occt_2142243456_44562206633046 vaxisortho + +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] + +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** + +vinit +vpoint p 0 0 0 + +@subsubsection occt_2142243456_44562206633048 vplane + +Syntax:                  vplane name [AxisName] [PointName] +                        vplane name [PointName] [PointName] [PointName] +                        vplane name [PlaneName] [PointName] + +Creates a plane from named or interactively selected entities. +**Example** + +vinit +vpoint p1 0 50 0 +vaxis axe1 0 0 0 0 0 1 +vtrihedron tr +vplane plane1 axe1 p1 + +@subsubsection occt_2142243456_44562206633049 vplanepara + +Syntax:                  vplanepara name + +Creates a plane from interactively selected vertex and face. + +@subsubsection occt_2142243456_445622066330410 vplaneortho + +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] + +Creates a line from coordinates, named or interactively selected vertices. +**Example** + +vinit +vtrihedron tr +vpoint p1 0 50 0 +vpoint p2 50 0 0 +vline line1 p1 p2 +vline line2 0 0 0 50 0 1 + +@subsubsection occt_2142243456_445622066330412 vcircle + +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. +**Example** + +vinit +vtrihedron tr +vpoint p1 0 50 0 +vpoint p2 50 0 0 +vpoint p3 0 0 0 +vcircle circle1 p1 p2 p3 1 + + +@subsubsection occt_2142243456_445622066330413 vtri2d + +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 + +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. +**Example** + +vinit +vpoint p1 0 0 0 +vpoint p2 50 0 0 +vpoint p3 25 40 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 + +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. +**Example** + +Vinitvinit +vpoint p1 0 0 0 +vpoint p2 50 0 0 +vsegment segment p1 p2 +restore CrankArm.brep obj +vdisplay obj +vconnectsh new obj 100100100 1 0 0 0 0 1 + + + +@subsubsection occt_2142243456_445622066330416 vtriangle + +Syntax:                  vtriangle name PointName PointName PointName + +Creates and displays a filled triangle from named points. +**Example** + +vinit +vpoint p1 0 0 0 +vpoint p2 50 0 0 +vpoint p3 25 40 0 +vtriangle triangle1 p1 p2 p3 + +@subsubsection occt_2142243456_445622066330417 vsegment + +Syntax:                  vsegment name PointName PointName + +Creates and displays a segment from named points. +**Example** + +Vinit +vpoint p1 0 0 0 +vpoint p2 50 0 0 +vsegment segment p1 p2 + + +**MeshVS **(Mesh Visualization Service) component provides flexible means of displaying meshes with associated pre- and post- processor data. + + + +@subsection occt_2142243456_4456220663305 AIS viewer – Mesh Visualization Service + +@subsubsection occt_2142243456_44562206633051 meshfromstl + +Syntax:                  meshfromstl meshname file + +Creates a MeshVS_Mesh object based on STL file data. The object will be displayed immediately. +**Example** + +meshfromstl mesh myfile.stl + +@subsubsection occt_2142243456_44562206633052 meshdispmode + +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** + +vinit +meshfromstl mesh myfile.stl +meshdispmode mesh 2 + +@subsubsection occt_2142243456_44562206633053 meshselmode + +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, +**2** – 0D elements (not suppored in STL) +**4** – links (not supported in STL) +**8** – faces +**Example** + +vinit +meshfromstl mesh myfile.stl +meshselmode mesh 1 + +@subsubsection occt_2142243456_44562206633054 meshshadcolor + +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** + +vinit +meshfromstl mesh myfile.stl +meshshadcolormode mesh 0.5 0.5 0.5 + +@subsubsection occt_2142243456_44562206633055 meshlinkcolor + +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** + +vinit +meshfromstl mesh myfile.stl +meshlinkcolormode mesh 0.5 0.5 0.5 + +@subsubsection occt_2142243456_44562206633056 meshmat + +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,** +**1 – BRONZE,** +**2 - COPPER,** +**3 - GOLD,** +**4 - PEWTER,** +**5 - PLASTER,** +**6 - PLASTIC,** +**7 - SILVER,** +**8 - STEEL,** +**9 - STONE,** +**10 - SHINY_PLASTIC,** +**11 - SATIN,** +**12 - METALIZED,** +**13 - NEON_GNC,** +**14 - CHROME,** +**15 - ALUMINIUM,** +**16 - OBSIDIAN,** +**17 - NEON_PHC,** +**18 - JADE,** +**19 - DEFAULT,** +**20 - UserDefined** +**Example** + +vinit +meshfromstl mesh myfile.stl +meshmat mesh JADE + +@subsubsection occt_2142243456_44562206633057 meshshrcoef + +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** + +vinit +meshfromstl mesh myfile.stl +meshshrcoef mesh 0.05 + +@subsubsection occt_2142243456_44562206633058 meshshow + +Syntax:                  meshshow meshname + +Displays **meshname** in the viewer (if it is erased). +**Example** + +vinit +meshfromstl mesh myfile.stl +meshshow mesh + +@subsubsection occt_2142243456_44562206633059 meshhide + +Syntax:                  meshhide meshname + +Hides **meshname** in the viewer. +**Example** + +vinit +meshfromstl mesh myfile.stl +meshhide mesh + +@subsubsection occt_2142243456_445622066330510 meshhidesel + +Syntax:                  meshhidesel meshname + +Hides only selected entities. The other part of **meshname** remains visible. + +@subsubsection occt_2142243456_445622066330511 meshshowsel + +Syntax:                  meshshowsel meshname + +Shows only selected entities. The other part of **meshname** becomes invisible. + +@subsubsection occt_2142243456_445622066330512 meshshowall + +Syntax:                  meshshowall meshname + +Changes the state of all entities to visible for **meshname**. + +@subsubsection occt_2142243456_445622066330513 meshdelete + +Syntax:                  meshdelete meshname + +Deletes MeshVS_Mesh object **meshname**. +**Example** + +vinit +meshfromstl mesh myfile.stl +meshdelete mesh + + + + +@subsection occt_2142243456_4456220663306 AIS viewer – 2D viewer – view commands + +@subsubsection occt_2142243456_44562206633061 v2dinit + +Syntax:                  v2dinit + +**v2dinit **creates the 2D viewer window. + +@subsubsection occt_2142243456_44562206633062 v2dsetbg + +Syntax:                  v2dsetbg imagefile [filletype] + +**v2dsetbg** loads **imagefile** as background. **filletype** is **NONE**, **CENTERED**, **TILED**, **STRETCH**. +**Example** + +v2dinit +v2dsetbg myimage.brep CENTERED + +@subsubsection occt_2142243456_44562206633063 v2dfit + +Syntax:                  v2dfit + +Fits all shapes to the size of the window. + +@subsubsection occt_2142243456_44562206633064 v2drepaint + +Syntax:                  v2drepaint + +Forcedly repaints all shapes. + +@subsubsection occt_2142243456_44562206633065 v2dclear + +Syntax:                  v2dclear + +Clears the 2D viewer window + +@subsubsection occt_2142243456_44562206633066 v2dtext + +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**. +**Example** + +v2dinit +v2dtext *My text* 10 10 +@subsubsection occt_2142243456_44562206633067 v2dsettextcolor + +Syntax:                  v2dsettextcolor text_name colorindex + +Changes the color of **text_name** object (**name** must be an integer value). +**Example** + +v2dinit +v2dtext *My text* 10 10 +# Change color to red +v2dsettextcolor text_0 3 +@subsubsection occt_2142243456_44562206633068 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]] + +Loads a grid in the 2D viewer window. +**type** is **Rect** or **Circ**. +**drawmode** is **Lines**, **Points** or **None**. +**Example** + +v2dinit +v2dgrid Circ 0 0 250 12 0 Lines +v2drmgrid +v2dgrid Rect 0 0 200 200 0 Lines +@subsubsection occt_2142243456_445622066330610 v2rmgrid + +Syntax:                  v2rmgrid + +Unloads a grid from the window. + +@subsubsection occt_2142243456_445622066330611 v2dpickgrid + +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]] + +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 + +Makes aLlist of the displayed objects. + + +@subsection occt_2142243456_4456220663306127 Ais viewer – 2D viewer – display commands + +@subsubsection occt_2142243456_44562206633061271 v2ddisplay + +Syntax:                  v2ddisplay name [projection] + +Projection: origin_x origin_y origin_z normal_x normal_y normal_z dx_x dx_y dx_z. + +Displays named objects. +**Example** + +v2dinit +box b 10 10 10 +psphere s 20 +v2ddisplay s +v2ddisplay b +v2dfit +@subsubsection occt_2142243456_44562206633061272 v2ddonly + +Syntax:                  v2ddonly [name1] … [name n] + +Displays only selected or named objects. If there are no selected or named objects, nothing is done. +**Example** + +v2dinit +box b 10 10 10 +psphere s 20 +v2ddisplay b +v2ddisplay s +v2ddonly s +v2dfit +@subsubsection occt_2142243456_44562206633061273 v2ddisplayall + +Syntax:                  v2ddisplayall + +Displays all created objects. +**Example** + +v2dinit +box b 10 10 10 +psphere s 20 +v2ddisplay b +v2ddisplay s +v2ddonly +v2ddisplayall +v2dfit +@subsubsection occt_2142243456_44562206633061274 v2derase + +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** + +v2dinit +box b 10 10 10 +psphere s 20 +v2ddisplay b +v2ddisplay s +v2derase b +v2dfit +@subsubsection occt_2142243456_44562206633061275 v2deraseall + +Syntax:                  v2deraseall + +Erases all objects displayed in the viewer. +**Example** + +v2dinit +box b 10 10 10 +psphere s 20 +v2ddisplay b +v2ddisplay s +v2deraseall +v2dfit +@subsubsection occt_2142243456_44562206633061276 v2dsetcolor + +Syntax:                  v2dsetcolor [shapename] colorname + +Sets color for all, selected or named shapes. +Values of **colorname** see **vsetcolor**. +**Example** + +v2dinit +box b 10 10 10 +v2ddisplay b +v2ddisplay s +v2dsetcolor b RED +v2dfit +@subsubsection occt_2142243456_44562206633061277 v2dunsetcolor + +Syntax:                  v2dunsetcolor [shapename] + +Sets default color for all, selected or named shapes. +**Example** + +v2dinit +box b 10 10 10 +v2ddisplay b +v2ddisplay s +v2dsetcolor RED +v2dunsetcolor b +v2dfit +@subsubsection occt_2142243456_44562206633061278 v2dsetbgcolor + +Syntax:                  v2dsetbgcolor colorname + +Sets background color. +See **vsetcolor** for the values of **colorname.**. +**Example** + +v2dinit +box b 10 10 10 +v2ddisplay b +v2ddisplay s +v2dsetbgcolor RED +v2dfit +@subsubsection occt_2142243456_44562206633061279 v2dsetwidth + +Syntax:                  v2dsetwidth [shapename] widthenum + +Set width of the edges for all, selected or named shapes. +**widthenum** may be one of: **THIN, MEDIUM, THICK, VERYTHICK**. +**Example** + +v2dinit +box b 10 10 10 +v2ddisplay b +v2ddisplay s +v2dsetwidth b THICK +v2dfit +@subsubsection occt_2142243456_445622066330612710 v2dunsetwidth + +Syntax:                  vunsetwidth [shapename] + +Sets default width of the edges for all, selected or named shapes. +**Example** + +v2dinit +box b 10 10 10 +v2ddisplay b +v2ddisplay s +v2dsetwidth THICK +v2dunsetwidth b +v2dfit + +@section occt_2142243456_930384826 OCAF commands + + +This chapter contains a set of commands for Open CASCADE Technology Application Framework (OCAF). + + +@subsection occt_2142243456_9303848261 Application commands + + +@subsubsection occt_2142243456_93038482611 NewDocument + +Syntax:       NewDocument docname [format] + +Creates a new **docname** document with MDTV-Standard or described format. +**Example** + +# Create new document with default (MDTV-Standard) format +NewDocument D + +# Create new document with BinOcaf format +NewDocument D2 BinOcaf + +@subsubsection occt_2142243456_93038482612 IsInSession + +Syntax:       IsInSession path + +**I**Returns **0**, if **path** document is managed by the application session, **1** – otherwise. +**Example** + +IsInSession /myPath/myFile.std + +@subsubsection occt_2142243456_93038482613 ListDocuments + +Syntax:       ListDocuments + +Makes a list of documents handled during the session of the application. + + +@subsubsection occt_2142243456_93038482614 Open + +Syntax:       Open path docname + +Retrieves the document of file **docname** in the path **path**. Overwrites the document, if it is already in session. +**Example** + +Open /myPath/myFile.std D + +@subsubsection occt_2142243456_93038482615 Close + +Syntax:       Close docname + +Closes **docname** document. The document is no longer handled by the applicative session. +**Example** + +Close D + +@subsubsection occt_2142243456_93038482616 Save + +Syntax:       Save docname + +Saves **docname** active document. +**Example** + +Save D + +@subsubsection occt_2142243456_93038482617 SaveAs + +Syntax:       SaveAs docname path + +Saves the active document in the file **docname** in the path **path**. Overwrites the file if it already exists. +**Example** + +SaveAs D /myPath/myFile.std + +@subsection occt_2142243456_9303848262 Basic commands + + +@subsubsection occt_2142243456_930384826521 Label + +Syntax:       Label docname entry + +Creates the label expressed by **entry** if it does not exist. +**Example** + +Label D 0:2 + +@subsubsection occt_2142243456_930384826522 NewChild + +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** + +# Create new child of root label +NewChild D + +# Create new child of existing label +Label D 0:2 +NewChild D 0:2 + +@subsubsection occt_2142243456_930384826523 Children + +Syntax:       Children docname label + +Returns the list of attributes of **label**. +**Example** + +Children D 0:2 + +@subsubsection occt_2142243456_930384826524 ForgetAll + +Syntax:       ForgetAll docname label + +Forgets all attributes of the label. +**Example** + +ForgetAll D 0:2 + +@subsection occt_2142243456_93038482653 Application commands + + +@subsubsection occt_2142243456_930384826531 Main + +Syntax:       Main docname + +Returns the main label of the framework. +**Example** + +Main D + +@subsubsection occt_2142243456_930384826532 UndoLimit + +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 +**Example** + +UndoLimit D 100 + +@subsubsection occt_2142243456_930384826533 Undo + +Syntax:       Undo docname [value=1] + +Undoes **value** steps. +**Example** + +Undo D + +@subsubsection occt_2142243456_930384826534 Redo + +Syntax:       Redo docname [value=1] + +Redoes **value** steps. +**Example** + +Redo D + +@subsubsection occt_2142243456_930384826535 OpenCommand + +Syntax:       OpenCommand docname + +Opens a new command transaction. +**Example** + +OpenCommand D + +@subsubsection occt_2142243456_930384826536 CommitCommand + +Syntax:       CommitCommand docname + +Commits the Command transaction. +**Example** + +CommitCommand D + +@subsubsection occt_2142243456_930384826537 NewCommand + +Syntax:       NewCommand docname + +This is a short-cut for Commit and Open transaction. +**Example** + +NewCommand D + +@subsubsection occt_2142243456_930384826538 AbortCommand + +Syntax:       AbortCommand docname + +Aborts the Command transaction. +**Example** + +AbortCommand D + +@subsubsection occt_2142243456_930384826539 Copy + +Syntax:       Copy docname entry Xdocname Xentry + +Copies the contents of **entry** to **Xentry**. No links are registred. +**Example** + +Copy D1 0:2 D2 0:4 + +@subsubsection occt_2142243456_9303848265310 UpdateLink + +Syntax:       UpdateLink docname [entry] + +Updates external reference set at **entry**. +**Example** + +UpdateLink D + +@subsubsection occt_2142243456_9303848265311 CopyWithLink + +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. +**Example** + +CopyWithLink D1 0:2 D2 0:4 + +@subsubsection occt_2142243456_9303848265312 UpdateXLinks + +Syntax:       UpdateXLinks docname entry + +Sets modifications on labels impacted by external references to the **entry**. The **document** becomes invalid and must be recomputed +**Example** + +UpdateXLinks D 0:2 + +@subsubsection occt_2142243456_9303848265313 DumpDocument + +Syntax:       DumpDocument docname + +Displays parameters of **docname** document. +**Example** + +DumpDocument D + +@subsection occt_2142243456_93038482654 Data Framework commands + + +@subsubsection occt_2142243456_930384826541 MakeDF + +Syntax:       MakeDF dfname + +Creates a new data framework. +**Example** + +MakeDF D + +@subsubsection occt_2142243456_930384826542 ClearDF + +Syntax:       ClearDF dfname + +Clears a data framework. +**Example** + +ClearDF D + +@subsubsection occt_2142243456_930384826543 CopyDF + +Syntax:       CopyDF dfname1 entry1 [dfname2] entry2 + +Copies a data framework. +**Example** + +CopyDF D 0:2 0:4 + +@subsubsection occt_2142243456_930384826544 CopyLabel + +Syntax:       CopyLabel dfname fromlabel tolablel + +Copies a label. +**Example** + +CopyLabel D1 0:2 0:4 + +@subsubsection occt_2142243456_930384826545 MiniDumpDF + +Syntax:       MiniDumpDF dfname + +Makes a mini-dump of a data framework. +**Example** + +MiniDumpDF D + +@subsubsection occt_2142243456_930384826546 XDumpDF + +Syntax:       XDumpDF dfname + +Makes an extended dump of a data framework. +**Example** + +XDumpDF D + +@subsection occt_2142243456_93038482655 General attributes commands + + +@subsubsection occt_2142243456_930384826551 SetInteger + +Syntax:       SetInteger dfname entry value + +Finds or creates an Integer attribute at **entry** label and sets **value**. +**Example** + +SetInteger D 0:2 100 + +@subsubsection occt_2142243456_930384826552 GetInteger + +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** + +GetInteger D 0:2 Int1 + +@subsubsection occt_2142243456_930384826553 SetReal + +Syntax:       SetReal dfname entry value + +Finds or creates a Real attribute at **entry** label and sets **value**. +**Example** + +SetReal D 0:2 100. + +@subsubsection occt_2142243456_930384826554 GetReal + +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** + +GetReal D 0:2 Real1 + +@subsubsection occt_2142243456_930384826555 SetIntArray + +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** + +SetIntArray D 0:2 1 4 100 200 300 400 + +@subsubsection occt_2142243456_930384826556 GetIntArray + +Syntax:       GetIntArray dfname entry + +Gets a value of an IntegerArray attribute at **entry** label. +**Example** + +GetIntArray D 0:2 + +@subsubsection occt_2142243456_930384826557 SetRealArray + +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** + +GetRealArray D 0:2 1 4 100. 200. 300. 400. + +@subsubsection occt_2142243456_930384826558 GetRealArray + +Syntax:       GetRealArray dfname entry + +Gets a value of a RealArray attribute at **entry** label. +**Example** + +GetRealArray D 0:2 + +@subsubsection occt_2142243456_930384826559 SetComment + +Syntax:       SetComment dfname entry value + +Finds or creates a Comment attribute at **entry** label and sets **value**. +**Example** + +SetComment D 0:2 *My comment* + +@subsubsection occt_2142243456_9303848265510 GetComment + +Syntax:       GetComment dfname entry + +Gets a value of a Comment attribute at **entry** label. +**Example** + +GetComment D 0:2 + +@subsubsection occt_2142243456_9303848265511 SetExtStringArray + +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** + +SetExtStringArray D 0:2 1 3 *string1* *string2* *string3* + +@subsubsection occt_2142243456_9303848265512 GetExtStringArray + +Syntax:       GetExtStringArray dfname entry + +Gets a value of an ExtStringArray attribute at **entry** label. +**Example** + +GetExtStringArray D 0:2 + +@subsubsection occt_2142243456_9303848265513 SetName + +Syntax:       SetName dfname entry value + +Finds or creates a Name attribute at **entry** label and set **value**. +**Example** + +SetName D 0:2 *My name* + +@subsubsection occt_2142243456_9303848265514 GetName + +Syntax:       GetName dfname entry + +Gets a value of a Name attribute at **entry** label. +**Example** + +GetName D 0:2 + +@subsubsection occt_2142243456_9303848265515 SetReference + +Syntax:       SetReference dfname entry reference + +Creates a Reference attribute at **entry** label and sets **reference**. +**Example** + +SetReference D 0:2 0:4 + +@subsubsection occt_2142243456_9303848265516 GetReference + +Syntax:       GetReference dfname entry + +Gets a value of a Reference attribute at **entry** label. +**Example** + +GetReference D 0:2 + +@subsubsection occt_2142243456_9303848265517 SetUAttribute + +Syntax:       SetUAttribute dfname entry localGUID + +Creates a UAttribute attribute at **entry** label with **localGUID**. +**Example** + +set localGUID *c73bd076-22ee-11d2-acde-080009dc4422* +SetUAttribute D 0:2 ${localGUID} + +@subsubsection occt_2142243456_9303848265518 GetUAttribute + +Syntax:       GetUAttribute dfname entry loacalGUID + +Finds a UAttribute at **entry** label with **localGUID**. +**Example** + +set localGUID *c73bd076-22ee-11d2-acde-080009dc4422* +GetUAttribute D 0:2 ${localGUID} + +@subsubsection occt_2142243456_9303848265519 SetFunction + +Syntax:       SetFunction dfname entry ID failure + +Finds or creates a Function attribute at **entry** label with driver ID and **failure** index. +**Example** + +set ID *c73bd076-22ee-11d2-acde-080009dc4422* +SetFunction D 0:2 ${ID} 1 + +@subsubsection occt_2142243456_9303848265520 GetFunction + +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** + +GetFunction D 0:2 ID failure + +@subsubsection occt_2142243456_9303848265521 NewShape + +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. +**Example** + +box b 10 10 10 +NewShape D 0:2 b + +@subsubsection occt_2142243456_9303848265522 SetShape + +Syntax:       SetShape dfname entry shape + +Creates or updates a NamedShape attribute at **entry** label by **shape**. +**Example** + +box b 10 10 10 +SetShape D 0:2 b + +@subsubsection occt_2142243456_9303848265523 GetShape + +Syntax:       GetShape2 dfname entry shape + +Sets a shape from NamedShape attribute associated with **entry** label to **shape** draw variable. +**Example** + +GetShape2 D 0:2 b + +@subsection occt_2142243456_93038482656 Geometric attributes commands + + +@subsubsection occt_2142243456_930384826561 SetPoint + +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** + +point p 10 10 10 +SetPoint D 0:2 p + +@subsubsection occt_2142243456_930384826562 GetPoint + +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** + +GetPoint D 0:2 p + +@subsubsection occt_2142243456_930384826563 SetAxis + +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** + +line l 10 20 30 100 200 300 +SetAxis D 0:2 l + +@subsubsection occt_2142243456_930384826564 GetAxis + +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** + +GetAxis D 0:2 l + +@subsubsection occt_2142243456_930384826565 SetPlane + +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** + +plane pl 10 20 30 –1 0 0 +SetPlane D 0:2 pl + +@subsubsection occt_2142243456_930384826566 GetPlane + +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** + +GetPlane D 0:2 pl + +@subsubsection occt_2142243456_930384826567 SetGeometry + +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**. +**Example** + +point p 10 10 10 +SetGeometry D 0:2 pnt p + +@subsubsection occt_2142243456_930384826568 GetGeometryType + +Syntax:       GetGeometryType dfname entry + +Gets a geometry type from Geometry attribute at **entry** label. +**Example** + +GetGeometryType D 0:2 + +@subsubsection occt_2142243456_930384826569 SetConstraint + +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: +**rad/dia/minr/majr/tan/par/perp/concentric/equal/dist/angle/eqrad/symm/midp/ eqdist/fix/rigid** +or +**from/axis/mate/alignf/aligna/axesa/facesa/round/offset** + +2. Sets plane for the existing constraint. + +3. Sets value for the existing constraint. +**Example** + +SetConstraint D 0:2 *value* 5 + +@subsubsection occt_2142243456_9303848265610 GetConstraint + +Syntax:       GetConstraint dfname entry + +Dumps a Constraint attribute at **entry** label +**Example** + +GetConstraint D 0:2 + +@subsubsection occt_2142243456_9303848265611 SetVariable + +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** + +SetVariable D 0:2 1 *mm* + +@subsubsection occt_2142243456_9303848265612 GetVariable + +Syntax:       GetVariable dfname entry isconstant units + +Gets an **isconstant** flag and **units** of a Variable attribute at **entry** label. +**Example** + +GetVariable D 0:2 isconstant units +puts *IsConstant=${isconstant}* +puts *Units=${units}* + + +@subsection occt_2142243456_93038482657 Tree attributes commands + + +@subsubsection occt_2142243456_930384826571 RootNode + +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] + +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] + + +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] + + +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] + +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] + +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] + +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] + + +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. +**Example** + +Label D 0:2 +Label D 0:3 +Label D 0:4 +Label D 0:5 +Label D 0:6 +Label D 0:7 +Label D 0:8 +Label D 0:9 + +# Set root node +SetNode D 0:2 + +AppendNode D 0:2 0:4 +AppendNode D 0:2 0:5 +PrependNode D 0:4 0:3 +PrependNode D 0:4 0:8 +PrependNode D 0:4 0:9 + +InsertNodeBefore D 0:5 0:6 +InsertNodeAfter D 0:4 0:7 + +DetachNode D 0:8 + + +# List all levels +ChildNodeIterate D 0:2 1 + +==0:4 +==0:9 +==0:3 +==0:7 +==0:6 +==0:5 + + +# List only first levels +ChildNodeIterate D 0:2 1 + +==0:4 +==0:7 +==0:6 +==0:5 + +@subsubsection occt_2142243456_930384826579 InitChildNodeIterator + +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. +**Example** + +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 +    } +} +puts *aChildNumber=$aChildNumber* + +@subsubsection occt_2142243456_9303848265710 ChildNodeMore + +Syntax:       ChildNodeMore + +Returns TRUE if there is a current item in the iteration. + + +@subsubsection occt_2142243456_9303848265711 ChildNodeNext + +Syntax:       ChildNodeNext + +Moves to the next Item. + + +@subsubsection occt_2142243456_9303848265712 ChildNodeValue + +Syntax:       ChildNodeValue + +Returns the current treenode of ChildNodeIterator. + + +@subsubsection occt_2142243456_9303848265713 ChildNodeNextBrother + +Syntax:       ChildNodeNextBrother + +Moves to the next Brother. If there is none, goes up. This method is interesting only with ;allLevels; behavior. + + +@subsection occt_2142243456_93038482658 Standard presentation commands + + +@subsubsection occt_2142243456_930384826581 AISInitViewer + +Syntax:       AISInitViewer docname + +Creates and sets AISViewer attribute at root label, creates AIS viewer window. +**Example** + +AISInitViewer D + +@subsubsection occt_2142243456_930384826582 AISRepaint + +Syntax:       AISRepaint docname + +Updates the AIS viewer window. +**Example** + +AISRepaint D + +@subsubsection occt_2142243456_930384826583 AISDisplay + +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. +**Example** + +AISDisplay D 0:5 + +@subsubsection occt_2142243456_930384826584 AISUpdate + +Syntax:       AISUpdate docname entry + +Recomputes a presantation of AISobject from **entry** label and applies the visualization setting in AIS viewer. +**Example** + +AISUpdate D 0:5 + +@subsubsection occt_2142243456_930384826585 AISErase + +Syntax:       AISErase docname entry + +Erases AISobject of **entry** label in AIS viewer. +**Example** + +AISErase D 0:5 + +@subsubsection occt_2142243456_930384826586 AISRemove + +Syntax:       AISRemove docname entry + +Erases AISobject of **entry** label in AIS viewer, then AISobject is removed from AIS_InteractiveContext. +**Example** + +AISRemove D 0:5 + +@subsubsection occt_2142243456_930384826587 AISSet + +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). +**Example** + +AISSet D 0:5 NS + +@subsubsection occt_2142243456_930384826588 AISDriver + +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). +**Example** + +# Get Driver GUID +AISDriver D 0:5 + +@subsubsection occt_2142243456_930384826589 AISUnset + +Syntax:       AISUnset docname entry + +Deletes AISPresentation attribute (if it exists) of an **entry** label. +**Example** + +AISUnset D 0:5 + +@subsubsection occt_2142243456_9303848265810 AISTransparency + +Syntax:       AISTransparency docname entry [transparency] + +Sets (if **transparency** is defined) or gets the value of transparency for AISPresentation attribute of an **entry** label. +**Example** + +AISTransparency D 0:5 0.5 + +@subsubsection occt_2142243456_9303848265811 AISHasOwnTransparency + +Syntax:       AISHasOwnTransparency docname entry + +Tests AISPresentation attribute of an **entry** label by own transparency. +**Example** + +AISHasOwnTransparency D 0:5 + +@subsubsection occt_2142243456_9303848265812 AISMaterial + +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**). +**Example** + +AISMaterial D 0:5 5 + +@subsubsection occt_2142243456_9303848265813 AISHasOwnMaterial + +Syntax:       AISHasOwnMaterial docname entry + +Tests AISPresentation attribute of an **entry** label by own material. +**Example** + +AISHasOwnMaterial D 0:5 + +@subsubsection occt_2142243456_9303848265814 AISColor + +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** + +AISColor D 0:5 25 + +@subsubsection occt_2142243456_9303848265815 AISHasOwnColor + +Syntax:       AISHasOwnColor docname entry + +Tests AISPresentation attribute of an **entry** label by own color. +**Example** + +AISHasOwnColor D 0:5 + + + +@section occt_2142243456_1101404852 Geometry commands + + + + +@subsection occt_2142243456_110140485261 Overview + +Draw provides a set of commands to test geometry libraries. These commands are found in the TGEOMETRY executable, or in any Draw executable which includes GeometryTest commands. + +In the context of Geometry, Draw includes the following types of variable: + + * 2d and 3d points + * The 2d curve, which corresponds to *Curve *in *Geom2d*. + * The 3d curve and surface, which correspond to *Curve *and *Surface *in *Geom *[2]. +Draw geometric variables never share data; the **copy **command will always make a complete copy of the content of the variable. + +The following topics are covered in the nine sections of this chapter: + + * **Curve creation **deals with the various types of curves and how to create them. + * **Surface creation **deals with the different types of surfaces and how to create them. + * **Curve and surface modification **deals with the commands used to modify the definition of curves and surfaces, most of which concern modifications to bezier and bspline curves. + * **Geometric transformations **covers translation, rotation, mirror image and point scaling transformations. + * **Curve and Surface Analysis **deals with the commands used to compute points, derivatives and curvatures. + * **Intersections **presents intersections of surfaces and curves. + * **Approximations **deals with creating curves and surfaces from a set of points. + * **Constraints **concerns construction of 2d circles and lines by constraints such as tangency. + * **Display **describes commands to control the display of curves and surfaces. + +Where possible, the commands have been made broad in application, i.e. they apply to 2d curves, 3d curves and surfaces. For instance, the **circle **command may create a 2d or a 3d circle depending on the number of arguments given. + +Likewise, the **translate **command will process points, curves or surfaces, depending on argument type. You may not always find the specific command you are looking for in the section where you expect it to be. In that case, look in another section. The **trim **command, for example, is described in the surface section. It can, nonetheless, be used with curves as well. + + + +@subsection occt_2142243456_110140485262 Curve creation + +This section deals with both points and curves. Types of curves are: + + * Analytical curves such as lines, circles, ellipses, parabolas, and hyperbolas. + * Polar curves such as bezier curves and bspline curves. + * Trimmed curves and offset curves made from other curves with the **trim **and **offset **commands. Because they are used on both curves and surfaces, the **trim **and **offset **commands are described in the *surface creation *section. + * NURBS can be created from other curves using **convert **in the *Surface Creation *section. + * Curves can be created from the isoparametric lines of surfaces by the **uiso **and **viso **commands. + * 3d curves can be created from 2d curves and vice versa using the **to3d **and **to2d **commands. The **project **command computes a 2d curve on a 3d surface. + +Curves are displayed with an arrow showing the last parameter. + + +@subsubsection occt_2142243456_1101404852621 point + +Syntax:      point name x y [z] + +**point **creates a 2d or 3d point, depending on the number of arguments. +
Example
+ +# 2d point +point p1 1 2 + +# 3d point +point p2 10 20 -5 + + +@subsubsection occt_2142243456_1101404852622 line + +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. + +A 2d line will be represented asl x y dx dy, and a 3d line asl x y z dx dy dz. A line is parameterized along its length starting from the point of origin along the direction vector. The direction vector is normalized and must not be null. Lines are infinite, even though their representation is not. +**Example** + +# a 2d line at 45 degrees of the X axis +line l 2 0 1 1 + +# a 3d line through the point 10 0 0 and parallel to Z +line l 10 0 0 0 0 1 + + +@subsubsection occt_2142243456_1101404852623 circle + +Syntax:      circle name x y [z [dx dy dz]] [ux uy [uz]] radius + +**circle **creates a 2d or a 3d circle. + +In 2d, x, y are the coordinates of the center and ux, uy define the vector towards the point of origin of the parameters. By default, this direction is (1,0). The X Axis of the local coordinate system defines the origin of the parameters of the circle. Use another vector than the x axis to change the origin of parameters. + +In 3d, x, y, z are the coordinates of the center; dx, dy, dz give the vector normal to the plane of the circle. By default, this vector is (0,0,1) i.e. the Z axis (it must not be null). ux, uy, uz is the direction of the origin; if not given, a default direction will be computed. This vector must neither be null nor parallel to dx, dy, dz. + +The circle is parameterized by the angle in [0,2*pi] starting from the origin and. Note that the specification of origin direction and plane is the same for all analytical curves and surfaces. + +**Example** + +# A 2d circle of radius 5 centered at 10,-2 +circle c1 10 -2 5 + +# another 2d circle with a user defined origin +# the point of parameter 0 on this circle will be +# 1+sqrt(2),1+sqrt(2) +circle c2 1 1 1 1 2 + +# a 3d circle, center 10 20 -5, axis Z, radius 17 +circle c3 10 20 -5 17 + +# same 3d circle with axis Y +circle c4 10 20 -5 0 1 0 17 + +# full 3d circle, axis X, origin on Z +circle c5 10 20 -5 1 0 0 0 0 1 17 + + +@subsubsection occt_2142243456_1101404852624 ellipse + +Syntax: ellipse name x y [z [dx dy dz]] [ux uy [uz]] firstradius secondradius **ellipse **creates a 2d or 3d ellipse. In a 2d ellipse, the first two arguments define the center; in a 3d ellipse, the first three. The axis system is given by *firstradius*, the major radius, and *secondradius*, the minor radius. The parameter range of the ellipse is [0,2.*pi] starting from the X axis and going towards the Y axis. The Draw ellipse is parameterized by an angle: + +P(u) = O + firstradius*cos(u)*Xdir + secondradius*sin(u)*Ydir + +where: + + * P is the point of parameter u, + * O, Xdir and Ydir are respectively the origin, *X Direction* and *Y Direction* of its local coordinate system. +
Example
+ +# default 2d ellipse +ellipse e1 10 5 20 10 + +# 2d ellipse at angle 60 degree +ellipse e2 0 0 1 2 30 5 + +# 3d ellipse, in the XY plane +ellipse e3 0 0 0 25 5 + +# 3d ellipse in the X,Z plane with axis 1, 0 ,1 +ellipse e4 0 0 0 0 1 0 1 0 1 25 5 + +See also: **circle** +@subsubsection occt_2142243456_1101404852625 hyperbola + +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. + +The Draw hyperbola is parameterized as follows: + +P(U) = O + firstradius*Cosh(U)*XDir + secondradius*Sinh(U)*YDir + +where: + + * P is the point of parameter U, + * O, XDir and YDir are respectively the origin, *X Direction* and *Y + +Direction* of its local coordinate system. +**Example** + +# default 2d hyperbola, with asymptotes 1,1 -1,1 +hyperbola h1 0 0 30 30 + +# 2d hyperbola at angle 60 degrees +hyperbola h2 0 0 1 2 20 20 + +# 3d hyperbola, in the XY plane +hyperbola h3 0 0 0 50 50 + +See also: **circle** + + +@subsubsection occt_2142243456_1101404852626 parabola + +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. + +The Geom_Parabola parabola is parameterized as follows: + +P(u) = O + u*u/(4.*F)*XDir + u*YDir + +where: + * P is the point of parameter u, + * O, XDir and YDir are respectively the origin, *X Direction* and *Y Direction* of its local coordinate system, + * F is the focal length of the parabola. +**Example** + +# 2d parabola +parabola p1 0 0 50 + +# 2d parabola with convexity +Y +parabola p2 0 0 0 1 50 + +# 3d parabola in the Y-Z plane, convexity +Z +parabola p3 0 0 0 1 0 0 0 0 1 50 + +See also: **circle** + + +@subsubsection occt_2142243456_1101404852627 beziercurve, dbeziercurve + +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. +**Example** + +# a rational 2d bezier curve (arc of circle) +2dbeziercurve ci 3 0 0 1 10 0 sqrt(2.)/2. 10 10 1 + +# a 3d bezier curve, not rational +beziercurve cc 4 0 0 0 10 0 0 10 0 10 10 10 10 + + +@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) +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. + +A bspline curve is defined by its degree, its periodic or non-periodic nature, a table of knots and a table of poles (i.e. control points). Consequently, specify the degree, the number of knots, and for each knot, the multiplicity, for each pole, the weight. In the syntax above, the commas link the adjacent arguments which they fall between: knot and multiplicities, pole and weight. + +The table of knots is an increasing sequence of reals without repetition. +Multiplicities must be lower or equal to the degree of the curve. For non-periodic curves, the first and last multiplicities can be equal to degree+1. For a periodic curve, the first and last multiplicities must be equal. + +The poles must be given with their weights, use weights of 1 for a non rational curve, the number of poles must be: + + * For a non periodic curve: Sum of multiplicities - degree + 1 + * For a periodic curve: Sum of multiplicities - last multiplicity +**Example** + +# a bspline curve with 4 poles and 3 knots +bsplinecurve bc 2 3 0 3 1 1 2 3 \ +10 0 7 1 7 0 7 1 3 0 8 1 0 0 7 1 +# a 2d periodic circle (parameter from 0 to 2*pi !!) +dset h sqrt(3)/2 +2dpbsplinecurve c 2 \ +4 0 2 pi/1.5 2 pi/0.75 2 2*pi 2 \ +0 -h/3 1 \ +0.5 -h/3 0.5 \ +0.25 h/6 1 \ +0 2*h/3 0.5 \ +-0.25 h/6 1 \ +-0.5 -h/3 0.5 \ +0 -h/3 1 + +

NOTE

+*You can create the **NURBS **subset of bspline curves and* +*surfaces by trimming analytical curves and surfaces and* +*executing the command *convert*; see below.* + + +@subsubsection occt_2142243456_1101404852629 uiso, viso + +Syntax:      uiso name surface u +viso name surface u + +Use these commands to create a U or V isoparametric curve from a surface. +**Example** + +# create a cylinder and extract iso curves + +cylinder c 10 +uiso c1 c pi/6 +viso c2 c + +*NOTE* +*Cannot be done from offset surfaces.* + + +@subsubsection occt_2142243456_11014048526210 tod, tod + +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. +**Example** + +# the following commands +circle c 0 0 5 +plane p -2 1 0 1 2 3 +to3d c c p + +# will create the same circle as +circle c -2 1 0 1 2 3 5 + +See also: **project** + + +@subsubsection occt_2142243456_11014048526211 project + +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** + +# intersect a cylinder and a plane +# and project the resulting ellipse on the cylinder +# this will create a 2d sinusoid-like bspline +cylinder c 5 +plane p 0 0 0 0 1 1 +intersect i c p +project i2d i c + +@subsection occt_2142243456_110140485263 Surface creation + +Types of surfaces are: + + * Analytical surfaces: plane, cylinder, cone, sphere, torus. + * Polar surfaces: bezier surfaces, bspline surfaces + * Trimmed and Offset surfaces; see **trim**, **trimu**, **trimv**, **offset**. + * Surfaces produced by Revolution and Extrusion, created from curves with the **revsurf **and **extsurf**. + * NURBS surfaces. + +Surfaces are displayed with isoparametric lines. To show the parameterization, a small parametric line with a length 1/10 of V is displayed at 1/10 of U. + + +@subsubsection occt_2142243456_1101404852631 plane + +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** + +# a plane through the point 10,0,0 perpendicular to X +# with U direction on Y +plane p1 10 0 0 1 0 0 0 1 0 + +# an horixontal plane with origin 10, -20, -5 +plane p2 10 -20 -5 + + +@subsubsection occt_2142243456_1101404852632 cylinder + +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** +**Example** + +# a cylinder on the default Z axis, radius 10 +cylinder c1 10 + +# a cylinder, also along the Z axis but with origin 5, +10, -3 +cylinder c2 5 10 -3 10 + +# a cylinder through the origin and on a diagonal +# with longitude pi/3 and latitude pi/4 (euler angles) +dset lo pi/3. la pi/4. +cylinder c3 0 0 0 cos(la)*cos(lo) cos(la)*sin(lo) +sin(la) 10 + + +@subsubsection occt_2142243456_1101404852633 cone + +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. +See also: **plane** +**Example** + +# a cone at 45 degrees at the origin on Z +cone c1 45 0 + +# a cone on axis Z with radius r1 at z1 and r2 at z2 +cone c2 0 0 z1 180.*atan2(r2-r1,z2-z1)/pi r1 + +@subsubsection occt_2142243456_1101404852634 sphere + +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** +# a sphere at the origin +sphere s1 10 +# a sphere at 10 10 10, with poles on the axis 1,1,1 +sphere s2 10 10 10 1 1 1 10 + +See also: **plane** + + +@subsubsection occt_2142243456_1101404852635 torus + +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. + +To parameterize a torus, u is the angle from X to Y; v is the angle in the plane at angle u from the XY plane to Z. u and v are in 0,2*pi. +**Example** + +# a torus at the origin +torus t1 20 5 + +# a torus in another coordinate system +torus t2 10 5 -2 2 1 0 20 5 + +See also: **plane** + + +@subsubsection occt_2142243456_1101404852636 beziersurf + +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. + +Then give the poles in the following order: pole(1, 1), pole(nbupoles, 1), pole(1, nbvpoles) and pole(nbupoles, nbvpoles). + +Weights may be omitted, but if you give one weight you must give all of them. +**Example** + +# a non-rational degree 2,3 surface +beziersurf s 3 4 \ +0 0 0 10 0 5 20 0 0 \ +0 10 2 10 10 3 20 10 2 \ +0 20 10 10 20 20 20 20 10 \ +0 30 0 10 30 0 20 30 0 + +See also: **beziercurve** + +@subsubsection occt_2142243456_1101404852637  bsplinesurf, upbsplinesurf, vpbsplinesurf, uvpbsplinesurf + +Syntax:      bsplinesurf name udegree nbuknots uknot umult ... nbvknot vknot +vmult ... x y z w ... +upbsplinesurf ... +vpbsplinesurf ... +uvpbsplinesurf ... + +**bsplinesurf **generates bspline surfaces. **upbsplinesurf **creates a bspline surface periodic in u; **vpbsplinesurf **creates one periodic in v; and **uvpbsplinesurf **creates one periodic in uv. + +The syntax is similar to the **bsplinecurve **command. First give the degree in u and the knots in u with their multiplicities, then do the same in v. The poles follow. The number of poles is the product of the number in u and the number in v. See **bsplinecurve **to compute the number of poles, the poles are first given in U as in the beziersurf command. You must give weights if the surface is rational. +**Example** + +# create a bspline surface of degree 1 2 +# with two knots in U and three in V +bsplinesurf s \ +1 2 0 2 1 2 \ +2 3 0 3 1 1 2 3 \ +0 0 0 1 10 0 5 1 \ +0 10 2 1 10 10 3 1 \ +0 20 10 1 10 20 20 1 \ +0 30 0 1 10 30 0 1 + +See also: **bsplinecurve**, **beziersurf**, **convert** + + +@subsubsection occt_2142243456_1101404852638 trim, trimu, trimv + +Syntax:      trim newname name [u1 u2 [v1 v2]] +trimu newname name +trimv newname name + +The **trim **commands create trimmed curves or trimmed surfaces. Note that trimmed curves and surfaces are classes of the *Geom *package. The **trim **command creates either a new trimmed curve from a curve or a new trimmed surface in u and v from a surface. **trimu **creates a u-trimmed surface, and **trimv **a v-trimmed surface. After an initial trim, a second execution with no parameters given recreates the basis curve. The curves can be either 2d or 3d. If the trimming parameters decrease and if the curve or surface is not periodic, the direction is reversed. +

NOTE

+*Note that a trimmed curve or surface contains a copy of the* +*basis geometry: modifying that will not modify the trimmed* +*geometry. Trimming trimmed geometry will not create* +*multiple levels of trimming. The basis geometry will be used.* +**Example** + +# create a 3d circle +circle c 0 0 0 10 + +# trim it, use the same variable, the original is +deleted +trim c c 0 pi/2 + +# the original can be recovered! +trim orc c + +# trim again +trim c c pi/4 pi/2 + +# the original is not the trimmed curve but the basis +trim orc c + +# as the circle is periodic, the two following commands +are identical +trim cc c pi/2 0 +trim cc c pi/2 2*pi + +# trim an infinite cylinder +cylinder cy 10 +trimv cy cy 0 50 + +See also: **reverse** + + +@subsubsection occt_2142243456_1101404852639 offset + +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. + +The curve can be a 2d or a 3d curve. To compute the offsets for a 3d curve, you must also give a vector dx,dy,dz. For a planar curve, this vector is usually the normal to the plane containing the curve. + +The offset curve or surface copies the basic geometry, which can be modified later. +**Example** + +# graphic demonstration that the outline of a torus +# is the offset of an ellipse +smallview +X+Y +dset angle pi/6 +torus t 0 0 0 0 cos(angle) sin(angle) 50 20 +fit +ellipse e 0 0 0 50 50*sin(angle) +# note that the distance can be negative +offset l1 e 20 0 0 1 +@subsubsection occt_2142243456_11014048526310 revsurf + +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** + +# another way of creating a torus like surface +circle c 50 0 0 20 +revsurf s c 0 0 0 0 1 0 + + +@subsubsection occt_2142243456_11014048526311 extsurf + +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** + +# an elliptic cylinder +ellipse e 0 0 0 10 5 +extsurf s e 0 0 1 +# to make it finite +trimv s s 0 10 + + +@subsubsection occt_2142243456_11014048526312 convert + +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** + +# turn a 2d arc of a circle into a 2d NURBS +circle c 0 0 5 +trim c c 0 pi/3 +convert c1 c + +# an easy way to make a planar bspline surface +plane p +trim p p -1 1 -1 1 +convert p1 p + +

NOTE

+*Offset curves and surfaces are not treated by this command.* + + + +@subsection occt_2142243456_110140485264 Curve and surface modifications + +Draw provides commands to modify curves and surfaces, some of them are general, others restricted to bezier curves or bsplines. + +General modifications: + + * Reversing the parametrization: **reverse**, **ureverse**, **vreverse** + +Modifications for both bezier curves and bsplines: + + * Exchanging U and V on a surface: **exchuv** + * Segmentation: **segment**, **segsur** + * Increasing the degree: **incdeg**, **incudeg**, **incvdeg** + * Moving poles: **cmovep**, **movep**, **movecolp**, **moverowp** + +Modifications for bezier curves: + + * Adding and removing poles: **insertpole**, **rempole**, **remcolpole**, **remrowpole** + +Modifications for bspline: + + * Inserting and removing knots: **insertknot**, **remknot**, **insertuknot**, **remuknot**, **insetvknot**, **remvknot** + * Modifying periodic curves and surfaces: **setperiodic**, **setnotperiodic**, **setorigin**, **setuperiodic**, **setunotperiodic**, **setuorigin**, **setvperiodic**, **setvnotperiodic**, **setvorigin** + + + + + +@subsubsection occt_2142243456_1101404852641 reverse, ureverse, vreverse + + +Syntax:            reverse curvename +ureverse surfacename +vreverse surfacename + +The **reverse **command reverses the parameterization and inverses the orientation of a 2d or 3d curve. Note that the geometry is modified. To keep the curve or the surface, you must copy it before modification. + +**ureverse **or **vreverse **reverse the u or v parameter of a surface. Note that the new parameters of the curve may change according to the type of curve. For instance, they will change sign on a line or stay 0,1 on a bezier. + +Reversing a parameter on an analytical surface may create an indirect coordinate system. +**Example** + +# reverse a trimmed 2d circle +circle c 0 0 5 +trim c c pi/4 pi/2 +reverse c + +# dumping c will show that it is now trimmed between +# 3*pi/2 and 7*pi/4 i.e. 2*pi-pi/2 and 2*pi-pi/4 + + +@subsubsection occt_2142243456_1101404852642 exchuv + +Syntax:                  exchuv surfacename + +For a bezier or bspline surface this command exchanges the u and v parameters. +**Example** + +# exchanging u and v on a spline (made from a cylinder) +cylinder c 5 +trimv c c 0 10 +convert c1 c +exchuv c1 + + +@subsubsection occt_2142243456_1101404852643 segment, segsur + +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. + +This command must not be confused with **trim **which creates new geometry. + +**Example** + +# segment a bezier curve in half +beziercurve c 3 0 0 0 10 0 0 10 10 0 +segment c ufirst ulast + + +@subsubsection occt_2142243456_1101404852644 iincudeg, incvdeg + +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. +**Example** + +# make a planar bspline and increase the degree to 2 3 +plane p +trim p p -1 1 -1 1 +convert p1 p +incudeg p1 2 +incvdeg p1 3 + +

NOTE

+*The geometry is modified.* + + +@subsubsection occt_2142243456_1101404852645 cmovep, movep, movecolp, moverowp + +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 + +**move **methods translate poles of a bezier curve, a bspline curve or a bspline surface. **cmovep **and **movep **translate one pole with a given index. + +**movecolp **and **moverowp **translate a whole column (expressed by the uindex) or row (expressed by the vindex) of poles. +**Example** + +# start with a plane +# transform to bspline, raise degree and add relief +plane p +trim p p -10 10 -10 10 +convert p1 p +incud p1 2 +incvd p1 2 +movecolp p1 2 0 0 5 +moverowp p1 2 0 0 5 +movep p1 2 2 0 0 5 + + +@subsubsection occt_2142243456_1101404852646 insertpole, rempole, remcolpole, remrowpole + +Syntax:                  insertpole curvename index x y [z] [weight] +rempole curvename index +remcolpole surfacename index +remrowpole surfacename index + +**insertpole **inserts a new pole into a 2d or 3d bezier curve. You may add a weight for the pole. The default value for the weight is 1. The pole is added at the position after that of the index pole. Use an index 0 to insert the new pole before the first one already existing in your drawing. + +**rempole **removes a pole from a 2d or 3d bezier curve. Leave at least two poles in the curves. + +**remcolpole **and **remrowpole **remove a column or a row of poles from a bezier surface. A column is in the v direction and a row in the u direction The resulting degree must be at least 1; i.e there will be two rows and two columns left. +**Example** + +# start with a segment, insert a pole at end +# then remove the central pole +beziercurve c 2 0 0 0 10 0 0 +insertpole c 2 10 10 0 +rempole c 2 + + +@subsubsection occt_2142243456_1101404852647 insertknot, insertuknot, insertvknot + +Syntax:                  insertknot name knot [mult = 1] [knot mult ...] +insertuknot surfacename knot mult +insertvknot surfacename knot mult + +**insertknot **inserts knots in the knot sequence of a bspline curve. You must give a knot value and a target multiplicity. The default multiplicity is 1. If there is already a knot with the given value and a multiplicity lower than the target one, its multiplicity will be raised. **insertuknot **and **insertvknot **insert knots in a surface. + + + + +**Example** + +# create a cylindrical surface and insert a knot +cylinder c 10 +trim c c 0 pi/2 0 10 +convert c1 c +insertuknot c1 pi/4 1 + +@subsubsection occt_2142243456_1101404852648 remknot, remuknot, remvknot + +Syntax:      remknot index [mult] [tol] +remuknot index [mult] [tol] +remvknot index [mult] [tol] + +**remknot **removes a knot from the knot sequence of a curve or a surface. Give the index of the knot and optionally, the target multiplicity. If the target multiplicity is not 0, the multiplicity of the knot will be lowered. As the curve may be modified, you are allowed to set a tolerance to control the process. If the tolerance is low, the knot will only be removed if the curve will not be modified. + +By default, if no tolerance is given, the knot will always be removed. +**Example** + +# bspline circle, remove a knot +circle c 0 0 5 +convert c1 c +incd c1 5 +remknot c1 2 + +*NOTE* +*Curves or Surfaces may be modified.* + + +@subsubsection occt_2142243456_1101404852649 setperiodic, setnotperiodic, setuperiodic, setunotperiodic, setvperiodic, setvnotperiodic + +Syntax:      setperiodic curve +setnotperiodic curve +setuperiodic surface +setunotperiodic surface +setvperiodic surface +setvnotperiodic surface + +**setperiodic **turns a bspline curve into a periodic bspline curve; the knot vector stays the same and excess poles are truncated. The curve may be modified if it has not been closed. **setnotperiodic **removes the periodicity of a periodic curve. The pole table mau be modified. Note that knots are added at the beginning and the end of the knot vector and the multiplicities are knots set to degree+1 at the start and the end. + +**setuperiodic **and **setvperiodic **make the u or the v parameter of bspline surfaces periodic; **setunotperiodic**, and **setvnotperiodic **remove periodicity from the u or the v parameter of bspline surfaces. +**Example** + +# a circle deperiodicized +circle c 0 0 5 +convert c1 c +setnotperiodic c1 +@subsubsection occt_2142243456_11014048526410 setorigin, setuorigin, setvorigin + +Syntax:      setorigin curvename index +setuorigin surfacename index +setuorigin surfacename index + +These commands change the origin of the parameters on periodic curves or surfaces. The new origin must be an existing knot. To set an origin other than an existing knot, you must first insert one with the **insertknot **command. +**Example** + +# a torus with new U and V origins +torus t 20 5 +convert t1 t +setuorigin t1 2 +setvorigin t1 2 + + +@subsection occt_2142243456_110140485265 Transformations + +Draw provides commands to apply linear transformations to geometric objects: they include translation, rotation, mirroring and scaling. + +@subsubsection occt_2142243456_1101404852651 translate, dtranslate + +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. + +For 2d points or curves, use the **2dtranslate **command. +**Example** + +# 3d tranlation +point p 10 20 30 +circle c 10 20 30 5 +torus t 10 20 30 5 2 +translate p c t 0 0 15 +*NOTE* +*Objects are modified by this command.* + +@subsubsection occt_2142243456_1101404852652 rotate, drotate + +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. + +For a 2d rotation, you need only give the center point and the angle. In 2d or 3d, the angle can be negative. +**Example** + +# make a helix of circles. create a scripte file with +this code and execute it using **source**. +circle c0 10 0 0 3 +for {set i 1} {$i = 10} {incr i} { +copy c[expr $i-1] c$i +translate c$i 0 0 3 +rotate c$i 0 0 0 0 0 1 36 +} + +@subsubsection occt_2142243456_1101404852653 pmirror, lmirror, smirror, dpmirror, dlmirror + +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 +2dlmirror name [names ...] x y dx dy + +The mirror commands perform a mirror transformation of 2d or 3d geometry. + +**pmirror **is the point mirror, mirroring 3d curves and surfaces about a point of symmetry. **lmirror **is the line mirror commamd, mirroring 3d curves and surfaces about an axis of symmetry. **smirror **is the surface mirror, mirroring 3d curves and surfaces about a plane of symmetry. In the last case, the plane of symmetry is perpendicular to dx,dy,dz. + +In 2d, only **2dpmirror**, point symmetry mirroring, and **2dlmirror**, axis symmetry mirroring, are available. +**Example** + +# build 3 images of a torus +torus t 10 10 10 1 2 3 5 1 +copy t t1 +pmirror t1 0 0 0 +copy t t2 +lmirror t2 0 0 0 1 0 0 +copy t t3 +smirror t3 0 0 0 1 0 0 + +@subsubsection occt_2142243456_1101404852654 pscale, dpscale + +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** + +# double the size of a sphere +sphere s 0 0 0 10 +pscale s 0 0 0 2 + +@subsection occt_2142243456_110140485266 Curve and surface analysis + +**Draw **provides methods to compute information about curves and surfaces: + + * **coord **to find the coordinates of a point. + * **cvalue **and **2dcvalue **to compute points and derivatives on curves. + * **svalue **to compute points and derivatives on a surface. + * **localprop **and **minmaxcurandif **to compute the curvature on a curve. + * **parameters **to compute (u,v) values for a point on a surface. + * **proj **and **2dproj **to project a point on a curve or a surface. + * **surface_radius **to compute the curvature on a surface. + +@subsubsection occt_2142243456_1101404852661 coord + +Syntax:            coord P x y [z] + +The **coord **command will set the coordinates of the point P. x, y (and optionally z) +**Example** + +# translate a point +point p 10 5 5 +translate p 5 0 0 +coord p x y z +# x value is 15 +See also: **point** +@subsubsection occt_2142243456_1101404852662  cvalue, dcvalue + +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. +
Example
+ +# on a bezier curve at parameter 0 +# the point is the first pole +# the derivative is the vector first to second pole +# multiplied by the degree +# the second derivative is the difference +# first to second pole, second to third pole +# multipied by degree * degree-1 +2dbeziercurve c 4 0 0 1 1 2 1 3 0 +2dcvalue c 0 x y d1x d1y d2x d2y + +# values of x y d1x d1y d2x d2y +# are 0 0 3 3 0 -6 + + +@subsubsection occt_2142243456_1101404852663 svalue + +Syntax: svalue surfname U v x y z [dux duy duz dvx dvy dvz [d2ux d2uy d2uz d2vx d2vy d2vz d2uvx d2uvy d2uvz]] + +**svalue **computes points and derivatives on a surface for a pair of parameter values. The result depends on the number of arguments. You can compute first and second derivatives. +**Example** + +# display points on a sphere +sphere s 10 +for {dset t 0} {[dval t] = 1} {dset t t+0.01} { +svalue s t*2*pi t*pi-pi/2 x y z +point . x y z +} + + +@subsubsection occt_2142243456_1101404852664 localprop, minmaxcurandinf + +Syntax:      localprop curvename U +minmaxcurandinf curve + +The **localprop **command computes the curvature of a curve. +**minmaxcurandinf **computes and prints the parameters of the points where the curvature is minimum and maximum on a 2d curve. +**Example** + +# show curvature at the center of a bezier curve +beziercurve c 3 0 0 0 10 2 0 20 0 0 +localprop c 0.5 +== Curvature : 0.02 + +See also: **surface_radius** + + +@subsubsection occt_2142243456_1101404852665 parameters + +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** + +# Compute parameters on a plane +plane p 0 0 10 1 1 0 +parameters p 5 5 5 u v +# the values of u and v are : 0 5 + + +@subsubsection occt_2142243456_1101404852666 proj, dproj + +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. + +The command will compute and display all points in the projection. The lines joining the point to the projections are created with the names ext_1, ext_2, ... +**Example** + +# project point on a torus +torus t 20 5 +proj t 30 10 7 +== ext_1 ext_2 ext_3 ext_4 + + +@subsubsection occt_2142243456_1101404852667 surface_radius + +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** + +# computes curvatures of a cylinder +cylinder c 5 +surface_radius c pi 3 c1 c2 +== Min Radius of Curvature : -5 +== Min Radius of Curvature : infinite + + + +@subsection occt_2142243456_110140485267 Intersections + +The **intersect **command computes intersections of surfaces; the **2dintersect **command, intersections of 2d curves. + + +@subsubsection occt_2142243456_1101404852671 intersect + +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** + +# create an ellipse +cone c 45 0 +plane p 0 0 40 0 1 5 +intersect e c p + + +@subsubsection occt_2142243456_1101404852672 dintersect + +Syntax:      2dintersect curve1 curve2 + +**2dintersect **displays the intersection points between two 2d curves. +**Example** + +# intersect two 2d ellipses +ellipse e1 0 0 5 2 +ellipse e2 0 0 0 1 5 2 +2dintersect e1 e2 +@subsection occt_2142243456_110140485268 Approximations + +Draw provides command to create curves and surfaces by approximation. + +**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 + +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. +**Example** + +# pick points and they will be fitted +2dapprox c 10 + + +@subsubsection occt_2142243456_1101404852682 surfapp, grilapp + + +Syntax: surfapp name nbupoints nbvpoints x y z .... +grilapp name nbupoints nbvpoints xo dx yo dy z11 z12 ... + +**surfapp **fits a surface through an array of u and v points, nbupoints*nbvpoints. + +**grilapp **has the same function, but the x,y coordinates of the points are on a grid starting at x0,y0 with steps dx,dy. +**Example** + +# a surface using the same data as in the beziersurf +example sect 4.4 +surfapp s 3 4 \ +0 0 0 10 0 5 20 0 0 \ +0 10 2 10 10 3 20 10 2 \ +0 20 10 10 20 20 20 20 10 \ +0 30 0 10 30 0 20 30 0 + + + + + +@subsection occt_2142243456_110140485269 Constraints + +The **cirtang **command is used to construct 2d circles tangent to curves and **lintan **to construct 2d lines tangent to curves. + + +@subsubsection occt_2142243456_1101404852691 cirtang + +Syntax: cirtang cname curve/point/radius curve/point/radius curve/point/radius + +The **cirtang **command will build all circles satisfying the three constraints which are either a curve (the circle must be tangent to that curve), a point (the circle must pass through that point), or a radius for the circle. Only one constraint can be a radius. The solutions will be stored in variables *name_1*, *name_2*, etc. +**Example** + +# a point, a line and a radius. 2 solutions +point p 0 0 +line 1 10 0 -1 1 +cirtang c p 1 4 +== c_1 c_2 + + +@subsubsection occt_2142243456_1101404852692 lintan + +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** + +# lines tangent to 2 circles, 4 solutions +circle c1 -10 0 10 +circle c2 10 0 5 +lintan l c1 c2 + +# lines at 15 degrees tangent to a circle and a line, 2 +solutions: l1_1 l1_2 +circle c1 -10 0 1 +line l 2 0 1 1 +lintan l1 c1 l 15 + + + + +@subsection occt_2142243456_1101404852610 Display + +Draw provides commands to control the display of geometric objects. Some display parameters are used for all objects, others are valid for surfaces only, some for bezier and bspline only, and others for bspline only. + +On curves and surfaces, you can control the mode of representation with the **dmode **command. You can control the parameters for the mode with the **defle **command and the **discr **command, which control deflection and discretization respectively. + +On surfaces, you can control the number of isoparametric curves displayed on the surface with the **nbiso **commands. + +On bezier and bspline curve and surface you can toggle the display of the control points with the **clpoles **and **shpoles **commands. + +On bspline curves and surfaces you can toggle the display of the knots with the **shknots **and **clknots **commands. + + +@subsubsection occt_2142243456_11014048526101 dmod, discr, defle + +Syntax:      dmode name [name ...] u/d +discr name [name ...] nbintervals +defle name [name ...] deflection + +**dmode **allows you to choose the display mode for a curve or a surface. + +In mode ;u;, or *uniform deflection*, the points are computed to keep the polygon at a distance lower than the deflection of the geometry. The deflection is set with the **defle **command. This mode involves intensive use of computational power. + +In ;d;, or discretization mode, a fixed number of points is computed. This number is set with the **discr **command. This is the default mode. On a bspline, the fixed number of points is computed for each span of the curve. (A span is the interval between two knots). + +If the curve or the isolines seem to present too many angles, you can either increase the discretization or lower the deflection, depending on the mode. This will increase the number of points. +**Example** + +# increment the number of points on a big circle +circle c 0 0 50 50 +discr 100 + +# change the mode +dmode c u + + +@subsubsection occt_2142243456_11014048526102  nbiso + +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** + +# display 35 meridians and 15 parallels on a spere +sphere s 20 +nbiso s 35 15 + + +@subsubsection occt_2142243456_11014048526103 clpoles, shpoles + +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. +**Example** + +# make a bezier curve and erase the poles +beziercurve c 3 0 0 0 10 0 0 10 10 0 +clpoles c + + +@subsubsection occt_2142243456_11014048526104 clknots, shknots + +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. +**Example** + +# hide the knots on a bspline curve +bsplinecurve bc 2 3 0 3 1 1 2 3 \ +10 0 7 1 7 0 7 1 3 0 8 1 0 0 7 1 +clknots bc +@section occt_2142243456_1869436669 Topology commands + + + + + + + +Draw provides a set of commands to test OCCT Topology libraries. The Draw commands are found in the DRAWEXE executable or in any executable including the BRepTest commands. + +Topology defines the relationship between simple geometric entities, which can thus be linked together to represent complex shapes. The type of variable used by Topology in Draw is the shape variable. + +The different topological shapes[3] include: + + * COMPOUND: A group of any type of topological object. + * COMPSOLID: A set of solids connected by their faces. This expands the notions of WIRE and SHELL to solids. + * SOLID: A part of space limited by shells. It is three dimensional. + * SHELL: A set of faces connected by their edges. A shell can be open or closed. + * FACE: In 2d, a plane; in 3d, part of a surface. Its geometry is constrained (trimmed) by contours. It is two dimensional. + * WIRE: A set of edges connected by their vertices. It can be open or closed depending on whether the edges are linked or not. + * EDGE: A topological element corresponding to a restrained curve. An edge is generally limited by vertices. It has one dimension. + * VERTEX: A topological element corresponding to a point. It has a zero dimension. + +Shapes are usually shared. **copy **will create a new shape which shares its representation with the original. Nonetheless, two shapes sharing the same topology can be moved independently (see the section on **transformation**). + +The following topics are covered in the eight sections of this chapter: + + * Basic shape commands to handle the structure of shapes and control the display. + * Curve and surface topology, or methods to create topology from geometry and vice versa. + * Primitive construction commands: box, cylinder, wedge etc. + * Sweeping of shapes. + * Transformations of shapes: translation, copy, etc. + * Topological operations, or booleans. + * Drafting and blending. + * Analysis of shapes. + + + +@subsection occt_2142243456_186943666971 Basic topology + +The set of basic commands allows simple operations on shapes, or step-by-step construction of objects. These commands are useful for analysis of shape structure and include: + + * **isos **and **discretisation **to control display of shape faces by isoparametric curves . + * **orientation**, **complement **and **invert **to modify topological attributes such as orientation. + * **explode**, **exwire **and **nbshapes **to analyze the structure of a shape. + * **emptycopy**, **add**, **compound **to create shapes by stepwise construction. + +In Draw, shapes are displayed using isoparametric curves. There is color coding for the edges: + + * a red edge is an isolated edge, which belongs to no faces. + * a green edge is a free boundary edge, which belongs to one face, + * a yellow edge is a shared edge, which belongs to at least two faces. + + +@subsubsection occt_2142243456_1869436669711 isos, discretisation + +Syntax:                  isos [name ...][nbisos] +discretisation nbpoints +**isos **determines or changes the number of isoparametric curves on shapes. + +The same number is used for the u and v directions. With no arguments, **isos **prints the current default value. To determine, the number of isos for a shape, give it name as the first argument. + +**discretisation **changes the default number of points used to display the curves. The default value is 30. +**Example** + +# Display only the edges (the wireframe) +isos 0 + +

NOTE

+Don’t confuse *isos* and *discretisation* with the geometric +*commands *nbisos* and *discr*.* + + +@subsubsection occt_2142243456_1869436669712 orientation, complement, invert, normals, range + +Syntax:      orientation name [name ...] F/R/E/I +complement name [name ...] +invert name +normals s (length = 10), disp normals +range name value value + +**orientation **assigns the orientation of shapes - simple and complex - to one of the following four values: FORWARD, REVERSED, INTERNAL, EXTERNAL. + +**complement **changes the current orientation of shapes to its complement, FORWARD - REVERSED, INTERNAL - EXTERNAL. + +**invert **creates a new shape which is a copy of the original with the orientation all subshapes reversed. For example, it may be useful to reverse the normals of a solid. + +**normals **returns the assignment of colors to orientation values. + +**range **defines the length of a selected edge by defining the values of a starting point and an end point. +**Example** + +# invert normals of a box +box b 10 20 30 +normals b 5 +invert b +normals b 5 + +# to assign a value to an edge +box b1 10 20 30 +# to define the box as edges +explode b1 e +b_1 b_2 b_3 b_4 b_5 b_6 b_7 b_8 b_9 b_10 b_11 b_12 +# to define as an edge +makedge e 1 +# to define the length of the edge as starting from 0 +and finishing at 1 +range e 0 1 + + +@subsubsection occt_2142243456_1869436669713 explode, exwire, nbshapes + +Syntax:      explode name [C/So/Sh/F/W/E/V] +exwire name +nbshapes name + +**explode **extracts subshapes from an entity. The subshapes will be named *name_1*, *name_2*, ... Note that they are not copied but shared with the original. + +With name only, **explode **will extract the first sublevel of shapes: the shells of a solid or the edges of a wire, for example. With one argument, **explode **will extract all subshapes of that type: *C *for compounds, *So *for solids, *Sh *for shells, *F *for faces, *W *for wires, *E *for edges, *V *for vertices. + +**exwire **is a special case of **explode **for wires, which extracts the edges in an ordered way,if possible. Each edge, for example, is connected to the following one by a vertex. + +**nbshapes **counts the number of shapes of each type in an entity. +**Example** + +# on a box +box b 10 20 30 + +# whatis returns the type and various information +whatis b += b is a shape SOLID FORWARD Free Modified + +# make one shell +explode b +whatis b_1 += b_1 is a shape SHELL FORWARD Modified Orientable +Closed + +# extract the edges b_1, ... , b_12 +explode b e +==b_1 ... b_12 + +# count subshapes +nbshapes b +== +Number of shapes in b +VERTEX : 8 +EDGE : 12 +WIRE : 6 +FACE : 6 +SHELL : 1 +SOLID : 1 +COMPSOLID : 0 +COMPOUND : 0 +SHAPE : 34 + + +@subsubsection occt_2142243456_1869436669714 emptycopy, add, compound + +Syntax:                  emptycopy [newname] name +add name toname +compound [name ...] compoundname + +**emptycopy **returns an empty shape with the same orientation, location, and geometry as the target shape, but with no sub-shapes. If the newname argument is not given, the new shape is stored with the same name. This command is used to modify a frozen shape. A frozen shape is a shape used by another one. To modify it, you must emptycopy it. Its subshape may be reinserted with the **add **command. + +**add **inserts shape C into shape S. Verify that C and S reference compatible types of objects: + + * Any *Shape *can be added to a *Compound*. + * Only a *Solid *can be added to a *CompSolid*. + * Only a *Shell*, an *Edge *or a *Vertex *can be added into a *Solid*. + * Only a *Face *can be added to a *Shell*. + * Only a *Wire *and *Vertex *can be added in a *Solid*. + * Only an *Edge *can be added to a *Wire*. + * Only a *Vertex *can be added to an *Edge*. + * Nothing can be added to a *Vertex*. + +Care should be taken using **emptycopy **and **add**. + +On the other hand, **compound **is a safe way to achieve a similar result. It creates a compound from shapes. If no shapes are given, the compound is empty. +**Example** + +# a compound with three boxes +box b1 0 0 0 1 1 1 +box b2 3 0 0 1 1 1 +box b3 6 0 0 1 1 1 +compound b1 b2 b3 c + + +@subsubsection occt_2142243456_1869436669715 checkshape + +Syntax:                  checkshape [-top] shape [result] [-short] + +Where: +*-top* – check only topological validity of a shape. +*shape *– the only required parameter which represents the name of the shape to check. +*result* – optional parameter which is the prefix of the output shape names. +*-short* – short description of check. + + +**checkshape **examines the selected object for topological and geometric coherence. The object should be a three dimensional shape. +**Example** + +# checkshape returns a comment valid or invalid +box b1 0 0 0 1 1 1 +checkshape b1 +# returns the comment +this shape seems to be valid + +

NOTE

+*This test is performed using the tolerance set in the algorithm.* + + + + + +@subsection occt_2142243456_186943666972 Curve and surface topology + +This group of commands is used to create topology from shapes and to extract shapes from geometry. + + * To create vertices, use the **vertex **command. + * To create edges use, the **edge**, **mkedge **commands. + * To create wires, use the **wire**, **polyline**, **polyvertex **commands. + * To create faces, use the **mkplane**, **mkface **commands. + * To extract the geometry from edges or faces, use the **mkcurve **and **mkface **commands. + * To extract the 2d curves from edges or faces, use the **pcurve **command. + + +@subsubsection occt_2142243456_1869436669721 vertex + +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** + +vertex v1 10 20 30 + + +@subsubsection occt_2142243456_1869436669722 edge, mkedge, uisoedge, visoedge + +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 + +**edge **creates a straight line edge between two vertices. + +**mkedge **generates edges from curves[4].Two parameters can be given for the vertices: the first and last parameters of the curve are given by default. Vertices can also be given with their parameters, this option allows you to block the creation of new vertices. If the parameters of the vertices are not given, they are computed by projection on the curve. Instead of a 3d curve, a 2d curve and a surface can be given. +**Example** + +# straight line edge +vertex v1 10 0 0 +vertex v2 10 10 0 +edge e1 v1 v2 + +# make a circular edge +circle c 0 0 0 5 +mkedge e2 c 0 pi/2 + +# A similar result may be achieved by trimming the curve +# The trimming is removed by mkedge +trim c c 0 pi/2 +mkedge e2 c + +**visoedge **and **uisoedge **are commands that generate a uiso parameter edge +or a viso parameter edge. + +**Example** + +# to create an edge between v1 and v2 at point u +# to create the example plane +plane p +trim p p 0 1 0 1 +convert p p +incudeg p 3 +incvdeg p 3 +movep p 2 2 0 0 1 +movep p 3 3 0 0 0.5 +mkface p p +# to create the edge in the plane at the u axis point +0.5, and between the v axis points v=0.2 and v =0.8 +uisoedge e p 0.5 0.20 0.8 + + +@subsubsection occt_2142243456_1869436669723 wire, polyline, polyvertex + +Syntax:      wire wirename e1/w1 [e2/w2 ...] +polyline name x1 y1 z1 x2 y2 z2 ... +polyvertex name v1 v2 ... + +**wire **creates a wire from edges or wires. The order of the elements should ensure that the wire is connected, and vertex locations will be compared to detect connection. If the vertices are different, new edges will be created to ensure topological connectivity. The original edge may be copied in the new one. + +**polyline **creates a polygonal wire from point coordinates. To make a closed wire, you should give the first point again at the end of the argument list. + +**polyvertex **creates a polygonal wire from vertices. +**Example** + +# create two polygonal wires +# glue them and define as a single wire +polyline w1 0 0 0 10 0 0 10 10 0 +polyline w2 10 10 0 0 10 0 0 0 0 +wire w w1 w2 + + +@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 + +
Suffix
+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. + +Codes and values are used to define the next point or change the direction. When the profile changes from a straight line to a curve, a tangent is created. All angles are in degrees and can be negative. + +The point [code values] can be repeated any number of times and in any order to create the profile contour. + +The profile shape definition is the suffix; no suffix produces a face, **w **is a closed wire, **ww **is an open wire. + +Code letters are not case-sensitive. +**Example** + +# to create a trianglular plane using a vertex at the +origin, in the xy plane +profile p O 0 0 0 X 1 Y 0 x 1 y 1 +**Example** + +# to create a contour using the different code +possibilities + +# two vertices in the xy plane +profile p F 1 0 x 2 y 1 ww + +# to view from a point normal to the plane +top + +# add a circular element of 45 degrees +profile p F 1 0 x 2 y 1 c 1 45 ww + +# add a tangential segment with a length value 1 +profile p F 1 0 x 2 y 1 c 1 45 l 1 ww + +# add a vertex with xy values of 1.5 and 1.5 +profile p F 1 0 x 2 y 1 c 1 45 l 1 tt 1.5 1.5 ww + +# add a vertex with the x value 0.2, y value is constant +profile p F 1 0 x 2 y 1 c 1 45 l 1 tt 1.5 1.5 xx 0.2 ww + +# add a vertex with the y value 2 x value is constant +profile p F 1 0 x 2 y 1 c 1 45 l 1 tt 1.5 1.5 yy 2 ww + +# add a circular element with a radius value of 1 and a circular value of 290 degrees +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 + +# wire continues at a tangent to the intersection x = 0 +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 ww + +# continue the wire at an angle of 90 degrees until it intersects the y axis at y= -o.3 +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 ww + +#close the wire +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 w + +# to create the plane with the same contour +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 + +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 + +**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. + +The profile shape definition is the suffix; no suffix produces a face, **w **is a closed wire, **ww **is an open wire. +**Example** + +#to view the xy plane +top +#to create a 2d curve with the mouse +bsplineprof res +# click mb1 to start the curve +# click mb1 to create the second vertex +# click mb1 to create a curve +== +#click mb2 to finish the curve and start a new curve +== +# click mb1 to create the second curve +# click mb3 to create the face + + +@subsubsection occt_2142243456_1869436669726 mkoffset + +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. + +The offset distance defines the spacing and the positionning of the occurences. +**Example** + +#Create a box and select a face +box b 1 2 3 +explode b f +#Create three exterior parallel contours with an offset +value of 2 +mkoffset r b_1 3 2 +Create one interior parallel contour with an offset +value of +0.4 +mkoffset r b_1 1 -0.4 + +NOTE +*The mkoffset command must be used with prudence, angular contours produce offset contours with fillets. Interior parallel contours can produce more than one wire, normally these are refused. In the following example, any increase in the offset value is refused* +**Example** + +# to create the example contour +profile p F 0 0 x 2 y 4 tt 1 1 tt 0 4 w +# to create an incoherent interior offset +mkoffset r p 1 -0.50 +==p is not a FACE but a WIRE +BRepFill_TrimEdgeTool: incoherent intersection +# to create two incoherent wires +mkoffset r p 1 -0.50 + + +@subsubsection occt_2142243456_1869436669727 mkplane, mkface + +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. + +**mkface **generates a face from a surface. Parameter values can be given to trim a rectangular area. The default boundaries are those of the surface. +**Example** + +# make a polygonal face +polyline f 0 0 0 20 0 0 20 10 0 10 10 0 10 20 0 0 20 0 0 0 0 +mkplane f f + +# make a cylindrical face +cylinder g 10 +trim g g -pi/3 pi/2 0 15 +mkface g g + + +@subsubsection occt_2142243456_1869436669728 mkcurve, mksurface + +Syntax:      mkcurve curve edge +mksurface name face + +**mkcurve **creates a 3d curve from an edge. The curve will be trimmed to the edge boundaries. + +**mksurface **creates a surface from a face. The surface will not be trimmed. +**Example** + +# make a line +vertex v1 0 0 0 +vertex v2 10 0 0 +edge e v1 v2 + + +@subsubsection occt_2142243456_1869436669729 pcurve + +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** + +# view the pcurves of a face +plane p +trim p p -1 1 -1 1 +mkface p p +av2d; # a 2d view +pcurve p +2dfit + + +@subsubsection occt_2142243456_18694366697210 chfid + +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: + + * a radius value + * two respective distance values + * a distance value and an angle + +The radius value produces a fillet between the two faces. + +The distance is the length value from the edge between the two selected faces in a normal direction. + +**Example** + +# to create a 2d fillet +top +profile p x 2 y 2 x -2 +chfi2d cfr p . . F 0.3 +==Pick an object +#select an edge +==Pick an object +#select an edge +**Example** + +# to create a 2d chamfer using two distances +profile p x 2 y 2 x -2 +chfi2d cfr p . . CDD 0.3 0.6 +==Pick an object +#select an edge +==Pick an object +#select an edge +**Example** + +# to create a 2d chamfer using a defined distance and +angle +top +profile p x 2 y 2 x -2 +chfi2d cfr p . . CDA 0.3 75 +==Pick an object +#select an edge +==Pick an object +#select an edge + + +@subsubsection occt_2142243456_18694366697211 nproject + +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. +
Example
+ +# create a curved surface +line l 0 0 0 1 0 0 +trim l l 0 2 +convert l l + +incdeg l 3 +cmovep l 1 0 0.5 0 +cmovep l 3 0 0.5 0 +copy l ll +translate ll 2 -0.5 0 +mkedge e1 l +mkedge e2 ll +wire w e1 e2 +prism p w 0 0 3 +donl p +#display in four views +mu4 +fit +# create the example shape +circle c 1.8 -0.5 1 0 1 0 1 0 0 0.4 +mkedge e c +donly p e +# create the normal projection of the shape(circle) +nproject r e p + + + +@subsection occt_2142243456_186943666973 Primitives + +Primitive commands make it possible to create simple shapes. They include: + + * **box **and **wedge **commands. + * **pcylinder**, **pcone**, **psphere**, **ptorus **commands. + * **halfspace **command + + +@subsubsection occt_2142243456_1869436669731 box, wedge + +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. + +**wedge **creates a box with five faces called a wedge. One face is in the OXZ plane, and has dimensions dx,dz while the other face is in the plane y = dy. This face either has dimensions ltx, dz or is bounded by xmin,zmin,xmax,zmax. + +The other faces are defined between these faces. The face in the y=yd plane may be degenerated into a line if ltx = 0, or a point if xmin = xmax and ymin = ymax. In these cases, the line and the point both have 5 faces each. To position the wedge use the **ttranslate **and **trotate **commands. +**Example** + +# a box at the origin +box b1 10 20 30 + +# another box +box b2 30 30 40 10 20 30 + +# a wedge +wedge w1 10 20 30 5 + +# a wedge with a sharp edge (5 faces) +wedge w2 10 20 30 0 + +# a pyramid +wedge w3 20 20 20 10 10 10 10 + + +@subsubsection occt_2142243456_1869436669732 pcylinder, pcone, psphere, ptorus + +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 name [plane] radius1 radius2 [angle1 angle2] [angle] + +All these commands create solid blocks in the default coordinate system, using the Z axis as the axis of revolution and the X axis as the origin of the angles. To use another system, translate and rotate the resulting solid or use a plane as first argument to specify a coordinate system. All primitives have an optional last argument which is an angle expreesed in degrees and located on the Z axis, starting from the X axis. The default angle is 360. + +**pcylinder **creates a cylindrical block with the given radius and height. + +**pcone **creates a truncated cone of the given height with radius1 in the plane z = 0 and radius2 in the plane z = height. Neither radius can be negative, but one of them can be null. + +**psphere **creates a solid sphere centered on the origin. If two angles, *angle1 *and *angle2, *are given, the solid will be limited by two planes at latitude *angle1 *and *angle2*. The angles must be increasing and in the range -90,90. + +**ptorus **creates a solid torus with the given radii, centered on the origin, which is a point along the z axis. If two angles increasing in degree in the range 0 – 360 are given, the solid will be bounded by two planar surfaces at those positions on the circle. +**Example** + +# a can shape +pcylinder cy 5 10 + +# a quarter of a truncated cone +pcone co 15 10 10 90 + +# three-quarters of sphere +psphere sp 10 270 + +# half torus +ptorus to 20 5 0 90 +@subsubsection occt_2142243456_1869436669733 halfspace + +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** + +box b 0 0 0 1 2 3 +explode b f +==b_1 b_2 b_3 b_4 b_5 b_6 +halfspace hr b_3 0.5 0.5 0.5 + + + +@subsection occt_2142243456_186943666974 Sweeping + +Sweeping creates shapes by sweeping out a shape along a defined path: + + * **prism **sweeps along a direction. + * **revol **sweeps around an axis. + * **pipe **sweeps along a wire. + * **mksweep **and **buildsweep **are commands to create sweeps by defining the arguments and algorithms. + * **thrusections **creates a sweep from wire in different planes. + + +@subsubsection occt_2142243456_1869436669741 prism + +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. + +The shape is swept along the vector dx dy dz. The original shape will be shared in the result unless *Copy *is specified. If *Inf *is specified the prism is infinite in both directions. If *SemiInf *is specified the prism is infinite in the dx,dy,dz direction, and the length of the vector has no importance. +**Example** + +# sweep a planar face to make a solid +polyline f 0 0 0 10 0 0 10 5 0 5 5 0 5 15 0 0 15 0 0 0 0 +mkplane f f + + +@subsubsection occt_2142243456_1869436669742 revol + +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** + +# shell by wire rotation +polyline w 0 0 0 10 0 0 10 5 0 5 5 0 5 15 0 0 15 0 +revol s w 20 0 0 0 1 0 90 + + + +@subsubsection occt_2142243456_1869436669743 pipe + +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** + +# sweep a circle along a bezier curve to make a solid +pipe + +beziercurve spine 4 0 0 0 10 0 0 10 10 0 20 10 0 +mkedge spine spine +wire spine spine +circle profile 0 0 0 1 0 0 2 +mkedge profile profile +wire profile profile +mkplane profile profile +pipe p spine profile + + +@subsubsection occt_2142243456_1869436669744 mksweep, deletesweep, buildsweep, simulsweep + +Syntax:      mksweep wire +addsweep wire[vertex][-M][-C] [auxiilaryshapedeletesweep wire +setsweep options [arg1 [arg2 [...]]] + +options are : + +-FR : Tangent and Normal are defined by a Frenet trihedron +-CF : Tangent is given by Frenet, +the Normal is computed to minimize the torsion +-DX Surf : Tangent and Normal are given by Darboux trihedron, +Surf must be a shell or a face +-CN dx dy dz : BiNormal is given by dx dy dz +-FX Tx Ty TZ [Nx Ny Nz] : Tangent and Normal are fixed +-G guide 0|1(AC +simulsweep r [n] [option] +buildsweep [r] [option] [Tol] + +These commands are used to create a shape from wires. One wire is designated as the contour that defines the direction; it is called the spine. At least one other wire is used to define the the sweep profile. + +**mksweep **initializes the sweep creation and defines the wire to be used as the spine. + +**addsweep **defines the wire to be used as the profile. + +**deletesweep **cancels the choice of profile wire, without leaving the mksweep mode. You can re-select a profile wire. + +**setsweep **commands the algorithms used for the construction of the sweep. + +**simulsweep **can be used to create a preview of the shape. [n] is the number of sections that are used to simulate the sweep. + +**buildsweep **creates the sweep using the arguments defined by all the commands. +**Example** + +#create a sweep based on a semi-circular wire using the +Frenet algorithm +#create a circular figure +circle c2 0 0 0 1 0 0 10 +trim c2 c2 -pi/2 pi/2 +mkedge e2 c2 +donly e2 +wire w e2 +whatis w +mksweep w +# to display all the options for a sweep +setsweep +#to create a sweep using the Frenet algorithm where the +#normal is computed to minimise the torsion +setsweep -CF +addsweep w -R +# to simulate the sweep with a visual approximation +simulsweep w 3 + + +@subsubsection occt_2142243456_1869436669745 thrusections + +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. +**Example** + +#create three wires in three planes +polyline w1 0 0 0 5 0 0 5 5 0 2 3 0 +polyline w2 0 1 3 4 1 3 4 4 3 1 3 3 +polyline w3 0 0 5 5 0 5 5 5 5 2 3 5 +# create the shape +thrusections th issolid isruled w1 w2 w3 +==thrusections th issolid isruled w1 w2 w3 +Tolerances obtenues   -- 3d : 0 +-- 2d : 0 + + + + + +@subsection occt_2142243456_186943666975 Topological transformation + +Transformations are applications of matrices. When the transformation is nondeforming, such as translation or rotation, the object is not copied. The topology localcoordinate system feature is used. The copy can be enforced with the **tcopy **command. + + * **tcopy **makes a copy of the structure of a shape. + * **ttranslate**, **trotate**, **tmove**, **reset **move a shape. + * **tmirror**, **tscale **always modify the shape. + + +@subsubsection occt_2142243456_1869436669751  tcopy + +Syntax: tcopy name toname [name toname ...] + +Copies the structure of one shape, including the geometry, into another, newer shape. +**Example** + +# create an edge from a curve and copy it +beziercurve c 3 0 0 0 10 0 0 20 10 0 +mkedge e1 c +ttranslate e1 0 5 0 +tcopy e1 e2 +ttranslate e2 0 5 0 +# now modify the curve, only e1 and e2 will be modified + +@subsubsection occt_2142243456_1869436669752  tmove, treset + +Syntax:      tmove name [name ...] shape +reset name [name ...] + +**tmove **and **reset **modify the location, or the local coordinate system of a shape. + +**tmove **applies the location of a given shape to other shapes. **reset **restores one or several shapes it to its or their original coordinate system(s). +**Example** + +# create two boxes +box b1 10 10 10 +box b2 20 0 0 10 10 10 +# translate the first box +ttranslate b1 0 10 0 +# and apply the same location to b2 +tmove b2 b1 +# return to original positions +reset b1 b2 + + +@subsubsection occt_2142243456_1869436669753  ttranslate, trotate + +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. +When creating multiple shapes, the same location is used for all the shapes. (See toto.tcl example below. Note that the code of this file can also be directly executed in interactive mode.) + +Locations are very economic in the data structure because multiple occurences of an object share the topological description. +**Example** +# make rotated copies of a sphere in between two cylinders +# create a file source toto.tcl +# toto.tcl code: +for {set i 0} {$i 360} {incr i 20} { +copy s s$i +trotate s$i 0 0 0 0 0 1 $i +} + +# create two cylinders +pcylinder c1 30 5 +copy c1 c2 +ttranslate c2 0 0 20 + +#create a sphere +psphere s 3 +ttranslate s 25 0 12.5 + +# call the source file for multiple copies +source toto.tcl + + +@subsubsection occt_2142243456_1869436669754  tmirror, tscale + +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. +**Example** + +# mirror a portion of cylinder about the YZ plane +pcylinder c1 10 10 270 +copy c1 c2 +tmirror c2 15 0 0 1 0 0 +# and scale it +tscale c1 0 0 0 0.5 + + + +@subsection occt_2142243456_186943666976 Old Topological operations + + + + * **fuse**, **cut**, **common **are boolean operations. + * **section**, **psection **compute sections. + * **sewing **joins two or more shapes. + + +@subsubsection occt_2142243456_1869436669761 fuse, cut, common + +Syntax:      fuse name shape1 shape2 +cut name shape1 shape2 +common name shape1 shape2 + +**fuse **creates a new shape by a boolean operation on two existing shapes. The new shape contains both originals intact. + +**cut **creates a new shape which contains all parts of the second shape but only the first shape without the intersection of the two shapes. + +**common **creates a new shape which contains only what is in common between the two original shapes in their intersection. +**Example** + +# all four boolean operations on a box and a cylinder + +box b 0 -10 5 20 20 10 +pcylinder c 5 20 + +fuse s1 b c +ttranslate s1 40 0 0 + +cut s2 b c +ttranslate s2 -40 0 0 + +cut s3 c b +ttranslate s3 0 40 0 + +common s4 b c +ttranslate s4 0 -40 0 + + + +@subsubsection occt_2142243456_1869436669762 section, psection + +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. + +**psection **creates a planar section consisting of the edges for the intersection curves on the faces of a shape and a plane. +**Example** + +# section line between a cylinder and a box +pcylinder c 10 20 +box b 0 0 5 15 15 15 +trotate b 0 0 0 1 1 1 20 +section s b c + +# planar section of a cone +pcone c 10 30 30 +plane p 0 0 15 1 1 2 +psection s c p + + +@subsubsection occt_2142243456_1869436669763 sewing + +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. + +**Example** + +# create two adjacent boxes +box b 0 0 0 1 2 3 +box b2 0 2 0 1 2 3 +sewing sr b b2 +whatis sr +sr is a shape COMPOUND FORWARD Free Modified + + +@subsection occt_2142243456_186943666977 New Topological operations + + +The new algorithm of Boolean operations avoids a large number of weak points and limitations presented in the old boolean operation algorithm. + + +@subsubsection occt_2142243456_1869436669771 bop, bopfuse, bopcut, boptuc, bopcommon, + +**bop** defines **shape1** and **shape2** subject to ulterior Boolean operations + +**bopfuse **creates a new shape by a boolean operation on two existing shapes. The new shape contains both originals intact. + +**bopcut **creates a new shape which contains all parts of the second shape but only the first shape without the intersection of the two shapes. + +**boptuc **is a reverced** bopcut**. + +**bopcommon **creates a new shape which contains only whatever is in common between the two original shapes in their intersection. + + +Syntax:      bop shape1 shape2 +bopcommon result +bopfuse result +bopcut result +boptuc result + +These commands have short variants: + +bcommon result shape1 shape2 +bfuse result shape1 shape2 +bcut result shape1 shape2 + + +**bop** fills data structure (DS) of boolean operation for **shape1** and **shape2**. +**bopcommon, bopfuse, bopcut, boptuc **commands used after **bop** command. After one **bop** command it is possible to call several commands from the list above. For example: **bop** S1 S2; **bopfuse** R. + +**Example** + +# all four boolean operations on a box and a cylinder + +box b 0 -10 5 20 20 10 +pcylinder c 5 20 + +# fills data structure +bop b c + +bopfuse s1 +ttranslate s1 40 0 0 + +bopcut s2 +ttranslate s2 -40 0 0 + +boptuc s3 +ttranslate s3 0 40 0 + +bopcommon s4 +ttranslate s4 0 -40 0 + + +Short variants of commands: + +bfuse s11 b c +ttranslate s11 40 0 100 + +bcut s12 b c +ttranslate s12 -40 0 100 + +bcommon s14 b c +ttranslate s14 0 -40 100 + +@subsubsection occt_2142243456_1869436669772 bopsection + +**bopsection **creates a compound object consisting of the edges for the intersection curves on the faces of two shapes. + + +Syntax:      bop shape1 shape2 +bopsection result + + + +Short variant: + +bsection result shape1 shape2 [-2d/-2d1/-2s2] [-a] + + +**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. +**-2d1** - PCurves are computed on first part. +**-2d2 **- PCurves are computed on second part. +**-a**  -    geometries built are approximated. + + +**Example** + +# section line between a cylinder and a box +pcylinder c 10 20 +box b 0 0 5 15 15 15 +trotate b 0 0 0 1 1 1 20 +bop b c +bopsection s +# Short variant: +bsection s2 b c + + +@subsubsection occt_2142243456_1869436669773 bopcheck, bopargshape + +Syntax:      bopcheck shape +bopargcheck shape1 [[shape2] [-F/O/C/T/S/U] [/R|F|T|V|E|I|P]] [#BF] + + +**bopcheck** checks a shape for self-interference. + +**bopargcheck** checks the validity of argument(s) for boolean operations. + +-Boolean Operation + **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) +By default all options are enabled. + + #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. + +**Example** + +# checks a shape on self-interference +box b1 0 0 0 1 1 1 +bopcheck b1 + +# checks the validity of argument for boolean cut operations +box b2 0 0 0 10 10 10 +bopargcheck b1 b2 -C + + +@subsection occt_2142243456_186943666978 Drafting and blending + +Drafting is creation of a new shape by tilting faces through an angle. + +Blending is the creation of a new shape by rounding edges to create a fillet. + + * Use the **depouille **command for drafting. + * Use the **chamf **command to add a chamfer to an edge + * Use the **blend **command for simple blending. + * Use **fubl **for a fusion + blending operation. + * Use **buildevol**, **mkevol**, **updatevol **to realize varying radius blending. + + +@subsubsection occt_2142243456_1869436669781 depouille + +Syntax: dep result shape dirx diry dirz face angle x y x dx dy dz [face angle...] + +**depouille **creates a new shape by drafting one or more faces of a shape. + +Identify the shape(s) to be drafted, the drafting direction, and the face(s) with an angle and an axis of rotation for each face. You can use dot syntax to identify the faces. +**Example** +# draft a face of a box +box b 10 10 10 +explode b f +== b_1 b_2 b_3 b_4 b_5 b_6 + +dep a b 0 0 1 b_2 10 0 10 0 1 0 5 + + +@subsubsection occt_2142243456_1869436669782 chamf + +Syntax:      chamf newname shape edge face S dist +chamf newname shape edge face dist1 dist2 +chamf newname shape edge face A dist angle + +**chamf **creates a chamfer along the edge between faces using: + + * a equal distances from the edge + * the edge, a face and distance, a second distance + * the edge, a reference face and an angle + +Use the dot syntax to select the faces and edges. +
Example
+ +# to create a chamfer based on equal distances from the +edge (45 degree angle) +# create a box +box b 1 2 3 +chamf ch b . . S 0.5 +==Pick an object +# select an edge +==Pick an object +# select an adjacent face +**Example** + +# to create a chamfer based on different distances from +the selected edge +box b 1 2 3 +chamf ch b . . 0.3 0.4 +==Pick an object +# select an edge +==Pick an object +# select an adjacent face +**Example** + +# to create a chamfer based on a distance from the edge +and an angle +box b 1 2 3 +chamf ch b . . A 0.4 30 +==Pick an object +# select an edge +==Pick an object +# select an adjacent face + + +@subsubsection occt_2142243456_1869436669783 blend + +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** + +# blend a box, click on an edge +box b 20 20 20 +blend b b 2 . +==tolerance ang : 0.01 +==tolerance 3d : 0.0001 +==tolerance 2d : 1e-05 +==fleche : 0.001 +==tolblend 0.01 0.0001 1e-05 0.001 +==Pick an object +# click on the edge you want ot fillet + +==COMPUTE: temps total 0.1s dont : +==- Init + ExtentAnalyse 0s +==- PerformSetOfSurf 0.02s +==- PerformFilletOnVertex 0.02s +==- FilDS 0s +==- Reconstruction 0.06s +==- SetRegul 0s + + +@subsubsection occt_2142243456_1869436669784 fubl + +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** + +# fuse-blend two boxes +box b1 20 20 5 +copy b1 b2 +ttranslate b2 -10 10 3 +fubl a b1 b2 1 +See also: **fuse**, **blend** + + +@subsubsection occt_2142243456_1869436669785 mkevol, updatevol, buildevol + +Syntax:      mkevol result object (then use updatevol) [R/Q/P] +updatevol edge u1 radius1 [u2 radius2 ...] +buildevol + +These three commands work together to create fillets with evolving radii. + +**mkevol **allows you to specify the shape and the name of the result. It returns the tolerances of the fillet. + +**updatevol **allows you to describe the filleted edges you want to create. For each edge, you give a set of coordinates: parameter and radius and the command prompts you to pick the edge of the shape which you want to modify. The parameters will be calculated along the edges and the radius function applied to the whole edge. + +**buildevol **produces the result described previously in **mkevol **and **updatevol**. +**Example** + +# makes an evolved radius on a box +box b 10 10 10 +mkevol b b +==tolerance ang : 0.01 +==tolerance 3d : 0.0001 +==tolerance 2d : 1e-05 +==fleche : 0.001 +==tolblend 0.01 0.0001 1e-05 0.001 + +# click an edge +updatevol . 0 1 1 3 2 2 +==Pick an object + +buildevol +==Dump of SweepApproximation +==Error 3d = 1.28548881203818e-14 +==Error 2d = 1.3468326936926e-14 , +==1.20292299999388e-14 +==2 Segment(s) of degree 3 + +==COMPUTE: temps total 0.91s dont : +==- Init + ExtentAnalyse 0s +==- PerformSetOfSurf 0.33s +==- PerformFilletOnVertex 0.53s +==- FilDS 0.01s +==- Reconstruction 0.04s +==- SetRegul 0s + + + +@subsection occt_2142243456_186943666979 Topological analysis + +Analysis of shapes includes commands to compute length, area, volumes and inertial properties. + + * Use **lprops**, **sprops**, **vprops **to compute integral properties. + * Use **bounding **to display the bounding box of a shape. + * Use **distmini **to calculate the minimum distance between two shapes. + + + + +@subsubsection occt_2142243456_1869436669791 lprops, sprops, vprops + +Syntax:      lprops shape +sprops shape +vprops shape + +**lprops **computes the mass properties of all edges in the shape with a linear density of 1, **sprops **of all faces with a surface density of 1 and **vprops **of all solids with a density of 1. + +All three commands print the mass, the coordinates of the center of gravity, the matrix of inertia and the moments. Mass is either the length, the area or the volume. The center and the main axis of inertia are displayed. +**Example** + +# volume of a cylinder +pcylinder c 10 20 +vprops c +== results +Mass : 6283.18529981086 + +Center of gravity : +X = 4.1004749224903e-06 +Y = -2.03392858349861e-16 +Z = 9.9999999941362 + +Matrix of Inertia : +366519.141445068                    5.71451850691484e-12 +0.257640437382627 +5.71451850691484e-12                366519.141444962 +2.26823064169991e-10                0.257640437382627 +2.26823064169991e-10                314159.265358863 + +Moments : +IX = 366519.141446336 +IY = 366519.141444962 +I.Z = 314159.265357595 + + + +@subsubsection occt_2142243456_1869436669792  bounding + +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 - +5.0000001000000003 +==27.059805107309852               27.059805107309852 +5.0000001000000003 + + +@subsubsection occt_2142243456_1869436669793 distmini + +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** + +box b 0 0 0 10 20 30 +box b2 30 30 0 10 20 30 +distmini d1 b b2 +==the distance value is : 22.3606797749979 +==the number of solutions is :2 + +==solution number 1 +==the type of the solution on the first shape is 0 +==the type of the solution on the second shape is 0 +==the coordinates of the point on the first shape are: +==X=10 Y=20 Z=30 +==the coordinates of the point on the second shape +are: +==X=30 Y=30 Z=30 + +==solution number 2: +==the type of the solution on the first shape is 0 +==the type of the solution on the second shape is 0 +==the coordinates of the point on the first shape are: +==X=10 Y=20 Z=0 +==the coordinates of the point on the second shape +are: +==X=30 Y=30 Z=0 + +==d1_val d1 d12 + + + + +@subsection occt_2142243456_1869436669710 Surface creation + +Surface creation commands include surfaces created from boundaries and from spaces between shapes. + + * gplate creates a surface from a boundary definition. + * filling creates a surface from a group of surfaces. + + +@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] ... + +**gplate **creates a surface from a defined boundary. The boundary can be defined using edges, points, or other surfaces. +
Example
+ +plane p +trim p p -1 3 -1 3 +mkface p p + +beziercurve c1 3 0 0 0 1 0 1 2 0 0 +mkedge e1 c1 +tcopy e1 e2 +tcopy e1 e3 + +ttranslate e2 0 2 0 +trotate e3 0 0 0 0 0 1 90 +tcopy e3 e4 +ttranslate e4 2 0 0 +# create the surface +gplate r1 4 0 p e1 0 e2 0 e3 0 e4 0 +== +======== Results =========== +DistMax=8.50014503228635e-16 +* GEOMPLATE END* +Calculation time: 0.33 +Loop number: 1 +Approximation results +Approximation error : 2.06274907619957e-13 +Criterium error : 4.97600631215754e-14 + +#to create a surface defined by edges and passing through a point +# to define the border edges and the point +plane p +trim p p -1 3 -1 3 +mkface p p + +beziercurve c1 3 0 0 0 1 0 1 2 0 0 +mkedge e1 c1 +tcopy e1 e2 +tcopy e1 e3 + +ttranslate e2 0 2 0 +trotate e3 0 0 0 0 0 1 90 +tcopy e3 e4 +ttranslate e4 2 0 0 +# to create a point +point pp 1 1 0 +# to create the surface +gplate r2 4 1 p e1 0 e2 0 e3 0 e4 0 pp +== +======== Results =========== +DistMax=3.65622157610934e-06 +* GEOMPLATE END* +Calculculation time: 0.27 +Loop number: 1 +Approximation results +Approximation error : 0.000422195884750181 +Criterium error : 3.43709808053967e-05 + +@subsubsection occt_2142243456_18694366697102  filling, fillingparam + +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. + +To define the surface border: + + * enter the number of edges, constraints, and points + * enumerate the edges, constraints and points + +The surface can pass through other points. These are defined after the border definition. + +You can use the **fillingparam **command to access the filling parameters. + +The options are: + +-l : to list current values + +-i : to set default values + +-r deg nbPonC nbIt anis : to set filling options + +-c t2d t3d tang tcur : to set tolerances + +-a maxdeg maxseg : Approximation option +**Example** + +# to create four curved survaces and a point +plane p +trim p p -1 3 -1 3 +mkface p p + +beziercurve c1 3 0 0 0 1 0 1 2 0 0 +mkedge e1 c1 +tcopy e1 e2 +tcopy e1 e3 + +ttranslate e2 0 2 0 +trotate e3 0 0 0 0 0 1 90 +tcopy e3 e4 +ttranslate e4 2 0 0 + +point pp 1 1 0 + +prism f1 e1 0 -1 0 +prism f2 e2 0 1 0 +prism f3 e3 -1 0 0 +prism f4 e4 1 0 0 + +# to create a tangential surface +filling r1 4 0 0 p e1 f1 1 e2 f2 1 e3 f3 1 e4 f4 1 +# to create a tangential surface passing through point pp +filling r2 4 0 1 p e1 f1 1 e2 f2 1 e3 f3 1 e4 f4 1 pp# +# to visualise the surface in detail +isos r2 40 +# to display the current filling parameters +fillingparam -l +== +Degree = 3 +NbPtsOnCur = 10 +NbIter = 3 +Anisotropie = 0 +Tol2d = 1e-05 +Tol3d = 0.0001 +TolAng = 0.01 +TolCurv = 0.1 + +MaxDeg = 8 +MaxSegments = 9 + + + + +@subsection occt_2142243456_1869436669711 Complex Topology + +Complex topology is the group of commands that modify the topology of shapes. This includes feature modeling. + + +@subsubsection occt_2142243456_18694366697111 offsetshape, offsetcompshape + +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. + +The resulting shape is based on a calculation of intersections. In case of simple shapes such as a box, only the adjacent intersections are required and you can use the **offsetshape **command. + +In case of complex shapes, where intersections can occur from non-adjacent edges and faces, use the **offsetcompshape **command. **comp **indicates complete and requires more time to calculate the result. + + +The opening between the object interior and exterior is defined by the argument face or faces. +**Example** + +box b1 10 20 30 +explode b1 f +== 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 + +**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**. +**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. +**Example** + +box b1 10 20 30 +explode b1 f +== b1_1 b1_2 b1_3 b1_4 b1_5 b1_6 +offsetparameter 1e-7 p i +offsetload b1 2 b1_1 b1_2 +offsetonface b1_3 5 +offsetperform result + + + +@subsubsection occt_2142243456_18694366697112 featprism, featdprism, featrevol, featlf, featrf + +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) +featrf shape wire plane X Y Z DirX DirY DirZ Size Size Fuse(0/1/2) Modify(0/1) +featperform prism/revol/pipe/dprism/lf result [[Ffrom] Funtil] +featperformval prism/revol/dprism/lf result value + +**featprism **loads the arguments for a prism with contiguous sides normal to the face. + +**featdprism **loads the arguments for a prism which is created in a direction normal to the face and includes a draft angle. + +**featrevol **loads the arguments for a prism with a circular evolution. + +**featlf **loads the arguments for a linear rib or slot. This feature uses planar faces and a wire as a guideline. + +**featrf **loads the arguments for a rib or slot with a curved surface. This feature uses a circular face and a wire as a guideline. + +**featperform **loads the arguments to create the feature. + +**featperformval **uses the defined arguments to create a feature with a limiting value. + +All the features are created from a set of arguments which are defined when you initialize the feature context. Negative values can be used to create depressions. +**Example** + +# to create a feature prism with a draft angle and a +normal direction +# create a box with a wire contour on the upper face +box b 1 1 1 +profil f O 0 0 1 F 0.25 0.25 x 0.5 y 0.5 x -0.5 +explode b f +# loads the feature arguments defining the draft angle +featdprism b f b_6 5 1 0 +# create the feature +featperformval dprism r 1 +==BRepFeat_MakeDPrism::Perform(Height) +BRepFeat_Form::GlobalPerform () +Gluer +still Gluer +Gluer result + +# to create a feature prism with circular direction +# create a box with a wire contour on the upper face +box b 1 1 1 +profil f O 0 0 1 F 0.25 0.25 x 0.5 y 0.5 x -0.5 +explode b f +# loads the feature arguments defining a rotation axis +featrevol b f b_6 1 0 1 0 1 0 1 0 +featperformval revol r 45 +==BRepFeat_MakeRevol::Perform(Angle) +BRepFeat_Form::GlobalPerform () +Gluer +still Gluer +Gluer result + +# to create a slot using the linear feature +#create the base model using the multi viewer +mu4 +profile p x 5 y 1 x -3 y -0.5 x -1.5 y 0.5 x 0.5 y 4 x -1 y -5 +prism pr p 0 0 1 +# create the contour for the linear feature +vertex v1 -0.2 4 0.3 +vertex v2 0.2 4 0.3 +vertex v3 0.2 0.2 0.3 +vertex v4 4 0.2 0.3 +vertex v5 4 -0.2 0.3 +edge e1 v1 v2 +edge e2 v2 v3 +edge e3 v3 v4 +edge e4 v4 v5 +wire w e1 e2 e3 e4 +# define a plane +plane pl 0.2 0.2 0.3 0 0 1 +# loads the linear feature arguments +featlf pr w pl 0 0 0.3 0 0 0 0 1 +featperform lf result + +# to create a rib using the revolution feature +#create the base model using the multi viewer +mu4 +pcylinder c1 3 5 +# create the contour for the revolution feature +profile w c 1 190 WW +trotate w 0 0 0 1 0 0 90 +ttranslate w -3 0 1 +trotate w -3 0 1.5 0 0 1 180 +plane pl -3 0 1.5 0 1 0 +# loads the revolution feature arguments +featrf c1 w pl 0 0 0 0 0 1 0.3 0.3 1 1 +featperform rf result + + +@subsubsection occt_2142243456_18694366697113 draft + +Syntax: draft result shape dirx diry dirz angle shape/surf/length [-IN/-OUT] [Ri/Ro] [-Internal] + +**draft **computes a draft angle surface from a wire. The surface is determined by the draft direction, the inclination of the draft surface, a draft angle, and a limiting distance. + + * The draft angle is measured in radians. + * The draft direction is determined by the argument -INTERNAL + * The argument Ri/Ro deftermines wether the corner edges of the + +draft surface are angular or rounded. + + * Arguments that can be used to define the surface distance are: + * length, a defined distance + * shape, until the surface contacts a shape + * surface, until the surface contacts a surface. + +

NOTE

+*The original aim of adding a draft angle to a shape is to* +*produce a shape which can be removed easily from a mould.* +*The Examples below use larger angles than are used normally* +*and the calculation results returned are not indicated.* + +**Example** + +# to create a simple profile +profile p F 0 0 x 2 y 4 tt 0 4 w +# creates a draft with rounded angles +draft res p 0 0 1 3 1 -Ro +# to create a profile with an internal angle +profile p F 0 0 x 2 y 4 tt 1 1.5 tt 0 4 w +# creates a draft with rounded external angles +draft res p 0 0 1 3 1 -Ro + + +@subsubsection occt_2142243456_18694366697114 deform, nurbsconvert + +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. + +Syntax nurbsconvert result name [result name] + +**nurbsconvert **changes the NURBS curve definition of a shape to a Bspline curve definition. This conversion is required for assymetric deformation and prepares the arguments for other commands such as **deform. **The conversion can be necessary when transferring shape data to other applications. +**Example** + +pcylinder c 20 20 +deform a c 1 3 5 +# the conversion to bspline is followed by the +deformation + + + +@subsection occt_2142243456_1869436669712 Texture Mapping to a Shape + +Texture mapping allows you to map textures on a shape. Textures are texture image files and several are predefined. You can control the number of occurrences of the texture on a face, the position of a texture and the scale factor of the texture. + +@subsubsection occt_2142243456_18694366697121 vtexture + +Syntax       vtexture NameOfShape TextureFile +vtexture NameOfShape +vtexture NameOfShape ? +vtexture NameOfShape IdOfTexture + +**TextureFile **identifies the file containing the texture you want. The same syntax without **TextureFile **disables texture mapping. The question-mark ***?* **lists available textures. **IdOfTexture **allows you to apply predefined textures. + +@subsubsection occt_2142243456_18694366697122 vtexscale + +Syntax:      vtexscale NameOfShape ScaleU ScaleV +vtexscale NameOfShape ScaleUV +vtexscale NameOfShape + +**ScaleU **and **Scale V **allow you to scale the texture according to the U and V parameters individually, while **ScaleUV **applies the same scale to both parameters. The same syntax without **ScaleU**, **ScaleV **or **ScaleUV **disables texture scaling. + +@subsubsection occt_2142243456_18694366697123 vtexorigin + +Syntax       vtexorigin NameOfShape UOrigin VOrigin +vtexorigin NameOfShape UVOrigin +vtexorigin NameOfShape + +**UOrigin **and **VOrigin **allow you to place the texture according to the U and V parameters individually while **UVOrigin **applies the same position value to both parameters. The same syntax without **UOrigin**, **VOrigin **or **UVOrigin **disables origin positioning. + +@subsubsection occt_2142243456_18694366697124 vtexrepeat + +Syntax       vtexrepeat NameOfShape URepeat VRepeat +vtexrepeat NameOfShape UVRepeat +vtexrepeat NameOfShape + +**URepeat **and **VRepeat **allow you to repeat the texture along the U and V parameters individually while **UVRepeat **applies the same number of repetitions for both parameters. The same syntax without **URepeat**, **VRepeat **or **UVRepeat **disables texture repetition. + +@subsubsection occt_2142243456_18694366697125 vtexdefault + +Syntax       vtexdefault NameOfShape + +**Vtexdefault **sets or resets the texture mapping default parameters. + +The defaults are: + +URepeat = VRepeat = 1 = no repetition +UOrigin = VOrigin = 1 = origin set at (0,0) +UScale = VScale = 1 = texture covers 100% of the face +@section occt_2142243456_1866931135 Data Exchange commands + + +@subsection occt_2142243456_186693113581 General + +This paragraph presents some general information about Data Exchange (DE) operations. + +DE commands are intended for translation files of various formats (IGES,STEP) into OCCT shapes with their attributes (colors, layers etc.) + +This files include a number of entities. Each entity has its own number in the file which we call label and denote as # for a STEP file and D for an IGES file. Each file has entities called roots (one or more). A full description of such entities is contained in the Users’s Guide for a corresponding format. + +Each Draw session has an interface model – some structure for keeping various information. +First step of translation – loading information from a file into a model. +Second step – creation of an OpenCASCADE shape from this model. +Each entity from file has its own number in the model (num). +During the translation a map of correspondences between labels(from file) and numbers (from model) is created. +The model and the mentioned map are used for working with most of DE commands. + +@subsection occt_2142243456_186693113582 IGES commands + +These commands are used during the translation of IGES models. + + +@subsubsection occt_2142243456_1866931135821 igesread + +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: + + +After the selected set of entities is loaded the user will be asked how loaded entities should be converted into OCCT shapes (e.g., one shape per root or one shape for all the entities). It is also possible to save loaded shapes in files, and to cancel loading. +The second parameter of this command defines the name of the loaded shape. If several shapes are created, they will get indexed names. For instance, if the last parameter was ‘s’, they will be s_1, ... s_N. +selection specifies the scope of selected entities in the model, it is xst-transferrable-roots by default. More about selection see in the *IGES FORMAT User’s Guide*. +If we use symbol * as selection all roots will be translated. +
Example
+ +# translation all roots from file +igesread /disk01/files/model.igs a * + +@subsubsection occt_2142243456_1866931135822  tplosttrim + +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. +Optional parameter IGES_type can be TrimmedSurface, BoundedSurface or Face to specify the only type of IGES faces. +
Example
+ +tplosttrim TrimmedSurface + +@subsubsection occt_2142243456_1866931135823 brepiges + +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 +== 1 Shapes written, giving 345 Entities +==  Now, to write a file, command : writeall filename +==  Output on file : /disk1/tmp/aaa.igs +==  Write OK + + + +@subsection occt_2142243456_186693113583 STEP commands + +These commands are used during the translation of STEP models. + + +@subsubsection occt_2142243456_1866931135831 stepread + +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: + + +After the selected set of entities is loaded the user will be asked how loaded entities should be converted into OCCT shapes. +The second parameter of this command defines the name of the loaded shape. If several shapes are created, they will get indexed names. For instance, if the last parameter was ‘s’, they will be s_1, ... s_N. +selection specifies the scope of selected entities in the model. More about selection see in the *STEP FORMAT User’s Guide*. +If as selection we use symbol * all roots will be translated. +
Example
+ +# translation all roots from file +stepread /disk01/files/model.stp a * + +@subsubsection occt_2142243456_1866931135832  stepwrite + +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 +For further information see ;STEP FORMAT User’s Guide ;. +
Example
+ +# write shape with name a to STEP file with mode 0 +stepwrite 0 a /disk1/tmp/aaa.igs + + + +@subsection occt_2142243456_186693113584 General commands + +These commands are auxilary commands. Most of them are used for the analysis of result of translation of IGES and STEP files. + +@subsubsection occt_2142243456_1866931135841 count + +Syntax:      count counter [selection] + +Is used to calculate statistics on the entities in the model. +Gives us a count of entities. +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 (for example): + +
Example
+ +count xst-types + +@subsubsection occt_2142243456_1866931135842 data + +Syntax:      data symbol + +Is used to obtain general statistics on the loaded data. +Information printed by this command depends on the symbol specified: +
Example
+ +# print full information about warnings and fails +data c + +@subsubsection occt_2142243456_1866931135843 elabel + +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. +
Example
+ +elabel 84 + +@subsubsection occt_2142243456_1866931135844 entity + +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. +level_of_information has range [0-6]. You can get more information about this level using this command without parameters. +
Example
+ +# full information for STEP entity with label 84 +entity #84 6 + +@subsubsection occt_2142243456_1866931135845 enum + +Syntax:      enum #(D) + +Prints a number for the entity with a given label. +
Example
+ +# give a number for IGES entity with label 21 +enum D21 + +@subsubsection occt_2142243456_1866931135846 estatus + +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. +
Example
+ +estatus #315 + +@subsubsection occt_2142243456_1866931135847 fromshape + +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. +
Example
+ +fromshape a_1_23 + +@subsubsection occt_2142243456_1866931135848 givecount + +Syntax:      givecount selection_name [selection_name] + +
Example
+ +givecount xst-model-roots + +@subsubsection occt_2142243456_1866931135849 givelist + +Syntax:      givelist selection_name + +Prints a list of a subset of loaded entities defined by the selection argument: + +
Example
+ +# give a list of all entities of the model +givelist xst-model-all + +@subsubsection occt_2142243456_18669311358410 listcount + +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: + +
Example
+ +listcount xst-types + +@subsubsection occt_2142243456_18669311358411 listitems + +Syntax:      listitems + +This command prints a list of objects (counters, selections etc.) defined in the current session. +
Example
+ +listitems + +@subsubsection occt_2142243456_18669311358412 listtypes + +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. +
Example
+ +# full list of all entities with thier counts +listtypes + +@subsubsection occt_2142243456_18669311358413 newmodel + +Syntax:      newmodel + +Clears the current model. +
Example
+ +newmodel + +@subsubsection occt_2142243456_18669311358414 param + +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. +Command with parameter (without value) gives us the current value of this parameter and all possible values for it. Command with value sets this new value to parameter. +For more information about translation parameters see the corresponding User’s Guide. +
Example
+ +# info about possible schemes for writing STEP file +param write.step.schema + +@subsubsection occt_2142243456_18669311358415 sumcount + +Syntax:      sumcount counter [selection ...] + +Prints only a number of entities per each type matching the criteria defined by arguments. +
Example
+ +sumcount xst-types + +@subsubsection occt_2142243456_18669311358416 tpclear + +Syntax:      tpclear + +Clears the map of correspondences between IGES or STEP entities and OCCT shapes. +
Example
+ +tpclear + +@subsubsection occt_2142243456_18669311358417 tpdraw + +Syntax:      tpdraw #(D)_or_num + +
Example
+ +tpdraw 57 + +@subsubsection occt_2142243456_18669311358418 tpent + +Syntax:      tpent #(D)_or_num + +
Example
+ +tpent #23 + +@subsubsection occt_2142243456_18669311358419 tpstat + +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: + + +The sign ‘*’ before the parameters **n**, **s**, **b**, **t**, **r** makes it work on all entities (not only on roots). The sign ‘?’ before **n**, **s**, **b**, **t** limits the scope of information to invalid entities. +Optional argument selection can limit the action of the command with a selected subset of entities. +
Example
+ +# translation ratio on IGES faces +tpstat *l iges-faces + +@subsubsection occt_2142243456_18669311358420 xload + +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. +
Example
+ +xload /disk1/tmp/aaa.stp + + + +@subsection occt_2142243456_186693113585 Overview of XDE commands + +These commands are used for translation of IGES and STEP files into an XCAF document (special document is inherited from CAF document and is intended for Extended Data Exchange (XDE) ) and working with it. XDE translation allows reading and writing of shapes with additional attributes – colors, layers etc. All commands can be divided into the following groups: + * **XDE translation commands** + * **XDE general commands** + * **XDE shape’s commands** + * **XDE color’s commands** + * **XDE layer’s commands** + * **XDE property’s commands** + + + +@subsection occt_2142243456_186693113586 XDE translation commands + +Reminding: All operations of translation are performed with parameters managed by command param (see above) + +@subsubsection occt_2142243456_1866931135861 ReadIges + +Syntax:      ReadIges document file_name + +Reads information from an IGES file to an XCAF document. +
Example
+ +ReadIges D /disk1/tmp/aaa.igs +== Document saved with name D + +@subsubsection occt_2142243456_1866931135862 ReadStep + +Syntax:      ReadStep document file_name + +Reads information from a STEP file to an XCAF document. +
Example
+ +ReadStep D /disk1/tmp/aaa.stp +== Document saved with name D + +@subsubsection occt_2142243456_1866931135863 WriteIges + +Syntax:      WriteIges document file_name + +
Example
+ +WriteIges D /disk1/tmp/aaa.igs + +@subsubsection occt_2142243456_1866931135864 WriteStep + +Syntax:      WriteStep document file_name + +Writes information from an XCAF document to a STEP file. +
Example
+ +WriteStep D /disk1/tmp/aaa.stp + +@subsubsection occt_2142243456_1866931135865 XFileCur + +Syntax:      XFileCur + +Returns the name of file which is set as the current one in the Draw session. +
Example
+ +XFileCur +== *as1-ct-203.stp* + +@subsubsection occt_2142243456_1866931135866 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. +
Example
+ +XFileList +== *as1-ct-Bolt.stp* +== *as1-ct-L-Bracktet.stp* +== *as1-ct-LBA.stp* +== *as1-ct-NBA.stp* +== … + +@subsubsection occt_2142243456_1866931135867 XFileSet + +Syntax:      XFileSet filename + +Sets the current file taking it from the components list of the assemble file. +
Example
+ +XFileSet as1-ct-NBA.stp + +@subsubsection occt_2142243456_1866931135868 XFromShape + +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. +
Example
+ +XFromShape a +== Shape a: imported from entity 217:#26 in file as1-ct-Nut.stp + + +@subsection occt_2142243456_186693113587 XDE general commands + +@subsubsection occt_2142243456_1866931135871 XNewDoc + +Syntax:      XNewDoc document + +Creates a new XCAF document. +
Example
+ +XNewDoc D + +@subsubsection occt_2142243456_1866931135872 XShow + +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. +
Example
+ +# show shape from label 0:1:1:4 from document D +XShow D 0:1:1:4 + +@subsubsection occt_2142243456_1866931135873 XStat + +Syntax:      XStat document + +Prints common information from an XCAF document. +
Example
+ +XStat D +==Statistis of shapes in the document: +==level N 0 : 9 +==level N 1 : 18 +==level N 2 : 5 +==Total number of labels for shapes in the document = 32 +==Number of labels with name = 27 +==Number of labels with color link = 3 +==Number of labels with layer link = 0 +==Statistis of Props in the document: +==Number of Centroid Props = 5 +==Number of Volume Props = 5 +==Number of Area Props = 5 +==Number of colors = 4 +==BLUE1 RED YELLOW BLUE2 +==Number of layers = 0 + +@subsubsection occt_2142243456_1866931135874 XWdump + +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. +
Example
+ +XWdump D /disk1/tmp/image.png + +@subsubsection occt_2142243456_1866931135875 Xdump + +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. +
Example
+ +Xdump D 1 +== ASSEMBLY 0:1:1:1 L-BRACKET(0xe8180448) +== ASSEMBLY 0:1:1:2 NUT(0xe82151e8) +== ASSEMBLY 0:1:1:3 BOLT(0xe829b000) +== 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) +etc. + + +@subsection occt_2142243456_186693113588 XDE shape’s commands + +@subsubsection occt_2142243456_1866931135881 XAddComponent + +Syntax:      XAddComponent document label shape + +Adds a component shape to assembly. +
Example
+ +# Add shape b as component shape to assembly shape from +# label 0:1:1:1 +XAddComponent D 0:1:1:1 b + +@subsubsection occt_2142243456_1866931135882 XAddShape + +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. +
Example
+ +# add shape b to document D +XAddShape D b 0 +== 0:1:1:10 +# if pointed shape is compound and last parameter in +# XAddShape command is used by default (1), then for +# each subshapes new label is created + +@subsubsection occt_2142243456_1866931135883 XFindComponent + +Syntax:      XFindComponent document shape + +Prints a sequence of labels of the assembly path. +
Example
+ +XFindComponent D b + +@subsubsection occt_2142243456_1866931135884 XFindShape + +Syntax:      XFindShape document shape + +Finds and prints a label with an indicated top-level shape. +
Example
+ +XFindShape D a + +@subsubsection occt_2142243456_1866931135885 XGetFreeShapes + +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 +[shape_prefix]_num (i.e. for example: there are 3 free shapes and [shape_prefix] = a therefore shapes will be created with names a_1, a_2 and a_3). +Note: a free shape is a shape to which no other shape refers to. +
Example
+ +XGetFreeShapes D +== 0:1:1:6 0:1:1:10 0:1:1:12 0:1:1:13 + +XGetFreeShapes D sh +== sh_1 sh_2 sh_3 sh_4 + +@subsubsection occt_2142243456_1866931135886 XGetOneShape + +Syntax:      XGetOneShape shape document + +Creates one DRAW shape for all free shapes from a document. +
Example
+ +XGetOneShape a D + +@subsubsection occt_2142243456_1866931135887 XGetReferredShape + +Syntax:      XGetReferredShape document label + +Prints a label that contains a top-level shape that corresponds to a shape at a given label. +
Example
+ +XGetReferredShape D 0:1:1:1:1 + +@subsubsection occt_2142243456_1866931135888 XGetShape + +Syntax:      XGetShape result document label + +Puts a shape from the indicated label in document to result. +
Example
+ +XGetShape b D 0:1:1:3 + +@subsubsection occt_2142243456_1866931135889 XGetTopLevelShapes + +Syntax:      XGetTopLevelShapes document + +Prints labels that contain top-level shapes. +
Example
+ +XGetTopLevelShapes D +== 0:1:1:1 0:1:1:2 0:1:1:3 0:1:1:4 0:1:1:5 0:1:1:6 0:1:1:7 +0:1:1:8 0:1:1:9 + +@subsubsection occt_2142243456_18669311358810 XLabelInfo + +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 + +Creates a new empty top-level shape. +
Example
+ +XNewShape D + +@subsubsection occt_2142243456_18669311358812 XRemoveComponent + +Syntax:      XRemoveComponent document label + +Removes a component from the components label. +
Example
+ +XRemoveComponent D 0:1:1:1:1 + +@subsubsection occt_2142243456_18669311358813 XRemoveShape + +Syntax:      XRemoveShape document label + +Removes a shape from a document (by it’s label). +
Example
+ +XRemoveShape D 0:1:1:2 + +@subsubsection occt_2142243456_18669311358814 XSetShape + +Syntax:      XSetShape document label shape + +Sets a shape at the indicated label. +
Example
+ +XSetShape D 0:1:1:3 b + + +@subsection occt_2142243456_186693113589 XDE color’s commands + +@subsubsection occt_2142243456_1866931135891 XAddColor + +Syntax:      XAddColor document R G B + +Adds color in document to the color table. Parameters R,G,B are real. +
Example
+ +XAddColor D 0.5 0.25 0.25 + +@subsubsection occt_2142243456_1866931135892 XFindColor + +Syntax:      XFindColor document R G B + +Finds a label where the indicated color is situated. +
Example
+ +XFindColor D 0.25 0.25 0.5 +== 0:1:2:2 + +@subsubsection occt_2142243456_1866931135893 XGetAllColors + +Syntax:      XGetAllColors document + +Prints all colors that are defined in the document. +
Example
+ +XGetAllColors D +== RED DARKORANGE BLUE1 GREEN YELLOW3 + +@subsubsection occt_2142243456_1866931135894 XGetColor + +Syntax:      XGetColor document label + +Returns a color defined at the indicated label from the color table. +
Example
+ +XGetColor D 0:1:2:3 +== BLUE1 + +@subsubsection occt_2142243456_1866931135895 XGetObjVisibility + +Syntax:      XGetObjVisibility document {label|shape} + +Returns the visibility of a shape. +
Example
+ +XGetObjVisibility D 0:1:1:4 + +@subsubsection occt_2142243456_1866931135896 XGetShapeColor + +Syntax:      XGetShapeColor document label colortype(s|c) + +Returns the color defined by label. If colortype=’s’ – returns surface color, else – returns curve color. +
Example
+ +XGetShapeColor D 0:1:1:4 c + +@subsubsection occt_2142243456_1866931135897 XRemoveColor + +Syntax:      XRemoveColor document label + +Removes a color from the color table in a document. +
Example
+ +XRemoveColor D 0:1:2:1 + +@subsubsection occt_2142243456_1866931135898 XSetColor + +Syntax:      XSetColor document {label|shape} R G B + +Sets an RGB color to a shape given by label. +
Example
+ +XsetColor D 0:1:1:4 0.5 0.5 0. + +@subsubsection occt_2142243456_1866931135899 XSetObjVisibility + +Syntax:      XSetObjVisibility document {label|shape} {0|1} + +Sets the visibility of a shape. +
Example
+ +# set shape from label 0:1:1:4 as invisible +XSetObjVisibility D 0:1:1:4 0 + +@subsubsection occt_2142243456_18669311358910 XUnsetColor + +Syntax:      XUnsetColor document {label|shape} colortype + +Unset a color given??? type (‘s’ or ‘c’) for the indicated shape. +
Example
+ +XUnsetColor D 0:1:1:4 s + + +@subsection occt_2142243456_1866931135810 XDE layer’s commands + +@subsubsection occt_2142243456_18669311358101 XAddLayer + +Syntax:      XAddLayer document layer + +Adds a new layer in an XCAF document. layer - name of new layer (string). +
Example
+ +XAddLayer D layer2 + +@subsubsection occt_2142243456_18669311358102 XFindLayer + +Syntax:      XFindLayer document layer + +Prints a label where a layer is situated. +
Example
+ +XFindLayer D Bolt +== 0:1:3:2 + +@subsubsection occt_2142243456_18669311358103 XGetAllLayers + +Syntax:      XGetAllLayers document + +Prints all layers in an XCAF document. +
Example
+ +XGetAllLayers D +== *0:1:1:3* *Bolt* *0:1:1:9* + +@subsubsection occt_2142243456_18669311358104 XGetLayers + +Syntax:      XGetLayers document {shape|label} + +Returns names of layers, which are pointed to by links of an indicated shape. +
Example
+ +XGetLayers D 0:1:1:3 +== *bolt* *123* + +@subsubsection occt_2142243456_18669311358105 XGetOneLayer + +Syntax:      XGetOneLayer document label + +Prints the name of a layer at a given label. +
Example
+ +XGetOneLayer D 0:1:3:2 + +@subsubsection occt_2142243456_18669311358106 XIsVisible + +Syntax:      XIsVisible document {label|layer} + +Returns 1 if the indicated layer is visible, else returns 0. +
Example
+ +XIsVisible D 0:1:3:1 + +@subsubsection occt_2142243456_18669311358107 XRemoveAllLayers + +Syntax:      XRemoveAllLayers document + +Removes all layers from an XCAF document. +
Example
+ +XRemoveAllLayers D + +@subsubsection occt_2142243456_18669311358108 XRemoveLayer + +Syntax:      XRemoveLayer document {label|layer} + +Removes the indicated layer from an XCAF document. +
Example
+ +XRemoveLayer D layer2 + +@subsubsection occt_2142243456_18669311358109 XSetLayer + +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). +
Example
+ +XSetLayer D 0:1:1:2 layer2 + +@subsubsection occt_2142243456_186693113581010 XSetVisibility + +Syntax:      XSetVisibility document {label|layer} isvisible {0|1} + +Sets the visibility of a layer. +
Example
+ +# set layer at label 0:1:3:2 as invisible +XSetVisibility D 0:1:3:2 0 + +@subsubsection occt_2142243456_186693113581011 XUnSetAllLayers + +Syntax:      XUnSetAllLayers document {label|shape} + +Unsets a shape from all layers. +
Example
+ +XUnSetAllLayers D 0:1:1:2 + +@subsubsection occt_2142243456_186693113581012 XUnSetLayer + +Syntax:      XUnSetLayer document {label|shape} layer + +Unsets a shape from the indicated layer. +
Example
+ +XUnSetLayer D 0:1:1:2 layer1 + + +@subsection occt_2142243456_1866931135811 XDE property’s commands + +@subsubsection occt_2142243456_18669311358111 XCheckProps + +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. +
Example
+ +# 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 + +@subsubsection occt_2142243456_18669311358112 XGetArea + +Syntax:      XGetArea document {shape|label} + +Returns the area of a given shape. +
Example
+ +XGetArea D 0:1:1:1 +== 24628.31815094999 + +@subsubsection occt_2142243456_18669311358113 XGetCentroid + +Syntax:      XGetCentroid document {shape|label} + +Returns the center of gravity coordinates of a given shape. +
Example
+ +XGetCentroid D 0:1:1:1 + +@subsubsection occt_2142243456_18669311358114 XGetVolume + +Syntax:      XGetVolume document {shape|label} + +Returns the volume of a given shape. +
Example
+ +XGetVolume D 0:1:1:1 + +@subsubsection occt_2142243456_18669311358115 XSetArea + +Syntax:      XSetArea document {shape|label} area + +Sets new area to attribute list ??? given shape. +
Example
+ +XSetArea D 0:1:1:1 2233.99 + +@subsubsection occt_2142243456_18669311358116 XSetCentroid + +Syntax:      XSetCentroid document {shape|label} x y z + +Sets new center of gravity  to the attribute list ??? given shape. +
Example
+ +XSetCentroid D 0:1:1:1 0. 0. 100. + +@subsubsection occt_2142243456_18669311358117 XSetMaterial + +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. +
Example
+ +XSetMaterial D 0:1:1:1 Titanium 8899.77 + +@subsubsection occt_2142243456_18669311358118 XSetVolume + +Syntax:      XSetVolume document {shape|label} volume + +Sets new volume to the attribute list ??? given shape. +
Example
+ +XSetVolume D 0:1:1:1 444555.33 + +@subsubsection occt_2142243456_18669311358119 XShapeMassProps + +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. +
Example
+ +XShapeMassProps D +== Shape from label : 0:1:1:1 +== Mass = 193.71681469282299 +== CenterOfGravity X = 14.594564763807696,Y = +    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 + +Calculates the real volume of a pointed shape with a given deflection. +
Example
+ +XShapeVolume a 0 + +@section occt_2142243456_1672096717 Shape Healing commands + + + +@subsection occt_2142243456_16720967171 General commands + +@subsubsection occt_2142243456_1672096717111 bsplres + +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 + +Shows where a point which is given by coordinates is located in relation to a given face – outbound, inside or at the bounds. +
Example
+ +checkfclass2d f 10.5 1.1 +== Point is OUT + +@subsubsection occt_2142243456_1672096717113 checkoverlapedges + +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. +
Example
+ +checkoverlapedges e1 e2 + +@subsubsection occt_2142243456_1672096717114 comtol + +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 +== Relation real tolerance / tolerance set in edge +== MAX=0.80001130696523448 AVG=0.06349345591805905 MIN=0 +== Edge with max tolerance saved to t_edge_tol +== Concerned faces saved to shapes t_1, t_2 + + +@subsubsection occt_2142243456_1672096717115 convtorevol + +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. +
Example
+ +convtorevol r a + +@subsubsection occt_2142243456_1672096717116 directfaces + +Syntax:      directfaces result shape + +Converts indirect surfaces and returns the results into the shape, which is given as the result parameter. +
Example
+ +directfaces r a + +@subsubsection occt_2142243456_1672096717117 expshape + +Syntax:   expshape shape maxdegree maxseg + +Gives statistics for a given shape. This test command is working with Bezier and BSpline entities. +
Example
+ +expshape a 10 10 +== Number of Rational Bspline curves 128 +== Number of Rational Bspline pcurves 48 + +@subsubsection occt_2142243456_1672096717118 fixsmall + +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. +
Example
+ +fixsmall r a 0.1 + +@subsubsection occt_2142243456_1672096717119 fixsmalledges + +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. +
Example
+ +fixsmalledges r a 0.1 1 + +@subsubsection occt_2142243456_16720967171110 fixshape + +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 +The following syntax is used: symbolparameter +- symbol may be - to set parameter off, + to set on or * to set default +- parameters are identified by letters: +l - FixLackingMode +o - FixOrientationMode +h - FixShiftedMode +m - FixMissingSeamMode +d - FixDegeneratedMode +s - FixSmallMode +i - FixSelfIntersectionMode +n - FixNotchedEdgesMode +For enhanced message output, use switch '+?' +
Example
+ +fixshape r a 0.001 + +@subsubsection occt_2142243456_16720967171111 fixwgaps + +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. +
Example
+ +fixwgaps r a + +@subsubsection occt_2142243456_16720967171112 offsetcurve, offset2dcurve + +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. +
Example
+ +point pp 10 10 10 +offsetcurve r c 20 pp + +@subsubsection occt_2142243456_16720967171113 projcurve + +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 + + +@subsubsection occt_2142243456_16720967171114 projface + +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. +
Example
+ +projface a_1 10.0 0.0 +==  Point UV  U = 10  V = 0 +==   =   proj  X = -116  Y = -45  Z = 0 + +@subsubsection occt_2142243456_16720967171115 scaleshape + +Syntax:   scaleshape result shape scale + +
Example
+ +scaleshape r a_1 0.8 + +@subsubsection occt_2142243456_16720967171116 settolerance + +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. +
Example
+ +settolerance a 0.001 + +@subsubsection occt_2142243456_16720967171117 splitface + +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. +
Example
+ +# split face f by parameter u = 5 +splitface r f u 5 +== Splitting by   U:   ,5 +== Status:  DONE1 + +@subsubsection occt_2142243456_16720967171118 statshape + +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. +
Example
+ +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 + +@subsubsection occt_2142243456_16720967171119 tolerance + +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. +
Example
+ +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 + +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 + + + +@subsection occt_2142243456_16720967172 Convertion commands +More detailed information about using here classes can be found into Shape Healing documentation. All this commands are created for testing. + +@subsubsection occt_2142243456_1672096717121 DT_ClosedSplit + +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. +
Example
+ +DT_ClosetSplit r a + +@subsubsection occt_2142243456_1672096717122 DT_ShapeConvert, DT_ShapeConvertRev + +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. +
Example
+ +DT_ShapeConvert r a 1 1 +== Status: DONE1 + +@subsubsection occt_2142243456_1672096717123 DT_ShapeDivide + +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 +Done1 : Some edges were split +Done2 : Surface was split +Fail1    : Some errors occurred +
Example
+ +DT_ShapeDivide r a 0.001 +== Status: OK + +@subsubsection occt_2142243456_1672096717124 DT_SplitAngle + +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. +
Example
+ +DT_SplitAngle r a +== Status: DONE2 + +@subsubsection occt_2142243456_1672096717125 DT_SplitCurve + +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. +
Example
+ +DT_SplitCurve r c + +@subsubsection occt_2142243456_1672096717126 DT_SplitCurve2d + +Syntax:      DT_SplitCurve2d Curve Tol Split(0/1) + +Works just as DT_SplitCurve (see above), only with 2d curve. +
Example
+ +DT_SplitCurve2d r c + +@subsubsection occt_2142243456_1672096717127 DT_SplitSurface + +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. +**Example** +    +# split surface with name ‘su’ +DT_SplitSurface res su 0.1 1 +== single surf +== appel a SplitSurface::Init +== appel a SplitSurface::Build +== appel a SplitSurface::GlobalU/VKnots +== nb GlobalU;nb GlobalV=7 2 0 1 2 3 4 5 6.2831853072 0 1 +== appel a Surfaces +== transfert resultat +== res1_1_1 res1_2_1 res1_3_1 res1_4_1 res1_5_1 res1_6_1 + + +@subsubsection occt_2142243456_1672096717128 DT_ToBspl + +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 + +@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] + +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. + +This command can be used for visualization performance evaluation instead of the outdated Visualization Performance Meter. +**Example** + +vdrawsphere s 200 1 1 1 500 1 == Compute Triangulation... == NumberOfPoints: 39602 == NumberOfTriangles: 79200 == Amount of memory required for PolyTriangulation without Normals: 2 Mb == Amount of memory for colors: 0 Mb == Amount of memory for PolyConnect: 1 Mb == Amount of graphic card memory required: 2 Mb == Number of scene redrawings: 1 == CPU user time: 15.6000999999998950 msec == CPU system time: 0.0000000000000000 msec == CPU average time of scene redrawing: 15.6000999999998950 msec + + + +@section occt_2142243456_713659999 Extending Test Harness with custom commands + + +The following chapters explain how to extend Test Harness with custom commands and how to activate them using a plug-in mechanism. + + +@subsection occt_2142243456_7136599991 Custom command implementation + +Custom command implementation has not undergone any changes since the introduction of the plug-in mechanism. The syntax of every command should still be like in the following example. +**Example** + +static Standard_Integer myadvcurve(Draw_Interpretor& di, +Standard_Integer n, +char** a) +{ +... +} + +For examples of existing commands refer to Open CASCADE Technology (e.g. GeomliteTest.cxx). + + +@subsection occt_2142243456_7136599992 Registration of commands in Test Harness + +To become available in the Test Harness the custom command must be registered in it. This should be done as follows. +**Example** + +void MyPack::CurveCommands(Draw_Interpretor& theCommands) +{ +... +char* g = ;Advanced curves creation;; + + +                  theCommands.Add ( ;myadvcurve;, ;myadvcurve name p1 p2 p3 – +                              Creates my advanced curve from points;, +__FILE__, myadvcurve, g); +... +} + +@subsection occt_2142243456_7136599993 Creating a toolkit (library) as a plug-in + +All custom commands are compiled and linked into a dynamic library (.dll on Windows, or .so on Unix/Linux). To make Test Harness recognize it as a plug-in it must respect certain conventions. Namely, it must export function PLUGINFACTORY() accepting the Test Harness interpreter object (Draw_Interpretor). This function will be called when the library is dynamically loaded during the Test Harness session. +This exported function PLUGINFACTORY() must be implemented only once per library. +For convenience the DPLUGIN macro (defined in the Draw_PluginMacro.hxx file) has been provided. It implements the PLUGINFACTORY() function as a call to the Package::Factory() method and accepts Package as an argument. Respectively, this Package::Factory() method must be implemented in the library and activate all implemented commands. +**Example** + +#include Draw_PluginMacro.hxx + +void MyPack::Factory(Draw_Interpretor& theDI) +{ +... +// +MyPack::CurveCommands(theDI); +... +} + +// Declare entry point PLUGINFACTORY +DPLUGIN(MyPack) + + +@subsection occt_2142243456_7136599994 Creation of the plug-in resource file + +As mentioned above, the plug-in resource file must be compliant with Open CASCADE Technology requirements (see Resource_Manager.cdl file for details). In particular, it should contain keys separated from their values by a colon (;:;). +For every created plug-in there must be a key. For better readability and comprehension it is recommended to have some meaningful name. +Thus, the resource file must contain a line mapping this name (key) to the library name. The latter should be without file extension (.dll on Windows, .so on Unix/Linux) and without the ;lib; prefix on Unix/Linux. +For several plug-ins one resource file can be created. In such case, keys denoting plug-ins can be combined into groups, these groups - into their groups and so on (thereby creating some hierarchy). Any new parent key must have its value as a sequence of child keys separated by spaces, tabs or commas. Keys should form a tree without cyclic dependencies. +**Examples** (file MyDrawPlugin): + +! Hierarchy of plug-ins +ALL                : ADVMODELING, MESHING +DEFAULT            : MESHING +ADVMODELING        : ADVSURF, ADVCURV + +! Mapping from naming to toolkits (libraries) +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. + + +@subsection occt_2142243456_7136599995 Dynamic loading and activation + +Loading a plug-in and activating its commands is described in the *;Activation of the commands implemented in the plug-in;* chapter. + +The procedure consists in defining the system variables and using the pload commands in the Test Harness session. + +**Example** + +Draw[] set env(CSF_MyDrawPluginDefaults) /users/test + + diff --git a/dox/user_guides/draw_test_harness/images/draw_test_harness_image001.jpg b/dox/user_guides/draw_test_harness/images/draw_test_harness_image001.jpg new file mode 100644 index 0000000000..0e782cab77 Binary files /dev/null and b/dox/user_guides/draw_test_harness/images/draw_test_harness_image001.jpg differ diff --git a/dox/user_guides/draw_test_harness/images/draw_test_harness_image002.jpg b/dox/user_guides/draw_test_harness/images/draw_test_harness_image002.jpg new file mode 100644 index 0000000000..5f87a335b2 Binary files /dev/null and b/dox/user_guides/draw_test_harness/images/draw_test_harness_image002.jpg differ diff --git a/dox/user_guides/foundation_classes/foundation_classes.md b/dox/user_guides/foundation_classes/foundation_classes.md new file mode 100644 index 0000000000..c024890f36 --- /dev/null +++ b/dox/user_guides/foundation_classes/foundation_classes.md @@ -0,0 +1,1877 @@ +Foundation Classes {#user_guides__foundation_classes} +================================= + +@section occt_fcug_1 Introduction + +@subsection occt_fcug_1_1 Foundation Classes Overview + +This manual explains how to use Open CASCADE Technology (**OCCT**) Foundation Classes. It provides basic documentation on foundation classes. For advanced information on foundation classes and their applications, see our offerings on our web site at www.opencascade.org/support/training/ +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 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), + * configurable optimized memory manager increasing the performance of applications that intensively use dynamically created objects, + * extended run-time type information (RTTI) mechanism facilitating the creation of complex programs, + * management of exceptions, + * encapsulation of C++ streams. +Root classes are mainly implemented in the **Standard** and **MMgt** packages. + +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 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 +------------------------------ +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 +--------------------- + +These classes provide commonly used mathematical algorithms and basic calculations (addition, multiplication, transposition, inversion, etc.) involving vectors and matrices. + +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: + * 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. + +Common Math Algorithms +---------------------- + +Open CASCADE Technology common math algorithms provide 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, + * Algorithms to find the eigen-values and eigen-vectors of a square matrix. + +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 +---------- +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 +-------------------- +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 + * 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: + * Enumerations + * Object classes + * Exceptions + * Pointers to other object classes +Inside a package, two data types *cannot *bear the same name. + +![](/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. +* **Instance method** Operates on the instance which owns it. +* **Class method** Does not work on individual instances, only on the class itself. + +@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 +------------------------ +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 +--------------------------- +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 +-------------------------------- +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); +@endcode + +This declaration located in a CDL file of the *TColStd* package defines a new C++ class *TColStd_Array1OfReal* as the instantiation of generic class *TCollection_Array1* for *Real* values. +More than one class can be instantiated from the same generic class with the same argument types. Such classes will be identical by implementation, but considered as two different classes by C++. +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 +---------------------- +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 +class MapOfReal instantiates Map from TCollection (Real,MapRealHasher); +@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 +The data types in Open CASCADE Technology fall into two categories: + * Data types manipulated by handle (or reference) + * Data types manipulated by value + +![](/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++: + +~~~~~ +Handle(myClass) m = new myClass; +~~~~~ + +In Open CASCADE Technology, the Handles are specific classes that are used to safely manipulate objects allocated in the dynamic memory by reference, providing reference counting mechanism and automatic destruction of the object when it is not referenced. + +@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. +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 +This chapter deals with basic services such as memory management, programming with handles, primitive types, exception handling, genericity by downcasting and plug-in creation. +@subsection occt_fcug_2_1 Data Types +@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. +* **ExtCharacter** is an extended character. +* **Integer** is a whole number. +* **Real** denotes a real number (i.e. one with whole and a fractional part, either of which may be null). +* **ShortReal** is a 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. +The services offered by each of these types are described in the **Standard** Package. +The table below presents the equivalence existing between C++ fundamental types and OCCT primitive types. + +**Table 1: Equivalence between C++ Types and OCCT Primitive Types** +|C++ Types | OCCT Types | +|----------:|------------:| +|int | Standard_Integer | +| double | Standard_Real | +|float | Standard_ShortReal | +|unsigned int | Standard_Boolean | +|char | Standard_Character | +| short | Standard_ExtCharacter | +| char* | Standard_CString | +| void* | Standard_Address | +|short* | Standard_ExtString | + +* pointer + + +**Reminder of the classes listed above:** + +* Standard_Integer: fundamental type representing 32-bit integers yielding negative, positive or null values. **Integer** is implemented as a **typedef** of the C++ **int** fundamental type. As such, the algebraic operations +, -, *, / as well as the ordering and equivalence relations <, <=, ==, !=, >=, > are defined on it. +* Standard_Real: fundamental type representing real numbers with finite precision and finite size. **Real** is implemented as a **typedef** of the C++ **double** (double precision) fundamental type. As such, the algebraic operations +, -, *, /, unary- and the ordering and equivalence relations <, <=, ==, !=, >=, > are defined on reals. +* Standard_ShortReal: fundamental type representing real numbers with finite precision and finite size. **ShortReal** is implemented as a **typedef** of the C++ **float** (simple precision) fundamental type. As such, the algebraic operations +, -, *, /, unary- and the ordering and equivalence relations <, <=, ==, !=, >=, > are defined on reals. +* Standard_Boolean: **Boolean** is a fundamental type representing logical expressions. It has two values, false and true. **Boolean** is implemented as a **typedef** of the C++ **unsigned int** fundamental type. As such, the algebraic operations and, or, xor, not as well as equivalence relations ==, != are defined on Booleans. +* 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. + +@subsubsection occt_fcug_2_1_2 Types manipulated by value +There are three categories of types which are manipulated by value: + * Primitive types + * Enumerated types + * 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. + +![](/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. + +![](/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 + +The following table summarizes how various data types are handled and stored. + +| | Manipulated by handle | Manipulated by value | +|--------:|----------------------:|---------------------:| +| storable | Persistent | Primitive, Storable (if nested in a persistent class)| +|temporary | Transient | Other | + + +@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: +~~~~~ +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 + +General +------- + +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 +~~~~~ + + +The compiler sees p1 as a handle to *Point* though the actual object referenced by *p1* is of the *CartesianPoint* type. + +Explicit Type Conversion +------------------------ + +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. + +~~~~~~ +Handle (Geom_Point) p1; +Handle (Geom_CartesianPoint) p2, p3; +p2 = new Geom_CartesianPoint; +p1 = p2; // OK, standard assignment +p3 = Handle (Geom_CartesianPoint)::DownCast (p1); +// OK, the actual type of p1 is CartesianPoint, although the static type of the handle is Point +~~~~~~ + +If conversion is not compatible with the actual type of the referenced object, the handle which was “cast” becomes null (and no exception is raised). So, if you require reliable services defined in a sub-class of the type seen by the handle (static type), write as follows: + +~~~~~~ +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 +  } +} +~~~~~~ +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: + +~~~~~ +Handle (A) a; +Handle (B) b; +Handle (Standard_Transient) t; +SequenceOfTransient s; +a = new A; +s.Append (a); +b = new B; +s.Append (b); +t = s.Value (1); +// here, you cannot write: +// a = t; // ERROR ! +// so you downcast: +a = Handle (A)::Downcast (t) +if (! a.IsNull()) { +        // types are compatible, you can use a +} +else { +       // the types are incompatible +} +~~~~~ + +@subsubsection occt_fcug_2_2_3 Using Handles to Create Objects +To create an object which is manipulated by handle, declare the handle and initialize it with the standard C++ **new** operator, immediately followed by a call to the constructor. The constructor can be any of those specified in the source of the class from which the object is instanced. + +~~~~~ +Handle (Geom_CartesianPoint) p; +p = new Geom_CartesianPoint (0, 0, 0); +~~~~~ + +Unlike for a pointer, the **delete** operator does not work on a handle; the referenced object is automatically destroyed when no longer in use. + +@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->Coord(x, y, z); +~~~~~ + +The example below illustrates how to access the type object of a Cartesian point: + +~~~~~ +Handle(Standard_Transient) p = new Geom_CartesianPoint(0.,0.,0.); +if ( p->DynamicType() == STANDARD_TYPE(Geom_CartesianPoint) ) +  cout << ;Type check OK; << endl; +else +  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. + +Invoking Class Methods +---------------------- +A class method is called like a static C++ function, i.e. it is called by the name of the class of which it is a member, followed by the “::” operator and the name of the method. + +For example, we can find the maximum degree of a Bezier curve: + +~~~~~ +Standard_Integer n; +n = Geom_BezierCurve::MaxDegree(); +~~~~~ + +@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. +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 +} +// 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 + +@subsubsection occt_fcug_2_2_6 Creating Transient Classes without CDL + +Though generation of Handle class and related C++ code is normally performed by CDL extractor, it is also possible to define a class managed by handle without CDL. To facilitate that, several macros are provided in the file Standard_DefineHandle.hxx: + +* **DEFINE_STANDARD_HANDLE(class_name,ancestor_name)** - declares Handle class for a class *class_name* that inherits class *ancestor_name* (for instance, *Standard_Transient*). This macro should be put in a header file; the declaration of the handle to a base class must be available (usually put before or after the declaration of the class *class_name*, or into a separate header file). +* **IMPLEMENT_STANDARD_HANDLE(class_name,ancestor_name)** - implements method *DownCast()* of the *Handle* class. Should be located in a C++ file (normally the file where methods of the class *class_name* are implemented). +* **DEFINE_STANDARD_RTTI(class_name)** - declares methods required for RTTI in the class *class_name* declaration; should be in public: section. +* **IMPLEMENT_STANDARD_RTTIEXT(class_name,ancestor_name)** - implements above methods. Usually put into the C++ file implementing class class_name. +Note that it is important to ensure correctness of macro arguments, especially the ancestor name, otherwise the definition may be inconsistent (no compiler warnings will be issued in case of mistake). + +In *Appli_ExtSurface.hxx* file: +~~~~~ +#include +class Appli_ExtSurface : public Geom_Surface +{ +. . . +public: +  DEFINE_STANDARD_RTTI(Appli_ExtSurface) +} +DEFINE_STANDARD_HANDLE(Appli_ExtSurface,Geom_Surface) +~~~~~ + +In *Appli_ExtSurface.cxx* file: +~~~~~ +#include +IMPLEMENT_STANDARD_HANDLE(Appli_ExtSurface,Geom_Surface) +IMPLEMENT_STANDARD_RTTIEXT(Appli_ExtSurface,Geom_Surface) +~~~~~ + + +@subsection occt_fcug_2_3 Memory Management in Open CASCADE Technology +In the course of a work session, geometric modeling applications create and delete a considerable number of C++ objects allocated in the dynamic memory (heap). In this context, performance of standard functions for allocating and de-allocating memory may be not sufficient. For this reason, Open CASCADE Technology employs a specialized memory manager implemented in the Standard package. + +@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. + +@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. +The configuration is defined by numeric values of the following environment variables: + * *MMGT_OPT*: if set to 0 (default) every memory block is allocated in C memory heap directly (via *malloc()* and *free()* functions). In this case, all other options except for *MMGT_CLEAR* are ignored; if set to 1 the memory manager performs optimizations as described below; if set to 2, Intel ® TBB optimized memory manager is used. + * *MMGT_CLEAR*: if set to 1 (default), every allocated memory block is cleared by zeros; if set to 0, memory block is returned as it is. + * *MMGT_CELLSIZE*: defines the maximal size of blocks allocated in large pools of memory. Default is 200. + * *MMGT_NBPAGES*: defines the size of memory chunks allocated for small blocks in pages (operating-system dependent). Default is 1000. + * *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*. +@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 +---------------------- +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: + * 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. +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. + +@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. +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. +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 +----------------- +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: +~~~~~ +try { +  OCC_CATCH_SIGNALS +  // try block +} +catch(DomainError) { +// handle DomainError exceptions here +} +~~~~~ + +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: + +~~~~~ +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]; +} +~~~~~ + +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. +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: +~~~~~ +_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.  +The entire call may be removed by defining one of the pre-processor symbols No_Exception or No_ at compile-time: + +~~~~~ +#define No_Exception /* remove all raises */ +~~~~~ + +Using this syntax, the Value function becomes: + +~~~~~ +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]; +} +~~~~~ + +@subsubsection occt_fcug_2_4_2 Handling an Exception +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. + +~~~~~ +void f(1) + { +  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. +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 +  } +  . . . +} +~~~~~ + +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 +#include +#include +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; +} +~~~~~ + +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. + +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. + +@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: +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. +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; + + 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. +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; + * 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. + +@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: +~~~~~ +! METADATADRIVER whose value must be OS or DM. + +! FW +a148e300-5740-11d1-a904-080036aaa103.Location: + +libFWOSPlugin.so +a148e300-5740-11d1-a904-080036aaa103.CCL: +/adv_44/CAS/BAG/FW-K4C/inc/FWOS.ccl + +! FWDM +a148e301-5740-11d1-a904-080036aaa103.Location: +libFWDMPlugin.so +a148e301-5740-11d1-a904-080036aaa103.CCL: +/adv_44/CAS/BAG/DESIGNMANAGER-K4C/inc/DMAccess.ccl|/ +adv_44/CAS/BAG/DATABASE-K4C/inc/FWDMCommands.ccl +a148e301-5740-11d1-a904-080036aaa103.Message: /adv_44/CAS/ +BAG/DESIGNMANAGER-K4C/etc/locale/DMAccess + +! Copy-Paste +5ff7dc00-8840-11d1-b5c2-00a0c9064368.Location: +libCDMShapeDriversPlugin.so +5ff7dc01-8840-11d1-b5c2-00a0c9064368.Location: +libCDMShapeDriversPlugin.so +5ff7dc02-8840-11d1-b5c2-00a0c9064368.Location: +libCDMShapeDriversPlugin.so +5ff7dc03-8840-11d1-b5c2-00a0c9064368.Location: +libCDMShapeDriversPlugin.so +5ff7dc04-8840-11d1-b5c2-00a0c9064368.Location: +libCDMShapeDriversPlugin.so + +! Plugs 2d plotters: +d0d722a2-b4c9-11d1-b561-0000f87a4710.location: FWOSPlugin +d0d722a2-b4c9-11d1-b561-0000f87a4710.CCL: /adv_44/CAS/BAG/ +VIEWERS-K4C/inc/CCLPlotters.ccl +d0d722a2-b4c9-11d1-b561-0000f87a4710.Message: /adv_44/CAS/ +BAG/VIEWERS-K4C/etc/locale/CCLPlotters + +!SHAPES +e3708f72-b1a8-11d0-91c2-080036424703.Location: +libBRepExchangerPlugin.so +e3708f72-b1a8-11d0-91c2-080036424703.CCL: /adv_44/CAS/BAG/ +FW-K4C/inc/BRep.ccl +~~~~~ + + +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: + +~~~~~ +Handle(FADriver_PartStorer)::DownCast +(PlugIn::ServiceFactory +(PlugIn_ServiceId(yourStandardGUID))) +~~~~~ + +Let us take **FAFactory.cxx** as an example: + +~~~~~ +#include + +#include +#include +#include +#include +#include +#include +#include + +PLUGIN(FAFactory) + +static Standard_GUID +       StorageDriver(“45b3c690-22f3-11d2-b09e-0000f8791463”); +static Standard_GUID +       RetrievalDriver(“45b3c69c-22f3-11d2-b09e-0000f8791463”); +static Standard_GUID +       Schema(“45b3c6a2-22f3-11d2-b09e-0000f8791463”); + +//====================================================== +// function : Factory +// purpose : +//====================================================== + +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; +} +~~~~~ + +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: + +~~~~~ +#include +#include +class Standard_Transient; +class Standard_GUID; +class FAFactory { +public: +  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 +@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: + * 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 **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. + +@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: + * **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_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. + +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. + +TCollection_List +---------------- +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. +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_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. + +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. + +@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. + +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 +----------- +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. +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. +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. +*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: + * 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. + +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 +--------------- + +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 +--------------------- +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. + +@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_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. + +TCollection_DoubleMapIterator +----------------------------- +Functions used for iterating the contents of a **DoubleMap **map. + +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. + +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. + +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_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. + +@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. + +@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). + +@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. + +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. + +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*). + +Definition of a new collection class +------------------------------------ + +Let the header file be *MyPackage_SequenceOfPnt.hxx* : + +Template class instantiaton +~~~~~ +#include +#include +typedef NCollection_Sequence MyPackage_SequenceOfPnt; +~~~~~ + +Macro instantiation +~~~~~ +#include +#include +~~~~~ + +The following line defines the class "base collection of points" +~~~~~ +DEFINE_BASECOLLECTION(MyPackage_BaseCollPnt, gp_Pnt) +~~~~~ + +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 +------------------------------------------------------ + +It is necessary to provide relevant statements both in the header ( .hxx file) and the C++ source ( .cxx file). + +Header file MyPackage_HSequenceOfPnt.hxx: + +~~~~~ +#include +#include +~~~~~ + +The following line defines the class "base collection of points" + +~~~~~ +DEFINE_BASECOLLECTION(MyPackage_BaseCollPnt, gp_Pnt) +~~~~~ + +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) + +~~~~~ +DEFINE_HSEQUENCE (MyPackage_HSequenceOfPnt, MyPackage_SequenceOfPnt) +~~~~~ + +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. + +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. + +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; + +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 + +Type 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. +* Can grow without limits, like List, Stack or Queue types. +* Once having the size LEN, it cannot be reduced to any size less than LEN – there is no operation of removal of items. + +Insertion in a Vector-type class is made by two methods: +* _SetValue(ind, theValue)_ – array-type insertion, where ind is the index of the inserted item, can be any non-negative number. If it is greater than or equal to Length(), then the vector is enlarged (its Length() grows). +* _Append(theValue)_ – list-type insertion equivalent to _myVec.SetValue(myVec.Length(), theValue)_ – incrementing the size of the collection. + +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 (). + +Type 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. + +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 + { + public: + inline void Add (const MyBndType& other); + // Updates me with other bounding type instance + + inline Standard_Boolean IsOut (const MyBndType& other) const; + // Classifies other bounding type instance relatively me + + 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. + +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. + +~~~~~ +typedef NCollection_UBTree UBTree; +typedef NCollection_List ListOfSelected; +//! Tree Selector type +class MyTreeSelector : public UBTree::Selector +{ +public: + // This constructor initializes the selection criterion (e.g., a point) + + MyTreeSelector (const gp_XY& thePnt) : myPnt(thePnt) {} + // Get the list of selected objects + + const ListOfSelected& ListAccepted () const + { return myList; } + // Bounding box rejection - definition of virtual method. @return True if theBox is outside the selection criterion. + + Standard_Boolean Reject (const Bnd_B2f& theBox) const + { return theBox.IsOut(myPnt); } + // Redefined from the base class. Called when the bounding of theData conforms to the selection criterion. This method updates myList. + + Standard_Boolean Accept (const MyData& theData) + { myList.Append(theData); } + private: + gp_XY myPnt; + ListOfSelected myList; +}; +. . . +// Create a UBTree instance and fill it with data, each data item having the corresponding 2D box. + +UBTree aTree; +NCollection_UBTreeFiller aTreeFiller(aTree); +for(;;) { + const MyData& aData = …; + const Bnd_B2d& aBox = aData.GetBox(); + aTreeFiller.Add(aData, aBox); +} +aTreeFiller.Fill(); +. . . +// Perform selection based on ‘aPoint2d’ +MyTreeSelector aSel(aPoint2d); +aTree.Select(aSel); +const ListOfSelected = aSel.ListAccepted(); +~~~~~ + + +Type 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 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 +--------------- + +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. + +@subsubsection occt_fcug_3_3_5 Features + +NCollection defines some specific features, in addition to the public API inherited from TCollection classes. + +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; +* _Standard_Boolean More () const_ - makes a query if there is another non-iterated member; +* _void Next ()_ - increments the iterator; +* _const ItemType& Value () const_ - returns the current member; +* _ItemType& ChangeValue () const_ - returns the mutable current member + +~~~~~ +typedef Ncollection_Sequence +MyPackage_SequenceOfPnt +void Perform (const MyPackage_SequenceOfPnt& theSequence) +{ + MyPackage_SequenceOfPnt::Iterator anIter (theSequence); + for (; anIter.More(); anIter.Next()) { + const gp_Pnt aPnt& = anIter.Value(); +.... + } +} +This feature is present only for some classes in TCollection (Stack, List, Set, Map, DataMap, DoubleMap). In NCollection it is generalized. + + +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. + +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; + +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: + +~~~~~ +#include +typedef NCollection_Map MyPackage_MapOfPnt; +typedef NCollection_BaseCollection MyPackage_BaseCollPnt; +MyPackage_MapOfPnt aMapPnt; +.... +gp_Pnt aResult = COG (aMapPnt); +.... +gp_Pnt COG(const MyPackage_BaseCollPnt& theColl) +{ + gp_XYZ aCentreOfGravity(0., 0., 0.); +// create type-independent iterator (it is abstract type instance) + MyPackage_BaseCollString::Iterator& anIter = theColl.CreateIterator(); + for (; anIter.More(); anIter.Next()) { + aCentreOfGravity += anIter.Value().XYZ(); + } + return aCentreOfGravity / theColl.Size(); +} +~~~~~ + +Note that there are fundamental differences between the shown type-independent iterator and the iterator belonging to a particular non-abstract collection: +* Type-independent iterator can only be obtained via the call CreateIterator(); the typed iterator - only via the explicit construction. +* Type-independent iterator is an abstract class, so it is impossible to copy it or to assign it to another collection object; the typed iterators can be copied and reassigned using the method Init() . +* Type-independent iterator is actually destroyed when its collection object is destroyed; the typed iterator is destroyed as any other C++ object in the corresponding C++ scope. + +The common point between them is that it is possible to create any number of both types of iterators on the same collection object. + +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. + +For example, conversion of Map into Array1 is performed like this: + +~~~~~ +#include +#include +typedef NCollection_Map MyPackage_MapOfPnt; +typedef NCollection_Array1 MyPackage_Array1OfPnt; +.... +MyPackage_MapOfPnt aMapPnt; +.... +MyPackage_Array1OfPnt anArr1Pnt (1, aMapPnt.Size()); +anArr1Pnt.Assign (aMapPnt); // heterogeneous assignment +~~~~~ + +There are some aspects to mention: +* Unlike in TCollection, in NCollection the methods Assign and operator= do not coincide. The former is a virtual method defined in the BaseCollection class. The latter is always defined in instance classes as a non-virtual inline method and it corresponds exactly to the method Assign in TCollection classes. Therefore it is always profitable to use operator= instead of Assign wherever the types on both sides of assignment are known. +* If the method Assign copies to Array1or Array2 structure, it first checks if the size of the array is equal to the number of items in the copied collection object. If the sizes differ, an exception is thrown, as in TCollection_Array1.gxx. +* Copying to Map, IndexedMap, DataMap and IndexedDataMap can bring about a loss of data: when two or more copied data items have the same key value, only one item is copied and the others are discarded. It can lead to an error in the code like the following: + +~~~~~ +MyPackage_Array1OfPnt anArr1Pnt (1, 100); +MyPackage_MapOfPnt aMapPnt; +.... +aMapPnt.Assign(anArr1Pnt); +anArr1Pnt.Assign(aMapPnt); +~~~~~ + +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 +--------- + +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: + +~~~~~ +Standard_EXPORT virtual void* Allocate (const size_t size); +Standard_EXPORT virtual void Free (void * anAddress); +~~~~~ + +It is used internally every time when the collection allocates memory for its item(s) and releases this memory. The default value of this parameter (empty Handle) designates the use of NCollection_BaseAllocator X where the functions Standard::Allocate and Standard::Free are called. Therefore if the user of NCollection does not specify any allocator as a parameter to the constructor of his collection, the memory management will be identical to the one in TCollection and other Open CASCADE Technology classes. + +Nevertheless, the it is possible to define a custom Allocator type to manage the memory in the most optimal or convenient way for his algorithms. + +As one possible choice, the class NCollection_IncAllocator is included. Unlike BaseAllocator, it owns all memory it allocates from the system. Memory is allocated in big blocks (about 20kB) and the allocator keeps track of the amount of occupied memory. The method Allocate just increments the pointer to non-occupied memory and returns its previous value. Memory is only released in the destructor of IncAllocator, the method Free is empty. If used efficiently, this Allocator can greatly improve the performance of OCCT collections. + + + +@subsection occt_fcug_3_4 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. + +@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. + +@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 +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 **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. +A physical quantity is defined by a string (example: LENGTH). + + +@section occt_occt_fcug_4 Math Primitives and Algorithms +@subsection occt_occt_fcug_4_1 Overview +Math primitives and algorithms available in Open CASCADE Technology include: + * 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. + +~~~~~ +math_Vector v(1, 3); +// a vector of dimension 3 with range (1..3) +math_Matrix m(0, 2, 0, 2); +// a matrix of dimension 3x3 with range (0..2, 0..2) +math_Vector v(N1, N2); +// a vector of dimension N2-N1+1 with range (N1..N2) +~~~~~ + +Vector and Matrix objects use value semantics. In other words, they cannot be shared and are copied through assignment. + +~~~~~ +math_Vector v1(1, 3), v2(0, 2); +v2 = v1; +// v1 is copied into v2. a modification of v1 does not affect v2 +~~~~~ + +Vector and Matrix values may be initialized and obtained using indexes which must lie within the range definition of the vector or the matrix. + +~~~~~ +math_Vector v(1, 3); +math_Matrix m(1, 3, 1, 3); +Standard_Real value; + +v(2) = 1.0; +value = v(1); +m(1, 3) = 1.0; +value = m(2, 2); +~~~~~ + +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. + +~~~~~~ +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 +~~~~~~ + +@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 available geometric entities are: + * 2d & 3d Cartesian coordinates (x, y, z) + * Matrices + * Cartesian points + * Vector + * Direction + * Axis + * Line + * Circle + * Ellipse + * Hyperbola + * Parabola + * Plane + * Infinite cylindrical surface + * Spherical surface + * Toroidal surface + * 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.* +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. +@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 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: + +~~~~~~ +class Gauss { +public: +  Gauss (const math_Matrix& A); +  Standard_Boolean IsDone() const; +  void Solve (const math_Vector& B, +  math_Vector& X) const; +}; +~~~~~~ + +Now the main program uses the Gauss class to solve the equations a*x1=b1 and a*x2=b2: + +~~~~~ +#include +#include +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 +  } +} +~~~~~ + +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 { + public: + BissecNewton (math_FunctionWithDerivative& f, + const Standard_Real bound1, + const Standard_Real bound2, + const Standard_Real tolx); + Standard_Boolean IsDone() const; + Standard_Real Root(); +}; +~~~~~ + +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 { + public: + virtual Standard_Boolean Value + (const Standard_Real x, Standard_Real& f) = 0; + virtual Standard_Boolean Derivative + (const Standard_Real x, Standard_Real& d) = 0; + virtual Standard_Boolean Values + (const Standard_Real x, + Standard_Real& f, + Standard_Real& d) = 0; +}; +~~~~~ + +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 +#include +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; +    } +}; + +main() +{ +  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 +  } +~~~~~ + +@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. +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. +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*. +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. +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: + +~~~~~ +Abs(t1-t2) < ParametricPrecision +Distance (P(t1),P(t2)) < RealPrecision. +~~~~~ + +@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. +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. + +@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 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. + +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: +_Abs(Angle1 - Angle2) < Precision::Angular()_ + +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: +_Abs(D1 * D2) < Precision::Angular()_ + +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: +_P1.IsEqual(P2,Precision::Confusion())_ + +It is also possible to find a vector of null length (_Vec_ from _gp_) : +_V.Magnitude() < Precision::Confusion()_ + +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 +------------------------ +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 + +![](/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. +Note that when an object is stored, if it contains another stored object, the references to the contained object are also managed. +![](/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 + +The storage procedure of a transient object follows five main steps. +1. Create an I/O driver for files. For example, *FSD_File f()*; +2. Instance the data schema, which will process your persistent information. The schema is used for read/write operations. If ShapeSchema is the name of your schema: +~~~~~ +Handle(ShapeSchema) s = new ShapeSchema; +~~~~~ + +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. +~~~~~ +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); +~~~~~ + +@subsubsection occt_fcug_5_2_2 Opening +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. +~~~~~ +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). +~~~~~ +Handle(Standard_Persistent) p; +Handle(Standard_Root) r; +if(roots -> Length() >= 1) { +  r = roots -> Value(1); +  p = r -> Object(); +} +~~~~~ +4. DownCast the persistent object to a PTopoDS_Hshape. +~~~~~ +Handle(PTopoDS_HShape) aPShape; +aPShape = Handle(PTopoDS_HShape)::DownCast(p); +~~~~~ +5. Create the TopoDS_Shape. +~~~~~ +TopoDS_Shape aShape; +PTColStd_PersistentTransientMap aMap;   +MgtBRep::Translate (aPShape, aMap, aShape, MgtBRep_WithoutTriangle); +~~~~~ + + + diff --git a/dox/user_guides/foundation_classes/images/foundation_classes_image001.jpg b/dox/user_guides/foundation_classes/images/foundation_classes_image001.jpg new file mode 100644 index 0000000000..0e782cab77 Binary files /dev/null and b/dox/user_guides/foundation_classes/images/foundation_classes_image001.jpg differ diff --git a/dox/user_guides/foundation_classes/images/foundation_classes_image002.jpg b/dox/user_guides/foundation_classes/images/foundation_classes_image002.jpg new file mode 100644 index 0000000000..5f87a335b2 Binary files /dev/null and b/dox/user_guides/foundation_classes/images/foundation_classes_image002.jpg differ diff --git a/dox/user_guides/foundation_classes/images/foundation_classes_image003.jpg b/dox/user_guides/foundation_classes/images/foundation_classes_image003.jpg new file mode 100644 index 0000000000..308605c219 Binary files /dev/null and b/dox/user_guides/foundation_classes/images/foundation_classes_image003.jpg differ diff --git a/dox/user_guides/foundation_classes/images/foundation_classes_image004.jpg b/dox/user_guides/foundation_classes/images/foundation_classes_image004.jpg new file mode 100644 index 0000000000..719dfddc06 Binary files /dev/null and b/dox/user_guides/foundation_classes/images/foundation_classes_image004.jpg differ diff --git a/dox/user_guides/foundation_classes/images/foundation_classes_image005.jpg b/dox/user_guides/foundation_classes/images/foundation_classes_image005.jpg new file mode 100644 index 0000000000..d3b604ea80 Binary files /dev/null and b/dox/user_guides/foundation_classes/images/foundation_classes_image005.jpg differ diff --git a/dox/user_guides/foundation_classes/images/foundation_classes_image006.jpg b/dox/user_guides/foundation_classes/images/foundation_classes_image006.jpg new file mode 100644 index 0000000000..f4ee0ad94d Binary files /dev/null and b/dox/user_guides/foundation_classes/images/foundation_classes_image006.jpg differ diff --git a/dox/user_guides/foundation_classes/images/foundation_classes_image007.jpg b/dox/user_guides/foundation_classes/images/foundation_classes_image007.jpg new file mode 100644 index 0000000000..f11559a224 Binary files /dev/null and b/dox/user_guides/foundation_classes/images/foundation_classes_image007.jpg differ diff --git a/dox/user_guides/foundation_classes/images/foundation_classes_image008.jpg b/dox/user_guides/foundation_classes/images/foundation_classes_image008.jpg new file mode 100644 index 0000000000..823d6461d4 Binary files /dev/null and b/dox/user_guides/foundation_classes/images/foundation_classes_image008.jpg differ diff --git a/dox/user_guides/iges/iges.md b/dox/user_guides/iges/iges.md new file mode 100644 index 0000000000..41de701ef9 --- /dev/null +++ b/dox/user_guides/iges/iges.md @@ -0,0 +1,1560 @@ +IGES Support {#user_guides__iges} +================== + +@section occt_1856844696_591811643 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 www.opencascade.org/support/training/ + +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 +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 +The types of IGES entities, which can be translated, are: + * Points + * Lines + * Curves + * Surfaces + * B-Rep entities + * 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 +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 +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 +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 +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 +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. +

read.iges.bspline.continuity

+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. +Read this parameter with: +Standard_Integer ic = Interface_Static::IVal(;read.iges.bspline.continuity;); +Modify this value with: +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). * +

read.precision.mode

+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. +Read this parameter with: +Standard_Integer ic = Interface_Static::IVal(;read.precision.mode;); +Modify this value with: +if (!Interface_Static::SetIVal (;read.precision.mode;,1)) +.. error ..; +Default value is ;File; (0). +

read.precision.val

+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. +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;); +Modify this parameter with: +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. +

read.maxprecision.mode

+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. +Read this parameter with: +Standard_Integer mv = Interface_Static::IVal(;read.maxprecision.mode;); +Modify this parameter with: +if (!Interface_Static::SetIVal (;read.maxprecision.mode;,1)) +.. error ..; +Default value is ;Preferred; (0). + +

read.maxprecision.val

+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;); +Modify this parameter with: +if (!Interface_Static::SetRVal (;read.maxprecision.val;,0.1)) +.. error ..; +Default value is 1. + +

read.stdsameparameter.mode

+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. +Read this parameter with: +Standard_Integer mv = Interface_Static::IVal(;read.stdsameparameter.mode;); +Modify this parameter with: +if (!Interface_Static::SetIVal (;read.stdsameparameter.mode;,1)) +.. error ..; +Deafault value is 0 (;Off;). + +

read.surfacecurve.mode

+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. +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: + * 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. +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;); +Modify this value with: +if (!Interface_Static::SetIVal (;read.surfacecurve.mode;,3)) +.. error ..; +Default value is ;Default; (0). +

read.encoderegularity.angle

+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;); +Modify this parameter with: +if (!Interface_Static::SetRVal (;read.encoderegularity.angle;,0.1)) +.. error ..; +Default value is 0.01. +

read.iges.bspline.approxd1.mode

+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;); +Modify this parameter with: +if (!Interface_Static::SetRVal (;read.encoderegularity.angle;,;On;)) +.. error ..; +Default value is Off. +

read.iges.resource.name

+

read.iges.sequence

+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. +

read.scale.unit

+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.  +

xstep.cascade.unit

+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. +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); +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)”); + +

List of predefined operators that can be used:

+ * 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 +Perform translation according to what you want to translate: +1.       Translate an entity identified by its rank with: +Standard_Boolean ok = reader.Transfer (rank); +-# 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: +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: +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: +Standard_Boolean onlyvisible = Standard_True or Standard_False; +reader.TransferRoots(onlyvisible) +@subsubsection occt_1856844696_804874798_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. +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. +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.). + +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 +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 + +@subsubsection occt_1856844696_804874798_47 Transformation Matrix +@subsection occt_1856844696_804874798_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 +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. +

3D (spatial) tolerances

+
Package method Precision::Confusion
+The value is 10-7. It is used as a minimal distance between points, which are considered distinct. +
Resolution in the IGES file
+This parameter 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
+It is to be used instead of resolution from the file when parameter read.precision.mode is 1 (“User”). +
Field EpsGeom of the class IGESToBRep_CurveAndSurface
+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. +
Field MaxTol of the class IGESToBRep_CurveAndSurface
+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*.* +

2D (parametric) tolerances

+
Package method Precision::PConfusion
+This is value 0.01*Precision::Confusion = 10-9. It is used to compare parametric bounds of curves. +
Field EpsCoeff of the class IGESToBRep_CurveAndSurface
+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). +
Methods UResolution(tolerance3d), 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. +

Zero-dimensional tolerances

+
Field Epsilon of the class IGESToBRep_CurveAndSurface
+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 +

Translating into Geometry

+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 +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: +
Class 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-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). +
Class IGESToBRep_BasicSurface
+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). +

Translating into Topology

+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. +Although the IGES file contains only one parameter for tolerance in the Global Section, OCCT shapes are produced with different tolerances. As a rule, updating the tolerance is fulfilled according to local distances between shapes (distance between vertices of adjacent edges, deviation of edge’s 3D curve and its parametric curve and so on) and may be less or greater than precision in the file. +The following classes show what default tolerances are used when creating shapes and how they are updated during transfer. +
Class IGESToBRep_TopoCurve
+All the methods which are in charge of transferring curves from IGES curve entities (TransferCompositeCurve, Transfer2dCompositeCurve, TransferCurveOnFace, TransferBoundaryOnFace, TransferOffsetCurve, TransferTopoBasicCurve) if an entity has transformation call to IGESData_ToolLocation::ConvertLocation with Epsilon value set to 10-4. + * IGESToBRep_TopoCurve::TransferPoint +Vertex is constructed from a Point entity with tolerance EpsGeom*UnitFactor. + * IGESToBRep_TopoCurve::Transfer2dPoint +Vertex is constructed from a Point entity with tolerance EpsCoeff. + * IGESToBRep_TopoCurve::TransferCompositeCurveGeneral +Obtains shapes (edges or wires) from other methods and adds them into the resulting wire. Two adjacent edges of the wire can be connected with tolerance up to MaxTol. + * IGESToBRep_TopoCurve::TransferCurveOnFace and IGESToBRep_TopoCurve::TransferBoundaryOnFace +This method builds a wire from 3D and 2D representations of a curve on surface. +Edges and vertices of the wire cannot have tolerance larger than MaxTol. +The value EpsGeom*UnitFactor is passed into ShapeFix_Wire::SetPrecision and MaxTol - into ShapeFix_Wire::MaxTolerance. To find out how these parameters affect the resulting tolerance changes, please refer to class ShapeFix_Wire. + * IGESToBRep_TopoCurve::TransferTopoBasicCurve and IGESToBRep_TopoCurve::Transfer2dTopoBasicCurve +The boundary vertices of an edge (or a wire if a curve was of C0 continuity) translated from a basis IGES curve (BSplineCurve, CopiousData, Line, etc.) are built with tolerance EpsGeom*UnitFactor, the tolerance of the edge(s) is (are) Precision::Confusion*.* +If a curve was divided into several edges, the common vertices of such adjacent edges have tolerance Precision::Confusion*.* +
Class IGESToBRep_TopoSurface
+All the faces created by this class have tolerance Precision::Confusion*.* +
Class IGESToBRep_BRepEntity
+ * IGESToBRep_BRepEntity::TransferVertex +The vertices from the VertexList entity are constructed with tolerance EpsGeom*UnitFactor. + * IGESToBRep_BRepEntity::TransferEdge +The edges from the EdgeList entity are constructed with tolerance Precision::Confusion*.* + * IGESToBRep_BRepEntity::TransferLoop +This function works like IGESToBRep_TopoCurve::TransferCurveOnFace* *and* *IGESToBRep_TopoCurve::TransferBoundaryOnFace*.* + * IGESToBRep_BRepEntity::TransferFace +The face from the Face IGES entity is constructed with tolerance Precision::Confusion. +
Shape Healing classes
+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 +
Package IGESControl
+IGESControl_Reader +
Package IGESToBRep
+IGESToBRep_Reader +IGESToBRep_Actor +IGESToBRep_CurveAndSurface +IGESToBRep_BasicCurve +IGESToBRep_BasicSurface +IGESToBRep_TopoCurve +IGESToBRep_TopoSurface +IGESToBRep_BRepEntity +
Package IGESConvGeom
+For description of classes, refer to CDL. +@subsubsection occt_1856844696_804874798_72 List of API classes +
package IGESControl
+IGESControl_Reader +
package IGESToBRep
+IGESToBRep_Reader +
package IGESData
+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 +The following diagram illustrates the structure of calls in reading IGES. +The highlighted classes produce OCCT geometry. +![](/user_guides/iges/images/iges_image003.jpg) + +@subsection occt_1856844696_804874798_8 Example +#include “IGESControl_Reader.hxx” +#include “TColStd_HSequenceOfTransient.hxx” +#include “TopoDS_Shape.hxx” +{ +IGESControl_Reader myIgesReader; +Standard_Integer nIgesFaces,nTransFaces; + +myIgesReader.ReadFile (“MyFile.igs”); +//loads file MyFile.igs + +Handle(TColStd_HSequenceOfTransient) myList = myIgesReader.GiveList(“iges-faces”); +//selects all IGES faces in the file and puts them into a list called //MyList, + +nIgesFaces = myList-Length(); +nTransFaces = myIgesReader.TransferList(myList); +//translates MyList, + +cout“IGES Faces: “nIgesFaces“  Transferred:”nTransFacesendl; +TopoDS_Shape sh = myIgesReader.OneShape(); +//and obtains the results in an OCCT shape. +} + + +@section occt_1856844696_874243683 Writing IGES +@subsection occt_1856844696_8742436831 Procedure +You can translate OCCT shapes to IGES entities in the following steps: +1.       initialize the process. +2.       set the translation parameters, +3.       perform the model translation, +4.       write the output IGES file. +You can translate several shapes before writing a file. Each shape will be a root entity in the IGES model. +@subsection occt_1856844696_8742436832 Domain covered +There are two families of OCCT objects that can be translated: + * geometrical, + * topological. +@subsection occt_1856844696_8742436833 Description of the process +@subsubsection occt_1856844696_87424368331 Initializing the process +Choose the unit and the mode you want to use to write the output file as follows: +IGESControl_Controller::Init +performs standard initialization. Returns False if an error occurred. +IGESControl_Writer writer; +uses the default unit (millimeters) and the default write mode (Face). +IGESControl_Writer writer (UNIT); +uses the Face write mode and any of the units that are accepted by IGES. +IGESControl_Writer writer (UNIT,modecr); +uses the unit (accepted by IGES) and the write mode of your choice. + * 0: Faces, + * 1: BRep +The result is an IGESControl_Writer object. +@subsubsection occt_1856844696_87424368332 Setting the translation parameters +The following parameters are used for the OCCT-to-IGES translation. +

write.iges.brep.mode:

+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. +Read this parameter with: +Standard_Integer byvalue = Interface_Static::IVal(;write.iges.brep.mode;); +Modify this parameter with: +Interface_Static::SetIVal (;write.iges.brep.mode;, 1); +Default value is ;Faces; (0). +

write.convertsurface.mode

+For writing to IGES in the BRep mode (see parameter write.iges.brep.mode), this parameter indicates whether elementary surfaces (cylindrical, conical, spherical, and toroidal) are converted into corresponding IGES 5.3 entities (if parameter's value is On), or written as surfaces of revolution (by default). +Default value is Off. +

write.iges.unit:

+gives the choice of the unit. The default unit for Open CASCADE Technology is the millimeter. You can choose to write your file in any of the units that are accepted by IGES. +Read this parameter with: +Standard_String byvalue = Interface_Static::CVal(;write.iges.unit;); +Modify this parameter with: +Interface_Static::SetCVal (;write.iges.unit;, ;INCH;); +Default value is ;MM;. +

write.iges.header.autor:

+gives the name of the author of the file. +Read this parameter with: +Standard_String byvalue = Interface_Static::CVal(;write.iges.header.author;); +Modify this value with: +Interface_Static::SetCVal (;write.iges.header.author;, ;name;); +Default value is the system name of the user. +

write.iges.header.company:

+gives the name of the sending company. +Read this parameter with: +Standard_String byvalue = Interface_Static::CVal(;write.iges.header.company;); +Modify this value with: +Interface_Static::SetCVal (;write.iges.header.company;, ;MDTV;); +Default value is ;; (empty). +

write.iges.header.product:

+gives the name of the sending product. +Read this parameter with: +Standard_String byvalue = Interface_Static::CVal(;write.iges.header.product;); +Modify this value with: +Interface_Static::SetCVal (;write.iges.header.product;, ;product name;); +Default value is ;CAS.CADE IGES processor Vx.x; where x.x means the current version of Open CASCADE Technology. +

write.iges.header.receiver:

+gives the name of the receiving company. +Read this parameter with: +Standard_String byvalue = Interface_Static::CVal(;write.iges.header.receiver;); +Modify this value with: +Interface_Static::SetCVal (;write.iges.header.receiver;, ;reciever name;); +Default value is ;; (empty). +

write.precision.mode:

+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. +Read this parameter with: +Standard_Integer ic = Interface_Static::IVal(;write.precision.mode;); +Modify this parameter with: +if (!Interface_Static::SetIVal(;write.precision.mode;,1)) +.. error .. +Default value is ;Average; (0). +

write.precision.val:

+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. +Read this parameter with: +Standard_Real rp = Interface_Static::RVal(;write.precision.val;); +Modify this parameter with: +if (!Interface_Static::SetRVal(;write.precision.val;,0.01)) +.. error .. +Default value is 0.0001. +

write.iges.resource.name

+

write.iges.sequence

+The same as read.iges.*, please see above. Note that the default sequence for writing contains one operator – DirectFaces - which converts elementary surfaces based on left-hand axes (valid in CASCADE) to right-hand axes (which are valid only in IGES). +Default values : write.iges.resource.name – IGES, write.iges.sequence – ToIGES. +@subsubsection occt_1856844696_87424368333 Performing the Open CASCADE Technology shape translation +You can perform the translation in one or several operations. Here is how you translate topological and geometrical objects: +Standard_Boolean ok = writer.AddShape (shape); +where shape is a TopoDS_Shape. +ok is True if translation was correctly performed and False if there was at least one entity that was not translated. +Standard_Boolean ok = writer.AddGeom (geom); +where geom is either Handle(Geom_Curve) or Handle(Geom_Surface) +ok is True if the translation was correctly performed and False if there was at least one entity whose geometry was not among the allowed types. +@subsubsection occt_1856844696_87424368334 Writing the IGES file +Write the IGES file with: +Standard_Boolean ok = writer.Write (;filename.igs;); +to give the file name. +Standard_Boolean ok = writer.Write (S); +where S is Standard_OStream +ok is True if the operation was correctly performed and False if an error occurred (for instance, if the processor could not create the file). +@subsection occt_1856844696_8742436834 Mapping Open CASCADE Technology shapes to IGES entities +Translated objects depend on the write mode that you chose. If you chose the Face mode, all of the shapes are translated, but the level of topological entities becomes lower (geometrical one). If you chose the BRep mode, topological OCCT shapes become topological IGES entities. +@subsubsection occt_1856844696_87424368341 Curves +@subsubsection occt_1856844696_87424368342 Surfaces + +@subsubsection occt_1856844696_87424368343 Topological entities +
Translation in Face mode
+ +
Translation in BRep mode
+@subsection occt_1856844696_8742436835 Tolerance management +@subsubsection occt_1856844696_87424368351 Setting resolution in an IGES file +There are several possibilities to set resolution in an IGES file. They are controlled by write.precision.mode parameter; the dependence between the value of this parameter and the set resolution is described in paragraph 3.3.2 Setting the translation parameters. +If the value of parameter write.precision.mode is -1, 0 or 1, resolution is computed from tolerances of sub-shapes inside the shape to be translated. In this computation, only tolerances of TopoDS_Edges and TopoDS_Vertices participate since they reflect the accuracy of the shape. TopoDS_Faces are ignored in computations since their tolerances may have influence on resulting computed resolution while IGES resolution mainly concerns points and curves but not surfaces. + +@subsection occt_1856844696_8742436836 Code architecture +@subsubsection occt_1856844696_87424368361 List of the classes +
package IGESControl
+IGESControl_Controller +IGESControl_Writer +
package BRepToIGES
+BRepToIGES_BREntity +BRepToIGES_BRWire +BRepToIGES_BRShell +BRepToIGES_BRSolid +
package BRepToIGESBRep
+BRepToIGESBRep_Entity +
package GeomToIGES
+GeomToIGES_GeomPoint +GeomToIGES_GeomVector +GeomToIGES_GeomCurve +GeomToIGES_GeomSurface +
package Geom2dToIGES
+Geom2dToIGES_Geom2dCurve +
package IGESConvGeom
+IGESConvGeom_GeomBuilder +For description of classes refer to CDL. +@subsubsection occt_1856844696_87424368362 List of API classes +
package IGESControl
+ * IGESControl_Controller + * IGESControl_Writer +
package IGESData
+ * class IGESData_IGESModel + * class IGESData_IGESEntity +For details refer to 4. API for reading/writing IGES and CDL. +@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. + + + + + + + + +
+ +
+ + + ![](/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 +} +@section occt_1856844696_1288309531 API for reading/writing IGES +@subsection occt_1856844696_12883095311 Overview +API classes provides the following tools: + * loading IGES files into memory, + * checking IGES files consistency, + * translating IGES files into OCCT shapes, + * translating OCCT shapes into IGES files, + * accessing the IGES model (which is an image of the IGES file in memory), + * selecting entities from the IGES model, + * accessing each entity in the IGES model. +@subsection occt_1856844696_12883095312 Package IGESControl +@subsubsection occt_1856844696_128830953121 General description +This package is intended to provide a tool to convert IGES-format entities to OCCT shapes and vice versa. +The package allows the end-user to perform both import from and export to an IGES file. +IGES files up to and including IGES version 5.3 can be read. +IGES files that are produced by this component conform to IGES version 5.3. +The result of reading IGES files is either a single Open CASCADE Technology shape or a set of them, the result of exporting Open CASCADE Technology geometric or topologic objects is an IGES file which may include one or several root entities (the ones not referenced by others). +@subsubsection occt_1856844696_128830953122 Class IGESControl_Controller +

General description

+This class controls the IGES norm. +This class is intended to provide an appropriate initialization of the IGES norm, namely it includes a set of necessary parameters for IGES translation and declaration of possible selections for IGES entities. +After the execution of initialization procedures, the use of IGES norm becomes available. +Inheritance +Standard_Transient +MMgt_TShared +XSControl_Controller +

Methods

+
Constructors
+IGESControl_Controller(const Standard_Boolean modefnes = Standard_False); +Purpose: Initializes the use of IGES (if modefnes is False) or FNES (if modefnes is True) norm. +
Method for performing initialization
+IGESControl:: 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. +
Method for creating IGES model
+IGESControl:: NewModel +Handle_Interface_InterfaceModel NewModel() const; +Purpose: Creates a new empty model ready to receive data of the norm. The Global section is filled with static parameters (receiver, author, company and unit). +
Method for getting the actor object
+IGESControl:: ActorRead +Handle_Transfer_ActorOfTransientProcess ActorRead( const Handle(Interface_InterfaceModel)& model) const; +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. +
Method for translating an Open CASCADE Technology shape
+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; +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_RetError: if modetrans is not equal to 0 or 1, or model is not an IGES model. +IFSelect_Fail:         if shape is null. + +@subsubsection occt_1856844696_128830953123 Class IGESControl_Reader +

General description

+This object reads IGES files and translates their contents into OCCT shapes. +All definitions in IGES version 5.3 are recognized but only geometric and topologic entities can be translated. Data, which cannot be translated, is loaded with the file but during translation it is ignored. +The translation of the IGES model into the OCCT model goes through the following steps: + * loading a file into memory, + * checking file consistency, + * setting translation parameters, + * performing the translation itself, + * fetching the results. + +The resulting OCCT objects belong to topologic shapes. The geometric objects (2D and 3D) are constructed in intermediate steps and serve as a support for topologic entities. +Each successful translation operation outputs one shape. A series of translations gives a list of shapes. +Inheritance +IGESToBRep_Reader +This class complements IGESToBRep_Reader class: + * deals directly with WorkSession object, + * computes the list of IGES entities matching specified criteria, + * performs translation of a list of entities and the ones specified by handle, + * outputs the results of checking and translating. +

Methods

+
Constructors:
+ * IGESControl_Reader (); +Purpose: Creates a reader from scratch and with a  new WorkSession object. + * IGESControl_Reader (const Handle(XSControl_WorkSession)& WS, +                                  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. +
Methods for dealing with WorkSession object
+ * IGESControl_Reader::SetWS +void SetWS ( const Handle(XSControl_WorkSession)& WS, +             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. + * IGESControl_Reader::WS +Handle_XSControl_WorkSession() const; +Purpose: Returns the used work session object. +
Method for loading an IGES file into memory
+ * IGESControl_Reader::ReadFile +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_RetError: an error occurred during reading +See also: +          IGESToBRep_Reader::LoadFile() + +
Methods for selecting entities to transfer
+ * IGESControl_Reader::GiveList +Handle_TColStd_HSequenceOfTransient GiveList( const Standard_CString first = ;;, const Standard_CString second = ;;); +Purpose: Returns a list of entities from the model according to the following rules: + * if first and second are empty - the list of roots for transfer, + * if first is a number or label of an entity - this entity itself, + * if first is a list of numbers/labels separated by commas - these entities, + * 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. +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. +Remarks: +      if first is erroneous, a null handle is returned. +
Methods for performing translation
+ * IGESControl_Reader::TransferEntity +Standard_Boolean TransferEntity(const Handle(Standard_Transient)& start) ; +Purpose: Performs the translation of the entity specified by its handle. +Returns False if an entity is not in the Model, else returns the result of the transfer. + * IGESControl_Reader:: TransferList +Standard_Integer TransferList( const Handle(TColStd_HSequenceOfTransient)& list) ; +Purpose: Performs the translation of the list of entities. +Returns the number of successful transfers. +
Methods for printing statistics
+ * 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. +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_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: Displays the checking results of the last transfer. +The parameters play the same role as in PrintCheckLoad. + * IGESControl_Reader:: PrintStatsTransfer +void PrintStatsTransfer( const Standard_Integer what, const Standard_Integer mode = 0) const; +Purpose: Displays all available statistics of the last transfer on the default trace file. The returned information is filtered by giving parameters. +what defines what kind of statistics are to be printed: +0 - basic figures, +1 - root results, +2 - all recorded (roots, intermediate, checked entities), +3 - abnormal records, +4 - warnings and fails messages, +5 - only fail messages +mode is used according to what: +if what is 0 mode is ignored +if what is 1, 2 or 3 mode defines the following: +0 - lists numbers of concerned entities in the model, +1 - for each entity, gives the number, label, type and result type and/or status (fail / warning...), +2 - for each entity, gives the maximum information (check result), +3 - counts per type of starting entity (class type), +4 - counts per result type and/or status, +5 - counts per couple (starting type / result type/status), +6 – does the same thing plus gives for each item, the list of numbers of entities in the starting model +if what is 4 or 5 - mode is treated as enumeration IFSelect_PrintCount. + * IGESControl_Reader:: PrintTransferInfo +void PrintTransferInfo( const IFSelect_PrintFail failwarn, const IFSelect_PrintCount mode) const; +Purpose: Displays information concerning the last transfer on the default trace file according to the given parameters: +mode defines what will be printed: +IFSelect_GeneralCount - general statistics (number of selected IGES entities, number of root IGES entities, number of resulting OCCT shapes, number of fail and warning messages), +IFSelect_CountByItem - number of IGES entities per each message type and IGES type and form, +IFSelect_ListByItem - number and a complete list of DE numbers of IGES entities per each message type and IGES type and form, +IFSelect_ResultCount - number of resulting OCCT shapes per each type of the shape, +IFSelect_Mapping - mapping of root IGES entities into OCCT shapes per IGES type and form and OCCT shape type. +failwarn defines if only fail messages (if failwarn is IFSelect_FailOnly) or both fail and warning messages (if it is IFSelect_FailAndWarn) will be printed if mode is IFSelect_CountByItem or IFSelect_ListByItem. +@subsubsection occt_1856844696_128830953124 Class IGESControl_Writer +

General description

+This class is intended to create and write an IGES file out of OCCT models. +IGES files produced by this component conform to IGES version 5.3. +This component gives a possibility to write an IGES file containing either geometric entities (conformant to IGES version less than 5.1) only or BRep entities (conformant to IGES version up to and including 5.3) as well. The writing mode is chosen by specifying the appropriate parameter. +The translation of an OCCT model (which can be a 2D or 3D geometric object or a topologic shape) into an IGES file is fulfilled in the following steps: +1.    initializing the file, +2.    setting the translation parameters, +3.    performing the translation itself, +4.    writing the IGES file. +Export to the IGES file can be performed on the basis of either an already existing IGES model (representation of the IGES file in memory) or a new one. The former case gives an opportunity to add geometric/topologic OCCT objects into an IGES model (file) that already exists. +

Methods

+
Constructors:
+ * IGESControl_Writer(); +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), +modecr corresponds to write mode: +0 - Face (default), +1 - BRep + * IGESControl_Writer( const Handle(IGESData_IGESModel)& model, + const Standard_Integer modecr = 0); +Purpose: Creates a writer object with an already prepared IGES model and write mode. +
Methods dealing with IGES models
+ * IGESControl_Writer:: Model +Handle_IGESData_IGESModel Model() const; +Purpose: Returns the produced model. + * IGESControl_Writer:: ComputeModel() ; +void ComputeModel() ; +Purpose: Prepares the model before writing by setting the required statuses inside the model. +
Methods dealing with transfer processes
+ * IGESControl_Writer:: SetTransferProcess +void SetTransferProcess(const Handle(Transfer_FinderProcess)& TP) ; +Purpose: Sets the FinderProcess object for the writer. + * IGESControl_Writer:: TransferProcess +Handle_Transfer_FinderProcess TransferProcess() const; +Purpose: Returns the FinderProcess object (containing final results and messages if any). +
Methods for performing translation
+ * IGESControl_Writer:: AddShape +Standard_Boolean AddShape(const TopoDS_Shape& sh) ; +Purpose: Translates a shape sh to IGES entities and adds them to the model. +Returns True if done, False if sh is not suitable for IGES or is null. + * IGESControl_Writer:: AddGeom +Standard_Boolean AddGeom(const Handle(Standard_Transient)& geom) ; +Purpose: Translates geom (which must be a curve or a surface) to IGES entities and adds them to the model. +Returns True if done, False if geom is neither a surface nor a curve suitable for IGES or is null. + * IGESControl_Writer:: AddEntity +Standard_Boolean AddEntity(const Handle(IGESData_IGESEntity)& ent) ; +Purpose: Adds an IGES entity (and the ones it references) to the model. +Returns False if ent is null. +
Methods for writing an IGES file
+ * IGESControl_Writer:: Write +Standard_Boolean Write( Standard_OStream& S, const Standard_Boolean fnes = Standard_False) ; +Standard_Boolean Write( const Standard_CString file, const Standard_Boolean fnes = Standard_False) ; +Purpose: Prepares (call ComputeModel()) and writes the model to the stream S or to the file file. +Returns True if the operation was correctly performed, False in case of error. +If mode fnes is equal to True, the resulting file will be written in the FNES format. +
Method for obtaining statistics
+ * IGESControl_Writer:: PrintStatsTransfer +void PrintStatsTransfer( const Standard_Integer what, const Standard_Integer mode = 0) const; +Purpose: Intended to display all statistics on the last performed translation. +Remarks: At the present moment does nothing (an empty method). +Package IGESToBRep + +@subsubsection occt_1856844696_128830953125 General description +Performs the actual translation of IGES entities into OCCT objects. +This package recognizes an IGES entity, performs its translation into an OCCT object (which can be 2D or 3D geometric objects, topologic shapes or transformation matrices) and returns the resulting shapes with associated messages (if there are any) occurred during the translation. +Those IGES entities that can be translated into OCCT objects by this package are given in the following table: + +Finally, all geometric IGES entities (curves and surfaces) are translated into topologic shapes. OCCT geometric objects serve as a support for topology. +@subsubsection occt_1856844696_128830953126 Class IGESToBRep_Reader +

General description

+This class reads IGES files and translates their contents into OCCT shapes. +This class provides basic tools for loading, checking and translating IGES files into OCCT topologic shapes. It is complemented with more high-level features by class IGESControl_Reader. +The functionalities provided by this class are the following: + * loading a file into memory, + * checking an IGES model in memory, + * translating all root entities or one entity specified by its rank number into OCCT shapes, + * fetching the results. + +

Methods

+
Constructors:
+ * IGESToBRep_Reader(); +Purpose: Performs initialization calling IGESAppli::Init() and IGESSolid::Init(), creates a new Actor object for transfer. + +
Method for loading an IGES file into memory
+ * IGESToBRep_Reader:: LoadFile +Standard_Integer LoadFile(const Standard_CString filename) ; +Purpose: Loads an IGES file filename into memory calling IGESFile_Read(), sets the returned IGES model (representing the loaded IGES file) calling SetModel(). +
Method for checking an IGES file
+ * IGESToBRep_Reader:: Check +Standard_Boolean Check(const Standard_Boolean withprint) const; +Purpose: Performs checking of a loaded IGES file calling Interface_CheckTool and Interface_CheckIterator. If withprint is True outputs the results of checking to the default trace file. +
Methods for preparing the transfer process
+ * IGESToBRep_Reader:: SetModel +void SetModel(const Handle(IGESData_IGESModel)& model) ; +Purpose: Sets a new IGES model object. Clears the list of translated shapes (if there are any), sets a new transfer process object. + * IGESToBRep_Reader:: Model +Handle_IGESData_IGESModel Model() const; +Purpose: Returns the used IGES model object. + * IGESToBRep_Reader:: SetTransientProcess +void SetTransientProcess(const Handle(Transfer_TransientProcess)& TP) ; +Purpose: Sets the transfer process object. + * IGESToBRep_Reader:: TransientProcess +Handle_Transfer_TransientProcess TransientProcess() const; +Purpose: Returns the used transfer process object. + * IGESToBRep_Reader:: Actor +Handle_IGESToBRep_Actor Actor() const; +Purpose: Returns the used actor object. + * IGESToBRep_Reader::Clear +void Clear() ; +Purpose: Clears the list of translated shapes. +
Methods for translation
+ * IGESToBRep_Reader:: TransferRoots +void TransferRoots(const Standard_Boolean onlyvisible = Standard_True) +Purpose: Performs the translation of root entities (ones that are not referenced by others). If onlyvisible is True, translates only visible entities (with Blank status equal to 0). Sets the continuity in accordance with the static parameter read.iges.bspline.continuity. +If parameter read.maxprecision.mode is set to 1, calls to ShapeTool_Utils::LimitTolerance() for the resulting shape with parameters 0 and the maximum between read.maxprecision.val and the basis tolerance of processor. + * IGESToBRep_Reader:: Transfer +Standard_Boolean Transfer(const Standard_Integer num) ; +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 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. +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. +
Methods for fetching the results
+ * IGESToBRep_Reader:: IsDone +Standard_Boolean IsDone() const; +Purpose: Returns True if the last transfer was successful. + * IGESToBRep_Reader:: NbShapes +Standard_Integer NbShapes() const; +Purpose: Returns the number of shapes recorded in the result. + * IGESToBRep_Reader:: Shape +TopoDS_Shape Shape(const Standard_Integer num = 1) const; +Purpose: Returns the result number num where num is an integer between 1 and NbShapes(). If not returns a null shape. + * IGESToBRep_Reader:: OneShape +TopoDS_Shape OneShape() const; +Purpose: Returns all results in a single shape, which is: + * a null shape if there are no results, + * in the case of a single result, only that shape, + * a compound that lists all the results if there are several resulting shapes. +@subsection occt_1856844696_12883095313 Package IGESData +@subsubsection occt_1856844696_128830953131 General description +This package defines general objects for dealing with the IGES interface. +It gives a basic description of the IGES interface: + * defines the Model for IGES (class IGESData_IGESModel), + * defines the Protocol tool specific for IGES (class IGESData_Protocol) + * defines the basic class IGESData_IGESEntity describing abstract IGES entity + * defines classes derived from IGESEntity and representing general IGES entities (IGESData_LineFontEntity, IGESData_TransfEntity, IGESData_SingleParentEntity, etc.), +@subsubsection occt_1856844696_128830953132 Class IGESData_IGESModel +

General description

+Gives an access to the general data in the Start and the Global sections of an IGES file. +Defines a model specific for IGES. +An IGES file includes the following sections: +Start, +Global, +Directory Entry, +Parameter Data, +Terminate +Inheritance: +Interface_InterfaceModel +MMgt_TShared +Standard_Transient +

Methods

+
Constructor
+ * IGESData_IGESModel (); +Purpose: Creates an empty IGES Model. +
Methods for initializing
+ * IGESData_IGESModel::ClearHeader +void ClearHeader() ; +Purpose: Erases all the data in the Start and Global sections. + * IGESData_IGESModel::NewEmptyModel +Handle_Interface_InterfaceModel NewEmptyModel() const; +Purpose: Returns a new Empty Model of the same type as this object, i.e. of type IGESData_IGESModel. +
Methods for dealing with the Start and the Global sections
+ * IGESData_IGESModel::DumpHeader +void DumpHeader(Standard_OStream& S, const Standard_Integer level = 0) const; +Remark: the Integer parameter is intended to be used as a level indicator, but not used for the moment. + * IGESData_IGESModel::StartSection +Handle_TColStd_HSequenceOfHAsciiString StartSection() const; +Purpose: Returns the Start section of the Model as a list of lines. + * IGESData_IGESModel::NbStartLines +Standard_Integer NbStartLines() const; +Purpose: Returns the number of the lines in the Start section. + * IGESData_IGESModel::StartLine +Standard_CString StartLine(const Standard_Integer num) const; +Purpose: Returns a line from the Start section specified by number num. +Remark: An empty string is returned if number num is out of range [1, NbStartLines()]. + * IGESData_IGESModel::ClearStartSection +void ClearStartSection() ; +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. + * 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. +Remark: If a number is out of range [0, NbStartLines()], the line is added at the end of section. + * IGESData_IGESModel::GlobalSection +const IGESData_GlobalSection& GlobalSection() const; +Purpose: Returns the Global section of the Model. + * IGESData_IGESModel::SetGlobalSection. +void SetGlobalSection(const IGESData_GlobalSection& header) ; +Purpose: Sets the Model's Global section. + * IGESData_IGESModel::ApplyStatic +Standard_Boolean ApplyStatic(const Standard_CString param = ;;) ; +Purpose: Sets some parameters of the Global section to those defined by static parameters (see parameters of translation). The allowed values for param (all by default) are: receiver, author and company (these are acronyms of static parameters). Returns True when done and if param is given, False if param is unknown or empty. +Remark: To set a unit into the Global section use the IGESData_BasicEditor class. +See also: User’s Guide: Parameters of translation. + * IGESData_IGESModel::GetFromAnother +void GetFromAnother(const Handle(Interface_InterfaceModel)& other) ; +Purpose: Takes the Global section from another Model. + * IGESData_IGESModel::VerifyCheck +virtual void VerifyCheck(Interface_Check& ach) const; +Purpose: Checks whether the Global section contains valid data according to the IGES specification. If the Global section is correct this method adds nothing into ach, but if not the method adds fail messages. + * IGESData_IGESModel::SetLineWeights +void SetLineWeights(const Standard_Real defw) ; +Purpose: Sets LineWeights of entities according to the Global section (MaxLineWeight and LineWeightGrad values) or to a default value (defw) for undefined weights. +
Methods for dealing with IGES entities
+ * IGESData_IGESModel::ClearLabels() ; +void ClearLabels() ; +Purpose: Erases labels. Not yet implemented. + * IGESData_IGESModel::PrintLabel +void PrintLabel(const Handle(Standard_Transient)& ent, Standard_OStream& S) const; +Purpose: Prints the Directory Entry number of a given entity, i.e. 'Dnn' where Dnn=2*number-1on the stream S. + * IGESData_IGESModel::StringLabel +Handle_TCollection_HAsciiString StringLabel (const Handle(Standard_Transient)& ent) const; +Purpose: Returns a string with a Directory Entry number of a given entity, i.e. a string 'Dnn' where Dnn=2*number-1. + * IGESData_IGESModel::Entity +Handle_IGESData_IGESEntity Entity(const Standard_Integer num) const; +Purpose: Returns an entity given by its rank number. + * IGESData_IGESModel::DNum +Standard_Integer DNum(const Handle(IGESData_IGESEntity)& ent) const; +Purpose: Returns the DE Number of an entity, i.e. 2*Number(ent)-1, or 0 if ent is unknown from this Model. +@subsubsection occt_1856844696_128830953133 Class IGESData_IGESEntity +

General description

+Represents an abstract IGES entity. +This class provides an access to common IGES entity fields (TypeNumber, TransformationMatrix, +etc.). +This class is a basic one for other classes complementing it to represent a certain IGES entity. +Refer to the IGES specification for more details. +Inheritance +MMgt_TShared +Standard_Transient +

Methods

+
Constructors:
+ * IGESData_IGESEntity(); +Purpose: Creates an empty object. Sets all values to defaults (calls Clear()). +
Methods for initializing fields of object.
+ * IGESData_IGESEntity::Clear +void Clear() ; +Purpose: Clears all fields of the object. + * IGESData_IGESEntity::InitTypeAndForm +void InitTypeAndForm( const Standard_Integer typenum, const Standard_Integer formnum) ; +Purpose: Sets the Type and Form Numbers to new values. +Remarks: Private method. Reserved for special use. + * IGESData_IGESEntity::InitDirFieldEntity +void InitDirFieldEntity( const Standard_Integer fieldnum, const Handle(IGESData_IGESEntity)& ent) ; +Purpose: Sets a directory field to an ent of any kind (see DirFieldEntity() for more details). +Remarks: If fieldnum is not equal to values listed in DirFieldEntity(), this method does nothing. + * IGESData_IGESEntity::InitTransf +void InitTransf(const Handle(IGESData_TransfEntity)& ent) ; +Purpose: Sets the Transf or erases it if ent is null. + * IGESData_IGESEntity::InitView +void InitView(const Handle(IGESData_ViewKindEntity)& ent) ; +Purpose: Sets the View or erases it if ent is null. + * IGESData_IGESEntity::InitLineFont +void InitLineFont( const Handle(IGESData_LineFontEntity)& ent, const Standard_Integer rank = 0) ; +Purpose: Sets the LineFont. If ent is null the RankLineFont is set to rank, otherwise it is set to a negative value. + * IGESData_IGESEntity::InitLevel +void InitLevel( const Handle(IGESData_LevelListEntity)& ent, const Standard_Integer val = 0) ; +Purpose: Sets the Level. If ent is null the DefLevel is set to val, otherwise it is set to a negative value. + * IGESData_IGESEntity::InitColor +void InitColor( const Handle(IGESData_ColorEntity)& ent, const Standard_Integer rank = 0) ; +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) ; +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) ; +Purpose: Sets data or erases it if it is given as null (zero for weightnum): +          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 +Remarks: If gradw is zero, there is division by zero in this method. +
Methods for querying the corresponding fields of an IGES entity.
+ * IGESData_IGESEntity::IGESType +IGESData_IGESType IGESType() const; +Purpose: Returns information on the IGES type of an entity including the type and the form of that entity. + * IGESData_IGESEntity::TypeNumber +Standard_Integer TypeNumber() const; +Purpose: Returns the IGES Type number. + * IGESData_IGESEntity::FormNumber +Standard_Integer FormNumber() const; +Purpose: Returns the IGES Form number. + * 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. + + * IGESData_IGESEntity::HasStructure +Standard_Boolean HasStructure() const; +Purpose: Returns True if an IGES entity is defined with a structure (it is normally reserved for certain classes, such as Macros). + * IGESData_IGESEntity::Structure +Handle_IGESData_IGESEntity Structure() const; +Purpose: Returns the Structure (used by some types of IGES entities only), returns a null handle if Structure is not defined. + * IGESData_IGESEntity::DefLineFont +IGESData_DefType DefLineFont() const; +Purpose: Returns the definition status of LineFont. + * IGESData_IGESEntity::RankLineFont +Standard_Integer RankLineFont() 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;. + * IGESData_IGESEntity::DefLevel +IGESData_DefList DefLevel() const; +Purpose: Returns the definition status of Level. + * IGESData_IGESEntity::Level +Standard_Integer Level() const; +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;. + * IGESData_IGESEntity::DefView +IGESData_DefList DefView() const; +Purpose: Returns the definition status of View (None,One or Several). + * IGESData_IGESEntity::View +Handle_IGESData_ViewKindEntity View() const; +Purpose: Returns the View (either Single or List) if it is defined. Returns a null handle if it is not defined. + + * 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;. + * 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::HasTransf +Standard_Boolean HasTransf() const; +Purpose: Returns True if a Transformation Matrix is defined. + * IGESData_IGESEntity::Transf +Handle_IGESData_TransfEntity Transf() const; +Purpose: Returns the Transformation Matrix (under IGES definition). Returns a null handle if there is none. +Remarks: For a more complete use, see Location & CompoundLocation. + * IGESData_IGESEntity::HasLabelDisplay +Standard_Boolean HasLabelDisplay() const; +Purpose: Returns True if the LabelDisplay mode is defined for this entity. + * IGESData_IGESEntity::LabelDisplay +Handle_IGESData_LabelDisplayEntity LabelDisplay() const; +Purpose: Returns the LabelDisplay, if there is one; else returns a null handle. + * IGESData_IGESEntity::BlankStatus +Standard_Integer BlankStatus() const; +Purpose: Returns the Blank Status (0 - visible, 1 - blanked). + * IGESData_IGESEntity::SubordinateStatus +Standard_Integer SubordinateStatus() const; +Purpose: Returns the Subordinate Switch (0-1-2-3) + * IGESData_IGESEntity::UseFlag +Standard_Integer UseFlag() const; +Purpose: Returns the Use Flag (0 to 5) of an entity. + * IGESData_IGESEntity::HierarchyStatus +Standard_Integer HierarchyStatus() const; +Purpose: Returns the Hierarchy status (0-1-2). + * IGESData_IGESEntity::LineWeightNumber +Standard_Integer LineWeightNumber() const; +Purpose: Returns the LineWeight Number (0 if it is not defined). +See also: LineWeight. + + * 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. + * IGESData_IGESEntity::DefColor +IGESData_DefType DefColor() const; +Purpose: Returns the definition status of Color. + * IGESData_IGESEntity::RankColor +Standard_Integer RankColor() const; +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;. + * 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. +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 True if ShortLabel is not null. + * IGESData_IGESEntity::ShortLabel +Handle_TCollection_HAsciiString ShortLabel() const; +Purpose: Returns label value as a string (null if ShortLabel is blank). + * IGESData_IGESEntity::HasSubScriptNumber +virtualStandard_Boolean HasSubScriptNumber() const; +Purpose: Returns True if SubScript Number is defined. + * IGESData_IGESEntity::SubScriptNumber +Standard_Integer SubScriptNumber() const; +Purpose: Returns SubScript Number as an integer (0 if not defined). + * IGESData_IGESEntity::HasOneParent() +Standard_Boolean HasOneParent() const; +Purpose: Returns True if an entity has one and only one parent, defined by a SingleParentEntity Type Associativity (explicit sharing). +Remarks: Thus, implicit sharing remains defined at the model level. +See class ToolLocation. + * IGESData_IGESEntity::UniqueParent() const; +Handle_IGESData_IGESEntity UniqueParent() const; +Purpose: Returns the Unique Parent (if it is the one). +Exceptions: Interface_InterfaceError if there are either several or no parents. + * IGESData_IGESEntity::Location() +gp_GTrsf Location() const; +Purpose: Returns the entity Location given by Transf in the Directory Part (see above). Considers local location only (not taking into account the parent's one - see CompoundLocation for that). If no Transf is defined, returns Identity. + * IGESData_IGESEntity::VectorLocation() +gp_GTrsf VectorLocation() 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. + * 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). + * 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. +
Methods for dealing with associativities and properties.
+ * IGESData_IGESEntity::ArePresentAssociativities() +Standard_Boolean ArePresentAssociativities() const; +Purpose: Returns True if the Entity is defined with an Associativity list, even an empty one (i.e., the file is of 0 length). Otherwise returns False (the file contains no identification concerning this list at all). + * IGESData_IGESEntity::NbAssociativities +Standard_Integer NbAssociativities() const; +Purpose: Returns the number of recorded associativities (0 if no list is defined). + * IGESData_IGESEntity::Associativities +Interface_EntityIterator Associativities() const; +Purpose: Returns the Associativity List in the form of an EntityIterator. + * IGESData_IGESEntity::NbTypedAssociativities +Standard_Integer NbTypedAssociativities +          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; +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 +void AddAssociativity(const Handle(IGESData_IGESEntity)& ent) ; +Purpose: Adds an Associativity to the list (called by Associate only). +Exceptions: Standard_NullObject if ent is null. + * IGESData_IGESEntity::RemoveAssociativity +void RemoveAssociativity(const Handle(IGESData_IGESEntity)& ent) ; +Purpose: Removes an Associativity from the list (called by Dissociate). +Exceptions: Standard_NullObject if ent is null. + * IGESData_IGESEntity::LoadAssociativities +void LoadAssociativities(const Interface_EntityList& list) ; +Purpose: Loads a complete List of Asociativities (used during Read or Copy operations). + * IGESData_IGESEntity::ClearAssociativities +void ClearAssociativities() ; +Purpose: Removes all associativities at once. + * IGESData_IGESEntity::Associate +void Associate(const Handle(IGESData_IGESEntity)& ent) const; +Purpose: Sets this object to the Associativity list of another Entity. If ent is a null object, method does nothing. + * IGESData_IGESEntity::Dissociate +void Dissociate(const Handle(IGESData_IGESEntity)& ent) const; +Purpose: Removes this object from the Associativity list of another Entity. If ent is a null object, method does nothing. + * IGESData_IGESEntity::ArePresentProperties +Standard_Boolean ArePresentProperties() const; +Purpose: Returns True if the Entity is defined with a Property list, even an empty one (i.e., the file is of 0 length). Otherwise, returns False (file contains no identification concerning this list at all). + * IGESData_IGESEntity::NbProperties() +Standard_Integer NbProperties() const; +Purpose: Returns the number of recorded properties (0 if no list is defined) + * IGESData_IGESEntity::Properties() +Interface_EntityIterator Properties() const; +Purpose: Returns the Property List in the form of an EntityIterator + * IGESData_IGESEntity::NbTypedProperties +Standard_Integer NbTypedProperties +          (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; +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 +void AddProperty(const Handle(IGESData_IGESEntity)& ent) ; +Purpose: Adds a Property to the list. +Exceptions: Standard_NullObject if entis null. + * IGESData_IGESEntity::RemoveProperty +void RemoveProperty(const Handle(IGESData_IGESEntity)& ent) ; +Purpose: Removes a Property from the list. +Exceptions: Standard_NullObject if entis null. + * IGESData_IGESEntity::LoadProperties +void LoadProperties(const Interface_EntityList& list) ; +Purpose: Loads a complete List of Properties (used during Read or Copy operations). + * IGESData_IGESEntity::ClearProperties() ; +void ClearProperties() ; +Purpose: Removes all properties at once + + + +@section occt_1856844696_722523915 Using XSTEPDRAW +@subsection occt_1856844696_7225239151 XSDRAWIGES Overview +XSTEPDRAW UL is intended for creating executables for testing XSTEP interfaces interactively in the DRAW environment. It provides an additional set of DRAW commands specific for the data exchange tasks, which allow loading and writing data files and analysis of resulting data structures and shapes. +This paragraph 5 is divided into several sections. Sections 5.3 and 5.5 deal with reading and writing of IGES files and are intended specifically for the IGES processor, sections 5.2 and 5.4 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. +***NOTE*** +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, vertical dash (|) is used. +@subsection occt_1856844696_7225239152 Setting interface parameters +A set of parameters for importing and exporting IGES files is defined in the XSTEP resource file. In XSTEPDRAW, these parameters can be viewed or changed using command +Draw param [parameter_name [value]] +Command param with no arguments gives a list of all parameters with their values. When 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 the loaded entities into OCCT shapes etc.) can be output to the trace file. Two parameters are defined in the DRAW session: trace level (integer value from 0 to 9, default is 0), and trace file (default is a standard output). +Command xtrace is intended to view and change these parameters: +Draw xtrace +- prints current settings (e.g.: ;Level=0 - Standard Output;); +Draw xtrace # +- sets the trace level to the value #; +Draw xtrace tracefile.log +- sets the trace file as tracefile.log; and +Draw xtrace . +- directs all messages to the standard output. + +@subsection occt_1856844696_7225239153 Reading IGES files +For a description of parameters used in reading an IGES file refer to 2.3.3 ;Setting the translation parameters ;. +These parameters are set by command param: + + +It is possible either only to load an IGES file into memory (i.e. to fill the model with data from the file), or to read it (i.e. to load and convert all entities to OCCT shapes). +Loading is done by the command +Draw xload file_name +Once the file is loaded, it is possible to investigate the structure of the loaded data. To learn how to do it see 5.4 Analyzing the transferred. +Reading of an IGES file is done by the command +Draw igesbrep 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 **igesbrep** command. In that case, only conversion of IGES entities to OCCT shapes will be done. +Command **igesbrep** will interactively ask the user to select a set of entities to be converted: + + +After the selected set of entities is loaded the user will be asked how loaded entities should be converted into OCCT shapes (e.g., one shape per root or one shape for all the entities). It is also possible to save loaded shapes in files, and to cancel loading. +The second parameter of the **igesbrep** command defines the name of the loaded shape. If several shapes are created, they will get indexed names. For instance, if the last parameter was ‘s’, they will be s_1, ... s_N. +selection specifies the scope of selected entities in the model, it is xst-transferrable-roots by default. An asterisk “*” can be specified instead of iges-visible-transf-roots. For possible values for selection refer to 2.3.4. +Instead of igesbrep the following commands can be used: +Draw trimport file_name result_shape_name selection +which outputs the result of translation of each selected entity into one shape, +Draw trimpcomp file_name result_shape_name selection +which outputs the result of translation of all selected entities into one shape (TopoDS_Compound for several entities). +An asterisk “*” can be specified instead of selection, it means xst-transferrable-roots. +During the IGES translation, a map of correspondence between IGES entities and OCCT shapes is created. +To get information on the result of translation of the given IGES entity the command +Draw tpent # +is used. +To create an OCCT shape corresponding to an IGES entity the command +Draw tpdraw # +is used. +To get the number of an IGES entity corresponding to an OCCT shape the command +Draw fromshape shape_name +is used. +To clear the map of correspondences between IGES entities and OCCT shapes the command +Draw tpclear +is used. +@subsection occt_1856844696_7225239154 Analyzing the transferred data +The procedure of analysis of the data import can be divided into two stages: +1.    checking the file contents, +2.    estimation of translation results (conversion and validated ratios). +@subsubsection occt_1856844696_72252391541 Checking file contents +General statistics on the loaded data can be obtained by using command +Draw data symbol +The information printed by this command depends on the symbol specified: + + +There is a set of special objects, which can be used to operate with the 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 +In the following commands if several selection arguments are specified the results of each following selection are applied to those of the one preceding it. +Command +Draw givelist selection_name [selection_name] +prints a list of loaded entities defined by selection argument. For possible values of selection_name please refer to 2.3.4. +Command +Draw givecount selection_name [selection_name] +prints a number of loaded entities defined by selection argument. For possible values of selection_name please refer to 2.3.4. +Three commands are used to calculate statistics on the entities in the model: +Draw count counter [selection ...] +Prints only a number of entities per each type matching the criteria defined by arguments. +Draw sumcount counter [selection ...] +Prints the total number of entities of all types matching the criteria defined by arguments and the largest number corresponding to one type. +Draw listcount counter [selection ...] +Prints a list of entities per each type matching the criteria defined by arguments. +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: + +Command +Draw listtypes selection_name ... +gives a list of entity types which were encountered in the last loaded file (with a number of IGES 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. + +Entities in the IGES file are numbered in the succeeding order. An entity can be identified either by its number (#) or by its label. Label is the letter ‘D’ followed by the index of the first line with the data for this entity in the Directory Entry section of the IGES file. The label can be calculated on the basis of the number as ‘D(2*# -1)’. For example, entity # 6 has label D11. To get a label for an entity with a known number, command +Draw elab # +can be used. +In the same way, command +Draw enum D# +prints a number for an entity with the given label. +The content of an IGES entity can be obtained by using 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 # +@subsubsection occt_1856844696_72252391542 Estimating the results of reading IGES +All of the following commands are available only after the data are converted into OCCT shapes (i.e. after command **igesbrep**). +Command +Draw tpstat [*|?]symbol [selection] +is provided to get all statistics on the last transfer, including the list of transferred entities with mapping from IGES to OCCT types, as well as fail and warning messages. The parameter *symbol *defines what information will be printed: + + +The sign ‘*’ before the parameters **n**, **s**, **b**, **t**, **r** makes it work on all entities (not only on roots). The sign ‘?’ before **n**, **s**, **b**, **t** limits the scope of information to invalid entities. +Optional argument selection can limit the action of the command with a selected subset of entities. +To get help, run this command without arguments. +Example. Translation ratio on IGES faces. +Draw: tpstat *l iges-faces +The second version of the same command is TPSTAT (not capital spelling). +Draw: TPSTAT symbol +Symbol can be of the following values: + +Sometimes the trimming contours of IGES faces (i.e., entity 141 for 143, 142 for 144) can be lost during translation due to fails. To obtain the number of lost trims and the number of corresponding IGES entities the command +Draw tplosttrim [IGES_type] +is used. It outputs the rank and DE 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. +Optional parameter IGES_type can be TrimmedSurface, BoundedSurface or Face to specify the only type of IGES faces. +Example. Untrimmed 144 entities. +Draw tplosttrim TrimmedSurface +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 a shape and some geometrical data (number of C0 surfaces, curves, indirect surfaces, etc.). +Note. 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 a shape, command +Draw checkbrep shape_name expurged_shape_name +is used. It checks the geometry and topology of a shape 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 IGES entities the OCCT shape was produced from. +expurged_shape_name will contain the original shape without invalid subshapes. +To get information on tolerances of subshapes 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 or it can output tolerances of all subshapes of the whole shape. +When specifying min and max arguments this command outputs shapes with names shape_name_... and their total number with tolerances in the range [min, max]. +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_1856844696_7225239155 Writing an IGES file +For a description of parameters used in reading an IGES file refer to 3.3.2 Setting the translation parameters. +These parameters are set by 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 make it empty, and the next command will convert the specified shapes to IGES entities and put them into the InterfaceModel: +Draw brepiges shape_name_1 [filename.igs] +To write the prepared model to a file with name **filename.igs**, enter +Draw writeall filename.igs +@subsection occt_1856844696_7225239156 Index of useful commands + + + + +@section occt_1856844696_332489123 Reading from and writing to XDE +@subsection occt_1856844696_3324891231 Description of the process +@subsubsection occt_1856844696_33248912311 Loading an IGES file +Before performing any other operation, you must load an IGES file with: +IGESCAFControl_Reader reader(XSDRAW::Session(), Standard_False); +IFSelect_ReturnStatus stat = reader.ReadFile(“filename.igs”); +Loading the file only memorizes, but does not translate the data. +@subsubsection occt_1856844696_33248912312 Checking the loaded IGES file +This step is not obligatory. See the description of this step below in paragraph 2.3.2. +@subsubsection occt_1856844696_33248912313 Setting parameters for translation to XDE +See the description of this step below in paragraph 2.3.3. +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_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). +@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_33248912316 Setting parameters for translation from XDE to IGES +The following parameters can be set for translation of attributes to IGES: +• 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_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). +@subsubsection occt_1856844696_33248912318 Writing an IGES file +Write an IGES file with: +IFSelect_ReturnStatus statw = aWriter.WriteFile(;filename.igs;); +or +IFSelect_ReturnStatus statw = writer.WriteFile (S); +where S is OStream + + diff --git a/dox/user_guides/iges/images/iges_image001.jpg b/dox/user_guides/iges/images/iges_image001.jpg new file mode 100644 index 0000000000..0e782cab77 Binary files /dev/null and b/dox/user_guides/iges/images/iges_image001.jpg differ diff --git a/dox/user_guides/iges/images/iges_image002.jpg b/dox/user_guides/iges/images/iges_image002.jpg new file mode 100644 index 0000000000..5f87a335b2 Binary files /dev/null and b/dox/user_guides/iges/images/iges_image002.jpg differ diff --git a/dox/user_guides/iges/images/iges_image003.jpg b/dox/user_guides/iges/images/iges_image003.jpg new file mode 100644 index 0000000000..3374326554 Binary files /dev/null and b/dox/user_guides/iges/images/iges_image003.jpg differ diff --git a/dox/user_guides/iges/images/iges_image004.jpg b/dox/user_guides/iges/images/iges_image004.jpg new file mode 100644 index 0000000000..f0f591d39a Binary files /dev/null and b/dox/user_guides/iges/images/iges_image004.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image001.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image001.jpg new file mode 100644 index 0000000000..0e782cab77 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image001.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image002.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image002.jpg new file mode 100644 index 0000000000..5f87a335b2 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image002.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image003.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image003.jpg new file mode 100644 index 0000000000..6e29a8f2bc Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image003.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image004.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image004.jpg new file mode 100644 index 0000000000..99083f72a0 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image004.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image005.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image005.jpg new file mode 100644 index 0000000000..8077bf48d7 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image005.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image006.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image006.jpg new file mode 100644 index 0000000000..467615ff07 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image006.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image007.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image007.jpg new file mode 100644 index 0000000000..7a06470356 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image007.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image008.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image008.jpg new file mode 100644 index 0000000000..cf3000fdfb Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image008.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image009.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image009.jpg new file mode 100644 index 0000000000..a130f4ced6 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image009.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image010.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image010.jpg new file mode 100644 index 0000000000..c1acfa5493 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image010.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image011.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image011.jpg new file mode 100644 index 0000000000..f3008bb691 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image011.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image012.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image012.jpg new file mode 100644 index 0000000000..900f1cc42e Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image012.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image013.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image013.jpg new file mode 100644 index 0000000000..074ddc183d Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image013.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image014.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image014.jpg new file mode 100644 index 0000000000..a32391362b Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image014.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image015.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image015.jpg new file mode 100644 index 0000000000..89951ff205 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image015.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image016.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image016.jpg new file mode 100644 index 0000000000..8088f57a41 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image016.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image017.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image017.jpg new file mode 100644 index 0000000000..4257e6c749 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image017.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image018.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image018.jpg new file mode 100644 index 0000000000..ac491ac15a Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image018.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image019.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image019.jpg new file mode 100644 index 0000000000..5c1d334893 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image019.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image020.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image020.jpg new file mode 100644 index 0000000000..a5ffde8839 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image020.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image021.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image021.jpg new file mode 100644 index 0000000000..892580cda3 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image021.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image022.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image022.jpg new file mode 100644 index 0000000000..eb85fbb52b Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image022.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image023.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image023.jpg new file mode 100644 index 0000000000..056de2a754 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image023.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image024.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image024.jpg new file mode 100644 index 0000000000..41a3f5d138 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image024.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image025.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image025.jpg new file mode 100644 index 0000000000..0ac51112b8 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image025.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image026.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image026.jpg new file mode 100644 index 0000000000..d80efe4e4e Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image026.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image027.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image027.jpg new file mode 100644 index 0000000000..7d6ef1a2a5 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image027.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image028.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image028.jpg new file mode 100644 index 0000000000..3b84415646 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image028.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image029.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image029.jpg new file mode 100644 index 0000000000..2395516d8e Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image029.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image030.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image030.jpg new file mode 100644 index 0000000000..3cfcdabd7a Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image030.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image031.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image031.jpg new file mode 100644 index 0000000000..e517a418ff Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image031.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image032.png b/dox/user_guides/modeling_algos/images/modeling_algos_image032.png new file mode 100644 index 0000000000..0cef972677 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image032.png differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image033.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image033.jpg new file mode 100644 index 0000000000..003316358a Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image033.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image034.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image034.jpg new file mode 100644 index 0000000000..4e24bf6857 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image034.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image035.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image035.jpg new file mode 100644 index 0000000000..4f9fe81c10 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image035.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image036.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image036.jpg new file mode 100644 index 0000000000..460c7f433d Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image036.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image037.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image037.jpg new file mode 100644 index 0000000000..9705467fc0 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image037.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image038.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image038.jpg new file mode 100644 index 0000000000..ab8895ecce Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image038.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image039.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image039.jpg new file mode 100644 index 0000000000..1f3720dc16 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image039.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image040.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image040.jpg new file mode 100644 index 0000000000..8d58cdb7ba Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image040.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image041.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image041.jpg new file mode 100644 index 0000000000..5ce5a93067 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image041.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image042.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image042.jpg new file mode 100644 index 0000000000..9f21968f7e Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image042.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image043.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image043.jpg new file mode 100644 index 0000000000..8797c27d86 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image043.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image044.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image044.jpg new file mode 100644 index 0000000000..ae36c9750e Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image044.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image045.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image045.jpg new file mode 100644 index 0000000000..940693f569 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image045.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image046.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image046.jpg new file mode 100644 index 0000000000..334f9c9b1e Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image046.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image047.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image047.jpg new file mode 100644 index 0000000000..9a6b1f4550 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image047.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image048.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image048.jpg new file mode 100644 index 0000000000..146d252ac6 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image048.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image049.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image049.jpg new file mode 100644 index 0000000000..789628de1d Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image049.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image050.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image050.jpg new file mode 100644 index 0000000000..7bf04ab391 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image050.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image051.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image051.jpg new file mode 100644 index 0000000000..6cd2adbcc5 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image051.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image052.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image052.jpg new file mode 100644 index 0000000000..23c5b18272 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image052.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image053.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image053.jpg new file mode 100644 index 0000000000..1b1c9a8908 Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image053.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image054.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image054.jpg new file mode 100644 index 0000000000..94b9cb4dff Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image054.jpg differ diff --git a/dox/user_guides/modeling_algos/images/modeling_algos_image055.jpg b/dox/user_guides/modeling_algos/images/modeling_algos_image055.jpg new file mode 100644 index 0000000000..3255ef582a Binary files /dev/null and b/dox/user_guides/modeling_algos/images/modeling_algos_image055.jpg differ diff --git a/dox/user_guides/modeling_algos/modeling_algos.md b/dox/user_guides/modeling_algos/modeling_algos.md new file mode 100644 index 0000000000..9f5520c13a --- /dev/null +++ b/dox/user_guides/modeling_algos/modeling_algos.md @@ -0,0 +1,2661 @@ +Modeling Algorithms {#user_guides__modeling_algos} +========================= + +@section occt_modalg_1 Introduction + +@subsection occt_modalg_1_1 The Modeling Algorithms Module + + +This manual explains how to use the Modeling Algorithms. It provides basic documentation on modeling algorithms. For advanced information on Modeling Algorithms, see our offerings on our web site at www.opencascade.org/support/training/ + +The Modeling Algorithms module brings together a wide range of topological algorithms used in modeling. Along with these tools, you will find the geometric algorithms, which they call. + +The algorithms available are divided into: + * Geometric tools + * Topological tools + * The Topology API + +@subsection occt_modalg_1_2 The Topology API + +The Topology  API of Open CASCADE Technology (**OCCT**) includes the following six packages: + + * BRepAlgoAPI + * BRepBuilderAPI + * BRepFilletAPI + * BRepFeat + * BRepOffsetAPI + * BRepPrimAPI + +The classes in these six packages provide the user with a simple and powerful interface. + * A simple interface: a function call works ideally, + * A powerful interface: including error handling and access to extra information provided by the algorithms. + +As an example, the class BRepBuilderAPI_MakeEdge can be used to create a linear edge from two points. + +~~~~~ +gp_Pnt P1(10,0,0), P2(20,0,0); +TopoDS_Edge E = BRepBuilderAPI_MakeEdge(P1,P2); +~~~~~ + +This is the simplest way to create edge E from two points P1, P2, but the developer can test for errors when he is not as confident of the data as in the previous example. + +~~~~~ +#include +#include +#include +void EdgeTest() +{ +gp_Pnt P1; +gp_Pnt P2; +BRepBuilderAPI_MakeEdge ME(P1,P2); +if (!ME.IsDone()) +{ +// doing ME.Edge() or E = ME here +// would raise StdFail_NotDone +Standard_DomainError::Raise +(“ProcessPoints::Failed to createan edge”); +} +TopoDS_Edge E = ME; +} +~~~~~ + +In this example an intermediary object ME has been introduced. This can be tested for the completion of the function before accessing the result. More information on **error handling** in the topology programming interface can be found in the next section. + +BRepBuilderAPI_MakeEdge provides valuable information. For example, when creating an edge from two points, two vertices have to be created from the points. Sometimes you may be interested in getting these vertices quickly without exploring the new edge. Such information can be provided when using a class. The following example shows a function creating an edge and two vertices from two points. + +~~~~~ +void MakeEdgeAndVertices(const gp_Pnt& P1, +const gp_Pnt& P2, +TopoDS_Edge& E, +TopoDS_Vertex& V1, +TopoDS_Vertex& V2) +{ +BRepBuilderAPI_MakeEdge ME(P1,P2); +if (!ME.IsDone()) { +Standard_DomainError::Raise +(“MakeEdgeAndVerices::Failed to create an edge”); +} +E = ME; +V1 = ME.Vextex1(); +V2 = ME.Vertex2(); +~~~~~ + +The BRepBuilderAPI_MakeEdge class provides the two methods Vertex1 and Vertex2, which return the two vertices used to create the edge. + +How can BRepBuilderAPI_MakeEdge be both a function and a class? It can do this because it uses the casting capabilities of C++. The BRepBuilderAPI_MakeEdge class has a method called Edge; in the previous example the line E = ME could have been written. + +~~~~~ +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 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. + + +@subsubsection occt_modalg_1_2_1 Error Handling in the Topology API + +A method can report an error in the two following situations: + * The data or arguments of the method are incorrect, i.e. they do not respect the restrictions specified by the methods in its specifications. Typical example: creating a linear edge from two identical points is likely to lead to a zero divide when computing the direction of the line. + * Something unexpected happened. This situation covers every error not included in the first category. Including: interruption, programming errors in the method or in another method called by the first method, bad specifications of the arguments (i.e. a set of arguments that was not expected to fail). + +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. + +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: + +~~~~~ +#include +try { +TopoDS_Edge E = BRepBuilderAPI_MakeEdge(P1,P2); +// go on with the edge +} +catch { +// process the error. +} +~~~~~ + +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. + +~~~~~ +BRepBuilderAPI_MakeEdge ME(P1,P2); +if (!ME.IsDone()) { +// doing ME.Edge() or E = ME here +// would raise StdFail_NotDone +Standard_DomainError::Raise +(“ProcessPoints::Failed to create an edge”); +} +TopoDS_Edge E = ME; +~~~~~ + +@section occt_modalg_2 Geometric Tools + +@subsection occt_modalg_2_1 Overview + +Open CASCADE Technology geometric tools include: + + * Computation of intersections + * Interpolation laws + * Computation of curves and surfaces from constraints + * Computation of lines and circles from constraints + * Projections + +@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. + +![](/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.* + +![](/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. + +@subsubsection occt_modalg_2_2_1 Geom2dAPI_InterCurveCurve + +This class may be instantiated either for intersection of curves C1 and C2. +~~~~~ +Geom2dAPI_InterCurveCurve Intersector(C1,C2,tolerance); +~~~~~ + +or for self-intersection of curve C3. +~~~~~ +Geom2dAPI_InterCurveCurve Intersector(C3,tolerance); +~~~~~ + +~~~~~ +Standard_Integer N = Intersector.NbPoints(); +~~~~~ +Calls the number of intersection points + +To select the desired intersection point, pass an integer index value in argument. +~~~~~ +gp_Pnt2d P = Intersector.Point(Index); +~~~~~ + +~~~~~ +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; +Intersector.Segment(Index,Seg1,Seg2); +// if intersection of 2 curves +Intersector.Segment(Index,Seg1); +// if self-intersection of a curve +~~~~~ + +If you need access to a wider range of functionalities the following method will return the algorithmic object for the calculation of intersections: + +~~~~~ +Geom2dInt_GInter& TheIntersector = Intersector.Intersector(); +~~~~~ + +@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. + +This class is instantiated as follows: +~~~~~ +GeomAPI_IntCS Intersector(C, S); +~~~~~ + +~~~~~ +Standard_Integer nb = Intersector.NbPoints(); +~~~~~ +Calls the number of intersection points. + +~~~~~ +gp_Pnt& P = Intersector.Point(Index); +~~~~~ + +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. + +This class is instantiated as follows: +~~~~~ +GeomAPI_IntSS Intersector(S1, S2, Tolerance); +~~~~~ +Once the *GeomAPI_IntSS *object has been created, it can be interpreted. + +~~~~~ +Standard_Integer nb = Intersector. NbLines(); +~~~~~ +Calls the number of intersection curves. + +~~~~~ +Handle(Geom_Curve) C = Intersector.Line(Index) +~~~~~ +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 may be instantiated as follows: +~~~~~ +Geom2dAPI_Interpolate +(const Handle_TColgp_HArray1OfPnt2d& Points, +const Standard_Boolean PeriodicFlag, +const Standard_Real Tolerance); + +Geom2dAPI_Interpolate Interp(Points, Standard_False, +                                    Precision::Confusion()); +~~~~~ + + +It is possible to call the BSpline curve from the object defined above it. +~~~~~ +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. + +~~~~~ +Handle(Geom2d_BSplineCurve) C = +Geom2dAPI_Interpolate(Points, +    Standard_False, +    Precision::Confusion()); +~~~~~ + +@subsubsection occt_modalg_2_3_2 GeomAPI_Interpolate + +This class may be instantiated as follows: +~~~~~ +GeomAPI_Interpolate +(const Handle_TColgp_HArray1OfPnt& Points, +const Standard_Boolean PeriodicFlag, +const Standard_Real Tolerance); + +GeomAPI_Interpolate Interp(Points, Standard_False, +                                    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. + +Handle(Geom_BSplineCurve) C = + GeomAPI_Interpolate(Points, + Standard_False, + 1.0e-7); + +Boundary conditions may be imposed with the method Load. +~~~~~ +GeomAPI_Interpolate AnInterpolator +(Points, Standard_False, 1.0e-5); +AnInterpolator.Load (StartingTangent, EndingTangent); +~~~~~ + +@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. + +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. + +![](/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 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. + +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 + +The following analytic algorithms using value-handled entities for creation of 2D lines or circles with geometric constraints are available: + + * circle tangent to three elements (lines, circles, curves, points), + * circle tangent to two elements and having a radius, + * circle tangent to two elements and centered on a third element, + * circle tangent to two elements and centered on a point, + * circle tangent to one element and centered on a second, + * bisector of two points, + * bisector of two lines, + * bisector of two circles, + * bisector of a line and a point, + * bisector of a circle and a point, + * bisector of a line and a circle, + * line tangent to two elements (points, circles, curves), + * line tangent to one element and parallel to a line, + * line tangent to one element and perpendicular to a line, + * line tangent to one element and forming angle with a line. + +@subsection occt_modalg_2_6 Types of algorithms +There are three categories of available algorithms, which complement each other: + * analytic, + * geometric, + * iterative. + +An analytic algorithm will solve a system of equations, whereas a geometric algorithm works with notions of parallelism, tangency, intersection and so on. + +Both methods can provide solutions. An iterative algorithm, however, seeks to refine an approximate solution. + +@subsection occt_modalg_2_7 Performance factors + +The appropriate algorithm is the one, which reaches a solution of the required accuracy in the least time. Only the solutions actually requested by the user should be calculated. A simple means to reduce the number of solutions is the notion of a "qualifier". There are four qualifiers, which are: + + * Unqualified: the position of the solution is undefined with respect to this argument. + * Enclosing: the solution encompasses this argument. + * Enclosed: the solution is encompassed by this argument. + * Outside: the solution and argument are outside each other. + + +@subsection occt_modalg_2_8 Conventions + +@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"). + +![](/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: + +![](/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. + +![](/user_guides/modeling_algos/images/modeling_algos_image008.jpg "An Oriented Line") + +@subsection occt_modalg_2_9 Examples + +@subsubsection occt_modalg_2_9_1 Line tangent to two circles +The following four diagrams illustrate four cases of using qualifiers in the creation of a line. The fifth shows the solution if no qualifiers are given. + +Note that the qualifier "Outside" is used to mean "Mutually exterior". + +**Example 1 Case 1** + +![](/user_guides/modeling_algos/images/modeling_algos_image009.jpg "Both circles outside") + +Constraints: +Tangent and Exterior to C1. +Tangent and Exterior to C2. + +Syntax: + +~~~~~ +GccAna_Lin2d2Tan + Solver(GccEnt::Outside(C1), + GccEnt::Outside(C2), + Tolerance); +~~~~~ + +**Example 1 Case 2** + +![](/user_guides/modeling_algos/images/modeling_algos_image010.jpg "Both circles enclosed") + +Constraints: +Tangent and Including C1. +Tangent and Including C2. + +Syntax: + +~~~~~ +GccAna_Lin2d2Tan + Solver(GccEnt::Enclosing(C1), + GccEnt::Enclosing(C2), + Tolerance); +~~~~~ + +**Example 1 Case 3** + +![](/user_guides/modeling_algos/images/modeling_algos_image011.jpg "C1 enclosed, C2 outside") + +Constraints: +Tangent and Including C1. +Tangent and Exterior to C2. + +Syntax: +~~~~~ +GccAna_Lin2d2Tan + Solver(GccEnt::Enclosing(C1), + GccEnt::Outside(C2), + Tolerance); +~~~~~ + +**Example 1 Case 4** + +![](/user_guides/modeling_algos/images/modeling_algos_image012.jpg "C1 outside, C2 enclosed") +Constraints: +Tangent and Exterior to C1. +Tangent and Including C2. + +Syntax: +~~~~~ +GccAna_Lin2d2Tan + Solver(GccEnt::Outside(C1), + GccEnt::Enclosing(C2), + Tolerance); +~~~~~ + +**Example 1 Case 5** + +![](/user_guides/modeling_algos/images/modeling_algos_image013.jpg "With no qualifiers specified") + +Constraints: +Tangent and Undefined with respect to C1. +Tangent and Undefined with respect to C2. + +Syntax: +~~~~~ +GccAna_Lin2d2Tan + Solver(GccEnt::Unqualified(C1), + GccEnt::Unqualified(C2), + Tolerance); +~~~~~ + +@subsubsection occt_modalg_2_9_2 Circle of given radius tangent to two circles +The following four diagrams show the four cases in using qualifiers in the creation of a circle. + +**Example 2 Case 1** +![](/user_guides/modeling_algos/images/modeling_algos_image014.jpg "Both solutions outside") + +Constraints: +Tangent and Exterior to C1. +Tangent and Exterior to C2. + +Syntax: +~~~~~ +GccAna_Circ2d2TanRad + Solver(GccEnt::Outside(C1), + GccEnt::Outside(C2), Rad, Tolerance); +~~~~~ + +**Example 2 Case 2** + +![](/user_guides/modeling_algos/images/modeling_algos_image015.jpg "C2 encompasses C1") + +Constraints: +Tangent and Exterior to C1. +Tangent and Included by C2. + +Syntax: +~~~~~ +GccAna_Circ2d2TanRad + Solver(GccEnt::Outside(C1), + GccEnt::Enclosed(C2), Rad, Tolerance); +~~~~~ + +**Example 2 Case 3** +![](/user_guides/modeling_algos/images/modeling_algos_image016.jpg "Solutions enclose C2") + +Constraints: +Tangent and Exterior to C1. +Tangent and Including C2. + +Syntax: +~~~~~ +GccAna_Circ2d2TanRad + Solver(GccEnt::Outside(C1), + GccEnt::Enclosing(C2), Rad, Tolerance); +~~~~~ + +**Example 2 Case 4** +![](/user_guides/modeling_algos/images/modeling_algos_image017.jpg "Solutions enclose C1") + +Constraints: +Tangent and Enclosing C1. +Tangent and Enclosing C2. + +Syntax: +~~~~~ +GccAna_Circ2d2TanRad + Solver(GccEnt::Enclosing(C1), + GccEnt::Enclosing(C2), Rad, Tolerance); +~~~~~ + +**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: + +~~~~~ +GccAna_Circ2d2TanRad Solver(GccEnt::Unqualified(C1), + GccEnt::Unqualified(C2), + Rad,Tolerance); +~~~~~ + +@subsection occt_modalg_2_10 Algorithms + +The objects created by this toolkit are non-persistent. + +@subsubsection occt_modalg_2_10_1 Qualifiers +The *GccEnt* package contains the following package methods: + * Unqualified, + * Enclosing, + * Enclosed, + * Outside. + +This enables creation of expressions, for example: +~~~~~ +GccAna_Circ2d2TanRad + Solver(GccEnt::Outside(C1), + GccEnt::Enclosing(C2), Rad, Tolerance); +~~~~~ + +The objective in this case is to find all circles of radius *Rad*, which are tangent to both circle *C1* and *C2*, C1 being outside and C2 being inside. + +@subsubsection occt_modalg_2_10_2 General Remarks about Algorithms + +We consider the following to be the case: + * If a circle passes through a point then the circle is tangential to it. + * 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: + +Creation of a Line +------------------ + +~~~~~ +Tangent ( point | circle ) & Parallel ( line ) +Tangent ( point | circle ) & Perpendicular ( line | circle ) +Tangent ( point | circle ) & Oblique ( line ) +Tangent ( 2 { point | circle } ) +Bisector( line | line ) +~~~~~ + +Creation of Conics +------------------ + +~~~~~ +Bisector ( point | point ) +Bisector ( line | point ) +Bisector ( circle | point ) +Bisector ( line | line ) +Bisector ( circle | line ) +Bisector ( circle | circle ) +~~~~~ + +Creation of a Circle +-------------------- +~~~~~ +Tangent ( point | line | circle ) & Center ( point ) +Tangent ( 3 { point | line | circle } ) +Tangent ( 2 { point | line | circle } ) & Radius ( real ) +Tangent ( 2 { point | line | circle } ) & Center ( line | circle ) +Tangent ( point | line | circle ) & Center ( line | circle ) & Radius ( real ) +~~~~~ + +For each algorithm, the tolerance (and angular tolerance if appropriate) is given as an argument. Calculation is done with the highest precision available from the hardware. + +@subsubsection occt_modalg_2_10_4 Geometric Algorithms + +*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 +-------------------- + +~~~~~ +Tangent ( curve ) & Center ( point ) +Tangent ( curve , point | line | circle | curve ) & Radius ( real ) +Tangent ( 2 {point | line | circle} ) & Center ( curve ) +Tangent ( curve ) & Center ( line | circle | curve ) & Radius ( real ) +Tangent ( point | line | circle ) & Center ( curve ) & Radius ( real ) +~~~~~ + +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: + +Creation of a Line +------------------ +~~~~~ +Tangent ( curve ) & Oblique ( line ) +Tangent ( curve , { point | circle | curve } ) +~~~~~ + +Creation of a Circle +-------------------- + +~~~~~ +Tangent ( curve , 2 { point | circle | curve } ) +Tangent ( curve , { point | circle | curve } ) +& Center ( line | circle | curve ) +~~~~~ + +@subsection occt_modalg_2_1 Curves and Surfaces from Constraints + +@subsubsection occt_modalg_2_1_1 Fair 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 +------------------------- +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: + + * 0 the curve must pass through a point + * 1 the curve must pass through a point and have a given tangent + * 2 the curve must pass through a point, have a given tangent and a given curvature. + +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: + + * 0 the curve must pass through a point + * 1 the curve must pass through a point and have a given tangent + * 2 the curve must pass through a point, have a given tangent and a given curvature. + +Constraint orders of 0, 1 and 2 can be used. The algorithm minimizes tension, sagging and jerk energy. + +The function *Curve* returns the result as a 2D BSpline curve. + +Specifying the length of the curve +---------------------------------- +If you want to give a specific length to a batten curve, use: + +~~~~~ +b.SetSlidingFactor(L / b.SlidingOfReference()) +~~~~~ +where *b* is the name of the batten curve object + +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 +---------------- +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 +--------------------------- +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 +---------------------------- +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. + +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 +---------------------- +The class *GeomFill_SimpleBound* allows you defining a boundary for the surface to be constructed. + +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 +-------------- +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) + + +@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 +------------------------- +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 +-------------------------------- +The class *CurveConstraint* allows defining curves as constraints to the surface, which you want to build. + +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 +-------------------------------------- +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*. + +![](/user_guides/modeling_algos/images/modeling_algos_image019.jpg "Surface generated from four curves and a point") + +**Example** + +Create a Plate surface and approximate it from a polyline as a curve constraint and a point constraint + +~~~~~ +Standard_Integer NbCurFront=4, +NbPointConstraint=1; +gp_Pnt P1(0.,0.,0.); +gp_Pnt P2(0.,10.,0.); +gp_Pnt P3(0.,10.,10.); +gp_Pnt P4(0.,0.,10.); +gp_Pnt P5(5.,5.,5.); +BRepBuilderAPI_MakePolygon W; +W.Add(P1); +W.Add(P2); +W.Add(P3); +W.Add(P4); +W.Add(P1); +// Initialize a BuildPlateSurface +GeomPlate_BuildPlateSurface BPSurf(3,15,2); +// Create the curve constraints +BRepTools_WireExplorer anExp; +for(anExp.Init(W); anExp.More(); anExp.Next()) +{ +TopoDS_Edge E = anExp.Current(); +Handle(BRepAdaptor_HCurve) C = new +BRepAdaptor_HCurve(); +C-ChangeCurve().Initialize(E); +Handle(BRepFill_CurveConstraint) Cont= new +BRepFill_CurveConstraint(C,0); +BPSurf.Add(Cont); +} +// Point constraint +Handle(GeomPlate_PointConstraint) PCont= new +GeomPlate_PointConstraint(P5,0); +BPSurf.Add(PCont); +// Compute the Plate surface +BPSurf.Perform(); +// Approximation of the Plate surface +Standard_Integer MaxSeg=9; +Standard_Integer MaxDegree=8; +Standard_Integer CritOrder=0; +Standard_Real dmax,Tol; +Handle(GeomPlate_Surface) PSurf = BPSurf.Surface(); +dmax = Max(0.0001,10*BPSurf.G0Error()); +Tol=0.0001; +GeomPlate_MakeApprox +Mapp(PSurf,Tol,MaxSeg,MaxDegree,dmax,CritOrder); +Handle (Geom_Surface) Surf (Mapp.Surface()); +// create a face corresponding to the approximated Plate +Surface +Standard_Real Umin, Umax, Vmin, Vmax; +PSurf-Bounds( Umin, Umax, Vmin, Vmax); +BRepBuilderAPI_MakeFace MF(Surf,Umin, Umax, Vmin, Vmax); +~~~~~ + +@subsection occt_modalg_2_12 Projections +This package provides functionality for projecting points onto 2D and 3D curves and surfaces. + +@subsubsection occt_modalg_2_12_1 Projection of a Point onto a Curve +*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. + + +![](/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. + +@subsubsection occt_modalg_2_12_2 Geom2dAPI_ProjectPointOnCurve +This class may be instantiated as in the following example: + +~~~~~ +gp_Pnt2d P; +Handle(Geom2d_BezierCurve) C = + new Geom2d_BezierCurve(args); +Geom2dAPI_ProjectPointOnCurve Projector (P, C); +~~~~~ + +To restrict the search for normals to a given domain *[U1,U2]*, use the following constructor: +~~~~~ +Geom2dAPI_ProjectPointOnCurve Projector (P, C, U1, U2); +~~~~~ +Having thus created the *Geom2dAPI_ProjectPointOnCurve* object, we can now interrogate it. + +Calling the number of solution points +------------------------------------- +~~~~~ +Standard_Integer NumSolutions = Projector.NbPoints(); +~~~~~ + +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 +----------------------------------------- +For a given point corresponding to a given *Index*: + +~~~~~ +Standard_Real U = Projector.Parameter(Index); +~~~~~ + +This can also be programmed as: + +~~~~~ +Standard_Real U; +Projector.Parameter(Index,U); +~~~~~ + +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 +--------------------------------- + +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 +--------------------------------------------------- +~~~~~ +Standard_Real U = Projector.LowerDistanceParameter(); +~~~~~ + +Calling the minimum distance from the point to the curve +------------------------------------------------------- +~~~~~ +Standard_Real D = Projector.LowerDistance(); +~~~~~ + +@subsubsection occt_modalg_2_12_3 Redefined operators + +Some operators have been redefined to find the closest solution. + +*Standard_Real()* returns the minimum distance from the point to the curve. + +~~~~~ +Standard_Real D = Geom2dAPI_ProjectPointOnCurve (P,C); +~~~~~ + +*Standard_Integer()* returns the number of solutions. + +~~~~~ +Standard_Integer N = +Geom2dAPI_ProjectPointOnCurve (P,C); +~~~~~ + +*gp_Pnt2d()* returns the nearest solution point. + +~~~~~ +gp_Pnt2d P1 = Geom2dAPI_ProjectPointOnCurve (P,C); +~~~~~ + +Using these operators makes coding easier when you only need the nearest point. Thus: +~~~~~ +Geom2dAPI_ProjectPointOnCurve Projector (P, C); +gp_Pnt2d P1 = Projector.NearestPoint(); +~~~~~ +can be written more concisely as: +~~~~~ +gp_Pnt2d P1 = Geom2dAPI_ProjectPointOnCurve (P,C); +~~~~~ +However, note that in this second case no intermediate *Geom2dAPI_ProjectPointOnCurve* object is created, and thus it is impossible to have access to other solution points. + + +@subsubsection occt_modalg_2_12_4 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 extrema. For example: + +~~~~~ +Extrema_ExtPC2d& TheExtrema = Projector.Extrema(); +~~~~~ + +@subsubsection occt_modalg_2_12_5 GeomAPI_ProjectPointOnCurve + +This class is instantiated as in the following example: +~~~~~ +gp_Pnt P; +Handle(Geom_BezierCurve) C = + new Geom_BezierCurve(args); +GeomAPI_ProjectPointOnCurve Projector (P, C); +~~~~~ +If you wish to restrict the search for normals to the given domain [U1,U2], use the following constructor: +~~~~~ +GeomAPI_ProjectPointOnCurve Projector (P, C, U1, U2); +~~~~~ +Having thus created the *GeomAPI_ProjectPointOnCurve* object, you can now interrogate it. + +Calling the number of solution points +------------------------------------- +~~~~~ +Standard_Integer NumSolutions = Projector.NbPoints(); +~~~~~ + +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 +----------------------------------------- +For a given point corresponding to a given index: + +~~~~~ +Standard_Real U = Projector.Parameter(Index); +~~~~~ + +This can also be programmed as: +~~~~~ +Standard_Real U; +Projector.Parameter(Index,U); +~~~~~ + +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 +---------------------------------- +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 +--------------------------------------------------- +~~~~~ +Standard_Real U = Projector.LowerDistanceParameter(); +~~~~~ + +Calling the minimum distance from the point to the curve +-------------------------------------------------------- +~~~~~ +Standard_Real D = Projector.LowerDistance(); +~~~~~ + +Redefined operators +-------------------- +Some operators have been redefined to find the nearest solution. + +*Standard_Real()* returns the minimum distance from the point to the curve. + +~~~~~ +Standard_Real D = GeomAPI_ProjectPointOnCurve (P,C); +~~~~~ + +*Standard_Integer()* returns the number of solutions. +~~~~~ +Standard_Integer N = GeomAPI_ProjectPointOnCurve (P,C); +~~~~~ + +*gp_Pnt2d()* returns the nearest solution point. + +~~~~~ +gp_Pnt P1 = GeomAPI_ProjectPointOnCurve (P,C); +~~~~~ +Using these operators makes coding easier when you only need the nearest point. In this way, + +~~~~~ +GeomAPI_ProjectPointOnCurve Projector (P, C); +gp_Pnt P1 = Projector.NearestPoint(); +~~~~~ + +can be written more concisely as: +~~~~~ +gp_Pnt P1 = GeomAPI_ProjectPointOnCurve (P,C); +~~~~~ +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: + +~~~~~ +Extrema_ExtPC& TheExtrema = Projector.Extrema(); +~~~~~ + +@subsubsection occt_modalg_2_12_6 Projection of a Point on a Surface + +*GeomAPI_ProjectPointOnSurf* class allows calculation of all normals projected from a point from *gp_Pnt* onto a geometric surface from Geom_Surface. + + +![](/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. + +*GeomAPI_ProjectPointOnSurf* is instantiated as in the following example: +~~~~~ +gp_Pnt P; +Handle (Geom_Surface) S = new Geom_BezierSurface(args); +GeomAPI_ProjectPointOnSurf Proj (P, S); +~~~~~ + +To restrict the search for normals within the given rectangular domain [U1, U2, V1, V2], use the following constructor: + +~~~~~ +GeomAPI_ProjectPointOnSurf Proj (P, S, U1, U2, V1, V2); +~~~~~ + +The values of U1, U2, V1 and V2 lie at or within their maximum and minimum limits, i.e.: +~~~~~ +Umin <= U1 < U2 <= Umax +Vmin <= V1 < V2 <= Vmax +~~~~~ +Having thus created the *GeomAPI_ProjectPointOnSurf* object, you can interrogate it. + +Calling the number of solution points +------------------------------------- + +~~~~~ +Standard_Integer NumSolutions = Proj.NbPoints(); +~~~~~ + +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 +------------------------------------------ +For a given point corresponding to the given index: + +~~~~~ +Standard_Real U,V; +Proj.Parameters(Index, U, V); +~~~~~ + +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 +---------------------------------- +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 +---------------------------------------------------- +~~~~~ +Standard_Real U,V; +Proj.LowerDistanceParameters (U, V); +~~~~~ + +Calling the minimum distance from a point to the surface +-------------------------------------------------------- +~~~~~ +Standard_Real D = Proj.LowerDistance(); +~~~~~ + +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. + +~~~~~ +Standard_Real D = GeomAPI_ProjectPointOnSurf (P,S); +~~~~~ + +*Standard_Integer()* returns the number of solutions. + +~~~~~ +Standard_Integer N = GeomAPI_ProjectPointOnSurf (P,S); +~~~~~ + +*gp_Pnt2d()* returns the nearest solution point. + +~~~~~ +gp_Pnt P1 = GeomAPI_ProjectPointOnSurf (P,S); +~~~~~ + +Using these operators makes coding easier when you only need the nearest point. In this way, + +~~~~~ +GeomAPI_ProjectPointOnSurface Proj (P, S); +gp_Pnt P1 = Proj.NearestPoint(); +~~~~~ + +can be written more concisely as: + +~~~~~ +gp_Pnt P1 = GeomAPI_ProjectPointOnSurface (P,S); +~~~~~ + +In the second case, however, no intermediate *GeomAPI_ProjectPointOnSurf* object is created, and it is impossible to access other solution points. + +@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: + +~~~~~ +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. + +These methods are called as follows: +~~~~~ +Handle(Geom2d_Curve) C2d = GeomAPI::To2d(C3d, Pln); +Handle(Geom_Curve) C3d = GeomAPI::To3d(C2d, Pln); +~~~~~ + + +@section occt_modalg_3 Topological Tools + +Open CASCADE Technology topological tools include: + + * Standard topological objects combining topological data structure and boundary representation + * Geometric Transformations + * Conversion to NURBS geometry + * Finding Planes + * Duplicating Shapes + * Checking Validity + + +@subsection occt_modalg_3_1 Creation of Standard Topological Objects + +The standard topological objects include + * Vertices + * Edges + * Wires + * Faces + * Shells + * Solids. + +There are two root classes for their construction and modification: +* The deferred class *BRepBuilderAPI_MakeShape* is the root of all *BRepBuilderAPI* classes, which build shapes. It inherits from the class *BRepBuilderAPI_Command* and provides a field to store the constructed shape. +* The deferred *BRepBuilderAPI_ModifyShape* is used as a root for the shape modifications. It inherits *BRepBuilderAPI_MakeShape* and implements the methods used to trace the history of all sub-shapes. + +@subsubsection occt_modalg_3_1_1 Vertex + +*BRepBuilderAPI_MakeVertex* creates a new vertex from a 3D point from gp. +~~~~~ +gp_Pnt P(0,0,10); +TopoDS_Vertex V = BRepBuilderAPI_MakeVertex(P); +~~~~~ + +This class always creates a new vertex and has no other methods. + +@subsubsection occt_modalg_3_1_2 Edge + +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 +----------------------- + +~~~~~ +Handle(Geom_Curve) C = ...; // a curve +TopoDS_Vertex V1 = ...,V2 = ...;// two Vertices +Standard_Real p1 = ..., p2 = ..;// two parameters +TopoDS_Edge E = BRepBuilderAPI_MakeEdge(C,V1,V2,p1,p2); +~~~~~ + +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. + +![](/user_guides/modeling_algos/images/modeling_algos_image022.jpg "Basic Edge Construction") + +The following rules apply to the arguments: + +**The curve** + * Must not be a Null Handle. + * If the curve is a trimmed curve, the basis curve is used. + +**The vertices** + * Can be null shapes. When V1 or V2 is Null the edge is open in the corresponding direction and the corresponding parameter p1 or p2 must be infinite (i.e p1 is RealFirst(), p2 is RealLast()). + * Must be different vertices if they have different 3d locations and identical vertices if they have the same 3d location (identical vertices are used when the curve is closed). + +**The parameters** + * Must be increasing and in the range of the curve, i.e.: +~~~~~ + C->FirstParameter() <= p1 < p2 <= C->LastParameter() +~~~~~ + +* If the parameters are decreasing, the Vertices are switched, i.e. V2 becomes V1 and V1 becomes V2. +* On a periodic curve the parameters p1 and p2 are adjusted by adding or subtracting the period to obtain p1 in the range of the curve and p2 in the range p1 < p2 <= p1+ Period. So on a parametric curve p2 can be greater than the second parameter, see the figure below. +* Can be infinite but the corresponding vertex must be Null (see above). +* The distance between the Vertex 3d location and the point evaluated on the curve with the parameter must be lower than the default precision. + +The figure below illustrates two special cases, a semi-infinite edge and an edge on a periodic curve. + +![](/user_guides/modeling_algos/images/modeling_algos_image023.jpg "Infinite and Periodic Edges") + + +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. + * 3d points (Pnt from gp) can be given in place of vertices. Vertices are created from the points. Giving vertices is useful when creating connected vertices. + * The vertices or points can be omitted if the parameters are given. The points are computed by evaluating the parameters on the curve. + * The vertices or points and the parameters can be omitted. The first and the last parameters of the curve are used. + +The five following methods are thus derived from the basic construction: + +~~~~~ +Handle(Geom_Curve) C = ...; // a curve +TopoDS_Vertex V1 = ...,V2 = ...;// two Vertices +Standard_Real p1 = ..., p2 = ..;// two parameters +gp_Pnt P1 = ..., P2 = ...;// two points +TopoDS_Edge E; +// project the vertices on the curve +E = BRepBuilderAPI_MakeEdge(C,V1,V2); +// Make vertices from points +E = BRepBuilderAPI_MakeEdge(C,P1,P2,p1,p2); +// Make vertices from points and project them +E = BRepBuilderAPI_MakeEdge(C,P1,P2); +// Computes the points from the parameters +E = BRepBuilderAPI_MakeEdge(C,p1,p2); +// Make an edge from the whole curve +E = BRepBuilderAPI_MakeEdge(C); +~~~~~ + + +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* + +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. + +~~~~~ + +TopoDS_Vertex V1 = ...,V2 = ...;// two Vertices +gp_Pnt P1 = ..., P2 = ...;// two points +TopoDS_Edge E; + +// linear edge from two vertices +E = BRepBuilderAPI_MakeEdge(V1,V2); + +// linear edge from two points +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. + +The *Error* method returns a term of the *BRepBuilderAPI_EdgeError* enumeration. It can be used to analyze the error when *IsDone* method returns False. The terms are: + + * **EdgeDone** - No error occurred, *IsDone* returns True. + * **PointProjectionFailed** - No parameters were given, but the projection of the 3D points on the curve failed. This happens if the point distance to the curve is greater than the precision. + * **ParameterOutOfRange** - The given parameters are not in the range *C->FirstParameter()*, *C->LastParameter()* + * **DifferentPointsOnClosedCurve** - The two vertices or points have different locations but they are the extremities of a closed curve. + * **PointWithInfiniteParameter** - A finite coordinate point was associated with an infinite parameter (see the Precision package for a definition of infinite values). + * **DifferentsPointAndParameter** - The distance of the 3D point and the point evaluated on the curve with the parameter is greater than the precision. + * **LineThroughIdenticPoints** - Two identical points were given to define a line (construction of an edge without curve), *gp::Resolution* is used to test confusion . + +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. + +![](/user_guides/modeling_algos/images/modeling_algos_image024.jpg "Creating a Wire") + +~~~~~ +#include +#include +#include +#include +#include +#include +#include + +// Use MakeArc method to make an edge and two vertices +void MakeArc(Standard_Real x,Standard_Real y, +Standard_Real R, +Standard_Real ang, +TopoDS_Shape& E, +TopoDS_Shape& V1, +TopoDS_Shape& V2) +{ +gp_Ax2 Origin = gp::XOY(); +gp_Vec Offset(x, y, 0.); +Origin.Translate(Offset); +BRepBuilderAPI_MakeEdge +ME(gp_Circ(Origin,R), ang, ang+PI/2); +E = ME; +V1 = ME.Vertex1(); +V2 = ME.Vertex2(); +} + +TopoDS_Wire MakeFilletedRectangle(const Standard_Real H, +const Standard_Real L, +const Standard_Real R) +{ +TopTools_Array1OfShape theEdges(1,8); +TopTools_Array1OfShape theVertices(1,8); + +// First create the circular edges and the vertices +// using the MakeArc function described above. +void MakeArc(Standard_Real, Standard_Real, +Standard_Real, Standard_Real, +TopoDS_Shape&, TopoDS_Shape&, TopoDS_Shape&); + +Standard_Real x = L/2 - R, y = H/2 - R; +MakeArc(x,-y,R,3.*PI/2.,theEdges(2),theVertices(2), +theVertices(3)); +MakeArc(x,y,R,0.,theEdges(4),theVertices(4), +theVertices(5)); +MakeArc(-x,y,R,PI/2.,theEdges(6),theVertices(6), +theVertices(7)); +MakeArc(-x,-y,R,PI,theEdges(8),theVertices(8), +theVertices(1)); +// Create the linear edges +for (Standard_Integer i = 1; i <= 7; i += 2) +{ +theEdges(i) = BRepBuilderAPI_MakeEdge +(TopoDS::Vertex(theVertices(i)),TopoDS::Vertex +(theVertices(i+1))); +} +// Create the wire using the BRepBuilderAPI_MakeWire +BRepBuilderAPI_MakeWire MW; +for (i = 1; i <= 8; i++) +{ +MW.Add(TopoDS::Edge(theEdges(i))); +} +return MW.Wire(); +} +~~~~~ + +@subsubsection occt_modalg_3_1_3 Edge 2D + +Use *BRepBuilderAPI_MakeEdge2d* class to make edges on a working plane from 2d curves. The working plane is a default value of the *BRepBuilderAPI* package (see the *Plane* methods). + +*BRepBuilderAPI_MakeEdge2d* class is strictly similar to BRepBuilderAPI_MakeEdge, but it uses 2D geometry from gp and Geom2d instead of 3D geometry. + +@subsubsection occt_modalg_3_1_4 Polygon + +*BRepBuilderAPI_MakePolygon* class is used to build polygonal wires from vertices or points. Points are automatically changed to vertices as in *BRepBuilderAPI_MakeEdge*. + +The basic usage of *BRepBuilderAPI_MakePolygon* is to create a wire by adding vertices or points using the Add method. At any moment, the current wire can be extracted. The close method can be used to close the current wire. In the following example, a closed wire is created from an array of points. + +~~~~~ +#include +#include +#include + +TopoDS_Wire ClosedPolygon(const TColgp_Array1OfPnt& Points) +{ +BRepBuilderAPI_MakePolygon MP; +for(Standard_Integer i=Points.Lower();i=Points.Upper();i++) +{ +MP.Add(Points(i)); +} +MP.Close(); +return MP; +} +~~~~~ + +Short-cuts are provided for 2, 3, or 4 points or vertices. Those methods have a Boolean last argument to tell if the polygon is closed. The default value is False. + +Two examples: + +Example of a closed triangle from three vertices: +~~~~~ +TopoDS_Wire W = BRepBuilderAPI_MakePolygon(V1,V2,V3,Standard_True); +~~~~~ + +Example of an open polygon from four points: +~~~~~ +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. + +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 +----------------------- + +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. + +~~~~~ +Handle(Geom_Surface) S = ...; // a surface +Standard_Real umin,umax,vmin,vmax; // parameters +TopoDS_Face F = BRepBuilderAPI_MakeFace(S,umin,umax,vmin,vmax); +~~~~~ + +![](/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: + +~~~~~ +Handle(Geom_Surface) S = ...; // a surface +TopoDS_Face F = BRepBuilderAPI_MakeFace(S); +~~~~~ + +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. + + +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* + +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. + +~~~~~ +gp_Cylinder C = ..; // a cylinder +TopoDS_Wire W = ...;// a wire +BRepBuilderAPI_MakeFace MF(C); +MF.Add(W); +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. + +If there is no parametric curve for an edge of the wire on the Face it is computed by projection. + +For one wire, a simple syntax is provided to construct the face from the surface and the wire. The above lines could be written: + +~~~~~ +TopoDS_Face F = BRepBuilderAPI_MakeFace(C,W); +~~~~~ + +A planar face can be created from only a wire, provided this wire defines a plane. For example, to create a planar face from a set of points you can use *BRepBuilderAPI_MakePolygon* and *BRepBuilderAPI_MakeFace*. + +~~~~~ +#include +#include +#include +#include + +TopoDS_Face PolygonalFace(const TColgp_Array1OfPnt& thePnts) +{ +BRepBuilderAPI_MakePolygon MP; +for(Standard_Integer i=thePnts.Lower(); +i<=thePnts.Upper(); i++) +{ +MP.Add(thePnts(i)); +} +MP.Close(); +TopoDS_Face F = BRepBuilderAPI_MakeFace(MP.Wire()); +return F; +} +~~~~~ + +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 +TopoDS_Wire W = ...; // a wire +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. + +Error status +------------ +The Error method returns an error status, which is a term from the *BRepBuilderAPI_FaceError* enumeration. + +* *FaceDone* - no error occurred. +* *NoFace* - no initialization of the algorithm; an empty constructor was used. +* *NotPlanar* - no surface was given and the wire was not planar. +* *CurveProjectionFailed* - no curve was found in the parametric space of the surface for an edge. +* *ParametersOutOfRange* - the parameters umin,umax,vmin,vmax are out of the surface. + +@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. + +Up to four edges can be used directly, for example: + +~~~~~ +TopoDS_Wire W = BRepBuilderAPI_MakeWire(E1,E2,E3,E4); +~~~~~ + +For a higher or unknown number of edges the Add method must be used; for example, to build a wire from an array of shapes (to be edges). + +~~~~~ +TopTools_Array1OfShapes theEdges; +BRepBuilderAPI_MakeWire MW; +for (Standard_Integer i = theEdge.Lower(); +i <= theEdges.Upper(); i++) +MW.Add(TopoDS::Edge(theEdges(i)); +TopoDS_Wire W = MW; +~~~~~ + +The class can be constructed with a wire. A wire can also be added. In this case, all the edges of the wires are added. For example to merge two wires: + +~~~~~ +#include +#include + +TopoDS_Wire MergeWires (const TopoDS_Wire& W1, +const TopoDS_Wire& W2) +{ +BRepBuilderAPI_MakeWire MW(W1); +MW.Add(W2); +return MW; +} +~~~~~ + +*BRepBuilderAPI_MakeWire* class connects the edges to the wire. When a new edge is added if one of its vertices is shared with the wire it is considered as connected to the wire. If there is no shared vertex, the algorithm searches for a vertex of the edge and a vertex of the wire, which are at the same location (the tolerances of the vertices are used to test if they have the same location). If such a pair of vertices is found, the edge is copied with the vertex of the wire in place of the original vertex. All the vertices of the edge can be exchanged for vertices from the wire. If no connection is found the wire is considered to be disconnected. This is an error. + +BRepBuilderAPI_MakeWire class can return the last edge added to the wire (Edge method). This edge can be different from the original edge if it was copied. + +The Error method returns a term of the *BRepBuilderAPI_WireError* enumeration: +*WireDone* - no error occurred. +*EmptyWire* - no initialization of the algorithm, an empty constructor was used. +*DisconnectedWire* - the last added edge was not connected to the wire. +*NonManifoldWire* - the wire with some singularity. + +@subsubsection occt_modalg_3_1_7 Shell +The shell is a composite shape built not from a geometry, but by the assembly of faces. +Use *BRepBuilderAPI_MakeShell* class to build a Shell from a set of Faces. What may be important is that each face should have the required continuity. That is why an initial surface is broken up into faces. + +@subsubsection occt_modalg_3_1_8 Solid +The solid is a composite shape built not from a geometry, but by the assembly of shells. Use *BRepBuilderAPI_MakeSolid* class to build a Solid from a set of Shells. Its use is similar to the use of the MakeWire class: shells are added to the solid in the same way that edges are added to the wire in MakeWire. + + +@subsubsection occt_modalg_3_2 Modification Operators + +@subsubsection occt_modalg_3_2_1 Transformation +*BRepBuilderAPI_Transform* class can be used to apply a transformation to a shape (see class *gp_Trsf*). The methods have a boolean argument to copy or share the original shape, as long as the transformation allows (it is only possible for direct isometric transformations). By default, the original shape is shared. + +The following example deals with the rotation of shapes. + +~~~~~ + +TopoDS_Shape myShape1 = ...; +// The original shape 1 +TopoDS_Shape myShape2 = ...; +// The original shape2 +gp_Trsf T; +T.SetRotation(gp_Ax1(gp_Pnt(0.,0.,0.),gp_Vec(0.,0.,1.)), +2.*PI/5.); +BRepBuilderAPI_Transformation theTrsf(T); +theTrsf.Perform(myShape1); +TopoDS_Shape myNewShape1 = theTrsf.Shape() +theTrsf.Perform(myShape2,Standard_True); +// Here duplication is forced +TopoDS_Shape myNewShape2 = theTrsf.Shape() +~~~~~ + +@subsubsection occt_modalg_3_2_2 Duplication + +Use the BRepBuilderAPI_Copy class to duplicate a shape. A new shape is thus created. +In the following example, a solid is copied: + +~~~~~ +TopoDS Solid MySolid; +....// Creates a solid + +TopoDS_Solid myCopy = BRepBuilderAPI_Copy(mySolid); +~~~~~ + +@section occt_modalg_4 Construction of Primitives +@subsection occt_modalg_4_1 Making Primitives +@subsubsection occt_modalg_4_1_1 Box + +BRepPrimAPI_MakeBox class allows building a parallelepiped box. The result is either a Shell or a Solid. There are four ways to build a box: + +* From three dimensions dx,dy,dz. The box is parallel to the axes and extends for [0,dx] [0,dy] [0,dz]. +* From a point and three dimensions. The same as above but the point is the new origin. +* From two points, the box is parallel to the axes and extends on the intervals defined by the coordinates of the two points. +* From a system of axes (gp_Ax2) and three dimensions. Same as the first way but the box is parallel to the given system of axes. + +An error is raised if the box is flat in any dimension using the default precision. The following code shows how to create a box: +~~~~~ +TopoDS_Solid theBox = BRepPrimAPI_MakeBox(10.,20.,30.); +~~~~~ + +The four methods to build a box are shown in the figure: + +![](/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. + +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. + +![](/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. + +The particular constructions of these primitives are described, but they all have some common arguments, which are: + + * A system of coordinates, where the Z axis is the rotation axis.. + * An angle in the range [0,2*PI]. + * A vmin, vmax parameter range on the curve. + +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. + +![](/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: + + * Radius and height, to build a full cylinder. + * Radius, height and angle to build a portion of a cylinder. + +The following code builds the cylindrical face of the figure, which is a quarter of cylinder along the Y axis with the origin at X,Y,Z, a length of DY, and a radius R. + +~~~~~ + +Standard_Real X = 20, Y = 10, Z = 15, R = 10, DY = 30; +// Make the system of coordinates +gp_Ax2 axes = gp::ZOX(); +axes.Translate(gp_Vec(X,Y,Z)); +TopoDS_Face F = +BRepPrimAPI_MakeCylinder(axes,R,DY,PI/2.); +~~~~~ +![](/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: + + * 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. + +The following code builds the solid cone of the figure, which is located in the default system with radii R1 and R2 and height H. + +~~~~~ +Standard_Real R1 = 30, R2 = 10, H = 15; +TopoDS_Solid S = BRepPrimAPI_MakeCone(R1,R2,H); +~~~~~ + +![](/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: + + * From a radius - builds a full sphere. + * From a radius and an angle - builds a lune (digon). + * From a radius and two angles - builds a wraparound spherical segment between two latitudes. The angles a1, a2 must follow the relation: PI/2 <= a1 < a2 <= PI/2. + * From a radius and three angles - a combination of two previous methods builds a portion of spherical segment. + +The following code builds four spheres from a radius and three angles. + +~~~~~ +Standard_Real R = 30, ang = + PI/2, a1 = -PI/2.3, a2 = PI/4; +TopoDS_Solid S1 = BRepPrimAPI_MakeSphere(R); +TopoDS_Solid S2 = BRepPrimAPI_MakeSphere(R,ang); +TopoDS_Solid S3 = BRepPrimAPI_MakeSphere(R,a1,a2); +TopoDS_Solid S4 = BRepPrimAPI_MakeSphere(R,a1,a2,ang); +~~~~~ + +Note that we could equally well choose to create Shells instead of Solids. + +![](/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: + + * 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. + +![](/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. + +~~~~~ +Standard_Real R1 = 30, R2 = 10, ang = PI, a1 = 0, + a2 = PI/2; +TopoDS_Shell S1 = BRepPrimAPI_MakeTorus(R1,R2); +TopoDS_Shell S2 = BRepPrimAPI_MakeTorus(R1,R2,ang); +TopoDS_Shell S3 = BRepPrimAPI_MakeTorus(R1,R2,a1,a2); +TopoDS_Shell S4 = + BRepPrimAPI_MakeTorus(R1,R2,a1,a2,ang); +~~~~~ + +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. + +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: + + * From a curve, use the full curve and make a full rotation. + * From a curve and an angle of rotation. + * From a curve and two parameters to trim the curve. The two parameters must be growing and within the curve range. + * From a curve, two parameters, and an angle. The two parameters must be growing and within the curve range. + + +@subsection occt_modalg_4_2 Sweeping: Prism, Revolution and Pipe +@subsubsection occt_modalg_4_2_1 Sweeping + +Sweeps are the objects you obtain by sweeping a **profile** along a **path**. The profile can be of any topology. The path is usually a curve or a wire. The profile generates objects according to the following rules: + + * Vertices generate Edges + * Edges generate Faces. + * Wires generate Shells. + * Faces generate Solids. + * Shells generate Composite Solids + +It is forbidden to sweep Solids and Composite Solids. A Compound generates a Compound with the sweep of all its elements. + +![](/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 +* *BRepPrimAPI_MakeRevol* - produces a rotational sweep +* *BRepPrimAPI_MakePipe* - produces a general 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. +* 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 +. +~~~~~ +TopoDS_Face F = ..; // The swept face +gp_Dir direc(0,0,1); +Standard_Real l = 10; +// create a vector from the direction and the length +gp_Vec v = direc; +v *= l; +TopoDS_Solid P1 = BRepPrimAPI_MakePrism(F,v); +// finite +TopoDS_Solid P2 = BRepPrimAPI_MakePrism(F,direc); +// infinite +TopoDS_Solid P3 = BRepPrimAPI_MakePrism(F,direc,Standard_False); +// semi-infinite +~~~~~ + +![](/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 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 +gp_Ax1 axis(gp_Pnt(0,0,0),gp_Dir(0,0,1)); +Standard_Real ang = PI/3; +TopoDS_Solid R1 = BRepPrimAPI_MakeRevol(F,axis); +// Full revol +TopoDS_Solid R2 = BRepPrimAPI_MakeRevol(F,axis,ang); +~~~~~ + +![](/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 | + +BRepAlgoAPI_BooleanOperation class is the deferred root class for Boolean operations. + +![](/user_guides/modeling_algos/images/modeling_algos_image036.jpg "Boolean Operations") + +@subsection occt_modalg_5_1 Fuse + +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. + +~~~~~ +TopoDS_Shape A = ..., B = ...; +TopoDS_Shape S = BRepAlgoAPI_Common(A,B); +~~~~~ + +@subsection occt_modalg_5_3 Cut +BRepAlgoAPI_Cut performs the Cut operation. + +~~~~~ +TopoDS_Shape A = ..., B = ...; +TopoDS_Shape S = BRepAlgoAPI_Cut(A,B); +~~~~~ + +@subsection occt_modalg_5_4 Section + +BRepAlgoAPI_Section performs the section, described as a *TopoDS_Compound* made of *TopoDS_Edge*. + +![](/user_guides/modeling_algos/images/modeling_algos_image037.jpg "Section operation") + +~~~~~ +TopoDS_Shape A = ..., TopoDS_ShapeB = ...; +TopoDS_Shape S = BRepAlgoAPI_Section(A,B); +~~~~~ + +@section occt_modalg_6 Fillets and Chamfers +@subsection occt_modalg_6_1 Fillets +@subsection occt_modalg_6_1_1 Fillet on shape + +A fillet is a smooth face replacing a sharp edge. + +*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. + +![](/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 +---------------- + +~~~~~ +#include +#include +#include +#include +#include +#include + +TopoDS_Shape FilletedBox(const Standard_Real a, + const Standard_Real b, + const Standard_Real c, + const Standard_Real r) +{ + TopoDS_Solid Box = BRepPrimAPI_MakeBox(a,b,c); + BRepFilletAPI_MakeFillet MF(Box); + + // add all the edges to fillet + TopExp_Explorer ex(Box,TopAbs_EDGE); + while (ex.More()) + { + MF.Add(r,TopoDS::Edge(ex.Current())); + ex.Next(); + } + return MF.Shape(); + } +~~~~~ + +![](/user_guides/modeling_algos/images/modeling_algos_image039.jpg "Fillet with constant radius") + +Changing radius +--------------- + +~~~~~ +void CSampleTopologicalOperationsDoc::OnEvolvedblend1() +{ + TopoDS_Shape theBox = BRepPrimAPI_MakeBox(200,200,200); + + BRepFilletAPI_MakeFillet Rake(theBox); + ChFi3d_FilletShape FSh = ChFi3d_Rational; + Rake.SetFilletShape(FSh); + + TColgp_Array1OfPnt2d ParAndRad(1, 6); + ParAndRad(1).SetCoord(0., 10.); + ParAndRad(1).SetCoord(50., 20.); + ParAndRad(1).SetCoord(70., 20.); + ParAndRad(1).SetCoord(130., 60.); + ParAndRad(1).SetCoord(160., 30.); + ParAndRad(1).SetCoord(200., 20.); + + TopExp_Explorer ex(theBox,TopAbs_EDGE); + Rake.Add(ParAndRad, TopoDS::Edge(ex.Current())); + TopoDS_Shape evolvedBox = Rake.Shape(); +} +~~~~~ + +![](/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): + +~~~~~ +Add(dist, E, F) +Add(d1, d2, E, F) with d1 on the face F. +~~~~~ + +![](/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. +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. +Fillets and chamfers are calculated when addition is complete. + +If face F2 is created by 2D fillet and chamfer builder from face F1, the builder can be rebuilt (the builder recovers the status it had before deletion). To do so, use the following syntax: +~~~~~ +BRepFilletAPI_MakeFillet2d builder; +builder.Init(F1,F2); +~~~~~ + +Planar Fillet +------------- + +~~~~~ +#include “BRepPrimAPI_MakeBox.hxx” +#include “TopoDS_Shape.hxx” +#include “TopExp_Explorer.hxx” +#include “BRepFilletAPI_MakeFillet2d.hxx” +#include “TopoDS.hxx” +#include “TopoDS_Solid.hxx” + +TopoDS_Shape FilletFace(const Standard_Real a, + const Standard_Real b, + const Standard_Real c, + const Standard_Real r) + +{ + TopoDS_Solid Box = BRepPrimAPI_MakeBox (a,b,c); + TopExp_Explorer ex1(Box,TopAbs_FACE); + + const TopoDS_Face& F = TopoDS::Face(ex1.Current()); + BRepFilletAPI_MakeFillet2d MF(F); + TopExp_Explorer ex2(F, TopAbs_VERTEX); + while (ex2.More()) + { + MF.AddFillet(TopoDS::Vertex(ex2.Current()),r); + ex2.Next(); + } + // while... + return MF.Shape(); +} +~~~~~ + +@section occt_modalg_7 Offsets, Drafts, Pipes and Evolved shapes +@subsection occt_modalg_7_1 Shelling + +Shelling is used to offset given faces of a solid by a specific value. It rounds or intersects adjacent faces along its edges depending on the convexity of the edge. + +The constructor *BRepOffsetAPI_MakeThickSolid* shelling operator takes the solid, the list of faces to remove and an offset value as input. + +~~~~~ +TopoDS_Solid SolidInitial = ...; + +Standard_Real Of = ...; +TopTools_ListOfShape LCF; +TopoDS_Shape Result; +Standard_Real Tol = Precision::Confusion(); + +for (Standard_Integer i = 1 ;i <= n; i++) { + TopoDS_Face SF = ...; // a face from SolidInitial + LCF.Append(SF); +} + +Result = BRepOffsetAPI_MakeThickSolid (SolidInitial, + LCF, + Of, + Tol); +~~~~~ + +![](/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: + + * 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. + +The following code places a draft angle on several faces of a shape; the same direction, angle and neutral plane are used for each face: + +~~~~~ +TopoDS_Shape myShape = ... +// The original shape +TopTools_ListOfShape ListOfFace; +// Creation of the list of faces to be modified +... + +gp_Dir Direc(0.,0.,1.); +// Z direction +Standard_Real Angle = 5.*PI/180.; +// 5 degree angle +gp_Pln Neutral(gp_Pnt(0.,0.,5.), Direc); +// Neutral plane Z=5 +BRepOffsetAPI_DraftAngle theDraft(myShape); +TopTools_ListIteratorOfListOfShape itl; +for (itl.Initialize(ListOfFace); itl.More(); itl.Next()) { + theDraft.Add(TopoDS::Face(itl.Value()),Direc,Angle,Neutral); + if (!theDraft.AddDone()) { + // An error has occurred. The faulty face is given by // ProblematicShape + break; + } +} +if (!theDraft.AddDone()) { + // An error has occurred + TopoDS_Face guilty = theDraft.ProblematicShape(); + ... +} +theDraft.Build(); +if (!theDraft.IsDone()) { + // Problem encountered during reconstruction + ... +} +else { + TopoDS_Shape myResult = theDraft.Shape(); + ... +} +~~~~~ + +![](/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_Wire Spine = ...; +TopoDS_Shape Profile = ...; +TopoDS_Shape Pipe = BRepOffsetAPI_MakePipe(Spine,Profile); +~~~~~ + +![](/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: + +* The reference axes of the profile are the origin axes. +* The references axes of the profile are calculated as follows: + + the origin is given by the point on the spine which is the closest to the profile + + the X axis is given by the tangent to the spine at the point defined above + + the Z axis is the normal to the plane which contains the spine. + +~~~~~ +TopoDS_Face Spine = ...; +TopoDS_Wire Profile = ...; +TopoDS_Shape Evol = +BRepOffsetAPI_MakeEvolved(Spine,Profile); +~~~~~ + +@section occt_modalg_8 Sewing operators +@subsection occt_modalg_8_1 Sewing + +*BRepOffsetAPI_Sewing* class allows sewing TopoDS Shapes together along their common edges. The edges can be partially shared as in the following example. + +![](/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 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; +* *NbContiguousEdges* returns the number of contiguous edges within the given tolerance as defined above; +* *ContiguousEdge* takes an edge number as an argument and returns the *TopoDS* edge contiguous to another edge; +* *ContiguousEdgeCouple* gives all edges or sections, which are common to the edge with the number given above. +* *SectionToBoundary* finds the original edge on the original shape from the section. + +@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. + +@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. + +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), + * a direction, + * a Boolean indicating the type of operation (fusion=protrusion or cut=depression) on the basic shape, + * another Boolean indicating if the self-intersections have to be found (not used in every case). + +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. | + +**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. + +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_Face Fbase = ....; // a base of prism + +gp_Dir Extrusion (.,.,.); + +// An empty face is given as the sketch face + +BRepFeat_MakePrism thePrism(Sbase, Fbase, TopoDS_Face(), Extrusion, Standard_True, Standard_True); + +thePrism, Perform(100.); +if (thePrism.IsDone()) { + TopoDS_Shape theResult = thePrism; + ... +} +~~~~~ + +![](/user_guides/modeling_algos/images/modeling_algos_image047.jpg "Fusion with MakePrism") + +![](/user_guides/modeling_algos/images/modeling_algos_image048.jpg "Creating a prism between two faces with Perform(From, Until)") + +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 + * 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), + * an angle, + * a Boolean indicating the type of operation (fusion=protrusion or cut=depression) on the basic shape, + * another Boolean indicating if self-intersections have to be found (not used in every case). + +Evidently the input data for MakeDPrism are the same as for MakePrism except for a new parameter Angle and a missing parameter Direction: the direction of the prism generation is determined automatically as the normal to the base of the prism. +The semantics of draft prism feature creation is based on the construction of shapes: + * along a length + * up to a limiting face + * from a limiting face to a height. + +The shape defining construction of the draft prism feature can be either the supporting edge or the concerned area of a face. + +In case of the supporting edge, this contour can be attached to a face of the basis shape by binding. When the contour is bound to this face, the information that the contour will slide on the face becomes available to the relevant class methods. +In case of the concerned area of a face, it is possible to cut it out and move it to a different height, which will define the limiting face of a protrusion or depression direction . + +The *Perform* methods are the same as for *MakePrism*. + +~~~~~ +TopoDS_Shape S = BRepPrimAPI_MakeBox(400.,250.,300.); +TopExp_Explorer Ex; +Ex.Init(S,TopAbs_FACE); +Ex.Next(); +Ex.Next(); +Ex.Next(); +Ex.Next(); +Ex.Next(); +TopoDS_Face F = TopoDS::Face(Ex.Current()); +Handle(Geom_Surface) surf = BRep_Tool::Surface(F); +gp_Circ2d +c(gp_Ax2d(gp_Pnt2d(200.,130.),gp_Dir2d(1.,0.)),50.); +BRepBuilderAPI_MakeWire MW; +Handle(Geom2d_Curve) aline = new Geom2d_Circle(c); +MW.Add(BRepBuilderAPI_MakeEdge(aline,surf,0.,PI)); +MW.Add(BRepBuilderAPI_MakeEdge(aline,surf,PI,2.*PI)); +BRepBuilderAPI_MakeFace MKF; +MKF.Init(surf,Standard_False); +MKF.Add(MW.Wire()); +TopoDS_Face FP = MKF.Face(); +BRepLib::BuildCurves3d(FP); +BRepFeat_MakeDPrism MKDP (S,FP,F,10*PI180,Standard_True, + Standard_True); +MKDP.Perform(200); +TopoDS_Shape res1 = MKDP.Shape(); +~~~~~ + +![](/user_guides/modeling_algos/images/modeling_algos_image049.jpg "A tapered prism") + +MakeRevol +--------- +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,) + * the base of the revolution, + * 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), + * an axis of revolution, + * a boolean indicating the type of operation (fusion=protrusion or cut=depression) on 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. + + +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_Face Frevol = ....; // a base of prism +TopoDS_Face FUntil = ....; // face limiting the revol + +gp_Dir RevolDir (.,.,.); +gp_Ax1 RevolAx(gp_Pnt(.,.,.), RevolDir); + +// An empty face is given as the sketch face + +BRepFeat_MakeRevol theRevol(Sbase, Frevol, TopoDS_Face(), RevolAx, Standard_True, Standard_True); + +theRevol.Perform(FUntil); +if (theRevol.IsDone()) { + TopoDS_Shape theResult = theRevol; + ... +} +~~~~~ + +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) + * 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), + * a spine wire + * a Boolean indicating the type of operation (fusion=protrusion or cut=depression) on the basic shape, + * another Boolean indicating if self-intersections have to be found (not used in every case). + +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 | + +~~~~~ +TopoDS_Shape S = BRepPrimAPI_MakeBox(400.,250.,300.); +TopExp_Explorer Ex; +Ex.Init(S,TopAbs_FACE); +Ex.Next(); +Ex.Next(); +TopoDS_Face F1 = TopoDS::Face(Ex.Current()); +Handle(Geom_Surface) surf = BRep_Tool::Surface(F1); +BRepBuilderAPI_MakeWire MW1; +gp_Pnt2d p1,p2; +p1 = gp_Pnt2d(100.,100.); +p2 = gp_Pnt2d(200.,100.); +Handle(Geom2d_Line) aline = GCE2d_MakeLine(p1,p2).Value(); + +MW1.Add(BRepBuilderAPI_MakeEdge(aline,surf,0.,p1.Distance(p2))); +p1 = p2; +p2 = gp_Pnt2d(150.,200.); +aline = GCE2d_MakeLine(p1,p2).Value(); + +MW1.Add(BRepBuilderAPI_MakeEdge(aline,surf,0.,p1.Distance(p2))); +p1 = p2; +p2 = gp_Pnt2d(100.,100.); +aline = GCE2d_MakeLine(p1,p2).Value(); + +MW1.Add(BRepBuilderAPI_MakeEdge(aline,surf,0.,p1.Distance(p2))); +BRepBuilderAPI_MakeFace MKF1; +MKF1.Init(surf,Standard_False); +MKF1.Add(MW1.Wire()); +TopoDS_Face FP = MKF1.Face(); +BRepLib::BuildCurves3d(FP); +TColgp_Array1OfPnt CurvePoles(1,3); +gp_Pnt pt = gp_Pnt(150.,0.,150.); +CurvePoles(1) = pt; +pt = gp_Pnt(200.,100.,150.); +CurvePoles(2) = pt; +pt = gp_Pnt(150.,200.,150.); +CurvePoles(3) = pt; +Handle(Geom_BezierCurve) curve = new Geom_BezierCurve +(CurvePoles); +TopoDS_Edge E = BRepBuilderAPI_MakeEdge(curve); +TopoDS_Wire W = BRepBuilderAPI_MakeWire(E); +BRepFeat_MakePipe MKPipe (S,FP,F1,W,Standard_False, +Standard_True); +MKPipe.Perform(); +TopoDS_Shape res1 = MKPipe.Shape(); +~~~~~ + +![](/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. +Here they include extrusion: + * to a limiting face of the basis shape; + * to or from a limiting plane; + * to a height. +A class object is created or initialized from + * a shape (basic shape); + * a wire (base of rib or groove); + * a plane (plane of the wire); + * direction1 (a vector along which thickness will be built up); + * direction2 (vector opposite to the previous one along which thickness will be built up, may be null); + * 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). + +~~~~~ +BRepBuilderAPI_MakeWire mkw; +gp_Pnt p1 = gp_Pnt(0.,0.,0.); +gp_Pnt p2 = gp_Pnt(200.,0.,0.); +mkw.Add(BRepBuilderAPI_MakeEdge(p1,p2)); +p1 = p2; +p2 = gp_Pnt(200.,0.,50.); +mkw.Add(BRepBuilderAPI_MakeEdge(p1,p2)); +p1 = p2; +p2 = gp_Pnt(50.,0.,50.); +mkw.Add(BRepBuilderAPI_MakeEdge(p1,p2)); +p1 = p2; +p2 = gp_Pnt(50.,0.,200.); +mkw.Add(BRepBuilderAPI_MakeEdge(p1,p2)); +p1 = p2; +p2 = gp_Pnt(0.,0.,200.); +mkw.Add(BRepBuilderAPI_MakeEdge(p1,p2)); +p1 = p2; +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.))); +TopoDS_Wire W = BRepBuilderAPI_MakeWire(BRepBuilderAPI_MakeEdge(gp_Pnt + (50.,45.,100.), +gp_Pnt(100.,45.,50.))); +Handle(Geom_Plane) aplane = + new Geom_Plane(gp_Pnt(0.,45.,0.), gp_Vec(0.,1.,0.)); +BRepFeat_MakeLinearForm aform(S, W, aplane, gp_Dir + (0.,5.,0.), gp_Dir(0.,-3.,0.), 1, Standard_True); +aform.Perform(); +TopoDS_Shape res = aform.Shape(); +~~~~~ + +![](/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 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. + +**Note** 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 +TopoDS_Shape Sglued = ...; // the glued shape + +TopTools_ListOfShape Lfbase; +TopTools_ListOfShape Lfglued; +// Determination of the glued faces +... + +BRepFeat_Gluer theGlue(Sglue, Sbase); +TopTools_ListIteratorOfListOfShape itlb(Lfbase); +TopTools_ListIteratorOfListOfShape itlg(Lfglued); +for (; itlb.More(); itlb.Next(), itlg(Next()) { +const TopoDS_Face& f1 = TopoDS::Face(itlg.Value()); +const TopoDS_Face& f2 = TopoDS::Face(itlb.Value()); +theGlue.Bind(f1,f2); +// for example, use the class FindEdges from LocOpe to +// determine coincident edges +LocOpe_FindEdge fined(f1,f2); +for (fined.InitIterator(); fined.More(); fined.Next()) { +theGlue.Bind(fined.EdgeFrom(),fined.EdgeTo()); +} +} +theGlue.Build(); +if (theGlue.IsDone() { +TopoDS_Shape theResult = theGlue; +... +} +~~~~~ + +@subsubsection occt_modalg_9_1_3 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. + +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). | + +**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. + +~~~~~ +TopoDS_Shape Sbase = ...; // basic shape +TopoDS_Face Fsplit = ...; // face of Sbase +TopoDS_Wire Wsplit = ...; // new wire contained in Fsplit +BRepFeat_SplitShape Spls(Sbase); +Spls.Add(Wsplit, Fsplit); +TopoDS_Shape theResult = Spls; +... +~~~~~ + + +@section occt_modalg_10 Hidden Line Removal + +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. + +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. + +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. + +However, there some restrictions in HLR use: + * Points are not processed; + * Z-clipping planes are not used; + * Infinite faces or lines are not processed. + + +![](/user_guides/modeling_algos/images/modeling_algos_image052.jpg "Sharp, smooth and sewn edges in a simple screw shape") + +![](/user_guides/modeling_algos/images/modeling_algos_image053.jpg "Outline edges and isoparameters in the same shape") + +![](/user_guides/modeling_algos/images/modeling_algos_image054.jpg "A simple screw shape seen with shading") + +![](/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 +-------------- +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. + +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. + +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 + +HLRBRep_Algo +------------ +~~~~~ +// Build The algorithm object +myAlgo = new HLRBRep_Algo(); + +// Add Shapes into the algorithm +TopTools_ListIteratorOfListOfShape anIterator(myListOfShape); +for (;anIterator.More();anIterator.Next()) +myAlgo-Add(anIterator.Value(),myNbIsos); + +// Set The Projector (myProjector is a +HLRAlgo_Projector) +myAlgo-Projector(myProjector); + +// Build HLR +myAlgo->Update(); + +// Set The Edge Status +myAlgo->Hide(); + +// Build the extraction object : +HLRBRep_HLRToShape aHLRToShape(myAlgo); + +// extract the results : +TopoDS_Shape VCompound           = aHLRToShape.VCompound(); +TopoDS_Shape Rg1LineVCompound                            = +aHLRToShape.Rg1LineVCompound(); +TopoDS_Shape RgNLineVCompound                            = +aHLRToShape.RgNLineVCompound(); +TopoDS_Shape OutLineVCompound                            = +aHLRToShape.OutLineVCompound(); +TopoDS_Shape IsoLineVCompound                            = +aHLRToShape.IsoLineVCompound(); +TopoDS_Shape HCompound           = aHLRToShape.HCompound(); +TopoDS_Shape Rg1LineHCompound                            = +aHLRToShape.Rg1LineHCompound(); +TopoDS_Shape RgNLineHCompound                            = +aHLRToShape.RgNLineHCompound(); +TopoDS_Shape OutLineHCompound                            = +aHLRToShape.OutLineHCompound(); +TopoDS_Shape IsoLineHCompound                            = +aHLRToShape.IsoLineHCompound(); +~~~~~ + +HLRBRep_PolyAlgo +---------------- + +~~~~~ + +// Build The algorithm object +myPolyAlgo = new HLRBRep_PolyAlgo(); + +// Add Shapes into the algorithm +TopTools_ListIteratorOfListOfShape +anIterator(myListOfShape); +for (;anIterator.More();anIterator.Next()) +myPolyAlgo-Load(anIterator.Value()); + +// Set The Projector (myProjector is a +HLRAlgo_Projector) +myPolyAlgo->Projector(myProjector); + +// Build HLR +myPolyAlgo->Update(); + +// Build the extraction object : +HLRBRep_PolyHLRToShape aPolyHLRToShape; +aPolyHLRToShape.Update(myPolyAlgo); + +// extract the results : +TopoDS_Shape VCompound = +aPolyHLRToShape.VCompound(); +TopoDS_Shape Rg1LineVCompound = +aPolyHLRToShape.Rg1LineVCompound(); +TopoDS_Shape RgNLineVCompound = +aPolyHLRToShape.RgNLineVCompound(); +TopoDS_Shape OutLineVCompound = +aPolyHLRToShape.OutLineVCompound(); +TopoDS_Shape HCompound = +aPolyHLRToShape.HCompound(); +TopoDS_Shape Rg1LineHCompound = +aPolyHLRToShape.Rg1LineHCompound(); +TopoDS_Shape RgNLineHCompound = +aPolyHLRToShape.RgNLineHCompound(); +TopoDS_Shape OutLineHCompound = +aPolyHLRToShape.OutLineHCompound(); +~~~~~ + +@section occt_modalg_10_4 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. + +~~~~~ +Standard_Real radius=10. ; +Standard_Real height=25. ; +BRepBuilderAPI_MakeCylinder myCyl (radius, height) ; +TopoDS_Shape myShape = myCyl.Shape() ; +Standard_Real Deflection = 0.01 ; +BRepMesh::Mesh (myShape, Deflection); +~~~~~ + +Meshing covers a shape with a triangular mesh. Other than hidden line removal, you can use meshing to transfer the shape to another tool: a manufacturing tool, a shading algorithm, a finite element algorithm, or a collision algorithm, for example. + +You can obtain information on the shape by first exploring it. To then access triangulation of a face in the shape, use *BRepTool::Triangulation*. To access a polygon which is the approximation of an edge of the face, use *BRepTool::PolygonOnTriangulation*. \ No newline at end of file diff --git a/dox/user_guides/modeling_data/images/modeling_data_image001.jpg b/dox/user_guides/modeling_data/images/modeling_data_image001.jpg new file mode 100644 index 0000000000..b81c818e93 Binary files /dev/null and b/dox/user_guides/modeling_data/images/modeling_data_image001.jpg differ diff --git a/dox/user_guides/modeling_data/images/modeling_data_image002.jpg b/dox/user_guides/modeling_data/images/modeling_data_image002.jpg new file mode 100644 index 0000000000..5f87a335b2 Binary files /dev/null and b/dox/user_guides/modeling_data/images/modeling_data_image002.jpg differ diff --git a/dox/user_guides/modeling_data/images/modeling_data_image003.jpg b/dox/user_guides/modeling_data/images/modeling_data_image003.jpg new file mode 100644 index 0000000000..f57e759544 Binary files /dev/null and b/dox/user_guides/modeling_data/images/modeling_data_image003.jpg differ diff --git a/dox/user_guides/modeling_data/images/modeling_data_image004.jpg b/dox/user_guides/modeling_data/images/modeling_data_image004.jpg new file mode 100644 index 0000000000..9dbc7f8aed Binary files /dev/null and b/dox/user_guides/modeling_data/images/modeling_data_image004.jpg differ diff --git a/dox/user_guides/modeling_data/images/modeling_data_image005.jpg b/dox/user_guides/modeling_data/images/modeling_data_image005.jpg new file mode 100644 index 0000000000..701c2f1e7a Binary files /dev/null and b/dox/user_guides/modeling_data/images/modeling_data_image005.jpg differ diff --git a/dox/user_guides/modeling_data/images/modeling_data_image006.jpg b/dox/user_guides/modeling_data/images/modeling_data_image006.jpg new file mode 100644 index 0000000000..d40127ab5a Binary files /dev/null and b/dox/user_guides/modeling_data/images/modeling_data_image006.jpg differ diff --git a/dox/user_guides/modeling_data/images/modeling_data_image007.jpg b/dox/user_guides/modeling_data/images/modeling_data_image007.jpg new file mode 100644 index 0000000000..563111efd4 Binary files /dev/null and b/dox/user_guides/modeling_data/images/modeling_data_image007.jpg differ diff --git a/dox/user_guides/modeling_data/images/modeling_data_image008.jpg b/dox/user_guides/modeling_data/images/modeling_data_image008.jpg new file mode 100644 index 0000000000..9abea4d5b0 Binary files /dev/null and b/dox/user_guides/modeling_data/images/modeling_data_image008.jpg differ diff --git a/dox/user_guides/modeling_data/images/modeling_data_image009.jpg b/dox/user_guides/modeling_data/images/modeling_data_image009.jpg new file mode 100644 index 0000000000..0af5124e1d Binary files /dev/null and b/dox/user_guides/modeling_data/images/modeling_data_image009.jpg differ diff --git a/dox/user_guides/modeling_data/images/modeling_data_image010.jpg b/dox/user_guides/modeling_data/images/modeling_data_image010.jpg new file mode 100644 index 0000000000..44fc3b5cbe Binary files /dev/null and b/dox/user_guides/modeling_data/images/modeling_data_image010.jpg differ diff --git a/dox/user_guides/modeling_data/images/modeling_data_image011.jpg b/dox/user_guides/modeling_data/images/modeling_data_image011.jpg new file mode 100644 index 0000000000..5650674b6a Binary files /dev/null and b/dox/user_guides/modeling_data/images/modeling_data_image011.jpg differ diff --git a/dox/user_guides/modeling_data/images/modeling_data_image012.jpg b/dox/user_guides/modeling_data/images/modeling_data_image012.jpg new file mode 100644 index 0000000000..29ab381c7f Binary files /dev/null and b/dox/user_guides/modeling_data/images/modeling_data_image012.jpg differ diff --git a/dox/user_guides/modeling_data/images/modeling_data_image013.jpg b/dox/user_guides/modeling_data/images/modeling_data_image013.jpg new file mode 100644 index 0000000000..66f3029ebf Binary files /dev/null and b/dox/user_guides/modeling_data/images/modeling_data_image013.jpg differ diff --git a/dox/user_guides/modeling_data/images/modeling_data_image014.jpg b/dox/user_guides/modeling_data/images/modeling_data_image014.jpg new file mode 100644 index 0000000000..9c751d8c11 Binary files /dev/null and b/dox/user_guides/modeling_data/images/modeling_data_image014.jpg differ diff --git a/dox/user_guides/modeling_data/modeling_data.md b/dox/user_guides/modeling_data/modeling_data.md new file mode 100644 index 0000000000..6cc525e977 --- /dev/null +++ b/dox/user_guides/modeling_data/modeling_data.md @@ -0,0 +1,921 @@ +Modeling Data {#user_guides__modeling_data} +======================== + +@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 www.opencascade.org/support/training/     + + + +@section occt_modat_1 Geometry Utilities + +Geometry Utilities provide the following services: + * Creation of shapes by interpolation and approximation + * Direct construction of shapes + * Conversion of curves and surfaces to Bspline curves and surfaces + * Computation of the coordinates of points on 2D and 3D curves + * Calculation of extrema between shapes. + +@subsection occt_modat_1_1 Interpolations and Approximations + +In modeling, it is often required to approximate or interpolate points into curves and surfaces. In interpolation, the process is complete when the curve or surface passes through all the points; in approximation, when it is as close to these points as possible. This component provides both high and low level services to approximate or interpolate points into curves and surfaces. The lower level services allow performing parallel approximation of groups of points into groups of Bezier or B-spline curves. + +@subsubsection occt_modat_1_1_1 Analysis of a set of points + +The class *PEquation* from *GProp* package allows analyzng a collection or cloud of points and verifying if they are coincident, collinear or coplanar within a given precision. If they are, the algorithm computes the mean point, the mean line or the mean plane of the points. If they are not, the algorithm computes the minimal box, which includes all the points. + +@subsubsection occt_modat_1_1_2 Basic Interpolation and Approximation + +Packages *Geom2dAPI* and *GeomAPI* provide simple methods for approximation and interpolation with minimal programming + +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 +---------------- +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. + +![](/user_guides/modeling_data/images/modeling_data_image003.jpg "Approximation of a BSpline from scattered points") + +This class may be instantiated as follows: +~~~~~ +GeomAPI_Interpolate Interp(Points); +~~~~~ + +From this object, the BSpline curve may be requested as follows: +~~~~~ +Handle(Geom_BSplineCurve) C = Interp.Curve(); +~~~~~ + +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 +--------------- +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: + +~~~~~ +GeomAPI_PointsToBSpline +Approx(Points,DegMin,DegMax,Continuity, Tol); +~~~~~ + +From this object, the BSpline curve may be requested as follows: +~~~~~ +Handle(Geom_BSplineCurve) K = Approx.Curve(); +~~~~~ + +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 +------------------------------------------- +*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. + +![](/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. + * Defined as a group: *Pn*, *Qn*, *Rn,* ... *Sn* form a MultipointConstraint. They possess the same passage, tangency and curvature constraints. + * *P1*, *P2*, ... *Pn*, or the *Q*, *R*, ... or *S* series represent the lines to be approximated. + +* Definition of a set of point constraints: +The class **MultiPointConstraint** allows defining a multiple point constraint and computing the approximation of sets of points to several curves. + +* Computation of an approximation of a Bezier curve from a set of points: +The class *Compute* allows making an approximation of a set of points to a Bezier curve + +* Computation of an approximation of a BSpline curve from a set of points: +The class **BSplineCompute** allows making an approximation of a set of points to a BSpline curve. + +* 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 +---------------------------------------------------- + +*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. + +The algorithms used include: +- the least squares method +- a search for the best approximation within a given tolerance value. + +The following low-level services are provided: + +* Association of an index to an object: +The class *ConstraintCouple* allows you associating an index to an object to compute faired curves using *AppDef_TheVariational*. + +* Definition of a set of approximations of Bezier curves: +The class *MultiCurve* allows defining the approximation of a multi-line made up of multiple Bezier curves. + +* Definition of a set of approximations of BSpline curves: +The class *MultiBSpCurve* allows defining the approximation of a multi-line made up of multiple BSpline curves. + +* Definition of points making up a set of point constraints +The class *MultiPoint* allows defining groups of 2D or 3D points making up a multi-line. + +@subsection occt_modat_1_2 Direct Construction + +Direct Construction methods from *gce*, *GC* and *GCE2d* packages provide simplified algorithms to build elementary geometric entities such as lines, circles and curves. They complement the reference definitions provided by the *gp*, *Geom* and *Geom2d *packages. + +For example, to construct a circle from a point and a radius using the *gp* package, it is necessary to construct axis *Ax2d* before creating the circle. If *gce* package is used, and *Ox* is taken for the axis, it is possible to create a circle directly from a point and a radius. + +@subsubsection occt_modat_1_2_1 Non-persistent entities + +The following algorithms used to build entities from non-persistent *gp* entities are provided by *gce* package. +- 2D line parallel to another at a distance, +- 2D line parallel to another passing through a point, +- 2D circle passing through two points, +- 2D circle parallel to another at a distance, +- 2D circle parallel to another passing through a point, +- 2D circle passing through three points, +- 2D circle from a center and a radius, +- 2D hyperbola from five points, +- 2D hyperbola from a center and two apexes, +- 2D ellipse from five points, +- 2D ellipse from a center and two apexes, +- 2D parabola from three points, +- 2D parabola from a center and an apex, +- line parallel to another passing through a point, +- line passing through two points, +- circle coaxial to another passing through a point, +- circle coaxial to another at a given distance, +- circle passing through three points, +- circle with its center, radius, and normal to the plane, +- circle with its axis (center + normal), +- hyperbola with its center and two apexes, +- ellipse with its center and two apexes, +- plane passing through three points, +- plane from its normal, +- plane parallel to another plane at a given distance, +- plane parallel to another passing through a point, +- plane from an array of points, +- cylinder from a given axis and a given radius, +- cylinder from a circular base, +- cylinder from three points, +- cylinder parallel to another cylinder at a given distance, +- cylinder parallel to another cylinder passing through a point, +- cone from four points, +- cone from a given axis and two passing points, +- cone from two points (an axis) and two radii, +- cone parallel to another at a given distance, +- cone parallel to another passing through a point, +- all transformations (rotations, translations, mirrors,scaling transformations, etc.). + +Each class from *gp* package, such as *Circ, Circ2d, Mirror, Mirror2d*, etc., has the corresponding *MakeCirc, MakeCirc2d, MakeMirror, MakeMirror2d*, etc. class from *gce* package. + +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; + ... + //Initialization of Point1 and Point2 + gce_MakeLin2d L = gce_MakeLin2d(Point1,Point2); + if (L.Status() == gce_Done() ){ + 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 ** + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +gp_Lin2d l = gce_MakeLin2d(Point1,Point2); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@subsubsection occt_modat_1_2_2 Persistent entities + +*GC* and *GCE2d* packages provides an implementation of algorithms used to build entities from *Geom* and *Geom2D* packages. They implement the same algorithms as the *gce* package but create **persistent** entities, and also contain algorithms for trimmed surfaces and curves. The following algorithms are available: +- arc of a circle trimmed by two points, +- arc of a circle trimmed by two parameters, +- arc of a circle trimmed by one point and one parameter, +- arc of an ellipse from an ellipse trimmed by two points, +- arc of an ellipse from an ellipse trimmed by two parameters, +- arc of an ellipse from an ellipse trimmed by one point and one parameter, +- arc of a parabola from a parabola trimmed by two points, +- arc of a parabola from a parabola trimmed by two parameters, +- arc of a parabola from a parabola trimmed by one point and one parameter, +- arc of a hyperbola from a hyperbola trimmed by two points, +- arc of a hyperbola from a hyperbola trimmed by two parameters, +- arc of a hyperbola from a hyperbola trimmed by one point and one parameter, +- segment of a line from two points, +- segment of a line from two parameters, +- segment of a line from one point and one parameter, +- trimmed cylinder from a circular base and a height, +- trimmed cylinder from three points, +- trimmed cylinder from an axis, a radius, and a height, +- trimmed cone from four points, +- trimmed cone from two points (an axis) and a radius, +- trimmed cone from two coaxial circles. + +Each class from *GCE2d* package, such as *Circle, Ellipse, Mirror*, etc., has the corresponding *MakeCircle, MakeEllipse, MakeMirror*, etc. class from *Geom2d* package. +Besides, the class *MakeArcOfCircle* returns an object of type *TrimmedCurve* from *Geom2d*. + +Each class from *GC* package, such as *Circle, Ellipse, Mirror*, etc., has the corresponding *MakeCircle, MakeEllipse, MakeMirror*, etc. class from *Geom* package. +The following classes return objects of type *TrimmedCurve* from *Geom*: +- *MakeArcOfCircle* +- *MakeArcOfEllipse* +- *MakeArcOfHyperbola* +- *MakeArcOfParabola* +- *MakeSegment* + +@subsection occt_modat_1_3 Conversion to and from BSplines + +The following algorithms to convert geometric curves or surfaces into their BSpline or Bezier equivalents are provided by *GeomConvert*, *Geom2dConvert* and *Convert* packages: +- Conversion of a conic into a rational BSpline. +- Conversion of an elementary surface into a rational Bspline. +- Conversion of a BSpline or Bezier curve into two or more Bezier curves or surfaces. +- Conversion of a BSpline curve or surface into two or more BSplinecurves or surfaces with constraints on continuity. +- Conversion of a set of joining Bezier curves into a BSplinecurve. +- Conversion of a polynomial representation into a BSpline curve. + +@subsection occt_modat_1_4 Points on Curves + +The following characteristic points exist on parameterized curves in 3d space: +- points equally spaced on a curve, +- points distributed along a curve with equal chords, +- a point at a given distance from another point on a curve. + +*GCPnts* package provides algorithms to calculate such points: +- *AbscissaPoint* calculates a point on a curve at a given distance from another point on the curve. +- *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. +----------------------------- + +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:** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + Handle(Geom2d_Curve) mycurve = ... ; + Geom2dAdaptor_Curve C (mycurve) ; +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**case 3D:** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + Handle(Geom_Curve) mycurve = ... ; + GeomAdaptor_Curve C (mycurve) ; +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The algorithm is then constructed with this object: + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + GCPnts_UniformDeflection myAlgo () ; + Standard_Real Deflection = ... ; + myAlgo.Initialize ( C , Deflection ) ; + if ( myAlgo.IsDone() ) + { + Standard_Integer nbr = myAlgo.NbPoints() ; + Standard_Real param ; +   for ( Standard_Integer i = 1 ; i = nbr ; i++ ) + { + param = myAlgo.Parameter (i) ; + ... + } + } +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +@subsection occt_modat_1_5 Extrema + +The classes to calculate the minimum distance between points, curves, and surfaces in 2d and 3d are provided by *GeomAPI* and *Geom2dAPI* packages. + +These packages calculate the extrema of distance between: +- point and a curve, +- point and a surface, +- two curves, +- a curve and a surface, +- two surfaces. + +@subsubsection occt_modat_1_5_1 Extrema between Curves + +The *Geom2dAPI_ExtremaCurveCurve* class allows calculation of all extrema between two 2D geometric curves. Extrema are the lengths of the segments orthogonal to two curves. + +The *GeomAPI_ExtremaCurveCurve* class allows calculation of all extrema between two 3D geometric curves. Extrema are the lengths of the segments orthogonal to two curves. + +@subsubsection occt_modat_1_5_2 Extrema between Curve and Surface + +The *GeomAPI_ExtremaCurveSurface* class allows calculation of all extrema between a 3D curve and a surface. Extrema are the lengths of the segments orthogonal to the curve and the surface. + +@subsubsection occt_modat_1_5_3 Extrema between Surfaces + +The *GeomAPI_ExtremaSurfaceSurface* class allows calculation of all extrema between two surfaces. Extrema are the lengths of the segments orthogonal to two surfaces. + +@section occt_modat_2 2D Geometry + +*Geom2d* package defines geometric objects in 2dspace. All geometric entities are STEP processed. The objects are non-persistent and are handled by reference. The following objects are available: +- point, +- Cartesian point, +- vector, +- direction, +- vector with magnitude, +- axis, +- curve, +- line, +- conic: circle, ellipse, hyperbola, pparabola, +- rounded curve: trimmed curve, NURBS curve, Bezier curve. +- offset curve + +Before creating a geometric object, it is necessary to decide how the object is handled. +The objects provided by *Geom2d* package are handled by reference rather than by value. Copying an instance copies the handle, not the object, so that a change to one instance is reflected in each occurrence of it. +If a set of object instances is needed rather than a single object instance, *TColGeom2d* package can be used. This package provides standard and frequently used instantiations of one-dimensional arrays and sequences for curves from *Geom2d* package. All objects are available in two versions: +- handled by reference and +- handled by value. + +@section occt_modat_3 3D Geometry + +The *Geom* package defines geometric objects in 3d space and contains all basic geometric transformations, such as identity, rotation, translation, mirroring, scale transformations, combinations of transformations, etc. as well as special functions depending on the reference definition of the geometric object (e.g. addition of a control point on a B-Spline curve,modification of a curve, etc.). All geometrical entities are STEP processed. The following non-persistent and reference-handled objects are available: +- Point +- Cartesian point +- Vector +- Direction +- Vector with magnitude +- Axis +- Curve +- Line +- Conic: circle, ellipse, hyperbola, parabola +- Offset curve +- Elementary surface: plane, cylinder, cone, sphere, torus +- Bounded curve: trimmed curve, NURBS curve, Bezier curve +- Bounded surface: rectangular trimmed surface, NURBS surface,Bezier surface +- Swept surface: surface of linear extrusion, surface of revolution +- Offset surface. + +If a set of object instances is needed rather than a single object instance, *TColGeom* package can be used. This package provides instantiations of one- and two-dimensional arrays and sequences for curves from *Geom* package. All objects are available in two versions: +- handled by reference and +- handled by value. + +@subsection occt_modat_4 Local Properties of Curves and Surfaces + +Packages **GeomLProp**, **Geom2dLProp** provide algorithms calculating the local properties of curves and surfaces + +A curve (for one parameter) has the following local properties: +- Point +- Derivative +- Tangent +- Normal +- Curvature +- Center of curvature. + +A surface (for two parameters U and V) has the following local properties: +- point +- derivative for U and V) +- tangent line (for U and V) +- normal +- max curvature +- min curvature +- main directions of curvature +- mean curvature +- Gaussian curvature + +The following methods are available: +* *CLProps* - calculates the local properties of a curve (tangency, curvature,normal); +* *CurAndInf2d* - calculates the maximum and minimum curvatures and the inflection points of 2d curves; +* *SLProps* - calculates the local properties of a surface (tangency, the normal and curvature). +* *Continuity* - calculates regularity at the junction of two curves. + +Note that the B-spline curve and surface are accepted but they are not cut into pieces of the desired continuity. It is the global continuity, which is seen. + + +@section occt_modat_5 Topology + +Open CASCADE Technology Topology allows accessing and manipulating objects data without dealing with their 2D or 3D representations. Whereas OCCT Geometry provides a description of objects in terms of coordinates or parametric values, Topology describes data structures of objects in parametric space. These descriptions use location in and restriction of parts of this space. + +To provide its descriptions, OCCT abstract topology offers the following services: +- Keeping track of Location of shapes +- Naming shapes, sub-shapes, their orientations and states +- Manipulating shapes and sub-shapes +- Exploring topological data structures +- Using lists and maps of shapes + + +@subsection occt_modat_5_1 Shape Location + +A local coordinate system can be viewed as either of the following: +- A right-handed trihedron with an origin and three orthonormal vectors. The **gp_Ax2** package corresponds to this definition. +- A transformation of a +1 determinant, allowing the transformation of coordinates between local and global references frames. This corresponds to the **gp_Trsf**. + +*TopLoc* package distinguishes two notions: +- *TopLoc_Datum3D* class provides the elementary reference coordinate, represented by a right-handed orthonormal system of axes or by a right-handed unitary transformation. +- *TopLoc_Location* class provides the composite reference coordinate made from elementary ones. It is a marker composed of a chain of references to elementary markers. The resulting cumulative transformation is stored in order to avoid recalculating the sum of the transformations for the whole list. + +![](/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. + +For example, consider three elementary coordinates: +R1, R2, R3 +The composite coordinates are: +C1 = R1 * R2, +C2 = R2 * R3 +C3 = C1 * R3 +C4 = R1 * C2 + +**NOTE** C3 and C4 are equal because they are both R1 * R2 * R3. + +The TopLoc package is chiefly targeted at the topological data structure, but it can be used for other purposes. + +Change of coordinates +--------------------- + +*TopLoc_Datum3D* class represents a change of elementary coordinates. Such changes must be shared so this class inherits from *MMgt_TShared*. The coordinate is represented by a transformation *gp_Trsfpackage*. This transformation has no scaling factor. + + +@subsection occt_modat_5_2 Naming shapes, sub-shapes, their orientation and state + +The **TopAbs** package provides general enumerations describing the basic concepts of topology and methods to handle these enumerations. It contains no classes. This package has been separated from the rest of the topology because the notions it contains are sufficiently general to be used by all topological tools. This avoids redefinition of enumerations by remaining independent of modeling resources. The TopAbs package defines three notions: +- Topological type (TopAbs_ShapeEnum) +- Orietation (TopAbs_Orientation) +- StateTopAbs_State) + + +@subsubsection occt_modat_5_2_1 Topological types + +TopAbs contains the *TopAbs_ShapeEnum* enumeration,which lists the different topological types: +- COMPOUND - a group of any type of topological objects. +- COMPSOLID - a composite solid is a set of solids connected by their faces. It expands the notions of WIRE and SHELL to solids. +- SOLID - a part of space limited by shells. It is three dimensional. +- SHELL - a set of faces connected by their edges. A shell can be open or closed. +- FACE - in 2D it is a part of a plane; in 3D it is a part of a surface. Its geometry is constrained (trimmed) by contours. It is two dimensional. +- WIRE - a set of edges connected by their vertices. It can be an open or closed contour depending on whether the edges are linked or not. +- EDGE - a topological element corresponding to a restrained curve. An edge is generally limited by vertices. It has one dimension. +- VERTEX - a topological element corresponding to a point. It has zero dimension. +- SHAPE - a generic term covering all of the above. + +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. +![](/user_guides/modeling_data/images/modeling_data_image006.jpg "ShapeEnum") + +@subsubsection occt_modat_5_2_2 Orientation + +The notion of orientation is represented by the **TopAbs_Orientation** enumeration. Orientation is a generalized notion of the sense of direction found in various modelers. This is used when a shape limits a geometric domain; and is closely linked to the notion of boundary. The three cases are the following: +- Curve limited by a vertex. +- Surface limited by an edge. +- Space limited by a face. + +In each case the topological form used as the boundary of a geometric domain of a higher dimension defines two local regions of which one is arbitrarily considered as the **default region**. + +For a curve limited by a vertex the default region is the set of points with parameters greater than the vertex. That is to say it is the part of the curve after the vertex following the natural direction along the curve. + +For a surface limited by an edge the default region is on the left of the edge following its natural direction. More precisely it is the region pointed to by the vector product of the normal vector to the surface and the vector tangent to the curve. + +For a space limited by a face the default region is found on the negative side of the normal to the surface. + +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.| + +![](/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 | + +![](/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. | +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. + +![](/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. + +![](/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 *TopoDS* package describes the topological data structure with the following characteristics: +- reference to an abstract shape with neither orientation nor location. +- Access to the data structure through the tool classes. + +As stated above, OCCT Topology describes data structures of objects in parametric space. These descriptions use localization in and restriction of parts of this space. The types of shapes, which can be described in these terms, are the vertex, the face and the shape. The vertex is defined in terms of localization in parametric space, and the face and shape, in terms of restriction of this space. + +OCCT topological descriptions also allow the simple shapes defined in these terms to be combined into sets. For example, a set of edges forms a wire; a set of faces forms a shell, and a set of solids forms a composite solid (CompSolid in Open CASCADE Technology). You can also combine shapes of either sort into compounds. Finally, you can give a shape an orientation and a location. + +Listing shapes in order of complexity from vertex to composite solid leads us to the notion of the data structure as knowledge of how to break a shape down into a set of simpler shapes. This is in fact, the purpose of the *TopoDS* package. + +The model of a shape is a shareable data structure because it can be used by other shapes. (An edge can be used by more than one face of a solid). A shareable data structure is handled by reference. When a simple reference is insufficient, two pieces of information are added - an orientation and a local coordinate reference. +- An orientation tells how the referenced shape is used in a boundary (*Orientation* from *TopAbs*). +- A local reference coordinate (*Location* from *TopLoc*) allows referencing a shape at a position different from that of its definition. + +The **TopoDS_TShape** class is the root of all shape descriptions. It contains a list of shapes. Classes inheriting **TopoDS_TShape** can carry the description of a geometric domain if necessary (for example, a geometric point associated with a TVertex). A **TopoDS_TShape** is a description of a shape in its definition frame of reference. This class is manipulated by reference. + +The **TopoDS_Shape** class describes a reference to a shape. It contains a reference to an underlying abstract shape, an orientation,and a local reference coordinate. This class is manipulated by value and thus cannot be shared. + +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. + +![](/user_guides/modeling_data/images/modeling_data_image011.jpg "Structure of a shell formed from two faces") + +![](/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 wire TW1 references the edges from TE1 to TE4; TW2 references from TE4 to TE7. + +The vertices are referenced by the edges as follows:TE1(TV1,TV4), TE2(TV1,TV2), TE3(TV2,TV3), TE4(TV3,TV4), TE5(TV4,TV5), TE6(T5,TV6),TE7(TV3,TV6). + +**Note** that this data structure does not contain any *back references*. All references go from more complex underlying shapes to less complex ones. The techniques used to access the information are described later. The data structure is as compact as possible. Sub-objects can be shared among different objects. + +Two very similar objects, perhaps two versions of the same object, might share identical sub-objects. The usage of local coordinates in the data structure allows the description of a repetitive sub-structure to be shared. + +The compact data structure avoids the loss of information associated with copy operations which are usually used in creating a new version of an object or when applying a coordinate change. + +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. +![](/user_guides/modeling_data/images/modeling_data_image013.jpg "Data structure containing two versions of a solid") + +Classes inheriting TopoDS_Shape +------------------------------ +*TopoDS* is based on class *TopoDS_Shape* and the class defining its underlying shape. This has certain advantages, but the major drawback is that these classes are too general. Different shapes they could represent do not type them (Vertex, Edge, etc.) hence it is impossible to introduce checks to avoid incoherences such as inserting a face in an edge. + + *TopoDS* package offers two sets of classes, one set inheriting the underlying shape with neither orientation nor location and the other inheriting *TopoDS_Shape*, which represent the standard topological shapes enumerated in *TopAbs* package. + +The following classes inherit Shape : *TopoDS_Vertex, TopoDS_Edge, TopoDS_Wire, TopoDS_Face, TopoDS_Shell, TopoDS_Solid,TopoDS_CompSolid,* and *TopoDS_Compound*. In spite of the similarity of names with those inheriting from **TopoDS_TShape** there is a profound difference in the way they are used. + +*TopoDS_Shape* class and the classes, which inherit from it, are the natural means to manipulate topological objects. *TopoDS_TShape* classes are hidden. *TopoDS_TShape* describes a class in its original local coordinate system without orientation. *TopoDS_Shape* is a reference to *TopoDS_TShape* with an orientation and a local reference. + +*TopoDS_TShape* class is deferred; *TopoDS_Shape* class is not. Using *TopoDS_Shape* class allows manipulation of topological objects without knowing their type. It is a generic form. Purely topological algorithms often use the *TopoDS_Shape* class. + +*TopoDS_TShape* class is manipulated by reference; TopoDS_Shape class by value. A TopoDS_Shape is nothing more than a reference enhanced with an orientation and a local coordinate. The sharing of *TopoDS_Shapes* is meaningless. What is important is the sharing of the underlying *TopoDS_TShapes*. Assignment or passage in argument does not copy the data structure: this only creates new *TopoDS_Shapes* which refer to the same *TopoDS_TShape*. + +Although classes inheriting *TopoDS_TShape* are used for adding extra information, extra fields should not be added in a class inheriting from TopoDS_Shape. Classes inheriting from TopoDS_Shape serve only to specialize a reference in order to benefit from static type control (carried out by the compiler). For example, a routine that receives a *TopoDS_Face* in argument is more precise for the compiler than the one, which receives a *TopoDS_Shape*. It is pointless to derive other classes than those found inTopoDS. All references to a topological data structure are made with the Shape class and its inheritors defined in *TopoDS*. + +There are no constructors for the classes inheriting from the *TopoDS_Shape* class, otherwise the type control would disappear through **implicit casting** (a characteristic of C++). The TopoDS package provides package methods for **casting** an object of the TopoDS_Shape class in one of these sub-classes, with type verification. + +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 + #include TopoDS_Shape.hxx + + + voidProcessEdge(const TopoDS_Edge&); + + voidProcess(const TopoDS_Shape& aShape) { + if (aShape.Shapetype() == TopAbs_VERTEX) { + TopoDS_Vertex V; + V = TopoDS::Vertex(aShape); // Also correct + TopoDS_Vertex V2 = aShape;// Rejected by compiler + TopoDS_Vertex V3 = TopoDS::Vertex(aShape); // Correct + } + else if (aShape.ShapeType() == TopAbs_EDGE){ + ProcessEdge(aShape) ;// Thisis rejected + ProcessEdge(TopoDS::Edge(aShape)) ; // Correct + } + else { + cout *Neither a vertex nor an edge ?* ; + ProcessEdge(TopoDS::Edge(aShape)) ; + // OK for compiler but anexception will be raised at run-time + } + } +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + + +@subsection occt_modat_5_4 Exploration of Topological Data Structures + +The *TopExp* package provides tools for exploring the data structure described with the *TopoDS* package. Exploring a topological structure means finding all sub-objects of a given type, for example, finding all the faces of a solid. + +The TopExp package provides the class *TopExp_Explorer* to find all sub-objects of a given type. An explorer is built with: +- The shape to be explored. +- The type of shapes to be found e.g. VERTEX, EDGE with the exception of SHAPE, which is not allowed. +- The type of Shapes to avoid. e.g. SHELL, EDGE. By default, this type is SHAPE. This default value means that there is no restriction on the exploration. + + + +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; + TopExp_Explorer Ex; + for (Ex.Init(S,TopAbs_FACE); Ex.More(); Ex.Next()) { + ProcessFace(Ex.Current()); + } + } +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +To 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: + + +**Example ** + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + void test() { + TopExp_Explorer Ex1, Ex2; + TopoDS_Shape S; + for (Ex1.Init(S,TopAbs_SHELL);Ex1.More(); Ex1.Next()){ + // visit all shells + for (Ex2.Init(Ex1.Current(),TopAbs_FACE);Ex2.More(); + Ex2.Next()){ + //visit all the faces of the current shell + ProcessFaceinAshell(Ex2.Current()); + ... + } + } + for(Ex1.Init(S,TopAbs_FACE,TopAbs_SHELL);Ex1.More(); Ex1.Next()){ + // visit all faces not ina shell. + ProcessFace(Ex1.Current()); + } + } +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +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 *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. + +**Example ** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + void TopExp::MapShapes (const TopoDS_Shape& S, + const TopAbs_ShapeEnum T, + TopTools_IndexedMapOfShape& M) + { + TopExp_Explorer Ex(S,T); + while (Ex.More()) { + M.Add(Ex.Current()); + Ex.Next(); + } + } +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +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. + +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. +2. Exploring the faces. Each face is drawn. +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, + const Color FaceIsocolor, + const Color FreeEdgeColor, + const Color BorderEdgeColor, + const Color SharedEdgeColor) + { + // Store the edges in aMap. + TopTools_IndexedMapOfShape edgemap; + TopExp::MapShapes(aShape,TopAbs_EDGE,edgeMap); + // Create an array set to zero. + TColStd_Array1OfInteger faceCount(1,edgeMap.Extent()); + faceCount.Init (0); + // Explore the faces. + TopExp_Explorer expFace(aShape,TopAbs_FACE); + while (expFace.More()) { + //Draw the current face. + DrawFaceIsos(TopoDS::Face(expFace.Current()),nbIsos,FaceIsoColor); + // Explore the edges ofthe face. + TopExp_Explorer expEdge(expFace.Current(),TopAbs_EDGE); + while (expEdge.More()) { + //Increment the face count for this edge. + faceCount(edgemap.FindIndex(expEdge.Current()))++; + expEdge.Next(); + } + expFace.Next(); + } + //Draw the edges of theMap + Standard_Integer i; + for (i=1;i=edgemap.Extent();i++) { + switch (faceCount(i)) { + case 0 : + DrawEdge(TopoDS::Edge(edgemap(i)),FreeEdgeColor); + break; + case 1 : + DrawEdge(TopoDS::Edge(edgemap(i)),BorderEdgeColor); + break; + default : + DrawEdge(TopoDS::Edge(edgemap(i)),SharedEdgeColor); + break; + } + } + } +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@subsection occt_modat_5_5 Lists and Maps of Shapes + +**TopTools** package contains tools for exploiting the *TopoDS* data structure. It is an instantiation of the tools from *TCollection* package with the Shape classes of *TopoDS*. + +| *TopTools_Array1OfShape, HArray1OfShape* | Instantiation of the *TCollection_Array1* and *TCollection_HArray1* with *TopoDS_Shape*. | +| *TopTools_SequenceOfShape* | Instantiation of the *TCollection_Sequence* with *TopoDS_Shape*. | +| *TopTools_MapOfShape* | Instantiation of the *TCollection_Map*. Allows the construction of sets of shapes. | +| *TopTools_IndexedMapOfShape* | Instantiation of the *TCollection_IndexedMap*. Allows the construction of tables of shapes and other data structures. | + +With a **TopTools_Map**, a set of references to Shapes can be kept without duplication. +The following example program 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 is a recursive method. + // The size of a shape is1 + the sizes of the subshapes. + TopoDS_Iterator It; + Standard_Integer size = 1; + for (It.Initialize(aShape);It.More();It.Next()) { + size += Size(It.Value()); + } + return size; + } +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +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 ** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + #include TopoDS_Iterator.hxx + #includeTopTools_MapOfShape.hxx + + void MapShapes(const TopoDS_Shape& aShape, + TopTools_MapOfShape& aMap) + { + //This is a recursive auxiliary method. It stores all subShapes of aShape in a Map. + if (aMap.Add(aShape)) { + //Add returns True if aShape was not already in the Map. + TopoDS_Iterator It; + for (It.Initialize(aShape);It.More();It.Next()){ + MapShapes(It.Value(),aMap); + } + } + } + + Standard_Integer Size(const TopoDS_Shape& aShape) + { + // Store Shapes in a Mapand return the size. + TopTools_MapOfShape M; + MapShapes(aShape,M); + return M.Extent(); + } +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**Note** For more details about Maps see 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. +- 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 + #include TopTools_IndexedMapOfShape.hxx + #include TopTools_Array1OfShape.hxx + #include TopoDS_Location.hxx + + TopoDS_Shape Copy(const TopoDS_Shape& aShape, + const TopoDS_Builder& aBuilder) + { + // Copies the wholestructure of aShape using aBuilder. + // Stores all thesub-Shapes in an IndexedMap. + TopTools_IndexedMapOfShape theMap; + TopoDS_Iterator It; + Standard_Integer i; + TopoDS_Shape S; + TopLoc_Location Identity; + S = aShape; + S.Location(Identity); + S.Orientation(TopAbs_FORWARD); + theMap.Add(S); + for (i=1; i= theMap.Extent(); i++) { + for(It.Initialize(theMap(i)); It.More(); It.Next()) { + S=It.Value(); + S.Location(Identity); + S.Orientation(TopAbs_FORWARD); + theMap.Add(S); + } + } + } +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +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*. + +**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()); + + // Use a recursivefunction to copy the first element. + void AuxiliaryCopy (Standard_Integer, + const TopTools_IndexedMapOfShape &, + TopTools_Array1OfShape &, + const TopoDS_Builder&); + + AuxiliaryCopy(1,theMap,theCopies,aBuilder); + + // Get the result with thecorrect local reference and orientation. + S = theCopies(1); + S.Location(aShape.Location()); + S.Orientation(aShape.Orientation()); + return S; +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +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, + TopTools_Array1OfShape&copies, + const TopoDS_Builder&aBuilder) + { + //If the copy is a null Shape the copy is not done. + if (copies(index).IsNull()) { + copies(index) =sources(index).EmptyCopied(); + //Insert copies of the sub-shapes. + TopoDS_Iterator It; + TopoDS_Shape S; + TopLoc_Location Identity; + for(It.Initialize(sources(index)),It.More(), It.Next ()) { + S = It.Value(); + S.Location(Identity); + S.Orientation(TopAbs_FORWARD); + AuxiliaryCopy(sources.FindIndex(S),sources,copies,aBuilder); + S.Location(It.Value().Location());S.Orientation(It.Value().Orientation()); aBuilder.Add(copies(index),S); + } + } + } +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@subsubsection occt_modat_5_5_1 Wire Explorer + +BRepTools_WireExplorer class can access edges of a wire in their order of connection. + +For example, in the wire in the image we want to recuperate the edges in the order {e1, e2, e3,e4, e5} : + +![](/user_guides/modeling_data/images/modeling_data_image014.jpg "A wire composed of 6 edges.") + +TopExp_Explorer, however, recuperates the lines in any order. + +**Example ** + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} + TopoDS_Wire W = ...; + BRepTools_WireExplorer Ex; + for(Ex.Init(W); Ex.More(); Ex.Next()) { + ProcessTheCurrentEdge(Ex.Current()); + ProcessTheVertexConnectingTheCurrentEdgeToThePrevious + One(Ex.CurrentVertex()); + } +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \ No newline at end of file diff --git a/dox/user_guides/ocaf/images/ocaf_image001.png b/dox/user_guides/ocaf/images/ocaf_image001.png new file mode 100644 index 0000000000..e47c657b3b Binary files /dev/null and b/dox/user_guides/ocaf/images/ocaf_image001.png differ diff --git a/dox/user_guides/ocaf/images/ocaf_image002.png b/dox/user_guides/ocaf/images/ocaf_image002.png new file mode 100644 index 0000000000..6154ace907 Binary files /dev/null and b/dox/user_guides/ocaf/images/ocaf_image002.png differ diff --git a/dox/user_guides/ocaf/images/ocaf_image003.png b/dox/user_guides/ocaf/images/ocaf_image003.png new file mode 100644 index 0000000000..bffcbc4f4d Binary files /dev/null and b/dox/user_guides/ocaf/images/ocaf_image003.png differ diff --git a/dox/user_guides/ocaf/images/ocaf_image004.png b/dox/user_guides/ocaf/images/ocaf_image004.png new file mode 100644 index 0000000000..5f2a148eea Binary files /dev/null and b/dox/user_guides/ocaf/images/ocaf_image004.png differ diff --git a/dox/user_guides/ocaf/images/ocaf_image005.png b/dox/user_guides/ocaf/images/ocaf_image005.png new file mode 100644 index 0000000000..c7235a0cac Binary files /dev/null and b/dox/user_guides/ocaf/images/ocaf_image005.png differ diff --git a/dox/user_guides/ocaf/images/ocaf_image006.png b/dox/user_guides/ocaf/images/ocaf_image006.png new file mode 100644 index 0000000000..1525f2e726 Binary files /dev/null and b/dox/user_guides/ocaf/images/ocaf_image006.png differ diff --git a/dox/user_guides/ocaf/images/ocaf_image007.png b/dox/user_guides/ocaf/images/ocaf_image007.png new file mode 100644 index 0000000000..eea54a7251 Binary files /dev/null and b/dox/user_guides/ocaf/images/ocaf_image007.png differ diff --git a/dox/user_guides/ocaf/images/ocaf_image008.png b/dox/user_guides/ocaf/images/ocaf_image008.png new file mode 100644 index 0000000000..b82df300af Binary files /dev/null and b/dox/user_guides/ocaf/images/ocaf_image008.png differ diff --git a/dox/user_guides/ocaf/images/ocaf_image009.png b/dox/user_guides/ocaf/images/ocaf_image009.png new file mode 100644 index 0000000000..2605b03e06 Binary files /dev/null and b/dox/user_guides/ocaf/images/ocaf_image009.png differ diff --git a/dox/user_guides/ocaf/images/ocaf_image010.png b/dox/user_guides/ocaf/images/ocaf_image010.png new file mode 100644 index 0000000000..978599327c Binary files /dev/null and b/dox/user_guides/ocaf/images/ocaf_image010.png differ diff --git a/dox/user_guides/ocaf/images/ocaf_image011.png b/dox/user_guides/ocaf/images/ocaf_image011.png new file mode 100644 index 0000000000..fa93768ea3 Binary files /dev/null and b/dox/user_guides/ocaf/images/ocaf_image011.png differ diff --git a/dox/user_guides/ocaf/images/ocaf_image012.png b/dox/user_guides/ocaf/images/ocaf_image012.png new file mode 100644 index 0000000000..11a5c9dff0 Binary files /dev/null and b/dox/user_guides/ocaf/images/ocaf_image012.png differ diff --git a/dox/user_guides/ocaf/images/ocaf_image013.png b/dox/user_guides/ocaf/images/ocaf_image013.png new file mode 100644 index 0000000000..54f4083ac4 Binary files /dev/null and b/dox/user_guides/ocaf/images/ocaf_image013.png differ diff --git a/dox/user_guides/ocaf/images/ocaf_image014.png b/dox/user_guides/ocaf/images/ocaf_image014.png new file mode 100644 index 0000000000..5cc6743c00 Binary files /dev/null and b/dox/user_guides/ocaf/images/ocaf_image014.png differ diff --git a/dox/user_guides/ocaf/images/ocaf_image015.png b/dox/user_guides/ocaf/images/ocaf_image015.png new file mode 100644 index 0000000000..f5c2785fa8 Binary files /dev/null and b/dox/user_guides/ocaf/images/ocaf_image015.png differ diff --git a/dox/user_guides/ocaf/images/ocaf_image016.png b/dox/user_guides/ocaf/images/ocaf_image016.png new file mode 100644 index 0000000000..1567c758b0 Binary files /dev/null and b/dox/user_guides/ocaf/images/ocaf_image016.png differ diff --git a/dox/user_guides/ocaf/images/ocaf_image017.png b/dox/user_guides/ocaf/images/ocaf_image017.png new file mode 100644 index 0000000000..0076ccd142 Binary files /dev/null and b/dox/user_guides/ocaf/images/ocaf_image017.png differ diff --git a/dox/user_guides/ocaf/ocaf.md b/dox/user_guides/ocaf/ocaf.md new file mode 100644 index 0000000000..83d239a43f --- /dev/null +++ b/dox/user_guides/ocaf/ocaf.md @@ -0,0 +1,1596 @@ +OCAF {#user_guides__ocaf} +======================== + +@section occt_ocaf_1 Introduction + +This manual explains how to use the Open CASCADE Application Framework (OCAF). +It provides basic documentation on using OCAF. For advanced information on OCAF +and its applications, see our offerings on our web site at +www.opencascade.org/support/training/ + +OCAF (the Open CASCADE Application Framework) is a RAD (Rapid Application Development) framework used for +specifying and organizing application data. To do this, OCAF provides: + + * Ready-to-use data common to most CAD/CAM applications, + * A scalable extension protocol for implementing new application specific data, + * An infrastructure + * To attach any data to any topological element + * To link data produced by different applications (*associativity of data*) + * To register the modeling process - the creation history, or parametrics, used to carry out the modifications. + +Using OCAF, the application designer concentrates on the functionality and its specific algorithms. In this way, he avoids architectural problems notably implementing Undo-redo and saving application data. + +In OCAF, all of the above are already handled for the application designer, allowing him to reach a significant increase in productivity. + +In this respect, OCAF is much more than just one toolkit among many in the CAS.CADE Object Libraries. Since it can handle any data and algorithms in these libraries - be it modeling algorithms, topology or geometry - OCAF is a logical supplement to these libraries. + +The table below contrasts the design of a modeling application using object libraries alone and using OCAF. + +**Table 1: Services provided by OCAF** + +|Development tasks |Comments | Without OCAF | With OCAF | +|------------------:|---------:|---------------:|-----------:| +|Creation of geometry| Algorithm Calling the modeling libraries | To be created by the user | To be created by the user| +| Data organization | Including specific attributes and modeling process | To be created by the user | Simplified| +| Saving data in a file | Notion of document | To be created by the user | Provided | +| Document-view management | | To be created by the user | Provided | +| Application infrastructure | New, Open, Close, Save and Save As File menus | To be created by the user | Provided | +| Undo-Redo | Robust, multi-level | To be created by the user | Provided | +| Application-specific dialog boxes | | To be created by the user | To be created by the user | + + + +The relationship between OCAF and the Open CASCADE Technology (**OCCT**) Object Libraries can be seen in the image below. + +![](/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 subsequent chapters of this document explain the concepts and show how to use the services of OCAF. + +@section occt_ocaf_2 Basic Concepts + +@subsection occt_ocaf_2_1 Overview + +In most existing geometric modeling systems, the data structure is shape driven. They usually use a brep model, where solids and surfaces are defined by a collection of entities such as faces, edges etc., and by attributes such as application data. These attributes are attached to the entities. Examples of application data include: + + * color, + * material, + * information that a particular edge is blended. + +A shape, however, is inevitably tied to its underlying geometry. And geometry is highly subject to change in applications such as parametric modeling or product development. In this sort of application, using a brep (boundary representation) data structure proves to be a not very effective solution. A solution other than the shape must be found, i.e. a solution where attributes are attached to a deeper invariant structure of the model. Here, the topology itself will be one attribute among many. + +In OCAF, data structure is reference key-driven. The reference key is implemented in the form of labels. Application data is attached to these labels as attributes. By means of these labels and a tree structure they are organized in, the reference key aggregates all user data, not just shapes and their geometry. These attributes have similar importance; no attribute is master in respect of the others. + +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 | +|-----------------------:|------------------------------:| + +![](/user_guides/ocaf/images/ocaf_image004.png "Topology-driven vs. reference key-driven approaches") + +@subsection occt_ocaf_2_2 Applications and documents + +OCAF documents are in turn managed by an OCAF application, which is in charge of: + + * Creating new documents + * Saving documents and opening them + * Initializing document views. + +Apart from their role as a container of application data, documents can refer to each other; Document A, for example, can refer to a specific label in Document B. This functionality is made possible by means of the reference key. + +@subsection occt_ocaf_23 The document and the data framework + +Inside a document, there is a data framework, a model, for example. This is a set of labels organized in a tree structure characterized by the following features: + * The first label in a framework is the root of the tree; + * Each label has a tag expressed as an integer value; + * Sub-labels of a label are called its children; + * Each label which is not the root has one father – label from an upper level of the framework; + * Labels which have the same father are called brothers; + * 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). + +![](/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). + +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: + + * a lamp-shade label with tag 1 + * a bulb label with tag 2 + * a stem label with tag 3 + +Label tags are chosen at will. They are just identifiers of the lamp parts. Now you can refine all units: set to the specified label geometry, color, material and other information about the lamp or it’s parts. This information is placed into special attributes of the label: the pure label contains no data – it is only a key to access data. + +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. + +![](/user_guides/ocaf/images/ocaf_image006.jpg) + +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. + +![](/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. + +The data framework structure allows to create more complex structures: each lamp label sub-label may have children labels with more detailed information about parts of the table lamp and its components. + +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): + + * Geometric attributes + * General attributes + * Relationship attributes + * Auxiliary attributes + +@subsubsection occt_ocaf_2_3_1 Documents + +Documents offer access to the data framework and manage the following items: + + * Manage the notification of changes + * Update external links + * Manage the saving and restoring of data + * Store the names of software extensions. + * Manage command transactions + * Manage Undo and Redo options. + +@subsubsection occt_ocaf_2_3_2 Shape attribute + +The shape attribute implements the functionality of the OCCT topology manipulation: + + * reference to the shapes + * tracking of shape evolution + +@subsubsection occt_ocaf_2_3_3 Standard attributes + +Several ready-to-use base attributes already exist. These allow operating with simple common data in the data framework (for example: integer, real, string, array kinds of data), realize auxiliary functions (for example: tag sources attribute for the children of the label counter), create dependencies (for example: reference, tree node).... + +@subsubsection occt_ocaf_2_3_4 Visualization attributes + +These attributes allow placing viewer information to the data framework, visual representation of objects and other auxiliary visual information, which is needed for graphical data representation. + +@subsubsection occt_ocaf_2_3_5 Function services + +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. + +![](/user_guides/ocaf/images/ocaf_image008.jpg "Document structure") + +@section occt_ocaf_3_ Data Framework Services + +@subsection occt_ocaf_3_1 Overview + +The data framework offers a single environment in which data from different application components can be handled. + +This allows you to exchange and modify data simply, consistently, with a maximum level of information, and with stable semantics. + +The building blocks of this approach are: + + * The tag + * The label + * The attribute + +As it has been mentioned earlier, the first label in a framework is the root label of the tree. Each label has a tag expressed as an integer value, and a label is uniquely defined by an entry expressed as a list of tags from the root, 0:1:2:1, for example. + +Each label can have a list of attributes, which contain data, and several attributes can be attached to a label. Each attribute is identified by a GUID, and although a label may have several attributes attached to it, it must not have more than one attribute of a single GUID. + +The sub-labels of a label are called its children. Conversely, each label, which is not the root, has a father. Brother labels cannot share the same tag. + +The most important property is that a label’s entry is its persistent address in the data framework. + +![](/user_guides/ocaf/images/ocaf_image009.jpg "Contents of a document") + +@subsection occt_ocaf_3_2 The Tag + +A tag is an integer, which identifies a label in two ways: + + * Relative identification + * Absolute identification. + +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 both relative and absolute identification, it is important to remember that the value of an integer has no intrinsic semantics whatsoever. In other words, the natural sequence that integers suggest, i.e. 0, 1, 2, 3, 4 ... - has no importance here. The integer value of a tag is simply a key. + +The tag can be created in two ways: + + * Random delivery + * User-defined delivery + +As the names suggest, in random delivery, the tag value is generated by the system in a random manner. In user-defined delivery, you assign it by passing the tag as an argument to a method. + +@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. + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +TDF_Label child1 = TDF_TagSource::NewChild (level2); +TDF_Label child2 = TDF_TagSource::NewChild (level2); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@subsubsection occt_ocaf_3_2_2 Creation of a child label by user delivery from a tag + +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. + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +TDF_Label achild = root.FindChild(3,Standard_False); +if (!achild.IsNull()) { +Standard_Integer tag = achild.Tag(); +} +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@subsection occt_ocaf_3_3 The Label + +The tag gives a persistent address to a label. The label – the semantics of the tag – is a place in the data framework where attributes, which contain data, are attached. The data framework is, in fact, a tree of labels with a root as the ultimate father label (refer to the following figure): + +![](/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. + +@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. + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +//creating a label with tag 10 at Root +TDF_Label lab1 = aDF->Root().FindChild(10); + +//creating labels 7 and 2 on label 10 +TDF_Label lab2 = lab1.FindChild(7); + +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. + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +TDF_Label level1 = root.FindChild(3,Standard_True); +TDF_Label level2 = level1.FindChild(1,Standard_True); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +@subsubsection occt_ocaf_3_3_3 Retrieving child labels + +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; +// +for (TDF_ChildIterator it1 (current,Standard_False); it1.More(); it1.Next()) { +achild = it1.Value(); +// +// do something on a child (level 1) +// +} +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +You can also retrieve all child labels in every descendant generation of your current label by iteration on all levels in the scope of this label. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +for (TDF_ChildIterator itall (current,Standard_True); itall.More(); itall.Next()) { +achild = itall.Value(); +// +// do something on a child (all levels) +// +} +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +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) +{ + TDF_ChildIterator it; + TCollection_AsciiString es; + for (it.Initialize(aLabel,Standard_True); it.More(); it.Next()){ + TDF_Tool::Entry(it.Value(),es); + cout = as.ToCString() = endl; + } +} +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +@subsubsection occt_ocaf_3_3_4 Retrieving the father label + +Retrieving the father label of a current label. + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +TDF_Label father = achild.Father(); +isroot = father.IsRoot(); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +@subsection occt_ocaf_3_4 The Attribute + +The label itself contains no data. All data of any type whatsoever - application or non-application - is contained in attributes. These are attached to labels, and there are different types for different types of data. OCAF provides many ready-to-use standard attributes such as integer, real, constraint, axis and plane. There are also attributes for topological naming, functions and visualization. Each type of attribute is identified by a GUID. + +The 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. + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +if(current.FindAttribute(TDataStd_Integer::GetID(),INT)) +{ + // the attribute is found +} +else +{ + // the attribute is not found +} +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +@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. + +**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. + +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 +TDF_Label attach = INT->Label(); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +@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. + +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 +// +if (current.IsA(TDataStd_Integer::GetID())) { +// the label has an Integer attribute attached +} +if (current.HasAttribute()) { +// the label has at least one attribute attached +Standard_Integer nbatt = current.NbAttributes(); +// the label has nbatt attributes attached +} +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +@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. + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +current.Forget(TDataStd_Integer::GetID()); +// integer attribute is now not attached to current label +current.ForgetAll(); +// current has now 0 attributes attached +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +@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. + +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 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. + +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 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. + +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. +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. + +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: + * 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. + +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 Appendix. + +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). + +![](/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; + * Point of axis of rotation as TDataStd_RealArray (three values: X, Y and Z); + * Axis of rotation as TDataStd_RealArray (three values: DX, DY and DZ); + * Angle of rotation as TDataStd_Real. + +![](/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). + + +@section occt_ocaf_4_ Standard Document Services + +@subsection occt_ocaf_4_1 Overview + +Standard documents offer ready-to-use documents containing a TDF-based data framework. Each document can contain only one framework. + +The documents themselves are contained in the instantiation of a class inheriting from TDocStd_Application. This application manages the creation, storage and retrieval of documents. + +You can implement undo and redo in your document, and refer from the data framework of one document to that of another one. This is done by means of external link attributes, which store the path and the entry of external links. + +To sum up, standard documents alone provide access to the data framework. They also allow you to: + + * Update external links + * Manage the saving and opening of data + * Manage the undo/redo functionality. + + +@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. + +@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. + +@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. + +**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()); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +@subsection occt_ocaf_4_3 The Document + +The document contains your data framework, and allows you to retrieve this framework, recover its main label, save it in a file, and open or close this file. + +@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. + +**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 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: New Document Format Version 1.0 +NewDocumentFormat.FileExtension: ndf +NewDocumentFormat.StoragePlugin: bd696000-5b34-11d1-b5ba-00a0c9064368 +NewDocumentFormat.RetrievalPlugin: bd696001-5b34-11d1-b5ba-00a0c9064368 +NewDocumentFormatSchema: bd696002-5b34-11d1-b5ba-00a0c9064368 +NewDocumentFormat.AttributeStoragePlugin:57b0b826-d931-11d1-b5da-00a0c9064368 +NewDocumentFormat.AttributeRetrievalPlugin:57b0b827-d931-11d1-b5da-00a0c9064368 +~~~~~ + +* Create the resource file «Plugin» with GUIDs and corresponding plugin libraries, which looks like this: + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +! Description of available plugins +! ************ + +b148e300-5740-11d1-a904-080036aaa103.Location: libFWOSPlugin.so +! +! standard document drivers plugin +! +bd696000-5b34-11d1-b5ba-00a0c9064368.Location: libPAppStdPlugin.so +bd696001-5b34-11d1-b5ba-00a0c9064368.Location: libPAppStdPlugin.so +! +! standard schema plugin +! +bd696002-5b34-11d1-b5ba-00a0c9064368.Location: libPAppStdPlugin.so +! +! standard attribute drivers plugin +! +57b0b826-d931-11d1-b5da-00a0c9064368.Location: libPAppStdPlugin.so +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": + +~~~~~ +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»). + +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. + +@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. + +![](/user_guides/ocaf/images/ocaf_image012.jpg  "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 +--------------------------------------- + +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; + +TDF_Label source = doc1->GetData()->Root(); +TDF_Label target = doc2->GetData()->Root(); +TDocStd_XLinkTool XLinkTool; + +XLinkTool.CopyWithLink(target,source); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Now the target document has a copy of the source document. The copy also has a link in order to update the content of the copy if the original changes. + +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 +---------------------------------------------- + +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); + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +@section occt_ocaf_5_ OCAF Shape Attributes +@subsection occt_ocaf_5_1 Overview + +OCAF shape attributes are used for topology objects and their evolution access. All topological objects are stored in one TNaming_UsedShapes attribute at the root label of the data framework. This attribute contains a map with all topological shapes used in a given document. + +The user can add the TNaming_NamedShape attribute to other labels. This attribute contains references (hooks) to shapes from the TNaming_UsedShapes attribute and an evolution of these shapes. The TNaming_NamedShape attribute contains a set of pairs of hooks: to the *Old* shape and to a *New* shape (see the following figure). It allows not only to get the topological shapes by the labels, but also to trace the evolution of the shapes and to correctly update dependent shapes by the changed one. + +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. + +![](/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: + +* If a sub-shape must have some extra attributes (material of each face or color of each edge). In this case a specific sub-shape is placed to a separate label (usually to a sub-label of the result shape label) with all attributes of this sub-shape. +* If the topological naming algorithm is needed, a necessary and sufficient set of sub-shapes is placed to child labels of the result shape label. As usual, for a basic solid and closed shells, all faces of the shape are disposed. + + +TNaming_NamedShape may contain a few pairs of hooks with the same evolution. In this case the topology shape, which belongs to the named shape is a compound of new shapes. + +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. + +![](/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. + +![](/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 generation of F12 face + * edges as an intersection of two contiguous faces + * vertices as an intersection of three contiguous faces + +After any modification of source boxes the application must automatically rebuild the naming entities: recompute the named shapes of the boxes (solids and faces) and fuse the resulting named shapes (solids and faces) that reference to the new named shapes. + +@subsection occt_ocaf_5_2 Services provided + +@subsubsection occt_ocaf_5_2_1 Registering shapes and their evolution + +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. +* 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 ) +* 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 +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. + +@subsubsection occt_ocaf_5_2_2 Using naming resources + +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» +TNaming_Builder builder(label); +// set a pair of shapes with evolution GENERATED +builder.Generated(oldshape1,newshape1); +// set another pair of shapes with the same evolution +builder.Generated(oldshape2,newshape2); +// get the result – TNaming_NamedShape attribute +Handle(TNaming_NamedShape) ns = builder.NamedShape(); +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +@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()). +  +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: +* GetShape(Handle(TNaming_NamedShape)) method returns a compound of new shapes of the given named shape +* CurrentShape(Handle(TNaming_NamedShape)) method returns a compound of the shapes – last modifications ( latest versions ) of the shapes from the given named shape +* 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); +// iterate while some pairs are not iterated +while(iter.More()) { +// get the new shape from the current pair +TopoDS_Shape newshape = iter.NewShape(); +// get the old shape from the current pair +TopoDS_Shape oldshape = iter.OldShape(); +// do something... + +// go to the next pair +iter.Next(); +} +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +@subsubsection occt_ocaf_5_2_4 Selection Mechanism + +One of user interfaces for topological naming resources is the TNaming_Selector class. You can use this class to: + + * Store a selected shape on a label + * 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. + +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. + +@subsubsection occt_ocaf_5_2_5 Exploring shape evolution + +The class TNaming_Tool provides a toolkit to read current data contained in the attribute. + +If you need to create a topological attribute for existing data, use the method NamedShape. + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +class MyPkg_MyClass +{ +public: Standard_Boolean SameEdge (const Handle(CafTest_Line)& L1, const Handle(CafTest_Line)& L2); +}; + +Standard_Boolean CafTest_MyClass::SameEdge (const Handle(CafTest_Line)& L1, const Handle(CafTest_Line)& L2) +{ + Handle(TNaming_NamedShape) NS1 = L1->NamedShape(); + Handle(TNaming_NamedShape) NS2 = L2->NamedShape(); + return BRepTools::Compare(NS1,NS2); +} +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@section occt_ocaf_6_ Standard Attributes + +@subsection occt_ocaf_6_1 Overview + +There are several ready-to-use attributes, which allow creating and modifying attributes for many basic data types. They are available in the packages TDataStd, TDataXtd and TDF. Each attribute belongs to one of four types: + + * Geometric attributes + * General attributes + * Relationship attributes + * Auxiliary 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 + * Geometry – simply identifies, that the concerned TNaming_NamedShape attribute with a specified-type geometry belongs to the same label + * Plane – simply identifies, that the concerned TNaming_NamedShape attribute with a plane shape inside belongs to the same label + * Point – simply identifies, that the concerned TNaming_NamedShape attribute with a  point shape inside belongs to the same label + * Shape – simply identifies, that the concerned TNaming_NamedShape attribute belongs to the same label + * PatternStd  – identifies one of five available pattern models (linear, circular, rectangular, circular rectangular and mirror) + * Position – identifies the position in 3d global space + +General attributes +------------------ + + * AsciiString – contains AsciiString value + * BooleanArray – contains an array of Boolean + * BooleanList – contains a list of Boolean + * ByteArray – contains an array of Byte (unsigned char) values + * Comment – contains a string – some comment for a given label (or attribute) + * Expression – contains an expression string and a list of used variables attributes + * ExtStringArray – contains an array of ExtendedString values + * ExtStringList – contains a list of ExtendedString values + * Integer – contains an integer value + * IntegerArray – contains an array of  integer values + * IntegerList – contains a list of integer values + * IntPackedMap – contains a packed map of integers + * Name – contains a string – some name of a given label (or attribute) + * NamedData – may contain up to 6 of the following named data sets (vocabularies): DataMapOfStringInteger, DataMapOfStringReal, DataMapOfStringString, DataMapOfStringByte, DataMapOfStringHArray1OfInteger, DataMapOfStringHArray1OfReal + * NoteBook – contains a NoteBook object attribute + * Real – contains a real value + * RealArray – contains an array of  real values + * RealList    – contains a list of real values + * Relation – contains a relation string and a list of used variables attributes + * Tick – defines a boolean attribute + * Variable – simply identifies, that a variable belongs to this label; contains the «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 +----------------------- + + * Reference – contains reference to the label of its own data framework + * ReferenceArray – contains an array of references + * ReferenceList – contains a list of references + * TreeNode – this attribute allows to create an internal tree in the data framework; this tree consists of nodes with the specified tree ID; each node contains references to the father, previous brother, next brother, first child nodes and tree ID. + +Auxiliary attributes +-------------------- + * Directory – 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. + +All of these attributes inherit class TDF_Attribute, so, each attribute has its own GUID and standard methods for attribute creation, manipulation, getting access to the data framework. + + +@subsection occt_ocaf_6_2 Services common to all attributes + +@subsubsection occt_ocaf_6_2_1 Accessing GUIDs + +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. + +@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. + +@section occt_ocaf_7_ Visualization Attributes + +@subsection occt_ocaf_7_1 Overview + +Standard visualization attributes implement the Application Interactive Services (see Open CASCADE Technology Visualization User’s Guide) in the context of Open CASCADE Technology Application Framework. Standard visualization attributes are AISViewer and Presentation and belong to the TPrsStd package. + +@subsection occt_ocaf_7_2 Services provided + +@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. + +To initialize the AIS viewer as in the example below, use method Find. + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +// «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. + +@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: +![](/user_guides/ocaf/images/ocaf_image016.png) + +As usual, the GUID of a driver and the GUID of a displayed attribute are the same. + +@subsubsection occt_ocaf_7_2_4 Using a container for drivers + +You frequently need a container for different presentation drivers. The class TPrsStd_DriverTable provides this service. You can add a driver to the table, see if one is successfully added, and fill it with standard drivers. + +To fill a driver table with standard drivers, first initialize the AIS viewer as in the example above, and then pass the return value of the method InitStandardDrivers to the driver table returned by the method Get. Then attach a TNaming_NamedShape to a label and set the named shape in the presentation attribute using the method Set. Then attach the presentation attribute to the named shape attribute, and the AIS_InteractiveObject, which the presentation attribute contains, will initialize its drivers for the named shape. This can be seen in the example below. + +**Example** +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp} +DriverTable::Get() -> InitStandardDrivers(); +// next, attach your named shape to a label +TPrsStd_AISPresentation::Set(NS}; +// here, attach the AISPresentation to NS. +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +@section occt_ocaf_8_ Function Services + +@subsection occt_ocaf_8_1 Overview + +Function services aggregate data necessary for regeneration of a model. The function mechanism - available in the package TFunction - provides links between functions and any execution algorithms, which take their arguments from the data framework, and write their results inside the same framework. + +When you edit any application model, you have to regenerate the model by propagating the modifications. Each propagation step calls various algorithms. To make these algorithms independent of your application model, you need to use function services. + +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 + +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. + +You can write your function attribute, a driver for such attribute (which updates the function result in accordance to a given map of changed labels), and set your driver with the GUID to the driver table. + +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 + +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 + +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): + +![](/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 + * create prism P using face F as a basis + * create fillet L at the edge of the prism + * 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 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 solver calls the L function driver + * the driver rebuilds fillet L and adds the label of the fillet to the logbook as impacted + +@section occt_ocaf_9 XML Support + +Writing and reading XML files in OCCT is provided by LDOM package, which constitutes an integral part +of XML OCAF persistence, which is the optional component provided on top of Open CASCADE Technology. + +The Light DOM (LDOM) package contains classes maintaining a data structure whose main principles conform to W3C DOM Level 1 Recommendations. The purpose of these classes as required by XML OCAF persistence schema is to: +* Maintain a tree structure of objects in memory representing the XML document. The root of the structure is an object of the LDOM_Document type. This object contains all the data corresponding to a given XML document and contains one object of the LDOM_Element type named "document element". The document element contains other LDOM_Element objects forming a tree. Other types of nodes (LDOM_Attr, LDOM_Text, LDOM_Comment, LDOM_CDATASection) represent the corresponding XML types and serve as branches of the tree of elements. +* Provide class LDOM_Parser to read XML files and convert them to LDOM_Document objects. +* Provide class LDOM_XmlWriter to convert LDOM_Document to a character stream in XML format and store it in file. + +This package covers the functionality provided by numerous products known as "DOM parsers". Unlike most of them, LDOM was specifically developed to meet the following requirements: +* To minimize the virtual memory allocated by DOM data structures. In average, the amount of memory of LDOM is the same as the XML file size (UTF-8). +* To minimize the time required for parsing and formatting XML, as well as for access to DOM data structures. + +Both these requirements are important when XML files are processed by applications if these files are relatively large (occupying megabytes and even hundreds of megabytes). To meet the requirements, some limitations were imposed on the DOM Level 1 specification; these limitations are insignificant in applications like OCAF. Some of these limitations can be overridden in the course of future developments. The main limitations are: +* No Unicode support as well as various other encodings; only ASCII strings are used in DOM/XML. Note: There is a data type TCollection_ExtendedString for wide character data. This type is supported by LDOM_String as a sequence of numbers. +* Some superfluous methods are deleted: getPreviousSibling, getParentNode, etc. +* No resolution of XML Entities of any kind +* No support for DTD: the parser just checks for observance of general XML rules and never validates documents. +* Only 5 available types of DOM nodes: LDOM_Element, LDOM_Attr, LDOM_Text, LDOM_Comment, LDOM_CDATASection. +* No support of Namespaces; prefixed names are used instead of qualified names. +* No support of the interface DOMException (no exception when attempting to remove a non-existing node). + +LDOM is dependent on Kernel OCCT classes only. Therefore, it can be used outside OCAF persistence in various algorithms where DOM/XML support may be required. + +@subsection occt_ocaf_9_1 Document Drivers + +The drivers for document storage and retrieval manage conversion between a transient OCAF +Document in memory and its persistent reflection in a container (disk, memory, network ...). For XML Persistence, they are defined in the package XmlDrivers. + +The main methods (entry points) of these drivers are: +* *Write()* - for a storage driver; +* *Read()* - for a retrieval driver. + +The most common case (which is implemented in XML Persistence) is writing/reading document to/from a regular OS file. Such conversion is performed in two steps: + +First it is necessary to convert the transient document into another form (called persistent), suitable for writing into a file, and vice versa. +In XML Persistence LDOM_Document is used as the persistent form of an OCAF Document and the DOM_Nodes are the persistent objects. +An OCAF Document is a tree of labels with attributes. Its transformation into a persistent form can be functionally divided into two parts: +* Conversion of the labels structure, which is performed by the method XmlMDF::FromTo() +* Conversion of the attributes and their underlying objects, which is performed by the corresponding attribute drivers (one driver per attribute type). + +The driver for each attribute is selected from a table of drivers, either by attribute +type (on storage) or by the name of the corresponding DOM_Element (on retrieval). +The table of drivers is created by by methods *XmlDrivers_DocumentStorageDriver::AttributeDrivers()* +and *XmlDrivers_DocumentRetrievalDriver::AttributeDrivers()*. + +Then the persistent document is written into a file (or read from a file). +In standard persistence Storage and FSD packages contain classes for writing/reading the persistent document into a file. In XML persistence LDOMParser and LDOM_XmlWriter are used instead. + +Usually, the library containing document storage and retrieval drivers is loaded at run time by a plugin mechanism. To support this in XML Persistence, there is a plugin XmlPlugin and a Factory()method in the XmlDrivers package. This method compares passed GUIDs with known GUIDs and returns the corresponding driver or generates an exception if the GUID is unknown. + +The application defines which GUID is needed for document storage or retrieval and in which library it should be found. This depends on document format and application resources. Resources for XML Persistence and also for standard persistence are found in the StdResource unit. They are written for the XmlOcaf document format. + +@subsection occt_ocaf_9_2 Attribute Drivers + +There is one attribute driver for XML persistence for each transient attribute from a set of standard OCAF attributes, with the exception of attribute types, which are never stored (pure transient). Standard OCAF attributes are collected in six packages, and their drivers also follow this distribution. Driver for attribute T*_* is called XmlM*_*. Conversion between transient and persistent form of attribute is performed by two methods Paste() of attribute driver. + +*XmlMDF_ADriver* is the root class for all attribute drivers. + +At the beginning of storage/retrieval process, one instance of each attribute driver is created and appended to driver table implemented as XmlMDF_ADriverTable. During OCAF Data storage, attribute drivers are retrieved from the driver table by the type of attribute. In the retrieval step, a data map is created linking names of DOM_Elements and attribute drivers, and then attribute drivers are sought in this map by DOM_Element qualified tag names. + +Every transient attribute is saved as a DOM_Element (root element of OCAF attribute) with attributes and possibly sub-nodes. The name of the root element can be defined in the attribute driver as a string passed to the base class constructor. The default is the attribute type name. Similarly, namespace prefixes for each attribute can be set. There is no default value, but it is possible to pass NULL or an empty string to store attributes without namespace prefixes. + +The basic class XmlMDF_ADriver supports errors reporting via the method *WriteMessage(const TCollection_ExtendedString&)*. It sends a message string to its message driver which is initialized in the constructor with a Handle(CDM_MessageDriver) passed from the application by Document Storage/Retrieval Driver. + +@subsection occt_ocaf_9_3 XML Document Structure + +Every XML Document has one root element, which may have attributes and contain other nodes. In OCAF XML Documents the root element is named "document" and has attribute "format" with the name of the OCAF Schema used to generate the file. The standard XML format is "XmlOcaf". The following elements are sub-elements of and should be unique entries as its sub-elements, in a specific order. The order is: +* **Element info** - contains strings identifying the format version and other parameters of the OCAF XML document. Normally, data under the element is used by persistence algorithms to correctly retrieve and initialize an OCAF document. The data also includes a copyright string. +* **Element comments** - consists of an unlimited number of sub-elements containing necessary comment strings. +* **Element label** is the root label of the document data structure, with the XML attribute "tag" equal to 0. It contains all the OCAF data (labels, attributes) as tree of XML elements. Every sub-label is identified by a tag (positive integer) defining a unique key for all sub-labels of a label. Every label can contain any number of elements representing OCAF attributes (see OCAF Attributes Representation below). +* **Element shapes** - contains geometrical and topological entities in BRep format. These entities being referenced by OCAF attributes written under the element