OpenCascade/occt
1
0
Fork 0
mirror of https://git.dev.opencascade.org/repos/occt.git synced 2025-04-03 17:56:21 +03:00
Code Packages Releases Activity

0028654: Existed tool (gendoc) for generation documentation does not take into account size of images.

Browse Source 
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.
This commit is contained in:
ysn 2017-06-02 11:55:34 +03:00 committed by bugmaster
parent 26e0b3353c
commit d6b4d3d0d5
20 changed files with 478 additions and 562 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
adm/gendoc.tcl
View File

@ -29,7 +29,7 @@ source [file join [file dirname [info script]] occaux.tcl]
# 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 ""
@ -57,7 +57,6 @@ proc OCCDoc_PrintHelpMessage {} {
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
@ -70,7 +69,6 @@ proc gendoc {args} {
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"
@ -199,8 +197,6 @@ proc gendoc {args} {
} 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
@ -317,19 +313,19 @@ proc gendoc {args} {
# 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
}
}
}
@ -340,14 +336,14 @@ proc gendoc {args} {
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
@ -465,14 +461,6 @@ proc OCCDoc_Main {docType {docfiles {}} {modules {}} generatorMode verboseMode u
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}]

99
adm/occaux.tcl
View File

@ -899,101 +899,4 @@ proc OCCDoc_ProcessTex {{texFiles {}} {latexDir} verboseMode} {
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
}
}
}

5
dox/dev_guides/contribution_workflow/contribution_workflow.md
View File

@ -35,7 +35,7 @@ According to his access level, the user can participate in the issue handling pr
@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
@ -280,7 +280,7 @@ Each change is integrated as a single commit without preserving the history of c
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.
@ -461,3 +461,4 @@ The category corresponds to the component of OCCT where the issue is found:
| 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. |

21
dox/dev_guides/documentation/documentation.md
View File

@ -30,7 +30,7 @@ You can use *custom.bat* file to add necessary paths to the *PATH* variable.
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.).
@ -102,7 +102,7 @@ The MarkDown files have a <i>*.md</i> extension and are based on rules described
@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.
@ -112,7 +112,7 @@ If you want to use the same image for several documents, you can place it in *do
@verbatim
@figure{/dev_guides/documentation/images/documentation_test_image.svg}
@figure{/dev_guides/documentation/images/documentation_test_image.svg,"",420}
@endverbatim
@ -140,13 +140,13 @@ dev_guides/svn/svn.md
@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
@ -389,7 +389,7 @@ Example:
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.
@ -399,11 +399,10 @@ Note that the image that will be included in documentation is the whole page of
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.
@ -482,4 +481,4 @@ gives the following result:
@endverbatim
that leads to the following result: @f$ \sqrt{3x-1}+(1+x)^2 @f$

37
dox/dev_guides/git_guide/git_guide.md
View File

@ -124,7 +124,7 @@ The official repository contains:
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}
@ -137,7 +137,7 @@ The official repository contains:
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
@ -188,7 +188,7 @@ The official repository contains:
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.
@ -292,7 +292,7 @@ Click **Save** to input the key to the system.
* 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.
@ -317,7 +317,7 @@ In TortoiseGit:
* 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.
@ -332,7 +332,7 @@ In TortoiseGit:
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.
@ -366,7 +366,7 @@ In TortoiseGit:
* 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).
@ -384,13 +384,13 @@ In TortoiseGit:
* 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:
@ -410,7 +410,7 @@ Note that Git forbids pushing a branch if the corresponding remote branch alread
* 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.
@ -423,7 +423,7 @@ Note that Git forbids pushing a branch if the corresponding remote branch alread
* 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.
@ -436,7 +436,7 @@ Remove the local branches that you do not need any more. Note that you cannot de
* 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.
@ -450,13 +450,13 @@ If you have a fix made on a previous version of OCCT, perform the following sequ
* 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.
@ -473,16 +473,16 @@ To rebase your branch into a single commit, you need to do the following:
* 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
@ -508,5 +508,6 @@ To rebase your branch into a single commit, you need to do the following:
* 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}

3
dox/dev_guides/tests/tests.md
View File

