The parameter defining image width has been added to all figures to improve their layout in PDF documents and tweaked depending on the nature of each image.
Additionally, some minor changes improving image and text layout have been introduced.
Remove temporary added possibility for setting image width automatically for generation of pdf documentation.
# Prints help message
proc OCCDoc_PrintHelpMessage {} {
- puts "\nUsage: gendoc \[-h\] {-refman|-overview} \[-html|-pdf|-chm\] \[-m=<list of modules>|-ug=<list of docs>\] \[-v\] \[-s=<search_mode>\] \[-mathjax=<path>\] \[-update_images_size\]"
+ puts "\nUsage: gendoc \[-h\] {-refman|-overview} \[-html|-pdf|-chm\] \[-m=<list of modules>|-ug=<list of docs>\] \[-v\] \[-s=<search_mode>\] \[-mathjax=<path>\]"
puts ""
puts "Options are:"
puts ""
puts " Can be: none | local | server | external"
puts " -h : Prints this help message"
puts " -v : Enables more verbose output"
- puts " -update_images_size: Updates width of images in *.md files during pdf generation for @figure alias. It takes actual size of image."
}
# A command for User Documentation compilation
set MODULES {}
set DOCLABEL ""
set VERB_MODE "NO"
- set UPDATE_IMAGES_SIZE "NO"
set SEARCH_MODE "none"
set MATHJAX_LOCATION "https://cdn.mathjax.org/mathjax/latest"
set mathjax_js_name "MathJax.js"
} elseif {$arg_n == "v"} {
set VERB_MODE "YES"
- } elseif {$arg_n == "update_images_size"} {
- set UPDATE_IMAGES_SIZE "YES"
} elseif {$arg_n == "ug"} {
if { ([ lsearch $args_names "refman" ] != -1) } {
continue
# Start main activities
if { $GEN_MODE != "PDF_ONLY" } {
if { [OCCDoc_GetProdRootDir] == ""} {
- OCCDoc_Main $DOC_TYPE $DOCFILES $MODULES $GEN_MODE $VERB_MODE $UPDATE_IMAGES_SIZE $SEARCH_MODE $MATHJAX_LOCATION $GENERATE_PRODUCTS_REFMAN $DOXYGEN_PATH $GRAPHVIZ_PATH $INKSCAPE_PATH $HHC_PATH
+ OCCDoc_Main $DOC_TYPE $DOCFILES $MODULES $GEN_MODE $VERB_MODE $SEARCH_MODE $MATHJAX_LOCATION $GENERATE_PRODUCTS_REFMAN $DOXYGEN_PATH $GRAPHVIZ_PATH $INKSCAPE_PATH $HHC_PATH
} else {
if { $DOC_TYPE == "REFMAN" } {
if { $MODULES != "" } {
foreach module $MODULES {
- OCCDoc_Main $DOC_TYPE $DOCFILES $module $GEN_MODE $VERB_MODE $UPDATE_IMAGES_SIZE $SEARCH_MODE $MATHJAX_LOCATION $GENERATE_PRODUCTS_REFMAN $DOXYGEN_PATH $GRAPHVIZ_PATH $INKSCAPE_PATH $HHC_PATH
+ OCCDoc_Main $DOC_TYPE $DOCFILES $module $GEN_MODE $VERB_MODE $SEARCH_MODE $MATHJAX_LOCATION $GENERATE_PRODUCTS_REFMAN $DOXYGEN_PATH $GRAPHVIZ_PATH $INKSCAPE_PATH $HHC_PATH
}
} else {
- OCCDoc_Main $DOC_TYPE $DOCFILES $MODULES $GEN_MODE $VERB_MODE $UPDATE_IMAGES_SIZE $SEARCH_MODE $MATHJAX_LOCATION $GENERATE_PRODUCTS_REFMAN $DOXYGEN_PATH $GRAPHVIZ_PATH $INKSCAPE_PATH $HHC_PATH
+ OCCDoc_Main $DOC_TYPE $DOCFILES $MODULES $GEN_MODE $VERB_MODE $SEARCH_MODE $MATHJAX_LOCATION $GENERATE_PRODUCTS_REFMAN $DOXYGEN_PATH $GRAPHVIZ_PATH $INKSCAPE_PATH $HHC_PATH
}
} else {
foreach md $DOCFILES {
- OCCDoc_Main $DOC_TYPE $md $MODULES $GEN_MODE $VERB_MODE $UPDATE_IMAGES_SIZE $SEARCH_MODE $MATHJAX_LOCATION $GENERATE_PRODUCTS_REFMAN $DOXYGEN_PATH $GRAPHVIZ_PATH $INKSCAPE_PATH $HHC_PATH
+ OCCDoc_Main $DOC_TYPE $md $MODULES $GEN_MODE $VERB_MODE $SEARCH_MODE $MATHJAX_LOCATION $GENERATE_PRODUCTS_REFMAN $DOXYGEN_PATH $GRAPHVIZ_PATH $INKSCAPE_PATH $HHC_PATH
}
}
}
puts "Info: Processing file $pdf\n"
# Some values are hardcoded because they are related only to PDF generation
- OCCDoc_Main "OVERVIEW" [list $pdf] {} "PDF_ONLY" $VERB_MODE $UPDATE_IMAGES_SIZE "none" $MATHJAX_LOCATION "NO" $DOXYGEN_PATH $GRAPHVIZ_PATH $INKSCAPE_PATH $HHC_PATH
+ OCCDoc_Main "OVERVIEW" [list $pdf] {} "PDF_ONLY" $VERB_MODE "none" $MATHJAX_LOCATION "NO" $DOXYGEN_PATH $GRAPHVIZ_PATH $INKSCAPE_PATH $HHC_PATH
}
puts "[clock format [clock seconds] -format {%Y-%m-%d %H:%M}] Generation completed."
}
}
# Main procedure for documents compilation
-proc OCCDoc_Main {docType {docfiles {}} {modules {}} generatorMode verboseMode updateImagesSize searchMode mathjaxLocation generateProductsRefman DOXYGEN_PATH GRAPHVIZ_PATH INKSCAPE_PATH HHC_PATH} {
+proc OCCDoc_Main {docType {docfiles {}} {modules {}} generatorMode verboseMode searchMode mathjaxLocation generateProductsRefman DOXYGEN_PATH GRAPHVIZ_PATH INKSCAPE_PATH HHC_PATH} {
global available_docfiles
global available_pdf
return -1
}
- # update image sizes in *.md files if necessary
- if { ("$::tcl_platform(platform)" == "windows") &&
- ($updateImagesSize == "YES") } {
- if { [OCCDoc_UpdateImagesSize $docfiles [OCCDoc_GetDoxDir [OCCDoc_GetProdRootDir]] $verboseMode] == -1 } {
- return -1
- }
- }
-
# Run doxygen tool
set starttimestamp [clock format [clock seconds] -format {%Y-%m-%d %H:%M}]
file delete -force $TEX
file rename $TMPFILENAME $TEX
}
-}
-
-# update image sizes in *.md files for PDF documentation if necessary
-proc OCCDoc_UpdateImagesSize {{DocFilesList {}} DoxDir verboseMode} {
-
- foreach DocFile $DocFilesList {
- if {$verboseMode == "YES"} {
- puts "Info: Updating image sizes for file $DocFile..."
- }
-
- if {![file exists $DoxDir/$DocFile]} {
- puts "Error: file $DoxDir/$DocFile does not exist."
- return -1
- }
-
- if { [catch {set aFile [open $DoxDir/$DocFile r]} aReason] } {
- puts "Error: cannot open file \"$DoxDir/$DocFile\" for reading: $aReason"
- return -1
- }
-
- set aFileContent [read $aFile]
- close $aFile
-
- set aNumberOfImages [regexp -all -line {@figure\s*\{[^\}]+\}} $aFileContent]
- set aLastImageIndex 0
-
- if {!$aNumberOfImages} {
- continue
- }
-
- while { $aNumberOfImages } {
- set currentFigureIndex [string first "@figure" $aFileContent ${aLastImageIndex}]
- set first_figure_inclusion [string range $aFileContent $currentFigureIndex end]
- set line ""
- set path ""
- set name ""
- set width ""
- set dump ""
- if [regexp {^(@figure[\s\t]*\{[^\}]+\})} $first_figure_inclusion dump line] {
- if { [regexp {@figure[\s\t]*\{([^,\}]+)[\s\t]*\}} $line dump aPath] } {
- set path "${aPath}"
- } elseif { [regexp {@figure[\s\t]*\{([^,\}]+)[\s\t]*,[\s\t]*\"(.*)\"\}} $line dump aPath aName] } {
- set path "${aPath}"
- set name "\"${aName}\""
- } elseif { [regexp {@figure[\s\t]*\{([^,\}]+)[\s\t]*,[\s\t]*\"(.*)\"[\s\t]*,[\s\t]*([0-9]+)\}} $line dump aPath aName aWidth] } {
- set path "${aPath}"
- set name "\"${aName}\""
- set width "${aWidth}"
- }
-
- if {$name == ""} {
- set name "\"\""
- }
- # find image
- set anImagePath ""
- if {[file exists "$DoxDir/$path"]} {
- set anImagePath "$DoxDir/$path"
- } elseif {[file exists "[OCCDoc_GetDoxDir]/$path"]} {
- set anImagePath "[OCCDoc_GetDoxDir]/$path"
- } elseif {[file exists "[OCCDoc_GetDoxDir]/resources/$path"]} {
- set anImagePath "[OCCDoc_GetDoxDir]/resources/$path"
- } elseif {[file exists "$DoxDir/[file dirname ${DocFile}]/images/$path"]} {
- set anImagePath "$DoxDir/[file dirname ${DocFile}]/images/$path"
- }
- if { ![file exists "$anImagePath"] } {
- puts "Warning: Could not find \"$DoxDir/$path\" file"
- incr aNumberOfImages -1
- set aLastImageIndex [expr $currentFigureIndex + [string length $dump]]
- continue
- }
- # get image width
- if [catch {exec identify "$anImagePath"} res] {
- puts "Error: identify returns \"${identify_error}\""
- incr aNumberOfImages -1
- set aLastImageIndex [expr $currentFigureIndex + [string length $dump]]
- continue
- } else {
- if [regexp {([0-9]+)x[0-9]+} $res dump2 loc_width] {
- set width $loc_width
- }
- }
-
- set newInfo "@figure{$path,$name,$width}"
- set aFileContent "[string replace $aFileContent $currentFigureIndex [expr $currentFigureIndex + [string length $dump] - 1] $newInfo]"
- set aLastImageIndex [expr $currentFigureIndex + [string length $newInfo]]
- }
- incr aNumberOfImages -1
- }
-
- if { [catch {set aFile [open $DoxDir/$DocFile w]} aReason] } {
- puts "Error: cannot open file \"$DoxDir/$DocFile\" for writting: $aReason"
- return -1
- }
-
- puts $aFile "${aFileContent}"
- close $aFile
- }
-}
+}
\ No newline at end of file
@subsection occt_contribution_workflow_general General scheme
<center>
-@figure{OCCT_ContributionWorkflow_V3_image001.svg, "Standard life cycle of an issue"}
+@figure{OCCT_ContributionWorkflow_V3_image001.svg,"Standard life cycle of an issue",360}
</center>
@subsection occt_contribution_workflow_issue Issue registration
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"}
+@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.
| 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. |
+
Note that in the process of PDF generation MiKTeX may need some packages not installed by default.
We recommend setting option "Install missing packages on-the-fly" to "Ask me first" (default) during MiKTeX installation:
-@figure{/dev_guides/documentation/images/documentation_miktex.png}
+@figure{/dev_guides/documentation/images/documentation_miktex.png,"",320}
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.).
@subsection OCCT_DM_SECTION_3_2 Directory Structure
-@figure{/dev_guides/documentation/images/documentation_folders.png}
+@figure{/dev_guides/documentation/images/documentation_folders.png,"",160}
Each document has its own folder if there are any images used in it. These images are stored in *images* subfolder.
@verbatim
-@figure{/dev_guides/documentation/images/documentation_test_image.svg}
+@figure{/dev_guides/documentation/images/documentation_test_image.svg,"",420}
@endverbatim
@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 http://www.opencascade.com and <br> http://dev.opencascade.org sites.
-The information on formula syntax can be found at:
+The information on formula syntax can be found at: <br>
http://en.wikipedia.org/wiki/Help:Displaying_a_formula
-More information on MarkDown and Doxygen syntax can be found at:
+More information on MarkDown and Doxygen syntax can be found at: <br>
http://www.stack.nl/~dimitri/doxygen/manual
@section OCCT_DM_SECTION_A Appendix 1: Document Syntax
is rendered as:
-@figure{/dev_guides/documentation/images/documentation_test_image.svg,"Test SVG image"}
+@figure{/dev_guides/documentation/images/documentation_test_image.svg,"Test SVG image",320}
We recommend using **Inkscape** for creation and edition of vector graphics.
The graphics created in MS Word Draw and some other vector editors can be copy-pasted to Inkscape and saved as SVG images.
Note that the *figure* command is an alias to the standard Doxygen command *image* repeated twice: once for HTML and then for Latex output (used for PDF generation). Thus if HTML and PDF outputs should include different images or captions, command "image" can be used:
@verbatim
- @figure{/relative/path/to/image/occ_logo.png, "OCC logo"}
+ @image html /relative/path/to/image/occ_logo_for_html.png
+ @image latex /relative/path/to/image/occ_logo_for_pdf.png
@endverbatim
-@figure{/resources/occ_logo.png, "OCC logo"}
-
@subsection OCCT_DM_SECTION_A_8 Table Of Contents
Use \@tableofcontents tag to get the table of contents at the beginning of the document.
@endverbatim
that leads to the following result: @f$ \sqrt{3x-1}+(1+x)^2 @f$
-
\ No newline at end of file
+
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}
+@figure{OCCT_GitGuide_V2_image005.png,"",100}
Select Git->Config to add your user name and Email address to the local <i>.gitconfig</i> file
- @figure{OCCT_GitGuide_V2_image006.png}
+ @figure{OCCT_GitGuide_V2_image006.png,"",320}
@subsection occt_gitguide_2_2 Linux platform
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"}
+@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.
* 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}
+@figure{OCCT_GitGuide_V2_image009.png,"",320}
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.
* Right-click in the Explorer window, then choose **Git Create Branch**.
* Select **Base On** Branch *remotes/origin/master*.
-@figure{OCCT_GitGuide_V2_image012.png}
+@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.
In TortoiseGit: right-click in the explorer window and select in the context menu **TortoiseGit** -> **Switch/Checkout**.
-@figure{OCCT_GitGuide_V2_image013.png}
+@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.
* In TortoiseGit: right-click in the explorer window and select in the context menu <b>Git Commit -> CR…</b>:
-@figure{OCCT_GitGuide_V2_image014.png}
+@figure{OCCT_GitGuide_V2_image014.png,"",320}
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).
* In TortoiseGit: right-click in the explorer window and select in the context menu, TortoiseGit -> **Push**
-@figure{OCCT_GitGuide_V2_image015.png}
+@figure{OCCT_GitGuide_V2_image015.png,"",320}
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}
+@figure{OCCT_GitGuide_V2_image016.png,"",320}
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:
* 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}
+@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.
* In TortoiseGit: right-click in the explorer window and select in the context menu **TortoiseGit** -> **Pull**.
-@figure{OCCT_GitGuide_V2_image019.png}
+@figure{OCCT_GitGuide_V2_image019.png,"",320}
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.
* In TortoiseGit: right-click in the explorer window and select in the context menu **TortoiseGit** -> **Git Show Log**.
-@figure{OCCT_GitGuide_V2_image020.png}
+@figure{OCCT_GitGuide_V2_image020.png,"",420}
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.
* 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}
+@figure{OCCT_GitGuide_V2_image021.png,"",320}
* 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}
+@figure{OCCT_GitGuide_V2_image022.png,"",320}
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.
* In TortoiseGit history log, select a branch to rebase on <i>(remotes/origin/master)</i> 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}
+@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}
+@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}
+@figure{OCCT_GitGuide_V2_image025.png,"",320}
@section occt_gitguide_5 Work with repository: Reviewer operations
* 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}
+@figure{OCCT_GitGuide_V2_image026.png,"",320}
+
General layout of test scripts is shown in Figure 1.
-@figure{/dev_guides/tests/images/tests_image001.png, "Layout of tests folder"}
+@figure{/dev_guides/tests/images/tests_image001.png,"Layout of tests folder",400}
@subsection testmanual_2_2 Test Groups
~~~~~
checktrinfo result -defl 1 -tol_abs_defl 0.001
~~~~~
+
To illustrate the use of classes provided in the 3D geometric modeling toolkits, you will create a bottle as shown:
-@figure{/tutorial/images/tutorial_image001.png}
+@figure{/tutorial/images/tutorial_image001.png,"",240}
In the tutorial we will create, step-by-step, a function that will model a bottle as shown above. You will find the complete source code of this tutorial, including the very function *MakeBottle* in the distribution of Open CASCADE Technology. The function body is provided in the file samples/qt/Tutorial/src/MakeBottle.cxx.
In addition, we decide that the bottle's profile (base) will be centered on the origin of the global Cartesian coordinate system.
-@figure{/tutorial/images/tutorial_image002.png}
+@figure{/tutorial/images/tutorial_image002.png,"",240}
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}
+@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:
@subsection OCCT_TUTORIAL_SUB2_2 Profile: Defining the Geometry
With the help of the previously defined points, you can compute a part of the bottle's profile geometry. As shown in the figure below, it will consist of two segments and one arc.
-@figure{/tutorial/images/tutorial_image004.png}
+@figure{/tutorial/images/tutorial_image004.png,"",240}
To create such entities, you need a specific data structure, which implements 3D geometric objects. This can be found in the Geom package of Open CASCADE Technology.
In Open CASCADE Technology a package is a group of classes providing related functionality. The classes have names that start with the name of a package they belong to. For example, *Geom_Line* and *Geom_Circle* classes belong to the *Geom* package. The *Geom* package implements 3D geometric objects: elementary curves and surfaces are provided as well as more complex ones (such as *Bezier* and *BSpline*).
* Three edges out of the previously computed curves.
* One wire with these edges.
-@figure{/tutorial/images/tutorial_image005.png}
+@figure{/tutorial/images/tutorial_image005.png,"",240}
However, the *TopoDS* package provides only the data structure of the topological entities. Algorithm classes available to compute standard topological objects can be found in the *BRepBuilderAPI* package.
To create an edge, you use the BRepBuilderAPI_MakeEdge class with the previously computed curves:
* compute a new wire by reflecting the existing one.
* add the reflected wire to the initial one.
-@figure{/tutorial/images/tutorial_image006.png}
+@figure{/tutorial/images/tutorial_image006.png,"",377}
To apply a transformation on shapes (including wires), you first need to define the properties of a 3D geometric transformation by using the gp_Trsf class. This transformation can be a translation, a rotation, a scale, a reflection, or a combination of these.
In our case, we need to define a reflection with respect to the X axis of the global coordinate system. An axis, defined with the gp_Ax1 class, is built out of a point and has a direction (3D unitary vector). There are two ways to define this axis.
| Face | Solid |
| Shell | Compound of Solids |
-@figure{/tutorial/images/tutorial_image007.png}
+@figure{/tutorial/images/tutorial_image007.png,"",240}
Your current profile is a wire. Referring to the Shape/Generates table, you need to compute a face out of its wire to generate a solid.
To create a face, use the *BRepBuilderAPI_MakeFace* class. As previously explained, a face is a part of a surface bounded by a closed wire. Generally, *BRepBuilderAPI_MakeFace* computes a face out of a surface and one or more wires.
* applied on all edges of the shape
* have a radius of *myThickness* / 12
-@figure{/tutorial/images/tutorial_image008.png}
+@figure{/tutorial/images/tutorial_image008.png,"",240}
To apply fillets on the edges of a shape, you use the *BRepFilletAPI_MakeFillet* class. This class is normally used as follows:
To add a neck to the bottle, you will create a cylinder and fuse it to the body. The cylinder is to be positioned on the top face of the body with a radius of *myThickness* / 4. and a height of *myHeight* / 10.
-@figure{/tutorial/images/tutorial_image009.png}
+@figure{/tutorial/images/tutorial_image009.png,"",240}
To position the cylinder, you need to define a coordinate system with the *gp_Ax2* class defining a right-handed coordinate system from a point and two directions - the main (Z) axis direction and the X direction (the Y direction is computed from these two).
To align the neck with the center of the top face, being in the global coordinate system (0, 0, *myHeight*), with its normal on the global Z axis, your local coordinate system can be defined as follows:
* Create a parallel wall W2 from W1 at a distance D. If D is positive, W2 will be outside the initial solid, otherwise it will be inside.
* Compute a solid from the two walls W1 and W2.
-@figure{/tutorial/images/tutorial_image010.png}
+@figure{/tutorial/images/tutorial_image010.png,"",240}
To compute a thick solid, you create an instance of the *BRepOffsetAPI_MakeThickSolid* class by giving the following information:
Using the same coordinate system *neckAx2* used to position the neck, you create two cylindrical surfaces *Geom_CylindricalSurface* with the following radii:
-@figure{/tutorial/images/tutorial_image011.png}
+@figure{/tutorial/images/tutorial_image011.png,"",300}
Notice that one of the cylindrical surfaces is smaller than the neck. There is a good reason for this: after the thread creation, you will fuse it with the neck. So, we must make sure that the two shapes remain in contact.
* R is the radius of the cylindrical surface.
* U range is [0, 2PI] and V is infinite.
-@figure{/tutorial/images/tutorial_image012.png}
+@figure{/tutorial/images/tutorial_image012.png,"",400}
The advantage of having such parameterized geometries is that you can compute, for any (U, V) parameters of the surface:
There is another advantage of these parametric equations: you can consider a surface as a 2D parametric space defined with a (U, V) coordinate system. For example, consider the parametric ranges of the neck's surface:
-@figure{/tutorial/images/tutorial_image013.png}
+@figure{/tutorial/images/tutorial_image013.png,"",320}
Suppose that you create a 2D line on this parametric (U, V) space and compute its 3D parametric curve. Depending on the line definition, results are as follows:
* In V parameter: between 0 and myHeighNeck for the height description
* In U parameter: between 0 and 2PI for the angle description. But, since a cylindrical surface is U periodic, you can decide to extend this angle evolution to 4PI as shown in the following drawing:
-@figure{/tutorial/images/tutorial_image014.png}
+@figure{/tutorial/images/tutorial_image014.png,"",440}
In this (U, V) parametric space, you will create a local (X, Y) coordinate system to position the curves to be created. This coordinate system will be defined with:
* A center located in the middle of the neck's cylinder parametric space at (2*PI, myNeckHeight / 2) in U, V coordinates.
* A X direction defined with the (2*PI, myNeckHeight/4) vector in U, V coordinates, so that the curves occupy half of the neck's surfaces.
-@figure{/tutorial/images/tutorial_image015.png}
+@figure{/tutorial/images/tutorial_image015.png,"",440}
To use 2D primitive geometry types of Open CASCADE Technology for defining a point and a coordinate system, you will once again instantiate classes from gp:
You will now define the curves. As previously mentioned, these thread profiles are computed on two cylindrical surfaces. In the following figure, curves on the left define the base (on *aCyl1* surface) and the curves on the right define the top of the thread's shape (on *aCyl2* surface).
-@figure{/tutorial/images/tutorial_image016.png}
+@figure{/tutorial/images/tutorial_image016.png,"",440}
You have already used the *Geom* package to define 3D geometric entities. For 2D, you will use the *Geom2d* package. As for *Geom*, all geometries are parameterized. For example, a *Geom2d_Ellipse* ellipse is defined from:
* compute the edges of the neck's threading.
* compute two wires out of these edges.
-@figure{/tutorial/images/tutorial_image017.png}
+@figure{/tutorial/images/tutorial_image017.png,"",440}
Previously, you have built:
There are always faster ways to build a solid when the base topology is defined. You would like to create a solid out of two wires. Open CASCADE Technology provides a quick way to do this by building a loft: a shell or a solid passing through a set of wires in a given sequence.
The loft function is implemented in the *BRepOffsetAPI_ThruSections* class, which you use as follows:
-@figure{/tutorial/images/tutorial_image018.png}
+@figure{/tutorial/images/tutorial_image018.png,"",285}
* Initialize the algorithm by creating an instance of the class. The first parameter of this constructor must be specified if you want to create a solid. By default, *BRepOffsetAPI_ThruSections* builds a shell.
* Add the successive wires using the AddWire method.
Congratulations! Your bottle is complete. Here is the result snapshot of the Tutorial application:
-@figure{/tutorial/images/tutorial_image019.png}
+@figure{/tutorial/images/tutorial_image019.png,"",320}
We hope that this tutorial has provided you with a feel for the industrial strength power of Open CASCADE Technology.
If you want to know more and develop major projects using Open CASCADE Technology, we invite you to study our training, support, and consulting services on our site at http://www.opencascade.com/content/technology-support. Our professional services can maximize the power of your Open CASCADE Technology applications.
return aRes;
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
<i>R<sub>GF</sub> = GF (S<sub>1</sub>, S<sub>2</sub>) = S<sub>p1</sub> + S<sub>p2</sub> + S<sub>p12</sub></i>
-@figure{/user_guides/boolean_operations/images/operations_image001.svg, "Operators"}
+@figure{/user_guides/boolean_operations/images/operations_image001.svg,"Operators",320}
This Figure shows that
* <i>B<sub>common</sub> (S<sub>1</sub>, S<sub>2</sub>) = S<sub>p12</sub>;</i>
For two vertices *Vi* and *Vj*, the distance between their corresponding 3D points is less than the sum of their tolerances *Tol(Vi)* and *Tol(Vj)*.
-@figure{/user_guides/boolean_operations/images/operations_image002.svg, "Vertex/vertex interference"}
+@figure{/user_guides/boolean_operations/images/operations_image002.svg,"Vertex/vertex interference",420}
The result is a new vertex *Vn* with 3D point *Pn* and tolerance value <i>Tol(Vn)</i>.
For a vertex *Vi* and an edge *Ej*, the distance *D* between 3D point of the vertex and its projection on the 3D curve of edge *Ej* is less or equal than sum of tolerances of vertex *Tol(Vi)* and edge *Tol(Ej)*.
-@figure{/user_guides/boolean_operations/images/operations_image003.svg, "Vertex/edge interference"}
+@figure{/user_guides/boolean_operations/images/operations_image003.svg,"Vertex/edge interference",420}
The result is vertex *Vi* with the corresponding tolerance value <i>Tol(Vi)=Max(Tol(Vi), D+Tol(Ej))</i>, where <i>D = distance (Pi, PPi)</i>;
For a vertex *Vi* and a face *Fj* the distance *D* between 3D point of the vertex and its projection on the surface of the face is less or equal than sum of tolerances of the vertex *Tol(Vi)* and the face *Tol(Fj)*.
-@figure{/user_guides/boolean_operations/images/operations_image004.svg, "Vertex/face interference"}
+@figure{/user_guides/boolean_operations/images/operations_image004.svg,"Vertex/face interference",420}
The result is vertex *Vi* with the corresponding tolerance value <i>Tol(Vi)=Max(Tol(Vi), D+Tol(Fj))</i>, where <i>D = distance (Pi, PPi)</i>
In the first case two edges have one or several common parts of 3D curves in terms of tolerance.
-@figure{/user_guides/boolean_operations/images/operations_image005.svg, "Edge/edge interference: common parts"}
+@figure{/user_guides/boolean_operations/images/operations_image005.svg,"Edge/edge interference: common parts",420}
The results are:
* Parametric range <i>[t<sub>i1</sub>, t<sub>i2</sub> ]</i> for 3D curve *Ci* of edge *Ei*.
In the second case two edges have one or several common points in terms of tolerance.
-@figure{/user_guides/boolean_operations/images/operations_image006.svg, "Edge/edge interference: common points"}
+@figure{/user_guides/boolean_operations/images/operations_image006.svg,"Edge/edge interference: common points",420}
The result is a new vertex *Vn* with 3D point *Pn* and tolerance value *Tol(Vn)*.
In the first case Edge *Ei* and Face *Fj* have one or several common parts in terms of tolerance.
-@figure{/user_guides/boolean_operations/images/operations_image007.svg, "Edge/face interference: common parts"}
+@figure{/user_guides/boolean_operations/images/operations_image007.svg,"Edge/face interference: common parts",420}
The result is a parametric range <i>[t<sub>i1</sub>, t<sub>i2</sub>]</i> for the 3D curve *Ci* of the edge *Ei*.
In the second case Edge *Ei* and Face *Fj* have one or several common points in terms of tolerance.
-@figure{/user_guides/boolean_operations/images/operations_image008.svg, "Edge/face interference: common points"}
+@figure{/user_guides/boolean_operations/images/operations_image008.svg,"Edge/face interference: common points",420}
The result is a new vertex *Vn* with 3D point *Pn* and tolerance value *Tol(Vn)*.
For a face *Fi* and a face *Fj* (with the corresponding surfaces *Si* and *Sj*) there are some places in 3D space, where the distance between the surfaces is less than (or equal to) sum of tolerances of the faces.
-@figure{/user_guides/boolean_operations/images/operations_image009.svg, "Face/face interference: common curves"}
+@figure{/user_guides/boolean_operations/images/operations_image009.svg,"Face/face interference: common curves",418}
In the first case the result contains intersection curves *C<sub>ijk</sub> (k = 0, 1, 2…k<sub>N</sub>,* where *k<sub>N</sub>* is the number of intersection curves with corresponding values of tolerances *Tol(C<sub>ijk</sub>)*.
-@figure{/user_guides/boolean_operations/images/operations_image010.svg, "Face/face interference: common points"}
+@figure{/user_guides/boolean_operations/images/operations_image010.svg,"Face/face interference: common points",305}
In the second case Face *Fi* and face *Fj* have one or several new vertices *V<sub>ijm</sub>*, where <i>m=0,1,2, ... mN, mN </i> is the number of intersection points.
For a vertex *Vi* and a solid *Zj* there is Vertex/Solid interference if the vertex *Vi* has no BRep interferences with any sub-shape of *Zj* and *Vi* is completely inside the solid *Zj*.
-@figure{/user_guides/boolean_operations/images/operations_image060.png, "Vertex/Solid Interference"}
+@figure{/user_guides/boolean_operations/images/operations_image060.png,"Vertex/Solid Interference",220}
@subsubsection occt_algorithms_3_1_8 Edge/Soild Interference
For an edge *Ei* and a solid *Zj* there is Edge/Solid interference if the edge *Ei* and its sub-shapes have no BRep interferences with any sub-shape of *Zj* and *Ei* is completely inside the solid *Zj*.
-@figure{/user_guides/boolean_operations/images/operations_image061.png, "Edge/Solid Interference"}
+@figure{/user_guides/boolean_operations/images/operations_image061.png,"Edge/Solid Interference",220}
@subsubsection occt_algorithms_3_1_9 Face/Soild Interference
For a face *Fi* and a solid *Zj* there is Face/Solid interference if the face *Fi* and its sub-shapes have no BRep interferences with any sub-shape of *Zj* and *Fi* is completely inside the solid *Zj*.
-@figure{/user_guides/boolean_operations/images/operations_image062.png, "Face/Solid Interference"}
+@figure{/user_guides/boolean_operations/images/operations_image062.png,"Face/Solid Interference",220}
@subsubsection occt_algorithms_3_1_10 Solid/Soild Interference
For a solid *Zi* and a solid *Zj* there is Solid/Solid interference if the solid *Zi* and its sub-shapes have no BRep interferences with any sub-shape of *Zj* and *Zi* is completely inside the solid *Zj*.
-@figure{/user_guides/boolean_operations/images/operations_image063.png, "Solid/Solid Interference"}
+@figure{/user_guides/boolean_operations/images/operations_image063.png,"Solid/Solid Interference",220}
@subsubsection occt_algorithms_3_1_11 Computation Order
The position of vertex *Vi* on curve *C* can be defined by a value of parameter <i>t<sub>i</sub></i> of the 3D point of the vertex on the curve.
Pave *PVi* on curve *C* is a structure containing the vertex *Vi* and correspondent value of the parameter <i>t<sub>i</sub></i> of the 3D point of the vertex on the curve. Curve *C* can be a 3D or a 2D curve.
-@figure{/user_guides/boolean_operations/images/operations_image011.svg, "Paves"}
+@figure{/user_guides/boolean_operations/images/operations_image011.svg,"Paves",340}
Two paves *PV1* and *PV2* on the same curve *C* can be compared using the parameter value @code PV1 > PV2 if t1 > t2 @endcode
A pave block *PBi* is a part of the object (edge, intersection curve) between neighboring paves.
-@figure{/user_guides/boolean_operations/images/operations_image012.svg, "Pave Blocks"}
+@figure{/user_guides/boolean_operations/images/operations_image012.svg,"Pave Blocks",340}
Any finite source edge *E* has at least one pave block that contains two paves *PVb* and *PVe*:
* Pave *PVb* corresponds to the vertex *Vb* with minimal parameter <i>t<sub>b</sub></i> on the curve of the edge.
* In case of edge, the tolerance value is the tolerance of the edge.
* In case of intersection curve, the tolerance value is obtained from an intersection algorithm.
-@figure{/user_guides/boolean_operations/images/operations_image013.svg, "Shrunk Range"}
+@figure{/user_guides/boolean_operations/images/operations_image013.svg,"Shrunk Range",340}
The theoretical parametric range of the pave block is <i>[t1C, t2C]</i>.
In case of Edge/Edge interference the common parts are pave blocks that have different base edges.
-@figure{/user_guides/boolean_operations/images/operations_image014.svg, "Common Blocks: Edge/Edge interference"}
+@figure{/user_guides/boolean_operations/images/operations_image014.svg,"Common Blocks: Edge/Edge interference",340}
If the pave blocks <i>PB<sub>1</sub>, PB<sub>2</sub>…PB<sub>NbPB</sub></i> , where *NbPB* is the number of pave blocks have the same bounding vertices and geometrically coincide, the pave blocks form common block *CB*.
In case of Edge/Face interference the common parts are pave blocks lying on a face(s).
-@figure{/user_guides/boolean_operations/images/operations_image015.svg, "Common Blocks: Edge/Face interference"}
+@figure{/user_guides/boolean_operations/images/operations_image015.svg,"Common Blocks: Edge/Face interference",265}
If the pave blocks *PBi* geometrically coincide with a face *Fj*, the pave blocks form common block *CB*.
* Pave blocks built up from intersection curves for the face;
* Vertices built up from intersection points for the face.
-@figure{/user_guides/boolean_operations/images/operations_image016.svg, "Face Info"}
+@figure{/user_guides/boolean_operations/images/operations_image016.svg,"Face Info",420}
In the figure, for face *F1*:
* Pave blocks that have state **In** for the face: *PB<sub>in1</sub>*.
The Figure shows inheritance diagram for *BOPDS_Interf* classes.
-@figure{/user_guides/boolean_operations/images/operations_image017.svg, "BOPDS_Interf classes"}
+@figure{/user_guides/boolean_operations/images/operations_image017.svg,"BOPDS_Interf classes",420}
@subsection occt_algorithms_4_4 Pave, PaveBlock and CommonBlock
IP is implemented in the class *BOPAlgo_PaveFiller*.
-@figure{/user_guides/boolean_operations/images/operations_image064.svg, "Diagram for Class BOPAlgo_PaveFiller"}
+@figure{/user_guides/boolean_operations/images/operations_image064.svg,"Diagram for Class BOPAlgo_PaveFiller",230}
@subsection occt_algorithms_5_1a Class BOPAlgo_Algo
The class *BOPAlgo_Algo* provides the base interface for all algorithms to provide the possibility to:
The example of connexity chains of interfered vertices is given in the image:
-@figure{/user_guides/boolean_operations/images/operations_image018.svg, "Connexity chains of interfered vertices"}
+@figure{/user_guides/boolean_operations/images/operations_image018.svg,"Connexity chains of interfered vertices",394}
@subsection occt_algorithms_5_3 Compute Vertex/Edge Interferences
The example of coinciding chains of pave blocks is given in the image:
-@figure{/user_guides/boolean_operations/images/operations_image019.png, "Coinciding chains of pave blocks"}
+@figure{/user_guides/boolean_operations/images/operations_image019.png,"Coinciding chains of pave blocks",420}
* The pairs of coincided pave blocks are: <i>(PB11, PB12), (PB11, PB13), (PB12, PB13), (PB21, PB22), (PB21, PB23), (PB22, PB23).</i>
* The pairs produce two chains: <i>(PB11, PB12, PB13)</i> and <i>(PB21, PB22, PB23).</i>
* *BOPAlgo_BOP* -- for the Boolean Operation operator (BOA).
* *BOPAlgo_Section* -- for the Section operator (SA).
-@figure{/user_guides/boolean_operations/images/operations_image020.svg, "Diagram for BP classes"}
+@figure{/user_guides/boolean_operations/images/operations_image020.svg,"Diagram for BP classes",300}
The class *BOPAlgo_BuilderShape* provides the interface for algorithms that have:
* A Shape as the result;
Let us consider three edges: *E1, E2* and *E3* that intersect in one 3D point.
-@figure{/user_guides/boolean_operations/images/operations_image021.svg, "Three Intersecting Edges"}
+@figure{/user_guides/boolean_operations/images/operations_image021.svg,"Three Intersecting Edges",420}
The result of the GFA operation is a compound containing 6 new edges: *E11, E12, E21, E22, E31*, and *E32*. These edges have one shared vertex *Vn1*.
Let us consider two wires *W1 (Ew11, Ew12, Ew13)* and *W2 (Ew21, Ew22, Ew23)* and edge *E1*.
-@figure{/user_guides/boolean_operations/images/operations_image022.svg, "Two wires and an edge"}
+@figure{/user_guides/boolean_operations/images/operations_image022.svg,"Two wires and an edge",420}
The result of the GF operation is a compound consisting of 2 wires: *Wn1 (Ew11, En1, En2, En3, Ew13)* and *Wn2 (Ew21, En2, En3, En4, Ew23)* and two edges: *E11* and *E12*.
Let us consider edge *E1* and face *F2*:
-@figure{/user_guides/boolean_operations/images/operations_image023.svg, "An edge intersecting with a face"}
+@figure{/user_guides/boolean_operations/images/operations_image023.svg,"An edge intersecting with a face",420}
The result of the GF operation is a compound consisting of 3 shapes:
* Split edge parts *E11* and *E12* (image of *E1*).
Let us consider edge *E1* and face *F2*:
-@figure{/user_guides/boolean_operations/images/operations_image024.svg, "An edge lying on a face"}
+@figure{/user_guides/boolean_operations/images/operations_image024.svg,"An edge lying on a face",420}
The result of the GF operation is a compound consisting of 5 shapes:
* Split edge parts *E11, E12* and *E13* (image of *E1*).
Let us consider edge *E1* and shell *Sh2* that consists of 2 faces: *F21* and *F22*
-@figure{/user_guides/boolean_operations/images/operations_image025.svg, "An edge and a shell"}
+@figure{/user_guides/boolean_operations/images/operations_image025.svg,"An edge and a shell",488}
The result of the GF operation is a compound consisting of 5 shapes:
* Split edge parts *E11, E12 , E13* and *E14* (image of *E1*).
@subsubsection occt_algorithms_7_3_6 Case 6: A wire and a shell
Let us consider wire *W1 (E1, E2, E3, E4)* and shell *Sh2 (F21, F22)*.
-@figure{/user_guides/boolean_operations/images/operations_image026.svg, "A wire and a shell"}
+@figure{/user_guides/boolean_operations/images/operations_image026.svg,"A wire and a shell",427}
The result of the GF operation is a compound consisting of 2 shapes:
@subsubsection occt_algorithms_7_3_7 Case 7: Three faces
-Let us consider 3 faces: *F1, F2* and *F3*. @figure{/user_guides/boolean_operations/images/operations_image027.png, "Three faces"}
+Let us consider 3 faces: *F1, F2* and *F3*. @figure{/user_guides/boolean_operations/images/operations_image027.png,"Three faces",420}
The result of the GF operation is a compound consisting of 7 shapes:
* Split face parts: *Fn1, Fn2, Fn3, Fn4, Fn5, Fn6* and *Fn7*.
@subsubsection occt_algorithms_7_3_8 Case 8: A face and a shell
Let us consider shell *Sh1 (F11, F12, F13)* and face *F2*.
-@figure{/user_guides/boolean_operations/images/operations_image028.png, "A face and a shell"}
+@figure{/user_guides/boolean_operations/images/operations_image028.png,"A face and a shell",420}
The result of the GF operation is a compound consisting of 4 shapes:
* Image shell *Sh11* that consists of split face parts from shell *Sh1: Fn1, Fn2, Fn3, Fn4, Fn5* and *Fn6*.
@subsubsection occt_algorithms_7_3_9 Case 9: A shell and a solid
-Let us consider shell *Sh1 (F11, F12…F16)* and solid *So2*. @figure{/user_guides/boolean_operations/images/operations_image029.png, "A shell and a solid: arguments"}
+Let us consider shell *Sh1 (F11, F12…F16)* and solid *So2*. @figure{/user_guides/boolean_operations/images/operations_image029.png,"A shell and a solid: arguments",220}
The result of the GF operation is a compound consisting of 2 shapes:
* Image shell *Sh11* consisting of split face parts of *Sh1: Fn1, Fn2 ... Fn8.*
* Solid *So21* with internal shell. (image of *So2*).
-@figure{/user_guides/boolean_operations/images/operations_image030.png, "A shell and a solid: results"}
+@figure{/user_guides/boolean_operations/images/operations_image030.png,"A shell and a solid: results",420}
@subsubsection occt_algorithms_7_3_10 Case 10: A compound and a solid
Let us consider compound *Cm1* consisting of 2 solids *So11* and *So12*) and solid *So2*.
-@figure{/user_guides/boolean_operations/images/operations_image031.png, "A compound and a solid: arguments"}
+@figure{/user_guides/boolean_operations/images/operations_image031.png,"A compound and a solid: arguments",220}
The result of the GF operation is a compound consisting of 4 shapes:
* Image compound *Cm11* consisting of split solid parts from *So11* and *So12 (Sn1, Sn2, Sn3, Sn4)*.
* Split parts of solid *So2 (Sn2, Sn3, Sn5)*.
-@figure{/user_guides/boolean_operations/images/operations_image032.png, "A compound and a solid: results"}
+@figure{/user_guides/boolean_operations/images/operations_image032.png,"A compound and a solid: results",420}
@subsection occt_algorithms_7_4 Class BOPAlgo_Builder
@subsubsection occt_algorithms_7_4_3 Build Images for Vertices
-The input data for this step is *BOPAlgo_Builder* object after Initialisation.
+The input data for this step is *BOPAlgo_Builder* object after Initialization.
| No | Contents | Implementation |
| :--- | :--- | :--- |
The example of chains of same domain faces is given in the image:
-@figure{/user_guides/boolean_operations/images/operations_image033.svg, "Chains of same domain faces"}
+@figure{/user_guides/boolean_operations/images/operations_image033.svg,"Chains of same domain faces",420}
* The pairs of same domain faces are: <i>(F11, F21), (F22, F31), (F41, F51) , (F41, F6)</i> and <i>(F51, F6)</i>.
* The pairs produce the three chains: <i>(F11, F21), (F22, F31)</i> and <i>(F41, F51, F6)</i>.
<table align="center">
<tr>
- <td>@figure{/user_guides/boolean_operations/images/bsplit_image001.png, "Arguments"}</td>
- <td>@figure{/user_guides/boolean_operations/images/bsplit_image002.png, "Result"}</td>
+ <td>@figure{/user_guides/boolean_operations/images/bsplit_image001.png,"Arguments",160}</td>
+ <td>@figure{/user_guides/boolean_operations/images/bsplit_image002.png,"Result",160}</td>
</tr>
</table>
<table align="center">
<tr>
- <td>@figure{/user_guides/boolean_operations/images/bsplit_image003.png, "Arguments"}</td>
- <td>@figure{/user_guides/boolean_operations/images/bsplit_image004.png, "Result"}</td>
+ <td>@figure{/user_guides/boolean_operations/images/bsplit_image003.png,"Arguments",160}</td>
+ <td>@figure{/user_guides/boolean_operations/images/bsplit_image004.png,"Result",160}</td>
</tr>
</table>
Splitting shell hull by the planes:
<table align="center">
<tr>
- <td>@figure{/user_guides/boolean_operations/images/bsplit_image005.png, "Arguments"}</td>
- <td>@figure{/user_guides/boolean_operations/images/bsplit_image006.png, "Results"}</td>
+ <td>@figure{/user_guides/boolean_operations/images/bsplit_image005.png,"Arguments",160}</td>
+ <td>@figure{/user_guides/boolean_operations/images/bsplit_image006.png,"Results",160}</td>
</tr>
</table>
Let us consider two interfering vertices *V1* and *V2*:
-@figure{/user_guides/boolean_operations/images/boolean_image001.svg}
+@figure{/user_guides/boolean_operations/images/boolean_image001.svg,"",160}
* The result of *Fuse* operation is the compound that contains new vertex *V*.
-@figure{/user_guides/boolean_operations/images/boolean_image002.svg}
+@figure{/user_guides/boolean_operations/images/boolean_image002.svg,"",160}
* The result of *Common* operation is a compound containing new vertex *V*.
Let us consider vertex *V1* and the edge *E2*, that intersect in a 3D point:
-@figure{/user_guides/boolean_operations/images/boolean_image004.png}
+@figure{/user_guides/boolean_operations/images/boolean_image004.png,"",230}
* The result of *Fuse* operation is result is not defined because the dimension of the vertex (0) is not equal to the dimension of the edge (1).
* The result of *Common* operation is a compound containing vertex *V<sub>1</sub>* as the argument *V<sub>1</sub>* has a common part with edge *E2*.
-@figure{/user_guides/boolean_operations/images/boolean_image005.png}
+@figure{/user_guides/boolean_operations/images/boolean_image005.png,"",230}
* The result of *Cut12* operation is an empty compound.
* The result of *Cut21* operation is not defined because the dimension of the vertex (0) is less than the dimension of the edge (1).
Let us consider vertex *V1* and face *F2*, that intersect in a 3D point:
-@figure{/user_guides/boolean_operations/images/boolean_image006.png}
+@figure{/user_guides/boolean_operations/images/boolean_image006.png,"",230}
* The result of *Fuse* operation is not defined because the dimension of the vertex (0) is not equal to the dimension of the face (2).
* The result of *Common* operation is a compound containing vertex *V<sub>1</sub>* as the argument *V<sub>1</sub>* has a common part with face *F2*.
-@figure{/user_guides/boolean_operations/images/boolean_image007.png}
+@figure{/user_guides/boolean_operations/images/boolean_image007.png,"",230}
* The result of *Cut12* operation is an empty compound.
* The result of *Cut21* operation is not defined because the dimension of the vertex (0) is less than the dimension of the face (2).
Let us consider vertex *V1* and solid *S2*, that intersect in a 3D point:
-@figure{/user_guides/boolean_operations/images/boolean_image008.png}
+@figure{/user_guides/boolean_operations/images/boolean_image008.png,"",230}
* The result of *Fuse* operation is not defined because the dimension of the vertex (0) is not equal to the dimension of the solid (3).
* The result of *Common* operation is a compound containing vertex *V<sub>1</sub>* as the argument *V<sub>1</sub>* has a common part with solid *S2*.
-@figure{/user_guides/boolean_operations/images/boolean_image009.png}
+@figure{/user_guides/boolean_operations/images/boolean_image009.png,"",230}
* The result of *Cut12* operation is an empty compound.
* The result of *Cut21* operation is not defined because the dimension of the vertex (0) is less than the dimension of the solid (3).
Let us consider edges *E1* and *E2* that intersect in a 3D point:
-@figure{/user_guides/boolean_operations/images/boolean_image010.svg}
+@figure{/user_guides/boolean_operations/images/boolean_image010.svg,"",230}
* The result of *Fuse* operation is a compound containing split parts of arguments i.e. 4 new edges *E11, E12, E21*, and *E22*. These edges have one shared vertex *Vn1*.
In this case:
* argument edge *E1* has resulting split edges *E11* and *E12* (image of *E1*);
* argument edge *E2* has resulting split edges *E21* and *E22* (image of *E2*).
-@figure{/user_guides/boolean_operations/images/boolean_image011.svg}
+@figure{/user_guides/boolean_operations/images/boolean_image011.svg,"",230}
* The result of *Common* operation is an empty compound because the dimension (0) of the common part between the edges (vertex) is less than the dimension of the arguments (1).
In this case the argument edge *E1* has resulting split edges *E11* and *E12* (image of *E1*).
-@figure{/user_guides/boolean_operations/images/boolean_image012.svg}
+@figure{/user_guides/boolean_operations/images/boolean_image012.svg,"",230}
* The result of *Cut21* operation is a compound containing split parts of the argument *E2*, i.e. 2 new edges *E21* and *E12*. These edges have one shared vertex *Vn1*.
In this case the argument edge *E2* has resulting split edges *E21* and *E22* (image of *E2*).
-@figure{/user_guides/boolean_operations/images/boolean_image013.svg}
+@figure{/user_guides/boolean_operations/images/boolean_image013.svg,"",70}
@subsubsection occt_algorithms_9_4_6 Case 6: Two edges having a common block
Let us consider edges *E1* and *E2* that have a common block:
-@figure{/user_guides/boolean_operations/images/boolean_image014.svg}
+@figure{/user_guides/boolean_operations/images/boolean_image014.svg,"",230}
* The result of *Fuse* operation is a compound containing split parts of arguments i.e. 3 new edges *E11*, *E12* and *E22*. These edges have two shared vertices.
In this case:
* argument edge *E2* has resulting split edges *E21* and *E22* (image of *E2*);
* edge *E12* is common for the images of *E1* and *E2*.
-@figure{/user_guides/boolean_operations/images/boolean_image015.svg}
+@figure{/user_guides/boolean_operations/images/boolean_image015.svg,"",230}
* The result of *Common* operation is a compound containing split parts of arguments i.e. 1 new edge *E12*. In this case edge *E12* is common for the images of *E1* and *E2*.
The common part between the edges (edge) has the same dimension (1) as the dimension of the arguments (1).
-@figure{/user_guides/boolean_operations/images/boolean_image016.svg}
+@figure{/user_guides/boolean_operations/images/boolean_image016.svg,"",230}
* The result of *Cut12* operation is a compound containing a split part of argument *E1*, i.e. new edge *E11*.
-@figure{/user_guides/boolean_operations/images/boolean_image017.svg}
+@figure{/user_guides/boolean_operations/images/boolean_image017.svg,"",230}
* The result of *Cut21* operation is a compound containing a split part of argument *E2*, i.e. new edge *E22*.
-@figure{/user_guides/boolean_operations/images/boolean_image018.svg}
+@figure{/user_guides/boolean_operations/images/boolean_image018.svg,"",230}
@subsubsection occt_algorithms_9_4_7 Case 7: An Edge and a Face intersecting at a point
Let us consider edge *E1* and face *F2* that intersect at a 3D point:
-@figure{/user_guides/boolean_operations/images/boolean_image019.png}
+@figure{/user_guides/boolean_operations/images/boolean_image019.png,"",230}
* The result of *Fuse* operation is not defined because the dimension of the edge (1) is not equal to the dimension of the face (2).
In this case the argument edge *E1* has no common parts with the face *F2* so the whole image of *E1* is in the result.
-@figure{/user_guides/boolean_operations/images/boolean_image020.png}
+@figure{/user_guides/boolean_operations/images/boolean_image020.png,"",230}
* The result of *Cut21* operation is not defined because the dimension of the edge (1) is less than the dimension of the face (2).
Let us consider edge *E1* and face *F2* that have a common block:
-@figure{/user_guides/boolean_operations/images/boolean_image021.png}
+@figure{/user_guides/boolean_operations/images/boolean_image021.png,"",230}
* The result of *Fuse* operation is not defined because the dimension of the edge (1) is not equal to the dimension of the face (2).
In this case the argument edge *E1* has a common part with face *F2* so the corresponding part of the image of *E1* is in the result. The yellow square is not a part of the result. It only shows the place of *F2*.
-@figure{/user_guides/boolean_operations/images/boolean_image022.png}
+@figure{/user_guides/boolean_operations/images/boolean_image022.png,"",230}
* The result of *Cut12* operation is a compound containing split part of the argument *E1*, i.e. new edge *E11*.
In this case the argument edge *E1* has a common part with face *F2* so the corresponding part is not included into the result. The yellow square is not a part of the result. It only shows the place of F2.
-@figure{/user_guides/boolean_operations/images/boolean_image023.png}
+@figure{/user_guides/boolean_operations/images/boolean_image023.png,"",230}
* The result of *Cut21* operation is not defined because the dimension of the edge (1) is less than the dimension of the face (2).
Let us consider edge *E1* and solid *S2* that intersect at a point:
-@figure{/user_guides/boolean_operations/images/boolean_image024.png}
+@figure{/user_guides/boolean_operations/images/boolean_image024.png,"",230}
* The result of *Fuse* operation is not defined because the dimension of the edge (1) is not equal to the dimension of the solid (3).
In this case the argument edge *E1* has a common part with solid *S2* so the corresponding part of the image of *E1* is in the result. The yellow square is not a part of the result. It only shows the place of *S2*.
-@figure{/user_guides/boolean_operations/images/boolean_image025.png}
+@figure{/user_guides/boolean_operations/images/boolean_image025.png,"",230}
* The result of *Cut12* operation is a compound containing split part of the argument *E1*, i.e. new edge *E11*.
In this case the argument edge *E1* has a common part with solid *S2* so the corresponding part is not included into the result. The yellow square is not a part of the result. It only shows the place of *S2*.
-@figure{/user_guides/boolean_operations/images/boolean_image071.png}
+@figure{/user_guides/boolean_operations/images/boolean_image071.png,"",230}
* The result of *Cut21* operation is not defined because the dimension of the edge (1) is less than the dimension of the solid (3).
Let us consider edge *E1* and solid *S2* that have a common block:
-@figure{/user_guides/boolean_operations/images/boolean_image072.png}
+@figure{/user_guides/boolean_operations/images/boolean_image072.png,"",230}
* The result of *Fuse* operation is not defined because the dimension of the edge (1) is not equal to the dimension of the solid (3).
In this case the argument edge *E1* has a common part with solid *S2* so the corresponding part of the image of *E1* is in the result. The yellow square is not a part of the result. It only shows the place of *S2*.
-@figure{/user_guides/boolean_operations/images/boolean_image073.png}
+@figure{/user_guides/boolean_operations/images/boolean_image073.png,"",230}
* The result of *Cut12* operation is a compound containing split part of the argument *E1*, i.e. new edge *E11*.
In this case the argument edge *E1* has a common part with solid *S2* so the corresponding part is not included into the result. The yellow square is not a part of the result. It only shows the place of *S2*.
-@figure{/user_guides/boolean_operations/images/boolean_image026.png}
+@figure{/user_guides/boolean_operations/images/boolean_image026.png,"",230}
* The result of *Cut21* operation is not defined because the dimension of the edge (1) is less than the dimension of the solid (3).
Let us consider two intersecting faces *F1* and *F2*:
-@figure{/user_guides/boolean_operations/images/boolean_image027.png}
+@figure{/user_guides/boolean_operations/images/boolean_image027.png,"",230}
* The result of *Fuse* operation is a compound containing split parts of arguments i.e. 2 new faces *F11* and *F21*. These faces have one shared edge *En1*.
-@figure{/user_guides/boolean_operations/images/boolean_image028.png}
+@figure{/user_guides/boolean_operations/images/boolean_image028.png,"",230}
* The result of *Common* operation is an empty compound because the dimension (1) of the common part between *F1* and *F2* (edge) is less than the dimension of arguments (2).
* The result of *Cut12* operation is a compound containing split part of the argument *F1*, i.e. new face *F11*.
-@figure{/user_guides/boolean_operations/images/boolean_image029.png}
+@figure{/user_guides/boolean_operations/images/boolean_image029.png,"",230}
* The result of *Cut21* operation is a compound containing split parts of the argument *F2*, i.e. 1 new face *F21*.
-@figure{/user_guides/boolean_operations/images/boolean_image030.png}
+@figure{/user_guides/boolean_operations/images/boolean_image030.png,"",127}
@subsubsection occt_algorithms_9_4_12 Case 12: Two faces that have a common part
Let us consider two faces *F1* and *F2* that have a common part:
-@figure{/user_guides/boolean_operations/images/boolean_image031.png}
+@figure{/user_guides/boolean_operations/images/boolean_image031.png,"",230}
* The result of *Fuse* operation is a compound containing split parts of arguments, i.e. 3 new faces: *F11*, *F12* and *F22*. These faces are shared through edges In this case:
* the argument edge *F1* has resulting split faces *F11* and *F12* (image of *F1*)
* the argument face *F2* has resulting split faces *F12* and *F22* (image of *F2*)
* the face *F12* is common for the images of *F1* and *F2*.
-@figure{/user_guides/boolean_operations/images/boolean_image032.png}
+@figure{/user_guides/boolean_operations/images/boolean_image032.png,"",230}
* The result of *Common* operation is a compound containing split parts of arguments i.e. 1 new face *F12*.
In this case: face *F12* is common for the images of *F1* and *F2*.
The common part between the faces (face) has the same dimension (2) as the dimension of the arguments (2).
-@figure{/user_guides/boolean_operations/images/boolean_image033.png}
+@figure{/user_guides/boolean_operations/images/boolean_image033.png,"",230}
* The result of *Cut12* operation is a compound containing split part of the argument *F1*, i.e. new face *F11*.
-@figure{/user_guides/boolean_operations/images/boolean_image034.png}
+@figure{/user_guides/boolean_operations/images/boolean_image034.png,"",230}
* The result of *Cut21* operation is a compound containing split parts of the argument *F2*, i.e. 1 new face *F21*.
-@figure{/user_guides/boolean_operations/images/boolean_image035.png}
+@figure{/user_guides/boolean_operations/images/boolean_image035.png,"",230}
@subsubsection occt_algorithms_9_4_13 Case 13: Two faces that have a common edge
Let us consider two faces *F1* and *F2* that have a common edge:
-@figure{/user_guides/boolean_operations/images/boolean_image036.png}
+@figure{/user_guides/boolean_operations/images/boolean_image036.png,"",230}
* The result of *Fuse* operation is a compound containing split parts of arguments, i.e. 2 new faces: *F11* and *F21*. These faces have one shared edge *En1*.
-@figure{/user_guides/boolean_operations/images/boolean_image037.png}
+@figure{/user_guides/boolean_operations/images/boolean_image037.png,"",230}
* The result of *Common* operation is an empty compound because the dimension (1) of the common part between *F1* and *F2* (edge)is less than the dimension of the arguments (2)
* The result of *Cut12* operation is a compound containing split part of the argument *F1*, i.e. new face *F11*. The vertices are shown just to clarify the fact that the edges are spitted.
-@figure{/user_guides/boolean_operations/images/boolean_image038.png}
+@figure{/user_guides/boolean_operations/images/boolean_image038.png,"",230}
* The result of *Cut21* operation is a compound containing split parts of the argument *F2*, i.e. 1 new face *F21*. The vertices are shown just to clarify the fact that the edges are spitted.
-@figure{/user_guides/boolean_operations/images/boolean_image039.png}
+@figure{/user_guides/boolean_operations/images/boolean_image039.png,"",230}
@subsubsection occt_algorithms_9_4_14 Case 14: Two faces that have a common vertex
Let us consider two faces *F1* and *F2* that have a common vertex:
-@figure{/user_guides/boolean_operations/images/boolean_image040.png}
+@figure{/user_guides/boolean_operations/images/boolean_image040.png,"",230}
* The result of *Fuse* operation is a compound containing split parts of arguments, i.e. 2 new faces: *F11* and *F21*. These faces have one shared vertex *Vn1*.
-@figure{/user_guides/boolean_operations/images/boolean_image041.png}
+@figure{/user_guides/boolean_operations/images/boolean_image041.png,"",230}
* The result of *Common* operation is an empty compound because the dimension (0) of the common part between *F1* and *F2* (vertex) is less than the dimension of the arguments (2)
* The result of *Cut12* operation is a compound containing split part of the argument *F1*, i.e. new face *F11*.
-@figure{/user_guides/boolean_operations/images/boolean_image042.png}
+@figure{/user_guides/boolean_operations/images/boolean_image042.png,"",230}
* The result of *Cut21* operation is a compound containing split parts of the argument *F2*, i.e. 1 new face *F21*.
-@figure{/user_guides/boolean_operations/images/boolean_image043.png}
+@figure{/user_guides/boolean_operations/images/boolean_image043.png,"",230}
@subsubsection occt_algorithms_9_4_15 Case 15: A Face and a Solid that have an intersection curve.
Let us consider face *F1* and solid *S2* that have an intersection curve:
-@figure{/user_guides/boolean_operations/images/boolean_image044.png}
+@figure{/user_guides/boolean_operations/images/boolean_image044.png,"",230}
* The result of *Fuse* operation is not defined because the dimension of the face (2) is not equal to the dimension of the solid (3).
* The result of *Common* operation is a compound containing split part of the argument *F1*. In this case the argument face *F1* has a common part with solid *S2*, so the corresponding part of the image of *F1* is in the result. The yellow contour is not a part of the result. It only shows the place of *S2*.
-@figure{/user_guides/boolean_operations/images/boolean_image045.png}
+@figure{/user_guides/boolean_operations/images/boolean_image045.png,"",230}
* The result of *Cut12* operation is a compound containing split part of the argument *F1*. In this case argument face *F1* has a common part with solid *S2* so the corresponding part is not included into the result. The yellow contour is not a part of the result. It only shows the place of *S2*.
-@figure{/user_guides/boolean_operations/images/boolean_image046.png}
+@figure{/user_guides/boolean_operations/images/boolean_image046.png,"",230}
* The result of *Cut21* operation is is not defined because the dimension of the face (2) is less than the dimension of the solid (3).
Let us consider face *F1* and solid *S2* that have overlapping faces:
-@figure{/user_guides/boolean_operations/images/boolean_image047.png}
+@figure{/user_guides/boolean_operations/images/boolean_image047.png,"",230}
* The result of *Fuse* operation is not defined because the dimension of the face (2) is not equal to the dimension of the solid (3).
* The result of *Common* operation is a compound containing split part of the argument *F1*. In this case the argument face *F1* has a common part with solid *S2*, so the corresponding part of the image of *F1* is included in the result. The yellow contour is not a part of the result. It only shows the place of *S2*.
-@figure{/user_guides/boolean_operations/images/boolean_image048.png}
+@figure{/user_guides/boolean_operations/images/boolean_image048.png,"",230}
* The result of *Cut12* operation is a compound containing split part of the argument *F1*. In this case argument face *F1* has a common part with solid *S2* so the corresponding part is not included into the result. The yellow contour is not a part of the result. It only shows the place of *S2*.
-@figure{/user_guides/boolean_operations/images/boolean_image049.png}
+@figure{/user_guides/boolean_operations/images/boolean_image049.png,"",230}
* The result of *Cut21* operation is is not defined because the dimension of the face (2) is less than the dimension of the solid (3).
Let us consider face *F1* and solid *S2* that have overlapping edges:
-@figure{/user_guides/boolean_operations/images/boolean_image050.png}
+@figure{/user_guides/boolean_operations/images/boolean_image050.png,"",230}
* The result of *Fuse* operation is not defined because the dimension of the face (2) is not equal to the dimension of the solid (3).
* The result of *Cut12* operation is a compound containing split part of the argument *F1*. In this case argument face *F1* has a common part with solid *S2* so the corresponding part is not included into the result. The yellow contour is not a part of the result. It only shows the place of *S2*.
-@figure{/user_guides/boolean_operations/images/boolean_image051.png}
+@figure{/user_guides/boolean_operations/images/boolean_image051.png,"",230}
* The result of *Cut21* operation is is not defined because the dimension of the face (2) is less than the dimension of the solid (3).
Let us consider face *F1* and solid *S2* that have overlapping vertices:
-@figure{/user_guides/boolean_operations/images/boolean_image052.png}
+@figure{/user_guides/boolean_operations/images/boolean_image052.png,"",230}
* The result of *Fuse* operation is not defined because the dimension of the face (2) is not equal to the dimension of the solid (3).
* The result of *Cut12* operation is a compound containing split part of the argument *F1*. In this case argument face *F1* has a common part with solid *S2* so the corresponding part is not included into the result. The yellow contour is not a part of the result. It only shows the place of *S2*.
-@figure{/user_guides/boolean_operations/images/boolean_image053.png}
+@figure{/user_guides/boolean_operations/images/boolean_image053.png,"",230}
* The result of *Cut21* operation is is not defined because the dimension of the face (2) is less than the dimension of the solid (3).
Let us consider two intersecting solids *S1* and *S2*:
-@figure{/user_guides/boolean_operations/images/boolean_image054.png}
+@figure{/user_guides/boolean_operations/images/boolean_image054.png,"",230}
* The result of *Fuse* operation is a compound composed from the split parts of arguments *S11, S12* and *S22* <i>(Cut12, Common, Cut21)</i>. All inner webs are removed, so the result is one new solid *R*.
-@figure{/user_guides/boolean_operations/images/boolean_image055.png}
+@figure{/user_guides/boolean_operations/images/boolean_image055.png,"",230}
* The result of *Common* operation is a compound containing split parts of arguments i.e. one new solid *S12*. In this case solid *S12* is common for the images of *S1* and *S2*. The common part between the solids (solid) has the same dimension (3) as the dimension of the arguments (3). The yellow contour is not a part of the result. It only shows the place of *S1*.
-@figure{/user_guides/boolean_operations/images/boolean_image056.png}
+@figure{/user_guides/boolean_operations/images/boolean_image056.png,"",176}
* The result of *Cut12* operation is a compound containing split part of the argument *S1*, i.e. 1 new solid *S11*.
-@figure{/user_guides/boolean_operations/images/boolean_image057.png}
+@figure{/user_guides/boolean_operations/images/boolean_image057.png,"",230}
* The result of *Cut21* operation is a compound containing split part of the argument *S2*, i.e. 1 new solid *S21*.
-@figure{/user_guides/boolean_operations/images/boolean_image058.png}
+@figure{/user_guides/boolean_operations/images/boolean_image058.png,"",230}
@subsubsection occt_algorithms_9_4_20 Case 20: Two Solids that have overlapping faces.
Let us consider two solids *S1* and *S2* that have a common part on face:
-@figure{/user_guides/boolean_operations/images/boolean_image059.png}
+@figure{/user_guides/boolean_operations/images/boolean_image059.png,"",230}
* The result of *Fuse* operation is a compound composed from the split parts of arguments *S11, S12* and *S22* <i>(Cut12, Common, Cut21)</i>. All inner webs are removed, so the result is one new solid *R*.
-@figure{/user_guides/boolean_operations/images/boolean_image060.png}
+@figure{/user_guides/boolean_operations/images/boolean_image060.png,"",230}
* The result of *Common* operation is an empty compound because the dimension (2) of the common part between *S1* and *S2* (face) is less than the lower dimension of the arguments (3).
* The result of *Cut12* operation is a compound containing split part of the argument *S1*, i.e. 1 new solid *S11*.
-@figure{/user_guides/boolean_operations/images/boolean_image061.png}
+@figure{/user_guides/boolean_operations/images/boolean_image061.png,"",230}
* The result of *Cut21* operation is a compound containing split part of the argument *S2*, i.e. 1 new solid *S21*.
-@figure{/user_guides/boolean_operations/images/boolean_image062.png}
+@figure{/user_guides/boolean_operations/images/boolean_image062.png,"",230}
@subsubsection occt_algorithms_9_4_21 Case 21: Two Solids that have overlapping edges.
Let us consider two solids *S1* and *S2* that have overlapping edges:
-@figure{/user_guides/boolean_operations/images/boolean_image063.png}
+@figure{/user_guides/boolean_operations/images/boolean_image063.png,"",230}
* The result of *Fuse* operation is a compound composed from the split parts of arguments i.e. 2 new solids *S11* and *S21*. These solids have one shared edge *En1*.
-@figure{/user_guides/boolean_operations/images/boolean_image064.png}
+@figure{/user_guides/boolean_operations/images/boolean_image064.png,"",230}
* The result of *Common* operation is an empty compound because the dimension (1) of the common part between *S1* and *S2* (edge) is less than the lower dimension of the arguments (3).
* The result of *Cut12* operation is a compound containing split part of the argument *S1*. In this case
argument *S1* has a common part with solid *S2* so the corresponding part is not included into the result.
-@figure{/user_guides/boolean_operations/images/boolean_image065.png}
+@figure{/user_guides/boolean_operations/images/boolean_image065.png,"",230}
* The result of *Cut21* operation is a compound containing split part of the argument *S2*. In this case
argument *S2* has a common part with solid *S1* so the corresponding part is not included into the result.
-@figure{/user_guides/boolean_operations/images/boolean_image066.png}
+
+@figure{/user_guides/boolean_operations/images/boolean_image066.png,"",230}
@subsubsection occt_algorithms_9_4_22 Case 22: Two Solids that have overlapping vertices.
Let us consider two solids *S1* and *S2* that have overlapping vertices:
-@figure{/user_guides/boolean_operations/images/boolean_image067.png}
+@figure{/user_guides/boolean_operations/images/boolean_image067.png,"",230}
* The result of *Fuse* operation is a compound composed from the split parts of arguments i.e. 2 new solids *S11* and *S21*. These solids share *Vn1*.
-@figure{/user_guides/boolean_operations/images/boolean_image068.png}
+@figure{/user_guides/boolean_operations/images/boolean_image068.png,"",230}
* The result of *Common* operation is an empty compound because the dimension (0) of the common part between *S1* and *S2* (vertex) is less than the lower dimension of the arguments (3).
* The result of *Cut12* operation is a compound containing split part of the argument *S1*.
-@figure{/user_guides/boolean_operations/images/boolean_image069.png}
+@figure{/user_guides/boolean_operations/images/boolean_image069.png,"",230}
* The result of *Cut21* operation is a compound containing split part of the argument *S2*.
-@figure{/user_guides/boolean_operations/images/boolean_image070.png}
+@figure{/user_guides/boolean_operations/images/boolean_image070.png,"",230}
@subsubsection occt_algorithms_9_4_23 Case 23: A Shell and a Wire cut by a Solid.
Let us consider Shell *Sh* and Wire *W* as the objects and Solid *S* as the tool:
-@figure{/user_guides/boolean_operations/images/boolean_image136.png}
+@figure{/user_guides/boolean_operations/images/boolean_image136.png,"",230}
* The result of *Fuse* operation is not defined as the dimension of the arguments is not the same.
* The result of *Common* operation is a compound containing the parts of the initial Shell and Wire common for the Solid. The new Shell and Wire are created from the objects.
-@figure{/user_guides/boolean_operations/images/boolean_image137.png}
+@figure{/user_guides/boolean_operations/images/boolean_image137.png,"",230}
* The result of *Cut12* operation is a compound containing new Shell and Wire split from the arguments *Sh* and *W*. In this case they have a common part with solid *S* so the corresponding part is not included into the result.
-@figure{/user_guides/boolean_operations/images/boolean_image138.png}
+@figure{/user_guides/boolean_operations/images/boolean_image138.png,"",230}
* The result of *Cut21* operation is not defined as the objects have a lower dimension than the tool.
Let us consider two Wires that have overlapping edges, *W1* is the object and *W2* is the tool:
-@figure{/user_guides/boolean_operations/images/boolean_image139.png}
+@figure{/user_guides/boolean_operations/images/boolean_image139.png,"",230}
* The result of *Fuse* operation is a compound containing two Wires, which share an overlapping edge. The new Wires are created from the objects:
-@figure{/user_guides/boolean_operations/images/boolean_image140.png}
+@figure{/user_guides/boolean_operations/images/boolean_image140.png,"",230}
* The result of *Common* operation is a compound containing one Wire consisting of an overlapping edge. The new Wire is created from the objects:
-@figure{/user_guides/boolean_operations/images/boolean_image141.png}
+@figure{/user_guides/boolean_operations/images/boolean_image141.png,"",230}
* The result of *Cut12* operation is a compound containing a wire split from object *W1*. Its common part with *W2* is not included into the result.
-@figure{/user_guides/boolean_operations/images/boolean_image142.png}
+@figure{/user_guides/boolean_operations/images/boolean_image142.png,"",230}
* The result of *Cut21* operation is a compound containing a wire split from *W2*. Its common part with *W1* is not included into the result.
-@figure{/user_guides/boolean_operations/images/boolean_image143.png}
+@figure{/user_guides/boolean_operations/images/boolean_image143.png,"",230}
@subsection occt_algorithms_9_5 Class BOPAlgo_BOP
Let us consider two interfering vertices: *V1* and *V2*.
-@figure{/user_guides/boolean_operations/images/boolean_image080.png}
+@figure{/user_guides/boolean_operations/images/boolean_image080.png,"",131}
The result of *Section* operation is the compound that contains a new vertex *V*.
-@figure{/user_guides/boolean_operations/images/boolean_image081.png}
+@figure{/user_guides/boolean_operations/images/boolean_image081.png,"",128}
@subsubsection occt_algorithms_10a_3_2 Case 1: Case 2: A Vertex and an Edge
Let us consider vertex *V1* and the edge *E2*, that intersect in a 3D point:
-@figure{/user_guides/boolean_operations/images/boolean_image082.png}
+@figure{/user_guides/boolean_operations/images/boolean_image082.png,"",230}
The result of *Section* operation is the compound that contains vertex *V1*.
-@figure{/user_guides/boolean_operations/images/boolean_image083.png}
+@figure{/user_guides/boolean_operations/images/boolean_image083.png,"",230}
@subsubsection occt_algorithms_10a_3_3 Case 1: Case 2: A Vertex and a Face
Let us consider vertex *V1* and face *F2*, that intersect in a 3D point:
-@figure{/user_guides/boolean_operations/images/boolean_image084.png}
+@figure{/user_guides/boolean_operations/images/boolean_image084.png,"",230}
The result of *Section* operation is the compound that contains vertex *V1*.
-@figure{/user_guides/boolean_operations/images/boolean_image085.png}
+@figure{/user_guides/boolean_operations/images/boolean_image085.png,"",230}
@subsubsection occt_algorithms_10a_3_4 Case 4: A Vertex and a Solid
Let us consider vertex *V1* and solid *Z2*. The vertex *V1* is inside the solid *Z2*.
-@figure{/user_guides/boolean_operations/images/boolean_image086.png}
+@figure{/user_guides/boolean_operations/images/boolean_image086.png,"",230}
The result of *Section* operation is an empty compound.
Let us consider edges *E1* and *E2*, that intersect in a 3D point:
-@figure{/user_guides/boolean_operations/images/boolean_image087.png}
+@figure{/user_guides/boolean_operations/images/boolean_image087.png,"",230}
The result of *Section* operation is the compound that contains a new vertex *Vnew*.
-@figure{/user_guides/boolean_operations/images/boolean_image088.png}
+@figure{/user_guides/boolean_operations/images/boolean_image088.png,"",230}
@subsubsection occt_algorithms_10a_3_6 Case 6: Two edges having a common block
Let us consider edges *E1* and *E2*, that have a common block:
-@figure{/user_guides/boolean_operations/images/boolean_image089.png}
+@figure{/user_guides/boolean_operations/images/boolean_image089.png,"",230}
The result of *Section* operation is the compound that contains a new edge *Enew*.
-@figure{/user_guides/boolean_operations/images/boolean_image090.png}
+@figure{/user_guides/boolean_operations/images/boolean_image090.png,"",230}
@subsubsection occt_algorithms_10a_3_7 Case 7: An Edge and a Face intersecting at a point
Let us consider edge *E1* and face *F2*, that intersect at a 3D point:
-@figure{/user_guides/boolean_operations/images/boolean_image091.png}
+@figure{/user_guides/boolean_operations/images/boolean_image091.png,"",230}
The result of *Section* operation is the compound that contains a new vertex *Vnew*.
-@figure{/user_guides/boolean_operations/images/boolean_image092.png}
+@figure{/user_guides/boolean_operations/images/boolean_image092.png,"",230}
@subsubsection occt_algorithms_10a_3_8 Case 8: A Face and an Edge that have a common block
Let us consider edge *E1* and face *F2*, that have a common block:
-@figure{/user_guides/boolean_operations/images/boolean_image093.png}
+@figure{/user_guides/boolean_operations/images/boolean_image093.png,"",230}
The result of *Section* operation is the compound that contains new edge *Enew*.
-@figure{/user_guides/boolean_operations/images/boolean_image094.png}
+@figure{/user_guides/boolean_operations/images/boolean_image094.png,"",230}
@subsubsection occt_algorithms_10a_3_9 Case 9: An Edge and a Solid intersecting at a point
Let us consider edge *E1* and solid *Z2*, that intersect at a point:
-@figure{/user_guides/boolean_operations/images/boolean_image095.png}
+@figure{/user_guides/boolean_operations/images/boolean_image095.png,"",230}
The result of *Section* operation is the compound that contains a new vertex *Vnew*.
-@figure{/user_guides/boolean_operations/images/boolean_image096.png}
+@figure{/user_guides/boolean_operations/images/boolean_image096.png,"",230}
@subsubsection occt_algorithms_10a_3_10 Case 10: An Edge and a Solid that have a common block
Let us consider edge *E1* and solid *Z2*, that have a common block at a face:
-@figure{/user_guides/boolean_operations/images/boolean_image097.png}
+@figure{/user_guides/boolean_operations/images/boolean_image097.png,"",230}
The result of *Section* operation is the compound that contains a new edge *Enew*.
-@figure{/user_guides/boolean_operations/images/boolean_image098.png}
+@figure{/user_guides/boolean_operations/images/boolean_image098.png,"",230}
@subsubsection occt_algorithms_10a_3_11 Case 11: Two intersecting faces
Let us consider two intersecting faces *F1* and *F2*:
-@figure{/user_guides/boolean_operations/images/boolean_image099.png}
+@figure{/user_guides/boolean_operations/images/boolean_image099.png,"",230}
The result of *Section* operation is the compound that contains a new edge *Enew*.
-@figure{/user_guides/boolean_operations/images/boolean_image100.png}
+@figure{/user_guides/boolean_operations/images/boolean_image100.png,"",230}
@subsubsection occt_algorithms_10a_3_12 Case 12: Two faces that have a common part
Let us consider two faces *F1* and *F2* that have a common part:
-@figure{/user_guides/boolean_operations/images/boolean_image133.png}
+@figure{/user_guides/boolean_operations/images/boolean_image133.png,"",230}
The result of *Section* operation is the compound that contains 4 new edges.
-@figure{/user_guides/boolean_operations/images/boolean_image134.png}
+@figure{/user_guides/boolean_operations/images/boolean_image134.png,"",230}
@subsubsection occt_algorithms_10a_3_13 Case 13: Two faces that have overlapping edges
Let us consider two faces *F1* and *F2* that have a overlapping edges:
-@figure{/user_guides/boolean_operations/images/boolean_image101.png}
+@figure{/user_guides/boolean_operations/images/boolean_image101.png,"",230}
The result of *Section* operation is the compound that contains a new edge *Enew*.
-@figure{/user_guides/boolean_operations/images/boolean_image102.png}
+@figure{/user_guides/boolean_operations/images/boolean_image102.png,"",230}
@subsubsection occt_algorithms_10a_3_14 Case 14: Two faces that have overlapping vertices
Let us consider two faces *F1* and *F2* that have overlapping vertices:
-@figure{/user_guides/boolean_operations/images/boolean_image103.png}
+@figure{/user_guides/boolean_operations/images/boolean_image103.png,"",230}
The result of *Section* operation is the compound that contains a new vertex *Vnew*.
-@figure{/user_guides/boolean_operations/images/boolean_image104.png}
+@figure{/user_guides/boolean_operations/images/boolean_image104.png,"",230}
@subsubsection occt_algorithms_10a_3_15 Case 15: A Face and a Solid that have an intersection curve
Let us consider face *F1* and solid *Z2* that have an intersection curve:
-@figure{/user_guides/boolean_operations/images/boolean_image105.png}
+@figure{/user_guides/boolean_operations/images/boolean_image105.png,"",230}
The result of *Section* operation is the compound that contains new edges.
-@figure{/user_guides/boolean_operations/images/boolean_image106.png}
+@figure{/user_guides/boolean_operations/images/boolean_image106.png,"",230}
@subsubsection occt_algorithms_10a_3_16 Case 16: A Face and a Solid that have overlapping faces.
Let us consider face *F1* and solid *Z2* that have overlapping faces:
-@figure{/user_guides/boolean_operations/images/boolean_image107.png}
+@figure{/user_guides/boolean_operations/images/boolean_image107.png,"",230}
The result of *Section* operation is the compound that contains new edges
-@figure{/user_guides/boolean_operations/images/boolean_image108.png}
+@figure{/user_guides/boolean_operations/images/boolean_image108.png,"",230}
@subsubsection occt_algorithms_10a_3_17 Case 17: A Face and a Solid that have overlapping edges.
Let us consider face *F1* and solid *Z2* that have a common part on edge:
-@figure{/user_guides/boolean_operations/images/boolean_image109.png}
+@figure{/user_guides/boolean_operations/images/boolean_image109.png,"",230}
The result of *Section* operation is the compound that contains a new edge *Enew*.
-@figure{/user_guides/boolean_operations/images/boolean_image110.png}
+@figure{/user_guides/boolean_operations/images/boolean_image110.png,"",230}
@subsubsection occt_algorithms_10a_3_18 Case 18: A Face and a Solid that have overlapping vertices.
Let us consider face *F1* and solid *Z2* that have overlapping vertices:
-@figure{/user_guides/boolean_operations/images/boolean_image111.png}
+@figure{/user_guides/boolean_operations/images/boolean_image111.png,"",230}
The result of *Section* operation is the compound that contains a new vertex *Vnew*.
-@figure{/user_guides/boolean_operations/images/boolean_image112.png}
+@figure{/user_guides/boolean_operations/images/boolean_image112.png,"",230}
@subsubsection occt_algorithms_10a_3_19 Case 19: Two intersecting Solids
Let us consider two intersecting solids *Z1* and *Z2*:
-@figure{/user_guides/boolean_operations/images/boolean_image113.png}
+@figure{/user_guides/boolean_operations/images/boolean_image113.png,"",230}
The result of *Section* operation is the compound that contains new edges.
-@figure{/user_guides/boolean_operations/images/boolean_image114.png}
+@figure{/user_guides/boolean_operations/images/boolean_image114.png,"",230}
@subsubsection occt_algorithms_10a_3_20 Case 20: Two Solids that have overlapping faces
Let us consider two solids *Z1* and *Z2* that have a common part on face:
-@figure{/user_guides/boolean_operations/images/boolean_image115.png}
+@figure{/user_guides/boolean_operations/images/boolean_image115.png,"",230}
The result of *Section* operation is the compound that contains new edges.
-@figure{/user_guides/boolean_operations/images/boolean_image116.png}
+@figure{/user_guides/boolean_operations/images/boolean_image116.png,"",230}
@subsubsection occt_algorithms_10a_3_21 Case 21: Two Solids that have overlapping edges
Let us consider two solids *Z1* and *Z2* that have overlapping edges:
-@figure{/user_guides/boolean_operations/images/boolean_image117.png}
+@figure{/user_guides/boolean_operations/images/boolean_image117.png,"",230}
The result of *Section* operation is the compound that contains a new edge *Enew*.
-@figure{/user_guides/boolean_operations/images/boolean_image118.png}
+@figure{/user_guides/boolean_operations/images/boolean_image118.png,"",230}
@subsubsection occt_algorithms_10a_3_22 Case 22: Two Solids that have overlapping vertices
Let us consider two solids *Z1* and *Z2* that have overlapping vertices:
-@figure{/user_guides/boolean_operations/images/boolean_image119.png}
+@figure{/user_guides/boolean_operations/images/boolean_image119.png,"",230}
The result of *Section* operation is the compound that contains a new vertex *Vnew*.
-@figure{/user_guides/boolean_operations/images/boolean_image120.png}
+@figure{/user_guides/boolean_operations/images/boolean_image120.png,"",230}
@subsection occt_algorithms_10a_4 Class BOPAlgo_Section
<table align="center">
<tr>
- <td>@figure{/user_guides/boolean_operations/images/mkvolume_image001.png, "Arguments"}</td>
- <td>@figure{/user_guides/boolean_operations/images/mkvolume_image002.png, "Results"}</td>
+ <td>@figure{/user_guides/boolean_operations/images/mkvolume_image001.png,"Arguments",200}</td>
+ <td>@figure{/user_guides/boolean_operations/images/mkvolume_image002.png,"Results",200}</td>
</tr>
</table>
<table align="center">
<tr>
- <td>@figure{/user_guides/boolean_operations/images/mkvolume_image003.png, "Arguments"}</td>
- <td>@figure{/user_guides/boolean_operations/images/mkvolume_image004.png, "Results"}</td>
+ <td>@figure{/user_guides/boolean_operations/images/mkvolume_image003.png,"Arguments",200}</td>
+ <td>@figure{/user_guides/boolean_operations/images/mkvolume_image004.png,"Results",200}</td>
</tr>
</table>
mkface f p -25 30 -17 17
~~~~
-@figure{/user_guides/boolean_operations/images/cells_algorithm_001.png, "Arguments"}
+@figure{/user_guides/boolean_operations/images/cells_algorithm_001.png,"Arguments",160}
~~~~
bclearobjects
bcadd res c 1 s 1 f 1
~~~~
-@figure{/user_guides/boolean_operations/images/cells_algorithm_002.png, "The result of COMMON operation"}
+@figure{/user_guides/boolean_operations/images/cells_algorithm_002.png,"The result of COMMON operation",126}
#### 2. Common between cylinder and face
bcadd res f 1 c 1
~~~~
-@figure{/user_guides/boolean_operations/images/cells_algorithm_003.png, "The result of COMMON operation between cylinder and face"}
+@figure{/user_guides/boolean_operations/images/cells_algorithm_003.png,"The result of COMMON operation between cylinder and face",90}
#### 3. Common between cylinder and sphere
bcadd res c 1 s 1
~~~~
-@figure{/user_guides/boolean_operations/images/cells_algorithm_004.png, "The result of COMMON operation between cylinder and sphere"}
+@figure{/user_guides/boolean_operations/images/cells_algorithm_004.png,"The result of COMMON operation between cylinder and sphere",120}
#### 4. Fuse of cylinder and sphere
bcremoveint res
~~~~
-@figure{/user_guides/boolean_operations/images/cells_algorithm_005.png, "The result of FUSE operation between cylinder and sphere"}
+@figure{/user_guides/boolean_operations/images/cells_algorithm_005.png,"The result of FUSE operation between cylinder and sphere",160}
#### 5. Parts of the face inside solids - FUSE(COMMON(f, c), COMMON(f, s))
bcadd res f 1 c 1 -m 1
~~~~
-@figure{/user_guides/boolean_operations/images/cells_algorithm_006_1.png, "Parts of the face inside solids"}
+@figure{/user_guides/boolean_operations/images/cells_algorithm_006_1.png,"Parts of the face inside solids",160}
~~~~
bcremoveint res
~~~~
-@figure{/user_guides/boolean_operations/images/cells_algorithm_006_2.png, "Unified parts of the face inside solids"}
+@figure{/user_guides/boolean_operations/images/cells_algorithm_006_2.png,"Unified parts of the face inside solids",160}
#### 6. Part of the face outside solids
bcadd res f 1 c 0 s 0
~~~~
-@figure{/user_guides/boolean_operations/images/cells_algorithm_007.png, "Part of the face outside solids"}
+@figure{/user_guides/boolean_operations/images/cells_algorithm_007.png,"Part of the face outside solids",160}
#### 7. Fuse operation (impossible using standard Boolean Fuse operation)
bcremoveint res
~~~~
-@figure{/user_guides/boolean_operations/images/cells_algorithm_008.png, "Fuse operation"}
+@figure{/user_guides/boolean_operations/images/cells_algorithm_008.png,"Fuse operation",160}
These examples may last forever. To define any new operation, it is just necessary to define, which Cells should be taken and which should be avoided.
#### Example 1: Compound of two edges
The compound of two edges *E1* and *E2* is a self-interfered shape and cannot be used as the argument of the Algorithms.
-@figure{/user_guides/boolean_operations/images/operations_image036.svg, "Compound of two edges"}
+@figure{/user_guides/boolean_operations/images/operations_image036.svg,"Compound of two edges",230}
#### Example 2: Self-interfered Edge
The edge *E* is a self-interfered shape and cannot be used as an argument of the Algorithms.
-@figure{/user_guides/boolean_operations/images/operations_image037.svg, "Self-interfered Edge"}
+@figure{/user_guides/boolean_operations/images/operations_image037.svg,"Self-interfered Edge",140}
#### Example 3: Self-interfered Face
The face *F* is a self-interfered shape and cannot be used as an argument of the Algorithms.
-@figure{/user_guides/boolean_operations/images/operations_image038.svg, "Self-interfered Face"}
+@figure{/user_guides/boolean_operations/images/operations_image038.svg,"Self-interfered Face",230}
#### Example 4: Face of Revolution
The face *F* has been obtained by revolution of edge *E* around line *L*.
-@figure{/user_guides/boolean_operations/images/operations_image039a.png, "Face of Revolution: Arguments"}
-@figure{/user_guides/boolean_operations/images/operations_image039b.png, "Face of Revolution: Result"}
+@figure{/user_guides/boolean_operations/images/operations_image039a.png,"Face of Revolution: Arguments",230}
+@figure{/user_guides/boolean_operations/images/operations_image039b.png,"Face of Revolution: Result",230}
In spite of the fact that face *F* is valid (in terms of *BRepCheck_Analyzer*) it is a self-interfered shape and cannot be used as the argument of the Algorithms.
@subsubsection occt_algorithms_10_1_4 Self-interferences due to tolerances
#### Example 1: Non-closed Edge
-Let us consider edge *E* based on a non-closed circle. @figure{/user_guides/boolean_operations/images/operations_image040.png, "Edge based on a non-closed circle"}
+Let us consider edge *E* based on a non-closed circle. @figure{/user_guides/boolean_operations/images/operations_image040.png,"Edge based on a non-closed circle",230}
The distance between the vertices of *E* is *D=0.69799*. The values of the tolerances *Tol(V1)=Tol(V2)=0.5*.
-@figure{/user_guides/boolean_operations/images/operations_image041.png, "Distance and Tolerances"}
+@figure{/user_guides/boolean_operations/images/operations_image041.png,"Distance and Tolerances",230}
In spite of the fact that the edge *E* is valid in terms of *BRepCheck_Analyzer*, it is a self-interfered shape because its vertices are interfered. Thus, edge *E* cannot be used as an argument of the Algorithms.
#### Example 2: Solid containing an interfered vertex
-Let us consider solid *S* containing vertex V. @figure{/user_guides/boolean_operations/images/operations_image042.png, "Solid containing an interfered vertex"}
+Let us consider solid *S* containing vertex V. @figure{/user_guides/boolean_operations/images/operations_image042.png,"Solid containing an interfered vertex",230}
The value of tolerance Tol(V)= 50.000075982061.
-@figure{/user_guides/boolean_operations/images/operations_image043.png, "Tolerance"}
+@figure{/user_guides/boolean_operations/images/operations_image043.png,"Tolerance",230}
In spite of the fact that solid *S* is valid in terms of *BRepCheck_Analyzer* it is a self-interfered shape because vertex *V* is interfered with a lot of sub-shapes from *S* without any topological connection with them. Thus solid *S* cannot be used as an argument of the Algorithms.
#### Example 1: Cylindrical surface
The parameterization range for cylindrical surface is:
-@figure{/user_guides/boolean_operations/images/boolean_image135.png}
+@figure{/user_guides/boolean_operations/images/boolean_image135.png,"",230}
The range of *U* coordinate is always restricted while the range of *V* coordinate is non-restricted.
Let us consider a cylinder-based *Face 1* with radii *R=3* and *H=6*.
-@figure{/user_guides/boolean_operations/images/operations_image044.png, "Face 1"}
+@figure{/user_guides/boolean_operations/images/operations_image044.png,"Face 1",230}
-@figure{/user_guides/boolean_operations/images/operations_image045.png, "P-Curves for Face 1"}
+@figure{/user_guides/boolean_operations/images/operations_image045.png,"P-Curves for Face 1",230}
Let us also consider a cylinder-based *Face 2* with radii *R=3000* and *H=6000* (resulting from scaling Face 1 with scale factor *ScF=1000*).
-@figure{/user_guides/boolean_operations/images/operations_image046.png, "Face 2"}
+@figure{/user_guides/boolean_operations/images/operations_image046.png,"Face 2",230}
-@figure{/user_guides/boolean_operations/images/operations_image047.png, "P-Curves for Face 2"}
+@figure{/user_guides/boolean_operations/images/operations_image047.png,"P-Curves for Face 2",230}
Please, pay attention to the Zoom value of the Figures.
Let us consider the following example:
-@figure{/user_guides/boolean_operations/images/operations_image048.png, "Example"}
+@figure{/user_guides/boolean_operations/images/operations_image048.png,"Example",230}
* Face *F* has two edges *E1* and *E2* and two vertices, the base plane is <i>{0,0,0, 0,0,1}</i>;
* Edge *E1* is based on line <i>{0,0,0, 1,0,0}, Tol(E1) = 1.e-7; </i>
* *E1* is based on a line: <i>{0,-10,0, 1,0,0}, Tol(E1)=2.</i>
* *E2* is based on a circle: <i>{0,0,0, 0,0,1}, R=10, Tol(E2)=2.</i>
-@figure{/user_guides/boolean_operations/images/operations_image049.png, "Intersecting Edges"}
+@figure{/user_guides/boolean_operations/images/operations_image049.png,"Intersecting Edges",320}
The result of pure intersection between *E1* and *E2* is vertex *Vx {0,-10,0}*.
The intersection curve between the planes is curve *C12*. The curve produces a new intersection edge *EC12*. The edge goes through vertices *V1* and *V2* thanks to big tolerance values of vertices *Tol(V1)* and *Tol(V2)*. So, two straight edges *E12* and *EC12* go through two vertices, which is impossible in this case.
-@figure{/user_guides/boolean_operations/images/operations_image050.svg, "Intersecting Faces"}
+@figure{/user_guides/boolean_operations/images/operations_image050.svg,"Intersecting Faces",320}
The problem cannot be solved in general, because the length of *E12* can be infinite and the values of *Tol(V1)* and *Tol(V2)* theoretically can be infinite too.
*C1* practically coincides in 3D with *C2*. The value of deflection is *Dmax* (e.g. *Dmax=1.e<sup>-6</sup>*).
-@figure{/user_guides/boolean_operations/images/operations_image051.svg, "Intersecting Edges"}
+@figure{/user_guides/boolean_operations/images/operations_image051.svg,"Intersecting Edges",420}
The evident and prospective result should be the Common Block between *E1* and *E2*. However, the result of intersection differs.
-@figure{/user_guides/boolean_operations/images/operations_image052.svg, "Result of Intersection"}
+@figure{/user_guides/boolean_operations/images/operations_image052.svg,"Result of Intersection",420}
The result contains three new vertices *Vx1, Vx2* and *Vx3*, 8 new edges <i>(V1, Vx1, Vx2, Vx3, V2)</i> and no Common Blocks. This is correct due to the source data: *Tol(E1)=1.e<sup>-7</sup>, Tol(E2)=1.e<sup>-7</sup>* and <i>Dmax=1.e<sup>-6</sup></i>.
The example can be extended from 1D (edges) to 2D (faces).
-@figure{/user_guides/boolean_operations/images/operations_image053.svg, "Intersecting Faces"}
+@figure{/user_guides/boolean_operations/images/operations_image053.svg,"Intersecting Faces",420}
The comments and recommendations are the same as for 1D case above.
Let us consider vertex *V1* and edge *E2*.
-@figure{/user_guides/boolean_operations/images/operations_image054.svg, "Vertex and Edge"}
+@figure{/user_guides/boolean_operations/images/operations_image054.svg,"Vertex and Edge",171}
Vertex *V1* interferes with vertices *V12* and *V22*.
So vertex *V21* should interfere with vertex *V22*, which is impossible because vertices *V21* and *V22* are the vertices of edge *E2*, thus *V21* is not equal to *V22*.
Let us consider vertex *V2* and wire consisting of edges *E11* and *E12*.
-@figure{/user_guides/boolean_operations/images/operations_image055.svg, "Vertex and Wire"}
+@figure{/user_guides/boolean_operations/images/operations_image055.svg,"Vertex and Wire",200}
The arguments themselves are not self-intersected.
Vertex *V2* interferes with edges *E11* and *E12*. Thus, edge *E11* should interfere with edge *E22*, but it is impossible because edges *E11* and *E12* cannot interfere by the condition.
In this example the cylinder (shown in yellow and transparent) is subtracted from the box (shown in red). The cylinder is shifted by 5e<sup>-5</sup> relatively to the box along its axis (the distance between rear faces of the box and cylinder is 5e<sup>-5</sup>).
-@figure{/user_guides/boolean_operations/images/boolean_image121.png}
+@figure{/user_guides/boolean_operations/images/boolean_image121.png,"",240}
The following results are obtained using Basic Operations and the Fuzzy ones with the fuzzy value 5e<sup>-5</sup>:
-@figure{/user_guides/boolean_operations/images/boolean_image122.png, "Result of CUT operation obtained with Basic Operations"}
+@figure{/user_guides/boolean_operations/images/boolean_image122.png,"Result of CUT operation obtained with Basic Operations",240}
-@figure{/user_guides/boolean_operations/images/boolean_image123.png, "Result of CUT operation obtained with Fuzzy Option"}
+@figure{/user_guides/boolean_operations/images/boolean_image123.png,"Result of CUT operation obtained with Fuzzy Option",240}
In this example Fuzzy option allows eliminating a very thin part of the result shape produced by Basic algorithm due to misalignment of rear faces of the box and the cylinder.
In this example two boxes are fused. One of them has dimensions 10*10*10, and the other is 10*10.000001*10.000001 and adjacent to the first one. There is no gap in this case as the surfaces of the neighboring faces coincide, but one box is slightly greater than the other.
-@figure{/user_guides/boolean_operations/images/boolean_image124.png}
+@figure{/user_guides/boolean_operations/images/boolean_image124.png,"",240}
The following results are obtained using Basic Operations and the Fuzzy ones with the fuzzy value 1e<sup>-6</sup>:
-@figure{/user_guides/boolean_operations/images/boolean_image125.png, "Result of CUT operation obtained with Basic Operations"}
+@figure{/user_guides/boolean_operations/images/boolean_image125.png,"Result of CUT operation obtained with Basic Operations",240}
-@figure{/user_guides/boolean_operations/images/boolean_image126.png, "Result of CUT operation obtained with Fuzzy Option"}
+@figure{/user_guides/boolean_operations/images/boolean_image126.png,"Result of CUT operation obtained with Fuzzy Option",240}
In this example Fuzzy option allows eliminating an extremely narrow face in the result produced by Basic operation.
In this example the small planar face (shown in orange) is subtracted from the big one (shown in yellow). There is a gap 1e<sup>-5</sup> between the edges of these faces.
-@figure{/user_guides/boolean_operations/images/boolean_image127.png}
+@figure{/user_guides/boolean_operations/images/boolean_image127.png,"",240}
The following results are obtained using Basic Operations and the Fuzzy ones with the fuzzy value 1e<sup>-5</sup>:
-@figure{/user_guides/boolean_operations/images/boolean_image128.png, "Result of CUT operation obtained with Basic Operations"}
+@figure{/user_guides/boolean_operations/images/boolean_image128.png,"Result of CUT operation obtained with Basic Operations",240}
-@figure{/user_guides/boolean_operations/images/boolean_image129.png, "Result of CUT operation obtained with Fuzzy Option"}
+@figure{/user_guides/boolean_operations/images/boolean_image129.png,"Result of CUT operation obtained with Fuzzy Option",240}
In this example Fuzzy options eliminated a pin-like protrusion resulting from the gap between edges of the argument faces.
In this example the small edge is subtracted from the big one. The edges are overlapping not precisely, with max deviation between them equal to 5.28004e<sup>-5</sup>. We will use 6e<sup>-5</sup> value for Fuzzy option.
-@figure{/user_guides/boolean_operations/images/boolean_image130.png}
+@figure{/user_guides/boolean_operations/images/boolean_image130.png,"",240}
The following results are obtained using Basic Operations and the Fuzzy ones with the fuzzy value 6e<sup>-5</sup>:
-@figure{/user_guides/boolean_operations/images/boolean_image131.png, "Result of CUT operation obtained with Basic Operations"}
+@figure{/user_guides/boolean_operations/images/boolean_image131.png,"Result of CUT operation obtained with Basic Operations",240}
-@figure{/user_guides/boolean_operations/images/boolean_image132.png, "Result of CUT operation obtained with Fuzzy Option"}
+@figure{/user_guides/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).
It has been designed to speed up the computation of the interferences among arguments of the operations on special cases, in which the arguments may be overlapping but do not have real intersections between their sub-shapes.
This option cannot be used on the shapes having real intersections, like intersection vertex between edges, or intersection vertex between edge and a face or intersection line between faces:
-@figure{/user_guides/boolean_operations/images/glue_options_image002.png, "Intersecting faces"}
+
+@figure{/user_guides/boolean_operations/images/glue_options_image002.png,"Intersecting faces",240}
There are two possibilities of overlapping shapes:
* The shapes can be partially coinciding - the faces do not have intersection curves, but overlapping. The faces of such arguments will be split during the operation. The following picture illustrates such shapes:
-@figure{/user_guides/boolean_operations/images/glue_options_image001.png, "Partially coinciding faces"}
-* The shapes can be fully coinciding - there should be no partial overlapping of the faces, thus no intersection of type EDGE/FACE at all. In such cases the faces will not be split during the operation
-@figure{/user_guides/boolean_operations/images/glue_options_image003.png, "Full coinciding faces of the boxes"}
+
+@figure{/user_guides/boolean_operations/images/glue_options_image001.png,"Partially coinciding faces",240}
+
+* The shapes can be fully coinciding - there should be no partial overlapping of the faces, thus no intersection of type EDGE/FACE at all. In such cases the faces will not be split during the operation.
+
+@figure{/user_guides/boolean_operations/images/glue_options_image003.png,"Full coinciding faces of the boxes",240}
Thus, there are two possible options - for full and partial coincidence of the shapes.
@subsubsection occt_algorithms_11a_2_2 Examples
#### Case1 - Fusing the 64 bspline boxes into one solid
-@figure{/user_guides/boolean_operations/images/glue_options_image004.png, "BSpline Boxes with partial coincidence"}
+
+@figure{/user_guides/boolean_operations/images/glue_options_image004.png,"BSpline Boxes with partial coincidence",240}
Performance improvement from using the GlueShift option in this case is about 70 percent.
#### Case2 - Sewing faces of the shape after reading from IGES
-@figure{/user_guides/boolean_operations/images/glue_options_image005.png, "Faces with coinciding but not shared edges"}
+
+@figure{/user_guides/boolean_operations/images/glue_options_image005.png,"Faces with coinciding but not shared edges",240}
Performance improvement in this case is also about 70 percent.
* *BRepAlgoAPI_Cut* -- the class provides Boolean cut operation.
* *BRepAlgoAPI_Section* -- the class provides Boolean section operation.
-@figure{/user_guides/boolean_operations/images/operations_image065.png, "Diagram of BRepAlgoAPI package"}
+@figure{/user_guides/boolean_operations/images/operations_image065.png,"Diagram of BRepAlgoAPI package",420}
The detailed description of the classes can be found in the corresponding .hxx files. The examples are below in this chapter.
# 4 means Section operation
bapibop r 4
~~~~
+
Creates a window for VTK viewer.
-@figure{/user_guides/draw_test_harness/images/draw_image001.png}
+@figure{/user_guides/draw_test_harness/images/draw_image001.png,"",225}
@subsubsection occt_draw_4_6_2 ivtkdisplay
ivtkdisplay c
~~~~~
-@figure{/user_guides/draw_test_harness/images/draw_image002.png}
+@figure{/user_guides/draw_test_harness/images/draw_image002.png,"",261}
+
@subsubsection occt_draw_4_6_3 ivtkerase
ivtksetdispmode c 1
~~~~~
-@figure{/user_guides/draw_test_harness/images/draw_image003.png}
-
+@figure{/user_guides/draw_test_harness/images/draw_image003.png,"",262}
+
@subsubsection occt_draw_4_6_6 ivtksetselmode
Syntax:
ivtksetselmode a 4 1
~~~~~
-@figure{/user_guides/draw_test_harness/images/draw_image004.png}
+@figure{/user_guides/draw_test_harness/images/draw_image004.png,"",291}
@subsubsection occt_draw_4_6_7 ivtkmoveto
ivtkbgcolor 200 220 250
~~~~~
-@figure{/user_guides/draw_test_harness/images/draw_image005.png}
+@figure{/user_guides/draw_test_harness/images/draw_image005.png,"",196}
~~~~~
ivtkbgcolor 10 30 80 255 255 255
~~~~~
-@figure{/user_guides/draw_test_harness/images/draw_image006.png}
-
+@figure{/user_guides/draw_test_harness/images/draw_image006.png,"",190}
@section occt_draw_5 OCAF commands
-
This chapter contains a set of commands for Open CASCADE Technology Application Framework (OCAF).
* Pointers to other object classes
Inside a package, two data types cannot bear the same name.
-@figure{/user_guides/foundation_classes/images/foundation_classes_image003.png, "Contents of a package"}
+@figure{/user_guides/foundation_classes/images/foundation_classes_image003.png,"Contents of a package",420}
**Methods** are either **functions** or **procedures**. Functions return an object, whereas procedures only communicate by passing arguments. In both cases, when the transmitted object is an instance manipulated by a handle, its identifier is passed. There are three categories of methods:
* **Object constructor** Creates an instance of the described class. A class will have one or more object constructors with various different arguments or none.
* Data types manipulated by handle (or reference)
* Data types manipulated by value
-@figure{/user_guides/foundation_classes/images/foundation_classes_image004.png, "Manipulation of data types"}
+@figure{/user_guides/foundation_classes/images/foundation_classes_image004.png,"Manipulation of data types",420}
A data type is implemented as a class. The class not only defines its data representation and the methods available on instances, but it also suggests how the instance will be manipulated.
* A variable of a type manipulated by value contains the instance itself.
* Types defined by classes not inheriting from *Standard_Transient*, whether directly or not.
Types which are manipulated by value behave in a more direct fashion than those manipulated by handle and thus can be expected to perform operations faster, but they cannot be stored independently in a file.
-@figure{/user_guides/foundation_classes/images/foundation_classes_image005.png, "Manipulation of a data type by value"}
+@figure{/user_guides/foundation_classes/images/foundation_classes_image005.png,"Manipulation of a data type by value",420}
@subsubsection occt_fcug_2_1_3 Types manipulated by reference (handle)
These are types defined by classes inheriting from the *Transient* class.
-@figure{/user_guides/foundation_classes/images/foundation_classes_image006.png, "Manipulation of a data type by reference"}
+@figure{/user_guides/foundation_classes/images/foundation_classes_image006.png,"Manipulation of a data type by reference",420}
@subsubsection occt_fcug_2_1_4 When is it necessary to use a handle?
This is a reasonable precision to pass to an approximation process as a limit of refinement of fitting. The approximation is greater than the other precisions because it is designed to be used when the time is at a premium. It has been provided as a reasonable compromise by the designers of the Approximation algorithm. The current value is *Confusion() * 10*.
Note that Approximation is greater than Confusion, so care must be taken when using Confusion in an approximation process.
+
The following diagram illustrates the structure of calls in reading IGES.
The highlighted classes produce OCCT geometry.
-@figure{/user_guides/iges/images/iges_image003.png, "The structure of calls in reading IGES"}
+@figure{/user_guides/iges/images/iges_image003.png,"The structure of calls in reading IGES",420}
@subsection occt_iges_2_8 Example
The following diagram illustrates the class structure in writing IGES.
The highlighted classes are intended to translate geometry.
-@figure{/user_guides/iges/images/iges_image004.png, "The class structure in writing IGES"}
+@figure{/user_guides/iges/images/iges_image004.png,"The class structure in writing IGES",420}
@subsection occt_iges_3_7 Example
where S is OStream.
+
The *Geom2dAPI_InterCurveCurve* class allows the evaluation of the intersection points (*gp_Pnt2d*) between two geometric curves (*Geom2d_Curve*) and the evaluation of the points of self-intersection of a curve.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image003.png, "Intersection and self-intersection of curves"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image003.png,"Intersection and self-intersection of curves",420}
In both cases, the algorithm requires a value for the tolerance (Standard_Real) for the confusion between two points. The default tolerance value used in all constructors is *1.0e-6.*
-@figure{/user_guides/modeling_algos/images/modeling_algos_image004.png, "Intersection and tangent intersection"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image004.png,"Intersection and tangent intersection",420}
The algorithm returns a point in the case of an intersection and a segment in the case of tangent intersection.
The expression of a tangency problem generally leads to several results, according to the relative positions of the solution and the circles or straight lines in relation to which the tangency constraints are expressed. For example, consider the following
case of a circle of a given radius (a small one) which is tangential to two secant circles C1 and C2:
-@figure{/user_guides/modeling_algos/images/modeling_algos_image058.png,"Example of a Tangency Constraint"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image058.png,"Example of a Tangency Constraint",360}
This diagram clearly shows that there are 8 possible solutions.
#### Exterior/Interior
It is not hard to define the interior and exterior of a circle. As is shown in the following diagram, the exterior is indicated by the sense of the binormal, that is to say the right side according to the sense of traversing the circle. The left side is therefore the interior (or "material").
-@figure{/user_guides/modeling_algos/images/modeling_algos_image006.png, "Exterior/Interior of a Circle"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image006.png,"Exterior/Interior of a Circle",220}
By extension, the interior of a line or any open curve is defined as the left side according to the passing direction, as shown in the following diagram:
-@figure{/user_guides/modeling_algos/images/modeling_algos_image007.png, "Exterior/Interior of a Line and a Curve"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image007.png,"Exterior/Interior of a Line and a Curve",220}
#### Orientation of a Line
It is sometimes necessary to define in advance the sense of travel along a line to be created. This sense will be from first to second argument.
The following figure shows a line, which is first tangent to circle C1 which is interior to the line, and then passes through point P1.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image008.png, "An Oriented Line"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image008.png,"An Oriented Line",220}
#### Line tangent to two circles
**Example 1 Case 1**
-@figure{/user_guides/modeling_algos/images/modeling_algos_image009.png, "Both circles outside"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image009.png,"Both circles outside",220}
Constraints:
Tangent and Exterior to C1.
**Example 1 Case 2**
-@figure{/user_guides/modeling_algos/images/modeling_algos_image010.png, "Both circles enclosed"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image010.png,"Both circles enclosed",220}
Constraints:
Tangent and Including C1.
**Example 1 Case 3**
-@figure{/user_guides/modeling_algos/images/modeling_algos_image011.png, "C1 enclosed, C2 outside"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image011.png,"C1 enclosed and C2 outside",220}
Constraints:
Tangent and Including C1.
**Example 1 Case 4**
-@figure{/user_guides/modeling_algos/images/modeling_algos_image012.png, "C1 outside, C2 enclosed"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image012.png,"C1 outside and C2 enclosed",220}
Constraints:
Tangent and Exterior to C1.
Tangent and Including C2.
**Example 1 Case 5**
-@figure{/user_guides/modeling_algos/images/modeling_algos_image013.png, "With no qualifiers specified"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image013.png,"Without qualifiers",220}
Constraints:
Tangent and Undefined with respect to C1.
The following four diagrams show the four cases in using qualifiers in the creation of a circle.
**Example 2 Case 1**
-@figure{/user_guides/modeling_algos/images/modeling_algos_image014.png, "Both solutions outside"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image014.png,"Both solutions outside",220}
Constraints:
Tangent and Exterior to C1.
**Example 2 Case 2**
-@figure{/user_guides/modeling_algos/images/modeling_algos_image015.png, "C2 encompasses C1"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image015.png,"C2 encompasses C1",220}
Constraints:
Tangent and Exterior to C1.
~~~~~
**Example 2 Case 3**
-@figure{/user_guides/modeling_algos/images/modeling_algos_image016.png, "Solutions enclose C2"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image016.png,"Solutions enclose C2",220}
Constraints:
Tangent and Exterior to C1.
~~~~~
**Example 2 Case 4**
-@figure{/user_guides/modeling_algos/images/modeling_algos_image017.png, "Solutions enclose C1"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image017.png,"Solutions enclose C1",220}
Constraints:
Tangent and Enclosing C1.
A case in point is the intersection of two fillets at a corner. If the radius of the fillet on one edge is different from that of the fillet on another, it becomes impossible to sew together all the edges of the resulting surfaces. This leaves a gap in the overall surface of the object which you are constructing.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image059.png,"Intersecting filleted edges with differing radiuses"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image059.png,"Intersecting filleted edges with differing radiuses",220}
These algorithms allow you to fill this gap from two, three or four curves. This can be done with or without constraints, and the resulting surface will be either a Bezier or a BSpline surface in one of a range of filling styles.
* *Coons* -- a rounded style with less depth than *Curved*
* *Curved* -- the style with the most rounded patches.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image018.png, "Intersecting filleted edges with different radii leave a gap, is filled by a surface"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image018.png,"Intersecting filleted edges with different radii leave a gap filled by a surface",274}
@subsubsection occt_modalg_2_5_5 Plate surfaces
The surface is built using a variational spline algorithm. It uses the principle of deformation of a thin plate by localised mechanical forces. If not already given in the input, an initial surface is calculated. This corresponds to the plate prior
to deformation. Then, the algorithm is called to calculate the final surface. It looks for a solution satisfying constraints and minimizing energy input.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image061.png,"Surface generated from two curves and a point"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image061.png,"Surface generated from two curves and a point",360}
The package *GeomPlate* provides the following services for creating surfaces respecting curve and point constraints:
The class *MakeApprox* allows converting a *GeomPlate* surface into a *Geom_BSplineSurface*.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image060.png,"Surface generated from four curves and a point"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image060.png,"Surface generated from four curves and a point",360}
Let us create a Plate surface and approximate it from a polyline as a curve constraint and a point constraint
*Geom2dAPI_ProjectPointOnCurve* allows calculation of all normals projected from a point (*gp_Pnt2d*) onto a geometric curve (*Geom2d_Curve*). The calculation may be restricted to a given domain.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image020.png, "Normals from a point to a curve"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image020.png,"Normals from a point to a curve",320}
The curve does not have to be a *Geom2d_TrimmedCurve*. The algorithm will function with any class inheriting *Geom2d_Curve*.
The class *GeomAPI_ProjectPointOnSurf* allows calculation of all normals projected from a point from *gp_Pnt* onto a geometric surface from *Geom_Surface*.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image021.png, "Projection of normals from a point to a surface"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image021.png,"Projection of normals from a point to a surface",360}
Note that the surface does not have to be of *Geom_RectangularTrimmedSurface* type.
The algorithm will function with any class inheriting *Geom_Surface*.
This feature might be useful if you need for instance to restore the shape from the wireframe model:
<table align="center">
<tr>
- <td>@figure{/user_guides/modeling_algos/images/modeling_algos_image062.png, "Wireframe model"}</td>
- <td>@figure{/user_guides/modeling_algos/images/modeling_algos_image063.png, "Faces of the model"}</td>
+ <td>@figure{/user_guides/modeling_algos/images/modeling_algos_image062.png,"Wireframe model",160}</td>
+ <td>@figure{/user_guides/modeling_algos/images/modeling_algos_image063.png,"Faces of the model",160}</td>
</tr>
</table>
<table align="center">
<tr>
- <td>@figure{/user_guides/modeling_algos/images/modeling_algos_image064.png, "Wireframe model"}</td>
- <td>@figure{/user_guides/modeling_algos/images/modeling_algos_image065.png, "Two faces (red face has a hole)"}</td>
+ <td>@figure{/user_guides/modeling_algos/images/modeling_algos_image064.png,"Wireframe model",160}</td>
+ <td>@figure{/user_guides/modeling_algos/images/modeling_algos_image065.png,"Two faces (red face has a hole)",160}</td>
</tr>
</table>
The following methods allow checking the validity of the shapes:
* *BOPTools_AlgoTools::IsMicroEdge* detects the small edges;
* *BOPTools_AlgoTools::ComputeTolerance* computes the correct tolerance of the edge on the face;
- * *BOPTools_AlgoTools::CorrectShapeTolerances* and *BOPTools_AlgoTools::CorrectTolerances* allows correcting the tolerances of the sub-shapes.
+ * *BOPTools_AlgoTools::CorrectShapeTolerances* and *BOPTools_AlgoTools::CorrectTolerances* allow correcting the tolerances of the sub-shapes.
* *BRepLib::FindValidRange* finds a range of 3d curve of the edge not covered by tolerance spheres of vertices.
-
+
@subsection occt_modalg_2_topo_tools_7 Taking a point inside the face
The following methods allow taking a point located inside the face:
where C is the domain of the edge; V1 is the first vertex oriented FORWARD; V2 is the second vertex oriented REVERSED; p1 and p2 are the parameters for the vertices V1 and V2 on the curve. The default tolerance is associated with this edge.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image022.png, "Basic Edge Construction"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image022.png,"Basic Edge Construction",220}
The following rules apply to the arguments:
The figure below illustrates two special cases, a semi-infinite edge and an edge on a periodic curve.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image023.png, "Infinite and Periodic Edges"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image023.png,"Infinite and Periodic Edges",220}
@subsubsection occt_modalg_3_2_2 Supplementary edge construction methods
The following example creates a rectangle centered on the origin of dimensions H, L with fillets of radius R. The edges and the vertices are stored in the arrays *theEdges* and *theVertices*. We use class *Array1OfShape* (i.e. not arrays of edges or vertices). See the image below.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image024.png, "Creating a Wire"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image024.png,"Creating a Wire",360}
~~~~~
#include <BRepBuilderAPI_MakeEdge.hxx>
TopoDS_Face F = BRepBuilderAPI_MakeFace(S,umin,umax,vmin,vmax);
~~~~~
-@figure{/user_guides/modeling_algos/images/modeling_algos_image025.png, "Basic Face Construction"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image025.png,"Basic Face Construction",360}
To make a face from the natural boundary of a surface, the parameters are not required:
The four methods to build a box are shown in the figure:
-@figure{/user_guides/modeling_algos/images/modeling_algos_image026.png, "Making Boxes"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image026.png,"Making Boxes",420}
@subsubsection occt_modalg_4_1_2 Wedge
*BRepPrimAPI_MakeWedge* class allows building a wedge, which is a slanted box, i.e. a box with angles. The wedge is constructed in much the same way as a box i.e. from three dimensions dx,dy,dz plus arguments or from an axis system, three dimensions, and arguments.
The first method is a particular case of the second with *xmin = 0, xmax = ltx, zmin = 0, zmax = dz*.
To make a centered pyramid you can use *xmin = xmax = dx / 2, zmin = zmax = dz / 2*.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image027.png, "Making Wedges"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image027.png,"Making Wedges",420}
@subsubsection occt_modalg_4_1_3 Rotation object
*BRepPrimAPI_MakeOneAxis* is a deferred class used as a root class for all classes constructing rotational primitives. Rotational primitives are created by rotating a curve around an axis. They cover the cylinder, the cone, the sphere, the torus, and the revolution, which provides all other curves.
The result of the OneAxis construction is a Solid, a Shell, or a Face. The face is the face covering the rotational surface. Remember that you will not use the OneAxis directly but one of the derived classes, which provide improved constructions. The following figure illustrates the OneAxis arguments.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image028.png, "MakeOneAxis arguments"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image028.png,"MakeOneAxis arguments",360}
@subsubsection occt_modalg_4_1_4 Cylinder
*BRepPrimAPI_MakeCylinder* class allows creating cylindrical primitives. A cylinder is created either in the default coordinate system or in a given coordinate system *gp_Ax2*. There are two constructions:
TopoDS_Face F =
BRepPrimAPI_MakeCylinder(axes,R,DY,PI/2.);
~~~~~
-@figure{/user_guides/modeling_algos/images/modeling_algos_image029.png, "Cylinder"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image029.png,"Cylinder",360}
@subsubsection occt_modalg_4_1_5 Cone
*BRepPrimAPI_MakeCone* class allows creating conical primitives. Like a cylinder, a cone is created either in the default coordinate system or in a given coordinate system (gp_Ax2). There are two constructions:
TopoDS_Solid S = BRepPrimAPI_MakeCone(R1,R2,H);
~~~~~
-@figure{/user_guides/modeling_algos/images/modeling_algos_image030.png, "Cone"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image030.png,"Cone",360}
@subsubsection occt_modalg_4_1_6 Sphere
*BRepPrimAPI_MakeSphere* class allows creating spherical primitives. Like a cylinder, a sphere is created either in the default coordinate system or in a given coordinate system *gp_Ax2*. There are four constructions:
Note that we could equally well choose to create Shells instead of Solids.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image031.png, "Examples of Spheres"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image031.png,"Examples of Spheres",420}
@subsubsection occt_modalg_4_1_7 Torus
* Two radii and two angles -- builds a wraparound torus segment between two radial planes. The angles a1, a2 must follow the relation 0 < a2 - a1 < 2*PI.
* Two radii and three angles -- a combination of two previous methods builds a portion of torus segment.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image032.png, "Examples of Tori"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image032.png,"Examples of Tori",420}
The following code builds four toroidal shells from two radii and three angles.
It is forbidden to sweep Solids and Composite Solids. A Compound generates a Compound with the sweep of all its elements.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image033.png, "Generating a sweep"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image033.png,"Generating a sweep",360}
*BRepPrimAPI_MakeSweep class* is a deferred class used as a root of the the following sweep classes:
* *BRepPrimAPI_MakePrism* -- produces a linear sweep
// semi-infinite
~~~~~
-@figure{/user_guides/modeling_algos/images/modeling_algos_image034.png, "Finite, infinite, and semi-infinite prisms"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image034.png,"Finite, infinite, and semi-infinite prisms",420}
@subsubsection occt_modalg_4_2_3 Rotational Sweep
*BRepPrimAPI_MakeRevol* class allows creating a rotational sweep from a shape, an axis (gp_Ax1), and an angle. The angle has a default value of 2*PI which means a closed revolution.
TopoDS_Solid R2 = BRepPrimAPI_MakeRevol(F,axis,ang);
~~~~~
-@figure{/user_guides/modeling_algos/images/modeling_algos_image035.png, "Full and partial rotation"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image035.png,"Full and partial rotation",420}
@section occt_modalg_5 Boolean Operations
| Common | all points in S1 and S2 |
| Cut S1 by S2| all points in S1 and not in S2 |
-@figure{/user_guides/modeling_algos/images/modeling_algos_image036.png, "Boolean Operations"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image036.png,"Boolean Operations",420}
From the viewpoint of Topology these are topological operations followed by blending (putting fillets onto edges created after the topological operation).
*BRepAlgoAPI_Section* performs the section, described as a *TopoDS_Compound* made of *TopoDS_Edge*.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image037.png, "Section operation"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image037.png,"Section operation",220}
~~~~~
TopoDS_Shape A = ..., TopoDS_ShapeB = ...;
A fillet description contains an edge and a radius. The edge must be shared by two faces. The fillet is automatically extended to all edges in a smooth continuity with the original edge. It is not an error to add a fillet twice, the last description holds.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image038.png, "Filleting two edges using radii r1 and r2."}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image038.png,"Filleting two edges using radii r1 and r2.",360}
In the following example a filleted box with dimensions a,b,c and radius r is created.
}
~~~~~
-@figure{/user_guides/modeling_algos/images/modeling_algos_image039.png, "Fillet with constant radius"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image039.png,"Fillet with constant radius",360}
#### Changing radius
}
~~~~~
-@figure{/user_guides/modeling_algos/images/modeling_algos_image040.png, "Fillet with changing radius"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image040.png,"Fillet with changing radius",360}
@subsection occt_modalg_6_1_2 Chamfer
Add(d1, d2, E, F) with d1 on the face F.
~~~~~
-@figure{/user_guides/modeling_algos/images/modeling_algos_image041.png, "Chamfer"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image041.png,"Chamfer",360}
@subsection occt_modalg_6_1_3 Fillet on a planar face
Result = SolidMaker.Shape();
~~~~~
-@figure{/user_guides/modeling_algos/images/modeling_algos_image042.png, "Shelling"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image042.png,"Shelling",420}
Also it is possible to create solid between shell, offset shell. This functionality can be called using *BRepOffsetAPI_MakeThickSolid::MakeThickSolidBySimple* method. The code below shows usage example:
}
~~~~~
-@figure{/user_guides/modeling_algos/images/modeling_algos_image043.png, "DraftAngle"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image043.png,"DraftAngle",420}
@subsection occt_modalg_7_4 Pipe Constructor
TopoDS_Shape Pipe = BRepOffsetAPI_MakePipe(Spine,Profile);
~~~~~
-@figure{/user_guides/modeling_algos/images/modeling_algos_image044.png, "Example of a Pipe"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image044.png,"Example of a Pipe",320}
@subsection occt_modalg_7_5 Evolved Solid
Sewing allows creation of connected topology (shells and wires) from a set of separate topological elements (faces and edges). For example, Sewing can be used to create of shell from a compound of separate faces.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image045.png, "Shapes with partially shared edges"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image045.png,"Shapes with partially shared edges",320}
It is important to distinguish between sewing and other procedures, which modify the geometry, such as filling holes or gaps, gluing, bending curves and surfaces, etc.
}
~~~~~
-@figure{/user_guides/modeling_algos/images/modeling_algos_image047.png, "Fusion with MakePrism"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image047.png,"Fusion with MakePrism",320}
-@figure{/user_guides/modeling_algos/images/modeling_algos_image048.png, "Creating a prism between two faces with Perform(From, Until)"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image048.png,"Creating a prism between two faces with Perform()",320}
@subsubsection occt_modalg_9_1_2 Draft Prism
TopoDS_Shape res1 = MKDP.Shape();
~~~~~
-@figure{/user_guides/modeling_algos/images/modeling_algos_image049.png, "A tapered prism"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image049.png,"A tapered prism",320}
@subsubsection occt_modalg_9_1_3 Revolution
TopoDS_Shape res1 = MKPipe.Shape();
~~~~~
-@figure{/user_guides/modeling_algos/images/modeling_algos_image050.png, "Pipe depression"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image050.png,"Pipe depression",240}
@subsection occt_modalg_9_2 Mechanical Features
TopoDS_Shape res = aform.Shape();
~~~~~
-@figure{/user_guides/modeling_algos/images/modeling_algos_image051.png, "Creating a rib"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image051.png,"Creating a rib",240}
@subsubsection occt_modalg_9_2_3 Gluer
* Infinite faces or lines are not processed.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image052.png, "Sharp, smooth and sewn edges in a simple screw shape"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image052.png,"Sharp, smooth and sewn edges in a simple screw shape",320}
-@figure{/user_guides/modeling_algos/images/modeling_algos_image053.png, "Outline edges and isoparameters in the same shape"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image053.png,"Outline edges and isoparameters in the same shape",320}
-@figure{/user_guides/modeling_algos/images/modeling_algos_image054.png, "A simple screw shape seen with shading"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image054.png,"A simple screw shape seen with shading",320}
-@figure{/user_guides/modeling_algos/images/modeling_algos_image055.png, "An extraction showing hidden sharp edges"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image055.png,"An extraction showing hidden sharp edges",320}
The following services are related to Hidden Lines Removal :
At the second step, the faces are tessellated. Linear deflection limits the distance between a curve and its tessellation, whereas angular deflection limits the angle between subsequent segments in a polyline.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image056.png, "Deflection parameters of BRepMesh_IncrementalMesh algorithm"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image056.png,"Deflection parameters of BRepMesh_IncrementalMesh algorithm",420}
Linear deflection limits the distance between triangles and the face interior.
-@figure{/user_guides/modeling_algos/images/modeling_algos_image057.png, "Linear deflection"}
+@figure{/user_guides/modeling_algos/images/modeling_algos_image057.png,"Linear deflection",420}
Note that if a given value of linear deflection is less than shape tolerance then the algorithm will skip this value and will take into account the shape tolerance.
Meshing covers a shape with a triangular mesh. Other than hidden line removal, you can use meshing to transfer the shape to another tool: a manufacturing tool, a shading algorithm, a finite element algorithm, or a collision algorithm.
You can obtain information on the shape by first exploring it. To access triangulation of a face in the shape later, use *BRepTool::Triangulation*. To access a polygon, which is the approximation of an edge of the face, use *BRepTool::PolygonOnTriangulation*.
+
The class *Interpolate* from *GeomAPI* package allows building a constrained 3D BSpline curve, defined by a table of points through which the curve passes. If required, the parameter values and vectors of the tangents can be given for each point in the table.
-@figure{/user_guides/modeling_data/images/modeling_data_image003.png, "Approximation of a BSpline from scattered points"}
+@figure{/user_guides/modeling_data/images/modeling_data_image003.png,"Approximation of a BSpline from scattered points",420}
This class may be instantiated as follows:
~~~~~
The class *MultiLine* allows defining a given number of multi-point constraints in order to build the multi-line, multiple lines passing through ordered multiple point constraints.
- @figure{/user_guides/modeling_data/images/modeling_data_image004.png, "Definition of a MultiLine using Multiple Point Constraints"}
+ @figure{/user_guides/modeling_data/images/modeling_data_image004.png,"Definition of a MultiLine using Multiple Point Constraints",240}
In this image:
* *Pi*, *Qi*, *Ri* ... *Si* can be 2D or 3D points.
*Note:* Geometric continuity (G1, G2) means that the curve can be reparametrized to have parametric (C1, C2) continuity.
-@figure{/user_guides/modeling_data/images/modeling_data_continuity_curves.svg, "Continuity of Curves"}
+@figure{/user_guides/modeling_data/images/modeling_data_continuity_curves.svg,"Continuity of Curves",420}
The following types of surface continuity are supported:
* C0 (*GeomAbs_C0*) - parametric continuity (the surface has no points or curves of discontinuity).
* C3 (*GeomAbs_C3*) - continuity of all derivatives till the third order.
* CN (*GeomAbs_CN*) - continuity of all derivatives till the N-th order (infinite order of continuity).
-@figure{/user_guides/modeling_data/images/modeling_data_continuity_surfaces.svg, "Continuity of Surfaces"}
+@figure{/user_guides/modeling_data/images/modeling_data_continuity_surfaces.svg,"Continuity of Surfaces",420}
Against single surface, the connection of two surfaces (see the figure above) defines its continuity in each intersection point only. Smoothness of connection is a minimal value of continuities on the intersection curve.
- *TopLoc_Datum3D* class provides the elementary reference coordinate, represented by a right-handed orthonormal system of axes or by a right-handed unitary transformation.
- *TopLoc_Location* class provides the composite reference coordinate made from elementary ones. It is a marker composed of a chain of references to elementary markers. The resulting cumulative transformation is stored in order to avoid recalculating the sum of the transformations for the whole list.
-@figure{/user_guides/modeling_data/images/modeling_data_image005.png, "Structure of TopLoc_Location"}
+@figure{/user_guides/modeling_data/images/modeling_data_image005.png,"Structure of TopLoc_Location",420}
Two reference coordinates are equal if they are made up of the same elementary coordinates in the same order. There is no numerical comparison. Two coordinates can thus correspond to the same transformation without being equal if they were not built from the same elementary coordinates.
A topological model can be considered as a graph of objects with adjacency relationships. When modeling a part in 2D or 3D space it must belong to one of the categories listed in the ShapeEnum enumeration. The TopAbspackage lists all the objects, which can be found in any model. It cannot be extended but a subset can be used. For example, the notion of solid is useless in 2D.
The terms of the enumeration appear in order from the most complex to the most simple, because objects can contain simpler objects in their description. For example, a face references its wires, edges, and vertices.
-@figure{/user_guides/modeling_data/images/modeling_data_image006.png, "ShapeEnum"}
+@figure{/user_guides/modeling_data/images/modeling_data_image006.png,"ShapeEnum",420}
@subsubsection occt_modat_5_2_2 Orientation
| INTERNAL | The interior includes both regions. The boundary lies inside the material. For example a surface inside a solid. |
| EXTERNAL | The interior includes neither region. The boundary lies outside the material. For example an edge in a wire-frame model. |
-@figure{/user_guides/modeling_data/images/modeling_data_image007.png, "Four Orientations"}
+@figure{/user_guides/modeling_data/images/modeling_data_image007.png,"Four Orientations",420}
The notion of orientation is a very general one, and it can be used in any context where regions or boundaries appear. Thus, for example, when describing the intersection of an edge and a contour it is possible to describe not only the vertex of intersection but also how the edge crosses the contour considering it as a boundary. The edge would therefore be divided into two regions: exterior and interior and the intersection vertex would be the boundary. Thus an orientation can be associated with an intersection vertex as in the following figure:
| INTERNAL | Touching from inside |
| EXTERNAL | Touching from outside |
-@figure{/user_guides/modeling_data/images/modeling_data_image008.png, "Four orientations of intersection vertices"}
+@figure{/user_guides/modeling_data/images/modeling_data_image008.png,"Four orientations of intersection vertices",420}
Along with the Orientation enumeration the *TopAbs* package defines four methods:
The UNKNOWN term has been introduced because this enumeration is often used to express the result of a calculation, which can fail. This term can be used when it is impossible to know if a point is inside or outside, which is the case with an open wire or face.
-@figure{/user_guides/modeling_data/images/modeling_data_image009.png, "The four states"}
+@figure{/user_guides/modeling_data/images/modeling_data_image009.png,"The four states",420}
The State enumeration can also be used to specify various parts of an object. The following figure shows the parts of an edge intersecting a face.
-@figure{/user_guides/modeling_data/images/modeling_data_image010.png, "State specifies the parts of an edge intersecting a face"}
+@figure{/user_guides/modeling_data/images/modeling_data_image010.png,"State specifies the parts of an edge intersecting a face",420}
@subsection occt_modat_5_3 Manipulating shapes and sub-shapes
The information specific to each shape (the geometric support) is always added by inheritance to classes deriving from **TopoDS_TShape**. The following figures show the example of a shell formed from two faces connected by an edge.
-@figure{/user_guides/modeling_data/images/modeling_data_image011.png, "Structure of a shell formed from two faces"}
+@figure{/user_guides/modeling_data/images/modeling_data_image011.png,"Structure of a shell formed from two faces",420}
-@figure{/user_guides/modeling_data/images/modeling_data_image012.png, "Data structure of the above shell"}
+@figure{/user_guides/modeling_data/images/modeling_data_image012.png,"Data structure of the above shell",420}
In the previous diagram, the shell is described by the underlying shape TS, and the faces by TF1 and TF2. There are seven edges from TE1 to TE7 and six vertices from TV1 to TV6.
The following figure shows a data structure containing two versions of a solid. The second version presents a series of identical holes bored at different positions. The data structure is compact and yet keeps all information on the sub-elements.
The three references from *TSh2* to the underlying face *TFcyl* have associated local coordinate systems, which correspond to the successive positions of the hole.
-@figure{/user_guides/modeling_data/images/modeling_data_image013.png, "Data structure containing two versions of a solid"}
+@figure{/user_guides/modeling_data/images/modeling_data_image013.png,"Data structure containing two versions of a solid",420}
Classes inheriting TopoDS_Shape
------------------------------
For example, in the wire in the image we want to recuperate the edges in the order {e1, e2, e3,e4, e5} :
-@figure{/user_guides/modeling_data/images/modeling_data_image014.png, "A wire composed of 6 edges."}
+@figure{/user_guides/modeling_data/images/modeling_data_image014.png,"A wire composed of 6 edges.",320}
*TopExp_Explorer*, however, recuperates the lines in any order.
BinTools::Write (aShape, "result_file.bin");
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
The relationship between OCAF and the Open CASCADE Technology (**OCCT**) Object Libraries can be seen in the image below.
-@figure{/user_guides/ocaf/images/ocaf_image003.svg, "OCCT Architecture"}
+@figure{/user_guides/ocaf/images/ocaf_image003.svg,"OCCT Architecture",360}
In the image, the OCAF (Open CASCADE Application Framework) is shown with black rectangles and OCCT Object Libraries required by OCAF are shown with white rectangles.
OCAF provides you with an object-oriented Application-Document-Attribute model consisting of C++ class libraries.
-@figure{ocaf_wp_image003.png, "The Application-Document-Attribute model"}
+@figure{ocaf_wp_image003.png,"The Application-Document-Attribute model",420}
@subsubsection occt_ocaf_1_2_1 Application
For example, to associate a texture to a face in a geometric model,
both the face and the texture are attached to the same reference-key.
-@figure{ocaf_image004.png, "Topology driven versus reference-key driven approaches"}
+@figure{ocaf_image004.png,"Topology driven versus reference-key driven approaches",360}
Reference-keys can be created in two ways:
The most important property is that a label’s entry is its persistent address in the data framework.
-@figure{/user_guides/ocaf/images/ocaf_image005.png, "A simple framework model"}
+@figure{/user_guides/ocaf/images/ocaf_image005.png,"A simple framework model",216}
In this image the circles contain tags of the corresponding labels. The lists of tags are located under the circles. The root label always has a zero tag.
Let's have a look at the example:
-@figure{ocaf_wp_image007.png, "The coffee machine"}
+@figure{ocaf_wp_image007.png,"The coffee machine",200}
In the image the application for designing coffee machines first allocates
a label for the machine unit. It then adds sub-labels for the main features
Later on, you can modify the handle's geometry without changing its color —
both remain attached to the same label.
-@figure{ocaf_wp_image005.png, "The data structure of the coffee machine"}
+@figure{ocaf_wp_image005.png,"The data structure of the coffee machine",361}
The nesting of labels is key to OCAF. This allows a label to have its own structure
with its local addressing scheme which can be reused in a more complex structure.
Another example is the application for designing table lamps. The first label is allocated to the lamp unit.
-@figure{/user_guides/ocaf/images/ocaf_image006.png}
+@figure{/user_guides/ocaf/images/ocaf_image006.png,"",200}
The root label cannot have brother labels. Consequently, various lamps in the framework allocation correspond to the sub-labels of the root label. This allows avoiding any confusion between table lamps in the data framework. Different lamp parts have different material, color and other attributes, so a child label of the lamp with the specified tags is allocated for each sub-unit of the lamp:
So, after the user changes the lamp design, only corresponding attributes are changed, but the label structure is maintained. The lamp shape must be recreated by new attribute values and attributes of the lamp shape must refer to a new shape.
-@figure{/user_guides/ocaf/images/ocaf_image007.png}
+@figure{/user_guides/ocaf/images/ocaf_image007.png,"",360}
The previous figure shows the table-lamps document structure: each child of the root label contains a lamp shape attribute and refers to the sub-labels, which contain some design information about corresponding sub-units.
* First point as *TDataStd_RealArray* (three values: X1, Y1 and Z1);
* Second point as *TDataStd_RealArray* (three values: X2, Y2 and Z2).
-@figure{/user_guides/ocaf/images/ocaf_image010.png, "Data tree for translation"}
+@figure{/user_guides/ocaf/images/ocaf_image010.png,"Data tree for translation",240}
If the type of transformation is changed to rotation, the data tree looks like this:
* Type of transformation <i>(gp_Rotation)</i> as *TDataStd_Integer*;
* Axis of rotation as *TDataStd_RealArray* (three values: DX, DY and DZ);
* Angle of rotation as *TDataStd_Real*.
-@figure{/user_guides/ocaf/images/ocaf_image011.png, "Data tree for rotation"}
+@figure{/user_guides/ocaf/images/ocaf_image011.png,"Data tree for rotation",240}
The attribute *TDataStd_UAttribute* with the chosen unique GUID identifies the data type. The interface class initialized by the label of this attribute allows access to the data container (type of transformation and the data of transformation according to the type).
which references the coffee pot of the first document
(the XLink contains the relative path of the coffee pot document and the entry of the coffee pot data [0:1] ).
-@figure{ocaf_wp_image006.png, "The coffee machine compound document"}
+@figure{ocaf_wp_image006.png,"The coffee machine compound document",360}
In this context, the end-user of the coffee machine application can open the coffee pot document,
modify the geometry of, for example, the reservoir, and overwrite the document without worrying
External links refer from one document to another. They allow you to update the copy of data framework later on.
-@figure{/user_guides/ocaf/images/ocaf_image012.png, "External links between documents"}
+@figure{/user_guides/ocaf/images/ocaf_image012.png,"External links between documents",360}
Note that documents can be copied with or without a possibility of updating an external link.
If a shape is newly created, then the old shape of a corresponding named shape is an empty shape. If a shape is deleted, then the new shape in this named shape is empty.
-@figure{/user_guides/ocaf/images/ocaf_image013.png}
+@figure{/user_guides/ocaf/images/ocaf_image013.png,"",455}
@subsection occt_ocaf_5_2 Shape attributes in data framework.
Consider the following example. Two boxes (solids) are fused into one solid (the result one). Initially each box was placed to the result label as a named shape, which has evolution PRIMITIVE and refers to the corresponding shape of the *TNaming_UsedShapes* map. The box result label has a material attribute and six child labels containing named shapes of Box faces.
-@figure{/user_guides/ocaf/images/ocaf_image014.png, "Resulting box"}
+@figure{/user_guides/ocaf/images/ocaf_image014.png,"Resulting box",200}
After the fuse operation a modified result is placed to a separate label as a named shape, which refers to the old shape (one of the boxes) and to the new shape resulting from the fuse operation, and has evolution MODIFY (see the following figure).
* sub-label with tag 1 -- modified faces from box 1,
* sub-label with tag 2 -- modified faces from box 2.
-@figure{/user_guides/ocaf/images/ocaf_image015.png}
+@figure{/user_guides/ocaf/images/ocaf_image015.png,"",360}
This is necessary and sufficient information for the functionality of the right naming mechanism: any sub-shape of the result can be identified unambiguously by name type and set of labels, which contain named shapes:
Let us consider an example: imagine a wooden plate. The job is to drive several nails in it:
-@figure{/user_guides/ocaf/images/ocaf_image020.png, "A nail driven in a wooden plate"}
+@figure{/user_guides/ocaf/images/ocaf_image020.png,"A nail driven in a wooden plate",360}
There may be several nails with different size and position. A **Hammer** should push each **Nail** exactly in the center point of the top surface. For this the user does the following:
* Makes several Nails of different height and diameter (according to the need),
Each function gives the topological naming some hints how to “re-solve” the selected sub-shapes:
* The Nail constructs a solid shape and puts each face of the shape into sub-labels:
-@figure{/user_guides/ocaf/images/ocaf_image021.png, "Distribution of faces through sub-labels of the Nail"}
+@figure{/user_guides/ocaf/images/ocaf_image021.png,"Distribution of faces through sub-labels of the Nail",185}
* The **Translator** moves a shape and registers modification for each face: it puts a pair: “old” shape -- “new” shape at a sub-label of each moving Nail. The “old” shape represents a face of the Nail at the initial position. The “new” shape -- is the same face, but at a new position:
-@figure{/user_guides/ocaf/images/ocaf_image022.png, "Registration of relocation of faces of a Nail"}
+@figure{/user_guides/ocaf/images/ocaf_image022.png,"Registration of relocation of faces of a Nail",240}
How does it work?
* The Hammer selects a face of a Nail calling *TNaming_Selector::Select()*. This call makes a unique name for the selected shape. In our example, it will be a direct reference to the label of the top face of the Nail (Face 1).
Certainly, other variants are also possible.
-@figure{ocaf_tree_wp_image003.png, "Allocation of all data as one array of double values"}
+@figure{ocaf_tree_wp_image003.png,"Allocation of all data as one array of double values",350}
The first approach to allocation of all data represented as one array of double values
saves initial memory and is easy to implement.
In this case we create 100 000 labels -- one label for each measurement point
and attach an array of double values to these labels:
-@figure{ocaf_tree_wp_image004.png, "Allocation of data of each measurement point as arrays of double values"}
+@figure{ocaf_tree_wp_image004.png,"Allocation of data of each measurement point as arrays of double values",288}
Now edition of data is safer as far as memory usage is concerned.
Change of value for one measurement point (any value: point co-ordinates, load, and so on)
The third case of allocation of data through OCAF tree is represented below:
-@figure{ocaf_tree_wp_image005.png, "Allocation of data into separate arrays of double values"}
+@figure{ocaf_tree_wp_image005.png,"Allocation of data into separate arrays of double values",354}
In this case sub-labels are involved and we can easily access the values of each measurement point,
load or matrix. We don’t need an interface class with methods of access to the data
In this case we implement the third variant of using the standard attributes (see picture 3),
but we use less memory (because we use only one attribute instead of three):
-@figure{ocaf_tree_wp_image006.png, "Allocation of data into newly created OCAF attribute"}
+@figure{ocaf_tree_wp_image006.png,"Allocation of data into newly created OCAF attribute",383}
The second variant of using standard OCAF attributes still has drawbacks:
when data is edited, OCAF backs-up all values of the measurement point.
The abstract class TPrsStd_Driver allows you to define your own driver classes. Simply redefine the Update method in your new class, which will rebuild the presentation.
If your driver is placed to the driver table with the unique driver GUID, then every time the viewer updates presentations with a GUID identical to your driver’s GUID, the *Update* method of your driver for these presentations must be called:
-@figure{/user_guides/ocaf/images/ocaf_image016.png}
+@figure{/user_guides/ocaf/images/ocaf_image016.png,"",420}
As usual, the GUID of a driver and the GUID of a displayed attribute are the same.
When you edit any application model, you have to regenerate the model by propagating the modifications. Each propagation step calls various algorithms. To make these algorithms independent of your application model, you need to use function services.
-@figure{/user_guides/ocaf/images/ocaf_image008.png, "Document structure"}
+@figure{/user_guides/ocaf/images/ocaf_image008.png,"Document structure",360}
Take, for example, the case of a modeling sequence made up of a box with the application of a fillet on one of its edges. If you change the height of the box, the fillet will need to be regenerated as well.
An application must implement its functions, function drivers and the common solver for parametric model creation. For example, check the following model:
-@figure{/user_guides/ocaf/images/ocaf_image017.png}
+@figure{/user_guides/ocaf/images/ocaf_image017.png,"",360}
The procedure of its creation is as follows:
* create a rectangular planar face *F* with height 100 and width 200;
Let us describe the usage of the Function Mechanism of Open CASCADE Application Framework on a simple example.
This example represents a "nail" composed by a cone and two cylinders of different radius and height:
-@figure{ocaf_functionmechanism_wp_image003.png, "A nail"}
+@figure{ocaf_functionmechanism_wp_image003.png,"A nail",160}
These three objects (a cone and two cylinders) are independent,
but the Function Mechanism makes them connected to each other and representing one object -- a nail.
The function of the cone is independent. The functions of the cylinders depend on the cone function.
The nail function depends on the results of all functions:
-@figure{ocaf_functionmechanism_wp_image005.png, "A graph of dependencies between functions"}
+@figure{ocaf_functionmechanism_wp_image005.png,"A graph of dependencies between functions",232}
Computation of the model starts with the cone function, then the long cylinder,
after that the header cylinder and, finally, the result is generated by the nail function at the end of function chain.
- creating a Cut (Box1, Box2) as a modification of Box1 and push it in DF;
- recovering the result from DF.
+
The following diagram shows dependencies of API packages:
-@figure{/user_guides/shape_healing/images/shape_healing_image009.svg, "Shape Healing packages"}
+@figure{/user_guides/shape_healing/images/shape_healing_image009.svg,"Shape Healing packages",420}
Each sub-domain has its own scope of functionality:
* analysis -- exploring shape properties, computing shape features, detecting violation of OCCT requirements (shape itself is not modified);
Let us correct the following wire:
-@figure{/user_guides/shape_healing/images/shape_healing_image013.png, "Initial shape"}
+@figure{/user_guides/shape_healing/images/shape_healing_image013.png,"Initial shape",420}
It is necessary to apply the @ref occt_shg_3_1_2 "tools for the analysis of wire validity" to check that:
* the edges are correctly oriented;
As the result all failures have been fixed.
-@figure{/user_guides/shape_healing/images/shape_healing_image014.png, "Resulting shape"}
+@figure{/user_guides/shape_healing/images/shape_healing_image014.png,"Resulting shape",420}
@subsubsection occt_shg_2_3_8 Repairing tool for edges
To see how this tool works, it is possible to take an edge, where the maximum deviation between the 3D curve and 2D curve P1 is greater than the edge tolerance.
-@figure{/user_guides/shape_healing/images/shape_healing_image011.png, "Initial shape"}
+@figure{/user_guides/shape_healing/images/shape_healing_image011.png,"Initial shape",420}
First it is necessary to apply the @ref occt_shg_3_1_3 "tool for checking the edge validity" to find that the maximum deviation between pcurve and 3D curve is greater than tolerance. Then we can use the repairing tool to increase the tolerance and make the deviation acceptable.
}
~~~~~
-@figure{/user_guides/shape_healing/images/shape_healing_image012.png, "Resulting shape"}
+@figure{/user_guides/shape_healing/images/shape_healing_image012.png,"Resulting shape",420}
As the result, the edge tolerance has been increased.
An example of using this tool is presented in the figures below:
-@figure{/user_guides/shape_healing/images/shape_healing_image003.png, "Source Face"}
+@figure{/user_guides/shape_healing/images/shape_healing_image003.png,"Source Face",240}
-@figure{/user_guides/shape_healing/images/shape_healing_image004.png, "Resulting shape"}
+@figure{/user_guides/shape_healing/images/shape_healing_image004.png,"Resulting shape",240}
*ShapeUpgrade_ShapeDivideArea* is inherited from the base class *ShapeUpgrade_ShapeDivide* and should be used in the following way:
An example of using this tool is presented in the figures below:
-@figure{/user_guides/shape_healing/images/shape_healing_image005.png, "Source Face"}
-@figure{/user_guides/shape_healing/images/shape_healing_image006.png, "Resulting shape"}
+@figure{/user_guides/shape_healing/images/shape_healing_image005.png,"Source Face",240}
+@figure{/user_guides/shape_healing/images/shape_healing_image006.png,"Resulting shape",240}
After the processing three internal wires with contour area less than the specified minimal area have been removed. One internal face has been removed. The outer wire of this face consists of the edges belonging to the removed internal wires and a seam edge.
Two other internal faces have not been removed because their outer wires consist not only of edges belonging to the removed wires.
-@figure{/user_guides/shape_healing/images/shape_healing_image007.png, "Source Face"}
+@figure{/user_guides/shape_healing/images/shape_healing_image007.png,"Source Face",240}
-@figure{/user_guides/shape_healing/images/shape_healing_image008.png, "Resulting shape"}
+@figure{/user_guides/shape_healing/images/shape_healing_image008.png,"Resulting shape",240}
After the processing six internal wires with contour area less than the specified minimal area have been removed. Six internal faces have been removed. These faces can be united into groups of faces. Each group of faces has an outer wire consisting only of edges belonging to the removed internal wires. Such groups of faces are also removed.
The default trace level can be changed by using method *SetDefLevel*. In this way, the information received in the log file is modified.
It is possible to close the log file and set the default trace output to the screen display instead of the log file using the method *SetDefault* without any arguments.
+
STEP is more and more widely used to exchange data between various software, involved in CAD, PDM, Analysis, etc... STEP is far more than an "exchange standard" : it provides a technology and a set of methodologies to describe the data to exchange in a modular and upgradeable way. Regarding OCCT, this mostly applies to CAD data but it is not a limitation, other kinds of data for specific applications can be addressed too.
-@figure{/user_guides/step/images/step_image002.png, "Image imported from STEP"}
+@figure{/user_guides/step/images/step_image002.png,"Image imported from STEP",240}
Open Cascade allows its users to employ STEP in the following domains:
* Exchange of data for technical applications, following the state-of-the-art definitions and rules;
The following diagram illustrates the structure of calls in reading STEP. The highlighted classes are intended to translate geometry
-@figure{/user_guides/step/images/step_image003.png, "The structure of calls in reading STEP"}
+@figure{/user_guides/step/images/step_image003.png,"The structure of calls in reading STEP",420}
@subsection occt_step_2_7 Example
~~~~~
The highlighted classes are intended to translate geometry.
-@figure{/user_guides/step/images/step_image004.png, "The structure of calls in writing STEP"}
+@figure{/user_guides/step/images/step_image004.png,"The structure of calls in writing STEP",420}
@subsection occt_step_3_7 Example
Saved Views are not exported by OCCT.
+
Logically the *TObj* data model is represented as a tree of model objects, with upper-level objects typically being collections of other objects (called *partitions*, represented by the class *TObj_Partition*). The root object of the model is called the *Main partition* and is maintained by the model itself. This partition contains a list of sub-objects called its *children* each sub-object may contain its own children (according to its type), etc.
-@figure{/user_guides/tobj/images/tobj_image003.png, "TObj Data Model"}
+@figure{/user_guides/tobj/images/tobj_image003.png,"TObj Data Model",240}
As the *TObj* Data Model is based on OCAF (Open CASCADE Application Framework) technology,
it stores its data in the underlying OCAF document. The OCAF document consists of a tree of
Generally the structure of the OCAF tree of the *TObj* data
model corresponds to the logical structure of the model and can be presented as in the following picture:
-@figure{/user_guides/tobj/images/tobj_image004.png, "TObj Data Model mapped on OCAF document"}
+@figure{/user_guides/tobj/images/tobj_image004.png,"TObj Data Model mapped on OCAF document",360}
All data of the model are stored in the root label (0:1) of the OCAF document.
An attribute *TObj_TModel* is located in this root label. It
basic approaches that are recommended for all descendants,
and provides tools to facilitate their usage.
-@figure{/user_guides/tobj/images/tobj_image005.png, "TObj objects hierarchy"}
+@figure{/user_guides/tobj/images/tobj_image005.png,"TObj objects hierarchy",170}
@subsection occt_tobj_3_1 Separation of data and interface
in the OCAF tree. *TObj_TObject* is a simple container for the object of type *TObj_Object*.
All objects (interfaces) of the data model inherit this class.
-@figure{/user_guides/tobj/images/tobj_image006.png, "TObj object stored on OCAF label"}
+@figure{/user_guides/tobj/images/tobj_image006.png,"TObj object stored on OCAF label",360}
@subsection occt_tobj_3_2 Basic features
and keeps reference to the main label of the referred object.
At the same time the referred object can maintain the back reference to the master object.
-@figure{/user_guides/tobj/images/tobj_image007.png, "Objects relationship"}
+@figure{/user_guides/tobj/images/tobj_image007.png,"Objects relationship",360}
The structure of *TObj* iterators hierarchy is presented below:
-@figure{/user_guides/tobj/images/tobj_image008.png, "Hierarchy of iterators"}
+@figure{/user_guides/tobj/images/tobj_image008.png,"Hierarchy of iterators",420}
@section occt_tobj_5 Packaging
* *TKBinL, TKXmlL* -- toolkits of binary and XML persistence
+
@section occt_vis_1 Introduction
VIS component provides adaptation functionality for visualization of OCCT topological shapes by means of VTK library. This User’s Guide describes how to apply VIS classes in application dealing with 3D visualization based on VTK library.
-@figure{/user_guides/vis/images/vis_image001.png}
+@figure{/user_guides/vis/images/vis_image001.png,"3D visualization based on VTK library",421}
There are two ways to use VIS in the application:
* Use a **high-level API**. It is a simple scenario to use VTK viewer with displayed OCCT shapes. It considers usage of tools provided with VIS component such as a specific VTK data source, a picker class and specific VTK filters. Basically, in this scenario you enrich your custom VTK pipeline with extensions coming from VIS.
* **IVtkVTK** -- implementation of interfaces related to VTK visualization toolkit;
* **IVtkTools** -- high-level tools designed for integration into VTK visualization pipelines.
-@figure{/user_guides/vis/images/vis_image002.png "Dependencies of VIS packages"}
+@figure{/user_guides/vis/images/vis_image002.png, "Dependencies of VIS packages",200}
The idea behind the mentioned organization of packages is separation of interfaces from their actual implementations by their dependencies from a particular library (OCCT, VTK). Besides providing of semantic separation, such splitting helps to avoid excessive dependencies on other OCCT toolkits and VTK.
* **IVtk** package does not depend on VTK libraries at all and needs OCCT libraries only because of collections usage (*TKernel* library);
* Implementation classes from **IVtkOCC** package depend on OCCT libraries only and do not need VTK;
* **IVtkVTK** package depends on VTK libraries only and does not need any OCCT functionality except collections.
-@figure{/user_guides/vis/images/vis_image003.png "Dependencies of VIS packages"}
+@figure{/user_guides/vis/images/vis_image003.png, "Dependencies of VIS packages", 240}
Basically, it is enough to use the first three packages in the end user’s application (*IVtk, IVtkOCC* and *IVtkVTK*) to be able to work with OCCT shapes in VTK viewer. However, *IVtkTools* package is also provided as a part of the component to make the work more comfortable.
@subsection occt_vis_3_3 Display modes
The output of the shape data source can be presented in wireframe or shading display mode. A specific filter from class *IVtkTools_DisplayModeFilter* can be applied to select the display mode. The filter passes only the cells corresponding to the given mode. The set of available modes is defined by *IVtk_DisplayMode* enumeration.
-@figure{/user_guides/vis/images/vis_image004.png}
+@figure{/user_guides/vis/images/vis_image004.png,"",360}
For example, the shading representation can be obtained in the following way:
TIP: to make the shading representation smooth, use additional *vtkPolyDataNormals* filter. This filter must be applied after the display mode filter.
-@figure{/user_guides/vis/images/vis_image005.png}
+@figure{/user_guides/vis/images/vis_image005.png,"",360}
@subsection occt_vis_3_4 Interactive selection
*IVtkTools* package provides *IVtkTools_ShapePicker* class to perform selection of OCCT shapes and sub-shapes in VTK viewer and access the picking results. The typical usage of *IVtkTools_ShapePicker* tool consists in the following sequence of actions:
WARNING: VIS picker essentially works on the initial topological data structures rather than on the actually visualized actors. This peculiarity allows VIS to take advantage of standard OCCT selection mechanism, but puts strict limitations on the corresponding visualization pipelines. Once constructed, the faceted shape representation should not be morphed or translated anyhow. Otherwise, the picking results will lose their associativity with the source geometry. E.g. you should never use *vtkTransform* filter, but rather apply OCCT isometric transformation on the initial model in order to work on already relocated facet. These limitations are often acceptable for CAD visualization. If not, consider usage of a custom VTK-style picker working on the actually visualized actors.
-@figure{/user_guides/vis/images/vis_image006.png}
+@figure{/user_guides/vis/images/vis_image006.png,"",420}
@subsubsection occt_vis_3_5 Selection of sub-shapes
The low-level scenario of VIS usage in VTK pipeline is shown in the figure below. The Mesher component produces shape facet (VTK polygonal data) using implementation of *IShapeData* interface. Then result can be retrieved from this implementation as a *vtkPolyData* instance.
-@figure{/user_guides/vis/images/vis_image007.svg "Low-level VIS usage with VTK"}
+@figure{/user_guides/vis/images/vis_image007.svg "Low-level VIS usage with VTK", 420}
The visualization pipeline for OCCT shape presentation can be initialized as follows:
1. Create an instance of *IShape* class initialized by OCCT topological shape:
*TKIVtkDraw* toolkit contains classes for embedding VIS functionality into DRAW Test Harness with possibility of simple interactions, including detection and highlighting.
* *IVtkDraw_HighlightAndSelectionPipeline* -- Creates VTK pipeline with OCCT shape data source and properly initialized VIS filters.
* *IVtkDraw_Interactor* -- Controls simple interactive actions, such as detection and selection of the displayed shapes.
+
The figure below presents a schematic overview of the relations between the key concepts and packages in visualization. Naturally, "Geometry & Topology" is just an example of application data that can be handled by *AIS*, and application-specific interactive objects can deal with any kind of data.
-@figure{visualization_image003.png, "Key concepts and packages in visualization"}
+@figure{visualization_image003.png,"Key concepts and packages in visualization",400}
To answer different needs of CASCADE users, this User's Guide offers the following three paths in reading it.
The shape is created using the *BRepPrimAPI_MakeWedge* command. An *AIS_Shape* is then created from the shape. When calling the *Display* command, the interactive context calls the Compute method of the presentable object to calculate the presentation data and transfer it to the viewer. See figure below.
-@figure{visualization_image004.svg, "Processes involved in displaying a presentable shape"}
+@figure{visualization_image004.svg,"Processes involved in displaying a presentable shape",400}
@subsection occt_visu_2_2 Selection
The purpose of entities is to define what parts of the object will be selectable in particular. Thus, any object that is meant to be selectable must be split into sensitive entities (one or several). For instance, to apply face selection to an object it is necessary to explode it into faces and use them for creation of a sensitive entity set.
-@figure{visualization_image005.png, "Example of a shape divided into sensitive entities"}
+@figure{visualization_image005.png,"Example of a shape divided into sensitive entities",400}
Depending on the user's needs, sensitive entities may be atomic (point or edge) or complex. Complex entities contain many sub-elements that can be handled by detection mechanism in a similar way (for example, a polyline stored as a set of line segments or a triangulation).
- 5 -- selection of the shells;
- 6 -- selection of the constituent solids.
-@figure{visualization_image006.png, "Hierarchy of references from sensitive entity to selectable object"}
+@figure{visualization_image006.png,"Hierarchy of references from sensitive entity to selectable object",400}
-@figure{visualization_image007.png, "The principle of entities organization within the selectable object"}
+@figure{visualization_image007.png,"The principle of entities organization within the selectable object",400}
<h4>Viewer selector</h4>
Selection manager is a high-level API to manipulate selection of all displayed objects. It handles all viewer selectors, activates and deactivates selection modes for the objects in all or particular selectors, manages computation and update of selections for each object. Moreover, it keeps selection structures updated taking into account applied changes.
-@figure{visualization_image008.png, "The relations chain between viewer selector and selection manager"}
+@figure{visualization_image008.png,"The relations chain between viewer selector and selection manager",400}
@subsubsection occt_visu_2_2_2 Algorithm
The frustum length is limited by near and far view volume planes and each plane is built parallel to the corresponding view volume plane.
-@figure{visualization_image009.png, "Rectangular frustum: a) after mouse move or click, b) after applying the rectangular selection"}
+@figure{visualization_image009.png,"",400}
-@figure{visualization_image010.png, "Triangular frustum set: a) user-defined polyline, b) triangulation of the polygon based on the given polyline, c) triangular frustum based on one of the triangles"}
+The image above shows the rectangular frustum: a) after mouse move or click, b) after applying the rectangular selection.
+
+@figure{visualization_image010.png,"",400}
+
+In the image above triangular frustum is set: a) by a user-defined polyline, b) by triangulation of the polygon based on the given polyline, c) by a triangular frustum based on one of the triangles.
<h4>BVH trees</h4>
The third level BVH tree is used for complex sensitive entities that contain many elements: for example, triangulations, wires with many segments, point sets, etc. It is built on demand for sensitive entities with under 800K sub-elements.
-@figure{visualization_image022.png, "Selection BVH tree hierarchy: from the biggest object-level (first) to the smallest complex entity level (third)"}
+@figure{visualization_image022.png,"Selection BVH tree hierarchy: from the biggest object-level (first) to the smallest complex entity level (third)",400}
<h4>Stages of the algorithm</h4>
**Interactive Objects** are the entities, which are visualized and selected. You can use classes of standard interactive objects for which all necessary functions have already been programmed, or you can implement your own classes of interactive objects, by respecting a certain number of rules and conventions described below.
-@figure{visualization_image016.png}
+@figure{visualization_image016.png,"",240}
An Interactive Object is a "virtual" entity, which can be presented and selected. An Interactive Object can have a certain number of specific graphic attributes, such as visualization mode, color and material.
When an Interactive Object is visualized, the required graphic attributes are taken from its own **Drawer** if it has the required custom attributes or otherwise from the context drawer.
-@figure{visualization_image017.png}
+@figure{visualization_image017.png,"",360}
It can be necessary to filter the entities to be selected. Consequently there are **Filter** entities, which allow refining the dynamic detection context. Some of these filters can be used at the Neutral Point, others only in an open local context. It is possible to program custom filters and load them into the interactive context.
By convention, the default mode of representation for the Interactive Object has index 0.
-@figure{visualization_image018.png}
+@figure{visualization_image018.png,"",360}
Calculation of different presentations of an interactive object is done by the *Compute* functions inheriting from *PrsMgr_ PresentableObject::Compute* functions. They are automatically called by *PresentationManager* at a visualization or an update request.
* By default, the interactive object takes the graphic attributes of the context in which it is visualized (visualization mode, deflection values for the calculation of presentations, number of isoparameters, color, type of line, material, etc.)
* In the *AIS_InteractiveObject* abstract class, standard attributes including color, line thickness, material, and transparency have been privileged. Consequently, there is a certain number of virtual functions, which allow acting on these attributes. Each new class of interactive object can redefine these functions and change the behavior of the class.
-@figure{visualization_image019.png, "Figure 13. Redefinition of virtual functions for changes in AIS_Point"}
+@figure{visualization_image019.png,"Redefinition of virtual functions for changes in AIS_Point",360}
-@figure{visualization_image020.png, "Figure 14. Redefinition of virtual functions for changes in AIS_Shape."}
+@figure{visualization_image020.png,"Redefinition of virtual functions for changes in AIS_Shape.",360}
The following virtual functions provide settings for color, width, material and transparency:
* *AIS_InteractiveObject::UnsetColor*
See how proxy *OpenGl_Structure* is used to represent instance:
-@figure{/user_guides/visualization/images/visualization_image029.png}
+@figure{/user_guides/visualization/images/visualization_image029.png,"",240}
The original object does not have to be displayed in order to make instance. Also selection handles transformations of instances correctly:
vfit
~~~~~
-@figure{/user_guides/visualization/images/visualization_image030.png}
+@figure{/user_guides/visualization/images/visualization_image030.png,"",420}
Here is the example of a more complex hierarchy involving sub-assemblies:
- The type of point marker used to draw points can be specified as a presentation aspect.
- The presentation provides selection by a bounding box of the visualized set of points. It supports two display / highlighting modes: points or bounding box.
-@figure{point_cloud.png, "A random colored cloud of points"}
+@figure{point_cloud.png,"A random colored cloud of points",240}
Example:
~~~~~
@subsubsection occt_visu_4_4_4 Orthographic Projection
-@figure{view_frustum.png, "Perspective and orthographic projection"}
+@figure{view_frustum.png,"Perspective and orthographic projection",420}
The following code configures the camera for orthographic rendering:
**Field of view (FOVy)** -- defines the field of camera view by y axis in degrees (45° is default).
-@figure{camera_perspective.png, "Perspective frustum"}
+@figure{camera_perspective.png,"Perspective frustum",420}
The following code configures the camera for perspective rendering:
**ZFocus** -- defines the distance to the point of stereographic focus.
-@figure{stereo.png, "Stereographic projection"}
+@figure{stereo.png,"Stereographic projection",420}
To enable stereo projection, your workstation should meet the following requirements:
Visual attributes of the <i>MeshVS_Mesh</i> object (such as shading color, shrink coefficient and so on) are controlled through <i>MeshVS_Drawer</i> object. It maintains a map "Attribute ID --> attribute value" and can be easily extended with any number of custom attributes.
In all other respects, <i>MeshVS_Mesh</i> is very similar to any other class derived from <i>AIS_InteractiveObject</i> and it should be used accordingly (refer to the description of <i>AIS package</i> in the documentation).
+
Finally, the XDE provides reader and writer tools for reading and writing the data supported by XCAF to and from IGES and STEP files.
-@figure{/user_guides/xde/images/646_xde_11_400.png,"Shape imported using XDE"}
+@figure{/user_guides/xde/images/646_xde_11_400.png,"Shape imported using XDE",240}
The XDE component requires @ref occt_user_guides__shape_healing "Shape Healing" toolkit for operation.
XDE supports assemblies by separating shape definitions and their locations. Shapes are simple OCAF objects without a location definition. An assembly consists of several components. Each of these components references one and the same specified shape with different locations. All this provides an increased flexibility in working on multi-level assemblies.
For example, a mechanical assembly can be defined as follows:
-@figure{/user_guides/xde/images/xde_image003.png, "Assembly Description"}
+@figure{/user_guides/xde/images/xde_image003.png,"Assembly Description",240}
-@figure{/user_guides/xde/images/xde_image004.png, "Assembly View"}
+@figure{/user_guides/xde/images/xde_image004.png,"Assembly View",240}
XDE defines the specific organization of the assembly content. Shapes are stored on sub-labels of label 0:1:1. There can be one or more roots (called free shapes) whether they are true trees or simple shapes. A shape can be considered to be an Assembly (such as AS1 under 0:1:1:1 in Figure1) if it is defined with Components (sub-shapes, located or not).
Advanced Data Exchange supports both reading and writing of validation properties, and provides a tool to check them.
-@figure{/user_guides/xde/images/xde_image005.png, "Validation Property Descriptions"}
+@figure{/user_guides/xde/images/xde_image005.png,"Validation Property Descriptions",240}
Check logs contain deviations of computed values from the values stored in a STEP file. A typical example appears as follows:
XDE supports reading and writing the names of shapes to and from IGES and STEP file formats. This functionality can be switched off if you do not need this type of data, thereby reducing the size of the document.
-@figure{/user_guides/xde/images/614_xde_04_400.png, "Instance Names"}
+@figure{/user_guides/xde/images/614_xde_04_400.png,"Instance Names",360}
@subsection occt_xde_1_6 Colors and Layers
XDE can read and write colors and layers assigned to shapes or their subparts (down to the level of faces and edges) to and from both IGES and STEP formats. Three types of colors are defined in the enumeration *XCAFDoc_ColorType*:
* surface color <i>(XCAFDoc_ColorSurf)</i>
* curve color <i>(XCAFDoc_ColorCurv)</i>
- @figure{/user_guides/xde/images/xde_image006.png, "Colors and Layers"}
+ @figure{/user_guides/xde/images/xde_image006.png,"Colors and Layers",240}
@section occt_xde_2 Working with XDE
XDE can read and write colors and layers assigned to shapes or their subparts (down to level of faces and edges) to and from both IGES and STEP formats.
-@figure{/user_guides/xde/images/239_xde_12_400.png,"Motor Head"}
+@figure{/user_guides/xde/images/239_xde_12_400.png,"Motor Head",240}
In an XDE document, colors are managed by the class *XCAFDoc_ColorTool*. This is done with the same principles as for ShapeTool with Shapes, and with the same capability of having a tool on the Main Label, or on any sub-label. The Property itself is defined as an *XCAFDoc_Color*, sub-class of *TDF_Attribute*.
As a result, if an application works on Assemblies, on Colors or Layers, on Validation Properties (as defined in STEP), it can rely on all or a part of the XDE definitions, and include them in its own data structure.
In addition, if an application has a data structure far from these notions, it can get data (such as Colors and Names on Shapes) according to its needs, but without having to consider the whole.
+
projects / occt-copy.git / commitdiff