diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index a8bce65c02..fe41af8a8d 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -2,40 +2,43 @@ ## Contribute Code -In order to contribute code to OCCT, you must register on this [portal](https://dev.opencascade.org/) and sign the Contributor License Agreement (CLA). +In order to contribute code to OCCT you must sign the Contributor License Agreement (CLA). - [Introduction: What is CLA and Why It Is Needed?](CLA_SIGNING.md) - [Contribution License Agreement](CLA.md) - [CLA Submission Form](https://dev.opencascade.org/get_involed/cla_submission_form) ### Steps to Submit Your Contribution -1. **Clone OCCT Git Repository**: See [Guide to installing and using Git for OCCT development](https://dev.opencascade.org/doc/overview/html/occt_contribution__git_guide.html) if you are not familiar with Git. -2. **Develop Your Change**: Ensure it complies with [OCCT Coding Rules](https://dev.opencascade.org/doc/overview/html/occt_contribution__coding_rules.html). -3. **Build and Verify**: Build the modified version of OCCT and verify it works as expected. Consider creating a test case. -4. **Register an Issue**: Register an issue in the [Mantis bug tracker](https://tracker.dev.opencascade.org/login_select_proj_page.php?ref=bug_report_page.php) or [GitHub issues](https://github.com/Open-Cascade-SAS/OCCT/issues) describing your change. -5. **Push Your Change**: Push your change to the Git repository in a branch with a name starting with "CR" followed by the issue ID, then switch the issue to Resolved. -The contribution then passes code review and testing; if everything is OK, it will be integrated into the master branch in about one week. +1. **Fork the repository** on GitHub: https://github.com/Open-Cascade-SAS/OCCT +2. **Create a feature branch** from an up-to-date `master`. Any descriptive branch name is fine. +3. **Develop your change** following the [OCCT Coding Rules](https://dev.opencascade.org/doc/overview/html/occt_contribution__coding_rules.html). Format the source with `clang-format` using the `.clang-format` configuration shipped in the repository. +4. **Test locally**. Run the existing DRAW test suite and `OpenCascadeGTest` tests; create a test case for the change when applicable. +5. **Open a Draft Pull Request** against `Open-Cascade-SAS/OCCT:master`. CI/CD pipelines run on every push and report build, style and test results. +6. **Mark the PR Ready for Review** once CI is green. A maintainer will review the change and request updates as needed. +7. **Address review feedback** by pushing additional commits to the same branch; CI re-runs automatically. +8. After approval the PR is merged (typically squashed) by a maintainer. -See [Contribution Workflow](https://dev.opencascade.org/doc/overview/html/occt_contribution__contribution_workflow.html) for other possibilities and details on how contributions are processed. +PR titles follow the convention `Group - Summary`, for example `Modeling - Fix crash in BRepAlgoAPI_Fuse on null shapes`. -For more details on integration into GitHub, see the [GitHub Discussions Guide](https://github.com/Open-Cascade-SAS/OCCT/discussions/36). +See the [Contribution Workflow](https://dev.opencascade.org/doc/overview/html/occt_contribution__contribution_workflow.html) and [Git Guide](https://dev.opencascade.org/doc/overview/html/occt_contribution__git_guide.html) for full details. ## Contribute Ideas -Every big thing starts with an idea. We appreciate your vision on how to enhance Open CASCADE technology. Share your thoughts on the [OCCT product development forum](https://dev.opencascade.org/forums) or submit your meaningful ideas and bug reports via [Mantis tracker](https://tracker.dev.opencascade.org) or [GitHub issues](https://github.com/Open-Cascade-SAS/OCCT/issues). +Every big thing starts with an idea. We appreciate your vision on how to enhance Open CASCADE Technology. Share your thoughts on the [OCCT development forum](https://dev.opencascade.org/forums) or [GitHub Discussions](https://github.com/Open-Cascade-SAS/OCCT/discussions), and submit bug reports or feature requests via [GitHub Issues](https://github.com/Open-Cascade-SAS/OCCT/issues) using the provided issue templates. -- **Forum**: [OCCT product development forum](https://dev.opencascade.org/forums) -- **Reporting Issues**: [Mantis tracker](https://tracker.dev.opencascade.org) or [GitHub issues](https://github.com/Open-Cascade-SAS/OCCT/issues) +- **Forum**: [OCCT development forum](https://dev.opencascade.org/forums) +- **Discussions**: [GitHub Discussions](https://github.com/Open-Cascade-SAS/OCCT/discussions) +- **Reporting Issues**: [GitHub Issues](https://github.com/Open-Cascade-SAS/OCCT/issues) ## Contribute Knowledge -Know a lot about OCCT? You can help educate other OCCT users by writing OCCT-related articles or blog posts, creating samples, examples, or tutorials, and even by writing a book about OCCT! If you would like us to share your content via official OCCT resources, please [contact us](https://dev.opencascade.org/webform/contact_us). +Know a lot about OCCT? You can help educate other OCCT users by writing OCCT-related articles or blog posts, creating samples, examples or tutorials, and even by writing a book about OCCT. If you would like us to share your content via official OCCT resources, please [contact us](https://dev.opencascade.org/webform/contact_us). ## Contribute Documentation and Tutorials -Do you have an idea on how to make OCCT Documentation easier for new users or even more exhaustive for professionals? Or want to help with proofreading and technical writing? Translating OCCT Documentation and materials into your native language is also very much appreciated. You are always welcome to submit your documentation improvement suggestions via [Mantis tracker](https://tracker.dev.opencascade.org) or [GitHub issues](https://github.com/Open-Cascade-SAS/OCCT/issues).. +Do you have an idea on how to make OCCT documentation easier for new users or more exhaustive for professionals? Want to help with proofreading and technical writing? Translating OCCT documentation and materials into your native language is also very much appreciated. Submit documentation improvements as [Pull Requests](https://github.com/Open-Cascade-SAS/OCCT/pulls) against files under `dox/`, or open a [GitHub Issue](https://github.com/Open-Cascade-SAS/OCCT/issues) describing what you would like to see improved. ## Contribute to the Community -At any community interaction points, we value your support in starting forum topics or replying to other users’ posts, joining Open CASCADE social networks, participating in GitHub or Stack Overflow projects, and just spreading the word about OCCT! Welcome to our community! \ No newline at end of file +At any community interaction point, we value your support in starting forum topics or replying to other users' posts, joining Open CASCADE social networks, participating in GitHub or Stack Overflow projects, and just spreading the word about OCCT. Welcome to our community! diff --git a/.github/ISSUE_TEMPLATE/config.yml b/.github/ISSUE_TEMPLATE/config.yml index 82a0e0aff5..cb1adad9eb 100644 --- a/.github/ISSUE_TEMPLATE/config.yml +++ b/.github/ISSUE_TEMPLATE/config.yml @@ -6,9 +6,6 @@ contact_links: - name: GitHub discussions url: https://github.com/Open-Cascade-SAS/OCCT/discussions about: You can also use GitHub discussions to ask questions and discuss the problem you are seeing - - name: Mantis bug tracker - url: https://tracker.dev.opencascade.org/ - about: You can also use the Mantis bug tracker to report bugs and issues - name: Contact US form url: https://dev.opencascade.org/webform/contact_us about: You can also use the Contact US form to ask questions and discuss the problem you are seeing diff --git a/dox/FILES_HTML.txt b/dox/FILES_HTML.txt index f90ec255ab..42c457dcd3 100644 --- a/dox/FILES_HTML.txt +++ b/dox/FILES_HTML.txt @@ -11,7 +11,6 @@ tutorial/tutorial.md build/build_upgrade.md build/build_occt/building_occt.md -build/build_3rdparty/building_3rdparty.md build/build_documentation/building_documentation.md debug/debug.md @@ -44,4 +43,6 @@ contribution/contribution_workflow/contribution_workflow.md contribution/git_guide/git_guide.md contribution/tests/tests.md +samples/samples.md + license.md diff --git a/dox/build/build_3rdparty/building_3rdparty.md b/dox/build/build_3rdparty/building_3rdparty.md deleted file mode 100644 index bc7d892671..0000000000 --- a/dox/build/build_3rdparty/building_3rdparty.md +++ /dev/null @@ -1,556 +0,0 @@ - Build 3rd-parties {#build_upgrade_building_3rdparty} -============================================== -@tableofcontents - -On Windows, the easiest way to install third-party libraries is to download archive with pre-built binaries from https://dev.opencascade.org/resources/download/3rd-party-components. -On Linux and macOS, it is recommended to use the version installed in the system natively. - -@section dev_guides__building_3rdparty_win_1 Windows - -This section presents guidelines for building third-party products used by Open CASCADE Technology (OCCT) and samples on Windows platform. -It is assumed that you are already familiar with MS Visual Studio / Visual C++. - -You need to use the same version of MS Visual Studio for building all third-party products and OCCT itself, in order to receive a consistent set of runtime binaries. - -It is recommended to create a separate new folder on your workstation, where you will unpack the downloaded archives of the third-party products, and where you will build these products (for example, `c:/occ3rdparty`). -Further in this document, this folder is referred to as `3rdparty`. - -@subsection dev_guides__building_3rdparty_win_2 Tcl/Tk - -Tcl/Tk is required for DRAW test harness. - -**Installation from sources: Tcl** - -Download the necessary archive from https://www.tcl.tk/software/tcltk/download.html and unpack it. - -1. In the `win` sub-directory, edit file `buildall.vc.bat`: - - * Edit the line `"call ... vcvars32.bat"` to have correct path to the version of Visual Studio to be used for building, for instance: - - call "%VS80COMNTOOLS%\vsvars32.bat" - - If you are building 64-bit version, set environment accordingly, e.g.: - - call "%VS80COMNTOOLS%\..\..\VC\vcvarsall.bat" amd64 - - * Define variable `INSTALLDIR` pointing to directory where Tcl/Tk will be installed, e.g.: - - set INSTALLDIR=D:\OCCT\3rdparty\tcltk-86-32 - - * Add option `install` to the first command line calling `nmake`: - - nmake -nologo -f makefile.vc release htmlhelp install %1 - - * Remove second call to `nmake` (building statically linked executable) - -2. Edit file `rules.vc` replacing line - - SUFX = tsgx - - by - - SUFX = sgx - - This is to avoid extra prefix 't' in the library name, which is not recognized by default by OCCT build tools. - -3. By default, Tcl uses dynamic version of run-time library (MSVCRT), which must be installed on the system where Tcl will be used. - You may wish to link Tcl library with static version of run-time to avoid this dependency. - For that: - - * Edit file `makefile.vc` replacing strings `"crt = -MD"` by `"crt = -MT"` - - * Edit source file `tclMain.c` (located in folder `generic`) commenting out forward declaration of function `isatty()`. - -4. In the command prompt, run `buildall.vc.bat`
- You might need to run this script twice to have `tclsh` executable installed; check subfolder `bin` of specified installation path to verify this. - -5. For convenience of use, we recommend making a copy of `tclsh` executable created in subfolder `bin` of `INSTALLDIR` and named with Tcl version number suffix, as `tclsh.exe` (with no suffix) - - > cd D:\OCCT\3rdparty\tcltk-86-32\bin - > cp tclsh86.exe tclsh.exe - -**Installation from sources: Tk** - -Download the necessary archive from https://www.tcl.tk/software/tcltk/download.html and unpack it. -Apply the same steps as described for building Tcl above, with the same `INSTALLDIR`. -Note that Tk produces its own executable, called `wish`. - -You might need to edit default value of `TCLDIR` variable defined in `buildall.vc.bat` (should be not necessary if you unpack both Tcl and Tk sources in the same folder). - -@subsection dev_guides__building_3rdparty_win_2_2 FreeType - -FreeType is required for text display in a 3D viewer. -You can download its sources from https://freetype.org/ - -1. Unpack the downloaded archive of FreeType product into the `3rdparty` folder. - As a result, you will get a folder named, for example, `3rdparty/freetype-2.4.10`. - Further in this document, this folder is referred to as `freetype`. - -2. Open the solution file `freetype/builds/win32/vc20xx/freetype.sln` in Visual Studio. - Here `vc20xx` stands for your version of Visual Studio. - -3. Select the configuration to build: either `Debug` or `Release`. - -4. Build the `freetype` project.
- As a result, you will get a `freetype` import library (`.lib`) in the `freetype/obj/win32/vc20xx` folder. - -5. If you build FreeType for a 64 bit platform, select in the main menu `Build - Configuration Manager` - and add `x64` platform to the solution configuration by copying the settings from `Win32` platform: - - @figure{/build/build_3rdparty/images/3rdparty_image001.png} - - Update the value of the Output File for `x64` configuration: - - @figure{/build/build_3rdparty/images/3rdparty_image003.png} - - Build the `freetype` project.
- As a result, you will obtain a 64 bit import library (`.lib`) file in the `freetype/x64/vc20xx` folder. - To build FreeType as a dynamic library (`.dll`) follow steps 6, 7 and 8 of this procedure. - -6. Open menu Project-> Properties-> Configuration Properties-> General and change option `Configuration Type` to `Dynamic Library (.dll)`. -7. Edit file `freetype/include/freetype/config/ftoption.h`:
- in line 255, uncomment the definition of macro `FT_EXPORT` and change it as follows: - - #define FT_EXPORT(x) __declspec(dllexport) x - -8. Build the `freetype` project.
- As a result, you will obtain the files of the import library (`.lib`) and the dynamic library (`.dll`) in folders `freetype/objs/release` or `freetype/objs/debug`. - If you build for a 64 bit platform, follow step 5 of the procedure. - - To facilitate the use of FreeType libraries in OCCT with minimal adjustment of build procedures, - it is recommended to copy the include files and libraries of FreeType into a separate folder, named according to the pattern `freetype-compiler-bitness-building mode`, where: - * `compiler` is `vc8` or `vc9` or `vc10` or `vc11`; - * `bitness` is `32` or `64`; - * `building mode` is `opt` (for `Release`) or `deb` (for `Debug`). - - The `include` subfolder should be copied as is, while libraries should be renamed to `freetype.lib` and `freetype.dll` (suffixes removed) and placed to subdirectories `lib` and `bin`, respectively. - If the `Debug` configuration is built, the Debug libraries should be put into subdirectories `libd` and `bind`. - -@subsection dev_guides__building_3rdparty_win_3_1 TBB - -This third-party product is installed with binaries from the archive that can be downloaded from https://github.com/oneapi-src/oneTBB/releases/tag/v2021.5.0. -Go to the **Download** page, find the release version you need (e.g. `oneTBB 2021.5.0`) and pick the archive for Windows platform. -To install, unpack the downloaded archive of TBB product (`oneapi-tbb-2021.5.0-win.zip`) - -Unpack the downloaded archive of TBB product into the `3rdparty` folder. - -Further in this document, this folder is referred to as `tbb`. - -@subsection dev_guides__building_3rdparty_win_3_3 FreeImage - -This third-party product should be built as a dynamically loadable library (`.dll` file). -You can download its sources from -https://sourceforge.net/projects/freeimage/files/Source%20Distribution/ - -1. Unpack the downloaded archive of FreeImage product into `3rdparty` folder.
- As a result, you should have a folder named `3rdparty/FreeImage`. - Rename it according to the rule: `freeimage-platform-compiler-building mode`, where - - * `platform` is `win32` or `win64`; - * `compiler` is `vc8` or `vc9` or `vc10` or `vc11`; - * `building mode` is *opt* (for release) or `deb` (for debug) - - Further in this document, this folder is referred to as `freeimage`. - -2. Open the solution file `freeimage/FreeImage.*.sln` in your Visual Studio.
- If you use a Visual Studio version higher than VC++ 2008, apply conversion of the workspace. - Such conversion should be suggested automatically by Visual Studio. - -3. Select a configuration to build. - - Choose `Release` if you are building Release binaries. - - Choose `Debug` if you are building Debug binaries. - - *Note:* - - If you want to build a debug version of FreeImage binaries then you need to rename the following files in FreeImage projects: - - Project -> Properties -> Configuration Properties -> Linker -> General -> Output File - - FreeImage*d*.dll to FreeImage.dll - - Project -> Properties -> Configuration Properties -> Linker -> Debugging-> Generate Program Database File - - FreeImage*d*.pdb to FreeImage.pdb - - Project -> Properties -> Configuration Properties -> Linker -> Advanced-Import Library - - FreeImage*d*.lib to FreeImage.lib - - Project -> Properties -> Configuration Properties -> Build Events -> Post -> Build Event -> Command Line - - FreeImage*d*.dll to FreeImage.dll - FreeImage*d*.lib to FreeImage.lib - - Additionally, rename in project FreeImagePlus - - Project -> Properties -> Configuration Properties -> Linker -> Input -> Additional Dependencies - - from FreeImage*d*.lib to FreeImage.lib - -4. Select a platform to build. - - Choose `Win32` if you are building for a 32 bit platform. - - Choose `x64` if you are building for a 64 bit platform. - -5. Start the building process.
- As a result, you should have the library files of FreeImage product in `freeimage/Dist` folder (`FreeImage.dll` and `FreeImage.lib`). - -@subsection dev_guides__building_3rdparty_win_3_4 VTK - -VTK Integration Services component provides adaptation functionality for visualization of OCCT topological shapes by means of VTK library. - -1. Download the necessary archive from https://www.vtk.org/VTK/resources/software.html and unpack it into `3rdparty` folder.
- As a result, you will get a folder named, for example, `3rdparty/VTK-6.1.0`. - Further in this document, this folder is referred to as `VTK`. - -2. Use CMake to generate VS projects for building the library: - - Start CMake-GUI and select `VTK` folder as source path, and the folder of your choice for VS project and intermediate build data. - - Click **Configure**. - - Select the VS version to be used from the ones you have installed (we recommend using VS 2015) and the architecture (32 or 64-bit). - - Generate VS projects with default CMake options. The open solution `VTK.sln` will be generated in the build folder. - -3. Build project VTK in Release mode. - -@section build_3rdparty_linux Linux - -This section presents additional guidelines for building third-party products used by Open CASCADE Technology and samples on Linux platform. - -@subsection dev_guides__building_3rdparty_linux_4 Installation From Official Repositories - -**Debian-based distributives** - -All 3rd-party products required for building of OCCT could be installed from official repositories. -You may install them from console using apt-get utility: - - sudo apt-get install tcllib tklib tcl-dev tk-dev libfreetype-dev libx11-dev libgl1-mesa-dev libfreeimage-dev - sudo apt-get install rapidjson-dev libdraco-dev - -Building is possible with C++ compliant compiler: - - sudo apt-get install g++ - -@subsection dev_guides__building_3rdparty_linux_2_1 Tcl/Tk - -Tcl/Tk is required for DRAW test harness. - -**Installation from sources: Tcl** - -Download the necessary archive from https://www.tcl.tk/software/tcltk/download.html and unpack it. - -1. Enter the `unix` sub-directory of the directory where the Tcl source files are located (`TCL_SRC_DIR`). - - cd TCL_SRC_DIR/unix - -2. Run the `configure` command: - - configure --enable-gcc --enable-shared --enable-threads --prefix=TCL_INSTALL_DIR - - For a 64 bit platform also add `--enable-64bit` option to the command line. - -3. If the configure command has finished successfully, start the building process: - - make - -4. If building is finished successfully, start the installation of Tcl. - All binary and service files of the product will be copied to the directory defined by `TCL_INSTALL_DIR` - - make install - -**Installation from sources: Tk** - -Download the necessary archive from https://www.tcl.tk/software/tcltk/download.html and unpack it. - -1. Enter the `unix` sub-directory of the directory where the Tk source files are located (`TK_SRC_DIR`) - - cd TK_SRC_DIR/unix - -2. Run the `configure` command, where `TCL_LIB_DIR` is `TCL_INSTALL_DIR/lib`. - - configure --enable-gcc --enable-shared --enable-threads --with-tcl=TCL_LIB_DIR --prefix=TK_INSTALL_DIR - - For a 64 bit platform also add `--enable-64bit` option to the command line. - -3. If the configure command has finished successfully, start the building process: - - make - -4. If the building has finished successfully, start the installation of Tk. - All binary and service files of the product will be copied - to the directory defined by `TK_INSTALL_DIR` (usually it is `TCL_INSTALL_DIR`) - - make install - -@subsection dev_guides__building_3rdparty_linux_2_2 FreeType - -FreeType is required for text display in the 3D viewer. -Download the necessary archive from https://freetype.org/ and unpack it. - -1. Enter the directory where the source files of FreeType are located (`FREETYPE_SRC_DIR`). - - cd FREETYPE_SRC_DIR - -2. Run the `configure` command: - - configure --prefix=FREETYPE_INSTALL_DIR - - For a 64 bit platform also add `CFLAGS='-m64 -fPIC' CPPFLAGS='-m64 -fPIC'` option to the command line. - -3. If the `configure` command has finished successfully, start the building process: - - make - -4. If the building has finished successfully, start the installation of FreeType. - All binary and service files of the product will be copied to the directory defined by `FREETYPE_INSTALL_DIR` - - make install - -@subsection dev_guides__building_3rdparty_linux_3_1 TBB - -This third-party product is installed with binaries from the archive that can be downloaded from https://github.com/oneapi-src/oneTBB/releases/tag/v2021.5.0. -Go to the **Download** page, find the release version you need (e.g. `oneTBB 2021.5.0`) and pick the archive for Linux platform. -To install, unpack the downloaded archive of TBB product (`oneapi-tbb-2021.5.0-lin.tgz`). - -@subsection dev_guides__building_3rdparty_linux_3_3 FreeImage - -Download the necessary archive from https://sourceforge.net/projects/freeimage/files/Source%20Distribution/ and unpack it. -The directory with unpacked sources is further referred to as `FREEIMAGE_SRC_DIR`. - -1. Modify `FREEIMAGE_SRC_DIR/Source/OpenEXR/Imath/ImathMatrix.h`:
- In line 60 insert the following: - - #include string.h - -2. Enter the directory where the source files of FreeImage are located (`FREEIMAGE_SRC_DIR`). - - cd FREEIMAGE_SRC_DIR - -3. Run the building process - - make - -4. Run the installation process - - a. If you have the permission to write into directories `/usr/include` and `/usr/lib`, run the following command: - - make install - - b. If you do not have this permission, you need to modify file `FREEIMAGE_SRC_DIR/Makefile.gnu`: - - Change lines 7-9 from: - - DESTDIR ?= / - INCDIR ?= $(DESTDIR)/usr/include - INSTALLDIR ?= $(DESTDIR)/usr/lib - - to: - - DESTDIR ?= $(DESTDIR) - INCDIR ?= $(DESTDIR)/include - INSTALLDIR ?= $(DESTDIR)/lib - - Change lines 65-67 from: - - install -m 644 -o root -g root $(HEADER) $(INCDIR) - install -m 644 -o root -g root $(STATICLIB) $(INSTALLDIR) - install -m 755 -o root -g root $(SHAREDLIB) $(INSTALLDIR) - - to: - - install -m 755 $(HEADER) $(INCDIR) - install -m 755 $(STATICLIB) $(INSTALLDIR) - install -m 755 $(SHAREDLIB) $(INSTALLDIR) - - Change line 70 from: - - ldconfig - - to: - - \#ldconfig - - Then run the installation process by the following command: - - make DESTDIR=FREEIMAGE_INSTALL_DIR install - -5. Clean temporary files - - make clean - -@subsection dev_guides__building_3rdparty_linux_3_4 VTK - -Download the necessary archive from https://www.vtk.org/VTK/resources/software.html and unpack it. - -1. Install or build `cmake` product from the source file. -2. Start `cmake` in GUI mode with the directory where the source files of *VTK* are located: - - ccmake VTK_SRC_DIR - - * Press `[c]` to make the initial configuration - * Define the necessary options in `VTK_INSTALL_PREFIX` - * Press `[c]` to make the final configuration - * Press `[g]` to generate `Makefile` and exit - -3. Start the building of VTK: - - make - -4. Start the installation of VTK. Binaries will be installed according to the `VTK_INSTALL_PREFIX` option. - - make install - -@section build_3rdparty_macos Mac OS X - -This section presents additional guidelines for building third-party products -used by Open CASCADE Technology and samples on Mac OS X platform (10.6.4 and later). - -@subsection dev_guides__building_3rdparty_osx_2_1 Tcl/Tk - -Tcl/Tk is required for DRAW test harness. - -**Installation from sources: Tcl** - -Download the necessary archive from https://www.tcl.tk/software/tcltk/download.html and unpack it. - -1. Enter the `macosx` sub-directory of the directory where the Tcl source files are located (`TCL_SRC_DIR`). - - cd TCL_SRC_DIR/macosx - -2. Run the `configure` command - - configure --enable-gcc --enable-shared --enable-threads --prefix=TCL_INSTALL_DIR - - For a 64 bit platform also add `--enable-64bit` option to the command line. - -3. If the `configure` command has finished successfully, start the building process - - make - -4. If building is finished successfully, start the installation of Tcl. - All binary and service files of the product will be copied to the directory defined by `TCL_INSTALL_DIR`. - - make install - -**Installation from sources: Tk** - -Download the necessary archive from https://www.tcl.tk/software/tcltk/download.html and unpack it. - -1. Enter the `macosx` sub-directory of the directory where the source files of Tk are located (`TK_SRC_DIR`). - - cd TK_SRC_DIR/macosx - -2. Run the `configure` command, where `TCL_LIB_DIR` is `TCL_INSTALL_DIR/lib` - - configure --enable-gcc --enable-shared --enable-threads --with-tcl=TCL_LIB_DIR --prefix=TK_INSTALL_DIR - - For a 64 bit platform also add `--enable-64bit` option to the command line. - -3. If the `configure` command has finished successfully, start the building process: - - make - -4. If the building has finished successfully, start the installation of Tk. - All binary and service files of the product will be copied to the directory defined by `TK_INSTALL_DIR` (usually it is `TCL_INSTALL_DIR`). - - make install - -@subsection dev_guides__building_3rdparty_osx_2_2 FreeType - -FreeType is required for text display in the 3D viewer. -Download the necessary archive from https://freetype.org/ and unpack it. - -1. Enter the directory where the source files of FreeType are located (`FREETYPE_SRC_DIR`). - - cd FREETYPE_SRC_DIR - -2. Run the `configure` command - - configure --prefix=FREETYPE_INSTALL_DIR - - For a 64 bit platform also add `CFLAGS='-m64 -fPIC' CPPFLAGS='-m64 -fPIC'` option to the command line. - -3. If the `configure` command has finished successfully, start the building process - - make - -4. If building has finished successfully, start the installation of FreeType. - All binary and service files of the product will be copied to the directory defined by `FREETYPE_INSTALL_DIR`. - - make install - -@subsection dev_guides__building_3rdparty_osx_3_1 TBB - -This third-party product is installed with binaries from the archive that can be downloaded from https://github.com/oneapi-src/oneTBB/releases/tag/v2021.5.0. -Go to the **Download** page, find the release version you need (e.g. `oneTBB 2021.5.0`) and pick the archive for Mac OS X platform. -To install, unpack the downloaded archive of TBB product (`oneapi-tbb-2021.5.0-mac.tgz`). - -@subsection dev_guides__building_3rdparty_osx_3_3 FreeImage - -Download the necessary archive from -https://sourceforge.net/projects/freeimage/files/Source%20Distribution/ -and unpack it. The directory with unpacked sources is further referred to as `FREEIMAGE_SRC_DIR`. - -Note that for building FreeImage on Mac OS X 10.7 you should replace `Makefile.osx` -in `FREEIMAGE_SRC_DIR` by the corrected file, which you can find in attachment to issue [`#22811`](https://tracker.dev.opencascade.org/file_download.php?file_id=6937&type=bug) in OCCT Mantis bug tracker. - -1. If you build FreeImage 3.15.x you can skip this step. - - Modify `FREEIMAGE_SRC_DIR/Source/OpenEXR/Imath/ImathMatrix.h:`
- In line 60 insert the following: - - #include string.h - - Modify `FREEIMAGE_SRC_DIR/Source/FreeImage/PluginTARGA.cpp`:
- In line 320 replace: - - SwapShort(value); - - with: - - SwapShort(&value); - -2. Enter the directory where the source files of FreeImage are located (`FREEIMAGE_SRC_DIR`). - - cd FREEIMAGE_SRC_DIR - -3. Run the building process - - make - -4. Run the installation process - - 1. If you have the permission to write into `/usr/local/include` and `/usr/local/lib` directories, run the following command: - - make install - - 2. If you do not have this permission, you need to modify file `FREEIMAGE_SRC_DIR/Makefile.osx`:
- Change line 49 from: - - PREFIX ?= /usr/local - - to: - - PREFIX ?= $(PREFIX) - -   Change lines 65-69 from: - - install -d -m 755 -o root -g wheel $(INCDIR) $(INSTALLDIR) - install -m 644 -o root -g wheel $(HEADER) $(INCDIR) - install -m 644 -o root -g wheel $(SHAREDLIB) $(STATICLIB) $(INSTALLDIR) - ranlib -sf $(INSTALLDIR)/$(STATICLIB) - ln -sf $(SHAREDLIB) $(INSTALLDIR)/$(LIBNAME) - - to: - - install -d $(INCDIR) $(INSTALLDIR) - install -m 755 $(HEADER) $(INCDIR) - install -m 755 $(STATICLIB) $(INSTALLDIR) - install -m 755 $(SHAREDLIB) $(INSTALLDIR) - ln -sf $(SHAREDLIB) $(INSTALLDIR)/$(VERLIBNAME) - ln -sf $(VERLIBNAME) $(INSTALLDIR)/$(LIBNAME) - - Then run the installation process by the following command: - - make PREFIX=FREEIMAGE_INSTALL_DIR install - -5. Clean temporary files - - make clean diff --git a/dox/build/build_3rdparty/images/3rdparty_image001.png b/dox/build/build_3rdparty/images/3rdparty_image001.png deleted file mode 100644 index d021815b85..0000000000 Binary files a/dox/build/build_3rdparty/images/3rdparty_image001.png and /dev/null differ diff --git a/dox/build/build_3rdparty/images/3rdparty_image003.png b/dox/build/build_3rdparty/images/3rdparty_image003.png deleted file mode 100644 index c7fd21d57b..0000000000 Binary files a/dox/build/build_3rdparty/images/3rdparty_image003.png and /dev/null differ diff --git a/dox/build/build_3rdparty/images/3rdparty_image004.png b/dox/build/build_3rdparty/images/3rdparty_image004.png deleted file mode 100644 index 1b41730b52..0000000000 Binary files a/dox/build/build_3rdparty/images/3rdparty_image004.png and /dev/null differ diff --git a/dox/build/build_3rdparty/images/3rdparty_image005.png b/dox/build/build_3rdparty/images/3rdparty_image005.png deleted file mode 100644 index 7ee7289e82..0000000000 Binary files a/dox/build/build_3rdparty/images/3rdparty_image005.png and /dev/null differ diff --git a/dox/build/build_3rdparty/images/3rdparty_image006.png b/dox/build/build_3rdparty/images/3rdparty_image006.png deleted file mode 100644 index f1d55a252e..0000000000 Binary files a/dox/build/build_3rdparty/images/3rdparty_image006.png and /dev/null differ diff --git a/dox/build/build_3rdparty/images/3rdparty_image007.png b/dox/build/build_3rdparty/images/3rdparty_image007.png deleted file mode 100644 index 91321e8989..0000000000 Binary files a/dox/build/build_3rdparty/images/3rdparty_image007.png and /dev/null differ diff --git a/dox/build/build_3rdparty/images/genconf_linux.png b/dox/build/build_3rdparty/images/genconf_linux.png deleted file mode 100644 index 9125c47421..0000000000 Binary files a/dox/build/build_3rdparty/images/genconf_linux.png and /dev/null differ diff --git a/dox/build/build_3rdparty/images/genconf_osx.png b/dox/build/build_3rdparty/images/genconf_osx.png deleted file mode 100644 index f7b53fd4c4..0000000000 Binary files a/dox/build/build_3rdparty/images/genconf_osx.png and /dev/null differ diff --git a/dox/build/build_3rdparty/images/genconf_windows.png b/dox/build/build_3rdparty/images/genconf_windows.png deleted file mode 100644 index 409dff035c..0000000000 Binary files a/dox/build/build_3rdparty/images/genconf_windows.png and /dev/null differ diff --git a/dox/build/build_documentation/building_documentation.md b/dox/build/build_documentation/building_documentation.md index 994be6e949..1447294b0d 100644 --- a/dox/build/build_documentation/building_documentation.md +++ b/dox/build/build_documentation/building_documentation.md @@ -1,19 +1,23 @@ -Build Documentation {#build_upgrade__building_documentation} +Build Documentation {#build_upgrade__building_documentation} ================= To generate HTML documentation from sources contained in *dox* subdirectory, -you need to have Tcl and Doxygen 1.8.5 (or above) installed on your system. +you need to have Doxygen 1.8.4 (or above) installed on your system. +Tcl/Tk is required when configuring a full OCCT build with DRAW enabled. -Use script **gendoc** (batch file on Windows, shell script on Linux / Mac OSX) located in `adm` directory to generate documentation. +OCCT documentation is generated via CMake targets. Enable `-DBUILD_DOC_Overview=ON` +when configuring the build, then build the desired target: To generate Overview documentation: - cmd> gendoc -overview + cmake --build . --target Overview To generate Reference manual: - cmd> gendoc -refman + cmake --build . --target RefMan -Run this command without arguments to get help on supported options. +To generate all documentation: + + cmake --build . --target doc See @ref occt_contribution__documentation for prerequisites and details on OCCT documentation system. diff --git a/dox/build/build_occt/building_occt.md b/dox/build/build_occt/building_occt.md index ce095d6118..599d020041 100644 --- a/dox/build/build_occt/building_occt.md +++ b/dox/build/build_occt/building_occt.md @@ -8,31 +8,44 @@ The list of required libraries depends on what OCCT modules will be used, and yo The typical minimum is **FreeType** (necessary for Visualization) and **Tcl/Tk** (for DRAW). See @ref intro_req "requirements on 3rdparty libraries" for a full list. -The easiest way to install third-party libraries is to download archive with pre-built binaries, corresponding to your target configuration, -from [Development Portal](https://dev.opencascade.org/resources/download/3rd-party-components). -You can also build third-party libraries from their sources, see @ref build_upgrade_building_3rdparty for instructions. +The easiest way to obtain third-party libraries is to enable vcpkg integration with `-DBUILD_USE_VCPKG=ON` -- OCCT will then download and build only the components required by the enabled `USE_*` options (e.g. `USE_TBB`, `USE_VTK`, `USE_FREEIMAGE`, `USE_RAPIDJSON`, `USE_DRACO`). -On Linux and macOS we recommend using libraries maintained by distributive developers when possible. +Pre-built third-party archives matching official releases are also attached to [OCCT GitHub Releases](https://github.com/Open-Cascade-SAS/OCCT/releases). On Linux and macOS prefer the libraries provided by your distribution's package manager. Manual builds from sources are still supported -- follow each project's upstream build documentation. @section build_requirements System Requirements -* **CMake** version 3.10 or later (3.16+ recommended for precompiled headers support) -* C++11 compliant compiler (required) +* **CMake** 3.10 or later (3.16+ recommended; required when `BUILD_USE_PCH=ON` for precompiled headers) +* C++17 compliant compiler (required) * Supported platforms and compilers: * Windows: - - Visual Studio 2015 or later + - Visual Studio 2019 or later (2022 preferred — used by official CI) - MinGW-w64 7.3 or later * Linux: - - GCC 5.0 or later - - Clang 3.8 or later + - GCC 8.0 or later + - Clang 7.0 or later * macOS: - - Apple Clang 9.0 or later - - Xcode 9.0 or later + - Apple Clang 11.0 or later + - Xcode 11.0 or later @section build_occt_cmake Building with CMake This chapter describes the [CMake](https://cmake.org/download/)-based build process, which is the standard way to produce OCCT binaries from sources. +@subsection build_occt_vcpkg_quickstart Quick start with vcpkg + +The fastest path to a working OCCT build, used by the official CI (`.github/workflows/`), is to let CMake provision third-party dependencies via [vcpkg](https://vcpkg.io). OCCT ships a `vcpkg.json` manifest under `adm/vcpkg/ports/opencascade/` (referenced automatically via `VCPKG_MANIFEST_DIR`) and pulls only the packages needed by the OCCT `USE_*` options you enable -- you do not need to manage vcpkg manifest features manually. + +~~~~ +cmake -S . -B build \ + -DBUILD_USE_VCPKG=ON \ + -DUSE_TBB=ON -DUSE_VTK=ON -DUSE_FREEIMAGE=ON \ + -DUSE_RAPIDJSON=ON -DUSE_DRACO=ON \ + -DCMAKE_BUILD_TYPE=Release +cmake --build build --config Release --parallel +~~~~ + +Toggle additional third-party features through the corresponding `USE_*` cache variables (e.g. `USE_FFMPEG`, `USE_OPENVR`, `USE_EIGEN`); enabling a `USE_*` flag automatically triggers vcpkg installation of the corresponding package. The `CMAKE_TOOLCHAIN_FILE` for vcpkg is detected automatically from `VCPKG_ROOT` -- pass it explicitly only if vcpkg is not on `PATH`. Manual third-party setup is still supported via standard upstream build instructions, but no longer the recommended path. + CMake is a tool that generates project files for the selected target build system (e.g. Unix makefiles) or IDE (e.g. Visual Studio). Here we describe the build procedure using Windows platform with Visual Studio as an example. However, CMake is cross-platform and can be used to build OCCT on Linux and macOS in essentially the same way. @@ -48,7 +61,7 @@ Different configurations should be built in different build directories to avoid For example: d:/occt/ - the source directory - d:/tmp/occt-build-vc14-x64 - the build directory with the generated + d:/tmp/occt-build-vc143-x64 - the build directory with the generated solution and other intermediate files created during a CMake tool working d:/occt-install - the installation directory that can contain several OCCT configurations @@ -60,7 +73,7 @@ A command-line alternative, *ccmake* can also be used. If the command-line tool is used, run it from the build directory with a single argument indicating the source directory: - cd d:/tmp/occt-build-vc14-x64 + cd d:/tmp/occt-build-vc143-x64 ccmake d:/occt Then press *c* to configure. @@ -72,17 +85,14 @@ If the GUI tool is used, run this tool without additional arguments and specify @figure{/build/build_occt/images/cmake_image001.png} @note Each configuration of the project should be built in its own directory. -When building multiple configurations it is suggested to indicate in the name of build directories the system, bitness and compiler (e.g., d:/occt/build/win32-vc14). +When building multiple configurations it is suggested to indicate in the name of build directories the system, bitness and compiler (e.g., d:/occt/build/win64-vc143). Once the source and build directories are selected, "Configure" button should be pressed in order to start manual configuration process. -It begins with selection of a target configurator. It is "Visual Studio 14 2015 Win64" in our example. +It begins with selection of a target configurator. It is "Visual Studio 17 2022" in our example. @figure{/build/build_occt/images/cmake_image002.png} -@note To build OCCT for **Universal Windows Platform (UWP)** specify the path to toolchain file for cross-compiling d:/occt/adm/templates/uwp.toolchain.config.cmake. -Alternatively, if you are using CMake from the command line add options `-DCMAKE_SYSTEM_NAME=WindowsStore -DCMAKE_SYSTEM_VERSION=10.0`. -Universal Windows Platform (UWP) is supported only on "Visual Studio 14 2015". -File `CASROOT/samples/xaml/ReadMe.md` describes the building procedure of XAML (UWP) sample. +@note When configuring OCCT for **Universal Windows Platform (UWP)**, use CMake from the command line with options `-DCMAKE_SYSTEM_NAME=WindowsStore -DCMAKE_SYSTEM_VERSION=10.0`. Once "Finish" button is pressed, the first pass of the configuration process is executed. At the end of the process, CMake outputs the list of environment variables, which have to be properly specified for successful configuration. @@ -125,13 +135,10 @@ The following table gives the full list of environment variables used at the con | 3RDPARTY_FREEIMAGE* | Path | Path to FreeImage binaries | | 3RDPARTY_TBB* | Path | Path to TBB binaries | | 3RDPARTY_VTK_* | Path | Path to VTK binaries | -| BUILD_ADDITIONAL_TOOLKITS | String | Semicolon-separated individual toolkits to include into build process. If you want to build some particular libraries (toolkits) only, then you may uncheck all modules in the corresponding *BUILD_MODUE_\* options and provide the list of necessary libraries here. Of course, all dependencies will be resolved automatically | +| BUILD_ADDITIONAL_TOOLKITS | String | Semicolon-separated individual toolkits to include into build process. If you want to build some particular libraries (toolkits) only, then you may uncheck all modules in the corresponding *BUILD_MODULE_\* options and provide the list of necessary libraries here. Of course, all dependencies will be resolved automatically | | BUILD_YACCLEX | Boolean | Enables Flex/Bison lexical analyzers. OCCT source files relating to STEP reader and ExprIntrp functionality are generated automatically with Flex/Bison. Checking this option leads to automatic search of Flex/Bison binaries and regeneration of the mentioned files | -| BUILD_SAMPLES_MFC | Boolean | Indicates whether MFC samples should be built together with OCCT. This option is only relevant to Windows platforms | -| BUILD_SAMPLES_QT | Boolean | Indicates whether QT samples should be built together with OCCT. | -| BUILD_Inspector | Boolean | Indicates whether Inspector should be built together with OCCT. | +| BUILD_GTEST | Boolean | Enable building of the GoogleTest-based C++ unit tests located under `src///GTests/`. Produces the `OpenCascadeGTest` executable in the build/install `bin/` directory | | BUILD_DOC_Overview | Boolean | Indicates whether OCCT overview documentation project should be created together with OCCT. It is not built together with OCCT. Checking this option leads to automatic search of Doxygen binaries. Its building calls Doxygen command to generate the documentation in HTML format | -| BUILD_PATCH | Path | Points to the directory recognized as a "patch" for OCCT. If specified, the files from this directory take precedence over the corresponding native OCCT sources. This way you are able to introduce patches to Open CASCADE Technology not affecting the original source distribution | | BUILD_WITH_DEBUG | Boolean | Enables extended messages of many OCCT algorithms, usually printed to cout. These include messages on internal errors and special cases encountered, timing, etc. | | BUILD_ENABLE_FPE_SIGNAL_HANDLER | Boolean | Enable/Disable the floating point exceptions (FPE) during DRAW execution only. Corresponding environment variable (CSF_FPE) can be changed manually in custom.bat/sh scripts without regeneration by CMake. | | CMAKE_CONFIGURATION_TYPES | String | Semicolon-separated CMake configurations | @@ -186,11 +193,11 @@ clear (if they are not empty) `3RDPARTY__DLL_DIR`, `3RDPARTY__ At this time the search will be performed in the newly identified directory and the result will be recorded to corresponding variables (replace old value if it is necessary). For example, `3RDPARTY_FREETYPE_DIR` variable - d:/3rdparty/freetype-2.4.10 + d:/3rdparty/freetype- can be changed to - d:/3rdparty/freetype-2.5.3 + d:/3rdparty/freetype- During the configuration process the related variables (`3RDPARTY_FREETYPE_DLL_DIR`, `3RDPARTY_FREETYPE_INCLUDE_DIR` and `3RDPARTY_FREETYPE_LIBRARY_DIR`) will be filled with new found values. @@ -227,10 +234,9 @@ The directory structure is as follows: data - data files for OCCT (brep, iges, stp) doc - OCCT overview documentation in HTML format inc - header files - samples - samples - src - all required source files for OCCT + resources - DrawResources, Shaders, XSTEPResource, textures, and other runtime data tests - OCCT test suite - win32\vc14\bind - binary files (installed 3rdparties and occt) + win64\vc143\bind - binary files (installed 3rdparties and occt) \libd - libraries (installed 3rdparties and occt) @note The above example is given for debug configuration. @@ -238,7 +244,7 @@ However, it is generally safe to use the same installation directory for the rel In the latter case the contents of install directory will be enriched with subdirectories and files related to the release configuration. In particular, the binaries directory win64 will be expanded as follows: - \win32\vc14\bind + \win64\vc143\bind \libd \bin \lib @@ -246,18 +252,18 @@ In particular, the binaries directory win64 will be expanded as follows: If CMake installation flags are enabled for the 3rd party products (e.g. `INSTALL_FREETYPE`), then the corresponding binaries will be copied to the same bin(d) and lib(d) directories together with the native binaries of OCCT. Such organization of libraries can be especially helpful if your OCCT-based software does not use itself the 3rd parties of Open CASCADE Technology (thus, there is no sense to pack them into dedicated directories). -The installation folder contains the scripts to run *DRAWEXE* (*draw.bat* or *draw.sh*), samples (if they were installed) and overview.html (short-cut for installed OCCT overview documentation). +The installation folder contains the scripts to run *DRAWEXE* (*draw.bat* or *draw.sh*) and overview.html (short-cut for installed OCCT overview documentation). @subsection build_occt_crossplatform_cmake Cross-compiling (Android) This section describes the steps to build OCCT libraries for Android from a complete source package with GNU make (makefiles). -The steps on Windows 7 and Ubuntu 15.10 are similar. There is the only one difference: makefiles are built with mingw32-make on Windows and native GNU make on Ubuntu. +The steps on Windows and Linux are similar. There is the only one difference: makefiles are built with mingw32-make on Windows and native GNU make on Ubuntu. Required tools (download and install if it is required): - - CMake 3.10+ (3.16+ recommended) + - CMake 3.16+ - Android NDK r19+ - Android SDK API level 21+ - - For Windows: MinGW-w64 7.3+ or Visual Studio 2015+ + - For Windows: MinGW-w64 7.3+ or Visual Studio 2019+ - For Linux/macOS: GNU Make 4.0+ Run GUI tool provided by CMake and: diff --git a/dox/build/build_occt/images/genconf_linux.png b/dox/build/build_occt/images/genconf_linux.png deleted file mode 100644 index 9125c47421..0000000000 Binary files a/dox/build/build_occt/images/genconf_linux.png and /dev/null differ diff --git a/dox/build/build_occt/images/genconf_windows.png b/dox/build/build_occt/images/genconf_windows.png deleted file mode 100644 index 409dff035c..0000000000 Binary files a/dox/build/build_occt/images/genconf_windows.png and /dev/null differ diff --git a/dox/build/build_upgrade.md b/dox/build/build_upgrade.md index 711577f3cf..086055d4b7 100644 --- a/dox/build/build_upgrade.md +++ b/dox/build/build_upgrade.md @@ -1,10 +1,9 @@ -Build, Debug and Upgrade {#build_upgrade} +Build, Debug and Upgrade {#build_upgrade} ================= This chapter contains the detailed information about building, debugging and upgrade procedures: * @subpage build_upgrade__building_occt -* @subpage build_upgrade_building_3rdparty * @subpage build_upgrade__building_documentation * @subpage occt__debug * @subpage occt__upgrade diff --git a/dox/contribution/coding_rules.md b/dox/contribution/coding_rules.md index 301768d377..7f48334c19 100644 --- a/dox/contribution/coding_rules.md +++ b/dox/contribution/coding_rules.md @@ -96,7 +96,7 @@ Such types should be given own names using *typedef* statement, located in same- For example, see definition in the file *TColStd_IndexedDataMapOfStringString.hxx*: ~~~~{.cpp} -typedef NCollection_IndexedDataMap NCollection_IndexedDataMap; +typedef NCollection_IndexedDataMap TColStd_IndexedDataMapOfStringString; ~~~~ ### Names of functions @@ -235,9 +235,18 @@ To improve the open source readability and, consequently, maintainability, the f ### Clang-format [MANDATORY] -The source code should be formatted using the clang-format tool with the configuration file provided in the OCCT repository. +The source code must be formatted using the clang-format tool with the configuration file provided in the OCCT repository (`.clang-format` at the project root). The version of clang-format should be 18.1.8 or higher. +### Clang-tidy + +Source code should also be checked with clang-tidy where practical to ensure compliance with modern C++ best practices. +Useful checks include: +- `readability-braces-around-statements` -- braces required for all `if`/`for`/`while`/`else` blocks +- `readability-identifier-naming` -- checks the/a/THE/an naming prefixes +- `modernize-use-override` -- requires `override` specifier on virtual methods +- `modernize-use-nullptr` -- use `nullptr` instead of `NULL` or `0` + ### International language [MANDATORY] All comments in all sources must be in English. @@ -293,14 +302,14 @@ See the following example: ~~~~{.cpp} -// ================================================================================================ +//================================================================================================= void TellMeSmthGood() { ... } -// ================================================================================================ +//================================================================================================= void TellMeSmthBad() { @@ -322,24 +331,28 @@ while (expression) Entering a block increases and leaving a block decreases the indentation by one tabulation. -### Single-line operators +### Braces around statements [MANDATORY] -Single-line conditional operators (if, while, for, etc.) can be written without brackets on the following line. +Curly braces `{ }` are required for all compound statements (`if`, `for`, `while`, `else`, etc.), even when the body contains a single statement. +The clang-tidy `readability-braces-around-statements` check can be used to detect violations of this rule. ~~~~{.cpp} -if (!myIsInit) return false; // bad +if (!myIsInit) return false; // WRONG - missing braces -if (thePtr == nullptr) // OK +if (thePtr == nullptr) // WRONG - missing braces return false; -if (!theAlgo.IsNull()) // preferred +if (!theAlgo.IsNull()) // CORRECT +{ + DoSomething(); +} + +for (int anIdx = 0; anIdx < aSize; ++anIdx) // CORRECT { DoSomething(); } ~~~~ -Having all code in the same line is less convenient for debugging. - ### Comparison expressions with constants In comparisons, put the variable (in the current context) on the left side and constant on the right side of expression. @@ -873,6 +886,15 @@ for (int anIter = 0; anIter < 4096; ++anIter) since linear access does not invalidate cache too often. +@section occt_coding_rules_testing Testing + +OCCT ships with two complementary test runners; new code is expected to be covered by at least one of them: + +* **DRAW Tcl tests** (under `tests/`) -- the primary regression suite, exercised through DRAW commands. See @ref occt_contribution__tests "Automated Test System" for layout, naming, `TODO`/`REQUIRED`/`BAD` conventions and how to add a new case. +* **OpenCascadeGTest** (under `src///GTests/`) -- a GoogleTest-based C++ unit test runner, enabled at configure time with `-DBUILD_GTEST=ON` and producing the `OpenCascadeGTest` executable in the build/install `bin/` directory. Use it for unit-level tests of C++ APIs that are awkward to drive from DRAW. Add new test files to the corresponding `GTests/FILES.cmake`. Use the project's standard naming convention `TestFixture.MethodOrFeature_Scenario_ExpectedBehavior` for test names. Default to GTest assertions (`EXPECT_*` / `ASSERT_*`); use `EXPECT_NEAR` with `Precision::Confusion()` / `Precision::Angular()` for geometric / direction comparisons; wrap intentional `Standard_*` exception assertions in `#ifndef No_Exception` and cast the call with `(void)` to silence `[[nodiscard]]`. + +Refactors that affect public behaviour should add or update tests in the same PR; bug-fix PRs are expected to include a minimal regression test that fails before the fix and passes after. + @section occt_coding_rules_10 Draw Harness command Draw Harness provides TCL interface for OCCT algorithms. @@ -925,7 +947,7 @@ Information printed into Draw Interpreter should be well-structured to allow usa Any command with a long list of obligatory parameters should be considered as ill-formed by design. Optional parameters should start with flag name (with '-' prefix) and followed by its values: -~~~~{.php} +~~~~{.tcl} myCommand -flag1 value1 value2 -flag2 value3 ~~~~ @@ -946,14 +968,14 @@ Functions *Draw::Atof()* and *Draw::Atoi()* support expressions and read values aFlag.LowerCase(); //!< for case insensitive comparison if (aFlag == "position") { - if ((anArgIt + 3) >= theArgsNb) + if ((anArgIter + 3) >= theArgsNb) { std::cerr << "Wrong syntax at argument '" << anArg << "'!\n"; return 1; } - aPosition[0] = Draw::Atof (theArgVec[++anArgIt]); - aPosition[1] = Draw::Atof (theArgVec[++anArgIt]); - aPosition[2] = Draw::Atof (theArgVec[++anArgIt]); + aPosition[0] = Draw::Atof (theArgVec[++anArgIter]); + aPosition[1] = Draw::Atof (theArgVec[++anArgIter]); + aPosition[2] = Draw::Atof (theArgVec[++anArgIter]); } else { @@ -978,12 +1000,12 @@ public: //! @name public methods //! @return squared value Standard_Export double Square (const double theValue); -private: //! \@name private methods +private: //! @name private methods //! Auxiliary method void increment(); -private: //! \@name private fields +private: //! @name private fields int myCounter; //!< usage counter @@ -994,20 +1016,17 @@ private: //! \@name private fields ~~~~{.cpp} #include -// ========================================================== -// function : Square -// purpose : Method computes the square value -// ========================================================== + +//================================================================================================= + double Package_Class::Square (const double theValue) { increment(); return theValue * theValue; } -// ========================================================== -// function : increment -// purpose : -// ========================================================== +//================================================================================================= + void Package_Class::increment() { ++myCounter; @@ -1050,7 +1069,7 @@ vdump $imagedir/${casename}.png 512 512 ~~~~ ### GLSL program: -~~~~{.cpp} +~~~~{.glsl} vec3 Ambient; //!< Ambient contribution of light sources vec3 Diffuse; //!< Diffuse contribution of light sources vec3 Specular; //!< Specular contribution of light sources diff --git a/dox/contribution/contribution.md b/dox/contribution/contribution.md index 61042ec1e8..1ae9c9e436 100644 --- a/dox/contribution/contribution.md +++ b/dox/contribution/contribution.md @@ -1,4 +1,4 @@ -Contribution {#contribution} +Contribution {#contribution} ============ This chapter contains the detailed information about contribution procedure: diff --git a/dox/contribution/contribution_workflow/contribution_workflow.md b/dox/contribution/contribution_workflow/contribution_workflow.md index 0b7f7be8a6..e5910b6ea1 100644 --- a/dox/contribution/contribution_workflow/contribution_workflow.md +++ b/dox/contribution/contribution_workflow/contribution_workflow.md @@ -4,462 +4,132 @@ Contribution Workflow {#occt_contribution__contribution_workflow} @section occt_contribution_intro Introduction -The purpose of this document is to describe standard workflow for processing contributions to certified version of OCCT. +The purpose of this document is to describe the standard workflow for processing contributions to OCCT. -@subsection occt_contribution_intro_tracker Use of issue tracker system +OCCT development is hosted on GitHub at https://github.com/Open-Cascade-SAS/OCCT. +All contributions are submitted as Pull Requests (PRs) through the GitHub interface. -Each contribution should have corresponding issue (bug, or feature, or integration request) -registered in the MantisBT issue tracker system accessible by URL -https://tracker.dev.opencascade.org. -The issue is processed according to the described workflow. +@subsection occt_contribution_intro_cla Contributor License Agreement -@subsection occt_contribution_intro_access Access levels +Before contributing, you must sign the Contributor License Agreement (CLA). +See the [CLA submission form](https://dev.opencascade.org/get_involed/cla_submission_form) for details. -Access level defines the permissions of the user to view, register and modify issues in the issue tracker. -The correspondence of access level and user permissions is defined in the table below. +@subsection occt_contribution_intro_pr PR Title Convention -| Access level | Granted to | Permissions | Can set statuses | -|:------------- | :--------- | :-------------- | :----------------------- | -| Viewer | Everyone (anonymous access) | View public issues only | None | -| Updater | Users registered on dev.opencascade.org, in Open CASCADE project | View and comment issues | None | -| Reporter | Users registered on dev.opencascade.org, in Community project | View, report, and comment issues | New, Resolved, Feedback | -| Developer | OCC developers and (in Community project) external contributors who signed the CLA | View, report, modify, and handle issues | New, Assigned, Resolved, Reviewed, Feedback | -| Tester | OCC engineer devoted to certification testing | View, report, modify, and handle issues | Assigned, Tested, Feedback | -| Maintainer | Person responsible for a project or OCCT component | View, report, modify, and handle issues | New, Resolved, Reviewed, Tested, Closed, Feedback | -| Bugmaster | Person responsible for Mantis issue tracker, integrations, certification, and releases | Full access | All statuses | +PR titles should follow the pattern ` - `, for example: -According to his access level, the user can participate in the issue handling process under different roles, as described below. + Modeling - Modify surface evaluation + Visualization - Fix crash on empty shape display + Data Exchange - Add support for STEP AP242 edition 4 -@section occt_contribution_workflow Standard workflow for an issue +The group identifies the OCCT module or component affected by the change. +The summary should be a short, imperative description of what the change does. -@subsection occt_contribution_workflow_general General scheme +@section occt_contribution_workflow Standard Pull Request Workflow -
-@figure{OCCT_ContributionWorkflow_V3_image001.svg,"Standard life cycle of an issue",360} -
- -@subsection occt_contribution_workflow_issue Issue registration +@subsection occt_contribution_workflow_overview Overview -An issue is registered in Mantis bugtracker by the **Reporter** with definition of the necessary attributes (see also @ref occt_contribution_app): +The contribution workflow follows these steps: -**Category** -- indicates the OCCT component, to which the issue relates. - (If in doubt, assign to OCCT:Foundation Classes.) +1. **Fork and Branch**: Fork the OCCT repository and create a feature branch. +2. **Develop**: Implement the change following @ref occt_contribution__coding_rules "Coding Rules". +3. **Test**: Run existing tests to ensure no regressions. Create a test case when applicable (see @ref occt_contribution__tests "Automated Test System"). +4. **Create Draft PR**: Submit a Draft Pull Request on GitHub. CI/CD tests will run automatically. +5. **Ready for Review**: When the change is complete and CI/CD passes, mark the PR as "Ready for Review". +6. **Code Review**: A maintainer reviews the change. Feedback is provided as PR comments. +7. **Address Feedback**: If changes are requested, update the PR. The CI/CD will re-run. +8. **Merge**: Once approved and all checks pass, the PR is merged. -**Severity** -- indicates the impact of the issue in the context where it was discovered. +@subsection occt_contribution_workflow_draft Draft Pull Request -**Profile** -- specifies the configuration, on which the problem was detected. -For specific configurations it is possible to specify separately platform, OS, and version. -These fields can be left empty if the issue is not configuration-specific. -Additional details relevant for the environment where the issue is reproduced (such as compiler version, bitness, etc.) can be provided in the **Description**. +Start with a Draft PR to signal that the work is in progress. CI/CD pipelines will run on every push, providing early feedback on build and test results. -**Products Version** -- defines the OCCT version, on which the problem has been detected. +Create the PR from your fork's feature branch to the `IR` branch of the official repository. -It is preferable to indicate the version of the earliest known official release where the problem can be reproduced. -If the issue is reported on the current development version of OCCT, the current development version should be used (for convenience, this version is marked by asterisk in Mantis). - -@note OCCT version number can be consulted in the file Standard_Version.hxx (value of OCC_VERSION_COMPLETE macro). +@subsection occt_contribution_workflow_review Code Review -**Assign to** -- developer to whom the issue will be assigned. - By default, it is set to **Maintainer** of the OCCT component selected in **Category** field. +When the Draft PR is ready, mark it as "Ready for Review": -**Target Version** -- defines the target version for the fix to be provided. - By default, it is set to the current version under development. +- A reviewer will examine the changes for correctness, compliance with @ref occt_contribution__coding_rules "Coding Rules", and completeness. +- Review comments are posted as PR comments. Use GitHub's "Request changes" or "Approve" features. +- Address review feedback by pushing additional commits to the branch. CI/CD re-runs automatically. -**Summary** -- a short, one sentence description of the issue. - -The **Summary** has a limit of 128 characters. -It should be informative and useful for the developers. -It is not allowed to mention the issue originator, and in particular the customer, in the name of the registered issue. +@subsection occt_contribution_workflow_merge Merge -A good practice is to start the issue with indication of the relevant component (OCCT module, package, class etc.) to better represent its context. +After approval and successful CI/CD checks, the PR is merged by a maintainer. +PRs are typically squashed into a single commit on the IR branch. -The summary should be given in imperative mood when it can be formulated as goal to be achieved or action to be done. -In particular, this applies to feature requests and improvements, for instance: +@subsection occt_contribution_workflow_ci CI/CD Testing -> *Visualization - provide a support of zoom persistent selection* +The following automated checks run on every PR: +- Build on multiple platforms (Windows, Linux, macOS) +- Coding style verification (clang-format) +- DRAW test suite execution -If the issue reports a problem, the summary should be given in Present Simple. -If reported problem is believed to be a regression, it is recommended to indicate this in the summary, like this: +Results are visible in the GitHub Actions tab of the PR. -> [Regression in 6.9.0] *IGES - Export of a reversed face leads to wrong data* +@subsection occt_contribution_workflow_branch Branch Naming -**Description** -- should contain a detailed definition of the nature of the registered issue depending on its type. +There are no restrictions on branch names. Choose a descriptive name that reflects your change (e.g., `fix-empty-shape-crash`, `add-step-ap242-ed4`). -For a bug it is required to submit a detailed description of the incorrect behavior, including the indication of the cause of the problem (if known at this stage), and details on the context where the issue has been detected. +@subsection occt_contribution_workflow_commit Commit Messages -For a feature or integration request it is necessary to describe the proposed feature in details (as much as possible at that stage), including the changes required for its implementation and the main features of the new functionality. +Commit messages should be descriptive. The recommended format: -Example: + Modeling - Fix crash in BRepAlgoAPI_Fuse on empty shapes -> *Currently selection does not work correctly for non-zoomable objects (those defined using transform persistence). To provide correct selection for such objects, first-level (object) BVH structures must be updated on each camera change, and frustum must be rebuilt accordingly.* +The commit description should explain: +- **Problem**: What was wrong +- **Change**: What was modified and why +- **Result**: The expected behavior after the fix -@note In the description and notes to the issues you can refer to another issue by its ID prefixed by number sign (e.g.: #12345), and refer to a note by its ID prefixed by tilde (e.g.: ~20123). -These references will be expanded by Mantis into links to the corresponding issue or note. -When the number sign or the tilde followed by digits are a part of a normal text, add a space before digits (e.g.: "face # 12345 contains ~ 1000 edges") to avoid this conversion. +@subsection occt_contribution_workflow_code Requirements to the Code -**Steps To Reproduce** -- allows describing in detail how to reproduce the issue. +The change should comply with OCCT @ref occt_contribution__coding_rules "Coding Rules". +Re-formatting of unrelated code should be avoided unless done in a dedicated PR. -This information is crucial for the developer to investigate the cause of the problem and to create the test case. -The optimal approach is to give a sequence of @ref occt_user_guides__test_harness "DRAW Test Harness" commands to reproduce the problem in DRAW. -This information can also be provided as a DRAW Tcl script attached to the issue (in **Upload File** field). +@subsection occt_contribution_workflow_test Providing a Test Case -**Additional information and documentation updates** -- any additional information, remarks to be taken into account in Release Notes, etc.. +For functional changes, a test case should be created (unless an existing test already covers it). +See @ref testmanual_intro_quick_create "Creating a New Test" for instructions. -**Upload File** -- allows attaching the shapes, snapshots, scripts, documents, or modified source files of OCCT. +Test data files (CAD models, etc.) should be attached to the GitHub Issue or PR. -This field can be used to attach a prototype test case in form of a Tcl script for DRAW, a C++ code which can be organized in DRAW commands, sample shapes, documents describing proposed change or analysis of the problem, or other data required for reproduction of the issue. -Where applicable, pictures demonstrating a problem and/or desired result can be attached. - -The newly registered issue gets status **NEW** and is assigned to the person indicated in the **Assign to** field. +@subsection occt_contribution_workflow_doc Updating Documentation -@subsection occt_contribution_workflow_assign Assigning the issue +If the change affects documented functionality, the corresponding documentation in the `dox/` directory should be updated in the same PR. -The description of the new issue is checked by the **Maintainer** and if it is feasible, he may assign the issue to a **Developer**. -Alternatively, any user with **Developer** access level or higher can assign the issue to himself if he wants to provide a solution. - -The recommended way to handle contributions is that the **Reporter** assigns the issue to himself and provides a solution. +Changes that break API compatibility must be documented in @ref occt__upgrade "Upgrade from previous OCCT versions". -The **Maintainer** or **Bugmaster** can close or reassign the issue (in **FEEDBACK** state) to the **Reporter** after it has been registered, if its description does not contain sufficient details to reproduce the bug or explain the need of the new feature. -That decision shall be documented in the comments to the issue in the Bugtracker. +@section occt_contribution_issue_attrs Reporting Issues -The assigned issue has status **ASSIGNED**. +Open issues through the GitHub web interface using the provided issue templates: -@subsection occt_contribution_workflow_fix Resolving the issue +- **Bug Report** - for reproducible defects. The template asks for a description, expected and actual behavior, a sample script or code, OS, compiler, bitness and OCCT version. +- **Feature Request** - for new functionality or enhancements. The template asks for a description, use case, expected benefits and any additional context. -The **Developer** responsible for the issue assigned to him provides a solution including: +Templates apply the appropriate labels automatically; there is no need to set them by hand. Maintainers may add further classification labels (component, priority, etc.) during triage. -* Changes in the code, with appropriate comments; -* Test case (when applicable) and data necessary for its execution; -* Changes in the user and developer guides (when necessary). +@section occt_contribution_nonstd Additional Notes -The change is integrated to branch named CRxxxxx (where **xxxxx** is issue number) in the OCCT Git repository, based on current master, and containing a single commit with the appropriate description. -Then the issue is switched to **RESOLVED** for further review and testing. +@subsection occt_contribution_nonstd_rebase Updating Branches -The following sub-sections describe this process, relevant requirements and options, in more details. +If your branch falls behind IR, rebase it: -@subsubsection occt_contribution_workflow_fix_code Requirements to the code modification - -The amount of code affected by the change should be limited to the changes required for the bug fix or improvement. -Change of layout or re-formatting of the existing code is allowed only in the parts where meaningful changes related to the issue have been made. + git fetch upstream + git rebase upstream/IR -@note If deemed useful, re-formatting or cosmetic changes affecting considerable parts of the code can be made within a dedicated issue. +Force-push the updated branch: -The changes should comply with the OCCT @ref occt_contribution__coding_rules "Codng Rules". -It is especially important to comment the code properly so that other people can understand it easier. + git push --force origin -The modification should be tested by running OCCT tests (on the platform and scope available to **Developer**) and ensuring absence of regressions. -In case if modification affects results of some existing test case and the new result is correct, -such test case should be updated to report OK (or BAD), as described in @ref testmanual_details_results "Automated Test System / Interpretation of Test Results". - -@subsubsection occt_contribution_workflow_fix_test Providing a test case +@subsection occt_contribution_nonstd_feedback Handling Feedback -For modifications affecting OCCT functionality, a test case should be created (unless already exists) and included in the commit or patch. -See @ref testmanual_intro_quick_create "Automated Test System / Creating a New Test" for relevant instructions. +Review feedback is provided as PR comments. Address each comment by: +- Pushing a fix commit to the same branch +- Replying to the comment thread explaining the resolution +- Resolving the conversation when done -The data files required for a test case should be attached to the corresponding issue in Mantis (i.e. not included in the commit). - -When the test case cannot be provided for any reason, the maximum possible information on how the problem can be reproduced and how to check the fix should be provided in the **Steps to Reproduce** field of an issue. - -@subsubsection occt_contribution_workflow_fix_doc Updating user and developer guides - -If the change affects a functionality described in @ref user_guides "User Guides", the corresponding user guide should be updated to reflect the change. - -If the change affects OCCT test system, build environment, or development tools described in @ref build_upgrade "Build, Debug and Upgrade" or @ref contribution "Contribution", the corresponding guide should be updated. - -The changes that break compatibility with the previous versions of OCCT (i.e. affecting API or behavior of existing functionality in the way that may require update of existing applications based on an earlier official release of OCCT to work correctly) should be described in the document @ref occt__upgrade "Upgrade from previous OCCT versions". -It is recommended to add a sub-section for each change described. -The description should provide the explanation of the incompatibility introduced by the change, and describe how it can be resolved (at least, in known situations). -When feasible, the automatic upgrade procedure (adm/upgrade.tcl) can be extended by a new option to perform the required upgrade of the dependent code automatically. - -@subsubsection occt_contribution_workflow_fix_git Submission of change as a Git branch - -The modification of sources should be provided in the dedicated branch of the official OCCT Git repository. - -The branch should contain a single commit, with the appropriate commit message (see @ref occt_contribution_workflow_fix_commit "Requirements to the commit message" below). - -In general, this branch should be based on the recent version of the master branch. -It is highly preferable to submit changes basing on the current master. -In case if the fix is implemented on the previous release of OCCT, the branch can be based on the corresponding tag in Git, instead of the master. - -The branch name should be composed of letters **CR** (abbreviation of "Change Request") followed by the issue ID number (without leading zeros). -It is possible to add an optional suffix to the branch name after the issue ID, e.g. to distinguish between several versions of the fix (see @ref occt_contribution_nonstd_rebase). - -See @ref occt_contribution__git_guide "Guide to using GIT" for help. - -@note When a branch with the name given according to the above rule is pushed to Git, a note is automatically added to the corresponding issue in Mantis, indicating the person who has made the push, the commit hash, and (for new commits) the description. - -@subsubsection occt_contribution_workflow_fix_commit Requirements to the commit message - -The commit message posted in Git constitutes an integral part of both the fix and the release documentation. - -The first line of the commit message should contain the Summary of the issue (starting with its ID followed by colon, e.g. "0022943: Bug in TDataXtd_PatternStd"), followed by an empty line. - -The following lines should provide a description of the context and details on the changes made. -The contents and the recommended structure of the description depend on the nature of the bug. - -In a general case, the following elements should be present: -* **Problem** -- a description of the unwanted behavior; -* **Change** -- a description of the implemented changes, including the names of involved classes / methods / enumerations etc.; -* **Result** -- a description of the current behavior (after the implementation). - -Example: - -> *0026330: BRepOffsetAPI_ThruSections creates invalid shape.* -> -> *Methods BRep_Tool::CurveOnSurface() and BRepCheck_Edge::InContext() now properly handle parametric range on a 3D curve when it is used to generate a p-curve dynamically (on a planar surface) and both the surface and the 3D curve have non-null locations.* - -Provide sufficient context so that potential user of the affected functionality can understand what has been changed and how the algorithm works now. -Describe reason and essence of the changes made, but do not go too deep into implementation details -- these should be reflected in comments in the code. - -@subsubsection occt_contribution_workflow_fix_resolve Marking issue as resolved - -To mark the change as ready for review and testing, the corresponding issue should be switched to **RESOLVED** state. -By default, the issue gets assigned to the **Maintainer** of the component, who is thus responsible for its review. -Alternatively, another person can be selected as a reviewer at this step. - -When the issue is switched to **RESOLVED**, it is required to update or fill the field **Steps to reproduce**. -The possible variants are: - -* The name of an existing or new test case (preferred variant); -* A sequence of DRAW commands; -* N/A (Not required / Not possible / Not applicable); -* Reference to an issue in the bug tracker of another project. - -@subsection occt_contribution_workflow_review Code review - -The **Reviewer** analyzes the proposed solution for applicability in accordance with OCCT @ref occt_contribution__coding_rules "Coding Rules" and examines all changes in the sources, test case(s), and documentation to detect obvious and possible errors, misprints, or violations of the coding style. - -If the Reviewer detects some problems, he can either: - -* Fix these issues and provide a new solution. - The issue can then be switched to **REVIEWED**. - - In case of doubt or possible disagreement the **Reviewer** can reassign the issue (in **RESOLVED** state) to the **Developer**, who then becomes a **Reviewer**. - Possible disagreements should be resolved through discussion, which is done normally within issue notes (or on the OCCT developer’s forum if necessary). - -* Reassign the issue back to the **Developer**, providing detailed list of remarks. The issue then gets status **ASSIGNED** and a new solution should be provided. - -If Reviewer does not detect any problems, or provides a corrected version, he changes status to **REVIEWED**. -The issue gets assigned to the **Bugmaster**. - -@subsection occt_contribution_workflow_test Testing - - The issues that are in **REVIEWED** state are subject of certification (non-regression) testing. - The issue is assigned to an OCCT **Tester** when he starts processing it. - - If the branch submitted for testing is based on obsolete status of the master branch, **Tester** @ref occt_contribution_nonstd_rebase "rebases" it on master HEAD. - In case of conflicts, the issue is assigned back to **Developer** in **FEEDBACK** status, requesting for a rebase. - - Certification testing includes: - * Addition of new data models (if required for a new test case) to the data base; - * Revision of the new test case(s) added by developer, and changes in the existing test cases included in commit. - The **Tester** can amend tests to ensure their correct behavior in the certification environment. - * Building OCCT on a sub-set of supported configurations (OS and compiler), watching for errors and warnings; - * Execution of tests on sub-set of supported platforms (at least, one Windows and one Linux configuration), watching for regressions; - * Building OCCT samples, watching for errors; - * Building and testing of OCC products based on OCCT. - -If the **Tester** does not detect problems or regressions, he changes the status to **TESTED** for further integration. - -If the **Tester** detects build problems or regressions, he changes the status to **ASSIGNED** and reassigns the issue to the **Developer** with a detailed description of the problems. -The **Developer** should analyze the reported problems and, depending on results of this analysis, either: -* Confirm that the detected problems are expected changes and they should be accepted as a new status of the code. Then the issue should be switched to **FEEDBACK** and assigned to the **Bugmaster**. -* Produce a new solution (see @ref occt_contribution_workflow_fix, and also @ref occt_contribution_nonstd_minor). - -@subsection occt_contribution_workflow_integrate Integration of a solution - -Before integration into the master branch of the repository the **Integrator** checks the following conditions: - * the change has been reviewed; - * the change has been tested without regressions (or with regressions treated properly); - * the test case has been created for this issue (when applicable), and the change has been rechecked on this test case; - * the change does not conflict with other changes integrated previously. - -If the result of check is successful the Integrator integrates the solution into the branch. -The integrations are performed weekly; integration branches are named following the pattern IR-YYYY-MM-DD. - -Each change is integrated as a single commit without preserving the history of changes made in the branch (by rebase, squashing all intermediate commits if any), however, preserving the author when possible. -This is done to have the master branch history plain and clean. -The following picture illustrates the process: - -@figure{OCCT_ContributionWorkflow_V3_image002.png,"Integration of several branches",420} - -The new integration branch is tested against possible regressions that might appear due to interference between separate changes. -When the tests are OK, the integration branch is pushed as the new master to the official repository. -The issue status is set then to **VERIFIED** and is assigned to the **Reporter** so that he could check the fix as integrated. - -The branches corresponding to the integrated fixes are removed from the repository by the **Bugmaster**. - -@subsection occt_contribution_workflow_close Closing an issue - -When possible, the **Reporter** should check whether the problem is actually resolved in the environment where it has been discovered, after the fix is integrated to master. -If the fix does not actually resolve the original problem, the issue in **VERIFIED** status can be reopened and assigned back to the **Developer** for rework. -The details on how to check that the issue is still reproducible should be provided. -However, if the issue does resolve the problem as described in the original report, but a similar problem is discovered for another input data or configuration, or the fix has caused a regression, that problem should be registered as a separate (@ref occt_contribution_nonstd_relate "related") issue. - -If the fix integrated to master causes regressions, **Bugmaster** can revert it and reopen the issue. - -The **Bugmaster** closes the issue after the regular OCCT Release, provided that the issue status is **VERIFIED** and the change was actually included in the release. -The final issue state is **CLOSED**. - -The field **Fixed in Version** of the issue is set to the OCCT version where it is fixed. - -@section occt_contribution_nonstd Additional workflow elements - -@subsection occt_contribution_nonstd_feedback Requesting more information or specific action - -If, at any step of the issue lifetime, the person responsible for it cannot process it due to absence of required information, expertise, or rights, he can switch it to status **FEEDBACK** and assign to the person who is (presumably) able to resolve the block. Some examples of typical situations where **FEEDBACK** is used are: - -* The **Maintainer** or the **Developer** requests for more information from the **Reporter** to reproduce the issue; -* The **Tester** requests the **Developer** or the **Maintainer** to help him in the interpretation of testing results; -* The **Developer** or the **Maintainer** asks the **Bugmaster** to close the issue that is found irrelevant or already fixed (see @ref occt_contribution_nonstd_autofix). - -In general, issues with status **FEEDBACK** should be processed as fast as possible, to avoid unjustified delays. - -@subsection occt_contribution_nonstd_relate Defining relationships between issues - -When two or more issues are related to each other, this relationship should be reflected in the issue tracker. -It is also highly recommended to add a note to explain the relationship. -Typical cases of relationships are: - -* Issue A is caused by previous fix made for issue B (A is a child of B); -* Issue A describes the same problem as issue B (A is a duplicate of B); -* Issues A and B relate to the same piece of code, functionality etc., in the sense that the fix for one of these issues will affect the other (A is related to B) - -When the fix made for one issue also resolves another one, these issues should be marked as related or duplicate. -In general, the duplicate issue should have the same status, and, when closed, be marked as fixed in the same OCCT version, as the main one. - -@subsection occt_contribution_nonstd_patch Submission of a change as a patch - -In some cases (if Git is not accessible for the contributor), external contributions can be submitted as a patch file (generated by *diff* command) or as modified sources attached to the Mantis issue. -The OCCT version, for which the patch is generated, should be clearly specified (e.g. as hash code of Git commit if the patch is based on an intermediate state of the master). - -@note Such contributions should be put to Git by someone else (e.g. the **Reviewer**), this may cause delay in their processing. - -@subsection occt_contribution_nonstd_rebase Updating branches in Git - -Updates of the existing branch (e.g. taking into account the remarks of the **Reviewer**, or fixing regressions) should be provided as new commits on top of previous state of the branch. - -It is allowed to rebase the branch on the new state of the master and push it to the repository under the same name (with --force option) provided that the original sequence of commits is preserved. - -When a change is squashed into a single commit (e.g. to be submitted for review), it should be pushed into a branch a with different name. - -The recommended approach is to add a numeric suffix (index) indicating the version of the change, e.g. "CR12345_5". -Usually it is worth keeping a non-squashed branch in Git for reference. - -To avoid confusions, the branch corresponding to the latest version of the change should have a greater index. - -@note Make sure to revise the commit message after squashing a branch, to keep it meaningful and comprehensive. - -@subsection occt_contribution_nonstd_minor Minor corrections - -In some cases review remarks or results of testing require only minor corrections to be done in the branch containing a change. -"Minor" implies that the correction does not impact the functionality and does not affect the description of the previously committed change. - -As an exception to general @ref occt_contribution_workflow_fix_git "single-commit rule", it is allowed to put such minor corrections on top of the existing branch as a separate commit, and re-submit it for further processing in the same branch, without squashing. - -Minor commits should have a single-line message starting with #. -These messages will be ignored when the branch is squashed at integration. - -Typical cases of minor corrections are: - -* Amendments of test cases (including those made by the **Tester** to adjust a test script to a specific platform); -* Trivial corrections of compilation warnings (such as removal of an unused variable); -* Addition or correction of comments or documentation; -* Corrections of code formatting (e.g. reversion of irrelevant formatting changes made in the main commit). - -@subsection occt_contribution_nonstd_autofix Handling non-reproducible issues - -Investigation of each issue starts with reproducing it on current development version (master). - -If it cannot be reproduced on the current master, but can be reproduced on one of previous releases (or previous state of the master), it is considered as solved by a change made for another issue. -If that "fixing" issue can be identified (e.g. by parsing Git log), it should be set as related to that issue. -The issue should be switched to **FEEDBACK** and assigned to the **Bugmaster** for further processing. - -The **Bugmaster** decides whether it is necessary to create a test case for that issue, and if so may assign it to the **Developer** or the **Tester** to create a test. -The issue then follows the standard workflow. - -Otherwise, if the issue is fixed in one of previous releases, the **Bugmaster** closes it setting the appropriate value in **Fixed in Version** field, or, if the issue is fixed after the last release, switches it to **VERIFIED** status. - -If the issue cannot be reproduced due to an unclear description, missing data, etc., it should be assigned back to the **Reporter** in **FEEDBACK** status, requesting for more information. -The **Reporter** should provide additional information within one month; after that time, if no new information is provided, the issue should be closed by the **Bugmaster** with resolution **Unable to reproduce**. - -@section occt_contribution_app Appendix: Issue attributes - -@subsection occt_contribution_app_category Category - -The category corresponds to the component of OCCT where the issue is found: - - | Category | Component | - | :--------------------------- | :----------------------------------------------------- | - | OCCT:Foundation Classes | Foundation Classes module | - | OCCT:Modeling Data | Modeling Data classes | - | OCCT:Modeling Algorithms | Modeling Algorithms, except shape healing and meshing | - | OCCT:Shape Healing | Shape Healing component (TKShapeHealing) | - | OCCT:Mesh | BRepMesh algorithm | - | OCCT:Data Exchange | Data Exchange module | - | OCCT:Visualization | Visualization module | - | OCCT:Application Framework | OCAF | - | OCCT:DRAW | DRAW Test Harness | - | OCCT:Tests | Automatic Test System | - | OCCT:Documentation | Documentation | - | OCCT:Coding | General code quality | - | OCCT:Configuration | Configuration, build system, etc. | - | OCCT:Releases | Official OCCT releases | - | Website:Tracker | OCCT Mantis issue tracker, tracker.dev.opencascade.org | - | Website:Portal | OCCT development portal, dev.opencascade.org | - | Website:Git | OCCT Git repository, git.dev.opencascade.org | - - -@subsection occt_contribution_app_severity Severity - - Severity shows at which extent the issue affects the product. - The list of used severities is given in the table below in the descending order. - - | Severity | Description | - | :---------- | :------------------------------------------------ | - | crash | Crash of the application or OS, loss of data | - | block | Regression corresponding to the previously delivered official version. Impossible operation of a function on any data with no work-around. Missing function previously requested in software requirements specification. Destroyed data. | - | major | Impossible operation of a function with existing work-around. Incorrect operation of a function on a particular dataset. Impossible operation of a function after intentional input of incorrect data. Incorrect behavior of a function after intentional input of incorrect data. | - | minor | Incorrect behavior of a function corresponding to the description in software requirements specification. Insufficient performance of a function. | - | tweak | Ergonomic inconvenience, need of light updates. | - | text | Non-conformance of the program code to the Coding Rules, mistakes and non-functional errors in the source text (e.g. unnecessary variable declarations, missing comments, grammatical errors in user manuals). | - | trivial | Cosmetic issues. | - | feature | Request for a new feature or improvement. | - | integration request | Requested integration of an existing feature into the product. | - | just a question | A question to be processed, without need of any changes in the product. | - -@subsection occt_contribution_app_status Status - - The bug statuses that can be applied to the issues are listed in the table below. - - | Status | Description | - | :------------------- | :----------------------------------------- | - | New | A new, just registered issue. | - | Acknowledged | Can be used to mark the issue as postponed. | - | Confirmed | Can be used to mark the issue as postponed. | - | Feedback | The issue requires more information or a specific action. | - | Assigned | Assigned to a developer. | - | Resolved | The issue has been fixed, and now is waiting for review. | - | Reviewed | The issue has been reviewed, and now is waiting for testing (or being tested). | - | Tested | The fix has been internally tested by the tester with success on the full non-regression database or its part and a test case has been created for this issue. | - | Verified | The fix has been integrated into the master of the corresponding repository | - | Closed + resolution | The fix has been integrated to the master. The corresponding test case has been executed successfully. The issue is no longer reproduced. | - -@subsection occt_contribution_app_resolution Resolution - - **Resolution** is set when the bug is closed. "Reopen" resolution is added automatically when the bug is reopened. - - | Resolution | Description | - |:--------------------- | :--------------------------------------------------------------------------- | - | Open | The issue is pending. | - | Fixed | The issue has been successfully fixed. | - | Reopened | The bug has been reopened because of insufficient fix or regression. | - | Unable to reproduce | The bug is not reproduced. | - | Not fixable | The bug cannot be fixed because e.g. it is a bug of third party software, OS or hardware limitation, etc. | - | Duplicate | The bug for the same issue already exists in the tracker. | - | Not a bug | It is a normal behavior in accordance with the specification of the product. | - | No change required | The issue didn’t require any change of the product, such as a question issue.| - | Suspended | The issue is postponed (for Acknowledged status). | - | Documentation updated | The documentation has been updated to resolve a misunderstanding causing the issue. | - | Won’t fix | It is decided to keep the existing behavior. | +@subsection occt_contribution_nonstd_relate Related Issues +If your PR relates to an existing GitHub issue, use "Closes #123" or "Fixes #456" in the PR description to automatically link and close it on merge. diff --git a/dox/contribution/contribution_workflow/images/OCCT_ContributionWorkflow_V3_image001.svg b/dox/contribution/contribution_workflow/images/OCCT_ContributionWorkflow_V3_image001.svg deleted file mode 100644 index b9595e808d..0000000000 --- a/dox/contribution/contribution_workflow/images/OCCT_ContributionWorkflow_V3_image001.svg +++ /dev/null @@ -1,1609 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - image/svg+xml - - - - - - - - - YES, bug - - - Reporter - provides - more info - - - No - t clear: - - more info - - requested - - - Developer resolves - - the issue - - - Reporter registers an issue - - - - New - - - - - Resolved - - - - Ma - intainer - - checks - - the - description - - - - Feedback - - - - - - - - YES, fixed - - - Reporter - - is not satisfied - with - - the - fix - - - YES, fixed - , no regressions - - - Tester - is not satisfied - with - the - fix - - - Integrator merges the fix to trunk - - - Tester verifies the solution - - - - - Tested - - - - Integration to the trunk - - Verified - - - - - Fixed? - - - - - Conflict ? - - - - YES, fixed - - - - Assigned - - - Reviewer - - verifies the solution - - - - - Reviewer - - is not - satisfied with - the fix - - - - - Good - ? - - - - Reviewed - - - + Resolution - - - - Delivery of the release - - Closed - - - YES, code is good - - - Reporter can re - - - check the fix - - - - - OK - ? - - - - - Conflict with other - change is detected - - - - - - YES, fix provided - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Clear? - Fix provided? - - diff --git a/dox/contribution/contribution_workflow/images/OCCT_ContributionWorkflow_V3_image002.png b/dox/contribution/contribution_workflow/images/OCCT_ContributionWorkflow_V3_image002.png deleted file mode 100644 index d4dc06aa10..0000000000 Binary files a/dox/contribution/contribution_workflow/images/OCCT_ContributionWorkflow_V3_image002.png and /dev/null differ diff --git a/dox/contribution/documentation/documentation.md b/dox/contribution/documentation/documentation.md index b7836d811b..1c5bed6d43 100644 --- a/dox/contribution/documentation/documentation.md +++ b/dox/contribution/documentation/documentation.md @@ -28,17 +28,17 @@ This document provides practical guidelines for generation and editing of OCCT u You need to have the following software installed to generate the documentation. **Tcl/Tk** -Version 8.5 or 8.6: https://www.tcl.tk/software/tcltk/download.html +Version 8.6.3+: https://www.tcl.tk/software/tcltk/download.html **Doxygen** -Version 1.8.4 or above: http://www.doxygen.nl/download.html +Version 1.8.4 or above: https://www.doxygen.nl/download.html **Dot** Part of Graphviz software, used by Doxygen for generation of class diagrams in Reference Manual: https://www.graphviz.org/download/ -**MiKTeX** or other package providing **pdflatex** command (only needed for generation of PDF documents): https://miktex.org/download +**LaTeX distribution** (e.g. TeX Live, MikTeX, MacTeX) providing **pdflatex** command (only needed for generation of PDF documents): https://www.latex-project.org/get -**Inkscape** (only needed for generation of PDF documents containing SVG images): http://www.inkscape.org/download +**Inkscape** (optionally needed for generation of PDF documents containing SVG images): https://inkscape.org When generating PDF documentation, **pdflatex** and **inkscape** executables should be accessible by PATH variable. You can use *custom.bat* file to add necessary paths to the *PATH* variable. @@ -51,60 +51,33 @@ We recommend setting option "Install missing packages on-the-fly" to "Ask me fir On the first run of **pdflatex** it will open a dialog window prompting for installation of missing packages. Follow the instructions to proceed (define proxy settings if needed, select a mirror site to download from, etc.). -**MathJax** is used for rendering math formulas in browser (HTML and CHM outputs): http://www.mathjax.org. +**MathJax** is used for rendering math formulas in browser (HTML and CHM outputs): https://www.mathjax.org. By default MathJAX scripts and fonts work on-line and no installation of MathJAX is necessary if Internet is accessible. -If you need to use OCCT documentation while off-line, you can install a local copy of MatJAX, see https://docs.mathjax.org/en/v2.7-latest/start.html#installing-your-own-copy-of-mathjax. -See \ref OCCT_DM_SECTION_A_9 for more details on inserting mathematical expressions. +If you need to use OCCT documentation while off-line, you can install a local copy of MathJax, see https://docs.mathjax.org/en/v2.7-latest/start.html#installing-your-own-copy-of-mathjax. +See @ref OCCT_DM_SECTION_A_9 for more details on inserting mathematical expressions. @section OCCT_DM_SECTION_2_1 Documentation Generation -Run command *gendoc* from command prompt (located in `adm` directory) to generate OCCT documentation. -The synopsis is: +OCCT documentation is generated via CMake targets. Configure the build with +`-DBUILD_DOC_Overview=ON` and/or other documentation options: - gendoc \[-h\] {-refman|-overview} \[-html|-pdf|-chm\] \[-m=|-ug=\] \[-v\] \[-s=\] \[-mathjax=\] - -Here the options are: +| CMake Target | Purpose | +|-------------|---------| +| `Overview` | HTML documentation for Overview and User Guides | +| `RefMan` | HTML class Reference Manual | +| `doc` | Combined documentation (Overview + RefMan) | -* Choice of documentation to be generated: - * -overview: To generate Overview and User Guides (cannot be used with -refman) - * -refman: To generate class Reference Manual (cannot be used with -overview) - -* Choice of output format: - * -html: To generate HTML files (default, cannot be used with -pdf or -chm) - * -pdf: To generate PDF files (cannot be used with -refman, -html, or -chm) - * -chm: To generate CHM files (cannot be used with -html or -pdf) - -* Additional options: - * -m=\: List of OCCT modules (separated with comma), for generation of Reference Manual - * -ug=\: List of MarkDown documents (separated with comma), to use for generation of Overview / User Guides - * -mathjax=\: To use local or alternative copy of MathJax - * -s=\: Specifies the Search mode of HTML documents; can be: none | local | server | external - * -h: Prints this help message - * -v: Enables more verbose output - -**Note** - -* In case of PDF output the utility generates a separate PDF file for each document; -* In case of HTML output the utility generates a common Table of contents containing references to all documents. -* In case of CHM output single CHM file is generated - -**Examples** - -To generate the output for a specific document specify the path to the corresponding MarkDown file (paths relative to *dox* sub-folder can be given), for instance: +**Examples:** +To generate the HTML Overview documentation: ~~~~ - > gendoc -overview -ug=dev_guides/documentation/documentation.md +cmake --build . --target Overview ~~~~ -To generate Reference Manual for the whole Open CASCADE Technology library, run: +To generate the HTML Reference Manual: ~~~~ - > gendoc -refman -~~~~ - -To generate Reference Manual for Foundation Classes and Modeling Data modules only, with search option, run: -~~~~ - > gendoc -refman -m=FoundationClasses,ModelingData,ModelingAlgorithms -s=local +cmake --build . --target RefMan ~~~~ @section OCCT_DM_SECTION_3 Documentation Conventions @@ -114,7 +87,7 @@ This section contains information about file format conventions, directories str @subsection OCCT_DM_SECTION_3_1 File Format The format used for documentation is MarkDown with Doxygen extensions. -The MarkDown files have a *.md extension and are based on rules described in \ref OCCT_DM_SECTION_A section. +The MarkDown files have a *.md extension and are based on rules described in @ref OCCT_DM_SECTION_A section. @subsection OCCT_DM_SECTION_3_2 Directory Structure @@ -138,39 +111,39 @@ The documentation is generated in subfolder *doc* : @section OCCT_DM_SECTION_4 Adding a New Document -Place a new document in the folder taking into account its logical position in the documentation hierarchy. For instance, the document *svn.md* about the use of SVN to work with OCCT source code can be placed into /dox/contribution/. +Place a new document in the folder taking into account its logical position in the documentation hierarchy. For instance, the document *new_feature.md* could be placed into /dox/user_guides/new_feature/. If there are images in the document, it should be placed in its own folder containing a subfolder for images. For instance: -* /dox/contribution/svn/ -- for *svn.md* file; -* /dox/contribution/svn/images/ -- for images. +* /dox/user_guides/new_feature/ -- for *new_feature.md* file; +* /dox/user_guides/new_feature/images/ -- for images. -Add a relative path to *svn.md* in file dox/FILES.txt. For instance +Add a relative path to the file in dox/FILES_HTML.txt (for HTML documentation). For instance: @verbatim -contribution/svn/svn.md +user_guides/new_feature/new_feature.md @endverbatim -**Note** that the order of paths to documents in *FILES.txt* is reproduced in the Table of Contents in the HTML output, thus they need to be placed logically. +**Note** that the order of paths to documents in *FILES_HTML.txt* is reproduced in the Table of Contents in the HTML output, thus they need to be placed logically. **Note** that you should specify a file tag, not the document name. See @ref OCCT_DM_SECTION_A_1 "Header and hierarchic document structure" section for details. @section OCCT_DOC_SECTION_5 Additional Resources -More information about OCCT can be found at http://www.opencascade.com and
http://dev.opencascade.org sites. +More information about OCCT can be found at https://www.opencascade.com and https://dev.opencascade.org sites. The information on formula syntax can be found at:
-http://en.wikipedia.org/wiki/Help:Displaying_a_formula +https://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 +https://www.doxygen.nl/manual/ @section OCCT_DM_SECTION_A Appendix 1: Document Syntax A document file in *.md format must start with a proper header defining a caption and a unique tag. @verbatim -Documentation System {#contribution__documentation} +Documentation System {#occt_contribution__documentation} ===================== @endverbatim @@ -386,7 +359,7 @@ Empty lines in the quoted text, if any, should not have trailing spaces after th @subsection OCCT_DM_SECTION_A_6 References To insert a reference to a website, it is sufficient to write an URL. -For example: http://en.wikipedia.org +For example: https://en.wikipedia.org To insert a reference to a document or its subsection, use command \@ref followed by the document or section tag name. For instance, @code @ref OCCT_DM_SECTION_A @endcode will be rendered as @ref OCCT_DM_SECTION_A. diff --git a/dox/contribution/git_guide/git_guide.md b/dox/contribution/git_guide/git_guide.md index bf18ce21f6..dfa78d413f 100644 --- a/dox/contribution/git_guide/git_guide.md +++ b/dox/contribution/git_guide/git_guide.md @@ -1,4 +1,4 @@ -Guide to installing and using Git for OCCT development {#occt_contribution__git_guide} +Guide to using Git for OCCT development {#occt_contribution__git_guide} ================================= @tableofcontents @@ -7,513 +7,209 @@ Guide to installing and using Git for OCCT development {#occt_contribution__git_ @subsection occt_gitguide_1_1 Purpose - The purpose of this document is to provide a practical introduction to Git - to OCCT developers who are not familiar with this tool - and to facilitate the use of the official OCCT Git repository for code contribution to OCCT. +This document provides a practical introduction to Git for OCCT contributors. +OCCT development is hosted on GitHub at https://github.com/Open-Cascade-SAS/OCCT. - It can be useful to learn more about Git concepts and tools from a book a or manual. - Many good books on Git can be found at https://git-scm.com/documentation - - For the experienced Git users it can be enough to read sections 1 and 3 - of this document to start working with the repository. - - Familiarize yourselves with the @ref occt_contribution__contribution_workflow "Contribution Workflow document" - that describes how Git is used for processing contributions to OCCT. - - This and related documents are available at the Resources page - of the OCCT development portal at https://dev.opencascade.org/index.php?q=home/resources. +For experienced Git users, sections 1 and 3 are sufficient to get started. +Please also read the @ref occt_contribution__contribution_workflow "Contribution Workflow" for the overall process. -@subsection occt_gitguide_1_2 Git URL +@subsection occt_gitguide_1_2 Repository URL - URL of the official OCCT source code Git repository (accessed by SSH protocol) is: - - gitolite@git.dev.opencascade.org:occt - - or - - ssh://gitolite@dev.opencascade.org/occt.git +The official OCCT Git repository: -@subsection occt_gitguide_1_3 Content + https://github.com/Open-Cascade-SAS/OCCT -The official repository contains: +Clone via HTTPS: - * The current certified version of OCCT: the "master" branch. This branch is updated by the Bugmaster only. Official OCCT releases are marked by tags. - * Topic branches created by contributors to submit changes for review / testing or for collaborative development. The topic branches should be named by the pattern "CR12345" where 12345 is the ID of the relevant issue registered in Mantis (without leading zeroes), and "CR" stands for "Change Request". The name can have an additional postfix used if more than one branch was created for the same issue. - * Occasionally topic branches with non-standard names can be created by the Bugmaster for special needs. + git clone https://github.com/Open-Cascade-SAS/OCCT.git -@subsection occt_gitguide_1_4 Short rules of use +Or via SSH: - The name specified in the user.name field in Git configuration should correspond - to your login name on the OCCT development portal. - This is important to clearly identify the authorship of commits. - (The full real name can be used as well; in this case add the login username in parentheses.) - - By default, contributors are allowed to push branches only with the names starting with CR - (followed by the relevant Mantis issue ID). - Possibility to work with other branches can be enabled by the Bugmaster on request. - - The branch is created by the developer in his local repository when the development of a contribution starts. - The branch for new developments is to be created from the current master. - The branch for integration of patches or developments based on an obsolete version - is created from a relevant tag or commit. The branch should be pushed to the official repo - only when sharing with other people (for collaborative work or review / testing) is needed. - - Rebasing the local branch to the current master is encouraged before the first submission - to the official repository. If rebasing was needed after the branch is pushed to the official repo, - the rebased branch should have a different name (use suffix). - - Integration of contributions that have passed certification testing is made exclusively by the Bugmaster. - Normally this is made by rebasing the contribution branch on the current master - and squashing it into a single commit. This is made to have the master branch history plain and clean, - following the general rule “one issue -- one commit”. - The description of the commit integrated to the master branch is taken from the Mantis issue - (ID, 'Summary', followed by the information from 'Documentation' field if present). - - In special cases when it is important to save the commits history in the branch - (e.g. in case of a long-term development integration) it can be integrated by merge (no fast-forward). - - The authorship of the contribution is respected by preserving the Author field of the commit when integrating. - Branches are removed from the official repository when integrated to the master. - The Bugmaster can also remove branches which have no commits during one-month period. - - The Bugmaster may ask the developer (normally the one who produced the contribution) - to rebase a branch on the current master, in the case if merge conflicts appear during integration. + git clone git@github.com:Open-Cascade-SAS/OCCT.git -@subsection occt_gitguide_1_5 Version of Git +@subsection occt_gitguide_1_3 Repository Content - The repository is tested to work with Git 1.7.6 and above. - Avoid using versions below 1.7.1 as they are known to cause troubles. +- **master** branch: the current development version. Official releases are marked by tags. +- **IR** branch: the weekly integration branch where contributions are merged after review and CI/CD checks. +- Topic branches for feature development, bug fixes, and improvements. -@section occt_gitguide_2 Installing Tools for Work with Git +@subsection occt_gitguide_1_4 Quick Rules -@subsection occt_gitguide_2_1 Windows platform +- Configure your Git user name and email so that commits are properly attributed: + ~~~~ + git config --global user.name "Your Full Name" + git config --global user.email "your@email.com" + ~~~~ +- Create a fork of the repository and push your branches to your fork. +- Submit changes via Pull Requests (PRs). +- Branches that pass review and CI/CD checks are merged by maintainers (typically squashed into a single commit per PR). - Installation of Git for Windows (provided by MSysGit project) is required. - - In addition, it is recommended to install TortoiseGit to work with Git on Windows. - If you do not install TortoiseGit or any other GUI tool, - you can use GitGui and Gitk GUI tools delivered with Git and available on all platforms. +@section occt_gitguide_2 Setting Up Git -@subsubsection occt_gitguide_2_1_1 Installation of Git for Windows +@subsection occt_gitguide_2_1 Prerequisites - Download Git for Windows distributive from https://git-for-windows.github.io/ - During the installation: +- Install Git from https://git-scm.com/downloads +- On Windows, Git for Windows is recommended, optionally with TortoiseGit for GUI support. +- On Linux and macOS, use your system package manager or the Git packages recommended by your distribution. +- Configure your identity before creating commits: - * Check-in "Windows Explorer integration" options: - * "Git Bash Here"; - * "Git GUI Here". - * To avoid a mess in your PATH, we recommend selecting "Run Git from Windows Prompt" in the environment settings dialog: - * In "Configuring the line ending conversions" dialog, select "Checkout Windows-style, commit Unix style endings". - - Note that by default Git user interface is localized to the system default language. - If you prefer to work with the English interface, remove or rename .msg localization file - in subdirectories *share/git-gui/lib/msgs* and *share/gitk/lib/msgs* of the Git installation directory. - - Before the first commit to the OCCT repository, make sure that your User Name in the Git configuration file (file .gitconfig in the $HOME directory) is equal to your username on the OCCT development portal. + ~~~~ + git config --global user.name "Your Full Name" + git config --global user.email "your@email.com" + ~~~~ -@subsubsection occt_gitguide_2_1_2 Installation and configuration of TortoiseGit +- On Windows, keep line endings predictable for cross-platform patches: - Download TortoiseGit distributive from https://tortoisegit.org/download/. - Launch the installation. + ~~~~ + git config --global core.autocrlf true + git config --global core.safecrlf true + ~~~~ - * Select your SSH client. Choose option - * "OpenSSH, Git default SSH Client" if you prefer to use command-line tools for SSH keys generation, or - * "TortoisePLink, coming from Putty, integrates with Windows better" if you prefer to use GUI tool (PuttyGen, see 3.2). - * Complete the installation. - - TortoiseGit integrates into Windows Explorer, thus it is possible to use context menu in Windows Explorer to access its functionality: - -@figure{OCCT_GitGuide_V2_image005.png,"",100} - +If you use TortoiseGit or another graphical client, configure the same user name, email address, and SSH client in that tool. - - Note that if you have installed MSysGit or have Git installed in non-default path, - on the first time you use TortoiseGit you may get the message demanding to define path to Git. - In such case, click on **Set MSysGit path** button and add the path to git.exe - and path to MigGW libraries in the Settings dialog. +@subsection occt_gitguide_2_2 Authentication - * After the installation select Start -> Programs -> TortoiseGit Settings to configure TortoiseGit. - - Select Git->Config to add your user name and Email address to the local .gitconfig file - - @figure{OCCT_GitGuide_V2_image006.png,"",320} - - Optionally, you can set up TortoiseGit to use visual diff utility for SVG images used in OCCT documentation. - For that, click on item "Diff Viewer" in the Settings dialog, then click button "Advanced..." in the right tab to add a new record with the following parameters: - - Extension: .svg - - External program: <path_to_OCCT>\\adm\\svgdiff.bat %%base %%mine %%bname %%yname - -@figure{OCCT_GitGuide_V2_svgdiff.png,"",320} - -@subsection occt_gitguide_2_2 Linux platform - - We assume that Linux users have Git already installed and available in the *PATH*. - - Make sure to configure Git so that the user name is equal to your username - on the OCCT development portal, and set SafeCrLf option to true: +GitHub supports both HTTPS and SSH remotes. +HTTPS is usually the simplest option for cloning and pushing through Git Credential Manager. +SSH is convenient when you already use SSH keys: ~~~~ - > git config --global user.name "Your User Name" - > git config --global user.email your@mail.address - > git config --global your@mail.address +ssh-keygen -t ed25519 -C "your@email.com" ~~~~ -@section occt_gitguide_3 Getting access to the repository - -@subsection occt_gitguide_3_1 Prerequisites - - Access to the repository is granted to the users who have signed the Contributor License Agreement. - - The repository is accessed by SSH protocol, thus you need to register your public SSH key - on the development portal to get access to the repository. - - SSH keys are used for secure authentication of the user when accessing the Git server. - Private key is the one stored on the user workstation (optionally encrypted). - Open (or public) key is stored in the user account page on the web site. - When Git client accesses the remote repository through SSH, - it uses this key pair to identify the user and acquire relevant access rights. - - Normally when you have Git installed, you should have also SSH client available. - On Unix/Linux it is installed by default in the system. - On Windows it is typical to have several SSH clients installed; - in particular they are included with Cygwin, Git, TortoiseGit. - - It is highly recommended to use the tools that come - with the chosen Git client for generation of SSH keys. - Using incompatible tools (e.g. *ssh-keygen.exe* from Cygwin for code generation, - and TortoiseGit GUI with a default Putty client for connection to server) - may lead to authentication problems. - -@subsection occt_gitguide_3_2 How to generate a key - -@subsubsection occt_gitguide_3_2_1 Generating key with Putty - - Use this option if you have installed TortoiseGit (or other GUI Git client on Windows) - and have chosen “TortoisePLink” (or other Putty client) as SSH client during installation. - - To generate the key with this client, run **Puttygen** (e.g. from Start menu -> TortoiseGit -> Puttygen), - then click **Generate** and move mouse cursor over the blank area until the key is generated. - -@figure{OCCT_GitGuide_V2_image007.png,"Putty key generator",320} - - After the key is generated, you will see GUI controls to define the public key comment - and / or specify the password for the private key protection. - When done, save both the public and the private key to the files of your choice - (make sure to store your private key in a secure place!). - - Copy the public key as shown by Puttygen to the clipboard to add it in your account. - Do not copy the Putty public key file content -- it is formatted in a way not suitable for the web site. - -@subsubsection occt_gitguide_3_2_2 Generating key with command-line tools - - Use this option if you work on Linux or if you have chosen “OpenSSH” as SSH client - during installation of TortoiseGit (or other Windows tool). - - Make sure that you have *ssh* and *ssh-keygen* commands in the path. - On Windows, you might need to start **Git Bash** command prompt window. - - Use the following command to generate SSH keys: -~~~~ - > ssh-keygen -t rsa -C "your@mail.address" -~~~~ - - The last argument is an optional comment, which can be included with the public key and used to distinguish between different keys (if you have many). The common practice is to put here your mail address or workstation name. - - The command will ask you where to store the keys. It is recommended to accept the default path $HOME/.ssh/id_rsa. Just press **Enter** for that. You will be warned if a key is already present in the specified file; you can either overwrite it by the new one, or stop generation and use the old key. - - If you want to be on the safe side, enter password to encrypt the private key. You will be asked to enter this password each time you use that key (e.g. access a remote Git repository), unless you use the tool that caches the key (like TortoiseGit). If you do not want to bother, enter an empty string. - - On Windows, make sure to note the complete path to the generated files (the location of your $HOME might be not obvious). Two key files will be created in the specified location (by default in $HOME/.ssh/): - - * *id_rsa* -- private key - * *id_rsa.pub* -- public key - - The content of the public key file (one text line) is the key to be added to the user account on the site (see below). - -@subsubsection occt_gitguide_3_2_3 Generating key with Git GUI - - GitGUI (standard GUI interface included with Git) provides the option - to either generate the SSH key (if not present yet) or show the existing one. - Click Help/Show SSH key and copy the public key content for adding to the user account page (see below). - -@subsection occt_gitguide_3_3 Adding public key in your account - -Log in on the portal https://dev.opencascade.org and click on **My account** link to the right. If you have a Contributor status, you will see **SSH keys** tab to the right. - -Click on that tab, then click **Add a public key**, and paste the text of the public key (see above sections on how to generate the key) into the text box. - -Click **Save** to input the key to the system. - - Note that a user can have several SSH keys. - You can distinguish between these keys by the Title field ID; by default it is taken from SSH key comment. - It is typical to use your e-mail address or workstation name for this field; no restrictions are set by the portal. - - - **Note** that some time (5-10 min) is needed for the system - to update the configuration after the new key is added. - After that time, you can try accessing Git. - -@section occt_gitguide_4 Work with repository: developer operations - -@subsection occt_gitguide_4_1 General workflow - - To start working with OCCT source repository, you need to create its clone in your local system. - This cloned repository will manage your working copy of the sources - and provide you the means to exchange code between your clone and the origin. - - In most cases it is sufficient to have one clone of the repository; - your working copy will be updated automatically by Git when you switch branches. - - The typical development cycle for an issue is as follows: - - * Create a new branch for your development, basing on the selected version of the sources - (usually the current master) and switch your working copy to it - * Develop and test your change. - * Do as many commits in your branch as you feel convenient; - the general recommendation is to commit every stable state (even incomplete), to record the history of your development. - * Push your branch to the repository when your development is complete or when you need to share it with other people (e.g. for review) - * Before the first push, rebase your local branch on the latest master; - consider collapsing the history in one commit unless you think the history of your commits is interesting for others. - Make sure to provide a good commit message. - * Do not amend the commits that have been already pushed in the remote repository, - If you need to rebase your branch, commit the rebased branch under a different name, and remove the old branch. - - You can switch to another branch at any moment - (unless you have some uncommitted changes in the working copy) - and return back to the branch when necessary (e.g. to take into account review remarks). - Note that only the sources that are different between the switched branches will be modified, - thus required recompilation should be reasonably small in most cases. - -@subsection occt_gitguide_4_2 Cloning official repository - - Clone the official OCCT repository in one of following ways: - - * From command line by command: +Add the generated public key to your GitHub account, then check access with: ~~~~ - > git clone gitolite@git.dev.opencascade.org:occt +ssh -T git@github.com ~~~~ - where \ is the path to the new folder which will be created for the repository. - - * In TortoiseGit: create a new folder, open it and right-click in the Explorer window, then choose **Git Clone** in the context menu: - -@figure{OCCT_GitGuide_V2_image009.png,"",320} +@subsection occt_gitguide_2_3 Fork and Clone - If you have chosen Putty as SSH client during TortoiseGit installation, check the **Load Putty Key** option and specify the location of the private key file saved by PuttyGen (see 3.2.1). This shall be done for the first time only. - - Note that on the first connection to the repository server you may be requested to enter a password for your private SSH key; further you can get a message that the authenticity of the host cannot be established and will be asked if you want to continue connecting or not. Choose **Yes** to continue. The host’s key will be stored in $HOME/.ssh/known_hosts file. +1. Fork the repository on GitHub: click **Fork** at https://github.com/Open-Cascade-SAS/OCCT +2. Clone your fork: -@subsection occt_gitguide_4_3 Branch creation + ~~~~ + git clone https://github.com/YOUR_USERNAME/OCCT.git + cd OCCT + ~~~~ - You need to create a branch when you are going to start development of a new change, - apply a patch, etc. It is recommended to fetch updates from the remote repository - before this operation, to make sure you work with the up-to-date version. - - Create a branch from the current master branch unless you need to base your development on a particular version or revision. +3. Add the upstream repository as a remote: -In the console: + ~~~~ + git remote add upstream https://github.com/Open-Cascade-SAS/OCCT.git + ~~~~ + +@section occt_gitguide_3 Development Workflow + +@subsection occt_gitguide_3_1 Create a Branch + +Always create branches from an up-to-date master: ~~~~ - > git checkout -b CR12345 origin/master -~~~~ - -In TortoiseGit: - * Go to the local copy of the repository. - * Right-click in the Explorer window, then choose **Git Create Branch**. - * Select **Base On** Branch *remotes/origin/master*. - -@figure{OCCT_GitGuide_V2_image012.png,"",320} - - Check option **Switch to new branch** if you are going to start working with the newly created branch immediately. - -@subsection occt_gitguide_4_4 Branch switching - - If you need to switch to another branch, use Git command checkout for that. - In the console: - -~~~~ - > git checkout CR12345 -~~~~ - - In TortoiseGit: right-click in the explorer window and select in the context menu **TortoiseGit** -> **Switch/Checkout**. - -@figure{OCCT_GitGuide_V2_image013.png,"",320} - - Note that in order to work with the branch locally you need to set option - **Create new branch** when you checkout the branch from the remote repository for the first time. - Option **Track** stores association between the local branch and the original branch in a remote repository. - -@subsection occt_gitguide_4_5 Committing branch changes - - Commit your changes locally as soon as a stable status of the work is reached. - Make sure to review carefully the committed changes beforehand to avoid unintentional commit of a wrong code. - - * In the console: - -~~~~ - > git diff - … - > git commit -a -m "Write meaningful commit message here" +git checkout master +git pull upstream master +git checkout -b my-feature-branch ~~~~ - Option -a tells the command to automatically include (stage) files - that have been modified or deleted, but it will omit the new files that might have been added by you. - To commit such new files, you must add (stage) them before commit command. +Use any descriptive name for your branch (e.g., `fix-empty-shape-crash`, `step-ap242-ed4`). - To find new unstaged files and them to commit, use commands: +@subsection occt_gitguide_3_2 Make Changes + +Develop your change, following @ref occt_contribution__coding_rules "OCCT Coding Rules". +Format your code using clang-format with the configuration provided in the repository. + +@subsection occt_gitguide_3_3 Commit + +Commit your changes with a meaningful message: ~~~~ - > git status -s - ?? file1.hxx - ?? file2.cxx - > git add file1.hxx file2.cxx +git add . +git commit -m "Modeling - Fix crash in BRepAlgoAPI_Fuse on null shapes" ~~~~ - * In TortoiseGit: right-click in the explorer window and select in the context menu Git Commit -> CR…: - -@figure{OCCT_GitGuide_V2_image014.png,"",320} +The first line should follow the `Group - Summary` format (see @ref occt_contribution__contribution_workflow "Contribution Workflow"). +Provide a detailed description in the commit body if needed. - Unstaged files will be shown if you check the option ‘Show Unversioned Files’. - Double-click on each modified file to see the changes to be committed (as a difference vs. the base version). +@subsection occt_gitguide_3_4 Push and Create a Pull Request -@subsection occt_gitguide_4_6 Pushing branch to the remote repository - - When the code developed in your local branch is ready for review, - or you need to share it with others, push your local changes to the remote repository. - - * In the console: +Push your branch to your fork: ~~~~ - > git push "origin" CR12345:CR12345 +git push origin my-feature-branch ~~~~ - * In TortoiseGit: right-click in the explorer window and select in the context menu, TortoiseGit -> **Push** +Then create a Pull Request on GitHub: -@figure{OCCT_GitGuide_V2_image015.png,"",320} +- Go to your fork on GitHub +- Click **New Pull Request** +- Set the base to `Open-Cascade-SAS/OCCT/IR` and compare to your branch +- Start with a **Draft PR** to indicate work in progress +- When ready, click **Ready for Review** -Note that Git forbids pushing a branch if the corresponding remote branch already exists and has some changes, which are not in the history of your local branch. This may happen in different situations: - * You have amended the last commit which is already in the remote repository. If you are sure that nobody else uses your branch, push again with **Force** option. - * You have rebased your branch, so that now it is completely different from the branch in the remote repository. In this case, push it under a different name (add a suffix): - -@figure{OCCT_GitGuide_V2_image016.png,"",320} +@subsection occt_gitguide_3_5 CI/CD and Review - Then remove the original remote branch so that other people recognize that it has been replaced by the new one. For that, select TortoiseGit -> **Push** again, select an empty line for your local branch name, - and enter the name of the branch to be removed in **Remote** field: +The CI/CD pipeline runs automatically on every push: +- Build checks (Windows, Linux, macOS) +- Code style verification (clang-format) +- DRAW test suite - * The other developer has committed some changes in the remote branch. In this case, **Pull** changes from the remote repository to have them merged with your version, and push your branch after it is successfully merged. +Results appear in the GitHub Actions tab of the PR. -@subsection occt_gitguide_4_7 Synchronizing with remote repository +A reviewer examines the changes and provides feedback as PR comments. +Address feedback by pushing new commits to the same branch. +CI/CD re-runs automatically. + +@subsection occt_gitguide_3_6 Merge + +Once approved and all checks pass, a maintainer merges the PR. +PRs are typically squashed into a single commit on IR. + +@subsection occt_gitguide_3_7 Keep Your Fork Updated + +Regularly sync your fork with upstream: - Maintain your repository synchronized with the remote one and clean unnecessary stuff regularly. - - Use Git command *fetch* with option *prune* to get the update of all branches from the remote repository and to clean your local repository from the remote branches that have been deleted. - - * In the console: ~~~~ - > git fetch --prune -~~~~ - - * In TortoiseGit: right-click in the explorer window and select in the context menu **TortoiseGit** -> **Fetch**. Check in **Prune** check-box. - -@figure{OCCT_GitGuide_V2_image018.png,"",320} - - If the branch you are working with has been changed in the remote repository, use Git command *pull* to get the remote changes and merge them with your local branch. - - This operation is required in particular to update your local master branch when the remote master changes. - - * In console: -~~~~ - > git pull +git checkout master +git pull upstream master +git push origin master ~~~~ - * In TortoiseGit: right-click in the explorer window and select in the context menu **TortoiseGit** -> **Pull**. +@section occt_gitguide_4 Rebasing -@figure{OCCT_GitGuide_V2_image019.png,"",320} +If your branch falls behind IR, rebase it: -Note that the local branches of your repository are the primary place, where your changes are stored until they get integrated to the official version of OCCT (master branch). The branches submitted to official repository are for collaborative work, review, and integration -- that repository should not be used for long-term storage of incomplete changes. - -Remove the local branches that you do not need any more. Note that you cannot delete the current branch. It means that you need to switch to another one (e.g. master) if the branch you are going to delete is the current one. - - * In the console: ~~~~ - > git branch -d CR12345 +git checkout my-feature-branch +git pull --rebase upstream IR ~~~~ - - * In TortoiseGit: right-click in the explorer window and select in the context menu **TortoiseGit** -> **Git Show Log**. -@figure{OCCT_GitGuide_V2_image020.png,"",420} +If conflicts occur, resolve them manually, then: - Select **All branches** check-box to view all branches. - Right-click on the branch you want to delete and select **Delete** item in the context menu. - -Note that many functions described above can be accessed from the Log View, which is a very convenient tool to visualize and manage branches. +~~~~ +git add . +git rebase --continue +~~~~ -@subsection occt_gitguide_4_8 Applying a fix made on older version of OCCT +After rebasing, force-push to your fork: -If you have a fix made on a previous version of OCCT, perform the following sequence of operations to prepare it for testing and integration to the current development version: - * Identify the version of OCCT on which the fix has been made. In most cases, this will be an OCCT release, e.g. OCCT 6.7.0. - * Find a tag or a commit corresponding to this version in the Git history log of the master branch. - * Create a branch basing on this tag or commit. In TortoiseGit history log: right-click on the base commit, then select **Create branch at this version**. - -@figure{OCCT_GitGuide_V2_image021.png,"",320} +~~~~ +git push --force origin my-feature-branch +~~~~ - * Check option **Switch to the new branch** to start working within the new branch immediately, or switch to it separately afterwards. - * Put your fix in the working copy, build and check that it works, then commit to the branch. - * Rebase the branch on the current master. In TortoiseGit: right-click on the working directory, choose **TortoiseGit** -> **Rebase**, select *remotes/origin/master* as UpStream revision, and click **Start**: - -@figure{OCCT_GitGuide_V2_image022.png,"",320} +**Note:** Do not force-push if others are working on the same branch. -Note that you can get some conflicts during rebase. To resolve them, double-click on each conflicted file (highlighted by red in the file list) to open visual merge tool. Switch between conflicting fragments by red arrows, and for each one decide if the code of one or both conflicting versions is to be taken. +@section occt_gitguide_5 Cleanup -@subsection occt_gitguide_4_9 Rebasing with history clean-up +After your PR is merged, delete the local and remote branch: -At some moments you might need to rebase your branch on the latest version of the master. - -We recommend rebasing before the first submission of the branch for review or when the master has diverged substantially from your branch. - -Rebasing is a good occasion to clean-up the history of commits in the branch. Consider collapsing (squashing, in terms of Git) the history of your branch into a single commit unless you deem that having separate commits is important for your future work with the branch or its code reviewing. Git also allows changing the order of commits, edit commit contents and messages, etc. - -To rebase your branch into a single commit, you need to do the following: - * Switch to your branch (e.g. “CR12345”) - * In TortoiseGit history log, select a branch to rebase on (remotes/origin/master) and in the context menu choose **Rebase “CR12345” onto this**. - * In the **Rebase** dialog, check **Squash All**. You can also change the order of commits and define for each commit whether it should be kept (**Pick**), edited, or just skipped. - -@figure{OCCT_GitGuide_V2_image023.png,"",320} - - * Click **Start**. - * The process will stop if a conflict is detected. In that case, find files with status **Conflicted** in the list (marked by red), and double-click on them to resolve the conflict. When all conflicts are resolved, click **Continue**. - -@figure{OCCT_GitGuide_V2_image024.png,"",320} - - * At the end of the process, edit the final commit message (it should start from the issue ID and a description from Mantis in the first line, followed by a summary of actual changes), and click **Commit**. - -@figure{OCCT_GitGuide_V2_image025.png,"",320} - -@section occt_gitguide_5 Work with repository: Reviewer operations - -@subsection occt_gitguide_5_1 Review branch changes using GitWeb - - The changes made in the branch can be reviewed without direct access to Git, using GitWeb interface: - - * Open GitWeb in your web browser: https://git.dev.opencascade.org/gitweb/?p=occt.git - * Locate the branch you want to review among **heads** (click ‘…’ at the bottom of the page to see the full list). - * Click **log** (or **shortlog**) to see the history of the branch. - - **Note** that the branch can contain more than one commit, and you need to distinguish commits that belong to that branch (those to be reviewed) from the commits corresponding to the previous state of the master branch. Normally the first commit in the list that starts from the ID of the other issue indicates the branching point; commits above it are the ones to be reviewed. - - * Click **commitdiff** on each log entry to review the changes (highlighted with color format). - -@subsection occt_gitguide_5_2 Review branch changes with TortoiseGit - - Use of TortoiseGit is recommended for convenient code review: - - * Fetch the changes from the remote repository as described in @ref occt_gitguide_4_7 "Synchronizing with remote repository" section. - * Right-click on the repository, choose **TortoiseGit** -> **Show** log; - * Locate the remote branch you need to review; - * To review commits one-by-one, select each commit in the log. The list of changed files is shown at the bottom of the window; double-click on the file will open visual compare tool. - * To review all changes made in the branch at once, or to compare two arbitrary revisions, select the corresponding commits in the log (e.g. the last commit in the branch and the branching point), ight-click for the context menu, and choose **Compare revisions**. - -@figure{OCCT_GitGuide_V2_image026.png,"",320} +~~~~ +git checkout IR +git branch -d my-feature-branch +git push origin --delete my-feature-branch +~~~~ +Regularly prune stale remote tracking branches: +~~~~ +git fetch --prune upstream +~~~~ diff --git a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image005.png b/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image005.png deleted file mode 100644 index 8a60f27968..0000000000 Binary files a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image005.png and /dev/null differ diff --git a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image006.png b/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image006.png deleted file mode 100644 index 0f45bd6794..0000000000 Binary files a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image006.png and /dev/null differ diff --git a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image007.png b/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image007.png deleted file mode 100644 index a6fa5fb83a..0000000000 Binary files a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image007.png and /dev/null differ diff --git a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image009.png b/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image009.png deleted file mode 100644 index 056e099a0e..0000000000 Binary files a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image009.png and /dev/null differ diff --git a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image012.png b/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image012.png deleted file mode 100644 index 4c41eaf5ed..0000000000 Binary files a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image012.png and /dev/null differ diff --git a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image013.png b/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image013.png deleted file mode 100644 index 628ea06876..0000000000 Binary files a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image013.png and /dev/null differ diff --git a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image014.png b/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image014.png deleted file mode 100644 index d90dddabbb..0000000000 Binary files a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image014.png and /dev/null differ diff --git a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image015.png b/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image015.png deleted file mode 100644 index a07f9f2821..0000000000 Binary files a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image015.png and /dev/null differ diff --git a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image016.png b/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image016.png deleted file mode 100644 index 5d1637b24e..0000000000 Binary files a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image016.png and /dev/null differ diff --git a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image018.png b/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image018.png deleted file mode 100644 index 6a75712608..0000000000 Binary files a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image018.png and /dev/null differ diff --git a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image019.png b/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image019.png deleted file mode 100644 index 5312504c9c..0000000000 Binary files a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image019.png and /dev/null differ diff --git a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image020.png b/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image020.png deleted file mode 100644 index c47540a55c..0000000000 Binary files a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image020.png and /dev/null differ diff --git a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image021.png b/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image021.png deleted file mode 100644 index cb13e840d4..0000000000 Binary files a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image021.png and /dev/null differ diff --git a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image022.png b/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image022.png deleted file mode 100644 index 4becdaa4fe..0000000000 Binary files a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image022.png and /dev/null differ diff --git a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image023.png b/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image023.png deleted file mode 100644 index 9fb6b0de8e..0000000000 Binary files a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image023.png and /dev/null differ diff --git a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image024.png b/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image024.png deleted file mode 100644 index 11db66fb37..0000000000 Binary files a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image024.png and /dev/null differ diff --git a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image025.png b/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image025.png deleted file mode 100644 index 2ca3568e0a..0000000000 Binary files a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image025.png and /dev/null differ diff --git a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image026.png b/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image026.png deleted file mode 100644 index b5a1ad832c..0000000000 Binary files a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_image026.png and /dev/null differ diff --git a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_svgdiff.png b/dox/contribution/git_guide/images/OCCT_GitGuide_V2_svgdiff.png deleted file mode 100644 index d65c0620db..0000000000 Binary files a/dox/contribution/git_guide/images/OCCT_GitGuide_V2_svgdiff.png and /dev/null differ diff --git a/dox/contribution/tests/tests.md b/dox/contribution/tests/tests.md index 05ef3d56f8..63a40dd24c 100644 --- a/dox/contribution/tests/tests.md +++ b/dox/contribution/tests/tests.md @@ -7,7 +7,13 @@ This document provides OCCT developers and contributors with an overview and practical guidelines for work with OCCT automatic testing system. -Reading the Introduction should be sufficient for developers to use the test system to control non-regression of the modifications they implement in OCCT. Other sections provide a more in-depth description of the test system, required for modifying the tests and adding new test cases. +Reading the Introduction should be sufficient for developers to use the test system to control non-regression of the modifications they implement in OCCT. Other sections provide a more in-depth description of the test system, required for modifying the tests and adding new test cases. + +Tests are also run automatically on every Pull Request via GitHub Actions CI/CD. The results are visible in the CI/CD checks of the PR. See @ref occt_contribution__contribution_workflow "Contribution Workflow" for details. + +OCCT ships two complementary test runners: +- **DRAW Test Harness** (Tcl scripts under `tests/`) — the primary regression suite, described in this document. +- **OpenCascadeGTest** — a GoogleTest-based C++ unit test runner. Sources live under `src///GTests/`. Enable it at configure time with `-DBUILD_GTEST=ON`; the resulting executable is `OpenCascadeGTest` and is run directly (e.g. `./bin/OpenCascadeGTest --gtest_filter="*MyClass*"`). Use it for unit-level tests of C++ APIs that are awkward to drive from DRAW. @subsection testmanual_intro_basic Basic Information @@ -51,12 +57,12 @@ For this it is recommended to add a file *DrawAppliInit* in the directory which Example (Windows) -~~~~{.php} +~~~~ set env(CSF_TestDataPath) $env(CSF_TestDataPath)\;d:/occt/test-data ~~~~ Note that variable *CSF_TestDataPath* is set to default value at DRAW start, pointing at the folder $CASROOT/data. -In this example, subdirectory d:/occt/test-data is added to this path. Similar code could be used on Linux and Mac OS X except that on non-Windows platforms colon ":" should be used as path separator instead of semicolon ";". +In this example, subdirectory d:/occt/test-data is added to this path. Similar code could be used on Linux and macOS except that on non-Windows platforms colon ":" should be used as path separator instead of semicolon ";". All tests are run from DRAW command prompt (run *draw.bat* or *draw.sh* to start it). @@ -66,7 +72,7 @@ To run all tests, type command *testgrid* Example: -~~~~{.php} +~~~~ Draw[]> testgrid ~~~~ @@ -75,7 +81,7 @@ Each argument is a list of file masks separated with commas or spaces; by defaul Example: -~~~~{.php} +~~~~ Draw[]> testgrid bugs caf,moddata*,xde ~~~~ @@ -86,7 +92,7 @@ including the list of detected regressions and improvements, if any. Example: -~~~~{.php} +~~~~ Tests summary CASE 3rdparty export A1: OK @@ -105,7 +111,7 @@ The results and detailed logs of the tests are saved by default to a new subdire If necessary, a non-default output directory can be specified using option -outdir followed by a path to the directory. This directory should be new or empty; use option -overwrite to allow writing results in the existing non-empty directory. Example: -~~~~{.php} +~~~~ Draw[]> testgrid -outdir d:/occt/last_results -overwrite ~~~~ In the output directory, a cumulative HTML report summary.html provides links to reports on each test case. An additional report in JUnit-style XML format can be output for use in Jenkins or other continuous integration system. @@ -114,13 +120,13 @@ To re-run the test cases, which were detected as regressions on the previous run dirname is a path to the directory containing the results of the previous run. Only the test cases with *FAILED* and *IMPROVEMENT* statuses will be tested. Example: -~~~~{.php} +~~~~ Draw[]> testgrid -regress d:/occt/last_results ~~~~ Type help testgrid in DRAW prompt to get help on options supported by *testgrid* command: -~~~~{.php} +~~~~ Draw[3]> help testgrid testgrid: Run all tests, or specified group, or one grid Use: testgrid [groupmask [gridmask [casemask]]] [options...] @@ -143,7 +149,7 @@ To run a single test, type command *test* followed by names of group, grid, and Example: -~~~~{.php} +~~~~ Draw[1]> test blend simple A1 CASE blend simple A1: OK Draw[2]> @@ -156,7 +162,7 @@ To see intermediate commands and their output during the test execution, add one Type help test in DRAW prompt to get help on options supported by *test* command: -~~~~{.php} +~~~~ Draw[3]> help test test: Run specified test case Use: test group grid casename [options...] @@ -180,7 +186,7 @@ test: Run specified test case The detailed rules of creation of new tests are given in @ref testmanual_3 "Creation and modification of tests" chapter. The following short description covers the most typical situations: -Use prefix bug followed by Mantis issue ID and, if necessary, additional suffixes, for naming the test script, data files, and DRAW commands specific for this test case. +Use prefix bug followed by the issue ID and, if necessary, additional suffixes, for naming the test script, data files, and DRAW commands specific for this test case. 1. If the test requires C++ code, add it as new DRAW command(s) in one of files in *QABugs* package. 2. Add script(s) for the test case in the subfolder corresponding to the relevant OCCT module of the group *bugs* ($CASROOT/tests/bugs). See @ref testmanual_5_2 "the correspondence map". @@ -195,15 +201,15 @@ Use prefix bug followed by Mantis issue ID and, if necessary, additional 4. To check whether the data files needed for the test are already present in the database, use DRAW command *testfile* (see below). If the data file is already present, use it for a new test instead of adding a duplicate. If the data file(s) are not yet present in the test database, put them to a folder and add it to the environment variable *CSF_TestDataPath* to be found by the test system. - The location of the data files, which need to be accessed by OCC team and put to the official database, should be provided in the comment to Mantis issue, clearly indicating how the names of the files used by the test script match the actual names of the files. - The simplest way is to attach the data files to the Mantis issue, with the same names as used by the test script. + The location of the data files, which need to be accessed by OCC team and put to the official database, should be provided in the comment to the GitHub issue, clearly indicating how the names of the files used by the test script match the actual names of the files. + The simplest way is to attach the data files to the GitHub issue, with the same names as used by the test script. 5. Check that the test case runs as expected (test for fix: OK with the fix, FAILED without the fix; test for existing problem: BAD), and integrate it to the Git branch created for the issue. Example: * Added files: -~~~~{.php} +~~~~ git status -short A tests/bugs/heal/data/bug210_a.brep A tests/bugs/heal/data/bug210_b.brep @@ -213,7 +219,7 @@ A tests/bugs/heal/bug210_2 * Test script -~~~~{.php} +~~~~ puts "OCC210 (case 1): Improve FixShape for touching wires" restore [locate_data_file bug210_a.brep] a @@ -225,7 +231,7 @@ checkshape result DRAW command *testfile* should be used to check the data files used by the test for possible duplication of content or names. The command accepts the list of paths to files to be checked (as a single argument) and gives a conclusion on each of the files, for instance: -~~~~{.php} +~~~~ Draw[1]> testfile [glob /my/data/path/bug12345*] Collecting info on test data files repository... Checking new file(s)... @@ -318,7 +324,7 @@ additional Tcl functions used in test scripts. Example: -~~~~{.php} +~~~~ pload TOPTEST ;# load topological command set cpulimit 300 ;# set maximum time allowed for script execution ~~~~ @@ -332,7 +338,7 @@ Note: *TEST COMPLETED* string should be present in the output to indicate that t See @ref testmanual_3 "Creation and modification of tests" chapter for more information. Example: -~~~~{.php} +~~~~ if { [isdraw result] } { checkshape result } else { @@ -347,7 +353,7 @@ The test group may contain *parse.rules* file. This file defines patterns used f 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 should follow Tcl syntax, with a special exception that "\b" is considered as word limit (Perl-style), in addition to "\y" used in Tcl. +The regular expressions should follow Tcl syntax, with a special exception that "\\b" is considered as word limit (Perl-style), in addition to "\\y" used in Tcl. The rest of the line can contain a comment message, which will be added to the test report when this status is detected. @@ -403,7 +409,7 @@ Usually it sets variables specific for the current grid. Example: -~~~~{.php} +~~~~ set command bopfuse ;# command tested in this grid ~~~~ @@ -415,7 +421,7 @@ Usually it executes a specific sequence of commands common for all tests in the Example: -~~~~{.php} +~~~~ vdump $imagedir/${casename}.png ;# makes a snap-shot of AIS viewer ~~~~ @@ -450,7 +456,7 @@ and produces meaningful messages that can be used to check the validity of the r Example: -~~~~{.php} +~~~~ 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 @@ -479,12 +485,12 @@ 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 the frame of processing issues in OCCT Mantis tracker. +The new tests are usually added in the frame of processing issues in the OCCT issue tracker. Such tests in general should be added to group bugs, in the grid corresponding to the affected OCCT functionality. See @ref testmanual_5_2 "Mapping of OCCT functionality to grid names in group bugs". New grids can be added as necessary to contain tests for the functionality not yet covered by existing test grids. -The test case name in the bugs group should be prefixed by the ID of the corresponding issue in Mantis (without leading zeroes) with prefix *bug*. It is recommended to add a suffix providing a hint on the tested situation. If more than one test is added for a bug, they should be distinguished by suffixes; either meaningful or just ordinal numbers. +The test case name in the bugs group should be prefixed by the ID of the corresponding issue (without leading zeroes) with prefix *bug*. It is recommended to add a suffix providing a hint on the tested situation. If more than one test is added for a bug, they should be distinguished by suffixes; either meaningful or just ordinal numbers. Example: @@ -512,9 +518,9 @@ When you prepare a test script, try to minimize the size of involved data model. @subsection testmanual_3_3 Adding new DRAW commands If the test cannot be implemented using available DRAW commands, consider the following possibilities: -* If the existing DRAW command can be extended to enable possibility required for a test in a natural way (e.g. by adding an option to activate a specific mode of the algorithm), this way is recommended. This change should be appropriately documented in a relevant Mantis issue. -* If the new command is needed to access OCCT functionality not exposed to DRAW previously, and this command can be potentially reused (for other tests), it should be added to the package where similar commands are implemented (use *getsource* DRAW command to get the package name). The name and arguments of the new command should be chosen to keep similarity with the existing commands. This change should be documented in a relevant Mantis issue. -* Otherwise the new command implementing the actions needed for this particular test should be added in *QABugs* package. The command name should be formed by the Mantis issue ID prefixed by *bug*, e.g. *bug12345*. +* If the existing DRAW command can be extended to enable possibility required for a test in a natural way (e.g. by adding an option to activate a specific mode of the algorithm), this way is recommended. This change should be appropriately documented in a relevant GitHub issue. +* If the new command is needed to access OCCT functionality not exposed to DRAW previously, and this command can be potentially reused (for other tests), it should be added to the package where similar commands are implemented (use *getsource* DRAW command to get the package name). The name and arguments of the new command should be chosen to keep similarity with the existing commands. This change should be documented in a relevant GitHub issue. +* Otherwise the new command implementing the actions needed for this particular test should be added in *QABugs* package. The command name should be formed by the issue ID prefixed by *bug*, e.g. *bug12345*. Note that a DRAW command is expected to return 0 in case of a normal completion, and 1 (Tcl exception) if it is incorrectly used (e.g. a wrong number of input arguments). Thus if the new command needs to report a test error, this should be done by outputting an appropriate error message rather than by returning a non-zero value. File names must be encoded in the script rather than in the DRAW command and passed to the DRAW command as an argument. @@ -526,7 +532,7 @@ The test should run commands necessary to perform the tested operations, in gene 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: -~~~~{.php} +~~~~ # Simple test of fusing box and sphere box b 10 10 10 sphere s 5 @@ -546,7 +552,7 @@ For the messages generated in the script it is recommended to use the word 'Erro Example: -~~~~{.php} +~~~~ set expected_length 11 if { [expr $actual_length - $expected_length] > 0.001 } { puts "Error: The length of the edge should be $expected_length" @@ -571,7 +577,7 @@ During execution of the test, location of such data file can be constructed usin Example: -~~~~{.php} +~~~~ checkresult $result $::dirname/$::groupname/$::gridname/data/${::casename}.txt ~~~~ @@ -583,7 +589,7 @@ If the file is not found, *locate_data_file* will raise exception, and the test Example: -~~~~{.php} +~~~~ stepread [locate_data_file CAROSKI_COUPELLE.step] a * ~~~~ @@ -601,7 +607,7 @@ The test system can recognize an image file (snapshot) and include it in HTML lo The image format (defined by extension) should be *png*. Example: -~~~~{.php} +~~~~ xwd $::imagedir/${::casename}.png vdisplay result; vfit vdump $::imagedir/${::casename}-axo.png @@ -641,10 +647,10 @@ The new test created for an unsolved problem should return BAD. The new test cre @subsection testmanual_3_6 Marking BAD cases -If the test produces an invalid result at a certain moment then the corresponding bug should be created in the OCCT issue tracker located at https://tracker.dev.opencascade.org, and the problem should be marked as TODO in the test script. +If the test produces an invalid result at a certain moment then the corresponding bug should be created in the OCCT issue tracker on GitHub (https://github.com/Open-Cascade-SAS/OCCT/issues), and the problem should be marked as TODO in the test script. The following statement should be added to such a test script: -~~~~{.php} +~~~~ puts "TODO BugNumber ListOfPlatforms: RegularExpression" ~~~~ @@ -653,7 +659,7 @@ Here: * *ListOfPlatforms* is a list of platforms, at which the bug is reproduced (Linux, Windows, MacOS, or All). Note that the platform name is custom for the OCCT test system; Use procedure *checkplatform* to get the platform name. Example: -~~~~{.php} +~~~~ Draw[2]> checkplatform Windows ~~~~ @@ -661,7 +667,7 @@ Windows * RegularExpression is a regular expression, which should be matched against the line indicating the problem in the script output. Example: -~~~~{.php} +~~~~ puts "TODO #22622 Mandriva2008: Abort .* an exception was raised" ~~~~ @@ -673,7 +679,7 @@ To mark the test as BAD for an incomplete case (when the final *TEST COMPLETE* m Example: -~~~~{.php} +~~~~ puts "TODO OCC22817 All: exception.+There are no suitable edges" puts "TODO OCC22817 All: \\*\\* Exception \\*\\*" puts "TODO OCC22817 All: TEST INCOMPLETE" @@ -684,7 +690,7 @@ puts "TODO OCC22817 All: TEST INCOMPLETE" To check the obtained test output matches the expected results considered correct, add REQUIRED statement for each specific message. For that, the following statement should be added to the corresponding test script: -~~~~{.php} +~~~~ puts "REQUIRED ListOfPlatforms: RegularExpression" ~~~~ @@ -693,7 +699,7 @@ Here *ListOfPlatforms* and *RegularExpression* have the same meaning as in TODO The REQUIRED statement can also be used to mask the message that would normally be interpreted as error (according to the rules defined in *parse.rules*) but should not be considered as such within the current test. Example: -~~~~{.php} +~~~~ puts "REQUIRED Linux: Faulty shapes in variables faulty_1 to faulty_5" ~~~~ @@ -705,16 +711,16 @@ If output does not contain required statement, test case will be marked as FAILE @subsection testmanual_4_1 Running Tests on Older Versions of OCCT -Sometimes it might be necessary to run tests on the previous versions of OCCT (<= 6.5.4) 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 start-up, to load test commands and to define the necessary environment. +Sometimes it might be necessary to run tests on older OCCT versions 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 start-up, to load test commands and to define the necessary environment. -Note: in OCCT 6.5.3, file *DrawAppliInit* already exists in $CASROOT/src/DrawResources, new commands should be added to this file instead of a new one in the current directory. +Note: in some older OCCT versions, file *DrawAppliInit* already exists in $CASROOT/resources/DrawResources, new commands should be added to this file instead of a new one in the current directory. For example, let us assume that *d:/occt* contains an up-to-date version of OCCT sources with tests, and the test data archive is unpacked to *d:/test-data*): -~~~~{.php} +~~~~ set env(CASROOT) d:/occt set env(CSF_TestScriptsPath) $env(CASROOT)/tests -source $env(CASROOT)/src/DrawResources/TestCommands.tcl +source $env(CASROOT)/resources/DrawResources/TestCommands.tcl set env(CSF_TestDataPath) $env(CASROOT)/data;d:/test-data return ~~~~ @@ -728,7 +734,7 @@ You can extend the test system by adding your own tests. For that it is necessar Use Tcl command _path_separator to insert a platform-dependent separator to the path list. For example: -~~~~{.php} +~~~~ set env(CSF_TestScriptsPath) \ $env(TestScriptsPath)[_path_separator]d:/MyOCCTProject/tests set env(CSF_TestDataPath) \ @@ -749,7 +755,7 @@ Some test results are very dependent on the characteristics of the workstation, OCCT test system provides a dedicated command *testdiff* for comparing CPU time of execution, memory usage, and images produced by the tests. -~~~~{.php} +~~~~ testdiff dir1 dir2 [groupname [gridname]] [options...] ~~~~ Here *dir1* and *dir2* are directories containing logs of two test runs. @@ -771,7 +777,7 @@ Possible options are: Example: -~~~~{.php} +~~~~ Draw[]> testdiff results/CR12345-2012-10-10T08:00 results/master-2012-10-09T21:20 ~~~~ @@ -780,7 +786,7 @@ For that, for each parameter to be controlled, the test should produce the line Example of test code: -~~~~{.php} +~~~~ puts "COUNTER Memory heap usage at step 5: [meminfo h]" ~~~~ @@ -788,18 +794,6 @@ puts "COUNTER Memory heap usage at step 5: [meminfo h]" @subsection testmanual_5_1 Test groups -@subsubsection testmanual_5_1_1 3rdparty - -This group allows testing the interaction of OCCT and 3rdparty products. - -DRAW module: VISUALIZATION. - -| Grid | Commands | Functionality | -| :---- | :----- | :------- | -| export | vexport | export of images to different formats | -| fonts | vtrihedron, vcolorscale, vdrawtext | display of fonts | - - @subsubsection testmanual_5_1_2 blend This group allows testing blends (fillets) and related operations. @@ -856,9 +850,9 @@ Grids names are based on name of the command used, with suffixes: @subsubsection testmanual_5_1_4 bugs -This group allows testing cases coming from Mantis issues. +This group allows testing cases coming from the issue tracker. -The grids are organized following OCCT module and category set for the issue in the Mantis tracker. +The grids are organized following OCCT module and category set for the issue. See @ref testmanual_5_2 "Mapping of OCCT functionality to grid names in group bugs" chapter for details. @subsubsection testmanual_5_1_5 caf @@ -948,7 +942,7 @@ DRAW module: MODELING (package *BRepTest*). This group allows testing the functionality provided by *ShapeHealing* toolkit. -DRAW module: XSDRAW +DRAW module: TKXSDRAWSTEP | Grid | Commands | Functionality | | :---- | :----- | :------- | @@ -1083,20 +1077,20 @@ This group allows testing extended data exchange packages. @subsection testmanual_5_2 Mapping of OCCT functionality to grid names in group *bugs* -| OCCT Module / Mantis category | Toolkits | Test grid in group bugs | +| OCCT Module / Category | Toolkits | Test grid in group bugs | | :---------- | :--------- | :---------- | -| Application Framework | PTKernel, TKPShape, TKCDF, TKLCAF, TKCAF, TKBinL, TKXmlL, TKShapeSchema, TKPLCAF, TKBin, TKXml, TKPCAF, FWOSPlugin, TKStdLSchema, TKStdSchema, TKTObj, TKBinTObj, TKXmlTObj | caf | +| Application Framework | TKCDF, TKLCAF, TKCAF, TKBinL, TKXmlL, TKBin, TKXml, TKTObj, TKBinTObj, TKXmlTObj | caf | | Draw | TKDraw, TKTopTest, TKViewerTest, TKXSDRAW, TKDCAF, TKXDEDRAW, TKTObjDRAW, TKQADraw, DRAWEXE, Problems of testing system | draw | | Shape Healing | TKShHealing | heal | | Mesh | TKMesh, TKXMesh | mesh | | Data Exchange | TKDEIGES | iges | | Data Exchange | TKDESTEP | step | | Data Exchange | TKDESTL, TKDEVRML | stlvrml | -| Data Exchange | TKXSBase, TKXCAF, TKXCAFSchema, TKXmlXCAF, TKBinXCAF | xde | +| Data Exchange | TKXSBase, TKXCAF, TKXmlXCAF, TKBinXCAF | xde | | Foundation Classes | TKernel, TKMath | fclasses | | Modeling_algorithms | TKGeomAlgo, TKTopAlgo, TKPrim, TKBO, TKBool, TKHLR, TKFillet, TKOffset, TKFeat, TKXMesh | modalg | | Modeling Data | TKG2d, TKG3d, TKGeomBase, TKBRep | moddata | -| Visualization | TKService, TKV2d, TKV3d, TKOpenGl, TKMeshVS, TKNIS | vis | +| Visualization | TKService, TKV3d, TKOpenGl, TKMeshVS | vis | @subsection testmanual_5_3 Recommended approaches to checking test results @@ -1106,7 +1100,7 @@ This group allows testing extended data exchange packages. Run command *checkshape* on the result (or intermediate) shape and make sure that *parse.rules* of the test grid or group reports bad shapes (usually recognized by word "Faulty") as error. Example -~~~~{.php} +~~~~ checkshape result ~~~~ @@ -1115,27 +1109,27 @@ To check the number of faults in the shape command *checkfaults* can be used. Use: checkfaults shape source_shape [ref_value=0] The default syntax of *checkfaults* command: -~~~~{.php} +~~~~ checkfaults results a_1 ~~~~ The command will check the number of faults in the source shape (*a_1*) and compare it with number of faults in the resulting shape (*result*). If shape *result* contains more faults, you will get an error: -~~~~{.php} +~~~~ checkfaults results a_1 Error : Number of faults is 5 ~~~~ It is possible to set the reference value for comparison (reference value is 4): -~~~~{.php} +~~~~ checkfaults results a_1 4 ~~~~ If number of faults in the resulting shape is unstable, reference value should be set to "-1". As a result command *checkfaults* will return the following error: -~~~~{.php} +~~~~ checkfaults results a_1 -1 Error : Number of faults is UNSTABLE ~~~~ @@ -1144,7 +1138,7 @@ Error : Number of faults is UNSTABLE The maximal tolerance of sub-shapes of each kind of the resulting shape can be extracted from output of tolerance command as follows: -~~~~{.php} +~~~~ set tolerance [tolerance result] regexp { *FACE +: +MAX=([-0-9.+eE]+)} $tolerance dummy max_face regexp { *EDGE +: +MAX=([-0-9.+eE]+)} $tolerance dummy max_edgee @@ -1162,7 +1156,7 @@ Allowed options are: * -multi_tol -- tolerance multiplier. The default syntax of *checkmaxtol* command for comparison with the reference value: -~~~~{.php} +~~~~ checkmaxtol result -ref 0.00001 ~~~~ @@ -1171,7 +1165,7 @@ In the following example command *checkmaxtol* gets max tolerance among objects Then it chooses the maximum value between founded tolerance and value -min_tol (0.000001) and multiply it on the coefficient -multi_tol (i.e. 2): -~~~~{.php} +~~~~ checkmaxtol result -source {a_1 a_2} -min_tol 0.000001 -multi_tol 2 ~~~~ @@ -1179,7 +1173,7 @@ If the value of maximum tolerance more than founded tolerance for comparison, th Also, command *checkmaxtol* can be used to get max tolerance of the shape: -~~~~{.php} +~~~~ set maxtol [checkmaxtol result] ~~~~ @@ -1188,7 +1182,7 @@ set maxtol [checkmaxtol result] Use command *vprops, sprops,* or *lprops* to correspondingly measure volume, area, or length of the shape produced by the test. The value can be extracted from the result of the command by *regexp*. Example: -~~~~{.php} +~~~~ # check area of shape result with 1% tolerance regexp {Mass +: +([-0-9.+eE]+)} [sprops result] dummy area if { abs($area - $expected) > 0.1 + 0.01 * abs ($area) } { @@ -1204,7 +1198,7 @@ To check memory leak on a particular operation, run it in a cycle, measure the m The command *checktrend* (defined in *tests/bugs/begin*) can be used to analyze a sequence of memory measurements and to get a statistically based evaluation of the leak presence. Example: -~~~~{.php} +~~~~ set listmem {} for {set i 1} {$i < 100} {incr i} { # run suspect operation @@ -1222,7 +1216,7 @@ for {set i 1} {$i < 100} {incr i} { The following command sequence allows you to take a snapshot of the viewer, give it the name of the test case, and save in the directory indicated by Tcl variable *imagedir*. -~~~~{.php} +~~~~ vinit vclear vdisplay result @@ -1256,13 +1250,13 @@ Allowed options are: Note that is required to use either option -2d or option -3d. Examples: -~~~~{.php} +~~~~ checkview -display result -2d -path ${imagedir}/${test_image}.png checkview -display result -3d -path ${imagedir}/${test_image}.png checkview -display result_2d -2d v2d -path ${imagedir}/${test_image}.png ~~~~ -~~~~{.php} +~~~~ box a 10 10 10 box b 5 5 5 10 10 10 bcut result b a @@ -1270,7 +1264,7 @@ set result_vertices [explode result v] checkview -display result -2d -with ${result_vertices} -otherwise { a b } -l -path ${imagedir}/${test_image}.png ~~~~ -~~~~{.php} +~~~~ box a 10 10 10 box b 5 5 5 10 10 10 bcut result b a @@ -1290,7 +1284,7 @@ Allowed options are: * -tol N -- used tolerance (default -0.01); * -type N -- used type, possible values are "closed" and "opened" (default "closed"). -~~~~{.php} +~~~~ checkfreebounds result 13 ~~~~ @@ -1301,7 +1295,7 @@ Option -type N is used to select the type of counted free edges: closed o If the number of free edges in the resulting shape is unstable, the reference value should be set to "-1". As a result command *checkfreebounds* will return the following error: -~~~~{.php} +~~~~ checkfreebounds result -1 Error : Number of free edges is UNSTABLE ~~~~ @@ -1312,7 +1306,7 @@ Procedure *checkreal* checks the equality of two reals with a tolerance (relativ Use: checkreal name value expected tol_abs tol_rel -~~~~{.php} +~~~~ checkreal "Some important value" $value 5 0.0001 0.01 ~~~~ @@ -1336,7 +1330,7 @@ Allowed options are: the same sub-shapes with different location as different sub-shapes. * -m msg -- prints "msg" in case of error -~~~~{.php} +~~~~ checknbshapes result -vertex 8 -edge 4 ~~~~ @@ -1354,7 +1348,7 @@ This procedure checks color with tolerance (5x5 area). Next example will compare color of point with coordinates x=100 y=100 with RGB color R=1 G=0 B=0. If colors are not equal, procedure will check the nearest ones points (5x5 area) -~~~~{.php} +~~~~ checkcolor 100 100 1 0 0 ~~~~ @@ -1375,7 +1369,7 @@ Allowed options are: Options -l, -s and -v are independent and can be used in any order. Tolerance *epsilon* is the same for all options. -~~~~{.php} +~~~~ checkprops result -s 6265.68 checkprops result -s -equal FaceBrep ~~~~ @@ -1391,7 +1385,7 @@ Allowed options are: * -ref VALUE -- list of reference values for each parameter in *NAME*; * -eps EPSILON -- the epsilon defines relative precision of computation. -~~~~{.php} +~~~~ checkdump result -name {Center Axis XAxis YAxis Radii} -ref {{-70 0} {-1 -0} {-1 -0} {0 -1} {20 10}} -eps 0.01 ~~~~ @@ -1407,7 +1401,7 @@ Allowed options are: * -equal CURVE -- compares the length of input curves. Puts error if they are not equal; * -notequal CURVE -- compares the length of input curves. Puts error if they are equal. -~~~~{.php} +~~~~ checklength cp1 -l 7.278 checklength res -l -equal ext_1 ~~~~ @@ -1438,33 +1432,33 @@ Note that options -tri, -nod and -defl do not work together wi Examples: Comparison with some reference values: -~~~~{.php} +~~~~ checktrinfo result -tri 129 -nod 131 -defl 0.01 ~~~~ Comparison with another mesh: -~~~~{.php} +~~~~ checktrinfo result -ref [tringo a] ~~~~ Comparison of deflection with the max possible value: -~~~~{.php} +~~~~ checktrinfo result -max_defl 1 ~~~~ Check that the current values are not equal to zero: -~~~~{.php} +~~~~ checktrinfo result -tri -nod -defl ~~~~ Check that the number of triangles and the number of nodes are not equal to some specific values: -~~~~{.php} +~~~~ checktrinfo result -tri !10 -nod !8 ~~~~ It is possible to compare current values with reference values with some tolerances. Use options -tol_\* for that. -~~~~{.php} +~~~~ checktrinfo result -defl 1 -tol_abs_defl 0.001 ~~~~ diff --git a/dox/debug/debug.md b/dox/debug/debug.md index df8887fe42..51126582bb 100644 --- a/dox/debug/debug.md +++ b/dox/debug/debug.md @@ -11,10 +11,10 @@ This manual describes facilities included in OCCT to support debugging, and prov Many OCCT algorithms can produce extended debug messages, usually printed to cout. These include messages on internal errors and special cases encountered, timing etc. -In OCCT versions prior to 6.8.0 most of these messages were activated by compiler macro *DEB*, enabled by default in debug builds. -Since version 6.8.0 this is disabled by default but can be enabled by defining compiler macro *OCCT_DEBUG*. +In older OCCT versions most of these messages were activated by compiler macro *DEB*, enabled by default in debug builds. +This is now disabled by default but can be enabled by defining compiler macro *OCCT_DEBUG*. -To enable this macro on Windows when building with Visual Studio projects, edit file custom.bat and add the line: +To enable this macro on Windows, set it in the CMake configuration (e.g., using `adm/templates/custom.bat.main` as a template): set CSF_DEFINES=OCCT_DEBUG @@ -35,7 +35,7 @@ This feature can be activated by defining environment variable *CSF_DEBUG_BOP*, The diagnostic code checks validity of the input arguments and the result of each Boolean operation. When an invalid situation is detected, the report consisting of argument shapes and a DRAW script to reproduce the problematic operation is saved to the directory pointed by *CSF_DEBUG_BOP*. -Note that this feature does not applicable for UWP build. +Note that this feature is not applicable for UWP builds. @section occt_debug_call Functions for calling from debugger @@ -45,18 +45,18 @@ Note that all these functions accept pointer to variable as void* to allo @subsection occt_debug_call_draw Interacting with DRAW -Open CASCADE Test Harness or @ref occt_user_guides__test_harness "DRAW" provides an extensive set of tools for inspection and analysis of OCCT shapes and geometric objects and is mostly used as environment for prototyping and debugging OCCT-based algorithms. +Open CASCADE DRAW Test Harness or @ref occt_user_guides__test_harness "DRAW" provides an extensive set of tools for inspection and analysis of OCCT shapes and geometric objects and is mostly used as environment for prototyping and debugging OCCT-based algorithms. In some cases the objects to be inspected are available in DRAW as results of DRAW commands. In other cases, however, it is necessary to inspect intermediate objects created by the debugged algorithm. To support this, DRAW provides a set of commands allowing the developer to store intermediate objects directly from the debugger stopped at some point during the program execution (usually at a breakpoint). -~~~~{.php} +~~~~{.cpp} const char* Draw_Eval (const char *theCommandStr) ~~~~ Evaluates a DRAW command or script. A command is passed as a string parameter. -~~~~{.php} +~~~~{.cpp} const char* DBRep_Set (const char* theNameStr, void* theShapePtr) ~~~~ @@ -64,7 +64,7 @@ Sets the specified shape as a value of DRAW interpreter variable with the given - *theNameStr* -- the DRAW interpreter variable name to set. - *theShapePtr* -- a pointer to *TopoDS_Shape* variable. -~~~~{.php} +~~~~{.cpp} const char* DBRep_SetComp (const char* theNameStr, void* theListPtr) ~~~~ @@ -72,7 +72,7 @@ Makes a compound from the specified list of shapes and sets it as a value of DRA - *theNameStr* -- the DRAW interpreter variable name to set. - *theListPtr* -- a pointer to *TopTools_ListOfShape* variable. -~~~~{.php} +~~~~{.cpp} const char* DrawTrSurf_Set (const char* theNameStr, void* theHandlePtr) const char* DrawTrSurf_SetPnt (const char* theNameStr, void* thePntPtr) const char* DrawTrSurf_SetPnt2d (const char* theNameStr, void* thePnt2dPtr) @@ -90,7 +90,7 @@ All these functions are defined in *TKDraw* toolkit and return a string indicati The following functions are provided by *TKBRep* toolkit and can be used from debugger prompt: -~~~~{.php} +~~~~{.cpp} const char* BRepTools_Write (const char* theFileNameStr, void* theShapePtr) ~~~~ @@ -98,7 +98,7 @@ Saves the specified shape to a file with the given name. - *theFileNameStr* -- the name of the file where the shape is saved. - *theShapePtr* -- a pointer to *TopoDS_Shape* variable. -~~~~{.php} +~~~~{.cpp} const char* BRepTools_Dump (void* theShapePtr) const char* BRepTools_DumpLoc (void* theShapePtr) ~~~~ @@ -108,28 +108,28 @@ Dumps shape or its location to cout. The following function is provided by *TKMesh* toolkit: -~~~~{.php} +~~~~{.cpp} const char* BRepMesh_Dump (void* theMeshHandlePtr, const char* theFileNameStr) ~~~~ Stores mesh produced in parametric space to BREP file. -- *theMeshHandlePtr* -- a pointer to *occ::handle\* variable. +- *theMeshHandlePtr* -- a pointer to *BRepMesh_DataStructureOfDelaun* variable. - *theFileNameStr* -- the name of the file where the mesh is stored. The following functions are provided by *TKTopTest* toolkit: -~~~~{.php} -const char* MeshTest_DrawLinks(const char* theNameStr, void* theFaceAttr) -const char* MeshTest_DrawTriangles(const char* theNameStr, void* theFaceAttr) +~~~~{.cpp} +const char* MeshTest_DrawLinks(const char* theNameStr, void* theDataStruct) +const char* MeshTest_DrawTriangles(const char* theNameStr, void* theDataStruct) ~~~~ -Sets the edges or triangles from mesh data structure of type *occ::handle\* as DRAW interpreter variables, assigning a unique name in the form "_" to each object. +Sets the edges or triangles from mesh data structure as DRAW interpreter variables, assigning a unique name in the form "_" to each object. - *theNameStr* -- the prefix to use in names of objects. -- *theFaceAttr* -- a pointer to *occ::handle\* variable. +- *theDataStruct* -- a pointer to the mesh data structure variable. The following additional function is provided by *TKGeomBase* toolkit: -~~~~{.php} +~~~~{.cpp} const char* GeomTools_Dump (void* theHandlePtr) ~~~~ @@ -174,7 +174,7 @@ It is implemented in 'vaspect' and 'boundingbox' commands. Json output for Bnd_OBB (using command 'bounding v -obb -dumpJson'): -~~~~{.java} +~~~~{.json} "Bnd_OBB": { "Center": { "gp_XYZ": [1, 2, 3] @@ -199,14 +199,14 @@ Json output for Bnd_OBB (using command 'bounding v -obb -dumpJson'): @subsection occt_debug_vstudio_command Command window -Visual Studio debugger provides the Command Window (can be activated from menu View / Other Windows / Command Window), which can be used to evaluate variables and expressions interactively in a debug session (see https://msdn.microsoft.com/en-us/library/c785s0kz.aspx). Note that the Immediate Window can also be used but it has some limitations, e.g. does not support aliases. +Visual Studio debugger provides the Command Window (can be activated from menu View / Other Windows / Command Window), which can be used to evaluate variables and expressions interactively in a debug session (see https://learn.microsoft.com/en-us/visualstudio/ide/reference/command-window). Note that the Immediate Window can also be used but it has some limitations, e.g. does not support aliases. When the execution is interrupted by a breakpoint, you can use this window to call the above described functions in context of the currently debugged function. Note that in most cases you will need to specify explicitly context of the function by indicating the name of the DLL where it is defined. For example, assume that you are debugging a function, where local variable *TopoDS_Edge* *anEdge1* is of interest. The following set of commands in the Command window will save this edge to file *edge1.brep*, then put it to DRAW variable *e1* and show it maximized in the axonometric DRAW view: -~~~~{.php} +~~~~ >? ({,,TKBRep.dll}BRepTools_Write)("d:/edge1.brep",(void*)&anEdge1) 0x04a2f234 "d:/edge1.brep" >? ({,,TKDraw.dll}DBRep_Set)("e1",(void*)&anEdge1) @@ -217,7 +217,7 @@ The following set of commands in the Command window will save this edge to file For convenience it is possible to define aliases to commands in this window, for instance (here ">" is prompt provided by the command window; in the Immediate window this symbol should be entered manually): -~~~~{.php} +~~~~ >alias deval ? ({,,TKDraw}Draw_Eval) >alias dsetshape ? ({,,TKDraw}DBRep_Set) >alias dsetcomp ? ({,,TKDraw}DBRep_SetComp) @@ -233,7 +233,7 @@ For convenience it is possible to define aliases to commands in this window, for Note that aliases are stored in the Visual Studio user's preferences and it is sufficient to define them once on a workstation. With these aliases, the above example can be reproduced easier (note the space symbol after alias name!): -~~~~{.php} +~~~~ >saveshape ("d:/edge1.brep",(void*)&anEdge1) 0x04a2f234 "d:/edge1.brep" >dsetshape ("e1",(void*)&anEdge1) @@ -248,7 +248,7 @@ Note that there is no guarantee that the call will succeed and will not affect t Visual Studio provides a way to customize display of variables of different types in debugger windows (Watch, Autos, Locals, etc.). -In Visual Studio 2005-2010 the rules for this display are defined in file *autoexp.dat* located in subfolder *Common7\\Packages\\Debugger* of the Visual Studio installation folder (hint: the path to that folder is given in the corresponding environment variable, e.g. *VS100COMNTOOLS* for vc10). This file contains two sections: *AutoExpand* and *Visualizer*. The following rules can be added to these sections to provide more convenient display of some OCCT data types. +Customization rules are defined in XML-based *.natvis* files. OCCT provides a natvis file (*occt.natvis*) in the distribution for this purpose; Visual Studio loads it automatically when the project is opened. The following rules illustrate the display customization for OCCT data types. ### \[AutoExpand\] section @@ -344,7 +344,7 @@ Handle_TCollection_HAsciiString { } ~~~~ -In Visual Studio 2012 and later, visualizers can be put in a separate file in subdirectory *Visualizers*. See file *occt.natvis* for example. +In Visual Studio, visualizers can be put in a separate file in subdirectory *Visualizers*. See file *occt.natvis* for example. @section occt_debug_perf Performance measurement tools @@ -401,10 +401,10 @@ Example of configuration steps for Ubuntu: 6. When using UBSan, set environment variable UBSAN_OPTIONS to get stack traces: > export UBSAN_OPTIONS=print_stacktrace=1 -7. Run DRAW and perform tests as usual, keeping in mind that running with sanitizer is much heavier than normal build: -> ./draw.sh relwithdeb
+7. Source the build environment script and run DRAW; running under a sanitizer is much heavier than a normal build: +> source /env.sh && DRAWEXE -~~~~{.php} +~~~~{.tcl} Draw[]> testgrid -parallel 0 ~~~~ @@ -415,4 +415,4 @@ Known problems (as of CLang 6.0) are: @subsection occt_debug_sanitizers_windows Windows -Though CLang toolset is available in Visual Studio 2015 and newer, sanitizer do not seem to be available out of the box (last tested with VS 2019 16.2.3). +Clang toolset is available in Visual Studio 2019 and newer. Sanitizers may require manual installation via the Visual Studio Installer. diff --git a/dox/introduction/images/overview_3rdparty.png b/dox/introduction/images/overview_3rdparty.png deleted file mode 100644 index 099b22fb91..0000000000 Binary files a/dox/introduction/images/overview_3rdparty.png and /dev/null differ diff --git a/dox/introduction/images/overview_draw.png b/dox/introduction/images/overview_draw.png deleted file mode 100644 index 27cd5cda1d..0000000000 Binary files a/dox/introduction/images/overview_draw.png and /dev/null differ diff --git a/dox/introduction/images/overview_installation.png b/dox/introduction/images/overview_installation.png deleted file mode 100644 index 0f8a397f51..0000000000 Binary files a/dox/introduction/images/overview_installation.png and /dev/null differ diff --git a/dox/introduction/introduction.md b/dox/introduction/introduction.md index 51a23ffa08..08daf59224 100644 --- a/dox/introduction/introduction.md +++ b/dox/introduction/introduction.md @@ -1,4 +1,4 @@ -Introduction {#mainpage} +Introduction {#mainpage} ======== @tableofcontents @@ -46,7 +46,7 @@ This modular structure is illustrated in the diagram below. * @ref intro_overview_de "Data Exchange" module inter-operates with popular data formats and relies on @ref intro_overview_heal "Shape Healing" to improve compatibility between CAD software of different vendors; * @ref intro_overview_ocaf "Application Framework" module offers ready-to-use solutions for handling application-specific data (user attributes) and commonly used functionality (save/restore, undo/redo, copy/paste, tracking CAD modifications, etc). -In addition, @ref intro_overview_draw "Open CASCADE Test Harness", also called Draw, provides an entry point to the library and can be used as a testing tool for its modules. +In addition, @ref intro_overview_draw "Open CASCADE DRAW Test Harness", also called Draw, provides an entry point to the library and can be used as a testing tool for its modules. @subsection intro_overview_fclasses Foundation Classes @@ -143,7 +143,7 @@ Top-level API provides the following functionality: * Pipes -- general-form sweeps; * Lofting. -@figure{/introduction/images/0001.png "Shapes containing pipes with variable radius produced by sweeping"} +@figure{/introduction/images/0001.png,"Shapes containing pipes with variable radius produced by sweeping"} * Boolean Operations, which allow creating new shapes from the combinations of source shapes. For two shapes *S1* and *S2*: * *Common* contains all points that are in *S1* and *S2*; @@ -171,7 +171,7 @@ See the details in @ref occt_user_guides__modeling_algos "Modeling Algorithms Us - data structures and algorithms to build triangular surface mesh from *BRep* objects (shapes); - tools for displaying meshes with associated pre- and post-processor data (scalars or vectors). -Open CASCADE SAS also offers Advanced Mesh Products: +Open CASCADE SAS also offers Advanced Mesh Products (commercial product pages, URLs may change): - Open CASCADE Mesh Framework (OMF) - Express Mesh @@ -212,8 +212,8 @@ Here are a few examples of OCCT Visualization features: * View frustum culling, which skips the presentation outside camera at the rendering stage; * Back face culling, which reduces the rendered number of triangles and eliminates artifacts at shape boundaries. * Real-time ray tracing technique using recursive Whitted's algorithm and Bounded Volume Hierarchy effective optimization structure. -@figure{introduction/images/0002.png, "Real time visualization by ray tracing method"} -@figure{introduction/images/0012.png, "Simulation of a glass cover"} +@figure{/introduction/images/0002.png, "Real time visualization by ray tracing method"} +@figure{/introduction/images/0012.png, "Simulation of a glass cover"} For more details, see @ref occt_user_guides__visualization "Visualization User's Guide". @@ -239,13 +239,13 @@ This module handles various problems of interoperability between CAD systems, ca * **STL** converter translates Open CASCADE shapes to STL files. STL (STtereoLithography) format is widely used for rapid prototyping (3D printing). * @ref occt_user_guides__xde "Extended data exchange" (XDE) allows translating additional attributes attached to geometric data (colors, layers, names, materials etc). -* Advanced Data Exchange Components - are available in addition to standard Data Exchange interfaces to support interoperability and data adaptation (also using @ref intro_overview_heal "Shape Healing") with CAD software using the following proprietary formats: - * ACIS SAT - * Parasolid - * DXF - * IFC - * JT +* Advanced Data Exchange Components + are available in addition to standard Data Exchange interfaces to support interoperability and data adaptation (also using @ref intro_overview_heal "Shape Healing") with CAD software using the following proprietary formats (commercial product pages, URLs may change): + * ACIS SAT + * Parasolid + * DXF + * IFC + * JT These components are based on the same architecture as interfaces with STEP and IGES. @@ -306,9 +306,9 @@ OCAF organizes and embeds these attributes in a document. OCAF documents, in the For more details, see @ref occt_user_guides__ocaf "OCAF User's Guide". -@subsection intro_overview_draw Draw Test Harness +@subsection intro_overview_draw DRAW Test Harness -**Test Harness** or **Draw** is a convenient testing tool for OCCT libraries. +**DRAW Test Harness** (or **Draw**) is a convenient testing tool for OCCT libraries. It can be used to test and prototype various algorithms before building an entire application. It includes: - A command interpreter based on the TCL language; @@ -324,7 +324,7 @@ The basic commands provide general-purpose services such as: - Managing views; - Displaying objects. -In addition, **Test Harness** provides commands to create and manipulate curves and surfaces (geometry) and shapes, access visualization services, work with OCAF documents, perform data exchange, etc. +In addition, **DRAW Test Harness** provides commands to create and manipulate curves and surfaces (geometry) and shapes, access visualization services, work with OCAF documents, perform data exchange, etc. You can add custom commands to test or demonstrate any new functionalities, which you develop. @@ -333,7 +333,7 @@ For more details, see @ref occt_user_guides__test_harness "Draw Test Harness Man @section intro_req Requirements Open CASCADE Technology is designed to be highly portable and is known to work on wide range of platforms. -Current version is officially certified on Windows (x86-64), Linux (x86-64), OS X / macOS (x86-64, arm64), Android (arm64), and iOS (arm64) platforms. +Current version is officially certified on Windows (x86-64), Linux (x86-64), macOS (x86-64, arm64), Android (arm64), and iOS (arm64) platforms. The tables below describe the recommended software configurations for which OCCT is certified to work. @@ -341,29 +341,28 @@ The tables below describe the recommended software configurations for which OCCT | OS | Compiler | | --------- | ----------- | -| Windows | Microsoft Visual Studio: 2015 Update 3, 2017 1, 2019, 2022
, LLVM (ClangCL), GCC 4.3+ (Mingw-w64)| -| Linux | GNU gcc 4.3+
LLVM CLang 3.6+ | -| OS X / macOS | XCode 6 or newer | -| Android | NDK r12, GNU gcc 4.9 or newer | -| Web | Emscripten SDK 1.39 or newer (CLang) | +| Windows | Microsoft Visual Studio 2019 or 2022 (2022 preferred)
LLVM (ClangCL), GCC 7.3+ (MinGW-w64)| +| Linux | GCC 8.0+
Clang 7.0+ | +| macOS | Xcode 11.0 or newer (Apple Clang 11.0+) | +| Android | NDK r19+, Clang | +| Web | Emscripten SDK 3.0 or newer (Clang) | -1) VC++ 141 64-bit is used for regular testing and for building binary package of official release of OCCT on Windows. +1) Visual Studio 2022 (MSVC v143) 64-bit is used by the official CI for regular testing and for building binary packages on Windows. @subsection intro_req_libs Third-party libraries and tools The following third-party libraries and tools are not included in OCCT sources but are either required or can be optionally used for the indicated components of OCCT. -They are not needed if relevant component is not needed - it is possible building core OCCT modules without additional dependencies. +They are not needed if relevant component is not needed - it is possible to build core OCCT modules without additional dependencies. -Note that pre-built packages of many of the listed libraries are available at -https://dev.opencascade.org/resources/download/3rd-party-components +Pre-built third-party archives are attached to the OCCT GitHub release pages at https://github.com/Open-Cascade-SAS/OCCT/releases. Alternatively, configure the build with `-DBUILD_USE_VCPKG=ON` and OCCT will pull and build the required packages via [vcpkg](https://vcpkg.io) automatically based on the enabled `USE_*` options. | Component | Where to find | Used for | Purpose | | --------- | ------------- | -------- | -------------------- | -| CMake 3.1+ | https://cmake.org/ | Configuration | Build from sources | -| Intel oneTBB 2021.5.0 | https://github.com/oneapi-src/oneTBB/releases/tag/v2021.5.0 | All | Parallelization of algorithms (alternative to built-in thread pool) | +| CMake 3.16+ | https://cmake.org/ | Configuration | Build from sources | +| Intel oneTBB 2021+ | https://github.com/oneapi-src/oneTBB/releases/tag/v2021.5.0 | All | Parallelization of algorithms (alternative to built-in thread pool) | | OpenGL 3.3+, OpenGL ES 2.0+ | System | Visualization | Required for using 3D Viewer | | OpenVR 1.10+ | https://github.com/ValveSoftware/openvr | Visualization | VR (Virtual Reality) support in 3D Viewer | -| FreeType 2.4+ | https://www.freetype.org/download.html | Visualization | Text rendering in 3D Viewer | +| FreeType 2.10+ | https://www.freetype.org/download.html | Visualization | Text rendering in 3D Viewer | | FreeImage 3.17+ | https://sourceforge.net/projects/freeimage/files | Visualization | Reading/writing image files | | FFmpeg 3.1+ | https://www.ffmpeg.org/download.html | Visualization | Video recording | | VTK 6.1+ | https://www.vtk.org/download/ | IVtk | VTK integration module | @@ -371,8 +370,7 @@ https://dev.opencascade.org/resources/download/3rd-party-components | RapidJSON 1.1+ | https://rapidjson.org/ | Data Exchange | Reading glTF files | | Draco 1.4.1+ | https://github.com/google/draco | Data Exchange | Reading compressed glTF files | | Tcl/Tk 8.6.3+ | https://www.tcl.tk/software/tcltk/download.html | DRAW Test Harness | Tcl interpreter in Draw module | -| Qt 5.3.2+ | https://www.qt.io/download/ | Inspector and Samples | Inspector Qt samples and | -| Doxygen 1.8.5+ | https://www.doxygen.nl/download.html | Documentation | (Re)generating documentation | +| Doxygen 1.8.4+ | https://www.doxygen.nl/download.html | Documentation | (Re)generating documentation | | Graphviz 2.38+ | https://graphviz.org/ | Documentation | Generating dependency graphs | @subsection intro_req_hw Hardware @@ -380,7 +378,7 @@ https://dev.opencascade.org/resources/download/3rd-party-components | Component | Requirement | | --------- | ----------- | | Minimum memory | 512 MB, 1 GB recommended | -| Free disk space (complete installation) | 1,5 GB approx. | +| Free disk space (complete installation) | 2 GB approx. | On desktop, 3D viewer for optimal performance requires graphics processing unit (GPU) supporting OpenGL 3.3 or above. Ray tracing requires OpenGL 4.0+ or OpenGL 3.3+ with *GL_ARB_texture_buffer_object_rgb32* extension. @@ -407,47 +405,27 @@ The following subsections describe how OCCT can be installed from ready-to-use p @subsection intro_install_windows Windows -On Windows Open CASCADE Technology with binaries precompiled by Visual C++ 2017 -can be installed using installation procedure available on official download page. +On Windows, OCCT can be built from sources using CMake. +Pre-built binary packages for Visual Studio are available from the +[GitHub releases page](https://github.com/Open-Cascade-SAS/OCCT/releases). +Third-party dependencies can be automatically resolved via vcpkg by configuring CMake with `-DBUILD_USE_VCPKG=ON`. -**Recommendation:** +The source tree obtained from a Git clone contains the following top-level directories: -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). - -Full OCCT installation with reference documentation requires 1.8 Gb on disk. - -When the installation is complete, you will find the directories for 3rd party products -(some might be absent in case of custom installation) and the main **OCCT** directory: - -@figure{/introduction/images/overview_3rdparty.png} - -The contents of the OCCT-7.4.0 directory (called further "OCCT root", or $CASROOT) are as follows: - -@figure{/introduction/images/overview_installation.png, "The directory tree"} - - * **adm** This folder contains administration files, which allow rebuilding OCCT; - * **adm/cmake** This folder contains files of CMake building procedure; - * **adm/msvc** This folder contains Visual Studio projects for Visual C++ 2013, 2015, 2017, 2019 and 2022 which allow rebuilding OCCT under Windows platform in 32 and 64-bit mode; - * **adm/scripts** This folder contains auxiliary scripts for semi-automated building and packaging of OCCT for different platforms; - * **data** This folder contains CAD files in different formats, which can be used to test the OCCT functionality; - * **doc** This folder contains OCCT documentation in HTML and PDF format; - * **dox** This folder contains sources of OCCT documentation in plain text (MarkDown) format; - * **inc** This folder contains copies of all OCCT header files; - * **samples** This folder contains sample applications. - * **src** This folder contains OCCT source files. They are organized in folders, one per development unit; - * **tests** This folder contains scripts for OCCT testing. - * **tools** This folder contains sources of Inspector tool. - * **win64/vc14** This folder contains executable and library files built in optimize mode for Windows platform by Visual C++ 2015; + * **adm** Administration files for building and packaging OCCT; + * **data** CAD files in various formats for testing OCCT functionality; + * **doc** Documentation in HTML and PDF format; + * **dox** Documentation sources in Markdown format; + * **inc** Header files (generated during build); + * **samples** Sample applications; + * **src** OCCT source files, organized by module/toolkit/package; + * **tests** Draw Harness test scripts; @subsection intro_install_linux Linux OCCT is available as package "opencascade" in official repositories of many Linux distributions. -See https://repology.org/project/opencascade/versions for overview of available repositories. +See https://repology.org/project/opencascade-occt/versions for overview of available repositories. @subsection intro_install_mac macOS @@ -458,27 +436,15 @@ and MacPorts (https://ports.macports.org/port/opencascade/summary) repositories. To run any Open CASCADE Technology application you need to set the environment variables. -### On Windows +### On any platform -You can define the environment variables with env.bat script located in the -$CASROOT folder. This script accepts two arguments to be used: -the version of Visual Studio (vc12 -- vc143) and the architecture (win32 or win64). +The environment script `env.sh` (or `env.bat` on Windows) is generated by CMake +in the build directory. Source it to set up the environment for running OCCT applications: -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. + source /env.sh -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 OCCT root folder. +The script defines environment variables such as `PATH`, `LD_LIBRARY_PATH` (on Linux), +`DYLD_LIBRARY_PATH` (on macOS), and `CSF_*` configuration variables. ### Description of system variables: @@ -514,7 +480,7 @@ The scripts are located in the OCCT root folder. @section intro_license License Open CASCADE Technology and all materials, including this documentation, is -Copyright (c) 1999-2020 by OPEN CASCADE S.A.S. All rights reserved. +Copyright (c) 1999-2026 by OPEN CASCADE S.A.S. All rights reserved. Open CASCADE Technology is free software; you can redistribute it and / or modify it under the terms of the @ref license_lgpl_21 "GNU Lesser General Public License (LGPL) version 2.1", with additional @ref occt_lgpl_exception "exception". @@ -548,11 +514,6 @@ authors and such software may not be freely available and/or be free of charge f 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, refer to Qt Homepage (https://www.qt.io/) - **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 @@ -572,7 +533,7 @@ FreeType 2 is released under two open-source licenses: BSD-like FreeType License 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. -Intel oneTBB 2021.5.0 is available under Apache 2.0 license (https://www.threadingbuildingblocks.org). +Intel oneTBB 2021+ is available under Apache 2.0 license (https://github.com/oneapi-src/oneTBB/). **OpenGL** is an industry standard API for 3D graphics used by OCCT for implementation of 3D viewer. OpenGL specification is developed by the @@ -601,12 +562,12 @@ basis under The Eclipse Public License (EPL) (https://www.graphviz.org/license/) **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). +It is licensed under Inno Setup License (https://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 optionally used by OCCT to work +and cross-platform (works both with Linux and macOS). FreeImage is optionally used by OCCT to work with images, on conditions of the FreeImage Public License (FIPL) (https://freeimage.sourceforge.net/freeimage-license.txt). **FFmpeg** is an Open Source framework supporting various image, video and audio codecs. @@ -629,15 +590,13 @@ CMake is used to control the software compilation process using simple platform OCCT uses CMake as a build system. CMake is available under BSD 3-Clause license. See more at https://cmake.org/ -**MikTEX** is up-to-date implementation of TeX/LaTeX and related programs for Windows. It is used -for generation of User and Developer Guides in PDF format. See https://miktex.org for information -on this tool. +**LaTeX** distribution (e.g. TeX Live, MikTeX, MacTeX) is used for generation of User and Developer Guides in PDF format. **RapidJSON** is an Open Source JSON parser and generator for C++. RapidJSON is optionally used by OCCT for reading glTF files (https://rapidjson.org/). -**Draco** is an Open Source JSON parser and generator for C++. -Draco is optionally used by OCCT for reading glTF files using KHR_draco_mesh_compression extension (https://github.com/google/draco). +**Draco** is an Open Source library for compressing and decompressing 3D geometric meshes and point clouds. +Draco is optionally used by OCCT to decode glTF files that use the KHR_draco_mesh_compression extension (https://github.com/google/draco). Draco is available under Apache 2.0 license. **DejaVu** fonts are a font family based on the Vera Fonts under a permissive license (MIT-like, https://dejavu-fonts.github.io/License.html). diff --git a/dox/resources/occt_ug_html.doxyfile b/dox/resources/occt_ug_html.doxyfile index 120f4c99ae..cdf6fd0458 100644 --- a/dox/resources/occt_ug_html.doxyfile +++ b/dox/resources/occt_ug_html.doxyfile @@ -40,7 +40,6 @@ GENERATE_HTML = YES HTML_COLORSTYLE_HUE = 220 HTML_COLORSTYLE_SAT = 100 HTML_COLORSTYLE_GAMMA = 80 -HTML_TIMESTAMP = YES HTML_DYNAMIC_SECTIONS = YES HTML_INDEX_NUM_ENTRIES = 100 DISABLE_INDEX = YES @@ -54,7 +53,6 @@ SEARCHENGINE = YES EXTERNAL_SEARCH = YES SKIP_FUNCTION_MACROS = YES FORMULA_FONTSIZE = 12 -FORMULA_TRANSPARENT = YES USE_MATHJAX = YES MATHJAX_FORMAT = HTML-CSS diff --git a/dox/samples/ais_object.md b/dox/samples/ais_object.md index bd1c31a347..a86344e304 100644 --- a/dox/samples/ais_object.md +++ b/dox/samples/ais_object.md @@ -1,4 +1,4 @@ -AIS: Custom Presentation {#tutorials__ais_object} +AIS: Custom Presentation {#tutorials__ais_object} ======== @tableofcontents @@ -69,7 +69,7 @@ occ::handle aPrs = new MyAisObject(); theCtx->Display (aPrs, true); ~~~~ -@figure{ais_object_step1_shaded.png,"@c StdPrs_ShadedShape presentation builder.",409} height=409px +@figure{images/ais_object_step1_shaded.png,"@c StdPrs_ShadedShape presentation builder.",409} height=409px @c PrsMgr_PresentableObject::Compute() method takes three arguments: - **Presentation Manager** (@c PrsMgr_PresentationManager). @@ -129,7 +129,7 @@ void MyAisObject::Compute (const occ::handle& thePrs } ~~~~ -@figure{ais_object_step1_shaded_wf.png,"Result of @c StdPrs_ShadedShape + @c StdPrs_WFShape presentation builders.",409} height=409px +@figure{images/ais_object_step1_shaded_wf.png,"Result of @c StdPrs_ShadedShape + @c StdPrs_WFShape presentation builders.",409} height=409px Presentation builders take the @c Prs3d_Drawer object defining various attributes - material of shaded shape, number of isolines in wireframe mode, tessellation quality, line colors and many others. @c PrsMgr_PresentableObject defines @c myDrawer property with default attributes. @@ -169,7 +169,7 @@ occ::handle aPrs = new MyAisObject(); theCtx->Display (aPrs, 1, 0, true); ~~~~ -@figure{ais_object_step1_bndbox.png,"@c Prs3d_BndBox presentation builder.",409} height=409px +@figure{images/ais_object_step1_bndbox.png,"@c Prs3d_BndBox presentation builder.",409} height=409px @c AIS disallows activating multiple display modes at the same time, so that these presentation modes should be alternatives to each other. But @c AIS may use non-active display mode for highlighting purposes - like wireframe (@c AIS_Wireframe) presentation displayed on top of shaded (@c AIS_Shaded) presentation for selected @c AIS_Shape objects. @@ -199,7 +199,7 @@ theCtx->HilightWithColor (aPrs, aPrs->HilightAttributes(), false); theCtx->CurrentViewer()->Redraw(); ~~~~ -@figure{ais_object_step1_highlight.png,"Highlighting by color (left) and highlighting by another display mode (right).",818} height=409px +@figure{images/ais_object_step1_highlight.png,"Highlighting by color (left) and highlighting by another display mode (right).",818} height=409px In this particular use case we've used the method @c AIS_InteractiveContext::HilightWithColor() instead of @c @::SetSelected() - just because our object is not selectable yet and @c @::SetSelected() wouldn't work. Highlighted presentation appears on the screen with modulated color (see left screenshot above). @@ -258,7 +258,7 @@ void MyAisObject::Compute (const occ::handle& thePrs } ~~~~ -@figure{ais_object_step2_segments.png,"Displaying @c Graphic3d_ArrayOfSegments.",409} height=409px +@figure{images/ais_object_step2_segments.png,"Displaying @c Graphic3d_ArrayOfSegments.",409} height=409px The process is quite straightforward: - Create a new @c Graphic3d_Group using @c Prs3d_Presentation::NewGroup(); @@ -354,7 +354,7 @@ void MyAisObject::Compute (const occ::handle& thePrs } ~~~~ -@figure{ais_object_step3_quadrics_10.png,"@c Prs3d_ToolCylinder (10 slices).",409} height=409px +@figure{images/ais_object_step3_quadrics_10.png,"@c Prs3d_ToolCylinder (10 slices).",409} height=409px Well... that looks a little bit edgy. Quadric builder creates a triangulation taking the following parameters: @@ -371,7 +371,7 @@ occ::handle aTris = Prs3d_ToolCylinder::Create (aRadius, aRadius, aHeight, 25, 25, gp_Trsf()); ~~~~ -@figure{ais_object_step3_quadrics_25.png,"@c Prs3d_ToolCylinder (25 slices).",409} height=409px +@figure{images/ais_object_step3_quadrics_25.png,"@c Prs3d_ToolCylinder (25 slices).",409} height=409px It looks much better now! Note that @c Prs3d_ToolCylinder could be used for building both cones and cylinders depending on top/bottom radius definition. @@ -414,7 +414,7 @@ Now our cylinder looks solid! The sample above merges two triangulations into a This looks like a minor difference, but it might have a _dramatic impact on performance_ in case of a large scene, as each `Graphic3d_ArrayOfPrimitives` is mapped into a dedicated draw call at graphic driver (OpenGL) level. -@figure{ais_object_step3_quadrics_fin.png,"@c Prs3d_ToolCylinder + @c Prs3d_ToolDisk.",409} height=409px +@figure{images/ais_object_step3_quadrics_fin.png,"@c Prs3d_ToolCylinder + @c Prs3d_ToolDisk.",409} height=409px As an exercise, let's try computing a triangulation for cylinder disk without help of @c Prs3d_ToolDisk builder: @@ -456,7 +456,7 @@ void MyAisObject::Compute (const occ::handle& thePrs } ~~~~ -@figure{ais_object_step3_quadrics_disk.png,"Manually triangulated disk.",409} height=409px +@figure{images/ais_object_step3_quadrics_disk.png,"Manually triangulated disk.",409} height=409px The disk is here, but it has a strange color - like it is not affected by lighting. This happens when vertex normals are defined incorrectly. @@ -633,7 +633,7 @@ void SelectMgr_EntityOwner::HilightWithColor ( } ~~~~ -@figure{ais_object_step4_highlight1.png,"Default behavior of @c SelectMgr_EntityOwner::HilightWithColor().",409} height=409px +@figure{images/ais_object_step4_highlight1.png,"Default behavior of @c SelectMgr_EntityOwner::HilightWithColor().",409} height=409px Now, let's override the @c SelectMgr_EntityOwner::HilightWithColor() method and display a bounding box presentation: @@ -646,6 +646,7 @@ void MyAisOwner::HilightWithColor (const occ::handle { myPrs = new Prs3d_Presentation (thePrsMgr->StructureManager()); MyAisObject* anObj = dynamic_cast (mySelectable); + if (anObj == nullptr) return; anObj->Compute (thePrsMgr, myPrs, MyAisObject::MyDispMode_Highlight); } if (!thePrsMgr->IsImmediateModeOn()) @@ -658,7 +659,7 @@ void MyAisOwner::HilightWithColor (const occ::handle @c SelectMgr_EntityOwner::HilightWithColor() doesn't receive a presentation to fill in as an argument; highlight presentation should be manually created and even explicitly displayed on the screen. To avoid code duplication, the code above reuses @c MyAisObject::Compute() already implementing computation of highlight presentation. -@figure{ais_object_step4_highlight2.png,"Result of custom implementation @c MyAisOwner::HilightWithColor().",409} height=409px +@figure{images/ais_object_step4_highlight2.png,"Result of custom implementation @c MyAisOwner::HilightWithColor().",409} height=409px The visual result of the selected object looks exactly the same as when we've used a dedicated highlight mode. One thing became broken, though - highlighting remains displayed even after clearing selection. @@ -686,6 +687,7 @@ void MyAisOwner::HilightWithColor (const occ::handle { myPrs = new Prs3d_Presentation (thePrsMgr->StructureManager()); MyAisObject* anObj = dynamic_cast (mySelectable); + if (anObj == nullptr) return; anObj->Compute (thePrsMgr, myPrs, MyAisObject::MyDispMode_Highlight); } if (thePrsMgr->IsImmediateModeOn()) @@ -713,9 +715,10 @@ void MyAisOwner::HilightWithColor (const occ::handle const int theMode) { MyAisObject* anObj = dynamic_cast (mySelectable); + if (anObj == nullptr) return; if (thePrsMgr->IsImmediateModeOn()) { - occ::handle aSelector = + occ::handle aSelector = anObj->InteractiveContext()->MainSelector(); SelectMgr_SortCriterion aPickPnt; for (int aPickIter = 1; aPickIter <= aSelector->NbPicked(); ++aPickIter) @@ -731,14 +734,14 @@ void MyAisOwner::HilightWithColor (const occ::handle aPrs->SetZLayer (Graphic3d_ZLayerId_Top); aPrs->Clear(); occ::handle aGroup = aPrs->NewGroup(); - aGroupPnt->SetGroupPrimitivesAspect (theStyle->ArrowAspect()->Aspect()); + aGroup->SetGroupPrimitivesAspect (theStyle->ArrowAspect()->Aspect()); gp_Trsf aTrsfInv = mySelectable->LocalTransformation().Inverted(); gp_Dir aNorm (aPickPnt.Normal.x(), aPickPnt.Normal.y(), aPickPnt.Normal.z()); occ::handle aTris = Prs3d_Arrow::DrawShaded (gp_Ax1(aPickPnt.Point, aNorm).Transformed (aTrsfInv), 1.0, 15.0, 3.0, 4.0, 10); - aGroupPnt->AddPrimitiveArray (aTris); + aGroup->AddPrimitiveArray (aTris); thePrsMgr->AddToImmediateList (aPrs); } } @@ -755,7 +758,7 @@ normally our Owner should be the very first one in this list when no selection f @c SelectMgr_SortCriterion provides us useful information like 3D point on detected object lying on the picking ray, and surface normal direction at this point (actually, it would be a normal to a picked triangle), which we display as an arrow with help of @c Prs3d_Arrow presentation builder. -@figure{ais_object_step4_highlight3.png,"Surface normal on mouse over.",409} height=409px +@figure{images/ais_object_step4_highlight3.png,"Surface normal on mouse over.",409} height=409px Result looks pretty nice on the screenshot, but has interaction problems - once displayed, an arrow is no longer updated with further mouse movements. But this behavior is not a bug - @c AIS calls @c MyAisOwner::HilightWithColor() only when picking Owner changes to avoid unnecessary Viewer updates. @@ -868,6 +871,7 @@ bool MyAisOwner::HandleMouseClick (const NCollection_Vec2& thePoint, static bool isFirst = true; isFirst = !isFirst; MyAisObject* anObj = dynamic_cast (mySelectable); + if (anObj == nullptr) return false; gp_Trsf aTrsfTo; aTrsfTo.SetRotation (gp_Ax1 (gp::Origin(), gp::DX()), isFirst ? M_PI * 0.5 : -M_PI * 0.5); @@ -908,4 +912,4 @@ QATutorialAisObject p vfit ~~~~ -You may also take a look onto source code of this command at @c src/QADraw/QADraw_Tutorials.cxx if you have some problems following the tutorial. +You may also take a look onto source code of this command at @c src/Draw/TKQADraw/QADraw/QADraw_Tutorials.cxx if you have some problems following the tutorial. diff --git a/dox/samples/draw_scripts.md b/dox/samples/draw_scripts.md index 5de2f17bb9..111b0426b4 100644 --- a/dox/samples/draw_scripts.md +++ b/dox/samples/draw_scripts.md @@ -1,92 +1,61 @@ -Draw: Demo Scripts {#samples__draw_scripts} +Draw: Demo Scripts {#samples__draw_scripts} ================ -All demo scripts are provided with OCCT sources and locate in CASROOT/resources/samples/tcl. To play around them please -follow the steps below: +All demo scripts are shipped with OCCT sources under the resources/samples/tcl directory. To run them: -1. Start DRAWEXE -2. Type *cd ../..* to return to the root directory -3. Type *cd resources/samples/tcl* to reach the demo scripts directory -4. Type *source \* to run the demonstration file provided with Open CASCADE. The following demonstration -files are available: - * DataExchangeDemo.tcl: demonstrates sample sequence of operations with writing and reading IGES file - * ModelingDemo.tcl: demonstrates creation of simple shape and displaying it in HLR mode - * VisualizationDemo.tcl: demonstrates use of 3d viewer - * cad.tcl: creates solid shape looking like abbreviation "CAD" - * bottle.tcl: creates bottle as in OCCT Tutorial - * drill.tcl: creates twist drill bit shape - * cutter.tcl: creates milling cutter shape - * xde.tcl: demonstrates creation of simple assembly in XDE - * materials.tcl: demonstrates visual properties of materials supported by 3d viewer - * raytrace.tcl: demonstrates use of ray tracing display in 3d viewer - * dimensions.tcl: demonstrates use of dimensions, clipping, and capping in 3d viewer - * ... +1. Source the build environment script `env.sh` (Linux/macOS) or `env.bat` (Windows) generated next to *DRAWEXE* in the build / install `bin/` directory. +2. Launch *DRAWEXE*. +3. From the DRAW prompt, source any demo script by absolute or `$CASROOT`-relative path, for example: + + source $env(CASROOT)/resources/samples/tcl/bottle.tcl + +A few representative demos: + + * DataExchangeDemo.tcl: writes and reads an IGES file + * ModelingDemo.tcl: creates a simple shape and displays it in HLR mode + * VisualizationDemo.tcl: exercises the 3D viewer + * bottle.tcl: builds the bottle from the OCCT Tutorial + * cad.tcl, drill.tcl, cutter.tcl: solid modeling examples + * xde.tcl: creates a simple assembly in XDE + * materials.tcl, raytrace.tcl, vis_pbr_spheres.tcl, pathtrace_*.tcl: visualization, materials, ray-tracing and PBR demos + * dimensions.tcl: dimensions, clipping and capping in the 3D viewer + +For the full up-to-date list, see the contents of the `resources/samples/tcl/` directory. Draw is a command interpreter based on TCL and a graphical system used for testing and demonstrating OCCT modeling libraries. +It can be used interactively to create, display, and modify objects such as curves, surfaces, and topological shapes. +Draw also provides a scriptable environment for OCCT tests and demonstrations. -Draw can be used interactively to create, display and modify objects such as curves, surfaces and topological shapes. +Draw includes: -@figure{/introduction/images/overview_draw.png} + * a TCL command interpreter; + * 2D and 3D viewers with zoom, pan, rotation, and fit operations; + * geometric and topological commands for OCCT modeling algorithms; + * graphic commands for view and display operations; + * OCAF, data exchange, and shape healing commands loaded by plug-ins. -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 @ref occt_user_guides__test_harness. - -Draw Test Harness provides an environment for OCCT automated testing system. -Check its @ref occt_contribution__tests "Automated Testing System" 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. +Commands grouped in toolkits can be loaded at run time with *pload*. +The plug-in mechanism and instructions for extending Draw are described in @ref occt_user_guides__test_harness. +Draw Test Harness is also used by the OCCT automated testing system; see @ref occt_contribution__tests "Automated Test System" for details. Experimenting with Draw Test Harness ------------------------------------ - Running Draw +Running Draw ------------ **On Linux:** -* If OCCT was built by Code::Blocks use $CASROOT/draw.sh file to launch *DRAWEXE* executable. - -Draw[1]> prompt appears in the command window +* Launch *DRAWEXE* executable. The 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. +Launch Draw executable from Open CASCADE Technology\\DRAW Test Harness +item of the Start\\Programs menu. The Draw[1]> prompt appears in the command window. -Draw[1]> prompt appears in the command window - -Type pload ALL +Type *pload ALL* **Creating your first geometric objects** @@ -104,22 +73,9 @@ Type pload ALL **Running demonstration files** -1. Type *cd ../..* to return to the root directory -2. Type *cd resources/samples/tcl* to reach the demo scripts directory -3. Type *source \* to run the demonstration file provided with Open CASCADE. The following demonstration files are available: - * DataExchangeDemo.tcl: demonstrates sample sequence of operations with writing and reading IGES file - * ModelingDemo.tcl: demonstrates creation of simple shape and displaying it in HLR mode - * VisualizationDemo.tcl: demonstrates use of 3d viewer - * cad.tcl: creates solid shape looking like abbreviation "CAD" - * bottle.tcl: creates bottle as in OCCT Tutorial - * drill.tcl: creates twist drill bit shape - * cutter.tcl: creates milling cutter shape - * xde.tcl: demonstrates creation of simple assembly in XDE - * materials.tcl: demonstrates visual properties of materials supported by 3d viewer - * raytrace.tcl: demonstrates use of ray tracing display in 3d viewer - * dimensions.tcl: demonstrates use of dimensions, clipping, and capping in 3d viewer +Use `source $env(CASROOT)/resources/samples/tcl/` from the DRAW prompt, replacing `` with the name of the demonstration script. **Getting Help** 1. Type *help* to see all available commands -2. Type *help \* to find out the arguments for a given command \ No newline at end of file +2. Type *help \* to find out the arguments for a given command diff --git a/dox/samples/images/sample_overview_qt_geometry.png b/dox/samples/images/sample_overview_qt_geometry.png deleted file mode 100644 index 946e4d65d8..0000000000 Binary files a/dox/samples/images/sample_overview_qt_geometry.png and /dev/null differ diff --git a/dox/samples/images/sample_overview_qt_ocaf.png b/dox/samples/images/sample_overview_qt_ocaf.png deleted file mode 100644 index 4b07fc7d2e..0000000000 Binary files a/dox/samples/images/sample_overview_qt_ocaf.png and /dev/null differ diff --git a/dox/samples/images/sample_overview_qt_topology.png b/dox/samples/images/sample_overview_qt_topology.png deleted file mode 100644 index fbefb8fcad..0000000000 Binary files a/dox/samples/images/sample_overview_qt_topology.png and /dev/null differ diff --git a/dox/samples/images/sample_overview_qt_triangulation.png b/dox/samples/images/sample_overview_qt_triangulation.png deleted file mode 100644 index 39afb1ed11..0000000000 Binary files a/dox/samples/images/sample_overview_qt_triangulation.png and /dev/null differ diff --git a/dox/samples/images/sample_overview_qt_viewers.png b/dox/samples/images/sample_overview_qt_viewers.png deleted file mode 100644 index a7f13f9781..0000000000 Binary files a/dox/samples/images/sample_overview_qt_viewers.png and /dev/null differ diff --git a/dox/samples/images/sample_overview_qt_xde.png b/dox/samples/images/sample_overview_qt_xde.png deleted file mode 100644 index 643560ea16..0000000000 Binary files a/dox/samples/images/sample_overview_qt_xde.png and /dev/null differ diff --git a/dox/samples/images/samples_draw.png b/dox/samples/images/samples_draw.png deleted file mode 100644 index 27cd5cda1d..0000000000 Binary files a/dox/samples/images/samples_draw.png and /dev/null differ diff --git a/dox/samples/novice_guide.md b/dox/samples/novice_guide.md index fc4c90b8b7..d4adce23d7 100644 --- a/dox/samples/novice_guide.md +++ b/dox/samples/novice_guide.md @@ -3,6 +3,8 @@ Novice Guide {#samples__novice_guide} @tableofcontents +@note This guide refers to the **OCCTOverview** Qt sample (and other C++ project samples such as Qt, MFC, C#, WebGL, QML, Java/Android and iOS). These project samples are **no longer bundled with the OCCT repository** -- they are being repackaged into separate Git repositories. Until those land, treat the screenshots and instructions related to the OCCTOverview Qt application as illustrative; the @ref samples__draw_scripts "DRAW Tcl demos" under `resources/samples/tcl/` and the @ref occt__tutorial "OCCT Tutorial" remain available and are the recommended starting points. + @section diffs Modeling with OCCT: Key differences Open CASCADE Technology (OCCT) is an object-oriented C++ framework designed for rapid production of sophisticated CAD/CAM/CAE applications. @@ -25,90 +27,24 @@ In this tutorial you will create a solid model step-by-step using different clas Each step of the tutorial contains code snippets and images. The basics involved in the modeling process are explained. -When the basics of OCCT are clear, the next logical step is to check out @ref samples "sample applications" and examine those that suit your needs. -For these, the best starting point is **OCCTOverview** located in /samples/qt subfolder of OCCT installation. +When the basics of OCCT are clear, the next logical step is to check out @ref samples "sample scripts and examples" and examine those that suit your needs. +For these, the @ref samples__draw_scripts "DRAW demo scripts" (located in the `resources/samples/tcl/` directory) are an excellent next step. +These Tcl-based scripts demonstrate a wide range of OCCT functionality -- from basic geometry and topology to advanced modeling algorithms, data exchange, and visualization. +They can be executed in the DRAW Test Harness and are the most immediate way to see OCCT in action. -This sample provides code examples for several actions as well as visualization of these code snippets output. -The Overview interface is dynamically changing based on selected **Category** at the menu. -Additional menu buttons will appear, providing users with subcategories and relevant commands to select one of the actions. -The result will appear in the viewer window, the code will appear at the top right, and in several cases the output will be produced at the bottom right window. - -@figure{sample_overview_qt_viewers.png,"Comparison of 3D and 2D viewer windows",240} height=420px - -The 3D viewer window has a row of preset interface buttons to customize the visual output. - -Those buttons can be grouped into three types, left to right: - -- View controls: **Fit all** and **Isometric**, will center the view and reset the camera angles respectively; -- Display mode customization: **HLR,** e.g. "Hidden line removal" (works only when shading is disabled) can be turned on and off; -solid models may be displayed either in **Shading** or **Wireframe** modes. **Transparency** level may be set for models in shading mode; -- The last four buttons in a row are beautifiers enabling Ray-tracing engine and configuring it's parameters. - -At the bottom left of the screen the orientation cube (trihedron) is located. -The trihedron interactively shows the position of the camera in relation to the XYZ axis of the displayed data. -The sides of the trihedron are labeled to help with orientation. -Click on a side of the box to orient the camera view along the preferred axis. - -The 2D viewer window lacks most of these elements and only have **Fit all** button. - -The **Geometry** category of the Overview focuses on primitive objects like dots, lines (including vectors) or planes. -These objects will appear in the viewer after the subcategory is selected. -This section will demonstrate these entities both in 2D and 3D view mode and provide basic examples of parametric creation and data analysis. - -@figure{sample_overview_qt_geometry.png,"",240} height=440px - -The usage of the functions shown in the Overview is described more thoroughly at the @ref occt_user_guides__modeling_data "Modeling data" section of the documentation. -Additionally, @ref occt_user_guides__modeling_algos "Modeling Algorithms" are used in more complex cases. - -The **Topology** section of the Overview demonstrates the functions used in 3D operations. -Multiple use cases are provided, including different object intersections, modifying and calculations. - -@figure{sample_overview_qt_topology.png,"",240} height=440px - -The subsections are grouped as shown on the screenshot before. -Most shapes and primitive objects are introduced and then followed by a set of operations and interactions. - -The **Triangulation** segment allows computing the number of triangles on a shape. - -This may be inspected via [Poly_Triangulation Class Reference](https://dev.opencascade.org/doc/refman/html/class_poly___triangulation.html) - -a part of the [Reference manual](https://dev.opencascade.org/doc/refman/html/index.html), -an overall Open CASCADE code guide that may be used to inspect the key points in classes and their connections. - -@figure{sample_overview_qt_triangulation.png,"",240} height=440px - -The triangulation uses some of Mesh-related classes - see full description at @ref occt_user_guides__mesh "Mesh" documentation section. - -The **Data exchange** section provides examples of how to export and import files of several different formats. - -@figure{sample_overview_qt_xde.png,"",240} height=440px - -The **OCAF** section gives an introduction for the @ref intro_overview_ocaf "Open CASCADE Application Framework" functionality. -To test these functions, create an object first (box or cylinder). -After that, the object may be modified and saved. Actions are recorded and may be undone or redone. - -@figure{sample_overview_qt_ocaf.png,"",240} height=440px - -**Viewers** section demonstrates examples of the 2D and 3D visualization outputs. -Check @ref occt_user_guides__visualization "Visualization" section of the documentation for a detailed description. -In addition to these two samples, there are much more that might be of use to a new user based on their particular use case. - -Check Readme files in the sample directories to learn more about samples compilation. - -**Note:** source code for OCCTOverview is stored at 'samples/qt/OCCTOverview/src' folder in your OCCT root, -and the source code files for examples presented in subsections are stored at 'samples/qt/OCCTOverview/code folder'. -Several utility classes that are not presented in the example window may be found in example source code files. +Example C++ applications (using Qt, MFC, C#, WebGL, QML, Java/Android, and iOS) are available separately from the [OCCT organization's GitHub repositories](https://github.com/Open-Cascade-SAS). +These provide full project setups demonstrating how to integrate OCCT into various application frameworks. The overall classes introduction may be found in the @ref occt_user_guides__foundation_classes "Foundation Classes" section of the documentation. -The "Introduction" section contains short descriptions of the most massive entries in the documentation. +The @ref occt_user_guides "User Guides" contain in-depth descriptions of all major OCCT modules. @section helps Additional assistance -There are several places that may be of use for new users. -The first one is [Training & E-learning](https://dev.opencascade.org/resources/trainings) page that lists available trainings and describes their specifics. +There are several resources that may be of use for new users. +The first is the [Training & E-learning](https://dev.opencascade.org/resources/trainings) page, which lists available trainings and describes their specifics. -The second one is the Overview documentation (this document is a part of it) - here you can find information that suits most of the use cases. -This may seem overwhelming at first, but if you have the clear understanding of what do you seek, you will most likely find the required information. +The second is the documentation itself -- if you have a clear understanding of what you seek, you will most likely find the required information in the User Guides. -Aside from the Overview documentation itself, the [Reference manual](https://dev.opencascade.org/doc/refman/html/index.html) is present. -Use it to check classes descriptions, dependencies and examples. +Aside from the documentation, the [Reference manual](https://dev.opencascade.org/doc/refman/html/index.html) is available. +Use it to check class descriptions, dependencies and examples. Additionally, there is a [Forum](https://dev.opencascade.org/forums) where you can contact the OCCT community and developers. diff --git a/dox/samples/ocaf.md b/dox/samples/ocaf.md index b1209d6538..4c45c09e06 100644 --- a/dox/samples/ocaf.md +++ b/dox/samples/ocaf.md @@ -1,4 +1,4 @@ -OCAF: Usage Tutorial {#samples__ocaf} +OCAF: Usage Tutorial {#samples__ocaf} ======== ## Getting Started @@ -22,12 +22,7 @@ Once you have implemented the commands which create and modify the data structur * Undo-redo; * Save and open application data. -Finally, you develop the application's graphical user interface using the toolkit of your choice, for example: -* KDE Qt or GNOME GTK+ on Linux; -* Microsoft Foundation Classes (MFC) on Windows Motif on Sun; -* Other commercial products such as Ilog Views. - -You can also implement the user interface in the Java language using the Swing-based Java Application Desktop component (JAD) provided with OCAF. +Finally, you develop the application's graphical user interface using the toolkit of your choice, for example Qt, GTK, MFC, .NET, or a similar framework. ## An example of OCAF usage @@ -55,7 +50,7 @@ This file contains several definitions for the saving and opening mechanisms ass ~~~~ 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: +and CSF_ResourcesDefaults, which defines the resource file: ~~~~{.cpp} SetEnvironmentVariable ("CSF_ResourcesDefaults", myDirectory); @@ -80,7 +75,7 @@ Five drivers are required to use all standard attributes provided within OCAF: * 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. +These drivers are provided as plug-ins by OCCT toolkits such as *TKStd* / *TKStdL* (legacy binary), *TKBin* / *TKBinL* (current binary) and *TKXml* / *TKXmlL* (XML). The mapping from GUID to toolkit lives in the standard `Plugin` resource file shipped under `resources/StdResource/Plugin`. For example, this is a resource file, which declares a new model document OCAF-MyApplication: @@ -97,25 +92,29 @@ OCAF-MyApplication.AttributeRetrievalPlugin: 47b0b827-d931-11d1-b5da-00a0c906436 ### 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. +The plugin file describes the list of required plug-ins to run the application and the toolkits in which the plug-ins are located. -You need at least the FWOSPlugin and the plug-in drivers to run an OCAF application. +You need the OCAF plug-in drivers (such as *TKStd*, *TKBin*, *TKXml*) to run an OCAF application; OCCT ships them in `resources/StdResource/Plugin`, which is loaded via the *CSF_PluginDefaults* environment variable. -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. +The syntax of each item is Identification.Location: Toolkit_Name, where: +* Identification is the *Standard_GUID* of the service implemented by the plug-in. +* Location is the kind of attribute (here always `.Location`). +* Toolkit_Name is the OCCT toolkit name without the platform-specific `lib`/`.dll`/`.so` decoration; the platform's dynamic loader resolves the actual library at runtime. -For example, this is a Plugin file: +For example, an excerpt from the standard `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 +! standard attribute drivers plugin +ad696001-5b34-11d1-b5ba-00a0c9064368.Location: TKStd + +! BinOcaf Document Plugin +03a56835-8269-11d5-aab2-0050044b1af1.Location: TKBin +03a56836-8269-11d5-aab2-0050044b1af1.Location: TKBin + +! XmlOcaf Document Plugin +03a56820-8269-11d5-aab2-0050044b1af1.Location: TKXml +03a56822-8269-11d5-aab2-0050044b1af1.Location: TKXml +03a56824-8269-11d5-aab2-0050044b1af1.Location: TKXml ~~~~ ## Implementation of Attribute Transformation in a HXX file @@ -161,7 +160,7 @@ public: //!@ name Methods for setting the data of transformation //! The method defines an axis mirror type of transformation (axial symmetry). Standard_EXPORT void SetMirror (const gp_Ax1& theAxis); - //! The method defines a point mirror type of transformation (planar symmetry). + //! The method defines a planar mirror type of transformation (planar symmetry). Standard_EXPORT void SetMirror (const gp_Ax2& thePlane); //! The method defines a scale type of transformation. @@ -221,23 +220,16 @@ private: ~~~~{.cpp} #include -//======================================================================= -//function : GetID -//purpose : The method returns a unique GUID of this attribute. -// By means of this GUID this attribute may be identified -// among other attributes attached to the same label. -//======================================================================= +//================================================================================================== + const Standard_GUID& MyPackage_Transformation::GetID() { static Standard_GUID ID("4443368E-C808-4468-984D-B26906BA8573"); return ID; } -//======================================================================= -//function : Set -//purpose : Finds or creates the attribute attached to . -// The found or created attribute is returned. -//======================================================================= +//================================================================================================== + occ::handle MyPackage_Transformation::Set(const TDF_Label& theLabel) { occ::handle T; @@ -249,10 +241,8 @@ occ::handle MyPackage_Transformation::Set(const TDF_La return T; } -//======================================================================= -//function : Get -//purpose : The method returns the transformation. -//======================================================================= +//================================================================================================== + gp_Trsf MyPackage_Transformation::Get() const { gp_Trsf transformation; @@ -305,10 +295,8 @@ gp_Trsf MyPackage_Transformation::Get() const return transformation; } -//======================================================================= -//function : SetRotation -//purpose : The method defines a rotation type of transformation. -//======================================================================= +//================================================================================================== + void MyPackage_Transformation::SetRotation(const gp_Ax1& theAxis, const double theAngle) { Backup(); @@ -317,10 +305,8 @@ void MyPackage_Transformation::SetRotation(const gp_Ax1& theAxis, const double t myAngle = theAngle; } -//======================================================================= -//function : SetTranslation -//purpose : The method defines a translation type of transformation. -//======================================================================= +//================================================================================================== + void MyPackage_Transformation::SetTranslation(const gp_Vec& theVector) { Backup(); @@ -329,11 +315,8 @@ void MyPackage_Transformation::SetTranslation(const gp_Vec& theVector) mySecondPoint.SetCoord(theVector.X(), theVector.Y(), theVector.Z()); } -//======================================================================= -//function : SetMirror -//purpose : The method defines a point mirror type of transformation -// (point symmetry). -//======================================================================= +//================================================================================================== + void MyPackage_Transformation::SetMirror(const gp_Pnt& thePoint) { Backup(); @@ -341,11 +324,8 @@ void MyPackage_Transformation::SetMirror(const gp_Pnt& thePoint) myFirstPoint = thePoint; } -//======================================================================= -//function : SetMirror -//purpose : The method defines an axis mirror type of transformation -// (axial symmetry). -//======================================================================= +//================================================================================================== + void MyPackage_Transformation::SetMirror(const gp_Ax1& theAxis) { Backup(); @@ -353,11 +333,8 @@ void MyPackage_Transformation::SetMirror(const gp_Ax1& theAxis) myAx1 = theAxis; } -//======================================================================= -//function : SetMirror -//purpose : The method defines a point mirror type of transformation -// (planar symmetry). -//======================================================================= +//================================================================================================== + void MyPackage_Transformation::SetMirror(const gp_Ax2& thePlane) { Backup(); @@ -365,10 +342,8 @@ void MyPackage_Transformation::SetMirror(const gp_Ax2& thePlane) myAx2 = thePlane; } -//======================================================================= -//function : SetScale -//purpose : The method defines a scale type of transformation. -//======================================================================= +//================================================================================================== + void MyPackage_Transformation::SetScale(const gp_Pnt& thePoint, const double theScale) { Backup(); @@ -377,11 +352,8 @@ void MyPackage_Transformation::SetScale(const gp_Pnt& thePoint, const double the myScale = theScale; } -//======================================================================= -//function : SetTransformation -//purpose : The method defines a complex type of transformation -// from one coordinate system to another -//======================================================================= +//================================================================================================== + void MyPackage_Transformation::SetTransformation (const gp_Ax3& theCoordinateSystem1, const gp_Ax3& theCoordinateSystem2) { @@ -390,23 +362,15 @@ void MyPackage_Transformation::SetTransformation (const gp_Ax3& theCoordinateSys mySecondAx3 = theCoordinateSystem2; } -//======================================================================= -//function : ID -//purpose : The method returns a unique GUID of the attribute. -// By means of this GUID this attribute may be identified -// among other attributes attached to the same label. -//======================================================================= +//================================================================================================== + const Standard_GUID& MyPackage_Transformation::ID() const { return GetID(); } -//======================================================================= -//function : Restore -//purpose : The method is called on Undo / Redo. -// It copies the content of -// into this attribute (copies the fields). -//======================================================================= +//================================================================================================== + void MyPackage_Transformation::Restore(const occ::handle& theAttribute) { occ::handle theTransformation = occ::down_cast(theAttribute); @@ -421,22 +385,15 @@ void MyPackage_Transformation::Restore(const occ::handle& theAttr mySecondPoint = theTransformation->mySecondPoint; } -//======================================================================= -//function : NewEmpty -//purpose : It creates a new instance of this attribute. -// It is called on Copy / Paste, Undo / Redo. -//======================================================================= +//================================================================================================== + occ::handle MyPackage_Transformation::NewEmpty() const { return new MyPackage_Transformation(); } -//======================================================================= -//function : Paste -//purpose : The method is called on Copy / Paste. -// It copies the content of this attribute into -// (copies the fields). -//======================================================================= +//================================================================================================== + void MyPackage_Transformation::Paste (const occ::handle& theAttribute, const occ::handle& ) const { @@ -452,68 +409,64 @@ void MyPackage_Transformation::Paste (const occ::handle& theAttri theTransformation->mySecondPoint = mySecondPoint; } -//======================================================================= -//function : Dump -//purpose : Prints the content of this attribute into the stream. -//======================================================================= +//================================================================================================== + Standard_OStream& MyPackage_Transformation::Dump(Standard_OStream& theOS) const { - anOS << "Transformation: "; + theOS << "Transformation: "; switch (myType) { case gp_Identity: { - anOS << "gp_Identity"; + theOS << "gp_Identity"; break; } case gp_Rotation: { - anOS << "gp_Rotation"; + theOS << "gp_Rotation"; break; } case gp_Translation: { - anOS << "gp_Translation"; + theOS << "gp_Translation"; break; } case gp_PntMirror: { - anOS << "gp_PntMirror"; + theOS << "gp_PntMirror"; break; } case gp_Ax1Mirror: { - anOS << "gp_Ax1Mirror"; + theOS << "gp_Ax1Mirror"; break; } case gp_Ax2Mirror: { - anOS << "gp_Ax2Mirror"; + theOS << "gp_Ax2Mirror"; break; } case gp_Scale: { - anOS << "gp_Scale"; + theOS << "gp_Scale"; break; } case gp_CompoundTrsf: { - anOS << "gp_CompoundTrsf"; + theOS << "gp_CompoundTrsf"; break; } case gp_Other: { - anOS << "gp_Other"; + theOS << "gp_Other"; break; } } - return anOS; + return theOS; } -//======================================================================= -//function : MyPackage_Transformation -//purpose : A constructor. -//======================================================================= +//================================================================================================== + MyPackage_Transformation::MyPackage_Transformation() : myType (gp_Identity) { @@ -523,9 +476,8 @@ MyPackage_Transformation::MyPackage_Transformation() ## Implementation of typical actions with standard OCAF attributes. -There are four sample files provided in the directory 'OpenCasCade/ros/samples/ocafsamples'. -They present typical actions with OCAF services (mainly for newcomers). -The method *Sample()* of each file is not dedicated for execution 'as is', it is rather a set of logical actions using some OCAF services. +The following four examples present typical actions with OCAF services (mainly for newcomers). +The method *Sample()* of each example is not dedicated for execution "as is"; it is rather a set of logical actions using some OCAF services. ### TDataStd_Sample.cxx This sample contains templates for typical actions with the following standard OCAF attributes: diff --git a/dox/samples/ocaf_func.md b/dox/samples/ocaf_func.md index 95ae6c765d..b47fc2b188 100644 --- a/dox/samples/ocaf_func.md +++ b/dox/samples/ocaf_func.md @@ -1,4 +1,4 @@ -OCAF: Function Mechanism {#samples__ocaf_func} +OCAF: Function Mechanism {#samples__ocaf_func} ======================== Let us describe the usage of the "Function Mechanism" of Open CASCADE Application Framework on a simple example. @@ -162,43 +162,43 @@ drivers for a function driver table with the help of *TFunction_DriverTable* cl ~~~~{.cpp} - // The scope of functions is defined. - occ::handle scope = TFunction_Scope::Set( anyLabel ); - - // The information on modifications in the model is received. - TFunction_Logbook& log = scope-GetLogbook(); - - // The iterator is iInitialized by the scope of functions. - TFunction_Iterator iterator( anyLabel ); - Iterator.SetUsageOfExecutionOrder( true ); - - // The function is iterated,  its dependency is checked on the modified data and  executed if necessary. - for (; iterator.more(); iterator.Next()) - { - // The function iterator may return a list of current functions for execution. - // It might be useful for multi-threaded execution of functions. - const NCollection_List& currentFunctions = iterator.Current(); - - //The list of current functions is iterated. - NCollection_List::Iterator currentterator( currentFunctions ); - for (; currentIterator.More(); currentIterator.Next()) - { - // An interface for the function is created. - TFunction_IFunction interface( currentIterator.Value() ); - - // The function driver is retrieved. - occ::handle driver = interface.GetDriver(); - - // The dependency of the function on the  modified data is checked. - If (driver-MustExecute( log )) - { - // The function is executed. - int ret = driver-Execute( log ); - if ( ret ) - return false; - } // end if check on modification - } // end of iteration of current functions - } // end of iteration of functions. + // The scope of functions is defined. + occ::handle scope = TFunction_Scope::Set (anyLabel); + + // The information on modifications in the model is received. + occ::handle log = scope->GetLogbook(); + + // The iterator is initialized by the scope of functions. + TFunction_Iterator iterator (anyLabel); + iterator.SetUsageOfExecutionStatus (true); + + // The function is iterated, its dependency is checked on the modified data and executed if necessary. + for (; iterator.More(); iterator.Next()) + { + // The function iterator may return a list of current functions for execution. + // It might be useful for multi-threaded execution of functions. + const NCollection_List& currentFunctions = iterator.Current(); + + // The list of current functions is iterated. + NCollection_List::Iterator currentIterator (currentFunctions); + for (; currentIterator.More(); currentIterator.Next()) + { + // An interface for the function is created. + TFunction_IFunction interface (currentIterator.Value()); + + // The function driver is retrieved. + occ::handle driver = interface.GetDriver(); + + // The dependency of the function on the modified data is checked. + if (driver->MustExecute (log)) + { + // The function is executed. + int ret = driver->Execute (log); + if (ret) + return false; + } // end if check on modification + } // end of iteration of current functions + } // end of iteration of functions. ~~~~ @@ -209,78 +209,80 @@ drivers for a function driver table with the help of *TFunction_DriverTable* cl ~~~~{.cpp} - // A virtual method ::Arguments() returns a list of arguments of the function. - CylinderDriver::Arguments( NCollection_List& args ) - { - // The direct arguments, located at sub-leaves of the function, are collected (see picture 2). - TDF_ChildIterator cIterator( Label(), false ); - for (; cIterator.More(); cIterator.Next() ) - { - // Direct argument. - TDF_Label sublabel = cIterator.Value(); - Args.Append( sublabel ); - - // The references to the external data are checked. - occ::handle ref; - If ( sublabel.FindAttribute( TDF_Reference::GetID(), ref ) ) - { - args.Append( ref-Get() ); - } - } - - // A virtual method ::Results() returns a list of result leaves. - CylinderDriver::Results( NCollection_List& res ) - { - // The result is kept at the function label. -   Res.Append( Label() ); - } - - // Execution of the function driver. - Int CylinderDriver::Execute( TFunction_Logbook& log ) - { - // Position of the cylinder - position of the first function (cone) - //is  elevated along Z for height values of all previous functions. - gp_Ax2 axes = …. // out of the scope of this guide. - // The radius value is retrieved. - // It is located at second child sub-leaf (see the picture 2). - TDF_Label radiusLabel = Label().FindChild( 2 ); - - // The multiplicator of the radius ()is retrieved. - occ::handle radiusValue; - radiusLabel.FindAttribute( TDataStd_Real::GetID(), radiusValue); - - // The reference to the radius is retrieved. - occ::handle refRadius; - RadiusLabel.FindAttribute( TDF_Reference::GetID(), refRadius ); - - // The radius value is calculated. - double radius = 0.0; - - if ( refRadius.IsNull() ) + // A virtual method ::Arguments() returns a list of arguments of the function. + void CylinderDriver::Arguments (NCollection_List& args) const + { + // The direct arguments, located at sub-leaves of the function, are collected (see picture 2). + TDF_ChildIterator cIterator (Label(), false); + for (; cIterator.More(); cIterator.Next()) { - radius = radiusValue-Get(); + // Direct argument. + TDF_Label sublabel = cIterator.Value(); + args.Append (sublabel); + + // The references to the external data are checked. + occ::handle ref; + if (sublabel.FindAttribute (TDF_Reference::GetID(), ref)) + { + args.Append (ref->Get()); + } } - else - { - // The referenced radius value is retrieved. - occ::handle referencedRadiusValue; - RefRadius-Get().FindAttribute(TDataStd_Real::GetID() ,referencedRadiusValue ); - radius = referencedRadiusValue-Get() * radiusValue-Get(); - } - - // The height value is retrieved. - double height = … // similar code to taking the radius value. - - // The cylinder is created. - TopoDS_Shape cylinder = BRepPrimAPI_MakeCylinder(axes, radius, height); - - // The result (cylinder) is set - TNaming_Builder builder( Label() ); - Builder.Generated( cylinder ); - - // The modification of the result leaf is saved in the log. - log.SetImpacted( Label() ); - + } + + // A virtual method ::Results() returns a list of result leaves. + void CylinderDriver::Results (NCollection_List& res) const + { + // The result is kept at the function label. + res.Append (Label()); + } + + // Execution of the function driver. + int CylinderDriver::Execute (occ::handle& log) const + { + // Position of the cylinder - position of the first function (cone) + // is elevated along Z for height values of all previous functions. + gp_Ax2 axes = ...; // out of the scope of this guide. + + // The radius value is retrieved. + // It is located at second child sub-leaf (see the picture 2). + TDF_Label radiusLabel = Label().FindChild (2); + + // The multiplicator of the radius is retrieved. + occ::handle radiusValue; + radiusLabel.FindAttribute (TDataStd_Real::GetID(), radiusValue); + + // The reference to the radius is retrieved. + occ::handle refRadius; + radiusLabel.FindAttribute (TDF_Reference::GetID(), refRadius); + + // The radius value is calculated. + double radius = 0.0; + + if (refRadius.IsNull()) + { + radius = radiusValue->Get(); + } + else + { + // The referenced radius value is retrieved. + occ::handle referencedRadiusValue; + refRadius->Get().FindAttribute (TDataStd_Real::GetID(), referencedRadiusValue); + radius = referencedRadiusValue->Get() * radiusValue->Get(); + } + + // The height value is retrieved. + double height = ...; // similar code to taking the radius value. + + // The cylinder is created. + TopoDS_Shape cylinder = BRepPrimAPI_MakeCylinder (axes, radius, height); + + // The result (cylinder) is set + TNaming_Builder builder (Label()); + builder.Generated (cylinder); + + // The modification of the result leaf is saved in the log. + log->SetImpacted (Label()); + return 0; } ~~~~ diff --git a/dox/samples/samples.md b/dox/samples/samples.md index 48c490272a..5267bd4347 100644 --- a/dox/samples/samples.md +++ b/dox/samples/samples.md @@ -1,4 +1,4 @@ -Tutorials and Samples {#samples} +Tutorials and Samples {#samples} ===================== - @subpage samples__tutorials @@ -9,7 +9,6 @@ These scripts can be also considered as a tutorials on **Tcl** usage within @ref occt_user_guides__test_harness "Draw Harness". * @ref occt__tutorial
A programming tutorial teaching how to use OCCT services to model a 3D object. - See also @ref samples_qt_tutorial * @ref samples__ocaf
A set of code snippets performing typical actions with @ref occt_user_guides__ocaf "OCAF" services for newcomers. * @ref samples__ocaf_func @@ -17,28 +16,7 @@ * @ref tutorials__ais_object
A programming tutorial teaching how to compute presentation within AIS_InteractiveObject subclass for displaying in @ref occt_user_guides__visualization "OCCT 3D Viewer". - @subpage samples__projects - * @ref samples_qt_iesample -
A cross-platform multi-document 3D Viewer sample with CAD import / export functionality based on **Qt Widgets** framework. - * @ref samples_qml_android_occt -
A cross-platform 3D Viewer sample with CAD import based on **QtQuick** framework. - * @ref samples_qt_tutorial -
A cross-platform sample application based on **Qt Widgets** framework and implementing @ref occt__tutorial. - * @ref samples_qt_overview -
A sample application interactively demonstrating OCCT C++ usage with code snippets for newcomers. - * @ref samples_mfc_standard -
A set of projects for Windows platform demonstrating OCCT usage based on **Microsoft Foundation Class** (**MFC**) library. - * @ref samples_csharp_occt -
A Multi-document 3D Viewer sample with CAD import / export functionality based on .NET and **Windows Forms** or **WPF**. - * @ref samples_csharp_direct3d -
3D Viewer sample wrapped into Direct3D context based on .NET and **Windows Presentation Foundation** (**WPF**). - * @ref occt_samples_webgl -
3D Viewer sample based on **Emscripten SDK** representing a static HTML page to be opened in Web Browser. - * @ref samples_java_android_occt -
3D Viewer sample with CAD import for Android mobile platform based on Android SDK and JNI layer. - * @ref occt_samples_ios_uikit -
3D Viewer sample for iOS platform based on Apple **UIKit** framework. - * @ref occt_samples_glfw -
A cross-platform 3D Viewer sample using **GLFW** library. + Additional demo scripts are provided in the OCCT repository under the resources/samples/tcl directory. @page samples__tutorials Tutorials and Demos - @subpage samples__novice_guide @@ -48,15 +26,9 @@ - @subpage samples__ocaf_func - @subpage tutorials__ais_object -@page samples__projects Sample Projects -- @subpage samples_qt_iesample -- @subpage samples_qml_android_occt -- @subpage samples_qt_tutorial -- @subpage samples_qt_overview -- @subpage samples_mfc_standard -- @subpage samples_csharp_occt -- @subpage samples_csharp_direct3d -- @subpage occt_samples_webgl -- @subpage samples_java_android_occt -- @subpage occt_samples_ios_uikit -- @subpage occt_samples_glfw +@page samples__projects Additional Demo Scripts + +Additional DRAW demo scripts are available in the OCCT repository under the resources/samples/tcl directory. +They can be run from DRAW as described in @ref samples__draw_scripts. + +C++ project samples (Qt, MFC, C#, WebGL, Java/Android, iOS, GLFW, QML) are available separately from the OCCT organization's GitHub repositories. diff --git a/dox/specification/boolean_operations/boolean_operations.md b/dox/specification/boolean_operations/boolean_operations.md index 1c7b992b74..3e3fc9c235 100644 --- a/dox/specification/boolean_operations/boolean_operations.md +++ b/dox/specification/boolean_operations/boolean_operations.md @@ -648,7 +648,7 @@ The input data for this step is the DS after updating Pave Blocks. | 4 | Access to the pave blocks of interfered shapes: (PBi1, PBi2…PBiNi) for edge *Ei* and (PBj1, PBj2…PBjNj) for edge *Ej* | *BOPAlgo_PaveFiller::PerformEE()* | | 5 | Compute shrunk data for pave blocks in terms of @ref specification__boolean_4_4 "Pave, PaveBlock and CommonBlock", if it is necessary. | *BOPAlgo_PaveFiller::FillShrunkData()* | | 6 | Compute Edge/Edge interference for pave blocks *PBix* and *PBiy*. The result of the computation is a set of objects of type *IntTools_CommonPart* | *IntTools_EdgeEdge* | -| 7.1 | For each *CommonPart* of type *VERTEX:* Create new vertices *VNi (i =1, 2…,NbVN),* where *NbVN* is the number of new vertices. Intersect the vertices *VNi* using the steps Initialization and compute Vertex/Vertex interferences as follows: a) create a new object *PFn* of type *BOPAlgo_PaveFiller* with its own DS; b) use new vertices *VNi (i=1, 2…,NbVN), NbVN* as arguments (in terms of *TopoDs_Shape*) of *PFn*; c) invoke method *Perform()* for *PFn*. The resulting vertices *VNXi (i=1, 2…,NbVNX)*, where *NbVNX* is the number of vertices, are obtained via mapping between *VNi* and the results of *PVn*. | *BOPTools_Tools::MakeNewVertex()* | +| 7.1 | For each *CommonPart* of type *VERTEX:* Create new vertices *VNi (i =1, 2…,NbVN),* where *NbVN* is the number of new vertices. Intersect the vertices *VNi* using the steps Initialization and compute Vertex/Vertex interferences as follows: a) create a new object *PFn* of type *BOPAlgo_PaveFiller* with its own DS; b) use new vertices *VNi (i=1, 2…,NbVN), NbVN* as arguments (in terms of *TopoDS_Shape*) of *PFn*; c) invoke method *Perform()* for *PFn*. The resulting vertices *VNXi (i=1, 2…,NbVNX)*, where *NbVNX* is the number of vertices, are obtained via mapping between *VNi* and the results of *PVn*. | *BOPTools_Tools::MakeNewVertex()* | | 7.2 | For each *CommonPart* of type *EDGE:* Compute the coinciding connexity chains of pave blocks (PB1C, PB2C… PNnC)k, C=0, 1…nCs, where *nCs* is the number of the connexity chains. Create common blocks (CBc. C=0, 1…nCs) from the chains. Attach the common blocks to the pave blocks. | *BOPAlgo_Tools::PerformCommonBlocks()* | | 8 | Post-processing. Append the paves of *VNXi* into the corresponding pave blocks in terms of @ref specification__boolean_4_4 "Pave, PaveBlock and CommonBlock" | *BOPDS_PaveBlock:: AppendExtPave()* | | 9 | Split common blocks CBc by the paves. | *BOPDS_DS:: UpdateCommonBlock()* | @@ -684,7 +684,7 @@ The input data for this step is the DS after computing Vertex/Face Interferences | 4 | Access to the pave blocks of interfered edge (PBi1, PBi2…PBiNi) for edge *Ei* | *BOPAlgo_PaveFiller::PerformEF()* | | 5 | Compute shrunk data for pave blocks (in terms of @ref specification__boolean_4_4 "Pave, PaveBlock and CommonBlock") if it is necessary. | *BOPAlgo_PaveFiller::FillShrunkData()* | | 6 | Compute Edge/Face interference for pave block *PBix*, and face *nFj*. The result of the computation is a set of objects of type *IntTools_CommonPart* | *IntTools_EdgeFace* | -| 7.1 | For each *CommonPart* of type *VERTEX:* Create new vertices *VNi (i=1, 2…,NbVN),* where *NbVN* is the number of new vertices. Merge vertices *VNi* as follows: a) create new object *PFn* of type *BOPAlgo_PaveFiller* with its own DS; b) use new vertices *VNi (i=1, 2…,NbVN), NbVN* as arguments (in terms of *TopoDs_Shape*) of *PFn*; c) invoke method *Perform()* for *PFn*. The resulting vertices *VNXi (i=1, 2…,NbVNX)*, where *NbVNX* is the number of vertices, are obtained via mapping between *VNi* and the results of *PVn*. | *BOPTools_Tools::MakeNewVertex()* and *BOPAlgo_PaveFiller::PerformVertices1()* | +| 7.1 | For each *CommonPart* of type *VERTEX:* Create new vertices *VNi (i=1, 2…,NbVN),* where *NbVN* is the number of new vertices. Merge vertices *VNi* as follows: a) create new object *PFn* of type *BOPAlgo_PaveFiller* with its own DS; b) use new vertices *VNi (i=1, 2…,NbVN), NbVN* as arguments (in terms of *TopoDS_Shape*) of *PFn*; c) invoke method *Perform()* for *PFn*. The resulting vertices *VNXi (i=1, 2…,NbVNX)*, where *NbVNX* is the number of vertices, are obtained via mapping between *VNi* and the results of *PVn*. | *BOPTools_Tools::MakeNewVertex()* and *BOPAlgo_PaveFiller::PerformVertices1()* | | 7.2 | For each *CommonPart* of type *EDGE:* Create common blocks (CBc. C=0, 1…nCs) from pave blocks that lie on the faces. Attach the common blocks to the pave blocks. | *BOPAlgo_Tools::PerformCommonBlocks()* | | 8 | Post-processing. Append the paves of *VNXi* into the corresponding pave blocks in terms of @ref specification__boolean_4_4 "Pave, PaveBlock and CommonBlock". | *BOPDS_PaveBlock:: AppendExtPave()* | | 9 | Split pave blocks and common blocks *CBc* by the paves. | *BOPAlgo_PaveFiller::PerformVertices1()*, *BOPDS_DS:: UpdatePaveBlock()* and *BOPDS_DS:: UpdateCommonBlock()* | @@ -722,7 +722,7 @@ The input data for this step is the DS after computing Face/Face interferences. | No | Contents | Implementation | | :---- | :---- | :---- | -| 1 | For each Face/Face interference *nFi, nFj*, retrieve @ref specification__boolean_4_6 "FaceInfo". Create draft vertices from intersection points *VPk (k=1, 2…, NbVP)*, where *NbVP* is the number of new vertices, and the draft vertex *VPk* is created from an intersection point if *VPk ≠ Vm (m = 0, 1, 2… NbVm)*, where *Vm* is an existing vertex for the faces *nFi* and *nF,j* (*On* or *In* in terms of *TopoDs_Shape*), *NbVm* is the number of vertices existing on faces *nFi* and *nF,j* and ≠ -- means non-coincidence in terms of @ref specification__boolean_3_1_1 "Vertex/Vertex interference". | *BOPAlgo_PaveFiller::MakeBlocks()* | +| 1 | For each Face/Face interference *nFi, nFj*, retrieve @ref specification__boolean_4_6 "FaceInfo". Create draft vertices from intersection points *VPk (k=1, 2…, NbVP)*, where *NbVP* is the number of new vertices, and the draft vertex *VPk* is created from an intersection point if *VPk ≠ Vm (m = 0, 1, 2… NbVm)*, where *Vm* is an existing vertex for the faces *nFi* and *nF,j* (*On* or *In* in terms of *TopoDS_Shape*), *NbVm* is the number of vertices existing on faces *nFi* and *nF,j* and ≠ -- means non-coincidence in terms of @ref specification__boolean_3_1_1 "Vertex/Vertex interference". | *BOPAlgo_PaveFiller::MakeBlocks()* | | 2 | For each intersection curve *Cijk* | | | 2.1 | Create paves PVc for the curve using existing vertices, i.e. vertices On or In (in terms of *FaceInfo*) for faces *nFi* and *nFj*. Append the paves *PVc* | *BOPAlgo_PaveFiller::PutPaveOnCurve()* and *BOPDS_PaveBlock::AppendExtPave()* | | 2.2 | Create technological vertices *Vt*, which are the bounding points of an intersection curve (with the value of tolerance *Tol(Cijk)*). Each vertex *Vt* with parameter *Tt* on curve *Cijk* forms pave *PVt* on curve *Cijk*. Append technological paves. | *BOPAlgo_PaveFiller::PutBoundPaveOnCurve()* | @@ -836,12 +836,12 @@ BOPAlgo_GlueEnum aGlue = BOPAlgo_GlueShift; aBuilder.SetGlue(aGlue); // Disabling/Enabling the check for inverted solids (default is true) -Standard Boolean bCheckInverted = false; +bool bCheckInverted = false; aBuilder.SetCheckInverted(bCheckInverted); // Set OBB usage (default is false) bool bUseOBB = true; -aBuilder.SetUseOBB(buseobb); +aBuilder.SetUseOBB(bUseOBB); // Perform the operation aBuilder.Perform(); @@ -2206,7 +2206,7 @@ const TopoDS_Shape& aResult = aMV.Shape(); // result of the operation #### Tcl Level To use the algorithm in Draw the command mkvolume has been implemented. The usage of this command is following: -~~~~{.php} +~~~~{.tcl} Usage: mkvolume r b1 b2 ... [-c] [-ni] [-ai] Options: -c - use this option to have input compounds considered as set of separate arguments (allows passing multiple arguments as one compound); @@ -2309,7 +2309,7 @@ aResult = aCBuilder.Shape(); // the result #### DRAW usage The following set of new commands has been implemented to run the algorithm in DRAW Test Harness: -~~~~{.php} +~~~~{.tcl} bcbuild : Initialization of the Cells Builder. Use: *bcbuild r* bcadd : Add parts to result. Use: *bcadd r s1 (0,1) s2 (0,1) ... [-m material [-u]]* bcaddall : Add all parts to result. Use: *bcaddall r [-m material [-u]]* @@ -2320,7 +2320,7 @@ bcmakecontainers : Make containers from the parts added to result. Use: *bcmakec ~~~~ Here is the example of the algorithm use on the DRAW level: -~~~~{.php} +~~~~{.tcl} psphere s1 15 psphere s2 15 psphere s3 15 @@ -2343,7 +2343,7 @@ bcremoveint res @subsection specification__boolean_10c_Cells_2 Examples The following simple example illustrates the possibilities of the algorithm working on a cylinder and a sphere intersected by a plane: -~~~~{.php} +~~~~{.tcl} pcylinder c 10 30 psphere s 15 ttranslate s 0 0 30 @@ -2353,7 +2353,7 @@ mkface f p -25 30 -17 17 @figure{/specification/boolean_operations/images/cells_algorithm_001.png,"Arguments",160} -~~~~{.php} +~~~~{.tcl} bclearobjects bcleartools baddobjects c s f @@ -2363,7 +2363,7 @@ bcbuild r #### 1. Common for all arguments -~~~~{.php} +~~~~{.tcl} bcremoveall bcadd res c 1 s 1 f 1 ~~~~ @@ -2372,7 +2372,7 @@ bcadd res c 1 s 1 f 1 #### 2. Common between cylinder and face -~~~~{.php} +~~~~{.tcl} bcremoveall bcadd res f 1 c 1 ~~~~ @@ -2381,7 +2381,7 @@ bcadd res f 1 c 1 #### 3. Common between cylinder and sphere -~~~~{.php} +~~~~{.tcl} bcremoveall bcadd res c 1 s 1 ~~~~ @@ -2390,7 +2390,7 @@ bcadd res c 1 s 1 #### 4. Fuse of cylinder and sphere -~~~~{.php} +~~~~{.tcl} bcremoveall bcadd res c 1 -m 1 bcadd res s 1 -m 1 @@ -2401,7 +2401,7 @@ bcremoveint res #### 5. Parts of the face inside solids - FUSE(COMMON(f, c), COMMON(f, s)) -~~~~{.php} +~~~~{.tcl} bcremoveall bcadd res f 1 s 1 -m 1 bcadd res f 1 c 1 -m 1 @@ -2409,7 +2409,7 @@ bcadd res f 1 c 1 -m 1 @figure{/specification/boolean_operations/images/cells_algorithm_006_1.png,"Parts of the face inside solids",160} -~~~~{.php} +~~~~{.tcl} bcremoveint res ~~~~ @@ -2417,7 +2417,7 @@ bcremoveint res #### 6. Part of the face outside solids -~~~~{.php} +~~~~{.tcl} bcremoveall bcadd res f 1 c 0 s 0 ~~~~ @@ -2426,7 +2426,7 @@ bcadd res f 1 c 0 s 0 #### 7. Fuse operation (impossible using standard Boolean Fuse operation) -~~~~{.php} +~~~~{.tcl} bcremoveall bcadd res c 1 -m 1 bcadd res s 1 -m 1 @@ -2733,7 +2733,7 @@ The following results are obtained using Basic Operations and the Fuzzy ones wit @figure{/specification/boolean_operations/images/boolean_image132.png,"Result of CUT operation obtained with Fuzzy Option",240} -This example stresses not only the validity, but also the performance issue. The usage of Fuzzy option with the appropriate value allows processing the case much faster than with the pure Basic operation. The performance gain for the case is 45 (Processor: Intel(R) Core(TM) i5-3450 CPU @ 3.10 GHz). +This example stresses not only the validity, but also the performance issue. The usage of Fuzzy option with the appropriate value allows processing the case much faster than with the pure Basic operation. The performance gain for the case is 45 (tested on Intel(R) Core(TM) i5-3450 CPU @ 3.10 GHz; results may vary depending on hardware). @subsection specification__boolean_11a_2 Gluing Operation @@ -2777,7 +2777,7 @@ BOPAlgo_Builder aGF; // .... // setting the gluing option to speed up intersection of the arguments -aGF.SetGlue(BOPAlgo_GlueShift) +aGF.SetGlue(BOPAlgo_GlueShift); // .... ~~~~ @@ -2788,7 +2788,7 @@ For setting the Gluing options in DRAW it is necessary to call the bglue * 1 - for partial coincidence; * 2 - for full coincidence -~~~~{.php} +~~~~{.tcl} bglue 1 ~~~~ @@ -2836,7 +2836,7 @@ To enable the safe processing mode for the operation in DRAW, it is necessary to * 0 - default value, the safe mode is switched off; * 1 - the safe mode will be switched on. -~~~~{.php} +~~~~{.tcl} bnondestructive 1 ~~~~ @@ -2867,7 +2867,7 @@ To enable/disable the classification of the solids in DRAW, it is necessary to c * 0 - disabling the classification; * 1 - default value, enabling the classification. -~~~~{.php} +~~~~{.tcl} bcheckinverted 0 ~~~~ @@ -2893,7 +2893,7 @@ aGF.SetUseOBB(true); To enable/disable the usage of OBB in the operation in DRAW it is necessary to call the *buseobb* command with the appropriate value: * 0 - disabling the usage of OBB; * 1 - enabling the usage of OBB. -~~~~{.php} +~~~~{.tcl} buseobb 1 ~~~~ @@ -2919,17 +2919,17 @@ Note that messages corresponding to errors and warnings are defined in resource These messages can be localized; for that put translated version to separate file and load it in the application by call to *Message_MsgFile::Load()* . Here is the example of how to use this system: -~~~~{.php} +~~~~{.cpp} BOPAlgo_PaveFiller aPF; aPF.SetArguments(...); aPF.Perform(); if (aPF.HasErrors()) { aPF.DumpErrors(std::cerr); // - if (aPF.HasError(STANDARD_TYPE(BOPAlgo_AlertNullInputShapes)) { + if (aPF.HasError(STANDARD_TYPE(BOPAlgo_AlertNullInputShapes))) { // some actions } - if (aPF.HasWarning(STANDARD_TYPE(BOPAlgo_AlertTooSmallEdge)) { + if (aPF.HasWarning(STANDARD_TYPE(BOPAlgo_AlertTooSmallEdge))) { // some actions } ... @@ -2939,7 +2939,7 @@ if (aPF.HasErrors()) { DRAW commands executing Boolean operations output errors and warnings generated by these operations in textual form. Additional option allows saving shapes for which warnings have been generated, as DRAW variables. To activate this option, run command *bdrawwarnshapes* with argument 1 (or with 0 to deactivate): -~~~~{.php} +~~~~{.tcl} bdrawwarnshapes 1 ~~~~ @@ -2978,7 +2978,7 @@ But if the faces are fully coinciding, the result must be empty, and both faces Example of the overlapping faces: -~~~~{.php} +~~~~{.tcl} plane p 0 0 0 0 0 1 mkface f1 p -10 10 -10 10 mkface f2 p 0 20 -10 10 @@ -3005,7 +3005,7 @@ Thus, each of the input edges will be Modified into its two splits. But in the CUT operation on the same edges, the tool edge will be Deleted from the result and, thus, will not have any Modified shapes. Example of the intersecting edges: -~~~~{.php} +~~~~{.tcl} line l1 0 0 0 1 0 0 mkedge e1 l1 -10 10 @@ -3051,7 +3051,7 @@ Two intersecting edges will both have the intersection vertices Generated from t As for the operation with intersecting faces, consider the following example: -~~~~{.php} +~~~~{.tcl} plane p1 0 0 0 0 0 1 mkface f1 p1 -10 10 -10 10 @@ -3115,7 +3115,7 @@ For controlling this possibility in DRAW the command **bsimplify** has been impl Here is the simple example of simplification of the result of Fuse operation of two boxes: -~~~~{.php} +~~~~{.tcl} bsimplify -f 1 box b1 10 10 15 @@ -3205,7 +3205,7 @@ The following example illustrates how to use General Fuse operator: #### Tcl Level -~~~~{.php} +~~~~{.tcl} # prepare the arguments box b1 10 10 10 box b2 3 4 5 10 10 10 @@ -3236,7 +3236,7 @@ The following example illustrates how to use the Splitter operator: #include #include // -BRepAlgoAPI_BuilderAlgo aSplitter; +BRepAlgoAPI_Splitter aSplitter; // // prepare the arguments // objects @@ -3265,7 +3265,7 @@ const TopoDS_Shape& aResult = aSplitter.Shape(); #### Tcl Level -~~~~{.php} +~~~~{.tcl} # prepare the arguments # objects box b1 10 10 10 @@ -3300,7 +3300,7 @@ The following example illustrates how to use Common operation: ~~~~{.cpp} #include #include -#include < BRepAlgoAPI_Common.hxx> +#include {… bool bRunParallel; double aFuzzyValue; @@ -3336,7 +3336,7 @@ The following example illustrates how to use Common operation: #### Tcl Level -~~~~{.php} +~~~~{.tcl} # prepare the arguments box b1 10 10 10 box b2 7 0 4 10 10 10 @@ -3367,7 +3367,7 @@ The following example illustrates how to use Fuse operation: ~~~~{.cpp} #include #include -#include < BRepAlgoAPI_Fuse.hxx> +#include {… bool bRunParallel; double aFuzzyValue; @@ -3403,7 +3403,7 @@ The following example illustrates how to use Fuse operation: #### Tcl Level -~~~~{.php} +~~~~{.tcl} # prepare the arguments box b1 10 10 10 box b2 7 0 4 10 10 10 @@ -3434,7 +3434,7 @@ The following example illustrates how to use Cut operation: ~~~~{.cpp} #include #include -#include < BRepAlgoAPI_Cut.hxx> +#include {… bool bRunParallel; double aFuzzyValue; @@ -3470,7 +3470,7 @@ The following example illustrates how to use Cut operation: #### Tcl Level -~~~~{.php} +~~~~{.tcl} # prepare the arguments box b1 10 10 10 box b2 7 0 4 10 10 10 @@ -3502,7 +3502,7 @@ The following example illustrates how to use Section operation: ~~~~{.cpp} #include #include -#include < BRepAlgoAPI_Section.hxx> +#include {… bool bRunParallel; double aFuzzyValue; @@ -3538,7 +3538,7 @@ The following example illustrates how to use Section operation: #### Tcl Level -~~~~{.php} +~~~~{.tcl} # prepare the arguments box b1 10 10 10 box b2 3 4 5 10 10 10 diff --git a/dox/specification/brep_format.md b/dox/specification/brep_format.md index 4565bb21ac..be7be27627 100644 --- a/dox/specification/brep_format.md +++ b/dox/specification/brep_format.md @@ -9,6 +9,8 @@ BRep Format {#specification__brep_format} of vertices, edges, wires, faces, shells, solids, compsolids, compounds, edge triangulations, face triangulations, polylines on triangulations, space location and orientation. Any set of such models may be stored as a single model which is a compound of the models. + + @note This document describes the **ASCII** BREP format produced by `BRepTools` (`Write` / `Read`), whose header line is `CASCADE Topology V1/V2/V3`. OCCT also ships a **binary** BREP format, produced by the `BinTools` package (`BinTools::Write` / `BinTools::Read`), with its own independent header sequence (`Open CASCADE Topology V1`..`V4`). The two formats share most of the geometric content but differ in framing and tokenization, and are not interchangeable. The format is described in an order which is convenient for understanding rather than in the order the format parts follow each other. @@ -1124,7 +1126,7 @@ The example record is interpreted as a circle which has a center *P*=(1,2). Th **Description** -\<2D curve record 3\> describes an ellipse. The ellipse data are 2D point *P*, orthogonal 2D directions *Dmaj* and *Dmin* and non-negative reals *rmaj* and *rmin* that *rmaj* @f$ \leq @f$ *rmin*. The ellipse has a center *P*, major and minor axis directions *Dmaj* and *Dmin*, major and minor radii *rmaj* and *rmin* and is defined by the following parametric equation: +\<2D curve record 3\> describes an ellipse. The ellipse data are 2D point *P*, orthogonal 2D directions *Dmaj* and *Dmin* and non-negative reals *rmaj* and *rmin* that *rmaj* @f$ \geq @f$ *rmin*. The ellipse has a center *P*, major and minor axis directions *Dmaj* and *Dmin*, major and minor radii *rmaj* and *rmin* and is defined by the following parametric equation: @f[ C(u)=P+r_{maj} \cdot cos(u) \cdot D_{maj}+r_{min} \cdot sin(u) \cdot D_{min},\; u \in [0,\; 2 \cdot \pi) . @f] @@ -1193,7 +1195,7 @@ The example record is interpreted as a parabola in plane which passes through a @f[ C(u)=P+k_{x} \cdot cosh(u) D_{x}+k_{y} \cdot sinh(u) \cdot D_{y},\; u \in (-\infty,\; \infty). @f] -The example record is interpreted as a hyperbola with coordinate system which has origin *P*=(1,2) and axis directions *Dx*=(1,0) and *Dy*=(0,1). Other data for the hyperbola are *kx*=5 and *ky*=4. The hyperbola is defined by the following parametric equation: @f$ C(u)=(1,2)+3 \cdot cosh(u) \cdot (1,0)+4 \cdot sinh(u) \cdot (0,1) @f$. +The example record is interpreted as a hyperbola with coordinate system which has origin *P*=(1,2) and axis directions *Dx*=(1,0) and *Dy*=(0,1). Other data for the hyperbola are *kx*=3 and *ky*=4. The hyperbola is defined by the following parametric equation: @f$ C(u)=(1,2)+3 \cdot cosh(u) \cdot (1,0)+4 \cdot sinh(u) \cdot (0,1) @f$. @subsubsection specification__brep_format_5_3_6 Bezier Curve - \<2D curve record 6\> diff --git a/dox/specification/pbr_math.md b/dox/specification/pbr_math.md index 52f68b26df..5007e938e5 100644 --- a/dox/specification/pbr_math.md +++ b/dox/specification/pbr_math.md @@ -627,7 +627,7 @@ Lets go back to diffuse indirect illumination component represented by following Of course, Monte-Carlo algorithm can be applied directly and hemisphere integral can be precalculated for every normal direction but dependence from \f$v\f$ in Fresnel's factor does not allow to do it efficiently (every \f$v\f$ direction is needed to be considered again). -In order to resolve it modified version of Schlick's approximation has been created [[?](TODO)]: +In order to resolve it, a modified version of Schlick's approximation has been created: \f[F \approx F_{ss}=F_0+(\max(1-r, F_0))(1-\cos\theta_v)^5\f] @@ -770,11 +770,11 @@ As practice shows this is very good approximation of diffuse indirect illuminati @section pbr_transparency Transparent materials -TODO +Content to be provided. @section pbr_low_discrepancy Low discrepancy sequence -TODO +Content to be provided. @section pbr_references References @@ -868,7 +868,7 @@ Romain Guy, Mathias Agopian, "Physically Based Rendering in Filament", *Part of @anchor Aguilar17 **[Aguilar17]** Orlando Aguilar, "Spherical Harmonics", *Blog post*: -[http://orlandoaguilar.github.io/sh/spherical/harmonics/irradiance/map/2017/02/12/SphericalHarmonics.html](http://orlandoaguilar.github.io/sh/spherical/harmonics/irradiance/map/2017/02/12/SphericalHarmonics.html) +[https://orlandoaguilar.github.io/sh/spherical/harmonics/irradiance/map/2017/02/12/SphericalHarmonics.html](https://orlandoaguilar.github.io/sh/spherical/harmonics/irradiance/map/2017/02/12/SphericalHarmonics.html) diff --git a/dox/tutorial/tutorial.md b/dox/tutorial/tutorial.md index e1d3d52bb8..fd2a41be7f 100644 --- a/dox/tutorial/tutorial.md +++ b/dox/tutorial/tutorial.md @@ -20,7 +20,7 @@ To illustrate the use of classes provided in the 3D geometric modeling toolkits, @figure{/tutorial/images/tutorial_image001.png,"",240} height=350px -In the tutorial we will create, step-by-step, a function that will model a bottle as shown above. You will find the complete source code of this tutorial, including the very function *MakeBottle* in the distribution of Open CASCADE Technology. The function body is provided in the file samples/qt/Tutorial/src/MakeBottle.cxx. +In 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 in the appendix below. @subsection OCCT_TUTORIAL_SUB1_3 Model Specifications @@ -50,7 +50,7 @@ This modeling requires four steps: To create the bottle's profile, you first create characteristic points with their coordinates as shown below in the (XOY) plane. These points will be the supports that define the geometry of the profile. -@figure{tutorial/images/tutorial_image003.svg,"",466} +@figure{/tutorial/images/tutorial_image003.svg,"",466} There are two classes to describe a 3D Cartesian point from its X, Y and Z coordinates in Open CASCADE Technology: @@ -96,6 +96,7 @@ This is because the *GC* provides two algorithm classes which are exactly what i 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} + // For production code, prefer the explicit IsDone()/Value() pattern shown below. occ::handle aArcOfCircle = GC_MakeArcOfCircle(aPnt2,aPnt3,aPnt4); occ::handle aSegment1 = GC_MakeSegment(aPnt1, aPnt2); occ::handle aSegment2 = GC_MakeSegment(aPnt4, aPnt5); @@ -106,7 +107,7 @@ All *GC* classes provide a casting method to obtain a result automatically with ~~~~{.cpp} GC_MakeSegment mkSeg (aPnt1, aPnt2); occ::handle aSegment1; - if(mkSegment.IsDone()){ + if(mkSeg.IsDone()){ aSegment1 = mkSeg.Value(); } else { @@ -144,6 +145,8 @@ Referring to the previous table, to build the profile, you will create: 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: +**Note:** In production code, `IsDone()` should be checked on all builder operations before accessing their results. The tutorial omits these checks for brevity. + ~~~~{.cpp} TopoDS_Edge anEdge1 = BRepBuilderAPI_MakeEdge(aSegment1); TopoDS_Edge anEdge2 = BRepBuilderAPI_MakeEdge(aArcOfCircle); @@ -153,8 +156,8 @@ To create an edge, you use the BRepBuilderAPI_MakeEdge class with the previously 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, anEdge1 and anEdge3 could have been computed in a simpler way: ~~~~{.cpp} - TopoDS_Edge anEdge1 = BRepBuilderAPI_MakeEdge(aPnt1, aPnt3); - TopoDS_Edge anEdge2 = BRepBuilderAPI_MakeEdge(aPnt4, aPnt5); + TopoDS_Edge anEdge1 = BRepBuilderAPI_MakeEdge(aPnt1, aPnt2); + TopoDS_Edge anEdge3 = 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: @@ -437,7 +440,7 @@ DynamicType returns the real type of the object, but you need to compare it with 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(!aSurface.IsNull() && aSurface->DynamicType() == STANDARD_TYPE(Geom_Plane)){ } ~~~~ @@ -457,11 +460,14 @@ Remember that the goal of all these conversions is to find the highest face of t 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(); - double aZ = aPnt.Z(); - if(aZ > zMax){ - zMax = aZ; - faceToRemove = aFace; + if (!aPlane.IsNull()) + { + gp_Pnt aPnt = aPlane->Location(); + double aZ = aPnt.Z(); + if(aZ > zMax){ + zMax = aZ; + faceToRemove = aFace; + } } ~~~~ @@ -469,6 +475,8 @@ You have now found the top face of the neck. Your final step before creating the 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. +@note In OCCT 8.0.0 the package-level `TCol*` typedefs are deprecated. Prefer `NCollection_*` directly -- see the @ref upgrade_occt800 "Upgrade to OCCT 8.0.0". + ~~~~{.cpp} NCollection_List facesToRemove; facesToRemove.Append(faceToRemove); @@ -700,13 +708,13 @@ Congratulations! Your bottle is complete. Here is the result snapshot of the Tut @figure{/tutorial/images/tutorial_image019.png,"",320} height=450px 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 https://www.opencascade.com/content/technology-support. Our professional services can maximize the power of your Open CASCADE Technology applications. +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 https://www.opencascade.com/content/technology-support (commercial product page, URL may change). 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): +Complete definition of MakeBottle function: ~~~~{.cpp} TopoDS_Shape MakeBottle(const double myWidth, const double myHeight, @@ -772,7 +780,16 @@ Complete definition of MakeBottle function (defined in the file src/MakeBottle.c BRepPrimAPI_MakeCylinder MKCylinder(neckAx2, myNeckRadius, myNeckHeight); TopoDS_Shape myNeck = MKCylinder.Shape(); - myBody = BRepAlgoAPI_Fuse(myBody, myNeck); + BRepAlgoAPI_Fuse aFuser(myBody, myNeck); + if (aFuser.IsDone()) + { + myBody = aFuser.Shape(); + } + else + { + // Fuse failed; proceed with unmodified myBody. + // In production code, report the error and handle the failure appropriately. + } // Body : Create a Hollowed Solid TopoDS_Face faceToRemove; @@ -782,13 +799,16 @@ Complete definition of MakeBottle function (defined in the file src/MakeBottle.c TopoDS_Face aFace = TopoDS::Face(aFaceExplorer.Current()); // Check if is the top face of the bottle's neck occ::handle aSurface = BRep_Tool::Surface(aFace); - if(aSurface->DynamicType() == STANDARD_TYPE(Geom_Plane)){ + if(!aSurface.IsNull() && aSurface->DynamicType() == STANDARD_TYPE(Geom_Plane)){ occ::handle aPlane = occ::down_cast(aSurface); - gp_Pnt aPnt = aPlane->Location(); - double aZ = aPnt.Z(); - if(aZ > zMax){ - zMax = aZ; - faceToRemove = aFace; + if (!aPlane.IsNull()) + { + gp_Pnt aPnt = aPlane->Location(); + double aZ = aPnt.Z(); + if(aZ > zMax){ + zMax = aZ; + faceToRemove = aFace; + } } } } @@ -846,4 +866,3 @@ Complete definition of MakeBottle function (defined in the file src/MakeBottle.c return aRes; } ~~~~ - diff --git a/dox/upgrade/upgrade.md b/dox/upgrade/upgrade.md index 1616d381de..790839dc09 100644 --- a/dox/upgrade/upgrade.md +++ b/dox/upgrade/upgrade.md @@ -7,7 +7,7 @@ Upgrade from older OCCT versions {#occt__upgrade} This document provides technical details on changes made in particular versions of OCCT. It can help to upgrade user applications based on previous versions of OCCT to newer ones. -@ref upgrade_occt790 "SEEK TO THE LAST CHAPTER (UPGRADE TO 7.9.0)" +@ref upgrade_occt800 "SEEK TO THE LAST CHAPTER (UPGRADE TO 8.0.0)" @subsection upgrade_intro_precautions Precautions @@ -26,987 +26,10 @@ The automatic upgrade tool is provided as is, without warranty of any kind, and It is your responsibility to ensure that the changes you made in your code are correct. When you upgrade the code by an automatic script, make sure to carefully review the introduced changes at each step before committing them. -@section upgrade_65 Upgrade to OCCT 6.5.0 +@section upgrade_pre_7_1 Upgrades pre-7.1.0 -Porting of user applications from an earlier OCCT version to version 6.5 requires taking into account the following major changes: -* If you are not comfortable with dependence on Intel TBB, FreeImage, or Gl2Ps libraries, you will need to (re)build OCCT with these dependencies disabled. -* The low-level format version of OCAF binary and XML persistence has been incremented. Hence, the files saved by OCCT 6.5 to OCAF binary or XML format will not be readable by previous versions of OCCT. -* The *BRepMesh* triangulation algorithm has been seriously revised and now tries hard to fulfill the requested deflection and angular tolerance parameters. If you experience any problems with performance or triangulation quality (in particular, display of shapes in shading mode), consider revising the values of these parameters used in your application. -* If you were using method *ToPixMap()* of class *V3d_View* to get a buffer for passing to Windows API functions (e.g. *BitBlt*), this will not work anymore. You will need to use method *Image_PixMap::AccessBuffer()* to get the raw buffer data that can be further passed to WinAPI functions. -* As the processing of message gravity parameter in *Message* package has been improved, some application messages (especially the ones generated by IGES or STEP translators) can be suppressed or new messages appear in the application. Use relevant message level parameter to tune this behavior. +Detailed upgrade notes for OCCT versions 6.5.0 through 7.0.0 are available in the versioned documentation archives at https://dev.opencascade.org/doc (e.g. https://dev.opencascade.org/doc/occt-7.0.0/overview/html/index.html). Refer to the [OCCT GitHub releases](https://github.com/Open-Cascade-SAS/OCCT/releases) for per-version change logs. -@section upgrade_651 Upgrade to OCCT 6.5.1 - -Porting of user applications from an earlier OCCT version to version 6.5.1 requires taking into account the following major changes: - -* Method *Graphic3d_Structure::Groups()* now returns *Graphic3d_SequenceOfGroup*. If this method has been used, the application code should be updated to iterate another collection type or, if *Graphic3d_HSetOfGroup* is required, to fill its own collection: -~~~~{.cpp} -const NCollection_Sequence>& aGroupsSeq = theStructure.Groups(); -occ::handle aGroupSet = new Graphic3d_HSetOfGroup(); -int aLen = aGroupsSeq.Length(); -for (int aGr = 1; aGr <= aLen; ++aGr) -{ - aGroupSet->Add (aGroupsSeq.Value (aGr)); -} -~~~~ - -* All occurrences of *Select3D_Projector* in the application code (if any) should be replaced with *Handle(Select3D_Projector)*. -* The code of inheritors of *Select3D_SensitiveEntity* should be updated if they override Matches() (this is probable, if clipping planes are used). -* Constructor for *V3d_Plane* has been changed, so the extra argument should be removed if used in the application. It is necessary to add a new plane using method *V3d_Viewer::AddPlane()* if *V3d_Viewer* has been used to manage clipping planes list (this does not affect clipping planes representation). Have a look at the source code for new DRAWEXE *vclipplane* command in *ViewerTest_ObjectsCommands.cxx, VClipPlane* to see how clipping planes can be managed in the application. - -@section upgrade_652 Upgrade to OCCT 6.5.2 - -Porting of user applications from an earlier OCCT version to version 6.5.2 requires taking into account the following major changes: -* Any code that has been generated by WOK from CDL generic classes *Tcollection_DataMap* and *Tcollection_IndexedDataMap* needs to be regenerated by WOK to take into account the change in the interface of these classes. -* The enumerations *CDF_StoreStatus* and *CDF_RetrievableStatus* have been replaced by the enumerations *PCDM_StoreStatus* and *PCDM_ReaderStatus*. Correspondingly, the methods *Open, Save* and *SaveAs* of the class *TDocStd_Application* have changed their return value. Any code, which uses these enumerations, needs to be updated. -* *BRepLib_MakeFace* has been modified to receive tolerance value for resolution of degenerated edges. This tolerance parameter has no default value to ensure that the client code takes care of passing a meaningful value, not just *Precision::Confusion*, so some porting overheads are expected. -* If the callback mechanism in call_togl_redraw function was used in the application code, it is necessary to revise it to take into account the new callback execution and provide a check of reason value of Aspect_GraphicCallbackStruct in callback methods to confirm that the callback code is executed at the right moment. Now the callbacks are executed before redrawing the underlayer, before redrawing the overlayer and at the end of redrawing. The information about the moment when the callback is invoked is provided with the reason value in form of an additional bit flag (OCC_PRE_REDRAW, OCC_PRE_OVERLAY). The state of OpenGl changed in callback methods will not be restored automatically, which might lead to unwanted behavior in redrawing procedure. -* The print method used in the application code might need to be revised to take into account the ability to choose between print algorithms: tile and stretch. The stretch algorithm will be selected by default during porting. -* It is recommended to *BRepMesh_DiscretFactory* users, to check *BRepMesh_DiscretFactory::SetDefault()* return value to determine plugin availability / validity. *BRepMesh_DiscretFactory::Discret()* method now returns handle instead of pointer. The code should be updated in the following manner: -~~~~{.cpp} -occ::handle aMeshAlgo = BRepMesh_DiscretFactory::Get().Discret (theShape, theDeflection, theAngularToler); - if (!aMeshAlgo.IsNull()) {} -~~~~ - -* The default state of *BRepMesh* parallelization has been turned off. The user should switch this flag explicitly: - * by using methods *BRepMesh_IncrementalMesh::SetParallel(Standard_True)* for each *BRepMesh_IncrementalMesh* instance before Perform(); - * by calling *BRepMesh_IncrementalMesh::SetParallelDefault(Standard_True)* when *BRepMesh_DiscretFactory* is used to retrieve the meshing tool (this also affects auto-triangulation in *AIS*). - -@section upgrade_653 Upgrade to OCCT 6.5.3 - -Porting of user applications from an earlier OCCT version to version 6.5.3 requires taking into account the following major changes: -* As a result of code clean-up and redesign of *TKOpenGl* driver, some obsolete functions and rendering primitives (TriangleMesh, TriangleSet, Bezier, Polyline, Polygon, PolygonHoles, QuadrangleMesh and *QuadrangleSet*) have been removed. Instead, the application developers should use primitive arrays that provide the same functionality but are hardware-accelerated. The details can be found in OCCT Visualization User's Guide, “Primitive Arrays” chapter. -* Applications should not call *AIS_InteractiveObject::SetPolygonOffsets()* method for an instance of *AIS_TexturedShape* class after it has been added to *AIS_InteractiveContext*. More generally, modification of *Graphic3d_AspectFillArea3d* parameters for the computed groups of any *AIS_InteractiveObject* subclass that uses texture mapping should be avoided, because this results in broken texture mapping (see issue 23118). It is still possible to apply non-default polygon offsets to *AIS_TexturedShape* by calling *SetPolygonOffsets()* before displaying the shape. -* The applications that might have used internal functions provided by *TKOpenGl* or removed primitives will need to be updated. -* In connection with the implementation of Z-layers it might be necessary to revise the application code or revise the custom direct descendant classes of *Graphic3d_GraphicDriver* and *Graphic3d_StructureManager* to use the Z-layer feature. -* Global variables *Standard_PI* and *PI* have been eliminated (use macro *M_PI* instead). -* Method *HashCode()* has been removed from class *Standard_Transient*. It is advisable to use global function HashCode() for Handle objects instead. -* Declaration of operators new/delete for classes has become consistent and is encapsulated in macros. -* Memory management has been changed to use standard heap (MMGT_OPT=0) and reentrant mode (MMGT_REENTRANT=1) by default. -* Map classes in *NCollection* package now receive one more argument defining a hash tool. - -@section upgrade_654 Upgrade to OCCT 6.5.4 - -Porting of user applications from an earlier OCCT version to version 6.5.4 requires taking into account the following major changes: -* The code using obsolete classes *Aspect_PixMap, Xw_PixMap* and *WNT_PixMap* should be rewritten implementing class *Image_PixMap*, which is now retrieved by *ToPixMap* methods as argument. A sample code using *ToPixMap* is given below: -~~~~{.cpp} -#include -void dump (occ::handle& theView3D) -{ - int aWndSizeX = 0; - int aWndSizeY = 0; - theView3D->Window()->Size (aWndSizeX, aWndSizeY); - Image_AlienPixMap aPixMap; - theView3D->ToPixMap (aPixMap, aWndSizeX, aWndSizeY); - aPixMap.Save ("c:\\image.png"); -} -~~~~ -* Now OpenGL resources related to Interactive Objects are automatically freed when the last view (window) is removed from graphical driver. -To avoid presentation data loss, the application should replace an old view with a new one in the proper order: first the new view is created and activated and only then the old one is detached and removed. -* It is recommended to use *NCollection* containers with hasher parameter (introduced in 6.5.3) instead of global definition IsEqual()/HashCode() as well as to use explicit namespaces to avoid name collision. - - -@section upgrade_660 Upgrade to OCCT 6.6.0 - -Porting of user applications from an earlier OCCT version to version 6.6.0 requires taking into account the following major changes: -* Due to the changes in the implementation of Boolean Operations, the order of sub-shapes resulting from the same operation performed with OCCT 6.5.x and OCCT 6.6.0 can be different. -It is necessary to introduce the corresponding changes in the applications for which the order of sub-shapes resulting from a Boolean operation is important. It is strongly recommended to use identification methods not relying on the order of sub-shapes (e.g. OCAF naming). -* If you need to use OCCT on Mac OS X with X11 (without Cocoa), build OCCT with defined pre-processor macro *CSF_MAC_USE_GLX11*. XLib front-end (previously the only way for unofficial OCCT builds on Mac OS X) is now disabled by default on this platform. If your application has no support for Cocoa framework you may build OCCT with XLib front-end adding *MACOSX_USE_GLX* macro to compiler options (you may check the appropriate option in WOK configuration GUI and in CMake configuration). Notice that XQuartz (XLib implementation for Mac OS X) now is an optional component and does not provide a sufficient level of integrity with native (Cocoa-based) applications in the system. It is not possible to build OCCT with both XLib and Cocoa at the same time due to symbols conflict in OpenGL functions. -* Animation mode and degeneration presentation mode (simplified presentation for animation) and associated methods have been removed from 3D viewer functionality. -Correspondingly, the code using methods *SetAnimationModeOn(), SetAnimationModeOff(), AnimationModeIsOn(), AnimationMode(), Tumble(), SetDegenerateModeOn(), SetDegenerateModeOff()* and *DegenerateModeIsOn()* of classes *V3d_View* and *Visual3d_View* will need to be removed or redesigned. Hidden Line Removal presentation was not affected; however, the old code that used methods *V3d_View::SetDegenerateModeOn* or *V3d_View::SetDegenerateModeOff* to control HLR presentation should be updated to use *V3d_View::SetComputedMode* method instead. -* Calls of *Graphic3d_Group::BeginPrimitives()* and *Graphic3d_Group::EndPrimitives()* should be removed from the application code. -* Application functionality for drawing 2D graphics that was formerly based on *TKV2d* API should be migrated to *TKV3d* API. The following changes are recommended for this migration: - * A 2D view can be implemented as a *V3d_View* instance belonging to *V3d_Viewer* managed by *AIS_InteractiveContext* instance. To turn *V3d_View* into a 2D view, the necessary view orientation should be set up at the view initialization stage using *V3d_View::SetProj()* method, and view rotation methods simply should not be called. - * Any 2D graphic entity (formerly represented with *AIS2D_InteractiveObject*) should become a class derived from *AIS_InteractiveObject* base. These entities should be manipulated in a view using *AIS_InteractiveContext* class API. - * All drawing code should be put into *Compute()* virtual method of a custom interactive object class and use API of *Graphic3d* package. In particular, all geometry should be drawn using class hierarchy derived from *Graphic3d_ArrayOfPrimitives*. Normally, the Z coordinate for 2D geometry should be constant, unless the application implements some advanced 2D drawing techniques like e.g. multiple "Z layers" of drawings. - * Interactive selection of 2D presentations should be set up inside *ComputeSelection()* virtual method of a custom interactive object class, using standard sensitive entities from *Select3D* package and standard or custom entity owners derived from *SelectMgr_EntityOwner* base. -Refer to the Visualization User's Guide for further details concerning OCCT 3D visualization and selection classes. See also *Viewer2D* OCCT sample application, which shows how 2D drawing can be implemented using TKV3d API. -* Run-time graphic driver library loading mechanism based on *CSF_GraphicShr* environment variable usage has been replaced by explicit linking against *TKOpenGl* library. The code sample below shows how the graphic driver should be created and initialized in the application code: -~~~~{.cpp} -// initialize a new viewer with OpenGl graphic driver -occ::handle aGraphicDriver = -new OpenGl_GraphicDriver ("TKOpenGl"); - aGraphicDriver->Begin (new Aspect_DisplayConnection()); - TCollection_ExtendedString aNameOfViewer ("Visu3D"); - occ::handle aViewer -= new V3d_Viewer (aGraphicDriver, aNameOfViewer.ToExtString()); - aViewer->Init(); - -// create a new window or a wrapper over the existing window, -// provided by a 3rd-party framework (Qt, MFC, C# or Cocoa) -#if defined(_WIN32) || defined(__WIN32__) - Aspect_Handle aWindowHandle = (Aspect_Handle )winId(); - occ::handle aWindow = new WNT_Window (winId()); -#elif defined(__APPLE__) && !defined(MACOSX_USE_GLX) - NSView* aViewHandle = (NSView* )winId(); - occ::handle aWindow = new Cocoa_Window (aViewHandle); -#else - Aspect_Handle aWindowHandle = (Aspect_Handle )winId(); - occ::handle aWindow = - new Xw_Window (aGraphicDriver->GetDisplayConnection(), aWindowHandle); -#endif // WNT - -// setup the window for a new view - occ::handle aView = aViewer->CreateView(); - aView->SetWindow (aWindow); -~~~~ - -* The following changes should be made in the application-specific implementations of texture aspect: - * *Graphic3d_TextureRoot* inheritors now should return texture image by overloading of *Graphic3d_TextureRoot::GetImage()* method instead of the old logic. - * Now you can decide if the application should store the image copy as a field of property or reload it dynamically each time (to optimize the memory usage). The default implementation (which loads the image content from the provided file path) does not hold an extra copy since it will be uploaded to the graphic memory when first used. - * Notice that the image itself should be created within *Image_PixMap* class from *AlienImage* package, while *Image_Image* class is no more supported and will be removed in the next OCCT release. - -@section upgrade_670 Upgrade to OCCT 6.7.0 - -Porting of user applications from an earlier OCCT version to version 6.7.0 requires taking into account the following major changes. - -@subsection upgrade_670_clipping Object-level clipping and capping algorithm. - -* It might be necessary to revise and port code related to management of view-level clipping to use *Graphic3d_ClipPlane* instead of *V3d_Plane* instances. Note that *V3d_Plane* class has been preserved -- as previously, it can be used as plane representation. Another approach to represent *Graphic3d_ClipPlane* in a view is to use custom presentable object. -* The list of arguments of *Select3D_SensitiveEntity::Matches()* method for picking detection has changed. Since now, for correct selection clipping, the implementations should perform a depth clipping check and return (as output argument) minimum depth value found at the detected part of sensitive. Refer to CDL / Doxygen documentation to find descriptive hints and snippets. -* *Select3D_SensitiveEntity::ComputeDepth()* abstract method has been removed. Custom implementations should provide depth checks by method *Matches()* instead -- all data required for it is available within a scope of single method. -* It might be necessary to revise the code of custom sensitive entities and port *Matches()* and *ComputeDepth()* methods to ensure proper selection clipping. Note that obsolete signature of *Matches* is not used anymore by the selector. If your class inheriting *Select3D_SensitiveEntity* redefines the method with old signature the code should not compile as the return type has been changed. This is done to prevent override of removed methods. - -@subsection upgrade_670_markers Redesign of markers presentation - -* Due to the redesign of *Graphic3d_AspectMarker3d* class the code of custom markers initialization should be updated. Notice that you can reuse old markers definition code as *TColStd_HArray1OfByte*; however, *Image_PixMap* is now the preferred way (and supports full-color images on modern hardware). -* Logics and arguments of methods *AIS_InteractiveContext::Erase()* and *AIS_InteractiveContext::EraseAll()* have been changed. Now these methods do not remove resources from *Graphic3d_Structure*; they simply change the visibility flag in it. Therefore, the code that deletes and reсomputes resources should be revised. -* *Graphic3d_Group::MarkerSet()* has been removed. *Graphic3d_Group::AddPrimitiveArray()* should be used instead to specify marker(s) array. - -@subsection upgrade_670_views Default views are not created automatically - -As the obsolete methods *Init(), DefaultOrthographicView()* and *DefaultPerspectiveView()* have been removed from *V3d_Viewer* class, the two default views are no longer created automatically. It is obligatory to create *V3d_View* instances explicitly, either directly by operator new or by calling *V3d_Viewer::CreateView()*. - -The call *V3d_Viewer::SetDefaultLights()* should also be done explicitly at the application level, if the application prefers to use the default light source configuration. Otherwise, the application itself should set up the light sources to obtain a correct 3D scene. - -@subsection upgrade_670_dimensions Improved dimensions implementation - -* It might be necessary to revise and port code related to management of *AIS_LengthDimension, AIS_AngleDimension* and *AIS_DiameterDimension* presentations. There is no more need to compute value of dimension and pass it as string to constructor argument. The value is computed internally. The custom value can be set with *SetCustomValue()* method. -* The definition of units and general aspect properties is now provided by *Prs3d_DimensionUnits* and *Prs3d_DimensionApsect* classes. -* It might be also necessary to revise code of your application related to usage of *AIS_DimensionDisplayMode enumeration*. If it used for specifying the selection mode, then it should be replaced by a more appropriate enumeration *AIS_DimensionSelectionMode*. - -@subsection upgrade_670_list_collection NCollection_Set replaced by List collection - -It might be necessary to revise your application code, which uses non-ordered *Graphic3d_SetOfHClipPlane* collection type and replace its occurrences by ordered *Graphic3d_SequenceOfHClipPlane* collection type. - - -@section upgrade_680 Upgrade to OCCT 6.8.0 - -Porting of user applications from an earlier OCCT version to version 6.8.0 requires taking into account the following major changes. - -@subsection upgrade_680_ncollection Changes in NCollection classes - -Method *Assign()* in *NCollection* classes does not allow any more copying between different collection types. Such copying should be done manually. - -List and map classes in *NCollection* package now require that their items be copy-constructible, but do not require items to have default constructor. Thus the code using *NCollection* classes for non-copy-constructible objects needs be updated. One option is to provide copy constructor; another possibility is to use Handle or other smart pointer. - -@subsection upgrade_680_view_camera 3D View Camera - -If *ViewMapping* and *ViewOrientation* were used directly, this functionality has to be ported to the new camera model. The following methods should be considered as an alternative to the obsolete *Visual3d* services (all points and directions are supposed to be in world coordinates): -* *Graphic3d_Camera::ViewDimensions()* or *V3d_View::Size()/ZSize()* -- returns view width, height and depth (or "Z size"). Since the view is symmetric now, you can easily compute top, bottom, left and right limits. *Graphic3d_Camera::ZNear()/ZFar()* can be used to obtain the near and far clipping distances with respect to the eye. -* *Graphic3d_Camera::Up()* or *V3d_View::Up()* -- returns Y direction of the view. -* *Graphic3d_Camera::Direction()* returns the reverse view normal directed from the eye, *V3d_View::Proj()* returns the old-style view normal. -* *Graphic3d_Camera::Eye()* or *V3d_View::Eye()* -- returns the camera position (same as projection reference point in old implementation). -* *Graphic3d_Camera::Center()* or *V3d_View::At()* -- returns the point the camera looks at (or view reference point according to old terminology). - -The current perspective model is not fully backward compatible, so the old perspective-related functionality needs to be reviewed. - -Revise application-specific custom presentations to provide a proper bounding box, otherwise the object might become erroneously clipped by automatic *ZFit* or frustum culling algorithms enabled by default. - -@subsection upgrade_680_connected_objects Redesign of Connected Interactive Objects - -The new implementation of connected Interactive Objects makes it necessary to take the following steps if you use connected Interactive Objects in your application. -* Use new *PrsMgr_PresentableObject* transformation API. -* Call *RemoveChild()* from the original object after connect if you need the original object and *AIS_ConnectedInteractive* to move independently. -* Access instances of objects connected to *AIS_MultiplyConnectedInteractive* with *Children()* method. -* For *PrsMgr_PresentableObject* transformation: - * *SetLocation (TopLoc_Location) -> SetLocalTransformation (gp_Trsf)* - * *Location -> LocalTransformation* - * *HasLocation -> HasTransformation* - * *ResetLocation -> ResetTransformation* - -@subsection upgrade_680_unicode Support of UNICODE Characters - -Support of UNICODE characters introduced in OCCT breaks backward compatibility with applications, which currently use filenames in extended ASCII encoding bound to the current locale. Such applications should be updated to convert such strings to UTF-8 format. - -The conversion from UTF-8 to wchar_t is made using little-endian approach. Thus, this code will not work correctly on big-endian platforms. It is needed to complete this in the way similar as it is done for binary persistence (see the macro *DO_INVERSE* in *FSD_FileHeader.hxx).* - -@subsection upgrade_680_projection_shift Elimination of Projection Shift Concept - -It might be necessary to revise the application code, which deals with *Center()* method of *V3d_View*. - -This method was used to pan a *V3d* view by virtually moving the screen center with respect to the projection ray passed through Eye and At points. There is no more need to derive the panning from the Center parameter to get a camera-like eye position and look at the coordinates. *Eye()* and *At()* now return these coordinates directly. When porting code dealing with *Center()*, the parameters *Eye()* and *At()* can be adjusted instead. Also *V3d_View::SetCenter(Xpix, Ypix)* method can be used instead of *V3d_View::Center(X, Y)* to center the view at the given point. However, if the center coordinates X and Y come from older OCCT releases, calling *V3d_View::Panning(-X, -Y)* can be recommended to compensate missing projection shift effect. - -There are several changes introduced to *Graphic3d_Camera*. The internal data structure of the camera is based on *Standard_Real* data types to avoid redundant application-level conversions and precision errors. The transformation matrices now can be evaluated both for *Standard_Real* and *Standard_ShortReal* value types. *ZNear* and *ZFar* planes can be either negative or positive for orthographic camera projection, providing a trade-off between the camera distance and the range of *ZNear* or *ZFar* to reduce difference of exponents of values composing the orientation matrix - to avoid calculation errors. The negative values can be specified to avoid Z-clipping if the reference system of camera goes inside of the model when decreasing camera distance. - -The auto z fit mode, since now, has a parameter defining Z-range margin (the one which is usually passed as argument to *ZFitAll()* method). The methods *SetAutoZFitMode(), AutoZFitScaleFactor()* and *ZFitAll()* from class *V3d_View* deal with the new parameter. - -The class *Select3D_Projector* now supports both orientation and projection transformation matrices, which can be naturally set for the projector. The definition of projector was revised in *StdSelect_ViewerSelector3d*: perspective and orthographic projection parameters are handled properly. Orthographic projector is based only on direction of projection - no more *Center* property. This makes it possible to avoid unnecessary re-projection of sensitive while panning, zooming or moving along the projection ray of the view. These operations do not affect the orthographic projection. - - -@section upgrade_690 Upgrade to OCCT 6.9.0 - -Porting of user applications from an earlier OCCT version to version 6.9.0 requires taking into account the following major changes. - -@subsection upgrade_690_shaders 3D Viewer initialization - -3D Viewer now uses GLSL programs for managing frame buffer and stereoscopic output. -For proper initialization, application should configure **CSF_ShadersDirectory** environment variable pointing to a folder with GLSL resources - files from folder **CASROOT**/src/Shaders. -*Note that **CSF_ShadersDirectory** become optional since OCCT 7.1.0 release*. - -@subsection upgrade_690_selection Changes in Selection - -Selection mechanism of 3D Viewer has been redesigned to use 3-level BVH tree traverse directly in 3D space instead of projection onto 2D screen space (updated on each rotation). This architectural redesign may require appropriate changes at application level in case if custom Interactive Objects are used. - -#### Standard selection -Usage of standard OCCT selection entities would require only minor updates. - -Custom Interactive Objects should implement new virtual method *SelectMgr_SelectableObject::BoundingBox().* - -Now the method *SelectMgr_Selection::Sensitive()* does not return *SelectBasics_SensitiveEntity*. It returns an instance of *SelectMgr_SensitiveEntity*, which belongs to a different class hierarchy (thus *DownCast()* will fail). To access base sensitive it is necessary to use method *SelectMgr_SensitiveEntity::BaseSensitive()*. For example: - -~~~~{.cpp} -occ::handle aSelection = anInteractiveObject->Selection (aMode); -for (aSelection->Init(); aSelection->More(); aSelection->Next()) -{ - occ::handle anEntity = aSelection->Sensitive()->BaseSensitive(); -} -~~~~ - -#### Custom sensitive entities - -Custom sensitive entities require more complex changes, since the selection algorithm has been redesigned and requires different output from the entities. - -The method *SelectBasics_SensitiveEntity::Matches()* of the base class should be overridden following the new signature: - -*Standard_Boolean Matches (SelectBasics_SelectingVolumeManager& theMgr, SelectBasics_PickResult& thePickResult)*, where *theMgr* contains information about the currently selected frustum or set of frustums (see *SelectMgr_RectangularFrustum, SelectMgr_TrangularFrustum, SelectMgr_TriangularFrustumSet)* and *SelectBasics_PickResult* is an output parameter, containing information about the depth of the detected entity and distance to its center of geometry. - -In the overridden method it is necessary to implement an algorithm of overlap and inclusion detection (the active mode is returned by *theMgr.IsOverlapAllowed()*) with triangular and rectangular frustums. - -The depth and distance to the center of geometry must be calculated for the 3D projection of user-picked screen point in the world space. You may use already implemented overlap and inclusion detection methods for different primitives from *SelectMgr_RectangularFrustum* and *SelectMgr_TriangularFrustum*, including triangle, point, axis-aligned box, line segment and planar polygon. - -Here is an example of overlap/inclusion test for a box: - -~~~~{.cpp} -if (!theMgr.IsOverlapAllowed()) // check for inclusion -{ - bool isInside = true; - return theMgr.Overlaps (myBox.CornerMin(), myBox.CornerMax(), &isInside) && isInside; -} - -double aDepth; -if (!theMgr.Overlaps (myBox, aDepth)) // check for overlap -{ - return false; -} - -thePickResult = -SelectBasics_PickResult (aDepth, theMgr.DistToGeometryCenter (myCenter3d)); -~~~~ - -The interface of *SelectBasics_SensitiveEntity* now contains four new pure virtual functions that should be implemented by each custom sensitive: -* BoundingBox() – returns a bounding box of the entity; -* Clear() – clears up all the resources and memory allocated for complex sensitive entities; -* BVH() – builds a BVH tree for complex sensitive entities, if it is needed; -* NbSubElements() – returns atomic sub-entities of a complex sensitive entity, which will be used as primitives for BVH building. If the entity is simple and no BVH is required, this method returns 1. - -Each sensitive entity now has its own tolerance, which can be overridden by method *SelectBasics_SensitiveEntity::SetSensitivityFactor()* called from constructor. - - -@subsection upgrade_690_adaptor3d-curve Changes in Adaptor3d_Curve class - -All classes inheriting *Adaptor3d_Curve* (directly or indirectly) must be updated in application code to use new signature of methods *Intervals()* and *NbIntervals()*. Note that no compiler warning will be generated if this is not done. - -@subsection upgrade_690_v3d_view Changes in V3d_View class - -The methods *V3d_View::Convert* and *V3d_View::ConvertWithProj()* have ceased to return point on the active grid. It might be necessary to revise the code of your application so that *V3d_View::ConvertToGrid()* was called explicitly for the values returned by *V3d_View::Convert* to get analogous coordinates on the grid. The methods *V3d_View::Convert* and *V3d_View::ConvertWithProj* convert point into reference plane of the view corresponding to the intersection with the projection plane of the eye/view point vector. - -@section upgrade_700 Upgrade to OCCT 7.0.0 - -Porting of user applications from an earlier OCCT version to version 7.0.0 requires taking into account the following major changes. - -Building OCCT now requires compiler supporting some C++11 features. -The supported compilers are: -- MSVC: version 10 (Visual Studio 2010) or later -- GCC: version 4.3 or later -- CLang: version 3.6 or later -- ICC: version XE 2013 SP 1 or later - -When compiling code that uses OCCT with GCC and CLang compilers, it is necessary to use compiler option -std=c++0x (or its siblings) to enable C++11 features. - -@subsection upgrade_700_persist Removal of legacy persistence - -Legacy persistence for shapes and OCAF data based on *Storage_Schema* (toolkits *TKPShape*, *TKPLCAF*, *TKPCAF*, *TKShapeShcema, TLStdLSchema, TKStdSchema*, and *TKXCAFSchema*) has been removed in OCCT 7.0.0. -The applications that used these data persistence tools need to be updated to use other persistence mechanisms. - -@note For compatibility with previous versions, the possibility to read standard OCAF data (*TKLCAF* and *TKCAF*) from files stored in the old format is preserved (toolkits *TKStdL* and *TKStd*). - -The existing data files in standard formats can be converted using OCCT 6.9.1 or a previous version, as follows. - -@note Reading / writing custom files capability from OCCT 6.9.1 is restored in OCCT 7.2.0. See details in @ref upgrade_720_persistence section. - -#### CSFDB files - -Files in *CSFDB* format (usually with extension .csfdb) contain OCCT shape data that can be converted to BRep format. -The easiest way to do that is to use ImportExport sample provided with OCCT 6.9.0 (or earlier): - -- Start ImportExport sample; -- Select File / New; -- Select File / Import / CSFDB... and specify the file to be converted; -- Drag the mouse with the right button pressed across the view to select all shapes by the rectangle; -- Select File / Export / BREP... and specify the location and name for the resulting file - -#### OCAF and XCAF documents - -Files containing OCAF data saved in the old format usually have extensions .std, .sgd or .dxc (XDE documents). -These files can be converted to XML or binary OCAF formats using DRAW Test Harness commands. -Note that if the file contains only attributes defined in *TKLCAF* and *TKCAF*, this action can be performed in OCCT 7.0; otherwise OCCT 6.9.1 or earlier should be used. - -For that, start *DRAWEXE* and perform the following commands: - - * To convert *.std and *.sgd file formats to binary format *.cbf (The created document should be in *BinOcaf* format instead of *MDTV-Standard*): - - @code - Draw[]> pload ALL - Draw[]> Open [path to *.std or *.sgd file] Doc - Draw[]> Format Doc BinOcaf - Draw[]> SaveAs Doc [path to the new file] - @endcode - - * To convert *.dxc file format to binary format *.xbf (The created document should be in *BinXCAF* format instead of *MDTV-XCAF*): - - @code - Draw[]> pload ALL - Draw[]> XOpen [path to *.dxc file] Doc - Draw[]> Format Doc BinXCAF - Draw[]> XSave Doc [path to the new file] - @endcode - -On Windows, it is necessary to replace back slashes in the file path by direct slashes or pairs of back slashes. - -Use *XmlOcaf* or *XmlXCAF* instead of *BinOcaf* and *BinXCAF*, respectively, to save in XML format instead of binary one. - -@subsection upgrade_occt700_cdl Removal of CDL and WOK - -OCCT code has been completely refactored in version 7.0 to get rid of obsolete technologies used since its inception: CDL (Cas.Cade Definition Language) and WOK (Workshop Organization Kit). - -C++ code previously generated by WOK from CDL declarations is now included directly in OCCT sources. - -This modification did not change names, API, and behavior of existing OCCT classes, thus in general the code based on OCCT 6.x should compile and work fine with OCCT 7.0. -However, due to redesign of basic mechanisms (CDL generic classes, Handles and RTTI) using C++ templates, some changes may be necessary in the code when porting to OCCT 7.0, as described below. - -WOK is not necessary anymore for building OCCT from sources, though it still can be used in a traditional way -- auxiliary files required for that are preserved. -The recommended method for building OCCT 7.x is CMake, see @ref build_occt_win_cmake. -The alternative solution is to use project files generated by OCCT legacy tool **genproj**, see @ref build_occt_genproj. - -@subsubsection upgrade_occt700_cdl_auto Automatic upgrade - -Most of typical changes required for upgrading code for OCCT 7.0 can be done automatically using the *upgrade* tool included in OCCT 7.0. -This tool is a Tcl script, thus Tcl should be available on your workstation to run it. - -Example: -~~~~{.php} - $ tclsh - % source /adm/upgrade.tcl - % upgrade -recurse -all -src= -~~~~ - -On Windows, the helper batch script *upgrade.bat* can be used, provided that Tcl is either available in *PATH*, or configured via *custom.bat* script (for instance, if you use OCCT installed from Windows installer package). Start it from the command prompt: - -~~~~ -cmd> \upgrade.bat -recurse -all -inc=\inc -src= [options] -~~~~ - -Run the upgrade tool without arguments to see the list of available options. - -The upgrade tool performs the following changes in the code. - -1. Replaces macro *DEFINE_STANDARD_RTTI* by *DEFINE_STANDARD_RTTIEXT*, with second argument indicating base class for the main argument class (if inheritance is recognized by the script): -~~~~{.cpp} -DEFINE_STANDARD_RTTI(Class) -> DEFINE_STANDARD_RTTIEXT(Class, Base) -~~~~ - - @note If macro *DEFINE_STANDARD_RTTI* with two arguments (used in intermediate development versions of OCCT 7.0) is found, the script will convert it to either *DEFINE_STANDARD_RTTIEXT* or *DEFINE_STANDARD_RTTI_INLINE*. - The former case is used if current file is header and source file with the same name is found in the same folder. - In this case, macro *IMPLEMENT_STANDARD_RTTI* is injected in the corresponding source file. - The latter variant defines all methods for RTTI as inline, and does not require *IMPLEMENT_STANDARD_RTTIEXT* macro. - -2. Replaces forward declarations of collection classes previously generated from CDL generics (defined in *TCollection* package) by inclusion of the corresponding header: -~~~~{.cpp} -class NCollection_Array1; -> #include .hxx> -~~~~ - -3. Replaces underscored names of *Handle* classes by usage of a macro: -~~~~{.cpp} -Handle_Class -> occ::handle -~~~~ - This change is not applied if the source or header file is recognized as containing the definition of Qt class with signals or slots, to avoid possible compilation errors of MOC files caused by inability of MOC to recognize macros (see https://doc.qt.io/qt-4.8/signalsandslots.html). - The file is considered as defining a Qt object if it contains strings *Q_OBJECT* and either *slots:* or *signals:*. - -4. Removes forward declarations of classes with names Handle(C) or *Handle_C*, replacing them either by forward declaration of its argument class, or (for files defining Qt objects) \#include statement for a header with the name of the argument class and extension .hxx: -~~~~{.cpp} -class occ::handle>; -> #include .hxx> -~~~~ - -5. Removes \#includes of files Handle_...hxx that have disappeared in OCCT 7.0: -~~~~{.cpp} -#include -> -~~~~ - -6. Removes *typedef* statements that use *Handle* macro to generate the name: -~~~~{.cpp} -typedef NCollection_Handle occ::handle; -> -~~~~ - -7. Converts C-style casts applied to Handles into calls to DownCast() method: -~~~~{.cpp} - ((occ::handle&)b) -> occ::down_cast(b) - (occ::handle&)b -> occ::down_cast(b) - (*((occ::handle*)&b)) -> occ::down_cast(b) - *((occ::handle*)&b) -> occ::down_cast(b) - (*(occ::handle*)&b) -> occ::down_cast(b) -~~~~ - -8. Moves Handle() macro out of namespace scope: -~~~~{.cpp} -Namespace::occ::handle -> Handle(Namespace::Class) -~~~~ - -9. Converts local variables of reference type, which are initialized by a temporary object returned by call to DownCast(), to the variables of non-reference type (to avoid using references to destroyed memory): -~~~~{.cpp} - const occ::handle& a = Handle(B)::DownCast (b); -> occ::handle a (Handle(B)::DownCast (b)); -~~~~ - -10. Adds \#include for all classes used as argument to macro STANDARD_TYPE(), except for already included ones; - -11. Removes uses of obsolete macros *IMPLEMENT_DOWNCAST* and *IMPLEMENT_STANDARD_*..., except *IMPLEMENT_STANDARD_RTTIEXT*. - - @note If you plan to keep compatibility of your code with older versions of OCCT, add option -compat to avoid this change. See also @ref upgrade_occt700_cdl_compat. - -. - -As long as the upgrade routine runs, some information messages are sent to the standard output. -In some cases the warnings or errors like the following may appear: - -~~~~ - Error in {HEADER_FILE}: Macro DEFINE_STANDARD_RTTI used for class {CLASS_NAME} whose declaration is not found in this file, cannot fix -~~~~ - -Be sure to check carefully all reported errors and warnings, as the corresponding code will likely require manual corrections. -In some cases these messages may help you to detect errors in your code, for instance, cases where *DEFINE_STANDARD_RTTI* macro is used with incorrect class name as an argument. - -@subsubsection upgrade_occt700_cdl_compiler Possible compiler errors - -Some situations requiring upgrade cannot be detected and / or handled by the automatic procedure. -If you get compiler errors or warnings when trying to build the upgraded code, you will need to fix them manually. -The following paragraphs list known situations of this kind. - -#### Missing header files - -The use of handle objects (construction, comparison using operators == or !=, use of function STANDRAD_TYPE() and method DownCast()) now requires the type of the object pointed by Handle to be completely known at compile time. Thus it may be necessary to include header of the corresponding class to make the code compilable. - -For example, the following lines will fail to compile if *Geom_Line.hxx* is not included: - -~~~~{.cpp} -occ::handle aLine = 0; -if (aLine != aCurve) {...} -if (aCurve->IsKind(STANDARD_TYPE(Geom_Line)) {...} -aLine = Handle(Geom_Line)::DownCast (aCurve); -~~~~ - -Note that it is not necessary to include header of the class to declare Handle to it. -However, if you define a class *B* that uses Handle(*A*) in its fields, or contains a method returning Handle(*A*), it is advisable to have header defining *A* included in the header of *B*. -This will eliminate the need to include the header *A* in each source file where class *B* is used. - -#### Ambiguity of calls to overloaded functions - -This issue appears in the compilers that do not support default arguments in template functions (known cases are Visual C++ 10 and 11): the compiler reports an ambiguity error if a handle is used in the argument of a call to the function that has two or more overloaded versions, receiving handles to different types. -The problem is that operator const handle& is defined for any type *T2*, thus the compiler cannot make the right choice. - -Example: -~~~~{.cpp} -void func (const occ::handle&); -void func (const occ::handle&); - -occ::handle aCurve = new Geom_TrimmedCurve (...); -func (aCurve); // ambiguity error in VC++ 10 -~~~~ - -Note that this problem can be avoided in many cases if macro *OCCT_HANDLE_NOCAST* is used, see @ref upgrade_occt700_cdl_nocast "below". - -To resolve this ambiguity, change your code so that argument type should correspond exactly to the function signature. -In some cases this can be done by using the relevant type for the corresponding variable, like in the example above: - -~~~~{.cpp} -occ::handle aCurve = new Geom_TrimmedCurve (...); -~~~~ - -Other variants consist in assigning the argument to a local variable of the correct type and using the direct cast or constructor: - -~~~~{.cpp} -const occ::handle& aGCurve (aTrimmedCurve); -func (aGCurve); // OK - argument has exact type -func (static_cast(aCurve)); // OK - direct cast -func (occ::handle(aCurve)); // OK - temporary handle is constructed -~~~~ - -Another possibility consists in defining additional template variant of the overloaded function causing ambiguity, and using *SFINAE* to resolve the ambiguity. -This technique can be illustrated by the definition of the template variant of method IGESData_IGESWriter::Send(). - -#### Lack of implicit cast to base type - -As the cast of a handle to the reference to another handle to the base type has become a user-defined operation, the conversions that require this cast together with another user-defined cast will not be resolved automatically by the compiler. - -For example: - -~~~~{.cpp} -occ::handle aC = GC_MakeLine (p, v); // compiler error -~~~~ - -The problem is that the class *GC_MakeLine* has a user-defined conversion to const Handle(Geom_TrimmedCurve)&, which is not the same as the type of the local variable *aC*. - -To resolve this, use method Value(): - -~~~~{.cpp} -occ::handle aC = GC_MakeLine (p, v).Value(); // ok -~~~~ - -or use variable of the appropriate type: - -~~~~{.cpp} -occ::handle aC = GC_MakeLine (p, v); // ok -~~~~ - -A similar problem appears with GCC compiler, when *const* handle to derived type is used to construct handle to base type via assignment (and in some cases in return statement), for instance: - -~~~~{.cpp} - const occ::handle aLine; - occ::handle c1 = aLine; // GCC error - occ::handle c2 (aLine); // ok -~~~~ - -This problem is specific to GCC and it does not appear if macro *OCCT_HANDLE_NOCAST* is used, see @ref upgrade_occt700_cdl_nocast "below". - -#### Incorrect use of STANDARD_TYPE and Handle macros - -You might need to clean your code from incorrect use of macros *STANDARD_TYPE*() and *Handle*(). - -1. Explicit definitions of static functions with names generated by macro *STANDARD_TYPE()*, which are artifacts of old implementation of RTTI, should be removed. - - Example: -~~~~{.cpp} -const occ::handle& STANDARD_TYPE(math_GlobOptMin) -{ - static occ::handle _atype = new Standard_Type ("math_GlobOptMin", sizeof (math_GlobOptMin)); - return _atype; -} -~~~~ - -2. Incorrect location of closing parenthesis of *Handle()* macro that was not detectable in OCCT 6.x will cause a compiler error and must be corrected. - - Example (note misplaced closing parenthesis): -~~~~{.cpp} -aBSpline = Handle( Geom2d_BSplineCurve::DownCast(BS->Copy()) ); -~~~~ - -#### Use of class Standard_AncestorIterator - -Class *Standard_AncestorIterator* has been removed; use method *Parent()* of *Standard_Type* class to parse the inheritance chain. - -#### Absence of cast to Standard_Transient* - -Handles in OCCT 7.0 do not have the operator of conversion to Standard_Transient*, which was present in earlier versions. -This is done to prevent possible unintended errors like this: - -~~~~{.cpp} -occ::handle aLine = ...; -occ::handle aSurf = ...; -... -if (aLine == aSurf) {...} // will cause a compiler error in OCCT 7.0, but not OCCT 6.x -~~~~ - -The places where this implicit cast has been used should be corrected manually. -The typical situation is when Handle is passed to stream: - -~~~~{.cpp} -occ::handle aLine = ...; -os << aLine; // in OCCT 6.9.0, resolves to operator << (void*) -~~~~ - -Call method get() explicitly to output the address of the Handle. - -#### Method DownCast for non-base types - -Method *DownCast()* in OCCT 7.0 is made templated; if its argument is not a base class, "deprecated" compiler warning is generated. -This is done to prevent possible unintended errors like this: - -~~~~{.cpp} -occ::handle aSurf = ; -occ::handle aLine = - Handle(Geom_Line)::DownCast (aSurf); // will cause a compiler warning in OCCT 7.0, but not OCCT 6.x -~~~~ - -The places where this cast has been used should be corrected manually. - -If down casting is used in a template context where the argument can have the same or unrelated type so that *DownCast()* may be not available in all cases, use C++ *dynamic_cast<>* instead, e.g.: - -~~~~{.cpp} -template -bool CheckLine (const occ::handle theArg) -{ - occ::handle aLine = dynamic_cast (theArg.get()); - ... -} -~~~~ - -@subsubsection upgrade_occt700_cdl_runtime Possible runtime problems - -Here is the list of known possible problems at run time after the upgrade to OCCT 7.0. - -#### References to temporary objects - -In previous versions, the compiler was able to detect the situation when a local variable of a "reference to a Handle" type is initialized by temporary object, and ensured that lifetime of that object is longer than that of the variable. -In OCCT 7.0 with default options, it will not work if types of the temporary object and variable are different (due to involvement of user-defined type cast), thus such temporary object will be destroyed immediately. - -This problem does not appear if macro *OCCT_HANDLE_NOCAST* is used during compilation, see below. - -Example: - -~~~~{.cpp} -// note that DownCast() returns new temporary object! -const occ::handle& aBC = -occ::down_cast(aCurve); -aBC->Transform (T); // access violation in OCCT 7.0 -~~~~ - -@subsubsection upgrade_occt700_cdl_nocast Option to avoid cast of handle to reference to base type - -In OCCT 6.x and earlier versions the handle classes formed a hierarchy echoing the hierarchy of the corresponding object classes . -This automatically enabled the possibility to use the handle to a derived class in all contexts where the handle to a base class was needed, e.g. to pass it in a function by reference without copying: - -~~~~{.cpp} -bool GetCurve (occ::handle& theCurve); -.... -occ::handle aLine; -if (GetCurve (aLine)) { - // use aLine, unsafe -} -~~~~ - -This feature was used in multiple places in OCCT and dependent projects. -However it is potentially unsafe: in the above example no checks are done at compile time or at run time to ensure that the type assigned to the argument handle is compatible with the type of the handle passed as argument. -If an object of incompatible type (e.g. Geom_Circle) is assigned to *theCurve*, the behavior will be unpredictable. - -For compatibility with the existing code, OCCT 7.0 keeps this possibility by default, providing operators of type cast to the handle to a base type. However, this feature is unsafe and in specific situations it may cause compile-time or run-time errors as described above. - -To provide a safer behavior, this feature can be disabled by a compile-time macro *OCCT_HANDLE_NOCAST*. -When it is used, constructors and assignment operators are defined (instead of type cast operators) to convert handles to a derived type into handles to a base type. -This implies creation of temporary objects and hence may be more expensive at run time in some circumstances, however this way is more standard, safer, and in general recommended. - -The code that relies on the possibility of casting to base should be amended to always use the handle of argument type in function call and to use *DownCast()* to safely convert the result to the desired type. -For instance, the code from the example below can be changed as follows: - -~~~~{.cpp} -occ::handle aLine; -occ::handle aCurve; -if (GetCurve (aCure) && !(aLine = Handle(Geom_Line)::DownCast (aCurve)).IsNull()) { - // use aLine safely -} -~~~~ - -@subsubsection upgrade_occt700_cdl_compat Preserving compatibility with OCCT 6.x - -If you like to preserve the compatibility of your application code with OCCT versions 6.x even after the upgrade to 7.0, consider the following suggestions: - -1. If your code used sequences of macros *IMPLEMENT_STANDARD_*... generated by WOK, replace them by single macro *IMPLEMENT_STANDARD_RTTIEXT* - -2. When running automatic upgrade tool, add option -compat. - -3. Define macros *DEFINE_STANDARD_RTTIEXT* and *DEFINE_STANDARD_RTTI_INLINE* when building with previous versions of OCCT, resolving to *DEFINE_STANDARD_RTTI* with single argument - - Example: -~~~~{.cpp} -#if OCC_VERSION_HEX < 0x070000 - #define DEFINE_STANDARD_RTTIEXT(C1,C2) DEFINE_STANDARD_RTTI(C1) - #define DEFINE_STANDARD_RTTI_INLINE(C1,C2) DEFINE_STANDARD_RTTI(C1) -#endif -~~~~ - -@subsubsection upgrade_occt700_cdl_wok Applications based on CDL and WOK - -If your application is essentially based on CDL, and you need to upgrade it to OCCT 7.0, you will very likely need to convert your application code to non-CDL form. -This is a non-trivial effort; the required actions would depend strongly on the structure of the code and used CDL features. - -The upgrade script and sources of a specialized WOK version used for OCCT code upgrade can be found in WOK Git repository in branch [CR0_700_2](https://git.dev.opencascade.org/gitweb/?p=occt-wok.git;a=log;h=refs/heads/CR0_700_2). - -[Contact us](https://www.opencascade.com/contact/) if you need more help. - -@subsection upgrade_occt700_bspline Separation of BSpline cache - -Implementation of NURBS curves and surfaces has been revised: the cache of polynomial coefficients, which is used to accelerate the calculation of values of a B-spline, has been separated from data objects *Geom2d_BSplineCurve, Geom_BSplineCurve* and *Geom_BSplineSurface* into the dedicated classes *BSplCLib_Cache* and *BSplSLib_Cache*. - -The benefits of this change are: -* Reduced memory footprint of OCCT shapes (up to 20% on some cases) -* Possibility to evaluate the same B-Spline concurrently in parallel threads without data races and mutex locks - -The drawback is that direct evaluation of B-Splines using methods of curves and surfaces becomes slower due to the absence of cache. The slow-down can be avoided by using adaptor classes *Geom2dAdaptor_Curve, GeomAdaptor_Curve* and *GeomAdaptor_Surface*, which now use cache when the curve or surface is a B-spline. - -OCCT algorithms have been changed to use adaptors for B-spline calculations instead of direct methods for curves and surfaces. -The same changes (use of adaptors instead of direct call to curve and surface methods) should be implemented in relevant places in the applications based on OCCT to get the maximum performance. - -@subsection upgrade_occt700_booleanresult Structural result of Boolean operations - -The result of Boolean operations became structured according to the structure of the input shapes. Therefore it may impact old applications that always iterate on direct children of the result compound assuming to obtain solids as iteration items, regardless of the structure of the input shapes. In order to get always solids as iteration items it is recommended to use TopExp_Explorer instead of TopoDS_Iterator. - -@subsection upgrade_occt700_brepextrema BRepExtrema_ExtCC finds one solution only - -Extrema computation between non-analytical curves in shape-shape distance calculation algorithm has been changed in order to return only one solution. So, if e.g. two edges are created on parallel b-spline curves the algorithm BRepExtrema_DistShapeShape will return only one solution instead of enormous number of solutions. There is no way to get algorithm working in old manner. - -@subsection upgrade_occt700_sorttools Removal of SortTools package - -Package *SortTools* has been removed. -The code that used the tools provided by that package should be corrected manually. -The recommended approach is to use sorting algorithms provided by STL. - -For instance: -~~~~{.cpp} -#include -#include -#include -... -TCollection_Array1OfReal aValues = ...; -... -TCollection_CompareOfReal aCompReal; -SortTools_StraightInsertionSortOfReal::Sort(aValues, aCompReal); -~~~~ -can be replaced by: -~~~~{.cpp} -#include -... -TCollection_Array1OfReal aValues = ...; -... -std::stable_sort (aValues.begin(), aValues.end()); -~~~~ - -@subsection upgrade_occt700_2dlayers On-screen objects and ColorScale - -The old mechanism for rendering Underlay and Overlay on-screen 2D objects based on *Visual3d_Layer* and immediate drawing model (uncached and thus slow) has been removed. -Classes *Aspect_Clayer2d, OpenGl_GraphicDriver_Layer, Visual3d_Layer, Visual3d_LayerItem, V3d_LayerMgr* and *V3d_LayerMgrPointer* have been deleted. -The following auxiliary definition have been removed as well: Aspect_TypeOfPrimitive, Aspect_TypeOfLayer, Aspect_TypeOfEdge, Aspect_TypeOfDrawMode, Aspect_TypeOfConstraint, Aspect_DriverDefinitionError, Aspect_BadAccess. - -General AIS interactive objects with transformation persistence flag *Graphic3d_TMF_2d* can be used as a replacement of *Visual3d_LayerItem*. -The anchor point specified for transformation persistence defines the window corner of (or center in case of (0, 0) point). -To keep on-screen 2D objects on top of the main screen, they can be assigned to the appropriate Z-layer. -Predefined Z-layers *Graphic3d_ZLayerId_TopOSD* and *Graphic3d_ZLayerId_BotOSD* are intended to replace Underlay and Overlay layers within the old API. - -*ColorScale* object previously implemented using *Visual3d_LayerItem* has been moved to a new class *AIS_ColorScale*, with width and height specified explicitly. -The property of *V3d_View* storing the global *ColorScale* object has been removed with associated methods *V3d_View::ColorScaleDisplay(), V3d_View::ColorScaleErase(), V3d_View::ColorScaleIsDisplayed()* and *V3d_View::ColorScale()* as well as the classes *V3d_ColorScale, V3d_ColorScaleLayerItem* and *Aspect_ColorScale*. -Here is an example of creating *ColorScale* using the updated API: - -~~~~{.cpp} -occ::handle aCS = new AIS_ColorScale(); -// configuring -int aWidth, aHeight; -aView->Window()->Size (aWidth, aHeight); -aCS->SetSize (aWidth, aHeight); -aCS->SetRange (0.0, 10.0); -aCS->SetNumberOfIntervals (10); -// displaying -aCS->SetZLayer (Graphic3d_ZLayerId_TopOSD); -aCS->SetTransformPersistence (Graphic3d_TMF_2d, gp_Pnt (-1,-1,0)); -aCS->SetToUpdate(); -theContextAIS->Display (aCS); -~~~~ - -To see how 2d objects are implemented in OCCT you can call Draw commands *vcolorscale, vlayerline* or *vdrawtext* (with -2d option). -Draw command *vcolorscale* now requires the name of *ColorScale* object as argument. -To display this object use command *vdisplay*. For example: - -~~~~{.php} -pload VISUALIZATION -vinit -vcolorscale cs -demo -pload MODELING -box b 100 100 100 -vdisplay b -vsetdispmode 1 -vfit -vlayerline 0 300 300 300 10 -vdrawtext t "2D-TEXT" -2d -pos 0 150 0 -color red -~~~~ - -Here is a small example in C++ illustrating how to display a custom AIS object in 2d: -~~~~{.cpp} -occ::handle aContext = ...; -occ::handle anObj =...; // create an AIS object -anObj->SetZLayer(Graphic3d_ZLayerId_TopOSD); // display object in overlay -anObj->SetTransformPersistence (Graphic3d_TMF_2d, gp_Pnt (-1,-1,0)); // set 2d flag, coordinate origin is set to down-left corner -aContext->Display (anObj); // display the object -~~~~ - -@subsection upgrade_occt700_userdraw UserDraw and Visual3d - -#### Visual3d package - -Package *Visual3d* implementing the intermediate layer between high-level *V3d* classes -and low-level OpenGl classes for views and graphic structures management has been dropped. - -The *OpenGl_View* inherits from the new class *Graphic3d_CView*. -*Graphic3d_CView* is an interface class that declares abstract methods for managing displayed structures, -display properties and a base layer code that implements computation -and management of HLR (or more broadly speaking view-depended) structures. - -In the new implementation it takes place of the eliminated *Visual3d_View*. -As before the instance of *Graphic3d_CView* is still completely managed by *V3d_View* classes. -It can be accessed through *V3d_View* interface but normally it should not be required as all its methods are completely wrapped. - -In more details, a concrete specialization of *Graphic3d_CView* is created and returned by the graphical driver on request. -Right after the creation the views are directly used for setting rendering properties and adding graphical structures to be displayed. - -The rendering of graphics is possible after mapping a window and activating the view. -The direct setting of properties obsoletes the use of intermediate structures with display parameter -like *Visual3d_ContextView*, etc. This means that the whole package *Visual3d* becomes redundant. - -The functionality previously provided by *Visual3d* package has been redesigned in the following way : -- The management of display of structures has been moved from *Visual3d_ViewManager* into *Graphic3d_StructureManager*. -- The class *Visual3d_View* has been removed. The management of computed structures has been moved into the base layer of *Graphi3d_CView*. -- All intermediate structures for storing view parameters, e.g. *Visual3d_ContextView*, have been removed. - The settings are now kept by instances of *Graphic3d_CView*. -- The intermediate class *Visual3d_Light* has been removed. All light properties are stored in *Graphic3d_CLight* structure, which is directly accessed by instances of *V3d_Light* classes. -- All necessary enumerations have been moved into *Graphic3d* package. - -#### Custom OpenGL rendering and UserDraw - -Old APIs based on global callback functions for creating *UserDraw* objects and for performing custom OpenGL rendering within the view have been dropped. -*UserDraw* callbacks are no more required since *OpenGl_Group* now inherits *Graphic3d_Group* and thus can be accessed directly from *AIS_InteractiveObject*: - -~~~~{.cpp} -//! Class implementing custom OpenGL element. -class UserDrawElement : public OpenGl_Element {}; - -//! Implementation of virtual method AIS_InteractiveObject::Compute(). -void UserDrawObject::Compute (const occ::handle& thePrsMgr, - const occ::handle& thePrs, - const int theMode) -{ - NCollection_Vec4 aBndMin (myCoords[0], myCoords[1], myCoords[2], 1.0f); - NCollection_Vec4 aBndMax (myCoords[3], myCoords[4], myCoords[5], 1.0f); - - // casting to OpenGl_Group should be always true as far as application uses OpenGl_GraphicDriver for rendering - occ::handle aGroup = Handle(OpenGl_Group)::DownCast (thePrs->NewGroup()); - aGroup->SetMinMaxValues (aBndMin.x(), aBndMin.y(), aBndMin.z(), - aBndMax.x(), aBndMax.y(), aBndMax.z()); - UserDrawElement* anElem = new UserDrawElement (this); - aGroup->AddElement(anElem); - - // invalidate bounding box of the scene - thePrsMgr->StructureManager()->Update(); -} -~~~~ - -To perform a custom OpenGL code within the view, it is necessary to inherit from class *OpenGl_View*. -See the following code sample: - -~~~~{.cpp} -//! Custom view. -class UserView : public OpenGl_View -{ -public: - //! Override rendering into the view. - virtual void render (Graphic3d_Camera::Projection theProjection, - OpenGl_FrameBuffer* theReadDrawFbo, - const bool theToDrawImmediate) - { - OpenGl_View::render (theProjection, theReadDrawFbo, theToDrawImmediate); - if (theToDrawImmediate) - { - return; - } - - // perform custom drawing - const occ::handle& aCtx = myWorkspace->GetGlContext(); - GLfloat aVerts[3] = { 0.0f, 0,0f, 0,0f }; - aCtx->core20->glEnableClientState(GL_VERTEX_ARRAY); - aCtx->core20->glVertexPointer(3, GL_FLOAT, 0, aVerts); - aCtx->core20->glDrawArrays(GL_POINTS, 0, 1); - aCtx->core20->glDisableClientState(GL_VERTEX_ARRAY); - } - -}; - -//! Custom driver for creating UserView. -class UserDriver : public OpenGl_GraphicDriver -{ -public: - //! Create instance of own view. - virtual occ::handle CreateView (const occ::handle& theMgr) override - { - occ::handle aView = new UserView (theMgr, this, myCaps, myDeviceLostFlag, &myStateCounter); - myMapOfView.Add (aView); - for (NCollection_Sequence::Iterator aLayerIt (myLayerSeq); aLayerIt.More(); aLayerIt.Next()) - { - const Graphic3d_ZLayerId aLayerID = aLayerIt.Value(); - const Graphic3d_ZLayerSettings& aSettings = myMapOfZLayerSettings.Find (aLayerID); - aView->AddZLayer (aLayerID); - aView->SetZLayerSettings (aLayerID, aSettings); - } - return aView; - } -}; - -~~~~ - -@subsection upgrade_occt700_localcontext Deprecation of Local Context - -The conception of Local Context has been deprecated. -The related classes, e.g. *AIS_LocalContext*, and methods ( AIS_InteractiveContext::OpenLocalContext() and others) will be removed in a future OCCT release. - -The main functionality provided by Local Context - selection of object subparts - can be now used within Neutral Point without opening any Local Context. - -The property *SelectionMode()* has been removed from the class *AIS_InteractiveObject*. -This property contradicts to selection logic, since it is allowed to activate several Selection modes at once. -Therefore keeping one selection mode as object field makes no sense. -Applications that used this method should implement selection mode caching at application level, if it is necessary for some reason. - -@subsection upgrade_occt700_separate_caf_visualisation Separation of visualization part from TKCAF - -Visualization CAF attributes have been moved into a new toolkit *TKVCAF*. -If your application uses the classes from *TPrsStd* package then add link to *TKVCAF* library. - -Version numbers of *BinOCAF* and *XmlOCAF* formats are incremented; new files cannot be read by earlier versions of OCCT. - -Before loading the OCAF files saved by previous versions and containing *TPrsStd_AISPresentation* attribute it is necessary to define the environment variable *CSF_MIGRATION_TYPES*, pointing to file *src/StdResources/MigrationSheet.txt*. -When using documents loaded from a file, make sure to call method *TPrsStd_AISViewer::New()* prior to accessing *TPrsStd_AISPresentation* attributes in this document as that method creates them. - -@subsection upgrade_euler_angles Correction of interpretation of Euler angles in gp_Quaternion - -Conversion of *gp_Quaternion* to and from intrinsic Tait-Bryan angles (including *gp_YawPitchRoll*) is fixed. - -Before that fix the sequence of rotation axes was opposite to the intended; e.g. *gp_YawPitchRoll* (equivalent to *gp_Intrinsic_ZYX*) actually defined intrinsic rotations around X, then Y, then Z. Now the rotations are made in the correct order. - -The applications that use *gp_Quaternion* to convert Yaw-Pitch-Roll angles (or other intrinsic Tait-Bryan sequences) may need to be updated to take this change into account. - -@subsection upgrade_zoom_persistent_selection Zoom Persistent Selection - -Zoom persistent selection introduces a new structure *Graphic3d_TransformPers* to transform persistence methods and parameters and a new class *Graphic3d_WorldViewProjState* to refer to the camera transformation state. You might need to update your code to deal with the new classes if you were using the related features. Keep in mind the following: -* *Graphic3d_Camera::ModelViewState* has been renamed to *Graphic3d_Camera::WorldViewState*. -* Transformation matrix utilities from *OpenGl_Utils* namespace have been moved to *Graphic3d_TransformUtils* and *Graphic3d_TransformUtils.hxx* header respectively. -* Matrix stack utilities from *OpenGl_Utils* namespace have been moved to *OpenGl_MatrixStack* class and *OpenGl_MatrixStack.hxx* header respectively. -* *OpenGl_View* methods *Begin/EndTransformPersistence* have been removed. Use *Graphic3d_TransformPers::Apply()* instead to apply persistence to perspective and world-view projection matrices. - -@subsection upgrade_occt700_correction_of_texture Texture mapping of objects - -Textured objects now have the priority over the environment mapping. - -Redundant enumerations *V3d_TypeOfSurface* and *Graphic3d_TypeOfSurface*, class *OpenGl_SurfaceDetailState*, the corresponding methods from *Graphic3d_CView, OpenGl_ShaderManager, OpenGl_View, V3d_View* and *V3d_Viewer* have been deleted. -Draw command *VSetTextureMode* has been deleted. - -@subsection upgrade_occt700_wfshape Shape presentation builders - -Presentation tools for building Wireframe presentation have been refactored to eliminate duplicated code and interfaces. -Therefore, the following classes have been modified: -* *StdPrs_WFDeflectionShape* and *Prs3d_WFShape* have been removed. *StdPrs_WFShape* should be used instead. -* *StdPrs_ToolShadedShape* has been renamed to *StdPrs_ToolTriangulatedShape*. @section upgrade_occt710 Upgrade to OCCT 7.1.0 @@ -1110,7 +133,7 @@ The following obsolete features have been removed: * The 3D viewer printing API *V3d_View::Print()* has been removed. This functionality was available on Windows platforms only. The applications should use the general image dump API *V3d_View::ToPixMap()* and manage printing using a platform-specific API at the application level. Text resolution can be managed by rendering parameter *Graphic3d_RenderingParams::Resolution*, returned by *V3d_View::ChangeRenderingParams()*. * Methods *PrsMgr_PresentationManager::BoundBox*, *PrsMgr_PresentationManager::Hilight* and *SelectMgr_EntityOwner::Hilight* have been removed as not used. The corresponding method in custom implementations of *SelectMgr_EntityOwner* can be removed safely. *PrsMgr_PresentationManager::Color* with the corresponding style must be used instead. -* Class *NCollection_QuickSort* has been removed. The code that used the tools provided by that class should be corrected manually. The recommended approach is to use sorting algorithms provided by STL (std::sort). See also @ref upgrade_occt700_sorttools above. +* Package *SortTools* has been removed. The code that used the tools provided by that package should be corrected manually. The recommended approach is to use sorting algorithms provided by STL (std::sort). * Package *Dico*. The code that used the tools provided by that package should be corrected manually. The recommended approach is to use *NCollection_DataMap* and *NCollection_IndexedDataMap* classes. @@ -2128,13 +1151,13 @@ Redundant class Prs3d_Root has been marked as deprecated - Prs3d_Presentation::N @subsection upgrade_750_cdf_session Support of multiple OCAF application instances Class *CDF_Session* has been removed. -That class was used to store global instance of OCAF application (object of class *CDM_Application* or descendant, typically *TDataStd_Application*). +That class was used to store global instance of OCAF application (object of class *CDM_Application* or descendant, typically *TDocStd_Application*). Global directory of all opened OCAF documents has been removed as well; such directory is maintained now by each instance of the *CDM_Application* class. This allows creating programs that work with different OCAF documents concurrently in parallel threads, -provided that each thread deals with its own instance of *TDataStd_Application* and documents managed by this instance. +provided that each thread deals with its own instance of *TDocStd_Application* and documents managed by this instance. -Note that neither *TDataStd_Application* nor *TDocStd_Document* is protected from concurrent access from several threads. +Note that neither *TDocStd_Application* nor *TDocStd_Document* is protected from concurrent access from several threads. Such protection, if necessary, shall be implemented on the application level. For an example, access to labels and attributes could be protected by mutex if there is a probability that different threads access the same labels / attributes: ~~~~{.cpp} @@ -2297,8 +1320,8 @@ void Perform(const occ::handle& theCurveOnSurface, @section upgrade_occt770 Upgrade to OCCT 7.7.0 -Building OCCT now requires C++11-compliant compiler, so that some legacy compilers (Visual Studio 2010 and 2012) are no more supported. -It is recommended using Visual Studio 2015 or newer for building OCCT on Windows platform. +Building OCCT now requires C++17-compliant compiler (see [Building OCCT](@ref build_upgrade__building_occt) for details). +It is recommended using Visual Studio 2019 or later (2022 preferred) for building OCCT on Windows platform. @subsection upgrade_770_removed_features Removed features @@ -2402,7 +1425,7 @@ New profiles to allocate memory (defined at configuration time): * `JeMalloc` - allocates with `jemalloc` functions. * `Flexible` - old-way allocation which defines allocation method in real-time by environment variables.
-The most recommended manager is `JeMalloc`. To use it with a plugin system, like `DRAW`, please ensure that JeMalloc was built with the `--disable-initial-exec-tls` flag. For more details, visit [JeMalloc](http://jemalloc.net/). +The most recommended manager is `JeMalloc`. To use it with a plugin system, like `DRAW`, please ensure that JeMalloc was built with the `--disable-initial-exec-tls` flag. For more details, visit [JeMalloc](https://jemalloc.net/). @subsection upgrade_780_optimization_profiles New CMake Variable for Optimization Profiles @@ -2475,11 +1498,445 @@ The `Handle_*` type names are still available, but it is recommended to use the Example: ~~~~{.cpp} - occ::handle anApp = new TDataStd_Application(); // recommended - Handle_TDataStd_Application anApp = new TDataStd_Application(); // deprecated + occ::handle anApp = new TDocStd_Application(); // recommended + Handle_TDocStd_Application anApp = new TDocStd_Application(); // deprecated ~~~~ @subsection upgrade_790_general_map NCollection_Map algorithm method migration The `NCollection_Map` class has been reorganized to migrate extra methods to the `NCollection_MapAlgo` class. Boolean operations on maps are now available in the `NCollection_MapAlgo` class. + +@section upgrade_occt800 Upgrade to OCCT 8.0.0 + +OCCT 8.0.0 is a major release with broad, source-incompatible changes across the foundation, modeling-data, and modeling-algorithm layers. The bulk of the per-line changes (handle macro, `Standard_*` typedefs, `Standard_OVERRIDE` etc., `TColStd_*`/`TopTools_*` typedefs, `DEFINE_HARRAY*`, `Standard_Failure::Raise`) can be migrated automatically. A smaller set of changes — exception handling, removed/renamed APIs, reworked evaluation hierarchies, and packages that have been removed outright — require manual review. + +@subsection upgrade_800_minimums Minimum requirements and project layout + +OCCT 8.0.0 raises the supported toolchain baseline and reorganizes the source tree. + +- **C++17 is now required**. Application code and CMake `CXX_STANDARD` must be raised to 17 or higher. Compiler minimums: VS 2019 (2022 preferred), GCC 8.0, Clang 7.0, Apple Clang 11.0, MinGW-w64 7.3. +- **CMake 3.10 or later** is enforced (3.16+ recommended; required when `BUILD_USE_PCH=ON` for precompiled headers). +- **Source-tree layout** has been reorganized from a flat `src//` layout to `src////`. Build scripts that hard-coded the old layout, copied OCCT into a vendored tree, or referenced specific source paths must be updated. +- **Resource files** are now installed under `share//resources/` (vcpkg-compliant layout). The CSF_* environment variables (`CSF_OCCTResourcePath`, `CSF_IGESDefaults`, `CSF_STEPDefaults`, `CSF_PluginDefaults`, `CSF_XCAFDefaults`, etc.) are the supported way to point OCCT at the resources at runtime; `CASROOT` remains supported for compatibility. +- **`BUILD_PATCH` CMake option is removed**. There is no replacement; apply patches at the source level or via your build system. +- **`OCCT_PROJECT_NAME`** is a new CMake cache variable that controls the install layout's project name (defaults to `opencascade`); it is the supported customization hook for vcpkg and embedded builds. +- **Inspector** and **ExpToCas** have been moved out of the main repository to their own GitHub repositories. If your build relied on them being shipped in-tree, switch to the upstream repositories. +- The `-symbolic` Unix linker flag is no longer applied. RTTI behavior with `dlopen`-style plugins should be re-validated. + +@subsection upgrade_800_migration_toolkit Automated migration toolkit + +A 12-phase Python migration suite is shipped with OCCT under `adm/scripts/migration_800/`. It requires Python 3.6+ with no external dependencies. Each phase supports `--dry-run` to preview changes. + +For external projects, the recommended entry point is the wrapper script: + +~~~~{.bash} +# Linux/macOS +./adm/scripts/migration_800/run_migration.sh /path/to/your/src --dry-run +./adm/scripts/migration_800/run_migration.sh /path/to/your/src + +# Windows +adm\scripts\migration_800\run_migration.bat /path/to/your/src --dry-run +~~~~ + +The phases run in order and cover, in summary: + +1. `migrate_handles.py`- `Handle(T)` to `occ::handle`, `Handle(T)::DownCast()` to `occ::down_cast()`. +2. `migrate_standard_types.py`- `Standard_Boolean/Integer/Real/...` to `bool/int/double/...`, `Standard_True/False` to `true/false`. +3. `migrate_macros.py`- `Standard_OVERRIDE` to `override`, `Standard_NODISCARD` to `[[nodiscard]]`, `Standard_FALLTHROUGH` to `[[fallthrough]];`, etc. +4. `cleanup_define_handle.py`- removes redundant `DEFINE_STANDARD_HANDLE` macros. +5. `cleanup_deprecated_typedefs.py`- removes deprecated typedef/using declarations and replaces usages. +6. `collect_typedefs.py`- collects `NCollection` typedef mappings (analysis phase). +7. `replace_typedefs.py`- replaces `TColStd_*`/`TopTools_*` etc. with `NCollection_*`. +8. `remove_typedef_headers.py`- removes typedef-only headers and updates `FILES.cmake`. +9. `cleanup_forwarding_headers.py`- cleans up forwarding/include-only headers. +10. `cleanup_unused_typedefs.py`- removes unused typedef declarations. +11. `cleanup_access_specifiers.py`- removes redundant access specifiers. +12. `migrate_raise_to_throw.py`- converts `Standard_Failure::Raise(...)` to `throw Standard_Failure(...)`. + +The accompanying `migrate_hcollections.py` script converts `DEFINE_HARRAY1`/`DEFINE_HARRAY2`/`DEFINE_HSEQUENCE` macros to the `NCollection_HArray1`/`HArray2`/`HSequence` template classes. + +After all phases, `verify_migration.py` reports any remaining legacy patterns: + +~~~~{.bash} +python3 adm/scripts/migration_800/verify_migration.py --verbose /path/to/your/src +~~~~ + +Pre-generated mapping files (`collected_typedefs.json`, `collected_deprecated_typedefs.json`) are bundled in `adm/scripts/migration_800/`; external projects do not need to re-scan the OCCT source. The migration scripts also support `.h`/`.c`/`.hpp`/`.cpp` files and can automatically add or replace `#include` directives when replacing typedefs. + +`Standard_UNUSED` is an exception and requires manual migration to `[[maybe_unused]]` due to stricter placement rules of the C++ attribute. + +@subsection upgrade_800_handle Handle macro and Standard_* primitive types + +The `Handle()` macro and `::DownCast` are replaced with explicit `occ::handle<>` / `occ::down_cast<>` templates: + +~~~~{.cpp} +// Before // After +Handle(Geom_Circle) aCircle; occ::handle aCircle; +Handle(Geom_Circle)::DownCast(aCurve); occ::down_cast(aCurve); +~~~~ + +OCCT's primitive typedefs are migrated to standard C++ types: + +| Deprecated typedef | Replacement | +| ------------------------ | ----------------- | +| `Standard_Boolean` | `bool` | +| `Standard_True/False` | `true/false` | +| `Standard_Integer` | `int` | +| `Standard_Real` | `double` | +| `Standard_ShortReal` | `float` | +| `Standard_Byte` | `uint8_t` | +| `Standard_Size` | `size_t` | +| `Standard_Address` | `void*` | +| `Standard_CString` | `const char*` | +| `Standard_Character` | `char` | +| `Standard_ExtCharacter` | `char16_t` | +| `Standard_Time` | `std::time_t` | + +The `Standard_*` typedefs are still defined for source-level compatibility, but their use is discouraged in new code and the migration scripts rewrite them to the native C++ types. + +@subsection upgrade_800_macros Standard_* macros + +Legacy attribute macros are replaced with the standard C++ attributes and keywords: + +| Deprecated macro | Replacement | +| ---------------------- | ------------------ | +| `Standard_OVERRIDE` | `override` | +| `Standard_NODISCARD` | `[[nodiscard]]` | +| `Standard_FALLTHROUGH` | `[[fallthrough]];` | +| `Standard_Noexcept` | `noexcept` | +| `Standard_DELETE` | `= delete` | +| `Standard_THREADLOCAL` | `thread_local` | +| `Standard_ATOMIC(T)` | `std::atomic` | + +@subsection upgrade_800_exceptions Exception handling + +`Standard_Failure` now inherits from `std::exception`. OCCT exceptions can be caught by standard `catch (const std::exception&)` blocks, the message is exposed through `what()`, and `ExceptionType()` returns the exception class name. + +Static `Raise()`, `Instance()`, and `Throw()` methods on `Standard_Failure` and its subclasses are removed. Use the C++ `throw` statement directly: + +~~~~{.cpp} +// Before (removed) // After +Standard_Failure::Raise("error"); throw Standard_Failure("error"); +Standard_OutOfRange::Raise("index"); throw Standard_OutOfRange("index"); +~~~~ + +`GetMessageString()` is deprecated- use `what()`. The error-handler stack used by `OCC_CATCH_SIGNALS` is now `thread_local` instead of being protected by a global mutex; threads no longer contend on error-handler state. `Catches()` and `LastCaughtError()` static methods on `Standard_ErrorHandler` have been removed; `OCC_CATCH_SIGNALS` exposes a new `Raise()` re-throw method. + +If you previously combined OCCT exceptions with custom catch logic that relied on `Catches()` / `LastCaughtError()`, restructure the handler around the standard `try`/`catch` flow. + +@subsection upgrade_800_ncollection NCollection API changes + +`Seek()` and `ChangeSeek()` are removed from `NCollection_Map`. Use the unified `Contained()` API, which returns `std::optional>`: + +~~~~{.cpp} +// Before (removed) +const KeyType* pKey = aMap.Seek(aKey); + +// After +auto anOpt = aMap.Contained(aKey); +if (anOpt.has_value()) { const KeyType& aFoundKey = anOpt->get(); } +~~~~ + +The non-throwing `TryEmplace`/`TryBind` methods are now available on all map types and avoid the throwing two-step "find then add" pattern: + +~~~~{.cpp} +if (auto* pValue = aMap.TryBind(key, defaultValue)) { /* use pValue */ } +aMap.Emplace(key, constructorArgs...); // in-place construction, no copy/move +~~~~ + +C++17 structured bindings are supported via `Items()` / `IndexedItems()` views: + +~~~~{.cpp} +for (auto [aKey, aValue] : aMap.Items()) { ... } +~~~~ + +New collection types are available in 8.0.0 and may be preferred over their predecessors in new code: + +- `NCollection_FlatMap` / `NCollection_FlatDataMap`- cache-friendly open-addressing hash containers with Robin Hood hashing. +- `NCollection_OrderedMap` / `NCollection_OrderedDataMap`- insertion-order-preserving maps with O(1) lookup, append, and removal. +- `NCollection_KDTree`- header-only static balanced KD-Tree for spatial queries (`gp_Pnt`, `gp_Pnt2d`, `gp_XYZ`, `gp_XY`). +- `NCollection_ForwardRange`- lightweight forward-range adapter for non-owning index spans. + +`Standard_Mutex` is deprecated in favor of `std::mutex`. + +@subsection upgrade_800_collections_typedefs Package collection typedefs + +The package-specific collection typedefs (`TColStd_*`, `TopTools_*`, `TColgp_*`, etc.) are kept as deprecated aliases of the underlying `NCollection_*` template instantiations and emit deprecation warnings on use. The migration scripts rewrite call sites to use the templates directly: + +~~~~{.cpp} +// Before // After +TColStd_ListOfInteger aList; NCollection_List aList; +TopTools_MapOfShape aMap; NCollection_Map aMap; +TColStd_Array1OfReal anArr; NCollection_Array1 anArr; +TColgp_SequenceOfPnt aSeq; NCollection_Sequence aSeq; +~~~~ + +Two package typedef wrappers have been removed entirely (no backward-compatible aliases): `TColGeom` and `TColGeom2d`. Replace with `NCollection_Array1>` and the equivalent `Geom2d_*` form: + +~~~~{.cpp} +// Before (removed) // After +#include #include +TColGeom_Array1OfCurve aCurves; #include + NCollection_Array1> aCurves; +~~~~ + +@subsection upgrade_800_bspline BSpline/Bezier weights and accessors + +BSpline and Bezier curves and surfaces store poles, weights, and knots as direct array value-members rather than `NCollection_HArray*` handles. The previously nullable `Weights()` accessor is replaced by `WeightsArray()`, which always returns a valid reference- non-rational geometry exposes a non-owning view over a static unit-weights buffer with zero allocation: + +~~~~{.cpp} +// Before (nullable) +const NCollection_Array1* pWeights = aCurve->Weights(); +if (pWeights != nullptr) { /* use weights */ } + +// After (always valid) +const NCollection_Array1& aWeights = aCurve->WeightsArray(); +~~~~ + +Copy-out accessor overloads (those taking an output `NCollection_Array1` to fill) are deprecated in favour of zero-copy const-reference returning versions: + +~~~~{.cpp} +// Before (deprecated, copies data) +NCollection_Array1 aPoles; +aCurve->Poles(aPoles); + +// After (zero-copy) +const NCollection_Array1& aPoles = aCurve->Poles(); +~~~~ + +The same deprecation applies to single-element accessors throughout the `Convert` package- prefer the batch const-reference accessors (`Poles()`, `Weights()`, `Knots()`, `Multiplicities()`). + +@subsection upgrade_800_eval Evaluation hierarchy: EvalD0/D1/D2/D3/DN + +The geometry evaluation dispatch hierarchy has been redesigned across all 32 `Geom`/`Geom2d` curve and surface classes and across `Adaptor3d_Curve`, `Adaptor3d_Surface`, and their subclasses. + +The new primary virtual dispatch points are `EvalD0`, `EvalD1`, `EvalD2`, `EvalD3`, and `EvalDN`. They return POD result structs (`Geom_CurveD1` / `D2` / `D3`, `Geom_SurfD1` / `D2` / `D3`, and the `Geom2d_*` equivalents) and use exception-based error handling on the hot path. + +The old `Value()` and `D0` / `D1` / `D2` / `D3` / `DN` methods are kept as non-virtual inline backward-compatible wrappers that delegate to `EvalD*`. **If your code overrides `D0`/`D1`/`D2`/`D3`/`DN` on a `Geom*` class or an `Adaptor3d_Curve`/`Adaptor3d_Surface` subclass, you must override `EvalD0`/`EvalD1`/`EvalD2`/`EvalD3`/`EvalDN` instead.** Existing call-site code that consumes `Value()` / `D0..DN` continues to work unchanged. + +The new `EvalRep` descriptor system additionally allows alternate evaluation paths to be attached per-object via the `Set`/`Get`/`Clear` EvalRep API (full, derivative-bounded, and parameter-mapped descriptors are supported). This is the mechanism behind, for example, the offset-surface fast path that bypasses the expensive offset evaluation when an equivalent non-offset surface is available. + +Adaptor classes for elementary geometry now store `gp_*` primitives directly in `std::variant` and dispatch via switch/enum to `ElCLib`/`ElSLib` static methods, eliminating virtual calls for elementary geometry on the evaluation hot path. + +@subsection upgrade_800_lprop_gprop LProp consolidation and GProp deprecations + +LProp packages are consolidated and several `GProp` classes are deprecated. + +- `Geom2dLProp` and `LProp3d` packages are removed and consolidated into the unified `GeomLProp` template classes (`GeomLProp_CLPropsBase`, `GeomLProp_SLProps`). Backward-compatible type aliases for the previous class names are preserved, so most call sites continue to compile unchanged. +- `LProp_AnalyticCurInf` is removed (dead code). +- The `GProp_EquaType` enum is removed (no consumers). Dimensionality analysis is now exposed via `PointSetLib_Equation`. + +The point-cloud property classes `GProp_PGProps`, `GProp_PEquation`, `GProp_CelGProps`, `GProp_SelGProps`, `GProp_VelGProps` are marked with `Standard_HEADER_DEPRECATED("Deprecated since OCCT 8.0.0. Use PointSetLib_Equation instead")` (and equivalent messages) in favour of the new `PointSetLib` package (`PointSetLib_Props`, `PointSetLib_Equation`), which is provided in `TKMath` without inheritance from `GProp_GProps`. + +@subsection upgrade_800_bndlib Bounding-box computation: GeomBndLib + +A new `GeomBndLib` package provides geometry-aware bounding boxes for all standard `Geom` curve and surface types via `std::variant`-based per-type dispatch, with analytical solutions for conics and quadrics and PSO+Powell-based tight `BoxOptimal` results. `BndLib_Add3dCurve`, `BndLib_AddSurface`, and `BndLib_Add2dCurve` now delegate to `GeomBndLib`. The public `BndLib` API is preserved unchanged. + +@subsection upgrade_800_extremapc Point-to-curve extrema: ExtremaPC + +The new `ExtremaPC` package provides point-to-curve extrema computation with per-geometry specialized evaluators (`ExtremaPC_Line`, `ExtremaPC_Circle`, `ExtremaPC_Ellipse`, `ExtremaPC_Hyperbola`, `ExtremaPC_BezierCurve`, `ExtremaPC_BSplineCurve`, `ExtremaPC_OffsetCurve`) and an `ExtremaPC_Curve` aggregator dispatcher. + +@subsection upgrade_800_brepgraph BRepGraph- graph-based BRep representation + +OCCT 8.0.0 introduces a new graph-based representation of topology and BRep geometry as an alternative to the linked `TopoDS_Shape` data structure. The foundation is split across two layers: + +- `BRepGraph` (public)- typed `BRepGraph_NodeId` identifiers, multiple Views (`TopoView`, `RefsView`, `CacheView`, `BuilderView`), bidirectional parent/child explorers (`BRepGraph_ChildExplorer`, `BRepGraph_ParentExplorer`, `BRepGraph_WireExplorer`), iterators (`BRepGraph_DefsIterator`, `BRepGraph_RefsIterator`, `BRepGraph_RelatedIterator`, `BRepGraph_CacheKindIterator`, `BRepGraph_LayerIterator`), extensible Layer/Cache system, mutation guards (`BRepGraph_MutGuard`), history tracking (`BRepGraph_History`), deduplication (`BRepGraph_Deduplicate`), compaction (`BRepGraph_Compact`), deep copy (`BRepGraph_Copy`), and validation (`BRepGraph_Validate`). +- `BRepGraphInc` (internal)- incidence-table storage with `BRepGraphInc_Populate` (`TopoDS_Shape` -> graph) and `BRepGraphInc_Reconstruct` (graph -> `TopoDS_Shape`) roundtrip conversion. + +`BRepGraph_Tool` is the centralized geometry-access API (analogue of `BRep_Tool`). `BRepGraph_Builder` allows programmatic graph construction without an input `TopoDS_Shape`. + +The graph representation is additive in 8.0.0- existing `TopoDS_Shape` code continues to work unchanged. Application code that wants to opt in can use `BRepGraphInc_Populate` and `BRepGraphInc_Reconstruct` to convert in either direction. + +@subsection upgrade_800_topods TopoDS_TShape redesign + +The `TopoDS_TShape` hierarchy has been reworked at the state and dispatch layer: + +- `ShapeType()` is non-virtual and embedded in a compact `uint16_t` bit-packed state field on `TopoDS_TShape`. Subclasses no longer override `ShapeType()`; the shape type is stored alongside the orientation/lock/checked/closed/infinite/convex/modified/free flags in the same field. +- `TopAbs::Compose()`, `Reverse()`, and `Complement()` are inlined `noexcept` static functions in the `TopAbs.hxx` header (constexpr lookup tables) rather than out-of-line functions in `TopAbs.cxx`. + +This is a binary-incompatible change. Source compatibility is preserved for code that uses the public `TopoDS_*` and `TopExp*` APIs. Custom `TShape`-derived classes that previously overrode `ShapeType()` must drop the override and rely on the base-class state field. + +Child storage on `TopoDS_TShape` remains `NCollection_List` and `TopoDS_Iterator` continues to iterate the list - callers that touch `myShapes` directly do not need to change. + +@subsection upgrade_800_handle_outparams Handle out-parameter overloads deprecated + +Methods that previously returned `occ::handle<>` values via output parameters are deprecated in favour of return-by-value overloads in `ApplicationFramework`, `DataExchange`, `ModelingAlgorithms`, `ModelingData`, and `Visualization`: + +~~~~{.cpp} +// Before (deprecated) +occ::handle aDoc; +anApp.GetDocument(aLabel, aDoc); + +// After +occ::handle aDoc = anApp.GetDocument(aLabel); +~~~~ + +Many handle-returning APIs are now `[[nodiscard]]`. + +@subsection upgrade_800_mesh_factory Mesh: registry-based discrete-algorithm factory + +The legacy `DISCRETPLUGIN` / `DISCRETALGO` symbol-based plugin system is replaced with a registry-based factory. The headers `BRepMesh_PluginMacro.hxx`, `BRepMesh_PluginEntryType.hxx`, and `BRepMesh_FactoryError.hxx` are removed, as are the Draw commands `mpsetfunctionname`, `mpgetfunctionname`, `mperror`. + +Migrate plugin discovery to the new factory: + +~~~~{.cpp} +// Before (removed) +BRepMesh_PluginEntryType aFunc = BRepMesh::PluginEntry("DISCRETPLUGIN"); + +// After +occ::handle aFactory = + BRepMesh_DiscretAlgoFactory::FindFactory("FastDiscret"); +if (!aFactory.IsNull()) +{ + occ::handle anAlgo = aFactory->Create(); +} +~~~~ + +`BRepMesh_IncrementalMeshFactory` is registered for the "FastDiscret" algorithm and `XBRepMesh_Factory` for the "XBRepMesh" extended meshing algorithm. Loading both `TKMesh` and `TKXMesh` no longer causes symbol collisions. + +@subsection upgrade_800_plib PLib refactoring- value types and removed classes + +The `PLib_Base` abstract handle class has been removed. `PLib_JacobiPolynomial` and `PLib_HermitJacobi` are now value types (no longer derived from `Standard_Transient`); their methods are non-virtual and `const`. Construct them on the stack or as direct members: + +~~~~{.cpp} +// Before +occ::handle aPoly = new PLib_JacobiPolynomial(theDegree, theNivConstr); +aPoly->Points(...); + +// After +PLib_JacobiPolynomial aPoly(theDegree, theNivConstr); +aPoly.Points(...); +~~~~ + +`PLib_DoubleJacobiPolynomial` is removed entirely. There is no direct in-tree replacement- application code that depended on it must be ported manually to a combination of `PLib_JacobiPolynomial` and `PLib_HermitJacobi`, or rewritten against the new `Geom2dProp` / `GeomProp` differential-property packages where applicable. + +@subsection upgrade_800_std_math Standard math wrappers deprecated + +The OCCT-specific math wrapper functions are deprecated in favour of the `` / `` standard library equivalents: + +| Deprecated | Replacement | +| ---------- | ----------- | +| `ACos`, `ASin`, `ATan`, `Cos`, `Sin`, `Tan`, `Cosh`, `Sinh`, `Tanh` | `std::acos`, `std::asin`, ... | +| `Exp`, `Log`, `Pow`, `Sqrt` | `std::exp`, `std::log`, `std::pow`, `std::sqrt` | +| `Abs`, `Sign` | `std::abs`, `std::copysign` (or `<` comparison) | +| `Floor`, `Ceiling`, `Round`, `IntegerPart` | `std::floor`, `std::ceil`, `std::round`, `std::trunc` | +| `Min`, `Max` | `std::min`, `std::max` | +| `NextAfter` | `std::nextafter` | + +@subsection upgrade_800_step_signature StepData_ReadWriteModule::StepType signature + +The pure virtual `StepType()` method on `StepData_ReadWriteModule` now returns `const std::string_view&` instead of `const TCollection_AsciiString&`. All subclasses must update their override to match. If your code stored or compared the result against `TCollection_AsciiString` instances, convert through `TCollection_AsciiString(theType.data(), int(theType.size()))` or compare against string literals directly. + +@subsection upgrade_800_ais_immediate AIS_InteractiveContext immediate-mode rendering deprecated + +The legacy immediate-mode rendering methods on `AIS_InteractiveContext` are deprecated. New code should use the retained-mode pipeline through `Display()` / `Redisplay()` and presentation updates. Specific deprecated entry points emit compiler warnings on use. + +@subsection upgrade_800_mutex Standard_Mutex superseded by std::mutex + +`Standard_Mutex` and its `Standard_Mutex::Sentry` RAII helper are deprecated. Use the standard library: + +~~~~{.cpp} +// Before +static Standard_Mutex theMutex; +{ + Standard_Mutex::Sentry aLock(theMutex); + ... +} + +// After +static std::mutex theMutex; +{ + std::lock_guard aLock(theMutex); + ... +} +~~~~ + +`TopTools_MutexForShapeProvider` is removed. Where shape-level locking is needed, allocate a `std::mutex` directly. Several previously mutex-guarded internals in `BRepCheck_*` and Foundation globals have been converted to `thread_local` storage in 8.0.0, which may obviate the lock entirely. + +@subsection upgrade_800_visualization_unlit Visualization: implicit UNLIT shading removed + +The implicit optimization in `OpenGl_Aspects` that forced UNLIT shading when a material had no reflection properties has been removed. This was breaking PBR materials, interior color handling, and texture modulation. If your application relied on zero-material properties to obtain UNLIT shading, set the shading model explicitly: + +~~~~{.cpp} +// After +anAspect->SetShadingModel(Graphic3d_TypeOfShadingModel_Unlit); +~~~~ + +@subsection upgrade_800_bnd_intersected Bnd: IntersectStatus enum + +`Bnd_Range::IsIntersected()` previously returned a magic integer; it now returns the strongly-typed `Bnd_Range::IntersectStatus` enum: + +~~~~{.cpp} +// Before +int aResult = aRange.IsIntersected(...); + +// After +Bnd_Range::IntersectStatus aResult = aRange.IsIntersected(...); +~~~~ + +Several `Bnd_*` accessors (`Center()`, `Min()`, `Max()`, `Get()`) now return `std::optional`. `Bnd_*` classes have been annotated with `[[nodiscard]]` and `noexcept` where appropriate; `Contains()` and `Intersects()` wrappers have been added. + +@subsection upgrade_800_geomadaptor_transformed Transformed adaptor changes + +`GeomAdaptor_TransformedSurface::GeomSurface()` is deprecated. Use the new original/transformed surface accessors instead. `GeomAdaptor_TransformedCurve` has been introduced as a new base class for `BRepAdaptor_Curve` that wraps a `GeomAdaptor_Curve` (or `Adaptor3d_CurveOnSurface`) with an applied `gp_Trsf`. `GeomAdaptor_Surface` exposes new `ToleranceU()` / `ToleranceV()` accessors. + +@subsection upgrade_800_geomhash GeomHash configurable tolerances + +Geometry hash classes now expose `CompTolerance` and `HashTolerance` fields and constructors instead of the previously hard-coded `1e-12` constant. Code that depended on the old constant should explicitly request the previous values via the constructors. + +@subsection upgrade_800_isclosed IsClosed/IsPeriodic tolerance change + +`IsClosed()` on curves and surfaces previously used `gp::Resolution()` (~1e-290), making the check practically unusable. It now uses `Precision::Computational()` (~`DBL_EPSILON`). Trimmed curves and surfaces now also detect integer-period spans when reporting `IsClosed()` / `IsPeriodic()`. Application code that relied on the previous near-zero tolerance must adjust its inputs or its expectations accordingly. + +@subsection upgrade_800_build Build and configuration + +- `USE_VTK` is now `OFF` by default. Builds that need VIS must opt in explicitly (`-DUSE_VTK=ON`). +- ARM64 architecture is supported; CMake auto-detection and Windows ARM64 CI are added. +- **glTF read/write (`USE_RAPIDJSON`)** is now an explicit dependency: glTF support is disabled when RapidJSON is not available. Set `-DUSE_RAPIDJSON=ON` (and ensure RapidJSON is discoverable, or use `BUILD_USE_VCPKG=ON`) to keep glTF. +- **Documentation build is CMake-driven**. The legacy Tcl-based documentation entrypoints have been removed; use the `Overview`, `RefMan`, and `doc` CMake targets. +- **`vcpkg` integration**- OCCT ships a vcpkg manifest at `adm/vcpkg/ports/opencascade/vcpkg.json` (referenced via `VCPKG_MANIFEST_DIR`). Configure with `-DBUILD_USE_VCPKG=ON` and the desired `USE_*` flags; the toolchain file is detected automatically from `VCPKG_ROOT`. CMake config files are now installed under `share//` for vcpkg compliance. +- **Plugin discovery**- Data Exchange plugin registration is centralized through new `Register` / `UnRegister` static methods on configuration nodes, with `DE_MultiPluginHolder` for projects that load multiple providers. +- Standard exception throw replaces legacy `Standard_Failure::Raise` throughout the OCCT source tree- any custom build system that grepped for `Raise(` should be updated. + +@subsection upgrade_800_removed Removed and deprecated- summary + +Removed (no backward-compatible alias): + +| Item | Replacement | +| ---- | ----------- | +| `Standard_Failure::Raise()`, `Instance()`, `Throw()` static methods | `throw Standard_Failure(...)` | +| `Standard_ErrorHandler::Catches()` / `LastCaughtError()` | Implicit via execution flow / variant in handler | +| `NCollection_Map::Seek()` / `ChangeSeek()` | `Contained()` returning `std::optional` | +| `BRepMesh_PluginMacro.hxx`, `BRepMesh_PluginEntryType.hxx`, `BRepMesh_FactoryError.hxx` | `BRepMesh_DiscretAlgoFactory` | +| Draw commands `mpsetfunctionname`, `mpgetfunctionname`, `mperror` | Not needed with factory pattern | +| `TColGeom`, `TColGeom2d` packages | `NCollection_Array1>` | +| `Geom2dLProp`, `LProp3d` packages | `GeomLProp` template classes (aliases preserved) | +| `LProp_AnalyticCurInf` |- | +| `GProp_EquaType` enum | `PointSetLib_Equation` | +| `BUC60720` Draw command, `QABugs_PresentableObject` |- | +| `PLib_Base` abstract class | `PLib_JacobiPolynomial` / `PLib_HermitJacobi` as value types | +| `PLib_DoubleJacobiPolynomial` |- (port manually) | +| `TopTools_MutexForShapeProvider` | `std::mutex` | +| `OSD_MAllocHook` class, `mallochook` Draw command | Platform tools (Valgrind, AddressSanitizer) | +| `QANCollection` test package | GTest-based tests under `src/.../GTests/` | +| `BUILD_PATCH` CMake option |- (apply patches at source level) | +| Legacy Tcl documentation entrypoints | `Overview`, `RefMan`, `doc` CMake targets | +| Inspector, ExpToCas (in-tree) | Separate GitHub repositories | + +Deprecated (still compiles with warnings): + +| Item | Replacement | +| ---- | ----------- | +| `Standard_Failure::GetMessageString()` | `what()` | +| Package collection typedefs (`TColStd_*`, `TopTools_*`, ...) | `NCollection_*` | +| BSpline / Bezier copy-out accessor overloads | Const-reference returning versions | +| Convert package single-element accessors | Batch const-reference accessors | +| Nullable `Weights()` | `WeightsArray()` | +| `GProp_PGProps`, `GProp_PEquation`, `GProp_CelGProps`, `GProp_SelGProps`, `GProp_VelGProps` | `PointSetLib_Props`, `PointSetLib_Equation` | +| `GeomAdaptor_TransformedSurface::GeomSurface()` | Original/transformed surface accessors | +| Handle out-parameter overloads | Return-by-value overloads | +| `Standard_Mutex` (and `Standard_Mutex::Sentry`) | `std::mutex` (with `std::lock_guard`) | +| OCCT math wrappers (`ACos`, `Sin`, `Sqrt`, `Min`, `Max`, ...) | `std::` equivalents in `` / `` | +| `Transfer_TransferDeadLoop` exception | Status-flag-based dead-loop detection | +| `AIS_InteractiveContext` immediate-mode rendering methods | Retained-mode pipeline | diff --git a/dox/user_guides/de_wrapper/de_wrapper.md b/dox/user_guides/de_wrapper/de_wrapper.md index 336d7e1de9..fe9367a54b 100644 --- a/dox/user_guides/de_wrapper/de_wrapper.md +++ b/dox/user_guides/de_wrapper/de_wrapper.md @@ -24,7 +24,7 @@ This guide principally deals with the following OCCT classes: | CAD format | Extensions | RW support | Thread Safety | Presentation | Package | | :--------- | :--------- | :--------- | :----------- | :----------- | :------ | -| STEP | .stp, .step .stepz | RW | No | BRep, Mesh | DESTEP | +| STEP | .step, .stp, .stepz | RW | Yes (per-reader) | BRep, Mesh | DESTEP | | XCAF | .xbf | RW | Yes | BRep, Mesh | DEXCAF | | BREP | .brep | RW | Yes | BRep, Mesh | DEBREP | | IGES | .igs, .iges | RW | No | BRep | DEIGES | @@ -37,6 +37,7 @@ This guide principally deals with the following OCCT classes: **Note** : * The format names in the first column match the FormatName values used for configuration nodes. * The VendorName for all listed CAD formats is "OCC". + * For STEP, thread safety requires that each concurrent call uses its own *DESTEP_Parameters* instance rather than relying on the process-wide *Interface_Static* settings. See the @ref occt_user_guides__step "STEP user guide" for details. @section occt_de_wrapper_3 DE Session Configuration @@ -153,10 +154,11 @@ Dump to resource string. If the vendors list is empty, saves all vendors. If the occ::handle aSession = DE_Wrapper::GlobalWrapper(); NCollection_List aFormats; NCollection_List aVendors; - aFormats.Appends("STEP"); - aVendors.Appends("OCC"); + aFormats.Append("STEP"); + aVendors.Append("OCC"); bool aIsRecursive = true; - TCollection_AsciiString aConf = aSession->aConf->Save(aIsRecursive, aFormats, aVendors); + TCollection_AsciiString aConfDump = + aSession->Save(aIsRecursive, aFormats, aVendors); ~~~~ Configure using a resource file. If the vendors list is empty, saves all vendors. If the providers list is empty, saves all providers of valid vendors. ~~~~{.cpp} @@ -164,8 +166,8 @@ Configure using a resource file. If the vendors list is empty, saves all vendors TCollection_AsciiString aPathToFile = ""; NCollection_List aFormats; NCollection_List aVendors; - aFormats.Appends("STEP"); - aVendors.Appends("OCC"); + aFormats.Append("STEP"); + aVendors.Append("OCC"); bool aIsRecursive = true; if (!aSession->Save(aPathToFile, aIsRecursive, aFormats,aVendors)) { @@ -249,8 +251,8 @@ If the high priority vendor's provider is not supported, a transfer operation is occ::handle aSession = DE_Wrapper::GlobalWrapper(); TCollection_AsciiString aFormat = "STEP"; NCollection_List aVendors; - aVendors.Appends("OCC"); // high priority - aVendors.Appends("DTK"); + aVendors.Append("OCC"); // high priority + aVendors.Append("DTK"); // Flag to disable not chosen vendors, in this case configuration is possible // otherwise, lower their priority and continue to check ability to transfer bool aToDisable = true; @@ -291,7 +293,7 @@ Writing Shape to STEP file. occ::handle aSession = DE_Wrapper::GlobalWrapper(); TCollection_AsciiString aPathToFile = "example.stp"; TopoDS_Shape aShFrom = ...; - if (!aSession->Write(aPathToFile, aShRes)) + if (!aSession->Write(aPathToFile, aShFrom)) { Message::SendFail() << "Error: Can't write 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 index b2d2ba726a..cdb93216d1 100644 --- a/dox/user_guides/draw_test_harness/draw_test_harness.md +++ b/dox/user_guides/draw_test_harness/draw_test_harness.md @@ -50,7 +50,7 @@ This documentation describes: 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. -~~~~{.php} +~~~~{.tcl} exit ~~~~ @@ -58,7 +58,7 @@ Terminates the Draw, TCL session. If the commands are read from a file using the **Example:** -~~~~{.php} +~~~~{.tcl} # this is a very short example exit ~~~~ @@ -66,7 +66,7 @@ exit @subsection occt_draw_1_3 Getting started -Install Draw and launch Emacs. Get a command line in Emacs using *Esc x* and key in *woksh*. +Launch `DRAWEXE` from the CMake build directory after sourcing `env.sh`. All DRAW Test Harness can be activated in the common executable called **DRAWEXE**. They are grouped in toolkits and can be loaded at run-time thereby implementing dynamically loaded plug-ins. Thus, it is possible to work only with the required commands adding them dynamically without leaving the Test Harness session. @@ -74,12 +74,12 @@ Declaration of available plug-ins is done through the special resource file(s). @subsubsection occt_draw_1_3_1 Launching DRAW Test Harness -Test Harness executable *DRAWEXE* is located in the $CASROOT/\/bin directory (where \ is Win for Windows and Linux for Linux operating systems). Prior to launching it is important to make sure that the environment is correctly setup (usually this is done automatically after the installation process on Windows or after launching specific scripts on Linux). +The Test Harness executable *DRAWEXE* is produced by the OCCT build and installed under the build / install `bin/` directory (per platform: e.g. `/win64/vc143/bin/`, `/lin64/gcc/bin/`, `/mac64/clang/bin/`). Prior to launching it, source the environment script generated next to it -- `env.sh` on Linux/macOS or `env.bat` on Windows -- so that `PATH`, `LD_LIBRARY_PATH` / `DYLD_LIBRARY_PATH` and the `CSF_*` resource variables are set correctly. @subsubsection occt_draw_1_3_2 Plug-in resource file -Open CASCADE Technology is shipped with the DrawPlugin resource file located in the $CASROOT/src/DrawResources directory. +Open CASCADE Technology is shipped with the DrawPlugin resource file located in the $CSF_OCCTResourcePath/DrawResources directory. The format of the file is compliant with standard Open CASCADE Technology resource files (see the *Resource_Manager.hxx* file for details). @@ -99,7 +99,7 @@ AISV : TKViewerTest To load a plug-in declared in the resource file and to activate the commands the following command must be used in Test Harness: -~~~~{.php} +~~~~{.tcl} pload [-PluginFileName] [[Key1] [Key2]...] ~~~~ @@ -108,14 +108,14 @@ 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. +According to the OCCT resource file management rules, to access the resource file the environment variable *CSF_DrawPluginDefaults* (and optionally *CSF_DrawPluginUserDefaults*) 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 $CSF_OCCTResourcePath/DrawResources directory. -~~~~{.php} +~~~~{.tcl} Draw[] pload -DrawPlugin OCAF ~~~~ -This command 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. +This command 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 $CSF_OCCTResourcePath/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. -~~~~{.php} +~~~~{.tcl} Draw[] pload (equivalent to pload -DrawPlugin DEFAULT). ~~~~ This command will find the default DrawPlugin file and the DEFAULT key. The latter finally maps to the TKTopTest toolkit which implements basic modeling commands. @@ -140,7 +140,7 @@ TCL is an interpreted command language, not a structured language like C, Pascal The basic program for TCL is a script. A script consists of one or more commands. Commands are separated by new lines or semicolons. -~~~~{.php} +~~~~{.tcl} set a 24 set b 15 set a 25; set b 15 @@ -157,7 +157,7 @@ The following substitutions are performed by TCL: Variable substitution is triggered by the $ character (as with csh), the content of the variable is substituted; { } may be used as in csh to enclose the name of the variable. **Example:** -~~~~{.php} +~~~~{.tcl} # set a variable value set file documentation puts $file #to display file contents on the screen @@ -179,7 +179,7 @@ Command substitution is triggered by the [ ] characters. The brackets must enclo Compare command construction in csh. **Example:** -~~~~{.php} +~~~~{.tcl} set degree 30 set pi 3.14159265 # expr is a command evaluating a numeric expression @@ -193,7 +193,7 @@ TCL uses two forms of *quoting* to prevent substitution and word breaking. 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:** -~~~~{.php} +~~~~{.tcl} # set msg to ;the price is 12.00; set price 12.00 set msg ;the price is $price; @@ -202,7 +202,7 @@ set msg ;the price is $price; 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:** -~~~~{.php} +~~~~{.tcl} set x 0 # this will loop for ever # because while argument is ;0 < 3; @@ -225,7 +225,7 @@ 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:** -~~~~{.php} +~~~~{.tcl} # This is a comment set a 1 # this is not a comment set b 1; # this is a comment @@ -235,7 +235,7 @@ The number of words is never changed by substitution when parsing in TCL. For ex **Example:** -~~~~{.php} +~~~~{.tcl} # I want to delete two files set files ;foo bar; @@ -261,7 +261,7 @@ There are many kinds of Draw variables, and new ones may be added with C++. Geom 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:** -~~~~{.php} +~~~~{.tcl} # dset is used for numeric variables # pi is a predefined Draw variable dset angle pi/3 radius 10 @@ -273,7 +273,7 @@ It is recommended that you use TCL variables only for strings and Draw for numer Syntax: -~~~~{.php} +~~~~{.tcl} set varname [value] unset varname [varname varname ...] ~~~~ @@ -285,7 +285,7 @@ Without a value, *set* returns the content of the variable. *unset* deletes variables. It is also used to delete Draw variables. **Example:** -~~~~{.php} +~~~~{.tcl} set a "Hello world" set b "Goodbye" set a @@ -301,7 +301,7 @@ set a Syntax -~~~~{.php} +~~~~{.tcl} dset var1 value1 vr2 value2 ... dval name ~~~~ @@ -312,7 +312,7 @@ dval name **Example:** -~~~~{.php} +~~~~{.tcl} # z is set to 0 dset x 10 y 15 z == 0 @@ -330,7 +330,7 @@ puts ;x = [dval x], cos(x/pi) = [dval cos(x/pi)]; @subsubsection occt_draw_2_3_3 del, dall Syntax: -~~~~{.php} +~~~~{.tcl} del varname_pattern [varname_pattern ...] dall ~~~~ @@ -346,7 +346,7 @@ TCL uses lists. A list is a string containing elements separated by spaces or ta This allows you to insert lists within lists. **Example:** -~~~~{.php} +~~~~{.tcl} # a list of 3 strings ;a b c; @@ -368,7 +368,7 @@ TCL allows looping using control structures. The control structures are implemen Syntax -~~~~{.php} +~~~~{.tcl} if condition script [elseif script .... else script] ~~~~ @@ -377,7 +377,7 @@ if condition script [elseif script .... else script] **Example:** -~~~~{.php} +~~~~{.tcl} if {$x > 0} { puts ;positive; } elseif {$x == 0} { @@ -392,7 +392,7 @@ puts ;negative; Syntax: -~~~~{.php} +~~~~{.tcl} while condition script for init condition reinit script foreach varname list script @@ -401,7 +401,7 @@ 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:** -~~~~{.php} +~~~~{.tcl} # while example dset x 1.1 while {[dval x] < 100} { @@ -422,7 +422,7 @@ foreach object {crapo tomson lucas} {display $object} Syntax: -~~~~{.php} +~~~~{.tcl} break continue ~~~~ @@ -432,7 +432,7 @@ Within loops, the **break** and **continue** commands have the same effect as in **break** interrupts the innermost loop and **continue** jumps to the next iteration. **Example:** -~~~~{.php} +~~~~{.tcl} # search the index for which t$i has value ;secret; for {set i 1} {$i <= 100} {incr i} { if {[set t$i] == ;secret;} break; @@ -454,7 +454,7 @@ As TCL is not a strongly typed language it is very difficult to detect programmi Syntax: -~~~~{.php} +~~~~{.tcl} proc argumentlist script ~~~~ @@ -463,7 +463,7 @@ proc argumentlist script **return** gives a return value to the procedure. **Example:** -~~~~{.php} +~~~~{.tcl} # simple procedure proc hello {} { puts ;hello world; @@ -485,7 +485,7 @@ proc fact n { Syntax: -~~~~{.php} +~~~~{.tcl} global varname [varname ...] upvar varname localname [varname localname ...] ~~~~ @@ -498,7 +498,7 @@ upvar varname localname [varname localname ...] **Note** that in the following examples the \$ character is always necessarily used to access the arguments. **Example:** -~~~~{.php} +~~~~{.tcl} # convert degree to radian # pi is a global variable proc deg2rad (degree} { @@ -538,7 +538,7 @@ This section describes several useful commands: Syntax: -~~~~{.php} +~~~~{.tcl} help [command [helpstring group]] ~~~~ @@ -549,7 +549,7 @@ Provides help or modifies the help information. 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:** -~~~~{.php} +~~~~{.tcl} # Gives help on all commands starting with *a* ~~~~ @@ -558,7 +558,7 @@ Specifying the command returns its syntax and in some cases, information on the Syntax: -~~~~{.php} +~~~~{.tcl} source filename ~~~~ Executes a file. @@ -569,7 +569,7 @@ The **exit** command will terminate the file. Syntax: -~~~~{.php} +~~~~{.tcl} spy [filename] ~~~~ @@ -580,7 +580,7 @@ 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:** -~~~~{.php} +~~~~{.tcl} # all commands will be saved in the file ;session; spy session # the file ;session; is closed and commands are not saved @@ -593,14 +593,14 @@ spy Syntax: -~~~~{.php} +~~~~{.tcl} 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:** -~~~~{.php} +~~~~{.tcl} #limit cpu to one hour cpulimit 3600 ~~~~ @@ -608,12 +608,12 @@ cpulimit 3600 @subsubsection occt_draw_3_1_5 wait Syntax: -~~~~{.php} +~~~~{.tcl} 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. -~~~~{.php} +~~~~{.tcl} # You have ten seconds ... wait ~~~~ @@ -622,7 +622,7 @@ wait Syntax: -~~~~{.php} +~~~~{.tcl} chrono [ name start/stop/reset/show/restart/[counter text]] ~~~~ @@ -637,7 +637,7 @@ With arguments, **chrono** is used to manage activated chronometers. You can per * display the current time with specified text (output example - *COUNTER text: N*), command testdiff will compare such outputs between two test runs (counter). **Example:** -~~~~{.php} +~~~~{.tcl} chrono ==Chronometers activated. ptorus t 20 5 @@ -651,7 +651,7 @@ ptorus t 20 5 @subsubsection occt_draw_3_2_1 isdraw, directory Syntax: -~~~~{.php} +~~~~{.tcl} isdraw varname directory [pattern] ~~~~ @@ -661,7 +661,7 @@ directory [pattern] Use **directory** to return a list of all Draw global variables matching a pattern. **Example:** -~~~~{.php} +~~~~{.tcl} set a 1 isdraw a === 0 @@ -683,7 +683,7 @@ foreach var [directory *curve*] {unset $var} Syntax: -~~~~{.php} +~~~~{.tcl} whatis varname [varname ...] dump varname [varname ...] ~~~~ @@ -693,7 +693,7 @@ dump varname [varname ...] **dump** returns a brief type description, the coordinates, and if need be, the parameters of a Draw variable. **Example:** -~~~~{.php} +~~~~{.tcl} circle c 0 0 1 0 5 whatis c c is a 2d curve @@ -714,7 +714,7 @@ Radius :5 @subsubsection occt_draw_3_2_3 renamevar, copy Syntax: -~~~~{.php} +~~~~{.tcl} renamevar varname tovarname [varname tovarname ...] copy varname tovarname [varname tovarname ...] ~~~~ @@ -723,7 +723,7 @@ copy varname tovarname [varname tovarname ...] * **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:** -~~~~{.php} +~~~~{.tcl} circle c1 0 0 1 0 5 renamevar c1 c2 @@ -734,7 +734,7 @@ copy c2 c3 @subsubsection occt_draw_3_2_4 datadir, save, restore Syntax: -~~~~{.php} +~~~~{.tcl} datadir [directory] save variable [filename] restore filename [variablename] @@ -751,7 +751,7 @@ If the path starts with a dot (.) only the last directory name will be changed i The exact content of the file is type-dependent. They are usually ASCII files and so, architecture independent. **Example:** -~~~~{.php} +~~~~{.tcl} # note how TCL accesses shell environment variables # using $env() datadir @@ -782,7 +782,7 @@ restore theBox #### In DrawTrSurf package: -~~~~{.php} +~~~~{.cpp} void Set(const char*& Name,const gp_Pnt& G) ; void Set(const char*& Name,const gp_Pnt2d& G) ; void Set(const char*& Name, @@ -799,22 +799,22 @@ const occ::handle& P) ; #### In DBRep package: -~~~~{.php} +~~~~{.cpp} void Set(const char* Name, const TopoDS_Shape& S) ; ~~~~ Example of *DrawTrSurf* -~~~~{.php} +~~~~{.cpp} occ::handle C1 = new Geom2d_Circle -(gce_MakeCirc2d (gp_Pnt2d(50,0,) 25)); +(gce_MakeCirc2d (gp_Pnt2d(50,0), 25)); DrawTrSurf::Set(char*, C1); ~~~~ Example of *DBRep* -~~~~{.php} +~~~~{.cpp} TopoDS_Solid B; B = BRepPrimAPI_MakeBox (10,10,10); DBRep::Set(char*,B); @@ -824,13 +824,13 @@ DBRep::Set(char*,B); #### In DrawTrSurf package: -~~~~{.php} +~~~~{.cpp} occ::handle Get(const char*& Name) ; ~~~~ #### In DBRep package: -~~~~{.php} +~~~~{.cpp} TopoDS_Shape Get(const char*& Name, const TopAbs_ShapeEnum Typ = TopAbs_SHAPE, const bool Complain @@ -839,20 +839,20 @@ const bool Complain Example of *DrawTrSurf* -~~~~{.php} +~~~~{.cpp} int MyCommand (Draw_Interpretor& theCommands, int argc, char** argv) {...... // Creation of a Geom_Geometry from a Draw geometric // name -Handle (Geom_Geometry) aGeom= DrawTrSurf::Get(argv[1]); +occ::handle aGeom = DrawTrSurf::Get(argv[1]); } ~~~~ Example of *DBRep* -~~~~{.php} +~~~~{.cpp} int MyCommand (Draw_Interpretor& theCommands, int argc, char** argv) @@ -872,7 +872,7 @@ Graphic commands are used to manage the Draw graphic system. Draw provides a 2d @subsubsection occt_draw_4_1_1 view, delete Syntax: -~~~~{.php} +~~~~{.tcl} view index type [X Y W H] delete [index] ~~~~ @@ -893,7 +893,7 @@ Type selects from the following range: The index, the type, the current zoom are displayed in the window title . **Example:** -~~~~{.php} +~~~~{.tcl} # this is the content of the mu4 procedure proc mu4 {} { delete @@ -910,7 +910,7 @@ See also: **axo, pers, top, bottom, left, right, front, back, mu4, v2d, av2d, sm Syntax: -~~~~{.php} +~~~~{.tcl} axo pers ... @@ -933,7 +933,7 @@ See also: **view**, **delete** Syntax: -~~~~{.php} +~~~~{.tcl} mu [index] value 2dmu [index] value zoom [index] value @@ -947,7 +947,7 @@ perform the same on one or all 2d views. * **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:** -~~~~{.php} +~~~~{.tcl} # set a zoom of 2.5 zoom 2.5 @@ -963,13 +963,13 @@ See also: **fit**, **2dfit** Syntax: -~~~~{.php} +~~~~{.tcl} pu [index] pd [index] ~~~~ The p_ commands are used to pan. **pu** and **pd** pan up and down respectively; **pl** and **pr** pan to the left and to the right respectively. Each time the view is displaced by 40 pixels. When no index is given, all views will pan in the direction specified. -~~~~{.php} +~~~~{.tcl} # you have selected one anonometric view pu # or @@ -985,7 +985,7 @@ See also: **fit**, **2dfit** Syntax: -~~~~{.php} +~~~~{.tcl} fit [index] 2dfit [index] ~~~~ @@ -995,7 +995,7 @@ fit [index] When fitting all views a unique zoom is computed for all the views. All views are on the same scale. **Example:** -~~~~{.php} +~~~~{.tcl} # fit only view 1 fit 1 # fit all 2d views @@ -1008,7 +1008,7 @@ See also: **zoom**, **mu**, **pu** Syntax: -~~~~{.php} +~~~~{.tcl} u [index] d [index] l [index] @@ -1018,7 +1018,7 @@ 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:** -~~~~{.php} +~~~~{.tcl} # rotate the view up u ~~~~ @@ -1026,7 +1026,7 @@ u @subsubsection occt_draw_4_1_7 focal, fu, fd Syntax: -~~~~{.php} +~~~~{.tcl} focal [f] fu [index] fd [index] @@ -1036,7 +1036,7 @@ fd [index] * **fu** and **fd** increase or decrease the focal value by 10%. **fd** makes the eye closer to the object. **Example:** -~~~~{.php} +~~~~{.tcl} pers repeat 10 fd ~~~~ @@ -1049,7 +1049,7 @@ See also: **pers** Syntax: -~~~~{.php} +~~~~{.tcl} color index name ~~~~ @@ -1058,7 +1058,7 @@ color index name 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:** -~~~~{.php} +~~~~{.tcl} # change the value of blue color 3 "navy blue" ~~~~ @@ -1069,7 +1069,7 @@ color 3 "navy blue" @subsubsection occt_draw_4_1_9 dtext Syntax: -~~~~{.php} +~~~~{.tcl} dtext [x y [z]] string ~~~~ @@ -1078,7 +1078,7 @@ dtext [x y [z]] string The coordinates are real space coordinates. **Example:** -~~~~{.php} +~~~~{.tcl} # mark the origins dtext 0 0 bebop dtext 0 0 0 bebop @@ -1087,7 +1087,7 @@ dtext 0 0 0 bebop @subsubsection occt_draw_4_1_10 hardcopy, hcolor, xwd Syntax: -~~~~{.php} +~~~~{.tcl} hardcopy [index] hcolor index width gray xwd [index] filename @@ -1098,7 +1098,7 @@ xwd [index] filename * **xwd** creates an X window xwd file from an active view. By default, the index is set to1. To visualize an xwd file, use the unix command **xwud**. **Example:** -~~~~{.php} +~~~~{.tcl} # all blue lines (color 3) # will be half-width and gray hcolor 3 0.5 @@ -1122,7 +1122,7 @@ See also: **color** @subsubsection occt_draw_4_1_11 wclick, pick Syntax: -~~~~{.php} +~~~~{.tcl} wclick pick index X Y Z b [nowait] ~~~~ @@ -1141,7 +1141,7 @@ This option is useful for tracking the pointer. **Note** that the results are stored in Draw numeric variables. **Example:** -~~~~{.php} +~~~~{.tcl} # 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 @@ -1171,7 +1171,7 @@ The variable name "." (dot) has a special status in Draw. Any Draw command expec * If you do not see what you expected while executing loops or sourcing files, use the **repaint** and **dflush** commands. **Example:** -~~~~{.php} +~~~~{.tcl} # OK use dot to dump an object on the screen dump . @@ -1201,7 +1201,7 @@ renamevar . x Syntax: -~~~~{.php} +~~~~{.tcl} autodisplay [0/1] ~~~~ @@ -1210,7 +1210,7 @@ By default, Draw automatically displays any graphic object as soon as it is crea When **autodisplay** is off, using the dot return argument is ineffective. **Example:** -~~~~{.php} +~~~~{.tcl} # c is displayed circle c 0 0 1 0 5 @@ -1226,7 +1226,7 @@ display c @subsubsection occt_draw_4_1_13 display, donly Syntax: -~~~~{.php} +~~~~{.tcl} display varname [varname ...] donly varname [varname ...] ~~~~ @@ -1235,7 +1235,7 @@ donly varname [varname ...] * **donly** *display only* makes objects visible and erases all other objects. It is very useful to extract one object from a messy screen. **Example:** -~~~~{.php} +~~~~{.tcl} \# to see all objects foreach var [directory] {display $var} @@ -1248,7 +1248,7 @@ donly . . Syntax: -~~~~{.php} +~~~~{.tcl} erase [varname varname ...] clear 2dclear @@ -1260,7 +1260,7 @@ clear **Example:** -~~~~{.php} +~~~~{.tcl} # erase everything with a name starting with c_ foreach var [directory c_*] {erase $var} @@ -1272,7 +1272,7 @@ foreach var [directory c_*] {erase $var} These commands have the same meaning as correspondingly display, donly and erase, but with the difference that they evaluate the arguments using glob pattern rules. For example, to display all objects with names d_1, d_2, d_3, etc. it is enough to run the command: -~~~~{.php} +~~~~{.tcl} disp d_* ~~~~ @@ -1281,7 +1281,7 @@ disp d_* Syntax: -~~~~{.php} +~~~~{.tcl} repaint dflush ~~~~ @@ -1315,7 +1315,7 @@ Syntax: @snippet ViewerTest_ViewerCommands.cxx vtop **Example:** -~~~~{.php} +~~~~{.tcl} vinit box b 10 10 10 vdisplay b @@ -1329,7 +1329,7 @@ Syntax: @snippet ViewerTest_ViewerCommands.cxx vaxo **Example:** -~~~~{.php} +~~~~{.tcl} vinit box b 10 10 10 vdisplay b @@ -1408,7 +1408,7 @@ Syntax: @snippet ViewerTest_ViewerCommands.cxx vcamera **Example:** -~~~~{.php} +~~~~{.tcl} vinit box b 10 10 10 vdisplay b @@ -1422,7 +1422,7 @@ Syntax: @snippet ViewerTest_ViewerCommands.cxx vstereo **Example:** -~~~~{.php} +~~~~{.tcl} vinit box b 10 10 10 vdisplay b @@ -1441,7 +1441,7 @@ Syntax: @snippet ViewerTest.cxx vdisplay **Example:** -~~~~{.php} +~~~~{.tcl} vinit box b 40 40 40 10 10 10 psphere s 20 @@ -1455,7 +1455,7 @@ Syntax: @snippet ViewerTest.cxx vdonly **Example:** -~~~~{.php} +~~~~{.tcl} vinit box b 40 40 40 10 10 10 psphere s 20 @@ -1469,7 +1469,7 @@ Syntax: @snippet ViewerTest.cxx vdisplayall **Example:** -~~~~{.php} +~~~~{.tcl} vinit box b 40 40 40 10 10 10 psphere s 20 @@ -1483,7 +1483,7 @@ Syntax: @snippet ViewerTest.cxx verase **Example:** -~~~~{.php} +~~~~{.tcl} vinit box b1 40 40 40 10 10 10 box b2 -40 -40 -40 10 10 10 @@ -1502,7 +1502,7 @@ Syntax: @snippet ViewerTest.cxx veraseall **Example:** -~~~~{.php} +~~~~{.tcl} vinit box b1 40 40 40 10 10 10 box b2 -40 -40 -40 10 10 10 @@ -1521,7 +1521,7 @@ Syntax: @snippet ViewerTest.cxx vsetdispmode **Example:** -~~~~{.php} +~~~~{.tcl} vinit box b 10 10 10 vdisplay b @@ -1550,7 +1550,7 @@ Syntax: @snippet ViewerTest.cxx vaspects Aliases: -~~~~{.php} +~~~~{.tcl} vsetcolor [-noupdate|-update] [name] ColorName ~~~~ @@ -1591,7 +1591,7 @@ Manages presentation properties (color, material, transparency) of all objects, *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*. -~~~~{.php} +~~~~{.tcl} vaspects [name] [-setColor ColorName] [-setColor R G B] [-unsetColor] vsetcolor [name] ColorName vunsetcolor [name] @@ -1599,7 +1599,7 @@ vunsetcolor [name] **Transparency** may be between 0.0 (opaque) and 1.0 (fully transparent). **Warning**: at 1.0 the shape becomes invisible. -~~~~{.php} +~~~~{.tcl} vaspects [name] [-setTransparency Value] [-unsetTransparency] vsettransparency [name] Value vunsettransparency [name] @@ -1607,21 +1607,21 @@ vunsettransparency [name] **Material** name can be *BRASS*, *BRONZE*, *COPPER*, *GOLD*, *PEWTER*, *PLASTER*, *PLASTIC*, *SILVER*, *STEEL*, *STONE*, *SHINY_PLASTIC*, *SATIN*, *METALIZED*, *NEON_GNC*, *CHROME*, *ALUMINIUM*, *OBSIDIAN*, *NEON_PHC*, *JADE*, *WATER*, *GLASS*, *DIAMOND* or *CHARCOAL*. -~~~~{.php} +~~~~{.tcl} vaspects [name] [-setMaterial MaterialName] [-unsetMaterial] vsetmaterial [name] MaterialName vunsetmaterial [name] ~~~~ **Line width** specifies width of the edges. The width value may be between 0.0 and 10.0. -~~~~{.php} +~~~~{.tcl} vaspects [name] [-setWidth LineWidth] [-unsetWidth] vsetwidth [name] LineWidth vunsetwidth [name] ~~~~ **Example:** -~~~~{.php} +~~~~{.tcl} vinit box b 10 10 10 vdisplay b @@ -1638,7 +1638,7 @@ Syntax: @snippet ViewerTest.cxx vsetshading **Example:** -~~~~{.php} +~~~~{.tcl} vinit psphere s 20 vdisplay s @@ -1668,7 +1668,7 @@ Syntax: @snippet ViewerTest.cxx vsub **Example:** -~~~~{.php} +~~~~{.tcl} vinit box b 10 10 10 psphere s 20 @@ -1704,7 +1704,7 @@ Syntax: @snippet ViewerTest_ViewerCommands.cxx vrenderparams **Example:** -~~~~{.php} +~~~~{.tcl} vinit box b 10 10 10 vdisplay b @@ -1725,7 +1725,7 @@ Syntax: @snippet ViewerTest_ObjectCommands.cxx vtrihedron **Example:** -~~~~{.php} +~~~~{.tcl} vinit vtrihedron tr1 @@ -1746,7 +1746,7 @@ Syntax: @snippet ViewerTest_ObjectCommands.cxx vsize **Example:** -~~~~{.php} +~~~~{.tcl} vinit vtrihedron tr1 vtrihedron tr2 0 0 0 1 0 0 1 0 0 @@ -1759,7 +1759,7 @@ Syntax: @snippet ViewerTest_ObjectCommands.cxx vaxis **Example:** -~~~~{.php} +~~~~{.tcl} vinit vtrihedron tr vaxis axe1 0 0 0 1 0 0 @@ -1781,7 +1781,7 @@ Syntax: @snippet ViewerTest_ObjectCommands.cxx vpoint **Example:** -~~~~{.php} +~~~~{.tcl} vinit vpoint p 0 0 0 ~~~~ @@ -1792,7 +1792,7 @@ Syntax: @snippet ViewerTest_ObjectCommands.cxx vplane **Example:** -~~~~{.php} +~~~~{.tcl} vinit vpoint p1 0 50 0 vaxis axe1 0 0 0 0 0 1 @@ -1816,7 +1816,7 @@ Syntax: @snippet ViewerTest_ObjectCommands.cxx vline **Example:** -~~~~{.php} +~~~~{.tcl} vinit vtrihedron tr vpoint p1 0 50 0 @@ -1831,7 +1831,7 @@ Syntax: @snippet ViewerTest_ObjectCommands.cxx vcircle **Example:** -~~~~{.php} +~~~~{.tcl} vinit vtrihedron tr vpoint p1 0 50 0 @@ -1851,7 +1851,7 @@ Syntax: @snippet ViewerTest_ObjectCommands.cxx vselmode **Example:** -~~~~{.php} +~~~~{.tcl} vinit vpoint p1 0 0 0 vpoint p2 50 0 0 @@ -1865,7 +1865,7 @@ Syntax: @snippet ViewerTest_ObjectCommands.cxx vconnect **Example:** -~~~~{.php} +~~~~{.tcl} vinit vpoint p1 0 0 0 vpoint p2 50 0 0 @@ -1881,7 +1881,7 @@ Syntax: @snippet ViewerTest_ObjectCommands.cxx vtriangle **Example:** -~~~~{.php} +~~~~{.tcl} vinit vpoint p1 0 0 0 vpoint p2 50 0 0 @@ -1895,7 +1895,7 @@ Syntax: @snippet ViewerTest_ObjectCommands.cxx vsegment **Example:** -~~~~{.php} +~~~~{.tcl} vinit vpoint p1 0 0 0 vpoint p2 50 0 0 @@ -1908,7 +1908,7 @@ Syntax: @snippet ViewerTest_ObjectCommands.cxx vpointcloud **Example:** -~~~~{.php} +~~~~{.tcl} vinit vpointcloud pc 0 0 0 100 100000 surface -randColor vfit @@ -1920,7 +1920,7 @@ Syntax: @snippet ViewerTest_ViewerCommands.cxx vclipplane **Example:** -~~~~{.php} +~~~~{.tcl} vinit vclipplane pln1 -equation 1 0 0 -0.1 -set Driver1/Viewer1/View1 box b 100 100 100 @@ -1939,7 +1939,7 @@ Syntax: **Attention:** length dimension can't be built without working plane. **Example:** -~~~~{.php} +~~~~{.tcl} vinit vpoint p1 0 0 0 vpoint p2 50 50 0 @@ -1959,7 +1959,7 @@ Syntax: @snippet ViewerTest_RelationCommands.cxx vdimparam **Example:** -~~~~{.php} +~~~~{.tcl} vinit vpoint p1 0 0 0 vpoint p2 50 50 0 @@ -1976,7 +1976,7 @@ Syntax: @snippet ViewerTest_RelationCommands.cxx vangleparam **Example:** -~~~~{.php} +~~~~{.tcl} vinit vpoint p1 0 0 0 vpoint p2 10 0 0 @@ -1992,7 +1992,7 @@ Syntax: @snippet ViewerTest_RelationCommands.cxx vlengthparam **Example:** -~~~~{.php} +~~~~{.tcl} vinit vpoint p1 20 20 0 vpoint p2 80 80 0 @@ -2009,7 +2009,7 @@ Syntax: @snippet ViewerTest_RelationCommands.cxx vmovedim **Example:** -~~~~{.php} +~~~~{.tcl} vinit vpoint p1 0 0 0 vpoint p2 50 50 0 @@ -2033,21 +2033,21 @@ You can control the number of occurrences of the texture on a face, the position @subsubsection occt_draw_4_5_1 meshfromstl Syntax: -~~~~{.php} +~~~~{.tcl} meshfromstl meshname file ~~~~ Creates a *MeshVS_Mesh* object based on STL file data. The object will be displayed immediately. **Example:** -~~~~{.php} +~~~~{.tcl} meshfromstl mesh myfile.stl ~~~~ @subsubsection occt_draw_4_5_2 vsetdispmode Syntax: -~~~~{.php} +~~~~{.tcl} vsetdispmode meshname displaymode ~~~~ @@ -2057,7 +2057,7 @@ Changes the display mode of object **meshname**. The **displaymode** is integer * *3* for *shrink* mode. **Example:** -~~~~{.php} +~~~~{.tcl} vinit meshfromstl mesh myfile.stl vsetdispmode mesh 2 @@ -2066,7 +2066,7 @@ vsetdispmode mesh 2 @subsubsection occt_draw_4_5_3 vselmode Syntax: -~~~~{.php} +~~~~{.tcl} vselmode meshname selectionmode {on|off} ~~~~ @@ -2081,7 +2081,7 @@ The *selectionmode* is integer OR-combination of mode flags (`MeshVS_SelectionMo * *256* -- groups (not supported in STL). **Example:** -~~~~{.php} +~~~~{.tcl} vinit meshfromstl mesh myfile.stl vselmode mesh 1 @@ -2090,39 +2090,39 @@ vselmode mesh 1 @subsubsection occt_draw_4_5_4 meshshadcolor Syntax: -~~~~{.php} +~~~~{.tcl} 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:** -~~~~{.php} +~~~~{.tcl} vinit meshfromstl mesh myfile.stl -meshshadcolormode mesh 0.5 0.5 0.5 +meshshadcolor mesh 0.5 0.5 0.5 ~~~~ @subsubsection occt_draw_4_5_5 meshlinkcolor Syntax: -~~~~{.php} +~~~~{.tcl} 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:** -~~~~{.php} +~~~~{.tcl} vinit meshfromstl mesh myfile.stl -meshlinkcolormode mesh 0.5 0.5 0.5 +meshlinkcolor mesh 0.5 0.5 0.5 ~~~~ @subsubsection occt_draw_4_5_6 meshmat Syntax: -~~~~{.php} +~~~~{.tcl} meshmat meshname material [transparency] ~~~~ @@ -2150,7 +2150,7 @@ Changes the material of object **meshname**. * *18 -- JADE*. **Example:** -~~~~{.php} +~~~~{.tcl} vinit meshfromstl mesh myfile.stl meshmat mesh 18 @@ -2159,7 +2159,7 @@ meshmat mesh 18 @subsubsection occt_draw_4_5_7 meshshrcoef Syntax: -~~~~{.php} +~~~~{.tcl} meshshrcoef meshname shrinkcoefficient ~~~~ @@ -2168,7 +2168,7 @@ In the shrink mode the face is shown as a congruent part of a usual face, so tha The *shrinkcoefficient* is a positive real number. **Example:** -~~~~{.php} +~~~~{.tcl} vinit meshfromstl mesh myfile.stl meshshrcoef mesh 0.05 @@ -2177,7 +2177,7 @@ meshshrcoef mesh 0.05 @subsubsection occt_draw_4_5_8 meshshow Syntax: -~~~~{.php} +~~~~{.tcl} meshshow meshname ~~~~ @@ -2185,7 +2185,7 @@ Displays **meshname** in the viewer (if it is erased). The same as calling `vdisplay`. **Example:** -~~~~{.php} +~~~~{.tcl} vinit meshfromstl mesh myfile.stl meshshow mesh @@ -2194,7 +2194,7 @@ meshshow mesh @subsubsection occt_draw_4_5_9 meshhide Syntax: -~~~~{.php} +~~~~{.tcl} meshhide meshname ~~~~ @@ -2202,7 +2202,7 @@ Hides **meshname** in the viewer. The same as calling `verase`. **Example:** -~~~~{.php} +~~~~{.tcl} vinit meshfromstl mesh myfile.stl meshhide mesh @@ -2211,7 +2211,7 @@ meshhide mesh @subsubsection occt_draw_4_5_10 meshhidesel Syntax: -~~~~{.php} +~~~~{.tcl} meshhidesel meshname ~~~~ @@ -2220,7 +2220,7 @@ Hides only selected entities. The other part of **meshname** remains visible. @subsubsection occt_draw_4_5_11 meshshowsel Syntax: -~~~~{.php} +~~~~{.tcl} meshshowsel meshname ~~~~ @@ -2229,7 +2229,7 @@ Shows only selected entities. The other part of **meshname** becomes invisible. @subsubsection occt_draw_4_5_12 meshshowall Syntax: -~~~~{.php} +~~~~{.tcl} meshshowall meshname ~~~~ @@ -2238,14 +2238,14 @@ Changes the state of all entities to visible for **meshname**. @subsubsection occt_draw_4_5_13 vremove Syntax: -~~~~{.php} +~~~~{.tcl} vremove meshname ~~~~ Deletes MeshVS_Mesh object **meshname**. **Example:** -~~~~{.php} +~~~~{.tcl} vinit meshfromstl mesh myfile.stl vremove mesh @@ -2255,14 +2255,14 @@ vremove mesh A specific plugin with alias *VIS* should be loaded to have access to VIS functionality in DRAW Test Harness: -~~~~{.php} +~~~~{.tcl} \> pload VIS ~~~~ @subsubsection occt_draw_4_6_1 ivtkinit Syntax: -~~~~{.php} +~~~~{.tcl} ivtkinit ~~~~ @@ -2273,14 +2273,14 @@ Creates a window for VTK viewer. @subsubsection occt_draw_4_6_2 ivtkdisplay Syntax: -~~~~{.php} +~~~~{.tcl} ivtkdisplay name1 [name2] …[name n] ~~~~ Displays named objects. **Example:** -~~~~{.php} +~~~~{.tcl} ivtkinit # create cone pcone c 5 0 10 @@ -2293,14 +2293,14 @@ ivtkdisplay c @subsubsection occt_draw_4_6_3 ivtkerase Syntax: -~~~~{.php} +~~~~{.tcl} ivtkerase [name1] [name2] … [name n] ~~~~ Erases named objects. If no arguments are passed, erases all displayed objects. **Example:** -~~~~{.php} +~~~~{.tcl} ivtkinit # create a sphere psphere s 10 @@ -2319,16 +2319,16 @@ ivtkerase s c @subsubsection occt_draw_4_6_4 ivtkfit Syntax: -~~~~{.php} +~~~~{.tcl} ivtkfit ~~~~ Automatic zoom/panning. -@subsubsection occt_draw_4_6_5 ivtkdispmode +@subsubsection occt_draw_4_6_5 ivtksetdispmode Syntax: -~~~~{.php} +~~~~{.tcl} ivtksetdispmode [name] {0|1} ~~~~ @@ -2336,7 +2336,7 @@ Sets display mode for a named object. If no arguments are passed, sets the given The possible modes are: 0 (WireFrame) and 1 (Shading). **Example:** -~~~~{.php} +~~~~{.tcl} ivtkinit # create a cone pcone c 5 0 10 @@ -2351,14 +2351,14 @@ ivtksetdispmode c 1 @subsubsection occt_draw_4_6_6 ivtksetselmode Syntax: -~~~~{.php} +~~~~{.tcl} ivtksetselmode [name] mode {0|1} ~~~~ Sets selection mode for a named object. If no arguments are passed, sets the given selection mode for all the displayed objects. **Example:** -~~~~{.php} +~~~~{.tcl} ivtkinit # load a shape from file restore CrankArm.brep a @@ -2373,14 +2373,14 @@ ivtksetselmode a 4 1 @subsubsection occt_draw_4_6_7 ivtkmoveto Syntax: -~~~~{.php} +~~~~{.tcl} ivtkmoveto x y ~~~~ Imitates mouse cursor moving to point with the given display coordinates **x**,**y**. **Example:** -~~~~{.php} +~~~~{.tcl} ivtkinit pcone c 5 0 10 ivtkdisplay c @@ -2390,14 +2390,14 @@ ivtkmoveto 40 50 @subsubsection occt_draw_4_6_8 ivtkselect Syntax: -~~~~{.php} +~~~~{.tcl} ivtkselect x y ~~~~ Imitates mouse cursor moving to point with the given display coordinates and performs selection at this point. **Example:** -~~~~{.php} +~~~~{.tcl} ivtkinit pcone c 5 0 10 ivtkdisplay c @@ -2407,7 +2407,7 @@ ivtkselect 40 50 @subsubsection occt_draw_4_6_9 ivtkdump Syntax: -~~~~{.php} +~~~~{.tcl} ivtkdump *filename* [buffer={rgb|rgba|depth}] [width height] [stereoproj={L|R}] ~~~~ @@ -2418,7 +2418,7 @@ Dumps the contents of VTK viewer to image. It supports: * dumping of stereo projections (left or right). **Example:** -~~~~{.php} +~~~~{.tcl} ivtkinit pcone c 5 0 10 ivtkdisplay c @@ -2429,21 +2429,21 @@ ivtkdump D:/ConeSnapshot.png rgb 768 768 Syntax: -~~~~{.php} +~~~~{.tcl} ivtkbgcolor r g b [r2 g2 b2] ~~~~ Sets uniform background color or gradient background if second triple of parameters is set. Color parameters r,g,b have to be chosen in the interval [0..255]. **Example:** -~~~~{.php} +~~~~{.tcl} ivtkinit ivtkbgcolor 200 220 250 ~~~~ @figure{/user_guides/draw_test_harness/images/draw_image005.png,"",196} -~~~~{.php} +~~~~{.tcl} ivtkbgcolor 10 30 80 255 255 255 ~~~~ @@ -2460,14 +2460,14 @@ This chapter contains a set of commands for Open CASCADE Technology Application @subsubsection occt_draw_5_1_1 NewDocument Syntax: -~~~~{.php} +~~~~{.tcl} NewDocument docname [format] ~~~~ Creates a new **docname** document with MDTV-Standard or described format. **Example:** -~~~~{.php} +~~~~{.tcl} # Create new document with default (MDTV-Standard) format NewDocument D @@ -2478,21 +2478,21 @@ NewDocument D2 BinOcaf @subsubsection occt_draw_5_1_2 IsInSession Syntax: -~~~~{.php} +~~~~{.tcl} IsInSession path ~~~~ -Returns *0*, if **path** document is managed by the application session, *1* -- otherwise. +Returns *1* if the document at **path** is currently managed by the application session, *0* otherwise. **Example:** -~~~~{.php} +~~~~{.tcl} IsInSession /myPath/myFile.std ~~~~ @subsubsection occt_draw_5_1_3 ListDocuments Syntax: -~~~~{.php} +~~~~{.tcl} ListDocuments ~~~~ @@ -2502,7 +2502,7 @@ Makes a list of documents handled during the session of the application. @subsubsection occt_draw_5_1_4 Open Syntax: -~~~~{.php} +~~~~{.tcl} Open path docname [-stream] ~~~~ @@ -2511,42 +2511,42 @@ Retrieves the document of file **docname** in the path **path**. Overwrites the option -stream activates usage of alternative interface of OCAF persistence working with C++ streams instead of file names. **Example:** -~~~~{.php} +~~~~{.tcl} Open /myPath/myFile.std D ~~~~ @subsubsection occt_draw_5_1_5 Close Syntax: -~~~~{.php} +~~~~{.tcl} Close docname ~~~~ Closes **docname** document. The document is no longer handled by the applicative session. **Example:** -~~~~{.php} +~~~~{.tcl} Close D ~~~~ @subsubsection occt_draw_5_1_6 Save Syntax: -~~~~{.php} +~~~~{.tcl} Save docname ~~~~ Saves **docname** active document. **Example:** -~~~~{.php} +~~~~{.tcl} Save D ~~~~ @subsubsection occt_draw_5_1_7 SaveAs Syntax: -~~~~{.php} +~~~~{.tcl} SaveAs docname path [-stream] ~~~~ @@ -2555,7 +2555,7 @@ Saves the active document in the file **docname** in the path **path**. Overwrit option -stream activates usage of alternative interface of OCAF persistence working with C++ streams instead of file names. **Example:** -~~~~{.php} +~~~~{.tcl} SaveAs D /myPath/myFile.std ~~~~ @@ -2565,14 +2565,14 @@ SaveAs D /myPath/myFile.std Syntax: -~~~~{.php} +~~~~{.tcl} Label docname entry ~~~~ Creates the label expressed by \ if it does not exist. Example -~~~~{.php} +~~~~{.tcl} Label D 0:2 ~~~~ @@ -2580,13 +2580,13 @@ Label D 0:2 Syntax: -~~~~{.php} +~~~~{.tcl} NewChild docname [taggerlabel = Root label] ~~~~ Finds (or creates) a *TagSource* attribute located at father label of \ and makes a new child label. Example -~~~~{.php} +~~~~{.tcl} # Create new child of root label NewChild D @@ -2598,26 +2598,26 @@ NewChild D 0:2 @subsubsection occt_draw_5_2_3 Children Syntax: -~~~~{.php} +~~~~{.tcl} Children docname label ~~~~ Returns the list of attributes of label. Example -~~~~{.php} +~~~~{.tcl} Children D 0:2 ~~~~ @subsubsection occt_draw_5_2_4 ForgetAll Syntax: -~~~~{.php} +~~~~{.tcl} ForgetAll docname label ~~~~ Forgets all attributes of the label. Example -~~~~{.php} +~~~~{.tcl} ForgetAll D 0:2 ~~~~ @@ -2627,21 +2627,21 @@ ForgetAll D 0:2 @subsubsection occt_draw_5_3_1 Main Syntax: -~~~~{.php} +~~~~{.tcl} Main docname ~~~~ Returns the main label of the framework. **Example:** -~~~~{.php} +~~~~{.tcl} Main D ~~~~ @subsubsection occt_draw_5_3_2 UndoLimit Syntax: -~~~~{.php} +~~~~{.tcl} UndoLimit docname [value=0] ~~~~ @@ -2649,126 +2649,126 @@ 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:** -~~~~{.php} +~~~~{.tcl} UndoLimit D 100 ~~~~ @subsubsection occt_draw_5_3_3 Undo Syntax: -~~~~{.php} +~~~~{.tcl} Undo docname [value=1] ~~~~ Undoes **value** steps. **Example:** -~~~~{.php} +~~~~{.tcl} Undo D ~~~~ @subsubsection occt_draw_5_3_4 Redo Syntax: -~~~~{.php} +~~~~{.tcl} Redo docname [value=1] ~~~~ Redoes **value** steps. **Example:** -~~~~{.php} +~~~~{.tcl} Redo D ~~~~ @subsubsection occt_draw_5_3_5 OpenCommand Syntax: -~~~~{.php} +~~~~{.tcl} OpenCommand docname ~~~~ Opens a new command transaction. **Example:** -~~~~{.php} +~~~~{.tcl} OpenCommand D ~~~~ @subsubsection occt_draw_5_3_6 CommitCommand Syntax: -~~~~{.php} +~~~~{.tcl} CommitCommand docname ~~~~ Commits the Command transaction. **Example:** -~~~~{.php} +~~~~{.tcl} CommitCommand D ~~~~ @subsubsection occt_draw_5_3_7 NewCommand Syntax: -~~~~{.php} +~~~~{.tcl} NewCommand docname ~~~~ This is a shortcut for Commit and Open transaction. **Example:** -~~~~{.php} +~~~~{.tcl} NewCommand D ~~~~ @subsubsection occt_draw_5_3_8 AbortCommand Syntax: -~~~~{.php} +~~~~{.tcl} AbortCommand docname ~~~~ Aborts the Command transaction. **Example:** -~~~~{.php} +~~~~{.tcl} AbortCommand D ~~~~ @subsubsection occt_draw_5_3_9 Copy Syntax: -~~~~{.php} +~~~~{.tcl} Copy docname entry Xdocname Xentry ~~~~ Copies the contents of *entry* to *Xentry*. No links are registered. **Example:** -~~~~{.php} +~~~~{.tcl} Copy D1 0:2 D2 0:4 ~~~~ @subsubsection occt_draw_5_3_10 UpdateLink Syntax: -~~~~{.php} +~~~~{.tcl} UpdateLink docname [entry] ~~~~ Updates external reference set at *entry*. **Example:** -~~~~{.php} +~~~~{.tcl} UpdateLink D ~~~~ @subsubsection occt_draw_5_3_11 CopyWithLink Syntax: -~~~~{.php} +~~~~{.tcl} CopyWithLink docname entry Xdocname Xentry ~~~~ @@ -2776,35 +2776,35 @@ Aborts the Command transaction. Copies the content of *entry* to *Xentry*. The link is registered with an *Xlink* attribute at *Xentry* label. **Example:** -~~~~{.php} +~~~~{.tcl} CopyWithLink D1 0:2 D2 0:4 ~~~~ @subsubsection occt_draw_5_3_12 UpdateXLinks Syntax: -~~~~{.php} +~~~~{.tcl} UpdateXLinks docname entry ~~~~ Sets modifications on labels impacted by external references to the *entry*. The *document* becomes invalid and must be recomputed **Example:** -~~~~{.php} +~~~~{.tcl} UpdateXLinks D 0:2 ~~~~ @subsubsection occt_draw_5_3_13 DumpDocument Syntax: -~~~~{.php} +~~~~{.tcl} DumpDocument docname ~~~~ Displays parameters of *docname* document. **Example:** -~~~~{.php} +~~~~{.tcl} DumpDocument D ~~~~ @@ -2815,84 +2815,84 @@ DumpDocument D @subsubsection occt_draw_5_4_1 MakeDF Syntax: -~~~~{.php} +~~~~{.tcl} MakeDF dfname ~~~~ Creates a new data framework. **Example:** -~~~~{.php} +~~~~{.tcl} MakeDF D ~~~~ @subsubsection occt_draw_5_4_2 ClearDF Syntax: -~~~~{.php} +~~~~{.tcl} ClearDF dfname ~~~~ Clears a data framework. **Example:** -~~~~{.php} +~~~~{.tcl} ClearDF D ~~~~ @subsubsection occt_draw_5_4_3 CopyDF Syntax: -~~~~{.php} +~~~~{.tcl} CopyDF dfname1 entry1 [dfname2] entry2 ~~~~ Copies a data framework. **Example:** -~~~~{.php} +~~~~{.tcl} CopyDF D 0:2 0:4 ~~~~ @subsubsection occt_draw_5_4_4 CopyLabel Syntax: -~~~~{.php} +~~~~{.tcl} CopyLabel dfname fromlabel tolablel ~~~~ Copies a label. **Example:** -~~~~{.php} +~~~~{.tcl} CopyLabel D1 0:2 0:4 ~~~~ @subsubsection occt_draw_5_4_5 MiniDumpDF Syntax: -~~~~{.php} +~~~~{.tcl} MiniDumpDF dfname ~~~~ Makes a mini-dump of a data framework. **Example:** -~~~~{.php} +~~~~{.tcl} MiniDumpDF D ~~~~ @subsubsection occt_draw_5_4_6 XDumpDF Syntax: -~~~~{.php} +~~~~{.tcl} XDumpDF dfname ~~~~ Makes an extended dump of a data framework. **Example:** -~~~~{.php} +~~~~{.tcl} XDumpDF D ~~~~ @@ -2902,238 +2902,238 @@ XDumpDF D @subsubsection occt_draw_5_5_1 SetInteger Syntax: -~~~~{.php} +~~~~{.tcl} SetInteger dfname entry value ~~~~ Finds or creates an Integer attribute at *entry* label and sets *value*. **Example:** -~~~~{.php} +~~~~{.tcl} SetInteger D 0:2 100 ~~~~ @subsubsection occt_draw_5_5_2 GetInteger Syntax: -~~~~{.php} +~~~~{.tcl} 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:** -~~~~{.php} +~~~~{.tcl} GetInteger D 0:2 Int1 ~~~~ @subsubsection occt_draw_5_5_3 SetReal Syntax: -~~~~{.php} +~~~~{.tcl} SetReal dfname entry value ~~~~ Finds or creates a Real attribute at *entry* label and sets *value*. **Example:** -~~~~{.php} +~~~~{.tcl} SetReal D 0:2 100. ~~~~ @subsubsection occt_draw_5_5_4 GetReal Syntax: -~~~~{.php} +~~~~{.tcl} 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:** -~~~~{.php} +~~~~{.tcl} GetReal D 0:2 Real1 ~~~~ @subsubsection occt_draw_5_5_5 SetIntArray Syntax: -~~~~{.php} +~~~~{.tcl} 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:** -~~~~{.php} +~~~~{.tcl} SetIntArray D 0:2 1 4 100 200 300 400 ~~~~ @subsubsection occt_draw_5_5_6 GetIntArray Syntax: -~~~~{.php} +~~~~{.tcl} GetIntArray dfname entry ~~~~ Gets a value of an *IntegerArray* attribute at *entry* label. **Example:** -~~~~{.php} +~~~~{.tcl} GetIntArray D 0:2 ~~~~ @subsubsection occt_draw_5_5_7 SetRealArray Syntax: -~~~~{.php} +~~~~{.tcl} 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:** -~~~~{.php} +~~~~{.tcl} GetRealArray D 0:2 1 4 100. 200. 300. 400. ~~~~ @subsubsection occt_draw_5_5_8 GetRealArray Syntax: -~~~~{.php} +~~~~{.tcl} GetRealArray dfname entry ~~~~ Gets a value of a RealArray attribute at *entry* label. **Example:** -~~~~{.php} +~~~~{.tcl} GetRealArray D 0:2 ~~~~ @subsubsection occt_draw_5_5_9 SetComment Syntax: -~~~~{.php} +~~~~{.tcl} SetComment dfname entry value ~~~~ Finds or creates a Comment attribute at *entry* label and sets *value*. **Example:** -~~~~{.php} +~~~~{.tcl} SetComment D 0:2 "My comment" ~~~~ @subsubsection occt_draw_5_5_10 GetComment Syntax: -~~~~{.php} +~~~~{.tcl} GetComment dfname entry ~~~~ Gets a value of a Comment attribute at *entry* label. **Example:** -~~~~{.php} +~~~~{.tcl} GetComment D 0:2 ~~~~ @subsubsection occt_draw_5_5_11 SetExtStringArray Syntax: -~~~~{.php} +~~~~{.tcl} 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:** -~~~~{.php} +~~~~{.tcl} SetExtStringArray D 0:2 1 3 *string1* *string2* *string3* ~~~~ @subsubsection occt_draw_5_5_12 GetExtStringArray Syntax: -~~~~{.php} +~~~~{.tcl} GetExtStringArray dfname entry ~~~~ Gets a value of an ExtStringArray attribute at *entry* label. **Example:** -~~~~{.php} +~~~~{.tcl} GetExtStringArray D 0:2 ~~~~ @subsubsection occt_draw_5_5_13 SetName Syntax: -~~~~{.php} +~~~~{.tcl} SetName dfname entry value ~~~~ Finds or creates a Name attribute at *entry* label and sets *value*. **Example:** -~~~~{.php} +~~~~{.tcl} SetName D 0:2 *My name* ~~~~ @subsubsection occt_draw_5_5_14 GetName Syntax: -~~~~{.php} +~~~~{.tcl} GetName dfname entry ~~~~ Gets a value of a Name attribute at *entry* label. **Example:** -~~~~{.php} +~~~~{.tcl} GetName D 0:2 ~~~~ @subsubsection occt_draw_5_5_15 SetReference Syntax: -~~~~{.php} +~~~~{.tcl} SetReference dfname entry reference ~~~~ Creates a Reference attribute at *entry* label and sets *reference*. **Example:** -~~~~{.php} +~~~~{.tcl} SetReference D 0:2 0:4 ~~~~ @subsubsection occt_draw_5_5_16 GetReference Syntax: -~~~~{.php} +~~~~{.tcl} GetReference dfname entry ~~~~ Gets a value of a Reference attribute at *entry* label. **Example:** -~~~~{.php} +~~~~{.tcl} GetReference D 0:2 ~~~~ @subsubsection occt_draw_5_5_17 SetUAttribute Syntax: -~~~~{.php} +~~~~{.tcl} SetUAttribute dfname entry localGUID ~~~~ Creates a UAttribute attribute at *entry* label with *localGUID*. **Example:** -~~~~{.php} +~~~~{.tcl} set localGUID "c73bd076-22ee-11d2-acde-080009dc4422" SetUAttribute D 0:2 ${localGUID} ~~~~ @@ -3141,14 +3141,14 @@ SetUAttribute D 0:2 ${localGUID} @subsubsection occt_draw_5_5_18 GetUAttribute Syntax: -~~~~{.php} +~~~~{.tcl} GetUAttribute dfname entry loacalGUID ~~~~ Finds a *UAttribute* at *entry* label with *localGUID*. **Example:** -~~~~{.php} +~~~~{.tcl} set localGUID "c73bd076-22ee-11d2-acde-080009dc4422" GetUAttribute D 0:2 ${localGUID} ~~~~ @@ -3156,14 +3156,14 @@ GetUAttribute D 0:2 ${localGUID} @subsubsection occt_draw_5_5_19 SetFunction Syntax: -~~~~{.php} +~~~~{.tcl} SetFunction dfname entry ID failure ~~~~ Finds or creates a *Function* attribute at *entry* label with driver ID and *failure* index. **Example:** -~~~~{.php} +~~~~{.tcl} set ID "c73bd076-22ee-11d2-acde-080009dc4422" SetFunction D 0:2 ${ID} 1 ~~~~ @@ -3171,28 +3171,28 @@ SetFunction D 0:2 ${ID} 1 @subsubsection occt_draw_5_5_20 GetFunction Syntax: -~~~~{.php} +~~~~{.tcl} 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:** -~~~~{.php} +~~~~{.tcl} GetFunction D 0:2 ID failure ~~~~ @subsubsection occt_draw_5_5_21 NewShape Syntax: -~~~~{.php} +~~~~{.tcl} 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:** -~~~~{.php} +~~~~{.tcl} box b 10 10 10 NewShape D 0:2 b ~~~~ @@ -3200,14 +3200,14 @@ NewShape D 0:2 b @subsubsection occt_draw_5_5_22 SetShape Syntax: -~~~~{.php} +~~~~{.tcl} SetShape dfname entry shape ~~~~ Creates or updates a *NamedShape* attribute at *entry* label by *shape*. **Example:** -~~~~{.php} +~~~~{.tcl} box b 10 10 10 SetShape D 0:2 b ~~~~ @@ -3215,14 +3215,14 @@ SetShape D 0:2 b @subsubsection occt_draw_5_5_23 GetShape Syntax: -~~~~{.php} +~~~~{.tcl} GetShape2 dfname entry shape ~~~~ Sets a shape from NamedShape attribute associated with *entry* label to *shape* draw variable. **Example:** -~~~~{.php} +~~~~{.tcl} GetShape2 D 0:2 b ~~~~ @@ -3232,14 +3232,14 @@ GetShape2 D 0:2 b @subsubsection occt_draw_5_6_1 SetPoint Syntax: -~~~~{.php} +~~~~{.tcl} SetPoint dfname entry point ~~~~ Finds or creates a Point attribute at *entry* label and sets *point* as generated in the associated *NamedShape* attribute. **Example:** -~~~~{.php} +~~~~{.tcl} point p 10 10 10 SetPoint D 0:2 p ~~~~ @@ -3247,28 +3247,28 @@ SetPoint D 0:2 p @subsubsection occt_draw_5_6_2 GetPoint Syntax: -~~~~{.php} +~~~~{.tcl} GetPoint dfname entry [drawname] ~~~~ Gets a vertex from *NamedShape* attribute at *entry* label and sets it to *drawname* variable, if it is defined. **Example:** -~~~~{.php} +~~~~{.tcl} GetPoint D 0:2 p ~~~~ @subsubsection occt_draw_5_6_3 SetAxis Syntax: -~~~~{.php} +~~~~{.tcl} SetAxis dfname entry axis ~~~~ Finds or creates an Axis attribute at *entry* label and sets *axis* as generated in the associated *NamedShape* attribute. **Example:** -~~~~{.php} +~~~~{.tcl} line l 10 20 30 100 200 300 SetAxis D 0:2 l ~~~~ @@ -3276,28 +3276,28 @@ SetAxis D 0:2 l @subsubsection occt_draw_5_6_4 GetAxis Syntax: -~~~~{.php} +~~~~{.tcl} GetAxis dfname entry [drawname] ~~~~ Gets a line from *NamedShape* attribute at *entry* label and sets it to *drawname* variable, if it is defined. **Example:** -~~~~{.php} +~~~~{.tcl} GetAxis D 0:2 l ~~~~ @subsubsection occt_draw_5_6_5 SetPlane Syntax: -~~~~{.php} +~~~~{.tcl} SetPlane dfname entry plane ~~~~ Finds or creates a Plane attribute at *entry* label and sets *plane* as generated in the associated *NamedShape* attribute. **Example:** -~~~~{.php} +~~~~{.tcl} plane pl 10 20 30 -1 0 0 SetPlane D 0:2 pl ~~~~ @@ -3305,28 +3305,28 @@ SetPlane D 0:2 pl @subsubsection occt_draw_5_6_6 GetPlane Syntax: -~~~~{.php} +~~~~{.tcl} GetPlane dfname entry [drawname] ~~~~ Gets a plane from *NamedShape* attribute at *entry* label and sets it to *drawname* variable, if it is defined. **Example:** -~~~~{.php} +~~~~{.tcl} GetPlane D 0:2 pl ~~~~ @subsubsection occt_draw_5_6_7 SetGeometry Syntax: -~~~~{.php} +~~~~{.tcl} 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:** -~~~~{.php} +~~~~{.tcl} point p 10 10 10 SetGeometry D 0:2 pnt p ~~~~ @@ -3334,21 +3334,21 @@ SetGeometry D 0:2 pnt p @subsubsection occt_draw_5_6_8 GetGeometryType Syntax: -~~~~{.php} +~~~~{.tcl} GetGeometryType dfname entry ~~~~ Gets a geometry type from Geometry attribute at *entry* label. **Example:** -~~~~{.php} +~~~~{.tcl} GetGeometryType D 0:2 ~~~~ @subsubsection occt_draw_5_6_9 SetConstraint Syntax: -~~~~{.php} +~~~~{.tcl} SetConstraint dfname entry keyword geometrie [geometrie …] SetConstraint dfname entry "plane" geometrie SetConstraint dfname entry "value" value @@ -3361,49 +3361,49 @@ SetConstraint dfname entry "value" value 3. Sets value for the existing constraint. **Example:** -~~~~{.php} +~~~~{.tcl} SetConstraint D 0:2 "value" 5 ~~~~ @subsubsection occt_draw_5_6_10 GetConstraint Syntax: -~~~~{.php} +~~~~{.tcl} GetConstraint dfname entry ~~~~ Dumps a Constraint attribute at *entry* label **Example:** -~~~~{.php} +~~~~{.tcl} GetConstraint D 0:2 ~~~~ @subsubsection occt_draw_5_6_11 SetVariable Syntax: -~~~~{.php} +~~~~{.tcl} SetVariable dfname entry isconstant(0/1) units ~~~~ Creates a Variable attribute at *entry* label and sets *isconstant* flag and *units* as a string. **Example:** -~~~~{.php} +~~~~{.tcl} SetVariable D 0:2 1 "mm" ~~~~ @subsubsection occt_draw_5_6_12 GetVariable Syntax: -~~~~{.php} +~~~~{.tcl} GetVariable dfname entry isconstant units ~~~~ Gets an *isconstant* flag and units of a Variable attribute at *entry* label. **Example:** -~~~~{.php} +~~~~{.tcl} GetVariable D 0:2 isconstant units puts "IsConstant=${isconstant}" puts "Units=${units}" @@ -3415,7 +3415,7 @@ puts "Units=${units}" @subsubsection occt_draw_5_7_1 RootNode Syntax: -~~~~{.php} +~~~~{.tcl} RootNode dfname treenodeentry [ID] ~~~~ @@ -3425,7 +3425,7 @@ Returns the ultimate father of *TreeNode* attribute identified by its *treenodee @subsubsection occt_draw_5_7_2 SetNode Syntax: -~~~~{.php} +~~~~{.tcl} SetNode dfname treenodeentry [ID] ~~~~ @@ -3435,7 +3435,7 @@ Creates a *TreeNode* attribute on the *treenodeentry* label with its tree *ID* ( @subsubsection occt_draw_5_7_3 AppendNode Syntax: -~~~~{.php} +~~~~{.tcl} AppendNode dfname fatherentry childentry [fatherID] ~~~~ @@ -3448,7 +3448,7 @@ Inserts a *TreeNode* attribute with its tree *fatherID* (or default ID, if *fath @subsubsection occt_draw_5_7_4 PrependNode Syntax: -~~~~{.php} +~~~~{.tcl} PrependNode dfname fatherentry childentry [fatherID] ~~~~ @@ -3459,7 +3459,7 @@ Inserts a *TreeNode* attribute with its tree *fatherID* (or default ID, if *fath @subsubsection occt_draw_5_7_5 InsertNodeBefore Syntax: -~~~~{.php} +~~~~{.tcl} InsertNodeBefore dfname treenodeentry beforetreenode [ID] ~~~~ @@ -3469,7 +3469,7 @@ Inserts a *TreeNode* attribute with tree *ID* (or default ID, if *ID* is not def @subsubsection occt_draw_5_7_6 InsertNodeAfter Syntax: -~~~~{.php} +~~~~{.tcl} InsertNodeAfter dfname treenodeentry aftertreenode [ID] ~~~~ @@ -3479,7 +3479,7 @@ Inserts a *TreeNode* attribute with tree *ID* (or default ID, if *ID* is not def @subsubsection occt_draw_5_7_7 DetachNode Syntax: -~~~~{.php} +~~~~{.tcl} DetachNode dfname treenodeentry [ID] ~~~~ @@ -3489,7 +3489,7 @@ Removes a *TreeNode* attribute with tree *ID* (or default ID, if *ID* is not def @subsubsection occt_draw_5_7_8 ChildNodeIterate Syntax: -~~~~{.php} +~~~~{.tcl} ChildNodeIterate dfname treenodeentry alllevels(0/1) [ID] ~~~~ @@ -3497,7 +3497,7 @@ 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:** -~~~~{.php} +~~~~{.tcl} Label D 0:2 Label D 0:3 Label D 0:4 @@ -3545,7 +3545,7 @@ ChildNodeIterate D 0:2 1 @subsubsection occt_draw_5_7_9 InitChildNodeIterator Syntax: -~~~~{.php} +~~~~{.tcl} InitChildNodeIterator dfname treenodeentry alllevels(0/1) [ID] ~~~~ @@ -3553,7 +3553,7 @@ 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:** -~~~~{.php} +~~~~{.tcl} InitChildNodeIterate D 0:5 1 set aChildNumber 0 for {set i 1} {$i < 100} {incr i} { @@ -3569,7 +3569,7 @@ puts "aChildNumber=$aChildNumber" @subsubsection occt_draw_5_7_10 ChildNodeMore Syntax: -~~~~{.php} +~~~~{.tcl} ChildNodeMore ~~~~ @@ -3579,7 +3579,7 @@ Returns TRUE if there is a current item in the iteration. @subsubsection occt_draw_5_7_11 ChildNodeNext Syntax: -~~~~{.php} +~~~~{.tcl} ChildNodeNext ~~~~ @@ -3589,7 +3589,7 @@ Moves to the next Item. @subsubsection occt_draw_5_7_12 ChildNodeValue Syntax: -~~~~{.php} +~~~~{.tcl} ChildNodeValue ~~~~ @@ -3599,7 +3599,7 @@ Returns the current treenode of *ChildNodeIterator*. @subsubsection occt_draw_5_7_13 ChildNodeNextBrother Syntax: -~~~~{.php} +~~~~{.tcl} ChildNodeNextBrother ~~~~ @@ -3612,112 +3612,112 @@ Moves to the next *Brother*. If there is none, goes up. This method is interesti @subsubsection occt_draw_5_8_1 AISInitViewer Syntax: -~~~~{.php} +~~~~{.tcl} AISInitViewer docname ~~~~ Creates and sets *AISViewer* attribute at root label, creates AIS viewer window. **Example:** -~~~~{.php} +~~~~{.tcl} AISInitViewer D ~~~~ @subsubsection occt_draw_5_8_2 AISRepaint Syntax: -~~~~{.php} +~~~~{.tcl} AISRepaint docname ~~~~ Updates the AIS viewer window. **Example:** -~~~~{.php} +~~~~{.tcl} AISRepaint D ~~~~ @subsubsection occt_draw_5_8_3 AISDisplay Syntax: -~~~~{.php} +~~~~{.tcl} 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:** -~~~~{.php} +~~~~{.tcl} AISDisplay D 0:5 ~~~~ @subsubsection occt_draw_5_8_4 AISUpdate Syntax: -~~~~{.php} +~~~~{.tcl} AISUpdate docname entry ~~~~ Recomputes a presentation of *AISobject* from *entry* label and applies the visualization setting in AIS viewer. **Example:** -~~~~{.php} +~~~~{.tcl} AISUpdate D 0:5 ~~~~ @subsubsection occt_draw_5_8_5 AISErase Syntax: -~~~~{.php} +~~~~{.tcl} AISErase docname entry ~~~~ Erases *AISobject* of *entry* label in AIS viewer. **Example:** -~~~~{.php} +~~~~{.tcl} AISErase D 0:5 ~~~~ @subsubsection occt_draw_5_8_6 AISRemove Syntax: -~~~~{.php} +~~~~{.tcl} AISRemove docname entry ~~~~ Erases *AISobject* of *entry* label in AIS viewer, then *AISobject* is removed from *AIS_InteractiveContext*. **Example:** -~~~~{.php} +~~~~{.tcl} AISRemove D 0:5 ~~~~ @subsubsection occt_draw_5_8_7 AISSet Syntax: -~~~~{.php} +~~~~{.tcl} 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:** -~~~~{.php} +~~~~{.tcl} AISSet D 0:5 NS ~~~~ @subsubsection occt_draw_5_8_8 AISDriver Syntax: -~~~~{.php} +~~~~{.tcl} 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:** -~~~~{.php} +~~~~{.tcl} # Get Driver GUID AISDriver D 0:5 ~~~~ @@ -3725,98 +3725,98 @@ AISDriver D 0:5 @subsubsection occt_draw_5_8_9 AISUnset Syntax: -~~~~{.php} +~~~~{.tcl} AISUnset docname entry ~~~~ Deletes *AISPresentation* attribute (if it exists) of an *entry* label. **Example:** -~~~~{.php} +~~~~{.tcl} AISUnset D 0:5 ~~~~ @subsubsection occt_draw_5_8_10 AISTransparency Syntax: -~~~~{.php} +~~~~{.tcl} AISTransparency docname entry [transparency] ~~~~ Sets (if *transparency* is defined) or gets the value of transparency for *AISPresentation* attribute of an *entry* label. **Example:** -~~~~{.php} +~~~~{.tcl} AISTransparency D 0:5 0.5 ~~~~ @subsubsection occt_draw_5_8_11 AISHasOwnTransparency Syntax: -~~~~{.php} +~~~~{.tcl} AISHasOwnTransparency docname entry ~~~~ Tests *AISPresentation* attribute of an *entry* label by own transparency. **Example:** -~~~~{.php} +~~~~{.tcl} AISHasOwnTransparency D 0:5 ~~~~ @subsubsection occt_draw_5_8_12 AISMaterial Syntax: -~~~~{.php} +~~~~{.tcl} 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 @ref occt_draw_4_5_6 "meshmat" command). **Example:** -~~~~{.php} +~~~~{.tcl} AISMaterial D 0:5 5 ~~~~ @subsubsection occt_draw_5_8_13 AISHasOwnMaterial Syntax: -~~~~{.php} +~~~~{.tcl} AISHasOwnMaterial docname entry ~~~~ Tests *AISPresentation* attribute of an *entry* label by own material. **Example:** -~~~~{.php} +~~~~{.tcl} AISHasOwnMaterial D 0:5 ~~~~ @subsubsection occt_draw_5_8_14 AISColor Syntax: -~~~~{.php} +~~~~{.tcl} 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:** -~~~~{.php} +~~~~{.tcl} AISColor D 0:5 25 ~~~~ @subsubsection occt_draw_5_8_15 AISHasOwnColor Syntax: -~~~~{.php} +~~~~{.tcl} AISHasOwnColor docname entry ~~~~ Tests *AISPresentation* attribute of an *entry* label by own color. **Example:** -~~~~{.php} +~~~~{.tcl} AISHasOwnColor D 0:5 ~~~~ @@ -3824,7 +3824,7 @@ AISHasOwnColor D 0:5 @subsection occt_draw_6_1 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. +Draw provides a set of commands to test geometry libraries. These commands are available in *DRAWEXE* once the corresponding *GeometryTest* plug-in is loaded with `pload MODELING` (or `pload ALL`). In the context of Geometry, Draw includes the following types of variable: @@ -3867,14 +3867,14 @@ Curves are displayed with an arrow showing the last parameter. @subsubsection occt_draw_6_2_1 point Syntax: -~~~~{.php} +~~~~{.tcl} point name x y [z] ~~~~ Creates a 2d or 3d point, depending on the number of arguments. **Example:** -~~~~{.php} +~~~~{.tcl} # 2d point point p1 1 2 @@ -3885,7 +3885,7 @@ point p2 10 20 -5 @subsubsection occt_draw_6_2_2 line Syntax: -~~~~{.php} +~~~~{.tcl} line name x y [z] dx dy [dz] ~~~~ @@ -3895,7 +3895,7 @@ Creates a 2d or 3d line. *x y z* are the coordinates of the line’s point of or A 2d line will be represented as *x y dx dy*, and a 3d line as *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:** -~~~~{.php} +~~~~{.tcl} # a 2d line at 45 degrees of the X axis line l 2 0 1 1 @@ -3906,7 +3906,7 @@ line l 10 0 0 0 0 1 @subsubsection occt_draw_6_2_3 circle Syntax: -~~~~{.php} +~~~~{.tcl} circle name x y [z [dx dy dz]] [ux uy [uz]] radius ~~~~ @@ -3919,7 +3919,7 @@ In 3d, *x, y, z* are the coordinates of the center; *dx, dy, dz* give the vector 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:** -~~~~{.php} +~~~~{.tcl} # A 2d circle of radius 5 centered at 10,-2 circle c1 10 -2 5 @@ -3941,13 +3941,13 @@ circle c5 10 20 -5 1 0 0 0 0 1 17 @subsubsection occt_draw_6_2_4 ellipse Syntax: -~~~~{.php} +~~~~{.tcl} ellipse name x y [z [dx dy dz]] [ux uy [uz]] firstradius secondradius ~~~~ 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: -~~~~{.php} +~~~~{.tcl} P(u) = O + firstradius*cos(u)*Xdir + secondradius*sin(u)*Ydir ~~~~ Where: @@ -3956,7 +3956,7 @@ Where: * *O, Xdir* and *Ydir* are respectively the origin, *X Direction* and *Y Direction* of its local coordinate system. **Example:** -~~~~{.php} +~~~~{.tcl} # default 2d ellipse ellipse e1 10 5 20 10 @@ -3973,14 +3973,14 @@ ellipse e4 0 0 0 0 1 0 1 0 1 25 5 @subsubsection occt_draw_6_2_5 hyperbola Syntax: -~~~~{.php} +~~~~{.tcl} hyperbola name x y [z [dx dy dz]] [ux uy [uz]] firstradius secondradius ~~~~ 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: -~~~~{.php} +~~~~{.tcl} P(U) = O + firstradius*Cosh(U)*XDir + secondradius*Sinh(U)*YDir ~~~~ Where: @@ -3989,7 +3989,7 @@ Where: * *O, XDir* and *YDir* are respectively the origin, *X Direction* and *YDirection* of its local coordinate system. **Example:** -~~~~{.php} +~~~~{.tcl} # default 2d hyperbola, with asymptotes 1,1 -1,1 hyperbola h1 0 0 30 30 @@ -4003,7 +4003,7 @@ hyperbola h3 0 0 0 50 50 @subsubsection occt_draw_6_2_6 parabola Syntax: -~~~~{.php} +~~~~{.tcl} parabola name x y [z [dx dy dz]] [ux uy [uz]] FocalLength ~~~~ @@ -4011,7 +4011,7 @@ Creates a 2d or 3d parabola. in the axis system defined by the first arguments. The *Geom_Parabola* is parameterized as follows: -~~~~{.php} +~~~~{.tcl} P(u) = O + u*u/(4.*F)*XDir + u*YDir ~~~~ @@ -4021,7 +4021,7 @@ Where: * *F* is the focal length of the parabola. **Example:** -~~~~{.php} +~~~~{.tcl} # 2d parabola parabola p1 0 0 50 @@ -4035,7 +4035,7 @@ parabola p3 0 0 0 1 0 0 0 0 1 50 @subsubsection occt_draw_6_2_7 beziercurve, 2dbeziercurve Syntax: -~~~~{.php} +~~~~{.tcl} beziercurve name nbpole pole, [weight] 2dbeziercurve name nbpole pole, [weight] ~~~~ @@ -4043,7 +4043,7 @@ beziercurve name nbpole pole, [weight] 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:** -~~~~{.php} +~~~~{.tcl} # a rational 2d bezier curve (arc of circle) 2dbeziercurve ci 3 0 0 1 10 0 sqrt(2.)/2. 10 10 1 @@ -4054,7 +4054,7 @@ beziercurve cc 4 0 0 0 10 0 0 10 0 10 10 10 10 @subsubsection occt_draw_6_2_8 bsplinecurve, 2dbsplinecurve, pbsplinecurve, 2dpbsplinecurve Syntax: -~~~~{.php} +~~~~{.tcl} bsplinecurve name degree nbknots knot, umult pole, weight 2dbsplinecurve name degree nbknots knot, umult pole, weight @@ -4075,7 +4075,7 @@ The poles must be given with their weights, use weights of 1 for a non rational * For a periodic curve: Sum of multiplicities - last multiplicity **Example:** -~~~~{.php} +~~~~{.tcl} # 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 @@ -4098,7 +4098,7 @@ dset h sqrt(3)/2 @subsubsection occt_draw_6_2_9 uiso, viso Syntax: -~~~~{.php} +~~~~{.tcl} uiso name surface u viso name surface u ~~~~ @@ -4106,7 +4106,7 @@ viso name surface u Creates a U or V isoparametric curve from a surface. **Example:** -~~~~{.php} +~~~~{.tcl} # create a cylinder and extract iso curves cylinder c 10 @@ -4120,7 +4120,7 @@ viso c2 c @subsubsection occt_draw_6_2_10 to3d, to2d Syntax: -~~~~{.php} +~~~~{.tcl} to3d name curve2d [plane] to2d name curve3d [plane] ~~~~ @@ -4128,7 +4128,7 @@ to2d name curve3d [plane] 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:** -~~~~{.php} +~~~~{.tcl} # the following commands circle c 0 0 5 plane p -2 1 0 1 2 3 @@ -4144,7 +4144,7 @@ See also: **project** @subsubsection occt_draw_6_2_11 project Syntax: -~~~~{.php} +~~~~{.tcl} project name curve3d surface ~~~~ @@ -4152,7 +4152,7 @@ Computes a 2d curve in the parametric space of a surface corresponding to a 3d c If we, for example, intersect a cylinder and a plane and project the resulting ellipse on the cylinder, this will create a 2d sinusoid-like bspline. -~~~~{.php} +~~~~{.tcl} cylinder c 5 plane p 0 0 0 0 1 1 intersect i c p @@ -4173,7 +4173,7 @@ Surfaces are displayed with isoparametric lines. To show the parameterization, a @subsubsection occt_draw_6_3_1 plane Syntax: -~~~~{.php} +~~~~{.tcl} plane name [x y z [dx dy dz [ux uy uz]]] ~~~~ @@ -4188,7 +4188,7 @@ There are default values for the coordinate system. If no arguments are given, t Note that this definition will be used for all analytical surfaces. **Example:** -~~~~{.php} +~~~~{.tcl} # 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 @@ -4200,14 +4200,14 @@ plane p2 10 -20 -5 @subsubsection occt_draw_6_3_2 cylinder Syntax: -~~~~{.php} +~~~~{.tcl} 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. **Example:** -~~~~{.php} +~~~~{.tcl} # a cylinder on the default Z axis, radius 10 cylinder c1 10 @@ -4225,13 +4225,13 @@ sin(la) 10 @subsubsection occt_draw_6_3_3 cone Syntax: -~~~~{.php} +~~~~{.tcl} 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. **Example:** -~~~~{.php} +~~~~{.tcl} # a cone at 45 degrees at the origin on Z cone c1 45 0 @@ -4242,7 +4242,7 @@ cone c2 0 0 z1 180.*atan2(r2-r1,z2-z1)/pi r1 @subsubsection occt_draw_6_3_4 sphere Syntax: -~~~~{.php} +~~~~{.tcl} sphere name [x y z [dx dy dz [ux uy uz]]] radius ~~~~ @@ -4251,7 +4251,7 @@ Creates a sphere in the local coordinate system defined in the **plane** command To parameterize the sphere, *u* is the angle from X to Y, between 0 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:** -~~~~{.php} +~~~~{.tcl} # a sphere at the origin sphere s1 10 # a sphere at 10 10 10, with poles on the axis 1,1,1 @@ -4261,7 +4261,7 @@ sphere s2 10 10 10 1 1 1 10 @subsubsection occt_draw_6_3_5 torus Syntax: -~~~~{.php} +~~~~{.tcl} torus name [x y z [dx dy dz [ux uy uz]]] major minor ~~~~ @@ -4270,7 +4270,7 @@ Creates a torus in the local coordinate system with the given major and minor ra 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:** -~~~~{.php} +~~~~{.tcl} # a torus at the origin torus t1 20 5 @@ -4282,7 +4282,7 @@ torus t2 10 5 -2 2 1 0 20 5 @subsubsection occt_draw_6_3_6 beziersurf Syntax: -~~~~{.php} +~~~~{.tcl} beziersurf name nbupoles nbvolpes pole, [weight] ~~~~ @@ -4293,7 +4293,7 @@ Then give the poles in the following order: *pole(1, 1), pole(nbupoles, 1), pole Weights may be omitted, but if you give one weight you must give all of them. **Example:** -~~~~{.php} +~~~~{.tcl} # a non-rational degree 2,3 surface beziersurf s 3 4 \ 0 0 0 10 0 5 20 0 0 \ @@ -4305,7 +4305,7 @@ beziersurf s 3 4 \ @subsubsection occt_draw_6_3_7 bsplinesurf, upbsplinesurf, vpbsplinesurf, uvpbsplinesurf Syntax: -~~~~{.php} +~~~~{.tcl} bsplinesurf name udegree nbuknots uknot umult ... nbvknot vknot vmult ... x y z w ... upbsplinesurf ... @@ -4323,7 +4323,7 @@ The syntax is similar to the *bsplinecurve* command. First give the degree in u 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:** -~~~~{.php} +~~~~{.tcl} # create a bspline surface of degree 1 2 # with two knots in U and three in V bsplinesurf s \ @@ -4339,7 +4339,7 @@ bsplinesurf s \ @subsubsection occt_draw_6_3_8 trim, trimu, trimv Syntax: -~~~~{.php} +~~~~{.tcl} trim newname name [u1 u2 [v1 v2] [usense vsense]] trimu newname name u1 u2 [usense] trimv newname name v1 v2 [vsense] @@ -4355,7 +4355,7 @@ After an initial trim, a second execution with no parameters given recreates the **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:** -~~~~{.php} +~~~~{.tcl} # create a 3d circle circle c 0 0 0 10 @@ -4385,7 +4385,7 @@ trimv cy cy 0 50 @subsubsection occt_draw_6_3_9 offset Syntax: -~~~~{.php} +~~~~{.tcl} offset name basename distance [dx dy dz] ~~~~ @@ -4396,7 +4396,7 @@ The curve can be a 2d or a 3d curve. To compute the offsets for a 3d curve, you The offset curve or surface copies the basic geometry, which can be modified later. **Example:** -~~~~{.php} +~~~~{.tcl} # graphic demonstration that the outline of a torus # is the offset of an ellipse smallview +X+Y @@ -4411,7 +4411,7 @@ offset l1 e 20 0 0 1 @subsubsection occt_draw_6_3_10 revsurf Syntax: -~~~~{.php} +~~~~{.tcl} revsurf name curvename x y z dx dy dz ~~~~ @@ -4422,7 +4422,7 @@ A surface of revolution or revolved surface is obtained by rotating a curve (cal 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:** -~~~~{.php} +~~~~{.tcl} # another way of creating a torus like surface circle c 50 0 0 20 revsurf s c 0 0 0 0 1 0 @@ -4431,7 +4431,7 @@ revsurf s c 0 0 0 0 1 0 @subsubsection occt_draw_6_3_11 extsurf Syntax: -~~~~{.php} +~~~~{.tcl} extsurf newname curvename dx dy dz ~~~~ @@ -4442,7 +4442,7 @@ 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:** -~~~~{.php} +~~~~{.tcl} # an elliptic cylinder ellipse e 0 0 0 10 5 extsurf s e 0 0 1 @@ -4453,14 +4453,14 @@ trimv s s 0 10 @subsubsection occt_draw_6_3_12 convert Syntax: -~~~~{.php} +~~~~{.tcl} convert newname name ~~~~ 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:** -~~~~{.php} +~~~~{.tcl} # turn a 2d arc of a circle into a 2d NURBS circle c 0 0 5 trim c c 0 pi/3 @@ -4504,7 +4504,7 @@ Modifications for bspline: Syntax: -~~~~{.php} +~~~~{.tcl} reverse curvename ureverse surfacename vreverse surfacename @@ -4517,7 +4517,7 @@ The **reverse** command reverses the parameterization and inverses the orientati Reversing a parameter on an analytical surface may create an indirect coordinate system. **Example:** -~~~~{.php} +~~~~{.tcl} # reverse a trimmed 2d circle circle c 0 0 5 trim c c pi/4 pi/2 @@ -4530,14 +4530,14 @@ reverse c @subsubsection occt_draw_6_4_2 exchuv Syntax: -~~~~{.php} +~~~~{.tcl} exchuv surfacename ~~~~ For a bezier or bspline surface this command exchanges the u and v parameters. **Example:** -~~~~{.php} +~~~~{.tcl} # exchanging u and v on a spline (made from a cylinder) cylinder c 5 trimv c c 0 10 @@ -4548,7 +4548,7 @@ exchuv c1 @subsubsection occt_draw_6_4_3 segment, segsur Syntax: -~~~~{.php} +~~~~{.tcl} segment curve Ufirst Ulast segsur surface Ufirst Ulast Vfirst Vlast ~~~~ @@ -4560,7 +4560,7 @@ These commands modify the curve to restrict it between the new parameters: *Ufir This command must not be confused with **trim** which creates a new geometry. **Example:** -~~~~{.php} +~~~~{.tcl} # segment a bezier curve in half beziercurve c 3 0 0 0 10 0 0 10 10 0 segment c ufirst ulast @@ -4569,7 +4569,7 @@ segment c ufirst ulast @subsubsection occt_draw_6_4_4 iincudeg, incvdeg Syntax: -~~~~{.php} +~~~~{.tcl} incudeg surfacename newdegree incvdeg surfacename newdegree ~~~~ @@ -4577,7 +4577,7 @@ incvdeg surfacename newdegree **incudeg** and **incvdeg** increase the degree in the U or V parameter of a bezier or bspline surface. **Example:** -~~~~{.php} +~~~~{.tcl} # make a planar bspline and increase the degree to 2 3 plane p trim p p -1 1 -1 1 @@ -4592,7 +4592,7 @@ incvdeg p1 3 @subsubsection occt_draw_6_4_5 cmovep, movep, movecolp, moverowp Syntax: -~~~~{.php} +~~~~{.tcl} cmovep curve index dx dy [dz] movep surface uindex vindex dx dy dz movecolp surface uindex dx dy dz @@ -4604,7 +4604,7 @@ moverowp surface vindex dx dy dz * **movecolp** and **moverowp** translate a whole column (expressed by the *uindex*) or row (expressed by the *vindex*) of poles. **Example:** -~~~~{.php} +~~~~{.tcl} # start with a plane # transform to bspline, raise degree and add relief plane p @@ -4620,7 +4620,7 @@ movep p1 2 2 0 0 5 @subsubsection occt_draw_6_4_6 insertpole, rempole, remcolpole, remrowpole Syntax: -~~~~{.php} +~~~~{.tcl} insertpole curvename index x y [z] [weight] rempole curvename index remcolpole surfacename index @@ -4634,7 +4634,7 @@ remrowpole surfacename index **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:** -~~~~{.php} +~~~~{.tcl} # start with a segment, insert a pole at end # then remove the central pole beziercurve c 2 0 0 0 10 0 0 @@ -4645,7 +4645,7 @@ rempole c 2 @subsubsection occt_draw_6_4_7 insertknot, insertuknot, insertvknot Syntax: -~~~~{.php} +~~~~{.tcl} insertknot name knot [mult = 1] [knot mult ...] insertuknot surfacename knot mult insertvknot surfacename knot mult @@ -4656,7 +4656,7 @@ insertvknot surfacename knot mult **insertuknot** and **insertvknot** insert knots in a surface. **Example:** -~~~~{.php} +~~~~{.tcl} # create a cylindrical surface and insert a knot cylinder c 10 trim c c 0 pi/2 0 10 @@ -4667,7 +4667,7 @@ insertuknot c1 pi/4 1 @subsubsection occt_draw_6_4_8 remknot, remuknot, remvknot Syntax: -~~~~{.php} +~~~~{.tcl} remknot index [mult] [tol] remuknot index [mult] [tol] remvknot index [mult] [tol] @@ -4678,7 +4678,7 @@ remvknot index [mult] [tol] By default, if no tolerance is given, the knot will always be removed. **Example:** -~~~~{.php} +~~~~{.tcl} # bspline circle, remove a knot circle c 0 0 5 convert c1 c @@ -4692,7 +4692,7 @@ remknot c1 2 @subsubsection occt_draw_6_4_9 setperiodic, setnotperiodic, setuperiodic, setunotperiodic, setvperiodic, setvnotperiodic Syntax: -~~~~{.php} +~~~~{.tcl} setperiodic curve setnotperiodic curve setuperiodic surface @@ -4706,7 +4706,7 @@ setvnotperiodic surface **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:** -~~~~{.php} +~~~~{.tcl} # a circle deperiodicized circle c 0 0 5 convert c1 c @@ -4716,7 +4716,7 @@ setnotperiodic c1 @subsubsection occt_draw_6_4_10 setorigin, setuorigin, setvorigin Syntax: -~~~~{.php} +~~~~{.tcl} setorigin curvename index setuorigin surfacename index setuorigin surfacename index @@ -4725,7 +4725,7 @@ 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:** -~~~~{.php} +~~~~{.tcl} # a torus with new U and V origins torus t 20 5 convert t1 t @@ -4741,7 +4741,7 @@ Draw provides commands to apply linear transformations to geometric objects: the @subsubsection occt_draw_6_5_1 translate, dtranslate Syntax: -~~~~{.php} +~~~~{.tcl} translate name [names ...] dx dy dz 2dtranslate name [names ...] dx dy ~~~~ @@ -4751,7 +4751,7 @@ The **Translate** command translates 3d points, curves and surfaces along a vect For 2d points or curves, use the **2dtranslate** command. **Example:** -~~~~{.php} +~~~~{.tcl} # 3d translation point p 10 20 30 circle c 10 20 30 5 @@ -4765,7 +4765,7 @@ translate p c t 0 0 15 @subsubsection occt_draw_6_5_2 rotate, 2drotate Syntax: -~~~~{.php} +~~~~{.tcl} rotate name [name ...] x y z dx dy dz angle 2drotate name [name ...] x y angle ~~~~ @@ -4775,7 +4775,7 @@ The **rotate** command rotates a 3d point curve or surface. You must give an axi For a 2d rotation, you need only give the center point and the angle. In 2d or 3d, the angle can be negative. **Example:** -~~~~{.php} +~~~~{.tcl} # make a helix of circles. create a script file with this code and execute it using **source**. circle c0 10 0 0 3 @@ -4789,7 +4789,7 @@ rotate c$i 0 0 0 0 0 1 36 @subsubsection occt_draw_6_5_3 pmirror, lmirror, smirror, dpmirror, dlmirror Syntax: -~~~~{.php} +~~~~{.tcl} pmirror name [names ...] x y z lmirror name [names ...] x y z dx dy dz smirror name [names ...] x y z dx dy dz @@ -4806,7 +4806,7 @@ The mirror commands perform a mirror transformation of 2d or 3d geometry. * **2dlmirror** is the axis symmetry mirror in 2D. **Example:** -~~~~{.php} +~~~~{.tcl} # build 3 images of a torus torus t 10 10 10 1 2 3 5 1 copy t t1 @@ -4820,7 +4820,7 @@ smirror t3 0 0 0 1 0 0 @subsubsection occt_draw_6_5_4 pscale, dpscale Syntax: -~~~~{.php} +~~~~{.tcl} pscale name [name ...] x y z s 2dpscale name [name ...] x y s ~~~~ @@ -4829,7 +4829,7 @@ The **pscale** and **2dpscale** commands transform an object by point scaling. Y **Example:** -~~~~{.php} +~~~~{.tcl} # double the size of a sphere sphere s 0 0 0 10 pscale s 0 0 0 2 @@ -4850,14 +4850,14 @@ pscale s 0 0 0 2 @subsubsection occt_draw_6_6_1 coord Syntax: -~~~~{.php} +~~~~{.tcl} coord P x y [z] ~~~~ Sets the x, y (and optionally z) coordinates of the point P. **Example:** -~~~~{.php} +~~~~{.tcl} # translate a point point p 10 5 5 translate p 5 0 0 @@ -4869,7 +4869,7 @@ coord p x y z @subsubsection occt_draw_6_6_2 cvalue, 2dcvalue Syntax: -~~~~{.php} +~~~~{.tcl} cvalue curve U x y z [d1x d1y d1z [d2x d2y d2z]] 2dcvalue curve U x y [d1x d1y [d2x d2y]] ~~~~ @@ -4880,7 +4880,7 @@ For a curve at a given parameter, and depending on the number of arguments, **cv Let on a bezier curve at parameter 0 the point is the first pole; the first derivative is the vector to the second pole multiplied by the degree; the second derivative is the difference first to the second pole, second to the third pole multiplied by *degree-1* : -~~~~{.php} +~~~~{.tcl} 2dbeziercurve c 4 0 0 1 1 2 1 3 0 2dcvalue c 0 x y d1x d1y d2x d2y @@ -4891,14 +4891,14 @@ Let on a bezier curve at parameter 0 the point is the first pole; the first deri @subsubsection occt_draw_6_6_3 svalue Syntax: -~~~~{.php} +~~~~{.tcl} svalue surfname U v x y z [dux duy duz dvx dvy dvz [d2ux d2uy d2uz d2vx d2vy d2vz d2uvx d2uvy d2uvz]] ~~~~ Computes points and derivatives on a surface for a pair of parameter values. The result depends on the number of arguments. You can compute the first and the second derivatives. **Example:** -~~~~{.php} +~~~~{.tcl} # display points on a sphere sphere s 10 for {dset t 0} {[dval t] <= 1} {dset t t+0.01} { @@ -4910,7 +4910,7 @@ point . x y z @subsubsection occt_draw_6_6_4 localprop, minmaxcurandinf Syntax: -~~~~{.php} +~~~~{.tcl} localprop curvename U minmaxcurandinf curve ~~~~ @@ -4919,7 +4919,7 @@ minmaxcurandinf curve **minmaxcurandinf** computes and prints the parameters of the points where the curvature is minimum and maximum on a 2d curve. **Example:** -~~~~{.php} +~~~~{.tcl} # 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 @@ -4929,14 +4929,14 @@ localprop c 0.5 @subsubsection occt_draw_6_6_5 parameters Syntax: -~~~~{.php} +~~~~{.tcl} parameters surf/curve x y z U [V] ~~~~ 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:** -~~~~{.php} +~~~~{.tcl} # Compute parameters on a plane plane p 0 0 10 1 1 0 parameters p 5 5 5 u v @@ -4946,7 +4946,7 @@ parameters p 5 5 5 u v @subsubsection occt_draw_6_6_6 proj, 2dproj Syntax: -~~~~{.php} +~~~~{.tcl} proj name x y z 2dproj name xy ~~~~ @@ -4959,7 +4959,7 @@ The command will compute and display all points in the projection. The lines joi Let us project a point on a torus -~~~~{.php} +~~~~{.tcl} torus t 20 5 proj t 30 10 7 == ext_1 ext_2 ext_3 ext_4 @@ -4968,7 +4968,7 @@ proj t 30 10 7 @subsubsection occt_draw_6_6_7 surface_radius Syntax: -~~~~{.php} +~~~~{.tcl} surface_radius surface u v [c1 c2] ~~~~ @@ -4978,7 +4978,7 @@ Computes the main curvatures of a surface at parameters *(u,v)*. If there are ex Let us compute curvatures of a cylinder: -~~~~{.php} +~~~~{.tcl} cylinder c 5 surface_radius c pi 3 c1 c2 == Min Radius of Curvature : -5 @@ -4995,14 +4995,14 @@ surface_radius c pi 3 c1 c2 @subsubsection occt_draw_6_7_1 intersect Syntax: -~~~~{.php} +~~~~{.tcl} intersect name surface1 surface2 ~~~~ 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:** -~~~~{.php} +~~~~{.tcl} # create an ellipse cone c 45 0 plane p 0 0 40 0 1 5 @@ -5012,7 +5012,7 @@ intersect e c p @subsubsection occt_draw_6_7_2 2dintersect Syntax: -~~~~{.php} +~~~~{.tcl} 2dintersect curve1 [curve2] [-tol tol] [-state] ~~~~ @@ -5022,7 +5022,7 @@ Options: -state - allows printing the intersection state for each point. **Example:** -~~~~{.php} +~~~~{.tcl} # intersect two 2d ellipses ellipse e1 0 0 5 2 ellipse e2 0 0 0 1 5 2 @@ -5032,7 +5032,7 @@ ellipse e2 0 0 0 1 5 2 @subsubsection occt_draw_6_7_3 intconcon Syntax: -~~~~{.php} +~~~~{.tcl} intconcon curve1 curve2 ~~~~ @@ -5041,7 +5041,7 @@ Curves must be only conic sections: 2d lines, circles, ellipses, hyperbolas, parabolas. The algorithm from *IntAna2d_AnaIntersection* is used. **Example:** -~~~~{.php} +~~~~{.tcl} # intersect two 2d ellipses ellipse e1 0 0 5 2 ellipse e2 0 0 0 1 5 2 @@ -5061,7 +5061,7 @@ Draw provides command to create curves and surfaces by approximation. @subsubsection occt_draw_6_8_1 appro, dapprox Syntax: -~~~~{.php} +~~~~{.tcl} appro result nbpoint [curve] 2dapprox result nbpoint [curve / x1 y1 x2 y2] ~~~~ @@ -5072,7 +5072,7 @@ These commands fit a curve through a set of points. First give the number of poi Let us pick points and they will be fitted -~~~~{.php} +~~~~{.tcl} 2dapprox c 10 ~~~~ @@ -5080,7 +5080,7 @@ Let us pick points and they will be fitted Syntax: -~~~~{.php} +~~~~{.tcl} surfapp name nbupoints nbvpoints x y z .... or surfapp name nbupoints nbvpoints surf [periodic_flag = 0] @@ -5100,7 +5100,7 @@ U direction of result surface corresponds columns of initial array of points. If **periodic_flag** = 1, algorithm uses first row of array as last row and builds periodical surface. **Example:** -~~~~{.php} +~~~~{.tcl} # a surface using the same data as in the beziersurf example sect 4.4 surfapp s 3 4 \ @@ -5121,7 +5121,7 @@ Draw provides commands to project points/curves on curves/surfaces. @subsubsection occt_draw_6_9_1 projponf Syntax: -~~~~{.php} +~~~~{.tcl} projponf face pnt [extrema flag: -min/-max/-minmax] [extrema algo: -g(grad)/-t(tree)] ~~~~ @@ -5136,7 +5136,7 @@ You can change the Extrema options: -minmax - to look for MinMax solutions. **Example** -~~~~{.php} +~~~~{.tcl} plane p 0 0 0 0 0 1 mkface f p point pnt 5 5 10 @@ -5156,7 +5156,7 @@ projponf f pnt @subsubsection occt_draw_6_10_1 cirtang Syntax: -~~~~{.php} +~~~~{.tcl} cirtang result [-t ] -c -p -r ... ~~~~ @@ -5168,7 +5168,7 @@ Builds all circles satisfying the condition: Only following set of input data is supported: Curve-Curve-Curve, Curve-Curve-Point, Curve-Curve-Radius, Curve-Point-Point, Curve-Point-Radius, Point-Point-Point, Point-Point-Radius. The solutions will be stored in variables *result_1*, *result_2*, etc. **Example:** -~~~~{.php} +~~~~{.tcl} # a point, a line and a radius. 2 solutions of type Curve-Point-Radius (C-P-R) point p 0 0 line l 10 0 -1 1 @@ -5179,7 +5179,7 @@ cirtang c -p p -c l -r 4 Additionally it is possible to create a circle(s) with given center and tangent to the given curve (Curve-Point type). **Example:** -~~~~{.php} +~~~~{.tcl} point pp 1 1 2dbsplinecurve cc 1 2 0 2 1 2 -10 -5 1 10 -5 1 cirtang r -p pp -c cc @@ -5189,14 +5189,14 @@ cirtang r -p pp -c cc @subsubsection occt_draw_6_10_2 lintan Syntax: -~~~~{.php} +~~~~{.tcl} lintan name curve curve [angle] ~~~~ Builds all 2d lines tangent to two curves. If the 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:** -~~~~{.php} +~~~~{.tcl} # lines tangent to 2 circles, 4 solutions circle c1 -10 0 10 circle c2 10 0 5 @@ -5225,7 +5225,7 @@ On bspline curves and surfaces you can toggle the display of the knots with the @subsubsection occt_draw_6_11_1 dmod, discr, defle Syntax: -~~~~{.php} +~~~~{.tcl} dmode name [name ...] u/d discr name [name ...] nbintervals defle name [name ...] deflection @@ -5240,7 +5240,7 @@ In *d*, or discretization mode, a fixed number of points is computed. This numbe 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:** -~~~~{.php} +~~~~{.tcl} # increment the number of points on a big circle circle c 0 0 50 50 discr 100 @@ -5252,7 +5252,7 @@ dmode c u @subsubsection occt_draw_6_11_2 nbiso Syntax: -~~~~{.php} +~~~~{.tcl} nbiso name [names...] nuiso nviso ~~~~ @@ -5261,7 +5261,7 @@ Changes the number of isoparametric curves displayed on a surface in the U and V **Example:** Let us display 35 meridians and 15 parallels on a sphere: -~~~~{.php} +~~~~{.tcl} sphere s 20 nbiso s 35 15 ~~~~ @@ -5269,7 +5269,7 @@ nbiso s 35 15 @subsubsection occt_draw_6_11_3 clpoles, shpoles Syntax: -~~~~{.php} +~~~~{.tcl} clpoles name shpoles name ~~~~ @@ -5280,7 +5280,7 @@ On bezier and bspline curves and surfaces, the control polygon is displayed by d Let us make a bezier curve and erase the poles -~~~~{.php} +~~~~{.tcl} beziercurve c 3 0 0 0 10 0 0 10 10 0 clpoles c ~~~~ @@ -5288,7 +5288,7 @@ clpoles c @subsubsection occt_draw_6_11_4 clknots, shknots Syntax: -~~~~{.php} +~~~~{.tcl} clknots name shknots name ~~~~ @@ -5296,7 +5296,7 @@ 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:** -~~~~{.php} +~~~~{.tcl} # 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 @@ -5357,7 +5357,7 @@ In Draw, shapes are displayed using isoparametric curves. There is color coding @subsubsection occt_draw_7_1_1 isos, discretisation Syntax: -~~~~{.php} +~~~~{.tcl} isos [name ...][nbisos] discretisation nbpoints ~~~~ @@ -5369,7 +5369,7 @@ The same number is used for the u and v directions. With no arguments, *isos* pr *discretisation* changes the default number of points used to display the curves. The default value is 30. **Example:** -~~~~{.php} +~~~~{.tcl} # Display only the edges (the wireframe) isos 0 ~~~~ @@ -5380,7 +5380,7 @@ isos 0 @subsubsection occt_draw_7_1_2 orientation, complement, invert, normals, range Syntax: -~~~~{.php} +~~~~{.tcl} orientation name [name ...] F/R/E/I complement name [name ...] invert name @@ -5395,7 +5395,7 @@ range name value value * **range** -- defines the length of a selected edge by defining the values of a starting point and an end point. **Example:** -~~~~{.php} +~~~~{.tcl} # to invert normals of a box box b 10 20 30 normals b 5 @@ -5417,7 +5417,7 @@ range e 0 1 @subsubsection occt_draw_7_1_3 explode, exwire, nbshapes Syntax: -~~~~{.php} +~~~~{.tcl} explode name [C/So/Sh/F/W/E/V] exwire name nbshapes name @@ -5432,7 +5432,7 @@ With name only, **explode** will extract the first sublevel of shapes: the shell **nbshapes** counts the number of shapes of each type in an entity. **Example:** -~~~~{.php} +~~~~{.tcl} # on a box box b 10 20 30 @@ -5468,7 +5468,7 @@ SHAPE : 34 @subsubsection occt_draw_7_1_4 emptycopy, add, compound Syntax: -~~~~{.php} +~~~~{.tcl} emptycopy [newname] name add name toname compound [name ...] compoundname @@ -5491,7 +5491,7 @@ compound [name ...] compoundname 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:** -~~~~{.php} +~~~~{.tcl} # a compound with three boxes box b1 0 0 0 1 1 1 box b2 3 0 0 1 1 1 @@ -5503,14 +5503,14 @@ compound b1 b2 b3 c @subsubsection occt_draw_7_1_5 compare Syntax: -~~~~{.php} +~~~~{.tcl} compare shape1 shape2 ~~~~ **compare** compares the two shapes *shape1* and *shape2* using the methods *TopoDS_Shape::IsSame()* and *TopoDS_Shape::IsEqual()*. **Example** -~~~~{.php} +~~~~{.tcl} box b1 1 1 1 copy b1 b2 compare b1 b2 @@ -5529,14 +5529,14 @@ compare b1 b2 @subsubsection occt_draw_7_1_6 issubshape Syntax: -~~~~{.php} +~~~~{.tcl} issubshape subshape shape ~~~~ **issubshape** checks if the shape *subshape* is sub-shape of the shape *shape* and gets its index in the shape. **Example** -~~~~{.php} +~~~~{.tcl} box b 1 1 1 explode b f issubshape b_2 b @@ -5559,35 +5559,35 @@ This group of commands is used to create topology from shapes and to extract sha @subsubsection occt_draw_7_2_1 vertex Syntax: -~~~~{.php} +~~~~{.tcl} 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:** -~~~~{.php} +~~~~{.tcl} vertex v1 10 20 30 ~~~~ @subsubsection occt_draw_7_2_1a mkpoint Syntax: -~~~~{.php} +~~~~{.tcl} mkpoint name vertex ~~~~ Creates a point from the coordinates of a given vertex. **Example:** -~~~~{.php} +~~~~{.tcl} mkpoint p v1 ~~~~ @subsubsection occt_draw_7_2_2 edge, mkedge, uisoedge, visoedge Syntax: -~~~~{.php} +~~~~{.tcl} edge name vertex1 vertex2 mkedge edge curve [surface] [pfirst plast] [vfirst [pfirst] vlast [plast]] uisoedge edge face u v1 v2 @@ -5598,7 +5598,7 @@ visoedge edge face v u1 u2 * **mkedge** generates edges from curves<.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 blocking 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:** -~~~~{.php} +~~~~{.tcl} # straight line edge vertex v1 10 0 0 vertex v2 10 10 0 @@ -5617,7 +5617,7 @@ mkedge e2 c * **visoedge** and **uisoedge** are commands that generate a *uiso* parameter edge or a *viso* parameter edge. **Example:** -~~~~{.php} +~~~~{.tcl} # to create an edge between v1 and v2 at point u # to create the example plane plane p @@ -5636,7 +5636,7 @@ uisoedge e p 0.5 0.20 0.8 @subsubsection occt_draw_7_2_3 wire, polyline, polyvertex Syntax: -~~~~{.php} +~~~~{.tcl} wire wirename e1/w1 [e2/w2 ...] polyline name x1 y1 z1 x2 y2 z2 ... polyvertex name v1 v2 ... @@ -5649,7 +5649,7 @@ polyvertex name v1 v2 ... **polyvertex** creates a polygonal wire from vertices. **Example:** -~~~~{.php} +~~~~{.tcl} # create two polygonal wires # glue them and define as a single wire polyline w1 0 0 0 10 0 0 10 10 0 @@ -5660,7 +5660,7 @@ wire w w1 w2 @subsubsection occt_draw_7_2_4 profile Syntax -~~~~{.php} +~~~~{.tcl} profile name [code values] [code values] ... ~~~~ @@ -5703,14 +5703,14 @@ The profile shape definition is the suffix; no suffix produces a face, *w* is a Code letters are not case-sensitive. **Example:** -~~~~{.php} +~~~~{.tcl} # to create a triangular 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:** -~~~~{.php} +~~~~{.tcl} # to create a contour using the different code possibilities @@ -5754,7 +5754,7 @@ 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 - @subsubsection occt_draw_7_2_5 bsplineprof Syntax: -~~~~{.php} +~~~~{.tcl} bsplineprof name [S face] [W WW] ~~~~ @@ -5768,7 +5768,7 @@ Builds a profile in the XY plane from digitizes. By default the profile is close The profile shape definition is the suffix; no suffix produces a face, **w** is a closed wire, **ww** is an open wire. **Example:** -~~~~{.php} +~~~~{.tcl} #to view the xy plane top #to create a 2d curve with the mouse @@ -5789,7 +5789,7 @@ bsplineprof res The offset distance defines the spacing and the positioning of the occurrences. Syntax: -~~~~{.php} +~~~~{.tcl} mkoffset result shape nboffset stepoffset [jointype(a/i) [alt]] ~~~~ Where: @@ -5802,7 +5802,7 @@ Where: **Example:** -~~~~{.php} +~~~~{.tcl} # Create a box and select a face box b 1 2 3 explode b f @@ -5821,7 +5821,7 @@ mkoffset r b_1 1 -0.4 **Note** that on a concave input contour for an interior step *mkoffset* command may produce several wires which will be contained in a single compound. **Example:** -~~~~{.php} +~~~~{.tcl} # to create the example contour profile p F 0 0 x 2 y 4 tt 1 1 tt 0 4 w # creates an incoherent interior offset @@ -5835,7 +5835,7 @@ mkoffset r p 1 -0.55 @subsubsection occt_draw_7_2_7 mkplane, mkface Syntax: -~~~~{.php} +~~~~{.tcl} mkplane name wire mkface name surface [ufirst ulast vfirst vlast] ~~~~ @@ -5845,7 +5845,7 @@ mkface name surface [ufirst ulast vfirst vlast] **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:** -~~~~{.php} +~~~~{.tcl} # 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 @@ -5859,7 +5859,7 @@ mkface g g @subsubsection occt_draw_7_2_8 mkcurve, mksurface Syntax: -~~~~{.php} +~~~~{.tcl} mkcurve curve edge mksurface name face ~~~~ @@ -5869,7 +5869,7 @@ mksurface name face **mksurface** creates a surface from a face. The surface will not be trimmed. **Example:** -~~~~{.php} +~~~~{.tcl} # make a line vertex v1 0 0 0 vertex v2 10 0 0 @@ -5880,14 +5880,14 @@ edge e v1 v2 Syntax: -~~~~{.php} +~~~~{.tcl} pcurve [name edgename] facename ~~~~ 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 counter-clockwise. To make curves visible, use a fitted 2d view. **Example:** -~~~~{.php} +~~~~{.tcl} # view the pcurves of a face plane p trim p p -1 1 -1 1 @@ -5900,7 +5900,7 @@ pcurve p @subsubsection occt_draw_7_2_10 chfi2d Syntax: -~~~~{.php} +~~~~{.tcl} chfi2d result face [edge1 edge2 (F radius/CDD d1 d2/CDA d ang) .... ~~~~ @@ -5918,7 +5918,7 @@ The distance is the length value from the edge between the two selected faces in Let us create a 2d fillet: -~~~~{.php} +~~~~{.tcl} top profile p x 2 y 2 x -2 chfi2d cfr p . . F 0.3 @@ -5930,7 +5930,7 @@ chfi2d cfr p . . F 0.3 Let us create a 2d chamfer using two distances: -~~~~{.php} +~~~~{.tcl} profile p x 2 y 2 x -2 chfi2d cfr p . . CDD 0.3 0.6 ==Pick an object @@ -5941,7 +5941,7 @@ chfi2d cfr p . . CDD 0.3 0.6 Let us create a 2d chamfer using a defined distance and angle -~~~~{.php} +~~~~{.tcl} top profile p x 2 y 2 x -2 chfi2d cfr p . . CDA 0.3 75 @@ -5954,7 +5954,7 @@ chfi2d cfr p . . CDA 0.3 75 @subsubsection occt_draw_7_2_11 nproject Syntax: -~~~~{.php} +~~~~{.tcl} nproject pj e1 e2 e3 ... surf -g -d [dmax] [Tol [continuity [maxdeg [maxseg]]] ~~~~ @@ -5962,7 +5962,7 @@ nproject pj e1 e2 e3 ... surf -g -d [dmax] [Tol Creates a shape projection which is normal to the target surface. **Example:** -~~~~{.php} +~~~~{.tcl} # create a curved surface line l 0 0 0 1 0 0 trim l l 0 2 @@ -6002,7 +6002,7 @@ Primitive commands make it possible to create simple shapes. They include: @subsubsection occt_draw_7_3_1 box, wedge Syntax: -~~~~{.php} +~~~~{.tcl} box name [x y z] dx dy dz wedge name dx dy dz ltx / xmin zmin xmax xmax ~~~~ @@ -6014,7 +6014,7 @@ wedge name dx dy dz ltx / xmin zmin xmax xmax 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:** -~~~~{.php} +~~~~{.tcl} # a box at the origin box b1 10 20 30 @@ -6034,7 +6034,7 @@ wedge w3 20 20 20 10 10 10 10 @subsubsection occt_draw_7_3_2 pcylinder, pcone, psphere, ptorus Syntax: -~~~~{.php} +~~~~{.tcl} pcylinder name [plane] radius height [angle] pcone name [plane] radius1 radius2 height [angle] pcone name [plane] radius1 radius2 height [angle] @@ -6053,7 +6053,7 @@ All these commands create solid blocks in the default coordinate system, using t **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:** -~~~~{.php} +~~~~{.tcl} # a can shape pcylinder cy 5 10 @@ -6070,14 +6070,14 @@ ptorus to 20 5 0 90 @subsubsection occt_draw_7_3_3 halfspace Syntax: -~~~~{.php} +~~~~{.tcl} 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:** -~~~~{.php} +~~~~{.tcl} box b 0 0 0 1 2 3 explode b f ==b_1 b_2 b_3 b_4 b_5 b_6 @@ -6099,7 +6099,7 @@ Sweeping creates shapes by sweeping out a shape along a defined path: @subsubsection occt_draw_7_4_1 prism Syntax: -~~~~{.php} +~~~~{.tcl} prism result base dx dy dz [Copy | Inf | SemiInf] ~~~~ @@ -6108,7 +6108,7 @@ Creates a new shape by sweeping a shape in a direction. Any shape can be swept: 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:** -~~~~{.php} +~~~~{.tcl} # 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 @@ -6117,14 +6117,14 @@ mkplane f f @subsubsection occt_draw_7_4_2 revol Syntax: -~~~~{.php} +~~~~{.tcl} revol result base x y z dx dy dz angle [Copy] ~~~~ 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:** -~~~~{.php} +~~~~{.tcl} # 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 @@ -6134,14 +6134,14 @@ revol s w 20 0 0 0 1 0 90 @subsubsection occt_draw_7_4_3 pipe Syntax: -~~~~{.php} +~~~~{.tcl} pipe name wire_spine Profile ~~~~ Creates a new shape by sweeping a shape known as the profile along a wire known as the spine. **Example:** -~~~~{.php} +~~~~{.tcl} # sweep a circle along a bezier curve to make a solid pipe @@ -6158,7 +6158,7 @@ pipe p spine profile @subsubsection occt_draw_7_4_4 mksweep, addsweep, setsweep, deletesweep, buildsweep, simulsweep Syntax: -~~~~{.php} +~~~~{.tcl} mksweep wire addsweep wire[vertex][-M][-C] [auxiilaryshape] deletesweep wire @@ -6186,7 +6186,7 @@ At least one other wire is used to define the sweep profile. * **buildsweep** -- creates the sweep using the arguments defined by all the commands. **Example:** -~~~~{.php} +~~~~{.tcl} #create a sweep based on a semi-circular wire using the Frenet algorithm #create a circular figure @@ -6210,7 +6210,7 @@ simulsweep w 3 @subsubsection occt_draw_7_4_5 thrusections Syntax: -~~~~{.php} +~~~~{.tcl} thrusections [-N] result issolid isruled wire1 wire2 [..wire..] ~~~~ @@ -6218,7 +6218,7 @@ thrusections [-N] result issolid isruled wire1 wire2 [..wire..] A bezier curve is generated between the vertices of each wire. The option *[-N]* means that no check is made on wires for direction. **Example:** -~~~~{.php} +~~~~{.tcl} #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 @@ -6243,14 +6243,14 @@ Transformations are applications of matrices. When the transformation is nondefo @subsubsection occt_draw_7_5_1 tcopy Syntax: -~~~~{.php} +~~~~{.tcl} tcopy name toname [name toname ...] ~~~~ Copies the structure of one shape, including the geometry, into another, newer shape. **Example:** -~~~~{.php} +~~~~{.tcl} # create an edge from a curve and copy it beziercurve c 3 0 0 0 10 0 0 20 10 0 mkedge e1 c @@ -6263,7 +6263,7 @@ ttranslate e2 0 5 0 @subsubsection occt_draw_7_5_2 tmove, treset Syntax: -~~~~{.php} +~~~~{.tcl} tmove name [name ...] shape reset name [name ...] ~~~~ @@ -6273,7 +6273,7 @@ reset name [name ...] **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:** -~~~~{.php} +~~~~{.tcl} # create two boxes box b1 10 10 10 box b2 20 0 0 10 10 10 @@ -6288,7 +6288,7 @@ reset b1 b2 @subsubsection occt_draw_7_5_3 ttranslate, trotate Syntax: -~~~~{.php} +~~~~{.tcl} ttranslate [name ...] dx dy dz trotate [name ...] x y z dx dy dz angle ~~~~ @@ -6299,7 +6299,7 @@ When creating multiple shapes, the same location is used for all the shapes. (Se Locations are very economic in the data structure because multiple occurrences of an object share the topological description. **Example:** -~~~~{.php} +~~~~{.tcl} # make rotated copies of a sphere in between two cylinders # create a file source toto.tcl # toto.tcl code: @@ -6324,7 +6324,7 @@ source toto.tcl @subsubsection occt_draw_7_5_4 tmirror, tscale Syntax: -~~~~{.php} +~~~~{.tcl} tmirror name x y z dx dy dz tscale name x y z scale ~~~~ @@ -6334,7 +6334,7 @@ tscale name x y z scale * **Tscale** applies a central homotopic mapping to a shape. **Example:** -~~~~{.php} +~~~~{.tcl} # mirror a portion of cylinder about the YZ plane pcylinder c1 10 10 270 copy c1 c2 @@ -6348,14 +6348,14 @@ tscale c1 0 0 0 0.5 **sewing** joins two or more shapes. Syntax: -~~~~{.php} +~~~~{.tcl} 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:** -~~~~{.php} +~~~~{.tcl} # create two adjacent boxes box b 0 0 0 1 2 3 box b2 0 2 0 1 2 3 @@ -6391,7 +6391,7 @@ Blending is the creation of a new shape by rounding edges to create a fillet. @subsubsection occt_draw_7_8_1 depouille Syntax: -~~~~{.php} +~~~~{.tcl} dep result shape dirx diry dirz face angle x y x dx dy dz [face angle...] ~~~~ @@ -6400,7 +6400,7 @@ 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:** -~~~~{.php} +~~~~{.tcl} # draft a face of a box box b 10 10 10 explode b f @@ -6412,7 +6412,7 @@ dep a b 0 0 1 b_2 10 0 10 0 1 0 5 @subsubsection occt_draw_7_8_2 chamf Syntax: -~~~~{.php} +~~~~{.tcl} chamf newname shape edge face S dist chamf newname shape edge face dist1 dist2 chamf newname shape edge face A dist angle @@ -6429,7 +6429,7 @@ Use the dot syntax to select the faces and edges. **Examples:** Let us create a chamfer based on equal distances from the edge (45 degree angle): -~~~~{.php} +~~~~{.tcl} # create a box box b 1 2 3 chamf ch b . . S 0.5 @@ -6440,7 +6440,7 @@ chamf ch b . . S 0.5 ~~~~ Let us create a chamfer based on different distances from the selected edge: -~~~~{.php} +~~~~{.tcl} box b 1 2 3 chamf ch b . . 0.3 0.4 ==Pick an object @@ -6451,7 +6451,7 @@ chamf ch b . . 0.3 0.4 Let us create a chamfer based on a distance from the edge and an angle: -~~~~{.php} +~~~~{.tcl} box b 1 2 3 chamf ch b . . A 0.4 30 ==Pick an object @@ -6463,14 +6463,14 @@ chamf ch b . . A 0.4 30 @subsubsection occt_draw_7_8_3 blend Syntax: -~~~~{.php} +~~~~{.tcl} blend result object rad1 ed1 rad2 ed2 ... [R/Q/P] ~~~~ 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:** -~~~~{.php} +~~~~{.tcl} # blend a box, click on an edge box b 20 20 20 blend b b 2 . @@ -6494,7 +6494,7 @@ blend b b 2 . @subsubsection occt_draw_7_8_4 bfuseblend Syntax: -~~~~{.php} +~~~~{.tcl} bfuseblend name shape1 shape2 radius [-d] ~~~~ @@ -6502,7 +6502,7 @@ Creates a boolean fusion of two shapes and then blends (fillets) the intersectio Option [-d] enables the Debugging mode in which the error messages, if any, will be printed. **Example:** -~~~~{.php} +~~~~{.tcl} # fuse-blend two boxes box b1 20 20 5 copy b1 b2 @@ -6513,7 +6513,7 @@ bfuseblend a b1 b2 1 @subsubsection occt_draw_7_8_4a bcutblend Syntax: -~~~~{.php} +~~~~{.tcl} bcutblend name shape1 shape2 radius [-d] ~~~~ @@ -6521,7 +6521,7 @@ Creates a boolean cut of two shapes and then blends (fillets) the intersection e Option [-d] enables the Debugging mode in which the error messages, if any, will be printed. **Example:** -~~~~{.php} +~~~~{.tcl} # cut-blend two boxes box b1 20 20 5 copy b1 b2 @@ -6532,7 +6532,7 @@ bcutblend a b1 b2 1 @subsubsection occt_draw_7_8_5 mkevol, updatevol, buildevol Syntax: -~~~~{.php} +~~~~{.tcl} mkevol result object (then use updatevol) [R/Q/P] updatevol edge u1 radius1 [u2 radius2 ...] buildevol @@ -6545,7 +6545,7 @@ These three commands work together to create fillets with evolving radii. * **buildevol** produces the result described previously in **mkevol** and **updatevol**. **Example:** -~~~~{.php} +~~~~{.tcl} # makes an evolved radius on a box box b 10 10 10 mkevol b b @@ -6581,7 +6581,7 @@ buildevol Draw command **removefeatures** is intended for performing @ref occt_modalg_defeaturing "3D Model Defeaturing", i.e. it performs the removal of the requested features from the shape. Syntax: -~~~~{.php} +~~~~{.tcl} removefeatures result shape f1 f2 ... [-nohist] [-parallel] ~~~~ Where: @@ -6609,7 +6609,7 @@ The command makes the shape periodic in the required directions with the require If trimming is given it trims the shape to fit the requested period. Syntax: -~~~~{.php} +~~~~{.tcl} makeperiodic result shape [-x/y/z period [-trim first]] ~~~~ Where: @@ -6626,7 +6626,7 @@ The result contains the all the repeated shapes glued together. The command should be called after **makeperiodic** command. Syntax: -~~~~{.php} +~~~~{.tcl} repeatshape result -x/y/z times ~~~~ @@ -6641,7 +6641,7 @@ All periodic twins should have the same geometry. The command should be called after **makeperiodic** command. Syntax: -~~~~{.php} +~~~~{.tcl} periodictwins twins shape ~~~~ Where: @@ -6670,7 +6670,7 @@ Draw module for @ref occt_modalg_makeconnected "making the touching same-dimensi The command makes the input touching shapes connected. Syntax: -~~~~{.php} +~~~~{.tcl} makeconnected result shape1 shape2 ... ~~~~ @@ -6684,7 +6684,7 @@ The command returns the materials located on the requested side of the shape. The command should be called after the shapes have been made connected, i.e. after the command **makeconnected**. Syntax: -~~~~{.php} +~~~~{.tcl} cmaterialson result +/- shape ~~~~ Where: @@ -6699,7 +6699,7 @@ The command makes the connected shape periodic in the required directions with t The command should be called after the shapes have been made connected, i.e. after the command **makeconnected**. Syntax: -~~~~{.php} +~~~~{.tcl} cmakeperiodic result [-x/y/z period [-trim first]] ~~~~ Where: @@ -6715,7 +6715,7 @@ The command repeats the connected periodic shape in the required periodic direct The command should be called after the shapes have been made connected and periodic, i.e. after the commands **makeconnected** and **cmakeperiodic**. Syntax: -~~~~{.php} +~~~~{.tcl} crepeatshape result -x/y/z times ~~~~ Where: @@ -6729,7 +6729,7 @@ The command returns all periodic twins for the shape. The command should be called after the shapes have been made connected and periodic, i.e. after the commands **makeconnected** and **cmakeperiodic**. Syntax: -~~~~{.php} +~~~~{.tcl} cperiodictwins twins shape ~~~~ @@ -6744,7 +6744,7 @@ The command should be called after the shapes have been made connected, periodic Otherwise the command will have no effect. Syntax: -~~~~{.php} +~~~~{.tcl} cclearrepetitions [result] ~~~~ @@ -6766,7 +6766,7 @@ Analysis of shapes includes commands to compute length, area, volumes and inerti @subsubsection occt_draw_7_9_1 lprops, sprops, vprops Syntax: -~~~~{.php} +~~~~{.tcl} lprops shape [x y z] [-skip] [-full] [-tri] sprops shape [epsilon] [c[losed]] [x y z] [-skip] [-full] [-tri] vprops shape [epsilon] [c[losed]] [x y z] [-skip] [-full] [-tri] @@ -6790,7 +6790,7 @@ If epsilon is given, exact geometry (curves, surfaces) are used for calculations 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:** -~~~~{.php} +~~~~{.tcl} # volume of a cylinder pcylinder c 10 20 vprops c @@ -6819,7 +6819,7 @@ I.Z = 314159.265357595 @subsubsection occt_draw_7_9_2 bounding Syntax: -~~~~{.php} +~~~~{.tcl} bounding {-s shape | -c xmin ymin zmin xmax ymax zmax} [-obb] [-shape name] [-dump] [-notriangulation] [-perfmeter name NbIters] [-save xmin ymin zmin xmax ymax zmax] [-nodraw] [-optimal] [-exttoler] ~~~~ @@ -6831,7 +6831,7 @@ Generally, bounding boxes can be divided into two main types: Detailed information about this command is available in DRAW help-system (enter "help bounding" in DRAW application). **Example 1: Creation of AABB with given corners** -~~~~{.php} +~~~~{.tcl} bounding -c 50 100 30 180 200 100 -shape result # look at the box vdisplay result @@ -6840,7 +6840,7 @@ vsetdispmode 1 ~~~~ **Example 2: Compare AABB and OBB** -~~~~{.php} +~~~~{.tcl} # Create a torus and rotate it ptorus t 20 5 trotate t 5 10 15 1 1 1 28 @@ -6883,7 +6883,7 @@ dval (x2-x1)*(y2-y1)*(z2-z1) The same result is obtained. -~~~~{.php} +~~~~{.tcl} # Create OBB from the torus bounding -s t -shape ro -dump -obb ==Oriented bounding box @@ -6905,14 +6905,14 @@ As we can see, the volume of OBB is significantly less than the volume of AABB. @subsubsection occt_draw_7_9_2a isbbinterf Syntax: -~~~~{.php} +~~~~{.tcl} isbbinterf shape1 shape2 [-o] ~~~~ Checks whether the bounding boxes created from the given shapes are interfered. If "-o"-option is switched on then the oriented boxes will be checked. Otherwise, axis-aligned boxes will be checked. **Example 1: Not interfered AABB** -~~~~{.php} +~~~~{.tcl} box b1 100 60 140 20 10 80 box b2 210 200 80 120 60 90 isbbinterf b1 b2 @@ -6920,7 +6920,7 @@ isbbinterf b1 b2 ~~~~ **Example 2: Interfered AABB** -~~~~{.php} +~~~~{.tcl} box b1 300 300 300 box b2 100 100 100 50 50 50 isbbinterf b1 b2 @@ -6928,7 +6928,7 @@ isbbinterf b1 b2 ~~~~ **Example 3: Not interfered OBB** -~~~~{.php} +~~~~{.tcl} box b1 100 150 200 copy b1 b2 trotate b1 -150 -150 -150 1 2 3 -40 @@ -6940,7 +6940,7 @@ isbbinterf b1 b2 -o ~~~~ **Example 4: Interfered OBB** -~~~~{.php} +~~~~{.tcl} box b1 100 150 200 copy b1 b2 trotate b1 -50 -50 -50 1 1 1 -40 @@ -6954,14 +6954,14 @@ isbbinterf b1 b2 -o @subsubsection occt_draw_7_9_3 distmini Syntax: -~~~~{.php} +~~~~{.tcl} distmini name Shape1 Shape2 ~~~~ 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 in red and the results are listed in the shell window. The *distmini* lines are considered as shapes which have a value v. **Example:** -~~~~{.php} +~~~~{.tcl} box b 0 0 0 10 20 30 box b2 30 30 0 10 20 30 distmini d1 b b2 @@ -6992,7 +6992,7 @@ are: @subsubsection occt_draw_7_9_4 xdistef, xdistcs, xdistcc, xdistc2dc2dss, xdistcc2ds Syntax: -~~~~{.php} +~~~~{.tcl} xdistef edge face xdistcs curve surface firstParam lastParam [NumberOfSamplePoints] xdistcc curve1 curve2 startParam finishParam [NumberOfSamplePoints] @@ -7010,7 +7010,7 @@ Commands with prefix *xdist* allow checking the distance between two objects on * **xdistc2dc2dss** -- distance between two 2d curves on surface. **Examples** -~~~~{.php} +~~~~{.tcl} bopcurves b1 b2 -2d mksurf s1 b1 mksurf s2 b2 @@ -7022,7 +7022,7 @@ xdistc2dc2dss c2d1_1 c2d2_1 s1 s2 0 1 1000 @subsubsection occt_draw_7_9_5 checkshape Syntax: -~~~~{.php} +~~~~{.tcl} checkshape [-top] shape [result] [-short] [-parallel] [-exact] ~~~~ @@ -7037,7 +7037,7 @@ Where: **checkshape** examines the selected object for topological and geometric coherence. The object should be a three dimensional shape. **Example:** -~~~~{.php} +~~~~{.tcl} # checkshape returns a comment valid or invalid box b1 0 0 0 1 1 1 checkshape b1 @@ -7048,7 +7048,7 @@ this shape seems to be valid @subsubsection occt_draw_7_9_6 tolsphere Syntax: -~~~~{.php} +~~~~{.tcl} tolsphere shape ~~~~ @@ -7058,7 +7058,7 @@ Where: **tolsphere** shows vertex tolerances by drawing spheres around each vertex in the shape. Each sphere is assigned a name of the shape with suffix "_vXXX", where XXX is the number of the vertex in the shape. **Example:** -~~~~{.php} +~~~~{.tcl} # tolsphere returns all names of created spheres. box b1 0 0 0 1 1 1 settolerance b1 0.05 @@ -7070,7 +7070,7 @@ b1_v1 b1_v2 b1_v3 b1_v4 b1_v5 b1_v6 b1_v7 b1_v8 @subsubsection occt_draw_7_9_7 validrange Syntax: -~~~~{.php} +~~~~{.tcl} validrange edge [(out) u1 u2] ~~~~ @@ -7081,7 +7081,7 @@ Where: **validrange** computes valid range of the edge. If *u1* and *u2* are not given, it returns the first and the last parameters. Otherwise, it sets variables *u1* and *u2*. **Example:** -~~~~{.php} +~~~~{.tcl} circle c 0 0 0 10 mkedge e c mkedge e c 0 pi @@ -7105,14 +7105,14 @@ Surface creation commands include surfaces created from boundaries and from spac @subsubsection occt_draw_7_10_1 gplate, Syntax: -~~~~{.php} +~~~~{.tcl} gplate result nbrcurfront nbrpntconst [SurfInit] [edge 0] [edge tang (1:G1;2:G2) surf]...[point] [u v tang (1:G1;2:G2) surf] ... ~~~~ Creates a surface from a defined boundary. The boundary can be defined using edges, points, or other surfaces. **Example:** -~~~~{.php} +~~~~{.tcl} plane p trim p p -1 3 -1 3 mkface p p @@ -7171,7 +7171,7 @@ Criterium error : 3.43709808053967e-05 @subsubsection occt_draw_7_10_2 filling, fillingparam Syntax: -~~~~{.php} +~~~~{.tcl} filling result nbB nbC nbP [SurfInit] [edge][face]order... edge[face]order... point/u v face order... ~~~~ @@ -7196,7 +7196,7 @@ The options are: * -a maxdeg maxseg : Approximation option **Example:** -~~~~{.php} +~~~~{.tcl} # to create four curved survaces and a point plane p trim p p -1 3 -1 3 @@ -7250,7 +7250,7 @@ Complex topology is the group of commands that modify the topology of shapes. Th @subsubsection occt_draw_7_11_1 offsetshape, offsetcompshape Syntax: -~~~~{.php} +~~~~{.tcl} offsetshape r shape offset [tol] [face ...] offsetcompshape r shape offset [face ...] ~~~~ @@ -7264,7 +7264,7 @@ In case of complex shapes, where intersections can occur from non-adjacent edges The opening between the object interior and exterior is defined by the argument face or faces. **Example:** -~~~~{.php} +~~~~{.tcl} box b1 10 20 30 explode b1 f == b1_1 b1_2 b1_3 b1_4 b1_5 b1_6 @@ -7274,7 +7274,7 @@ offsetcompshape r b1 -1 b1_3 @subsubsection occt_draw_7_11_2 featprism, featdprism, featrevol, featlf, featrf Syntax: -~~~~{.php} +~~~~{.tcl} 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) @@ -7304,7 +7304,7 @@ All the features are created from a set of arguments which are defined when you Let us create a feature prism with a draft angle and a normal direction : -~~~~{.php} +~~~~{.tcl} # 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 @@ -7322,7 +7322,7 @@ BRepFeat_Form::GlobalPerform () Let us create a feature prism with circular direction : -~~~~{.php} +~~~~{.tcl} # 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 @@ -7340,7 +7340,7 @@ BRepFeat_Form::GlobalPerform () Let us create a slot using the linear feature : -~~~~{.php} +~~~~{.tcl} #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 @@ -7365,7 +7365,7 @@ featperform lf result Let us create a rib using the revolution feature : -~~~~{.php} +~~~~{.tcl} #create the base model using the multi viewer mu4 pcylinder c1 3 5 @@ -7383,7 +7383,7 @@ featperform rf result @subsubsection occt_draw_7_11_3 draft Syntax: -~~~~{.php} +~~~~{.tcl} draft result shape dirx diry dirz angle shape/surf/length [-IN/-OUT] [Ri/Ro] [-Internal] ~~~~ @@ -7400,7 +7400,7 @@ Computes a draft angle surface from a wire. The surface is determined by the dra **Note** that 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:** -~~~~{.php} +~~~~{.tcl} # to create a simple profile profile p F 0 0 x 2 y 4 tt 0 4 w # creates a draft with rounded angles @@ -7414,14 +7414,14 @@ draft res p 0 0 1 3 1 -Ro @subsubsection occt_draw_7_11_4 deform Syntax: -~~~~{.php} +~~~~{.tcl} deform newname name CoeffX CoeffY CoeffZ ~~~~ Modifies the shape using the x, y, and z coefficients. You can reduce or magnify the shape in the x,y, and z directions. **Example:** -~~~~{.php} +~~~~{.tcl} pcylinder c 20 20 deform a c 1 3 5 # the conversion to bspline is followed by the @@ -7433,7 +7433,7 @@ deformation Syntax: -~~~~{.php} +~~~~{.tcl} nurbsconvert result name [result name] ~~~~ @@ -7447,7 +7447,7 @@ The conversion can be necessary when transferring shape data to other applicatio **edgestofaces** - The command allows building planar faces from the planar edges randomly located in 3D space. It has the following syntax: -~~~~{.php} +~~~~{.tcl} edgestofaces r_faces edges [-a AngTol -s Shared(0/1)] ~~~~ Options: @@ -7470,7 +7470,7 @@ Draw module for @ref occt_modalg_hist "History Information support" includes the By default it is TRUE, i.e. the history is filled and saved. Syntax: -~~~~{.php} +~~~~{.tcl} setfillhistory : Controls the history collection by the algorithms and its saving into the session after algorithm is done. Usage: setfillhistory [flag] w/o arguments prints the current state of the option; @@ -7479,7 +7479,7 @@ setfillhistory : Controls the history collection by the algorithms and its savi ~~~~ Example: -~~~~{.php} +~~~~{.tcl} box b1 10 10 10 box b2 10 10 10 setfillhistory 0 @@ -7502,7 +7502,7 @@ dump h *savehistory* command saves the history from the session into a drawable object with the given name. Syntax: -~~~~{.php} +~~~~{.tcl} savehistory : savehistory name ~~~~ @@ -7510,7 +7510,7 @@ If the history of shape modifications performed during an operation is needed, t If another operation supporting history will be performed before the history of the first operation is saved it will be overwritten with the new history. Example: -~~~~{.php} +~~~~{.tcl} box b1 10 10 10 box b2 5 0 0 10 10 15 bfuse r b1 b2 @@ -7538,12 +7538,12 @@ dump usd_hist *isdeleted* command checks if the given shape has been deleted in the given history. Syntax: -~~~~{.php} +~~~~{.tcl} isdeleted : isdeleted history shape ~~~~ Example: -~~~~{.php} +~~~~{.tcl} box b1 4 4 4 2 2 2 box b2 10 10 10 bcommon r b1 b2 @@ -7561,12 +7561,12 @@ foreach s [join [list [explode b2 v] [explode b2 e] [explode b2 f] ] ] { *modified* command returns the shapes Modified from the given shape in the given history. All modified shapes are put into a compound. If the shape has not been modified, the resulting compound will be empty. Note that if the shape has been modified into a single shape only, it will be returned without enclosure into the compound. Syntax: -~~~~{.php} +~~~~{.tcl} modified : modified modified_shapes history shape ~~~~ Example: -~~~~{.php} +~~~~{.tcl} box b 10 10 10 explode b e fillet r b 2 b_1 @@ -7584,12 +7584,12 @@ modified m5 fillet_hist b_5 *generated* command returns the shapes Generated from the given shape in the given history. All generated shapes are put into a compound. If no shapes have been generated from the shape, the resulting compound will be empty. Note that; if the shape has generated a single shape only, it will be returned without enclosure into the compound. Syntax: -~~~~{.php} +~~~~{.tcl} generated : generated generated_shapes history shape ~~~~ Example: -~~~~{.php} +~~~~{.tcl} polyline w1 0 0 0 10 0 0 10 10 0 polyline w2 5 1 10 9 1 10 9 5 10 @@ -7617,12 +7617,12 @@ compare g12 g22 Draw History mechanism allows fast and easy enabling of the Draw history support for the OCCT algorithms supporting standard history methods. To enable History commands for the algorithm it is necessary to save the history of the algorithm into the session. For that, it is necessary to put the following code into the command implementation just after the command is done: -~~~~{.php} +~~~~{.tcl} BRepTest_Objects::SetHistory(ListOfArguments, Algorithm); ~~~~ Here is the example of how it is done in the command performing Split operation (see implementation of the *bapisplit* command): -~~~~{.php} +~~~~{.tcl} BRepAlgoAPI_Splitter aSplitter; // setting arguments aSplitter.SetArguments(BOPTest_Objects::Shapes()); @@ -7675,7 +7675,7 @@ These commands allow intersecting the shapes only once for building all types of It may be very useful as the intersection part is usually most time-consuming part of the operation. Syntax: -~~~~{.php} +~~~~{.tcl} bop shape1 shape2 bopcommon result bopfuse result @@ -7686,7 +7686,7 @@ boptuc result **Example:** Let's produce all four boolean operations on a box and a cylinder performing intersection only once: -~~~~{.php} +~~~~{.tcl} box b 0 -10 5 20 20 10 pcylinder c 5 20 @@ -7716,15 +7716,15 @@ These commands also perform Boolean operations on two shapes. These are the shor Each of these commands performs both intersection and building the result and may be useful if you need only the result of a single boolean operation. Syntax: -~~~~{.php} +~~~~{.tcl} bcommon result shape1 shape2 bfuse result shape1 shape2 bcut result shape1 shape2 btuc result shape1 shape2 ~~~~ -**bection** command has some additional options for faces intersection: -~~~~{.php} +**bsection** command has some additional options for faces intersection: +~~~~{.tcl} bsection result shape1 shape2 [-n2d/-n2d1/-n2d2] [-na] ~~~~ @@ -7772,7 +7772,7 @@ The command **bfillds** performs intersection of the arguments (**Objects** and The command **bbop** is used for building the result of Boolean Operation. It has to be used after **bfillds** command. Syntax: -~~~~{.php} +~~~~{.tcl} bbop result iOp ~~~~ @@ -7787,7 +7787,7 @@ iOp - type of Boolean Operation. It could have the following values: **Example** -~~~~{.php} +~~~~{.tcl} box b1 10 10 10 box b2 5 5 5 10 10 10 box b3 -5 -5 -5 10 10 10 @@ -7815,11 +7815,11 @@ The command **bbuild** is used for building the result of General Fuse Operation General Fuse operation does not make the difference between Objects and Tools considering both as objects. Syntax: -~~~~{.php} +~~~~{.tcl} bbuild result ~~~~ **Example** -~~~~{.php} +~~~~{.tcl} box b1 10 10 10 box b2 5 5 5 10 10 10 box b3 -5 -5 -5 10 10 10 @@ -7843,7 +7843,7 @@ Split operation splits the **Objects** by the **Tools**. The command **bsplit** is used for building the result of Split operation. It has to be used after **bfillds** command. **Example** -~~~~{.php} +~~~~{.tcl} box b1 10 10 10 box b2 5 5 5 10 10 10 box b3 -5 -5 -5 10 10 10 @@ -7870,7 +7870,7 @@ The command has the following features: * History information for solids will be lost. Syntax: -~~~~{.php} +~~~~{.tcl} buildbop result -o s1 [s2 ...] -t s3 [s4 ...] -op operation (common/fuse/cut/tuc) ~~~~ Where: @@ -7880,7 +7880,7 @@ operation - type of boolean operation **Example** -~~~~{.php} +~~~~{.tcl} box b1 10 10 10 box b2 5 5 5 10 10 10 box b3 -5 -5 -5 10 10 10 @@ -7938,7 +7938,7 @@ These commands have the same syntax as the analogical commands described above. The algorithms in Boolean component have a wide range of options. To see the current state of all option the command **boptions** should be used. It has the following syntax: -~~~~{.php} +~~~~{.tcl} boptions [-default] -default - allows to set all options to default state. @@ -7951,7 +7951,7 @@ To have an effect the options should be set before the operation (before *bfilld **brunparallel** command enables/disables the parallel processing mode of the operation. Syntax: -~~~~{.php} +~~~~{.tcl} brunparallel flag ~~~~ Where: @@ -7967,7 +7967,7 @@ The command is applicable for all commands in the component. **bnondestructive** command enables/disables the safe processing mode in which the input arguments are protected from modification. Syntax: -~~~~{.php} +~~~~{.tcl} bnondestructive flag ~~~~ Where: @@ -7983,7 +7983,7 @@ The command is applicable for all commands in the component. **bfuzzyvalue** command sets the additional tolerance for operations. Syntax: -~~~~{.php} +~~~~{.tcl} bfuzzyvalue value ~~~~ @@ -7994,7 +7994,7 @@ The command is applicable for all commands in the component. **bglue** command sets the gluing mode for the BOP algorithms. Syntax: -~~~~{.php} +~~~~{.tcl} bglue 0/1/2 ~~~~ Where: @@ -8010,7 +8010,7 @@ The command is applicable for all commands in the component. **bcheckinverted** command enables/disables the check of the input solids on inverted status in BOP algorithms. Syntax: -~~~~{.php} +~~~~{.tcl} bcheckinverted 0 (off) / 1 (on) ~~~~ @@ -8021,7 +8021,7 @@ The command is applicable for all commands in the component. **buseobb** command enables/disables the usage of OBB in BOP algorithms. Syntax: -~~~~{.php} +~~~~{.tcl} buseobb 0 (off) / 1 (on) ~~~~ @@ -8032,7 +8032,7 @@ The command is applicable for all commands in the component. **bsimplify** command enables/disables the result simplification after BOP. The command is applicable only to the API variants of GF, BOP and Split operations. Syntax: -~~~~{.php} +~~~~{.tcl} bsimplify [-e 0/1] [-f 0/1] [-a tol] ~~~~ Where: @@ -8046,7 +8046,7 @@ Where: **bdrawwarnshapes** command enables/disables drawing of warning shapes of BOP algorithms. Syntax: -~~~~{.php} +~~~~{.tcl} bdrawwarnshapes 0 (do not draw) / 1 (draw warning shapes) ~~~~ @@ -8060,7 +8060,7 @@ The following commands are analyzing the given shape on the validity of Boolean @subsubsection occt_draw_bop_check_1 bopcheck Syntax: -~~~~{.php} +~~~~{.tcl} bopcheck shape [level of check: 0 - 9] ~~~~ @@ -8077,7 +8077,7 @@ It checks the given shape for self-interference. The optional level of check all * 9 - V/V, V/E, E/E, V/F, E/F, F/F, V/S, E/S, F/S and S/S - all interferences (Default value) **Example:** -~~~~{.php} +~~~~{.tcl} box b1 10 10 10 box b2 3 3 3 4 4 4 compound b1 b2 c @@ -8091,7 +8091,7 @@ In this example one box is completely included into other box. So the output sho @subsubsection occt_draw_bop_check_2 bopargcheck **bopargcheck** syntax: -~~~~{.php} +~~~~{.tcl} bopargcheck Shape1 [[Shape2] [-F/O/C/T/S/U] [/R|F|T|V|E|I|P|C|S]] [#BF] - @@ -8128,7 +8128,7 @@ As you can see *bopargcheck* performs more extended check of the given shapes th **Example:** Let's make an edge with big vertices: -~~~~{.php} +~~~~{.tcl} vertex v1 0 0 0 settolerance v1 0.5 vertex v2 1 0 0 @@ -8140,7 +8140,7 @@ tolsphere e bopargcheck e ~~~~ Here is the output of this command: -~~~~{.php} +~~~~{.tcl} Made faulty shape: s1si_1 Made faulty shape: s1se_1 Faulties for FIRST shape found : 2 @@ -8173,7 +8173,7 @@ All commands listed below are available when the Intersection Part of the algor **bopds** Syntax: -~~~~{.php} +~~~~{.tcl} bopds -v [e, f] ~~~~ @@ -8188,7 +8188,7 @@ Displays: Prints contents of the DS. Example: -~~~~{.php} +~~~~{.tcl} Draw[28]> bopdsdump *** DS *** Ranges:2 number of ranges @@ -8215,7 +8215,7 @@ Example: **bopindex** Syntax: -~~~~{.php} +~~~~{.tcl} bopindex S ~~~~ Prints DS index of shape *S*. @@ -8224,7 +8224,7 @@ Prints DS index of shape *S*. **bopiterator** Syntax: -~~~~{.php} +~~~~{.tcl} bopiterator [t1 t2] ~~~~ @@ -8236,7 +8236,7 @@ Prints pairs of DS indices of source shapes that are intersected in terms of bou * *4* -- face. Example: -~~~~{.php} +~~~~{.tcl} Draw[104]> bopiterator 6 4 EF: ( z58 z12 ) EF: ( z17 z56 ) @@ -8253,7 +8253,7 @@ Example: **bopinterf** Syntax: -~~~~{.php} +~~~~{.tcl} bopinterf t ~~~~ @@ -8265,7 +8265,7 @@ Prints contents of *myInterfTB* for the type of interference *t*: * *t=4* : edge/face. Example: -~~~~{.php} +~~~~{.tcl} Draw[108]> bopinterf 4 EF: (58, 12, 68), (17, 56, 69), (19, 64, 70), (45, 26, 71), (29, 36, 72), (38, 32, 73), 6 EF found. ~~~~ @@ -8281,7 +8281,7 @@ Here, record (58, 12, 68) means: Displays split edges. Example: -~~~~{.php} +~~~~{.tcl} Draw[33]> bopsp edge 58 : z58_74 z58_75 edge 17 : z17_76 z17_77 @@ -8297,7 +8297,7 @@ Example: **bopcb** Syntax: -~~~~{.php} +~~~~{.tcl} bopcb [nE] ~~~~ @@ -8306,7 +8306,7 @@ Prints Common Blocks for: * the source edge with the specified index *nE*. Example: -~~~~{.php} +~~~~{.tcl} Draw[43]> bopcb 17 -- CB: PB:{ E:71 orE:17 Pave1: { 68 3.000 } Pave2: { 18 10.000 } } @@ -8326,13 +8326,13 @@ This command dumps common blocks for the source edge with index 17. **bopfin** Syntax: -~~~~{.php} +~~~~{.tcl} bopfin nF ~~~~ Prints Face Info about IN-parts for the face with DS index *nF*. Example: -~~~~{.php} +~~~~{.tcl} Draw[47]> bopfin 36 pave blocks In: PB:{ E:71 orE:17 Pave1: { 68 3.000 } Pave2: { 18 10.000 } } @@ -8348,13 +8348,13 @@ Example: **bopfon** Syntax: -~~~~{.php} +~~~~{.tcl} bopfon nF ~~~~ Print Face Info about ON-parts for the face with DS index *nF*. Example: -~~~~{.php} +~~~~{.tcl} Draw[58]> bopfon 36 pave blocks On: PB:{ E:72 orE:38 Pave1: { 69 0.000 } Pave2: { 68 10.000 } } @@ -8371,14 +8371,14 @@ Example: **bopwho** Syntax: -~~~~{.php} +~~~~{.tcl} bopwho nS ~~~~ Prints the information about the shape with DS index *nF*. Example: -~~~~{.php} +~~~~{.tcl} Draw[116]> bopwho 5 rank: 0 ~~~~ @@ -8386,7 +8386,7 @@ Example: * *rank: 0* -- means that shape 5 results from the Argument with index 0. Example: -~~~~{.php} +~~~~{.tcl} Draw[118]> bopwho 68 the shape is new EF: (58, 12), @@ -8402,7 +8402,7 @@ This means that shape 68 is a result of the following interferences: **bopnews** Syntax: -~~~~{.php} +~~~~{.tcl} bopnews -v [-e] ~~~~ @@ -8416,7 +8416,7 @@ The commands listed below are available when the Building Part of the algorithm **bopim** Syntax: -~~~~{.php} +~~~~{.tcl} bopim S ~~~~ Shows the compound of shapes that are images of shape *S* from the argument. @@ -8446,7 +8446,7 @@ The model and the map are used for working with most of DE commands. @subsubsection occt_draw_8_1_1 igesread Syntax: -~~~~{.php} +~~~~{.tcl} igesread [] ~~~~ @@ -8471,7 +8471,7 @@ The second parameter of this command defines the name of the loaded shape. If se See also the detailed description of
Selecting IGES entities. **Example:** -~~~~{.php} +~~~~{.tcl} # translation all roots from file igesread /disk01/files/model.igs a * ~~~~ @@ -8479,7 +8479,7 @@ igesread /disk01/files/model.igs a * @subsubsection occt_draw_8_1_2 tplosttrim Syntax: -~~~~{.php} +~~~~{.tcl} tplosttrim [] ~~~~ @@ -8488,21 +8488,21 @@ It outputs the rank and numbers of faces that lost their trims and their numbers Optional parameter \ can be *0TrimmedSurface, BoundedSurface* or *Face* to specify the only type of IGES faces. **Example:** -~~~~{.php} +~~~~{.tcl} tplosttrim TrimmedSurface ~~~~ @subsubsection occt_draw_8_1_3 brepiges Syntax: -~~~~{.php} +~~~~{.tcl} brepiges ~~~~ Writes an OCCT shape to an IGES file. **Example:** -~~~~{.php} +~~~~{.tcl} # write shape with name aa to IGES file brepiges aa /disk1/tmp/aaa.igs == unit (write) : MM @@ -8522,7 +8522,7 @@ These commands are used during the translation of STEP models. @subsubsection occt_draw_8_2_1 stepread Syntax: -~~~~{.php} +~~~~{.tcl} stepread file_name result_shape_name [selection] ~~~~ @@ -8544,7 +8544,7 @@ The second parameter of this command defines the name of the loaded shape. If se See also the detailed description of Selecting STEP entities. **Example:** -~~~~{.php} +~~~~{.tcl} # translation all roots from file stepread /disk01/files/model.stp a * ~~~~ @@ -8552,7 +8552,7 @@ stepread /disk01/files/model.stp a * @subsubsection occt_draw_8_2_2 stepwrite Syntax: -~~~~{.php} +~~~~{.tcl} stepwrite mode shape_name file_name ~~~~ @@ -8571,8 +8571,8 @@ For further information see Writ Let us write shape *a* to a STEP file in mode *0*. -~~~~{.php} -stepwrite 0 a /disk1/tmp/aaa.igs +~~~~{.tcl} +stepwrite 0 a /disk1/tmp/aaa.stp ~~~~ @@ -8583,7 +8583,7 @@ These are auxiliary commands used for the analysis of result of translation of I @subsubsection occt_draw_8_3_1 count Syntax: -~~~~{.php} +~~~~{.tcl} count [] ~~~~ @@ -8594,17 +8594,17 @@ The optional selection argument, if specified, defines a subset of entities, whi | Counter | Operation | | :-------- | :-------- | | xst-types | Calculates how many entities of each OCCT type exist | -| step214-types | Calculates how many entities of each STEP type exist | +| step-types | Calculates how many entities of each STEP type exist | **Example:** -~~~~{.php} +~~~~{.tcl} count xst-types ~~~~ @subsubsection occt_draw_8_3_2 data Syntax: -~~~~{.php} +~~~~{.tcl} data ~~~~ @@ -8612,7 +8612,7 @@ Obtains general statistics on the loaded data. The information printed by this command depends on the symbol specified. **Example:** -~~~~{.php} +~~~~{.tcl} # print full information about warnings and fails data c ~~~~ @@ -8631,21 +8631,21 @@ data c @subsubsection occt_draw_8_3_3 elabel Syntax: -~~~~{.php} +~~~~{.tcl} elabel ~~~~ 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:** -~~~~{.php} +~~~~{.tcl} elabel 84 ~~~~ @subsubsection occt_draw_8_3_4 entity Syntax: -~~~~{.php} +~~~~{.tcl} entity <#(D)>_or_ ~~~~ @@ -8654,7 +8654,7 @@ Entity can be determined by its number or label. \ has range [0-6]. You can get more information about this level using this command without parameters. **Example:** -~~~~{.php} +~~~~{.tcl} # full information for STEP entity with label 84 entity #84 6 ~~~~ @@ -8662,14 +8662,14 @@ entity #84 6 @subsubsection occt_draw_8_3_5 enum Syntax: -~~~~{.php} +~~~~{.tcl} enum <#(D)> ~~~~ Prints a number for the entity with a given label. **Example:** -~~~~{.php} +~~~~{.tcl} # give a number for IGES entity with label 21 enum D21 ~~~~ @@ -8677,35 +8677,35 @@ enum D21 @subsubsection occt_draw_8_3_6 estatus Syntax: -~~~~{.php} +~~~~{.tcl} estatus <#(D)>_or_ ~~~~ The list of entities referenced by a given entity and the list of entities referencing to it can be obtained by this command. **Example:** -~~~~{.php} +~~~~{.tcl} estatus #315 ~~~~ @subsubsection occt_draw_8_3_7 fromshape Syntax: -~~~~{.php} +~~~~{.tcl} fromshape ~~~~ Gives 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:** -~~~~{.php} +~~~~{.tcl} fromshape a_1_23 ~~~~ @subsubsection occt_draw_8_3_8 givecount Syntax: -~~~~{.php} +~~~~{.tcl} givecount [] ~~~~ @@ -8714,14 +8714,14 @@ Prints a number of loaded entities defined by the selection argument. Possible values of \ you can find in the “IGES FORMAT Users’s Guide”. **Example:** -~~~~{.php} +~~~~{.tcl} givecount xst-model-roots ~~~~ @subsubsection occt_draw_8_3_9 givelist Syntax: -~~~~{.php} +~~~~{.tcl} givelist ~~~~ @@ -8736,7 +8736,7 @@ Prints a list of a subset of loaded entities defined by the selection argument: **Example:** -~~~~{.php} +~~~~{.tcl} # give a list of all entities of the model givelist xst-model-all ~~~~ @@ -8755,14 +8755,14 @@ Optional \ argument, if specified, defines a subset of entiti | iges-levels | Calculates how many entities lie in different IGES levels | **Example:** -~~~~{.php} +~~~~{.tcl} listcount xst-types ~~~~ @subsubsection occt_draw_8_3_11 listitems Syntax: -~~~~{.php} +~~~~{.tcl} listitems ~~~~ @@ -8772,7 +8772,7 @@ This command prints a list of objects (counters, selections etc.) defined in the @subsubsection occt_draw_8_3_12 listtypes Syntax: -~~~~{.php} +~~~~{.tcl} listtypes [ ...] ~~~~ @@ -8782,7 +8782,7 @@ Gives a list of entity types which were encountered in the last loaded file (wit @subsubsection occt_draw_8_3_13 newmodel Syntax: -~~~~{.php} +~~~~{.tcl} newmodel ~~~~ @@ -8792,7 +8792,7 @@ Clears the current model. @subsubsection occt_draw_8_3_14 param Syntax: -~~~~{.php} +~~~~{.tcl} param [] [] ~~~~ @@ -8804,28 +8804,28 @@ Command with \ (without ) gives us the current Let us get the information about possible schemes for writing STEP file : -~~~~{.php} +~~~~{.tcl} param write.step.schema ~~~~ @subsubsection occt_draw_8_3_15 sumcount Syntax: -~~~~{.php} +~~~~{.tcl} sumcount [ ...] ~~~~ Prints only a number of entities per each type matching the criteria defined by arguments. **Example:** -~~~~{.php} +~~~~{.tcl} sumcount xst-types ~~~~ @subsubsection occt_draw_8_3_16 tpclear Syntax: -~~~~{.php} +~~~~{.tcl} tpclear ~~~~ @@ -8836,33 +8836,33 @@ Clears the map of correspondences between IGES or STEP entities and OCCT shapes. @subsubsection occt_draw_8_3_17 tpdraw Syntax: -~~~~{.php} +~~~~{.tcl} tpdraw <#(D)>_or_ ~~~~ **Example:** -~~~~{.php} +~~~~{.tcl} tpdraw 57 ~~~~ @subsubsection occt_draw_8_3_18 tpent Syntax: -~~~~{.php} +~~~~{.tcl} tpent <#(D)>_or_ ~~~~ Get information about the result of translation of the given IGES or STEP entity. **Example:** -~~~~{.php} +~~~~{.tcl} tpent \#23 ~~~~ @subsubsection occt_draw_8_3_19 tpstat Syntax: -~~~~{.php} +~~~~{.tcl} tpstat [*|?] [] ~~~~ @@ -8890,7 +8890,7 @@ Optional argument \ can limit the action of the command to the selec To get help, run this command without arguments. **Example:** -~~~~{.php} +~~~~{.tcl} # translation ratio on IGES faces tpstat *l iges-faces ~~~~ @@ -8898,14 +8898,14 @@ tpstat *l iges-faces @subsubsection occt_draw_8_3_20 xload Syntax: -~~~~{.php} +~~~~{.tcl} xload ~~~~ 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:** -~~~~{.php} +~~~~{.tcl} xload /disk1/tmp/aaa.stp ~~~~ @@ -8925,14 +8925,14 @@ Reminding: All operations of translation are performed with parameters managed b @subsubsection occt_draw_8_4_1 ReadIges Syntax: -~~~~{.php} +~~~~{.tcl} ReadIges document file_name ~~~~ Reads information from an IGES file to an XCAF document. **Example:** -~~~~{.php} +~~~~{.tcl} ReadIges D /disk1/tmp/aaa.igs ==> Document saved with name D ~~~~ @@ -8940,14 +8940,14 @@ ReadIges D /disk1/tmp/aaa.igs @subsubsection occt_draw_8_4_2 ReadStep Syntax: -~~~~{.php} +~~~~{.tcl} ReadStep ~~~~ Reads information from a STEP file to an XCAF document. **Example:** -~~~~{.php} +~~~~{.tcl} ReadStep D /disk1/tmp/aaa.stp == Document saved with name D ~~~~ @@ -8955,40 +8955,40 @@ ReadStep D /disk1/tmp/aaa.stp @subsubsection occt_draw_8_4_3 WriteIges Syntax: -~~~~{.php} +~~~~{.tcl} WriteIges ~~~~ **Example:** -~~~~{.php} +~~~~{.tcl} WriteIges D /disk1/tmp/aaa.igs ~~~~ @subsubsection occt_draw_8_4_4 WriteStep Syntax: -~~~~{.php} +~~~~{.tcl} WriteStep ~~~~ Writes information from an XCAF document to a STEP file. **Example:** -~~~~{.php} +~~~~{.tcl} WriteStep D /disk1/tmp/aaa.stp ~~~~ @subsubsection occt_draw_8_4_5 XFileCur Syntax: -~~~~{.php} +~~~~{.tcl} XFileCur ~~~~ Returns the name of file which is set as the current one in the Draw session. **Example:** -~~~~{.php} +~~~~{.tcl} XFileCur == *as1-ct-203.stp* ~~~~ @@ -8996,14 +8996,14 @@ XFileCur @subsubsection occt_draw_8_4_6 XFileList Syntax: -~~~~{.php} +~~~~{.tcl} XFileList ~~~~ Returns a list all files that were transferred by the last transfer. This command is meant (assigned) for the assemble step file. **Example:** -~~~~{.php} +~~~~{.tcl} XFileList ==> *as1-ct-Bolt.stp* ==> *as1-ct-L-Bracktet.stp* @@ -9015,28 +9015,28 @@ XFileList @subsubsection occt_draw_8_4_7 XFileSet Syntax: -~~~~{.php} +~~~~{.tcl} XFileSet ~~~~ Sets the current file taking it from the components list of the assemble file. **Example:** -~~~~{.php} +~~~~{.tcl} XFileSet as1-ct-NBA.stp ~~~~ @subsubsection occt_draw_8_4_8 XFromShape Syntax: -~~~~{.php} +~~~~{.tcl} XFromShape ~~~~ This command is similar to the command @ref occt_draw_8_3_7 "fromshape", but gives additional information about the file name. It is useful if a shape was translated from several files. **Example:** -~~~~{.php} +~~~~{.tcl} XFromShape a ==> Shape a: imported from entity 217:#26 in file as1-ct-Nut.stp ~~~~ @@ -9046,28 +9046,28 @@ XFromShape a @subsubsection occt_draw_8_5_1 XNewDoc Syntax: -~~~~{.php} +~~~~{.tcl} XNewDoc ~~~~ Creates a new XCAF document. **Example:** -~~~~{.php} +~~~~{.tcl} XNewDoc D ~~~~ @subsubsection occt_draw_8_5_2 XShow Syntax: -~~~~{.php} +~~~~{.tcl} XShow [ … ] ~~~~ Shows a shape from a given label in the 3D viewer. If the label is not given -- shows all shapes from the document. **Example:** -~~~~{.php} +~~~~{.tcl} # show shape from label 0:1:1:4 from document D XShow D 0:1:1:4 ~~~~ @@ -9075,14 +9075,14 @@ XShow D 0:1:1:4 @subsubsection occt_draw_8_5_3 XStat Syntax: -~~~~{.php} +~~~~{.tcl} XStat ~~~~ Prints common information from an XCAF document. **Example:** -~~~~{.php} +~~~~{.tcl} XStat D ==>Statistis of shapes in the document: ==>level N 0 : 9 @@ -9104,7 +9104,7 @@ XStat D @subsubsection occt_draw_8_5_4 XWdump Syntax: -~~~~{.php} +~~~~{.tcl} XWdump ~~~~ @@ -9112,21 +9112,21 @@ Saves the contents of the viewer window as an image (XWD, png or BMP file). \ must have a corresponding extension. **Example:** -~~~~{.php} +~~~~{.tcl} XWdump D /disk1/tmp/image.png ~~~~ @subsubsection occt_draw_8_5_5 Xdump Syntax: -~~~~{.php} +~~~~{.tcl} Xdump [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:** -~~~~{.php} +~~~~{.tcl} Xdump D 1 ==> ASSEMBLY 0:1:1:1 L-BRACKET(0xe8180448) ==> ASSEMBLY 0:1:1:2 NUT(0xe82151e8) @@ -9147,7 +9147,7 @@ etc. @subsubsection occt_draw_8_6_1 XAddComponent Syntax: -~~~~{.php} +~~~~{.tcl} XAddComponent