@ -242,7 +242,7 @@ The names *begin, end, data, parse.rules, grids.list* and *cases.list* are reser
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
@ -1406,3 +1406,4 @@ Use options <i>-tol_\* </i> for that.
~~~~~
checktrinfo result -defl 1 -tol_abs_defl 0.001
~~~~~

39
dox/tutorial/tutorial.md
View File

@ -18,7 +18,7 @@ From a programming standpoint, Open CASCADE Technology is designed to enhance yo
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.
@ -34,7 +34,7 @@ We first define the bottle specifications as follows:
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:
@ -50,7 +50,7 @@ This modeling requires four steps:
To create the bottle's profile, you first create characteristic points with their coordinates as shown below in the (XOY) plane. These points will be the supports that define the geometry of the profile.
@figure{tutorial/images/tutorial_image003.svg}
@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:
@ -83,7 +83,7 @@ Standard_Real xValue1 = aPnt1.X();
@subsection OCCT_TUTORIAL_SUB2_2 Profile: Defining the Geometry
With the help of the previously defined points, you can compute a part of the bottle's profile geometry. As shown in the figure below, it will consist of two segments and one arc.
@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*).
@ -139,7 +139,7 @@ Referring to the previous table, to build the profile, you will create:
* Three edges out of the previously computed curves.
* One wire with these edges.
@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:
@ -177,7 +177,7 @@ Once the first part of your wire is created you need to compute the complete pro
* 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.
@ -260,7 +260,7 @@ To compute the main body of the bottle, you need to create a solid shape. The si
| 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.
@ -297,7 +297,7 @@ For our purposes, we will specify that fillets must be:
* 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:
@ -353,7 +353,7 @@ Once this is done, you perform the last step of the procedure by asking for the
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:
@ -395,7 +395,7 @@ In Open CASCADE Technology, a hollowed solid is called a *Thick* *Solid* and is
* 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:
@ -500,7 +500,7 @@ As a first step, you compute these cylindrical surfaces. You are already familia
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.
@ -525,7 +525,7 @@ P(U, V) = O + R * (cos(U) * xDir + sin(U) * yDir) + V * zDir, where :
* 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:
@ -534,7 +534,7 @@ The advantage of having such parameterized geometries is that you can compute, f
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:
@ -549,14 +549,14 @@ The helicoidal curve type is exactly what you need. On the neck's surface, the e
* 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:
@ -572,7 +572,7 @@ To use 2D primitive geometry types of Open CASCADE Technology for defining a poi
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:
@ -628,7 +628,7 @@ As you did when creating the base profile of the bottle, you can now:
* compute the edges of the neck's threading.
* compute two wires out of these edges.
@figure{/tutorial/images/tutorial_image017.png}
@figure{/tutorial/images/tutorial_image017.png,"",440}
Previously, you have built:
@ -668,7 +668,7 @@ You have computed the wires of the threading. The threading will be a solid shap
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.
@ -698,7 +698,7 @@ You are almost done building the bottle. Use the *TopoDS_Compound* and *BRep_Bui
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.
@ -847,3 +847,4 @@ Complete definition of MakeBottle function (defined in the file src/MakeBottle.c
return aRes;
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

452
dox/user_guides/boolean_operations/boolean_operations.md
View File

File diff suppressed because it is too large Load Diff

17
dox/user_guides/draw_test_harness/draw_test_harness.md
View File

@ -2785,7 +2785,7 @@ ivtkinit
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
@ -2804,7 +2804,8 @@ pcone c 5 0 10
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
@ -2862,8 +2863,8 @@ ivtkdisplay c
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:
@ -2884,7 +2885,7 @@ ivtkdisplay a
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
@ -2957,18 +2958,16 @@ ivtkinit
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).

9
dox/user_guides/foundation_classes/foundation_classes.md
View File

@ -111,7 +111,7 @@ Data types described in a package may include one or more of the following data
* 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.
@ -142,7 +142,7 @@ The data types in Open CASCADE Technology fall into two categories:
* 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.
@ -211,13 +211,13 @@ There are three categories of types which are manipulated by value:
* 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?
@ -1910,3 +1910,4 @@ This is reasonable precision to pass to an Intersection process as a limit of r
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.

