Open Inventor 10.10 最新版Crack

古城微笑少年丶 2022-09-13 05:19 263阅读 0赞

What's New  
VolumeViz  
Height field rendering improvement  
GPU memory optimization when loading uniform tiles  
SoOrthoSliceDragger automatic highlight  
New optional border for SoOrthoSlice  
Screen resolution culling，Ω**578867473**  
Incompatible changes in the .NET API  
Core  
New capability for efficient rendering of point set  
Ambient Occlusion on surfaces  
Rendering performance improvement  
Viewer Components  
Change in interactive mode  
SceneOrbiter Turntable rotation  
New QML render area (C++)  
SoViewingCube enhancements  
Incompatible api change in the SoViewingCube  
Compatibility and Dependency changes  
RemoteViz  
New npm package  
ImageViz  
New engines in .NET API  
Incompatible changes in the .NET API  
MeshViz XLM  
Outline performance improvement (C++)  
New predefined colormap (C++ & Java)  
Platforms update  
New platform Ubuntu 20.04  
Installers and packages renamed  
Licensing  
VolumeViz

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAam9obl9kd2g_size_20_color_FFFFFF_t_70_g_se_x_16][]

Height field rendering improvement  
Since Open Inventor 10.10, there is no more limitation in the height field rendering about different dataset dimensions, or tile sizes within a SoMultiDataSeparator. This means it is now possible to render a height field even if the SoHeightFieldGeometry(C++|Java|.Net) instance and the SoHeightFieldProperty(C++|Java|.Net) instance do not have the same dimensions and tile size.

It is also possible to render a height field by coloring its surface according to the 3D volume properties defined by one or more SoVolumeData(C++|Java|.Net). The interpolation of the 3D volume property on the horizon geometry is performed on-the-fly by the GPU. No new api has been added, but instances of SoHeightFieldGeometry(C++|Java|.Net) and SoVolumeData(C++|Java|.Net) must be within the same SoMultiDataSeparator(C++|Java|.Net).

For details, please refer to the "Composition with VolumeData" paragraph of SoHeightfieldRender(C++|Java|.Net)'s documentation.

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAam9obl9kd2g_size_20_color_FFFFFF_t_70_g_se_x_16 1][]

To illustrate this feature a new example, named horizonInVolume, has been added:

For C++ in $OIVHOME/examples/source/VolumeViz/horizonInVolume  
For .NET in $OIVNETHOME/examples/source/VolumeViz/HorizonInVolume  
For Java in $OIVJHOME/examples/volumeviz/sample/horizonInVolume  
This new example highlights that it is possible to dynamically displace the horizon and instantaneously see the horizon property updated from the 3D volume, thanks to a complete GPU implementation.

The following image coming from this new example shows how the surface is rendered when it is partially inside the volume data.

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAam9obl9kd2g_size_20_color_FFFFFF_t_70_g_se_x_16 2][]

GPU memory optimization when loading uniform tiles  
It is common for volume data to contain significant regions where data is uniform, for example with undefined regions. To avoid wasting memory (by storing the same value over and over) VolumeViz provides an optimization allowing to store only a single value per tile but, until now, this optimization only helped with CPU memory.

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAam9obl9kd2g_size_20_color_FFFFFF_t_70_g_se_x_16 3][]

Open Inventor 10.10 lifts this limitation as now uniform tiles can also be represented with a single value in GPU memory.

Such optimization allows applications to load, with the same amount of memory, more data than before when a given dataset contains a high percentage of uniform tiles. In the same way, an application which limits the amount of loaded tiles will use less GPU memory with Open Inventor 10.10.

There are several possible benefits:

Using the same amount of GPU memory compared to previous versions, the acccuracy of the volume rendering is improved because many more non-uniform tiles can be used by the GPU to render the data. Actually for large datasets containing a high percentage of uniform tiles, the acccuracy of the rendering can be increased quite significantly  
The amount of GPU memory is much less if you limit the number of tiles used to render  
Compared to the previous version, larger volume datasets can be loaded using the same resolution and the same amount of memory

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAam9obl9kd2g_size_20_color_FFFFFF_t_70_g_se_x_16 4][]

