The following document contains the release notes for the latest minor release 10.4.0 (November 2019).
Because Open Inventor 10 was a major step in the history of the SDK, please refer to the upgrade path documentation to get all the needed information and be sure your application is ready to be ported on his version of Open Inventor.
Important note: Since Open Inventor patch release 10.2.1, the DLLs and executables in the Open Inventor SDK are digitally signed for security. This should also avoid warning messages from anti-virus software.
See below the complete list of enhancements, new features included and old features removed in Open Inventor 10.4
Is a new node enabling and disabling writing of frame buffer color components. It allows specifying whether the individual color components in the frame buffer can or cannot be written, this affecting all draw buffers. You can refer to demo Hidden Line to see how it is used
The example can be found here
Hidden Line Demo with different values of SoColorMask fields
- C++: $OIVHOME/examples/source/Inventor/Features/HiddenLine/
- Java: $OIVJHOME/examples/inventor/advanced/hiddenLine/
- .NET: $OIVNETHOME/examples/source/Inventor/HiddenLine/
- SoGPUBufferObject(C++|Java|.Net) optimization
The SoGPUBufferObject(C++|Java|.Net) class has been optimized to remove any memory allocation on CPU, meaning now such buffers are allocated only in GPU memory. When comparing with previous Open Inventor versions the bigger the gpu buffer is, the bigger the amount of cpu memory is saved with Open Inventor 10.4. Any big shapes described by an SoBufferedShape(C++|Java|.Net) and where several SoGPUBufferObject(C++|Java|.Net) are used to set the fields vertexBuffer, indexBuffer, colorBuffer, normalBuffer and texCoordsBuffer should benefit from this optimization, like multiple instancing for example. Please remember that creating a SoGPUBufferObject(C++|Java|.Net) requires an active GPU context. AlgebraicShapes example can be run to compare the CPU memory used between Open Inventor 10.4 and previous versions. The example can be found here
- C++: $OIVHOME/examples/source/Inventor/Features/MultiInstancing/
- Removal of deprecated SoWX classes
Following classes are not available anymore starting with Open Inventor 10.4: SoWx, SoWxBitmapToggleButton, SoWxComponent, SoWxDevice, SoWxExaminerViewer, SoWxFullViewer, SoWxGLWidget, SoWxGLX, SoWxKeyboard, SoWxMouse, SoWxPlaneViewer, SoWxRenderArea, SoWxSensorHandler, SoWxViewer
- Removal of deprecated methods in SoCpuBufferBitSet(C++|Java|.Net) :
Following methods are not available anymore in the named class
- SoCpuBufferBitSet(SoDataCompressor* compressor);
- virtual void setCompressor( SoDataCompressor* compressor );
- virtual void setBufferUncompress( unsigned char* dataBuffer, size_t bufferSize );
Please use constructor with SoCpuBufferCompressed instead.
- Picking improvement
The picking of a surface shape is much more efficient thanks to a new optimization based on a GPU algorithm which has constant complexity (O(1), when the old CPU algorithm has a O(N) complexity). Nevertheless, this optimization depends on several conditions and if one of the following condition is false the CPU algorithm will be used automatically:
- The picked shape is a surface shape generated by MeshViz XLM
- The mesh handled by MeshViz XLM is a structured mesh. The mesh class must implement one of the following mesh interfaces
- The mesh is drawn using either an MoMeshSkin, MoMeshSlab, MoMeshLogicalSlice, MoMeshSurface
- The drawstyle (MoDrawstyle) of the picked surface shape must enable the flags displayFaces and displayEdges
- Picking radius must be zero. See SoRayPickAction::setRadius() or SoHandleEventAction::setPickRadius()
- The gpu picking is a screen space algorithm, thus SoRayPickAction (C++|Java|.Net) can only be used with setPoint()
- The picking mode must be DEFAULT. See SoRayPickAction::setPickingMode()
- The pickALL flag must be false. See SoRayPickAction::setPickAll()
This optimization is illustrated with the C++ DemoPickingAndProbing example or the EclipseMeshViz demo in Java
Services developed with RemoteViz can be used to display sensitive datasets and you might want to limit the access to those datasets to a specific list of users. In order to be sure that your user is who he says he is, you will need an authentication process. This process will normally use a token to prove the user's identity. Various platforms, for example Okta (https://www.okta.com/) and Auth0 (https://auth0.com/) provide authentication as a service and can now be used as Authentication Providers for your RemoteViz application.
In a token based authentication process, the client application first sends a request containing the user credentials to the Authentication Provider. The Authentication Provider returns a corresponding token if the credentials are valid. The client then sends this token to the service with each request. The service can use the token to validate the authenticity of the request.
Using Authentication in a RemoteViz application is explained on this page
- Load Balancing
A Load Balancer is commonly used when a web application needs multiple instances and/or multiple servers to handle all the users. The purpose of the load balancer is to distribute the workload in a way that makes the best use of each server's capacity in order to prevent overload on any server and ensure the best user experience.
A new RemoteViz example includes a simple, but highly customizable and multi-platform, load balancer that is able to load balance RemoteViz services efficiently. The load balancer provided in the example is a layer 7 load balancer written in Node.js (https://nodejs.org/en/) that intelligently routes the incoming connections based on the renderArea ID specified in the URL. This example can be easily customized to respond to different load balancing scenarios.
The Load Balancing example is explained on this page
- MRC Reader
A new reader is now available in VolumeViz and will allow any application to import MRC data. MRC is a file format that has become industry standard in cryo-electron microscopy (cryoEM) and electron tomography (ET). Following classes have been added to allow MRC operations
- Inside Center analysis measurement
The SoDataMeasurePredefined(C++|Java|.Net) class proposes two new measurements through the PredefinedMeasure enumerate: INSIDE_CENTER_X_2D and INSIDE_CENTER_Y_2D. Contrarily to the center of gravity which can be located outside the object, the inside center is always inside objects. The inside center is computed as the center of the inside length measurement extracted from the polygonal approximation of the object boundaries.
Red cross represents the location of the object center of gravity, while green cross represents its inside center
- Selection of the output type for image normalization
The SoRescaleIntensityProcessing(C++|Java|.Net) engine proposes a new parameter outputType which defines the type of the output image. Thanks to this parameter it is no longer necessary to convert the image type before or after re scaling the intensity range. For instance, when re scaling a 16-bit data set from the [0; 65535] range to [0; 255], the output type can be directly set to 8-bit unsigned integer in order to save memory. The default outputs type is SAME_AS_INPUT which assigns the input type to the output and amount to the same as the former behavior.