5
dox/user_guides/iges/iges.md
View File

@ -601,7 +601,7 @@ Class *ShapeFix_Wire* can increase the tolerance of a shape. This class is used
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
@ -819,7 +819,7 @@ If the value of parameter *write.precision.mode* is -1, 0 or 1, resolution is c
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
@ -1198,3 +1198,4 @@ IFSelect_ReturnStatus statw = writer.WriteFile (S);
where S is OStream.

125
dox/user_guides/modeling_algos/modeling_algos.md
View File

@ -28,11 +28,11 @@ The Intersections component is used to compute intersections between 2D or 3D ge
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.
@ -211,7 +211,7 @@ The implemented algorithms are more complex than those provided by the Direct Co
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.
@ -264,18 +264,18 @@ The following analytic algorithms using value-handled entities for creation of 2
#### 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 &quot;material&quot;).
@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
@ -284,7 +284,7 @@ The following four diagrams illustrate four cases of using qualifiers in the cr
**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.
@ -301,7 +301,7 @@ GccAna_Lin2d2Tan
**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.
@ -318,7 +318,7 @@ GccAna_Lin2d2Tan
**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.
@ -334,7 +334,7 @@ GccAna_Lin2d2Tan
**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.
@ -349,7 +349,7 @@ GccAna_Lin2d2Tan
**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.
@ -367,7 +367,7 @@ GccAna_Lin2d2Tan
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.
@ -382,7 +382,7 @@ GccAna_Circ2d2TanRad
**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.
@ -396,7 +396,7 @@ GccAna_Circ2d2TanRad
~~~~~
**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.
@ -410,7 +410,7 @@ GccAna_Circ2d2TanRad
~~~~~
**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.
@ -558,7 +558,7 @@ This is done by the class *GeomFill_ConstrainedFilling*, which allows filling a
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.
@ -578,7 +578,7 @@ The enumerations *FillingStyle* specify the styles used to build the surface. Th
* *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
@ -590,7 +590,7 @@ curve constraints and the point constraint respectively. The resulting surface c
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:
@ -616,7 +616,7 @@ The class *Surface* allows describing the characteristics of plate surface objec
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
@ -685,7 +685,7 @@ Projections provide for computing the following:
*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*.
@ -919,7 +919,7 @@ Extrema_ExtPC& TheExtrema = Projector.Extrema();
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*.
@ -1070,8 +1070,8 @@ It is possible to create the planar faces from the arbitrary set of planar edges
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>
@ -1109,8 +1109,8 @@ The wires located in the same plane and completely included into other wires wil
<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>
@ -1146,9 +1146,9 @@ The following methods allow building PCurves of edges on faces:
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:
@ -1323,7 +1323,7 @@ TopoDS_Edge E = BRepBuilderAPI_MakeEdge(C,V1,V2,p1,p2);
where C is the domain of the edge; V1 is the first vertex oriented FORWARD; V2 is the second vertex oriented REVERSED; p1 and p2 are the parameters for the vertices V1 and V2 on the curve. The default tolerance is associated with this edge.
@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:
@ -1349,7 +1349,7 @@ 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
@ -1424,7 +1424,7 @@ The *Error* method returns a term of the *BRepBuilderAPI_EdgeError* enumeration
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>
@ -1553,7 +1553,7 @@ Standard_Real umin,umax,vmin,vmax; // parameters
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:
@ -1771,7 +1771,7 @@ TopoDS_Solid theBox = BRepPrimAPI_MakeBox(10.,20.,30.);
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.
@ -1781,7 +1781,7 @@ The following figure shows two ways to build wedges. One is to add a dimension
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.
@ -1794,7 +1794,7 @@ The particular constructions of these primitives are described, but they all ha
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:
@ -1813,7 +1813,7 @@ axes.Translate(gp_Vec(X,Y,Z));
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:
@ -1828,7 +1828,7 @@ Standard_Real R1 = 30, R2 = 10, H = 15;
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:
@ -1851,7 +1851,7 @@ TopoDS_Solid S4 = BRepPrimAPI_MakeSphere(R,a1,a2,ang);
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
@ -1862,7 +1862,7 @@ Note that we could equally well choose to create Shells instead of Solids.
* 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.
@ -1902,7 +1902,7 @@ Sweeps are the objects you obtain by sweeping a **profile** along a **path**. T
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
@ -1932,7 +1932,7 @@ TopoDS_Solid P3 = BRepPrimAPI_MakePrism(F,direc,Standard_False);
// 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.
@ -1948,7 +1948,7 @@ TopoDS_Solid R1 = BRepPrimAPI_MakeRevol(F,axis);
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
@ -1960,7 +1960,7 @@ Boolean operations are used to create new shapes from the combinations of two s
| 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).
@ -2011,7 +2011,7 @@ TopoDS_Shape S = BRepAlgoAPI_Cut(A,B);
*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 = ...;
@ -2039,7 +2039,7 @@ To produce a fillet, it is necessary to define the filleted shape at the constru
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.
@ -2073,7 +2073,7 @@ TopoDS_Shape FilletedBox(const Standard_Real a,
}
~~~~~
@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
@ -2101,7 +2101,7 @@ void CSampleTopologicalOperationsDoc::OnEvolvedblend1()
}
~~~~~
@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
@ -2116,7 +2116,7 @@ Add(dist, E, F)
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
@ -2239,7 +2239,7 @@ if (SolidMaker.IsDone())
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:
@ -2300,7 +2300,7 @@ else {
}
~~~~~
@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
@ -2314,7 +2314,7 @@ TopoDS_Shape Profile = ...;
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
@ -2345,7 +2345,7 @@ BRepOffsetAPI_MakeEvolved(Spine,Profile);
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.
@ -2531,9 +2531,9 @@ if (thePrism.IsDone()) {
}
~~~~~
@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
@ -2586,7 +2586,7 @@ MKDP.Perform(200);
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
@ -2696,7 +2696,7 @@ MKPipe.Perform();
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
@ -2756,7 +2756,7 @@ aform.Perform();
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
@ -2840,13 +2840,13 @@ However, there some restrictions in HLR use:
* 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 :
@ -3017,11 +3017,11 @@ At the first step all edges from a face are discretized according to the specifi
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.
@ -3034,3 +3034,4 @@ However, an application that imports models created in other applications may no
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*.

