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

0028347: Reuse OCCT implementation for producing end-user documentation for Products

Browse Source 
Updated destination directory for generated by gendoc proc pdf files.

Added additional option "-update_images_size" for gendoc procedure to update width of images in *.md files during pdf generation for @figure alias.

Documentation was updated to use alias @figure instead of outdated @image

Added support of svg image format in procedure OCCDoc_UpdateImagesSize.

Added generation of overview for product components.

Added generation of products refman/chm for each component.
This commit is contained in:
apn 2017-03-30 12:13:19 +03:00 committed by bugmaster
parent b608f6a564
commit 7e3451c7a2
23 changed files with 494 additions and 503 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

148
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>\]"
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 ""
puts "Options are:"
puts ""
@ -56,7 +56,8 @@ proc OCCDoc_PrintHelpMessage {} {
puts " -s=<search_mode> : Specifies the Search mode of HTML documents"
puts " Can be: none | local | server | external"
puts " -h : Prints this help message"
puts " -v : Enables more verbose output"
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
@ -69,6 +70,7 @@ 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"
@ -171,7 +173,7 @@ proc gendoc {args} {
if { $DOCTYPE_COMBO_FLAG != 1 } {
set DOC_TYPE "REFMAN"
set DOCTYPE_COMBO_FLAG 1
if { [info exists env(PRODROOT)] && [file exists $::env(PRODROOT)/src/VAS/Products.tcl] } {
if { [file exists [OCCDoc_GetProdRootDir]/src/VAS/Products.tcl] } {
set GENERATE_PRODUCTS_REFMAN "YES"
}
} else {
@ -197,6 +199,8 @@ 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
@ -312,7 +316,23 @@ proc gendoc {args} {
# Start main activities
if { $GEN_MODE != "PDF_ONLY" } {
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
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
} 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
}
} 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
}
} 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
}
}
}
} else {
puts "Generating OCCT User Guides in PDF format...\n"
foreach pdf $DOCFILES {
@ -320,25 +340,19 @@ 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 "none" $MATHJAX_LOCATION "NO" $DOXYGEN_PATH $GRAPHVIZ_PATH $INKSCAPE_PATH $HHC_PATH
OCCDoc_Main "OVERVIEW" [list $pdf] {} "PDF_ONLY" $VERB_MODE $UPDATE_IMAGES_SIZE "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."
puts "\nPDF files are generated in \n[file normalize [OCCDoc_GetRootDir]/doc/pdf]"
}
}
# Main procedure for documents compilation
proc OCCDoc_Main {docType {docfiles {}} {modules {}} generatorMode verboseMode searchMode mathjaxLocation generateProductsRefman DOXYGEN_PATH GRAPHVIZ_PATH INKSCAPE_PATH HHC_PATH} {
proc OCCDoc_Main {docType {docfiles {}} {modules {}} generatorMode verboseMode updateImagesSize searchMode mathjaxLocation generateProductsRefman DOXYGEN_PATH GRAPHVIZ_PATH INKSCAPE_PATH HHC_PATH} {
global available_docfiles
global available_pdf
set PRODPATH ""
if { [string compare -nocase $generateProductsRefman "YES"] == 0 } {
set PRODPATH "$::env(PRODROOT)"
}
set ROOTDIR [OCCDoc_GetRootDir $PRODPATH]
set ROOTDIR [OCCDoc_GetRootDir [OCCDoc_GetProdRootDir]]
set INDIR [OCCDoc_GetDoxDir]
set OUTDIR $ROOTDIR/doc
set PDFDIR $OUTDIR/pdf
@ -348,7 +362,29 @@ proc OCCDoc_Main {docType {docfiles {}} {modules {}} generatorMode verboseMode s
set HTMLDIR $OUTDIR/overview/html
set LATEXDIR $OUTDIR/overview/latex
set DOXYFILE $OUTDIR/OCCT.cfg
# OUTDIR for products documentation should be separate directories for each components
if { [OCCDoc_GetProdRootDir] != ""} {
if { $docType == "REFMAN" } {
if { "$modules" != "" } {
source "[OCCDoc_GetSourceDir [OCCDoc_GetProdRootDir]]/VAS/${modules}.tcl"
set doc_component_name [${modules}:documentation_name]
set OUTDIR $OUTDIR/$doc_component_name
}
} else {
if {[regexp {([^/]+)/([^/]+)/([^/]+)} $docfiles dump doc_type doc_component doc_name]} {
set PDFNAME [file rootname $doc_name]
set OUTDIR $OUTDIR/$doc_component
} else {
error "Could not parse input path to *.md file: \"${docfiles}\""
}
}
set HTMLDIR $OUTDIR/html
set LATEXDIR $OUTDIR/latex
set DOXYFILE $OUTDIR/OCCT.cfg
set TAGFILEDIR $OUTDIR/refman
}
# Create or cleanup the output folders
if { [string compare -nocase $generateProductsRefman "YES"] != 0 } {
if { ![file exists $OUTDIR] } {
@ -357,19 +393,24 @@ proc OCCDoc_Main {docType {docfiles {}} {modules {}} generatorMode verboseMode s
if { ![file exists $HTMLDIR] } {
file mkdir $HTMLDIR
}
if { ![file exists $PDFDIR] } {
file mkdir $PDFDIR
if { [OCCDoc_GetProdRootDir] == ""} {
if { ![file exists $PDFDIR] } {
file mkdir $PDFDIR
}
if { ![file exists $UGDIR] } {
file mkdir $UGDIR
}
if { ![file exists $DGDIR] } {
file mkdir $DGDIR
}
}
if { ![file exists $UGDIR] } {
file mkdir $UGDIR
if { $generatorMode == "PDF_ONLY" } {
if { [file exists $LATEXDIR] } {
file delete -force $LATEXDIR
}
file mkdir $LATEXDIR
}
if { ![file exists $DGDIR] } {
file mkdir $DGDIR
}
if { [file exists $LATEXDIR] } {
file delete -force $LATEXDIR
}
file mkdir $LATEXDIR
}
if { $docType == "REFMAN" } {
if { ![file exists $TAGFILEDIR] } {
@ -397,7 +438,11 @@ proc OCCDoc_Main {docType {docfiles {}} {modules {}} generatorMode verboseMode s
set DOCDIR "$OUTDIR/refman"
puts "\nGenerating Open CASCADE Reference Manual\n"
} elseif { $docType == "OVERVIEW" } {
set DOCDIR "$OUTDIR/overview"
if { [OCCDoc_GetProdRootDir] == ""} {
set DOCDIR "$OUTDIR/overview"
} else {
set DOCDIR "$OUTDIR"
}
set FORMAT ""
if { ($generatorMode == "HTML_ONLY") || ($generatorMode == "CHM_ONLY") } {
if { $generatorMode == "HTML_ONLY" } {
@ -416,10 +461,18 @@ proc OCCDoc_Main {docType {docfiles {}} {modules {}} generatorMode verboseMode s
# Generate Doxyfile
puts "[clock format [clock seconds] -format {%Y-%m-%d %H:%M}] Generating Doxyfile..."
if { [OCCDoc_MakeDoxyfile $docType $DOCDIR $TAGFILEDIR $DOXYFILE $generatorMode $docfiles $modules $verboseMode $searchMode $HHC_PATH $mathjax_relative_location $GRAPHVIZ_PATH $PRODPATH] == -1 } {
if { [OCCDoc_MakeDoxyfile $docType $DOCDIR $TAGFILEDIR $DOXYFILE $generatorMode $docfiles $modules $verboseMode $searchMode $HHC_PATH $mathjax_relative_location $GRAPHVIZ_PATH [OCCDoc_GetProdRootDir]] == -1 } {
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}]
@ -564,21 +617,29 @@ proc OCCDoc_Main {docType {docfiles {}} {modules {}} generatorMode verboseMode s
set destFolder $PDFDIR
set parsed_string [split $TEX "_"]
if { [lsearch $parsed_string "tutorial"] != -1 } {
set TEX [string map [list occt__ occt_] $TEX]
set destFolder $PDFDIR
} elseif { [lsearch $parsed_string "user"] != -1 } {
set TEX [string map [list user_guides__ ""] $TEX]
set destFolder $UGDIR
} elseif { [lsearch $parsed_string "dev"] != -1 } {
set TEX [string map [list dev_guides__ ""] $TEX]
set destFolder $DGDIR
if { [OCCDoc_GetProdRootDir] == ""} {
if { [lsearch $parsed_string "tutorial"] != -1 } {
set TEX [string map [list occt__ occt_] $TEX]
set destFolder $PDFDIR
} elseif { [lsearch $parsed_string "user"] != -1 } {
set TEX [string map [list user_guides__ ""] $TEX]
set destFolder $UGDIR
} elseif { [lsearch $parsed_string "dev"] != -1 } {
set TEX [string map [list dev_guides__ ""] $TEX]
set destFolder $DGDIR
}
} else {
set destFolder $OUTDIR
set TEX "$PDFNAME"
}
file rename -force $LATEXDIR/refman.pdf "$destFolder/$TEX.pdf"
}
} elseif { $generatorMode == "CHM_ONLY" } {
file rename $OUTDIR/overview.chm $OUTDIR/occt_overview.chm
if { [OCCDoc_GetProdRootDir] == ""} {
file rename $OUTDIR/overview.chm $OUTDIR/occt_overview.chm
} else {
file rename -force $ROOTDIR/doc/overview.chm $OUTDIR/occt_overview.chm
}
}
cd $INDIR
@ -597,14 +658,17 @@ proc OCCDoc_Main {docType {docfiles {}} {modules {}} generatorMode verboseMode s
foreach file $deleteList {
file delete $file
}
puts "\nPDF files are generated in \n[file normalize $OUTDIR]"
return 0
}
# Generates Doxygen configuration file for Overview documentation
proc OCCDoc_MakeDoxyfile {docType outDir tagFileDir {doxyFileName} {generatorMode ""} {DocFilesList {}} {ModulesList {}} verboseMode searchMode hhcPath mathjaxLocation graphvizPath productsPath} {
set inputDir [OCCDoc_GetDoxDir [OCCDoc_GetProdRootDir]]
set inputDir [OCCDoc_GetDoxDir]
set TEMPLATES_DIR $inputDir/resources
set TEMPLATES_DIR [OCCDoc_GetDoxDir]/resources
set occt_version [OCCDoc_DetectCasVersion]
# Delete existent doxyfile
@ -751,10 +815,10 @@ proc OCCDoc_MakeDoxyfile {docType outDir tagFileDir {doxyFileName} {generatorMod
# Add common options for generation of Overview and User Guides
puts $doxyFile "PROJECT_NUMBER = $occt_version"
puts $doxyFile "OUTPUT_DIRECTORY = $outDir/."
puts $doxyFile "PROJECT_LOGO = $inputDir/resources/occ_logo.png"
puts $doxyFile "PROJECT_LOGO = [OCCDoc_GetDoxDir]/resources/occ_logo.png"
set PARAM_INPUT "INPUT ="
set PARAM_IMAGEPATH "IMAGE_PATH = $inputDir/resources/ "
set PARAM_IMAGEPATH "IMAGE_PATH = [OCCDoc_GetDoxDir]/resources/ "
foreach docFile $DocFilesList {
set NEW_IMG_PATH "$inputDir/$docFile"
if { [string compare $NEW_IMG_PATH [OCCDoc_GetRootDir $productsPath]] != 0 } {

141
adm/occaux.tcl
View File

@ -32,12 +32,12 @@ proc OCCDoc_ParseArguments {arguments} {
array set args_values {}
foreach arg $arguments {
if {[regexp {^(-)[a-z]+$} $arg] == 1} {
if {[regexp {^(-)[a-z_]+$} $arg] == 1} {
set name [string range $arg 1 [string length $arg]-1]
lappend args_names $name
set args_values($name) "NULL"
continue
} elseif {[regexp {^(-)[a-z]+=.+$} $arg] == 1} {
} elseif {[regexp {^(-)[a-z_]+=.+$} $arg] == 1} {
set equal_symbol_position [string first "=" $arg]
set name [string range $arg 1 $equal_symbol_position-1]
lappend args_names $name
@ -59,8 +59,19 @@ proc OCCDoc_ParseArguments {arguments} {
}
# Returns script parent folder
proc OCCDoc_GetDoxDir {} {
return [file normalize [file dirname [info script]]/../dox]
proc OCCDoc_GetDoxDir { {theProductsPath ""} } {
if { $theProductsPath == "" } {
return [file normalize [file dirname [info script]]/../dox]
} else {
return [file normalize $theProductsPath]/dox
}
}
# Returns products root folder
proc OCCDoc_GetProdRootDir {} {
if {[info exists ::env(PRODROOT)]} {
return [file normalize $::env(PRODROOT)]
}
}
# Returns OCCT root dir
@ -71,7 +82,6 @@ proc OCCDoc_GetOCCTRootDir {} {
# Returns root dir
proc OCCDoc_GetRootDir { {theProductsPath ""} } {
if { $theProductsPath == "" } {
return [OCCDoc_GetOCCTRootDir]
} else {
@ -736,8 +746,7 @@ proc OCCDoc_PostProcessor {outDir} {
# Loads a list of docfiles from file FILES.txt
proc OCCDoc_LoadFilesList {} {
set INPUTDIR [OCCDoc_GetDoxDir]
set INPUTDIR [OCCDoc_GetDoxDir [OCCDoc_GetProdRootDir]]
global available_docfiles
set available_docfiles {}
@ -799,7 +808,11 @@ proc OCCDoc_MakeRefmanTex {fileName latexDir verboseMode latexFilesList} {
}
# Copy template file to latex folder
file copy "[OCCDoc_GetDoxDir]/resources/occt_pdf_template.tex" $DOCNAME
if { "[OCCDoc_GetProdRootDir]" != "" } {
file copy "[OCCDoc_GetDoxDir [OCCDoc_GetProdRootDir]]/resources/prod_pdf_template.tex" $DOCNAME
} else {
file copy "[OCCDoc_GetDoxDir]/resources/occt_pdf_template.tex" $DOCNAME
}
# Get templatized data
set texfile [open $DOCNAME "r"]
@ -808,6 +821,7 @@ proc OCCDoc_MakeRefmanTex {fileName latexDir verboseMode latexFilesList} {
# Replace dummy values
set year [clock format [clock seconds] -format {%Y}]
set month [clock format [clock seconds] -format {%B}]
set texfile [open $DOCNAME "w"]
set casVersion [OCCDoc_DetectCasVersion]
@ -815,23 +829,23 @@ proc OCCDoc_MakeRefmanTex {fileName latexDir verboseMode latexFilesList} {
set docLabel ""
foreach aFileName $latexFilesList {
# Find the file in FILES_PDF.txt
set parsedFileName [split $aFileName "/" ]
set newfileName [string range $fileName [expr [string first "__" $fileName] + 2] end]
if { [lsearch -nocase $parsedFileName "$newfileName.md" ] != -1 } {
set filepath "[OCCDoc_GetDoxDir]/$aFileName"
set parsedFileName [file rootname [lindex [split $aFileName "/" ] end]]
if { [regexp "${parsedFileName}$" $fileName] } {
set filepath "[OCCDoc_GetDoxDir [OCCDoc_GetProdRootDir]]/$aFileName"
if { [file exists $filepath] } {
set MDFile [open $filepath "r"]
set label [split [gets $MDFile] "\{"]
set docLabel [lindex $label 0]
close $MDFile
break
}
}
}
set texfile_loaded [string map [list DEFDOCLABEL "$docLabel" DEFCASVERSION "$casVersion" DEFFILENAME "$fileName" DEFYEAR "$year"] $texfile_loaded]
set occtlogo_path "[OCCDoc_GetDoxDir]/resources/occt_logo.png"
set occlogo_path "[OCCDoc_GetDoxDir]/resources/occ_logo.png"
set copyright_path "[OCCDoc_GetDoxDir [OCCDoc_GetProdRootDir]]/resources/prod_pdf_template.tex"
set texfile_loaded [string map [list DEFDOCLABEL "$docLabel" DEFCASVERSION "$casVersion" DEFFILENAME "$fileName" DEFYEAR "$year" DEFMONTH "$month" DEFCOPYRIGHT "$copyright_path" DEFLOGO "$occtlogo_path" DEFOCCLOGO "$occlogo_path" DEFTITLE ""] $texfile_loaded]
# Get data
puts $texfile $texfile_loaded
@ -886,3 +900,100 @@ proc OCCDoc_ProcessTex {{texFiles {}} {latexDir} verboseMode} {
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
}
}

18
dox/dev_guides/building/3rdparty/3rdparty_windows.md vendored
View File

@ -112,13 +112,11 @@ FreeType is required for text display in a 3D viewer. You can download its sourc
5. If you build FreeType for a 64 bit platform, select in the main menu **Build - Configuration Manager** and add *x64* platform to the solution configuration by copying the settings from Win32 platform:
@image html /dev_guides/building/3rdparty/images/3rdparty_image001.png
@image latex /dev_guides/building/3rdparty/images/3rdparty_image001.png
@figure{/dev_guides/building/3rdparty/images/3rdparty_image001.png}
Update the value of the Output File for x64 configuration:
@image html /dev_guides/building/3rdparty/images/3rdparty_image003.png
@image latex /dev_guides/building/3rdparty/images/3rdparty_image003.png
@figure{/dev_guides/building/3rdparty/images/3rdparty_image003.png}
Build the *freetype* project.
@ -207,24 +205,20 @@ You can download its sources from http://geuz.org/gl2ps/src/.
* Press **Configure** button.
@image html /dev_guides/building/3rdparty/images/3rdparty_image004.png
@image latex /dev_guides/building/3rdparty/images/3rdparty_image004.png
@figure{/dev_guides/building/3rdparty/images/3rdparty_image004.png}
* Select the generator (the compiler and the target platform -- 32 or 64 bit) in the pop-up window.
@image html /dev_guides/building/3rdparty/images/3rdparty_image005.png
@image latex /dev_guides/building/3rdparty/images/3rdparty_image005.png
@figure{/dev_guides/building/3rdparty/images/3rdparty_image005.png}
* Press **Finish** button to return to the main CMake window.
Expand the ENABLE group and uncheck ENABLE_PNG and ENABLE_ZLIB check boxes.
@image html /dev_guides/building/3rdparty/images/3rdparty_image006.png
@image latex /dev_guides/building/3rdparty/images/3rdparty_image006.png
@figure{/dev_guides/building/3rdparty/images/3rdparty_image006.png}
* Expand the CMAKE group and define *CMAKE_INSTALL_PREFIX* which is the path where you want to install the build results, for example, *c:\\occ3rdparty\\gl2ps-1.3.5*.
@image html /dev_guides/building/3rdparty/images/3rdparty_image007.png
@image latex /dev_guides/building/3rdparty/images/3rdparty_image007.png
@figure{/dev_guides/building/3rdparty/images/3rdparty_image007.png}
* Press **Configure** button again, then press **Generate** button to generate Visual Studio projects. After completion, close CMake application.

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

@ -35,8 +35,7 @@ According to his access level, the user can participate in the issue handling pr
@subsection occt_contribution_workflow_general General scheme
<center>
@image html OCCT_ContributionWorkflow_V3_image001.svg "Standard life cycle of an issue"
@image latex OCCT_ContributionWorkflow_V3_image001.svg "Standard life cycle of an issue"
@figure{OCCT_ContributionWorkflow_V3_image001.svg, "Standard life cycle of an issue"}
</center>
@subsection occt_contribution_workflow_issue Issue registration
@ -281,8 +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:
@image html OCCT_ContributionWorkflow_V3_image002.png "Integration of several branches" width=\textwidth
@image latex OCCT_ContributionWorkflow_V3_image002.png "Integration of several branches" width=\textwidth
@figure{OCCT_ContributionWorkflow_V3_image002.png, "Integration of several branches"}
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.

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

@ -399,12 +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
@image html /relative/path/to/image/occ_logo.png
@image latex /relative/path/to/image/occ_logo.png "OCC logo"
@figure{/relative/path/to/image/occ_logo.png, "OCC logo"}
@endverbatim
@image html /resources/occ_logo.png
@image latex /resources/occ_logo.png "OCC logo"
@figure{/resources/occ_logo.png, "OCC logo"}
@subsection OCCT_DM_SECTION_A_8 Table Of Contents

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

@ -124,8 +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:
@image html OCCT_GitGuide_V2_image005.png
@image latex OCCT_GitGuide_V2_image005.png
@figure{OCCT_GitGuide_V2_image005.png}
@ -138,8 +137,7 @@ The official repository contains:
Select Git->Config to add your user name and Email address to the local <i>.gitconfig</i> file
@image html OCCT_GitGuide_V2_image006.png
@image latex OCCT_GitGuide_V2_image006.png
@figure{OCCT_GitGuide_V2_image006.png}
@subsection occt_gitguide_2_2 Linux platform
@ -190,8 +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.
@image html OCCT_GitGuide_V2_image007.png "Putty key generator"
@image latex OCCT_GitGuide_V2_image007.png "Putty key generator"
@figure{OCCT_GitGuide_V2_image007.png, "Putty key generator"}
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.
@ -295,8 +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:
@image html OCCT_GitGuide_V2_image009.png
@image latex OCCT_GitGuide_V2_image009.png
@figure{OCCT_GitGuide_V2_image009.png}
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.
@ -321,8 +317,7 @@ In TortoiseGit:
* Right-click in the Explorer window, then choose **Git Create Branch**.
* Select **Base On** Branch *remotes/origin/master*.
@image html OCCT_GitGuide_V2_image012.png
@image latex OCCT_GitGuide_V2_image012.png
@figure{OCCT_GitGuide_V2_image012.png}
Check option **Switch to new branch** if you are going to start working with the newly created branch immediately.
@ -337,8 +332,7 @@ In TortoiseGit:
In TortoiseGit: right-click in the explorer window and select in the context menu **TortoiseGit** -> **Switch/Checkout**.
@image html OCCT_GitGuide_V2_image013.png
@image latex OCCT_GitGuide_V2_image013.png
@figure{OCCT_GitGuide_V2_image013.png}
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.
@ -372,8 +366,7 @@ In TortoiseGit:
* In TortoiseGit: right-click in the explorer window and select in the context menu <b>Git Commit -> CR…</b>:
@image html OCCT_GitGuide_V2_image014.png
@image latex OCCT_GitGuide_V2_image014.png
@figure{OCCT_GitGuide_V2_image014.png}
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).
@ -391,15 +384,13 @@ In TortoiseGit:
* In TortoiseGit: right-click in the explorer window and select in the context menu, TortoiseGit -> **Push**
@image html OCCT_GitGuide_V2_image015.png
@image latex OCCT_GitGuide_V2_image015.png
@figure{OCCT_GitGuide_V2_image015.png}
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):
@image html OCCT_GitGuide_V2_image016.png
@image latex OCCT_GitGuide_V2_image016.png
@figure{OCCT_GitGuide_V2_image016.png}
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:
@ -419,8 +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.
@image html OCCT_GitGuide_V2_image018.png
@image latex OCCT_GitGuide_V2_image018.png
@figure{OCCT_GitGuide_V2_image018.png}
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.
@ -433,8 +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**.
@image html OCCT_GitGuide_V2_image019.png
@image latex OCCT_GitGuide_V2_image019.png
@figure{OCCT_GitGuide_V2_image019.png}
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.
@ -447,8 +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**.
@image html OCCT_GitGuide_V2_image020.png
@image latex OCCT_GitGuide_V2_image020.png
@figure{OCCT_GitGuide_V2_image020.png}
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.
@ -462,15 +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**.
@image html OCCT_GitGuide_V2_image021.png
@image latex OCCT_GitGuide_V2_image021.png
@figure{OCCT_GitGuide_V2_image021.png}
* 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**:
@image html OCCT_GitGuide_V2_image022.png
@image latex OCCT_GitGuide_V2_image022.png
@figure{OCCT_GitGuide_V2_image022.png}
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.
@ -487,19 +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.
@image html OCCT_GitGuide_V2_image023.png
@image latex OCCT_GitGuide_V2_image023.png
@figure{OCCT_GitGuide_V2_image023.png}
* 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**.
@image html OCCT_GitGuide_V2_image024.png
@image latex OCCT_GitGuide_V2_image024.png
@figure{OCCT_GitGuide_V2_image024.png}
* 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**.
@image html OCCT_GitGuide_V2_image025.png
@image latex OCCT_GitGuide_V2_image025.png
@figure{OCCT_GitGuide_V2_image025.png}
@section occt_gitguide_5 Work with repository: Reviewer operations
@ -525,6 +508,5 @@ 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**.
@image html OCCT_GitGuide_V2_image026.png
@image latex OCCT_GitGuide_V2_image026.png
@figure{OCCT_GitGuide_V2_image026.png}

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

@ -242,8 +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.
@image html /dev_guides/tests/images/tests_image001.png "Layout of tests folder"
@image latex /dev_guides/tests/images/tests_image001.png "Layout of tests folder"
@figure{/dev_guides/tests/images/tests_image001.png, "Layout of tests folder"}
@subsection testmanual_2_2 Test Groups

30
dox/overview/overview.md
View File

@ -4,8 +4,7 @@
@tableofcontents
@htmlonly<center>@endhtmlonly
@image html /resources/occt_logo.png
@image latex /resources/occt_logo.png
@figure{/resources/occt_logo.png}
@htmlonly</center>@endhtmlonly
@section OCCT_OVW_SECTION_1 Welcome
@ -23,8 +22,7 @@ Copyright (c) 1999-2016 by OPEN CASCADE S.A.S. All rights reserved.
@htmlonly<center>@endhtmlonly
http://www.opencascade.com
@image html /resources/occ_logo.png
@image latex /resources/occ_logo.png
@figure{/resources/occ_logo.png}
@htmlonly</center>@endhtmlonly
License
@ -262,13 +260,11 @@ OCCT are included into binary distribution (built with Visual C++ 2010).
When the installation is complete, you will find the directories for 3rd party products
(some might be absent in case of custom installation) and the main **OCCT** directory:
@image html /overview/images/overview_3rdparty.png
@image latex /overview/images/overview_3rdparty.png
@figure{/overview/images/overview_3rdparty.png}
The contents of the OCCT-7.0.0 directory (called further "OCCT root", or $CASROOT) are as follows:
@image html /overview/images/overview_installation.png "The directory tree"
@image latex /overview/images/overview_installation.png "The directory tree"
@figure{/overview/images/overview_installation.png, "The directory tree"}
* **adm** This folder contains administration files, which allow rebuilding OCCT;
* **adm/cmake** This folder contains files of CMake building procedure;
@ -348,8 +344,7 @@ Draw is a command interpreter based on TCL and a graphical system used for testi
Draw can be used interactively to create, display and modify objects such as curves, surfaces and topological shapes.
@image html /overview/images/overview_draw.png
@image latex /overview/images/overview_draw.png
@figure{/overview/images/overview_draw.png}
Scripts can be written to customize Draw and perform tests.
New types of objects and new commands can be added using C++ programming language.
@ -467,8 +462,7 @@ The list of MFC samples:
* Animation
* Convert
@image html /overview/images/overview_mvc.png
@image latex /overview/images/overview_mvc.png
@figure{/overview/images/overview_mvc.png}
**Remarks:**
@ -487,8 +481,7 @@ OCCT contains three samples based on Qt application framework
Import Export programming sample contains 3D Viewer and Import / Export functionality.
@image html /overview/images/overview_qt.png
@image latex /overview/images/overview_qt.png
@figure{/overview/images/overview_qt.png}
Tutorial
---------
@ -513,8 +506,7 @@ The combination of these resources allows creating substantial applications.
C# sample demonstrates integration of OCCT 3D Viewer and Import / Export functionality into .NET applications (using Windows Forms and WPF front ends).
@image html /overview/images/overview_c__ie.png
@image latex /overview/images/overview_c__ie.png
@figure{/overview/images/overview_c__ie.png}
Import:
@ -541,11 +533,9 @@ See \subpage samples_csharp_direct3d "Readme" for details.
There are two samples are representing usage OCCT framework on Android mobile platform. They represent an OCCT-based 3D-viewer with CAD import support in formats BREP, STEP and IGES: jniviewer (java) and AndroidQt (qt+qml)
jniviewer
@image html /overview/images/samples_java_android_occt.jpg
@image latex /overview/images/samples_java_android_occt.jpg
@figure{/overview/images/samples_java_android_occt.jpg}
Java -- See \subpage samples_java_android_occt "Readme" for details.
AndroidQt
@image html /overview/images/samples_qml_android_occt.jpg
@image latex /overview/images/samples_qml_android_occt.jpg
@figure{/overview/images/samples_qml_android_occt.jpg}
Qt -- See \subpage samples_qml_android_occt "Readme" for details.

1
dox/resources/occt_ug_html.doxyfile
View File

@ -58,3 +58,4 @@ MATHJAX_FORMAT = HTML-CSS
# Define alias for inserting images in uniform way (both HTML and PDF)
ALIASES += figure{1}="\image html \1 \n"
ALIASES += figure{2}="\image html \1 \2 \n"
ALIASES += figure{3}="\image html \1 \2 \n"

1
dox/resources/occt_ug_pdf.doxyfile
View File

@ -51,3 +51,4 @@ MAKEINDEX_CMD_NAME = makeindex
# Define alias for inserting images in uniform way (both HTML and PDF)
ALIASES += figure{1}="\image latex \1 \n"
ALIASES += figure{2}="\image latex \1 \2 \n"
ALIASES += figure{3}="\image latex \1 \2 width=\3 \n"

4
dox/technical_overview/technical_overview.md
View File

@ -128,7 +128,7 @@ Top-level API provides the following functionality:
* Pipes -- general-form sweeps;
* Lofting.
@figure{/technical_overview/images/0001.png "Shapes containing pipes with variable radius produced by sweeping"}
@figure{/technical_overview/images/0001.png "Shapes containing pipes with variable radius produced by sweeping"}
* Boolean Operations, which allow creating new shapes from the combinations of source shapes. For two shapes *S1* and *S2*:
* *Common* contains all points that are in *S1* and *S2*;
@ -145,7 +145,7 @@ See @ref occt_user_guides__boolean_operations "Boolean Operations" User's Guide
* Algorithms for creation of mechanical features, i.e. depressions, protrusions, ribs and grooves or slots along planar or revolution surfaces.
@figure{/technical_overview/images/0004.png}
@figure{/technical_overview/images/0004.png}
Please, see the details in @ref occt_user_guides__modeling_algos "Modeling Algorithms User's Guide".

54
dox/tutorial/tutorial.md
View File

@ -18,8 +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:
@image html /tutorial/images/tutorial_image001.png
@image latex /tutorial/images/tutorial_image001.png
@figure{/tutorial/images/tutorial_image001.png}
In the tutorial we will create, step-by-step, a function that will model a bottle as shown above. You will find the complete source code of this tutorial, including the very function *MakeBottle* in the distribution of Open CASCADE Technology. The function body is provided in the file samples/qt/Tutorial/src/MakeBottle.cxx.
@ -35,8 +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.
@image html /tutorial/images/tutorial_image002.png
@image latex /tutorial/images/tutorial_image002.png
@figure{/tutorial/images/tutorial_image002.png}
This modeling requires four steps:
@ -85,8 +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.
@image html /tutorial/images/tutorial_image004.png
@image latex /tutorial/images/tutorial_image004.png
@figure{/tutorial/images/tutorial_image004.png}
To create such entities, you need a specific data structure, which implements 3D geometric objects. This can be found in the Geom package of Open CASCADE Technology.
In Open CASCADE Technology a package is a group of classes providing related functionality. The classes have names that start with the name of a package they belong to. For example, *Geom_Line* and *Geom_Circle* classes belong to the *Geom* package. The *Geom* package implements 3D geometric objects: elementary curves and surfaces are provided as well as more complex ones (such as *Bezier* and *BSpline*).
@ -142,8 +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.
@image html /tutorial/images/tutorial_image005.png
@image latex /tutorial/images/tutorial_image005.png
@figure{/tutorial/images/tutorial_image005.png}
However, the *TopoDS* package provides only the data structure of the topological entities. Algorithm classes available to compute standard topological objects can be found in the *BRepBuilderAPI* package.
To create an edge, you use the BRepBuilderAPI_MakeEdge class with the previously computed curves:
@ -181,8 +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.
@image html /tutorial/images/tutorial_image006.png
@image latex /tutorial/images/tutorial_image006.png
@figure{/tutorial/images/tutorial_image006.png}
To apply a transformation on shapes (including wires), you first need to define the properties of a 3D geometric transformation by using the gp_Trsf class. This transformation can be a translation, a rotation, a scale, a reflection, or a combination of these.
In our case, we need to define a reflection with respect to the X axis of the global coordinate system. An axis, defined with the gp_Ax1 class, is built out of a point and has a direction (3D unitary vector). There are two ways to define this axis.
@ -265,8 +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 |
@image html /tutorial/images/tutorial_image007.png
@image latex /tutorial/images/tutorial_image007.png
@figure{/tutorial/images/tutorial_image007.png}
Your current profile is a wire. Referring to the Shape/Generates table, you need to compute a face out of its wire to generate a solid.
To create a face, use the *BRepBuilderAPI_MakeFace* class. As previously explained, a face is a part of a surface bounded by a closed wire. Generally, *BRepBuilderAPI_MakeFace* computes a face out of a surface and one or more wires.
@ -303,8 +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
@image html /tutorial/images/tutorial_image008.png
@image latex /tutorial/images/tutorial_image008.png
@figure{/tutorial/images/tutorial_image008.png}
To apply fillets on the edges of a shape, you use the *BRepFilletAPI_MakeFillet* class. This class is normally used as follows:
@ -360,8 +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.
@image html /tutorial/images/tutorial_image009.png
@image latex /tutorial/images/tutorial_image009.png
@figure{/tutorial/images/tutorial_image009.png}
To position the cylinder, you need to define a coordinate system with the *gp_Ax2* class defining a right-handed coordinate system from a point and two directions - the main (Z) axis direction and the X direction (the Y direction is computed from these two).
To align the neck with the center of the top face, being in the global coordinate system (0, 0, *myHeight*), with its normal on the global Z axis, your local coordinate system can be defined as follows:
@ -403,8 +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.
@image html /tutorial/images/tutorial_image010.png
@image latex /tutorial/images/tutorial_image010.png
@figure{/tutorial/images/tutorial_image010.png}
To compute a thick solid, you create an instance of the *BRepOffsetAPI_MakeThickSolid* class by giving the following information:
@ -509,8 +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:
@image html /tutorial/images/tutorial_image011.png
@image latex /tutorial/images/tutorial_image011.png
@figure{/tutorial/images/tutorial_image011.png}
Notice that one of the cylindrical surfaces is smaller than the neck. There is a good reason for this: after the thread creation, you will fuse it with the neck. So, we must make sure that the two shapes remain in contact.
@ -535,8 +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.
@image html /tutorial/images/tutorial_image012.png
@image latex /tutorial/images/tutorial_image012.png
@figure{/tutorial/images/tutorial_image012.png}
The advantage of having such parameterized geometries is that you can compute, for any (U, V) parameters of the surface:
@ -545,8 +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:
@image html /tutorial/images/tutorial_image013.png
@image latex /tutorial/images/tutorial_image013.png
@figure{/tutorial/images/tutorial_image013.png}
Suppose that you create a 2D line on this parametric (U, V) space and compute its 3D parametric curve. Depending on the line definition, results are as follows:
@ -561,16 +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:
@image html /tutorial/images/tutorial_image014.png
@image latex /tutorial/images/tutorial_image014.png
@figure{/tutorial/images/tutorial_image014.png}
In this (U, V) parametric space, you will create a local (X, Y) coordinate system to position the curves to be created. This coordinate system will be defined with:
* A center located in the middle of the neck's cylinder parametric space at (2*PI, myNeckHeight / 2) in U, V coordinates.
* A X direction defined with the (2*PI, myNeckHeight/4) vector in U, V coordinates, so that the curves occupy half of the neck's surfaces.
@image html /tutorial/images/tutorial_image015.png
@image latex /tutorial/images/tutorial_image015.png
@figure{/tutorial/images/tutorial_image015.png}
To use 2D primitive geometry types of Open CASCADE Technology for defining a point and a coordinate system, you will once again instantiate classes from gp:
@ -586,8 +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).
@image html /tutorial/images/tutorial_image016.png
@image latex /tutorial/images/tutorial_image016.png
@figure{/tutorial/images/tutorial_image016.png}
You have already used the *Geom* package to define 3D geometric entities. For 2D, you will use the *Geom2d* package. As for *Geom*, all geometries are parameterized. For example, a *Geom2d_Ellipse* ellipse is defined from:
@ -643,8 +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.
@image html /tutorial/images/tutorial_image017.png
@image latex /tutorial/images/tutorial_image017.png
@figure{/tutorial/images/tutorial_image017.png}
Previously, you have built:
@ -684,8 +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:
@image html /tutorial/images/tutorial_image018.png
@image latex /tutorial/images/tutorial_image018.png
@figure{/tutorial/images/tutorial_image018.png}
* Initialize the algorithm by creating an instance of the class. The first parameter of this constructor must be specified if you want to create a solid. By default, *BRepOffsetAPI_ThruSections* builds a shell.
* Add the successive wires using the AddWire method.
@ -715,8 +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:
@image html /tutorial/images/tutorial_image019.png
@image latex /tutorial/images/tutorial_image019.png
@figure{/tutorial/images/tutorial_image019.png}
We hope that this tutorial has provided you with a feel for the industrial strength power of Open CASCADE Technology.
If you want to know more and develop major projects using Open CASCADE Technology, we invite you to study our training, support, and consulting services on our site at http://www.opencascade.com/content/technology-support. Our professional services can maximize the power of your Open CASCADE Technology applications.

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

@ -194,8 +194,7 @@ The results are:
In the second case two edges have one or several common points in terms of tolerance.
@image html /user_guides/boolean_operations/images/operations_image006.svg "Edge/edge interference: common points"
@image latex /user_guides/boolean_operations/images/operations_image006.svg "Edge/edge interference: common points"
@figure{/user_guides/boolean_operations/images/operations_image006.svg, "Edge/edge interference: common points"}
The result is a new vertex *Vn* with 3D point *Pn* and tolerance value *Tol(Vn)*.
@ -260,13 +259,13 @@ For an edge *Ei* and a solid *Zj* there is Edge/Solid interference if the edge *
For a face *Fi* and a solid *Zj* there is Face/Solid interference if the face *Fi* and its sub-shapes have no BRep interferences with any sub-shape of *Zj* and *Fi* is completely inside the solid *Zj*.
@figure{/user_guides/boolean_operations/images/operations_image062.png, "Face/Solid Interference"}
@figure{/user_guides/boolean_operations/images/operations_image062.png, "Face/Solid Interference"}
@subsubsection occt_algorithms_3_1_10 Solid/Soild Interference
For a solid *Zi* and a solid *Zj* there is Solid/Solid interference if the solid *Zi* and its sub-shapes have no BRep interferences with any sub-shape of *Zj* and *Zi* is completely inside the solid *Zj*.
@figure{/user_guides/boolean_operations/images/operations_image063.png, "Solid/Solid Interference"}
@figure{/user_guides/boolean_operations/images/operations_image063.png, "Solid/Solid Interference"}
@subsubsection occt_algorithms_3_1_11 Computation Order
@ -1319,7 +1318,7 @@ In this case:
* argument edge *E1* has resulting split edges *E11* and *E12* (image of *E1*);
* argument edge *E2* has resulting split edges *E21* and *E22* (image of *E2*).
@figure{/user_guides/boolean_operations/images/boolean_image011.svg}
@figure{/user_guides/boolean_operations/images/boolean_image011.svg}
* The result of *Common* operation is an empty compound because the dimension (0) of the common part between the edges (vertex) is less than the dimension of the arguments (1).
@ -1327,13 +1326,13 @@ In this case:
In this case the argument edge *E1* has resulting split edges *E11* and *E12* (image of *E1*).
@figure{/user_guides/boolean_operations/images/boolean_image012.svg}
@figure{/user_guides/boolean_operations/images/boolean_image012.svg}
* The result of *Cut21* operation is a compound containing split parts of the argument *E2*, i.e. 2 new edges *E21* and *E12*. These edges have one shared vertex *Vn1*.
In this case the argument edge *E2* has resulting split edges *E21* and *E22* (image of *E2*).
@figure{/user_guides/boolean_operations/images/boolean_image013.svg}
@figure{/user_guides/boolean_operations/images/boolean_image013.svg}
@subsubsection occt_algorithms_9_4_6 Case 6: Two edges having a common block
@ -1347,20 +1346,20 @@ In this case:
* argument edge *E2* has resulting split edges *E21* and *E22* (image of *E2*);
* edge *E12* is common for the images of *E1* and *E2*.
@figure{/user_guides/boolean_operations/images/boolean_image015.svg}
@figure{/user_guides/boolean_operations/images/boolean_image015.svg}
* The result of *Common* operation is a compound containing split parts of arguments i.e. 1 new edge *E12*. In this case edge *E12* is common for the images of *E1* and *E2*.
The common part between the edges (edge) has the same dimension (1) as the dimension of the arguments (1).
@figure{/user_guides/boolean_operations/images/boolean_image016.svg}
@figure{/user_guides/boolean_operations/images/boolean_image016.svg}
* The result of *Cut12* operation is a compound containing a split part of argument *E1*, i.e. new edge *E11*.
@figure{/user_guides/boolean_operations/images/boolean_image017.svg}
@figure{/user_guides/boolean_operations/images/boolean_image017.svg}
* The result of *Cut21* operation is a compound containing a split part of argument *E2*, i.e. new edge *E22*.
@figure{/user_guides/boolean_operations/images/boolean_image018.svg}
@figure{/user_guides/boolean_operations/images/boolean_image018.svg}
@subsubsection occt_algorithms_9_4_7 Case 7: An Edge and a Face intersecting at a point
@ -1377,7 +1376,7 @@ Let us consider edge *E1* and face *F2* that intersect at a 3D point:
In this case the argument edge *E1* has no common parts with the face *F2* so the whole image of *E1* is in the result.
@figure{/user_guides/boolean_operations/images/boolean_image020.png}
@figure{/user_guides/boolean_operations/images/boolean_image020.png}
* The result of *Cut21* operation is not defined because the dimension of the edge (1) is less than the dimension of the face (2).
@ -1399,7 +1398,7 @@ In this case the argument edge *E1* has a common part with face *F2* so the corr
In this case the argument edge *E1* has a common part with face *F2* so the corresponding part is not included into the result. The yellow square is not a part of the result. It only shows the place of F2.
@figure{/user_guides/boolean_operations/images/boolean_image023.png}
@figure{/user_guides/boolean_operations/images/boolean_image023.png}
* The result of *Cut21* operation is not defined because the dimension of the edge (1) is less than the dimension of the face (2).
@ -1421,7 +1420,7 @@ In this case the argument edge *E1* has a common part with solid *S2* so the cor
In this case the argument edge *E1* has a common part with solid *S2* so the corresponding part is not included into the result. The yellow square is not a part of the result. It only shows the place of *S2*.
@figure{/user_guides/boolean_operations/images/boolean_image071.png}
@figure{/user_guides/boolean_operations/images/boolean_image071.png}
* The result of *Cut21* operation is not defined because the dimension of the edge (1) is less than the dimension of the solid (3).
@ -1443,7 +1442,7 @@ In this case the argument edge *E1* has a common part with solid *S2* so the cor
In this case the argument edge *E1* has a common part with solid *S2* so the corresponding part is not included into the result. The yellow square is not a part of the result. It only shows the place of *S2*.
@figure{/user_guides/boolean_operations/images/boolean_image026.png}
@figure{/user_guides/boolean_operations/images/boolean_image026.png}
* The result of *Cut21* operation is not defined because the dimension of the edge (1) is less than the dimension of the solid (3).
@ -1462,7 +1461,7 @@ Let us consider two intersecting faces *F1* and *F2*:
* The result of *Cut12* operation is a compound containing split part of the argument *F1*, i.e. new face *F11*.
@figure{/user_guides/boolean_operations/images/boolean_image029.png}
@figure{/user_guides/boolean_operations/images/boolean_image029.png}
* The result of *Cut21* operation is a compound containing split parts of the argument *F2*, i.e. 1 new face *F21*.
@ -1490,7 +1489,7 @@ The common part between the faces (face) has the same dimension (2) as the dimen
* The result of *Cut12* operation is a compound containing split part of the argument *F1*, i.e. new face *F11*.
@figure{/user_guides/boolean_operations/images/boolean_image034.png}
@figure{/user_guides/boolean_operations/images/boolean_image034.png}
* The result of *Cut21* operation is a compound containing split parts of the argument *F2*, i.e. 1 new face *F21*.
@ -1510,7 +1509,7 @@ Let us consider two faces *F1* and *F2* that have a common edge:
* The result of *Cut12* operation is a compound containing split part of the argument *F1*, i.e. new face *F11*. The vertices are shown just to clarify the fact that the edges are spitted.
@figure{/user_guides/boolean_operations/images/boolean_image038.png}
@figure{/user_guides/boolean_operations/images/boolean_image038.png}
* The result of *Cut21* operation is a compound containing split parts of the argument *F2*, i.e. 1 new face *F21*. The vertices are shown just to clarify the fact that the edges are spitted.
@ -1530,7 +1529,7 @@ Let us consider two faces *F1* and *F2* that have a common vertex:
* The result of *Cut12* operation is a compound containing split part of the argument *F1*, i.e. new face *F11*.
@figure{/user_guides/boolean_operations/images/boolean_image042.png}
@figure{/user_guides/boolean_operations/images/boolean_image042.png}
* The result of *Cut21* operation is a compound containing split parts of the argument *F2*, i.e. 1 new face *F21*.
@ -1551,7 +1550,7 @@ Let us consider face *F1* and solid *S2* that have an intersection curve:
* The result of *Cut12* operation is a compound containing split part of the argument *F1*. In this case argument face *F1* has a common part with solid *S2* so the corresponding part is not included into the result. The yellow contour is not a part of the result. It only shows the place of *S2*.
@figure{/user_guides/boolean_operations/images/boolean_image046.png}
@figure{/user_guides/boolean_operations/images/boolean_image046.png}
* The result of *Cut21* operation is is not defined because the dimension of the face (2) is less than the dimension of the solid (3).
@ -1569,7 +1568,7 @@ Let us consider face *F1* and solid *S2* that have overlapping faces:
* The result of *Cut12* operation is a compound containing split part of the argument *F1*. In this case argument face *F1* has a common part with solid *S2* so the corresponding part is not included into the result. The yellow contour is not a part of the result. It only shows the place of *S2*.
@figure{/user_guides/boolean_operations/images/boolean_image049.png}
@figure{/user_guides/boolean_operations/images/boolean_image049.png}
* The result of *Cut21* operation is is not defined because the dimension of the face (2) is less than the dimension of the solid (3).
@ -1586,7 +1585,7 @@ Let us consider face *F1* and solid *S2* that have overlapping edges:
* The result of *Cut12* operation is a compound containing split part of the argument *F1*. In this case argument face *F1* has a common part with solid *S2* so the corresponding part is not included into the result. The yellow contour is not a part of the result. It only shows the place of *S2*.
@figure{/user_guides/boolean_operations/images/boolean_image051.png}
@figure{/user_guides/boolean_operations/images/boolean_image051.png}
* The result of *Cut21* operation is is not defined because the dimension of the face (2) is less than the dimension of the solid (3).
@ -1602,7 +1601,7 @@ Let us consider face *F1* and solid *S2* that have overlapping vertices:
* The result of *Cut12* operation is a compound containing split part of the argument *F1*. In this case argument face *F1* has a common part with solid *S2* so the corresponding part is not included into the result. The yellow contour is not a part of the result. It only shows the place of *S2*.
@figure{/user_guides/boolean_operations/images/boolean_image053.png}
@figure{/user_guides/boolean_operations/images/boolean_image053.png}
* The result of *Cut21* operation is is not defined because the dimension of the face (2) is less than the dimension of the solid (3).
@ -1614,15 +1613,15 @@ Let us consider two intersecting solids *S1* and *S2*:
* The result of *Fuse* operation is a compound composed from the split parts of arguments *S11, S12* and *S22* <i>(Cut12, Common, Cut21)</i>. All inner webs are removed, so the result is one new solid *R*.
@figure{/user_guides/boolean_operations/images/boolean_image055.png}
@figure{/user_guides/boolean_operations/images/boolean_image055.png}
* The result of *Common* operation is a compound containing split parts of arguments i.e. one new solid *S12*. In this case solid *S12* is common for the images of *S1* and *S2*. The common part between the solids (solid) has the same dimension (3) as the dimension of the arguments (3). The yellow contour is not a part of the result. It only shows the place of *S1*.
@figure{/user_guides/boolean_operations/images/boolean_image056.png}
@figure{/user_guides/boolean_operations/images/boolean_image056.png}
* The result of *Cut12* operation is a compound containing split part of the argument *S1*, i.e. 1 new solid *S11*.
@figure{/user_guides/boolean_operations/images/boolean_image057.png}
@figure{/user_guides/boolean_operations/images/boolean_image057.png}
* The result of *Cut21* operation is a compound containing split part of the argument *S2*, i.e. 1 new solid *S21*.
@ -1636,13 +1635,13 @@ Let us consider two solids *S1* and *S2* that have a common part on face:
* The result of *Fuse* operation is a compound composed from the split parts of arguments *S11, S12* and *S22* <i>(Cut12, Common, Cut21)</i>. All inner webs are removed, so the result is one new solid *R*.
@figure{/user_guides/boolean_operations/images/boolean_image060.png}
@figure{/user_guides/boolean_operations/images/boolean_image060.png}
* The result of *Common* operation is an empty compound because the dimension (2) of the common part between *S1* and *S2* (face) is less than the lower dimension of the arguments (3).
* The result of *Cut12* operation is a compound containing split part of the argument *S1*, i.e. 1 new solid *S11*.
@figure{/user_guides/boolean_operations/images/boolean_image061.png}
@figure{/user_guides/boolean_operations/images/boolean_image061.png}
* The result of *Cut21* operation is a compound containing split part of the argument *S2*, i.e. 1 new solid *S21*.
@figure{/user_guides/boolean_operations/images/boolean_image062.png}
@ -1656,14 +1655,14 @@ Let us consider two solids *S1* and *S2* that have overlapping edges:
* The result of *Fuse* operation is a compound composed from the split parts of arguments i.e. 2 new solids *S11* and *S21*. These solids have one shared edge *En1*.
@figure{/user_guides/boolean_operations/images/boolean_image064.png}
@figure{/user_guides/boolean_operations/images/boolean_image064.png}
* The result of *Common* operation is an empty compound because the dimension (1) of the common part between *S1* and *S2* (edge) is less than the lower dimension of the arguments (3).
* The result of *Cut12* operation is a compound containing split part of the argument *S1*. In this case
argument *S1* has a common part with solid *S2* so the corresponding part is not included into the result.
@figure{/user_guides/boolean_operations/images/boolean_image065.png}
@figure{/user_guides/boolean_operations/images/boolean_image065.png}
* The result of *Cut21* operation is a compound containing split part of the argument *S2*. In this case
argument *S2* has a common part with solid *S1* so the corresponding part is not included into the result.
@ -1677,13 +1676,13 @@ Let us consider two solids *S1* and *S2* that have overlapping vertices:
* The result of *Fuse* operation is a compound composed from the split parts of arguments i.e. 2 new solids *S11* and *S21*. These solids share *Vn1*.
@figure{/user_guides/boolean_operations/images/boolean_image068.png}
@figure{/user_guides/boolean_operations/images/boolean_image068.png}
* The result of *Common* operation is an empty compound because the dimension (0) of the common part between *S1* and *S2* (vertex) is less than the lower dimension of the arguments (3).
* The result of *Cut12* operation is a compound containing split part of the argument *S1*.
@figure{/user_guides/boolean_operations/images/boolean_image069.png}
@figure{/user_guides/boolean_operations/images/boolean_image069.png}
* The result of *Cut21* operation is a compound containing split part of the argument *S2*.
@ -1699,11 +1698,11 @@ Let us consider Shell *Sh* and Wire *W* as the objects and Solid *S* as the tool
* The result of *Common* operation is a compound containing the parts of the initial Shell and Wire common for the Solid. The new Shell and Wire are created from the objects.
@figure{/user_guides/boolean_operations/images/boolean_image137.png}
@figure{/user_guides/boolean_operations/images/boolean_image137.png}
* The result of *Cut12* operation is a compound containing new Shell and Wire split from the arguments *Sh* and *W*. In this case they have a common part with solid *S* so the corresponding part is not included into the result.
@figure{/user_guides/boolean_operations/images/boolean_image138.png}
@figure{/user_guides/boolean_operations/images/boolean_image138.png}
* The result of *Cut21* operation is not defined as the objects have a lower dimension than the tool.
@ -1719,15 +1718,15 @@ Let us consider two Wires that have overlapping edges, *W1* is the object and *W
* The result of *Common* operation is a compound containing one Wire consisting of an overlapping edge. The new Wire is created from the objects:
@figure{/user_guides/boolean_operations/images/boolean_image141.png}
@figure{/user_guides/boolean_operations/images/boolean_image141.png}
* The result of *Cut12* operation is a compound containing a wire split from object *W1*. Its common part with *W2* is not included into the result.
@figure{/user_guides/boolean_operations/images/boolean_image142.png}
@figure{/user_guides/boolean_operations/images/boolean_image142.png}
* The result of *Cut21* operation is a compound containing a wire split from *W2*. Its common part with *W1* is not included into the result.
@figure{/user_guides/boolean_operations/images/boolean_image143.png}
@figure{/user_guides/boolean_operations/images/boolean_image143.png}
@subsection occt_algorithms_9_5 Class BOPAlgo_BOP
@ -1845,7 +1844,7 @@ Let us consider edges *E1* and *E2*, that have a common block:
The result of *Section* operation is the compound that contains a new edge *Enew*.
@figure{/user_guides/boolean_operations/images/boolean_image090.png}
@figure{/user_guides/boolean_operations/images/boolean_image090.png}
@subsubsection occt_algorithms_10a_3_7 Case 7: An Edge and a Face intersecting at a point
@ -1872,7 +1871,7 @@ The result of *Section* operation is the compound that contains new edge *Enew*.
Let us consider edge *E1* and solid *Z2*, that intersect at a point:
@figure{/user_guides/boolean_operations/images/boolean_image095.png}
@figure{/user_guides/boolean_operations/images/boolean_image095.png}
The result of *Section* operation is the compound that contains a new vertex *Vnew*.
@ -1952,7 +1951,7 @@ The result of *Section* operation is the compound that contains new edges
Let us consider face *F1* and solid *Z2* that have a common part on edge:
@figure{/user_guides/boolean_operations/images/boolean_image109.png}
@figure{/user_guides/boolean_operations/images/boolean_image109.png}
The result of *Section* operation is the compound that contains a new edge *Enew*.
@ -1971,18 +1970,18 @@ The result of *Section* operation is the compound that contains a new vertex *Vn
@subsubsection occt_algorithms_10a_3_19 Case 19: Two intersecting Solids
Let us consider two intersecting solids *Z1* and *Z2*:
@figure{/user_guides/boolean_operations/images/boolean_image113.png}
@figure{/user_guides/boolean_operations/images/boolean_image113.png}
The result of *Section* operation is the compound that contains new edges.
@figure{/user_guides/boolean_operations/images/boolean_image114.png}
@figure{/user_guides/boolean_operations/images/boolean_image114.png}
@subsubsection occt_algorithms_10a_3_20 Case 20: Two Solids that have overlapping faces
Let us consider two solids *Z1* and *Z2* that have a common part on face:
@figure{/user_guides/boolean_operations/images/boolean_image115.png}
@figure{/user_guides/boolean_operations/images/boolean_image115.png}
The result of *Section* operation is the compound that contains new edges.
@figure{/user_guides/boolean_operations/images/boolean_image116.png}
@figure{/user_guides/boolean_operations/images/boolean_image116.png}
@subsubsection occt_algorithms_10a_3_21 Case 21: Two Solids that have overlapping edges
@ -1990,15 +1989,15 @@ Let us consider two solids *Z1* and *Z2* that have overlapping edges:
@figure{/user_guides/boolean_operations/images/boolean_image117.png}
The result of *Section* operation is the compound that contains a new edge *Enew*.
@figure{/user_guides/boolean_operations/images/boolean_image118.png}
@figure{/user_guides/boolean_operations/images/boolean_image118.png}
@subsubsection occt_algorithms_10a_3_22 Case 22: Two Solids that have overlapping vertices
Let us consider two solids *Z1* and *Z2* that have overlapping vertices:
@figure{/user_guides/boolean_operations/images/boolean_image119.png}
@figure{/user_guides/boolean_operations/images/boolean_image119.png}
The result of *Section* operation is the compound that contains a new vertex *Vnew*.
@figure{/user_guides/boolean_operations/images/boolean_image120.png}
@figure{/user_guides/boolean_operations/images/boolean_image120.png}
@subsection occt_algorithms_10a_4 Class BOPAlgo_Section
@ -2366,8 +2365,8 @@ The face *F* is a self-interfered shape and cannot be used as an argument of the
#### Example 4: Face of Revolution
The face *F* has been obtained by revolution of edge *E* around line *L*.
@figure{/user_guides/boolean_operations/images/operations_image039a.png, "Face of Revolution: Arguments"}
@figure{/user_guides/boolean_operations/images/operations_image039b.png, "Face of Revolution: Result"}
@figure{/user_guides/boolean_operations/images/operations_image039a.png, "Face of Revolution: Arguments"}
@figure{/user_guides/boolean_operations/images/operations_image039b.png, "Face of Revolution: Result"}
In spite of the fact that face *F* is valid (in terms of *BRepCheck_Analyzer*) it is a self-interfered shape and cannot be used as the argument of the Algorithms.
@ -2445,7 +2444,7 @@ Let us consider the intersection between two edges:
* *E1* is based on a line: <i>{0,-10,0, 1,0,0}, Tol(E1)=2.</i>
* *E2* is based on a circle: <i>{0,0,0, 0,0,1}, R=10, Tol(E2)=2.</i>
@figure{/user_guides/boolean_operations/images/operations_image049.png, "Intersecting Edges"}
@figure{/user_guides/boolean_operations/images/operations_image049.png, "Intersecting Edges"}
The result of pure intersection between *E1* and *E2* is vertex *Vx {0,-10,0}*.
@ -2465,7 +2464,7 @@ Let us consider two planar rectangular faces *F1* and *F2*.
The intersection curve between the planes is curve *C12*. The curve produces a new intersection edge *EC12*. The edge goes through vertices *V1* and *V2* thanks to big tolerance values of vertices *Tol(V1)* and *Tol(V2)*. So, two straight edges *E12* and *EC12* go through two vertices, which is impossible in this case.
@figure{/user_guides/boolean_operations/images/operations_image050.svg, "Intersecting Faces"}
@figure{/user_guides/boolean_operations/images/operations_image050.svg, "Intersecting Faces"}
The problem cannot be solved in general, because the length of *E12* can be infinite and the values of *Tol(V1)* and *Tol(V2)* theoretically can be infinite too.
@ -2482,11 +2481,11 @@ Let us consider two edges *E1* and *E2*, which have common vertices *V1* and *V2
*C1* practically coincides in 3D with *C2*. The value of deflection is *Dmax* (e.g. *Dmax=1.e<sup>-6</sup>*).
@figure{/user_guides/boolean_operations/images/operations_image051.svg, "Intersecting Edges"}
@figure{/user_guides/boolean_operations/images/operations_image051.svg, "Intersecting Edges"}
The evident and prospective result should be the Common Block between *E1* and *E2*. However, the result of intersection differs.
@figure{/user_guides/boolean_operations/images/operations_image052.svg, "Result of Intersection"}
@figure{/user_guides/boolean_operations/images/operations_image052.svg, "Result of Intersection"}
The result contains three new vertices *Vx1, Vx2* and *Vx3*, 8 new edges <i>(V1, Vx1, Vx2, Vx3, V2)</i> and no Common Blocks. This is correct due to the source data: *Tol(E1)=1.e<sup>-7</sup>, Tol(E2)=1.e<sup>-7</sup>* and <i>Dmax=1.e<sup>-6</sup></i>.
@ -2496,7 +2495,7 @@ In this particular case the problem can be solved by several ways:
The example can be extended from 1D (edges) to 2D (faces).
@figure{/user_guides/boolean_operations/images/operations_image053.svg, "Intersecting Faces"}
@figure{/user_guides/boolean_operations/images/operations_image053.svg, "Intersecting Faces"}
The comments and recommendations are the same as for 1D case above.
@ -2506,7 +2505,7 @@ The comments and recommendations are the same as for 1D case above.
Let us consider vertex *V1* and edge *E2*.
@figure{/user_guides/boolean_operations/images/operations_image054.svg, "Vertex and Edge"}
@figure{/user_guides/boolean_operations/images/operations_image054.svg, "Vertex and Edge"}
Vertex *V1* interferes with vertices *V12* and *V22*.
So vertex *V21* should interfere with vertex *V22*, which is impossible because vertices *V21* and *V22* are the vertices of edge *E2*, thus *V21* is not equal to *V22*.
@ -2519,7 +2518,7 @@ In a particular case the problem can be solved by refinement of arguments, i.e.
Let us consider vertex *V2* and wire consisting of edges *E11* and *E12*.
@figure{/user_guides/boolean_operations/images/operations_image055.svg, "Vertex and Wire"}
@figure{/user_guides/boolean_operations/images/operations_image055.svg, "Vertex and Wire"}
The arguments themselves are not self-intersected.
Vertex *V2* interferes with edges *E11* and *E12*. Thus, edge *E11* should interfere with edge *E22*, but it is impossible because edges *E11* and *E12* cannot interfere by the condition.
@ -2551,13 +2550,13 @@ The following examples demonstrate the advantages of usage Fuzzy option operatio
In this example the cylinder (shown in yellow and transparent) is subtracted from the box (shown in red). The cylinder is shifted by 5e<sup>-5</sup> relatively to the box along its axis (the distance between rear faces of the box and cylinder is 5e<sup>-5</sup>).
@figure{/user_guides/boolean_operations/images/boolean_image121.png}
@figure{/user_guides/boolean_operations/images/boolean_image121.png}
The following results are obtained using Basic Operations and the Fuzzy ones with the fuzzy value 5e<sup>-5</sup>:
@figure{/user_guides/boolean_operations/images/boolean_image122.png, "Result of CUT operation obtained with Basic Operations"}
@figure{/user_guides/boolean_operations/images/boolean_image122.png, "Result of CUT operation obtained with Basic Operations"}
@figure{/user_guides/boolean_operations/images/boolean_image123.png, "Result of CUT operation obtained with Fuzzy Option"}
@figure{/user_guides/boolean_operations/images/boolean_image123.png, "Result of CUT operation obtained with Fuzzy Option"}
In this example Fuzzy option allows eliminating a very thin part of the result shape produced by Basic algorithm due to misalignment of rear faces of the box and the cylinder.
@ -2565,13 +2564,13 @@ In this example Fuzzy option allows eliminating a very thin part of the result s
In this example two boxes are fused. One of them has dimensions 10*10*10, and the other is 10*10.000001*10.000001 and adjacent to the first one. There is no gap in this case as the surfaces of the neighboring faces coincide, but one box is slightly greater than the other.
@figure{/user_guides/boolean_operations/images/boolean_image124.png}
@figure{/user_guides/boolean_operations/images/boolean_image124.png}
The following results are obtained using Basic Operations and the Fuzzy ones with the fuzzy value 1e<sup>-6</sup>:
@figure{/user_guides/boolean_operations/images/boolean_image125.png, "Result of CUT operation obtained with Basic Operations"}
@figure{/user_guides/boolean_operations/images/boolean_image125.png, "Result of CUT operation obtained with Basic Operations"}
@figure{/user_guides/boolean_operations/images/boolean_image126.png, "Result of CUT operation obtained with Fuzzy Option"}
@figure{/user_guides/boolean_operations/images/boolean_image126.png, "Result of CUT operation obtained with Fuzzy Option"}
In this example Fuzzy option allows eliminating an extremely narrow face in the result produced by Basic operation.
@ -2579,13 +2578,13 @@ In this example Fuzzy option allows eliminating an extremely narrow face in the
In this example the small planar face (shown in orange) is subtracted from the big one (shown in yellow). There is a gap 1e<sup>-5</sup> between the edges of these faces.
@figure{/user_guides/boolean_operations/images/boolean_image127.png}
@figure{/user_guides/boolean_operations/images/boolean_image127.png}
The following results are obtained using Basic Operations and the Fuzzy ones with the fuzzy value 1e<sup>-5</sup>:
@figure{/user_guides/boolean_operations/images/boolean_image128.png, "Result of CUT operation obtained with Basic Operations"}
@figure{/user_guides/boolean_operations/images/boolean_image128.png, "Result of CUT operation obtained with Basic Operations"}
@figure{/user_guides/boolean_operations/images/boolean_image129.png, "Result of CUT operation obtained with Fuzzy Option"}
@figure{/user_guides/boolean_operations/images/boolean_image129.png, "Result of CUT operation obtained with Fuzzy Option"}
In this example Fuzzy options eliminated a pin-like protrusion resulting from the gap between edges of the argument faces.
@ -2593,13 +2592,13 @@ In this example Fuzzy options eliminated a pin-like protrusion resulting from th
In this example the small edge is subtracted from the big one. The edges are overlapping not precisely, with max deviation between them equal to 5.28004e<sup>-5</sup>. We will use 6e<sup>-5</sup> value for Fuzzy option.
@figure{/user_guides/boolean_operations/images/boolean_image130.png}
@figure{/user_guides/boolean_operations/images/boolean_image130.png}
The following results are obtained using Basic Operations and the Fuzzy ones with the fuzzy value 6e<sup>-5</sup>:
@figure{/user_guides/boolean_operations/images/boolean_image131.png, "Result of CUT operation obtained with Basic Operations"}
@figure{/user_guides/boolean_operations/images/boolean_image131.png, "Result of CUT operation obtained with Basic Operations"}
@figure{/user_guides/boolean_operations/images/boolean_image132.png, "Result of CUT operation obtained with Fuzzy Option"}
@figure{/user_guides/boolean_operations/images/boolean_image132.png, "Result of CUT operation obtained with Fuzzy Option"}
This example stresses not only the validity, but also the performance issue. The usage of Fuzzy option with the appropriate value allows processing the case much faster than with the pure Basic operation. The performance gain for the case is 45 (Processor: Intel(R) Core(TM) i5-3450 CPU @ 3.10 GHz).
@ -2721,7 +2720,7 @@ The package consists of the following classes:
* *BRepAlgoAPI_Cut* -- the class provides Boolean cut operation.
* *BRepAlgoAPI_Section* -- the class provides Boolean section operation.
@figure{/user_guides/boolean_operations/images/operations_image065.png, "Diagram of BRepAlgoAPI package"}
@figure{/user_guides/boolean_operations/images/operations_image065.png, "Diagram of BRepAlgoAPI package"}
The detailed description of the classes can be found in the corresponding .hxx files. The examples are below in this chapter.

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

@ -111,8 +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.
@image html /user_guides/foundation_classes/images/foundation_classes_image003.png "Contents of a package"
@image latex /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"}
**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.
@ -143,8 +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
@image html /user_guides/foundation_classes/images/foundation_classes_image004.png "Manipulation of data types"
@image latex /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"}
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.
@ -213,15 +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.
@image html /user_guides/foundation_classes/images/foundation_classes_image005.png "Manipulation of a data type by value"
@image latex /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"}
@subsubsection occt_fcug_2_1_3 Types manipulated by reference (handle)
These are types defined by classes inheriting from the *Transient* class.
@image html /user_guides/foundation_classes/images/foundation_classes_image006.png "Manipulation of a data type by reference"
@image latex /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"}
@subsubsection occt_fcug_2_1_4 When is it necessary to use a handle?
@ -1754,7 +1750,7 @@ main ()
sol.Solve(b1, x1); // yes, so compute x1
sol.Solve(b2, x2); // then x2
...
}
}
else { // it is not OK:
// fix up
sol.Solve(b1, x1); // error:

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

@ -601,8 +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.
@image html /user_guides/iges/images/iges_image003.png "The structure of calls in reading IGES"
@image latex /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"}
@subsection occt_iges_2_8 Example
@ -820,8 +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.
@image html /user_guides/iges/images/iges_image004.png "The class structure in writing IGES"
@image latex /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"}
@subsection occt_iges_3_7 Example

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

@ -28,13 +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.
@image html /user_guides/modeling_algos/images/modeling_algos_image003.png "Intersection and self-intersection of curves"
@image latex /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"}
In both cases, the algorithm requires a value for the tolerance (Standard_Real) for the confusion between two points. The default tolerance value used in all constructors is *1.0e-6.*
@image html /user_guides/modeling_algos/images/modeling_algos_image004.png "Intersection and tangent intersection"
@image latex /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"}
The algorithm returns a point in the case of an intersection and a segment in the case of tangent intersection.
@ -266,21 +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;).
@image html /user_guides/modeling_algos/images/modeling_algos_image006.png "Exterior/Interior of a Circle"
@image latex /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"}
By extension, the interior of a line or any open curve is defined as the left side according to the passing direction, as shown in the following diagram:
@image html /user_guides/modeling_algos/images/modeling_algos_image007.png "Exterior/Interior of a Line and a Curve"
@image latex /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"}
#### Orientation of a Line
It is sometimes necessary to define in advance the sense of travel along a line to be created. This sense will be from first to second argument.
The following figure shows a line, which is first tangent to circle C1 which is interior to the line, and then passes through point P1.
@image html /user_guides/modeling_algos/images/modeling_algos_image008.png "An Oriented Line"
@image latex /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"}
#### Line tangent to two circles
@ -289,8 +284,7 @@ The following four diagrams illustrate four cases of using qualifiers in the cr
**Example 1 Case 1**
@image html /user_guides/modeling_algos/images/modeling_algos_image009.png "Both circles outside"
@image latex /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"}
Constraints:
Tangent and Exterior to C1.
@ -307,8 +301,7 @@ GccAna_Lin2d2Tan
**Example 1 Case 2**
@image html /user_guides/modeling_algos/images/modeling_algos_image010.png "Both circles enclosed"
@image latex /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"}
Constraints:
Tangent and Including C1.
@ -325,8 +318,7 @@ GccAna_Lin2d2Tan
**Example 1 Case 3**
@image html /user_guides/modeling_algos/images/modeling_algos_image011.png "C1 enclosed, C2 outside"
@image latex /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, C2 outside"}
Constraints:
Tangent and Including C1.
@ -342,8 +334,7 @@ GccAna_Lin2d2Tan
**Example 1 Case 4**
@image html /user_guides/modeling_algos/images/modeling_algos_image012.png "C1 outside, C2 enclosed"
@image latex /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, C2 enclosed"}
Constraints:
Tangent and Exterior to C1.
Tangent and Including C2.
@ -358,8 +349,7 @@ GccAna_Lin2d2Tan
**Example 1 Case 5**
@image html /user_guides/modeling_algos/images/modeling_algos_image013.png "With no qualifiers specified"
@image latex /user_guides/modeling_algos/images/modeling_algos_image013.png "With no qualifiers specified"
@figure{/user_guides/modeling_algos/images/modeling_algos_image013.png, "With no qualifiers specified"}
Constraints:
Tangent and Undefined with respect to C1.
@ -377,8 +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**
@image html /user_guides/modeling_algos/images/modeling_algos_image014.png "Both solutions outside"
@image latex /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"}
Constraints:
Tangent and Exterior to C1.
@ -393,8 +382,7 @@ GccAna_Circ2d2TanRad
**Example 2 Case 2**
@image html /user_guides/modeling_algos/images/modeling_algos_image015.png "C2 encompasses C1"
@image latex /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"}
Constraints:
Tangent and Exterior to C1.
@ -408,8 +396,7 @@ GccAna_Circ2d2TanRad
~~~~~
**Example 2 Case 3**
@image html /user_guides/modeling_algos/images/modeling_algos_image016.png "Solutions enclose C2"
@image latex /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"}
Constraints:
Tangent and Exterior to C1.
@ -423,8 +410,7 @@ GccAna_Circ2d2TanRad
~~~~~
**Example 2 Case 4**
@image html /user_guides/modeling_algos/images/modeling_algos_image017.png "Solutions enclose C1"
@image latex /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"}
Constraints:
Tangent and Enclosing C1.
@ -592,8 +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.
@image html /user_guides/modeling_algos/images/modeling_algos_image018.png "Intersecting filleted edges with different radii leave a gap, is filled by a surface"
@image latex /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, is filled by a surface"}
@subsubsection occt_modalg_2_5_5 Plate surfaces
@ -700,8 +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.
@image html /user_guides/modeling_algos/images/modeling_algos_image020.png "Normals from a point to a curve"
@image latex /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"}
The curve does not have to be a *Geom2d_TrimmedCurve*. The algorithm will function with any class inheriting *Geom2d_Curve*.
@ -935,8 +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*.
@image html /user_guides/modeling_algos/images/modeling_algos_image021.png "Projection of normals from a point to a surface"
@image latex /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"}
Note that the surface does not have to be of *Geom_RectangularTrimmedSurface* type.
The algorithm will function with any class inheriting *Geom_Surface*.
@ -1340,8 +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.
@image html /user_guides/modeling_algos/images/modeling_algos_image022.png "Basic Edge Construction"
@image latex /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"}
The following rules apply to the arguments:
@ -1367,8 +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.
@image html /user_guides/modeling_algos/images/modeling_algos_image023.png "Infinite and Periodic Edges"
@image latex /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"}
@subsubsection occt_modalg_3_2_2 Supplementary edge construction methods
@ -1443,8 +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.
@image html /user_guides/modeling_algos/images/modeling_algos_image024.png "Creating a Wire"
@image latex /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"}
~~~~~
#include <BRepBuilderAPI_MakeEdge.hxx>
@ -1573,8 +1553,7 @@ Standard_Real umin,umax,vmin,vmax; // parameters
TopoDS_Face F = BRepBuilderAPI_MakeFace(S,umin,umax,vmin,vmax);
~~~~~
@image html /user_guides/modeling_algos/images/modeling_algos_image025.png "Basic Face Construction"
@image latex /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"}
To make a face from the natural boundary of a surface, the parameters are not required:
@ -1792,8 +1771,7 @@ TopoDS_Solid theBox = BRepPrimAPI_MakeBox(10.,20.,30.);
The four methods to build a box are shown in the figure:
@image html /user_guides/modeling_algos/images/modeling_algos_image026.png "Making Boxes"
@image latex /user_guides/modeling_algos/images/modeling_algos_image026.png "Making Boxes"
@figure{/user_guides/modeling_algos/images/modeling_algos_image026.png, "Making Boxes"}
@subsubsection occt_modalg_4_1_2 Wedge
*BRepPrimAPI_MakeWedge* class allows building a wedge, which is a slanted box, i.e. a box with angles. The wedge is constructed in much the same way as a box i.e. from three dimensions dx,dy,dz plus arguments or from an axis system, three dimensions, and arguments.
@ -1803,8 +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*.
@image html /user_guides/modeling_algos/images/modeling_algos_image027.png "Making Wedges"
@image latex /user_guides/modeling_algos/images/modeling_algos_image027.png "Making Wedges"
@figure{/user_guides/modeling_algos/images/modeling_algos_image027.png, "Making Wedges"}
@subsubsection occt_modalg_4_1_3 Rotation object
*BRepPrimAPI_MakeOneAxis* is a deferred class used as a root class for all classes constructing rotational primitives. Rotational primitives are created by rotating a curve around an axis. They cover the cylinder, the cone, the sphere, the torus, and the revolution, which provides all other curves.
@ -1817,8 +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.
@image html /user_guides/modeling_algos/images/modeling_algos_image028.png "MakeOneAxis arguments"
@image latex /user_guides/modeling_algos/images/modeling_algos_image028.png "MakeOneAxis arguments"
@figure{/user_guides/modeling_algos/images/modeling_algos_image028.png, "MakeOneAxis arguments"}
@subsubsection occt_modalg_4_1_4 Cylinder
*BRepPrimAPI_MakeCylinder* class allows creating cylindrical primitives. A cylinder is created either in the default coordinate system or in a given coordinate system *gp_Ax2*. There are two constructions:
@ -1837,8 +1813,7 @@ axes.Translate(gp_Vec(X,Y,Z));
TopoDS_Face F =
BRepPrimAPI_MakeCylinder(axes,R,DY,PI/2.);
~~~~~
@image html /user_guides/modeling_algos/images/modeling_algos_image029.png "Cylinder"
@image latex /user_guides/modeling_algos/images/modeling_algos_image029.png "Cylinder"
@figure{/user_guides/modeling_algos/images/modeling_algos_image029.png, "Cylinder"}
@subsubsection occt_modalg_4_1_5 Cone
*BRepPrimAPI_MakeCone* class allows creating conical primitives. Like a cylinder, a cone is created either in the default coordinate system or in a given coordinate system (gp_Ax2). There are two constructions:
@ -1853,8 +1828,7 @@ Standard_Real R1 = 30, R2 = 10, H = 15;
TopoDS_Solid S = BRepPrimAPI_MakeCone(R1,R2,H);
~~~~~
@image html /user_guides/modeling_algos/images/modeling_algos_image030.png "Cone"
@image latex /user_guides/modeling_algos/images/modeling_algos_image030.png "Cone"
@figure{/user_guides/modeling_algos/images/modeling_algos_image030.png, "Cone"}
@subsubsection occt_modalg_4_1_6 Sphere
*BRepPrimAPI_MakeSphere* class allows creating spherical primitives. Like a cylinder, a sphere is created either in the default coordinate system or in a given coordinate system *gp_Ax2*. There are four constructions:
@ -1877,8 +1851,7 @@ TopoDS_Solid S4 = BRepPrimAPI_MakeSphere(R,a1,a2,ang);
Note that we could equally well choose to create Shells instead of Solids.
@image html /user_guides/modeling_algos/images/modeling_algos_image031.png "Examples of Spheres"
@image latex /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"}
@subsubsection occt_modalg_4_1_7 Torus
@ -1889,8 +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.
@image html /user_guides/modeling_algos/images/modeling_algos_image032.png "Examples of Tori"
@image latex /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"}
The following code builds four toroidal shells from two radii and three angles.
@ -1930,8 +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.
@image html /user_guides/modeling_algos/images/modeling_algos_image033.png "Generating a sweep"
@image latex /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"}
*BRepPrimAPI_MakeSweep class* is a deferred class used as a root of the the following sweep classes:
* *BRepPrimAPI_MakePrism* -- produces a linear sweep
@ -1961,8 +1932,7 @@ TopoDS_Solid P3 = BRepPrimAPI_MakePrism(F,direc,Standard_False);
// semi-infinite
~~~~~
@image html /user_guides/modeling_algos/images/modeling_algos_image034.png "Finite, infinite, and semi-infinite prisms"
@image latex /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"}
@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.
@ -1978,8 +1948,7 @@ TopoDS_Solid R1 = BRepPrimAPI_MakeRevol(F,axis);
TopoDS_Solid R2 = BRepPrimAPI_MakeRevol(F,axis,ang);
~~~~~
@image html /user_guides/modeling_algos/images/modeling_algos_image035.png "Full and partial rotation"
@image latex /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"}
@section occt_modalg_5 Boolean Operations
@ -1991,8 +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 |
@image html /user_guides/modeling_algos/images/modeling_algos_image036.png "Boolean Operations"
@image latex /user_guides/modeling_algos/images/modeling_algos_image036.png "Boolean Operations"
@figure{/user_guides/modeling_algos/images/modeling_algos_image036.png, "Boolean Operations"}
From the viewpoint of Topology these are topological operations followed by blending (putting fillets onto edges created after the topological operation).
@ -2043,8 +2011,7 @@ TopoDS_Shape S = BRepAlgoAPI_Cut(A,B);
*BRepAlgoAPI_Section* performs the section, described as a *TopoDS_Compound* made of *TopoDS_Edge*.
@image html /user_guides/modeling_algos/images/modeling_algos_image037.png "Section operation"
@image latex /user_guides/modeling_algos/images/modeling_algos_image037.png "Section operation"
@figure{/user_guides/modeling_algos/images/modeling_algos_image037.png, "Section operation"}
~~~~~
TopoDS_Shape A = ..., TopoDS_ShapeB = ...;
@ -2072,8 +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.
@image html /user_guides/modeling_algos/images/modeling_algos_image038.png "Filleting two edges using radii r1 and r2."
@image latex /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."}
In the following example a filleted box with dimensions a,b,c and radius r is created.
@ -2107,8 +2073,7 @@ TopoDS_Shape FilletedBox(const Standard_Real a,
}
~~~~~
@image html /user_guides/modeling_algos/images/modeling_algos_image039.png "Fillet with constant radius"
@image latex /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"}
#### Changing radius
@ -2136,8 +2101,7 @@ void CSampleTopologicalOperationsDoc::OnEvolvedblend1()
}
~~~~~
@image html /user_guides/modeling_algos/images/modeling_algos_image040.png "Fillet with changing radius"
@image latex /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"}
@subsection occt_modalg_6_1_2 Chamfer
@ -2152,8 +2116,7 @@ Add(dist, E, F)
Add(d1, d2, E, F) with d1 on the face F.
~~~~~
@image html /user_guides/modeling_algos/images/modeling_algos_image041.png "Chamfer"
@image latex /user_guides/modeling_algos/images/modeling_algos_image041.png "Chamfer"
@figure{/user_guides/modeling_algos/images/modeling_algos_image041.png, "Chamfer"}
@subsection occt_modalg_6_1_3 Fillet on a planar face
@ -2276,8 +2239,7 @@ if (SolidMaker.IsDone())
Result = SolidMaker.Shape();
~~~~~
@image html /user_guides/modeling_algos/images/modeling_algos_image042.png "Shelling"
@image latex /user_guides/modeling_algos/images/modeling_algos_image042.png "Shelling"
@figure{/user_guides/modeling_algos/images/modeling_algos_image042.png, "Shelling"}
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:
@ -2338,8 +2300,7 @@ else {
}
~~~~~
@image html /user_guides/modeling_algos/images/modeling_algos_image043.png "DraftAngle"
@image latex /user_guides/modeling_algos/images/modeling_algos_image043.png "DraftAngle"
@figure{/user_guides/modeling_algos/images/modeling_algos_image043.png, "DraftAngle"}
@subsection occt_modalg_7_4 Pipe Constructor
@ -2353,8 +2314,7 @@ TopoDS_Shape Profile = ...;
TopoDS_Shape Pipe = BRepOffsetAPI_MakePipe(Spine,Profile);
~~~~~
@image html /user_guides/modeling_algos/images/modeling_algos_image044.png "Example of a Pipe"
@image latex /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"}
@subsection occt_modalg_7_5 Evolved Solid
@ -2385,8 +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.
@image html /user_guides/modeling_algos/images/modeling_algos_image045.png "Shapes with partially shared edges"
@image latex /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"}
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.
@ -2572,11 +2531,9 @@ if (thePrism.IsDone()) {
}
~~~~~
@image html /user_guides/modeling_algos/images/modeling_algos_image047.png "Fusion with MakePrism"
@image latex /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"}
@image html /user_guides/modeling_algos/images/modeling_algos_image048.png "Creating a prism between two faces with Perform(From, Until)"
@image latex /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(From, Until)"}
@subsubsection occt_modalg_9_1_2 Draft Prism
@ -2629,8 +2586,7 @@ MKDP.Perform(200);
TopoDS_Shape res1 = MKDP.Shape();
~~~~~
@image html /user_guides/modeling_algos/images/modeling_algos_image049.png "A tapered prism"
@image latex /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"}
@subsubsection occt_modalg_9_1_3 Revolution
@ -2740,8 +2696,7 @@ MKPipe.Perform();
TopoDS_Shape res1 = MKPipe.Shape();
~~~~~
@image html /user_guides/modeling_algos/images/modeling_algos_image050.png "Pipe depression"
@image latex /user_guides/modeling_algos/images/modeling_algos_image050.png "Pipe depression"
@figure{/user_guides/modeling_algos/images/modeling_algos_image050.png, "Pipe depression"}
@subsection occt_modalg_9_2 Mechanical Features
@ -2801,8 +2756,7 @@ aform.Perform();
TopoDS_Shape res = aform.Shape();
~~~~~
@image html /user_guides/modeling_algos/images/modeling_algos_image051.png "Creating a rib"
@image latex /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"}
@subsubsection occt_modalg_9_2_3 Gluer
@ -2886,17 +2840,13 @@ However, there some restrictions in HLR use:
* Infinite faces or lines are not processed.
@image html /user_guides/modeling_algos/images/modeling_algos_image052.png "Sharp, smooth and sewn edges in a simple screw shape"
@image latex /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"}
@image html /user_guides/modeling_algos/images/modeling_algos_image053.png "Outline edges and isoparameters in the same shape"
@image latex /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"}
@image html /user_guides/modeling_algos/images/modeling_algos_image054.png "A simple screw shape seen with shading"
@image latex /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"}
@image html /user_guides/modeling_algos/images/modeling_algos_image055.png "An extraction showing hidden sharp edges"
@image latex /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"}
The following services are related to Hidden Lines Removal :

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

@ -49,8 +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.
@image html /user_guides/modeling_data/images/modeling_data_image003.png "Approximation of a BSpline from scattered points"
@image latex /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"}
This class may be instantiated as follows:
~~~~~
@ -110,8 +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.
@image html /user_guides/modeling_data/images/modeling_data_image004.png "Definition of a MultiLine using Multiple Point Constraints"
@image latex /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"}
In this image:
* *Pi*, *Qi*, *Ri* ... *Si* can be 2D or 3D points.
@ -618,8 +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.
@image html /user_guides/modeling_data/images/modeling_data_continuity_curves.svg "Continuity of Curves"
@image latex /user_guides/modeling_data/images/modeling_data_continuity_curves.svg "Continuity of Curves" width=\\textwidth
@figure{/user_guides/modeling_data/images/modeling_data_continuity_curves.svg, "Continuity of Curves"}
The following types of surface continuity are supported:
* C0 (*GeomAbs_C0*) - parametric continuity (the surface has no points or curves of discontinuity).
@ -630,8 +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).
@image html /user_guides/modeling_data/images/modeling_data_continuity_surfaces.svg "Continuity of Surfaces"
@image latex /user_guides/modeling_data/images/modeling_data_continuity_surfaces.svg "Continuity of Surfaces" width=\\textwidth
@figure{/user_guides/modeling_data/images/modeling_data_continuity_surfaces.svg, "Continuity of Surfaces"}
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.
@ -778,8 +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.
@image html /user_guides/modeling_data/images/modeling_data_image005.png "Structure of TopLoc_Location"
@image latex /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"}
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.
@ -823,8 +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.
@image html /user_guides/modeling_data/images/modeling_data_image006.png "ShapeEnum"
@image latex /user_guides/modeling_data/images/modeling_data_image006.png "ShapeEnum"
@figure{/user_guides/modeling_data/images/modeling_data_image006.png, "ShapeEnum"}
@subsubsection occt_modat_5_2_2 Orientation
@ -850,8 +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. |
@image html /user_guides/modeling_data/images/modeling_data_image007.png "Four Orientations"
@image latex /user_guides/modeling_data/images/modeling_data_image007.png "Four Orientations"
@figure{/user_guides/modeling_data/images/modeling_data_image007.png, "Four Orientations"}
The notion of orientation is a very general one, and it can be used in any context where regions or boundaries appear. Thus, for example, when describing the intersection of an edge and a contour it is possible to describe not only the vertex of intersection but also how the edge crosses the contour considering it as a boundary. The edge would therefore be divided into two regions: exterior and interior and the intersection vertex would be the boundary. Thus an orientation can be associated with an intersection vertex as in the following figure:
@ -862,8 +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 |
@image html /user_guides/modeling_data/images/modeling_data_image008.png "Four orientations of intersection vertices"
@image latex /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"}
Along with the Orientation enumeration the *TopAbs* package defines four methods:
@ -881,13 +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.
@image html /user_guides/modeling_data/images/modeling_data_image009.png "The four states"
@image latex /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"}
The State enumeration can also be used to specify various parts of an object. The following figure shows the parts of an edge intersecting a face.
@image html /user_guides/modeling_data/images/modeling_data_image010.png "State specifies the parts of an edge intersecting a face"
@image latex /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"}
@subsection occt_modat_5_3 Manipulating shapes and sub-shapes
@ -913,11 +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.
@image html /user_guides/modeling_data/images/modeling_data_image011.png "Structure of a shell formed from two faces"
@image latex /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"}
@image html /user_guides/modeling_data/images/modeling_data_image012.png "Data structure of the above shell"
@image latex /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"}
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.
@ -934,8 +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.
@image html /user_guides/modeling_data/images/modeling_data_image013.png "Data structure containing two versions of a solid"
@image latex /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"}
Classes inheriting TopoDS_Shape
------------------------------
@ -1276,8 +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} :
@image html /user_guides/modeling_data/images/modeling_data_image014.png "A wire composed of 6 edges."
@image latex /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."}
*TopExp_Explorer*, however, recuperates the lines in any order.

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

@ -65,8 +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.
@image html ocaf_wp_image003.png "The Application-Document-Attribute model"
@image latex ocaf_wp_image003.png "The Application-Document-Attribute model"
@figure{ocaf_wp_image003.png, "The Application-Document-Attribute model"}
@subsubsection occt_ocaf_1_2_1 Application
@ -134,8 +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.
@image html ocaf_image004.png "Topology driven versus reference-key driven approaches"
@image latex ocaf_image004.png "Topology driven versus reference-key driven approaches"
@figure{ocaf_image004.png, "Topology driven versus reference-key driven approaches"}
Reference-keys can be created in two ways:
@ -215,8 +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.
@image html /user_guides/ocaf/images/ocaf_image005.png "A simple framework model"
@image latex /user_guides/ocaf/images/ocaf_image005.png "A simple framework model"
@figure{/user_guides/ocaf/images/ocaf_image005.png, "A simple framework model"}
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.
@ -228,8 +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:
@image html ocaf_wp_image007.png "The coffee machine"
@image latex ocaf_wp_image007.png "The coffee machine"
@figure{ocaf_wp_image007.png, "The coffee machine"}
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
@ -241,8 +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.
@image html ocaf_wp_image005.png "The data structure of the coffee machine"
@image latex ocaf_wp_image005.png "The data structure of the coffee machine"
@figure{ocaf_wp_image005.png, "The data structure of the coffee machine"}
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.
@ -256,8 +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.
@image html /user_guides/ocaf/images/ocaf_image006.png
@image latex /user_guides/ocaf/images/ocaf_image006.png
@figure{/user_guides/ocaf/images/ocaf_image006.png}
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:
@ -271,8 +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.
@image html /user_guides/ocaf/images/ocaf_image007.png
@image latex /user_guides/ocaf/images/ocaf_image007.png
@figure{/user_guides/ocaf/images/ocaf_image007.png}
The previous figure shows the table-lamps document structure: each child of the root label contains a lamp shape attribute and refers to the sub-labels, which contain some design information about corresponding sub-units.
@ -523,8 +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).
@image html /user_guides/ocaf/images/ocaf_image010.png "Data tree for translation"
@image latex /user_guides/ocaf/images/ocaf_image010.png "Data tree for translation"
@figure{/user_guides/ocaf/images/ocaf_image010.png, "Data tree for translation"}
If the type of transformation is changed to rotation, the data tree looks like this:
* Type of transformation <i>(gp_Rotation)</i> as *TDataStd_Integer*;
@ -532,8 +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*.
@image html /user_guides/ocaf/images/ocaf_image011.png "Data tree for rotation"
@image latex /user_guides/ocaf/images/ocaf_image011.png "Data tree for rotation"
@figure{/user_guides/ocaf/images/ocaf_image011.png, "Data tree for rotation"}
The attribute *TDataStd_UAttribute* with the chosen unique GUID identifies the data type. The interface class initialized by the label of this attribute allows access to the data container (type of transformation and the data of transformation according to the type).
@ -548,8 +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] ).
@image html ocaf_wp_image006.png "The coffee machine compound document"
@image latex ocaf_wp_image006.png "The coffee machine compound document"
@figure{ocaf_wp_image006.png, "The coffee machine compound document"}
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
@ -794,8 +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.
@image html /user_guides/ocaf/images/ocaf_image012.png "External links between documents"
@image latex /user_guides/ocaf/images/ocaf_image012.png "External links between documents"
@figure{/user_guides/ocaf/images/ocaf_image012.png, "External links between documents"}
Note that documents can be copied with or without a possibility of updating an external link.
@ -845,8 +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.
@image html /user_guides/ocaf/images/ocaf_image013.png
@image latex /user_guides/ocaf/images/ocaf_image013.png
@figure{/user_guides/ocaf/images/ocaf_image013.png}
@subsection occt_ocaf_5_2 Shape attributes in data framework.
@ -859,8 +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.
@image html /user_guides/ocaf/images/ocaf_image014.png "Resulting box"
@image latex /user_guides/ocaf/images/ocaf_image014.png "Resulting box"
@figure{/user_guides/ocaf/images/ocaf_image014.png, "Resulting box"}
After the fuse operation a modified result is placed to a separate label as a named shape, which refers to the old shape (one of the boxes) and to the new shape resulting from the fuse operation, and has evolution MODIFY (see the following figure).
@ -868,8 +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.
@image html /user_guides/ocaf/images/ocaf_image015.png
@image latex /user_guides/ocaf/images/ocaf_image015.png
@figure{/user_guides/ocaf/images/ocaf_image015.png}
This is necessary and sufficient information for the functionality of the right naming mechanism: any sub-shape of the result can be identified unambiguously by name type and set of labels, which contain named shapes:
@ -1178,8 +1164,7 @@ It is possible to describe any model by means of standard OCAF attributes.
Certainly, other variants are also possible.
@image html ocaf_tree_wp_image003.png "Allocation of all data as one array of double values"
@image latex 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"}
The first approach to allocation of all data represented as one array of double values
saves initial memory and is easy to implement.
@ -1196,8 +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:
@image html ocaf_tree_wp_image004.png "Allocation of data of each measurement point as arrays of double values"
@image latex 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"}
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)
@ -1209,8 +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:
@image html ocaf_tree_wp_image005.png "Allocation of data into separate arrays of double values"
@image latex 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"}
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
@ -1227,8 +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):
@image html ocaf_tree_wp_image006.png "Allocation of data into newly created OCAF attribute"
@image latex 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"}
The second variant of using standard OCAF attributes still has drawbacks:
when data is edited, OCAF backs-up all values of the measurement point.
@ -1275,8 +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:
@image html /user_guides/ocaf/images/ocaf_image016.png
@image latex /user_guides/ocaf/images/ocaf_image016.png
@figure{/user_guides/ocaf/images/ocaf_image016.png}
As usual, the GUID of a driver and the GUID of a displayed attribute are the same.
@ -1301,8 +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.
@image html /user_guides/ocaf/images/ocaf_image008.png "Document structure"
@image latex /user_guides/ocaf/images/ocaf_image008.png "Document structure"
@figure{/user_guides/ocaf/images/ocaf_image008.png, "Document structure"}
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.
@ -1322,8 +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:
@image html /user_guides/ocaf/images/ocaf_image017.png
@image latex /user_guides/ocaf/images/ocaf_image017.png
@figure{/user_guides/ocaf/images/ocaf_image017.png}
The procedure of its creation is as follows:
* create a rectangular planar face *F* with height 100 and width 200;
@ -1349,8 +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:
@image html ocaf_functionmechanism_wp_image003.png "A nail"
@image latex ocaf_functionmechanism_wp_image003.png " A nail"
@figure{ocaf_functionmechanism_wp_image003.png, "A nail"}
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.
@ -1459,8 +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:
@image html ocaf_functionmechanism_wp_image005.png "A graph of dependencies between functions"
@image latex ocaf_functionmechanism_wp_image005.png "A graph of dependencies between functions"
@figure{ocaf_functionmechanism_wp_image005.png, "A graph of dependencies between functions"}
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.

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

@ -443,8 +443,7 @@ TopoDS_Wire newwire = sfw.Wire();
Let us correct the following wire:
@image html /user_guides/shape_healing/images/shape_healing_image013.png "Initial shape"
@image latex /user_guides/shape_healing/images/shape_healing_image013.png "Initial shape"
@figure{/user_guides/shape_healing/images/shape_healing_image013.png, "Initial shape"}
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;
@ -488,8 +487,7 @@ adjacent edges”<<endl;
As the result all failures have been fixed.
@image html /user_guides/shape_healing/images/shape_healing_image014.png "Resulting shape"
@image latex /user_guides/shape_healing/images/shape_healing_image014.png "Resulting shape"
@figure{/user_guides/shape_healing/images/shape_healing_image014.png, "Resulting shape"}
@subsubsection occt_shg_2_3_8 Repairing tool for edges
@ -502,8 +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.
@image html /user_guides/shape_healing/images/shape_healing_image011.png "Initial shape"
@image latex /user_guides/shape_healing/images/shape_healing_image011.png "Initial shape"
@figure{/user_guides/shape_healing/images/shape_healing_image011.png, "Initial shape"}
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.
@ -523,8 +520,7 @@ if (sae.CheckSameParameter (edge, maxdev)) {
}
~~~~~
@image html /user_guides/shape_healing/images/shape_healing_image012.png "Resulting shape"
@image latex /user_guides/shape_healing/images/shape_healing_image012.png "Resulting shape"
@figure{/user_guides/shape_healing/images/shape_healing_image012.png, "Resulting shape"}
As the result, the edge tolerance has been increased.
@ -1183,11 +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:
@image html /user_guides/shape_healing/images/shape_healing_image003.png "Source Face"
@image latex /user_guides/shape_healing/images/shape_healing_image003.png "Source Face"
@figure{/user_guides/shape_healing/images/shape_healing_image003.png, "Source Face"}
@image html /user_guides/shape_healing/images/shape_healing_image004.png "Resulting shape"
@image latex /user_guides/shape_healing/images/shape_healing_image004.png "Resulting shape"
@figure{/user_guides/shape_healing/images/shape_healing_image004.png, "Resulting shape"}
*ShapeUpgrade_ShapeDivideArea* is inherited from the base class *ShapeUpgrade_ShapeDivide* and should be used in the following way:
@ -1371,19 +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:
@image html /user_guides/shape_healing/images/shape_healing_image005.png "Source Face"
@image latex /user_guides/shape_healing/images/shape_healing_image005.png "Source Face"
@image html /user_guides/shape_healing/images/shape_healing_image006.png "Resulting shape"
@image latex /user_guides/shape_healing/images/shape_healing_image006.png "Resulting shape"
@figure{/user_guides/shape_healing/images/shape_healing_image005.png, "Source Face"}
@figure{/user_guides/shape_healing/images/shape_healing_image006.png, "Resulting shape"}
After the processing three internal wires with contour area less than the specified minimal area have been removed. One internal face has been removed. The outer wire of this face consists of the edges belonging to the removed internal wires and a seam edge.
Two other internal faces have not been removed because their outer wires consist not only of edges belonging to the removed wires.
@image html /user_guides/shape_healing/images/shape_healing_image007.png "Source Face"
@image latex /user_guides/shape_healing/images/shape_healing_image007.png "Source Face"
@figure{/user_guides/shape_healing/images/shape_healing_image007.png, "Source Face"}
@image html /user_guides/shape_healing/images/shape_healing_image008.png "Resulting shape"
@image latex /user_guides/shape_healing/images/shape_healing_image008.png "Resulting shape"
@figure{/user_guides/shape_healing/images/shape_healing_image008.png, "Resulting shape"}
After the processing six internal wires with contour area less than the specified minimal area have been removed. Six internal faces have been removed. These faces can be united into groups of faces. Each group of faces has an outer wire consisting only of edges belonging to the removed internal wires. Such groups of faces are also removed.

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

@ -735,8 +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
@image html /user_guides/step/images/step_image003.png "The structure of calls in reading STEP"
@image latex /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"}
@subsection occt_step_2_7 Example
~~~~~
@ -1074,8 +1073,7 @@ The following diagram illustrates the structure of calls in writing STEP.
The highlighted classes are intended to translate geometry.
@image html /user_guides/step/images/step_image004.png "The structure of calls in writing STEP"
@image latex /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"}
@subsection occt_step_3_7 Example

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

@ -48,8 +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.
@image html /user_guides/tobj/images/tobj_image003.png "TObj Data Model"
@image latex /user_guides/tobj/images/tobj_image003.png "TObj Data Model"
@figure{/user_guides/tobj/images/tobj_image003.png, "TObj Data Model"}
As the *TObj* Data Model is based on OCAF (Open CASCADE Application Framework) technology,
it stores its data in the underlying OCAF document. The OCAF document consists of a tree of
@ -62,8 +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:
@image html /user_guides/tobj/images/tobj_image004.png "TObj Data Model mapped on OCAF document"
@image latex /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"}
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
@ -430,8 +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.
@image html /user_guides/tobj/images/tobj_image005.png "TObj objects hierarchy"
@image latex /user_guides/tobj/images/tobj_image005.png "TObj objects hierarchy"
@figure{/user_guides/tobj/images/tobj_image005.png, "TObj objects hierarchy"}
@subsection occt_tobj_3_1 Separation of data and interface
@ -452,8 +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.
@image html /user_guides/tobj/images/tobj_image006.png "TObj object stored on OCAF label"
@image latex /user_guides/tobj/images/tobj_image006.png "TObj object stored on OCAF label"
@figure{/user_guides/tobj/images/tobj_image006.png, "TObj object stored on OCAF label"}
@subsection occt_tobj_3_2 Basic features
@ -643,8 +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.
@image html /user_guides/tobj/images/tobj_image007.png "Objects relationship"
@image latex /user_guides/tobj/images/tobj_image007.png "Objects relationship"
@figure{/user_guides/tobj/images/tobj_image007.png, "Objects relationship"}
@ -898,8 +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:
@image html /user_guides/tobj/images/tobj_image008.png "Hierarchy of iterators"
@image latex /user_guides/tobj/images/tobj_image008.png "Hierarchy of iterators"
@figure{/user_guides/tobj/images/tobj_image008.png, "Hierarchy of iterators"}
@section occt_tobj_5 Packaging

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

@ -28,8 +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.
@image html visualization_image003.png "Key concepts and packages in visualization"
@image latex visualization_image003.png "Key concepts and packages in visualization"
@figure{visualization_image003.png, "Key concepts and packages in visualization"}
To answer different needs of CASCADE users, this User's Guide offers the following three paths in reading it.
@ -99,8 +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.
@image html visualization_image004.svg "Processes involved in displaying a presentable shape"
@image latex visualization_image004.svg "Processes involved in displaying a presentable shape"
@figure{visualization_image004.svg, "Processes involved in displaying a presentable shape"}
@subsection occt_visu_2_2 Selection
@ -123,8 +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.
@image html visualization_image005.png "Example of a shape divided into sensitive entities"
@image latex visualization_image005.png "Example of a shape divided into sensitive entities"
@figure{visualization_image005.png, "Example of a shape divided into sensitive entities"}
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).
@ -155,11 +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.
@image html visualization_image006.png "Hierarchy of references from sensitive entity to selectable object"
@image latex 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"}
@image html visualization_image007.png "The principle of entities organization within the selectable object"
@image latex 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"}
<h4>Viewer selector</h4>
@ -171,8 +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.
@image html visualization_image008.png "The relations chain between viewer selector and selection manager"
@image latex 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"}
@subsubsection occt_visu_2_2_2 Algorithm
@ -186,11 +180,9 @@ 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.
@image html visualization_image009.png "Rectangular frustum: a) after mouse move or click, b) after applying the rectangular selection"
@image latex visualization_image009.png "Rectangular frustum: a) after mouse move or click, b) after applying the rectangular selection"
@figure{visualization_image009.png, "Rectangular frustum: a) after mouse move or click, b) after applying the rectangular selection"}
@image html 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"
@image latex 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"
@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"}
<h4>BVH trees</h4>
@ -202,8 +194,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.
@image html visualization_image022.png "Selection BVH tree hierarchy: from the biggest object-level (first) to the smallest complex entity level (third)"
@image latex 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)"}
<h4>Stages of the algorithm</h4>
@ -465,15 +456,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.
@image html visualization_image016.png
@image latex visualization_image016.png
@figure{visualization_image016.png}
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.
@image html visualization_image017.png
@image latex visualization_image017.png
@figure{visualization_image017.png}
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.
@ -491,8 +480,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.
@image html visualization_image018.png
@image latex visualization_image018.png
@figure{visualization_image018.png}
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.
@ -646,11 +634,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.
@image html visualization_image019.png "Figure 13. Redefinition of virtual functions for changes in AIS_Point"
@image latex visualization_image019.png "Figure 13. Redefinition of virtual functions for changes in AIS_Point"
@figure{visualization_image019.png, "Figure 13. Redefinition of virtual functions for changes in AIS_Point"}
@image html visualization_image020.png "Figure 14. Redefinition of virtual functions for changes in AIS_Shape."
@image latex visualization_image020.png "Figure 14. Redefinition of virtual functions for changes in AIS_Shape."
@figure{visualization_image020.png, "Figure 14. Redefinition of virtual functions for changes in AIS_Shape."}
The following virtual functions provide settings for color, width, material and transparency:
* *AIS_InteractiveObject::UnsetColor*
@ -1415,7 +1401,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.
@image html point_cloud.png "A random colored cloud of points"
@figure{point_cloud.png, "A random colored cloud of points"}
Example:
~~~~~
@ -2043,7 +2029,7 @@ aView->Camera()->Transform (aTrsf);
@subsubsection occt_visu_4_4_4 Orthographic Projection
@image html view_frustum.png "Perspective and orthographic projection"
@figure{view_frustum.png, "Perspective and orthographic projection"}
The following code configures the camera for orthographic rendering:
@ -2059,7 +2045,7 @@ aView->Update();
**Field of view (FOVy)** -- defines the field of camera view by y axis in degrees (45° is default).
@image html camera_perspective.png "Perspective frustum"
@figure{camera_perspective.png, "Perspective frustum"}
The following code configures the camera for perspective rendering:
@ -2083,7 +2069,7 @@ There are two types of IOD:
**ZFocus** -- defines the distance to the point of stereographic focus.
@image html stereo.png "Stereographic projection"
@figure{stereo.png, "Stereographic projection"}
To enable stereo projection, your workstation should meet the following requirements:

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

@ -39,12 +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:
@image html /user_guides/xde/images/xde_image003.png "Assembly Description"
@image latex /user_guides/xde/images/xde_image003.png "Assembly Description"
@figure{/user_guides/xde/images/xde_image003.png, "Assembly Description"}
@image html /user_guides/xde/images/xde_image004.png "Assembly View"
@image latex /user_guides/xde/images/xde_image004.png "Assembly View"
@figure{/user_guides/xde/images/xde_image004.png, "Assembly View"}
XDE defines the specific organization of the assembly content. Shapes are stored on sub-labels of label 0:1:1. There can be one or more roots (called free shapes) whether they are true trees or simple shapes. A shape can be considered to be an Assembly (such as AS1 under 0:1:1:1 in Figure1) if it is defined with Components (sub-shapes, located or not).
@ -56,8 +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.
@image html /user_guides/xde/images/xde_image005.png "Validation Property Descriptions"
@image latex /user_guides/xde/images/xde_image005.png "Validation Property Descriptions"
@figure{/user_guides/xde/images/xde_image005.png, "Validation Property Descriptions"}
Check logs contain deviations of computed values from the values stored in a STEP file. A typical example appears as follows: