mirror of
https://git.dev.opencascade.org/repos/occt.git
synced 2025-04-03 17:56:21 +03:00
0027191: Documentation - redesign of information architecture -- revision (overview and samples)
Revision of Introduction, Overview, Samples, Tutorial - Technical Overview is incorporated into Introduction - Samples (from Overview) and Tutorial are moved into new section Tutorials and Samples - Content of Getting Started section (Draw Test Harness and Experimenting with Draw Test Harness) is moved into Tutorial and Samples section. - Content changes: links to Open Cascade website promoting paid training and support are deleted. - Some pictures in User Guides (Foundation Classes, Modeling Data, Modeling Algorithms) and Tutorial are updated to improve quality and correct mistakes.
This commit is contained in:
Vera Sdobnova
abv
parent
06ce029fb9
commit
0a6d974274
@ -7,14 +7,17 @@
|
|||||||
|
|
||||||
introduction/introduction.md
|
introduction/introduction.md
|
||||||
|
|
||||||
|
samples/samples.md
|
||||||
../samples/mfc/standard/ReadMe.md
|
../samples/mfc/standard/ReadMe.md
|
||||||
../samples/CSharp/ReadMe.md
|
../samples/CSharp/ReadMe.md
|
||||||
../samples/CSharp/ReadMe_D3D.md
|
../samples/CSharp/ReadMe_D3D.md
|
||||||
|
|
||||||
../samples/qt/AndroidQt/ReadMe.md
|
../samples/qt/AndroidQt/ReadMe.md
|
||||||
../samples/java/jniviewer/ReadMe.md
|
../samples/java/jniviewer/ReadMe.md
|
||||||
../samples/ios/UIKitSample/ReadMe.md
|
../samples/ios/UIKitSample/ReadMe.md
|
||||||
../samples/webgl/ReadMe.md
|
../samples/webgl/ReadMe.md
|
||||||
|
samples/ocaf.md
|
||||||
|
samples/ocaf_func.md
|
||||||
|
samples/draw_scripts.md
|
||||||
|
|
||||||
tutorial/tutorial.md
|
tutorial/tutorial.md
|
||||||
|
|
||||||
@ -26,8 +29,6 @@ build/build_documentation/building_documentation.md
|
|||||||
debug/debug.md
|
debug/debug.md
|
||||||
upgrade/upgrade.md
|
upgrade/upgrade.md
|
||||||
|
|
||||||
technical_overview/technical_overview.md
|
|
||||||
|
|
||||||
user_guides/user_guides.md
|
user_guides/user_guides.md
|
||||||
user_guides/foundation_classes/foundation_classes.md
|
user_guides/foundation_classes/foundation_classes.md
|
||||||
user_guides/modeling_data/modeling_data.md
|
user_guides/modeling_data/modeling_data.md
|
||||||
|
|||||||
@ -6,7 +6,7 @@ Build OCCT {#build_upgrade__building_occt}
|
|||||||
@note Before building OCCT, make sure to have all required third-party libraries installed.
|
@note Before building OCCT, make sure to have all required third-party libraries installed.
|
||||||
The list of required libraries depends on what OCCT modules will be used, and your preferences.
|
The list of required libraries depends on what OCCT modules will be used, and your preferences.
|
||||||
The typical minimum is **Freetype** (necessary for Visualization) and **Tcl/Tk** (for DRAW).
|
The typical minimum is **Freetype** (necessary for Visualization) and **Tcl/Tk** (for DRAW).
|
||||||
See @ref OCCT_OVW_SECTION_2 "requirements on 3rdparty libraries" for a full list.
|
See @ref intro_req "requirements on 3rdparty libraries" for a full list.
|
||||||
On OS X we recommend to use native libraries.
|
On OS X we recommend to use native libraries.
|
||||||
|
|
||||||
@section build_occt_windows Windows
|
@section build_occt_windows Windows
|
||||||
|
|||||||
@ -1,4 +1,4 @@
|
|||||||
Coding Rules {#occt_dev_guides__coding_rules}
|
Coding Rules {#occt_contribution__coding_rules}
|
||||||
======================================
|
======================================
|
||||||
|
|
||||||
@tableofcontents
|
@tableofcontents
|
||||||
|
|||||||
@ -1,15 +1,10 @@
|
|||||||
Developer Guides {#dev_guides}
|
Contribution {#contribution}
|
||||||
================
|
============
|
||||||
|
|
||||||
The following documents provide information on OCCT building, development and testing:
|
This chapter contains the detailed infomation about contribution procedure:
|
||||||
|
|
||||||
* @subpage occt_contribution__documentation "Documentation system"
|
* @subpage occt_contribution__contribution_workflow
|
||||||
* @subpage occt_dev_guides__coding_rules "Coding Rules"
|
* @subpage occt_contribution__git_guide
|
||||||
* @subpage occt_dev_guides__contribution_workflow "Contribution Workflow"
|
* @subpage occt_contribution__coding_rules
|
||||||
* @subpage occt_dev_guides__git_guide "Guide to installing and using Git for OCCT development"
|
* @subpage occt_contribution__tests
|
||||||
* @subpage occt_dev_guides__tests "Automatic Testing system"
|
* @subpage occt_contribution__documentation
|
||||||
* @subpage occt__debug "Debugging tools and hints"
|
|
||||||
|
|
||||||
The following guide provides information relevant to upgrading applications developed with previous versions of OCCT, to recent one:
|
|
||||||
|
|
||||||
* @subpage occt__upgrade "Upgrade from previous OCCT versions"
|
|
||||||
|
|||||||
@ -1,4 +1,4 @@
|
|||||||
Contribution Workflow {#occt_dev_guides__contribution_workflow}
|
Contribution Workflow {#occt_contribution__contribution_workflow}
|
||||||
====================================
|
====================================
|
||||||
@tableofcontents
|
@tableofcontents
|
||||||
|
|
||||||
@ -144,7 +144,7 @@ Change of layout or re-formatting of the existing code is allowed only in the pa
|
|||||||
|
|
||||||
@note If deemed useful, re-formatting or cosmetic changes affecting considerable parts of the code can be made within a dedicated issue.
|
@note If deemed useful, re-formatting or cosmetic changes affecting considerable parts of the code can be made within a dedicated issue.
|
||||||
|
|
||||||
The changes should comply with the OCCT @ref occt_dev_guides__coding_rules "Codng Rules".
|
The changes should comply with the OCCT @ref occt_contribution__coding_rules "Codng Rules".
|
||||||
It is especially important to comment the code properly so that other people can understand it easier.
|
It is especially important to comment the code properly so that other people can understand it easier.
|
||||||
|
|
||||||
The modification should be tested by running OCCT tests (on the platform and scope available to **Developer**) and ensuring absence of regressions.
|
The modification should be tested by running OCCT tests (on the platform and scope available to **Developer**) and ensuring absence of regressions.
|
||||||
@ -163,7 +163,7 @@ When the test case cannot be provided for any reason, the maximum possible infor
|
|||||||
|
|
||||||
If the change affects a functionality described in @ref user_guides "User Guides", the corresponding user guide should be updated to reflect the change.
|
If the change affects a functionality described in @ref user_guides "User Guides", the corresponding user guide should be updated to reflect the change.
|
||||||
|
|
||||||
If the change affects OCCT test system, build environment, or development tools described in @ref dev_guides "Developer Guides", the corresponding guide should be updated.
|
If the change affects OCCT test system, build environment, or development tools described in @ref build_upgrade "Build, Debug and Upgrade" or @ref contribution "Contribution", the corresponding guide should be updated.
|
||||||
|
|
||||||
The changes that break compatibility with the previous versions of OCCT (i.e. affecting API or behavior of existing functionality in the way that may require update of existing applications based on an earlier official release of OCCT to work correctly) should be described in the document @ref occt__upgrade "Upgrade from previous OCCT versions".
|
The changes that break compatibility with the previous versions of OCCT (i.e. affecting API or behavior of existing functionality in the way that may require update of existing applications based on an earlier official release of OCCT to work correctly) should be described in the document @ref occt__upgrade "Upgrade from previous OCCT versions".
|
||||||
It is recommended to add a sub-section for each change described.
|
It is recommended to add a sub-section for each change described.
|
||||||
@ -183,7 +183,7 @@ In case if the fix is implemented on the previous release of OCCT, the branch ca
|
|||||||
The branch name should be composed of letters **CR** (abbreviation of "Change Request") followed by the issue ID number (without leading zeros).
|
The branch name should be composed of letters **CR** (abbreviation of "Change Request") followed by the issue ID number (without leading zeros).
|
||||||
It is possible to add an optional suffix to the branch name after the issue ID, e.g. to distinguish between several versions of the fix (see @ref occt_contribution_nonstd_rebase).
|
It is possible to add an optional suffix to the branch name after the issue ID, e.g. to distinguish between several versions of the fix (see @ref occt_contribution_nonstd_rebase).
|
||||||
|
|
||||||
See @ref occt_dev_guides__git_guide "Guide to using GIT" for help.
|
See @ref occt_contribution__git_guide "Guide to using GIT" for help.
|
||||||
|
|
||||||
@note When a branch with the name given according to the above rule is pushed to Git, a note is automatically added to the corresponding issue in Mantis, indicating the person who has made the push, the commit hash, and (for new commits) the description.
|
@note When a branch with the name given according to the above rule is pushed to Git, a note is automatically added to the corresponding issue in Mantis, indicating the person who has made the push, the commit hash, and (for new commits) the description.
|
||||||
|
|
||||||
@ -226,7 +226,7 @@ The possible variants are:
|
|||||||
|
|
||||||
@subsection occt_contribution_workflow_review Code review
|
@subsection occt_contribution_workflow_review Code review
|
||||||
|
|
||||||
The **Reviewer** analyzes the proposed solution for applicability in accordance with OCCT @ref occt_dev_guides__coding_rules "Coding Rules" and examines all changes in the sources, test case(s), and documentation to detect obvious and possible errors, misprints, or violations of the coding style.
|
The **Reviewer** analyzes the proposed solution for applicability in accordance with OCCT @ref occt_contribution__coding_rules "Coding Rules" and examines all changes in the sources, test case(s), and documentation to detect obvious and possible errors, misprints, or violations of the coding style.
|
||||||
|
|
||||||
If the Reviewer detects some problems, he can either:
|
If the Reviewer detects some problems, he can either:
|
||||||
|
|
||||||
|
|||||||
@ -5,6 +5,22 @@
|
|||||||
|
|
||||||
@section OCCT_DM_SECTION_1 Introduction
|
@section OCCT_DM_SECTION_1 Introduction
|
||||||
|
|
||||||
|
OCCT documentation is provided in several forms:
|
||||||
|
|
||||||
|
- This overview provides general description of OCCT structure, functionality, modules, and features.
|
||||||
|
It is available in HTML format (generated by Doxygen) and includes User and Developer Guides.
|
||||||
|
The sources of this documentation are contained in **dox** subdirectory of OCCT sources
|
||||||
|
(plain text format is used, with mixed MarkDown / Doxygen syntax mark-up).
|
||||||
|
|
||||||
|
- User and Developer Guides describing in details OCCT modules and development tools are also available in
|
||||||
|
Adobe Portable Document Format (PDF). To read this format, you need Adobe Acrobat Reader,
|
||||||
|
which is a freeware and can be downloaded from the Adobe site.
|
||||||
|
|
||||||
|
- Full reference documentation covering all OCCT classes generated automatically by Doxygen
|
||||||
|
software is provided in HTML format.
|
||||||
|
Reference documentation is presented in **Modules --> Toolkits --> Packages --> Classes**
|
||||||
|
logic structure with cross-references to all OCCT classes and complete in-browser search by all classes.
|
||||||
|
|
||||||
This document provides practical guidelines for generation and editing of OCCT user documentation.
|
This document provides practical guidelines for generation and editing of OCCT user documentation.
|
||||||
|
|
||||||
@section OCCT_DM_SECTION_2 Prerequisites
|
@section OCCT_DM_SECTION_2 Prerequisites
|
||||||
@ -122,16 +138,16 @@ The documentation is generated in subfolder *doc* :
|
|||||||
|
|
||||||
@section OCCT_DM_SECTION_4 Adding a New Document
|
@section OCCT_DM_SECTION_4 Adding a New Document
|
||||||
|
|
||||||
Place a new document in the folder taking into account its logical position in the documentation hierarchy. For instance, the document *svn.md* about the use of SVN to work with OCCT source code can be placed into <i>/dox/dev_guides/</i>.
|
Place a new document in the folder taking into account its logical position in the documentation hierarchy. For instance, the document *svn.md* about the use of SVN to work with OCCT source code can be placed into <i>/dox/contribution/</i>.
|
||||||
|
|
||||||
If there are images in the document, it should be placed in its own folder containing a subfolder for images. For instance:
|
If there are images in the document, it should be placed in its own folder containing a subfolder for images. For instance:
|
||||||
* <i> /dox/dev_guides/svn/ </i> -- for *svn.md* file;
|
* <i> /dox/contribution/svn/ </i> -- for *svn.md* file;
|
||||||
* <i> /dox/dev_guides/svn/images/ </i> -- for images.
|
* <i> /dox/contribution/svn/images/ </i> -- for images.
|
||||||
|
|
||||||
Add a relative path to *svn.md* in file <i>dox/FILES.txt</i>. For instance
|
Add a relative path to *svn.md* in file <i>dox/FILES.txt</i>. For instance
|
||||||
|
|
||||||
@verbatim
|
@verbatim
|
||||||
dev_guides/svn/svn.md
|
contribution/svn/svn.md
|
||||||
@endverbatim
|
@endverbatim
|
||||||
|
|
||||||
**Note** that the order of paths to documents in *FILES.txt* is reproduced in the Table of Contents in the HTML output, thus they need to be placed logically.
|
**Note** that the order of paths to documents in *FILES.txt* is reproduced in the Table of Contents in the HTML output, thus they need to be placed logically.
|
||||||
@ -154,7 +170,7 @@ http://www.stack.nl/~dimitri/doxygen/manual
|
|||||||
A document file in *.md format must start with a proper header defining a caption and a unique tag.
|
A document file in *.md format must start with a proper header defining a caption and a unique tag.
|
||||||
|
|
||||||
@verbatim
|
@verbatim
|
||||||
Documentation System {#dev_guides__documentation}
|
Documentation System {#contribution__documentation}
|
||||||
=====================
|
=====================
|
||||||
@endverbatim
|
@endverbatim
|
||||||
|
|
||||||
|
|||||||
@ -1,4 +1,4 @@
|
|||||||
Guide to installing and using Git for OCCT development {#occt_dev_guides__git_guide}
|
Guide to installing and using Git for OCCT development {#occt_contribution__git_guide}
|
||||||
=================================
|
=================================
|
||||||
|
|
||||||
@tableofcontents
|
@tableofcontents
|
||||||
@ -17,7 +17,7 @@ Guide to installing and using Git for OCCT development {#occt_dev_guides__git_gu
|
|||||||
For the experienced Git users it can be enough to read sections 1 and 3
|
For the experienced Git users it can be enough to read sections 1 and 3
|
||||||
of this document to start working with the repository.
|
of this document to start working with the repository.
|
||||||
|
|
||||||
Familiarize yourselves with the @ref occt_dev_guides__contribution_workflow "Contribution Workflow document"
|
Familiarize yourselves with the @ref occt_contribution__contribution_workflow "Contribution Workflow document"
|
||||||
that describes how Git is used for processing contributions to OCCT.
|
that describes how Git is used for processing contributions to OCCT.
|
||||||
|
|
||||||
This and related documents are available at the Resources page
|
This and related documents are available at the Resources page
|
||||||
|
|||||||
@ -1,4 +1,4 @@
|
|||||||
Automated Testing System {#occt_dev_guides__tests}
|
Automated Testing System {#occt_contribution__tests}
|
||||||
======================================
|
======================================
|
||||||
|
|
||||||
@tableofcontents
|
@tableofcontents
|
||||||
|
|||||||
|
Before Width: | Height: | Size: 103 KiB After Width: | Height: | Size: 103 KiB |
|
Before Width: | Height: | Size: 57 KiB After Width: | Height: | Size: 57 KiB |
|
Before Width: | Height: | Size: 260 KiB After Width: | Height: | Size: 260 KiB |
|
Before Width: | Height: | Size: 84 KiB After Width: | Height: | Size: 84 KiB |
|
Before Width: | Height: | Size: 80 KiB After Width: | Height: | Size: 80 KiB |
|
Before Width: | Height: | Size: 97 KiB After Width: | Height: | Size: 97 KiB |
|
Before Width: | Height: | Size: 45 KiB After Width: | Height: | Size: 45 KiB |
|
Before Width: | Height: | Size: 118 KiB After Width: | Height: | Size: 118 KiB |
|
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
@ -7,26 +7,512 @@
|
|||||||
@figure{/resources/occt_logo.png}
|
@figure{/resources/occt_logo.png}
|
||||||
@htmlonly</center>@endhtmlonly
|
@htmlonly</center>@endhtmlonly
|
||||||
|
|
||||||
@section OCCT_OVW_SECTION_1 Welcome
|
|
||||||
|
|
||||||
Welcome to Open CASCADE Technology (OCCT), a software development platform
|
Welcome to Open CASCADE Technology (OCCT), a software development platform
|
||||||
providing services for 3D surface and solid modeling, CAD data exchange, and
|
providing services for 3D surface and solid modeling, CAD data exchange, and
|
||||||
visualization. Most of OCCT functionality is available in the form of C++
|
visualization. Most of OCCT functionality is available in the form of C++
|
||||||
libraries. OCCT can be best applied in development of software dealing with 3D
|
libraries. OCCT can be best applied in development of software dealing with 3D
|
||||||
modeling (CAD), manufacturing / measuring (CAM) or numerical simulation (CAE).
|
modeling (CAD), manufacturing / measuring (CAM) or numerical simulation (CAE).
|
||||||
|
|
||||||
@section OCCT_OVW_SECTION_2 Copyrights
|
|
||||||
|
|
||||||
Open CASCADE Technology and all materials, including this documentation, is
|
|
||||||
Copyright (c) 1999-2018 by OPEN CASCADE S.A.S. All rights reserved.
|
|
||||||
|
|
||||||
@htmlonly<center>@endhtmlonly
|
@htmlonly<center>@endhtmlonly
|
||||||
https://www.opencascade.com
|
https://www.opencascade.com
|
||||||
@figure{/resources/occ_logo.png}
|
@figure{/resources/occ_logo.png}
|
||||||
@htmlonly</center>@endhtmlonly
|
@htmlonly</center>@endhtmlonly
|
||||||
|
|
||||||
License
|
@section intro_overview Overview
|
||||||
--------
|
|
||||||
|
Open CASCADE Technology (OCCT) is an object-oriented C++ class library designed for rapid production of sophisticated domain-specific CAD/CAM/CAE applications.
|
||||||
|
|
||||||
|
A typical application developed using OCCT deals with two or three-dimensional (2D or 3D) geometric modeling
|
||||||
|
in general-purpose or specialized Computer Aided Design (CAD) systems, manufacturing
|
||||||
|
or analysis applications, simulation applications, or even illustration tools.
|
||||||
|
|
||||||
|
OCCT library is designed to be truly modular and extensible, providing C++ classes for:
|
||||||
|
* Basic data structures (geometric modeling, visualization, interactive selection and application specific services);
|
||||||
|
* Modeling algorithms;
|
||||||
|
* Working with mesh (faceted) data;
|
||||||
|
* Data interoperability with neutral formats (IGES, STEP);
|
||||||
|
|
||||||
|
The C++ classes and other types are grouped into packages. Packages are organized into toolkits (libraries), to which you can link your application. Finally, toolkits are grouped into seven modules.
|
||||||
|
|
||||||
|
This modular structure is illustrated in the diagram below.
|
||||||
|
|
||||||
|
@figure{/introduction/images/technical_overview_schema.png}
|
||||||
|
|
||||||
|
* @ref intro_overview_fclasses "Foundation Classes" module underlies all other OCCT classes;
|
||||||
|
* @ref intro_overview_moddata "Modeling Data" module supplies data structures to represent 2D and 3D geometric primitives and their compositions into CAD models;
|
||||||
|
* @ref intro_overview_modalgo "Modeling Algorithms" module contains a vast range of geometrical and topological algorithms;
|
||||||
|
* @ref intro_overview_mesh "Mesh" toolkit from "Modeling Algorithms" module implements tessellated representations of objects;
|
||||||
|
* @ref intro_overview_visu "Visualization" module provides complex mechanisms for graphical data representation;
|
||||||
|
* @ref intro_overview_de "Data Exchange" module inter-operates with popular data formats and relies on @ref intro_overview_heal "Shape Healing" to improve compatibility between CAD software of different vendors;
|
||||||
|
* @ref intro_overview_ocaf "Application Framework" module offers ready-to-use solutions for handling application-specific data (user attributes) and commonly used functionality (save/restore, undo/redo, copy/paste, tracking CAD modifications, etc).
|
||||||
|
|
||||||
|
In addition, @ref intro_overview_draw "Open CASCADE Test Harness", also called Draw, provides an entry point to the library and can be used as a testing tool for its modules.
|
||||||
|
|
||||||
|
@subsection intro_overview_fclasses Foundation Classes
|
||||||
|
|
||||||
|
**Foundation Classes** module contains data structures and services used by higher-level Open CASCADE Technology classes:
|
||||||
|
|
||||||
|
* Primitive types, such as Boolean, Character, Integer or Real;
|
||||||
|
* String classes that handle Unicode strings;
|
||||||
|
* Collection classes that handle statically or dynamically sized aggregates of data, such as arrays, lists, queues, sets and hash tables (data maps).
|
||||||
|
* Classes providing commonly used numerical algorithms and basic linear algebra calculations (addition, multiplication, transposition of vectors and matrices, solving linear systems etc).
|
||||||
|
* Fundamental types like color, date and time information;
|
||||||
|
* Primitive geometry types providing implementation of basic geometric and algebraic entities that define and manipulate elementary data structures.
|
||||||
|
* Exception classes that describe situations, when the normal execution of program is abandoned;
|
||||||
|
|
||||||
|
This module also provides a variety of general-purpose services, such as:
|
||||||
|
* Safe handling of dynamically created objects, ensuring automatic deletion of unreferenced objects (smart pointers);
|
||||||
|
* Standard and specialized memory allocators;
|
||||||
|
* Extended run-time type information (RTTI) mechanism maintaining a full type hierarchy and providing means to iterate over it;
|
||||||
|
* Encapsulation of C++ streams;
|
||||||
|
* Basic interpreter of expressions facilitating the creation of customized scripting tools, generic definition of expressions, etc.;
|
||||||
|
* Tools for dealing with configuration resource files and customizable message files facilitating 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;
|
||||||
|
* and many others...
|
||||||
|
|
||||||
|
See the details in @ref occt_user_guides__foundation_classes "Foundation Classes User's Guide"
|
||||||
|
|
||||||
|
@subsection intro_overview_moddata Modeling Data
|
||||||
|
|
||||||
|
**Modeling Data** supplies data structures to implement boundary representation (BRep) of objects in 3D.
|
||||||
|
In BRep the shape is represented as an aggregation of geometry within topology.
|
||||||
|
The geometry is understood as a mathematical description of a shape, e.g. as curves and surfaces (simple or canonical, Bezier, NURBS, etc).
|
||||||
|
The topology is a data structure binding geometrical objects together.
|
||||||
|
|
||||||
|
Geometry types and utilities provide geometric data structures and services 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.
|
||||||
|
* Creation of parametric curves and surfaces by interpolation and approximation;
|
||||||
|
* Algorithms of direct construction;
|
||||||
|
* Conversion of curves and surfaces to NURBS form;
|
||||||
|
* Computation of point coordinates on 2D and 3D curves;
|
||||||
|
* Calculation of extrema between geometric objects.
|
||||||
|
|
||||||
|
Topology defines relationships between simple geometric entities.
|
||||||
|
A shape, which is a basic topological entity, can be divided into components (sub-shapes):
|
||||||
|
* Vertex -- a zero-dimensional shape corresponding to a point;
|
||||||
|
* Edge -- a shape corresponding to a curve and bounded by a vertex at each extremity;
|
||||||
|
* Wire -- a sequence of edges connected by their vertices;
|
||||||
|
* Face -- a part of a plane (in 2D) or a surface (in 3D) bounded by wires;
|
||||||
|
* Shell -- a collection of faces connected by edges of their wire boundaries;
|
||||||
|
* Solid -- a finite closed part of 3D space bounded by shells;
|
||||||
|
* Composite solid -- a collection of solids connected by faces of their shell boundaries;
|
||||||
|
* Compound -- a collection of shapes of arbitrary type.
|
||||||
|
|
||||||
|
Complex shapes can be defined as assemblies (compounds) of simpler entities.
|
||||||
|
|
||||||
|
See the details in @ref occt_user_guides__modeling_data "Modeling Data User's Guide"
|
||||||
|
|
||||||
|
3D geometric models can be stored in OCCT native BREP format.
|
||||||
|
See @ref specification__brep_format "BREP Format Description White Paper" for details on the format.
|
||||||
|
|
||||||
|
@subsection intro_overview_modalgo Modeling Algorithms
|
||||||
|
|
||||||
|
**Modeling Algorithms** module groups a wide range of topological and geometric algorithms used in geometric modeling.
|
||||||
|
Basically, there are two groups of algorithms in Open CASCADE Technology:
|
||||||
|
* High-level modeling routines used in the real design;
|
||||||
|
* Low-level mathematical support functions used as a groundwork for the modeling API.
|
||||||
|
|
||||||
|
Low-level *geometric tools* provide the algorithms, which:
|
||||||
|
* Calculate the intersection of two curves, surfaces, or a curve and a surface;
|
||||||
|
* Project points onto 2D and 3D curves, points onto surfaces and 3D curves onto surfaces;
|
||||||
|
* Construct lines and circles from constraints;
|
||||||
|
* Construct free-form curves and surfaces from constraints (interpolation, approximation, skinning, gap filling, etc).
|
||||||
|
|
||||||
|
Low-level *topological tools* provide the algorithms, which:
|
||||||
|
* Tessellate shapes;
|
||||||
|
* Check correct definition of shapes;
|
||||||
|
* Determine the local and global properties of shapes (derivatives, mass-inertia properties, etc);
|
||||||
|
* Perform affine transformations;
|
||||||
|
* Find planes in which edges are located;
|
||||||
|
* Convert shapes to NURBS geometry;
|
||||||
|
* Sew connected topologies (shells and wires) from separate topological elements (faces and edges).
|
||||||
|
|
||||||
|
Top-level API provides the following functionality:
|
||||||
|
* Construction of Primitives:
|
||||||
|
* Boxes;
|
||||||
|
* Prisms;
|
||||||
|
* Cylinders;
|
||||||
|
* Cones;
|
||||||
|
* Spheres;
|
||||||
|
* Toruses.
|
||||||
|
* Kinematic Modeling:
|
||||||
|
* Prisms -- linear sweeps;
|
||||||
|
* Revolutions -- rotational sweeps;
|
||||||
|
* Pipes -- general-form sweeps;
|
||||||
|
* Lofting.
|
||||||
|
|
||||||
|
@figure{/introduction/images/0001.png "Shapes containing pipes with variable radius produced by sweeping"}
|
||||||
|
|
||||||
|
* Boolean Operations, which allow creating new shapes from the combinations of source shapes. For two shapes *S1* and *S2*:
|
||||||
|
* *Common* contains all points that are in *S1* and *S2*;
|
||||||
|
* *Fuse* contains all points that are in *S1* or *S2*;
|
||||||
|
* *Cut* contains all points in that are in *S1* and not in *S2*.
|
||||||
|
|
||||||
|
See @ref specification__boolean_operations "Boolean Operations" User's Guide for detailed documentation.
|
||||||
|
|
||||||
|
* Algorithms for local modifications such as:
|
||||||
|
* Hollowing;
|
||||||
|
* Shelling;
|
||||||
|
* Creation of tapered shapes using draft angles;
|
||||||
|
* Algorithms to make fillets and chamfers on shape edges, including those with variable radius (chord).
|
||||||
|
|
||||||
|
* Algorithms for creation of mechanical features, i.e. depressions, protrusions, ribs and grooves or slots along planar or revolution surfaces.
|
||||||
|
|
||||||
|
@figure{/introduction/images/0004.png}
|
||||||
|
|
||||||
|
See the details in @ref occt_user_guides__modeling_algos "Modeling Algorithms User's Guide".
|
||||||
|
|
||||||
|
@subsection intro_overview_mesh Mesh
|
||||||
|
|
||||||
|
**Mesh** toolkit provides the functionality to work with tessellated representations of objects in form of triangular facets. This toolkit contains:
|
||||||
|
- data structures to store surface mesh data associated to shapes and basic algorithms to handle them;
|
||||||
|
- data structures and algorithms to build triangular surface mesh from *BRep* objects (shapes);
|
||||||
|
- tools for displaying meshes with associated pre- and post-processor data (scalars or vectors).
|
||||||
|
|
||||||
|
Open CASCADE SAS also offers Advanced Mesh Products:
|
||||||
|
- <a href="https://www.opencascade.com/content/mesh-framework">Open CASCADE Mesh Framework (OMF)</a>
|
||||||
|
- <a href="https://www.opencascade.com/content/express-mesh">Express Mesh</a>
|
||||||
|
|
||||||
|
@figure{/introduction/images/0003.png}
|
||||||
|
|
||||||
|
@subsection intro_overview_visu Visualization
|
||||||
|
|
||||||
|
**Visualization** module provides ready-to-use algorithms to create graphic presentations from various objects: shapes, meshes, etc.
|
||||||
|
|
||||||
|
In Open CASCADE Technology visualization is based on the separation of CAD data and its graphical presentation.
|
||||||
|
The module also supports a fast and powerful interactive selection mechanism.
|
||||||
|
|
||||||
|
Visualization module relies on the following key toolkits:
|
||||||
|
- *TKV3d* toolkit defines a high-level API called (Application Interactive Services* (AIS) for working with interactive objects.
|
||||||
|
- *TKService* toolkit defines a low-level API for managing and creating presentations from primitive arrays.
|
||||||
|
This toolkit defines an abstraction layer for defining an arbitrary graphic driver responsible for actual rendering.
|
||||||
|
- *TKOpenGl* toolkit implements the graphic driver using OpenGL and OpenGL ES libraries.
|
||||||
|
|
||||||
|
While low-level API operates with primitive arrays (triangles, lines, points), the higher level includes services for building presentations for B-Rep shapes (shaded and wireframe).
|
||||||
|
A comprehensive list of standard interactive objects includes topological shape, mesh presentation, various dimensions, manipulators and others.
|
||||||
|
It provides a solid basis for rapid application development, while flexible and extensible API allows development of highly customized application-specific presentations.
|
||||||
|
|
||||||
|
Here are a few examples of OCCT Visualization features:
|
||||||
|
* Camera-driven view projection and orientation.
|
||||||
|
Perspective, orthographic and stereographic projections are supported.
|
||||||
|
* Support of Common (diffuse/ambient/specular) and PBR metallic-roughness material models.
|
||||||
|
* Possibility to flexibly adjust appearance of dimensions in a 3D view.
|
||||||
|
The 3D text object represents a given text string as a true 3D object in the model space.
|
||||||
|
* Definition of clipping planes through the plane equation coefficients.
|
||||||
|
Ability to define visual attributes for cross-section at the level or individual clipping planes.
|
||||||
|
In the image below different parts of the rocket are clipped with different planes and hatched.
|
||||||
|
@figure{/introduction/images/0008.png, "Display of shape cross-section and dimensions"}
|
||||||
|
|
||||||
|
* Support of built-in and application-specific GLSL shaders.
|
||||||
|
@figure{/introduction/images/0013.png, "Fragment shader implementing custom clipping surface"}
|
||||||
|
|
||||||
|
* Optimization of rendering performance through the algorithms of:
|
||||||
|
* View frustum culling, which skips the presentation outside camera at the rendering stage;
|
||||||
|
* Back face culling, which reduces the rendered number of triangles and eliminates artifacts at shape boundaries.
|
||||||
|
* Real-time ray tracing technique using recursive Whitted's algorithm and Bounded Volume Hierarchy effective optimization structure.
|
||||||
|
@figure{introduction/images/0002.png, "Real time visualization by ray tracing method"}
|
||||||
|
@figure{introduction/images/0012.png, "Simulation of a glass cover"}
|
||||||
|
|
||||||
|
For more details, see @ref occt_user_guides__visualization "Visualization User's Guide".
|
||||||
|
|
||||||
|
The visualization of OCCT topological shapes by means of VTK library provided by VIS component is described in a separate @ref occt_user_guides__vis "VTK Integration Services" User's Guide.
|
||||||
|
|
||||||
|
@subsection intro_overview_de Data Exchange
|
||||||
|
|
||||||
|
**Data Exchange** allows developing OCCT-based applications that can interact with other CAD systems by writing and reading CAD models to and from external data.
|
||||||
|
|
||||||
|
@figure{/introduction/images/0014.png,"Shape imported from STEP"}
|
||||||
|
|
||||||
|
**Data Exchange** is organized in a modular way as a set of interfaces that comply with various CAD formats: IGES, STEP, STL, VRML, etc.
|
||||||
|
The interfaces allow software based on OCCT to exchange data with various CAD/PDM software packages, maintaining a good level of interoperability.
|
||||||
|
This module handles various problems of interoperability between CAD systems, caused by differences in model validity criteria and requirements to internal representation.
|
||||||
|
|
||||||
|
* **Standardized Data Exchange** interfaces allow querying and examining the input file, converting its contents to a CAD model and running validity checks on a fully translated shape.
|
||||||
|
The following formats are currently supported:
|
||||||
|
* @ref occt_user_guides__step "STEP" (AP203: Mechanical Design, this covers General 3D CAD; AP214: Automotive Design; AP242).
|
||||||
|
* @ref occt_iges_1 "IGES" (up to 5.3).
|
||||||
|
* **glTF** 2.0 reader and writer.
|
||||||
|
* **OBJ** mesh file reader.
|
||||||
|
* **VRML** converter translates Open CASCADE shapes to VRML 1.0 files (Virtual Reality Modeling Language).
|
||||||
|
* **STL** converter translates Open CASCADE shapes to STL files.
|
||||||
|
STL (STtereoLithography) format is widely used for rapid prototyping (3D printing).
|
||||||
|
* @ref occt_user_guides__xde "Extended data exchange" (XDE) allows translating additional attributes attached to geometric data (colors, layers, names, materials etc).
|
||||||
|
* <a href="https://www.opencascade.com/content/advanced-data-exchange-components">Advanced Data Exchange Components</a>
|
||||||
|
are available in addition to standard Data Exchange interfaces to support interoperability and data adaptation (also using @ref intro_overview_heal "Shape Healing") with CAD software using the following proprietary formats:
|
||||||
|
* <a href="https://www.opencascade.com/content/acis-sat-import-export">ACIS SAT</a>
|
||||||
|
* <a href="https://www.opencascade.com/content/parasolid-import">Parasolid</a>
|
||||||
|
* <a href="https://www.opencascade.com/content/dxf-import-export">DXF</a>
|
||||||
|
* <a href="https://www.opencascade.com/content/ifc-import">IFC</a>
|
||||||
|
* <a href="https://www.opencascade.com/content/jt-import-export">JT</a>
|
||||||
|
|
||||||
|
These components are based on the same architecture as interfaces with STEP and IGES.
|
||||||
|
|
||||||
|
@subsection intro_overview_heal Shape Healing
|
||||||
|
|
||||||
|
**Shape Healing** library provides algorithms to correct and adapt the geometry and topology of shapes imported to OCCT from other CAD systems.
|
||||||
|
|
||||||
|
Shape Healing algorithms include, but are not limited to, the following operations:
|
||||||
|
* Analyze shape characteristics and, in particular, identify the shapes that do not comply with OCCT geometry and topology validity rules by analyzing geometrical objects and topology:
|
||||||
|
- check edge and wire consistency;
|
||||||
|
- check edge order in a wire;
|
||||||
|
- check the orientation of face boundaries;
|
||||||
|
- analyze shape tolerances;
|
||||||
|
- identify closed and open wires in a boundary.
|
||||||
|
* Fix incorrect or incomplete shapes:
|
||||||
|
- provide consistency between a 3D curve and its corresponding parametric curve;
|
||||||
|
- repair defective wires;
|
||||||
|
- fit the shapes to a user-defined tolerance value;
|
||||||
|
- fill gaps between patches and edges.
|
||||||
|
* Upgrade and change shape characteristics:
|
||||||
|
- reduce curve and surface degree;
|
||||||
|
- split shapes to obtain C1 continuity;
|
||||||
|
- convert any types of curves or surfaces to Bezier or B-Spline curves or surfaces and back;
|
||||||
|
- split closed surfaces and revolution surfaces.
|
||||||
|
|
||||||
|
Each sub-domain of Shape Healing has its own scope of functionality:
|
||||||
|
|
||||||
|
| Sub-domain | Description | Impact on the shape |
|
||||||
|
| :--- | :---- | :---- |
|
||||||
|
| Analysis | Explores shape properties, computes shape features, detects violation of OCCT requirements. | The shape itself is not modified. |
|
||||||
|
| Fixing | Fixes the shape to meet the OCCT requirements. | The shape may change its original form: modification, removal or creation of sub-shapes, etc.) |
|
||||||
|
| Upgrade | Improves the shape to fit some particular algorithms. | The shape is replaced with a new one, but geometrically they are the same. |
|
||||||
|
| Customization | Modifies the shape representation to fit specific needs. | The shape is not modified, only the mathematical form of its internal representation is changed. |
|
||||||
|
| Processing | Mechanism of shape modification via a user-editable resource file. | |
|
||||||
|
|
||||||
|
For more details, refer to @ref occt_shg "Shape Healing User's guide".
|
||||||
|
|
||||||
|
@subsection intro_overview_ocaf Application Framework
|
||||||
|
|
||||||
|
**Open CASCADE Application Framework** (OCAF) handles Application Data basing on the Application/Document paradigm.
|
||||||
|
It uses an associativity engine to simplify the development of a CAD application thanks to the following ready-to-use features and services:
|
||||||
|
|
||||||
|
* Data attributes managing the application data, which can be organized according to the development needs;
|
||||||
|
* Data storage and persistence (open/save);
|
||||||
|
* Possibility to modify and recompute attributes in documents.
|
||||||
|
With OCAF it is easy to represent the history of modification and parametric dependencies within your model;
|
||||||
|
* Possibility to manage multiple documents;
|
||||||
|
* Predefined attributes common to CAD/CAM/CAE applications (e.g. to store dimensions);
|
||||||
|
* Undo-Redo and Copy-Paste functions.
|
||||||
|
|
||||||
|
Since OCAF handles the application structure, the only development task is the creation of application-specific data and GUIs.
|
||||||
|
|
||||||
|
OCAF differs from any other CAD framework in the organization of application data, as there the data structures are based on reference keys rather than on shapes.
|
||||||
|
In a model, such attributes as shape data, color and material are attached to an invariant structure, which is deeper than the shapes.
|
||||||
|
A shape object becomes the value of *Shape* attribute, in the same way as an integer number is the value of *Integer* attribute and a string is the value of *Name* attribute.
|
||||||
|
|
||||||
|
OCAF organizes and embeds these attributes in a document. OCAF documents, in their turn, are managed by an OCAF application.
|
||||||
|
|
||||||
|
For more details, see @ref occt_user_guides__ocaf "OCAF User's Guide".
|
||||||
|
|
||||||
|
@subsection intro_overview_draw Draw Test Harness
|
||||||
|
|
||||||
|
**Test Harness** or **Draw** is a convenient testing tool for OCCT libraries.
|
||||||
|
It can be used to test and prototype various algorithms before building an entire application.
|
||||||
|
It includes:
|
||||||
|
- A command interpreter based on the TCL language;
|
||||||
|
- A number of 2D and 3D viewers;
|
||||||
|
- A set of predefined commands.
|
||||||
|
|
||||||
|
The viewers support operations such as zoom, pan, rotation and full-screen views.
|
||||||
|
|
||||||
|
The basic commands provide general-purpose services such as:
|
||||||
|
- Getting help;
|
||||||
|
- Evaluating a script from a file;
|
||||||
|
- Capturing commands in a file;
|
||||||
|
- Managing views;
|
||||||
|
- Displaying objects.
|
||||||
|
|
||||||
|
In addition, **Test Harness** provides commands to create and manipulate curves and surfaces (geometry) and shapes, access visualization services, work with OCAF documents, perform data exchange, etc.
|
||||||
|
|
||||||
|
You can add custom commands to test or demonstrate any new functionalities, which you develop.
|
||||||
|
|
||||||
|
For more details, see @ref occt_user_guides__test_harness "Draw Test Harness Manual".
|
||||||
|
|
||||||
|
@section intro_req Requirements
|
||||||
|
|
||||||
|
Open CASCADE Technology is designed to be highly portable and is known to
|
||||||
|
work on wide range of platforms.
|
||||||
|
Current version is officially certified on Windows (IA-32 and x86-64),
|
||||||
|
Linux (x86-64), OS X / macOS (x86-64), Android (armv7 and x86), and
|
||||||
|
iOS (armv7, arm64) platforms.
|
||||||
|
|
||||||
|
The tables below describe the recommended software configurations
|
||||||
|
for which OCCT is certified to work.
|
||||||
|
|
||||||
|
@subsection intro_req_cpp C++ Compiler / IDE
|
||||||
|
|
||||||
|
| OS | Compiler |
|
||||||
|
| --------- | ----------- |
|
||||||
|
| Windows | Microsoft Visual Studio: 2008 SP1, 2010 SP1, 2012 Update 4, 2013 Update 5, 2015 Update 3, 2017 <sup>1</sup>, 2019 <br>, LLVM (ClangCL), GCC 4.3+ (Mingw-w64)|
|
||||||
|
| Linux | GNU gcc 4.3+ <br> LLVM CLang 3.6+ |
|
||||||
|
| OS X / macOS | XCode 6 or newer |
|
||||||
|
| Android | NDK r10, GNU gcc 4.8 or newer |
|
||||||
|
| Web | Emscripten SDK 1.39 or newer (CLang) |
|
||||||
|
|
||||||
|
1) VC++ 141 64-bit is used for regular testing and for building binary package of official release of OCCT on Windows.
|
||||||
|
|
||||||
|
@subsection intro_req_libs Third-party libraries
|
||||||
|
|
||||||
|
| Component | Requirement |
|
||||||
|
| --------- | ----------- |
|
||||||
|
| Graphic library | OpenGL 3.3+, OpenGL ES 2.0+ <br> Direct3D 9 |
|
||||||
|
| Qt (for samples and demos) | Desktop: Qt 4.8.6+ https://www.qt.io/download/ <br> Android: Qt 5.3.2+ https://www.qt.io/download/ |
|
||||||
|
| TCL (for testing tools) | Tcl/Tk 8.6.3+ https://www.tcl.tk/software/tcltk/download.html <br> or ActiveTcl 8.6 https://www.activestate.com/activetcl/downloads (for Windows)|
|
||||||
|
| Freetype (for text rendering) | FreeType 2.4.11-2.7.1 https://sourceforge.net/projects/freetype/files/ |
|
||||||
|
| FreeImage (optional, for support of common 2D graphic formats) | FreeImage 3.17.0+ https://sourceforge.net/projects/freeimage/files |
|
||||||
|
| FFmpeg (optional, for video recording) | FFmpeg 3.1+ https://www.ffmpeg.org/download.html |
|
||||||
|
| RapidJSON (optional, for reading glTF) | RapidJSON 1.1+ https://rapidjson.org/ |
|
||||||
|
| Intel TBB (optional, for multithreaded algorithms) | TBB 4.x or 5.x https://www.threadingbuildingblocks.org/ |
|
||||||
|
| VTK (for VTK Integration Services | VTK 6.1+ https://www.vtk.org/download/ |
|
||||||
|
| Doxygen (optional for building documentation) | Doxygen 1.8.5+ https://www.stack.nl/~dimitri/doxygen/download.html |
|
||||||
|
|
||||||
|
@subsection intro_req_hw Hardware
|
||||||
|
|
||||||
|
| Component | Requirement |
|
||||||
|
| --------- | ----------- |
|
||||||
|
| Minimum memory | 512 MB, 1 GB recommended |
|
||||||
|
| Free disk space (complete installation) | 600 MB approx. |
|
||||||
|
|
||||||
|
On desktop, 3D viewer for optimal performance requires graphics processing unit (GPU) supporting OpenGL 3.3 or above.
|
||||||
|
Ray tracing requires OpenGL 4.0+ or OpenGL 3.3+ with *GL_ARB_texture_buffer_object_rgb32* extension.
|
||||||
|
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 (OpenGL ES 3.1+ is recommended).
|
||||||
|
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).
|
||||||
|
|
||||||
|
OCCT 3D Viewer, in general, supports wide range of graphics hardware - from very old to new.
|
||||||
|
Therefore, if you observe some unexpected visual issues - first check for OpenGL driver update (or firmware update in case of mobile platforms);
|
||||||
|
but beware that driver update might also come with new bugs.
|
||||||
|
Don't forget to report these bugs to vendors.
|
||||||
|
|
||||||
|
@section intro_install Installation
|
||||||
|
|
||||||
|
In most cases you need to rebuild OCCT on your platform (OS, compiler) before
|
||||||
|
using it in your project, to ensure binary compatibility.
|
||||||
|
See @ref build_upgrade for instructions on building OCCT from sources on supported platforms.
|
||||||
|
|
||||||
|
The following subsections describe how OCCT can be installed from ready-to-use packages on different platforms.
|
||||||
|
|
||||||
|
@subsection intro_install_windows Windows
|
||||||
|
|
||||||
|
On Windows Open CASCADE Technology can be installed with binaries precompiled by
|
||||||
|
Visual C++ 2010 with installation procedure.
|
||||||
|
|
||||||
|
**Recommendation:**
|
||||||
|
|
||||||
|
If you have a previous version of OCCT installed on your station,
|
||||||
|
and you do not plan to use it along with the new version, you might want to uninstall
|
||||||
|
the previous version (using Control Panel, Add/Remove Programs) before
|
||||||
|
the installation of this new version, to avoid possible problems
|
||||||
|
(conflict of system variables, paths, etc).
|
||||||
|
|
||||||
|
**Attention:** For full installation OCCT requires approximately 650 Mb of disk space,
|
||||||
|
but during the installation process you will need 1,2 Gb of free disk space.
|
||||||
|
|
||||||
|
OCCT installation with reference documentation requires 1,4 Gb on disk.
|
||||||
|
|
||||||
|
* Download the OCCT installer from OPEN CASCADE web site using the link. you have been provided
|
||||||
|
* Launch the installer and follow the instructions.
|
||||||
|
|
||||||
|
The includes and binaries of third-party libraries necessary for building and launching
|
||||||
|
OCCT are included into binary distribution (built with Visual C++ 2010).
|
||||||
|
When the installation is complete, you will find the directories for 3rd party products
|
||||||
|
(some might be absent in case of custom installation) and the main **OCCT** directory:
|
||||||
|
|
||||||
|
@figure{/introduction/images/overview_3rdparty.png}
|
||||||
|
|
||||||
|
The contents of the OCCT-7.4.0 directory (called further "OCCT root", or $CASROOT) are as follows:
|
||||||
|
|
||||||
|
@figure{/introduction/images/overview_installation.png, "The directory tree"}
|
||||||
|
|
||||||
|
* **adm** This folder contains administration files, which allow rebuilding OCCT;
|
||||||
|
* **adm/cmake** This folder contains files of CMake building procedure;
|
||||||
|
* **adm/msvc** This folder contains Visual Studio projects for Visual C++ 2010, 2012, 2013, 2015, 2017 and 2019 which allow rebuilding OCCT under Windows platform in 32 and 64-bit mode;
|
||||||
|
* **data** This folder contains CAD files in different formats, which can be used to test the OCCT functionality;
|
||||||
|
* **doc** This folder contains OCCT documentation in HTML and PDF format;
|
||||||
|
* **dox** This folder contains sources of OCCT documentation in plain text (MarkDown) format;
|
||||||
|
* **inc** This folder contains copies of all OCCT header files;
|
||||||
|
* **samples** This folder contains sample applications.
|
||||||
|
* **src** This folder contains OCCT source files. They are organized in folders, one per development unit;
|
||||||
|
* **tests** This folder contains scripts for OCCT testing.
|
||||||
|
* **tools** This folder contains sources of Inspector tool.
|
||||||
|
* **win64/vc10** This folder contains executable and library files built in optimize mode for Windows platform by Visual C++ 2010;
|
||||||
|
|
||||||
|
@subsection intro_install_linux Linux
|
||||||
|
|
||||||
|
OCCT is available as package "opencascade" in official repositories of many Linux distributions.
|
||||||
|
|
||||||
|
See https://repology.org/project/opencascade/versions for overview of available repositories.
|
||||||
|
|
||||||
|
@subsection intro_install_mac macOS
|
||||||
|
|
||||||
|
On macOS, OCCT is available in Homebrew (https://formulae.brew.sh/formula/opencascade)
|
||||||
|
amd MacPorts (https://ports.macports.org/port/opencascade/summary) repositories.
|
||||||
|
|
||||||
|
@section intro_env Environment Variables
|
||||||
|
|
||||||
|
To run any Open CASCADE Technology application you need to set the environment variables.
|
||||||
|
|
||||||
|
### On Windows
|
||||||
|
|
||||||
|
You can define the environment variables with env.bat script located in the
|
||||||
|
$CASROOT folder. This script accepts two arguments to be used:
|
||||||
|
the version of Visual Studio (vc10 -- vc142) and the architecture (win32 or win64).
|
||||||
|
|
||||||
|
The additional environment settings necessary for compiling OCCT libraries and samples
|
||||||
|
by Microsoft Visual Studio can be set using script custom.bat located in the same folder.
|
||||||
|
You might need to edit this script to correct the paths to third-party libraries
|
||||||
|
if they are installed on your system in a non-default location.
|
||||||
|
|
||||||
|
Script msvc.bat can be used with the same arguments for immediate launch of Visual Studio for (re)compiling OCCT.
|
||||||
|
|
||||||
|
### On Unix
|
||||||
|
|
||||||
|
|
||||||
|
If OCCT was built by Code::Blocks, you can define the environment variables with env_cbp.sh or custom_cbp.sh script.
|
||||||
|
|
||||||
|
If OCCT was built by Automake, you can define the environment variables with env_amk.sh or custom_amk.sh script.
|
||||||
|
|
||||||
|
The scripts are located in the OCCT root folder.
|
||||||
|
|
||||||
|
### Description of system variables:
|
||||||
|
|
||||||
|
* **CASROOT** is used to define the root directory of Open CASCADE Technology;
|
||||||
|
* **PATH** is required to define the path to OCCT binaries and 3rdparty folder;
|
||||||
|
* **LD_LIBRARY_PATH** is required to define the path to OCCT libraries (on UNIX platforms only; **DYLD_LIBRARY_PATH** variable in case of macOS);
|
||||||
|
* **MMGT_OPT** (optional) if set to 1, the memory manager performs optimizations as described below; if set to 2,
|
||||||
|
Intel (R) TBB optimized memory manager is used; if 0 (default), every memory block is allocated
|
||||||
|
in C memory heap directly (via malloc() and free() functions).
|
||||||
|
In the latter case, all other options starting with *MMGT*, except MMGT_CLEAR, are ignored;
|
||||||
|
* **MMGT_CLEAR** (optional) if set to 1 (default), every allocated memory block is cleared by zeros;
|
||||||
|
if set to 0, memory block is returned as it is;
|
||||||
|
* **MMGT_CELLSIZE** (optional) defines the maximal size of blocks allocated in large pools of memory. Default is 200;
|
||||||
|
* **MMGT_NBPAGES** (optional) defines the size of memory chunks allocated for small blocks in pages
|
||||||
|
(operating-system dependent). Default is 10000;
|
||||||
|
* **MMGT_THRESHOLD** (optional) defines the maximal size of blocks that are recycled internally
|
||||||
|
instead of being returned to the heap. Default is 40000;
|
||||||
|
* **MMGT_MMAP** (optional) 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();
|
||||||
|
* **CSF_LANGUAGE** (optional) defines default language of messages;
|
||||||
|
* **CSF_DEBUG** (optional, Windows only): if defined then a diagnostic message is displayed in case of an exception;
|
||||||
|
* **CSF_DEBUG_BOP** (optional): if defined then it should specify directory where diagnostic data on problems occured in Boolean operations will be saved;
|
||||||
|
* **CSF_MDTVTexturesDirectory** defines the directory for available textures when using texture mapping;
|
||||||
|
* **CSF_ShadersDirectory** (optional) defines the directory for GLSL programs for Ray Tracing renderer (embedded resources are used when variable is undefined);
|
||||||
|
* **CSF_SHMessage** (optional) defines the path to the messages file for *ShapeHealing*;
|
||||||
|
* **CSF_XSMessage** (optional) defines the path to the messages file for **STEP** and **IGES** translators;
|
||||||
|
* **CSF_StandardDefaults**, **CSF_StandardLiteDefaults*, **CSF_XCAFDefaults**, and **CSF_PluginDefaults** define paths to directory where configuration files for OCAF persistence are located (required for open/save operations with OCAF documents);
|
||||||
|
* **CSF_IGESDefaults** and **CSF_STEPDefaults** (optional) define paths to directory where resource files of **IGES** and **STEP** translators are located;
|
||||||
|
* **CSF_XmlOcafResource** is required in order to set the path to **XSD** resources, which defines XML grammar.
|
||||||
|
* **CSF_MIGRATION_TYPES** is required in order to read documents that contain old data types, such as *TDataStd_Shape*;
|
||||||
|
|
||||||
|
@section intro_license License
|
||||||
|
|
||||||
|
Open CASCADE Technology and all materials, including this documentation, is
|
||||||
|
Copyright (c) 1999-2018 by OPEN CASCADE S.A.S. All rights reserved.
|
||||||
|
|
||||||
Open CASCADE Technology is free software; you can redistribute it and / or modify it under the terms of the
|
Open CASCADE Technology is free software; you can redistribute it and / or modify it under the terms of the
|
||||||
@ref license_lgpl_21 "GNU Lesser General Public License (LGPL) version 2.1", with additional @ref occt_lgpl_exception "exception".
|
@ref license_lgpl_21 "GNU Lesser General Public License (LGPL) version 2.1", with additional @ref occt_lgpl_exception "exception".
|
||||||
@ -50,24 +536,7 @@ WARRANTY OF ANY KIND. The entire risk related to any use of the OCCT code and
|
|||||||
materials is on you. See the @ref occt_public_license "license" text for formal
|
materials is on you. See the @ref occt_public_license "license" text for formal
|
||||||
disclaimer.
|
disclaimer.
|
||||||
|
|
||||||
Trademark information
|
@section intro_acknowledge Acknowledgments
|
||||||
----------------------
|
|
||||||
|
|
||||||
You are hereby informed that all software is a property of its respective authors and is protected by
|
|
||||||
international and domestic laws on intellectual property and trademarks.
|
|
||||||
Should you need further information, directly contact the authors.
|
|
||||||
|
|
||||||
**CAS.CADE** and **Open CASCADE** are registered trademarks of
|
|
||||||
OPEN CASCADE S.A.S.
|
|
||||||
|
|
||||||
**Linux** is a registered trademark of Linus Torvalds.
|
|
||||||
|
|
||||||
**Windows** is a registered trademark of Microsoft Corporation in the United States and other countries.
|
|
||||||
|
|
||||||
**Mac** and the Mac logo are trademarks of Apple Inc., registered in the U.S. and other countries.
|
|
||||||
|
|
||||||
Acknowledgments
|
|
||||||
-----------------
|
|
||||||
|
|
||||||
The following parties are acknowledged for producing tools which are used within
|
The following parties are acknowledged for producing tools which are used within
|
||||||
Open CASCADE Technology libraries or for release preparation.
|
Open CASCADE Technology libraries or for release preparation.
|
||||||
@ -156,432 +625,14 @@ RapidJSON is optionally used by OCCT for reading glTF files (https://rapidjson.o
|
|||||||
**DejaVu** fonts are a font family based on the Vera Fonts under a permissive license (MIT-like, https://dejavu-fonts.github.io/License.html).
|
**DejaVu** fonts are a font family based on the Vera Fonts under a permissive license (MIT-like, https://dejavu-fonts.github.io/License.html).
|
||||||
DejaVu Sans (basic Latin sub-set) is used by OCCT as fallback font when no system font is available.
|
DejaVu Sans (basic Latin sub-set) is used by OCCT as fallback font when no system font is available.
|
||||||
|
|
||||||
**Delabella** is an open-source, cross-platform implementation of the Newton Apple Wrapper algorithm producing 2D Delaunay triangulation.
|
**Delabella** is an open-source, cross-platform implementation of the Newton Apple Wrapper algorithm producing 2D Delaunay triangulation. Delabella is used by BRepMesh as one of alternative 2D triangulation algorithms. Delabella is licensed under the MIT license (https://github.com/msokalski/delabella).
|
||||||
Delabella is used by BRepMesh as one of alternative 2D triangulation algorithms.
|
|
||||||
Delabella is licensed under the MIT license (https://github.com/msokalski/delabella).
|
|
||||||
|
|
||||||
Adobe Systems, Inc. provides **Adobe Reader**, which can be used to view files in Portable Document Format (PDF).
|
Adobe Systems, Inc. provides **Adobe Reader**, which can be used to view files in Portable Document Format (PDF).
|
||||||
|
|
||||||
@section OCCT_OVW_SECTION_3 Documentation
|
**CAS.CADE** and **Open CASCADE** are registered trademarks of OPEN CASCADE S.A.S.
|
||||||
|
|
||||||
OCCT documentation is provided in several forms:
|
**Linux** is a registered trademark of Linus Torvalds.
|
||||||
|
|
||||||
- This overview provides general description of OCCT structure, functionality, modules, and features.
|
**Windows** is a registered trademark of Microsoft Corporation in the United States and other countries.
|
||||||
It is available in HTML format (generated by Doxygen) and includes User and Developer Guides.
|
|
||||||
The sources of this documentation are contained in **dox** subdirectory of OCCT sources
|
|
||||||
(plain text format is used, with mixed MarkDown / Doxygen syntax mark-up).
|
|
||||||
|
|
||||||
- User and Developer Guides describing in details OCCT modules and development tools are also available in
|
**Mac**, **OS X**, **macOS**, and the Mac logo are trademarks of Apple Inc., registered in the U.S. and other countries.
|
||||||
Adobe Portable Document Format (PDF). To read this format, you need Adobe Acrobat Reader,
|
|
||||||
which is a freeware and can be downloaded from the Adobe site.
|
|
||||||
|
|
||||||
- Full reference documentation covering all OCCT classes generated automatically by Doxygen
|
|
||||||
software is provided in HTML format.
|
|
||||||
Reference documentation is presented in **Modules --> Toolkits --> Packages --> Classes**
|
|
||||||
logic structure with cross-references to all OCCT classes and complete in-browser search by all classes.
|
|
||||||
|
|
||||||
See @ref occt_contribution__documentation "OCCT Documentation Guide" for details on OCCT documentation system.
|
|
||||||
|
|
||||||
**Generation of HTML documentation**
|
|
||||||
|
|
||||||
To generate HTML documentation from sources contained in *dox* subdirectory,
|
|
||||||
you need to have Tcl and Doxygen 1.8.5 (or above) installed on your system.
|
|
||||||
|
|
||||||
Use script **gendoc** (batch file on Windows, shell script on Linux / Mac OSX) to generate documentation.
|
|
||||||
|
|
||||||
To generate Overview documentation:
|
|
||||||
|
|
||||||
cmd> gendoc -overview
|
|
||||||
|
|
||||||
To generate Reference manual:
|
|
||||||
|
|
||||||
cmd> gendoc -refman
|
|
||||||
|
|
||||||
Run this command without arguments to get help on supported options.
|
|
||||||
|
|
||||||
@section OCCT_OVW_SECTION_5 Requirements
|
|
||||||
|
|
||||||
Open CASCADE Technology is designed to be highly portable and is known to
|
|
||||||
work on wide range of platforms.
|
|
||||||
Current version is officially certified on Windows (IA-32 and x86-64),
|
|
||||||
Linux (x86-64), OS X / macOS (x86-64), Android (armv7 and x86), and
|
|
||||||
iOS (armv7, arm64) platforms.
|
|
||||||
|
|
||||||
The tables below describe the recommended software configurations
|
|
||||||
for which OCCT is certified to work.
|
|
||||||
|
|
||||||
@subsection overview_req_cpp C++ Compiler / IDE
|
|
||||||
|
|
||||||
| OS | Compiler |
|
|
||||||
| --------- | ----------- |
|
|
||||||
| Windows | Microsoft Visual Studio: 2008 SP1, 2010 SP1, 2012 Update 4, 2013 Update 5, 2015 Update 3, 2017 <sup>1</sup>, 2019 <br>, LLVM (ClangCL), GCC 4.3+ (Mingw-w64)|
|
|
||||||
| Linux | GNU gcc 4.3+ <br> LLVM CLang 3.6+ |
|
|
||||||
| OS X / macOS | XCode 6 or newer |
|
|
||||||
| Android | NDK r10, GNU gcc 4.8 or newer |
|
|
||||||
| Web | Emscripten SDK 1.39 or newer (CLang) |
|
|
||||||
|
|
||||||
1) VC++ 141 64-bit is used for regular testing and for building binary package of official release of OCCT on Windows.
|
|
||||||
|
|
||||||
@subsection overview_req_libs Third-party libraries
|
|
||||||
|
|
||||||
| Component | Requirement |
|
|
||||||
| --------- | ----------- |
|
|
||||||
| Graphic library | OpenGL 3.3+, OpenGL ES 2.0+ <br> Direct3D 9 |
|
|
||||||
| Qt (for samples and demos) | Desktop: Qt 4.8.6+ https://www.qt.io/download/ <br> Android: Qt 5.3.2+ https://www.qt.io/download/ |
|
|
||||||
| TCL (for testing tools) | Tcl/Tk 8.6.3+ https://www.tcl.tk/software/tcltk/download.html <br> or ActiveTcl 8.6 https://www.activestate.com/activetcl/downloads (for Windows)|
|
|
||||||
| Freetype (for text rendering) | FreeType 2.4.11-2.7.1 https://sourceforge.net/projects/freetype/files/ |
|
|
||||||
| FreeImage (optional, for support of common 2D graphic formats) | FreeImage 3.17.0+ https://sourceforge.net/projects/freeimage/files |
|
|
||||||
| FFmpeg (optional, for video recording) | FFmpeg 3.1+ https://www.ffmpeg.org/download.html |
|
|
||||||
| RapidJSON (optional, for reading glTF) | RapidJSON 1.1+ https://rapidjson.org/ |
|
|
||||||
| Intel TBB (optional, for multithreaded algorithms) | TBB 4.x or 5.x https://www.threadingbuildingblocks.org/ |
|
|
||||||
| VTK (for VTK Integration Services | VTK 6.1+ https://www.vtk.org/download/ |
|
|
||||||
| Doxygen (optional for building documentation) | Doxygen 1.8.5+ https://www.stack.nl/~dimitri/doxygen/download.html |
|
|
||||||
|
|
||||||
@subsection overview_req_hw Hardware
|
|
||||||
|
|
||||||
| Component | Requirement |
|
|
||||||
| --------- | ----------- |
|
|
||||||
| Minimum memory | 512 MB, 1 GB recommended |
|
|
||||||
| Free disk space (complete installation) | 600 MB approx. |
|
|
||||||
|
|
||||||
On desktop, 3D viewer for optimal performance requires graphics processing unit (GPU) supporting OpenGL 3.3 or above.
|
|
||||||
Ray tracing requires OpenGL 4.0+ or OpenGL 3.3+ with *GL_ARB_texture_buffer_object_rgb32* extension.
|
|
||||||
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 (OpenGL ES 3.1+ is recommended).
|
|
||||||
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).
|
|
||||||
|
|
||||||
OCCT 3D Viewer, in general, supports wide range of graphics hardware - from very old to new.
|
|
||||||
Therefore, if you observe some unexpected visual issues - first check for OpenGL driver update (or firmware update in case of mobile platforms);
|
|
||||||
but beware that driver update might also come with new bugs.
|
|
||||||
Don't forget to report these bugs to vendors.
|
|
||||||
|
|
||||||
@section OCCT_OVW_SECTION_4 Installation
|
|
||||||
|
|
||||||
In most cases you need to rebuild OCCT on your platform (OS, compiler) before
|
|
||||||
using it in your project, to ensure binary compatibility.
|
|
||||||
See @ref build_upgrade for instructions on
|
|
||||||
building OCCT from sources on supported platforms.
|
|
||||||
|
|
||||||
@subsection OCCT_OVW_SECTION_4_1 Using Windows installer
|
|
||||||
|
|
||||||
On Windows Open CASCADE Technology can be installed with binaries precompiled by
|
|
||||||
Visual C++ 2010 with installation procedure.
|
|
||||||
|
|
||||||
**Recommendation:**
|
|
||||||
|
|
||||||
If you have a previous version of OCCT installed on your station,
|
|
||||||
and you do not plan to use it along with the new version, you might want to uninstall
|
|
||||||
the previous version (using Control Panel, Add/Remove Programs) before
|
|
||||||
the installation of this new version, to avoid possible problems
|
|
||||||
(conflict of system variables, paths, etc).
|
|
||||||
|
|
||||||
**Attention:** For full installation OCCT requires approximately 650 Mb of disk space,
|
|
||||||
but during the installation process you will need 1,2 Gb of free disk space.
|
|
||||||
|
|
||||||
OCCT installation with reference documentation requires 1,4 Gb on disk.
|
|
||||||
|
|
||||||
* Download the OCCT installer from OPEN CASCADE web site using the link. you have been provided
|
|
||||||
* Launch the installer and follow the instructions.
|
|
||||||
|
|
||||||
The includes and binaries of third-party libraries necessary for building and launching
|
|
||||||
OCCT are included into binary distribution (built with Visual C++ 2010).
|
|
||||||
When the installation is complete, you will find the directories for 3rd party products
|
|
||||||
(some might be absent in case of custom installation) and the main **OCCT** directory:
|
|
||||||
|
|
||||||
@figure{/introduction/images/overview_3rdparty.png}
|
|
||||||
|
|
||||||
The contents of the OCCT-7.4.0 directory (called further "OCCT root", or $CASROOT) are as follows:
|
|
||||||
|
|
||||||
@figure{/introduction/images/overview_installation.png, "The directory tree"}
|
|
||||||
|
|
||||||
* **adm** This folder contains administration files, which allow rebuilding OCCT;
|
|
||||||
* **adm/cmake** This folder contains files of CMake building procedure;
|
|
||||||
* **adm/msvc** This folder contains Visual Studio projects for Visual C++ 2010, 2012, 2013, 2015, 2017 and 2019 which allow rebuilding OCCT under Windows platform in 32 and 64-bit mode;
|
|
||||||
* **data** This folder contains CAD files in different formats, which can be used to test the OCCT functionality;
|
|
||||||
* **doc** This folder contains OCCT documentation in HTML and PDF format;
|
|
||||||
* **dox** This folder contains sources of OCCT documentation in plain text (MarkDown) format;
|
|
||||||
* **inc** This folder contains copies of all OCCT header files;
|
|
||||||
* **samples** This folder contains sample applications.
|
|
||||||
* **src** This folder contains OCCT source files. They are organized in folders, one per development unit;
|
|
||||||
* **tests** This folder contains scripts for OCCT testing.
|
|
||||||
* **tools** This folder contains sources of Inspector tool.
|
|
||||||
* **win64/vc10** This folder contains executable and library files built in optimize mode for Windows platform by Visual C++ 2010;
|
|
||||||
|
|
||||||
@section OCCT_OVW_SECTION_4_2 Environment Variables
|
|
||||||
|
|
||||||
To run any Open CASCADE Technology application you need to set the environment variables.
|
|
||||||
|
|
||||||
### On Windows
|
|
||||||
|
|
||||||
You can define the environment variables with env.bat script located in the
|
|
||||||
$CASROOT folder. This script accepts two arguments to be used:
|
|
||||||
the version of Visual Studio (vc10 -- vc142) and the architecture (win32 or win64).
|
|
||||||
|
|
||||||
The additional environment settings necessary for compiling OCCT libraries and samples
|
|
||||||
by Microsoft Visual Studio can be set using script custom.bat located in the same folder.
|
|
||||||
You might need to edit this script to correct the paths to third-party libraries
|
|
||||||
if they are installed on your system in a non-default location.
|
|
||||||
|
|
||||||
Script msvc.bat can be used with the same arguments for immediate launch of Visual Studio for (re)compiling OCCT.
|
|
||||||
|
|
||||||
### On Unix
|
|
||||||
|
|
||||||
|
|
||||||
If OCCT was built by Code::Blocks, you can define the environment variables with env_cbp.sh or custom_cbp.sh script.
|
|
||||||
|
|
||||||
If OCCT was built by Automake, you can define the environment variables with env_amk.sh or custom_amk.sh script.
|
|
||||||
|
|
||||||
The scripts are located in the OCCT root folder.
|
|
||||||
|
|
||||||
|
|
||||||
### Description of system variables:
|
|
||||||
|
|
||||||
* **CASROOT** is used to define the root directory of Open CASCADE Technology;
|
|
||||||
* **PATH** is required to define the path to OCCT binaries and 3rdparty folder;
|
|
||||||
* **LD_LIBRARY_PATH** is required to define the path to OCCT libraries (on UNIX platforms only; **DYLD_LIBRARY_PATH** variable in case of macOS);
|
|
||||||
* **MMGT_OPT** (optional) if set to 1, the memory manager performs optimizations as described below; if set to 2,
|
|
||||||
Intel (R) TBB optimized memory manager is used; if 0 (default), every memory block is allocated
|
|
||||||
in C memory heap directly (via malloc() and free() functions).
|
|
||||||
In the latter case, all other options starting with *MMGT*, except MMGT_CLEAR, are ignored;
|
|
||||||
* **MMGT_CLEAR** (optional) if set to 1 (default), every allocated memory block is cleared by zeros;
|
|
||||||
if set to 0, memory block is returned as it is;
|
|
||||||
* **MMGT_CELLSIZE** (optional) defines the maximal size of blocks allocated in large pools of memory. Default is 200;
|
|
||||||
* **MMGT_NBPAGES** (optional) defines the size of memory chunks allocated for small blocks in pages
|
|
||||||
(operating-system dependent). Default is 10000;
|
|
||||||
* **MMGT_THRESHOLD** (optional) defines the maximal size of blocks that are recycled internally
|
|
||||||
instead of being returned to the heap. Default is 40000;
|
|
||||||
* **MMGT_MMAP** (optional) 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();
|
|
||||||
* **CSF_LANGUAGE** (optional) defines default language of messages;
|
|
||||||
* **CSF_DEBUG** (optional, Windows only): if defined then a diagnostic message is displayed in case of an exception;
|
|
||||||
* **CSF_DEBUG_BOP** (optional): if defined then it should specify directory where diagnostic data on problems occured in Boolean operations will be saved;
|
|
||||||
* **CSF_MDTVTexturesDirectory** defines the directory for available textures when using texture mapping;
|
|
||||||
* **CSF_ShadersDirectory** (optional) defines the directory for GLSL programs for Ray Tracing renderer (embedded resources are used when variable is undefined);
|
|
||||||
* **CSF_SHMessage** (optional) defines the path to the messages file for *ShapeHealing*;
|
|
||||||
* **CSF_XSMessage** (optional) defines the path to the messages file for **STEP** and **IGES** translators;
|
|
||||||
* **CSF_StandardDefaults**, **CSF_StandardLiteDefaults*, **CSF_XCAFDefaults**, and **CSF_PluginDefaults** define paths to directory where configuration files for OCAF persistence are located (required for open/save operations with OCAF documents);
|
|
||||||
* **CSF_IGESDefaults** and **CSF_STEPDefaults** (optional) define paths to directory where resource files of **IGES** and **STEP** translators are located;
|
|
||||||
* **CSF_XmlOcafResource** is required in order to set the path to **XSD** resources, which defines XML grammar.
|
|
||||||
* **CSF_MIGRATION_TYPES** is required in order to read documents that contain old data types, such as *TDataStd_Shape*;
|
|
||||||
|
|
||||||
@section OCCT_OVW_SECTION_7 Getting Started
|
|
||||||
|
|
||||||
@subsection OCCT_OVW_SECTION_7_1 Draw Test Harness
|
|
||||||
|
|
||||||
Draw is a command interpreter based on TCL and a graphical system used for testing and demonstrating OCCT modeling libraries.
|
|
||||||
|
|
||||||
Draw can be used interactively to create, display and modify objects such as curves, surfaces and topological shapes.
|
|
||||||
|
|
||||||
@figure{/introduction/images/overview_draw.png}
|
|
||||||
|
|
||||||
Scripts can be written to customize Draw and perform tests.
|
|
||||||
New types of objects and new commands can be added using C++ programming language.
|
|
||||||
|
|
||||||
Draw contains:
|
|
||||||
|
|
||||||
* A command interpreter based on TCL command language.
|
|
||||||
* A 2D an 3D graphic viewer with support of operations such as zoom, pan, rotation and full-screen views.
|
|
||||||
* An optional set of geometric commands to create and modify curves and surfaces and to use OCCT geometry algorithms.
|
|
||||||
* A set of topological commands to create and modify BRep shapes and to use OCCT topology algorithms.
|
|
||||||
* A set of graphic commands for view and display operations including Mesh Visualization Service.
|
|
||||||
* A set of Application framework commands for handling of files and attributes.
|
|
||||||
* A set of Data Exchange commands for translation of files from various formats (IGES,STEP) into OCCT shapes.
|
|
||||||
* A set of Shape Healing commands: check of overlapping edges, approximation of a shape to BSpline, etc.
|
|
||||||
|
|
||||||
You can add new custom test harness commands to Draw in order to test
|
|
||||||
or demonstrate a new functionality, which you are developing.
|
|
||||||
|
|
||||||
Currently DRAW Test Harness is a single executable called *DRAWEXE*.
|
|
||||||
|
|
||||||
Commands grouped in toolkits can be loaded at run-time thereby implementing dynamically loaded plug-ins.
|
|
||||||
Thus you can work only with the commands that suit your needs adding
|
|
||||||
the commands dynamically without leaving the Test Harness session.
|
|
||||||
|
|
||||||
Declaration of available plug-ins is done through special resource file(s).
|
|
||||||
The *pload* command loads the plug-in in accordance with
|
|
||||||
the specified resource file and activates the commands implemented in the plug-in.
|
|
||||||
|
|
||||||
The whole process of using the plug-in mechanism as well as the instructions for extending Test Harness is described in the @ref occt_user_guides__test_harness.
|
|
||||||
|
|
||||||
Draw Test Harness provides an environment for OCCT automated testing system.
|
|
||||||
Check its @ref occt_dev_guides__tests "Automated Testing System" for details.
|
|
||||||
|
|
||||||
Remarks:
|
|
||||||
|
|
||||||
* The DRAWEXE executable is delivered with the installation procedure on Windows platform only.
|
|
||||||
* To start it, launch DRAWEXE executable from Open CASCADE Technology/Draw Test Harness item of the Start\\Programs menu.
|
|
||||||
|
|
||||||
@subsection OCCT_OVW_SECTION_7_2 Experimenting with Draw Test Harness
|
|
||||||
|
|
||||||
Running Draw
|
|
||||||
------------
|
|
||||||
|
|
||||||
**On Linux:**
|
|
||||||
|
|
||||||
* If OCCT was built by Code::Blocks use <i>$CASROOT/draw.sh</i> file to launch *DRAWEXE* executable.
|
|
||||||
|
|
||||||
Draw[1]> prompt appears in the command window
|
|
||||||
|
|
||||||
Type *pload ALL*
|
|
||||||
|
|
||||||
**On Windows:**
|
|
||||||
|
|
||||||
Launch Draw executable from Open CASCADE Technology\\Test Harness\\Draw Test Harness
|
|
||||||
item of the Start\\Programs menu or Use <i>$CASROOT\\draw.bat</i> file to launch *DRAWEXE* executable.
|
|
||||||
|
|
||||||
Draw[1]> prompt appears in the command window
|
|
||||||
|
|
||||||
Type pload ALL
|
|
||||||
|
|
||||||
**Creating your first geometric objects**
|
|
||||||
|
|
||||||
1. In the command window, type *axo* to create an axonometric view
|
|
||||||
2. Type *box b -10 -10 -10 20 20 20* to create a cube *b* of size 20, parallel to the X Y Z axis and centered on the origin. The cube will be displayed in the axonometric view in wireframe mode.
|
|
||||||
3. Type *fit* to fill the viewer with the cube
|
|
||||||
4. Type *pcylinder c 2 30* to create a cylinder *c* of radius 2 and height 30. The cylinder will be displayed in addition to the cube
|
|
||||||
|
|
||||||
**Manipulating the view**
|
|
||||||
|
|
||||||
1. Type *clear* to erase the view
|
|
||||||
2. Type *donly c* to display the cylinder only
|
|
||||||
3. Type *donly b* to display the cube only
|
|
||||||
4. Type *hlr hlr b* to display the cube in the hidden line removal mode
|
|
||||||
|
|
||||||
**Running demonstration files**
|
|
||||||
|
|
||||||
1. Type *cd ../..* to return to the root directory
|
|
||||||
2. Type *cd samples/tcl* to reach the *DrawResources* directory
|
|
||||||
3. Type *source \<demo_file\>* to run the demonstration file provided with Open CASCADE. The following demonstration files are available:
|
|
||||||
* DataExchangeDemo.tcl: demonstrates sample sequence of operations with writing and reading IGES file
|
|
||||||
* ModelingDemo.tcl: demonstrates creation of simple shape and displaying it in HLR mode
|
|
||||||
* VisualizationDemo.tcl: demonstrates use of 3d viewer
|
|
||||||
* cad.tcl: creates solid shape looking like abbreviation "CAD"
|
|
||||||
* bottle.tcl: creates bottle as in OCCT Tutorial
|
|
||||||
* drill.tcl: creates twist drill bit shape
|
|
||||||
* cutter.tcl: creates milling cutter shape
|
|
||||||
* xde.tcl: demonstrates creation of simple assembly in XDE
|
|
||||||
* materials.tcl: demonstrates visual properties of materials supported by 3d viewer
|
|
||||||
* raytrace.tcl: demonstrates use of ray tracing display in 3d viewer
|
|
||||||
* dimensions.tcl: demonstrates use of dimensions, clipping, and capping in 3d viewer
|
|
||||||
|
|
||||||
**Getting Help**
|
|
||||||
|
|
||||||
1. Type *help* to see all available commands
|
|
||||||
2. Type *help \<command_name\>* to find out the arguments for a given command
|
|
||||||
|
|
||||||
@subsection OCCT_OVW_SECTION_7_3 Programming Samples
|
|
||||||
|
|
||||||
@subsubsection OCCT_OVW_SECTION_7_3_1 MFC
|
|
||||||
|
|
||||||
Visual C++ programming samples containing 10 Visual C++ projects
|
|
||||||
illustrating how to use a particular module or functionality.
|
|
||||||
|
|
||||||
The list of MFC samples:
|
|
||||||
|
|
||||||
* Geometry
|
|
||||||
* Modeling
|
|
||||||
* Viewer2d
|
|
||||||
* Viewer3d
|
|
||||||
* ImportExport
|
|
||||||
* Ocaf
|
|
||||||
* Triangulation
|
|
||||||
* HLR
|
|
||||||
* Animation
|
|
||||||
* Convert
|
|
||||||
|
|
||||||
@figure{/introduction/images/overview_mvc.png}
|
|
||||||
|
|
||||||
**Remarks:**
|
|
||||||
|
|
||||||
* MFC samples are available only on Windows platform;
|
|
||||||
* To start a sample use Open CASCADE Technology\\Samples\\Mfc\\ item of the Start\\Programs menu;
|
|
||||||
* Read carefully readme.txt to learn about launching and compilation options.
|
|
||||||
|
|
||||||
See \subpage samples_mfc_standard "Readme" for details.
|
|
||||||
|
|
||||||
@subsubsection OCCT_OVW_SECTION_7_3_2 Qt
|
|
||||||
|
|
||||||
OCCT contains three samples based on Qt application framework
|
|
||||||
|
|
||||||
Import Export
|
|
||||||
-------------
|
|
||||||
|
|
||||||
Import Export programming sample contains 3D Viewer and Import / Export functionality.
|
|
||||||
|
|
||||||
@figure{/introduction/images/overview_qt.png}
|
|
||||||
|
|
||||||
Tutorial
|
|
||||||
---------
|
|
||||||
|
|
||||||
The Qt programming tutorial teaches how to use Open CASCADE Technology services to model a 3D object.
|
|
||||||
The purpose of the tutorial is not to explain all OCCT classes but
|
|
||||||
to help start thinking in terms of the Open CASCADE Technology.
|
|
||||||
|
|
||||||
This tutorial assumes that the user has experience in using and setting up C++.
|
|
||||||
From the viewpoint of programming, Open CASCADE Technology is designed
|
|
||||||
to enhance user's C++ tools with high performance modeling classes, methods and functions.
|
|
||||||
The combination of these resources allows creating substantial applications.
|
|
||||||
|
|
||||||
**See also:** @ref occt__tutorial "OCCT Tutorial"
|
|
||||||
|
|
||||||
**Remarks:**
|
|
||||||
|
|
||||||
* Qt samples are available on all supported platforms;
|
|
||||||
* To start a sample on Windows use Open CASCADE Technology\\Samples\\Qt\\ item of the Start\\Programs menu.
|
|
||||||
|
|
||||||
@subsubsection OCCT_OVW_SECTION_7_3_3 C#
|
|
||||||
|
|
||||||
C# sample demonstrates integration of OCCT 3D Viewer and Import / Export functionality into .NET applications (using Windows Forms and WPF front ends).
|
|
||||||
|
|
||||||
@figure{/introduction/images/overview_c__ie.png}
|
|
||||||
|
|
||||||
Import:
|
|
||||||
|
|
||||||
* BRep
|
|
||||||
* Iges
|
|
||||||
* Step
|
|
||||||
|
|
||||||
Export:
|
|
||||||
|
|
||||||
* Brep
|
|
||||||
* Iges
|
|
||||||
* Step
|
|
||||||
* Stl
|
|
||||||
* Vrml
|
|
||||||
|
|
||||||
See \subpage samples_csharp_occt "C# sample Readme" for details.
|
|
||||||
|
|
||||||
There is also another C# example with the same functionality, which demonstrates the integration of Direct3D Viewer into .NET applications using WPF front end.
|
|
||||||
|
|
||||||
See \subpage samples_csharp_direct3d "Direct3D C# sample Readme" for details.
|
|
||||||
|
|
||||||
@subsubsection OCCT_OVW_SECTION_7_3_4 Android
|
|
||||||
|
|
||||||
There are two samples are representing usage OCCT framework on Android mobile platform. They represent an OCCT-based 3D-viewer with CAD import support in formats BREP, STEP and IGES: jniviewer (java) and AndroidQt (qt+qml)
|
|
||||||
|
|
||||||
jniviewer
|
|
||||||
@figure{/introduction/images/samples_java_android_occt.jpg}
|
|
||||||
Java -- See \subpage samples_java_android_occt "Android Java sample Readme" for details.
|
|
||||||
|
|
||||||
AndroidQt
|
|
||||||
@figure{/introduction/images/samples_qml_android_occt.jpg}
|
|
||||||
Qt -- See \subpage samples_qml_android_occt "Android Qt sample Readme" for details.
|
|
||||||
|
|
||||||
@subsubsection OCCT_OVW_SECTION_7_3_5 iOS
|
|
||||||
|
|
||||||
There is a sample demonstrating usage of OCCT on iOS with Apple UIKit framework.
|
|
||||||
|
|
||||||
@figure{/introduction/images/sample_ios_uikit.png}
|
|
||||||
|
|
||||||
See \subpage occt_samples_ios_uikit "iOS sample Readme" for details.
|
|
||||||
|
|
||||||
@subsubsection OCCT_OVW_SECTION_7_3_6 Web
|
|
||||||
|
|
||||||
WebGL Viewer sample demonstrating usage of OCCT 3D Viewer in Web browser with Emscripten SDK can be found in `samples/webgl`.
|
|
||||||
|
|
||||||
@figure{/introduction/images/sample_webgl.png}
|
|
||||||
|
|
||||||
See \subpage occt_samples_webgl "WebGL sample Readme" for details.
|
|
||||||
|
|||||||
Binary file not shown.
|
Before Width: | Height: | Size: 7.4 KiB After Width: | Height: | Size: 6.5 KiB |
125
dox/samples/draw_scripts.md
Normal file
125
dox/samples/draw_scripts.md
Normal file
@ -0,0 +1,125 @@
|
|||||||
|
Draw Demo Scripts {#samples__draw_scripts}
|
||||||
|
================
|
||||||
|
|
||||||
|
All demo scripts are provided with OCCT sources and locate in <i>CASROOT/samples/tcl</i>. To play around them please
|
||||||
|
follow the steps below:
|
||||||
|
|
||||||
|
1. Start DRAWEXE
|
||||||
|
2. Type *cd ../..* to return to the root directory
|
||||||
|
3. Type *cd samples/tcl* to reach the *DrawResources* directory
|
||||||
|
4. Type *source \<demo_file\>* to run the demonstration file provided with Open CASCADE. The following demonstration
|
||||||
|
files are available:
|
||||||
|
* <b>DataExchangeDemo.tcl</b>: demonstrates sample sequence of operations with writing and reading IGES file
|
||||||
|
* <b>ModelingDemo.tcl</b>: demonstrates creation of simple shape and displaying it in HLR mode
|
||||||
|
* <b>VisualizationDemo.tcl</b>: demonstrates use of 3d viewer
|
||||||
|
* <b>cad.tcl</b>: creates solid shape looking like abbreviation "CAD"
|
||||||
|
* <b>bottle.tcl</b>: creates bottle as in OCCT Tutorial
|
||||||
|
* <b>drill.tcl</b>: creates twist drill bit shape
|
||||||
|
* <b>cutter.tcl</b>: creates milling cutter shape
|
||||||
|
* <b>xde.tcl</b>: demonstrates creation of simple assembly in XDE
|
||||||
|
* <b>materials.tcl</b>: demonstrates visual properties of materials supported by 3d viewer
|
||||||
|
* <b>raytrace.tcl</b>: demonstrates use of ray tracing display in 3d viewer
|
||||||
|
* <b>dimensions.tcl</b>: demonstrates use of dimensions, clipping, and capping in 3d viewer
|
||||||
|
* ...
|
||||||
|
|
||||||
|
Draw is a command interpreter based on TCL and a graphical system used for testing and demonstrating OCCT modeling libraries.
|
||||||
|
|
||||||
|
Draw can be used interactively to create, display and modify objects such as curves, surfaces and topological shapes.
|
||||||
|
|
||||||
|
@figure{/introduction/images/overview_draw.png}
|
||||||
|
|
||||||
|
Scripts can be written to customize Draw and perform tests.
|
||||||
|
New types of objects and new commands can be added using C++ programming language.
|
||||||
|
|
||||||
|
Draw contains:
|
||||||
|
|
||||||
|
* A command interpreter based on TCL command language.
|
||||||
|
* A 2D an 3D graphic viewer with support of operations such as zoom, pan, rotation and full-screen views.
|
||||||
|
* An optional set of geometric commands to create and modify curves and surfaces and to use OCCT geometry algorithms.
|
||||||
|
* A set of topological commands to create and modify BRep shapes and to use OCCT topology algorithms.
|
||||||
|
* A set of graphic commands for view and display operations including Mesh Visualization Service.
|
||||||
|
* A set of Application framework commands for handling of files and attributes.
|
||||||
|
* A set of Data Exchange commands for translation of files from various formats (IGES,STEP) into OCCT shapes.
|
||||||
|
* A set of Shape Healing commands: check of overlapping edges, approximation of a shape to BSpline, etc.
|
||||||
|
|
||||||
|
You can add new custom test harness commands to Draw in order to test
|
||||||
|
or demonstrate a new functionality, which you are developing.
|
||||||
|
|
||||||
|
Currently DRAW Test Harness is a single executable called *DRAWEXE*.
|
||||||
|
|
||||||
|
Commands grouped in toolkits can be loaded at run-time thereby implementing dynamically loaded plug-ins.
|
||||||
|
Thus you can work only with the commands that suit your needs adding
|
||||||
|
the commands dynamically without leaving the Test Harness session.
|
||||||
|
|
||||||
|
Declaration of available plug-ins is done through special resource file(s).
|
||||||
|
The *pload* command loads the plug-in in accordance with
|
||||||
|
the specified resource file and activates the commands implemented in the plug-in.
|
||||||
|
|
||||||
|
The whole process of using the plug-in mechanism as well as the instructions for extending Test Harness is described in the @ref occt_user_guides__test_harness.
|
||||||
|
|
||||||
|
Draw Test Harness provides an environment for OCCT automated testing system.
|
||||||
|
Check its @ref occt_contribution__tests "Automated Testing System" for details.
|
||||||
|
|
||||||
|
Remarks:
|
||||||
|
|
||||||
|
* The DRAWEXE executable is delivered with the installation procedure on Windows platform only.
|
||||||
|
* To start it, launch DRAWEXE executable from Open CASCADE Technology/Draw Test Harness item of the Start\\Programs menu.
|
||||||
|
|
||||||
|
Experimenting with Draw Test Harness
|
||||||
|
------------------------------------
|
||||||
|
|
||||||
|
Running Draw
|
||||||
|
------------
|
||||||
|
|
||||||
|
**On Linux:**
|
||||||
|
|
||||||
|
* If OCCT was built by Code::Blocks use <i>$CASROOT/draw.sh</i> file to launch *DRAWEXE* executable.
|
||||||
|
|
||||||
|
Draw[1]> prompt appears in the command window
|
||||||
|
|
||||||
|
Type *pload ALL*
|
||||||
|
|
||||||
|
**On Windows:**
|
||||||
|
|
||||||
|
Launch Draw executable from Open CASCADE Technology\\Test Harness\\Draw Test Harness
|
||||||
|
item of the Start\\Programs menu or Use <i>$CASROOT\\draw.bat</i> file to launch *DRAWEXE* executable.
|
||||||
|
|
||||||
|
Draw[1]> prompt appears in the command window
|
||||||
|
|
||||||
|
Type pload ALL
|
||||||
|
|
||||||
|
**Creating your first geometric objects**
|
||||||
|
|
||||||
|
1. In the command window, type *axo* to create an axonometric view
|
||||||
|
2. Type *box b -10 -10 -10 20 20 20* to create a cube *b* of size 20, parallel to the X Y Z axis and centered on the origin. The cube will be displayed in the axonometric view in wireframe mode.
|
||||||
|
3. Type *fit* to fill the viewer with the cube
|
||||||
|
4. Type *pcylinder c 2 30* to create a cylinder *c* of radius 2 and height 30. The cylinder will be displayed in addition to the cube
|
||||||
|
|
||||||
|
**Manipulating the view**
|
||||||
|
|
||||||
|
1. Type *clear* to erase the view
|
||||||
|
2. Type *donly c* to display the cylinder only
|
||||||
|
3. Type *donly b* to display the cube only
|
||||||
|
4. Type *hlr hlr b* to display the cube in the hidden line removal mode
|
||||||
|
|
||||||
|
**Running demonstration files**
|
||||||
|
|
||||||
|
1. Type *cd ../..* to return to the root directory
|
||||||
|
2. Type *cd samples/tcl* to reach the *DrawResources* directory
|
||||||
|
3. Type *source \<demo_file\>* to run the demonstration file provided with Open CASCADE. The following demonstration files are available:
|
||||||
|
* DataExchangeDemo.tcl: demonstrates sample sequence of operations with writing and reading IGES file
|
||||||
|
* ModelingDemo.tcl: demonstrates creation of simple shape and displaying it in HLR mode
|
||||||
|
* VisualizationDemo.tcl: demonstrates use of 3d viewer
|
||||||
|
* cad.tcl: creates solid shape looking like abbreviation "CAD"
|
||||||
|
* bottle.tcl: creates bottle as in OCCT Tutorial
|
||||||
|
* drill.tcl: creates twist drill bit shape
|
||||||
|
* cutter.tcl: creates milling cutter shape
|
||||||
|
* xde.tcl: demonstrates creation of simple assembly in XDE
|
||||||
|
* materials.tcl: demonstrates visual properties of materials supported by 3d viewer
|
||||||
|
* raytrace.tcl: demonstrates use of ray tracing display in 3d viewer
|
||||||
|
* dimensions.tcl: demonstrates use of dimensions, clipping, and capping in 3d viewer
|
||||||
|
|
||||||
|
**Getting Help**
|
||||||
|
|
||||||
|
1. Type *help* to see all available commands
|
||||||
|
2. Type *help \<command_name\>* to find out the arguments for a given command
|
||||||
BIN
dox/samples/images/overview_overview_qt.png
Normal file
BIN
dox/samples/images/overview_overview_qt.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 162 KiB |
BIN
dox/samples/images/sample_ios_uikit.png
Normal file
BIN
dox/samples/images/sample_ios_uikit.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 48 KiB |
BIN
dox/samples/images/sample_webgl.png
Normal file
BIN
dox/samples/images/sample_webgl.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 74 KiB |
BIN
dox/samples/images/samples_c__ie.png
Normal file
BIN
dox/samples/images/samples_c__ie.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 37 KiB |
BIN
dox/samples/images/samples_draw.png
Normal file
BIN
dox/samples/images/samples_draw.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
BIN
dox/samples/images/samples_java_android_occt.jpg
Normal file
BIN
dox/samples/images/samples_java_android_occt.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 13 KiB |
BIN
dox/samples/images/samples_mvc.png
Normal file
BIN
dox/samples/images/samples_mvc.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 31 KiB |
BIN
dox/samples/images/samples_qml_android_occt.jpg
Normal file
BIN
dox/samples/images/samples_qml_android_occt.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
BIN
dox/samples/images/samples_qt.png
Normal file
BIN
dox/samples/images/samples_qt.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 63 KiB |
594
dox/samples/ocaf.md
Normal file
594
dox/samples/ocaf.md
Normal file
@ -0,0 +1,594 @@
|
|||||||
|
OCAF Usage {#samples__ocaf}
|
||||||
|
========
|
||||||
|
|
||||||
|
## Getting Started
|
||||||
|
|
||||||
|
At the beginning of your development, you first define an application class by inheriting from the Application abstract class.
|
||||||
|
You only have to create and determine the resources of the application
|
||||||
|
for specifying the format of your documents (you generally use the standard one) and their file extension.
|
||||||
|
|
||||||
|
Then, you design the application data model by organizing attributes you choose among those provided with OCAF.
|
||||||
|
You can specialize these attributes using the User attribute. For example, if you need a reflection coefficient,
|
||||||
|
you aggregate a User attribute identified as a reflection coefficient
|
||||||
|
with a Real attribute containing the value of the coefficient (as such, you don't define a new class).
|
||||||
|
|
||||||
|
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 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:
|
||||||
|
|
||||||
|
* Persistent reference to any data, including geometric elements â€" several documents can be linked with such reference;
|
||||||
|
* Document-View association;
|
||||||
|
* Ready-to-use functions such as :
|
||||||
|
* Undo-redo;
|
||||||
|
* Save and open application data.
|
||||||
|
|
||||||
|
Finally, you develop the application's graphical user interface using the toolkit of your choice, for example:
|
||||||
|
* KDE Qt or GNOME GTK+ on Linux;
|
||||||
|
* Microsoft Foundation Classes (MFC) on Windows Motif on Sun;
|
||||||
|
* Other commercial products such as Ilog Views.
|
||||||
|
|
||||||
|
You can also implement the user interface in the Java language using
|
||||||
|
the Swing-based Java Application Desktop component (JAD) provided with OCAF.
|
||||||
|
|
||||||
|
## An example of OCAF usage
|
||||||
|
|
||||||
|
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
|
||||||
|
~~~~
|
||||||
|
|
||||||
|
### 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
|
||||||
|
~~~~
|
||||||
|
|
||||||
|
## Implementation of Attribute Transformation in a HXX file
|
||||||
|
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||||
|
\#include <TDF_Attribute.hxx>
|
||||||
|
|
||||||
|
\#include <gp_Ax3.hxx>
|
||||||
|
\#include <gp_Pnt.hxx>
|
||||||
|
\#include <gp_Vec.hxx>
|
||||||
|
\#include <gp_Trsf.hxx>
|
||||||
|
|
||||||
|
//! This attribute implements a transformation data container
|
||||||
|
class MyPackage_Transformation : public TDF_Attribute
|
||||||
|
{
|
||||||
|
public:
|
||||||
|
//!@ name Static methods
|
||||||
|
|
||||||
|
//! The method returns a unique GUID of this attribute.
|
||||||
|
//! By means of this GUID this attribute may be identified
|
||||||
|
//! among other attributes attached to the same label.
|
||||||
|
Standard_EXPORT static const Standard_GUID& GetID ();
|
||||||
|
|
||||||
|
//! Finds or creates the attribute attached to <theLabel>.
|
||||||
|
//! The found or created attribute is returned.
|
||||||
|
Standard_EXPORT static Handle(MyPackage_Transformation) Set (const TDF_Label theLabel);
|
||||||
|
|
||||||
|
//!@ name Methods for access to the attribute data
|
||||||
|
|
||||||
|
//! The method returns the transformation.
|
||||||
|
Standard_EXPORT gp_Trsf Get () const;
|
||||||
|
|
||||||
|
//!@ name Methods for setting the data of transformation
|
||||||
|
|
||||||
|
//! The method defines a rotation type of transformation.
|
||||||
|
Standard_EXPORT void SetRotation (const gp_Ax1& theAxis, Standard_Real theAngle);
|
||||||
|
|
||||||
|
//! The method defines a translation type of transformation.
|
||||||
|
Standard_EXPORT void SetTranslation (const gp_Vec& theVector);
|
||||||
|
|
||||||
|
//! The method defines a point mirror type of transformation (point symmetry).
|
||||||
|
Standard_EXPORT void SetMirror (const gp_Pnt& thePoint);
|
||||||
|
|
||||||
|
//! The method defines an axis mirror type of transformation (axial symmetry).
|
||||||
|
Standard_EXPORT void SetMirror (const gp_Ax1& theAxis);
|
||||||
|
|
||||||
|
//! The method defines a point mirror type of transformation (planar symmetry).
|
||||||
|
Standard_EXPORT void SetMirror (const gp_Ax2& thePlane);
|
||||||
|
|
||||||
|
//! The method defines a scale type of transformation.
|
||||||
|
Standard_EXPORT void SetScale (const gp_Pnt& thePoint, Standard_Real theScale);
|
||||||
|
|
||||||
|
//! The method defines a complex type of transformation from one co-ordinate system to another.
|
||||||
|
Standard_EXPORT void SetTransformation (const gp_Ax3& theCoordinateSystem1, const gp_Ax3& theCoordinateSystem2);
|
||||||
|
|
||||||
|
//!@ name Overridden methods from TDF_Attribute
|
||||||
|
|
||||||
|
//! The method returns a unique GUID of the attribute.
|
||||||
|
//! By means of this GUID this attribute may be identified among other attributes attached to the same label.
|
||||||
|
Standard_EXPORT const Standard_GUID& ID () const;
|
||||||
|
|
||||||
|
//! The method is called on Undo / Redo.
|
||||||
|
//! It copies the content of theAttribute into this attribute (copies the fields).
|
||||||
|
Standard_EXPORT void Restore (const Handle(TDF_Attribute)& theAttribute);
|
||||||
|
|
||||||
|
//! It creates a new instance of this attribute.
|
||||||
|
//! It is called on Copy / Paste, Undo / Redo.
|
||||||
|
Standard_EXPORT Handle(TDF_Attribute) NewEmpty () const;
|
||||||
|
|
||||||
|
//! The method is called on Copy / Paste.
|
||||||
|
//! It copies the content of this attribute into theAttribute (copies the fields).
|
||||||
|
Standard_EXPORT void Paste (const Handle(TDF_Attribute)& theAttribute, const Handle(TDF_RelocationTable)& theRelocationTable);
|
||||||
|
|
||||||
|
//! Prints the content of this attribute into the stream.
|
||||||
|
Standard_EXPORT Standard_OStream& Dump(Standard_OStream& theOS);
|
||||||
|
|
||||||
|
//!@ name Constructor
|
||||||
|
|
||||||
|
//! The C++ constructor of this atribute class.
|
||||||
|
//! Usually it is never called outside this class.
|
||||||
|
Standard_EXPORT MyPackage_Transformation();
|
||||||
|
|
||||||
|
private:
|
||||||
|
gp_TrsfForm myType;
|
||||||
|
|
||||||
|
// Axes (Ax1, Ax2, Ax3)
|
||||||
|
gp_Ax1 myAx1;
|
||||||
|
gp_Ax2 myAx2;
|
||||||
|
gp_Ax3 myFirstAx3;
|
||||||
|
gp_Ax3 mySecondAx3;
|
||||||
|
|
||||||
|
// Scalar values
|
||||||
|
Standard_Real myAngle;
|
||||||
|
Standard_Real myScale;
|
||||||
|
|
||||||
|
// Points
|
||||||
|
gp_Pnt myFirstPoint;
|
||||||
|
gp_Pnt mySecondPoint;
|
||||||
|
};
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
## Implementation of Attribute Transformation in a CPP file
|
||||||
|
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||||
|
\#include <MyPackage_Transformation.hxx>
|
||||||
|
|
||||||
|
//=======================================================================
|
||||||
|
//function : GetID
|
||||||
|
//purpose : The method returns a unique GUID of this attribute.
|
||||||
|
// By means of this GUID this attribute may be identified
|
||||||
|
// among other attributes attached to the same label.
|
||||||
|
//=======================================================================
|
||||||
|
const Standard_GUID& MyPackage_Transformation::GetID()
|
||||||
|
{
|
||||||
|
static Standard_GUID ID("4443368E-C808-4468-984D-B26906BA8573");
|
||||||
|
return ID;
|
||||||
|
}
|
||||||
|
|
||||||
|
//=======================================================================
|
||||||
|
//function : Set
|
||||||
|
//purpose : Finds or creates the attribute attached to <theLabel>.
|
||||||
|
// The found or created attribute is returned.
|
||||||
|
//=======================================================================
|
||||||
|
Handle(MyPackage_Transformation) MyPackage_Transformation::Set(const TDF_Label& theLabel)
|
||||||
|
{
|
||||||
|
Handle(MyPackage_Transformation) T;
|
||||||
|
if (!theLabel.FindAttribute(MyPackage_Transformation::GetID(), T))
|
||||||
|
{
|
||||||
|
T = new MyPackage_Transformation();
|
||||||
|
theLabel.AddAttribute(T);
|
||||||
|
}
|
||||||
|
return T;
|
||||||
|
}
|
||||||
|
|
||||||
|
//=======================================================================
|
||||||
|
//function : Get
|
||||||
|
//purpose : The method returns the transformation.
|
||||||
|
//=======================================================================
|
||||||
|
gp_Trsf MyPackage_Transformation::Get() const
|
||||||
|
{
|
||||||
|
gp_Trsf transformation;
|
||||||
|
switch (myType)
|
||||||
|
{
|
||||||
|
case gp_Identity:
|
||||||
|
{
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
case gp_Rotation:
|
||||||
|
{
|
||||||
|
transformation.SetRotation(myAx1, myAngle);
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
case gp_Translation:
|
||||||
|
{
|
||||||
|
transformation.SetTranslation(myFirstPoint, mySecondPoint);
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
case gp_PntMirror:
|
||||||
|
{
|
||||||
|
transformation.SetMirror(myFirstPoint);
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
case gp_Ax1Mirror:
|
||||||
|
{
|
||||||
|
transformation.SetMirror(myAx1);
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
case gp_Ax2Mirror:
|
||||||
|
{
|
||||||
|
transformation.SetMirror(myAx2);
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
case gp_Scale:
|
||||||
|
{
|
||||||
|
transformation.SetScale(myFirstPoint, myScale);
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
case gp_CompoundTrsf:
|
||||||
|
{
|
||||||
|
transformation.SetTransformation(myFirstAx3, mySecondAx3);
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
case gp_Other:
|
||||||
|
{
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
return transformation;
|
||||||
|
}
|
||||||
|
|
||||||
|
//=======================================================================
|
||||||
|
//function : SetRotation
|
||||||
|
//purpose : The method defines a rotation type of transformation.
|
||||||
|
//=======================================================================
|
||||||
|
void MyPackage_Transformation::SetRotation(const gp_Ax1& theAxis, const Standard_Real theAngle)
|
||||||
|
{
|
||||||
|
Backup();
|
||||||
|
myType = gp_Rotation;
|
||||||
|
myAx1 = theAxis;
|
||||||
|
myAngle = theAngle;
|
||||||
|
}
|
||||||
|
|
||||||
|
//=======================================================================
|
||||||
|
//function : SetTranslation
|
||||||
|
//purpose : The method defines a translation type of transformation.
|
||||||
|
//=======================================================================
|
||||||
|
void MyPackage_Transformation::SetTranslation(const gp_Vec& theVector)
|
||||||
|
{
|
||||||
|
Backup();
|
||||||
|
myType = gp_Translation;
|
||||||
|
myFirstPoint.SetCoord(0, 0, 0);
|
||||||
|
mySecondPoint.SetCoord(theVector.X(), theVector.Y(), theVector.Z());
|
||||||
|
}
|
||||||
|
|
||||||
|
//=======================================================================
|
||||||
|
//function : SetMirror
|
||||||
|
//purpose : The method defines a point mirror type of transformation
|
||||||
|
// (point symmetry).
|
||||||
|
//=======================================================================
|
||||||
|
void MyPackage_Transformation::SetMirror(const gp_Pnt& thePoint)
|
||||||
|
{
|
||||||
|
Backup();
|
||||||
|
myType = gp_PntMirror;
|
||||||
|
myFirstPoint = thePoint;
|
||||||
|
}
|
||||||
|
|
||||||
|
//=======================================================================
|
||||||
|
//function : SetMirror
|
||||||
|
//purpose : The method defines an axis mirror type of transformation
|
||||||
|
// (axial symmetry).
|
||||||
|
//=======================================================================
|
||||||
|
void MyPackage_Transformation::SetMirror(const gp_Ax1& theAxis)
|
||||||
|
{
|
||||||
|
Backup();
|
||||||
|
myType = gp_Ax1Mirror;
|
||||||
|
myAx1 = theAxis;
|
||||||
|
}
|
||||||
|
|
||||||
|
//=======================================================================
|
||||||
|
//function : SetMirror
|
||||||
|
//purpose : The method defines a point mirror type of transformation
|
||||||
|
// (planar symmetry).
|
||||||
|
//=======================================================================
|
||||||
|
void MyPackage_Transformation::SetMirror(const gp_Ax2& thePlane)
|
||||||
|
{
|
||||||
|
Backup();
|
||||||
|
myType = gp_Ax2Mirror;
|
||||||
|
myAx2 = thePlane;
|
||||||
|
}
|
||||||
|
|
||||||
|
//=======================================================================
|
||||||
|
//function : SetScale
|
||||||
|
//purpose : The method defines a scale type of transformation.
|
||||||
|
//=======================================================================
|
||||||
|
void MyPackage_Transformation::SetScale(const gp_Pnt& thePoint, const Standard_Real theScale)
|
||||||
|
{
|
||||||
|
Backup();
|
||||||
|
myType = gp_Scale;
|
||||||
|
myFirstPoint = thePoint;
|
||||||
|
myScale = theScale;
|
||||||
|
}
|
||||||
|
|
||||||
|
//=======================================================================
|
||||||
|
//function : SetTransformation
|
||||||
|
//purpose : The method defines a complex type of transformation
|
||||||
|
// from one co-ordinate system to another.
|
||||||
|
//=======================================================================
|
||||||
|
void MyPackage_Transformation::SetTransformation(const gp_Ax3& theCoordinateSystem1,
|
||||||
|
const gp_Ax3& theCoordinateSystem2)
|
||||||
|
{
|
||||||
|
Backup();
|
||||||
|
myFirstAx3 = theCoordinateSystem1;
|
||||||
|
mySecondAx3 = theCoordinateSystem2;
|
||||||
|
}
|
||||||
|
|
||||||
|
//=======================================================================
|
||||||
|
//function : ID
|
||||||
|
//purpose : The method returns a unique GUID of the attribute.
|
||||||
|
// By means of this GUID this attribute may be identified
|
||||||
|
// among other attributes attached to the same label.
|
||||||
|
//=======================================================================
|
||||||
|
const Standard_GUID& MyPackage_Transformation::ID() const
|
||||||
|
{
|
||||||
|
return GetID();
|
||||||
|
}
|
||||||
|
|
||||||
|
//=======================================================================
|
||||||
|
//function : Restore
|
||||||
|
//purpose : The method is called on Undo / Redo.
|
||||||
|
// It copies the content of <theAttribute>
|
||||||
|
// into this attribute (copies the fields).
|
||||||
|
//=======================================================================
|
||||||
|
void MyPackage_Transformation::Restore(const Handle(TDF_Attribute)& theAttribute)
|
||||||
|
{
|
||||||
|
Handle(MyPackage_Transformation) theTransformation = Handle(MyPackage_Transformation)::DownCast(theAttribute);
|
||||||
|
myType = theTransformation->myType;
|
||||||
|
myAx1 = theTransformation->myAx1;
|
||||||
|
myAx2 = theTransformation->myAx2;
|
||||||
|
myFirstAx3 = theTransformation->myFirstAx3;
|
||||||
|
mySecondAx3 = theTransformation->mySecondAx3;
|
||||||
|
myAngle = theTransformation->myAngle;
|
||||||
|
myScale = theTransformation->myScale;
|
||||||
|
myFirstPoint = theTransformation->myFirstPoint;
|
||||||
|
mySecondPoint = theTransformation->mySecondPoint;
|
||||||
|
}
|
||||||
|
|
||||||
|
//=======================================================================
|
||||||
|
//function : NewEmpty
|
||||||
|
//purpose : It creates a new instance of this attribute.
|
||||||
|
// It is called on Copy / Paste, Undo / Redo.
|
||||||
|
//=======================================================================
|
||||||
|
Handle(TDF_Attribute) MyPackage_Transformation::NewEmpty() const
|
||||||
|
{
|
||||||
|
return new MyPackage_Transformation();
|
||||||
|
}
|
||||||
|
|
||||||
|
//=======================================================================
|
||||||
|
//function : Paste
|
||||||
|
//purpose : The method is called on Copy / Paste.
|
||||||
|
// It copies the content of this attribute into
|
||||||
|
// <theAttribute> (copies the fields).
|
||||||
|
//=======================================================================
|
||||||
|
void MyPackage_Transformation::Paste(const Handle(TDF_Attribute)& theAttribute,
|
||||||
|
const Handle(TDF_RelocationTable)& ) const
|
||||||
|
{
|
||||||
|
Handle(MyPackage_Transformation) theTransformation = Handle(MyPackage_Transformation)::DownCast(theAttribute);
|
||||||
|
theTransformation->myType = myType;
|
||||||
|
theTransformation->myAx1 = myAx1;
|
||||||
|
theTransformation->myAx2 = myAx2;
|
||||||
|
theTransformation->myFirstAx3 = myFirstAx3;
|
||||||
|
theTransformation->mySecondAx3 = mySecondAx3;
|
||||||
|
theTransformation->myAngle = myAngle;
|
||||||
|
theTransformation->myScale = myScale;
|
||||||
|
theTransformation->myFirstPoint = myFirstPoint;
|
||||||
|
theTransformation->mySecondPoint = mySecondPoint;
|
||||||
|
}
|
||||||
|
|
||||||
|
//=======================================================================
|
||||||
|
//function : Dump
|
||||||
|
//purpose : Prints the content of this attribute into the stream.
|
||||||
|
//=======================================================================
|
||||||
|
Standard_OStream& MyPackage_Transformation::Dump(Standard_OStream& anOS) const
|
||||||
|
{
|
||||||
|
anOS = "Transformation: ";
|
||||||
|
switch (myType)
|
||||||
|
{
|
||||||
|
case gp_Identity:
|
||||||
|
{
|
||||||
|
anOS = "gp_Identity";
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
case gp_Rotation:
|
||||||
|
{
|
||||||
|
anOS = "gp_Rotation";
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
case gp_Translation:
|
||||||
|
{
|
||||||
|
anOS = "gp_Translation";
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
case gp_PntMirror:
|
||||||
|
{
|
||||||
|
anOS = "gp_PntMirror";
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
case gp_Ax1Mirror:
|
||||||
|
{
|
||||||
|
anOS = "gp_Ax1Mirror";
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
case gp_Ax2Mirror:
|
||||||
|
{
|
||||||
|
anOS = "gp_Ax2Mirror";
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
case gp_Scale:
|
||||||
|
{
|
||||||
|
anOS = "gp_Scale";
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
case gp_CompoundTrsf:
|
||||||
|
{
|
||||||
|
anOS = "gp_CompoundTrsf";
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
case gp_Other:
|
||||||
|
{
|
||||||
|
anOS = "gp_Other";
|
||||||
|
break;
|
||||||
|
}
|
||||||
|
}
|
||||||
|
return anOS;
|
||||||
|
}
|
||||||
|
|
||||||
|
//=======================================================================
|
||||||
|
//function : MyPackage_Transformation
|
||||||
|
//purpose : A constructor.
|
||||||
|
//=======================================================================
|
||||||
|
MyPackage_Transformation::MyPackage_Transformation():myType(gp_Identity){
|
||||||
|
|
||||||
|
}
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
## Implementation of typical actions with standard OCAF attributes.
|
||||||
|
|
||||||
|
There are four sample files provided in the directory 'OpenCasCade/ros/samples/ocafsamples'. They present typical actions with OCAF services (mainly for newcomers).
|
||||||
|
The method *Sample()* of each file is not dedicated for execution 'as is', it is rather a set of logical actions using some OCAF services.
|
||||||
|
|
||||||
|
### TDataStd_Sample.cxx
|
||||||
|
This sample contains templates for typical actions with the following standard OCAF attributes:
|
||||||
|
- Starting with data framework;
|
||||||
|
- TDataStd_Integer attribute management;
|
||||||
|
- TDataStd_RealArray attribute management;
|
||||||
|
- TDataStd_Comment attribute management;
|
||||||
|
- TDataStd_Name attribute management;
|
||||||
|
- TDataStd_UAttribute attribute management;
|
||||||
|
- TDF_Reference attribute management;
|
||||||
|
- TDataXtd_Point attribute management;
|
||||||
|
- TDataXtd_Plane attribute management;
|
||||||
|
- TDataXtd_Axis attribute management;
|
||||||
|
- TDataXtd_Geometry attribute management;
|
||||||
|
- TDataXtd_Constraint attribute management;
|
||||||
|
- TDataStd_Directory attribute management;
|
||||||
|
- TDataStd_TreeNode attribute management.
|
||||||
|
|
||||||
|
### TDocStd_Sample.cxx
|
||||||
|
This sample contains template for the following typical actions:
|
||||||
|
- creating application;
|
||||||
|
- creating the new document (document contains a framework);
|
||||||
|
- retrieving the document from a label of its framework;
|
||||||
|
- filling a document with data;
|
||||||
|
- saving a document in the file;
|
||||||
|
- closing a document;
|
||||||
|
- opening the document stored in the file;
|
||||||
|
- copying content of a document to another document with possibility to update the copy in the future.
|
||||||
|
|
||||||
|
### TPrsStd_Sample.cxx
|
||||||
|
This sample contains template for the following typical actions:
|
||||||
|
- starting with data framework;
|
||||||
|
- setting the TPrsStd_AISViewer in the framework;
|
||||||
|
- initialization of aViewer;
|
||||||
|
- finding TPrsStd_AISViewer attribute in the DataFramework;
|
||||||
|
- getting AIS_InteractiveContext from TPrsStd_AISViewer;
|
||||||
|
- adding driver to the map of drivers;
|
||||||
|
- getting driver from the map of drivers;
|
||||||
|
- setting TNaming_NamedShape to \<ShapeLabel\>;
|
||||||
|
- setting the new TPrsStd_AISPresentation to \<ShapeLabel\>;
|
||||||
|
- displaying;
|
||||||
|
- erasing;
|
||||||
|
- updating and displaying presentation of the attribute to be displayed;
|
||||||
|
- setting a color to the displayed attribute;
|
||||||
|
- getting transparency of the displayed attribute;
|
||||||
|
- modify attribute;
|
||||||
|
- updating presentation of the attribute in viewer.
|
||||||
|
|
||||||
|
### TNaming_Sample.cxx
|
||||||
|
This sample contains template for typical actions with OCAF Topological Naming services.
|
||||||
|
The following scenario is used:
|
||||||
|
- data framework initialization;
|
||||||
|
- creating Box1 and pushing it as PRIMITIVE in DF;
|
||||||
|
- creating Box2 and pushing it as PRIMITIVE in DF;
|
||||||
|
- moving Box2 (applying a transformation);
|
||||||
|
- pushing the selected edges of the top face of Box1 in DF;
|
||||||
|
- creating a Fillet (using the selected edges) and pushing the result as a modification of Box1;
|
||||||
|
- creating a Cut (Box1, Box2) as a modification of Box1 and push it in DF;
|
||||||
|
- recovering the result from DF.
|
||||||
|
|
||||||
286
dox/samples/ocaf_func.md
Normal file
286
dox/samples/ocaf_func.md
Normal file
@ -0,0 +1,286 @@
|
|||||||
|
Function Mechanism Usage {#samples__ocaf_func}
|
||||||
|
========================
|
||||||
|
|
||||||
|
Let us describe the usage of the "Function Mechanism" of Open CASCADE Application Framework on a simple example.
|
||||||
|
This example represents a "nail" composed by a cone and two cylinders of different radius and height:
|
||||||
|
|
||||||
|
@image html ocaf_functionmechanism_wp_image003.png "A nail"
|
||||||
|
@image latex ocaf_functionmechanism_wp_image003.png " A nail"
|
||||||
|
|
||||||
|
These three objects (a cone and two cylinders) are independent,
|
||||||
|
but the Function Mechanism makes them connected to each other and representing one object -- a nail.
|
||||||
|
The object "nail" has the following parameters:
|
||||||
|
|
||||||
|
* The position of the nail is defined by the apex point of the cone.
|
||||||
|
The cylinders are built on the cone and therefore they depend on the position of the cone.
|
||||||
|
In this way we define a dependency of the cylinders on the cone.
|
||||||
|
* The height of the nail is defined by the height of the cone.
|
||||||
|
Let’s consider that the long cylinder has 3 heights of the cone
|
||||||
|
and the header cylinder has a half of the height of the cone.
|
||||||
|
* The radius of the nail is defined by the radius of the cone.
|
||||||
|
The radius of the long cylinder coincides with this value.
|
||||||
|
Let’s consider that the header cylinder has one and a half radiuses of the cone.
|
||||||
|
|
||||||
|
So, the cylinders depend on the cone and the cone parameters define the size of the nail.
|
||||||
|
|
||||||
|
It means that re-positioning the cone (changing its apex point) moves the nail,
|
||||||
|
the change of the radius of the cone produces a thinner or thicker nail,
|
||||||
|
and the change of the height of the cone shortens or prolongates the nail.
|
||||||
|
It is suggested to examine the programming steps needed to create a 3D parametric model of the "nail".
|
||||||
|
|
||||||
|
## Step1: Data Tree
|
||||||
|
|
||||||
|
The first step consists in model data allocation in the OCAF tree.
|
||||||
|
In other words, it is necessary to decide where to put the data.
|
||||||
|
|
||||||
|
In this case, the data can be organized into a simple tree
|
||||||
|
using references for definition of dependent parameters:
|
||||||
|
|
||||||
|
* Nail
|
||||||
|
* Cone
|
||||||
|
+ Position (x,y,z)
|
||||||
|
+ Radius
|
||||||
|
+ Height
|
||||||
|
* Cylinder (stem)
|
||||||
|
+ Position = "Cone" position translated for "Cone" height along Z;
|
||||||
|
+ Radius = "Cone" radius;
|
||||||
|
+ Height = "Cone" height multiplied by 3;
|
||||||
|
* Cylinder (head)
|
||||||
|
+ Position = "Long cylinder" position translated for "Long cylinder" height along Z;
|
||||||
|
+ Radius = "Long cylinder" radius multiplied by 1.5;
|
||||||
|
+ Height = "Cone" height divided by 2.
|
||||||
|
|
||||||
|
The "nail" object has three sub-leaves in the tree: the cone and two cylinders.
|
||||||
|
|
||||||
|
The cone object is independent.
|
||||||
|
|
||||||
|
The long cylinder representing a "stem" of the nail refers to the corresponding parameters
|
||||||
|
of the cone to define its own data (position, radius and height). It means that the long cylinder depends on the cone.
|
||||||
|
|
||||||
|
The parameters of the head cylinder may be expressed through the cone parameters
|
||||||
|
only or through the cone and the long cylinder parameters.
|
||||||
|
It is suggested to express the position and the radius of the head cylinder
|
||||||
|
through the position and the radius of the long cylinder, and the height
|
||||||
|
of the head cylinder through the height of the cone.
|
||||||
|
It means that the head cylinder depends on the cone and the long cylinder.
|
||||||
|
|
||||||
|
## Step 2: Interfaces
|
||||||
|
|
||||||
|
The interfaces of the data model are responsible for dynamic creation
|
||||||
|
of the data tree of the represented at the previous step, data modification and deletion.
|
||||||
|
|
||||||
|
The interface called *INail* should contain the methods for creation
|
||||||
|
of the data tree for the nail, setting and getting of its parameters, computation, visualization and removal.
|
||||||
|
|
||||||
|
### Creation of the nail
|
||||||
|
|
||||||
|
This method of the interface creates a data tree for the nail at a given leaf of OCAF data tree.
|
||||||
|
|
||||||
|
It creates three sub-leaves for the cone and two cylinders and allocates the necessary data (references at the
|
||||||
|
sub-leaves of the long and the head cylinders).
|
||||||
|
|
||||||
|
It sets the default values of position, radius and height of the nail.
|
||||||
|
|
||||||
|
The nail has the following user parameters:
|
||||||
|
* The position -- coincides with the position of the cone
|
||||||
|
* The radius of the stem part of the nail -- coincides with the radius of the cone
|
||||||
|
* The height of the nail -- a sum of heights of the cone and both cylinders
|
||||||
|
|
||||||
|
The values of the position and the radius of the nail are defined for the cone object data.
|
||||||
|
The height of the cone is recomputed as 2 * heights of nail and divided by 9.
|
||||||
|
|
||||||
|
### Computation
|
||||||
|
|
||||||
|
The Function Mechanism is responsible for re-computation of the nail.
|
||||||
|
It will be described in detail later in this document.
|
||||||
|
|
||||||
|
A data leaf consists of the reference to the location of the real data
|
||||||
|
and a real value defining a coefficient of multiplication of the referenced data.
|
||||||
|
|
||||||
|
For example, the height of the long cylinder is defined as a reference to the height of the cone
|
||||||
|
with coefficient 3. The data leaf of the height of the long cylinder
|
||||||
|
should contain two attributes: a reference to the height of cone and a real value equal to 3.
|
||||||
|
|
||||||
|
### Visualization
|
||||||
|
|
||||||
|
The shape resulting of the nail function can be displayed using the standard OCAF visualization mechanism.
|
||||||
|
|
||||||
|
### Removal of the nail
|
||||||
|
|
||||||
|
To automatically erase the nail from the viewer and the data tree it is enough to clean the nail leaf from attributes.
|
||||||
|
|
||||||
|
## Step 3: Functions
|
||||||
|
|
||||||
|
The nail is defined by four functions: the cone, the two cylinders and the nail function.
|
||||||
|
The function of the cone is independent. The functions of the cylinders depend on the cone function.
|
||||||
|
The nail function depends on the results of all functions:
|
||||||
|
|
||||||
|
@image html ocaf_functionmechanism_wp_image005.png "A graph of dependencies between functions"
|
||||||
|
@image latex ocaf_functionmechanism_wp_image005.png "A graph of dependencies between functions"
|
||||||
|
|
||||||
|
Computation of the model starts with the cone function, then the long cylinder,
|
||||||
|
after that the header cylinder and, finally, the result is generated by the nail function at the end of function chain.
|
||||||
|
|
||||||
|
The Function Mechanism of Open CASCADE Technology creates this graph of dependencies
|
||||||
|
and allows iterating it following the dependencies.
|
||||||
|
The only thing the Function Mechanism requires from its user
|
||||||
|
is the implementation of pure virtual methods of *TFunction_Driver*:
|
||||||
|
|
||||||
|
* <i>\::Arguments()</i> -- returns a list of arguments for the function
|
||||||
|
* <i>\::Results()</i> -- returns a list of results of the function
|
||||||
|
|
||||||
|
These methods give the Function Mechanism the information on the location of arguments
|
||||||
|
and results of the function and allow building a graph of functions.
|
||||||
|
The class *TFunction_Iterator* iterates the functions of the graph in the execution order.
|
||||||
|
|
||||||
|
The pure virtual method *TFunction_Driver::Execute()* calculating the function should be overridden.
|
||||||
|
|
||||||
|
The method <i>\::MustExecute()</i> calls the method <i>\::Arguments()</i> of the function driver
|
||||||
|
and ideally this information (knowledge of modification of arguments of the function) is enough
|
||||||
|
to make a decision whether the function should be executed or not. Therefore, this method usually shouldn’t be overridden.
|
||||||
|
|
||||||
|
The cone and cylinder functions differ only in geometrical construction algorithms.
|
||||||
|
Other parameters are the same (position, radius and height).
|
||||||
|
|
||||||
|
It means that it is possible to create a base class -- function driver for the three functions,
|
||||||
|
and two descendant classes producing: a cone or a cylinder.
|
||||||
|
|
||||||
|
For the base function driver the methods <i>\::Arguments()</i> and <i>\::Results()</i> will be overridden.
|
||||||
|
Two descendant function drivers responsible for creation of a cone and a cylinder will override only the method
|
||||||
|
<i>\::Execute()</i>.
|
||||||
|
|
||||||
|
The method <i>\::Arguments()</i> of the function driver of the nail returns the results of the functions located under
|
||||||
|
it in the tree of leaves. The method <i>\::Execute()</i> just collects the results of the functions and makes one
|
||||||
|
shape -- a nail.
|
||||||
|
|
||||||
|
This way the data model using the Function Mechanism is ready for usage. Do not forget to introduce the function
|
||||||
|
drivers for a function driver table with the help of *TFunction_DriverTable* class.
|
||||||
|
|
||||||
|
### Example 1: iteration and execution of functions.
|
||||||
|
|
||||||
|
This is an example of the code for iteration and execution of functions.
|
||||||
|
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||||
|
|
||||||
|
// The scope of functions is defined.
|
||||||
|
Handle(TFunction_Scope) scope = TFunction_Scope::Set( anyLabel );
|
||||||
|
|
||||||
|
// The information on modifications in the model is received.
|
||||||
|
TFunction_Logbook& log = scope-GetLogbook();
|
||||||
|
|
||||||
|
// The iterator is iInitialized by the scope of functions.
|
||||||
|
TFunction_Iterator iterator( anyLabel );
|
||||||
|
Iterator.SetUsageOfExecutionOrder( true );
|
||||||
|
|
||||||
|
// The function is iterated, its dependency is checked on the modified data and executed if necessary.
|
||||||
|
for (; iterator.more(); iterator.Next())
|
||||||
|
{
|
||||||
|
// The function iterator may return a list of current functions for execution.
|
||||||
|
// It might be useful for multi-threaded execution of functions.
|
||||||
|
const TDF_LabelList& currentFunctions = iterator.Current();
|
||||||
|
|
||||||
|
//The list of current functions is iterated.
|
||||||
|
TDF_ListIteratorOfLabelList currentterator( currentFucntions );
|
||||||
|
for (; currentIterator.More(); currentIterator.Next())
|
||||||
|
{
|
||||||
|
// An interface for the function is created.
|
||||||
|
TFunction_IFunction interface( currentIterator.Value() );
|
||||||
|
|
||||||
|
// The function driver is retrieved.
|
||||||
|
Handle(TFunction_Driver) driver = interface.GetDriver();
|
||||||
|
|
||||||
|
// The dependency of the function on the modified data is checked.
|
||||||
|
If (driver-MustExecute( log ))
|
||||||
|
{
|
||||||
|
// The function is executed.
|
||||||
|
int ret = driver-Execute( log );
|
||||||
|
if ( ret )
|
||||||
|
return false;
|
||||||
|
} // end if check on modification
|
||||||
|
} // end of iteration of current functions
|
||||||
|
} // end of iteration of functions.
|
||||||
|
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
### Example 2: Cylinder function driver
|
||||||
|
|
||||||
|
This is an example of the code for a cylinder function driver. To make the things clearer, the methods
|
||||||
|
<i>\::Arguments()</i> and <i>\::Results()</i> from the base class are also mentioned.
|
||||||
|
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
|
||||||
|
|
||||||
|
// A virtual method ::Arguments() returns a list of arguments of the function.
|
||||||
|
CylinderDriver::Arguments( TDF_LabelList& args )
|
||||||
|
{
|
||||||
|
// The direct arguments, located at sub-leaves of the fucntion, are collected (see picture 2).
|
||||||
|
TDF_ChildIterator cIterator( Label(), false );
|
||||||
|
for (; cIterator.More(); cIterator.Next() )
|
||||||
|
{
|
||||||
|
// Direct argument.
|
||||||
|
TDF_Label sublabel = cIterator.Value();
|
||||||
|
Args.Append( sublabel );
|
||||||
|
|
||||||
|
// The references to the external data are checked.
|
||||||
|
Handle(TDF_Reference) ref;
|
||||||
|
If ( sublabel.FindAttribute( TDF_Reference::GetID(), ref ) )
|
||||||
|
{
|
||||||
|
args.Append( ref-Get() );
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
// A virtual method ::Results() returns a list of result leaves.
|
||||||
|
CylinderDriver::Results( TDF_LabelList& res )
|
||||||
|
{
|
||||||
|
// The result is kept at the function label.
|
||||||
|
Res.Append( Label() );
|
||||||
|
}
|
||||||
|
|
||||||
|
// Execution of the function driver.
|
||||||
|
Int CylinderDriver::Execute( TFunction_Logbook& log )
|
||||||
|
{
|
||||||
|
// Position of the cylinder - position of the first function (cone)
|
||||||
|
//is elevated along Z for height values of all previous functions.
|
||||||
|
gp_Ax2 axes = …. // out of the scope of this guide.
|
||||||
|
// The radius value is retrieved.
|
||||||
|
// It is located at second child sub-leaf (see the picture 2).
|
||||||
|
TDF_Label radiusLabel = Label().FindChild( 2 );
|
||||||
|
|
||||||
|
// The multiplicator of the radius ()is retrieved.
|
||||||
|
Handle(TDataStd_Real) radiusValue;
|
||||||
|
radiusLabel.FindAttribute( TDataStd_Real::GetID(), radiusValue);
|
||||||
|
|
||||||
|
// The reference to the radius is retrieved.
|
||||||
|
Handle(TDF_Reference) refRadius;
|
||||||
|
RadiusLabel.FindAttribute( TDF_Reference::GetID(), refRadius );
|
||||||
|
|
||||||
|
// The radius value is calculated.
|
||||||
|
double radius = 0.0;
|
||||||
|
|
||||||
|
if ( refRadius.IsNull() )
|
||||||
|
{
|
||||||
|
radius = radiusValue-Get();
|
||||||
|
}
|
||||||
|
else
|
||||||
|
{
|
||||||
|
// The referenced radius value is retrieved.
|
||||||
|
Handle(TDataStd_Real) referencedRadiusValue;
|
||||||
|
RefRadius-Get().FindAttribute(TDataStd_Real::GetID() ,referencedRadiusValue );
|
||||||
|
radius = referencedRadiusValue-Get() * radiusValue-Get();
|
||||||
|
}
|
||||||
|
|
||||||
|
// The height value is retrieved.
|
||||||
|
double height = … // similar code to taking the radius value.
|
||||||
|
|
||||||
|
// The cylinder is created.
|
||||||
|
TopoDS_Shape cylinder = BRepPrimAPI_MakeCylinder(axes, radius, height);
|
||||||
|
|
||||||
|
// The result (cylinder) is set
|
||||||
|
TNaming_Builder builder( Label() );
|
||||||
|
Builder.Generated( cylinder );
|
||||||
|
|
||||||
|
// The modification of the result leaf is saved in the log.
|
||||||
|
log.SetImpacted( Label() );
|
||||||
|
|
||||||
|
return 0;
|
||||||
|
}
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
152
dox/samples/samples.md
Normal file
152
dox/samples/samples.md
Normal file
@ -0,0 +1,152 @@
|
|||||||
|
Tutorials and Samples {#samples}
|
||||||
|
=====================
|
||||||
|
|
||||||
|
Tutorial: Modelling a Bottle
|
||||||
|
----------------------------
|
||||||
|
The Qt programming tutorial teaches how to use Open CASCADE Technology services to model a 3D object.
|
||||||
|
The purpose of the tutorial is not to explain all OCCT classes but
|
||||||
|
to help start thinking in terms of the Open CASCADE Technology.
|
||||||
|
|
||||||
|
This tutorial assumes that the user has experience in using and setting up C++.
|
||||||
|
From the viewpoint of programming, Open CASCADE Technology is designed
|
||||||
|
to enhance user's C++ tools with high performance modeling classes, methods and functions.
|
||||||
|
The combination of these resources allows creating substantial applications.
|
||||||
|
|
||||||
|
Read more about @subpage occt__tutorial
|
||||||
|
|
||||||
|
MFC
|
||||||
|
---------
|
||||||
|
|
||||||
|
Visual C++ programming samples containing 10 Visual C++ projects
|
||||||
|
illustrating how to use a particular module or functionality.
|
||||||
|
|
||||||
|
The list of MFC samples:
|
||||||
|
|
||||||
|
* Geometry
|
||||||
|
* Modeling
|
||||||
|
* Viewer2d
|
||||||
|
* Viewer3d
|
||||||
|
* ImportExport
|
||||||
|
* Ocaf
|
||||||
|
* Triangulation
|
||||||
|
* HLR
|
||||||
|
* Animation
|
||||||
|
* Convert
|
||||||
|
|
||||||
|
@figure{/samples/images/samples_mvc.png}
|
||||||
|
|
||||||
|
**Remarks:**
|
||||||
|
|
||||||
|
* MFC samples are available only on Windows platform;
|
||||||
|
* To start a sample use Open CASCADE Technology\\Samples\\Mfc\\ item of the Start\\Programs menu;
|
||||||
|
* Read carefully readme.txt to learn about launching and compilation options.
|
||||||
|
|
||||||
|
See @subpage samples_mfc_standard "Readme" for details.
|
||||||
|
|
||||||
|
Qt
|
||||||
|
---
|
||||||
|
|
||||||
|
OCCT contains three samples based on Qt application framework
|
||||||
|
|
||||||
|
Import Export
|
||||||
|
-------------
|
||||||
|
|
||||||
|
Import Export programming sample contains 3D Viewer and Import / Export functionality.
|
||||||
|
|
||||||
|
@figure{/samples/images/samples_qt.png}
|
||||||
|
|
||||||
|
Tutorial
|
||||||
|
---------
|
||||||
|
|
||||||
|
The Qt programming tutorial teaches how to use Open CASCADE Technology services to model a 3D object.
|
||||||
|
The purpose of the tutorial is not to explain all OCCT classes but
|
||||||
|
to help start thinking in terms of the Open CASCADE Technology.
|
||||||
|
|
||||||
|
This tutorial assumes that the user has experience in using and setting up C++.
|
||||||
|
From the viewpoint of programming, Open CASCADE Technology is designed
|
||||||
|
to enhance user's C++ tools with high performance modeling classes, methods and functions.
|
||||||
|
The combination of these resources allows creating substantial applications.
|
||||||
|
|
||||||
|
**See also:** @ref occt__tutorial "OCCT Tutorial"
|
||||||
|
|
||||||
|
C#
|
||||||
|
---
|
||||||
|
|
||||||
|
C# sample demonstrates integration of OCCT 3D Viewer and Import / Export functionality into .NET applications (using Windows Forms and WPF front ends).
|
||||||
|
|
||||||
|
@figure{/samples/images/samples_c__ie.png}
|
||||||
|
|
||||||
|
Import:
|
||||||
|
|
||||||
|
* BRep
|
||||||
|
* Iges
|
||||||
|
* Step
|
||||||
|
|
||||||
|
Export:
|
||||||
|
|
||||||
|
* Brep
|
||||||
|
* Iges
|
||||||
|
* Step
|
||||||
|
* Stl
|
||||||
|
* Vrml
|
||||||
|
|
||||||
|
See @subpage samples_csharp_occt "C# sample Readme" for details.
|
||||||
|
|
||||||
|
There is also another C# example with the same functionality, which demonstrates the integration of Direct3D Viewer into .NET applications using WPF front end.
|
||||||
|
|
||||||
|
See @subpage samples_csharp_direct3d "Direct3D C# sample Readme" for details.
|
||||||
|
|
||||||
|
Android
|
||||||
|
---------
|
||||||
|
|
||||||
|
There are two samples are representing usage OCCT framework on Android mobile platform. They represent an OCCT-based 3D-viewer with CAD import support in formats BREP, STEP and IGES: jniviewer (java) and AndroidQt (qt+qml)
|
||||||
|
|
||||||
|
jniviewer
|
||||||
|
@figure{/samples/images/samples_java_android_occt.jpg}
|
||||||
|
Java -- See @subpage samples_java_android_occt "Android Java sample Readme" for details.
|
||||||
|
|
||||||
|
AndroidQt
|
||||||
|
@figure{/samples/images/samples_qml_android_occt.jpg}
|
||||||
|
Qt -- See \subpage samples_qml_android_occt "Android Qt sample Readme" for details.
|
||||||
|
|
||||||
|
iOS
|
||||||
|
---
|
||||||
|
|
||||||
|
There is a sample demonstrating usage of OCCT on iOS with Apple UIKit framework.
|
||||||
|
|
||||||
|
@figure{/samples/images/sample_ios_uikit.png}
|
||||||
|
|
||||||
|
See @subpage occt_samples_ios_uikit "iOS sample Readme" for details.
|
||||||
|
|
||||||
|
Web
|
||||||
|
---------
|
||||||
|
|
||||||
|
WebGL Viewer sample demonstrating usage of OCCT 3D Viewer in Web browser with Emscripten SDK can be found in `samples/webgl`.
|
||||||
|
|
||||||
|
@figure{/samples/images/sample_webgl.png}
|
||||||
|
|
||||||
|
See @subpage occt_samples_webgl "WebGL sample Readme" for details.
|
||||||
|
|
||||||
|
OCAF Usage Sample
|
||||||
|
------------------
|
||||||
|
|
||||||
|
The provided set of samples dedicates to get initial knowledge about typical actions with OCAF services. It may be
|
||||||
|
useful for newcomers.
|
||||||
|
|
||||||
|
Read more about @subpage samples__ocaf
|
||||||
|
|
||||||
|
OCAF Function Mechanism Usage
|
||||||
|
-----------------------------
|
||||||
|
|
||||||
|
This simple example dedicates to the usage of "Function Mechanism" of OCCT Application Framework. It represents a "nail"
|
||||||
|
composed by a cone and two cylinders of different radius and height.
|
||||||
|
|
||||||
|
Read more about @subpage samples__ocaf_func
|
||||||
|
|
||||||
|
Draw Demo Scripts
|
||||||
|
------------------
|
||||||
|
|
||||||
|
A set of demo scripts demonsrates using OCCT functionality from DRAW. These scripts can be also considered as a
|
||||||
|
tutorials on tcl usage within Draw.
|
||||||
|
|
||||||
|
Read more about @subpage samples__draw_scripts
|
||||||
@ -3560,3 +3560,4 @@ baddtools b2
|
|||||||
bapibop r 4
|
bapibop r 4
|
||||||
~~~~
|
~~~~
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
Binary file not shown.
|
Before Width: | Height: | Size: 6.5 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 9.5 KiB |
@ -1,328 +0,0 @@
|
|||||||
Technical Overview {#technical_overview}
|
|
||||||
========================================
|
|
||||||
|
|
||||||
@tableofcontents
|
|
||||||
|
|
||||||
Open CASCADE Technology (OCCT) is an object-oriented C++ class library designed for rapid production of sophisticated domain-specific CAD/CAM/CAE applications.
|
|
||||||
|
|
||||||
A typical application developed using OCCT deals with two or three-dimensional (2D or 3D) geometric modeling
|
|
||||||
in general-purpose or specialized Computer Aided Design (CAD) systems, manufacturing
|
|
||||||
or analysis applications, simulation applications, or even illustration tools.
|
|
||||||
|
|
||||||
@figure{/technical_overview/images/technical_overview_over.png}
|
|
||||||
|
|
||||||
OCCT library is designed to be truly modular and extensible, providing C++ classes for:
|
|
||||||
* Basic data structures (geometric modeling, visualization, interactive selection and application specific services);
|
|
||||||
* Modeling algorithms;
|
|
||||||
* Working with mesh (faceted) data;
|
|
||||||
* Data interoperability with neutral formats (IGES, STEP);
|
|
||||||
|
|
||||||
The C++ classes and other types are grouped into packages. Packages are organized into toolkits (libraries), to which you can link your application. Finally, toolkits are grouped into seven modules.
|
|
||||||
|
|
||||||
This modular structure is illustrated in the diagram below.
|
|
||||||
|
|
||||||
@figure{/technical_overview/images/technical_overview_schema.png}
|
|
||||||
|
|
||||||
* @ref OCCT_TOVW_SECTION_2 "Foundation Classes" module underlies all other OCCT classes;
|
|
||||||
* @ref OCCT_TOVW_SECTION_3 "Modeling Data" module supplies data structures to represent 2D and 3D geometric primitives and their compositions into CAD models;
|
|
||||||
* @ref OCCT_TOVW_SECTION_4 "Modeling Algorithms" module contains a vast range of geometrical and topological algorithms;
|
|
||||||
* @ref OCCT_TOVW_SECTION_4a "Mesh" toolkit from "Modeling Algorithms" module implements tessellated representations of objects;
|
|
||||||
* @ref OCCT_TOVW_SECTION_5 "Visualization" module provides complex mechanisms for graphical data representation;
|
|
||||||
* @ref OCCT_TOVW_SECTION_6 "Data Exchange" module inter-operates with popular data formats and relies on @ref OCCT_TOVW_SECTION_6a "Shape Healing" to improve compatibility between CAD software of different vendors;
|
|
||||||
* @ref OCCT_TOVW_SECTION_7 "Application Framework" module offers ready-to-use solutions for handling application-specific data (user attributes) and commonly used functionality (save/restore, undo/redo, copy/paste, tracking CAD modifications, etc).
|
|
||||||
|
|
||||||
In addition, @ref OCCT_TOVW_SECTION_8 "Open CASCADE Test Harness", also called Draw, provides an entry point to the library and can be used as a testing tool for its modules.
|
|
||||||
|
|
||||||
@section OCCT_TOVW_SECTION_2 Foundation Classes
|
|
||||||
|
|
||||||
**Foundation Classes** module contains data structures and services used by higher-level Open CASCADE Technology classes:
|
|
||||||
|
|
||||||
* Primitive types, such as Boolean, Character, Integer or Real;
|
|
||||||
* String classes that handle Unicode strings;
|
|
||||||
* Collection classes that handle statically or dynamically sized aggregates of data, such as arrays, lists, queues, sets and hash tables (data maps).
|
|
||||||
* Classes providing commonly used numerical algorithms and basic linear algebra calculations (addition, multiplication, transposition of vectors and matrices, solving linear systems etc).
|
|
||||||
* Fundamental types like color, date and time information;
|
|
||||||
* Primitive geometry types providing implementation of basic geometric and algebraic entities that define and manipulate elementary data structures.
|
|
||||||
* Exception classes that describe situations, when the normal execution of program is abandoned;
|
|
||||||
|
|
||||||
This module also provides a variety of general-purpose services, such as:
|
|
||||||
* Safe handling of dynamically created objects, ensuring automatic deletion of unreferenced objects (smart pointers);
|
|
||||||
* Standard and specialized memory allocators;
|
|
||||||
* Extended run-time type information (RTTI) mechanism maintaining a full type hierarchy and providing means to iterate over it;
|
|
||||||
* Encapsulation of C++ streams;
|
|
||||||
* Basic interpreter of expressions facilitating the creation of customized scripting tools, generic definition of expressions, etc.;
|
|
||||||
* Tools for dealing with configuration resource files and customizable message files facilitating 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;
|
|
||||||
* and many others...
|
|
||||||
|
|
||||||
See the details in @ref occt_user_guides__foundation_classes "Foundation Classes User's Guide"
|
|
||||||
|
|
||||||
See also: our <a href="https://www.opencascade.com/content/tutorial-learning">E-learning & Training</a> offerings.
|
|
||||||
|
|
||||||
@section OCCT_TOVW_SECTION_3 Modeling Data
|
|
||||||
|
|
||||||
**Modeling Data** supplies data structures to implement boundary representation (BRep) of objects in 3D.
|
|
||||||
In BRep the shape is represented as an aggregation of geometry within topology.
|
|
||||||
The geometry is understood as a mathematical description of a shape, e.g. as curves and surfaces (simple or canonical, Bezier, NURBS, etc).
|
|
||||||
The topology is a data structure binding geometrical objects together.
|
|
||||||
|
|
||||||
Geometry types and utilities provide geometric data structures and services 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.
|
|
||||||
* Creation of parametric curves and surfaces by interpolation and approximation;
|
|
||||||
* Algorithms of direct construction;
|
|
||||||
* Conversion of curves and surfaces to NURBS form;
|
|
||||||
* Computation of point coordinates on 2D and 3D curves;
|
|
||||||
* Calculation of extrema between geometric objects.
|
|
||||||
|
|
||||||
Topology defines relationships between simple geometric entities.
|
|
||||||
A shape, which is a basic topological entity, can be divided into components (sub-shapes):
|
|
||||||
* Vertex -- a zero-dimensional shape corresponding to a point;
|
|
||||||
* Edge -- a shape corresponding to a curve and bounded by a vertex at each extremity;
|
|
||||||
* Wire -- a sequence of edges connected by their vertices;
|
|
||||||
* Face -- a part of a plane (in 2D) or a surface (in 3D) bounded by wires;
|
|
||||||
* Shell -- a collection of faces connected by edges of their wire boundaries;
|
|
||||||
* Solid -- a finite closed part of 3D space bounded by shells;
|
|
||||||
* Composite solid -- a collection of solids connected by faces of their shell boundaries;
|
|
||||||
* Compound -- a collection of shapes of arbitrary type.
|
|
||||||
|
|
||||||
Complex shapes can be defined as assemblies (compounds) of simpler entities.
|
|
||||||
|
|
||||||
See the details in @ref occt_user_guides__modeling_data "Modeling Data User's Guide"
|
|
||||||
|
|
||||||
3D geometric models can be stored in OCCT native BREP format.
|
|
||||||
See @ref occt_user_guides__brep_wp "BREP Format Description White Paper" for details on the format.
|
|
||||||
|
|
||||||
See also: our <a href="https://www.opencascade.com/content/tutorial-learning">E-learning & Training</a> offerings.
|
|
||||||
|
|
||||||
@section OCCT_TOVW_SECTION_4 Modeling Algorithms
|
|
||||||
|
|
||||||
**Modeling Algorithms** module groups a wide range of topological and geometric algorithms used in geometric modeling.
|
|
||||||
Basically, there are two groups of algorithms in Open CASCADE Technology:
|
|
||||||
* High-level modeling routines used in the real design;
|
|
||||||
* Low-level mathematical support functions used as a groundwork for the modeling API.
|
|
||||||
|
|
||||||
Low-level *geometric tools* provide the algorithms, which:
|
|
||||||
* Calculate the intersection of two curves, surfaces, or a curve and a surface;
|
|
||||||
* Project points onto 2D and 3D curves, points onto surfaces and 3D curves onto surfaces;
|
|
||||||
* Construct lines and circles from constraints;
|
|
||||||
* Construct free-form curves and surfaces from constraints (interpolation, approximation, skinning, gap filling, etc).
|
|
||||||
|
|
||||||
Low-level *topological tools* provide the algorithms, which:
|
|
||||||
* Tessellate shapes;
|
|
||||||
* Check correct definition of shapes;
|
|
||||||
* Determine the local and global properties of shapes (derivatives, mass-inertia properties, etc);
|
|
||||||
* Perform affine transformations;
|
|
||||||
* Find planes in which edges are located;
|
|
||||||
* Convert shapes to NURBS geometry;
|
|
||||||
* Sew connected topologies (shells and wires) from separate topological elements (faces and edges).
|
|
||||||
|
|
||||||
Top-level API provides the following functionality:
|
|
||||||
* Construction of Primitives:
|
|
||||||
* Boxes;
|
|
||||||
* Prisms;
|
|
||||||
* Cylinders;
|
|
||||||
* Cones;
|
|
||||||
* Spheres;
|
|
||||||
* Toruses.
|
|
||||||
* Kinematic Modeling:
|
|
||||||
* Prisms -- linear sweeps;
|
|
||||||
* Revolutions -- rotational sweeps;
|
|
||||||
* Pipes -- general-form sweeps;
|
|
||||||
* Lofting.
|
|
||||||
|
|
||||||
@figure{/technical_overview/images/0001.png "Shapes containing pipes with variable radius produced by sweeping"}
|
|
||||||
|
|
||||||
* Boolean Operations, which allow creating new shapes from the combinations of source shapes. For two shapes *S1* and *S2*:
|
|
||||||
* *Common* contains all points that are in *S1* and *S2*;
|
|
||||||
* *Fuse* contains all points that are in *S1* or *S2*;
|
|
||||||
* *Cut* contains all points in that are in *S1* and not in *S2*.
|
|
||||||
|
|
||||||
See @ref occt_user_guides__boolean_operations "Boolean Operations" User's Guide for detailed documentation.
|
|
||||||
|
|
||||||
* Algorithms for local modifications such as:
|
|
||||||
* Hollowing;
|
|
||||||
* Shelling;
|
|
||||||
* Creation of tapered shapes using draft angles;
|
|
||||||
* Algorithms to make fillets and chamfers on shape edges, including those with variable radius (chord).
|
|
||||||
|
|
||||||
* Algorithms for creation of mechanical features, i.e. depressions, protrusions, ribs and grooves or slots along planar or revolution surfaces.
|
|
||||||
|
|
||||||
@figure{/technical_overview/images/0004.png}
|
|
||||||
|
|
||||||
See the details in @ref occt_user_guides__modeling_algos "Modeling Algorithms User's Guide".
|
|
||||||
|
|
||||||
See also: our <a href="https://www.opencascade.com/content/tutorial-learning">E-learning & Training</a> offerings.
|
|
||||||
|
|
||||||
@subsection OCCT_TOVW_SECTION_4a Mesh
|
|
||||||
|
|
||||||
**Mesh** toolkit provides the functionality to work with tessellated representations of objects in form of triangular facets. This toolkit contains:
|
|
||||||
- data structures to store surface mesh data associated to shapes and basic algorithms to handle them;
|
|
||||||
- data structures and algorithms to build triangular surface mesh from *BRep* objects (shapes);
|
|
||||||
- tools for displaying meshes with associated pre- and post-processor data (scalars or vectors).
|
|
||||||
|
|
||||||
Open CASCADE SAS also offers Advanced Mesh Products:
|
|
||||||
- <a href="https://www.opencascade.com/content/mesh-framework">Open CASCADE Mesh Framework (OMF)</a>
|
|
||||||
- <a href="https://www.opencascade.com/content/express-mesh">Express Mesh</a>
|
|
||||||
|
|
||||||
@figure{/technical_overview/images/0003.png}
|
|
||||||
|
|
||||||
@section OCCT_TOVW_SECTION_5 Visualization
|
|
||||||
|
|
||||||
**Visualization** module provides ready-to-use algorithms to create graphic presentations from various objects: shapes, meshes, etc.
|
|
||||||
|
|
||||||
In Open CASCADE Technology visualization is based on the separation of CAD data and its graphical presentation.
|
|
||||||
The module also supports a fast and powerful interactive selection mechanism.
|
|
||||||
|
|
||||||
Visualization module relies on the following key toolkits:
|
|
||||||
- *TKV3d* toolkit defines a high-level API called (Application Interactive Services* (AIS) for working with interactive objects.
|
|
||||||
- *TKService* toolkit defines a low-level API for managing and creating presentations from primitive arrays.
|
|
||||||
This toolkit defines an abstraction layer for defining an arbitrary graphic driver responsible for actual rendering.
|
|
||||||
- *TKOpenGl* toolkit implements the graphic driver using OpenGL and OpenGL ES libraries.
|
|
||||||
|
|
||||||
While low-level API operates with primitive arrays (triangles, lines, points), the higher level includes services for building presentations for B-Rep shapes (shaded and wireframe).
|
|
||||||
A comprehensive list of standard interactive objects includes topological shape, mesh presentation, various dimensions, manipulators and others.
|
|
||||||
It provides a solid basis for rapid application development, while flexible and extensible API allows development of highly customized application-specific presentations.
|
|
||||||
|
|
||||||
Here are a few examples of OCCT Visualization features:
|
|
||||||
* Camera-driven view projection and orientation.
|
|
||||||
Perspective, orthographic and stereographic projections are supported.
|
|
||||||
* Support of Common (diffuse/ambient/specular) and PBR metallic-roughness material models.
|
|
||||||
* Possibility to flexibly adjust appearance of dimensions in a 3D view.
|
|
||||||
The 3D text object represents a given text string as a true 3D object in the model space.
|
|
||||||
* Definition of clipping planes through the plane equation coefficients.
|
|
||||||
Ability to define visual attributes for cross-section at the level or individual clipping planes.
|
|
||||||
In the image below different parts of the rocket are clipped with different planes and hatched.
|
|
||||||
@figure{/technical_overview/images/0008.png, "Display of shape cross-section and dimensions"}
|
|
||||||
|
|
||||||
* Support of built-in and application-specific GLSL shaders.
|
|
||||||
@figure{/technical_overview/images/0013.png, "Fragment shader implementing custom clipping surface"}
|
|
||||||
|
|
||||||
* Optimization of rendering performance through the algorithms of:
|
|
||||||
* View frustum culling, which skips the presentation outside camera at the rendering stage;
|
|
||||||
* Back face culling, which reduces the rendered number of triangles and eliminates artifacts at shape boundaries.
|
|
||||||
* Real-time ray tracing technique using recursive Whitted's algorithm and Bounded Volume Hierarchy effective optimization structure.
|
|
||||||
@figure{/technical_overview/images/0002.png, "Real time visualization by ray tracing method"}
|
|
||||||
@figure{/technical_overview/images/0012.png, "Simulation of a glass cover"}
|
|
||||||
|
|
||||||
For more details, see @ref occt_user_guides__visualization "Visualization User's Guide".
|
|
||||||
|
|
||||||
The visualization of OCCT topological shapes by means of VTK library provided by VIS component is described in a separate @ref occt_user_guides__vis "VTK Integration Services" User's Guide.
|
|
||||||
|
|
||||||
See also: our <a href="https://www.opencascade.com/content/tutorial-learning">E-learning & Training</a> offerings.
|
|
||||||
|
|
||||||
@section OCCT_TOVW_SECTION_6 Data Exchange
|
|
||||||
|
|
||||||
**Data Exchange** allows developing OCCT-based applications that can interact with other CAD systems by writing and reading CAD models to and from external data.
|
|
||||||
|
|
||||||
@figure{/technical_overview/images/0014.png,"Shape imported from STEP"}
|
|
||||||
|
|
||||||
**Data Exchange** is organized in a modular way as a set of interfaces that comply with various CAD formats: IGES, STEP, STL, VRML, etc.
|
|
||||||
The interfaces allow software based on OCCT to exchange data with various CAD/PDM software packages, maintaining a good level of interoperability.
|
|
||||||
This module handles various problems of interoperability between CAD systems, caused by differences in model validity criteria and requirements to internal representation.
|
|
||||||
|
|
||||||
* **Standardized Data Exchange** interfaces allow querying and examining the input file, converting its contents to a CAD model and running validity checks on a fully translated shape.
|
|
||||||
The following formats are currently supported:
|
|
||||||
* @ref occt_user_guides__step "STEP" (AP203: Mechanical Design, this covers General 3D CAD; AP214: Automotive Design; AP242).
|
|
||||||
* @ref occt_user_guides__iges "IGES" (up to 5.3).
|
|
||||||
* **glTF** 2.0 reader and writer.
|
|
||||||
* **OBJ** mesh file reader.
|
|
||||||
* **VRML** converter translates Open CASCADE shapes to VRML 1.0 files (Virtual Reality Modeling Language).
|
|
||||||
* **STL** converter translates Open CASCADE shapes to STL files.
|
|
||||||
STL (STtereoLithography) format is widely used for rapid prototyping (3D printing).
|
|
||||||
* @ref occt_user_guides__xde "Extended data exchange" (XDE) allows translating additional attributes attached to geometric data (colors, layers, names, materials etc).
|
|
||||||
* <a href="https://www.opencascade.com/content/advanced-data-exchange-components">Advanced Data Exchange Components</a>
|
|
||||||
are available in addition to standard Data Exchange interfaces to support interoperability and data adaptation (also using @ref OCCT_TOVW_SECTION_6a "Shape Healing") with CAD software using the following proprietary formats:
|
|
||||||
* <a href="https://www.opencascade.com/content/acis-sat-import-export">ACIS SAT</a>
|
|
||||||
* <a href="https://www.opencascade.com/content/parasolid-import">Parasolid</a>
|
|
||||||
* <a href="https://www.opencascade.com/content/dxf-import-export">DXF</a>
|
|
||||||
* <a href="https://www.opencascade.com/content/ifc-import">IFC</a>
|
|
||||||
* <a href="https://www.opencascade.com/content/jt-import-export">JT</a>
|
|
||||||
|
|
||||||
These components are based on the same architecture as interfaces with STEP and IGES.
|
|
||||||
|
|
||||||
@section OCCT_TOVW_SECTION_6a Shape Healing
|
|
||||||
|
|
||||||
**Shape Healing** library provides algorithms to correct and adapt the geometry and topology of shapes imported to OCCT from other CAD systems.
|
|
||||||
|
|
||||||
Shape Healing algorithms include, but are not limited to, the following operations:
|
|
||||||
* Analyze shape characteristics and, in particular, identify the shapes that do not comply with OCCT geometry and topology validity rules by analyzing geometrical objects and topology:
|
|
||||||
- check edge and wire consistency;
|
|
||||||
- check edge order in a wire;
|
|
||||||
- check the orientation of face boundaries;
|
|
||||||
- analyze shape tolerances;
|
|
||||||
- identify closed and open wires in a boundary.
|
|
||||||
* Fix incorrect or incomplete shapes:
|
|
||||||
- provide consistency between a 3D curve and its corresponding parametric curve;
|
|
||||||
- repair defective wires;
|
|
||||||
- fit the shapes to a user-defined tolerance value;
|
|
||||||
- fill gaps between patches and edges.
|
|
||||||
* Upgrade and change shape characteristics:
|
|
||||||
- reduce curve and surface degree;
|
|
||||||
- split shapes to obtain C1 continuity;
|
|
||||||
- convert any types of curves or surfaces to Bezier or B-Spline curves or surfaces and back;
|
|
||||||
- split closed surfaces and revolution surfaces.
|
|
||||||
|
|
||||||
Each sub-domain of Shape Healing has its own scope of functionality:
|
|
||||||
|
|
||||||
| Sub-domain | Description | Impact on the shape |
|
|
||||||
| :--- | :---- | :---- |
|
|
||||||
| Analysis | Explores shape properties, computes shape features, detects violation of OCCT requirements. | The shape itself is not modified. |
|
|
||||||
| Fixing | Fixes the shape to meet the OCCT requirements. | The shape may change its original form: modification, removal or creation of sub-shapes, etc.) |
|
|
||||||
| Upgrade | Improves the shape to fit some particular algorithms. | The shape is replaced with a new one, but geometrically they are the same. |
|
|
||||||
| Customization | Modifies the shape representation to fit specific needs. | The shape is not modified, only the mathematical form of its internal representation is changed. |
|
|
||||||
| Processing | Mechanism of shape modification via a user-editable resource file. | |
|
|
||||||
|
|
||||||
For more details, refer to @ref occt_user_guides__shape_healing "Shape Healing User's guide".
|
|
||||||
|
|
||||||
See also: our <a href="https://www.opencascade.com/content/tutorial-learning">E-learning & Training</a> offerings.
|
|
||||||
|
|
||||||
@section OCCT_TOVW_SECTION_7 Application Framework
|
|
||||||
|
|
||||||
**Open CASCADE Application Framework** (OCAF) handles Application Data basing on the Application/Document paradigm.
|
|
||||||
It uses an associativity engine to simplify the development of a CAD application thanks to the following ready-to-use features and services:
|
|
||||||
|
|
||||||
* Data attributes managing the application data, which can be organized according to the development needs;
|
|
||||||
* Data storage and persistence (open/save);
|
|
||||||
* Possibility to modify and recompute attributes in documents.
|
|
||||||
With OCAF it is easy to represent the history of modification and parametric dependencies within your model;
|
|
||||||
* Possibility to manage multiple documents;
|
|
||||||
* Predefined attributes common to CAD/CAM/CAE applications (e.g. to store dimensions);
|
|
||||||
* Undo-Redo and Copy-Paste functions.
|
|
||||||
|
|
||||||
Since OCAF handles the application structure, the only development task is the creation of application-specific data and GUIs.
|
|
||||||
|
|
||||||
OCAF differs from any other CAD framework in the organization of application data, as there the data structures are based on reference keys rather than on shapes.
|
|
||||||
In a model, such attributes as shape data, color and material are attached to an invariant structure, which is deeper than the shapes.
|
|
||||||
A shape object becomes the value of *Shape* attribute, in the same way as an integer number is the value of *Integer* attribute and a string is the value of *Name* attribute.
|
|
||||||
|
|
||||||
OCAF organizes and embeds these attributes in a document. OCAF documents, in their turn, are managed by an OCAF application.
|
|
||||||
|
|
||||||
For more details, see @ref occt_user_guides__ocaf "OCAF User's Guide".
|
|
||||||
|
|
||||||
See also: our <a href="https://www.opencascade.com/content/tutorial-learning">E-learning & Training</a> offerings.
|
|
||||||
|
|
||||||
@section OCCT_TOVW_SECTION_8 Draw Test Harness
|
|
||||||
|
|
||||||
**Test Harness** or **Draw** is a convenient testing tool for OCCT libraries.
|
|
||||||
It can be used to test and prototype various algorithms before building an entire application.
|
|
||||||
It includes:
|
|
||||||
- A command interpreter based on the TCL language;
|
|
||||||
- A number of 2D and 3D viewers;
|
|
||||||
- A set of predefined commands.
|
|
||||||
|
|
||||||
The viewers support operations such as zoom, pan, rotation and full-screen views.
|
|
||||||
|
|
||||||
The basic commands provide general-purpose services such as:
|
|
||||||
- Getting help;
|
|
||||||
- Evaluating a script from a file;
|
|
||||||
- Capturing commands in a file;
|
|
||||||
- Managing views;
|
|
||||||
- Displaying objects.
|
|
||||||
|
|
||||||
In addition, **Test Harness** provides commands to create and manipulate curves and surfaces (geometry) and shapes, access visualization services, work with OCAF documents, perform data exchange, etc.
|
|
||||||
|
|
||||||
You can add custom commands to test or demonstrate any new functionalities, which you develop.
|
|
||||||
|
|
||||||
For more details, see @ref occt_user_guides__test_harness "Draw Test Harness Manual".
|
|
||||||
Binary file not shown.
|
Before Width: | Height: | Size: 1.9 KiB After Width: | Height: | Size: 5.5 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.8 KiB After Width: | Height: | Size: 5.4 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.7 KiB After Width: | Height: | Size: 6.6 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.7 KiB After Width: | Height: | Size: 8.1 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 3.1 KiB After Width: | Height: | Size: 7.8 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.6 KiB After Width: | Height: | Size: 4.3 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 3.3 KiB After Width: | Height: | Size: 5.0 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 4.3 KiB After Width: | Height: | Size: 7.3 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 4.1 KiB After Width: | Height: | Size: 8.1 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 5.7 KiB After Width: | Height: | Size: 11 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 2.8 KiB After Width: | Height: | Size: 11 KiB |
Loading…
x
Reference in New Issue
Block a user