29
dox/user_guides/modeling_data/modeling_data.md
View File

@ -49,7 +49,7 @@ The class *Interpolate* from *Geom2dAPI* package allows building a constrained 2
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:
~~~~~
@ -109,7 +109,7 @@ The following low level services are provided:
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.
@ -616,7 +616,7 @@ In respect of curves, the following types of continuity are supported (see the f
*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).
@ -627,7 +627,7 @@ The following types of surface continuity are supported:
* 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.
@ -774,7 +774,7 @@ A local coordinate system can be viewed as either of the following:
- *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.
@ -818,7 +818,7 @@ TopAbs contains the *TopAbs_ShapeEnum* enumeration,which lists the different top
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
@ -844,7 +844,7 @@ Based on this default region the orientation allows definition of the region to
| 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:
@ -855,7 +855,7 @@ The notion of orientation is a very general one, and it can be used in any conte
| 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:
@ -873,11 +873,11 @@ The **TopAbs_State** enumeration described the position of a vertex or a set of
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
@ -903,9 +903,9 @@ The class representing the underlying abstract shape is never referenced directl
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.
@ -922,7 +922,7 @@ The compact data structure avoids the loss of information associated with copy o
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
------------------------------
@ -1263,7 +1263,7 @@ Below is the auxiliary function, which copies the element of rank *i* from the m
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.
@ -1293,3 +1293,4 @@ The following sample code reads a shape from ASCII file and writes it to a binar
BinTools::Write (aShape, "result_file.bin");
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

55
dox/user_guides/ocaf/ocaf.md
View File