In order to benefit from these improvements, the application must either:

Provide a volume reader inherited from SoVolumeReader(C++|Java|.Net) which returns an object of type SoCpuBufferUniform(C++|Java|.Net) for each tile containing a single value. Additionally, the getTileMinMax method must also return identical min and max values.  
Use an LDM file where the min and max tile values are equal when a tile is uniform  
The animation below illustrates the benefit of this optimization, with an arbitrary volume entirely composed of uniform tiles (each tile is composed of one random value). The volume on the left is rendered using Open Inventor 10.9 while the one on the right uses Open Inventor 10.10. (smaller tiles means higher resolution)

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAam9obl9kd2g_size_20_color_FFFFFF_t_70_g_se_x_16 5][]

When allowed GPU memory is decreased from 5 to 4 MB, both volumes are unloaded and reloaded according to this new amount of memory available. The loading with Open Inventor 10.9 quickly stops because the limit of 4MB is reached very fast, even if tiles are all uniforms.

With Open Inventor 10.10, because of uniform tiles management, we are able to reach the full resolution despite the drastic GPU memory limitation.  
SoOrthoSliceDragger automatic highlight  
Following the improvements done on the SoTabBoxDragger, in Open Inventor 10.8, the interaction with an SoOrthoSliceDragger(C++|Java|.Net) has also been improved with a dynamically highlighted border when the mouse cursor moves over the slice.

Two new fields have been added to the class SoOrthoSliceDragger(C++|Java|.Net): : enableHighlight and highlightColor. The first one is an SoSFBool(C++|Java|.Net), allowing to turn on or off the feature (activated by default). The second one, an SoSFColor(C++|Java|.Net), , is useful for customizing the color of the highlighted border. The default color is Yelow (R=1, G=1, B=0).

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAam9obl9kd2g_size_20_color_FFFFFF_t_70_g_se_x_16 6][]

New optional border for SoOrthoSlice  
The class SoOrthoSlice(C++ | Java | .Net ) has been extended to optionnaly render a border line at the boundary of the slice.

A new field enableImage allows also to enable (true) or disable (false) the rendering of slice's image. If set to false, only the slice's border will be rendered. Actually the SoOrthoSlice(C++ | Java | .Net ) provides now the same features as the OrthoSliceBorder which one becomes obsolete.

When the SoOrthoSlice(C++ | Java | .Net ) is associated with an SoOrthoSliceDragger(C++|Java|.Net) it also benefits from its new highlighting capability which leads to a change of color of the border when one interacts with the slice.

4 new fields have been added to the class SoOrthoSlice: borderColor, borderWidth, enableBorder and enableImage. enableBorder is equivalent to OrthoSliceBorder::border and enableImage is equivalent to OrthoSliceBorder::renderSlice.

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAam9obl9kd2g_size_20_color_FFFFFF_t_70_g_se_x_16 7][]

Screen resolution culling  
Until now, the screen resolution culling policy was only defined globally for all SoDataSet(C++|Java|.Net) through the SoLDMGlobalResourceParameters(C++|Java|.Net)::setScreenResolutionCulling API.

This policy allows to load only tiles for which the projection of a voxel is greater than or equal to 1 pixel on screen.

Incompatible changes in the .NET API  
Obsolete GetValue method of SoSFLDMDataTransform(.Net), SoSFLDMResourceParameters(.Net) and SoSFImageDataAdapter(.Net) have been removed. In your application you must use the public property Value instead like shown in following example

SoLDMDataTransform myDataTransform = myDataSet.dataTransform.GetValue();

must be replaced by

SoLDMDataTransform myDataTransform = myDataSet.dataTransform.Value();

New capability for efficient rendering of point set  
Thanks to the use of the well known "point sprite", it is now easily possible to customize the rendering of small textures at each point of the set.  
Point Sprites are, as explained in the OpenGL programming guide, essentially points rendered using a fragment shader that takes the fragment's coordinates within the point into account when running.

