Open Inventor 是一组高性能的三维软件开发包（SDK），用于医学、计算机辅助设计与工程、石油、天然气和采矿业这些领域中的专业应用。
其面向对象的应用程序编程接口、可拓展架构以及一整套先进庞大的组件为软件开发者提供一个完美的高级平台，用来快速集成2D/3D可视化数据与处理能力到工业和科学应用中
Open Inventor 是一组高性能的三维软件开发包(SDK),用于开发医学、CAD工程、石油、天然气和采矿等领域的专业应用。
轻松开发三维软件 构建强大的三维应用 为未来构建三维基础 从桌面到云端
从二维到三维
三维硬件已准备就绪。即使对于大型数据集，现代 3D 硬件的性能和功能允许高质量和互动性的渲染。
3D 渲染对任何程序来说基本上都能实现，无论它是一个新研发或应用升级，Open Inventor 都可以很容易地添加这些额外的功能
面向对象的软件开发工具
Open Inventor面向对象的框架允许应用软件快速原型设计与开发。更提供了强大的“场景图”范式与面向对象的应用程序界面，能够避免使用低层次程序重新实施渲染与场景管理运算。
内置组件
不需要重复发明， Open Inventor 提供了一系列全面超过1300种可以随时调用的程序，使用高层次概念来处理数据。这些内置组件包括二维、三维图像处理运算、先进的查看器、操纵器与引擎。专门扩展模块处理复杂的体数据与网格数据，并解决具有挑战性的问题，如远程与移动端软件开发，或是集成GPU运算。
高效率工具
Open Inventor 利用良好的设计模式，自动调用所有可用的功能、优化渲染、并使用更高层次的组件执行操作，作为一个面向对象的软件开发工具，无疑Open Inventor 从根本上来说是更为高效的。
附加在Open Inventor中的IVTune工具，为软件开发者提供场景图的交互性视图以便于他们在运行时追踪调试并优化其应用。
最后，Open Inventor附带有一组丰富的预先编译源代码的项目例子，一个完整的文档、以及一整个在线开发区域。
更大的灵活性
Open Inventor一个完全开放的架构，协助双向代码集成：集成Open Inventor API到您的应用或集成您的可视化代码到Open Inventor。
Open Inventor支持使用C ++，C＃（.NET）或Java 的开发，并允许开发者直接调用原生API。Open Inventor的展示窗口对象通过原生组件的方法可以很容易地加入到您的用户界面。
通过自定义节点和自定义着色器来扩展场景图对象，您可以无缝集成可视化代码到Open Inventor。Open Inventor提供的清晰的文档和方便的API，以减少创建自定义节点和自定义着色器的工作量。
此外，Open Inventor 产品团队提供专业服务用于集成与部署在任何特定环境下的协助。
跨平台
Open Inventor跨平台框架允许开发人员在Windows、Linux与OS X系统范围内设计可扩展和交互式的三维应用程序。所设计出的应用程序100%能与源代码兼容，并且只需要重新编译就能在其他平台上运行。
Open Inventor 支持使用C++, C# (.NET) 或是Java 进行开发。
数据量
如今的勘探与开采、医疗或工程学数字工作流程要求极大的2D、3D数据集的可视化。此类数据量可以轻松超过终端用户设备上的可用储存容量，如笔记本电脑、移动硬件或是需要过长的时间进行下载。
Open Inventor RemoteViz技术使其能够交互显示储存在远程大容量服务器上的超大型远程2D、3D数据。带宽优化技术甚至允许探索庞大的3D模型。
协作
基于分析理解复杂信息所作出的复杂决策通常不是由单独一个人所制定的。专家与管理人员必须经常分享共同的工作来探索、分析数据，从中他们将采取假设的关键决策数据。
Open Inventor RemoteViz技术能够使远程用户在服务器上共享一个独特的交互式工作会议，它也允许最终用户在同一个数据集上打开多个会话窗口，能够更快更便利的执行同步数据可视化与分析任务，从而制定决策。
Open Inventor 2023.1.1
- Core
- #OIV-4570 The roi manip shouldn't change the opacity of volume
#OIV-4547 Huge perf regression on scene with a lot of static Text2
#OIV-4510 SoViewingCube disappears from display when changing render action – CAS-43081
#OIV-4514 Transparent shapes disappear when switching the render mode from BboxHL to LineHL on Intel UHD – CAS-43081
#OIV-4566 Stereo dialog not well resized and positioned
#OIV-4595 AccessViolationException when importing .dxf file – CAS-43805, CAS-44123
- Dicom
- #OIV-4489 Missing return statement in the method DicomGetImagePosition of the MedicalHelper.cs class – CAS-42983
#OIV-4544 Getting dicom info issues – CAS-43493
- Documentation
- #OIV-4558 Picked point in seek mode doesn't position it at the center of the view area when ortho cam is enabled – CAS-42881
- OpenGL
- #OIV-4478 OGL error GL_STACK_OVERFLOW when calling direct OpenGL functions through SoGLCallback – CAS-42902
#OIV-4501 ShaderProgram not updated when ShaderObject changes – CAS-43042
- Shader
- #OIV-4568 Shape not renderered in SORTED_PIXEL & 5+ Viewers – CAS-43435
- RemoteViz
- #OIV-4602 The object Connection, got by onSendingFrame method, does not give a valid object with getLastEncodeFrame
Open Inventor 10 version numbering changes
As of 2023, all future Open Inventor 10 versions will be renamed by using the year number of the version release. We will continue to publish 2 versions per year thus in 2023 the first version will be named 2023.1 and the second version will be 2023.2. Each year, the first version will be planned for a March release, and the second for a September release. The number 10 will no longer be mentioned in the name of Open Inventor versions.
As per the last 3 years, these 2 versions per year will be what we call minor releases, with a policy of compatibility specified in the product life cycle. Future major releases will also be named using the year number. We will explictly communicate when a version is considered as a major release.
In addition to those twice yearly versions, we will also continue to publish, when needed, maintenance versions identified by the last digit in the version name. For instance Open Inventor 2023.1.2 defines the 2nd maintenance version of the minor version 2023.1
The legacy Open Inventor 9 version name will be unchanged.
VolumeViz
Volume rendering with a single resolution
Using a single resolution to render a volume is easier as Volume Viz can now automatically compute the highest possible resolution according to the current settings and the hardware configuration (e.g., viewpoint, amount of texture memory). Using a single resolution prevents undesirable artifacts that may be visible in the default mode. However, the highest possible resolution may be lower than the default mode resolution on some parts of the volume.
This highest computed resolution takes into account the regions of interest and the view culling option. Before reaching a uniform resolution, tiles of different resolutions are rendered without blocking the render area.
The following images highlight the benefits of a single resolution. On the left image, some unwanted artifacts are visible at the boundary between adjacent tiles with different resolutions. Such artifacts do not exist in the right image using the new mode because a uniform resolution is used on the whole volume. However, on the left image the closest parts of the battery to the camera are rendered with a higher resolution compared to the right image.
The new mode can be activated with the class SoLDMResourceParameters. The field fixedResolution must be TRUE and the field resolution must be set to -1.
New function in shader related to clipping and ROI
A new function VVizIsClippedByROI() of the VolumeViz fragment shader API has been added in the file vvizClipping_frag.h to check if a texture coordinate is clipped by a region of interest applied on a given dataset. It is mainly useful when blending several datasets that do not have the same size or the same extent.
MeshVizXLM
Clip line extraction extended in C++
The MoMeshClipLine class allows computing and extracting the intersection between a 3D surface mesh and a single plane. As of 2023.1, this class also allows computing and extracting any projection of a 3D polyline onto a 3D surface mesh. The polyline to project and the direction of the projection are 2 new public fields of the class MoMeshClipLine.
Note: MoMeshClipLine is now complementary to MoMeshFenceSlice as the new fields MoMeshClipLine::polyline and MoMeshClipLine::direction also defines a fence. MoMeshClipLine corresponds to the intersection of a fence with a 3D surface mesh, and MoMeshFenceSlice corresponds to the intersection with a 3D volume mesh.
The MoMeshClipLine::plane field is now deprecated as a single plane can be defined by setting a single point in the new MoMeshClipLine::polyline field.
2 existing C++ examples have been updated to demonstrate the projection of any 3D polyline onto a 3D surface mesh.
C++: $OIVHOME/examples/source/MeshVizXLM/mapping/ClipLine
C++: $OIVHOME/examples/source/MeshVizXLM/mapping/ClipLineOnSkin
The following images come from this example, and show a 3D red polyline on the top of the transparent cube that is projected and extracted onto the 3D surface mesh. The properties used to color the cells of the surface mesh are also extracted and displayed onto the projected polyline.