|
Open Inventor Release 2024.1.3
|
|
| |
|
Open Inventor Release 2024.1.3
|
|
|
| |
Minor version published in March 2024.
Enhancements and new features included in this version:
Other changes:
Open Inventor 2024.1 includes all fixes available in Open Inventor 2023.2
In previous versions of Open Inventor, many hangs could be observed when interacting with an ortho slice or an oblique slice with large volume data (i.e. at least several gigabytes). Any change that needed to update a large part of the slice to render potentially led to hangs. These use cases provide a non-exhaustive list of circumstances where hangs could easily occur:
Such use cases have been improved, creating a much better interactivity and user experience.
In this context, the default value of SoLDMResourceParameters::tex2LoadRate has been decreased from 640 to 100. The higher the tex2LoadRate, the higher the probability of observing hangs. Reducing the value of text2LoadRate reduces the risk of a hang when using tiles with large dimensions.
When changing the field sliceNumber of an SoOrthoSlice with an LDM compressed file, the interactivity could be very sticky with a bad user experience. Previously, it was possible to workaround this legacy defect by using the environment variable LDM_USE_IN_MEM_COMPRESSION.
As of version 2024.1, these interactions are no longer sticky in most cases, thus the environment variable LDM_USE_IN_MEM_COMPRESSION is no longer needed and has been deprecated. We strongly suggest that you use the field SoLDMResourceParameters::tileCachePolicy instead.
The API documentation of the different policies (to keep tile contents in a cache) has been clarified. See the enum SoLDMResourceParameters::TileCachePolicy and the class SoLDMGlobalResourceParameters for details.
Introduced in version 10.11, the concept of undefined value allows you to improve the rendering of data sets that contain regions whose voxels value are not significant. The voxels of those regions are not taken into account during the rendering. Thus, sharp boundaries along undefined voxels may be visible if the resolution of the volume is not high enough. This sharpness cannot be smoothed even by changing the interpolation method.
In this version, the rendering at the boundaries between defined and undefined regions is improved and smoothed unless using the NEAREST interpolation type. See SoVolumeRender::interpolation or SoVolumeShape::interpolation for detail on interpolation methods.
| cubic interpolation in previous versions | cubic interpolation with 2024.1 |
|---|---|
| 
|
The following example has been updated to demonstrate the effect of interpolation for a smooth rendering of the boundaries between defined/undefined regions.
A new light model PHYSICALLY_BASED is introduced with this version. Compared to the classic PHONG model, the new model allows you to easily change the shading of the scene by manipulating intuitive parameters.
Physically-based shading has become a standard de facto in the visualization industry. As the name suggests, this type of shading follows the physical rules for the interaction between lights and surface materials. One of the most important rules is that the surface cannot reflect more energy than the incoming energy, which is not the case for empirical models such as phong shading. As a consequence, the rendering may be interpreted as darker compared to phong shading. If you need a brighter result, you can use multiple lights. For instance using the classical headlight plus one fixed light usually produces bright enough images.
| PHONG light model | PHYSICALLY_BASED light model |
|---|---|
| 
|
The new physically rendering feature is based on the following new API:
The node SoPhysicalMaterial must be inserted in the scene graph to benefit from the physically based shading. Even if SoPhysicalMaterial is a new alternative to specify physical aspects of materials in the scene graph, it is not necessary to replace all the historical SoMaterial instances in the scene graph by SoPhysicalMaterial. In fact, if an SoPhysicalMaterial is inserted at the begining of the scene graph with the PHYSICALLY_BASED light model, all the SoMaterial::diffuseColor fields found during the traversal will be taken into account. However, the other SoMaterial fields (ie shininess, specularColor, etc) will be ignored, but the specular, roughness and metallic fields will be combined with the existing diffuse colors in the scene.
The documentation of the class SoLightModel has been updated: the definition of base color is introduced with the different ways to specify a base color with Open Inventor.
A new example has been added to highlight the benefits of the new light model PHYSICALLY_BASED:
Example of rendering using the new example PhysicalMaterial with coefficients: specular = 0.81, roughness = 0.46, metallic = 0.28:
A new class SoOverlayGroup derived from SoGroup is introduced with this version. It is dedicated to rendering multiple co-planar shapes without any Z-fighting artifacts.
The left image shows the rendering of a triangle over a coplanar square with a SoOverlayGroup. The right image shows the artifact of rendering when not using the new overlay group.
| with overlay group | without overlay group |
|---|---|
| 
|
This new class provides a new way to solve Z-fighting artifacts in addition to the classes SoPolygonOffset and SoDepthOffset, but the new SoOverlayGroup does not require any offset setting which can be tricky in some cases.
The performance for rendering a scene graph containing numerous custom OpenGL nodes has been significantly improved. In our tests, the gain is around 3 times faster with hundreds of custom OpenGL nodes compared to previous releases of Open Inventor.
The first rendering time of a SoText2 is reduced by approximately 15-20%. Furthermore, the amount of CPU memory allocated to render a SoText2 is reduced by approximately 15%. The improvements are significant for a scene graph containing several thousands of SoText2 instances.
New platform-specific information and guidelines Files to distribute are added in this manual. It provides a comprehensive description of all the files of Open Inventor that need to be redistributed in order to deploy your application on different platforms. This document replaces the previous legacy version in https://developer.openinventor.com and serves as an updated and reliable resource for developers.
IvTune becomes the default scene graph editor launched when the Shift-F12 key is pressed in your viewer. IvTune replaces Inventor Studio. However, the environment variable OIV_USE_OIVS must be set to 1 if Inventor Studio is your preferred choice. See SoPreferences for detail on the variable OIV_USE_OIVS.
The default value of SoLDMResourceParameters::tex2LoadRate has been reduced from 640 to 100. See interactivity improved in slice rendering for details.
The environment variables LDM_USE_IN_MEM_COMPRESSION and OIV_BUFFER_OBJECT_CACHE_SIZE are deprecated. See SoPreferences for details.
The buffer object cache API is removed as of version 2024.1. Using this API was useless:
Open Inventor 2024.1 is the last version that embeds ImageViz, and the API documentation for this extension is no longer provided in this release. As of Open Inventor 2024.2 (late 2024), ImageViz will be replaced by the new ImageDev toolkit, which offers the same functionality with the added benefit of a simpler API. More details are available here: developer.imageviz.com and imagedev-software-development-toolkit
The executable installer files are no longer provided. As of Open Inventor 2024.1, zip files (Windows) or tar.gz files (Linux) must be used to install the Open Inventor toolkit.
No platform dropped in this version.
As of 2025, we plan to support Qt6 on recent platforms and keep Qt5 only on old but still supported platforms. No platform of Open Inventor will support both versions of Qt.
| Open Inventor platform with Qt5 | Future Open Inventor platform with Qt6 |
|---|---|
| Windows / Visual Studio 2017 + 2019 | Windows / Visual Studio 2022 |
| Ubuntu 20.04 / gcc9 | Ubuntu 22.04 / gcc11 |
| RHEL8 / gcc8 |
As of Open Inventor 2024.2, Inventor Studio will be deprecated and dropped as of 2025.
Please use the VDS Customer Support portal at https:www.thermofisher.com/software-em-3d-vis/customersupport to contact us for technical or license issues/questions. After signing in (providing your license, contract, or activation number), please click on My Support then press the button + Create and fill the form to send your questions.
The Customer Support portal tutorial can be found at https://www.thermofisher.com/software-em-3d-vis/customerportal/wp-content/uploads/Customer-Support-Tutorial.pdf
1.9.8