The coordinate within the point is available in the two-dimensional vector gl\_PointCoord. This variable can be used in any number of ways. Two common uses are to use it as a texture coordinate (this is the classic origin of the term point sprite), or to use it to analytically compute color or coverage.

Programmable point size: Until previous versions the size in pixels of points could only be set using the pointSize field of the class SoDrawStyle(C++|Java|.Net). Thanks to this feature the size of points can now be changed inside a vertex shader by writing to the gl\_PointSize output variable.

A new example pointcloud is provided for each API and can be found in following locations:  
\- C++: $OIVHOME/examples/source/Inventor/Features/PointCloud  
\- .NET: $OIVNETHOME/examples/source/Inventor/PointCloud  
\- Java: $OIVJHOME/examples/inventor/advanced/pointcloud

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAam9obl9kd2g_size_20_color_FFFFFF_t_70_g_se_x_16 8][]

Ambient Occlusion on surfaces  
Ambient Occlusion (HBAO+) is now available to any surface shapes (SoIndexedFaceSet(C++|Java|.Net) etc.).

Two fields have been added to the SoEnvironment(C++|Java|.Net)

ambientOcclusionIntensity : controls the ambient occlusion intensity. In a nutshell, the higher the value is the darker the scene will be. Default value is 1.0  
ambientOcclusionRadius : controls the radius, in world space, of the sphere in which the ambient occlusion effect is applied. Default value is 4.0  
Each field is global to the scene, meaning, modifications done to one of them is automatically applied to the same field of any instance of SoEnvironment(C++|Java|.Net) node in the scene graph.

You will find opposite an simple illustration showing how Ambient Occlusion helps to sublimate details in a scene and add realism to the lighting (Parameters set to default with intensity set to 4 and radius to 1.0).

To learn more about Ambient Occlusion see Wikipedia: Ambient Occlusion (external resources)

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAam9obl9kd2g_size_20_color_FFFFFF_t_70_g_se_x_16 9][]

Rendering performance improvement  
Rendering performance improvement (FPS) on large shapes (containing millions of triangles).  
An example of improvement of the frame rate on an RTX5000 graphic board:

cad model containing several million triangles | 10.9 : 70fps | 10.10 : 140fps  
Viewer Components  
Change in interactive mode  
Starting with Open Inventor 10.10, the interactive mode is automatically managed by SceneExaminer(C++|Java|.Net) and SceneOrbiter(C++|Java|.Net) classes.  
Interactive mode is turned on as soon as the camera is moving and turned off after 0.5 seconds without any movement detected, even if no mouse release event occurs.

This new behavior only applies on scene graph containing a node that handles the SoInteractionElement(C++|Java|.Net) such as the SoInteractiveSwitch(C++|Java|.Net).

As the new behaviour is now managed by the SceneExaminer(C++|Java|.Net) and SceneOrbiter(C++|Java|.Net) classes, getInteractiveMode() and setInteractiveMode() become deprecated in RenderAreaInteractive, SoRenderAreaCore and SiRenderAreaInteractive classes.

Automatic interactive mode of the SoSceneManager embeded in the RenderAreaCore is also disabled when using any RenderAreaExaminer or RenderAreaOrbiter, except for RemoteViz RenderArea for which it remains enabled.

SceneOrbiter Turntable rotation  
Starting with Open Inventor 10.10 it is now possible to manipulate a scene, inside a SceneOrbiter(C++|Java|.Net), using the well known Turntable rotation.

In this mode it is not possible to see the model from arbitrary angles. In fact, the model's vertical axis is always pointing up and down on the screen.

In animation below the left model is manipulated using the Turntable rotation mode allowing to keep its vertical axis (in red) parallel to the screen's vertical border for more convenient manipulation.  
      
Turntable Rotation    Trackball Rotation  
Although it may feel like a constraint, it is quite convenient for some 3D scenes, where the model has an associated real-world axis for example, as it prevents from unwanted rotations. The level of constraint can be defined by calling SceneOrbiter(C++|Java|.Net)::setConstraintLevel to better control rotations in case of fast mouse drag motions.