@ -55,7 +55,7 @@ OCAF uses other modules of Open CASCADE Technology — the Shape is implemented
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.
@ -65,7 +65,7 @@ The subsequent chapters of this document explain the concepts and show how to us
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
@ -133,7 +133,7 @@ In addition, application-specific data can be added by defining new attribute c
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:
@ -213,7 +213,7 @@ The sub-labels of a label are called its children. Conversely, each label, which
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.
@ -225,7 +225,7 @@ List of tags of the right-bottom label is "0:3:4": this label has tag 4, its fat
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
@ -237,7 +237,7 @@ Let's have a look at the example:
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.
@ -251,7 +251,7 @@ Let's have a look at the example:
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:
@ -265,7 +265,7 @@ Remember that tags are private addresses without any meaning outside the data fr
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.
@ -516,7 +516,7 @@ Let’s study the implementation of the same data type in both ways by the examp
* 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*;
@ -524,7 +524,7 @@ If the type of transformation is changed to rotation, the data tree looks like t
* 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).
@ -539,7 +539,7 @@ The attribute *TDataStd_UAttribute* with the chosen unique GUID identifies the d
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
@ -784,7 +784,7 @@ You can also have a look at the class *TDF_Closure*, which can be useful to dete
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.
@ -834,7 +834,7 @@ The user can add the *TNaming_NamedShape* attribute to other labels. This attrib
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.
@ -847,7 +847,7 @@ Different algorithms may dispose sub-shapes of the result shape at the individua
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).
@ -855,7 +855,7 @@ Named shapes, which contain information about modified faces, belong to the fuse
* 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:
@ -998,7 +998,7 @@ Standard_Boolean CafTest_MyClass::SameEdge (const Handle(CafTest_Line)& L1, cons
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),
@ -1020,11 +1020,11 @@ The application contains 3 functions:
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).
@ -1164,7 +1164,7 @@ It is possible to describe any model by means of standard OCAF attributes.
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.
@ -1181,7 +1181,7 @@ It is possible to describe any model by means of standard OCAF attributes.
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)
@ -1193,7 +1193,7 @@ It is possible to describe any model by means of standard OCAF attributes.
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
@ -1210,7 +1210,7 @@ It is possible to describe any model by means of standard OCAF attributes.
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.
@ -1257,7 +1257,7 @@ The class *TPrsStd_AISPresentation* allows you to define the visual presentation
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.
@ -1282,7 +1282,7 @@ Function services aggregate data necessary for regeneration of a model. The func
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.
@ -1302,7 +1302,7 @@ For updating algorithm optimization, each function driver has access to the *TFu
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;
@ -1328,7 +1328,7 @@ The procedure of its creation is as follows:
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.
@ -1437,7 +1437,7 @@ To automatically erase the nail from the viewer and the data tree it is enough
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.
@ -2289,3 +2289,4 @@ The following scenario is used:
- creating a Cut (Box1, Box2) as a modification of Box1 and push it in DF;
- recovering the result from DF.

23
dox/user_guides/shape_healing/shape_healing.md
View File

@ -41,7 +41,7 @@ The solution: Shape Healing closes a gap by inserting lacking edge.
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);
@ -443,7 +443,7 @@ TopoDS_Wire newwire = sfw.Wire();
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;
@ -487,7 +487,7 @@ adjacent edges”<<endl;
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
@ -500,7 +500,7 @@ This tool does not have the method *Perform()*.
To see how this tool works, it is possible to take an edge, where the maximum deviation between the 3D curve and 2D curve P1 is greater than the edge tolerance.
@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.
@ -520,7 +520,7 @@ if (sae.CheckSameParameter (edge, maxdev)) {
}
~~~~~
@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.
@ -1179,9 +1179,9 @@ Such calculations are necessary to avoid creation of strip faces. In the process
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:
@ -1365,15 +1365,15 @@ If the sequence of shapes contains faces, only the internal wires from these fac
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.
@ -1967,3 +1967,4 @@ A new default log file can be added using method *SetDefault* with the same arg
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.

7
dox/user_guides/step/step.md
View File

@ -7,7 +7,7 @@ STEP processor {#occt_user_guides__step}
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;
@ -735,7 +735,7 @@ This method is intended to force two adjacent edges in the wire to share the sam
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
~~~~~
@ -1073,7 +1073,7 @@ The following diagram illustrates the structure of calls in writing STEP.
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
@ -1621,3 +1621,4 @@ Interface_Static::SetIVal("write.step.schema", 5));
Saved Views are not exported by OCCT.

13
dox/user_guides/tobj/tobj.md
View File

