Open CASCADE Technology
7.7.0
|
|
This document provides technical details on changes made in particular versions of OCCT. It can help to upgrade user applications based on previous versions of OCCT to newer ones.
SEEK TO THE LAST CHAPTER (UPGRADE TO 7.7.0)
Back-up your code before the upgrade. We strongly recommend using version control system during the upgrade process and saving one or several commits at each step of upgrade, until the overall result is verified. This will facilitate identification and correction of possible problems that can occur at the intermediate steps of upgrade. It is advisable to document each step carefully to be able to repeat it if necessary.
This document describes known issues that have been encountered during porting of OCCT and some applications and approaches that have helped to resolve these issues in known cases. It does not pretend to cover all possible migration issues that can appear in your application. Take this document with discretion; apply your expertise and knowledge of your application to ensure the correct result.
The automatic upgrade tool is provided as is, without warranty of any kind, and we explicitly disclaim any liability for possible errors that may appear due to use of this tool. It is your responsibility to ensure that the changes you made in your code are correct. When you upgrade the code by an automatic script, make sure to carefully review the introduced changes at each step before committing them.
Porting of user applications from an earlier OCCT version to version 6.5 requires taking into account the following major changes:
Porting of user applications from an earlier OCCT version to version 6.5.1 requires taking into account the following major changes:
Porting of user applications from an earlier OCCT version to version 6.5.2 requires taking into account the following major changes:
Porting of user applications from an earlier OCCT version to version 6.5.3 requires taking into account the following major changes:
Porting of user applications from an earlier OCCT version to version 6.5.4 requires taking into account the following major changes:
Porting of user applications from an earlier OCCT version to version 6.6.0 requires taking into account the following major changes:
Porting of user applications from an earlier OCCT version to version 6.7.0 requires taking into account the following major changes.
As the obsolete methods Init(), DefaultOrthographicView() and DefaultPerspectiveView() have been removed from V3d_Viewer class, the two default views are no longer created automatically. It is obligatory to create V3d_View instances explicitly, either directly by operator new or by calling V3d_Viewer::CreateView().
The call V3d_Viewer::SetDefaultLights() should also be done explicitly at the application level, if the application prefers to use the default light source configuration. Otherwise, the application itself should set up the light sources to obtain a correct 3D scene.
It might be necessary to revise your application code, which uses non-ordered Graphic3d_SetOfHClipPlane collection type and replace its occurrences by ordered Graphic3d_SequenceOfHClipPlane collection type.
Porting of user applications from an earlier OCCT version to version 6.8.0 requires taking into account the following major changes.
Method Assign() in NCollection classes does not allow any more copying between different collection types. Such copying should be done manually.
List and map classes in NCollection package now require that their items be copy-constructible, but do not require items to have default constructor. Thus the code using NCollection classes for non-copy-constructible objects needs be updated. One option is to provide copy constructor; another possibility is to use Handle or other smart pointer.
If ViewMapping and ViewOrientation were used directly, this functionality has to be ported to the new camera model. The following methods should be considered as an alternative to the obsolete Visual3d services (all points and directions are supposed to be in world coordinates):
The current perspective model is not fully backward compatible, so the old perspective-related functionality needs to be reviewed.
Revise application-specific custom presentations to provide a proper bounding box, otherwise the object might become erroneously clipped by automatic ZFit or frustum culling algorithms enabled by default.
The new implementation of connected Interactive Objects makes it necessary to take the following steps if you use connected Interactive Objects in your application.
Support of UNICODE characters introduced in OCCT breaks backward compatibility with applications, which currently use filenames in extended ASCII encoding bound to the current locale. Such applications should be updated to convert such strings to UTF-8 format.
The conversion from UTF-8 to wchar_t is made using little-endian approach. Thus, this code will not work correctly on big-endian platforms. It is needed to complete this in the way similar as it is done for binary persistence (see the macro DO_INVERSE in FSD_FileHeader.hxx).
It might be necessary to revise the application code, which deals with Center() method of V3d_View.
This method was used to pan a V3d view by virtually moving the screen center with respect to the projection ray passed through Eye and At points. There is no more need to derive the panning from the Center parameter to get a camera-like eye position and look at the coordinates. Eye() and At() now return these coordinates directly. When porting code dealing with Center(), the parameters Eye() and At() can be adjusted instead. Also V3d_View::SetCenter(Xpix, Ypix) method can be used instead of V3d_View::Center(X, Y) to center the view at the given point. However, if the center coordinates X and Y come from older OCCT releases, calling V3d_View::Panning(-X, -Y) can be recommended to compensate missing projection shift effect.
There are several changes introduced to Graphic3d_Camera. The internal data structure of the camera is based on Standard_Real data types to avoid redundant application-level conversions and precision errors. The transformation matrices now can be evaluated both for Standard_Real and Standard_ShortReal value types. ZNear and ZFar planes can be either negative or positive for orthographic camera projection, providing a trade-off between the camera distance and the range of ZNear or ZFar to reduce difference of exponents of values composing the orientation matrix - to avoid calculation errors. The negative values can be specified to avoid Z-clipping if the reference system of camera goes inside of the model when decreasing camera distance.
The auto z fit mode, since now, has a parameter defining Z-range margin (the one which is usually passed as argument to ZFitAll() method). The methods SetAutoZFitMode(), AutoZFitScaleFactor() and ZFitAll() from class V3d_View deal with the new parameter.
The class Select3D_Projector now supports both orientation and projection transformation matrices, which can be naturally set for the projector. The definition of projector was revised in StdSelect_ViewerSelector3d: perspective and orthographic projection parameters are handled properly. Orthographic projector is based only on direction of projection - no more Center property. This makes it possible to avoid unnecessary re-projection of sensitive while panning, zooming or moving along the projection ray of the view. These operations do not affect the orthographic projection.
Porting of user applications from an earlier OCCT version to version 6.9.0 requires taking into account the following major changes.
3D Viewer now uses GLSL programs for managing frame buffer and stereoscopic output. For proper initialization, application should configure CSF_ShadersDirectory environment variable pointing to a folder with GLSL resources - files from folder CASROOT/src/Shaders. Note that CSF_ShadersDirectory become optional since OCCT 7.1.0 release.
Selection mechanism of 3D Viewer has been redesigned to use 3-level BVH tree traverse directly in 3D space instead of projection onto 2D screen space (updated on each rotation). This architectural redesign may require appropriate changes at application level in case if custom Interactive Objects are used.
Usage of standard OCCT selection entities would require only minor updates.
Custom Interactive Objects should implement new virtual method SelectMgr_SelectableObject::BoundingBox().
Now the method SelectMgr_Selection::Sensitive() does not return SelectBasics_SensitiveEntity. It returns an instance of SelectMgr_SensitiveEntity, which belongs to a different class hierarchy (thus DownCast() will fail). To access base sensitive it is necessary to use method SelectMgr_SensitiveEntity::BaseSensitive(). For example:
Custom sensitive entities require more complex changes, since the selection algorithm has been redesigned and requires different output from the entities.
The method SelectBasics_SensitiveEntity::Matches() of the base class should be overridden following the new signature:
Standard_Boolean Matches (SelectBasics_SelectingVolumeManager& theMgr, SelectBasics_PickResult& thePickResult), where theMgr contains information about the currently selected frustum or set of frustums (see SelectMgr_RectangularFrustum, SelectMgr_TrangularFrustum, SelectMgr_TriangularFrustumSet) and SelectBasics_PickResult is an output parameter, containing information about the depth of the detected entity and distance to its center of geometry.
In the overridden method it is necessary to implement an algorithm of overlap and inclusion detection (the active mode is returned by theMgr.IsOverlapAllowed()) with triangular and rectangular frustums.
The depth and distance to the center of geometry must be calculated for the 3D projection of user-picked screen point in the world space. You may use already implemented overlap and inclusion detection methods for different primitives from SelectMgr_RectangularFrustum and SelectMgr_TriangularFrustum, including triangle, point, axis-aligned box, line segment and planar polygon.
Here is an example of overlap/inclusion test for a box:
The interface of SelectBasics_SensitiveEntity now contains four new pure virtual functions that should be implemented by each custom sensitive:
Each sensitive entity now has its own tolerance, which can be overridden by method SelectBasics_SensitiveEntity::SetSensitivityFactor() called from constructor.
All classes inheriting Adaptor3d_Curve (directly or indirectly) must be updated in application code to use new signature of methods Intervals() and NbIntervals(). Note that no compiler warning will be generated if this is not done.
The methods V3d_View::Convert and V3d_View::ConvertWithProj() have ceased to return point on the active grid. It might be necessary to revise the code of your application so that V3d_View::ConvertToGrid() was called explicitly for the values returned by V3d_View::Convert to get analogous coordinates on the grid. The methods V3d_View::Convert and V3d_View::ConvertWithProj convert point into reference plane of the view corresponding to the intersection with the projection plane of the eye/view point vector.
Porting of user applications from an earlier OCCT version to version 7.0.0 requires taking into account the following major changes.
Building OCCT now requires compiler supporting some C++11 features. The supported compilers are:
When compiling code that uses OCCT with GCC and CLang compilers, it is necessary to use compiler option -std=c++0x (or its siblings) to enable C++11 features.
Legacy persistence for shapes and OCAF data based on Storage_Schema (toolkits TKPShape, TKPLCAF, TKPCAF, TKShapeShcema, TLStdLSchema, TKStdSchema, and TKXCAFSchema) has been removed in OCCT 7.0.0. The applications that used these data persistence tools need to be updated to use other persistence mechanisms.
The existing data files in standard formats can be converted using OCCT 6.9.1 or a previous version, as follows.
Files in CSFDB format (usually with extension .csfdb) contain OCCT shape data that can be converted to BRep format. The easiest way to do that is to use ImportExport sample provided with OCCT 6.9.0 (or earlier):
Files containing OCAF data saved in the old format usually have extensions .std, .sgd or .dxc (XDE documents). These files can be converted to XML or binary OCAF formats using DRAW Test Harness commands. Note that if the file contains only attributes defined in TKLCAF and TKCAF, this action can be performed in OCCT 7.0; otherwise OCCT 6.9.1 or earlier should be used.
For that, start DRAWEXE and perform the following commands:
On Windows, it is necessary to replace back slashes in the file path by direct slashes or pairs of back slashes.
Use XmlOcaf or XmlXCAF instead of BinOcaf and BinXCAF, respectively, to save in XML format instead of binary one.
OCCT code has been completely refactored in version 7.0 to get rid of obsolete technologies used since its inception: CDL (Cas.Cade Definition Language) and WOK (Workshop Organization Kit).
C++ code previously generated by WOK from CDL declarations is now included directly in OCCT sources.
This modification did not change names, API, and behavior of existing OCCT classes, thus in general the code based on OCCT 6.x should compile and work fine with OCCT 7.0. However, due to redesign of basic mechanisms (CDL generic classes, Handles and RTTI) using C++ templates, some changes may be necessary in the code when porting to OCCT 7.0, as described below.
WOK is not necessary anymore for building OCCT from sources, though it still can be used in a traditional way – auxiliary files required for that are preserved. The recommended method for building OCCT 7.x is CMake, see Building with CMake tool. The alternative solution is to use project files generated by OCCT legacy tool genproj, see Building with Genproj tool.
Most of typical changes required for upgrading code for OCCT 7.0 can be done automatically using the upgrade tool included in OCCT 7.0. This tool is a Tcl script, thus Tcl should be available on your workstation to run it.
Example:
On Windows, the helper batch script upgrade.bat can be used, provided that Tcl is either available in PATH, or configured via custom.bat script (for instance, if you use OCCT installed from Windows installer package). Start it from the command prompt:
Run the upgrade tool without arguments to see the list of available options.
The upgrade tool performs the following changes in the code.
Replaces macro DEFINE_STANDARD_RTTI by DEFINE_STANDARD_RTTIEXT, with second argument indicating base class for the main argument class (if inheritance is recognized by the script):
Removes uses of obsolete macros IMPLEMENT_DOWNCAST and IMPLEMENT_STANDARD_..., except IMPLEMENT_STANDARD_RTTIEXT.
As long as the upgrade routine runs, some information messages are sent to the standard output. In some cases the warnings or errors like the following may appear:
Be sure to check carefully all reported errors and warnings, as the corresponding code will likely require manual corrections. In some cases these messages may help you to detect errors in your code, for instance, cases where DEFINE_STANDARD_RTTI macro is used with incorrect class name as an argument.
Some situations requiring upgrade cannot be detected and / or handled by the automatic procedure. If you get compiler errors or warnings when trying to build the upgraded code, you will need to fix them manually. The following paragraphs list known situations of this kind.
The use of handle objects (construction, comparison using operators == or !=, use of function STANDRAD_TYPE() and method DownCast()) now requires the type of the object pointed by Handle to be completely known at compile time. Thus it may be necessary to include header of the corresponding class to make the code compilable.
For example, the following lines will fail to compile if Geom_Line.hxx is not included:
Note that it is not necessary to include header of the class to declare Handle to it. However, if you define a class B that uses Handle(A) in its fields, or contains a method returning Handle(A), it is advisable to have header defining A included in the header of B. This will eliminate the need to include the header A in each source file where class B is used.
This issue appears in the compilers that do not support default arguments in template functions (known cases are Visual C++ 10 and 11): the compiler reports an ambiguity error if a handle is used in the argument of a call to the function that has two or more overloaded versions, receiving handles to different types. The problem is that operator const handle<T2>& is defined for any type T2, thus the compiler cannot make the right choice.
Example:
Note that this problem can be avoided in many cases if macro OCCT_HANDLE_NOCAST is used, see below.
To resolve this ambiguity, change your code so that argument type should correspond exactly to the function signature. In some cases this can be done by using the relevant type for the corresponding variable, like in the example above:
Other variants consist in assigning the argument to a local variable of the correct type and using the direct cast or constructor:
Another possibility consists in defining additional template variant of the overloaded function causing ambiguity, and using SFINAE to resolve the ambiguity. This technique can be illustrated by the definition of the template variant of method IGESData_IGESWriter::Send().
As the cast of a handle to the reference to another handle to the base type has become a user-defined operation, the conversions that require this cast together with another user-defined cast will not be resolved automatically by the compiler.
For example:
The problem is that the class GC_MakeLine has a user-defined conversion to const Handle(Geom_TrimmedCurve)&, which is not the same as the type of the local variable aC.
To resolve this, use method Value():
or use variable of the appropriate type:
A similar problem appears with GCC compiler, when const handle to derived type is used to construct handle to base type via assignment (and in some cases in return statement), for instance:
This problem is specific to GCC and it does not appear if macro OCCT_HANDLE_NOCAST is used, see below.
You might need to clean your code from incorrect use of macros STANDARD_TYPE() and Handle().
Explicit definitions of static functions with names generated by macro STANDARD_TYPE(), which are artifacts of old implementation of RTTI, should be removed.
Example:
Incorrect location of closing parenthesis of Handle() macro that was not detectable in OCCT 6.x will cause a compiler error and must be corrected.
Example (note misplaced closing parenthesis):
Class Standard_AncestorIterator has been removed; use method Parent() of Standard_Type class to parse the inheritance chain.
Handles in OCCT 7.0 do not have the operator of conversion to Standard_Transient*, which was present in earlier versions. This is done to prevent possible unintended errors like this:
The places where this implicit cast has been used should be corrected manually. The typical situation is when Handle is passed to stream:
Call method get() explicitly to output the address of the Handle.
Method DownCast() in OCCT 7.0 is made templated; if its argument is not a base class, "deprecated" compiler warning is generated. This is done to prevent possible unintended errors like this:
The places where this cast has been used should be corrected manually.
If down casting is used in a template context where the argument can have the same or unrelated type so that DownCast() may be not available in all cases, use C++ dynamic_cast<> instead, e.g.:
Here is the list of known possible problems at run time after the upgrade to OCCT 7.0.
In previous versions, the compiler was able to detect the situation when a local variable of a "reference to a Handle" type is initialized by temporary object, and ensured that lifetime of that object is longer than that of the variable. In OCCT 7.0 with default options, it will not work if types of the temporary object and variable are different (due to involvement of user-defined type cast), thus such temporary object will be destroyed immediately.
This problem does not appear if macro OCCT_HANDLE_NOCAST is used during compilation, see below.
Example:
In OCCT 6.x and earlier versions the handle classes formed a hierarchy echoing the hierarchy of the corresponding object classes . This automatically enabled the possibility to use the handle to a derived class in all contexts where the handle to a base class was needed, e.g. to pass it in a function by reference without copying:
This feature was used in multiple places in OCCT and dependent projects. However it is potentially unsafe: in the above example no checks are done at compile time or at run time to ensure that the type assigned to the argument handle is compatible with the type of the handle passed as argument. If an object of incompatible type (e.g. Geom_Circle) is assigned to theCurve, the behavior will be unpredictable.
For compatibility with the existing code, OCCT 7.0 keeps this possibility by default, providing operators of type cast to the handle to a base type. However, this feature is unsafe and in specific situations it may cause compile-time or run-time errors as described above.
To provide a safer behavior, this feature can be disabled by a compile-time macro OCCT_HANDLE_NOCAST. When it is used, constructors and assignment operators are defined (instead of type cast operators) to convert handles to a derived type into handles to a base type. This implies creation of temporary objects and hence may be more expensive at run time in some circumstances, however this way is more standard, safer, and in general recommended.
The code that relies on the possibility of casting to base should be amended to always use the handle of argument type in function call and to use DownCast() to safely convert the result to the desired type. For instance, the code from the example below can be changed as follows:
If you like to preserve the compatibility of your application code with OCCT versions 6.x even after the upgrade to 7.0, consider the following suggestions:
Define macros DEFINE_STANDARD_RTTIEXT and DEFINE_STANDARD_RTTI_INLINE when building with previous versions of OCCT, resolving to DEFINE_STANDARD_RTTI with single argument
Example:
If your application is essentially based on CDL, and you need to upgrade it to OCCT 7.0, you will very likely need to convert your application code to non-CDL form. This is a non-trivial effort; the required actions would depend strongly on the structure of the code and used CDL features.
The upgrade script and sources of a specialized WOK version used for OCCT code upgrade can be found in WOK Git repository in branch CR0_700_2.
Contact us if you need more help.
Implementation of NURBS curves and surfaces has been revised: the cache of polynomial coefficients, which is used to accelerate the calculation of values of a B-spline, has been separated from data objects Geom2d_BSplineCurve, Geom_BSplineCurve and Geom_BSplineSurface into the dedicated classes BSplCLib_Cache and BSplSLib_Cache.
The benefits of this change are:
The drawback is that direct evaluation of B-Splines using methods of curves and surfaces becomes slower due to the absence of cache. The slow-down can be avoided by using adaptor classes Geom2dAdaptor_Curve, GeomAdaptor_Curve and GeomAdaptor_Surface, which now use cache when the curve or surface is a B-spline.
OCCT algorithms have been changed to use adaptors for B-spline calculations instead of direct methods for curves and surfaces. The same changes (use of adaptors instead of direct call to curve and surface methods) should be implemented in relevant places in the applications based on OCCT to get the maximum performance.
The result of Boolean operations became structured according to the structure of the input shapes. Therefore it may impact old applications that always iterate on direct children of the result compound assuming to obtain solids as iteration items, regardless of the structure of the input shapes. In order to get always solids as iteration items it is recommended to use TopExp_Explorer instead of TopoDS_Iterator.
Extrema computation between non-analytical curves in shape-shape distance calculation algorithm has been changed in order to return only one solution. So, if e.g. two edges are created on parallel b-spline curves the algorithm BRepExtrema_DistShapeShape will return only one solution instead of enormous number of solutions. There is no way to get algorithm working in old manner.
Package SortTools has been removed. The code that used the tools provided by that package should be corrected manually. The recommended approach is to use sorting algorithms provided by STL.
For instance:
can be replaced by:
The old mechanism for rendering Underlay and Overlay on-screen 2D objects based on Visual3d_Layer and immediate drawing model (uncached and thus slow) has been removed. Classes Aspect_Clayer2d, OpenGl_GraphicDriver_Layer, Visual3d_Layer, Visual3d_LayerItem, V3d_LayerMgr and V3d_LayerMgrPointer have been deleted. The following auxiliary definition have been removed as well: Aspect_TypeOfPrimitive, Aspect_TypeOfLayer, Aspect_TypeOfEdge, Aspect_TypeOfDrawMode, Aspect_TypeOfConstraint, Aspect_DriverDefinitionError, Aspect_BadAccess.
General AIS interactive objects with transformation persistence flag Graphic3d_TMF_2d can be used as a replacement of Visual3d_LayerItem. The anchor point specified for transformation persistence defines the window corner of (or center in case of (0, 0) point). To keep on-screen 2D objects on top of the main screen, they can be assigned to the appropriate Z-layer. Predefined Z-layers Graphic3d_ZLayerId_TopOSD and Graphic3d_ZLayerId_BotOSD are intended to replace Underlay and Overlay layers within the old API.
ColorScale object previously implemented using Visual3d_LayerItem has been moved to a new class AIS_ColorScale, with width and height specified explicitly. The property of V3d_View storing the global ColorScale object has been removed with associated methods V3d_View::ColorScaleDisplay(), V3d_View::ColorScaleErase(), V3d_View::ColorScaleIsDisplayed() and V3d_View::ColorScale() as well as the classes V3d_ColorScale, V3d_ColorScaleLayerItem and Aspect_ColorScale. Here is an example of creating ColorScale using the updated API:
To see how 2d objects are implemented in OCCT you can call Draw commands vcolorscale, vlayerline or vdrawtext (with -2d option). Draw command vcolorscale now requires the name of ColorScale object as argument. To display this object use command vdisplay. For example:
Here is a small example in C++ illustrating how to display a custom AIS object in 2d:
Package Visual3d implementing the intermediate layer between high-level V3d classes and low-level OpenGl classes for views and graphic structures management has been dropped.
The OpenGl_View inherits from the new class Graphic3d_CView. Graphic3d_CView is an interface class that declares abstract methods for managing displayed structures, display properties and a base layer code that implements computation and management of HLR (or more broadly speaking view-depended) structures.
In the new implementation it takes place of the eliminated Visual3d_View. As before the instance of Graphic3d_CView is still completely managed by V3d_View classes. It can be accessed through V3d_View interface but normally it should not be required as all its methods are completely wrapped.
In more details, a concrete specialization of Graphic3d_CView is created and returned by the graphical driver on request. Right after the creation the views are directly used for setting rendering properties and adding graphical structures to be displayed.
The rendering of graphics is possible after mapping a window and activating the view. The direct setting of properties obsoletes the use of intermediate structures with display parameter like Visual3d_ContextView, etc. This means that the whole package Visual3d becomes redundant.
The functionality previously provided by Visual3d package has been redesigned in the following way :
Old APIs based on global callback functions for creating UserDraw objects and for performing custom OpenGL rendering within the view have been dropped. UserDraw callbacks are no more required since OpenGl_Group now inherits Graphic3d_Group and thus can be accessed directly from AIS_InteractiveObject:
To perform a custom OpenGL code within the view, it is necessary to inherit from class OpenGl_View. See the following code sample:
The conception of Local Context has been deprecated. The related classes, e.g. AIS_LocalContext, and methods ( AIS_InteractiveContext::OpenLocalContext() and others) will be removed in a future OCCT release.
The main functionality provided by Local Context - selection of object subparts - can be now used within Neutral Point without opening any Local Context.
The property SelectionMode() has been removed from the class AIS_InteractiveObject. This property contradicts to selection logic, since it is allowed to activate several Selection modes at once. Therefore keeping one selection mode as object field makes no sense. Applications that used this method should implement selection mode caching at application level, if it is necessary for some reason.
Visualization CAF attributes have been moved into a new toolkit TKVCAF. If your application uses the classes from TPrsStd package then add link to TKVCAF library.
Version numbers of BinOCAF and XmlOCAF formats are incremented; new files cannot be read by earlier versions of OCCT.
Before loading the OCAF files saved by previous versions and containing TPrsStd_AISPresentation attribute it is necessary to define the environment variable CSF_MIGRATION_TYPES, pointing to file src/StdResources/MigrationSheet.txt. When using documents loaded from a file, make sure to call method TPrsStd_AISViewer::New() prior to accessing TPrsStd_AISPresentation attributes in this document as that method creates them.
Conversion of gp_Quaternion to and from intrinsic Tait-Bryan angles (including gp_YawPitchRoll) is fixed.
Before that fix the sequence of rotation axes was opposite to the intended; e.g. gp_YawPitchRoll (equivalent to gp_Intrinsic_ZYX) actually defined intrinsic rotations around X, then Y, then Z. Now the rotations are made in the correct order.
The applications that use gp_Quaternion to convert Yaw-Pitch-Roll angles (or other intrinsic Tait-Bryan sequences) may need to be updated to take this change into account.
Zoom persistent selection introduces a new structure Graphic3d_TransformPers to transform persistence methods and parameters and a new class Graphic3d_WorldViewProjState to refer to the camera transformation state. You might need to update your code to deal with the new classes if you were using the related features. Keep in mind the following:
Textured objects now have the priority over the environment mapping.
Redundant enumerations V3d_TypeOfSurface and Graphic3d_TypeOfSurface, class OpenGl_SurfaceDetailState, the corresponding methods from Graphic3d_CView, OpenGl_ShaderManager, OpenGl_View, V3d_View and V3d_Viewer have been deleted. Draw command VSetTextureMode has been deleted.
Presentation tools for building Wireframe presentation have been refactored to eliminate duplicated code and interfaces. Therefore, the following classes have been modified:
This section should be considered if application defines custom presentations, i.e. inherited from AIS_InteractiveObject. The previous versions of OCCT have three levels for defining presentation properties (e.g. colors, materials, etc.):
The structure level has de facto not been used for a long time since OCCT presentations always define aspects at the graphic group level (overriding any structure aspects). Within this OCCT release, structure level of aspects has been completely removed. In most cases the application code should just remove missing methods. In those rare cases, when this functionality was intentionally used, the application should explicitly define aspects to the appropriate graphic groups.
Note that defining several different aspects within the same graphic group should also be avoided in the application code since it is a deprecated functionality which can be removed in further releases. Graphic3d_Group::SetGroupPrimitivesAspect() should be the main method defining presentation attributes.
The implementation of Graphic3d_Group::SetGroupPrimitivesAspect() has been changed from copying aspect values to keeping the passed object. Although it was not documented, previously it was possible to modify a single aspect instance, like Graphic3d_AspectFillArea3d and set it to multiple groups. Now such code would produce an unexpected result and therefore should be updated to create the dedicated aspect instance.
The following type definitions in OCCT has been modified to use C++11 types:
For most applications this change should be transparent on the level of source code. Binary compatibility is not maintained, as bool has a different size in comparison with unsigned int.
Fixed-function pipeline has been already deprecated since OCCT 7.0.0. Release 7.1.0 disables this functionality by default in favor of Programmable Pipeline (based on GLSL programs).
Method V3d_View::Export(), based on gl2ps library, requires fixed pipeline and will return error if used with default settings. Applications should explicitly enable fixed pipeline by setting OpenGl_Caps::ffpEnable flag to TRUE within OpenGl_GraphicDriver::ChangeOptions() before creating the viewer to use V3d_View::Export(). This method is declared as deprecated and will be removed in one of the next OCCT releases. The recommended way to generate a vector image of a 3D model or scene is to use an application-level solution independent from OpenGL.
The behavior of transformation persistence flags Graphic3d_TMF_ZoomPers and Graphic3d_TMF_TriedronPers has been changed for consistency with a textured fixed-size 2D text. An object with these flags is considered as defined in pixel units, and the presentation is no more scaled depending on the view height. The applications that need to scale such objects depending on viewport size should update them manually.
Flags Graphic3d_TMF_PanPers and Graphic3d_TMF_FullPers have been removed. Graphic3d_TMF_TriedronPers or Graphic3d_TMF_2d can be used instead depending on the context.
Graphic3d_TransModeFlags is not an integer bitmask anymore - enumeration values should be specified instead. Several transformation persistence methods in PrsMgr_PresentableObject have been marked deprecated. Transformation persistence should be defined using Graphic3d_TransformPers constructor directly and passed by a handle, not value.
Release 7.1.0 introduces Graphic3d_HighlightStyle - an entity that allows flexible customization of highlighting parameters (such as highlighting method, color, and transparency). Therefore, the signatures of the following methods related to highlighting:
Method AIS_InteractiveContext::Hilight is now deprecated and highlights the interactive object with selection style.
A group of methods AIS_InteractiveContext::IsHilighted has changed its behavior - now they only check highlight flags of the object or the owner in the global status. If the highlight color is required on the application level, it is necessary to use overloaded methods AIS_InteractiveContext::HighlightStyle for the owner and the object.
The following methods have been replaced in AIS_InteractiveContext class:
The API of Prs3d_Drawer has been extended to allow setting up styles for both dynamic selection and highlighting. Therefore, it is possible to change the highlight style of a particular object on the application level via SelectMgr_SelectableObject::HilightAttributes() and process it in the entity owner.
Methods TObj_Model::SaveAs and TObj_Model::Load now receive TCollection_ExtendedString filename arguments instead of char*. UTF-16 encoding can be used to pass file names containing Unicode symbols.
The following environment variables have become redundant:
Other environment variables still can be used to customize behavior of relevant algorithms but are not necessary any more (all required resources are embedded).
The following obsolete features have been removed:
The following classes have been changed:
The following obsolete features have been removed:
In classes BRepTools_ReShape and ShapeBuild_ReShape, the possibility to process shapes different only by orientation in different ways has been removed. Thus methods Remove() and Replace() do not have any more the last argument 'oriented'; they work always as if Standard_False was passed before (default behavior). Methods ModeConsiderLo() and Apply() with three arguments have been removed.
Class BRepOffsetAPI_MakeOffsetShape:
The code below shows new calling procedure:
Class BRepOffsetAPI_MakeThickSolid:
The code below shows new calling procedure:
Management of highlight attributes has been revised and might require modifications from application side:
Most AIS_InteractiveContext methods are defined with a flag to update viewer immediately or not. Within previous version of OCCT, this argument had default value TRUE. While immediate viewer updates are useful for beginners (the result is displayed as soon as possible), this approach is inefficient for batch viewer updates, and having default value as TRUE lead to non-intended accidental updates which are difficult to find.
To avoid such issues, the interface has been modified and default value has been removed. Therefore, old application code should be updated to set the flag theToUpdateViewer explicitly to desired value (TRUE to preserve old previous behavior), if it was not already set.
The following AIS_InteractiveContext methods have been changed: Display, Erase, EraseAll, DisplayAll, EraseSelected, DisplaySelected, ClearPrs, Remove, RemoveAll, Hilight, HilightWithColor, Unhilight, Redisplay, RecomputePrsOnly, Update, SetDisplayMode, UnsetDisplayMode, SetColor, UnsetColor, SetWidth, UnsetWidth, SetMaterial, UnsetMaterial, SetTransparency, UnsetTransparency, SetLocalAttributes, UnsetLocalAttributes, SetPolygonOffsets, SetTrihedronSize, SetPlaneSize, SetPlaneSize, SetDeviationCoefficient, SetDeviationAngle, SetAngleAndDeviation, SetHLRDeviationCoefficient, SetHLRDeviationAngle, SetHLRAngleAndDeviation, SetSelectedAspect, MoveTo, Select, ShiftSelect, SetSelected, UpdateSelected, AddOrRemoveSelected, HilightSelected, UnhilightSelected, ClearSelected, ResetOriginalState, SubIntensityOn, SubIntensityOff, FitSelected, EraseGlobal, ClearGlobal, ClearGlobalPrs.
In addition, the API for immediate viewer update has been removed from V3d_View and Graphic3d_StructureManager classes (enumerations Aspect_TypeOfUpdate and V3d_TypeOfUpdate): V3d::SetUpdateMode(), V3d::UpdateMode(), Graphic3d_StructureManager::SetUpdateMode(), Graphic3d_StructureManager::UpdateMode().
The argument theUpdateMode has been removed from methods Graphic3d_CView::Display(), Erase(), Update(). Method Graphic3d_CView::Update() does not redraw the view and does not re-compute structures anymore.
The following Grid management methods within class V3d_Viewer do not implicitly redraw the viewer: ActivateGrid, DeactivateGrid, SetRectangularGridValues, SetCircularGridValues, RectangularGridGraphicValues, CircularGridGraphicValues, SetPrivilegedPlane, DisplayPrivilegedPlane.
The duplicating interface methods accepting Quantity_NameOfColor (in addition to methods accepting Quantity_Color) of TKV3d toolkit have been removed. In most cases this change should be transparent, however applications implementing such interface methods should also remove them (compiler will automatically highlight this issue for methods marked with Standard_OVERRIDE keyword).
The capability of reading / writing files in old format using Storage_ShapeSchema functionality from OCCT 6.9.1 has been restored in OCCT 7.2.0.
One can use this functionality in two ways:
The code example below demonstrates how to read shapes from a storage driver using StdStorage class.
The following code demonstrates how to write shapes in OCCT 7.2.0 using StdStorage class.
Previously, BRepLib_MakeFace algorithm changed orientation of the source wire in order to avoid creation of face as a hole (i.e. it is impossible to create the entire face as a hole; the hole can be created in context of another face only). New algorithm does not reverse the wire if it is open. Material of the face for the open wire will be located on the left side from the source wire.
From now on, the offset will always be directed to the outer region in case of positive offset value and to the inner region in case of negative offset value. Inner/Outer region for an open wire is defined by the following rule: when we go along the wire (taking into account edges orientation) the outer region will be on the right side, the inner region will be on the left side. In case of a closed wire, the inner region will always be inside the wire (at that, the edges orientation is not taken into account).
Since 7.2.0 version, method IsPeriodic() returns the corresponding status of periodicity of the basis curve regardless of closure status of the adaptor curve (see method IsClosed()). Method IsClosed() for adaptor can return false even on periodic curve, in the case if its parametric range is not full period, e.g. for adaptor on circle in range [0, \( \pi \)]. In previous versions, IsPeriodic() always returned false if IsClosed() returned false.
The history of the changing of the initial shape was corrected:
Class RWStl now uses class Poly_Triangulation for storing triangular mesh instead of StlMesh data classes; the latter have been removed.
The Error/Warning reporting system of the algorithms in Boolean Component (in all BOPAlgo_* and BRepAlgoAPI_* algorithms) has been refactored. The methods returning the status of errors and warnings of the algorithms (ErrorStatus() and WarningStatus()) have been removed. Instead use methods HasErrors() and HasWarnings() to check for presence of errors and warnings, respectively. The full list of errors and warnings, with associated data such as problematic sub-shapes, can be obtained by method GetReport().
The following public methods in the class ShapeUpgrade_UnifySameDomain became protected:
The following public method has been removed:
The methods BuildPCurveForEdgeOnPlane and BuildPCurveForEdgesOnPlane have been moved from the class BOPTools_AlgoTools2D to the more lower level class BRepLib.
The following obsolete features have been removed:
Multiple changes have been applied to lights management within TKV3d and TKOpenGl:
Graphic3d_AspectFillArea3d has been extended by a new property ShadingModel(), which previously has been defined globally for the entire View.
Previously, a triangle array without normal vertex attributes was implicitly considered as unshaded, but now such array will be shaded using Graphic3d_TOSM_FACET model (e.g. by computing per-triangle normals). Therefore, Graphic3d_TOSM_UNLIT should be explicitly specified to disable shading of triangles array. Alternatively, a material without reflectance properties can be used to disable shading (as before).
The following API changes should be considered while porting custom OpenGl_Element objects:
The public method BuildSection() in the class BOPAlgo_Section has become protected. The methods Perform() or PerformWithFiller() should be called for construction of the result of SECTION operation.
The method BRepAdaptor_CompCurve::SetPeriodic has been eliminated. Since the new version, the method BRepAdaptor_CompCurve::IsPeriodic() will always return FALSE. Earlier, it could return TRUE in case if the wire contained only one edge based on a periodic curve.
Previously, the unclassified faces of BOPAlgo_BuilderSolid algorithm (i.e. the faces not used for solids creation and located outside of all created solids) were used to form an additional (not closed) solid with INTERNAL orientation. Since the new version, these unclassified faces are no longer added into the resulting solids. Instead, the warning with a list of these faces appears.
The following public methods of the BOPAlgo_BuilderSolid class have been removed as redundant:
The API classes in the package BRepAlgo providing access to old Boolean operations are marked as deprecated:
Class CDM_MessageDriver and its descendants have been removed; class Message_Messenger is used instead in all OCAF packages. By default, messenger returned by Message::DefaultMessenger() is used, thus all messages generated by OCAF are directed in the common message queue of OCCT.
In classes implementing OCAF persistence for custom attributes (those inheriting from BinMDF_ADriver, XmlMDF_ADriver), uses of method WriteMessage() should be replaced by call to method Send() of the inherited field myMessageDriver. Note that this method takes additional argument indicating the gravity of the message (Trace, Info, Warning, Alarm, or Fail).
Class Message_PrinterOStream can be used instead of CDM_COutMessageDriver to direct all messages to a stream. If custom driver class is used in the application, that class shall be reimplemented inheriting from Message_Printer instead of CDM_MessageDriver. Method Send() should be redefined instead of method Write() of CDM_MessageDriver. To use the custom printer in OCAF, it can be either added to default messenger or set into the custom Message_Messenger object created in the method MessageDriver() of a class inheriting CDF_Application.
Previously the algorithm could create a shape with the same degenerated edge shared between some faces. Now it is prevented. The algorithm creates the different copy of this edge for each face. The method Generated(...) has been changed in order to apply restriction to the input shape: input shape can be only of type VERTEX, EDGE, FACE or SOLID. For input shape of another type the method always returns empty list.
Previously deprecated Local Context functionality has been removed from AIS package, so that related methods have been removed from AIS_InteractiveContext interface: HasOpenedContext(), HighestIndex(), LocalContext(), LocalSelector(), OpenLocalContext(), CloseLocalContext(), IndexOfCurrentLocal(), CloseAllContexts(), ResetOriginalState(), ClearLocalContext(), UseDisplayedObjects(), NotUseDisplayedObjects(), SetShapeDecomposition(), SetTemporaryAttributes(), ActivateStandardMode(), DeactivateStandardMode(), KeepTemporary(), SubIntensityOn(), SubIntensityOff(), ActivatedStandardModes(), IsInLocal(), AddOrRemoveSelected() taking TopoDS_Shape.
A set of deprecated methods previously related to Local Context and now redirecting to other methods has been preserved to simplify porting; they will be removed in next release.
Now methods GeomConvert::ConcatG1, GeomConvert::ConcatC1, Geom2dConvert::ConcatG1, Geom2dConvert::ConcatC1 modify the input argument representing the flag of closedness.
SelectBasics_PickResult structure has been extended, so that it now defines a 3D point on the detected entity in addition to Depth value along picking ray. SelectMgr_SelectingVolumeManager::Overlap() methods have been corrected to fill in SelectBasics_PickResult structure (depth and 3D point) instead of only depth value, so that custom Select3D_SensitiveEntity implementation should be updated accordingly (including Select3D_SensitiveSet subclasses).
Previously Document format version restored by DocumentRetrievalDriver was propagated using static methods of the corresponding units (like MDataStd or MNaming) to static variables of these units and after that became accessible to Drivers of these units. Now Document format version is available to drivers via RelocationTable. The Relocation table now keeps HeaderData of the document and a format version can be extracted in the following way: theRelocTable.GetHeaderData()->StorageVersion(). Obsolete methods: static void SetDocumentVersion (const Standard_Integer DocVersion) and static Standard_Integer DocumentVersion() have been removed from BinMDataStd, BinMNaming, XmlMDataStd and XmlMNaming.
The entire structure of BRepMesh component has been revised and separated into several logically connected classes.
In new version, deflection is controlled more accurately, this may be necessary to tune parameters of call of the BRepMesh algorithm on the application side to obtain the same quality of presentation and/or performance as before.
BRepMesh_FastDiscret and BRepMesh_FastDiscretFace classes have been removed.
The following changes have been introduced in the API of BRepMesh_IncrementalMesh, component entry point:
Example of usage: Case 1 (explicit parameters):
Some public methods of the class BRepFilletAPI_MakeChamfer are released from excess arguments:
Fill Area, Line and Marker aspects (classes Graphic3d_AspectFillArea3d, Graphic3d_AspectLine3d, Graphic3d_AspectMarker3d and Graphic3d_AspectText3d) have been merged into new class Graphic3d_Aspects providing a single state for rendering primitives of any type. The old per-primitive type aspect classes have been preserved as sub-classes of Graphic3d_Aspects with default values close to the previous behavior. All aspects except Graphic3d_AspectFillArea3d define Graphic3d_TOSM_UNLIT shading model.
The previous approach with dedicated aspects per primitive type was handy in simplified case, but lead to confusion otherwise. In fact, drawing points or lines with lighting applied is a valid use case, but only Graphic3d_AspectFillArea3d previously defined necessary material properties.
As aspects for different primitive types have been merged, Graphic3d_Group does no more provide per-type aspect properties. Existing code relying on old behavior and putting interleaved per-type aspects into single Graphic3d_Group should be updated. For example, the following pseudo-code will not work anymore, because all SetGroupPrimitivesAspect calls will setup the same property:
To solve the problem, the code should be modified to either put primitives into dedicated groups (preferred approach), or using SetPrimitivesAspect in proper order:
Decomposition of Ambient, Diffuse, Specular and Emissive properties has been eliminated within Graphic3d_MaterialAspect definition. As result, the following methods of Graphic3d_MaterialAspect class have been removed: SetReflectionMode(), SetReflectionModeOn(), Ambient(), Diffuse(), Emissive(), Specular(), SetAmbient(), SetDiffuse(), SetSpecular(), SetEmissive().
Previously, computation of final value required the following code:
New code looks like this:
Existing code should be updated to:
Parameters of Text in Graphic3d_Group are moved into a new Graphic3d_Text class. AddText of Graphic3d_Group should be used instead of the previous Text.
The previous code:
should be replaced by the new code:
OpenGl_Text contains Graphic3d_Text field.
OpenGl_TextParam struct is removed. Constructor and Init of OpenGl_Text with OpenGl_TextParam are also removed. Instead of using them, change OpenGl_Text.
Please, note, that after modifying OpenGl_Text, Reset of OpenGl_Text should be called.
FormatParams of OpenGl_Text is replaced by Text.
Historically AIS_InteractiveObject provided two independent mechanisms invalidating presentation (asking presentation manager to recompute specific display mode or all modes):
The latter one has been removed to avoid confusion and unexpected behavior. In addition, two methods AIS_InteractiveObject::Update() have been deprecated in favor of new AIS_InteractiveObject::UpdatePresentations() recomputing only invalidated presentations.
Custom presentations implementing interface methods AIS_InteractiveObject::SetColor() and others should be revised to use AIS_InteractiveObject::SetToUpdate() or updating presentation without recomputation (see AIS_InteractiveObject::SynchronizeAspects() and AIS_InteractiveObject::replaceAspects()).
Proxy classes Prs3d_Presentation, PrsMgr_ModedPresentation and PrsMgr_Prs have been removed. Code iterating through the list of low-level structures AIS_InteractiveObject::Presentations() should be updated to access PrsMgr_Presentation directly. Forward declarations of Prs3d_Presentation should be corrected, since it is now a typedef to Graphic3d_Structure.
Proxy classes SelectBasics_SensitiveEntity and SelectBasics_EntityOwner have been removed - Select3D_SensitiveEntity and SelectMgr_EntityOwner should be now used directly instead.
Graphic3d_PolygonOffset default constructor has been corrected to define Units=1 instead of Units=0. Default polygon offset settings Mode=Aspect_POM_Fill + Factor=1 + Units=1 are intended to push triangulation (Shaded presentation) a little bit behind of lines (Wireframe and Face Edges) for reducing z-fighting effect of Shaded+Wireframe combination. The change in defaults (Units changed from 0 to 1) is intended to cover scenario when camera direction is perpendicular to model plane (like 2D view).
Application observing unexpected visual difference on this change should consider customizing this property within AIS_InteractiveContext default attributes or on per-presentation basis via Graphic3d_Aspects::SetPolygonOffset() methods.
Interface of insertion ZLayer in the viewer has been improved with ability to insert new layer before or after existing one. Previously undocumented behavior of V3d_Viewer::AddZlayer() method has been corrected to insert new layer before Graphic3d_ZLayerId_Top. Applications might need revising their custom layers creation code and specify precisely their order with new methods V3d_Viewer::InsertLayerBefore() and V3d_Viewer::InsertLayerAfter().
Applications using integer values of the following enumerations in persistence should be corrected as these enumerations have been modified:
Name |
---|
AIS_TypeOfAttribute |
Aspect_InteriorStyle |
Font_FontAspect |
env.bat produced by Visual Studio project generator genproj.bat has been modified so that CSF_DEFINES% variable is reset to initial state. Custom building environment relying on old behavior and setting extra macros within CSF_DEFINES% before env.bat should be updated to either modify custom.bat or setup new variable CSF_DEFINES_EXTRA% instead.
Since OCCT 7.4.0 Boolean Operations algorithm uses BVH tree instead of UBTree to find the pairs of entities with interfering bounding boxes. The following API changes have been made:
Standard_Stream.hxx header, commonly included by other OCCT header files, does no more add entities from std namespace related to streams (like std::cout, std::istream and others) into global namespace. The application code relying on this matter should be updated to either specify std namespace explicitly (like std::cout) or add "using std::" statements locally.
OCCT 3D Viewer has been improved to properly perform lighting using in linear RGB color space and then convert result into non-linear gamma-shifted sRGB color space before displaying on display. This change affects texture mapping, material definition and color definition.
Previously Quantity_Color definition was provided with unspecified RGB color space. In practice, mixed color spaces have been actually used, with non-linear sRGB prevailing in general. Since OCCT 7.5.0, Quantity_Color now specifies that components are defined in linear RGB color space.
This change affects following parts:
Unexpected const-ness of Aspect_Window::DoResize() method has been removed, so that application classes implementing this interface should be updated accordingly.
Enumeration BRepOffset_Type is renamed to ChFiDS_TypeOfConcavity.
Now by default offset faces of non-planar faces may be planar faces if their originals can be approximated by planes.
The following changes could be highlighted while porting:
Properties Prs3d_Drawer::HLRAngle() and Prs3d_Drawer::HLRDeviationCoefficient() have been removed from classes Prs3d_Drawer, AIS_Shape and AIS_InteractiveContext. Prs3d_Drawer::DeviationAngle() should be now used instead of Prs3d_Drawer::HLRAngle() and Prs3d_Drawer::DeviationCoefficient() instead of Prs3d_Drawer::HLRDeviationCoefficient(). The default value of Prs3d_Drawer::DeviationAngle() property has been changed from 12 to 20 degrees to match removed Prs3d_Drawer::HLRAngle(), previously used as input for triangulation algorithm.
Methods computing HLR presentation within PrsMgr_PresentableObject::Compute() have been renamed to PrsMgr_PresentableObject::computeHLR() and now accept Graphic3d_Camera object instead of removed Prs3d_Projector.
Presentation classes displaying Dimensions and Relations have been moved from AIS package to PrsDim. Corresponding classes should be renamed in application code (like AIS_LengthDimension -> PrsDim_LengthDimension).
The method Select3D_SensitiveEntity::NbSubElements() has been changed to be constant. Select3D_SensitiveEntity subclasses at application level should be updated accordingly.
Offset direction, which used in class Adaptor2d_OffsetCurve for evaluating values and derivatives of offset curve is unified for offset direction used in class Geom2d_OffsetCurve: now offset direction points to outer ("right") side of base curve instead of the previously used inner ("left") side. Old usage of class in any application should be changed something like that:
Adaptor2d_OffsetCurve aOC(BaseCurve, Offset) –> Adaptor2d_OffsetCurve aOC(BaseCurve, -Offset)
The progress indication mechanism has been revised to eliminate its weak points in previous design (leading to implementation mistakes). Redesign also allows using progress indicator in multi-threaded algorithms in more straight-forward way with minimal overhead. Note however, that multi-threaded algorithm should pre-allocate per-task progress ranges in advance to ensure thread-safety - see examples in documentation of class Message_ProgressScope for details.
Classes Message_ProgressSentry and Message_ProgressScale have been removed. New classes Message_ProgressScope and Message_ProgressRange should be used as main API classes to organize progress indication in the algorithms. Instances of the class Message_ProgressRange are used to pass the progress capability to nested levels of the algorithm, and an instance of the class Message_ProgressScope is to be created (preferably as local variable) to manage progress at each level of the algorithm. The instance of Message_ProgressIndicator is not passed anymore to sub-algorithms. See documentation of the class Message_ProgressScope for more details and examples.
Methods to deal with progress scopes and to advance progress are removed from class Message_ProgressIndicator; now it only provides interface to the application-level progress indicator. Virtual method Message_ProgressIndicator::Show() has changed its signature and should be updated accordingly in descendants of Message_ProgressIndicator. The scope passed as argument to this method can be used to obtain information on context of the current process (instead of calling method GetScope() in previous implementation). Methods Show(), UserBreak(), and Reset() are made protected in class Message_ProgressIndicator; methods More() or UserBreak() of classes Message_ProgressScope or Message_ProgressRange should be used to know if the cancel event has come. See documentation of the class Message_ProgressIndicator for more details and implementation of Draw_ProgressIndicator for an example.
Let's take a look onto typical algorithm using an old API:
The following guidance can be used to update such code:
const Handle(Message_ProgressIndicator)&
with const Message_ProgressRange&
in arguments of the methods that support progress indication. Message_ProgressIndicator object should be now created only at place where application starts algorithms.Message_ProgressSentry
with Message_ProgressScope
. Take note that Message_ProgressScope has less arguments (no "minimal value"). In other aspects, Message_ProgressScope mimics an iterator-style interface (with methods More() and Next()) close to the old Message_ProgressSentry (pay attention to extra functionality of Message_ProgressScope::Next() method below). Note that method Message_ProgressScope::Close() is equivalent of the method Relieve() of Message_ProgressSentry in previous version. Class Message_ProgressSentry is still defined (marked as deprecated) providing API more close to old one, and can be still used to reduce porting efforts.Take a look onto ported code and compare with code above to see differences:
Operators << with left argument Handle(Message_Messenger), used to output messages with a stream-like interface, have been removed. This functionality is provided now by separate class Message_Messenger::StreamBuffer. That class contains a stringstream buffer which can be filled using standard stream operators. The string is sent to a messenger on destruction of the buffer object, call of its method Flush(), or using operator << with one of ostream manipulators (std::endl, std::flush, std::ends). Manipulator Message_EndLine has been removed, std::endl should be used instead.
New methods SendFail(), SendAlarm(), SendWarning(), SendInfo(), and SendTrace() are provided in both Message_Messenger class and as static functions in Message package (short-cuts to default messenger), returning buffer object for the output of corresponding type of the message.
The code that used operator << for messenger, should be ported as follows.
Before the change:
After the change, single-line variant:
After the change, extended variant:
Previously, sub-classes of Message_Printer have to provide a triplet of Message_Printer::Send() methods accepting different string representations: TCollection_AsciiString, TCollection_ExtendedString and Standard_CString. Message_Printer interface has been changed, so that sub-classes now have to implement only single method Message_Printer::send() accepting TCollection_AsciiString argument and having no Endl flag, which has been removed. Old three Message_Printer::Send() methods remain defined virtual with unused last argument and redirecting to new send() method by default.
Redundant class Prs3d_Root has been marked as deprecated - Prs3d_Presentation::NewGroup() should be called directly.
Class CDF_Session has been removed. That class was used to store global instance of OCAF application (object of class CDM_Application or descendant, typically TDataStd_Application). Global directory of all opened OCAF documents has been removed as well; such directory is maintained now by each instance of the CDM_Application class.
This allows creating programs that work with different OCAF documents concurrently in parallel threads, provided that each thread deals with its own instance of TDataStd_Application and documents managed by this instance.
Note that neither TDataStd_Application nor TDocStd_Document is protected from concurrent access from several threads. Such protection, if necessary, shall be implemented on the application level. For an example, access to labels and attributes could be protected by mutex if there is a probability that different threads access the same labels / attributes:
Draw Harness hotkeys W (Wireframe) and S (Shaded) have been re-mapped to Ctrl+W and Ctrl+S. Hotkey A has been remapped to Backspace. Hotkeys WASD and Arrays are now mapped for walk-through navigation in 3D Viewer.
Message files (with extension .msg) are now expected to be in UTF-8 encoding (unless they have UTF-16 BOM in which case UTF-16 is expected). This allows using arbitrary Unicode symbols for localization of messages.
Existing message files containing 8-bit characters (previously interpreted as characters from Latin-1 code block) should be converted to UTF-8.
Interfaces Adaptor2d_Curve2d, Adaptor3d_Curve and Adaptor3d_Surface now inherit Standard_Transient and can be Handle-managed. No more necessary parallel hiererchy of classes Adaptor2d_HCurve2d, Adaptor3d_HCurve and Adaptor3d_HSurface (generated from generic templates by WOK) has been eliminated. Existing code using old Handle classes should be updated to:
Behavior of the method TCollection_ExtendedString::Print(Standard_OStream&) and corresponding operator << has changed. Previously it printed all Latin-1 symbols (those in range 0x80-0xff) as '\0' (effectively losing them); symbols above 0xff were converted to hex representation (formatted like XML Numeric Character Reference). Now all symbols are sent to stream as UTF-8 byte sequences. Existing code relying on old behavior, if any, shall be rewritten.
Geom_RectangularTrimmedSurface sequentially trimming in U and V directions already no longer loses the first trim. For example:
gives different result. In current version ST1 - surface trimmed only along V, U trim is removed; After modification ST1 - surface trimmed along U and V, U trim is kept.
The methods XmlLDrivers::StorageVersion() and BinLDrivers::StorageVersion() were removed. Since now TDocStd_Document manipulates the storage format version of a document for both XML and binary file formats. For this the methods StorageFormatVersion() and ChangeStorageFormatVersion() were moved from CDM_Document to TDocStd_Document. The methods are used to get and set the storage format version of a document. A new enumeration TDocStd_FormatVersion lists the storage format versions of a document. By default, the document uses the latest (current) storage format version. In order to save a document in an older storage format version, call the method ChangeStorageFormatVersion() with one of the values from the enumeration. This value will be used by storage drivers of a corresponding OCAF file format (XML or binary) and the document will be saved following the rules of the specified storage format version (corresponding to an older version of Open CASCADE Technology). This way an application based on an old version of Open CASCADE Technology may read documents saved by new applications (based on newer version of Open CASCADE Technology).
A new OCAF document may be created only by means of the method NewDocument() from CDF_Application (redefined in TDocStd_Application). The methods CreateDocument() are deleted in all retrieval drivers.
Information about per-vertex triangulations normals is now stored in BinOCAF and XmlOCAF document, BRep and Binary BRep Shape formats (only in case of triangulation-only Faces, with no analytical geometry to restore normals).
Versions of formats have been changed (11 for BinOCAF, 10 for XmlOCAF, 4 for BRep Shape and 3 for Binary BRep Shape). Files written with the new version will not be readable by applications of old versions.
All kinds of binary document formats since the new version 12 saved with support of partial reading (sub-set of labels and sub-set of attributes). For that the shapes data structures are stored with the related NamedShape attributes in the file, not in the particular section in the start of the document. Also, size allocated for each label is stored in the file. This allows to skip big parts of document in partial reading mode if needed.
As a result, the new binary files become some smaller, but default reading and writing of documents may take some more time (depenging on the environment), up to 15 percents slower in the worse cases. Backward compatibility (loading of old documents in the newer version) is still fully supported, as well as writing the older versions of the document.
Poly_Triangulation does no more provide access to internal array structures: methods Nodes(), ChangeNode(), Triangles(), ChangeTriangle(), UVNodes(), ChangeUVNode(), Normals() have been removed. Methods of Poly_Triangulation for accessing individual nodal properties / triangles by index and implementing copy semantics should be used instead. The same is applicable to Poly_PolygonOnTriangulation interface.
Accessors to standard materials have been modified within Declarations.glsl (occFrontMaterial_Diffuse() -> occMaterial_Diffuse(bool) and similar). Applications defining custom GLSL programs should take into account syntax changes.
Nodal color vertex attribute is now modulated in the same way as a color texture - color is multiplied by material coefficients (diffuse/ambient/specular in case of a common material definition). Existing code defining nodal colors should be updated to:
OCCT now provides two separate toolkits - TKOpenGl depending on desktop OpenGL and TKOpenGles depending on OpenGL ES. Both libraries can be now built simultaneously on systems providing both APIs (like desktop Linux).
Existing applications depending on OpenGL ES (mobile projects first of all) should be adjusted to link against TKOpenGles. Note that both TKOpenGl and TKOpenGles keep exporting classes with the same name, so applications should not attempt to link both libraries simultaneously.
Access to an OCAF label via its entry is accelerated. In order to activate it, call TDF_Data::SetAccessByEntries(). The method TDF_Tool::Label(), which returns a label by an entry, becomes faster for about 10 .. 20 times. It has sense for applications, which use an entry as a unique key to access the data in OCAF tree. Also, the method TDF_Tool::Entry(), which returns an entry for a label, is accelerated as well.
Method SetProgressIndicator() has been removed due to Progress indicator mechanism refactoring. To enable progress indicator and user break in Boolean operations user has to pass progress range as a parameter to Perform or Build method. For example:
Now the classes accept adaptors instead objects as input parameters. BRepLib_CheckCurveOnSurface does no more provide access to curves, surface and parameters: methods PCurve(), PCurve2(), Surface() and Range() have been removed. BRepLib_CheckCurveOnSurface: the default value of the isMultiThread parameter of the Perform() function has been changed from true to false GeomLib_CheckCurveOnSurface does no more provide access to curve, surface and parameters: methods Curve(), Surface() and Range() have been removed. GeomLib_CheckCurveOnSurface: the default value of the isMultiThread parameter of the Perform() function has been changed from true to false
The following functions in GeomLib_CheckCurveOnSurface have been modified:
Building OCCT now requires C++11-compliant compiler, so that some legacy compilers (Visual Studio 2010 and 2012) are no more supported. It is recommended using Visual Studio 2015 or newer for building OCCT on Windows platform.
theIsParallel parameter has been removed from Put/Compute/Perform from the next classes:
Now, to set this flag, it is necessary to use method SetParallel() For example:
Prs3d_Drawer
getters no more implicitly create "default" aspects. If specific property has not been set before to this drawer instance nor to linked drawer instance, then NULL property will be returned. Make sure to set property beforehand or to call SetOwn*
/ SetupOwn*
methods to derive from defaults.
Applications extending OCCT 3D Viewer and calling OpenGL functions directly (like ::glEnable()
, e.g. using global namespace) might be affected by changes in OpenGl_GlFunctions.hxx
. This header, as well as OpenGl_GlCore20.hxx
and similar, no more include system OpenGL / OpenGL ES headers to define function table. Application code calling OpenGL functions directly should be changed to either use OpenGl_Context::core11fwd
(as designed) or to include system OpenGL headers in advance (with help of OpenGl_GlNative.hxx
).
Method StdPrs_ToolTriangulatedShape::Normal()
has been removed. Please use BRepLib_ToolTriangulatedShape::ComputeNormals()
to fill in normal attributes in triangulation and fetch them directly using Poly_Triangulation::Normal()
.
A new way of using the BRepExtrema_ShapeProximity
class was provided for computing a proximity value between two shapes. If at initialization of the BRepExtrema_ShapeProximity
class the theTolerance parameter is not defined (Precision::Infinite() by default), the proximity value will be computed.