The Turntable rotation is now the default mode for the SceneOrbiter(C++|Java|.Net). It can be changed using the SceneOrbiter(C++|Java|.Net)::setRotationMethod() with the appropriate enum Value (TURNTABLE or TRACKBALL).

In the same way, the scene's vertical axis can be specified using the new SceneOrbiter(C++|Java|.Net)::setUpAxis() function with one of the value from openinventor::inventor::Axis (X|Y|Z).

If used in the SceneOrbiter(C++|Java|.Net), the SoViewingCube will aligned its up axis with the selected one.  
New QML render area (C++)  
The class RenderAreaOrbiter(C++) is now available for the QML widgets. It provides the same features and behaviours as the RenderAreaOrbiter for QT widgets. The include path folder is in <OIVHOME>/include/Inventor/ViewerComponents/Qt/QML.

This new class is embeded in the lib fei\_inventor\_QtViewerComponents and is located in the namespace openinventor::inventor::viewercomponents::qt::qml. We use namespace to avoid a name conflict with the render area for Qt widget in the library. The source code of this new class is delivered in <OIVHOME>/source/Inventor/ViewerComponents/Qt/QML. A new class QtHelper is also added with 2 useful methods addPlatformPluginsPath and qtPluginsPath.

We provide a new example QMLRenderAreaOrbiter in <OIVHOME>/examples/source/Inventor/ViewerComponents/Qt/QML.

SoViewingCube(C++|Java|.Net) enhancements  
Two new features have been added to the SoViewingCube(C++|Java|.Net):  
It is now possible to manage an animation to make the viewing cube fading while the mouse cursor moves away from it. This animation is managed by two new fields: SoViewingCube(C++|Java|.Net)::opacityMin and SoViewingCube(C++|Java|.Net)::opacityMax. They define the level of opacity you want when mouse cursor is far from the SoViewingCube (opacityMin) and when it is right above it (opacityMax)  
You can also add a compass inside the SoViewingCube(C++|Java|.Net) that will be shown when the mouse cursor is far from it. Using the newly added field SoViewingCube(C++|Java|.Net)::compass (SoSFNode) you can programatically attach a SoNode to this field so the compass will be attached to the SoViewingCube(C++|Java|.Net). Two examples of simple compasses are provided in $OIVHOME/examples/data/Inventor/Compass  
Animation below shows the result of both features activated on the SoViewingCube(C++|Java|.Net) with opacityMin set to 0.2 and opacityMax set to 1.0. The compass shown is compassNorthSouth.iv

Incompatible api changes in the SoViewingCube(C++|Java|.Net)  
With the SceneOrbiter now using the up axis, the enum Axis (X/Y/Z) has been moved to a specific location depending on the API:

In C++, the Axis type enum is defined in the include file InventorAxis.h in a namespace openinventor.inventor.  
In .NET, the Axis enum is defined in the namespace OIV.Inventor.  
In Java, the Axis enum is defined in the package com.openinventor.inventor.  
Compatibility and Dependency changes  
Compatibility change: the class QEventToSoEvent(C++) is now deprecated and should be replaced by the class QtEventToSoEvent(C++).

Dependency change: The viewer component libraries have been designed to be independent of the historical viewer classes and libraries. However, the Qt viewer component library was abnormally linked with the library fei\_inventor\_ui\_qt. We have fixed that and now the lib fei\_inventor\_QtViewerComponents is no longer dependant on this library. However, the library fei\_inventor\_QtViewerComponents is now linked with several Qt5Qml\* and Qt5Quick\* dll.

New npm package  
Over the past few years, npm has become an essential tool in javascript developers' workflow and is now a very convenient way to install packages and manage their dependencies automatically.  
For these reasons the RemoteViz Client of Open Inventor is now also available as npm package and all needed informations can be found on this page.  
Note that Open Inventor 10.10 installers are still containing JavaScript and TypeScript files of RemoteViz Client

New engines in .NET API  
The following engines classes have been added to the .NET API