@ -48,7 +48,7 @@ It should be emphasized that *TObj* package defines only the interfaces and the
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
@ -61,7 +61,7 @@ of the label, which uniquely identifies its position in the document.
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
@ -428,7 +428,7 @@ of important features of *TObj* model objects. This implementation defines
basic approaches that are recommended for all descendants,
and provides tools to facilitate their usage.
@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
@ -449,7 +449,7 @@ The special type of attribute *TObj_TObject* is used for storing instances of ob
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
@ -639,7 +639,7 @@ This attribute is located in the sub-label of the referring object (called *mast
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}
@ -893,7 +893,7 @@ Apart from the model and the object, package *TObj* provides a set of auxiliary
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
@ -907,3 +907,4 @@ The *TObj* sources are distributed in the following packages:
* *TKBinL, TKXmlL* -- toolkits of binary and XML persistence

15
dox/user_guides/vis/vis.md
View File

@ -6,7 +6,7 @@
@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.
@ -21,14 +21,14 @@ VIS component consists of the following packages:
* **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.
@ -156,7 +156,7 @@ For example, the scalar-based coloring can be disabled to bind a single color to
@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:
@ -176,7 +176,7 @@ By default, the display mode filter works in a wireframe mode.
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:
@ -241,7 +241,7 @@ OCCT picking algorithm *IVtkTools_ShapePicker* calculates a new transformation m
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
@ -282,7 +282,7 @@ The usage of low-level tools is justified in cases when the utilities from *IVtk
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:
@ -365,3 +365,4 @@ IVtk_ShapeIdList subShapeIds
*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.

45
dox/user_guides/visualization/visualization.md
View File

@ -28,7 +28,7 @@ The packages used to display 3D objects are also applicable for visualization of
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.
@ -98,7 +98,7 @@ aContext -> Display(anAis);
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
@ -121,7 +121,7 @@ Sensitive entities in the same way as entity owners are links between objects an
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).
@ -152,9 +152,9 @@ For all standard OCCT shapes, zero mode is supposed to select the whole object (
- 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>
@ -166,7 +166,7 @@ The viewer selector maintains activation and deactivation of selection modes, la
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
@ -180,9 +180,13 @@ For the point or the rectangular selection the base of the frustum is a rectangl
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>
@ -194,7 +198,7 @@ The second level BVH tree consists of all sensitive entities of one selectable o
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>
@ -456,13 +460,13 @@ in which you were before opening it (neutral point or previous local context).
**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.
@ -480,7 +484,7 @@ A presentation is identified by an index and by the reference to the Presentati
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.
@ -634,9 +638,9 @@ Keep in mind the following points concerning graphic attributes:
* 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*
@ -783,7 +787,7 @@ vfit
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:
@ -798,7 +802,7 @@ vconnect x 3 0 0 s p # make assembly
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:
@ -1401,7 +1405,7 @@ The presentation class *AIS_PointCloud* can be used for efficient drawing of lar
- 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:
~~~~~
@ -2029,7 +2033,7 @@ aView->Camera()->Transform (aTrsf);
@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:
@ -2045,7 +2049,7 @@ aView->Update();
**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:
@ -2069,7 +2073,7 @@ There are two types of IOD:
**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:
@ -2847,3 +2851,4 @@ From a developer's point of view, it is easy to integrate the *MeshVS* component
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).

15
dox/user_guides/xde/xde.md
View File

@ -13,7 +13,7 @@ Data types such as colors, layers, assembly descriptions and validation properti
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.
@ -39,10 +39,10 @@ The Document used by XDE usually starts as a *TDocStd_Document*.
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).
@ -54,7 +54,7 @@ Validation properties are geometric characteristics of Shapes (volume, centroid,
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:
@ -81,7 +81,7 @@ In our example, it can be seen that no errors were detected for either area, vol
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*:
@ -89,7 +89,7 @@ XDE can read and write colors and layers assigned to shapes or their subparts (d
* 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
@ -482,7 +482,7 @@ XCAFDoc_Volume::Set ( aLabel, volume );
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*.
@ -684,3 +684,4 @@ As XDE provides an extension of the data structure, for relevant data in standar
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.