Compare commits
364 Commits
Author | SHA1 | Date | |
---|---|---|---|
|
5c210a49dd | ||
|
ecd58be64a | ||
|
7cb899171d | ||
|
08f906ff37 | ||
|
38a0206f60 | ||
|
b85b0b0731 | ||
|
c87535af15 | ||
|
57c718c4b9 | ||
|
d721c8eb3d | ||
|
681cfe76b0 | ||
|
75d1222c2f | ||
|
032158d63d | ||
|
b0deeecfba | ||
|
35d1221827 | ||
|
f3981c67c3 | ||
|
8d64c0cc40 | ||
|
b3c433fea3 | ||
|
2afd4e9888 | ||
|
c3715b7477 | ||
|
74f91efccd | ||
|
58978f9bef | ||
|
699239e457 | ||
|
3eac3f55a5 | ||
|
cc2b0ec0e3 | ||
|
687574c09d | ||
|
867acdec68 | ||
|
5682a02934 | ||
|
5ae01c8551 | ||
|
67680042bc | ||
|
0c015ee26c | ||
|
9dfbbfe673 | ||
|
c40b7d580e | ||
|
d2d0f00268 | ||
|
f25b82d624 | ||
|
8ba678133b | ||
|
af65fb1941 | ||
|
ce77f9998a | ||
|
494782f666 | ||
|
7bb2b8293a | ||
|
a21ab2c1a1 | ||
|
4057f898f7 | ||
|
85a975f112 | ||
|
cf537aacf7 | ||
|
1d19db8dad | ||
|
346cf025a5 | ||
|
124ee9c962 | ||
|
42f8ba5632 | ||
|
3186aee9b6 | ||
|
43ebf89c22 | ||
|
f483f2ed11 | ||
|
91c60b5790 | ||
|
5b055f07b3 | ||
|
306f5893ea | ||
|
d585e74e51 | ||
|
138ac5300a | ||
|
6f7c5420f8 | ||
|
b5ef9d9151 | ||
|
536d98e224 | ||
|
24e40cc2dc | ||
|
e9e33e9167 | ||
|
cbca8a98e6 | ||
|
447c411576 | ||
|
d1db9125d0 | ||
|
aa9d6bec4e | ||
|
41ed1ed236 | ||
|
f751596e46 | ||
|
7a91ad6e81 | ||
|
7e859dff1b | ||
|
e135a1559a | ||
|
a2e4f780c2 | ||
|
44ef962bdd | ||
|
d4271fe56f | ||
|
269e9c3640 | ||
|
e1c659da58 | ||
|
dc5bfeae8b | ||
|
53a701974a | ||
|
65360da3db | ||
|
fd372378a1 | ||
|
1804bb99a6 | ||
|
ef0bfc15cc | ||
|
a3ee6e9f77 | ||
|
c1e0171c58 | ||
|
2905ff1727 | ||
|
b34efb623c | ||
|
39d24c098c | ||
|
3516cdec44 | ||
|
aa5f963b81 | ||
|
9aa684edf4 | ||
|
7331b4eec9 | ||
|
0a512187fd | ||
|
d4b867e617 | ||
|
2a8523acca | ||
|
d44e14e3f6 | ||
|
a3ac9c24ce | ||
|
07039714ab | ||
|
1dee069608 | ||
|
1cdee2a613 | ||
|
4e2914a6a0 | ||
|
936f43da8a | ||
|
08e464755d | ||
|
457b01e271 | ||
|
0a243bb4c4 | ||
|
e4ffdb1e40 | ||
|
36132a2ec8 | ||
|
a79f67f8d8 | ||
|
41e259eb8b | ||
|
9bd59d1c5b | ||
|
dfa0d64a91 | ||
|
1a6751b196 | ||
|
c4af16fbf3 | ||
|
7f0b39bec9 | ||
|
4dcc5ecb4f | ||
|
b12a3e54fc | ||
|
18ee2939c3 | ||
|
0f9f1f4ea0 | ||
|
095999010f | ||
|
3062fdf993 | ||
|
b11a99d9c1 | ||
|
ee51a9fe3a | ||
|
77e39787b4 | ||
|
3629864d0b | ||
|
8d44b0a05f | ||
|
458c2c5828 | ||
|
4e1523ef0b | ||
|
7f91733552 | ||
|
076b125a90 | ||
|
9a5a19e98f | ||
|
ef237d732d | ||
|
9bf3177ff6 | ||
|
3163e9fdeb | ||
|
4c5133866b | ||
|
5149c3f34b | ||
|
1a75746e71 | ||
|
50f32555af | ||
|
e94f2bfb11 | ||
|
a272ed9466 | ||
|
8621cdc2b7 | ||
|
6262338c4b | ||
|
44b47a9a7e | ||
|
d2094e110f | ||
|
f1b0b4f9c6 | ||
|
a3476a9fe2 | ||
|
9a6ea9c479 | ||
|
43e9197e9a | ||
|
760c21c2c4 | ||
|
c8187bb218 | ||
|
5bffb88282 | ||
|
a1096551c9 | ||
|
31b1749c42 | ||
|
69f86542ba | ||
|
50b994e73f | ||
|
6ddebb77cb | ||
|
b86bb3df20 | ||
|
af99433e4e | ||
|
bd28b2afac | ||
|
7ad63454a5 | ||
|
172f635278 | ||
|
7121535194 | ||
|
696d81d000 | ||
|
0a9b38ef44 | ||
|
40738f9ad7 | ||
|
59f520585b | ||
|
e002f1ce5b | ||
|
7a7e8cf174 | ||
|
19589673b3 | ||
|
859a47c3d1 | ||
|
8d9052db19 | ||
|
8750c36a35 | ||
|
d088c9c2a1 | ||
|
2c7b466ce6 | ||
|
95b2678c73 | ||
|
42b96b07b5 | ||
|
873c119ff1 | ||
|
48e653b689 | ||
|
b0091bc929 | ||
|
2c12770c38 | ||
|
20f319cdb8 | ||
|
2bfe59b69c | ||
|
fc0180e5f3 | ||
|
e32045fd71 | ||
|
4af098bab9 | ||
|
0090ae85ab | ||
|
b70d2b0999 | ||
|
b8f2022f8c | ||
|
eea55df528 | ||
|
d584648954 | ||
|
5bd9ed9369 | ||
|
348ff75335 | ||
|
2fe4f8f37b | ||
|
a41fbc10b9 | ||
|
7a5f12021e | ||
|
8d3aa19e69 | ||
|
15b54261a3 | ||
|
9ccea0c628 | ||
|
0769561063 | ||
|
a4d5c9abcc | ||
|
e8746a262f | ||
|
3f733bb126 | ||
|
14a35e5d91 | ||
|
c7b59798ca | ||
|
a61133c8c7 | ||
|
298fdbfb18 | ||
|
0bb1f1133c | ||
|
f5fa6b335c | ||
|
31e0b8e84c | ||
|
0b0320e76e | ||
|
843e15cd32 | ||
|
b9c1e44004 | ||
|
402bfe81c0 | ||
|
b990e5579a | ||
|
bcf50875e3 | ||
|
5fd3308acd | ||
|
433673e0dd | ||
|
e3414ada99 | ||
|
1e99558fbd | ||
|
34a0b4463a | ||
|
4e0311752a | ||
|
9bf0740bed | ||
|
4366363b04 | ||
|
2157cfd0ef | ||
|
fd3ba7a1d9 | ||
|
0bb09048e2 | ||
|
df515f16ce | ||
|
b2af2f567d | ||
|
a70f58235a | ||
|
c7806cb6e6 | ||
|
6da30ff153 | ||
|
e2b55410ff | ||
|
07f1a2e68c | ||
|
618617fe06 | ||
|
76eeac70cf | ||
|
52ba6031e8 | ||
|
0fe1715f01 | ||
|
79186c39b3 | ||
|
89bc1237a4 | ||
|
bdde45c38c | ||
|
dba608bb39 | ||
|
27a6612865 | ||
|
da72a17c80 | ||
|
a195430212 | ||
|
92e24f9d36 | ||
|
19dcfc1bdb | ||
|
8f7e78f4de | ||
|
99c5f9f045 | ||
|
1b7ae95146 | ||
|
e2da917a1c | ||
|
71595c2970 | ||
|
55b05039a4 | ||
|
6b0e8bd1a9 | ||
|
89cc29b0b5 | ||
|
cbff1e5531 | ||
|
460f4f693a | ||
|
edbf88ba99 | ||
|
4f0d73a918 | ||
|
fa89e0828b | ||
|
cd0a63dd7b | ||
|
63d907e787 | ||
|
43cb001124 | ||
|
49297cb6bd | ||
|
c857a60abe | ||
|
6504f8cd28 | ||
|
97c44f4156 | ||
|
bcf045cfdc | ||
|
c31e0defd7 | ||
|
6a38ff486c | ||
|
c8be748cd4 | ||
|
df932fdfb2 | ||
|
2195ab9699 | ||
|
270675f51e | ||
|
bc88a67737 | ||
|
4cf9a9f0ea | ||
|
92ac0eb708 | ||
|
ee6bb37b7f | ||
|
312a4043c2 | ||
|
51023771f9 | ||
|
bbe97eddea | ||
|
f43eff9ffe | ||
|
fe79003598 | ||
|
b9f6147d75 | ||
|
7c32c7c41f | ||
|
ee5ee7db3b | ||
|
8ac0cf5265 | ||
|
49b0c452e2 | ||
|
6219c44ce7 | ||
|
73d0a668b3 | ||
|
b7d2387022 | ||
|
656ec77a10 | ||
|
2283570591 | ||
|
032c140ff1 | ||
|
7c8996f49f | ||
|
d5a9d0da1c | ||
|
edf3cf25a2 | ||
|
da2db6a705 | ||
|
e275de58af | ||
|
8422b578d7 | ||
|
f05f2e3430 | ||
|
74da0216d7 | ||
|
949df2b64b | ||
|
ccadc126ba | ||
|
a4bb1420ca | ||
|
70d08ce5b2 | ||
|
3d58dc498b | ||
|
68cdb44b0a | ||
|
fa0f5a5558 | ||
|
f4fa7f0c16 | ||
|
db005e48df | ||
|
d0607a766f | ||
|
13cd069dbc | ||
|
b49eaa701f | ||
|
d315303da2 | ||
|
3922a2ec0f | ||
|
be09e9bf18 | ||
|
8a864791fe | ||
|
e11c1bc433 | ||
|
21b7d8be4c | ||
|
076ca35c3f | ||
|
a319f03ff9 | ||
|
c0bd0de183 | ||
|
558e68ea11 | ||
|
06696fd835 | ||
|
0b309a75c4 | ||
|
368cdde60e | ||
|
e8feb725a4 | ||
|
a6964ce627 | ||
|
21087d914b | ||
|
7fd6425dc4 | ||
|
3ea0a91b70 | ||
|
e159a66863 | ||
|
d2d9e8dc0e | ||
|
7e7bbb3a9e | ||
|
150e93a7f2 | ||
|
4a913f2102 | ||
|
6c6aadb1ff | ||
|
abdf0b107e | ||
|
b1d15f53b3 | ||
|
49e1a5c7e9 | ||
|
aa627f0805 | ||
|
8bcdd6976a | ||
|
ee0a5d2528 | ||
|
0059facbbf | ||
|
90a9485514 | ||
|
f70d6437bd | ||
|
9bb81d6ce8 | ||
|
e0608a8d27 | ||
|
e83c01bfc0 | ||
|
c84d6e55ea | ||
|
a86ce5a64a | ||
|
a791eb69f4 | ||
|
34e923b5c2 | ||
|
baf72cd2e7 | ||
|
80d659a5a6 | ||
|
d0a994c7f1 | ||
|
32a15d12db | ||
|
4ca4bbe8bd | ||
|
8cf06aa236 | ||
|
0da4579283 | ||
|
4590b5516c | ||
|
cf2439de58 | ||
|
ceb31c6156 | ||
|
93442c6f24 | ||
|
393598ebd6 | ||
|
7da00517d4 | ||
|
eb7404bf16 | ||
|
7a733b194b |
@@ -86,8 +86,8 @@ if ("${3RDPARTY_DIR}" STREQUAL "")
|
||||
set (3RDPARTY_DIR "$ENV{3RDPARTY_DIR}" CACHE PATH ${3RDPARTY_DIR_LABEL} FORCE)
|
||||
elseif (EXISTS "${CMAKE_SOURCE_DIR}/../")
|
||||
# in version 6.7.0 and above, occt parent directory contains 3rdparties
|
||||
GET_FILENAME_COMPONENT(3RDPARTY_DIR "${CMAKE_SOURCE_DIR}/../" ABSOLUTE)
|
||||
SET(3RDPARTY_DIR "${3RDPARTY_DIR}" CACHE PATH ${3RDPARTY_DIR_LABEL} FORCE)
|
||||
get_filename_component (3RDPARTY_DIR "${CMAKE_SOURCE_DIR}/../" ABSOLUTE)
|
||||
set (3RDPARTY_DIR "${3RDPARTY_DIR}" CACHE PATH ${3RDPARTY_DIR_LABEL} FORCE)
|
||||
endif()
|
||||
endif()
|
||||
|
||||
@@ -98,13 +98,8 @@ if ("${USE_TCL}" STREQUAL ON)
|
||||
message (STATUS "Info: tcl is used by OCCT")
|
||||
OCCT_INCLUDE_CMAKE_FILE ("adm/templates/tcl")
|
||||
else()
|
||||
OCCT_CHECK_AND_UNSET ("3RDPARTY_TCL_DIR")
|
||||
OCCT_CHECK_AND_UNSET ("3RDPARTY_TCL_INCLUDE_DIR")
|
||||
OCCT_CHECK_AND_UNSET ("3RDPARTY_TCL_LIBRARY")
|
||||
OCCT_CHECK_AND_UNSET ("3RDPARTY_TCL_LIBRARY_DIR")
|
||||
OCCT_CHECK_AND_UNSET ("3RDPARTY_TK_INCLUDE_DIR")
|
||||
OCCT_CHECK_AND_UNSET ("3RDPARTY_TK_LIBRARY")
|
||||
OCCT_CHECK_AND_UNSET ("3RDPARTY_TK_LIBRARY_DIR")
|
||||
OCCT_CHECK_AND_UNSET_GROUP ("3RDPARTY_TCL")
|
||||
OCCT_CHECK_AND_UNSET_GROUP ("3RDPARTY_TK")
|
||||
endif()
|
||||
|
||||
# search for CSF_FREETYPE variable in EXTERNLIB of each being used toolkit
|
||||
@@ -114,11 +109,9 @@ if ("${USE_FREETYPE}" STREQUAL ON)
|
||||
message (STATUS "Info: freetype is used by OCCT")
|
||||
OCCT_INCLUDE_CMAKE_FILE ("adm/templates/freetype")
|
||||
else()
|
||||
OCCT_CHECK_AND_UNSET ("3RDPARTY_FREETYPE_DIR")
|
||||
OCCT_CHECK_AND_UNSET_GROUP ("3RDPARTY_FREETYPE")
|
||||
OCCT_CHECK_AND_UNSET ("3RDPARTY_FREETYPE_INCLUDE_DIR_freetype2")
|
||||
OCCT_CHECK_AND_UNSET ("3RDPARTY_FREETYPE_INCLUDE_DIR_ft2build")
|
||||
OCCT_CHECK_AND_UNSET ("3RDPARTY_FREETYPE_LIBRARY")
|
||||
OCCT_CHECK_AND_UNSET ("3RDPARTY_FREETYPE_LIBRARY_DIR")
|
||||
endif()
|
||||
|
||||
# VTK
|
||||
@@ -167,7 +160,7 @@ endif()
|
||||
|
||||
# TBB
|
||||
if (USE_TBB)
|
||||
ADD_DEFINITIONS(-DHAVE_TBB)
|
||||
add_definitions (-DHAVE_TBB)
|
||||
OCCT_INCLUDE_CMAKE_FILE ("adm/templates/tbb")
|
||||
else()
|
||||
OCCT_CHECK_AND_UNSET_GROUP ("3RDPARTY_TBB")
|
||||
@@ -182,15 +175,19 @@ if (3RDPARTY_NOT_INCLUDED)
|
||||
message (FATAL_ERROR "NOT FOUND: ${3RDPARTY_NOT_INCLUDED}" )
|
||||
endif()
|
||||
|
||||
list (REMOVE_DUPLICATES 3RDPARTY_INCLUDE_DIRS)
|
||||
string (REGEX REPLACE ";" "\n\t" 3RDPARTY_INCLUDE_DIRS_WITH_ENDS "${3RDPARTY_INCLUDE_DIRS}")
|
||||
message (STATUS "The directories containing 3rdparty headers: ${3RDPARTY_INCLUDE_DIRS_WITH_ENDS}")
|
||||
include_directories (${3RDPARTY_INCLUDE_DIRS})
|
||||
if (3RDPARTY_INCLUDE_DIRS)
|
||||
list (REMOVE_DUPLICATES 3RDPARTY_INCLUDE_DIRS)
|
||||
string (REGEX REPLACE ";" "\n\t" 3RDPARTY_INCLUDE_DIRS_WITH_ENDS "${3RDPARTY_INCLUDE_DIRS}")
|
||||
message (STATUS "The directories containing 3rdparty headers: ${3RDPARTY_INCLUDE_DIRS_WITH_ENDS}")
|
||||
include_directories (${3RDPARTY_INCLUDE_DIRS})
|
||||
endif()
|
||||
|
||||
list (REMOVE_DUPLICATES 3RDPARTY_LIBRARY_DIRS)
|
||||
string (REGEX REPLACE ";" "\n\t" 3RDPARTY_LIBRARY_DIRS_WITH_ENDS "${3RDPARTY_LIBRARY_DIRS}")
|
||||
message (STATUS "The directories containing 3rdparty libraries: ${3RDPARTY_LIBRARY_DIRS_WITH_ENDS}")
|
||||
link_directories (${3RDPARTY_LIBRARY_DIRS})
|
||||
if (3RDPARTY_LIBRARY_DIRS)
|
||||
list (REMOVE_DUPLICATES 3RDPARTY_LIBRARY_DIRS)
|
||||
string (REGEX REPLACE ";" "\n\t" 3RDPARTY_LIBRARY_DIRS_WITH_ENDS "${3RDPARTY_LIBRARY_DIRS}")
|
||||
message (STATUS "The directories containing 3rdparty libraries: ${3RDPARTY_LIBRARY_DIRS_WITH_ENDS}")
|
||||
link_directories (${3RDPARTY_LIBRARY_DIRS})
|
||||
endif()
|
||||
|
||||
OCCT_MAKE_BUILD_POSTFIX()
|
||||
|
||||
|
@@ -63,11 +63,21 @@ Download the necessary archive from http://www.tcl.tk/software/tcltk/download.ht
|
||||
|
||||
This is to avoid extra prefix 't' in the library name, which is not recognized by default by OCCT build tools.
|
||||
|
||||
3. In the command prompt, run *buildall.vc.bat*
|
||||
|
||||
3. By default, Tcl uses dynamic version of run-time library (MSVCRT), which must be installed on the system where Tcl will be used.
|
||||
You may wish to link Tcl library with static version of run-time to avoid this dependency.
|
||||
For that:
|
||||
|
||||
* Edit file *makefile.vc* replacing strings "crt = -MD" by "crt = -MT"
|
||||
|
||||
* Edit source file *tclMain.c* (located in folder *generic*) commenting out forward declaration of function *isatty()*.
|
||||
|
||||
|
||||
4. In the command prompt, run *buildall.vc.bat*
|
||||
|
||||
You might need to run this script twice to have *tclsh* executable installed; check subfolder *bin* of specified installation path to verify this.
|
||||
|
||||
4. For convenience of use, we recommend making a copy of *tclsh* executable created in subfolder *bin* of *INSTALLDIR* and named with Tcl version number suffix, as *tclsh.exe* (with no suffix)
|
||||
5. For convenience of use, we recommend making a copy of *tclsh* executable created in subfolder *bin* of *INSTALLDIR* and named with Tcl version number suffix, as *tclsh.exe* (with no suffix)
|
||||
|
||||
> cd D:\OCCT\3rdparty\tcltk-86-32\bin
|
||||
> cp tclsh86.exe tclsh.exe
|
||||
|
@@ -204,7 +204,7 @@ The definition of the following attributes is obligatory:
|
||||
| Open | The issue is being processed. |
|
||||
| Fixed | The issue has been successfully fixed. |
|
||||
| Reopened | The bug has been reopened because of insufficient fix or regression. |
|
||||
| | Unable to reproduceThe bug is not reproduced. |
|
||||
| Unable to reproduce | The bug is not reproduced. |
|
||||
| Not fixable | The bug cannot be fixed because it is a bug of third party software, or because it requires more workload than it can be allowed. |
|
||||
| Duplicate | The bug for the same issue already exists in the tracker. |
|
||||
| Not a bug | It is a normal behavior in accordance with the specification of the product |
|
||||
|
@@ -3,6 +3,10 @@ Debugging tools and hints {#occt_dev_guides__debug}
|
||||
|
||||
@tableofcontents
|
||||
|
||||
@section occt_debug_intro Introduction
|
||||
|
||||
This manual describes facilities included in OCCT to support debugging, and provides some hints for more efficient debug.
|
||||
|
||||
@section occt_debug_macro Compiler macro to enable extended debug messages
|
||||
|
||||
Many OCCT algorithms can produce extended debug messages, usually printed to cout.
|
||||
@@ -23,10 +27,6 @@ Note that some header files are modified when *OCCT_DEBUG* is enabled, hence bin
|
||||
|
||||
On Windows platform when using Visual Studio compiler there is a possibility to start the debugger automatically if an exception is caught in a program running OCCT. For this, set environment variable *CSF_DEBUG* to any value. Note that this feature works only if you enable OCCT exception handler in your application by calling *OSD::SetSignal()*.
|
||||
|
||||
@section occt_debug_intro Introduction
|
||||
|
||||
This manual describes facilities included in OCCT to support debugging, and provides some hints for more efficient debug.
|
||||
|
||||
@section occt_debug_bop Self-diagnostics in Boolean operations algorithm
|
||||
|
||||
In real-world applications modeling operations are often performed in a long sequence, while the user sees only the final result of the whole sequence. If the final result is wrong, the first debug step is to identify the offending operation to be debugged further. Boolean operation algorithm in OCCT provides a self-diagnostic feature which can help to do that step.
|
||||
@@ -35,6 +35,41 @@ This feature can be activated by defining environment variable *CSF_DEBUG_BOP*,
|
||||
|
||||
The diagnostic code checks validity of the input arguments and the result of each Boolean operation. When an invalid situation is detected, the report consisting of argument shapes and a DRAW script to reproduce the problematic operation is saved to the directory pointed by *CSF_DEBUG_BOP*.
|
||||
|
||||
@section occt_debug_commands DRAW debugging commands
|
||||
|
||||
In this section description and usage of several debug commands represented.
|
||||
|
||||
@subsection occt_debug_commands_xdist "xdist" commands family
|
||||
|
||||
Commands with prefix "xdist" provides functionality to check distance between two objects on even grid:
|
||||
|
||||
* xdistef - distance between edge and face.
|
||||
* xdistcs - distance between curve and surface. This means that projection to surface of each sample point computed.
|
||||
* xdistcc - distance between two 3d curves.
|
||||
* xdistcc2ds - distance between 3d curve and 2d curve on surface.
|
||||
* xdistc2dc2dss - distance between two 2d curves on surface.
|
||||
|
||||
**Usage:**
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
xdistef edge face
|
||||
xdistcs curve surface firstParam lastParam [NumberOfSamplePoints]
|
||||
xdistcc curve1 curve2 startParam finishParam [NumberOfSamplePoints]
|
||||
xdistcc2ds c curve2d surf startParam finishParam [NumberOfSamplePoints]
|
||||
xdistc2dc2dss curve2d_1 curve2d_2 surface_1 surface_2 startParam finishParam [NumberOfSamplePoints]
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It is assumed that curves have same parametrization range and startParam < finishParam.
|
||||
|
||||
**Examples:**
|
||||
~~~~~
|
||||
bopcurves b1 b2 -2d
|
||||
mksurf s1 b1
|
||||
mksurf s2 b2
|
||||
xdistcs c_1 s1 0 1 100
|
||||
xdistcc2ds c_1 c2d2_1 s2 0 1
|
||||
xdistc2dc2dss c2d1_1 c2d2_1 s1 s2 0 1 1000
|
||||
~~~~~
|
||||
|
||||
@section occt_debug_call Functions for calling from debugger
|
||||
|
||||
Modern interactive debuggers provide the possibility to execute application code at a program break point. This feature can be used to analyse the temporary objects available only in the context of the debugged code. OCCT provides several global functions that can be used in this way.
|
||||
@@ -85,7 +120,7 @@ const char* BRepTools_Write (const char* theFileNameStr, void* theShapePtr)
|
||||
~~~~~
|
||||
|
||||
Saves the specified shape to a file with the given name.
|
||||
- *theFileNameStr* - the DRAW interpreter variable name to set.
|
||||
- *theFileNameStr* - the name of the file where the shape is saved.
|
||||
- *theShapePtr* - a pointer to *TopoDS_Shape* variable.
|
||||
|
||||
~~~~~
|
||||
@@ -104,7 +139,7 @@ const char* BRepMesh_Dump (void* theMeshHandlePtr, const char* theFileNameStr)
|
||||
|
||||
Stores mesh produced in parametric space to BREP file.
|
||||
- *theMeshHandlePtr* - a pointer to *Handle(BRepMesh_DataStructureOfDelaun)* variable.
|
||||
- *theFileNameStr* - name of file the mesh sould be stored to.
|
||||
- *theFileNameStr* - the name of the file where the mesh is stored.
|
||||
|
||||
The following additional function is provided by *TKGeomBase* toolkit:
|
||||
|
||||
@@ -269,4 +304,22 @@ Handle_TCollection_HAsciiString {
|
||||
}
|
||||
~~~~~
|
||||
|
||||
In Visual Studio 2012 and later, visualizers can be put in a separate file in subdirectory *Visualizers*. See file *occt.natvis* for example.
|
||||
In Visual Studio 2012 and later, visualizers can be put in a separate file in subdirectory *Visualizers*. See file *occt.natvis* for example.
|
||||
|
||||
@section occt_debug_perf Performance measurement tools
|
||||
|
||||
It is recommended to use specialized performance analysis tools to profile OCCT and application code.
|
||||
However, when such tools are not available or cannot be used for some reason, tools provided by OSD package can be used: low-level C functions and macros defined in *OSD_PerfMeter.h* and *OSD_PerfMeter* class.
|
||||
|
||||
This tool maintains an array of 100 global performance counters that can be started and stopped independently. Adding a performance counter to a function of interest allows to get statistics on the number of calls and the total execution time of the function.
|
||||
* In C++ code, this can be achieved by creating local variable *OSD_PerfMeter* in each block of code to be measured.
|
||||
* In C or Fortran code, use functions *perf_start_meter* and *perf_stop_meter* to start and stop the counter.
|
||||
|
||||
Note that this instrumentation is intended to be removed when the profiling is completed.
|
||||
|
||||
Macros provided in *OSD_PerfMeter.h* can be used to keep instrumentation code permanently but enable it only when macro *PERF_ENABLE_METERS* is defined.
|
||||
Each counter has its name shown when the collected statistics are printed.
|
||||
|
||||
In DRAW, use command *dperf* to print all performance statistics.
|
||||
|
||||
Note that performance counters are not thread-safe.
|
||||
|
@@ -23,7 +23,7 @@ The tests are organized in three levels:
|
||||
|
||||
See <a href="#testmanual_5_1">Test Groups</a> for the current list of available test groups and grids.
|
||||
|
||||
Some tests involve data files (typically CAD models) which are located separately and are not included with OCCT code. The archive with publicly available test data files should be downloaded and installed independently on OCCT sources (from http://dev.opencascade.org).
|
||||
Some tests involve data files (typically CAD models) which are located separately and are not included with OCCT code. The archive with publicly available test data files should be downloaded and installed independently on OCCT sources (see http://dev.opencascade.org).
|
||||
|
||||
@subsection testmanual_1_2 Intended Use of Automatic Tests
|
||||
|
||||
@@ -44,7 +44,6 @@ The modifications made in the OCCT code and related test scripts should be inclu
|
||||
@subsubsection testmanual_1_3_1 Setup
|
||||
|
||||
Before running tests, make sure to define environment variable *CSF_TestDataPath* pointing to the directory containing test data files.
|
||||
(Publicly available data files can be downloaded from http://dev.opencascade.org separately from OCCT code.)
|
||||
|
||||
For this it is recommended to add a file *DrawAppliInit* in the directory which is current at the moment of starting DRAWEXE (normally it is OCCT root directory, <i>$CASROOT </i>). This file is evaluated automatically at the DRAW start.
|
||||
|
||||
@@ -58,7 +57,7 @@ return ;# this is to avoid an echo of the last command above in cout
|
||||
Note that variable *CSF_TestDataPath* is set to default value at DRAW start, pointing at the folder <i>$CASROOT/data</i>.
|
||||
In this example, subdirectory <i>d:/occt/test-data</i> is added to this path. Similar code could be used on Linux and Mac OS X except that on non-Windows platforms colon ":" should be used as path separator instead of semicolon ";".
|
||||
|
||||
All tests are run from DRAW command prompt (run *draw.tcl* or *draw.sh* to start it).
|
||||
All tests are run from DRAW command prompt (run *draw.bat* or *draw.sh* to start it).
|
||||
|
||||
@subsubsection testmanual_1_3_2 Running Tests
|
||||
|
||||
@@ -102,7 +101,7 @@ Example:
|
||||
|
||||
The tests are considered as non-regressive if only OK, BAD (i.e. known problem), and SKIPPED (i.e. not executed, typically because of lack of a data file) statuses are reported. See <a href="#testmanual_3_5">Interpretation of test results</a> for details.
|
||||
|
||||
The results and detailed logs of the tests are saved by default to a subdirectory of the current folder, whose name is generated automatically using the current date and time, prefixed by word <i>"results_"</i> and Git branch name (if Git is available and current sources are managed by Git).
|
||||
The results and detailed logs of the tests are saved by default to a new subdirectory of the subdirectory *results* in the current folder, whose name is generated automatically using the current date and time, prefixed by Git branch name (if Git is available and current sources are managed by Git).
|
||||
If necessary, a non-default output directory can be specified using option <i> –outdir</i> followed by a path to the directory. This directory should be new or empty; use option –overwrite to allow writing results in existing non-empty directory.
|
||||
|
||||
Example:
|
||||
@@ -111,9 +110,7 @@ Draw[]> testgrid -outdir d:/occt/last_results -overwrite
|
||||
~~~~~
|
||||
In the output directory, a cumulative HTML report summary.html provides links to reports on each test case. An additional report in JUnit-style XML format can be output for use in Jenkins or other continuous integration system.
|
||||
|
||||
Type <i>help testgrid</i> in DRAW prompt to get help on options supported by *testgrid* command.
|
||||
|
||||
For example:
|
||||
Type <i>help testgrid</i> in DRAW prompt to get help on options supported by *testgrid* command:
|
||||
|
||||
~~~~~
|
||||
Draw[3]> help testgrid
|
||||
@@ -125,6 +122,7 @@ testgrid: Run all tests, or specified group, or one grid
|
||||
-outdir dirname: set log directory (should be empty or non-existing)
|
||||
-overwrite: force writing logs in existing non-empty directory
|
||||
-xml filename: write XML report for Jenkins (in JUnit-like format)
|
||||
-beep: play sound signal at the end of the tests
|
||||
Groups, grids, and test cases to be executed can be specified by list of file
|
||||
masks, separated by spaces or comma; default is all (*).
|
||||
~~~~~
|
||||
@@ -146,6 +144,28 @@ Note that normally an intermediate output of the script is not shown. The detail
|
||||
To see intermediate commands and their output during the test execution, add one more argument
|
||||
<i>"echo"</i> at the end of the command line. Note that with this option the log is not collected and summary is not produced.
|
||||
|
||||
Type <i>help testgrid</i> in DRAW prompt to get help on options supported by *testgrid* command:
|
||||
|
||||
~~~~~
|
||||
Draw[3]> help test
|
||||
test: Run specified test case
|
||||
Use: test group grid casename [options...]
|
||||
Allowed options are:
|
||||
-echo: all commands and results are echoed immediately,
|
||||
but log is not saved and summary is not produced
|
||||
It is also possible to use "1" instead of "-echo"
|
||||
If echo is OFF, log is stored in memory and only summary
|
||||
is output (the log can be obtained with command "dlog get")
|
||||
-outfile filename: set log file (should be non-existing),
|
||||
it is possible to save log file in text file or
|
||||
in html file(with snapshot), for that "filename"
|
||||
should have ".html" extension
|
||||
-overwrite: force writing log in existing file
|
||||
-beep: play sound signal at the end of the test
|
||||
-errors: show all lines from the log report that are recognized as errors
|
||||
This key will be ignored if the "-echo" key is already set.
|
||||
~~~~~
|
||||
|
||||
@subsubsection testmanual_1_3_4 Creating a New Test
|
||||
|
||||
The detailed rules of creation of new tests are given in <a href="#testmanual_3">section 3</a>. The following short description covers the most typical situations:
|
||||
@@ -166,6 +186,7 @@ Use prefix "bug" followed by Mantis issue ID and, if necessary, additional suffi
|
||||
Example:
|
||||
|
||||
* Added files:
|
||||
|
||||
~~~~~
|
||||
git status –short
|
||||
A tests/bugs/heal/data/OCC210a.brep
|
||||
@@ -284,7 +305,7 @@ The test group may contain *parse.rules* file. This file defines patterns used f
|
||||
|
||||
Each line in the file should specify a status (single word), followed by a regular expression delimited by slashes (*/*) that will be matched against lines in the test output log to check if it corresponds to this status.
|
||||
|
||||
The regular expressions support a subset of the Perl *re* syntax. See also <a href=http://perldoc.perl.org/perlre.html>Perl regular expressions</a>.
|
||||
The regular expressions support a subset of the Perl *re* syntax. See also <a href="http://perldoc.perl.org/perlre.html">Perl regular expressions</a>.
|
||||
|
||||
The rest of the line can contain a comment message, which will be added to the test report when this status is detected.
|
||||
|
||||
@@ -353,7 +374,7 @@ Usually it executes a specific sequence of commands common for all tests in the
|
||||
Example:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.tcl}
|
||||
vdump $logdir/${casename}.gif ;# makes a snap-shot of AIS viewer
|
||||
vdump $imagedir/${casename}.png ;# makes a snap-shot of AIS viewer
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@subsubsection testmanual_2_3_4 File "cases.list"
|
||||
@@ -437,7 +458,9 @@ If the new test corresponds to a functionality already covered by the existing s
|
||||
|
||||
It is advisable to make self-contained test scripts whenever possible, so as they could be used in environments where data files are not available. For that simple geometric objects and shapes can be created using DRAW commands in the test script itself.
|
||||
|
||||
If the test requires a data file, it should be put to subdirectory *data* of the test grid. It is recommended to prefix the data file with the corresponding issue id prefixed by *bug*, e.g. *bug12345_face1.brep*, to avoid possible conflicts with names of existing data files.
|
||||
If the test requires a data file, it should be put to directory listed in environment variable *CSF_TestDataPath*.
|
||||
Alternatively, it can be put to subdirectory *data* of the test grid.
|
||||
It is recommended to prefix the data file with the corresponding issue id prefixed by *bug*, e.g. *bug12345_face1.brep*, to avoid possible conflicts with names of existing data files.
|
||||
|
||||
Note that when the test is integrated to the master branch, OCC team will move the data file to data files repository, so as to keep OCCT sources repository clean from data files.
|
||||
|
||||
@@ -452,7 +475,7 @@ If the test cannot be implemented using available DRAW commands, consider the fo
|
||||
* Otherwise the new command implementing the actions needed for this particular test should be added in *QABugs* package. The command name should be formed by the Mantis issue ID prefixed by *bug*, e.g. *bug12345*.
|
||||
|
||||
Note that a DRAW command is expected to return 0 in case of a normal completion, and 1 (Tcl exception) if it is incorrectly used (e.g. a wrong number of input arguments). Thus if the new command needs to report a test error, this should be done by outputting an appropriate error message rather than by returning a non-zero value.
|
||||
|
||||
Also file names must not be encoded in DRAW command but in script, and passed to DRAW command as argument.
|
||||
|
||||
@subsection testmanual_3_4 Script Implementation
|
||||
|
||||
@@ -498,15 +521,23 @@ Example:
|
||||
stepread [locate_data_file CAROSKI_COUPELLE.step] a *
|
||||
~~~~~
|
||||
|
||||
When the test needs to produce some snapshots or other artefacts, use Tcl variable *logdir* as the location where such files should be put. Command *testgrid* sets this variable to the subdirectory of the results folder corresponding to the grid. Command *test* sets it to <i>$CASROOT/tmp</i> unless it is already defined. Use Tcl variable *casename* to prefix all files produced by the test. This variable is set to the name of the test case.
|
||||
When the test needs to produce some snapshots or other artefacts, use Tcl variable *imagedir* as the location where such files should be put.
|
||||
Command *testgrid* sets this variable to the subdirectory of the results folder corresponding to the grid.
|
||||
Command *test* by default creates dedicated temporary directory in the system temporary folder (normally the one specified by environment variable *TempDir*, *TEMP*, or *TMP*) for each execution, and sets *imagedir* to that location.
|
||||
However if variable *imagedir* is defined on top level of Tcl interpretor, command *test* will use it instead of creating a new directory.
|
||||
|
||||
Use Tcl variable *casename* to prefix all files produced by the test.
|
||||
This variable is set to the name of the test case.
|
||||
For the image file (snapshot) to be recognized by the test system (for inclusion in HTML log and differences), its name should start with name of the test case (use variable *casename*), optionally followed by underscore or dash and arbitrary suffix.
|
||||
The image format (defined by extension) should be *png*.
|
||||
|
||||
Example:
|
||||
~~~~~
|
||||
xwd $logdir/${casename}.png
|
||||
xwd $imagedir/${casename}.png
|
||||
vdisplay result; vfit
|
||||
vdump $logdir/${casename}-axo.png
|
||||
vdump $imagedir/${casename}-axo.png
|
||||
vfront; vfit
|
||||
vdump $logdir/${casename}-front.png
|
||||
vdump $imagedir/${casename}-front.png
|
||||
~~~~~
|
||||
|
||||
would produce:
|
||||
@@ -518,11 +549,15 @@ A1-front.png
|
||||
|
||||
Note that OCCT must be built with FreeImage support to be able to produce usable images.
|
||||
|
||||
Other Tcl variables defined during the test execution are:
|
||||
- *groupname*: name of the test group
|
||||
- *gridname*: name of the test grid
|
||||
- *dirname*: path to the root directory of the current set of test scripts
|
||||
|
||||
In order to ensure that the test works as expected in different environments, observe the following additional rules:
|
||||
* Avoid using external commands such as *grep, rm,* etc., as these commands can be absent on another system (e.g. on Windows); use facilities provided by Tcl instead.
|
||||
* Do not put call to *locate_data_file* in catch statement – this can prevent correct interpretation of the missing data file by the test system.
|
||||
|
||||
|
||||
@subsection testmanual_3_5 Interpretation of test results
|
||||
|
||||
The result of the test is evaluated by checking its output against patterns defined in the files *parse.rules* of the grid and group.
|
||||
@@ -953,7 +988,7 @@ This group allows testing extended data exchange packages.
|
||||
| Visualization | TKService, TKV2d, TKV3d, TKOpenGl, TKMeshVS, TKNIS, TKVoxel | vis |
|
||||
|
||||
|
||||
@subsection testmanual_5_2 Recommended approaches to checking test results
|
||||
@subsection testmanual_5_3 Recommended approaches to checking test results
|
||||
|
||||
@subsubsection testmanual_5_3_1 Shape validity
|
||||
|
||||
@@ -964,6 +999,36 @@ Example
|
||||
checkshape result
|
||||
~~~~~
|
||||
|
||||
To check the number of faults in the shape command *checkfaults* can be used.
|
||||
|
||||
Use: checkfaults shape source_shape [ref_value=0]
|
||||
|
||||
The default syntax of *checkfaults* command:
|
||||
~~~~~
|
||||
checkfaults results a_1
|
||||
~~~~~
|
||||
|
||||
The command will check the number of faults in the source shape (*a_1*) and compare it
|
||||
with number of faults in the resulting shape (*result*). If shape *result* contains
|
||||
more faults, you will get an error:
|
||||
~~~~~
|
||||
checkfaults results a_1
|
||||
Error : Number of faults is 5
|
||||
~~~~~
|
||||
It is possible to set the reference value for comparison (reference value is 4):
|
||||
|
||||
~~~~~
|
||||
checkfaults results a_1 4
|
||||
~~~~~
|
||||
|
||||
If number of faults in the resulting shape is unstable, reference value should be set to "-1".
|
||||
As a result command *checkfaults* will return the following error:
|
||||
|
||||
~~~~~
|
||||
checkfaults results a_1 -1
|
||||
Error : Number of faults is UNSTABLE
|
||||
~~~~~
|
||||
|
||||
@subsubsection testmanual_5_3_2 Shape tolerance
|
||||
The maximal tolerance of sub-shapes of each kind of the resulting shape can be extracted from output of tolerance command as follows:
|
||||
|
||||
@@ -974,6 +1039,33 @@ regexp { *EDGE +: +MAX=([-0-9.+eE]+)} $tolerance dummy max_edgee
|
||||
regexp { *VERTEX +: +MAX=([-0-9.+eE]+)} $tolerance dummy max_vertex
|
||||
~~~~~
|
||||
|
||||
It is possible to use command *checkmaxtol* to check maximal tolerance of shape and compare it with reference value.
|
||||
|
||||
Use: checkmaxtol shape ref_value [source_shapes={}] [options...]
|
||||
|
||||
Allowed options are:
|
||||
* -min_tol: minimum tolerance for comparison
|
||||
* -multi_tol: tolerance multiplier
|
||||
|
||||
Argument "source_shapes" is a list of shapes to compare with.
|
||||
It can be empty to skip comparison of tolerance with these shapes.
|
||||
|
||||
The default syntax of *checkmaxtol* command for comparison with the reference value:
|
||||
~~~~~
|
||||
checkmaxtol result 0.00001
|
||||
~~~~~
|
||||
|
||||
There is an opportunity to compare max tolerance of resulting shape with max tolerance of source shape.
|
||||
In the following example command *checkmaxtol* gets max tolerance among objects *a_1* and *a_2*.
|
||||
Then it chooses the maximum value between founded tolerance and value -min_tol (0.000001)
|
||||
and multiply it on the coefficient -multi_tol (i.e. 2):
|
||||
|
||||
~~~~~
|
||||
checkmaxtol result 0.00001 {a_1 a_2} -min_tol 0.000001 -multi_tol 2
|
||||
~~~~~
|
||||
|
||||
If the value of maximum tolerance more than founded tolerance for comparison, the command will return an error.
|
||||
|
||||
@subsubsection testmanual_5_3_3 Shape volume, area, or length
|
||||
|
||||
Use command *vprops, sprops,* or *lprops* to correspondingly measure volume, area, or length of the shape produced by the test. The value can be extracted from the result of the command by *regexp*.
|
||||
@@ -1010,7 +1102,7 @@ for {set i 1} {$i < 100} {incr i} {
|
||||
|
||||
@subsubsection testmanual_5_3_5 Visualization
|
||||
|
||||
Take a snapshot of the viewer, give it the name of the test case, and save in the directory indicated by Tcl variable *imagedir*. Note that this variable directs to the *log* directory if command *testgrid* is active, or to *tmp* subdirectory of the current folder if the test is run interactively.
|
||||
Take a snapshot of the viewer, give it the name of the test case, and save in the directory indicated by Tcl variable *imagedir*.
|
||||
|
||||
~~~~~
|
||||
vinit
|
||||
@@ -1023,3 +1115,82 @@ vdump $imagedir/${casename}_shading.png
|
||||
~~~~~
|
||||
|
||||
This image will be included in the HTML log produced by *testgrid* command and will be checked for non-regression through comparison of images by command *testdiff*.
|
||||
|
||||
@subsubsection testmanual_5_3_6 Number of free edges
|
||||
|
||||
To check the number of free edges run the command *checkfreebounds*.
|
||||
|
||||
It compares number of free edges with reference value.
|
||||
|
||||
Use: checkfreebounds shape ref_value [options...]
|
||||
|
||||
Allowed options are:
|
||||
* -tol N: used tolerance (default -0.01)
|
||||
* -type N: used type, possible values are "closed" and "opened" (default "closed")
|
||||
|
||||
~~~~~
|
||||
checkfreebounds result 13
|
||||
~~~~~
|
||||
|
||||
Option -tol N is used to set tolerance for command *freebounds*, which is used within command *checkfreebounds*.
|
||||
|
||||
Option -type N is used to select the type of counted free edges - closed or opened.
|
||||
|
||||
If the number of free edges in the resulting shape is unstable, reference value should be set to "-1".
|
||||
As a result command *checkfreebounds* will return the following error:
|
||||
|
||||
~~~~~
|
||||
checkfreebounds result -1
|
||||
Error : Number of free edges is UNSTABLE
|
||||
~~~~~
|
||||
|
||||
@subsubsection testmanual_5_3_7 Compare numbers
|
||||
|
||||
Procedure to check equality of two reals with some tolerance (relative and absolute)
|
||||
|
||||
Use: checkreal name value expected tol_abs tol_rel
|
||||
|
||||
~~~~~
|
||||
checkreal "Some important value" $value 5 0.0001 0.01
|
||||
~~~~~
|
||||
|
||||
@subsubsection testmanual_5_3_8 Check number of sub-shapes
|
||||
|
||||
Compare number of sub-shapes in "shape" with given reference data
|
||||
|
||||
Use: checknbshapes shape [options...]
|
||||
Allowed options are:
|
||||
* -vertex N
|
||||
* -edge N
|
||||
* -wire N
|
||||
* -face N
|
||||
* -shell N
|
||||
* -solid N
|
||||
* -compsolid N
|
||||
* -compound N
|
||||
* -shape N
|
||||
* -t: compare the number of sub-shapes in "shape" counting
|
||||
the same sub-shapes with different location as different sub-shapes.
|
||||
* -m msg: print "msg" in case of error
|
||||
|
||||
~~~~~
|
||||
checknbshapes result -vertex 8 -edge 4
|
||||
~~~~~
|
||||
|
||||
@subsubsection testmanual_5_3_9 Check pixel color
|
||||
|
||||
To check pixel color command *checkcolor* can be used.
|
||||
|
||||
Use: checkcolor x y red green blue
|
||||
|
||||
x y - pixel coordinates
|
||||
|
||||
red green blue - expected pixel color (values from 0 to 1)
|
||||
|
||||
This procedure checks color with tolerance (5x5 area)
|
||||
|
||||
Next example will compare color of point with coordinates x=100 y=100 with RGB color R=1 G=0 B=0.
|
||||
If colors are not equal, procedure will check the nearest ones points (5x5 area)
|
||||
~~~~~
|
||||
checkcolor 100 100 1 0 0
|
||||
~~~~~
|
||||
|
@@ -58,8 +58,7 @@ OPEN CASCADE S.A.S.
|
||||
|
||||
**Windows** is a registered trademark of Microsoft Corporation in the United States and other countries.
|
||||
|
||||
**Mac** and the Mac logo, **OpenCL** and the OpenCL logo, are trademarks of
|
||||
Apple Inc., registered in the U.S. and other countries.
|
||||
**Mac** and the Mac logo are trademarks of Apple Inc., registered in the U.S. and other countries.
|
||||
|
||||
Acknowledgements
|
||||
------------------
|
||||
@@ -220,14 +219,14 @@ for which OCCT is certified to work.
|
||||
|
||||
@subsection OCCT_OVW_SECTION_5_1 Linux
|
||||
|
||||
| Operating System | Mandriva 2010, CentOS 5.5, CentOS 6.3, Fedora 17, Fedora 18, Ubuntu-1304, Debian 6.0\* |
|
||||
| Operating System | Mandriva 2010, CentOS 5.5, CentOS 6.3, Fedora 17, Fedora 18, Ubuntu 13.04, Debian 6.0\* |
|
||||
| ----- | ----- |
|
||||
| Minimum memory | 512 MB, 1 GB recommended |
|
||||
| Free disk space (complete installation) | 600 MB approx. |
|
||||
| Video card | See \ref overview_req_graphics |
|
||||
| Graphic library | OpenGL 1.1+ (OpenGL 2.1+ is recommended)|
|
||||
| C++ | GNU gcc 4.0. - 4.7.3. |
|
||||
| TCL (for testing tools) | Tcltk 8.5 or 8.6 http://www.tcl.tk/software/tcltk/download.html |
|
||||
| TCL (for testing tools) | Tcl/Tk 8.5 or 8.6 http://www.tcl.tk/software/tcltk/download.html |
|
||||
| Qt (for demonstration tools) | Qt 4.8.6 http://qt-project.org/downloads |
|
||||
| Freetype (for text rendering) | freetype-2.5.3 http://sourceforge.net/projects/freetype/files/ |
|
||||
| FreeImage (optional, for support of common 2D graphic formats) | FreeImage 3.16.0 http://sourceforge.net/projects/freeimage/files |
|
||||
@@ -235,17 +234,17 @@ for which OCCT is certified to work.
|
||||
| Intel TBB (optional, for multithreaded algorithms) | TBB 3.x or 4.x http://www.threadingbuildingblocks.org/ |
|
||||
| VTK (for VTK Integration Services | VTK 6.1.0 http://www.vtk.org/VTK/resources/software.html |
|
||||
|
||||
* Debian 60 64 bit is a platform used for regular testing of contributions
|
||||
* Debian 6.0 64 bit is a platform used for regular testing of contributions
|
||||
|
||||
@subsection OCCT_OVW_SECTION_5_2 Windows
|
||||
|
||||
| Operating System | Windows 8 / 7 SP1 / Vista SP2 / XP SP3 |
|
||||
| Operating System | Windows 8.1 / 7 SP1 / Vista SP2 / XP SP3 |
|
||||
| ----- | ----- |
|
||||
| Minimum memory | 512 MB, 1 GB recommended |
|
||||
| Free disk space (complete installation) | 600 MB approx. |
|
||||
| Video card | See \ref overview_req_graphics |
|
||||
| Graphic library | OpenGL 1.1+ (OpenGL 2.1+ is recommended)|
|
||||
| C++ | Microsoft Visual Studio: 2005 SP1, 2008 SP1\*, 2010 SP1, 2012 Update 3, 2013 <br>Intel C++ Composer XE 2013 SP1 |
|
||||
| C++ | Microsoft Visual Studio: 2005 SP1, 2008 SP1, 2010 SP1 \*, 2012 Update 3, 2013 <br>Intel C++ Composer XE 2013 SP1 |
|
||||
| TCL (for testing tools) | Tcl/Tk 8.5 or 8.6 http://www.tcl.tk/software/tcltk/download.html |
|
||||
| Qt (for demonstration tools) | Qt 4.8.6 http://qt-project.org/downloads |
|
||||
| Freetype (OCCT Text rendering) | freetype-2.5.3 http://sourceforge.net/projects/freetype/files/ |
|
||||
@@ -259,14 +258,12 @@ for which OCCT is certified to work.
|
||||
|
||||
@subsection OCCT_OVW_SECTION_5_3 MAC OS X
|
||||
|
||||
| Operating System | Mac OS X 10.9 Mavericks / 10.8 Mountain Lion / 10.7 Lion / 10.6.8 Snow Leopard |
|
||||
| Operating System | OS X 10.10 Yosemite / 10.9 Mavericks / 10.8 Mountain Lion / 10.7 Lion / 10.6.8 Snow Leopard |
|
||||
| ----- | ----- |
|
||||
| Minimum memory | 512 MB, 1 GB recommended |
|
||||
| Free disk space (complete installation) | 600 MB approx. |
|
||||
| Video card | See \ref overview_req_graphics |
|
||||
| Graphic library | OpenGL 1.1+ (OpenGL 2.1+ is recommended)|
|
||||
| C++ | XCode 3.2 or newer (4.x is recommended) |
|
||||
| TCL (for testing tools) | Tcltk 8.5 or 8.6 http://www.tcl.tk/software/tcltk/download.html |
|
||||
| TCL (for testing tools) | Tcl/Tk 8.5 or 8.6 http://www.tcl.tk/software/tcltk/download.html |
|
||||
| Qt (for demonstration tools) | Qt 4.8.6 http://qt-project.org/downloads |
|
||||
| Freetype (OCCT Text rendering) | freetype-2.5.3 http://sourceforge.net/projects/freetype/files/ |
|
||||
| FreeImage (Support of common graphic formats) | FreeImage 3.16.0 http://sourceforge.net/projects/freeimage/files |
|
||||
@@ -277,27 +274,31 @@ for which OCCT is certified to work.
|
||||
|
||||
| Operating System | Android 4.0.4+ |
|
||||
| ----- | ----- |
|
||||
| Minimum memory | 512 MB, 1 GB recommended |
|
||||
| Minimum memory | 512 MB, 1 GB recommended |
|
||||
| C++ | NDK r10, GNU gcc 4.8 or newer |
|
||||
| Qt (for demonstration tools) | Qt 5.3.2 http://qt-project.org/downloads |
|
||||
| Freetype (for text rendering) | freetype-2.5.3 http://sourceforge.net/projects/freetype/files/ |
|
||||
|
||||
@subsection overview_req_graphics Graphic cards
|
||||
|
||||
For 3d viewer, graphic card or software implementation supporting OpenGL 1.1
|
||||
or above is required. OpenGL 2.1+ is highly recommended.
|
||||
For ray tracing, hardware implementation of OpenCL 1.1+ is required.
|
||||
On desktop, 3D viewer requires graphic card or software implementation supporting OpenGL 1.1 or above. OpenGL 2.1+ is highly recommended.
|
||||
Ray tracing requires OpenGL 4.0+ or OpenGL 3.1+ with GL_ARB_texture_buffer_object_rgb32 extension. Textures within ray tracing will be available only when GL_ARB_bindless_texture extension is provided by driver.
|
||||
|
||||
On mobile platforms, OpenGL ES 2.0+ is required for 3D viewer. The ray tracing is not yet available on mobile platforms.
|
||||
Some old hardware might be unable to execute complex GLSL programs (e.g. with high number of light sources, clipping planes).
|
||||
|
||||
The following table lists graphic cards tested to work with OCCT.
|
||||
|
||||
| Graphic card | Driver/GL/GLSL/CL version | OS | OpenGL (fixed pipeline) | OpenGL (shaders) | OpenCL (ray tracing) |
|
||||
| Graphic card | Driver | OS | OpenGL (fixed pipeline) | OpenGL (shaders) | OpenGL (ray tracing) |
|
||||
| ---- | ---- | ---- | :----: | :----: | :----: |
|
||||
| NVIDIA GeForce GT 610, 630M, 640 | Driver 311.44, GL 4.3.0, GLSL 4.30 | Windows 7 64 bit | OK | OK | OK |
|
||||
| Intel(R) HD Graphics 3000 | GL 3.1.0, GLSL 1.40 | Windows 7 64 bit | OK | OK | none |
|
||||
| RadeOn 9600 | GL 2.1.8454, GLSL 1.20 | | OK | bad | none |
|
||||
| AMD/ATI RadeOn HD 7870 | Driver 6.14.10.12002, GL 4.2.12002, GLSL 4.20 | Windows 7 64-bit | OK | OK | OK |
|
||||
| Mesa 7.8.2 Windows GDI Driver\* | GL 2.1, GLSL version 1.20 | Mac OS X 10.6 / OS X 10.9 | OK | artifacts | none |
|
||||
| NVIDIA GeForce 320 | | Mac OS X 10.6 / OS X 10.9 | OK | OK | OK on OSX 10.6, bad on OSX 10.9 |
|
||||
| NVIDIA GeForce 6600 GT | GL 2.1.2, GLSL 1.20 | Windows XP 32-bit | OK | OK | none |
|
||||
| Apple software OpenGL | | Mac OS X 10.6 / OS X 10.9 | OK | OK | OK |
|
||||
| NVIDIA GeForce GTX 650 | Driver 340.52, OpenGL 4.4 | Windows 7 64 bit | OK | OK | OK |
|
||||
| AMD/ATI RadeOn HD 7870 | Driver 14.100, OpenGL 4.4 | Windows 7 64-bit | OK | OK | OK |
|
||||
| Intel(R) HD Graphics 2500 | Driver 10.18.10.3621, OpenGL 4.0 | Windows 7 64 bit | OK | OK | limited (no textures) |
|
||||
| RadeOn 9600 | OpenGL 2.1.8454 | Windows XP 32-bit | OK | bad | unsupported by hardware |
|
||||
| NVIDIA GeForce 6600 GT | OpenGL 2.1 | Windows XP 32-bit | OK | OK | unsupported by hardware |
|
||||
| NVIDIA GeForce 320 | N/A | Mac OS X 10.6 / OS X 10.10 | OK | OK | not yet supported by OCCT |
|
||||
| Apple software OpenGL | N/A | Mac OS X 10.6 / OS X 10.10 | OK | OK | N/A |
|
||||
| Mesa 10.2.4 \* | "Gallium 0.4 on llvmpipe (LLVM 3.4, 256 bits)" OpenGL 3.0 | Windows 7 64 bit | OK | OK | unsupported by software |
|
||||
|
||||
* Mesa implementation of OpenGL is used for certification testing of OCCT
|
||||
|
||||
|
Before Width: | Height: | Size: 3.8 KiB After Width: | Height: | Size: 59 KiB |
Before Width: | Height: | Size: 4.0 KiB After Width: | Height: | Size: 60 KiB |
Before Width: | Height: | Size: 2.2 KiB After Width: | Height: | Size: 32 KiB |
Before Width: | Height: | Size: 2.4 KiB After Width: | Height: | Size: 36 KiB |
Before Width: | Height: | Size: 4.6 KiB After Width: | Height: | Size: 68 KiB |
Before Width: | Height: | Size: 4.9 KiB After Width: | Height: | Size: 69 KiB |
Before Width: | Height: | Size: 2.7 KiB After Width: | Height: | Size: 35 KiB |
Before Width: | Height: | Size: 2.6 KiB After Width: | Height: | Size: 38 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image080.png
Normal file
After Width: | Height: | Size: 2.2 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image081.png
Normal file
After Width: | Height: | Size: 3.5 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image082.png
Normal file
After Width: | Height: | Size: 1.6 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image083.png
Normal file
After Width: | Height: | Size: 825 B |
BIN
dox/user_guides/boolean_operations/images/boolean_image084.png
Normal file
After Width: | Height: | Size: 2.2 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image085.png
Normal file
After Width: | Height: | Size: 828 B |
BIN
dox/user_guides/boolean_operations/images/boolean_image086.png
Normal file
After Width: | Height: | Size: 3.4 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image087.png
Normal file
After Width: | Height: | Size: 1.4 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image088.png
Normal file
After Width: | Height: | Size: 940 B |
BIN
dox/user_guides/boolean_operations/images/boolean_image089.png
Normal file
After Width: | Height: | Size: 1.6 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image090.png
Normal file
After Width: | Height: | Size: 1.4 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image091.png
Normal file
After Width: | Height: | Size: 2.8 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image092.png
Normal file
After Width: | Height: | Size: 1.3 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image093.png
Normal file
After Width: | Height: | Size: 2.7 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image094.png
Normal file
After Width: | Height: | Size: 1.4 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image095.png
Normal file
After Width: | Height: | Size: 3.8 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image096.png
Normal file
After Width: | Height: | Size: 1.3 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image097.png
Normal file
After Width: | Height: | Size: 3.9 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image098.png
Normal file
After Width: | Height: | Size: 1.3 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image099.png
Normal file
After Width: | Height: | Size: 2.6 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image100.png
Normal file
After Width: | Height: | Size: 1.3 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image101.png
Normal file
After Width: | Height: | Size: 2.5 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image102.png
Normal file
After Width: | Height: | Size: 1.3 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image103.png
Normal file
After Width: | Height: | Size: 1.9 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image104.png
Normal file
After Width: | Height: | Size: 1.3 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image105.png
Normal file
After Width: | Height: | Size: 4.0 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image106.png
Normal file
After Width: | Height: | Size: 1.2 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image107.png
Normal file
After Width: | Height: | Size: 4.2 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image108.png
Normal file
After Width: | Height: | Size: 1.3 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image109.png
Normal file
After Width: | Height: | Size: 3.3 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image110.png
Normal file
After Width: | Height: | Size: 1.4 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image111.png
Normal file
After Width: | Height: | Size: 3.8 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image112.png
Normal file
After Width: | Height: | Size: 1.2 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image113.png
Normal file
After Width: | Height: | Size: 4.9 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image114.png
Normal file
After Width: | Height: | Size: 1.4 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image115.png
Normal file
After Width: | Height: | Size: 5.1 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image116.png
Normal file
After Width: | Height: | Size: 1.3 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image117.png
Normal file
After Width: | Height: | Size: 5.0 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image118.png
Normal file
After Width: | Height: | Size: 1.2 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image119.png
Normal file
After Width: | Height: | Size: 4.3 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image120.png
Normal file
After Width: | Height: | Size: 1.3 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image121.png
Normal file
After Width: | Height: | Size: 79 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image122.png
Normal file
After Width: | Height: | Size: 77 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image123.png
Normal file
After Width: | Height: | Size: 51 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image124.png
Normal file
After Width: | Height: | Size: 135 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image125.png
Normal file
After Width: | Height: | Size: 20 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image126.png
Normal file
After Width: | Height: | Size: 76 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image127.png
Normal file
After Width: | Height: | Size: 84 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image128.png
Normal file
After Width: | Height: | Size: 40 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image129.png
Normal file
After Width: | Height: | Size: 45 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image130.png
Normal file
After Width: | Height: | Size: 43 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image131.png
Normal file
After Width: | Height: | Size: 35 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image132.png
Normal file
After Width: | Height: | Size: 24 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image133.png
Normal file
After Width: | Height: | Size: 2.9 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image134.png
Normal file
After Width: | Height: | Size: 1.4 KiB |
BIN
dox/user_guides/boolean_operations/images/boolean_image135.png
Normal file
After Width: | Height: | Size: 8.4 KiB |
Before Width: | Height: | Size: 57 KiB After Width: | Height: | Size: 58 KiB |
Before Width: | Height: | Size: 69 KiB After Width: | Height: | Size: 89 KiB |
Before Width: | Height: | Size: 68 KiB After Width: | Height: | Size: 76 KiB |
@@ -9,14 +9,92 @@
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
width="496.79102"
|
||||
height="182.59267"
|
||||
width="489.42633"
|
||||
height="256.69815"
|
||||
id="svg7940"
|
||||
version="1.1"
|
||||
inkscape:version="0.48.4 r9939"
|
||||
sodipodi:docname="operations_image017.svg">
|
||||
<defs
|
||||
id="defs7942">
|
||||
<marker
|
||||
inkscape:stockid="Arrow1Lend"
|
||||
orient="auto"
|
||||
refY="0.0"
|
||||
refX="0.0"
|
||||
id="Arrow1Lend"
|
||||
style="overflow:visible;">
|
||||
<path
|
||||
id="path7101"
|
||||
d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "
|
||||
style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;"
|
||||
transform="scale(0.8) rotate(180) translate(12.5,0)" />
|
||||
</marker>
|
||||
<marker
|
||||
inkscape:stockid="TriangleInL"
|
||||
orient="auto"
|
||||
refY="0.0"
|
||||
refX="0.0"
|
||||
id="TriangleInL"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
id="path7231"
|
||||
d="M 5.77,0.0 L -2.88,5.0 L -2.88,-5.0 L 5.77,0.0 z "
|
||||
style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt"
|
||||
transform="scale(-0.8)" />
|
||||
</marker>
|
||||
<marker
|
||||
inkscape:stockid="Arrow1Mend"
|
||||
orient="auto"
|
||||
refY="0.0"
|
||||
refX="0.0"
|
||||
id="Arrow1Mend"
|
||||
style="overflow:visible;">
|
||||
<path
|
||||
id="path7107"
|
||||
d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "
|
||||
style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;"
|
||||
transform="scale(0.4) rotate(180) translate(10,0)" />
|
||||
</marker>
|
||||
<marker
|
||||
inkscape:stockid="Arrow2Mend"
|
||||
orient="auto"
|
||||
refY="0.0"
|
||||
refX="0.0"
|
||||
id="Arrow2Mend"
|
||||
style="overflow:visible;">
|
||||
<path
|
||||
id="path7125"
|
||||
style="fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round;"
|
||||
d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
|
||||
transform="scale(0.6) rotate(180) translate(0,0)" />
|
||||
</marker>
|
||||
<marker
|
||||
inkscape:stockid="Arrow2Lstart"
|
||||
orient="auto"
|
||||
refY="0.0"
|
||||
refX="0.0"
|
||||
id="Arrow2Lstart"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
id="path7116"
|
||||
style="fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round"
|
||||
d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
|
||||
transform="scale(1.1) translate(1,0)" />
|
||||
</marker>
|
||||
<marker
|
||||
inkscape:stockid="Arrow2Lend"
|
||||
orient="auto"
|
||||
refY="0.0"
|
||||
refX="0.0"
|
||||
id="Arrow2Lend"
|
||||
style="overflow:visible;">
|
||||
<path
|
||||
id="path7119"
|
||||
style="fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round;"
|
||||
d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
|
||||
transform="scale(1.1) rotate(180) translate(1,0)" />
|
||||
</marker>
|
||||
<clipPath
|
||||
id="clipEmfPath1"
|
||||
clipPathUnits="userSpaceOnUse">
|
||||
@@ -87,6 +165,132 @@
|
||||
y="155.1031"
|
||||
x="384.29144" />
|
||||
</clipPath>
|
||||
<marker
|
||||
inkscape:stockid="Arrow1Lend"
|
||||
orient="auto"
|
||||
refY="0"
|
||||
refX="0"
|
||||
id="Arrow1Lend-3"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
inkscape:connector-curvature="0"
|
||||
id="path7101-4"
|
||||
d="M 0,0 5,-5 -12.5,0 5,5 0,0 z"
|
||||
style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt"
|
||||
transform="matrix(-0.8,0,0,-0.8,-10,0)" />
|
||||
</marker>
|
||||
<marker
|
||||
inkscape:stockid="Arrow1Lend"
|
||||
orient="auto"
|
||||
refY="0"
|
||||
refX="0"
|
||||
id="Arrow1Lend-1"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
inkscape:connector-curvature="0"
|
||||
id="path7101-3"
|
||||
d="M 0,0 5,-5 -12.5,0 5,5 0,0 z"
|
||||
style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt"
|
||||
transform="matrix(-0.8,0,0,-0.8,-10,0)" />
|
||||
</marker>
|
||||
<marker
|
||||
inkscape:stockid="Arrow1Lend"
|
||||
orient="auto"
|
||||
refY="0"
|
||||
refX="0"
|
||||
id="Arrow1Lend-7"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
inkscape:connector-curvature="0"
|
||||
id="path7101-42"
|
||||
d="M 0,0 5,-5 -12.5,0 5,5 0,0 z"
|
||||
style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt"
|
||||
transform="matrix(-0.8,0,0,-0.8,-10,0)" />
|
||||
</marker>
|
||||
<marker
|
||||
inkscape:stockid="Arrow1Lend"
|
||||
orient="auto"
|
||||
refY="0"
|
||||
refX="0"
|
||||
id="Arrow1Lend-79"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
inkscape:connector-curvature="0"
|
||||
id="path7101-31"
|
||||
d="M 0,0 5,-5 -12.5,0 5,5 0,0 z"
|
||||
style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt"
|
||||
transform="matrix(-0.8,0,0,-0.8,-10,0)" />
|
||||
</marker>
|
||||
<marker
|
||||
inkscape:stockid="Arrow1Lend"
|
||||
orient="auto"
|
||||
refY="0"
|
||||
refX="0"
|
||||
id="Arrow1Lend-8"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
inkscape:connector-curvature="0"
|
||||
id="path7101-6"
|
||||
d="M 0,0 5,-5 -12.5,0 5,5 0,0 z"
|
||||
style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt"
|
||||
transform="matrix(-0.8,0,0,-0.8,-10,0)" />
|
||||
</marker>
|
||||
<marker
|
||||
inkscape:stockid="Arrow1Lend"
|
||||
orient="auto"
|
||||
refY="0"
|
||||
refX="0"
|
||||
id="Arrow1Lend-0"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
inkscape:connector-curvature="0"
|
||||
id="path7101-2"
|
||||
d="M 0,0 5,-5 -12.5,0 5,5 0,0 z"
|
||||
style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt"
|
||||
transform="matrix(-0.8,0,0,-0.8,-10,0)" />
|
||||
</marker>
|
||||
<marker
|
||||
inkscape:stockid="Arrow2Mend"
|
||||
orient="auto"
|
||||
refY="0"
|
||||
refX="0"
|
||||
id="Arrow2Mend-6"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
inkscape:connector-curvature="0"
|
||||
id="path7125-0"
|
||||
style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
|
||||
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||
transform="scale(-0.6,-0.6)" />
|
||||
</marker>
|
||||
<marker
|
||||
inkscape:stockid="Arrow2Mend"
|
||||
orient="auto"
|
||||
refY="0"
|
||||
refX="0"
|
||||
id="Arrow2Mend-4"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
inkscape:connector-curvature="0"
|
||||
id="path7125-8"
|
||||
style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
|
||||
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||
transform="scale(-0.6,-0.6)" />
|
||||
</marker>
|
||||
<marker
|
||||
inkscape:stockid="Arrow2Mend"
|
||||
orient="auto"
|
||||
refY="0"
|
||||
refX="0"
|
||||
id="Arrow2Mend-5"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
inkscape:connector-curvature="0"
|
||||
id="path7125-09"
|
||||
style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
|
||||
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||
transform="scale(-0.6,-0.6)" />
|
||||
</marker>
|
||||
</defs>
|
||||
<sodipodi:namedview
|
||||
id="base"
|
||||
@@ -96,8 +300,8 @@
|
||||
inkscape:pageopacity="0.0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:zoom="1.3164489"
|
||||
inkscape:cx="248.39551"
|
||||
inkscape:cy="91.293193"
|
||||
inkscape:cx="232.3447"
|
||||
inkscape:cy="41.764693"
|
||||
inkscape:document-units="px"
|
||||
inkscape:current-layer="g7973"
|
||||
showgrid="false"
|
||||
@@ -105,10 +309,10 @@
|
||||
fit-margin-left="0"
|
||||
fit-margin-right="0"
|
||||
fit-margin-bottom="0"
|
||||
inkscape:window-width="818"
|
||||
inkscape:window-height="609"
|
||||
inkscape:window-x="198"
|
||||
inkscape:window-y="198"
|
||||
inkscape:window-width="1209"
|
||||
inkscape:window-height="780"
|
||||
inkscape:window-x="31"
|
||||
inkscape:window-y="127"
|
||||
inkscape:window-maximized="0" />
|
||||
<metadata
|
||||
id="metadata7945">
|
||||
@@ -126,7 +330,7 @@
|
||||
inkscape:label="Layer 1"
|
||||
inkscape:groupmode="layer"
|
||||
id="layer1"
|
||||
transform="translate(151.25265,-326.77699)">
|
||||
transform="translate(151.25265,-261.25634)">
|
||||
<g
|
||||
id="g7973"
|
||||
transform="translate(-150.65102,302.21449)">
|
||||
@@ -169,8 +373,8 @@
|
||||
<text
|
||||
id="text7989"
|
||||
style="font-size:13.83749962px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Calibri"
|
||||
y="104.70588"
|
||||
x="13.536685"
|
||||
y="69.76339"
|
||||
x="50.758034"
|
||||
xml:space="preserve">BOPDS_InterfVV</text>
|
||||
<text
|
||||
id="text7991"
|
||||
@@ -205,14 +409,14 @@
|
||||
<text
|
||||
id="text8001"
|
||||
style="font-size:13.83749962px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Calibri"
|
||||
y="168.34177"
|
||||
x="139.72867"
|
||||
y="102.25489"
|
||||
x="48.574352"
|
||||
xml:space="preserve">BOPDS</text>
|
||||
<text
|
||||
id="text8003"
|
||||
style="font-size:13.83749962px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Calibri"
|
||||
y="168.34177"
|
||||
x="179.43626"
|
||||
y="103.77412"
|
||||
x="89.041565"
|
||||
xml:space="preserve">_InterfVE</text>
|
||||
<text
|
||||
id="text8005"
|
||||
@@ -235,8 +439,8 @@
|
||||
<text
|
||||
id="text8015"
|
||||
style="font-size:13.83749962px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Calibri"
|
||||
y="105.60851"
|
||||
x="395.72241"
|
||||
y="171.6954"
|
||||
x="47.057148"
|
||||
xml:space="preserve">BOPDS_InterfVF</text>
|
||||
<text
|
||||
id="text8017"
|
||||
@@ -259,8 +463,8 @@
|
||||
<text
|
||||
id="text8027"
|
||||
style="font-size:13.83749962px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Calibri"
|
||||
y="168.04089"
|
||||
x="14.739945"
|
||||
y="137.65613"
|
||||
x="48.922813"
|
||||
xml:space="preserve">BOPDS_InterfEE</text>
|
||||
<text
|
||||
id="text8029"
|
||||
@@ -283,8 +487,8 @@
|
||||
<text
|
||||
id="text8039"
|
||||
style="font-size:13.83749962px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Calibri"
|
||||
y="168.04089"
|
||||
x="266.52228"
|
||||
y="205.26224"
|
||||
x="49.271156"
|
||||
xml:space="preserve">BOPDS_InterfEF</text>
|
||||
<text
|
||||
id="text8041"
|
||||
@@ -307,8 +511,8 @@
|
||||
<text
|
||||
id="text8051"
|
||||
style="font-size:13.83749962px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Calibri"
|
||||
y="168.04089"
|
||||
x="396.92566"
|
||||
y="72.328857"
|
||||
x="356.66583"
|
||||
xml:space="preserve">BOPDS_InterfFF</text>
|
||||
<text
|
||||
id="text8053"
|
||||
@@ -328,72 +532,150 @@
|
||||
clip-path="url(#clipEmfPath7)"
|
||||
style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.15040761px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path8063"
|
||||
d="m 119.79026,151.06004 76.55747,-95.83935 c 0.21621,-0.272671 0.61103,-0.310281 0.88364,-0.09402 0.26322,0.216257 0.31022,0.601758 0.094,0.874429 L 120.7679,151.84044 c -0.21621,0.27268 -0.61103,0.31029 -0.87425,0.094 -0.27261,-0.21626 -0.31961,-0.61116 -0.1034,-0.87443 z m 73.32371,-96.817206 7.63318,-3.525925 -1.75789,8.217756 z"
|
||||
style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.15040761px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path8065"
|
||||
d="M 400.59186,88.514827 320.93223,51.71357 c -0.31962,-0.131634 -0.45122,-0.507733 -0.31962,-0.827417 0.15041,-0.300879 0.52643,-0.451318 0.84605,-0.300879 l 79.65962,36.801257 c 0.31962,0.15044 0.45123,0.507733 0.30082,0.827417 -0.13161,0.319684 -0.50763,0.451319 -0.82724,0.300879 z m -79.84764,-33.416369 -5.24547,-6.581727 8.40403,-0.244464 z"
|
||||
style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.15040761px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path8067"
|
||||
d="M 382.73095,151.88746 292.618,55.042044 c -0.24442,-0.244465 -0.22561,-0.639368 0.0376,-0.883832 0.24441,-0.22566 0.63923,-0.22566 0.88364,0.03761 l 90.11296,96.826608 c 0.22561,0.26327 0.20681,0.65817 -0.0376,0.88383 -0.26322,0.24447 -0.65804,0.22566 -0.88365,-0.0188 z m -91.56063,-93.780212 -2.36892,-8.086122 7.8776,2.952375 z"
|
||||
style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.15040761px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path8069"
|
||||
d="m 186.25162,148.65301 36.45504,-93.827223 c 0.13161,-0.319684 0.48883,-0.479526 0.81784,-0.357294 0.31962,0.122232 0.47943,0.488928 0.35722,0.808612 l -36.46444,93.827225 c -0.12221,0.31968 -0.48883,0.47952 -0.80844,0.35729 -0.31962,-0.12223 -0.47943,-0.48893 -0.35722,-0.80861 z m 33.08027,-93.789613 6.23252,-5.650883 0.78024,8.368196 z"
|
||||
style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.15040761px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path8071"
|
||||
d="M 298.37109,150.16681 261.17341,55.277105 c -0.12221,-0.319684 0.0376,-0.68638 0.35721,-0.818014 0.31962,-0.122232 0.68624,0.03761 0.80845,0.357293 l 37.19768,94.899106 c 0.1222,0.31968 -0.0376,0.68638 -0.35722,0.80861 -0.31962,0.13163 -0.68624,-0.0282 -0.80844,-0.35729 z m -39.66061,-92.576698 0.76144,-8.377598 6.24192,5.632078 z"
|
||||
style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.15040761px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path7977-0"
|
||||
d="m 5.1186429,88.992212 0,23.632508 109.3389271,0 0,-23.632508 z"
|
||||
d="m 42.339993,54.049725 0,23.632509 109.338927,0 0,-23.632509 z"
|
||||
clip-path="url(#clipEmfPath0)"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.13333213px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path7977-9"
|
||||
d="m 8.9373759,151.30163 0,23.59123 117.6534741,0 0,-23.59123 z"
|
||||
d="m 40.06113,155.83871 0,23.63251 109.33894,0 0,-23.63251 z"
|
||||
clip-path="url(#clipEmfPath0)"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.17460704px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.13333225px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path7977-4"
|
||||
d="m 133.51826,149.78571 0,25.86345 108.5314,0 0,-25.86345 z"
|
||||
d="m 41.604324,86.737307 0,25.863453 108.531406,0 0,-25.863453 z"
|
||||
clip-path="url(#clipEmfPath0)"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.181234px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path7977-8"
|
||||
d="m 254.27568,152.04252 0,23.62869 110.09473,0 0,-23.62869 z"
|
||||
d="m 346.98776,188.54277 0,26.59013 111.53693,0 0,-26.59013 z"
|
||||
clip-path="url(#clipEmfPath0)"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.13715053px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.21418393px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path7977-82"
|
||||
d="m 378.10495,152.05385 0,23.60604 114.6298,0 0,-23.60604 z"
|
||||
d="m 347.71077,152.04444 0,23.62486 110.85053,0 0,-23.62486 z"
|
||||
clip-path="url(#clipEmfPath0)"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.15977955px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.14095533px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path7977-45"
|
||||
d="m 384.16868,88.992217 0,23.632503 109.33893,0 0,-23.632503 z"
|
||||
d="m 348.46658,56.328587 0,23.632503 109.33893,0 0,-23.632503 z"
|
||||
clip-path="url(#clipEmfPath0)"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.13333213px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path8065-5"
|
||||
d="M 94.333788,88.994294 174.852,52.193762 c 0.32306,-0.131626 0.45608,-0.507719 0.32306,-0.827403 -0.15203,-0.300865 -0.5321,-0.451298 -0.85516,-0.300865 L 93.801694,87.866015 c -0.323062,0.150433 -0.456091,0.507719 -0.304061,0.827403 0.13303,0.319672 0.513105,0.451309 0.836155,0.300876 z m 80.708242,-33.415706 5.302,-6.581595 -8.4946,-0.244456 z"
|
||||
style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.15121448px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-opacity:1;stroke-dasharray:none"
|
||||
id="path7977-4-4"
|
||||
d="m 41.604316,120.54037 0,25.86345 108.531414,0 0,-25.86345 z"
|
||||
clip-path="url(#clipEmfPath0)"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.181234px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path7977-4-4-3"
|
||||
d="m 40.844696,188.9061 0,25.86345 108.531414,0 0,-25.86345 z"
|
||||
clip-path="url(#clipEmfPath0)"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.181234px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path7977-45-1"
|
||||
d="m 348.84638,87.472974 0,23.632496 109.33893,0 0,-23.632496 z"
|
||||
clip-path="url(#clipEmfPath0)"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.13333213px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path7977-45-1-2"
|
||||
d="m 348.84637,119.99774 0,23.63249 109.33894,0 0,-23.63249 z"
|
||||
clip-path="url(#clipEmfPath0)"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.13333213px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:1.10169673px;stroke-linecap:square;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow1Mend)"
|
||||
d="M 149.85384,204.29486 C 230.85854,55.736284 224.20183,70.168708 233.29123,49.430411"
|
||||
id="path7092"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:1.09412837000000000px;stroke-linecap:square;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Mend)"
|
||||
d="M 345.7377,205.8298 C 266.29458,50.514625 344.4084,205.30413 266.83812,50.201751"
|
||||
id="path7092-1"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:0.99494576000000001;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)"
|
||||
d="M 348.11603,163.37866 C 276.12641,49.564157 346.91144,162.99344 276.61894,49.334877"
|
||||
id="path7092-1-8"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:1.10269988;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow1Mend)"
|
||||
d="M 149.61475,165.27411 C 219.55739,49.941963 150.7851,164.88377 219.07886,49.709629"
|
||||
id="path7092-1-8-7"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:1.13005996;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow1Mend)"
|
||||
d="M 149.66811,132.69657 C 206.67163,53.004017 201.98726,60.746123 208.38353,49.6213"
|
||||
id="path7092-9"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:1.10019314000000000;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)"
|
||||
d="M 349.11274,130.81271 C 288.83402,53.259375 293.78753,60.793646 287.02374,49.967454"
|
||||
id="path7092-9-5"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:1.11000000000000010;stroke-linecap:square;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Mend);stroke-miterlimit:4;stroke-dasharray:none"
|
||||
d="M 348.82796,103.94125 C 300.14567,51.005439 304.14623,56.148144 298.68367,48.758472"
|
||||
id="path7092-8"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:0.94566226;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)"
|
||||
d="M 348.46436,74.478977 C 312.52241,49.924315 315.47601,52.309799 311.44301,48.882043"
|
||||
id="path7092-8-2"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:1.10514271;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)"
|
||||
d="M 149.55974,102.35503 C 199.86531,51.574705 195.73135,56.508011 201.37605,49.419244"
|
||||
id="path7092-8-6"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:0.84515506;stroke-linecap:square;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow2Mend)"
|
||||
d="m 151.98151,68.474714 c 37.31475,-18.891043 34.24834,-17.05577 38.43538,-19.692908"
|
||||
id="path7092-8-2-0"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<text
|
||||
id="text8051-0"
|
||||
style="font-size:13.83749962px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Calibri"
|
||||
y="101.49554"
|
||||
x="355.22458"
|
||||
xml:space="preserve">BOPDS_InterfVZ</text>
|
||||
<text
|
||||
id="text8051-6"
|
||||
style="font-size:13.83749962px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Calibri"
|
||||
y="135.67842"
|
||||
x="355.22461"
|
||||
xml:space="preserve">BOPDS_InterfEZ</text>
|
||||
<text
|
||||
id="text8051-6-1"
|
||||
style="font-size:13.83749962px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Calibri"
|
||||
y="166.82281"
|
||||
x="354.78879"
|
||||
xml:space="preserve">BOPDS_InterfFZ</text>
|
||||
<text
|
||||
id="text8051-6-1-3"
|
||||
style="font-size:13.83749962px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Calibri"
|
||||
y="206.323"
|
||||
x="354.23187"
|
||||
xml:space="preserve">BOPDS_InterfZZ</text>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 19 KiB After Width: | Height: | Size: 28 KiB |
@@ -9,14 +9,40 @@
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
width="442.23795"
|
||||
height="239.25778"
|
||||
width="488.59842"
|
||||
height="239.24245"
|
||||
id="svg2"
|
||||
version="1.1"
|
||||
inkscape:version="0.48.4 r9939"
|
||||
sodipodi:docname="operations_image020.svg">
|
||||
<defs
|
||||
id="defs4">
|
||||
<marker
|
||||
inkscape:stockid="Arrow2Lstart"
|
||||
orient="auto"
|
||||
refY="0.0"
|
||||
refX="0.0"
|
||||
id="Arrow2Lstart"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
id="path7116"
|
||||
style="fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round"
|
||||
d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
|
||||
transform="scale(1.1) translate(1,0)" />
|
||||
</marker>
|
||||
<marker
|
||||
inkscape:stockid="Arrow2Mend"
|
||||
orient="auto"
|
||||
refY="0.0"
|
||||
refX="0.0"
|
||||
id="Arrow2Mend"
|
||||
style="overflow:visible;">
|
||||
<path
|
||||
id="path7125"
|
||||
style="fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round;"
|
||||
d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
|
||||
transform="scale(0.6) rotate(180) translate(0,0)" />
|
||||
</marker>
|
||||
<clipPath
|
||||
id="clipEmfPath1"
|
||||
clipPathUnits="userSpaceOnUse">
|
||||
@@ -67,6 +93,20 @@
|
||||
y="204.34763"
|
||||
x="292.81927" />
|
||||
</clipPath>
|
||||
<marker
|
||||
inkscape:stockid="Arrow2Lstart"
|
||||
orient="auto"
|
||||
refY="0"
|
||||
refX="0"
|
||||
id="Arrow2Lstart-3"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
inkscape:connector-curvature="0"
|
||||
id="path7116-4"
|
||||
style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
|
||||
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||
transform="matrix(1.1,0,0,1.1,1.1,0)" />
|
||||
</marker>
|
||||
</defs>
|
||||
<sodipodi:namedview
|
||||
id="base"
|
||||
@@ -76,8 +116,8 @@
|
||||
inkscape:pageopacity="0.0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:zoom="2.1979709"
|
||||
inkscape:cx="221.11303"
|
||||
inkscape:cy="156.01843"
|
||||
inkscape:cx="318.63273"
|
||||
inkscape:cy="137.81983"
|
||||
inkscape:document-units="px"
|
||||
inkscape:current-layer="g3004"
|
||||
showgrid="false"
|
||||
@@ -85,10 +125,10 @@
|
||||
fit-margin-left="0"
|
||||
fit-margin-right="0"
|
||||
fit-margin-bottom="0"
|
||||
inkscape:window-width="1136"
|
||||
inkscape:window-width="1670"
|
||||
inkscape:window-height="723"
|
||||
inkscape:window-x="248"
|
||||
inkscape:window-y="192"
|
||||
inkscape:window-x="42"
|
||||
inkscape:window-y="158"
|
||||
inkscape:window-maximized="0" />
|
||||
<metadata
|
||||
id="metadata7">
|
||||
@@ -106,7 +146,7 @@
|
||||
inkscape:label="Layer 1"
|
||||
inkscape:groupmode="layer"
|
||||
id="layer1"
|
||||
transform="translate(-153.88697,-412.72562)">
|
||||
transform="translate(-153.88697,-412.74096)">
|
||||
<g
|
||||
id="g3004"
|
||||
transform="translate(153.4374,405.50687)">
|
||||
@@ -215,14 +255,14 @@
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path3054"
|
||||
d="m 190.76155,186.09256 0,28.80655 188.15051,0 0,-28.80655 z"
|
||||
d="m 67.466014,185.63759 0,28.80655 188.150506,0 0,-28.80655 z"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.04681468px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<text
|
||||
id="text3056"
|
||||
style="font-size:13.78678322px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
y="202.85298"
|
||||
x="239.23761"
|
||||
y="204.21788"
|
||||
x="124.58641"
|
||||
xml:space="preserve">BOPAlgo_BOP</text>
|
||||
<text
|
||||
id="text3058"
|
||||
@@ -231,9 +271,25 @@
|
||||
x="412.70435"
|
||||
xml:space="preserve"> </text>
|
||||
<path
|
||||
id="path3010-9"
|
||||
d="m 283.3676,185.54698 -0.59005,-22.61992 c 0,-0.3467 0.27161,-0.62781 0.60879,-0.63718 0.34654,-0.009 0.63689,0.26237 0.64625,0.60907 l 0.5807,22.61055 c 0.009,0.3467 -0.26225,0.62781 -0.59943,0.63718 -0.34654,0.009 -0.63689,-0.26237 -0.64626,-0.5997 z m -3.67148,-21.28933 3.54973,-7.58996 3.93373,7.39318 z"
|
||||
style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.14985634px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-opacity:1;stroke-dasharray:none"
|
||||
id="path3054-8"
|
||||
d="m 300.37408,185.70141 0,28.80655 188.1505,0 0,-28.80655 z"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.04681468px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<text
|
||||
id="text3056-9"
|
||||
style="font-size:13.78678322px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
y="203.31017"
|
||||
x="336.76245"
|
||||
xml:space="preserve">BOPAlgo_Section</text>
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:0.95747238px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#Arrow2Lstart);marker-end:none"
|
||||
d="m 267.10914,158.63892 -77.87032,26.89356"
|
||||
id="path13459"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:0.88220716px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#Arrow2Lstart);marker-end:none"
|
||||
d="m 316.41379,158.50756 65.91804,26.97147"
|
||||
id="path13459-4"
|
||||
inkscape:connector-curvature="0" />
|
||||
</g>
|
||||
</g>
|
||||
|
Before Width: | Height: | Size: 10 KiB After Width: | Height: | Size: 12 KiB |
@@ -14,7 +14,7 @@
|
||||
id="svg9815"
|
||||
version="1.1"
|
||||
inkscape:version="0.48.4 r9939"
|
||||
sodipodi:docname="operations_image26.svg">
|
||||
sodipodi:docname="operations_image026.svg">
|
||||
<defs
|
||||
id="defs9817">
|
||||
<clipPath
|
||||
@@ -236,16 +236,16 @@
|
||||
inkscape:pageopacity="0.0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:zoom="2.041917"
|
||||
inkscape:cx="135.36299"
|
||||
inkscape:cx="286.30241"
|
||||
inkscape:cy="128.68008"
|
||||
inkscape:document-units="px"
|
||||
inkscape:current-layer="layer1"
|
||||
inkscape:current-layer="g9890"
|
||||
showgrid="false"
|
||||
fit-margin-top="0"
|
||||
fit-margin-left="0"
|
||||
fit-margin-right="0"
|
||||
fit-margin-bottom="0"
|
||||
inkscape:window-width="1035"
|
||||
inkscape:window-width="1622"
|
||||
inkscape:window-height="778"
|
||||
inkscape:window-x="44"
|
||||
inkscape:window-y="44"
|
||||
@@ -550,11 +550,6 @@
|
||||
d="m 312.40693,228.95026 0,13.22891 111.43464,0 0,-13.22891 -111.43464,0 z"
|
||||
style="fill:#e0e0e0;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path9998"
|
||||
d="m 312.40693,134.43123 0,107.78552 111.35965,0 0,-107.78552 z"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.25607681px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<text
|
||||
id="text10000"
|
||||
style="font-size:13.79809761px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Calibri"
|
||||
@@ -653,17 +648,17 @@
|
||||
<path
|
||||
id="path10032"
|
||||
d="m 367.0744,135.42716 56.9359,54.49407"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.87474155px;stroke-linecap:butt;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.275;stroke-linecap:butt;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none;stroke-miterlimit:4"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path10034"
|
||||
d="m 424.62896,188.66223 -55.60483,51.99486"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.87474155px;stroke-linecap:butt;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.275;stroke-linecap:butt;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none;stroke-miterlimit:4"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path10036"
|
||||
d="m 312.08823,190.54134 54.98617,50.11575"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.87474155px;stroke-linecap:butt;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none"
|
||||
d="m 314.03751,192.49062 52.14919,47.27877"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.273;stroke-linecap:butt;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none;stroke-miterlimit:4"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path10038"
|
||||
@@ -981,6 +976,39 @@
|
||||
y="157.54424"
|
||||
x="98.086479"
|
||||
xml:space="preserve"> </text>
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
|
||||
d="m 311.42332,186.81701 c 0.48082,-53.87094 -0.48084,-53.37214 -0.48084,-53.37214 l 0,0 52.89148,-0.4988 0,0"
|
||||
id="path15317"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
|
||||
d="m 310.94248,193.18358 0,49.95306"
|
||||
id="path15319"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
|
||||
d="m 365.34296,232.61565 -54.85042,0 0.48974,-0.48973"
|
||||
id="path15321"
|
||||
inkscape:connector-curvature="0"
|
||||
transform="translate(0.44994,10.03125)" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
|
||||
d="m 370.73005,233.10539 51.42227,-0.48974 0.48974,-48.97358 0,0"
|
||||
id="path15323"
|
||||
inkscape:connector-curvature="0"
|
||||
transform="translate(0.44994,10.03125)" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:1.00884902px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
|
||||
d="m 369.22547,132.959 53.8621,-0.98798 0,55.82105 0,0"
|
||||
id="path15325"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
|
||||
d="m 313.92069,180.70365 106.27269,0"
|
||||
id="path15327"
|
||||
inkscape:connector-curvature="0"
|
||||
transform="translate(0.44994,10.03125)" />
|
||||
</g>
|
||||
<path
|
||||
transform="translate(161.72003,403.93982)"
|
||||
@@ -1006,11 +1034,10 @@
|
||||
id="path10353-5"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;stroke-miterlimit:4;stroke-dasharray:none"
|
||||
d="m 313.43096,177.76524 50.93253,-51.91201"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.2;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
d="m 474.66125,581.70506 50.93253,-51.91201"
|
||||
id="path10905"
|
||||
inkscape:connector-curvature="0"
|
||||
transform="translate(161.72003,403.93982)" />
|
||||
inkscape:connector-curvature="0" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
style="font-size:16px;font-style:normal;font-weight:bold;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Sans;-inkscape-font-specification:Sans Bold"
|
||||
|
Before Width: | Height: | Size: 54 KiB After Width: | Height: | Size: 56 KiB |
@@ -14,9 +14,48 @@
|
||||
id="svg17088"
|
||||
version="1.1"
|
||||
inkscape:version="0.48.4 r9939"
|
||||
sodipodi:docname="New document 66">
|
||||
sodipodi:docname="operations_image053.svg">
|
||||
<defs
|
||||
id="defs17090">
|
||||
<marker
|
||||
inkscape:stockid="Arrow1Lstart"
|
||||
orient="auto"
|
||||
refY="0.0"
|
||||
refX="0.0"
|
||||
id="Arrow1Lstart"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
id="path4823"
|
||||
d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "
|
||||
style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt"
|
||||
transform="scale(0.8) translate(12.5,0)" />
|
||||
</marker>
|
||||
<marker
|
||||
inkscape:stockid="Arrow2Lstart"
|
||||
orient="auto"
|
||||
refY="0.0"
|
||||
refX="0.0"
|
||||
id="Arrow2Lstart"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
id="path4841"
|
||||
style="fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round"
|
||||
d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
|
||||
transform="scale(1.1) translate(1,0)" />
|
||||
</marker>
|
||||
<marker
|
||||
inkscape:stockid="Arrow2Lend"
|
||||
orient="auto"
|
||||
refY="0.0"
|
||||
refX="0.0"
|
||||
id="Arrow2Lend"
|
||||
style="overflow:visible;">
|
||||
<path
|
||||
id="path4844"
|
||||
style="fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round;"
|
||||
d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
|
||||
transform="scale(1.1) rotate(180) translate(1,0)" />
|
||||
</marker>
|
||||
<clipPath
|
||||
id="clipEmfPath1"
|
||||
clipPathUnits="userSpaceOnUse">
|
||||
@@ -115,20 +154,20 @@
|
||||
borderopacity="1.0"
|
||||
inkscape:pageopacity="0.0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:zoom="0.35"
|
||||
inkscape:cx="570.39168"
|
||||
inkscape:cy="-65.896639"
|
||||
inkscape:zoom="1.979899"
|
||||
inkscape:cx="169.61988"
|
||||
inkscape:cy="105.53193"
|
||||
inkscape:document-units="px"
|
||||
inkscape:current-layer="layer1"
|
||||
inkscape:current-layer="g17127"
|
||||
showgrid="false"
|
||||
fit-margin-top="0"
|
||||
fit-margin-left="0"
|
||||
fit-margin-right="0"
|
||||
fit-margin-bottom="0"
|
||||
inkscape:window-width="467"
|
||||
inkscape:window-height="424"
|
||||
inkscape:window-x="22"
|
||||
inkscape:window-y="22"
|
||||
inkscape:window-width="1507"
|
||||
inkscape:window-height="597"
|
||||
inkscape:window-x="133"
|
||||
inkscape:window-y="130"
|
||||
inkscape:window-maximized="0" />
|
||||
<metadata
|
||||
id="metadata17093">
|
||||
@@ -138,7 +177,7 @@
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
<dc:title></dc:title>
|
||||
<dc:title />
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
@@ -150,6 +189,296 @@
|
||||
<g
|
||||
id="g17127"
|
||||
transform="translate(-195.54166,347.00012)">
|
||||
<path
|
||||
id="path17259"
|
||||
d="m 412.72388,50.112479 -4.18067,-1.005665 31.81433,-32.200256 4.19941,1.005665 z"
|
||||
style="fill:#7f7f7f;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17263"
|
||||
d="m 408.54321,49.106814 -4.3119,-0.929766 31.83307,-32.200256 4.29316,0.929766 z"
|
||||
style="fill:#7e7e7e;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17265"
|
||||
d="M 408.54321,49.106814 440.35754,16.906558"
|
||||
style="fill:none;stroke:#7e7e7e;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17251"
|
||||
d="m 420.80401,52.199708 -3.9932,-1.062589 31.81433,-32.200256 3.99319,1.062589 z"
|
||||
style="fill:#808080;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17261"
|
||||
d="M 412.72388,50.112479 444.55695,17.912223"
|
||||
style="fill:none;stroke:#7f7f7f;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17253"
|
||||
d="M 420.80401,52.199708 452.61833,19.999452"
|
||||
style="fill:none;stroke:#808080;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17255"
|
||||
d="m 416.81081,51.137119 -4.08693,-1.02464 31.83307,-32.200256 4.06819,1.02464 z"
|
||||
style="fill:#808080;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17243"
|
||||
d="m 428.56543,54.305912 -3.84322,-1.043614 31.81433,-32.200256 3.84321,1.043614 z"
|
||||
style="fill:#808080;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17247"
|
||||
d="m 424.72221,53.262298 -3.9182,-1.06259 31.81432,-32.200256 3.91821,1.06259 z"
|
||||
style="fill:#808080;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17231"
|
||||
d="m 439.83261,57.190084 -3.73073,-0.891816 31.81433,-32.219231 3.73073,0.910791 z"
|
||||
style="fill:#7f7f7f;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17235"
|
||||
d="m 436.10188,56.298268 -3.74948,-0.967716 31.81433,-32.200256 3.74948,0.948741 z"
|
||||
style="fill:#808080;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17239"
|
||||
d="m 432.3524,55.330552 -3.78697,-1.02464 31.81432,-32.200256 3.78698,1.02464 z"
|
||||
style="fill:#808080;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17237"
|
||||
d="M 436.10188,56.298268 467.91621,24.079037"
|
||||
style="fill:none;stroke:#808080;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17223"
|
||||
d="m 447.23783,58.708069 -3.69324,-0.702068 31.81433,-32.200256 3.69324,0.702068 z"
|
||||
style="fill:#7c7c7c;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17227"
|
||||
d="m 443.54459,58.006001 -3.71198,-0.815917 31.81433,-32.200256 3.71198,0.815917 z"
|
||||
style="fill:#7e7e7e;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17225"
|
||||
d="M 447.23783,58.708069 479.05216,26.507813"
|
||||
style="fill:none;stroke:#7c7c7c;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17233"
|
||||
d="M 439.83261,57.190084 471.64694,24.989828"
|
||||
style="fill:none;stroke:#7f7f7f;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17211"
|
||||
d="m 458.46752,60.055281 -3.76823,-0.303597 31.81433,-32.200257 3.76823,0.303597 z"
|
||||
style="fill:#767676;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17229"
|
||||
d="M 443.54459,58.006001 475.35892,25.805745"
|
||||
style="fill:none;stroke:#7e7e7e;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17219"
|
||||
d="m 450.94982,59.296288 -3.71199,-0.588219 31.81433,-32.200256 3.71198,0.588219 z"
|
||||
style="fill:#7b7b7b;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17215"
|
||||
d="m 454.69929,59.751684 -3.74947,-0.455396 31.81432,-32.200256 3.74948,0.455395 z"
|
||||
style="fill:#797979;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17257"
|
||||
d="M 416.81081,51.137119 448.62514,18.936863"
|
||||
style="fill:none;stroke:#808080;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17249"
|
||||
d="M 424.72221,53.262298 456.53654,21.062042"
|
||||
style="fill:none;stroke:#808080;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17241"
|
||||
d="M 432.3524,55.330552 464.16673,23.130296"
|
||||
style="fill:none;stroke:#808080;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17221"
|
||||
d="M 450.94982,59.296288 482.76414,27.096032"
|
||||
style="fill:none;stroke:#7b7b7b;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17217"
|
||||
d="M 454.69929,59.751684 486.51362,27.551427"
|
||||
style="fill:none;stroke:#797979;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17203"
|
||||
d="m 466.1727,60.169129 -3.86196,0.03795 31.81432,-32.219231 3.86197,-0.01898 z"
|
||||
style="fill:#727272;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17191"
|
||||
d="m 477.75859,59.353213 -3.86196,0.398471 31.83307,-32.200257 3.84322,-0.398471 z"
|
||||
style="fill:#787878;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17195"
|
||||
d="m 473.89663,59.751684 -3.86197,0.265647 31.81433,-32.200256 3.88071,-0.265648 z"
|
||||
style="fill:#767676;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17205"
|
||||
d="M 466.1727,60.169129 497.98703,27.968873"
|
||||
style="fill:none;stroke:#727272;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17213"
|
||||
d="M 458.46752,60.055281 490.28185,27.855024"
|
||||
style="fill:none;stroke:#767676;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17207"
|
||||
d="m 462.31074,60.207079 -3.84322,-0.151798 31.81433,-32.200257 3.84321,0.132824 z"
|
||||
style="fill:#747474;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17197"
|
||||
d="M 473.89663,59.751684 505.7297,27.551427"
|
||||
style="fill:none;stroke:#767676;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17199"
|
||||
d="m 470.03466,60.017331 -3.86196,0.151798 31.81433,-32.200256 3.86196,-0.151798 z"
|
||||
style="fill:#747474;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17167"
|
||||
d="m 500.98661,55.064905 -3.88071,0.910791 31.81433,-32.200256 3.88071,-0.910791 z"
|
||||
style="fill:#7e7e7e;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17169"
|
||||
d="M 500.98661,55.064905 532.80094,22.864649"
|
||||
style="fill:none;stroke:#7e7e7e;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17171"
|
||||
d="m 497.1059,55.975696 -3.86196,0.815917 31.81432,-32.200256 3.86197,-0.815917 z"
|
||||
style="fill:#7e7e7e;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17173"
|
||||
d="M 497.1059,55.975696 528.92023,23.77544"
|
||||
style="fill:none;stroke:#7e7e7e;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17175"
|
||||
d="m 493.24394,56.791613 -3.88071,0.777967 31.81432,-32.200256 3.88071,-0.777967 z"
|
||||
style="fill:#7d7d7d;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17177"
|
||||
d="M 493.24394,56.791613 525.05826,24.591357"
|
||||
style="fill:none;stroke:#7d7d7d;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17179"
|
||||
d="m 489.36323,57.56958 -3.86197,0.683093 31.81433,-32.200256 3.86196,-0.683093 z"
|
||||
style="fill:#7c7c7c;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17183"
|
||||
d="m 485.50126,58.252673 -3.86196,0.58822 31.81433,-32.200257 3.86196,-0.588219 z"
|
||||
style="fill:#7a7a7a;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17185"
|
||||
d="M 485.50126,58.252673 517.31559,26.052417"
|
||||
style="fill:none;stroke:#7a7a7a;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17187"
|
||||
d="m 481.6393,58.840893 -3.88071,0.51232 31.81433,-32.200257 3.88071,-0.51232 z"
|
||||
style="fill:#797979;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17153"
|
||||
d="M 524.75831,50.681723 556.57263,18.481467"
|
||||
style="fill:none;stroke:#a7a7a7;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17155"
|
||||
d="M 524.27087,48.841167 516.4907,51.02327 548.30503,18.823014 556.0852,16.64091 z"
|
||||
style="fill:#818181;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17201"
|
||||
d="M 470.03466,60.017331 501.84899,27.817075"
|
||||
style="fill:none;stroke:#747474;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17245"
|
||||
d="M 428.56543,54.305912 460.37975,22.105656"
|
||||
style="fill:none;stroke:#808080;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17181"
|
||||
d="M 489.36323,57.56958 521.17755,25.369324"
|
||||
style="fill:none;stroke:#7c7c7c;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17193"
|
||||
d="M 477.75859,59.353213 509.57292,27.152956"
|
||||
style="fill:none;stroke:#787878;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17157"
|
||||
d="M 524.27087,48.841167 556.0852,16.64091"
|
||||
style="fill:none;stroke:#818181;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17159"
|
||||
d="m 516.4907,51.02327 -7.76142,2.087229 31.81433,-32.200256 7.76142,-2.087229 z"
|
||||
style="fill:#808080;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17161"
|
||||
d="M 516.4907,51.02327 548.30503,18.823014"
|
||||
style="fill:none;stroke:#808080;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17163"
|
||||
d="m 508.72928,53.110499 -7.74267,1.954406 31.81433,-32.200256 7.74267,-1.954406 z"
|
||||
style="fill:#7f7f7f;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17165"
|
||||
d="M 508.72928,53.110499 540.54361,20.910243"
|
||||
style="fill:none;stroke:#7f7f7f;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17189"
|
||||
d="M 481.6393,58.840893 513.45363,26.640636"
|
||||
style="fill:none;stroke:#797979;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17209"
|
||||
d="M 462.31074,60.207079 494.12506,27.987848"
|
||||
style="fill:none;stroke:#747474;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17861"
|
||||
d="m 481.6393,58.840893 -3.88071,0.51232"
|
||||
style="fill:none;stroke:#858585;stroke-width:1.19983327px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<text
|
||||
id="text17129"
|
||||
style="font-size:13.79808235px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Calibri"
|
||||
@@ -212,291 +541,6 @@
|
||||
d="m 524.75831,50.681723 -0.48744,-1.840556 31.81433,-32.200257 0.48743,1.840557 z"
|
||||
style="fill:#a7a7a7;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17153"
|
||||
d="M 524.75831,50.681723 556.57263,18.481467"
|
||||
style="fill:none;stroke:#a7a7a7;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17155"
|
||||
d="M 524.27087,48.841167 516.4907,51.02327 548.30503,18.823014 556.0852,16.64091 z"
|
||||
style="fill:#818181;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17157"
|
||||
d="M 524.27087,48.841167 556.0852,16.64091"
|
||||
style="fill:none;stroke:#818181;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17159"
|
||||
d="m 516.4907,51.02327 -7.76142,2.087229 31.81433,-32.200256 7.76142,-2.087229 z"
|
||||
style="fill:#808080;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17161"
|
||||
d="M 516.4907,51.02327 548.30503,18.823014"
|
||||
style="fill:none;stroke:#808080;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17163"
|
||||
d="m 508.72928,53.110499 -7.74267,1.954406 31.81433,-32.200256 7.74267,-1.954406 z"
|
||||
style="fill:#7f7f7f;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17165"
|
||||
d="M 508.72928,53.110499 540.54361,20.910243"
|
||||
style="fill:none;stroke:#7f7f7f;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17167"
|
||||
d="m 500.98661,55.064905 -3.88071,0.910791 31.81433,-32.200256 3.88071,-0.910791 z"
|
||||
style="fill:#7e7e7e;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17169"
|
||||
d="M 500.98661,55.064905 532.80094,22.864649"
|
||||
style="fill:none;stroke:#7e7e7e;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17171"
|
||||
d="m 497.1059,55.975696 -3.86196,0.815917 31.81432,-32.200256 3.86197,-0.815917 z"
|
||||
style="fill:#7e7e7e;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17173"
|
||||
d="M 497.1059,55.975696 528.92023,23.77544"
|
||||
style="fill:none;stroke:#7e7e7e;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17175"
|
||||
d="m 493.24394,56.791613 -3.88071,0.777967 31.81432,-32.200256 3.88071,-0.777967 z"
|
||||
style="fill:#7d7d7d;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17177"
|
||||
d="M 493.24394,56.791613 525.05826,24.591357"
|
||||
style="fill:none;stroke:#7d7d7d;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17179"
|
||||
d="m 489.36323,57.56958 -3.86197,0.683093 31.81433,-32.200256 3.86196,-0.683093 z"
|
||||
style="fill:#7c7c7c;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17181"
|
||||
d="M 489.36323,57.56958 521.17755,25.369324"
|
||||
style="fill:none;stroke:#7c7c7c;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17183"
|
||||
d="m 485.50126,58.252673 -3.86196,0.58822 31.81433,-32.200257 3.86196,-0.588219 z"
|
||||
style="fill:#7a7a7a;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17185"
|
||||
d="M 485.50126,58.252673 517.31559,26.052417"
|
||||
style="fill:none;stroke:#7a7a7a;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17187"
|
||||
d="m 481.6393,58.840893 -3.88071,0.51232 31.81433,-32.200257 3.88071,-0.51232 z"
|
||||
style="fill:#797979;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17189"
|
||||
d="M 481.6393,58.840893 513.45363,26.640636"
|
||||
style="fill:none;stroke:#797979;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17191"
|
||||
d="m 477.75859,59.353213 -3.86196,0.398471 31.83307,-32.200257 3.84322,-0.398471 z"
|
||||
style="fill:#787878;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17193"
|
||||
d="M 477.75859,59.353213 509.57292,27.152956"
|
||||
style="fill:none;stroke:#787878;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17195"
|
||||
d="m 473.89663,59.751684 -3.86197,0.265647 31.81433,-32.200256 3.88071,-0.265648 z"
|
||||
style="fill:#767676;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17197"
|
||||
d="M 473.89663,59.751684 505.7297,27.551427"
|
||||
style="fill:none;stroke:#767676;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17199"
|
||||
d="m 470.03466,60.017331 -3.86196,0.151798 31.81433,-32.200256 3.86196,-0.151798 z"
|
||||
style="fill:#747474;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17201"
|
||||
d="M 470.03466,60.017331 501.84899,27.817075"
|
||||
style="fill:none;stroke:#747474;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17203"
|
||||
d="m 466.1727,60.169129 -3.86196,0.03795 31.81432,-32.219231 3.86197,-0.01898 z"
|
||||
style="fill:#727272;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17205"
|
||||
d="M 466.1727,60.169129 497.98703,27.968873"
|
||||
style="fill:none;stroke:#727272;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17207"
|
||||
d="m 462.31074,60.207079 -3.84322,-0.151798 31.81433,-32.200257 3.84321,0.132824 z"
|
||||
style="fill:#747474;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17209"
|
||||
d="M 462.31074,60.207079 494.12506,27.987848"
|
||||
style="fill:none;stroke:#747474;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17211"
|
||||
d="m 458.46752,60.055281 -3.76823,-0.303597 31.81433,-32.200257 3.76823,0.303597 z"
|
||||
style="fill:#767676;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17213"
|
||||
d="M 458.46752,60.055281 490.28185,27.855024"
|
||||
style="fill:none;stroke:#767676;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17215"
|
||||
d="m 454.69929,59.751684 -3.74947,-0.455396 31.81432,-32.200256 3.74948,0.455395 z"
|
||||
style="fill:#797979;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17217"
|
||||
d="M 454.69929,59.751684 486.51362,27.551427"
|
||||
style="fill:none;stroke:#797979;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17219"
|
||||
d="m 450.94982,59.296288 -3.71199,-0.588219 31.81433,-32.200256 3.71198,0.588219 z"
|
||||
style="fill:#7b7b7b;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17221"
|
||||
d="M 450.94982,59.296288 482.76414,27.096032"
|
||||
style="fill:none;stroke:#7b7b7b;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17223"
|
||||
d="m 447.23783,58.708069 -3.69324,-0.702068 31.81433,-32.200256 3.69324,0.702068 z"
|
||||
style="fill:#7c7c7c;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17225"
|
||||
d="M 447.23783,58.708069 479.05216,26.507813"
|
||||
style="fill:none;stroke:#7c7c7c;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17227"
|
||||
d="m 443.54459,58.006001 -3.71198,-0.815917 31.81433,-32.200256 3.71198,0.815917 z"
|
||||
style="fill:#7e7e7e;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17229"
|
||||
d="M 443.54459,58.006001 475.35892,25.805745"
|
||||
style="fill:none;stroke:#7e7e7e;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17231"
|
||||
d="m 439.83261,57.190084 -3.73073,-0.891816 31.81433,-32.219231 3.73073,0.910791 z"
|
||||
style="fill:#7f7f7f;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17233"
|
||||
d="M 439.83261,57.190084 471.64694,24.989828"
|
||||
style="fill:none;stroke:#7f7f7f;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17235"
|
||||
d="m 436.10188,56.298268 -3.74948,-0.967716 31.81433,-32.200256 3.74948,0.948741 z"
|
||||
style="fill:#808080;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17237"
|
||||
d="M 436.10188,56.298268 467.91621,24.079037"
|
||||
style="fill:none;stroke:#808080;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17239"
|
||||
d="m 432.3524,55.330552 -3.78697,-1.02464 31.81432,-32.200256 3.78698,1.02464 z"
|
||||
style="fill:#808080;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17241"
|
||||
d="M 432.3524,55.330552 464.16673,23.130296"
|
||||
style="fill:none;stroke:#808080;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17243"
|
||||
d="m 428.56543,54.305912 -3.84322,-1.043614 31.81433,-32.200256 3.84321,1.043614 z"
|
||||
style="fill:#808080;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17245"
|
||||
d="M 428.56543,54.305912 460.37975,22.105656"
|
||||
style="fill:none;stroke:#808080;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17247"
|
||||
d="m 424.72221,53.262298 -3.9182,-1.06259 31.81432,-32.200256 3.91821,1.06259 z"
|
||||
style="fill:#808080;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17249"
|
||||
d="M 424.72221,53.262298 456.53654,21.062042"
|
||||
style="fill:none;stroke:#808080;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17251"
|
||||
d="m 420.80401,52.199708 -3.9932,-1.062589 31.81433,-32.200256 3.99319,1.062589 z"
|
||||
style="fill:#808080;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17253"
|
||||
d="M 420.80401,52.199708 452.61833,19.999452"
|
||||
style="fill:none;stroke:#808080;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17255"
|
||||
d="m 416.81081,51.137119 -4.08693,-1.02464 31.83307,-32.200256 4.06819,1.02464 z"
|
||||
style="fill:#808080;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17257"
|
||||
d="M 416.81081,51.137119 448.62514,18.936863"
|
||||
style="fill:none;stroke:#808080;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17259"
|
||||
d="m 412.72388,50.112479 -4.18067,-1.005665 31.81433,-32.200256 4.19941,1.005665 z"
|
||||
style="fill:#7f7f7f;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17261"
|
||||
d="M 412.72388,50.112479 444.55695,17.912223"
|
||||
style="fill:none;stroke:#7f7f7f;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17263"
|
||||
d="m 408.54321,49.106814 -4.3119,-0.929766 31.83307,-32.200256 4.29316,0.929766 z"
|
||||
style="fill:#7e7e7e;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17265"
|
||||
d="M 408.54321,49.106814 440.35754,16.906558"
|
||||
style="fill:none;stroke:#7e7e7e;stroke-width:0.14997916px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17267"
|
||||
d="m 404.23131,48.177048 -4.40564,-0.872841 31.81433,-32.200256 4.42438,0.872841 z"
|
||||
@@ -1982,11 +2026,6 @@
|
||||
d="m 485.50126,58.252673 -3.86196,0.58822"
|
||||
style="fill:none;stroke:#848484;stroke-width:1.19983327px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17861"
|
||||
d="m 481.6393,58.840893 -3.88071,0.51232"
|
||||
style="fill:none;stroke:#858585;stroke-width:1.19983327px;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path17863"
|
||||
d="m 477.75859,59.353213 -3.86196,0.398471"
|
||||
@@ -2582,7 +2621,7 @@
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path18097"
|
||||
d="m 193.42624,106.17356 61.8664,0"
|
||||
d="m 193.42624,104.74499 61.8664,0"
|
||||
style="fill:none;stroke:#000000;stroke-width:0.9373697px;stroke-linecap:round;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<text
|
||||
@@ -2605,33 +2644,15 @@
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path18105"
|
||||
d="m 192.30139,48.869629 0.7499,42.124083"
|
||||
style="fill:none;stroke:#000000;stroke-width:0.9373697px;stroke-linecap:round;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none"
|
||||
d="m 193.02046,61.017268 0.74034,43.543092"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.047;stroke-linecap:round;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none;marker-end:none;marker-start:url(#Arrow2Lstart);stroke-miterlimit:4"
|
||||
inkscape:connector-curvature="0" />
|
||||
<text
|
||||
id="text18107"
|
||||
style="font-size:13.79808235px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#0000ff;font-family:Calibri"
|
||||
y="37.949623"
|
||||
x="464.48544"
|
||||
xml:space="preserve">S</text>
|
||||
<text
|
||||
id="text18109"
|
||||
style="font-size:8.69879055px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#0000ff;font-family:Calibri"
|
||||
y="39.923004"
|
||||
x="470.93454"
|
||||
xml:space="preserve">2</text>
|
||||
<text
|
||||
id="text18111"
|
||||
style="font-size:13.79808235px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#0000ff;font-family:Calibri"
|
||||
y="37.949623"
|
||||
x="475.4339"
|
||||
xml:space="preserve"> </text>
|
||||
<path
|
||||
id="path18113"
|
||||
d="m 402.28158,50.776597 122.28925,0 35.93876,-34.534158 -121.87681,0 -36.3512,34.534158 z"
|
||||
clip-path="url(#clipEmfPath4)"
|
||||
style="fill:#0000ff;fill-opacity:1;fill-rule:evenodd;stroke:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<text
|
||||
id="text18115"
|
||||
style="font-size:13.79808235px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Calibri"
|
||||
@@ -2728,6 +2749,16 @@
|
||||
y="69.827309"
|
||||
x="531.82605"
|
||||
xml:space="preserve"> </text>
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#Arrow2Lstart)"
|
||||
d="m 192.29284,47.322566 c 1.42857,-42.1428568 0.71428,-42.1428568 0.71428,-42.1428568 -1.42857,0 -1.42857,0 -1.42857,0"
|
||||
id="path5813"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path18079-1"
|
||||
d="M 522.05801,51.692484 558.24195,15.809788"
|
||||
style="fill:none;stroke:#ff0000;stroke-width:1.87473941px;stroke-linecap:butt;stroke-linejoin:round;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
Before Width: | Height: | Size: 152 KiB After Width: | Height: | Size: 153 KiB |
Before Width: | Height: | Size: 157 KiB |
Before Width: | Height: | Size: 63 KiB |
After Width: | Height: | Size: 14 KiB |
After Width: | Height: | Size: 13 KiB |
After Width: | Height: | Size: 13 KiB |
After Width: | Height: | Size: 14 KiB |
@@ -10,38 +10,40 @@
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
width="500.70731"
|
||||
height="148.97501"
|
||||
height="102.98"
|
||||
id="svg3731"
|
||||
version="1.1"
|
||||
inkscape:version="0.48.4 r9939"
|
||||
sodipodi:docname="operations_image057.svg">
|
||||
sodipodi:docname="operations_image064.svg">
|
||||
<defs
|
||||
id="defs3733">
|
||||
<marker
|
||||
inkscape:stockid="Arrow2Mstart"
|
||||
orient="auto"
|
||||
refY="0.0"
|
||||
refX="0.0"
|
||||
refY="0"
|
||||
refX="0"
|
||||
id="Arrow2Mstart"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
id="path4673"
|
||||
style="fill-rule:evenodd;stroke-width:0.62500000;stroke-linejoin:round"
|
||||
d="M 8.7185878,4.0337352 L -2.2072895,0.016013256 L 8.7185884,-4.0017078 C 6.9730900,-1.6296469 6.9831476,1.6157441 8.7185878,4.0337352 z "
|
||||
transform="scale(0.6) translate(0,0)" />
|
||||
style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
|
||||
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||
transform="scale(0.6,0.6)"
|
||||
inkscape:connector-curvature="0" />
|
||||
</marker>
|
||||
<marker
|
||||
inkscape:stockid="Arrow1Lstart"
|
||||
orient="auto"
|
||||
refY="0.0"
|
||||
refX="0.0"
|
||||
refY="0"
|
||||
refX="0"
|
||||
id="Arrow1Lstart"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
id="path4649"
|
||||
d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "
|
||||
style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt"
|
||||
transform="scale(0.8) translate(12.5,0)" />
|
||||
d="M 0,0 5,-5 -12.5,0 5,5 0,0 z"
|
||||
style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt"
|
||||
transform="matrix(0.8,0,0,0.8,10,0)"
|
||||
inkscape:connector-curvature="0" />
|
||||
</marker>
|
||||
<clipPath
|
||||
id="clipEmfPath1"
|
||||
@@ -113,8 +115,8 @@
|
||||
fit-margin-bottom="0"
|
||||
inkscape:window-width="1037"
|
||||
inkscape:window-height="615"
|
||||
inkscape:window-x="198"
|
||||
inkscape:window-y="198"
|
||||
inkscape:window-x="38"
|
||||
inkscape:window-y="209"
|
||||
inkscape:window-maximized="0" />
|
||||
<metadata
|
||||
id="metadata3736">
|
||||
@@ -124,7 +126,7 @@
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
<dc:title></dc:title>
|
||||
<dc:title />
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
@@ -132,7 +134,7 @@
|
||||
inkscape:label="Layer 1"
|
||||
inkscape:groupmode="layer"
|
||||
id="layer1"
|
||||
transform="translate(204.63937,-349.30482)">
|
||||
transform="translate(204.63937,-395.29983)">
|
||||
<g
|
||||
id="g3758"
|
||||
transform="translate(-262.09021,339.42982)">
|
||||
@@ -147,12 +149,13 @@
|
||||
d="m 214.87814,10.5 0,23.4375 135.43322,0 0,-23.4375 z"
|
||||
clip-path="url(#clipEmfPath1)"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.25626838px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
inkscape:connector-curvature="0"
|
||||
transform="translate(-1.4412873,56.78124)" />
|
||||
<text
|
||||
id="text3764"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
y="25.049999"
|
||||
x="237.60347"
|
||||
y="80.110596"
|
||||
x="236.44154"
|
||||
xml:space="preserve">BOPAlgo_Algo</text>
|
||||
<text
|
||||
id="text3766"
|
||||
@@ -166,12 +169,6 @@
|
||||
clip-path="url(#clipEmfPath2)"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.24689317px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<text
|
||||
id="text3770"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
y="128.85001"
|
||||
x="62.100906"
|
||||
xml:space="preserve">BOPAlgo_BuilderFace</text>
|
||||
<text
|
||||
id="text3772"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
@@ -192,15 +189,15 @@
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path3778"
|
||||
d="m 184.42769,64.6125 0,23.4375 191.2528,0 0,-23.4375 z"
|
||||
d="m 185.00124,121.96729 0,23.4375 191.2528,0 0,-23.4375 z"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.25626838px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<text
|
||||
id="text3780"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
y="79.199997"
|
||||
x="208.80305"
|
||||
xml:space="preserve">BOPAlgo_BuilderArea</text>
|
||||
y="135.98123"
|
||||
x="213.3766"
|
||||
xml:space="preserve">BOPAlgo_PaveFiller</text>
|
||||
<text
|
||||
id="text3782"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
@@ -219,22 +216,6 @@
|
||||
clip-path="url(#clipEmfPath4)"
|
||||
style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.1500022px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path3788"
|
||||
d="M 328.51115,113.3491 313.4858,93.159778 c -0.20034,-0.263568 -0.12749,-0.632564 0.12749,-0.825847 0.27318,-0.193283 0.65565,-0.122998 0.85598,0.14057 l 15.04358,20.189319 c 0.18212,0.26357 0.12749,0.63257 -0.1457,0.82585 -0.27319,0.17571 -0.65565,0.123 -0.856,-0.14057 z m -16.79197,-17.536069 -1.29309,-7.766476 7.21217,3.672384 z"
|
||||
style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.14311314px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path3790"
|
||||
d="m 314.55459,113.925 0,22.3875 181.50265,0 0,-22.3875 z"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.25626838px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<text
|
||||
id="text3792"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
y="128.55"
|
||||
x="330.30481"
|
||||
xml:space="preserve">BOPAlgo_BuilderSolid</text>
|
||||
<text
|
||||
id="text3794"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
@@ -247,22 +228,11 @@
|
||||
y="158.39999"
|
||||
x="318.75464"
|
||||
xml:space="preserve"> </text>
|
||||
<path
|
||||
id="path3778-1"
|
||||
d="m 59.826945,114.93839 0,23.58586 147.811525,0 0,-23.58586 z"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.10790598px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path3788-7"
|
||||
d="m 188.47884,114.85983 15.27723,-21.996553 c 0.20368,-0.287169 0.12962,-0.689183 -0.12963,-0.899777 -0.27777,-0.210571 -0.66664,-0.134008 -0.87033,0.153161 l -15.29576,21.996549 c -0.18517,0.28716 -0.12962,0.68918 0.14815,0.89977 0.27777,0.19144 0.66664,0.134 0.87034,-0.15315 z m 17.07345,-19.105793 1.31477,-8.461686 -7.33307,4.001108 z"
|
||||
style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.15062799px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
style="fill:#916f6f;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#Arrow2Mstart)"
|
||||
d="m 224.83077,23.941568 0,30.398037"
|
||||
d="m 281.70806,91.744904 0,30.398036"
|
||||
id="path3875"
|
||||
inkscape:connector-curvature="0"
|
||||
transform="translate(57.45084,9.875)" />
|
||||
inkscape:connector-curvature="0" />
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 8.9 KiB |
@@ -0,0 +1,407 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
|
||||
<svg
|
||||
xmlns:dc="http://purl.org/dc/elements/1.1/"
|
||||
xmlns:cc="http://creativecommons.org/ns#"
|
||||
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
|
||||
xmlns:svg="http://www.w3.org/2000/svg"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
width="500.70731"
|
||||
height="257.98001"
|
||||
id="svg3731"
|
||||
version="1.1"
|
||||
inkscape:version="0.48.4 r9939"
|
||||
sodipodi:docname="operations_image059.svg">
|
||||
<defs
|
||||
id="defs3733">
|
||||
<marker
|
||||
inkscape:stockid="Arrow2Mstart"
|
||||
orient="auto"
|
||||
refY="0"
|
||||
refX="0"
|
||||
id="Arrow2Mstart"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
id="path4673"
|
||||
style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
|
||||
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||
transform="scale(0.6,0.6)"
|
||||
inkscape:connector-curvature="0" />
|
||||
</marker>
|
||||
<marker
|
||||
inkscape:stockid="Arrow1Lstart"
|
||||
orient="auto"
|
||||
refY="0"
|
||||
refX="0"
|
||||
id="Arrow1Lstart"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
id="path4649"
|
||||
d="M 0,0 5,-5 -12.5,0 5,5 0,0 z"
|
||||
style="fill-rule:evenodd;stroke:#000000;stroke-width:1pt"
|
||||
transform="matrix(0.8,0,0,0.8,10,0)"
|
||||
inkscape:connector-curvature="0" />
|
||||
</marker>
|
||||
<clipPath
|
||||
id="clipEmfPath1"
|
||||
clipPathUnits="userSpaceOnUse">
|
||||
<rect
|
||||
id="rect3744"
|
||||
height="157.5"
|
||||
width="566.85828"
|
||||
y="0"
|
||||
x="0" />
|
||||
</clipPath>
|
||||
<clipPath
|
||||
id="clipEmfPath2"
|
||||
clipPathUnits="userSpaceOnUse">
|
||||
<rect
|
||||
id="rect3747"
|
||||
height="15"
|
||||
width="134.10196"
|
||||
y="14.7"
|
||||
x="215.55315" />
|
||||
</clipPath>
|
||||
<clipPath
|
||||
id="clipEmfPath3"
|
||||
clipPathUnits="userSpaceOnUse">
|
||||
<rect
|
||||
id="rect3750"
|
||||
height="13.95"
|
||||
width="158.85233"
|
||||
y="118.5"
|
||||
x="53.850784" />
|
||||
</clipPath>
|
||||
<clipPath
|
||||
id="clipEmfPath4"
|
||||
clipPathUnits="userSpaceOnUse">
|
||||
<rect
|
||||
id="rect3753"
|
||||
height="15"
|
||||
width="189.90277"
|
||||
y="68.849998"
|
||||
x="185.10271" />
|
||||
</clipPath>
|
||||
<clipPath
|
||||
id="clipEmfPath5"
|
||||
clipPathUnits="userSpaceOnUse">
|
||||
<rect
|
||||
id="rect3756"
|
||||
height="13.95"
|
||||
width="180.15263"
|
||||
y="118.2"
|
||||
x="315.3046" />
|
||||
</clipPath>
|
||||
<marker
|
||||
inkscape:stockid="Arrow2Mstart"
|
||||
orient="auto"
|
||||
refY="0"
|
||||
refX="0"
|
||||
id="Arrow2Mstart-1"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
id="path4673-7"
|
||||
style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
|
||||
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||
transform="scale(0.6,0.6)"
|
||||
inkscape:connector-curvature="0" />
|
||||
</marker>
|
||||
<clipPath
|
||||
id="clipEmfPath1-0"
|
||||
clipPathUnits="userSpaceOnUse">
|
||||
<rect
|
||||
id="rect3744-9"
|
||||
height="157.5"
|
||||
width="566.85828"
|
||||
y="0"
|
||||
x="0" />
|
||||
</clipPath>
|
||||
<marker
|
||||
inkscape:stockid="Arrow2Mstart"
|
||||
orient="auto"
|
||||
refY="0"
|
||||
refX="0"
|
||||
id="Arrow2Mstart-7"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
id="path4673-1"
|
||||
style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
|
||||
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||
transform="scale(0.6,0.6)"
|
||||
inkscape:connector-curvature="0" />
|
||||
</marker>
|
||||
<marker
|
||||
inkscape:stockid="Arrow2Mstart"
|
||||
orient="auto"
|
||||
refY="0"
|
||||
refX="0"
|
||||
id="Arrow2Mstart-2"
|
||||
style="overflow:visible">
|
||||
<path
|
||||
id="path4673-76"
|
||||
style="fill-rule:evenodd;stroke-width:0.625;stroke-linejoin:round"
|
||||
d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
|
||||
transform="scale(0.6,0.6)"
|
||||
inkscape:connector-curvature="0" />
|
||||
</marker>
|
||||
<clipPath
|
||||
id="clipEmfPath1-4"
|
||||
clipPathUnits="userSpaceOnUse">
|
||||
<rect
|
||||
id="rect3744-2"
|
||||
height="157.5"
|
||||
width="566.85828"
|
||||
y="0"
|
||||
x="0" />
|
||||
</clipPath>
|
||||
</defs>
|
||||
<sodipodi:namedview
|
||||
id="base"
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1.0"
|
||||
inkscape:pageopacity="0.0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:zoom="1.7435336"
|
||||
inkscape:cx="250.35365"
|
||||
inkscape:cy="166.25673"
|
||||
inkscape:document-units="px"
|
||||
inkscape:current-layer="g3758"
|
||||
showgrid="false"
|
||||
fit-margin-top="0"
|
||||
fit-margin-left="0"
|
||||
fit-margin-right="0"
|
||||
fit-margin-bottom="0"
|
||||
inkscape:window-width="1195"
|
||||
inkscape:window-height="615"
|
||||
inkscape:window-x="10"
|
||||
inkscape:window-y="129"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:snap-bbox="false"
|
||||
inkscape:bbox-nodes="false"
|
||||
inkscape:snap-nodes="false"
|
||||
inkscape:snap-global="true" />
|
||||
<metadata
|
||||
id="metadata3736">
|
||||
<rdf:RDF>
|
||||
<cc:Work
|
||||
rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type
|
||||
rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
|
||||
<dc:title></dc:title>
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<g
|
||||
inkscape:label="Layer 1"
|
||||
inkscape:groupmode="layer"
|
||||
id="layer1"
|
||||
transform="translate(204.63937,-240.29985)">
|
||||
<g
|
||||
id="g3758"
|
||||
transform="translate(-261.51666,329.10596)">
|
||||
<text
|
||||
id="text3760"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Arial"
|
||||
y="142.64999"
|
||||
x="558.15814"
|
||||
xml:space="preserve"> </text>
|
||||
<path
|
||||
id="path3762"
|
||||
d="m 214.87814,10.5 0,23.4375 135.43322,0 0,-23.4375 z"
|
||||
clip-path="url(#clipEmfPath1)"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.25626838px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0"
|
||||
transform="matrix(1.8268958,0,0,0.9818143,-213.2932,-1.3165801)" />
|
||||
<text
|
||||
id="text3764"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
y="23.035164"
|
||||
x="220.98541"
|
||||
xml:space="preserve">BRepAlgoAPI_BuilderAlgo</text>
|
||||
<text
|
||||
id="text3766"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
y="25.049999"
|
||||
x="327.60477"
|
||||
xml:space="preserve"> </text>
|
||||
<path
|
||||
id="path3768"
|
||||
d="m 53.175776,114.3 0,22.37812 160.127334,0 0,-22.37812 z"
|
||||
clip-path="url(#clipEmfPath2)"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.24689317px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<text
|
||||
id="text3770"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
y="143.76225"
|
||||
x="148.95631"
|
||||
xml:space="preserve">BRepAlgoAPI_Fuse</text>
|
||||
<text
|
||||
id="text3772"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
y="128.85001"
|
||||
x="204.603"
|
||||
xml:space="preserve"> </text>
|
||||
<text
|
||||
id="text3774"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Arial"
|
||||
y="158.85001"
|
||||
x="57.45084"
|
||||
xml:space="preserve"> </text>
|
||||
<path
|
||||
id="path3776"
|
||||
d="m 280.56035,62.94375 -0.59064,-22.621875 c -0.009,-0.346875 0.26251,-0.6375 0.60939,-0.646875 0.34688,-0.0094 0.62813,0.2625 0.63751,0.609375 l 0.59063,22.63125 c 0.009,0.346875 -0.2625,0.628125 -0.60938,0.6375 -0.34688,0.0094 -0.62814,-0.2625 -0.63751,-0.609375 z m -3.68443,-21.290625 3.55317,-7.603125 3.94694,7.40625 z"
|
||||
clip-path="url(#clipEmfPath3)"
|
||||
style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.1500022px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path3778"
|
||||
d="m 177.37132,50.938071 0,23.25606 252.44098,0 0,-23.25606 z"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.43770862px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<text
|
||||
id="text3780"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
y="64.861305"
|
||||
x="203.64111"
|
||||
xml:space="preserve">BRepAlgoAPI_BooleanOperation</text>
|
||||
<text
|
||||
id="text3782"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
y="79.199997"
|
||||
x="351.30511"
|
||||
xml:space="preserve"> </text>
|
||||
<text
|
||||
id="text3784"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
y="108.3"
|
||||
x="188.70276"
|
||||
xml:space="preserve"> </text>
|
||||
<path
|
||||
id="path3786"
|
||||
d="m 198.98728,113.10938 20.70968,-20.700005 c 0.24375,-0.24375 0.63751,-0.24375 0.88126,0 0.24375,0.24375 0.24375,0.6375 0,0.88125 L 199.87792,114 c -0.24376,0.24375 -0.64689,0.24375 -0.89064,0 -0.24375,-0.24375 -0.24375,-0.64688 0,-0.89062 z m 17.61588,-22.031255 7.95012,-2.653125 -2.64379,7.959375 z"
|
||||
clip-path="url(#clipEmfPath4)"
|
||||
style="fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:0.1500022px;stroke-linecap:butt;stroke-linejoin:bevel;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path3790"
|
||||
d="m 323.06859,130.86407 0,22.45692 161.49789,0 0,-22.45692 z"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.18685222px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<text
|
||||
id="text3792"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
y="144.46437"
|
||||
x="341.69354"
|
||||
xml:space="preserve">BRepAlgoAPI_Cut</text>
|
||||
<text
|
||||
id="text3794"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
y="128.55"
|
||||
x="480.30701"
|
||||
xml:space="preserve"> </text>
|
||||
<text
|
||||
id="text3796"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:normal;text-align:start;text-anchor:start;fill:#000000;font-family:Arial"
|
||||
y="158.39999"
|
||||
x="318.75464"
|
||||
xml:space="preserve"> </text>
|
||||
<path
|
||||
id="path3778-1"
|
||||
d="m 136.65269,130.42418 0,23.58586 147.81153,0 0,-23.58586 z"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.10790598px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
style="fill:#916f6f;stroke:#000000;stroke-width:0.7965284px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#Arrow2Mstart)"
|
||||
d="m 304.3563,32.239951 0,18.31124"
|
||||
id="path3875"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
transform="matrix(1.1475795,0,0,0.99628756,-17.657381,-45.674459)"
|
||||
id="path3762-4"
|
||||
d="m 214.87814,10.5 0,23.4375 135.43322,0 0,-23.4375 z"
|
||||
clip-path="url(#clipEmfPath1-0)"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.25626838px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path3778-1-8"
|
||||
d="m 78.687273,88.627374 0,23.585856 147.811517,0 0,-23.585856 z"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.10790598px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:0.90858448px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline"
|
||||
d="M 276.56388,74.263936 224.85315,129.41594"
|
||||
id="path6825"
|
||||
inkscape:connector-type="polyline"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:0.91995925px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;display:inline"
|
||||
d="m 325.68413,73.924924 51.41999,56.861286"
|
||||
id="path6825-2"
|
||||
inkscape:connector-type="polyline"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
|
||||
d="m 179.52049,162.77106 c -59.64898,14.3387 -59.64898,14.3387 -59.64898,14.3387"
|
||||
id="path6849"
|
||||
inkscape:connector-curvature="0"
|
||||
transform="translate(56.87729,-88.80611)" />
|
||||
<text
|
||||
id="text3792-4"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
y="103.56826"
|
||||
x="83.965698"
|
||||
xml:space="preserve">BRepAlgoAPI_Common</text>
|
||||
<path
|
||||
id="path3778-1-8-5"
|
||||
d="m 373.01844,90.295386 0,23.546834 158.6699,0 0,-23.546834 z"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.14692891px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:1.0304904px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
|
||||
d="m 389.40321,74.26698 c 58.76558,15.4553 58.76558,15.4553 58.76558,15.4553"
|
||||
id="path6849-5"
|
||||
inkscape:connector-curvature="0" />
|
||||
<text
|
||||
id="text3792-4-1"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
y="104.71535"
|
||||
x="382.07281"
|
||||
xml:space="preserve">BRepAlgoAPI_Section</text>
|
||||
<path
|
||||
style="fill:#916f6f;stroke:#000000;stroke-width:0.7965284px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#Arrow2Mstart)"
|
||||
d="m 305.51053,-9.9971206 0,18.31124"
|
||||
id="path3875-1"
|
||||
inkscape:connector-curvature="0" />
|
||||
<text
|
||||
id="text3764-5"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
y="-19.759373"
|
||||
x="249.94737"
|
||||
xml:space="preserve">BRepAlgoAPI_Algo</text>
|
||||
<path
|
||||
style="fill:#916f6f;stroke:#000000;stroke-width:0.7965284px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-start:url(#Arrow2Mstart)"
|
||||
d="m 306.65763,-54.160308 0,18.31124"
|
||||
id="path3875-1-1"
|
||||
inkscape:connector-curvature="0" />
|
||||
<path
|
||||
id="path3762-3"
|
||||
d="m 214.87814,10.5 0,23.4375 135.43322,0 0,-23.4375 z"
|
||||
clip-path="url(#clipEmfPath1-4)"
|
||||
style="fill:none;stroke:#000000;stroke-width:1.25626838px;stroke-linecap:round;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none"
|
||||
inkscape:connector-curvature="0"
|
||||
transform="matrix(1.6833898,0,0,0.98459396,-169.65553,-88.430725)" />
|
||||
<text
|
||||
id="text3764-2"
|
||||
style="font-size:12.45018196px;font-style:normal;font-weight:bold;text-align:start;text-anchor:start;fill:#000000;font-family:Courier New"
|
||||
y="-65.054825"
|
||||
x="221.258"
|
||||
xml:space="preserve">BRepBuilderAPI_MakeShape</text>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
After Width: | Height: | Size: 17 KiB |
@@ -1447,7 +1447,7 @@ Returns the number of selected objects in the interactive context.
|
||||
|
||||
Syntax:
|
||||
~~~~~
|
||||
valntialiasing 1|0
|
||||
vantialiasing 1|0
|
||||
~~~~~
|
||||
Sets antialiasing if the command is called with 1 or unsets otherwise.
|
||||
|
||||
|
@@ -5,21 +5,21 @@ Foundation Classes {#occt_user_guides__foundation_classes}
|
||||
|
||||
@section occt_fcug_1 Introduction
|
||||
|
||||
@subsection occt_fcug_1_1 Foundation Classes Overview
|
||||
This manual explains how to use Open CASCADE Technology (**OCCT**) Foundation Classes. It provides basic documentation on foundation classes. For advanced information on foundation classes and their applications, see the offerings on our web site at <a href="http://www.opencascade.org/support/training/">www.opencascade.org/support/training/</a>.
|
||||
|
||||
Foundation Classes provide a variety of general-purpose services such as automated dynamic memory management (manipulation of objects by handle), collections, exception handling, genericity by down-casting and plug-in creation.
|
||||
|
||||
This manual explains how to use Open CASCADE Technology (**OCCT**) Foundation Classes. It provides basic documentation on foundation classes. For advanced information on foundation classes and their applications, see our offerings on our web site at <a href="http://www.opencascade.org/support/training/">www.opencascade.org/support/training/</a>
|
||||
Foundation Classes provide a variety of general-purpose services such as automated dynamic memory management (manipulation of objects by handle), collections, exception handling, genericity by downcasting and plug-in creation.
|
||||
Foundation Classes include the following:
|
||||
|
||||
### Root Classes
|
||||
Root classes are the basic data types and classes on which all the other classes are built. They provide:
|
||||
* fundamental types such as Boolean, Character, Integer or Real,
|
||||
* safe handling of dynamically created objects, ensuring automatic deletion of unreferenced objects (see the Standard_Transient class),
|
||||
* safe handling of dynamically created objects, ensuring automatic deletion of unreferenced objects (see *Standard_Transient* class),
|
||||
* configurable optimized memory manager increasing the performance of applications that intensively use dynamically created objects,
|
||||
* extended run-time type information (RTTI) mechanism facilitating the creation of complex programs,
|
||||
* management of exceptions,
|
||||
* encapsulation of C++ streams.
|
||||
Root classes are mainly implemented in the *Standard* and *MMgt* packages.
|
||||
Root classes are mainly implemented in *Standard* and *MMgt* packages.
|
||||
|
||||
### Strings
|
||||
Strings are classes that handle dynamically sized sequences of characters based on both ASCII (normal 8-bit character type) and Unicode (16-bit character type).
|
||||
@@ -39,7 +39,6 @@ The *TColStd* package provides frequently used instantiations of generic classe
|
||||
|
||||
### Vectors and Matrices
|
||||
|
||||
|
||||
These classes provide commonly used mathematical algorithms and basic calculations (addition, multiplication, transposition, inversion, etc.) involving vectors and matrices.
|
||||
|
||||
### Primitive Geometric Types
|
||||
@@ -82,25 +81,27 @@ These are various classes supporting date and time information and fundamental
|
||||
### Application services
|
||||
|
||||
Foundation Classes also include implementation of several low-level services that facilitate the creation of customizable and user-friendly applications with Open CASCADE Technology. These include:
|
||||
* Unit conversion tools, providing a uniform mechanism for dealing with quantities and associated physical units: check unit compatibility, perform conversions of values between different units and so on (see package *UnitsAPI*).
|
||||
* Basic interpreter of expressions that facilitates the creation of customized scripting tools, generic definition of expressions and so on (see package *ExprIntrp*)
|
||||
* Tools for dealing with configuration resource files (see package *Resource*) and customizable message files (see package *Message*), making it easy to provide a multi-language support in applications
|
||||
* Unit conversion tools, providing a uniform mechanism for dealing with quantities and associated physical units: check unit compatibility, perform conversions of values between different units and so on (see package *UnitsAPI*);
|
||||
* Basic interpreter of expressions that facilitates the creation of customized scripting tools, generic definition of expressions and so on (see package *ExprIntrp*);
|
||||
* Tools for dealing with configuration resource files (see package *Resource*) and customizable message files (see package *Message*), making it easy to provide a multi-language support in applications;
|
||||
* Progress indication and user break interfaces, giving a possibility even for low-level algorithms to communicate with the user in a universal and convenient way.
|
||||
|
||||
|
||||
@section occt_fcug_2 Basics
|
||||
This chapter deals with basic services such as library organization, persistence, data types, memory management, programming with handles, exception handling, genericity by downcasting and plug-in creation.
|
||||
|
||||
|
||||
@subsection occt_fcug_1_2 Fundamental Concepts
|
||||
An object-oriented language structures a system around data types rather than around the actions carried out on this data. In this context, an **object** is an **instance** of a data type and its definition determines how it can be used. Each data type is implemented by one or more classes, which make up the basic elements of the system.
|
||||
@subsection occt_fcug_2_a Library organization
|
||||
|
||||
In Open CASCADE Technology the classes are usually defined using CDL (CASCADE Definition Language) that provides a certain level of abstraction from pure C++ constructs and ensures a definite level of similarity in the implementation of classes. See *CDL User’s Guide* for more details.
|
||||
This chapter introduces some basic concepts, which are used not only in Foundation Classes, but throughout the whole OCCT library.
|
||||
|
||||
This chapter introduces some basic concepts most of which are directly supported by CDL and used not only in Foundation Classes, but throughout the whole OCCT library.
|
||||
@subsubsection occt_fcug_2_a_1 Modules and toolkits
|
||||
|
||||
@subsubsection occt_fcug_1_2_1 Modules and toolkits
|
||||
The whole OCCT library is organized in a set of modules. The first module, providing most basic services and used by all other modules, is called Foundation Classes and described by this manual.
|
||||
|
||||
Every module consists primarily of one or several toolkits (though it can also contain executables, resource units etc.). Physically a toolkit is represented by a shared library (e.g. .so or .dll). The toolkit is built from one or several packages.
|
||||
|
||||
@subsubsection occt_fcug_1_2_2 Packages
|
||||
@subsubsection occt_fcug_2_a_2 Packages
|
||||
A **package** groups together a number of classes which have semantic links. For example, a geometry package would contain Point, Line, and Circle classes. A package can also contain enumerations, exceptions and package methods (functions). In practice, a class name is prefixed with the name of its package e.g.
|
||||
*Geom_Circle*.
|
||||
Data types described in a package may include one or more of the following data types:
|
||||
@@ -118,19 +119,18 @@ Inside a package, two data types cannot bear the same name.
|
||||
* **Instance method** Operates on the instance which owns it.
|
||||
* **Class method** Does not work on individual instances, only on the class itself.
|
||||
|
||||
@subsubsection occt_fcug_1_2_3 Classes
|
||||
@subsubsection occt_fcug_2_a_3 Classes
|
||||
The fundamental software component in object-oriented software development is the class. A class is the implementation of a **data type**. It defines its **behavior** (the services offered by its functions) and its **representation** (the data structure of the class – the fields, which store its data).
|
||||
|
||||
#### Categories of Classes
|
||||
Classes fall into three categories:
|
||||
* Ordinary classes.
|
||||
* Deferred classes. A **deferred class** cannot be instantiated. The purpose of having such classes is to have a given behavior shared by a hierarchy of classes and dependent on the implementation of the descendants. This is a way of guaranteeing a certain base of inherited behavior common to all the classes based on a particular deferred class. The C++ equivalent of a deferred CDL class is an abstract class.
|
||||
* Generic classes. A **generic class** offers a set of functional behaviors to manipulate other data types. Instantiation of a generic class requires that a data type is given for its argument(s). The generic classes in CDL perform the same mission as template classes in C++.
|
||||
* Ordinary classes.
|
||||
* Deferred classes. A **deferred class** cannot be instantiated. The purpose of having such classes is to have a given behavior shared by a hierarchy of classes and dependent on the implementation of the descendants. This is a way of guaranteeing a certain base of inherited behavior common to all the classes based on a particular deferred class. The C++ equivalent of a deferred CDL class is an abstract class.
|
||||
* Generic classes. A **generic class** offers a set of functional behaviors to manipulate other data types. Instantiation of a generic class requires that a data type is given for its argument(s). The generic classes in CDL perform the same mission as template classes in C++.
|
||||
|
||||
@subsubsection occt_fcug_1_2_4 Genericity
|
||||
@subsubsection occt_fcug_2_a_4 Generic Classes
|
||||
Generic classes are implemented in two steps. First you declare the generic class to establish the model, then you instantiate this class by giving information about the generic types.
|
||||
|
||||
#### Declaring a Generic Class
|
||||
#### Declaring a Generic Class
|
||||
|
||||
The generic classes in Open CASCADE Technology are similar by their intent to C++ templates with explicit instantiation.
|
||||
A generic class is declared in CDL as operating on data items of non-fixed types which are declared as arguments of the generic class. It is possible to put a restriction on these data types to be of subtype of some definite class. Definition of the generic class does not create new class type in C++ terms; it only defines a pattern for generation (instantiation) of the real classes.
|
||||
@@ -157,15 +157,27 @@ class MapOfReal instantiates Map from TCollection (Real,MapRealHasher);
|
||||
This declaration in *TColStd* defines not only class *TColStd_MapOfReal*, but also class *TColStd_MapIteratorOfMapOfReal*, which is instantiated from nested class *MapIterator* of the generic class *TCollection_Map*. Note that instantiation of the nested class is separate class, it is not nested class to the instantiation of the main class.
|
||||
**Nested classes**, even though they are described as non-generic classes, are generic by construction being inside the class they are a member of.
|
||||
|
||||
@subsubsection occt_fcug_1_2_5 Inheritance
|
||||
@subsubsection occt_fcug_2_a_5 Inheritance
|
||||
The purpose of inheritance is to reduce the development workload. The inheritance mechanism allows a new class to be declared already containing the characteristics of an existing class. This new class can then be rapidly specialized for the task in hand. This avoids the necessity of developing each component “from scratch”.
|
||||
For example, having already developed a class *BankAccount* you could quickly specialize new classes: *SavingsAccount, LongTermDepositAccount, MoneyMarketAccount, RevolvingCreditAccount*, etc....
|
||||
|
||||
The corollary of this is that when two or more classes inherit from a parent (or ancestor) class, all these classes guarantee as a minimum the behavior of their parent (or ancestor). For example, if the parent class BankAccount contains the method Print which tells it to print itself out, then all its descendent classes guarantee to offer the same service.
|
||||
The corollary of this is that when two or more classes inherit from a parent (or ancestor) class, all these classes guarantee as a minimum the behavior of their parent (or ancestor). For example, if the parent class BankAccount contains the method Print which tells it to print itself out, then all its descendant classes guarantee to offer the same service.
|
||||
|
||||
One way of ensuring the use of inheritance is to declare classes at the top of a hierarchy as being **deferred**. In such classes, the methods are not implemented. This forces the user to create a new class which redefines the methods. This is a way of guaranteeing a certain minimum of behavior among descendent classes.
|
||||
One way of ensuring the use of inheritance is to declare classes at the top of a hierarchy as being **deferred**. In such classes, the methods are not implemented. This forces the user to create a new class which redefines the methods. This is a way of guaranteeing a certain minimum of behavior among descendant classes.
|
||||
|
||||
@subsection occt_fcug_2_b Persistence and Data Schema
|
||||
The data schema is the structure used by an application to store its data. Data schemas consist of persistent classes.
|
||||
|
||||
An object is called **persistent** if it can be permanently stored. Thus, the object can be reused at a later date by the application, which created it, or by another application.
|
||||
|
||||
In order for an object to be persistent for CDL, its type must be declared as inheriting from the class *Standard_Persistent* or have a parent class inheriting from the *Standard_Persistent* class. Note that classes inheriting from *Standard_Persistent* are handled by a reference.
|
||||
|
||||
Objects instantiated from classes which inherit from the Standard_Storable class cannot themselves be stored individually, but they can be stored as fields of an object which inherits from *Standard_Persistent*. Note that objects inheriting from *Standard_Storable* are handled by a value.
|
||||
|
||||
@subsection occt_fcug_2_1 Data Types
|
||||
|
||||
An object-oriented language structures a system around data types rather than around the actions carried out on this data. In this context, an **object** is an **instance** of a data type and its definition determines how it can be used. Each data type is implemented by one or more classes, which make up the basic elements of the system.
|
||||
|
||||
@subsubsection occt_fcug_1_2_6 Categories of Data Types
|
||||
The data types in Open CASCADE Technology fall into two categories:
|
||||
* Data types manipulated by handle (or reference)
|
||||
* Data types manipulated by value
|
||||
@@ -186,24 +198,10 @@ Handle(myClass) m = new myClass;
|
||||
|
||||
In Open CASCADE Technology, the Handles are specific classes that are used to safely manipulate objects allocated in the dynamic memory by reference, providing reference counting mechanism and automatic destruction of the object when it is not referenced.
|
||||
|
||||
@subsubsection occt_fcug_1_2_7 Exceptions
|
||||
The behavior of any object is implemented by the methods, which were defined in its class declaration. The definition of these methods includes not only their signature (their programming interface) but also their domain of validity.
|
||||
|
||||
This domain is expressed by **exceptions**. Exceptions are raised under various error conditions. This mechanism is a safeguard of software quality.
|
||||
|
||||
@subsubsection occt_fcug_1_2_8 Persistence and Data Schema
|
||||
The data schema is the structure used by an application to store its data. Data schemas consist of persistent classes.
|
||||
|
||||
An object is called **persistent** if it can be permanently stored. Thus, the object can be reused at a later date by the application, which created it, or by another application.
|
||||
|
||||
In order for an object to be persistent for CDL, its type must be declared as inheriting from the class *Standard_Persistent* or have a parent class inheriting from the *Standard_Persistent* class. Note that classes inheriting from *Standard_Persistent* are handled by a reference.
|
||||
|
||||
Objects instantiated from classes which inherit from the Standard_Storable class cannot themselves be stored individually, but they can be stored as fields of an object which inherits from *Standard_Persistent*. Note that objects inheriting from *Standard_Storable* are handled by a value.
|
||||
|
||||
@section occt_fcug_2 Basics
|
||||
This chapter deals with basic services such as memory management, programming with handles, primitive types, exception handling, genericity by downcasting and plug-in creation.
|
||||
@subsection occt_fcug_2_1 Data Types
|
||||
@subsubsection occt_fcug_2_1_1 Primitive Types
|
||||
|
||||
The primitive types are predefined in the language and they are **manipulated by value**.
|
||||
Some of these primitives inherit from the **Storable** class. This means they can be used in the implementation of persistent objects, either contained in entities declared within the methods of the object, or they form part of the internal representation of the object.
|
||||
|
||||
@@ -237,7 +235,6 @@ The table below presents the equivalence existing between C++ fundamental types
|
||||
|
||||
\* The types with asterisk are pointers.
|
||||
|
||||
|
||||
**Reminder of the classes listed above:**
|
||||
|
||||
* **Standard_Integer** : fundamental type representing 32-bit integers yielding negative, positive or null values. *Integer* is implemented as a *typedef* of the C++ *int* fundamental type. As such, the algebraic operations +, -, *, / as well as the ordering and equivalence relations <, <=, ==, !=, >=, > are defined on it.
|
||||
@@ -270,7 +267,7 @@ There are two categories of types which are manipulated by handle:
|
||||
@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"
|
||||
|
||||
@subsubsection occt_fcug_2_1_4 Summary of properties
|
||||
@subsubsection occt_fcug_2_1_4 When is it necessary to use a handle?
|
||||
|
||||
The following table summarizes how various data types are handled and stored.
|
||||
|
||||
@@ -279,9 +276,26 @@ The following table summarizes how various data types are handled and stored.
|
||||
| storable | Persistent | Primitive, Storable (if nested in a persistent class)|
|
||||
|temporary | Transient | Other |
|
||||
|
||||
When you design an object, it can be difficult to choose how to manipulate that
|
||||
object: by value or by handle. The following ideas can help you to make up your mind:
|
||||
|
||||
* If your object may have a long lifetime within the application and you want to make multiple
|
||||
references to it, it would be preferable to manipulate this object with a handle. The memory for the
|
||||
object will be allocated on the heap. The handle which points to that memory is a light object which
|
||||
can be rapidly passed in argument. This avoids the penalty of copying a large object.
|
||||
* If your object will have a limited lifetime, for example, used within a single algorithm, it would
|
||||
be preferable to manipulate this object by value, non-regarding its size, because this object is
|
||||
allocated on the stack and the allocation and de-allocation of memory is extremely rapid, which
|
||||
avoids the implicit calls to *new* and *delete* occasioned by allocation on the heap.
|
||||
* Finally, if an object will be created only once during, but will exist throughout the lifetime of
|
||||
the application, the best choice may be a class manipulated by handle or a value declared as a
|
||||
global variable.
|
||||
|
||||
|
||||
@subsection occt_fcug_2_2 Programming with Handles
|
||||
|
||||
@subsubsection occt_fcug_2_2_1 Handle Definition
|
||||
|
||||
A handle may be compared with a C++ pointer. Several handles can reference the same object. Also, a single handle may reference several objects, but only one at a time. To have access to the object it refers to, the handle must be de-referenced just as with a C++ pointer.
|
||||
|
||||
Transient and Persistent classes may be manipulated either with handles or with values. Handles which reference non-persistent objects are called non-storable handles; therefore, a persistent object cannot contain a non-storable handle.
|
||||
@@ -315,10 +329,8 @@ To initialize a handle, either a new object should be created or the value of a
|
||||
|
||||
@subsubsection occt_fcug_2_2_2 Type Management
|
||||
|
||||
#### General
|
||||
|
||||
|
||||
Open CASCADE Technology provides a means to describe the hierarchy of data types in a generic way, with a possibility to check the exact type of the given object at run-time (similarly to C++ RTTI). For every class type derived from *Standard_Transient*, CDL extractor creates a code instantiating single instance of the class *Standard_Type* (type descriptor) that holds information on that type: its name and list of ancestor types.
|
||||
|
||||
That instance (actually, a handle on it) is returned by the virtual method *DynamicType()* of the class derived from *Standard_Transient*. The other virtual method *IsKind()* provides a means to check whether a given object has specified type or inherits it.
|
||||
|
||||
In order to refer to the type descriptor object for a given class type, use macros *STANDARD_TYPE()* with argument being a name of the class.
|
||||
@@ -341,7 +353,6 @@ The compiler sees p1 as a handle to *Point* though the actual object referenced
|
||||
|
||||
#### Explicit Type Conversion
|
||||
|
||||
|
||||
According to the rule of type conformity, it is always possible to go up the class hierarchy through successive assignments of handles. On the other hand, assignment does not authorize you to go down the hierarchy. Consequently, an explicit type conversion of handles is required.
|
||||
|
||||
A handle can be converted explicitly into one of its sub-types if the actual type of the referenced object is a descendant of the object used to cast the handle. If this is not the case, the handle is nullified (explicit type conversion is sometimes called a “safe cast”). Consider the example below.
|
||||
@@ -396,6 +407,7 @@ else {
|
||||
~~~~~
|
||||
|
||||
@subsubsection occt_fcug_2_2_3 Using Handles to Create Objects
|
||||
|
||||
To create an object which is manipulated by handle, declare the handle and initialize it with the standard C++ **new** operator, immediately followed by a call to the constructor. The constructor can be any of those specified in the source of the class from which the object is instanced.
|
||||
|
||||
~~~~~
|
||||
@@ -444,7 +456,8 @@ n = Geom_BezierCurve::MaxDegree();
|
||||
~~~~~
|
||||
|
||||
@subsubsection occt_fcug_2_2_5 Handle deallocation
|
||||
Before you delete an object, you must ensure it is no longer referenced. To reduce the programming load related to this management of object life, the delete function in Open CASCADE Technology is secured by a **reference counter** of classes manipulated by handle. A handle automatically deletes an object when it is no longer referenced. Normally you never call the delete operator explicitly on instances of subclasses of *Standard_Transient*.
|
||||
|
||||
Before you delete an object, you must ensure it is no longer referenced. To reduce the programming load related to this management of object life, the delete function in Open CASCADE Technology is secured by a **reference counter** of classes manipulated by handle. A handle automatically deletes an object when it is no longer referenced. Normally you never call the delete operator explicitly on instances of subclasses of *Standard_Transient*.
|
||||
|
||||
When a new handle to the same object is created, the reference counter is incremented. When the handle is destroyed, nullified, or reassigned to another object, that counter is decremented. The object is automatically deleted by the handle when reference counter becomes 0.
|
||||
|
||||
@@ -471,25 +484,38 @@ Handle (TColStd_HSequenceOfInteger) H1 = new TColStd_HSequenceOfInteger;
|
||||
// Here, H1 has no reference and the referred TColStd_HSequenceOfInteger object is deleted.
|
||||
~~~~~
|
||||
|
||||
#### Cycles
|
||||
You can easily cast a reference to the handle object to <i> void* </i> by defining the following:
|
||||
|
||||
Cycles appear if two or more objects reference each other by handles (stored as fields). In this condition automatic destruction will not work.
|
||||
~~~~
|
||||
void *pointer;
|
||||
Handle(Some_class) aHandle;
|
||||
// Here only a pointer will be copied
|
||||
Pointer = &aHandle;
|
||||
// Here the Handle object will be copied
|
||||
aHandle = * (Handle(Some_Class) *)pointer;
|
||||
~~~~
|
||||
|
||||
|
||||
@subsubsection occt_fcug_2_2_6 Cycles
|
||||
|
||||
Cycles appear if two or more objects reference each other by handles (stored as fields). In this condition automatic destruction will not work.
|
||||
|
||||
Consider for example a graph, whose objects (primitives) have to know the graph object to which they belong, i.e. a primitive must have a reference to complete graph object. If both primitives and the graph are manipulated by handle and they refer to each other by keeping a handle as a field, the cycle appears.
|
||||
|
||||
The graph object will not be deleted when the last handle to it is destructed in the application, since there are handles to it stored inside its own data structure (primitives).
|
||||
|
||||
There are two approaches how to avoid such situation:
|
||||
* Use C++ pointer for one kind of references, e.g. from a primitive to the graph
|
||||
* Nullify one set of handles (e.g. handles to a graph in primitives) when a graph object needs to be destroyed
|
||||
|
||||
@subsubsection occt_fcug_2_2_6 Creating Transient Classes without CDL
|
||||
@subsubsection occt_fcug_2_2_7 Creating Transient Classes without CDL
|
||||
|
||||
Though generation of Handle class and related C++ code is normally performed by CDL extractor, it is also possible to define a class managed by handle without CDL. To facilitate that, several macros are provided in the file Standard_DefineHandle.hxx:
|
||||
|
||||
* **DEFINE_STANDARD_HANDLE(class_name,ancestor_name)** - declares Handle class for a class *class_name* that inherits class *ancestor_name* (for instance, *Standard_Transient*). This macro should be put in a header file; the declaration of the handle to a base class must be available (usually put before or after the declaration of the class *class_name*, or into a separate header file).
|
||||
* **IMPLEMENT_STANDARD_HANDLE(class_name,ancestor_name)** - implements method *DownCast()* of the *Handle* class. Should be located in a C++ file (normally the file where methods of the class *class_name* are implemented).
|
||||
* **DEFINE_STANDARD_RTTI(class_name)** - declares methods required for RTTI in the class *class_name* declaration; should be in public: section.
|
||||
* **IMPLEMENT_STANDARD_RTTIEXT(class_name,ancestor_name)** - implements above methods. Usually put into the C++ file implementing class class_name.
|
||||
* **IMPLEMENT_STANDARD_RTTIEXT(class_name,ancestor_name)** - implements above methods. Usually put into the C++ file implementing class *class_name*.
|
||||
Note that it is important to ensure correctness of macro arguments, especially the ancestor name, otherwise the definition may be inconsistent (no compiler warnings will be issued in case of mistake).
|
||||
|
||||
In *Appli_ExtSurface.hxx* file:
|
||||
@@ -511,21 +537,118 @@ IMPLEMENT_STANDARD_HANDLE(Appli_ExtSurface,Geom_Surface)
|
||||
IMPLEMENT_STANDARD_RTTIEXT(Appli_ExtSurface,Geom_Surface)
|
||||
~~~~~
|
||||
|
||||
#### Example
|
||||
|
||||
@subsection occt_fcug_2_3 Memory Management in Open CASCADE Technology
|
||||
In the course of a work session, geometric modeling applications create and delete a considerable number of C++ objects allocated in the dynamic memory (heap). In this context, performance of standard functions for allocating and deallocating memory may be not sufficient. For this reason, Open CASCADE Technology employs a specialized memory manager implemented in the Standard package.
|
||||
The following example shows how to define a class <i> SamplePoint </i> manipulated by handle.
|
||||
|
||||
@subsubsection occt_fcug_2_3_1. Usage
|
||||
To use the Open CASCADE Technology memory manager to allocate memory in a C code, just use method *Standard::Allocate()* instead of *malloc()* and method *Standard::Free()* instead of *free()*. In addition, method *Standard::Reallocate()* is provided to replace C function *realloc()*.
|
||||
First you need to define *Sample_Point.hxx* :
|
||||
|
||||
~~~~
|
||||
|
||||
#ifndef _Sample_Point_HeaderFile
|
||||
#define _Sample_Point_HeaderFile
|
||||
#ifndef _Standard_Macro_HeaderFile
|
||||
#include <Standard_Macro.hxx>
|
||||
#endif
|
||||
#include <MMgt_TShared.hxx>
|
||||
#include <Standard_DefineHandle.hxx>
|
||||
// Handle definition
|
||||
//
|
||||
|
||||
DEFINE_STANDARD_HANDLE(Sample_Point,MMgt_TShared)
|
||||
class Sample_Point: public MMgt_TShared {
|
||||
public:
|
||||
Sample_Point();
|
||||
Sample_Point(const Standard_Real, const
|
||||
Standard_Real);
|
||||
void SetX(const Standard_Real x) {
|
||||
myX = x;
|
||||
}
|
||||
void SetY(const Standard_Real y) {
|
||||
myY = y;
|
||||
}
|
||||
Standard_Real X() const {
|
||||
return myX;
|
||||
}
|
||||
Standard_Real Y() const {
|
||||
return myY;
|
||||
}
|
||||
// some methods like DynamicType() or
|
||||
IsKind()
|
||||
//
|
||||
DEFINE_STANDARD_RTTI(Sample_Point)
|
||||
private:
|
||||
Standard_Real myX;
|
||||
Standard_Real myY;
|
||||
};
|
||||
#endif
|
||||
|
||||
~~~~
|
||||
|
||||
Then you need to define *Sample_Point.cxx* :
|
||||
|
||||
~~~~
|
||||
|
||||
#include <Sample_Point.hxx>
|
||||
|
||||
// Implementation of Handle and type mgt
|
||||
|
||||
IMPLEMENT_STANDARD_HANDLE(Sample_Point,MMgt_TShared)
|
||||
IMPLEMENT_STANDARD_RTTI(Sample_Point,MMgt_TShared)
|
||||
|
||||
// For ancestors, we add a IMPLEMENT_STANDARD_SUPERTYPE and
|
||||
// a IMPLEMENT_STANDARD_SUPERTYPE_ARRAY_ENTRY macro.
|
||||
// We must respect the order: from the direct ancestor class to the base class.
|
||||
|
||||
IMPLEMENT_STANDARD_TYPE(Sample_Point)
|
||||
IMPLEMENT_STANDARD_SUPERTYPE(MMgt_TShared)
|
||||
IMPLEMENT_STANDARD_SUPERTYPE(Standard_Transient)
|
||||
IMPLEMENT_STANDARD_SUPERTYPE_ARRAY()
|
||||
IMPLEMENT_STANDARD_SUPERTYPE_ARRAY_ENTRY(MMgt_TShared)
|
||||
IMPLEMENT_STANDARD_SUPERTYPE_ARRAY_ENTRY(Standard_Transient)
|
||||
IMPLEMENT_STANDARD_SUPERTYPE_ARRAY_END()
|
||||
IMPLEMENT_STANDARD_TYPE_END(Sample_Point)
|
||||
|
||||
// Constructors implementation
|
||||
|
||||
Sample_Point::Sample_Point(const
|
||||
Standard_Real x, const Standard_Real y)
|
||||
{
|
||||
myX = x;
|
||||
myY = y;
|
||||
}
|
||||
Sample_Point::Sample_Point()
|
||||
{
|
||||
myX = 0.0;
|
||||
myY = 0.0;
|
||||
}
|
||||
~~~~
|
||||
|
||||
|
||||
@subsection occt_fcug_2_3 Memory Management
|
||||
|
||||
In a work session, geometric modeling applications create and delete a considerable number of C++ objects allocated in the dynamic memory (heap). In this context, performance of standard functions for allocating and deallocating memory may be not sufficient. For this reason, Open CASCADE Technology employs a specialized memory manager implemented in the *Standard* package.
|
||||
|
||||
The Memory Manager is based on the following principles:
|
||||
|
||||
* small memory arrays are grouped into clusters and then recycled (clusters are never released to the system),
|
||||
* large arrays are allocated and de-allocated through the standard functions of the system (the arrays are released to system when they are no longer used).
|
||||
|
||||
As a general rule, it is advisable to allocate memory through significant blocks. In this way, the user can work with blocks of contiguous data and it facilitates memory page manager processing.
|
||||
|
||||
@subsubsection occt_fcug_2_3_1 Usage of Memory Manager
|
||||
|
||||
To allocate memory in a C code with Open CASCADE Technology memory manager, simply use method *Standard::Allocate()* instead of *malloc()* and method *Standard::Free()* instead of *free()*. In addition, method *Standard::Reallocate()* is provided to replace C function *realloc()*.
|
||||
|
||||
In C++, operators *new()* and *delete()* for a class may be defined so as to allocate memory using *Standard::Allocate()* and free it using *Standard::Free()*. In that case all objects of that class and all inherited classes will be allocated using the OCCT memory manager.
|
||||
|
||||
CDL extractor defines *new()* and *delete()* in this way for all classes declared with CDL. Thus all OCCT classes (apart from a few exceptions) are allocated using the OCCT memory manager.
|
||||
Since operators *new()* and *delete()* are inherited, this is also true for any class derived from an OCCT class, for instance, for all classes derived from *Standard_Transient*.
|
||||
|
||||
**Note** that it is possible (though not recommended unless really unavoidable) to redefine *new()* and *delete()* functions for some class inheriting Standard_Transient. If that is done, the method *Delete()* should be also redefined to apply operator *delete* to *this* pointer. This will ensure that appropriate *delete()* function will be called, even if the object is manipulated by a handle to a base class.
|
||||
**Note** that it is possible (though not recommended unless really unavoidable) to redefine *new()* and *delete()* functions for a class inheriting *Standard_Transient*. If that is done, the method *Delete()* should be also redefined to apply operator *delete* to this pointer. This will ensure that appropriate *delete()* function will be called, even if the object is manipulated by a handle to a base class.
|
||||
|
||||
@subsubsection occt_fcug_2_3_2 How to configure the Memory Manager
|
||||
|
||||
@subsubsection occt_fcug_2_3_2 Configuring the memory manager
|
||||
The OCCT memory manager may be configured to apply different optimization techniques to different memory blocks (depending on their size), or even to avoid any optimization and use C functions *malloc()* and *free()* directly.
|
||||
The configuration is defined by numeric values of the following environment variables:
|
||||
* *MMGT_OPT*: if set to 0 (default) every memory block is allocated in C memory heap directly (via *malloc()* and *free()* functions). In this case, all other options except for *MMGT_CLEAR* are ignored; if set to 1 the memory manager performs optimizations as described below; if set to 2, Intel ® TBB optimized memory manager is used.
|
||||
@@ -535,7 +658,8 @@ The configuration is defined by numeric values of the following environment var
|
||||
* *MMGT_THRESHOLD*: defines the maximal size of blocks that are recycled internally instead of being returned to the heap. Default is 40000.
|
||||
* *MMGT_MMAP*: when set to 1 (default), large memory blocks are allocated using memory mapping functions of the operating system; if set to 0, they will be allocated in the C heap by *malloc()*.
|
||||
|
||||
@subsubsection occt_fcug_2_3_3 Implementation details
|
||||
@subsubsection occt_fcug_2_3_3 Optimization Techniques
|
||||
|
||||
When *MMGT_OPT* is set to 1, the following optimization techniques are used:
|
||||
* Small blocks with a size less than *MMGT_CELLSIZE*, are not allocated separately. Instead, a large pools of memory are allocated (the size of each pool is *MMGT_NBPAGES* pages). Every new memory block is arranged in a spare place of the current pool. When the current memory pool is completely occupied, the next one is allocated, and so on.
|
||||
|
||||
@@ -547,15 +671,15 @@ However, unlike small blocks, the recycled medium blocks contained in the free
|
||||
|
||||
* Large blocks with a size greater than *MMGT_THRESHOLD*, including memory pools used for small blocks, are allocated depending on the value of *MMGT_MMAP*: if it is 0, these blocks are allocated in the C heap; otherwise they are allocated using operating-system specific functions managing memory mapped files. Large blocks are returned to the system immediately when *Standard::Free()* is called.
|
||||
|
||||
#### Benefits and drawbacks
|
||||
@subsubsection occt_fcug_2_3_4 Benefits and drawbacks
|
||||
|
||||
The major benefit of the OCCT memory manager is explained by its recycling of small and medium blocks that makes an application work much faster when it constantly allocates and frees multiple memory blocks of similar sizes. In practical situations, the real gain on the application performance may be up to 50%.
|
||||
|
||||
The associated drawback is that recycled memory is not returned to the operating system during program execution. This may lead to considerable memory consumption and even be misinterpreted as a memory leak. To minimize this effect, the method Standard::Purge() shall be called after the completion of memory-intensive operations.
|
||||
The associated drawback is that recycled memory is not returned to the operating system during program execution. This may lead to considerable memory consumption and even be misinterpreted as a memory leak. To minimize this effect it is necessary to call the method *Standard::Purge* after the completion of memory-intensive operations.
|
||||
|
||||
The overhead expenses induced by the OCCT memory manager are:
|
||||
* size of every allocated memory block is rounded up to 8 bytes (when MMGT_OPT is 0 (default), the rounding is defined by the CRT; the typical value for 32-bit platforms is 4 bytes)
|
||||
* additional 4 bytes (or 8 on 64-bit platforms) are allocated in the beginning of every memory block to hold its size (or address of the next free memory block when recycled in free list) only when MMGT_OPT is 1
|
||||
|
||||
* size of every allocated memory block is rounded up to 8 bytes (when *MMGT_OPT* is 0 (default), the rounding is defined by the CRT; the typical value for 32-bit platforms is 4 bytes)
|
||||
* additional 4 bytes (or 8 on 64-bit platforms) are allocated in the beginning of every memory block to hold its size (or address of the next free memory block when recycled in free list) only when *MMGT_OPT* is 1.
|
||||
|
||||
Note that these overheads may be greater or less than overheads induced by the C heap memory manager, so overall memory consumption may be greater in either optimized or standard modes, depending on circumstances.
|
||||
|
||||
@@ -564,12 +688,19 @@ As a general rule, it is advisable to allocate memory through significant block
|
||||
OCCT memory manager uses mutex to lock access to free lists, therefore it may have less performance than non-optimized mode in situations when different threads often make simultaneous calls to the memory manager.
|
||||
The reason is that modern implementations of *malloc()* and *free()* employ several allocation arenas and thus avoid delays waiting mutex release, which are possible in such situations.
|
||||
|
||||
@subsection occt_fcug_2_4 Exception Handling
|
||||
@subsection occt_fcug_2_4 Exceptions
|
||||
|
||||
@subsubsection occt_fcug_2_4_1 Introduction
|
||||
|
||||
The behavior of any object is implemented by the methods, which were defined in its class declaration. The definition of these methods includes not only their signature (their programming interface) but also their domain of validity.
|
||||
|
||||
This domain is expressed by **exceptions**. Exceptions are raised under various error conditions to protect software quality.
|
||||
|
||||
Exception handling provides a means of transferring control from a given point in a program being executed to an **exception handler** associated with another point previously executed.
|
||||
|
||||
A method may raise an exception which interrupts its normal execution and transfers control to the handler catching this exception.
|
||||
|
||||
Open CASCADE Technology provides a hierarchy of exception classes with a root class being class Standard_Failure from the Standard package. The CDL extractor generates exception classes with standardized interface.
|
||||
A hierarchy of commonly used exception classes is provided. The root class is *Standard_Failure* from the *Standard* package. So each exception inherits from *Standard_Failure* either directly or by inheriting from another exception. Exception classes list all exceptions, which can be raised by any OCCT function.
|
||||
|
||||
Open CASCADE Technology also provides support for converting system signals (such as access violation or division by zero) to exceptions, so that such situations can be safely handled with the same uniform approach.
|
||||
|
||||
@@ -577,7 +708,7 @@ However, in order to support this functionality on various platforms, some spec
|
||||
|
||||
The following paragraphs describe recommended approaches for using exceptions when working with Open CASCADE Technology.
|
||||
|
||||
@subsubsection occt_fcug_2_4_1 Raising an Exception
|
||||
@subsubsection occt_fcug_2_4_2 Raising an Exception
|
||||
|
||||
#### “C++ like” Syntax
|
||||
|
||||
@@ -648,7 +779,7 @@ Item TCollection_Array1::Value (const Standard_Integer&index) const
|
||||
}
|
||||
~~~~~
|
||||
|
||||
@subsubsection occt_fcug_2_4_2 Handling an Exception
|
||||
@subsubsection occt_fcug_2_4_3 Handling an Exception
|
||||
|
||||
When an exception is raised, control is transferred to the nearest handler of a given type in the call stack, that is:
|
||||
* the handler whose try block was most recently entered and not yet exited,
|
||||
@@ -736,31 +867,31 @@ Normally this method is called in the beginning of the main() function. It inst
|
||||
|
||||
In order to actually convert signals to exceptions, macro *OCC_CATCH_SIGNALS* needs to be inserted in the source code. The typical place where this macro is put is beginning of the *try{}* block which catches such exceptions.
|
||||
|
||||
@subsubsection occt_fcug_2_4_3 Implementation details
|
||||
@subsubsection occt_fcug_2_4_4 Implementation on various platforms.
|
||||
|
||||
The exception handling mechanism in Open CASCADE Technology is implemented in different ways depending on the preprocessor macros *NO_CXX_EXCEPTIONS* and *OCC_CONVERT_SIGNALS*, which shall be consistently defined by compilation procedures for both Open CASCADE Technology and user applications:
|
||||
|
||||
1. On Windows and DEC, these macros are not defined by default, and normal C++ exceptions are used in all cases, including throwing from signal handler. Thus the behavior is as expected in C++.
|
||||
1. On Windows, these macros are not defined by default, and normal C++ exceptions are used in all cases, including throwing from signal handler. Thus the behavior is as expected in C++.
|
||||
|
||||
2. On SUN and Linux, macro *OCC_CONVERT_SIGNALS* is defined by default. The C++ exception mechanism is used for catching exceptions and for throwing them from normal code. Since it is not possible to throw C++ exception from system signal handler function, that function makes a long jump to the nearest (in the execution stack) invocation of macro *OCC_CATCH_SIGNALS*, and only there the C++ exception gets actually thrown. The macro *OCC_CATCH_SIGNALS* is defined in the file *Standard_ErrorHandler.hxx*. Therefore, including this file is necessary for successful compilation of a code containing this macro.
|
||||
2. On Linux, macro *OCC_CONVERT_SIGNALS* is defined by default. The C++ exception mechanism is used for catching exceptions and for throwing them from normal code. Since it is not possible to throw C++ exception from system signal handler function, that function makes a long jump to the nearest (in the execution stack) invocation of macro *OCC_CATCH_SIGNALS*, and only there the C++ exception gets actually thrown. The macro *OCC_CATCH_SIGNALS* is defined in the file *Standard_ErrorHandler.hxx*. Therefore, including this file is necessary for successful compilation of a code containing this macro.
|
||||
|
||||
This mode differs from standard C++ exception handling only for signals:
|
||||
|
||||
* macro *OCC_CATCH_SIGNALS* is necessary (besides call to *OSD::SetSignal()* described above) for conversion of signals into exceptions;
|
||||
* the destructors for automatic C++ objects created in the code after that macro and till the place where signal is raised will not be called in case of signal, since no C++ stack unwinding is performed by long jump.
|
||||
|
||||
3. On SUN and Linux Open CASCADE Technology can also be compiled in compatibility mode (which was default till Open CASCADE Technology 6.1.0). In that case macro *NO_CXX_EXCEPTIONS* is defined and the C++ exceptions are simulated with C long jumps. As a consequence, the behavior is slightly different from that expected in the C++ standard.
|
||||
3. On Linux Open CASCADE Technology can also be compiled in compatibility mode. In that case macro *NO_CXX_EXCEPTIONS* is defined and the C++ exceptions are simulated with C long jumps. As a consequence, the behavior is slightly different from that expected in the C++ standard.
|
||||
|
||||
While exception handling with NO_CXX_EXCEPTIONS is very similar to C++ by syntax, it has a number of peculiarities that should be taken into account:
|
||||
While exception handling with *NO_CXX_EXCEPTIONS* is very similar to C++ by syntax, it has a number of peculiarities that should be taken into account:
|
||||
|
||||
* try and catch are actually macros defined in the file *Standard_ErrorHandler.hxx*. Therefore, including this file is necessary for handling OCCT exceptions;
|
||||
* due to being a macro, catch cannot contain a declaration of the exception object after its type; only type is allowed in the catch statement. Use method *Standard_Failure::Caught()* to access an exception object;
|
||||
* catch macro may conflict with some STL classes that might use catch(...) statements in their header files. So STL headers should not be included after *Standard_ErrorHandler.hxx*;
|
||||
* Open CASCADE Technology try/catch block will not handle normal C++ exceptions; however this can be achieved using special workarounds;
|
||||
* the try macro defines a C++ object that holds an entry point in the exception handler. Therefore if exception is raised by code located immediately after the try/catch block but on the same nesting level as *try*, it may be handled by that *catch*. This may lead to unexpected behavior, including infinite loop. To avoid that, always surround the try/catch block in \{\} braces;
|
||||
* the destructors of the C++ objects allocated on the stack after handler initialization are not called by exception raising.
|
||||
* the try macro defines a C++ object that holds an entry point in the exception handler. Therefore if exception is raised by code located immediately after the try/catch block but on the same nesting level as *try*, it may be handled by that *catch*. This may lead to unexpected behavior, including infinite loop. To avoid that, always surround the try/catch block with curved brackets;
|
||||
* the destructors of C++ objects allocated on the stack after handler initialization are not called by exception raising.
|
||||
|
||||
In general, for writing platform-independent code it is recommended to insert macros *OCC_CATCH_SIGNALS* in try \{\} blocks or other code where signals may happen. For compatibility with previous versions of Open CASCADE Technology the limitations described above for *NO_CXX_EXCEPTIONS* shall be assumed.
|
||||
In general, for writing platform-independent code it is recommended to insert macros *OCC_CATCH_SIGNALS* in try {} blocks or other code where signals may happen. For compatibility with previous versions of Open CASCADE Technology the limitations described above for *NO_CXX_EXCEPTIONS* shall be assumed.
|
||||
|
||||
@subsection occt_fcug_2_5 Plug-In Management
|
||||
|
||||
@@ -780,9 +911,9 @@ Once it has been loaded, the call to the services provided by the plug-in is di
|
||||
#### C++ Plug-In Implementation
|
||||
|
||||
The C++ plug-in implements a service as an object with functions defined in an abstract class (this abstract class and its parent classes with the GUID are the only information about the plug-in implemented in the client application). The plug-in consists of a sharable library including a method named Factory which creates the C++ object (the client cannot instantiate this object because the plug-in implementation is not visible).
|
||||
Foundation classes provide in the package **Plugin** a method named Load(), which enables the client to access the required service through a library.
|
||||
Foundation classes provide in the package *Plugin* a method named *Load()*, which enables the client to access the required service through a library.
|
||||
|
||||
That method reads the information regarding available plug-ins and their locations from the resource file Plugin found by environment variable CSF_PluginDefaults:
|
||||
That method reads the information regarding available plug-ins and their locations from the resource file *Plugin* found by environment variable *CSF_PluginDefaults*:
|
||||
|
||||
~~~~~
|
||||
$CSF_PluginDefaults/.Plugin
|
||||
@@ -904,7 +1035,7 @@ Handle(Standard_Transient) FAFactory::Factory(const Standard_GUID& aGUID)
|
||||
|
||||
#### Without using the Software Factory
|
||||
|
||||
To create a factory without using the Software Factory, define a *dll* project under Windows or a library under UNIX by using a source file as specified above. The *FAFactory* class is implemented as follows:
|
||||
To create a factory without using the Software Factory, define a *dll* project under Windows or a library under UNIX by using a source file as specified above. The *FAFactory* class is implemented as follows:
|
||||
|
||||
~~~~~
|
||||
#include <Handle_Standard_Transient.hxx>
|
||||
@@ -920,7 +1051,7 @@ public:
|
||||
~~~~~
|
||||
|
||||
|
||||
@section occt_fcug_3 Collections, Strings and Unit Conversion
|
||||
@section occt_fcug_3 Collections, Strings, Quantities and Unit Conversion
|
||||
|
||||
@subsection occt_fcug_3_1 Collections
|
||||
|
||||
@@ -928,18 +1059,35 @@ public:
|
||||
|
||||
The **Collections** component contains the classes that handle dynamically sized aggregates of data. They include a wide range of collections such as arrays, lists and maps.
|
||||
|
||||
Collections classes are *generic*, that is, they can hold a variety of objects which do not necessarily inherit from a unique root class. When you need to use a collection of a given type of object you must *instantiate* it for this specific type of element. Once this declaration is compiled, all the functions available on the generic collection are available on your *instantiated class*.
|
||||
Collections classes are *generic* (C++ template-like), that is, they define a structure and algorithms allowing to hold a variety of objects which do not necessarily inherit from a unique root class (similarly to C++ templates).
|
||||
|
||||
When you need to use a collection of a given type of object you must *instantiate* it for this specific type of element. Once this declaration is compiled, all the functions available on the generic collection are available on your *instantiated class*.
|
||||
|
||||
However, note that:
|
||||
* Each collection directly used as an argument in OCCT public syntax is instantiated in an OCCT component.
|
||||
* The *TColStd* package (**Collections of Standard Objects** component) provides numerous instantiations of these generic collections with objects from the **Standard** package or from the **Strings** component.
|
||||
The **Collections** component provides a wide range of generic collections:
|
||||
* **Arrays** are generally used for a quick access to the item, however an array is a fixed sized aggregate.
|
||||
* **Sequences** are variable-sized structures, they avoid the use of large and quasi-empty arrays. A sequence item is longer to access than an array item: only an exploration in sequence is effective (but sequences are not adapted for numerous explorations). Arrays and sequences are commonly used as data structures for more complex objects.
|
||||
* On the other hand, **maps** are dynamic structures where the size is constantly adapted to the number of inserted items and the access time for an item is effective. Maps structures are commonly used in cases of numerous explorations: they are typically internal data structures for complex algorithms. **Sets** generate the same results as maps but computation time is considerable.
|
||||
* **Lists, queues** and **stacks** are minor structures similar to sequences but with other exploration algorithms.
|
||||
* **Maps** are dynamic structures, where the size is constantly adapted to the number of inserted items and access to an item is the fastest. Maps structures are commonly used in cases of numerous explorations: they are typically internal data structures for complex algorithms.
|
||||
* **Lists** are similar to sequences but have different algorithms to explore them.
|
||||
* Specific iterators for sequences and maps.
|
||||
|
||||
Most collections follow value semantics: their instances are the actual collections, not **handles** to a collection. Only arrays and sequences may also be manipulated by handle, and therefore shared.
|
||||
|
||||
Each collection directly used as an argument in Open CASCADE Technology public syntax
|
||||
is instantiated in an OCCT component using the corresponding generic class in package
|
||||
<i> TCollection</i>, by means of compiling the CDL declaration of the instance.
|
||||
Thus OCCT generic classes require compilation of definitions in the CDL language and therefore
|
||||
can only be instantiated in WOK.
|
||||
|
||||
If you do not use CDL in your project (CDL compilation under WOK is necessary
|
||||
to instantiate any generic Collection from package <i>TCollection</i>), then you should
|
||||
use the Collections defined in <i> NCollection</i> package. It contains definitions of the
|
||||
same generic collection classes described above, but in a form of C++ templates.
|
||||
Therefore, to instantiate any collection type no additional support is required beyond
|
||||
the ANSI C++ compiler.
|
||||
|
||||
@subsubsection occt_fcug_3_1_2 Generic general-purpose Aggregates
|
||||
|
||||
#### TCollection_Array1
|
||||
@@ -1059,7 +1207,6 @@ Maps are dynamically extended data structures where data is quickly accessed wi
|
||||
|
||||
#### General properties of maps
|
||||
|
||||
|
||||
Map items may contain complex non-unitary data, thus it can be difficult to manage them with an array. The map allows a data structure to be indexed by complex data.
|
||||
|
||||
The size of a map is dynamically extended. So a map may be first dimensioned for a little number of items. Maps avoid the use of large and quasi-empty arrays.
|
||||
@@ -1583,9 +1730,15 @@ As one possible choice, the class *NCollection_IncAllocator* is included. Unlike
|
||||
|
||||
@subsection occt_fcug_3_4 Strings
|
||||
|
||||
The **Strings** component provides services to manipulate character strings.
|
||||
**Strings** are classes that handle dynamically sized sequences of characters based on both ASCII (normal 8-bit character type) and Unicode (16-bit character type). They provide editing operations with built-in memory management which make the relative objects easier to use than ordinary character arrays.
|
||||
*Strings* may also be manipulated by *handle*, and therefore shared.
|
||||
Strings are classes that handle dynamically sized sequences of characters based on
|
||||
ASCII/Unicode UTF-8 (normal 8-bit character type) and UTF-16/UCS-2 (16-bit character type). They provide editing operations with built-in memory management which make the relative objects easier to use than ordinary character arrays.
|
||||
|
||||
String classes provide the following services to manipulate character strings:
|
||||
* Editing operations on string objects, using a built-in string manager
|
||||
* Handling of dynamically-sized sequences of characters
|
||||
* Conversion from/to ASCII and UTF-8 strings.
|
||||
|
||||
Strings may also be manipulated by handles and therefore shared.
|
||||
|
||||
@subsubsection occt_fcug_3_4_1 Examples
|
||||
|
||||
@@ -1620,7 +1773,27 @@ A variable-length sequence of extended; (UNICODE) characters (16-bit character
|
||||
|
||||
*Resource_Unicode* provides functions to convert a non-ASCII *C string* given in ANSI, EUC, GB or SJIS format, to a Unicode string of extended characters, and vice versa.
|
||||
|
||||
@subsection occt_fcug_3_5 Unit Conversion
|
||||
@subsection occt_fcug_3_5 Quantities
|
||||
|
||||
Quantities are various classes supporting date and time information and fundamental types representing most physical quantities such as length, area, volume, mass, density, weight, temperature, pressure etc.
|
||||
|
||||
Quantity classes provide the following services:
|
||||
* Definition of primitive types representing most of mathematical and physical quantities;
|
||||
* Unit conversion tools providing a uniform mechanism for dealing with quantities and associated physical units: check unit compatibility, perform conversions of values between different units, etc. (see package *UnitsAPI*)
|
||||
* Resources to manage time information such as dates and time periods
|
||||
* Resources to manage color definition
|
||||
|
||||
A mathematical quantity is characterized by the name and the value (real).
|
||||
|
||||
A physical quantity is characterized by the name, the value (real) and the unit. The unit may be either an international unit complying with the International Unit System (SI) or a user defined unit. The unit is managed by the physical quantity user.
|
||||
|
||||
The fact that both physical and mathematical quantities are manipulated as real values means that :
|
||||
* They are defined as aliases of real values, so all functions provided by the <i>Standard_Real</i> class are available on each quantity.
|
||||
* It is possible to mix several physical quantities in a mathematical or physical formula involving real values.
|
||||
|
||||
<i>Quantity</i> package includes all commonly used basic physical quantities.
|
||||
|
||||
@subsection occt_fcug_3_6 Unit Conversion
|
||||
|
||||
The *UnitsAPI* global functions are used to convert a value from any unit into another unit. Conversion is executed among three unit systems:
|
||||
* the **SI System**,
|
||||
@@ -1636,15 +1809,32 @@ A physical quantity is defined by a string (example: LENGTH).
|
||||
|
||||
|
||||
@section occt_occt_fcug_4 Math Primitives and Algorithms
|
||||
|
||||
@subsection occt_occt_fcug_4_1 Overview
|
||||
|
||||
Math primitives and algorithms available in Open CASCADE Technology include:
|
||||
* Vectors and matrices
|
||||
* Geometric primitives
|
||||
* Math algorithms
|
||||
|
||||
@subsection occt_occt_fcug_4_2 Vectors and Matrices
|
||||
The Vectors and Matrices component provides a C++ implementation of the fundamental types Matrix and Vector, currently used to define more complex data structures. The Vector and Matrix classes support vectors and matrices of real values with standard operations such as addition, multiplication, transposition, inversion etc.
|
||||
Vectors and matrices have arbitrary ranges which must be defined at declaration time and cannot be changed after declaration.
|
||||
|
||||
The Vectors and Matrices component provides a C++ implementation of the fundamental types *Vector* and *Matrix*, which are regularly used to define more complex data structures.
|
||||
|
||||
The <i> Vector</i> and <i> Matrix </i> classes provide commonly used mathematical algorithms which
|
||||
include:
|
||||
|
||||
* Basic calculations involving vectors and matrices;
|
||||
* Computation of eigenvalues and eigenvectors of a square matrix;
|
||||
* Solvers for a set of linear algebraic equations;
|
||||
* Algorithms to find the roots of a set of non-linear equations;
|
||||
* Algorithms to find the minimum function of one or more independent variables.
|
||||
|
||||
These classes also provide a data structure to represent any expression,
|
||||
relation, or function used in mathematics, including the assignment of variables.
|
||||
|
||||
Vectors and matrices have arbitrary ranges which must be defined at declaration time
|
||||
and cannot be changed after declaration.
|
||||
|
||||
~~~~~
|
||||
math_Vector v(1, 3);
|
||||
@@ -1694,26 +1884,38 @@ v1(0) = 2.0;
|
||||
~~~~~~
|
||||
|
||||
@subsection occt_occt_fcug_4_3 Primitive Geometric Types
|
||||
Before creating a geometric object, you must decide whether you are in a 2d or in a 3d context and how you want to handle the object.
|
||||
The *gp* package offers classes for both 2d and 3d objects which are handled by value rather than by reference. When this sort of object is copied, it is copied entirely. Changes in one instance will not be reflected in another.
|
||||
|
||||
Open CASCADE Technology primitive geometric types are a STEP-compliant implementation of basic geometric and algebraic entities.
|
||||
They provide:
|
||||
* Descriptions of primitive geometric shapes, such as:
|
||||
* Points;
|
||||
* Vectors;
|
||||
* Lines;
|
||||
* Circles and conics;
|
||||
* Planes and elementary surfaces;
|
||||
* Positioning of these shapes in space or in a plane by means of an axis or a coordinate system;
|
||||
* Definition and application of geometric transformations to these shapes:
|
||||
* Translations;
|
||||
* Rotations;
|
||||
* Symmetries;
|
||||
* Scaling transformations;
|
||||
* Composed transformations;
|
||||
* Tools (coordinates and matrices) for algebraic computation.
|
||||
|
||||
All these functions are provided by geometric processor package <i> gp</i>. Its classes for 2d and 3d objects are handled by value rather than by reference. When this sort of object is copied, it is copied entirely. Changes in one instance will not be reflected in another.
|
||||
|
||||
The *gp* package defines the basic non-persistent geometric entities used for algebraic calculation and basic analytical geometry in 2d & 3d space. It also provides basic transformations such as identity, rotation, translation, mirroring, scale transformations, combinations of transformations, etc. Entities are handled by value.
|
||||
The available geometric entities are:
|
||||
* 2d & 3d Cartesian coordinates (x, y, z)
|
||||
* Matrices
|
||||
* Cartesian points
|
||||
* Vector
|
||||
* Direction
|
||||
* Axis
|
||||
* Line
|
||||
* Circle
|
||||
* Ellipse
|
||||
* Hyperbola
|
||||
* Parabola
|
||||
* Plane
|
||||
* Infinite cylindrical surface
|
||||
* Spherical surface
|
||||
* Toroidal surface
|
||||
* Conical surface.
|
||||
|
||||
Please, note that <i> gp</i> curves and surfaces are analytic: there is no parameterization and no orientation on <i>gp</i> entities, i.e. these entities do not provide functions which work with these properties.
|
||||
|
||||
If you need, you may use more evolved data structures provided by <i> Geom</i> (in 3D space) and <i> Geom2d</i> (in the plane). However, the definition of <i> gp</i> entities is identical to the one of equivalent <i> Geom</i> and <i> Geom2d</i> entities, and they are located in the plane or in space with the same kind of positioning systems. They implicitly contain the orientation, which they express on the <i> Geom </i> and <i> Geom2d </i> entities, and they induce the definition of their parameterization.
|
||||
|
||||
Therefore, it is easy to give an implicit parameterization to <i> gp</i> curves and surfaces, which is the parametrization of the equivalent <i> Geom</i> or <i> Geom2d</i> entity. This property is particularly useful when computing projections or intersections, or for operations involving complex algorithms where it is particularly important to manipulate the simplest data structures, i.e. those of <i> gp</i>. Thus, <i> ElCLib</i> and <i> ElSLib</i> packages provide functions to compute:
|
||||
* the point of parameter u on a 2D or 3D gp curve,
|
||||
* the point of parameter (u,v) on a gp elementary surface, and
|
||||
* any derivative vector at this point.
|
||||
|
||||
Note: the <i> gp</i> entities cannot be shared when they are inside more complex data structures.
|
||||
|
||||
@subsection occt_occt_fcug_4_4 Collections of Primitive Geometric Types
|
||||
|
||||
|
@@ -5,10 +5,19 @@ IGES Support {#occt_user_guides__iges}
|
||||
|
||||
@section occt_iges_1 Introduction
|
||||
|
||||
The IGES interface reads IGES files and translates them to Open CASCADE Technology models. The interface is able to translate one entity, a group of entities or a whole file. Before beginning a translation, you can set a range of parameters to manage the translation process. If you like, you can also check file consistency before translation. The IGES interface also translates OCCT models to IGES files.
|
||||
|
||||
This manual explains how to convert an IGES file to an Open CASCADE Technology (**OCCT**) shape and vice versa. It provides basic documentation on conversion. For advanced information on conversion, see our offerings on our web site at <a href="http://www.opencascade.org/support/training/">www.opencascade.org/support/training/</a>
|
||||
Other kinds of data such as colors and names can be read or written with the help of XDE tools <i> IGESCAFControl_Reader</i> and <i> IGESCAFControl_Writer</i>.
|
||||
|
||||
IGES files up to and including IGES version 5.3 can be read. IGES files that are produced by this interface conform to IGES version 5.3 (Initial Graphics Exchange Specification, IGES 5.3. ANS US PRO/IPO-100-1996).
|
||||
Please, note:
|
||||
|
||||
* an IGES model is an IGES file that has been loaded into memory.
|
||||
* an IGES entity is an entity in the IGES normal sense.
|
||||
* a root entity is the highest level entity of any given type, e.g. type 144 for surfaces and type 186 for solids. Roots are not referenced by other entities.
|
||||
|
||||
This manual mainly explains how to convert an IGES file to an Open CASCADE Technology (**OCCT**) shape and vice versa. It provides basic documentation on conversion. For advanced information on conversion, see our offerings on our web site at <a href="http://www.opencascade.org/support/training/">www.opencascade.org/support/training/</a>
|
||||
|
||||
IGES files produced in accordance with IGES standard versions up to and including version 5.3 can be read. IGES files that are produced by this interface conform to IGES version 5.3 (Initial Graphics Exchange Specification, IGES 5.3. ANS US PRO/IPO-100-1996).
|
||||
|
||||
This manual principally deals with two OCCT classes:
|
||||
* The Reader class, which loads IGES files and translates their contents to OCCT shapes,
|
||||
@@ -18,6 +27,8 @@ File translation is performed in the programming mode, via C++ calls, and the r
|
||||
|
||||
All definitions in IGES version 5.3 are recognized but only 3D geometric entities are translated. When the processor encounters data, which is not translated, it ignores it and writes a message identifying the types of data, which was not handled. This message can be written either to a log file or to screen output.
|
||||
|
||||
@ref occt_user_guides__shape_healing "Shape Healing" toolkit provides tools to heal various problems, which may be encountered in translated shapes, and to make them valid in Open CASCADE. The Shape Healing is smoothly connected to IGES translator using the same API, only the names of API packages change.
|
||||
|
||||
@section occt_iges_2 Reading IGES
|
||||
@subsection occt_iges_2_1 Procedure
|
||||
You can translate an IGES file to an OCCT shape by following the steps below:
|
||||
|
Before Width: | Height: | Size: 14 KiB |
After Width: | Height: | Size: 1.9 KiB |
After Width: | Height: | Size: 14 KiB |
After Width: | Height: | Size: 47 KiB |
After Width: | Height: | Size: 30 KiB |
@@ -5,24 +5,37 @@ Modeling Data {#occt_user_guides__modeling_data}
|
||||
|
||||
@section occt_modat_0 Introduction
|
||||
|
||||
Modeling Data supplies data structures to represent 2D and 3D geometric models. This manual explains how to use Modeling Data. For advanced information on modeling data, see our offerings on our web site at <a href="http://www.opencascade.org/support/training/">www.opencascade.org/support/training/</a>
|
||||
Modeling Data supplies data structures to represent 2D and 3D geometric models.
|
||||
|
||||
This manual explains how to use Modeling Data. For advanced information on modeling data, see our offerings on our web site at <a href="http://www.opencascade.org/support/training/">www.opencascade.org/support/training/</a>.
|
||||
|
||||
@section occt_modat_1 Geometry Utilities
|
||||
|
||||
Geometry Utilities provide the following services:
|
||||
* Creation of shapes by interpolation and approximation
|
||||
* Direct construction of shapes
|
||||
* Conversion of curves and surfaces to Bspline curves and surfaces
|
||||
* Conversion of curves and surfaces to BSpline curves and surfaces
|
||||
* Computation of the coordinates of points on 2D and 3D curves
|
||||
* Calculation of extrema between shapes.
|
||||
|
||||
@subsection occt_modat_1_1 Interpolations and Approximations
|
||||
|
||||
In modeling, it is often required to approximate or interpolate points into curves and surfaces. In interpolation, the process is complete when the curve or surface passes through all the points; in approximation, when it is as close to these points as possible. This component provides both high and low level services to approximate or interpolate points into curves and surfaces. The lower level services allow performing parallel approximation of groups of points into groups of Bezier or B-spline curves.
|
||||
In modeling, it is often required to approximate or interpolate points into curves and surfaces. In interpolation, the process is complete when the curve or surface passes through all the points; in approximation, when it is as close to these points as possible.
|
||||
|
||||
Approximation of Curves and Surfaces groups together a variety of functions used in 2D and 3D geometry for:
|
||||
* the interpolation of a set of 2D points using a 2D BSpline or Bezier curve;
|
||||
* the approximation of a set of 2D points using a 2D BSpline or Bezier curve;
|
||||
* the interpolation of a set of 3D points using a 3D BSpline or Bezier curve, or a BSpline surface;
|
||||
* the approximation of a set of 3D points using a 3D BSpline or Bezier curve, or a BSpline surface.
|
||||
|
||||
You can program approximations in two ways:
|
||||
|
||||
* Using high-level functions, designed to provide a simple method for obtaining approximations with minimal programming,
|
||||
* Using low-level functions, designed for users requiring more control over the approximations.
|
||||
|
||||
@subsubsection occt_modat_1_1_1 Analysis of a set of points
|
||||
|
||||
The class *PEquation* from *GProp* package allows analyzng a collection or cloud of points and verifying if they are coincident, collinear or coplanar within a given precision. If they are, the algorithm computes the mean point, the mean line or the mean plane of the points. If they are not, the algorithm computes the minimal box, which includes all the points.
|
||||
The class *PEquation* from *GProp* package allows analyzing a collection or cloud of points and verifying if they are coincident, collinear or coplanar within a given precision. If they are, the algorithm computes the mean point, the mean line or the mean plane of the points. If they are not, the algorithm computes the minimal box, which includes all the points.
|
||||
|
||||
@subsubsection occt_modat_1_1_2 Basic Interpolation and Approximation
|
||||
|
||||
@@ -78,6 +91,15 @@ The class **PointsToBSplineSurface** from GeomAPI package allows building a BSpl
|
||||
|
||||
Packages *AppDef* and *AppParCurves* provide low-level functions, allowing more control over the approximations.
|
||||
|
||||
The low-level functions provide a second API with functions to:
|
||||
* Define compulsory tangents for an approximation. These tangents have origins and extremities.
|
||||
* Approximate a set of curves in parallel to respect identical parameterization.
|
||||
* Smooth approximations. This is to produce a faired curve.
|
||||
|
||||
You can also find functions to compute:
|
||||
* The minimal box which includes a set of points
|
||||
* The mean plane, line or point of a set of coplanar, collinear or coincident points.
|
||||
|
||||
#### Approximation by multiple point constraints
|
||||
|
||||
*AppDef* package provides low-level tools to allow parallel approximation of groups of points into Bezier or B-Spline curves using multiple point constraints.
|
||||
@@ -86,7 +108,7 @@ The following low level services are provided:
|
||||
|
||||
* Definition of an array of point constraints:
|
||||
|
||||
The class *MultiLine* allows defining a given number of multipoint constraints in order to build the multi-line, multiple lines passing through ordered multiple point constraints.
|
||||
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"
|
||||
@@ -98,7 +120,7 @@ The following low level services are provided:
|
||||
|
||||
* Definition of a set of point constraints:
|
||||
|
||||
The class **MultiPointConstraint** allows defining a multiple point constraint and computing the approximation of sets of points to several curves.
|
||||
The class *MultiPointConstraint* allows defining a multiple point constraint and computing the approximation of sets of points to several curves.
|
||||
|
||||
* Computation of an approximation of a Bezier curve from a set of points:
|
||||
|
||||
@@ -106,7 +128,7 @@ The following low level services are provided:
|
||||
|
||||
* Computation of an approximation of a BSpline curve from a set of points:
|
||||
|
||||
The class **BSplineCompute** allows making an approximation of a set of points to a BSpline curve.
|
||||
The class *BSplineCompute* allows making an approximation of a set of points to a BSpline curve.
|
||||
|
||||
* Definition of Variational Criteria:
|
||||
|
||||
@@ -138,13 +160,48 @@ The class *MultiBSpCurve* allows defining the approximation of a multi-line made
|
||||
* Definition of points making up a set of point constraints
|
||||
|
||||
The class *MultiPoint* allows defining groups of 2D or 3D points making up a multi-line.
|
||||
|
||||
#### Example: How to approximate a curve with respect to tangency
|
||||
|
||||
To approximate a curve with respect to tangency, follow these steps:
|
||||
|
||||
1. Create an object of type <i> AppDef_MultiPointConstraints</i> from the set of points to approximate and use the method <i> SetTang </i>to set the tangency vectors.
|
||||
2. Create an object of type <i> AppDef_MultiLine </i>from the <i> AppDef_MultiPointConstraint</i>.
|
||||
3. Use <i> AppDef_BSplineCompute</i>, which instantiates <i>Approx_BSplineComputeLine</i> to perform the approximation.
|
||||
|
||||
@subsection occt_modat_1_2 Direct Construction
|
||||
|
||||
Direct Construction methods from *gce*, *GC* and *GCE2d* packages provide simplified algorithms to build elementary geometric entities such as lines, circles and curves. They complement the reference definitions provided by the *gp*, *Geom* and *Geom2d* packages.
|
||||
|
||||
The algorithms implemented by <i> gce</i>, <i> GCE2d</i> and <i> GC</i> packages are simple: there is no creation of objects defined by advanced positional constraints (for more information on this subject, see *Geom2dGcc* and *GccAna*, which describe geometry by constraints).
|
||||
|
||||
For example, to construct a circle from a point and a radius using the *gp* package, it is necessary to construct axis *Ax2d* before creating the circle. If *gce* package is used, and *Ox* is taken for the axis, it is possible to create a circle directly from a point and a radius.
|
||||
|
||||
Another example is the class <i>gce_MakeCirc</i> providing a framework for defining eight problems encountered in the geometric construction of circles and implementing the eight related construction algorithms.
|
||||
|
||||
The object created (or implemented) is an algorithm which can be consulted to find out, in particular:
|
||||
|
||||
* its result, which is a <i>gp_Circ</i>, and
|
||||
* its status. Here, the status indicates whether or not the construction was successful.
|
||||
|
||||
If it was unsuccessful, the status gives the reason for the failure.
|
||||
|
||||
~~~~
|
||||
gp_Pnt P1 (0.,0.,0.);
|
||||
gp_Pnt P2 (0.,10.,0.);
|
||||
gp_Pnt P3 (10.,0.,0.);
|
||||
gce_MakeCirc MC (P1,P2,P3);
|
||||
if (MC.IsDone()) {
|
||||
const gp_Circ& C = MC.Value();
|
||||
}
|
||||
~~~~
|
||||
|
||||
In addition, <i> gce</i>, <i> GCE2d</i> and <i> GC</i> each have a <i>Root</i> class. This class is the root of all classes in the package, which return a status. The returned status (successful
|
||||
construction or construction error) is described by the enumeration <i>gce_ErrorType</i>.
|
||||
|
||||
Note, that classes, which construct geometric transformations do not return a status, and therefore do not inherit from *Root*.
|
||||
|
||||
|
||||
@subsubsection occt_modat_1_2_1 Non-persistent entities
|
||||
|
||||
The following algorithms used to build entities from non-persistent *gp* entities are provided by *gce* package.
|
||||
@@ -245,16 +302,52 @@ The following classes return objects of type *TrimmedCurve* from *Geom*:
|
||||
|
||||
@subsection occt_modat_1_3 Conversion to and from BSplines
|
||||
|
||||
The following algorithms to convert geometric curves or surfaces into their BSpline or Bezier equivalents are provided by *GeomConvert*, *Geom2dConvert* and *Convert* packages:
|
||||
- Conversion of a conic into a rational BSpline.
|
||||
- Conversion of an elementary surface into a rational Bspline.
|
||||
- Conversion of a BSpline or Bezier curve into two or more Bezier curves or surfaces.
|
||||
- Conversion of a BSpline curve or surface into two or more BSplinecurves or surfaces with constraints on continuity.
|
||||
- Conversion of a set of joining Bezier curves into a BSplinecurve.
|
||||
- Conversion of a polynomial representation into a BSpline curve.
|
||||
The Conversion to and from BSplines component has two distinct purposes:
|
||||
* Firstly, it provides a homogeneous formulation which can be used to describe any curve or surface.
|
||||
This is useful for writing algorithms for a single data structure model.
|
||||
The BSpline formulation can be used to represent most basic geometric objects provided
|
||||
by the components which describe geometric data structures ("Fundamental Geometry Types", "2D Geometry Types" and "3D Geometry Types" components).
|
||||
* Secondly, it can be used to divide a BSpline curve or surface into a series of curves or surfaces,
|
||||
thereby providing a higher degree of continuity. This is useful for writing algorithms
|
||||
which require a specific degree of continuity in the objects to which they are applied.
|
||||
Discontinuities are situated on the boundaries of objects only.
|
||||
|
||||
The "Conversion to and from BSplines" component is composed of three packages.
|
||||
|
||||
The <i> Convert </i> package provides algorithms to convert the following into a BSpline curve or surface:
|
||||
|
||||
* a bounded curve based on an elementary 2D curve (line, circle or conic) from the <i> gp </i> package,
|
||||
* a bounded surface based on an elementary surface (cylinder, cone, sphere or torus) from the <i> gp</i> package,
|
||||
* a series of adjacent 2D or 3D Bezier curves defined by their poles.
|
||||
|
||||
These algorithms compute the data needed to define the resulting BSpline curve or surface.
|
||||
This elementary data (degrees, periodic characteristics, poles and weights, knots and multiplicities)
|
||||
may then be used directly in an algorithm, or can be used to construct the curve or the surface
|
||||
by calling the appropriate constructor provided by the classes <i>Geom2d_BSplineCurve, Geom_BSplineCurve </i> or <i>Geom_BSplineSurface</i>.
|
||||
|
||||
The <i>Geom2dConvert</i> package provides the following:
|
||||
|
||||
* a global function which is used to construct a BSpline curve from a bounded curve based on a 2D curve from the Geom2d package,
|
||||
* a splitting algorithm which computes the points at which a 2D BSpline curve should be cut in order to obtain arcs with the same degree of continuity,
|
||||
* global functions used to construct the BSpline curves created by this splitting algorithm, or by other types of segmentation of the BSpline curve,
|
||||
* an algorithm which converts a 2D BSpline curve into a series of adjacent Bezier curves.
|
||||
|
||||
The <i> GeomConvert</i> package also provides the following:
|
||||
|
||||
* a global function used to construct a BSpline curve from a bounded curve based on a curve from the Geom package,
|
||||
* a splitting algorithm, which computes the points at which a BSpline curve should be cut in order to obtain arcs with the same degree of continuity,
|
||||
* global functions to construct BSpline curves created by this splitting algorithm, or by other types of BSpline curve segmentation,
|
||||
* an algorithm, which converts a BSpline curve into a series of adjacent Bezier curves,
|
||||
* a global function to construct a BSpline surface from a bounded surface based on a surface from the Geom package,
|
||||
* a splitting algorithm, which determines the curves along which a BSpline surface should be cut in order to obtain patches with the same degree of continuity,
|
||||
* global functions to construct BSpline surfaces created by this splitting algorithm, or by other types of BSpline surface segmentation,
|
||||
* an algorithm, which converts a BSpline surface into a series of adjacent Bezier surfaces,
|
||||
* an algorithm, which converts a grid of adjacent Bezier surfaces into a BSpline surface.
|
||||
|
||||
@subsection occt_modat_1_4 Points on Curves
|
||||
|
||||
The Points on Curves component comprises high level functions providing an API for complex algorithms that compute points on a 2D or 3D curve.
|
||||
|
||||
The following characteristic points exist on parameterized curves in 3d space:
|
||||
- points equally spaced on a curve,
|
||||
- points distributed along a curve with equal chords,
|
||||
@@ -267,7 +360,6 @@ The following characteristic points exist on parameterized curves in 3d space:
|
||||
|
||||
### Example: Visualizing a curve.
|
||||
|
||||
|
||||
Let us take an adapted curve **C**, i.e. an object which is an interface between the services provided by either a 2D curve from the package Geom2d (in case of an Adaptor_Curve2d curve) or a 3D curve from the package Geom (in case of an Adaptor_Curve curve), and the services required on the curve by the computation algorithm. The adapted curve is created in the following way:
|
||||
|
||||
**2D case :**
|
||||
@@ -312,23 +404,30 @@ These packages calculate the extrema of distance between:
|
||||
- a curve and a surface,
|
||||
- two surfaces.
|
||||
|
||||
@subsubsection occt_modat_1_5_1 Extrema between Curves
|
||||
### Extrema between Curves
|
||||
|
||||
The *Geom2dAPI_ExtremaCurveCurve* class allows calculation of all extrema between two 2D geometric curves. Extrema are the lengths of the segments orthogonal to two curves.
|
||||
|
||||
The *GeomAPI_ExtremaCurveCurve* class allows calculation of all extrema between two 3D geometric curves. Extrema are the lengths of the segments orthogonal to two curves.
|
||||
|
||||
@subsubsection occt_modat_1_5_2 Extrema between Curve and Surface
|
||||
### Extrema between Curve and Surface
|
||||
|
||||
The *GeomAPI_ExtremaCurveSurface* class allows calculation of all extrema between a 3D curve and a surface. Extrema are the lengths of the segments orthogonal to the curve and the surface.
|
||||
|
||||
@subsubsection occt_modat_1_5_3 Extrema between Surfaces
|
||||
### Extrema between Surfaces
|
||||
|
||||
The *GeomAPI_ExtremaSurfaceSurface* class allows calculation of all extrema between two surfaces. Extrema are the lengths of the segments orthogonal to two surfaces.
|
||||
|
||||
@section occt_modat_2 2D Geometry
|
||||
|
||||
*Geom2d* package defines geometric objects in 2dspace. All geometric entities are STEP processed. The objects are non-persistent and are handled by reference. The following objects are available:
|
||||
*Geom2d* package defines geometric objects in 2dspace. All geometric entities are STEP processed. The objects are non-persistent and are handled by reference.
|
||||
|
||||
In particular, <i>Geom2d</i> package provides classes for:
|
||||
* description of points, vectors and curves,
|
||||
* their positioning in the plane using coordinate systems,
|
||||
* their geometric transformation, by applying translations, rotations, symmetries, scaling transformations and combinations thereof.
|
||||
|
||||
The following objects are available:
|
||||
- point,
|
||||
- Cartesian point,
|
||||
- vector,
|
||||
@@ -337,9 +436,9 @@ The *GeomAPI_ExtremaSurfaceSurface* class allows calculation of all extrema betw
|
||||
- axis,
|
||||
- curve,
|
||||
- line,
|
||||
- conic: circle, ellipse, hyperbola, pparabola,
|
||||
- rounded curve: trimmed curve, NURBS curve, Bezier curve.
|
||||
- offset curve
|
||||
- conic: circle, ellipse, hyperbola, parabola,
|
||||
- rounded curve: trimmed curve, NURBS curve, Bezier curve,
|
||||
- offset curve.
|
||||
|
||||
Before creating a geometric object, it is necessary to decide how the object is handled.
|
||||
The objects provided by *Geom2d* package are handled by reference rather than by value. Copying an instance copies the handle, not the object, so that a change to one instance is reflected in each occurrence of it.
|
||||
@@ -347,9 +446,45 @@ If a set of object instances is needed rather than a single object instance, *
|
||||
- handled by reference and
|
||||
- handled by value.
|
||||
|
||||
The key characteristic of <i> Geom2d </i> curves is that they are parameterized.
|
||||
Each class provides functions to work with the parametric equation of the curve,
|
||||
and, in particular, to compute the point of parameter u on a curve and the derivative vectors of order 1, 2.., N at this point.
|
||||
|
||||
As a consequence of the parameterization, a <i> Geom2d </i> curve is naturally oriented.
|
||||
|
||||
Parameterization and orientation differentiate elementary <i>Geom2d </i>curves from their
|
||||
equivalent as provided by <i> gp</i> package. <i> Geom2d</i> package provides conversion
|
||||
functions to transform a <i> Geom2d</i> object into a <i> gp</i> object, and vice-versa, when this is possible.
|
||||
|
||||
Moreover, <i> Geom2d</i> package provides more complex curves, including Bezier curves,
|
||||
BSpline curves, trimmed curves and offset curves.
|
||||
|
||||
<i> Geom2d </i> objects are organized according to an inheritance structure over several levels.
|
||||
|
||||
Thus, an ellipse (specific class <i> Geom2d_Ellipse</i>) is also a conical curve and inherits from the abstract class <i> Geom2d_Conic</i>, while a Bezier curve (concrete class <i> Geom2d_BezierCurve</i>) is also a bounded curve and inherits from the abstract class <i> Geom2d_BoundedCurve</i>; both these examples are also curves (abstract class <i>Geom2d_Curve</i>). Curves, points and vectors inherit from the abstract class <i> Geom2d_Geometry,</i> which describes the properties common to any geometric object from the <i>Geom2d</i> package.
|
||||
|
||||
This inheritance structure is open and it is possible to describe new objects, which inherit from those provided in the <i>Geom2d</i> package, provided that they respect the behavior of the classes from which they are to inherit.
|
||||
|
||||
Finally, <i> Geom2d</i> objects can be shared within more complex data structures. This is why they are used within topological data structures, for example.
|
||||
|
||||
<i>Geom2d</i>package uses the services of the <i> gp</i> package to:
|
||||
* implement elementary algebraic calculus and basic analytic geometry,
|
||||
* describe geometric transformations which can be applied to <i> Geom2d</i> objects,
|
||||
* describe the elementary data structures of <i>Geom2d</i> objects.
|
||||
|
||||
However, the <i> Geom2d</i> package essentially provides data structures and not algorithms.
|
||||
You can refer to the <i> GCE2d </i> package to find more evolved construction algorithms for <i> Geom2d </i> objects.
|
||||
|
||||
@section occt_modat_3 3D Geometry
|
||||
|
||||
The *Geom* package defines geometric objects in 3d space and contains all basic geometric transformations, such as identity, rotation, translation, mirroring, scale transformations, combinations of transformations, etc. as well as special functions depending on the reference definition of the geometric object (e.g. addition of a control point on a B-Spline curve,modification of a curve, etc.). All geometrical entities are STEP processed. The following non-persistent and reference-handled objects are available:
|
||||
The *Geom* package defines geometric objects in 3d space and contains all basic geometric transformations, such as identity, rotation, translation, mirroring, scale transformations, combinations of transformations, etc. as well as special functions depending on the reference definition of the geometric object (e.g. addition of a control point on a B-Spline curve,modification of a curve, etc.). All geometrical entities are STEP processed.
|
||||
|
||||
In particular, it provides classes for:
|
||||
* description of points, vectors, curves and surfaces,
|
||||
* their positioning in 3D space using axis or coordinate systems, and
|
||||
* their geometric transformation, by applying translations, rotations, symmetries, scaling transformations and combinations thereof.
|
||||
|
||||
The following non-persistent and reference-handled objects are available:
|
||||
- Point
|
||||
- Cartesian point
|
||||
- Vector
|
||||
@@ -366,13 +501,125 @@ The *Geom* package defines geometric objects in 3d space and contains all basic
|
||||
- Swept surface: surface of linear extrusion, surface of revolution
|
||||
- Offset surface.
|
||||
|
||||
The key characteristic of *Geom* curves and surfaces is that they are parameterized.
|
||||
Each class provides functions to work with the parametric equation of the curve or
|
||||
surface, and, in particular, to compute:
|
||||
* the point of parameter u on a curve, or
|
||||
* the point of parameters (u, v) on a surface.
|
||||
together with the derivative vectors of order 1, 2, ... N at this point.
|
||||
|
||||
As a consequence of this parameterization, a Geom curve or surface is naturally oriented.
|
||||
|
||||
Parameterization and orientation differentiate elementary Geom curves and surfaces from the classes of the same (or similar) names found in <i> gp</i> package.
|
||||
<i>Geom</i> package also provides conversion functions to transform a Geom object into a <i> gp</i> object, and vice-versa, when such transformation is possible.
|
||||
|
||||
Moreover, <i> Geom </i>package provides more complex curves and surfaces, including:
|
||||
* Bezier and BSpline curves and surfaces,
|
||||
* swept surfaces, for example surfaces of revolution and surfaces of linear extrusion,
|
||||
* trimmed curves and surfaces, and
|
||||
* offset curves and surfaces.
|
||||
|
||||
Geom objects are organized according to an inheritance structure over several levels.
|
||||
Thus, a sphere (concrete class <i> Geom_SphericalSurface</i>) is also an elementary surface and inherits from the abstract class <i> Geom_ElementarySurface</i>, while a Bezier surface (concrete class <i> Geom_BezierSurface</i>) is also a bounded surface and inherits from the abstract class <i> Geom_BoundedSurface</i>; both these examples are also surfaces (abstract class <i> Geom_Surface</i>). Curves, points and vectors inherit from the abstract class <i> Geom_Geometry,</i> which describes the properties common to any geometric object from the <i>Geom</i> package.
|
||||
|
||||
This inheritance structure is open and it is possible to describe new objects, which inherit from those provided in the Geom package, on the condition that they respect the behavior of the classes from which they are to inherit.
|
||||
|
||||
Finally, Geom objects can be shared within more complex data structures. This is why they are used within topological data structures, for example.
|
||||
|
||||
If a set of object instances is needed rather than a single object instance, *TColGeom* package can be used. This package provides instantiations of one- and two-dimensional arrays and sequences for curves from *Geom* package. All objects are available in two versions:
|
||||
- handled by reference and
|
||||
- handled by value.
|
||||
|
||||
@subsection occt_modat_4 Local Properties of Curves and Surfaces
|
||||
The <i> Geom</i> package uses the services of the <i> gp</i> package to:
|
||||
* implement elementary algebraic calculus and basic analytic geometry,
|
||||
* describe geometric transformations which can be applied to Geom objects,
|
||||
* describe the elementary data structures of Geom objects.
|
||||
|
||||
Packages **GeomLProp**, **Geom2dLProp** provide algorithms calculating the local properties of curves and surfaces
|
||||
However, the Geom package essentially provides data structures, not algorithms.
|
||||
|
||||
You can refer to the <i> GC</i> package to find more evolved construction algorithms for
|
||||
Geom objects.
|
||||
|
||||
@section occt_modat_4 Properties of Shapes
|
||||
|
||||
@subsection occt_modat_4_1 Local Properties of Shapes
|
||||
|
||||
<i>BRepLProp</i> package provides the Local Properties of Shapes component,
|
||||
which contains algorithms computing various local properties on edges and faces in a BRep model.
|
||||
|
||||
The local properties which may be queried are:
|
||||
|
||||
* for a point of parameter u on a curve which supports an edge :
|
||||
* the point,
|
||||
* the derivative vectors, up to the third degree,
|
||||
* the tangent vector,
|
||||
* the normal,
|
||||
* the curvature, and the center of curvature;
|
||||
* for a point of parameter (u, v) on a surface which supports a face :
|
||||
* the point,
|
||||
* the derivative vectors, up to the second degree,
|
||||
* the tangent vectors to the u and v isoparametric curves,
|
||||
* the normal vector,
|
||||
* the minimum or maximum curvature, and the corresponding directions of curvature;
|
||||
* the degree of continuity of a curve which supports an edge, built by the concatenation of two other edges, at their junction point.
|
||||
|
||||
Analyzed edges and faces are described as <i> BRepAdaptor</i> curves and surfaces,
|
||||
which provide shapes with an interface for the description of their geometric support.
|
||||
The base point for local properties is defined by its u parameter value on a curve, or its (u, v) parameter values on a surface.
|
||||
|
||||
@subsection occt_modat_4_2 Local Properties of Curves and Surfaces
|
||||
|
||||
The "Local Properties of Curves and Surfaces" component provides algorithms for computing various local properties on a Geom curve (in 2D or 3D space) or a surface. It is composed of:
|
||||
|
||||
* <i> Geom2dLProp</i> package, which allows computing Derivative and Tangent vectors (normal and curvature) of a parametric point on a 2D curve;
|
||||
* <i> GeomLProp </i> package, which provides local properties on 3D curves and surfaces
|
||||
* <i> LProp </i> package, which provides an enumeration used to characterize a particular point on a 2D curve.
|
||||
|
||||
Curves are either <i> Geom_Curve </i> curves (in 3D space) or <i> Geom2d_Curve </i> curves (in the plane).
|
||||
Surfaces are <i> Geom_Surface </i> surfaces. The point on which local properties are calculated
|
||||
is defined by its u parameter value on a curve, and its (u,v) parameter values on a surface.
|
||||
|
||||
It is possible to query the same local properties for points as mentioned above, and additionally for 2D curves:
|
||||
|
||||
* the points corresponding to a minimum or a maximum of curvature;
|
||||
* the inflection points.
|
||||
|
||||
|
||||
#### Example: How to check the surface concavity
|
||||
|
||||
To check the concavity of a surface, proceed as follows:
|
||||
|
||||
1. Sample the surface and compute at each point the Gaussian curvature.
|
||||
2. If the value of the curvature changes of sign, the surface is concave or convex depending on the point of view.
|
||||
3. To compute a Gaussian curvature, use the class <i> SLprops</i> from <i> GeomLProp</i>, which instantiates the generic class <i> SLProps </i>from <i> LProp</i> and use the method <i> GaussianCurvature</i>.
|
||||
|
||||
@subsection occt_modat_4_3 Global Properties of Shapes
|
||||
|
||||
The Global Properties of Shapes component provides algorithms for computing the global
|
||||
properties of a composite geometric system in 3D space, and frameworks to query the computed results.
|
||||
|
||||
The global properties computed for a system are :
|
||||
* mass,
|
||||
* mass center,
|
||||
* matrix of inertia,
|
||||
* moment about an axis,
|
||||
* radius of gyration about an axis,
|
||||
* principal properties of inertia such as principal axis, principal moments, and principal radius of gyration.
|
||||
|
||||
Geometric systems are generally defined as shapes. Depending on the way they are analyzed, these shapes will give properties of:
|
||||
|
||||
* lines induced from the edges of the shape,
|
||||
* surfaces induced from the faces of the shape, or
|
||||
* volumes induced from the solid bounded by the shape.
|
||||
|
||||
The global properties of several systems may be brought together to give the global properties of the system composed of the sum of all individual systems.
|
||||
|
||||
The Global Properties of Shapes component is composed of:
|
||||
* seven functions for computing global properties of a shape: one function for lines, two functions for surfaces and four functions for volumes. The choice of functions depends on input parameters and algorithms used for computation (<i>BRepGProp</i> global functions),
|
||||
* a framework for computing global properties for a set of points (<i>GProp_PGProps</i>),
|
||||
* a general framework to bring together the global properties retained by several more elementary frameworks, and provide a general programming interface to consult computed global properties.
|
||||
|
||||
Packages *GeomLProp* and *Geom2dLProp* provide algorithms calculating the local properties of curves and surfaces
|
||||
|
||||
A curve (for one parameter) has the following local properties:
|
||||
- Point
|
||||
@@ -401,24 +648,77 @@ The following methods are available:
|
||||
|
||||
Note that the B-spline curve and surface are accepted but they are not cut into pieces of the desired continuity. It is the global continuity, which is seen.
|
||||
|
||||
@subsection occt_modat_4_4 Adaptors for Curves and Surfaces
|
||||
|
||||
Some Open CASCADE Technology general algorithms may work theoretically on numerous types of curves or surfaces.
|
||||
|
||||
To do this, they simply get the services required of the analyzed curve or surface through an interface so as to a single API, whatever the type of curve or surface. These interfaces are called adaptors.
|
||||
|
||||
For example, <i> Adaptor3d_Curve </i> is the abstract class which provides the required services by an algorithm which uses any 3d curve.
|
||||
|
||||
<i> GeomAdaptor </i> package provides interfaces:
|
||||
* On a Geom curve;
|
||||
* On a curve lying on a Geom surface;
|
||||
* On a Geom surface;
|
||||
|
||||
<i> Geom2dAdaptor</i> package provides interfaces :
|
||||
* On a <i>Geom2d</i> curve.
|
||||
|
||||
<i> BRepAdaptor </i> package provides interfaces:
|
||||
* On a Face
|
||||
* On an Edge
|
||||
|
||||
When you write an algorithm which operates on geometric objects, use <i> Adaptor3d</i> (or <i> Adaptor2d</i>) objects.
|
||||
|
||||
As a result, you can use the algorithm with any kind of object, if you provide for this object an interface derived from *Adaptor3d* or *Adaptor2d*.
|
||||
These interfaces are easy to use: simply create an adapted curve or surface from a *Geom2d* curve, and then use this adapted curve as an argument for the algorithm? which requires it.
|
||||
|
||||
|
||||
@section occt_modat_5 Topology
|
||||
|
||||
Open CASCADE Technology Topology allows accessing and manipulating objects data without dealing with their 2D or 3D representations. Whereas OCCT Geometry provides a description of objects in terms of coordinates or parametric values, Topology describes data structures of objects in parametric space. These descriptions use location in and restriction of parts of this space.
|
||||
OCCT Topology allows accessing and manipulating data of objects without dealing with their 2D or 3D representations. Whereas OCCT Geometry provides a description of objects in terms of coordinates or parametric values, Topology describes data structures of objects in parametric space. These descriptions use location in and restriction of parts of this space.
|
||||
|
||||
To provide its descriptions, OCCT abstract topology offers the following services:
|
||||
- Keeping track of Location of shapes
|
||||
- Naming shapes, sub-shapes, their orientations and states
|
||||
- Manipulating shapes and sub-shapes
|
||||
- Exploring topological data structures
|
||||
- Using lists and maps of shapes
|
||||
Topological library allows you to build pure topological data structures. Topology defines relationships between simple geometric entities. In this way, you can model complex shapes as assemblies of simpler entities. Due to a built-in non-manifold (or mixed-dimensional) feature, you can build models mixing:
|
||||
* 0D entities such as points;
|
||||
* 1D entities such as curves;
|
||||
* 2D entities such as surfaces;
|
||||
* 3D entities such as volumes.
|
||||
|
||||
You can, for example, represent a single object made of several distinct bodies containing embedded curves and surfaces connected or non-connected to an outer boundary.
|
||||
|
||||
Abstract topological data structure describes a basic entity - a shape, which can be divided into the following component topologies:
|
||||
* Vertex - a zero-dimensional shape corresponding to a point in geometry;
|
||||
* Edge - a shape corresponding to a curve, and bound by a vertex at each extremity;
|
||||
* Wire - a sequence of edges connected by their vertices;
|
||||
* Face - part of a plane (in 2D geometry) or a surface (in 3D geometry) bounded by a closed wire;
|
||||
* Shell - a collection of faces connected by some edges of their wire boundaries;
|
||||
* Solid - a part of 3D space bound by a shell;
|
||||
* Compound solid - a collection of solids.
|
||||
|
||||
The wire and the solid can be either infinite or closed.
|
||||
|
||||
A face with 3D underlying geometry may also refer to a collection of connected triangles that approximate the underlying surface. The surfaces can be undefined leaving the faces represented by triangles only. If so, the model is purely polyhedral.
|
||||
|
||||
Topology defines the relationship between simple geometric entities, which can thus be linked together to represent complex shapes.
|
||||
|
||||
Abstract Topology is provided by six packages.
|
||||
The first three packages describe the topological data structure used in Open CASCADE Technology:
|
||||
|
||||
* <i> TopAbs</i> package provides general resources for topology-driven applications. It contains enumerations that are used to describe basic topological notions: topological shape, orientation and state. It also provides methods to manage these enumerations.
|
||||
* <i> TopLoc </i>package provides resources to handle 3D local coordinate systems: <i> Datum3D</i>and <i> Location</i>. <i> Datum3D</i> describes an elementary coordinate system, while <i> Location</i> comprises a series of elementary coordinate systems.
|
||||
* <i> TopoDS</i> package describes classes to model and build data structures that are purely topological.
|
||||
|
||||
Three additional packages provide tools to access and manipulate this abstract topology:
|
||||
|
||||
* <i> TopTools</i> package provides basic tools to use on topological data structures.
|
||||
* <i> TopExp</i> package provides classes to explore and manipulate the topological data structures described in the TopoDS package.
|
||||
* <i> BRepTools </i> package provides classes to explore, manipulate, read and write BRep data structures. These more complex data structures combine topological descriptions with additional geometric information, and include rules for evaluating equivalence of different possible representations of the same object, for example, a point.
|
||||
|
||||
@subsection occt_modat_5_1 Shape Location
|
||||
|
||||
A local coordinate system can be viewed as either of the following:
|
||||
- A right-handed trihedron with an origin and three orthonormal vectors. The **gp_Ax2** package corresponds to this definition.
|
||||
- A transformation of a +1 determinant, allowing the transformation of coordinates between local and global references frames. This corresponds to the **gp_Trsf**.
|
||||
- A right-handed trihedron with an origin and three orthonormal vectors. The *gp_Ax2* package corresponds to this definition.
|
||||
- A transformation of a +1 determinant, allowing the transformation of coordinates between local and global references frames. This corresponds to the *gp_Trsf*.
|
||||
|
||||
*TopLoc* package distinguishes two notions:
|
||||
- *TopLoc_Datum3D* class provides the elementary reference coordinate, represented by a right-handed orthonormal system of axes or by a right-handed unitary transformation.
|
||||
@@ -439,21 +739,19 @@ C4 = R1 * C2
|
||||
|
||||
**NOTE** C3 and C4 are equal because they are both R1 * R2 * R3.
|
||||
|
||||
The TopLoc package is chiefly targeted at the topological data structure, but it can be used for other purposes.
|
||||
The *TopLoc* package is chiefly targeted at the topological data structure, but it can be used for other purposes.
|
||||
|
||||
Change of coordinates
|
||||
---------------------
|
||||
|
||||
*TopLoc_Datum3D* class represents a change of elementary coordinates. Such changes must be shared so this class inherits from *MMgt_TShared*. The coordinate is represented by a transformation *gp_Trsfpackage*. This transformation has no scaling factor.
|
||||
|
||||
|
||||
@subsection occt_modat_5_2 Naming shapes, sub-shapes, their orientation and state
|
||||
|
||||
The **TopAbs** package provides general enumerations describing the basic concepts of topology and methods to handle these enumerations. It contains no classes. This package has been separated from the rest of the topology because the notions it contains are sufficiently general to be used by all topological tools. This avoids redefinition of enumerations by remaining independent of modeling resources. The TopAbs package defines three notions:
|
||||
- Topological type (TopAbs_ShapeEnum)
|
||||
- Orietation (TopAbs_Orientation)
|
||||
- StateTopAbs_State)
|
||||
|
||||
- **Type** *TopAbs_ShapeEnum*;
|
||||
- **Orientation** *TopAbs_Orientation* ;
|
||||
- **State** *StateTopAbs_State*
|
||||
|
||||
@subsubsection occt_modat_5_2_1 Topological types
|
||||
|
||||
@@ -920,7 +1218,7 @@ Below is the auxiliary function, which copies the element of rank *i* from the m
|
||||
|
||||
@subsubsection occt_modat_5_5_1 Wire Explorer
|
||||
|
||||
BRepTools_WireExplorer class can access edges of a wire in their order of connection.
|
||||
*BRepTools_WireExplorer* class can access edges of a wire in their order of connection.
|
||||
|
||||
For example, in the wire in the image we want to recuperate the edges in the order {e1, e2, e3,e4, e5} :
|
||||
|
||||
@@ -937,4 +1235,6 @@ For example, in the wire in the image we want to recuperate the edges in the ord
|
||||
ProcessTheVertexConnectingTheCurrentEdgeToThePrevious
|
||||
One(Ex.CurrentVertex());
|
||||
}
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 28 KiB After Width: | Height: | Size: 13 KiB |
@@ -145,7 +145,6 @@ Documents offer access to the data framework and manage the following items:
|
||||
@subsubsection occt_ocaf_2_3_2 Shape attribute
|
||||
|
||||
The shape attribute implements the functionality of the OCCT topology manipulation:
|
||||
|
||||
* reference to the shapes
|
||||
* tracking of shape evolution
|
||||
|
||||
@@ -164,6 +163,7 @@ Where the document manages the notification of changes, a function manages propa
|
||||
@image html /user_guides/ocaf/images/ocaf_image008.png "Document structure"
|
||||
@image latex /user_guides/ocaf/images/ocaf_image008.png "Document structure"
|
||||
|
||||
|
||||
@section occt_ocaf_3 Data Framework Services
|
||||
|
||||
@subsection occt_ocaf_3_1 Overview
|
||||
@@ -416,11 +416,11 @@ If you use a standard file format and you want your new attributes to be stored
|
||||
If you use the XML format, do the following:
|
||||
1. Create a new package with the name Xml[package name] (for example *XmlMyAttributePackage*) containing class *XmlMyAttributePackage_MyAttributeDriver*. The new class inherits *XmlMDF_ADriver* class and contains the translation functionality: from transient to persistent and vice versa (see the realization of the standard attributes in the packages *XmlMDataStd*, for example). Add package method AddDrivers which adds your class to a driver table (see below).
|
||||
2. Create a new package (or do it in the current one) with two package methods:
|
||||
* Factory, which loads the document storage and retrieval drivers; and
|
||||
* AttributeDrivers, which calls the methods AddDrivers for all packages responsible for persistence of the document.
|
||||
* *Factory*, which loads the document storage and retrieval drivers; and
|
||||
* *AttributeDrivers*, which calls the methods AddDrivers for all packages responsible for persistence of the document.
|
||||
3. Create a plug-in implemented as an executable (see example *XmlPlugin*). It calls a macro PLUGIN with the package name where you implemented the method Factory.
|
||||
If you use the binary format, do the following:
|
||||
1. Create a new package with name Bin[package name] (for example *BinMyAttributePackage*) containing a class *BinMyAttributePackage_MyAttributeDriver*. The new class inherits *BinMDF_ADriver* class and contains the translation functionality: from transient to persistent and vice versa (see the realization of the standard attributes in the packages *BinMDataStd*, for example). Add package method *AddDrivers*, which adds your class to a driver table (see below).
|
||||
1. Create a new package with name <i> Bin[package name] </i> (for example *BinMyAttributePackage*) containing a class *BinMyAttributePackage_MyAttributeDriver*. The new class inherits *BinMDF_ADriver* class and contains the translation functionality: from transient to persistent and vice versa (see the realization of the standard attributes in the packages *BinMDataStd*, for example). Add package method *AddDrivers*, which adds your class to a driver table.
|
||||
2. Create a new package (or do it in the current one) with two package methods:
|
||||
* Factory, which loads the document storage and retrieval drivers; and
|
||||
* AttributeDrivers, which calls the methods AddDrivers for all packages responsible for persistence of the document.
|
||||
@@ -439,23 +439,23 @@ Let’s study the implementation of the same data type in both ways by the examp
|
||||
1. The first way: creation of a new attribute. The implementation of the transformation by creation of a new attribute is represented in the <a href="#occt_ocaf_11">Samples</a>.
|
||||
|
||||
2. The second way: creation of a new data type by means of combination of standard attributes. Depending on the type of transformation it may be kept in data framework by different standard attributes. For example, a translation is defined by two points. Therefore the data tree for translation looks like this:
|
||||
* Type of transformation (gp_Translation) as TDataStd_Integer;
|
||||
* First point as TDataStd_RealArray (three values: X1, Y1 and Z1);
|
||||
* Second point as TDataStd_RealArray (three values: X2, Y2 and Z2).
|
||||
* Type of transformation <i>(gp_Translation)</i> as *TDataStd_Integer*;
|
||||
* First point as *TDataStd_RealArray* (three values: X1, Y1 and Z1);
|
||||
* Second point as *TDataStd_RealArray* (three values: X2, Y2 and Z2).
|
||||
|
||||
@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"
|
||||
|
||||
If the type of transformation is changed to rotation, the data tree looks like this:
|
||||
* Type of transformation (gp_Rotation) as TDataStd_Integer;
|
||||
* Point of axis of rotation as TDataStd_RealArray (three values: X, Y and Z);
|
||||
* Axis of rotation as TDataStd_RealArray (three values: DX, DY and DZ);
|
||||
* Angle of rotation as TDataStd_Real.
|
||||
* Type of transformation <i>(gp_Rotation)</i> as *TDataStd_Integer*;
|
||||
* Point of axis of rotation as *TDataStd_RealArray* (three values: X, Y and Z);
|
||||
* Axis of rotation as *TDataStd_RealArray* (three values: DX, DY and DZ);
|
||||
* Angle of rotation as *TDataStd_Real*.
|
||||
|
||||
@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"
|
||||
|
||||
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).
|
||||
The attribute *TDataStd_UAttribute* with the chosen unique GUID identifies the data type. The interface class initialized by the label of this attribute allows access to the data container (type of transformation and the data of transformation according to the type).
|
||||
|
||||
|
||||
@section occt_ocaf_4_ Standard Document Services
|
||||
@@ -464,7 +464,7 @@ The attribute TDataStd_UAttribute with the chosen unique GUID identifies the dat
|
||||
|
||||
Standard documents offer ready-to-use documents containing a TDF-based data framework. Each document can contain only one framework.
|
||||
|
||||
The documents themselves are contained in the instantiation of a class inheriting from TDocStd_Application. This application manages the creation, storage and retrieval of documents.
|
||||
The documents themselves are contained in the instantiation of a class inheriting from *TDocStd_Application*. This application manages the creation, storage and retrieval of documents.
|
||||
|
||||
You can implement undo and redo in your document, and refer from the data framework of one document to that of another one. This is done by means of external link attributes, which store the path and the entry of external links.
|
||||
|
||||
@@ -577,21 +577,58 @@ setenv CSF_NewFormatDefaults MyApplicationPath/MyResources
|
||||
|
||||
Once these steps are taken you may run your application, create documents and Save/Open them. These resource files already exist in the OCAF (format "Standard").
|
||||
|
||||
If you use your specific attributes from packages, for example, P-, M- and TMyAttributePackage, see "Specific attribute creation" on page 20; you must take some additional steps for the new plugin implementation:
|
||||
If you use your specific attributes from packages, for example, <i>P-, M-</i> and *TMyAttributePackage* (see @ref occt_ocaf_3_4_6 "Specific attribute creation") you must take some additional steps for the new plugin implementation:
|
||||
|
||||
1. Add our "P" package to the standard schema. You can get an already existing (in Open CASCADE Technology sources) schema from StdSchema unit and add your package string to the cdl-file: "package PMyAttributePackage".
|
||||
2. Next step consists of implementation of an executable, which will connect our documents to our application and open/save them. Copy the package PAppStdPlugin and change its name to MyTheBestApplicationPlugin. In the PLUGIN macros type the name of your factory which will be defined in the next step.
|
||||
3. Factory is a method, which returns drivers (standard drivers and our defined drivers from the "M" package) by a GUID. Copy the package where the standard factory is defined (it is PAppStd in the OCAF sources). Change its name to MyTheBestSchemaLocation. The Factory() method of the PappStd package checks the GUID set as its argument and returns the corresponding table of drivers. Set two new GUIDs for your determined storage and retrieval drivers. Append two "if" declarations inside the Factory() method which should check whether the set GUID coincides with GUIDs defined by the Factory() method as far as our storage and retrieval drivers are concerned. If the GUID coincides with one of them, the method should return a table of storage or retrieval drivers respectively.
|
||||
4. Recompile all. Add the strings with GUIDs – in accordance with your plugin library GUID - to the "Plugin" file.
|
||||
1. Add our *P* package to the standard schema. You can get an already existing (in Open CASCADE Technology sources) schema from *StdSchema* unit and add your package string to the cdl-file: package *PMyAttributePackage*.
|
||||
2. The next step consists in the implementation of an executable, which will connect our documents to our application and open/save them. Copy the package *PAppStdPlugin* and change its name to *MyTheBestApplicationPlugin*. In the *PLUGIN* macros type the name of your factory, which will be defined at the next step.
|
||||
3. *Factory* is a method, which returns drivers (standard drivers and our defined drivers from the *M* package) by a GUID. Copy the package to the location, where the standard factory is defined (it is PAppStd in the OCAF sources). Change its name to *MyTheBestSchemaLocation*. The *Factory()* method of the *PappStd* package checks the GUID set as its argument and returns the corresponding table of drivers. Set two new GUIDs for your determined storage and retrieval drivers. Append two *if* declarations inside the *Factory()* method, which should check whether the set GUID coincides with GUIDs defined by the *Factory()* method as far as our storage and retrieval drivers are concerned. If the GUID coincides with one of them, the method should return a table of storage or retrieval drivers respectively.
|
||||
4. Recompile all and add the strings with GUIDs to the *Plugin* file in accordance with your plugin library GUID.
|
||||
|
||||
@subsubsection occt_ocaf_4_3_4 Opening the document from a file
|
||||
|
||||
To open the document from a file where it has been previously saved, you use TDocStd_Application::Open as in the example below. The arguments are the path of the file and the document saved in this file.
|
||||
To open the document from a file where it has been previously saved, you can use *TDocStd_Application::Open* as in the example below. The arguments are the path of the file and the document saved in this file.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
app->Open("/tmp/example.caf", doc);
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@subsubsection occt_ocaf_4_3_5 Cutting, copying and pasting inside a document
|
||||
|
||||
To cut, copy and paste inside a document, use the class *TDF_CopyLabel*.
|
||||
|
||||
In fact, you must define a *Label*, which contains the temporary value of a cut or
|
||||
copy operation (say, in <i> Lab_Clipboard</i>). You must also define two other labels:
|
||||
|
||||
* The data container (e.g. <i> Lab_source</i>)
|
||||
* The destination of the copy (e.g. <i> Lab_ Target</i> )
|
||||
|
||||
~~~~
|
||||
Copy = copy (Lab_Source => Lab_Clipboard)
|
||||
Cut = copy + Lab_Source.ForgetAll() // command clear the contents of LabelSource.
|
||||
Paste = copy (Lab_Clipboard => Lab_target)
|
||||
~~~~
|
||||
|
||||
So we need a tool to copy all (or a part) of the content of a label and its sub-label,
|
||||
to another place defined by a label.
|
||||
|
||||
~~~~
|
||||
TDF_CopyLabel aCopy;
|
||||
TDF_IDFilter aFilter (Standard_False);
|
||||
|
||||
//Don't copy TDataStd_TreeNode attribute
|
||||
|
||||
aFilter.Ignore(TDataStd_TreeNode::GetDefaultTreeID());
|
||||
aCopy.Load(aSource, aTarget); aCopy.UseFilter(aFilter); aCopy.Perform();
|
||||
|
||||
// copy the data structure to clipboard
|
||||
|
||||
return aCopy.IsDone(); }
|
||||
~~~~
|
||||
|
||||
The filter is used to forbid copying a specified type of attribute.
|
||||
|
||||
You can also have a look at the class *TDF_Closure*, which can be useful to determine the dependencies of the part you want to cut from the document.
|
||||
|
||||
@subsection occt_ocaf_4_4 External Links
|
||||
|
||||
External links refer from one document to another. They allow you to update the copy of data framework later on.
|
||||
@@ -605,7 +642,7 @@ Note that documents can be copied with or without a possibility of updating an e
|
||||
|
||||
#### With the possibility of updating it later
|
||||
|
||||
To copy a document with a possibility of updating it later, you use TDocStd_XLinkTool::CopyWithLink.
|
||||
To copy a document with a possibility of updating it later, you use *TDocStd_XLinkTool::CopyWithLink*.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
Handle(TDocStd_Document) doc1;
|
||||
@@ -620,7 +657,7 @@ XLinkTool.CopyWithLink(target,source);
|
||||
|
||||
Now the target document has a copy of the source document. The copy also has a link in order to update the content of the copy if the original changes.
|
||||
|
||||
In the example below, something has changed in the source document. As a result, you need to update the copy in the target document. This copy is passed to TDocStd_XLinkTool::UpdateLink as the argument *target*.
|
||||
In the example below, something has changed in the source document. As a result, you need to update the copy in the target document. This copy is passed to *TDocStd_XLinkTool::UpdateLink* as the argument *target*.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
XLinkTool.UpdateLink(target);
|
||||
@@ -628,7 +665,7 @@ XLinkTool.UpdateLink(target);
|
||||
|
||||
#### Without any link between the copy and the original
|
||||
|
||||
You can also create a copy of the document with no link between the original and the copy. The syntax to use this option is TDocStd_XLinkTool::Copy; the copied document is again represented by the argument *target*, and the original – by *source.*
|
||||
You can also create a copy of the document with no link between the original and the copy. The syntax to use this option is *TDocStd_XLinkTool::Copy*. The copied document is again represented by the argument *target*, and the original – by *source.*
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
XLinkTool.Copy(target, source);
|
||||
@@ -639,39 +676,42 @@ XLinkTool.Copy(target, source);
|
||||
@section occt_ocaf_5_ OCAF Shape Attributes
|
||||
@subsection occt_ocaf_5_1 Overview
|
||||
|
||||
OCAF shape attributes are used for topology objects and their evolution access. All topological objects are stored in one TNaming_UsedShapes attribute at the root label of the data framework. This attribute contains a map with all topological shapes used in a given document.
|
||||
A topological attribute can be seen as a hook into the topological structure. It is possible to attach data to define references to it.
|
||||
|
||||
The user can add the TNaming_NamedShape attribute to other labels. This attribute contains references (hooks) to shapes from the TNaming_UsedShapes attribute and an evolution of these shapes. The TNaming_NamedShape attribute contains a set of pairs of hooks: to the *Old* shape and to a *New* shape (see the following figure). It allows not only to get the topological shapes by the labels, but also to trace the evolution of the shapes and to correctly update dependent shapes by the changed one.
|
||||
OCAF shape attributes are used for topology objects and their evolution access. All topological objects are stored in one *TNaming_UsedShapes* attribute at the root label of the data framework. This attribute contains a map with all topological shapes used in a given document.
|
||||
|
||||
The user can add the *TNaming_NamedShape* attribute to other labels. This attribute contains references (hooks) to shapes from the *TNaming_UsedShapes* attribute and an evolution of these shapes. The *TNaming_NamedShape* attribute contains a set of pairs of hooks: to the *Old* shape and to a *New* shape (see the following figure). It allows not only to get the topological shapes by the labels, but also to trace the evolution of the shapes and to correctly update dependent shapes by the changed one.
|
||||
|
||||
If a shape is newly created, then the old shape of a corresponding named shape is an empty shape. If a shape is deleted, then the new shape in this named shape is empty.
|
||||
|
||||
@image html /user_guides/ocaf/images/ocaf_image013.png
|
||||
@image latex /user_guides/ocaf/images/ocaf_image013.png
|
||||
|
||||
### Shape attributes in data framework.
|
||||
|
||||
Different algorithms may dispose sub-shapes of the result shape at the individual labels depending on whether it is necessary to do so:
|
||||
|
||||
* If a sub-shape must have some extra attributes (material of each face or color of each edge). In this case a specific sub-shape is placed to a separate label (usually to a sub-label of the result shape label) with all attributes of this sub-shape.
|
||||
* If the topological naming algorithm is needed, a necessary and sufficient set of sub-shapes is placed to child labels of the result shape label. As usual, for a basic solid and closed shells, all faces of the shape are disposed.
|
||||
|
||||
*TNaming_NamedShape* may contain a few pairs of hooks with the same evolution. In this case the topology shape, which belongs to the named shape is a compound of new shapes.
|
||||
|
||||
TNaming_NamedShape may contain a few pairs of hooks with the same evolution. In this case the topology shape, which belongs to the named shape is a compound of new shapes.
|
||||
|
||||
Consider the following example. Two boxes (solids) are fused into one solid (the result one). Initially each box was placed to the result label as a named shape, which has evolution PRIMITIVE and refers to the corresponding shape of the TNaming_UsedShapes map. The box result label has a material attribute and six child labels containing named shapes of Box faces.
|
||||
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"
|
||||
|
||||
After the fuse operation a modified result is placed to a separate label as a named shape, which refers to the old shape – one of the boxes, as well as to the new shape – the shape resulting from the fuse operation – and has evolution MODIFY (see the following figure).
|
||||
|
||||
Named shapes, which contain information about modified faces, belong to the fuse result sub-labels: sub-label with tag 1 – modified faces of the first box, sub-label with tag 2 – generated faces of the box 2.
|
||||
Named shapes, which contain information about modified faces, belong to the fuse result sub-labels: 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
|
||||
|
||||
This is necessary and sufficient information for the functionality of the right naming mechanism: any sub-shape of the result can be identified unambiguously by name type and set of labels, which contain named shapes:
|
||||
|
||||
* face F1’ as a modification of F11 face
|
||||
* face F1’’ as generation of F12 face
|
||||
* face F1’ as a modification of face F11
|
||||
* face F1’’ as generation of face F12
|
||||
* edges as an intersection of two contiguous faces
|
||||
* vertices as an intersection of three contiguous faces
|
||||
|
||||
@@ -684,19 +724,18 @@ After any modification of source boxes the application must automatically rebuil
|
||||
When using TNaming_NamedShape to create attributes, the following fields of an attribute are filled:
|
||||
|
||||
* A list of shapes called the "old" and the "new" shapes A new shape is recomputed as the value of the named shape. The meaning of this pair depends on the type of evolution.
|
||||
* The type of evolution: a term of the TNaming_Evolution enumeration:
|
||||
* PRIMITIVE – newly created topology, with no previous history
|
||||
* GENERATED – as usual, this evolution of a named shape means, that the new shape is created from a low-level old shape ( a prism face from an edge, for example )
|
||||
* MODIFY – the new shape is a modified old shape
|
||||
* DELETE – the new shape is empty; the named shape with this evolution just indicates that the old shape topology is deleted from the model
|
||||
* SELECTED – a named shape with this evolution has no effect on the history of the topology; it is
|
||||
used for the selected shapes that are placed to the separate label
|
||||
* The type of evolution, which is a term of the *TNaming_Evolution* enumeration used for the selected shapes that are placed to the separate label:
|
||||
* PRIMITIVE – newly created topology, with no previous history;
|
||||
* GENERATED – as usual, this evolution of a named shape means, that the new shape is created from a low-level old shape ( a prism face from an edge, for example );
|
||||
* MODIFY – the new shape is a modified old shape;
|
||||
* DELETE – the new shape is empty; the named shape with this evolution just indicates that the old shape topology is deleted from the model;
|
||||
* SELECTED – a named shape with this evolution has no effect on the history of the topology.
|
||||
|
||||
Only pairs of shapes with equal evolution can be stored in one named shape.
|
||||
|
||||
@subsubsection occt_ocaf_5_2_2 Using naming resources
|
||||
|
||||
The class TNaming_Builder allows you to create a named shape attribute. It has a label of a future attribute as an argument of the constructor. Respective methods are used for the evolution and setting of shape pairs. If for the same TNaming_Builder object a lot of pairs of shapes with the same evolution are given, then these pairs would be placed in the resulting named shape. After the creation of a new object of the TNaming_Builder class, an empty named shape is created at the given label.
|
||||
The class *TNaming_Builder* allows you to create a named shape attribute. It has a label of a future attribute as an argument of the constructor. Respective methods are used for the evolution and setting of shape pairs. If for the same TNaming_Builder object a lot of pairs of shapes with the same evolution are given, then these pairs would be placed in the resulting named shape. After the creation of a new object of the TNaming_Builder class, an empty named shape is created at the given label.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
// a new empty named shape is created at "label"
|
||||
@@ -710,15 +749,14 @@ Handle(TNaming_NamedShape) ns = builder.NamedShape();
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@subsubsection occt_ocaf_5_2_3 Reading the contents of a named shape attribute
|
||||
|
||||
You can use TNaming_NamedShape class to get evolution of this named shape (method TNaming_NamedShape::Evolution()) and "value" of the named shape – compound of new shapes of all pairs of this named shape (method TNaming_NamedShape::Get()).
|
||||
You can use the method <i>TNaming_NamedShape::Evolution()</i> to get the evolution of this named shape and the method <i>TNaming_NamedShape::Get()</i> to get a compound of new shapes of all pairs of this named shape.
|
||||
|
||||
More detailed information about the contents of the named shape or about the modification history of a topology can be obtained with the following:
|
||||
|
||||
* TNaming_Tool provides a common high-level functionality for access to the named shapes contents:
|
||||
* GetShape(Handle(TNaming_NamedShape)) method returns a compound of new shapes of the given named shape
|
||||
* CurrentShape(Handle(TNaming_NamedShape)) method returns a compound of the shapes – last modifications ( latest versions ) of the shapes from the given named shape
|
||||
* NamedShape(TopoDS_Shape,TDF_Label) method returns a named shape, which contains a given shape as a new shape. Given label is any label from the data framework – it just gives access to it
|
||||
* TNaming_Iterator given access to the named shape hooks pairs.
|
||||
* *TNaming_Tool* provides a common high-level functionality for access to the named shapes contents:
|
||||
* The method <i>GetShape(Handle(TNaming_NamedShape)) </i> returns a compound of new shapes of the given named shape;
|
||||
* The method <i>CurrentShape(Handle(TNaming_NamedShape))</i> returns a compound of the shapes, which are latest versions of the shapes from the given named shape;
|
||||
* The method <i>NamedShape(TopoDS_Shape,TDF_Label) </i> returns a named shape, which contains a given shape as a new shape. A given label is any label from the data framework – it just gives access to it.
|
||||
* *TNaming_Iterator* gives access to the named shape and hooks pairs.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
// create an iterator for a named shape
|
||||
@@ -739,7 +777,7 @@ iter.Next();
|
||||
|
||||
@subsubsection occt_ocaf_5_2_4 Selection Mechanism
|
||||
|
||||
One of user interfaces for topological naming resources is the TNaming_Selector class. You can use this class to:
|
||||
One of user interfaces for topological naming resources is the *TNaming_Selector* class. You can use this class to:
|
||||
|
||||
* Store a selected shape on a label
|
||||
* Access the named shape
|
||||
@@ -747,13 +785,13 @@ One of user interfaces for topological naming resources is the TNaming_Selector
|
||||
|
||||
Selector places a new named shape with evolution SELECTED to the given label. By the given context shape (main shape, which contains a selected sub-shape), its evolution and naming structure the selector creates a "name" of the selected shape – unique description how to find a selected topology.
|
||||
|
||||
After any modification of a context shape and updating of the corresponding naming structure, you must call the TNaming_Selector::Solve method. If the naming structure is right, then the selector automatically updates the selected shape in the corresponding named shape, else it fails.
|
||||
After any modification of a context shape and updating of the corresponding naming structure, you must call the method *TNaming_Selector::Solve*. If the naming structure is correct, the selector automatically updates the selected shape in the corresponding named shape, else it fails.
|
||||
|
||||
@subsubsection occt_ocaf_5_2_5 Exploring shape evolution
|
||||
|
||||
The class TNaming_Tool provides a toolkit to read current data contained in the attribute.
|
||||
The class *TNaming_Tool* provides a toolkit to read current data contained in the attribute.
|
||||
|
||||
If you need to create a topological attribute for existing data, use the method NamedShape.
|
||||
If you need to create a topological attribute for existing data, use the method *NamedShape*.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
class MyPkg_MyClass
|
||||
@@ -773,65 +811,62 @@ Standard_Boolean CafTest_MyClass::SameEdge (const Handle(CafTest_Line)& L1, cons
|
||||
|
||||
@subsection occt_ocaf_6_1 Overview
|
||||
|
||||
There are several ready-to-use attributes, which allow creating and modifying attributes for many basic data types. They are available in the packages TDataStd, TDataXtd and TDF. Each attribute belongs to one of four types:
|
||||
Standard attributes are ready-to-use attributes, which allow creating and modifying attributes for many basic data types. They are available in the packages *TDataStd, TDataXtd* and *TDF*. Each attribute belongs to one of four types:
|
||||
|
||||
* Geometric attributes
|
||||
* General attributes
|
||||
* Relationship attributes
|
||||
* Auxiliary attributes
|
||||
* Geometric attributes;
|
||||
* General attributes;
|
||||
* Relationship attributes;
|
||||
* Auxiliary attributes.
|
||||
|
||||
### Geometric attributes
|
||||
|
||||
|
||||
* Axis – simply identifies, that the concerned TNaming_NamedShape attribute with an axis shape inside belongs to the same label
|
||||
* Constraint – contains information about a constraint between geometries: used geometry attributes, type, value (if exists), plane (if exists), "is reversed", "is inverted" and "is verified" flags
|
||||
* Geometry – simply identifies, that the concerned TNaming_NamedShape attribute with a specified-type geometry belongs to the same label
|
||||
* Plane – simply identifies, that the concerned TNaming_NamedShape attribute with a plane shape inside belongs to the same label
|
||||
* Point – simply identifies, that the concerned TNaming_NamedShape attribute with a point shape inside belongs to the same label
|
||||
* Shape – simply identifies, that the concerned TNaming_NamedShape attribute belongs to the same label
|
||||
* PatternStd – identifies one of five available pattern models (linear, circular, rectangular, circular rectangular and mirror)
|
||||
* Position – identifies the position in 3d global space
|
||||
* **Axis** – simply identifies, that the concerned *TNaming_NamedShape* attribute with an axis shape inside belongs to the same label;
|
||||
* **Constraint** – contains information about a constraint between geometries: used geometry attributes, type, value (if exists), plane (if exists), "is reversed", "is inverted" and "is verified" flags;
|
||||
* **Geometry** – simply identifies, that the concerned *TNaming_NamedShape* attribute with a specified-type geometry belongs to the same label;
|
||||
* **Plane** – simply identifies, that the concerned *TNaming_NamedShape* attribute with a plane shape inside belongs to the same label;
|
||||
* **Point** – simply identifies, that the concerned *TNaming_NamedShape* attribute with a point shape inside belongs to the same label;
|
||||
* **Shape** – simply identifies, that the concerned *TNaming_NamedShape* attribute belongs to the same label;
|
||||
* **PatternStd** – identifies one of five available pattern models (linear, circular, rectangular, circular rectangular and mirror);
|
||||
* **Position** – identifies the position in 3d global space.
|
||||
|
||||
### General attributes
|
||||
|
||||
|
||||
* AsciiString – contains AsciiString value
|
||||
* BooleanArray – contains an array of Boolean
|
||||
* BooleanList – contains a list of Boolean
|
||||
* ByteArray – contains an array of Byte (unsigned char) values
|
||||
* Comment – contains a string – some comment for a given label (or attribute)
|
||||
* Expression – contains an expression string and a list of used variables attributes
|
||||
* ExtStringArray – contains an array of ExtendedString values
|
||||
* ExtStringList – contains a list of ExtendedString values
|
||||
* Integer – contains an integer value
|
||||
* IntegerArray – contains an array of integer values
|
||||
* IntegerList – contains a list of integer values
|
||||
* IntPackedMap – contains a packed map of integers
|
||||
* Name – contains a string – some name of a given label (or attribute)
|
||||
* NamedData – may contain up to 6 of the following named data sets (vocabularies): DataMapOfStringInteger, DataMapOfStringReal, DataMapOfStringString, DataMapOfStringByte, DataMapOfStringHArray1OfInteger, DataMapOfStringHArray1OfReal
|
||||
* NoteBook – contains a NoteBook object attribute
|
||||
* Real – contains a real value
|
||||
* RealArray – contains an array of real values
|
||||
* RealList – contains a list of real values
|
||||
* Relation – contains a relation string and a list of used variables attributes
|
||||
* Tick – defines a boolean attribute
|
||||
* Variable – simply identifies, that a variable belongs to this label; contains the "is constraint" flag and a string of used units ("mm", "m"...)
|
||||
* UAttribute – attribute with a user-defined GUID. As a rule, this attribute is used as a marker, which is independent of attributes at the same label (note, that attributes with the same GUIDs can not belong to the same label)
|
||||
* **AsciiString** – contains AsciiString value;
|
||||
* **BooleanArray** – contains an array of Boolean;
|
||||
* **BooleanList** – contains a list of Boolean;
|
||||
* **ByteArray** – contains an array of Byte (unsigned char) values;
|
||||
* **Comment** – contains a string – some comment for a given label (or attribute);
|
||||
* **Expression** – contains an expression string and a list of used variables attributes;
|
||||
* **ExtStringArray** – contains an array of *ExtendedString* values;
|
||||
* **ExtStringList** – contains a list of *ExtendedString* values;
|
||||
* **Integer** – contains an integer value;
|
||||
* **IntegerArray** – contains an array of integer values;
|
||||
* **IntegerList** – contains a list of integer values;
|
||||
* **IntPackedMap** – contains a packed map of integers;
|
||||
* **Name** – contains a string – some name of a given label (or attribute);
|
||||
* **NamedData** – may contain up to 6 of the following named data sets (vocabularies): *DataMapOfStringInteger, DataMapOfStringReal, DataMapOfStringString, DataMapOfStringByte, DataMapOfStringHArray1OfInteger* or *DataMapOfStringHArray1OfReal*;
|
||||
* **NoteBook** – contains a *NoteBook* object attribute;
|
||||
* **Real** – contains a real value;
|
||||
* **RealArray** – contains an array of real values;
|
||||
* **RealList** – contains a list of real values;
|
||||
* **Relation** – contains a relation string and a list of used variables attributes;
|
||||
* **Tick** – defines a boolean attribute;
|
||||
* **Variable** – simply identifies, that a variable belongs to this label; contains the flag *is constraint* and a string of used units ("mm", "m"...);
|
||||
* **UAttribute** – attribute with a user-defined GUID. As a rule, this attribute is used as a marker, which is independent of attributes at the same label (note, that attributes with the same GUIDs can not belong to the same label).
|
||||
|
||||
### Relationship attributes
|
||||
|
||||
|
||||
* Reference – contains reference to the label of its own data framework
|
||||
* ReferenceArray – contains an array of references
|
||||
* ReferenceList – contains a list of references
|
||||
* TreeNode – this attribute allows to create an internal tree in the data framework; this tree consists of nodes with the specified tree ID; each node contains references to the father, previous brother, next brother, first child nodes and tree ID.
|
||||
* **Reference** – contains reference to the label of its own data framework;
|
||||
* **ReferenceArray** – contains an array of references;
|
||||
* **ReferenceList** – contains a list of references;
|
||||
* **TreeNode** – this attribute allows to create an internal tree in the data framework; this tree consists of nodes with the specified tree ID; each node contains references to the father, previous brother, next brother, first child nodes and tree ID.
|
||||
|
||||
### Auxiliary attributes
|
||||
|
||||
* Directory – hi-level tool attribute for sub-labels management
|
||||
* TagSource – this attribute is used for creation of new children: it stores the tag of the last-created child of the label and gives access to the new child label creation functionality.
|
||||
* **Directory** – high-level tool attribute for sub-labels management;
|
||||
* **TagSource** – this attribute is used for creation of new children: it stores the tag of the last-created child of the label and gives access to the new child label creation functionality.
|
||||
|
||||
All of these attributes inherit class TDF_Attribute, so, each attribute has its own GUID and standard methods for attribute creation, manipulation, getting access to the data framework.
|
||||
All attributes inherit class *TDF_Attribute*, so, each attribute has its own GUID and standard methods for attribute creation, manipulation, getting access to the data framework.
|
||||
|
||||
|
||||
@subsection occt_ocaf_6_2 Services common to all attributes
|
||||
@@ -839,9 +874,15 @@ All of these attributes inherit class TDF_Attribute, so, each attribute has its
|
||||
@subsubsection occt_ocaf_6_2_1 Accessing GUIDs
|
||||
|
||||
To access the GUID of an attribute, you can use two methods:
|
||||
|
||||
* Method *GetID* is the static method of a class. It returns the GUID of any attribute, which is an object of a specified class (for example, TDataStd_Integer returns the GUID of an integer attribute). Only two classes from the list of standard attributes do not support these methods: TDataStd_TreeNode and TDataStd_Uattribute, because the GUIDs of these attributes are variable.
|
||||
* Method *GetID* is the static method of a class. It returns the GUID of any attribute, which is an object of a specified class (for example, *TDataStd_Integer* returns the GUID of an integer attribute). Only two classes from the list of standard attributes do not support these methods: *TDataStd_TreeNode* and *TDataStd_Uattribute*, because the GUIDs of these attributes are variable.
|
||||
* Method *ID* is the method of an object of an attribute class. It returns the GUID of this attribute. Absolutely all attributes have this method: only by this identifier you can discern the type of an attribute.
|
||||
|
||||
To find an attribute attached to a specific label, you use the GUID of the attribute type you are looking for. This information can be found using the method <i> GetID</i> and the method <i> Find</i> for the label as follows:
|
||||
|
||||
~~~~
|
||||
Standard_GUID anID = MyAttributeClass::GetID();
|
||||
Standard_Boolean HasAttribute = aLabel.Find(anID,anAttribute);
|
||||
~~~~
|
||||
|
||||
@subsubsection occt_ocaf_6_2_2 Conventional Interface of Standard Attributes
|
||||
|
||||
@@ -855,15 +896,15 @@ It is usual to create standard named methods for the attributes:
|
||||
|
||||
@subsection occt_ocaf_7_1 Overview
|
||||
|
||||
Standard visualization attributes implement the Application Interactive Services (see Open CASCADE Technology Visualization User’s Guide) in the context of Open CASCADE Technology Application Framework. Standard visualization attributes are AISViewer and Presentation and belong to the TPrsStd package.
|
||||
Standard visualization attributes implement the Application Interactive Services (see @ref occt_user_guides__visualization "Visualization User's Guide"). in the context of Open CASCADE Technology Application Framework. Standard visualization attributes are AISViewer and Presentation and belong to the TPrsStd package.
|
||||
|
||||
@subsection occt_ocaf_7_2 Services provided
|
||||
|
||||
@subsubsection occt_ocaf_7_2_1 Defining an interactive viewer attribute
|
||||
|
||||
The class TPrsStd_AISViewer allows you to define an interactive viewer attribute. There may be only one such attribute per one data framework and it is always placed to the root label. So, it could be set or found by any label ("access label") of the data framework. Nevertheless the default architecture can be easily extended and the user can manage several Viewers per one framework by himself.
|
||||
The class *TPrsStd_AISViewer* allows you to define an interactive viewer attribute. There may be only one such attribute per one data framework and it is always placed to the root label. So, it could be set or found by any label ("access label") of the data framework. Nevertheless the default architecture can be easily extended and the user can manage several Viewers per one framework by himself.
|
||||
|
||||
To initialize the AIS viewer as in the example below, use method Find.
|
||||
To initialize the AIS viewer as in the example below, use method *Find*.
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
// "access" is any label of the data framework
|
||||
@@ -872,13 +913,13 @@ Handle(TPrsStd_AISViewer) viewer = TPrsStd_AISViewer::Find(access)
|
||||
|
||||
@subsection occt_ocaf_7_2_2 Defining a presentation attribute
|
||||
|
||||
The class TPrsStd_AISPresentation allows you to define the visual presentation of document labels contents. In addition to various visual fields (color, material, transparency, "isDisplayed", etc.), this attribute contains its driver GUID. This GUID defines the functionality, which will update the presentation every time when needed.
|
||||
The class *TPrsStd_AISPresentation* allows you to define the visual presentation of document labels contents. In addition to various visual fields (color, material, transparency, *isDisplayed*, etc.), this attribute contains its driver GUID. This GUID defines the functionality, which will update the presentation every time when needed.
|
||||
|
||||
@subsubsection occt_ocaf_7_2_3 Creating your own driver
|
||||
|
||||
The abstract class TPrsStd_Driver allows you to define your own driver classes. Simply redefine the Update method in your new class, which will rebuild the presentation.
|
||||
|
||||
If your driver is placed to the driver table with the unique driver GUID, then every time the viewer updates presentations with a GUID identical to your driver’s GUID, the Update method of your driver for these presentations must be called:
|
||||
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
|
||||
|
||||
@@ -886,9 +927,9 @@ As usual, the GUID of a driver and the GUID of a displayed attribute are the sam
|
||||
|
||||
@subsubsection occt_ocaf_7_2_4 Using a container for drivers
|
||||
|
||||
You frequently need a container for different presentation drivers. The class TPrsStd_DriverTable provides this service. You can add a driver to the table, see if one is successfully added, and fill it with standard drivers.
|
||||
You frequently need a container for different presentation drivers. The class *TPrsStd_DriverTable* provides this service. You can add a driver to the table, see if one is successfully added, and fill it with standard drivers.
|
||||
|
||||
To fill a driver table with standard drivers, first initialize the AIS viewer as in the example above, and then pass the return value of the method InitStandardDrivers to the driver table returned by the method Get. Then attach a TNaming_NamedShape to a label and set the named shape in the presentation attribute using the method Set. Then attach the presentation attribute to the named shape attribute, and the AIS_InteractiveObject, which the presentation attribute contains, will initialize its drivers for the named shape. This can be seen in the example below.
|
||||
To fill a driver table with standard drivers, first initialize the AIS viewer as in the example above, and then pass the return value of the method *InitStandardDrivers* to the driver table returned by the method *Get*. Then attach a *TNaming_NamedShape* to a label and set the named shape in the presentation attribute using the method *Set*. Then attach the presentation attribute to the named shape attribute, and the *AIS_InteractiveObject*, which the presentation attribute contains, will initialize its drivers for the named shape. This can be seen in the example below.
|
||||
|
||||
**Example**
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
@@ -906,21 +947,23 @@ When you edit any application model, you have to regenerate the model by propaga
|
||||
|
||||
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.
|
||||
|
||||
See the white paper @ref occt_user_guides__ocaf_functionmechanism_wp "Application Framework Function Mechanism" for more information.
|
||||
|
||||
@subsection occt_ocaf_8_1 Finding functions, their owners and roots
|
||||
|
||||
The class TFunction_Function is an attribute, which stores a link to a function driver in the data framework. In the static table TFunction_DriverTable correspondence links between function attributes and drivers are stored.
|
||||
The class *TFunction_Function* is an attribute, which stores a link to a function driver in the data framework. In the static table *TFunction_DriverTable* correspondence links between function attributes and drivers are stored.
|
||||
|
||||
You can write your function attribute, a driver for such attribute (which updates the function result in accordance to a given map of changed labels), and set your driver with the GUID to the driver table.
|
||||
You can write your function attribute, a driver for such attribute, which updates the function result in accordance to a given map of changed labels, and set your driver with the GUID to the driver table.
|
||||
|
||||
Then the solver algorithm of a data model can find the Function attribute on a corresponding label and call the Execute driver method to update the result of the function.
|
||||
Then the solver algorithm of a data model can find the *Function* attribute on a corresponding label and call the *Execute* driver method to update the result of the function.
|
||||
|
||||
@subsection occt_ocaf_8_2 Storing and accessing information about function status
|
||||
|
||||
For updating algorithm optimization, each function driver has access to the TFunction_Logbook object that is a container for a set of touched, impacted and valid labels. Using this object a driver gets to know which arguments of the function were modified.
|
||||
For updating algorithm optimization, each function driver has access to the *TFunction_Logbook* object that is a container for a set of touched, impacted and valid labels. Using this object a driver gets to know which arguments of the function were modified.
|
||||
|
||||
@subsection occt_ocaf_8_3 Propagating modifications
|
||||
|
||||
An application must implement its functions, function drivers and the common solver for parametric model creation. For example, check the following model (see the following illustration):
|
||||
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
|
||||
@@ -948,29 +991,29 @@ Writing and reading XML files in OCCT is provided by LDOM package, which constit
|
||||
of XML OCAF persistence, which is the optional component provided on top of Open CASCADE Technology.
|
||||
|
||||
The Light DOM (LDOM) package contains classes maintaining a data structure whose main principles conform to W3C DOM Level 1 Recommendations. The purpose of these classes as required by XML OCAF persistence schema is to:
|
||||
* Maintain a tree structure of objects in memory representing the XML document. The root of the structure is an object of the LDOM_Document type. This object contains all the data corresponding to a given XML document and contains one object of the LDOM_Element type named "document element". The document element contains other LDOM_Element objects forming a tree. Other types of nodes (LDOM_Attr, LDOM_Text, LDOM_Comment, LDOM_CDATASection) represent the corresponding XML types and serve as branches of the tree of elements.
|
||||
* Provide class LDOM_Parser to read XML files and convert them to LDOM_Document objects.
|
||||
* Provide class LDOM_XmlWriter to convert LDOM_Document to a character stream in XML format and store it in file.
|
||||
* Maintain a tree structure of objects in memory representing the XML document. The root of the structure is an object of the *LDOM_Document* type. This object contains all the data corresponding to a given XML document and contains one object of the *LDOM_Element* type named "document element". The document element contains other *LDOM_Element* objects forming a tree. Other types of nodes: *LDOM_Attr, LDOM_Text, LDOM_Comment* and *LDOM_CDATASection* - represent the corresponding XML types and serve as branches of the tree of elements.
|
||||
* Provide class *LDOM_Parser* to read XML files and convert them to *LDOM_Document* objects.
|
||||
* Provide class *LDOM_XmlWriter* to convert *LDOM_Document* to a character stream in XML format and store it in file.
|
||||
|
||||
This package covers the functionality provided by numerous products known as "DOM parsers". Unlike most of them, LDOM was specifically developed to meet the following requirements:
|
||||
* To minimize the virtual memory allocated by DOM data structures. In average, the amount of memory of LDOM is the same as the XML file size (UTF-8).
|
||||
* To minimize the time required for parsing and formatting XML, as well as for access to DOM data structures.
|
||||
|
||||
Both these requirements are important when XML files are processed by applications if these files are relatively large (occupying megabytes and even hundreds of megabytes). To meet the requirements, some limitations were imposed on the DOM Level 1 specification; these limitations are insignificant in applications like OCAF. Some of these limitations can be overridden in the course of future developments. The main limitations are:
|
||||
* No Unicode support as well as various other encodings; only ASCII strings are used in DOM/XML. Note: There is a data type TCollection_ExtendedString for wide character data. This type is supported by LDOM_String as a sequence of numbers.
|
||||
* Some superfluous methods are deleted: getPreviousSibling, getParentNode, etc.
|
||||
* No Unicode support as well as various other encodings; only ASCII strings are used in DOM/XML. Note: There is a data type *TCollection_ExtendedString* for wide character data. This type is supported by *LDOM_String* as a sequence of numbers.
|
||||
* Some superfluous methods are deleted: *getPreviousSibling, getParentNode,* etc.
|
||||
* No resolution of XML Entities of any kind
|
||||
* No support for DTD: the parser just checks for observance of general XML rules and never validates documents.
|
||||
* Only 5 available types of DOM nodes: LDOM_Element, LDOM_Attr, LDOM_Text, LDOM_Comment, LDOM_CDATASection.
|
||||
* Only 5 available types of DOM nodes: *LDOM_Element, LDOM_Attr, LDOM_Text, LDOM_Comment* and *LDOM_CDATASection*.
|
||||
* No support of Namespaces; prefixed names are used instead of qualified names.
|
||||
* No support of the interface DOMException (no exception when attempting to remove a non-existing node).
|
||||
* No support of the interface *DOMException* (no exception when attempting to remove a non-existing node).
|
||||
|
||||
LDOM is dependent on Kernel OCCT classes only. Therefore, it can be used outside OCAF persistence in various algorithms where DOM/XML support may be required.
|
||||
|
||||
@subsection occt_ocaf_9_1 Document Drivers
|
||||
|
||||
The drivers for document storage and retrieval manage conversion between a transient OCAF
|
||||
Document in memory and its persistent reflection in a container (disk, memory, network ...). For XML Persistence, they are defined in the package XmlDrivers.
|
||||
Document in memory and its persistent reflection in a container (disk, memory, network). For XML Persistence, they are defined in the package XmlDrivers.
|
||||
|
||||
The main methods (entry points) of these drivers are:
|
||||
* *Write()* - for a storage driver;
|
||||
@@ -1089,15 +1132,14 @@ Both the XML format and the XML OCAF persistence code are extensible in the sens
|
||||
* **Child** - a label created from another label, which by definition, is the father label.
|
||||
* **Compound document** - a set of interdependent documents, linked to each other by means of external references. These references provide the associativity of data.
|
||||
* **Data framework** - a tree-like data structure which in OCAF, is a tree of labels with data attached to them in the form of attributes. This tree of labels is accessible through the services of the *TDocStd_Document* class.
|
||||
* *Document* - a container for a data framework which grants access to the data, and is, in its turn, contained by an application. A document also allows you to:
|
||||
* **Document** - a container for a data framework which grants access to the data, and is, in its turn, contained by an application. A document also allows you to:
|
||||
* Manage modifications, providing Undo and Redo functions
|
||||
* Manage command transactions
|
||||
* Update external links
|
||||
* Manage save and restore options
|
||||
* Store the names of software extensions.
|
||||
* **Driver** - an abstract class, which defines the communications protocol with a system.
|
||||
* **Entry** - an ASCII character string containing the tag list of a label.
|
||||
|
||||
* **Entry** - an ASCII character string containing the tag list of a label. For example:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
0:3:24:7:2:7
|
||||
@@ -1113,7 +1155,7 @@ To store these references properly, a label must also contain an external link a
|
||||
|
||||
In C++, the application behavior is implemented in virtual functions redefined in these derived classes. This is known as overriding.
|
||||
|
||||
* **GUID** - Global Universal ID. A string of 37 characters intended to uniquely identify an object.
|
||||
* **GUID** - Global Universal ID. A string of 37 characters intended to uniquely identify an object. For example:
|
||||
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||
2a96b602-ec8b-11d0-bee7-080009dc3333
|
||||
|
@@ -25,6 +25,15 @@ OCAF White-Paper {#occt_user_guides__ocaf_wp}
|
||||
|
||||
By providing architectural guidance and ready-to-use solutions to these issues,
|
||||
OCAF helps you to develop your application significantly faster: you concentrate on the application's functionality.
|
||||
|
||||
As you use the architecture provided by OCAF, the design of your application is made easy: as the application developer you can concentrate on the functionality instead of the underlying mechanisms required to support it.
|
||||
|
||||
Also, thanks to the coupling with the other Open CASCADE Technology modules,
|
||||
your application can rapidly be prototyped. In addition, the final application
|
||||
can be developed by industrializing the prototype — you don't need to restart the development from scratch.
|
||||
|
||||
Last but not least, you base your application on an Open Source component:
|
||||
this guarantees the long-term usefulness of your development.
|
||||
|
||||
@subsection ocaf_wp_1_2 Overview of the Architecture
|
||||
|
||||
@@ -73,7 +82,7 @@ OCAF uses other modules of Open CASCADE Technology — the Shape attribute is im
|
||||
If you need application specific data not provided with OCAF, for example,
|
||||
to incorporate a finite element model in the data structure,
|
||||
you define a new attribute class containing the mesh,
|
||||
and you include its persistent homolog in a new file format.
|
||||
and you include its persistent homologue in a new file format.
|
||||
|
||||
Once you have implemented the commands which create and modify the data structure
|
||||
according to your specification, OCAF provides you, without any additional programming:
|
||||
@@ -91,19 +100,99 @@ OCAF uses other modules of Open CASCADE Technology — the Shape attribute is im
|
||||
|
||||
You can also implement the user interface in the Java language using
|
||||
the Swing-based Java Application Desktop component (JAD) provided with OCAF.
|
||||
|
||||
@subsection ocaf_wp_1_4 Benefits of OCAF
|
||||
|
||||
@subsection ocaf_wp_1_4 An example of OCAF usage
|
||||
|
||||
As you use the architecture provided by OCAF, the design of your application is made easy:
|
||||
the application developer concentrates on the functionality
|
||||
instead of the underlying mechanisms required to support this functionality.
|
||||
To create a useful OCAF-based application, it is necessary to redefine two deferred methods: <i> Formats</i> and <i> ResourcesName</i>
|
||||
|
||||
In the <i> Formats </i> method, add the format of the documents, which need to be read by the application and may have been built in other applications.
|
||||
|
||||
For example:
|
||||
|
||||
~~~~
|
||||
void myApplication::Formats(TColStd_SequenceOfExtendedString& Formats)
|
||||
{
|
||||
Formats.Append(TCollection_ExtendedString ("OCAF-myApplication"));
|
||||
}
|
||||
~~~~
|
||||
|
||||
In the <i> ResourcesName</i> method, you only define the name of the resource file. This
|
||||
file contains several definitions for the saving and opening mechanisms associated
|
||||
with each format and calling of the plug-in file.
|
||||
|
||||
~~~~
|
||||
Standard_CString myApplication::ResourcesName()
|
||||
{
|
||||
return Standard_CString ("Resources");
|
||||
}
|
||||
~~~~
|
||||
|
||||
To obtain the saving and opening mechanisms, it is necessary to set two environment variables: <i> CSF_PluginDefaults</i>, which defines the path of the plug-in file, and <i> CSF_ResourcesDefault</i>, which defines the resource file:
|
||||
|
||||
~~~~
|
||||
SetEnvironmentVariable ( "CSF_ResourcesDefaults",myDirectory);
|
||||
SetEnvironmentVariable ( "CSF_PluginDefaults",myDirectory);
|
||||
~~~~
|
||||
|
||||
The plugin and the resource files of the application will be located in <i> myDirector</i>.
|
||||
The name of the plugin file must be <i>Plugin</i>.
|
||||
|
||||
### Resource File
|
||||
|
||||
The resource file describes the documents (type and extension) and
|
||||
the type of data that the application can manipulate
|
||||
by identifying the storage and retrieval drivers appropriate for this data.
|
||||
|
||||
Each driver is unique and identified by a GUID generated, for example, with the <i> uuidgen </i> tool in Windows.
|
||||
|
||||
Five drivers are required to use all standard attributes provided within OCAF:
|
||||
|
||||
* the schema driver (ad696002-5b34-11d1-b5ba-00a0c9064368)
|
||||
* the document storage driver (ad696000-5b34-11d1-b5ba-00a0c9064368)
|
||||
* the document retrieval driver (ad696001-5b34-11d1-b5ba-00a0c9064368)
|
||||
* the attribute storage driver (47b0b826-d931-11d1-b5da-00a0c9064368)
|
||||
* the attribute retrieval driver (47b0b827-d931-11d1-b5da-00a0c9064368)
|
||||
|
||||
These drivers are provided as plug-ins and are located in the <i> PappStdPlugin</i> library.
|
||||
|
||||
|
||||
For example, this is a resource file, which declares a new model document OCAF-MyApplication:
|
||||
|
||||
~~~~
|
||||
formatlist:OCAF-MyApplication
|
||||
OCAF-MyApplication.Description: MyApplication Document Version 1.0
|
||||
OCAF-MyApplication.FileExtension: sta
|
||||
OCAF-MyApplication.StoragePlugin: ad696000-5b34-11d1-b5ba-00a0c9064368
|
||||
OCAF-MyApplication.RetrievalPlugin: ad696001-5b34-11d1-b5ba-00a0c9064368
|
||||
OCAF-MyApplicationSchema: ad696002-5b34-11d1-b5ba-00a0c9064368
|
||||
OCAF-MyApplication.AttributeStoragePlugin: 47b0b826-d931-11d1-b5da-00a0c9064368
|
||||
OCAF-MyApplication.AttributeRetrievalPlugin: 47b0b827-d931-11d1-b5da-00a0c9064368
|
||||
~~~~
|
||||
|
||||
Also, thanks to the coupling with the other Open CASCADE Technology modules,
|
||||
your application can rapidly be prototyped. In addition, the final application
|
||||
can be developed by industrializing the prototype — you don't need to restart the development from scratch.
|
||||
|
||||
Last but not least, you base your application on an Open Source component:
|
||||
this guarantees the long-term usefulness of your development.
|
||||
|
||||
### Plugin File
|
||||
|
||||
The plugin file describes the list of required plug-ins to run the application and the
|
||||
libraries in which plug-ins are located.
|
||||
|
||||
You need at least the <i> FWOSPlugin</i> and the plug-in drivers to run an OCAF application.
|
||||
|
||||
The syntax of each item is <i> Identification.Location Library_Name, </i> where:
|
||||
* Identification is GUID.
|
||||
* Location defines the location of the Identification (where its definition is found).
|
||||
* Library_Name is the name (and path to) the library, where the plug-in is located.
|
||||
|
||||
For example, this is a Plugin file:
|
||||
|
||||
~~~~
|
||||
a148e300-5740-11d1-a904-080036aaa103.Location: FWOSPlugin
|
||||
! base document drivers plugin
|
||||
ad696000-5b34-11d1-b5ba-00a0c9064368.Location: PAppStdPlugin
|
||||
ad696001-5b34-11d1-b5ba-00a0c9064368.Location: PAppStdPlugin
|
||||
ad696002-5b34-11d1-b5ba-00a0c9064368.Location: PAppStdPlugin
|
||||
47b0b826-d931-11d1-b5da-00a0c9064368.Location: PAppStdPlugin
|
||||
47b0b827-d931-11d1-b5da-00a0c9064368.Location: PAppStdPlugin
|
||||
~~~~
|
||||
|
||||
@section ocaf_wp_2 A Look Inside OCAF
|
||||
|
||||
@@ -290,27 +379,17 @@ OCAF uses other modules of Open CASCADE Technology — the Shape attribute is im
|
||||
|
||||
@subsection ocaf_wp_2_3 Persistent Data Storage
|
||||
|
||||
In OCAF, persistence, that is, the mechanism used to save a document in a file,
|
||||
is based on an explicit formal description of the data saved.
|
||||
@subsubsection ocaf_wp_2_3_1 Introduction
|
||||
|
||||
In OCAF, persistence, that is, the mechanism used to save a document in a file, is based on an explicit formal description of the data saved.
|
||||
|
||||
When you open a document, the application reads the corresponding file
|
||||
and first creates a memory representation of it.
|
||||
This representation is then converted to the application data model —
|
||||
the OCAF-based data structure the application operates on.
|
||||
The file's memory representation consists of objects defined by classes known as persistent.
|
||||
The persistent classes needed by an application to save its documents make the application's data schema.
|
||||
This schema defines the way the data are organized in the file — the format of the data.
|
||||
In other words, the file is simply an ASCII dump of the persistent data defined by the schema,
|
||||
the persistent data being created from the application data model during the save process.
|
||||
|
||||
Only canonical information is saved. As a matter of fact,
|
||||
the application data model usually contains additional data to optimize processing.
|
||||
For example, the persistent Bézier curve is defined by its poles, whereas
|
||||
its data model equivalent also contains coefficients used to compute a point at a given parameter.
|
||||
The additional data is calculated when the document is opened.
|
||||
|
||||
The major advantages of this approach are the following:
|
||||
When you open a document, the application reads the corresponding file and first creates a memory representation of it. This representation is then converted to the application data model — the OCAF-based data structure the application operates on. The file's memory representation consists of objects defined by classes known as persistent.
|
||||
|
||||
The persistent classes needed by an application to save its documents make the application's data schema. This schema defines the way the data are organized in the file — the format of the data. In other words, the file is simply an ASCII dump of the persistent data defined by the schema, the persistent data being created from the application data model during the save process.
|
||||
|
||||
Only canonical information is saved. As a matter of fact, the application data model usually contains additional data to optimize processing. For example, the persistent Bézier curve is defined by its poles, whereas its data model equivalent also contains coefficients used to compute a point at a given parameter. The additional data is calculated when the document is opened.
|
||||
|
||||
The major advantages of this approach are the following:
|
||||
* Providing that the data format is published, files created by OCAF-based applications
|
||||
can be read without needing a runtime of the application (openness)
|
||||
* Although the persistence approach makes the data format more stable,
|
||||
@@ -329,4 +408,214 @@ Applications using compound documents extensively (saving data in many files lin
|
||||
|
||||
In order to ease the delegation of document management to a data management application, OCAF encapsulates the file management functions in a driver (the meta-data driver). You have to implement this driver for your application to communicate with the data management system of your choice.
|
||||
|
||||
|
||||
|
||||
@subsubsection ocaf_wp_2_3_2 Schemes of Persistence
|
||||
|
||||
There are three schemes of persistence, which you can use to store and retrieve OCAF data (documents):
|
||||
|
||||
* <i> Standard</i> persistence schema, compatible with previous OCAF applications
|
||||
* <i> XmlOcaf</i> persistence, allowing the storage of all OCAF data in XML form
|
||||
* <i> BinOcaf</i> persistence, allowing the storage of all OCAF data in binary format form
|
||||
|
||||
|
||||
All schemes are independent of each other, but they guarantee that the standard OCAF
|
||||
attributes stored and retrieved by one schema will be storable and retrievable by
|
||||
the other. Therefore in any OCAF application you can use any persistence schema or
|
||||
even all three of them. The choice is made depending on the *Format* string of stored OCAF documents
|
||||
or automatically by the file header data - on retrieval.
|
||||
|
||||
Persistent data storage in OCAF using the <i> Standard</i> package is presented in:
|
||||
|
||||
* Basic Data Storage
|
||||
* Persistent Collections
|
||||
|
||||
Persistent storage of shapes is presented in the following chapters:
|
||||
|
||||
* Persistent Geometry
|
||||
* Persistent Topology
|
||||
|
||||
Finally, information about opening and saving persistent data is presented in Standard
|
||||
Documents.
|
||||
|
||||
@subsubsection ocaf_wp_2_3_3 Basic Data Storage
|
||||
|
||||
Normally, all data structures provided by Open CASCADE Technology are run-time structures,
|
||||
in other words, transient data. As transient data, they exist only while an application
|
||||
is running and are not stored permanently. However, the Data Storage module provides
|
||||
resources, which enable an application to store data on disk as persistent data.
|
||||
|
||||
Data storage services also provide libraries of persistent classes and translation
|
||||
functions needed to translate data from transient to persistent state and vice-versa.
|
||||
|
||||
#### Libraries of persistent classes
|
||||
|
||||
Libraries of persistent classes are extensible libraries of elementary classes you
|
||||
use to define the database schema of your application. They include:
|
||||
* Unicode (8-bit or 16-bit character type) strings
|
||||
* Collections of any kind of persistent data such as arrays.
|
||||
|
||||
All persistent classes are derived from the \b Persistent base class, which defines
|
||||
a unique way of creating and handling persistent objects. You create new persistent
|
||||
classes by inheriting from this base class.
|
||||
|
||||
#### Translation Functions
|
||||
|
||||
Translation functions allow you to convert persistent objects to transient ones and
|
||||
vice-versa. These translation functions are used to build Storage and Retrieval drivers
|
||||
of an application.
|
||||
|
||||
For each class of 2D and 3D geometric types, and for the general shape class in the
|
||||
topological data structure library, there are corresponding persistent class libraries,
|
||||
which allow you to translate your data with ease.
|
||||
|
||||
#### Creation of Persistent Classes
|
||||
|
||||
If you use Unix platforms as well as WOK and CDL, you can create your own persistent
|
||||
classes. In this case, data storage is achieved by implementing *Storage* and *Retrieval*
|
||||
drivers.
|
||||
|
||||
The <i> Storage </i> package is used to write and read persistent objects.
|
||||
These objects are read and written by a retrieval or storage algorithm
|
||||
(<i> Storage_Schema </i>object) in a container (disk, memory, network ...).
|
||||
Drivers (<i> FSD_File</i> objects) assign a physical container for data to be stored or retrieved.
|
||||
|
||||
The standard procedure for an application in reading a container is as follows:
|
||||
|
||||
* open the driver in reading mode,
|
||||
* call the Read function from the schema, setting the driver as a parameter. This function returns an instance of the <i> Storage_Data </i> class which contains the data being read,
|
||||
* close the driver.
|
||||
|
||||
The standard procedure for an application in writing a container is as follows:
|
||||
|
||||
* open the driver in writing mode,
|
||||
* create an instance of the <i> Storage_Data </i> class, then add the persistent data to write with the function <i> AddRoot</i>,
|
||||
* call the function <i> Write </i> from the schema, setting the driver and the <i> Storage_Data </i> instance as parameters,
|
||||
* close the driver.
|
||||
|
||||
@subsubsection ocaf_wp_2_3_4 Persistent Collections
|
||||
|
||||
Persistent collections are classes which handle dynamically sized collections of data that can be stored in the database. These collections provide three categories of service:
|
||||
|
||||
* persistent strings,
|
||||
* generic arrays of data,
|
||||
* commonly used instantiations of arrays.
|
||||
|
||||
Persistent strings are concrete classes that handle sequences of characters based
|
||||
on both ASCII (normal 8-bit) and Unicode (16-bit) character sets.
|
||||
|
||||
Arrays are generic classes, that is, they can hold a variety of objects not necessarily inheriting from a unique root class. These arrays can be instantiated with any kind of storable or persistent object, and then inserted into the persistent data model of a user application.
|
||||
|
||||
The purpose of these data collections is simply to convert transient data into its persistent equivalent so that it can be stored in the database. To this end, the collections are used to create the persistent data model and assure the link with the database. They do not provide editing or query capabilities because it is more efficient, within the operative data model of the application, to work with transient data structures (from the <i> TCollection</i> package).
|
||||
|
||||
For this reason:
|
||||
|
||||
* the persistent strings only provide constructors and functions to convert between transient and persistent strings, and
|
||||
* the persistent data collections are limited to arrays. In other words, <i> PCollection</i> does not include sequences, lists, and so on (unlike <i> TCollection</i>).
|
||||
|
||||
Persistent string and array classes are found in the <i> PCollection</i> package. In addition, <i> PColStd</i> package provides standard, and frequently used, instantiations of persistent arrays, for very simple objects.
|
||||
|
||||
@subsubsection ocaf_wp_2_3_5 Persistent Geometry
|
||||
|
||||
The Persistent Geometry component describes geometric data structures which can be stored in the database. These packages provide a way to convert data from the transient "world" to the persistent "world".
|
||||
|
||||
Persistent Geometry consists of a set of atomic data models parallel to the geometric data structures described in the geometry packages. Geometric data models, independent of each other, can appear within the data model of any application. The system provides the means to convert each atomic transient data model into a persistent one, but it does not provide a way for these data models to share data.
|
||||
|
||||
Consequently, you can create a data model using these components, store data in, and retrieve it from a file or a database, using the geometric components provided in the transient and persistent "worlds". In other words, you customize the system by declaring your own objects, and the conversion of the geometric components from persistent to transient and vice versa is automatically managed for you by the system.
|
||||
|
||||
However, these simple objects cannot be shared within a more complex data model. To allow data to be shared, you must provide additional tools.
|
||||
|
||||
Persistent Geometry is provided by several packages.
|
||||
|
||||
The <i> PGeom</i> package describes geometric persistent objects in 3D space, such as points,
|
||||
vectors, positioning systems, curves and surfaces.
|
||||
|
||||
These objects are persistent versions of those provided by the <i> Geom</i> package: for
|
||||
each type of transient object provided by Geom there is a corresponding type of persistent
|
||||
object in the <i>PGeom</i> package. In particular the inheritance structure is parallel.
|
||||
|
||||
However the <i> PGeom </i>package does not provide any functions to construct, edit or access
|
||||
the persistent objects. Instead the objects are manipulated as follows:
|
||||
|
||||
* Persistent objects are constructed by converting the equivalent transient <i> Geom </i> objects. To do this you use the <i>MgtGeom::Translate</i> function.
|
||||
* Persistent objects created in this way are used to build persistent data structures that are then stored in a file or database.
|
||||
* When these objects are retrieved from the file or database, they are converted back into the corresponding transient objects from the Geom package. To do this, you use <i>MgtGeom::Translate</i> function.
|
||||
|
||||
In other words, you always edit or query transient data structures within the transient
|
||||
data model supplied by the session.
|
||||
Consequently, the documentation for the <i> PGeom </i> package consists simply of a list of available objects.
|
||||
|
||||
The <i> PGeom2d </i> package describes persistent geometric objects in 2D space, such as points,
|
||||
vectors, positioning systems and curves. This package provides the same type of services
|
||||
as the <i> PGeom</i> package, but for the 2D geometric objects provided by the <i> Geom2d</i> package.
|
||||
Conversions are provided by the <i>MgtGeom::Translate</i> function.
|
||||
|
||||
~~~~
|
||||
//Create a coordinate system
|
||||
Handle(Geom_Axis2Placement) aSys;
|
||||
|
||||
|
||||
//Create a persistent coordinate PTopoDS_HShape.cdlsystem
|
||||
Handle(PGeom_Axis2placement)
|
||||
aPSys = MgtGeom::Translate(aSys);
|
||||
|
||||
//Restore a transient coordinate system
|
||||
Handle(PGeom_Axis2Placement) aPSys;
|
||||
|
||||
Handle(Geom_Axis2Placement)
|
||||
aSys = MgtGeom::Translate(aPSys);
|
||||
~~~~
|
||||
|
||||
|
||||
@subsubsection ocaf_wp_2_3_6 Persistent Topology
|
||||
|
||||
The Persistent Topology component describes topological data structures which can be stored in the database. These packages provide a way to convert data from the transient "world" to the persistent "world".
|
||||
|
||||
Persistent Topology is based on the BRep concrete data model provided by the topology packages. Unlike the components of the Persistent Geometry package, topological components can be fully shared within a single model, as well as between several models.
|
||||
|
||||
Each topological component is considered to be a shape: a <i> TopoDS_Shape</i> object. The system's capacity to convert a transient shape into a persistent shape and vice-versa applies to all objects, irrespective of their complexity: vertex, edge, wire, face, shell, solid, and so on.
|
||||
|
||||
When a user creates a data model using BRep shapes, he uses the conversion functions that the system provides to store the data in, and retrieve it from the database. The data can also be shared.
|
||||
|
||||
Persistent Topology is provided by several packages.
|
||||
|
||||
The <i> PTopoDS</i> package describes the persistent data model associated with any BRep shape; it is the persistent version of any shape of type <i> TopoDS_Shape</i>. As is the case for persistent geometric models, this data structure is never edited or queried, it is simply stored in or retrieved from the database. It is created or converted by the <i>MgtBRep::Translate</i> function.
|
||||
|
||||
The <i> MgtBRepAbs</i> and <i> PTColStd </i> packages provide tools used by the conversion functions of topological objects.
|
||||
|
||||
~~~~
|
||||
//Create a shape
|
||||
TopoDS_Shape aShape;
|
||||
|
||||
//Create a persistent shape
|
||||
PtColStd_DoubleTransientPersistentMap aMap;
|
||||
|
||||
Handle(PTopoDS_HShape) aPShape =
|
||||
aMap.Bind2(MgtBRep::Translate
|
||||
aShape,aMap,MgtBRepAbs_WithTriangle));
|
||||
|
||||
aPShape.Nullify();
|
||||
|
||||
//Restore a transient shape
|
||||
Handle(PTopoDS_HShape) aPShape;
|
||||
|
||||
Handle(TopoDS_HShape) aShape =
|
||||
aMap.Bind1(MgtBRep::Translate
|
||||
(aPShape,aMap,MgtBRepAbs_WithTriangle));
|
||||
|
||||
aShape.Nullify();
|
||||
~~~~
|
||||
|
||||
@subsubsection ocaf_wp_2_3_7 Standard Documents
|
||||
|
||||
Standard documents offer you a ready-to-use document containing a TDF-based data
|
||||
structure. The documents themselves are contained in a class inheriting from <i> TDocStd_Application</i>
|
||||
which manages creation, storage and retrieval of documents.
|
||||
|
||||
You can implement undo and redo in your document, and refer from the data framework
|
||||
of one document to that of another one. This is done by means of external link attributes,
|
||||
which store the path and the entry of external links. To sum up, standard documents
|
||||
alone provide access to the data framework. They also allow you to:
|
||||
* Update external links;
|
||||
* Manage the saving and opening of data;
|
||||
* Manage undo/redo functionality.
|
||||
|
||||
|
@@ -5,9 +5,35 @@ Shape Healing {#occt_user_guides__shape_healing}
|
||||
|
||||
@section occt_shg_1 Overview
|
||||
|
||||
@subsection occt_shg_1_1 Introduction
|
||||
|
||||
This manual explains how to use Shape Healing. It provides basic documentation on its operation. For advanced information on Shape Healing and its applications, see our offerings on our web site at <a href="http://www.opencascade.org/support/training/">www.opencascade.org/support/training/</a>
|
||||
|
||||
The **Shape Healing** toolkit provides a set of tools to work on the geometry and topology of Open CASCADE Technology (**OCCT**) shapes. Shape Healing adapts shapes so as to make them as appropriate for use by Open CASCADE Technology as possible.
|
||||
|
||||
@subsection occt_shg_1_2 Examples of use
|
||||
|
||||
Here are a few examples of typical problems with illustrations of how Shape Healing deals with them:
|
||||
|
||||
#### Face with missing seam edge
|
||||
|
||||
The problem: Face on a periodical surface is limited by wires which make a full trip around the surface. These wires are closed in 3d but not closed in parametric space of the surface. This is not valid in Open CASCADE.
|
||||
The solution: Shape Healing fixes this face by inserting seam edge which combines two open wires and thus closes the parametric space. Note that internal wires are processed correctly.
|
||||
|
||||
#### Wrong orientation of wires
|
||||
The problem: Wires on face have incorrect orientation, so that interior and outer parts of the face are mixed.
|
||||
The solution: Shape Healing recovers correct orientation of wires.
|
||||
|
||||
#### Self-intersecting wire
|
||||
The problem: Face is invalid because its boundary wire has self-intersection (on two adjacent edges)
|
||||
The solution: Shape Healing cuts intersecting edges at intersection points thus making boundary valid.
|
||||
|
||||
#### Lacking edge
|
||||
The problem: There is a gap between two edges in the wire, so that wire is not closed
|
||||
The solution: Shape Healing closes a gap by inserting lacking edge.
|
||||
|
||||
@subsection occt_shg_1_3 Toolkit Structure
|
||||
|
||||
**Shape Healing** currently includes several packages that are designed to help you to:
|
||||
* analyze shape characteristics and, in particular, identify shapes that do not comply with Open CASCADE Technology validity rules
|
||||
* fix some of the problems shapes may have
|
||||
@@ -28,7 +54,7 @@ Message management is used for creating messages, filling them with various para
|
||||
|
||||
Tools responsible for analysis, fixing and upgrading of shapes can give the information about how these operations were performed. This information can be obtained by the user with the help of mechanism of status querying.
|
||||
|
||||
@subsection occt_shg_1_1 Querying the statuses
|
||||
@subsection occt_shg_1_4 Querying the statuses
|
||||
|
||||
Each fixing and upgrading tool has its own status, which is reset when their methods are called. The status can contain several flags, which give the information about how the method was performed. For exploring the statuses, a set of methods named *Status...()* is provided. These methods accept enumeration *ShapeExtend_Status* and return True if the status has the corresponding flag set. The meaning of flags for each method is described below.
|
||||
|
||||
|