SoPolylineExtrusionApproximation3d(C++|.Net)  
SoPolylineResamplerApproximation2d(C++|.Net)  
SoPolylineResamplerApproximation3d(C++|.Net)  
SoQuadrilateralMeshSlicerApproximation3d(C++|.Net)  
SoSurfaceFittingApproximation3d(C++|.Net)  
SoSurfaceUnfoldingProcessing3d(C++|.Net)  
The SoSFStructuredQuadrilateralMesh is also a new field class used in the new engine classes SoSurfaceUnfoldingProcessing3d(C++|.Net), SoQuadrilateralMeshSlicerApproximation3d as an input, in the class SoPolylineExtrusionApproximation3d(C++|.Net) as an output and in the class SoSurfaceFittingApproximation3d(C++|.Net) as an input and output.  
All these classes are already available in the C++ API.

Incompatible changes in the .NET API  
The obsolete public method GetValue in the class SoSFImageDataAdapter(.Net) has been removed. The Value public property must be used as a replacement. Even if an inherited method GetValue() still exists, using the Value property is more convenient.

Outline performance improvement  
Based on a new optimized algorithm, the computation of MoMeshOutline(C++ | Java)) in Open Inventor 10.10 is from 8 to 10 times faster than Open Inventor 10.9 for structured reservoir grids  
(MiVolumeMeshHexahedronIjk(C++ | Java) and MiVolumeMeshVertexHexahedronIjk(C++ | Java)).

Note: Because of this new algorithm it is possible, in some cases (mainly when there are dead cells inside the mesh), to detect insignificant differences in extracted outline compared to Open Inventor 10.9. In any case, the output is still a list of external edges of the grid representing a kind of skeleton.

New predefined colormap (C++|Java)  
A new RAINBOW\_TURBO colormap has been added to the list of predefined colormaps supported. It is very suitable to render reservoir models in the O&G domain. The new constant RAINBOW\_TURBO value has been added in the enumeration PredefColorMapping of the class MoPredefinedColorMapping(C++|Java).

New platform Ubuntu 20.04  
Open Inventor 10.10 C++ and Java are now available on Ubuntu 20.04. All C++ codes are built using gcc9 compiler on this new supported platform.

Installers and packages renamed  
For the sake of consistency all OpenInventor 10.10 packages (zip and exe) have been renamed. The following rule is now used:  
OpenInventor\[C++/Java/.NET\]\[VersionNumber\]-\[headless\]-\[System\]-\[Compiler\]-\[Arch\]

The \[compiler\] is not used for the Java versions. See the download pages for details.

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAam9obl9kd2g_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/b8c8baa93483402dac197000698a57ac.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAam9obl9kd2g_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/faae64ab5fc3481288b79440c75b55f1.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAam9obl9kd2g_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220828/e23a465ba3a44f30bdee7945b73c26e1.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAam9obl9kd2g_size_20_color_FFFFFF_t_70_g_se_x_16 3]: /images/20220828/6eb1c5286d18442186f4a5bc3c16dd1c.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAam9obl9kd2g_size_20_color_FFFFFF_t_70_g_se_x_16 4]: /images/20220828/45989f04906d448e9dc495ed303d7cf5.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAam9obl9kd2g_size_20_color_FFFFFF_t_70_g_se_x_16 5]: /images/20220828/dd28b28d77224f8c893b252edbe67ae2.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAam9obl9kd2g_size_20_color_FFFFFF_t_70_g_se_x_16 6]: /images/20220828/238b1802eceb45dba6b1a745240247b4.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAam9obl9kd2g_size_20_color_FFFFFF_t_70_g_se_x_16 7]: /images/20220828/6a8547e1705048c3b6853145c3c195ac.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAam9obl9kd2g_size_20_color_FFFFFF_t_70_g_se_x_16 8]: /images/20220828/f069fd9a02964acc8edabe22a0ee0206.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAam9obl9kd2g_size_20_color_FFFFFF_t_70_g_se_x_16 9]: /images/20220828/61cde7c4d7d447b6a9b560a759f55037.png