The HIO_Exchange module now imports CAD 'views' information from the original CAD file, and maps it to HOOPS/MVO MarkupManager information. HIOConnector support has also been added to provide a mapping between HOOPS/3DGS and PRC entitites. Refer to the HIO_Exchange documentation for more information.
We've introduced support for integration with HOOPS Publish, via the HIO_Publish module. This integration with our sister product allows you to easily export your HOOPS/3DGS scene-graph information, a subset of MVO animation info, and MVO PMI info to 3D-PDF files. Please see the HIO_Publish documentation for more information.
We've introduced support for integration with HOOPS Exchange. This integration with our sister product will give you access to the powerful data translation capabilities that can import 15 MCAD formats and export to 3D PDF.
During importation, if you want to import not just the current model but all models, then you can enable the new HInputHandlerOptions::m_bDGNImportAllModels flag.
With the SketchUp HIO Component, we now support SketchUp 8.
The HIO_DWG integration now includes an overhauled 'HIO_DWG2' implementation. Developers who are relying on the curent HIO_DWG should consider the HIO_DWG2 module as a BETA. (The goal is to finalize it in v20.) The new module is located in /dev_tools/hoops_hio/hio_dwg2. If you are interested in testing/using the module, you must manually rebuild it using the provided project files.
The HIO_Exchange module now imports non-PMI 2D text, and maps it to HOOPS/3DGS scene-graph 'text' primitives.
Support for 64-bit HIO_DWF and HIO_DGN is now included.
When DWG/DGN files are being loaded by the HIO modules, an 'optimize' step has always been performed in order to produce a more efficient scene graph. Despite the optimize step, DWG/DGN files could still end up with 1 segment per DWG/DGN 'entity' (i.e. 1 polyline per segment), which in turn could translate to an extremely large amount of HOOPS segments, thus requiring excessive memory and preventing reasonable rendering performance. We have enhanced the default HIO_DWG and HIO_DGN import behavior to now store user-data on a per-geometry basis rather than in segments. This allows the optimize setep to produce much more optimal HOOPS scene graphs, depending on the contents of the DWG/DGN file.
It is important to note that any application code which was relying on a '1 segment per entity' scene-graph (i.e. query/selection/highlighting code), that code may need to be restructured to work with the default HIO_DWG/HIO_DGN scene-graphs, as a result of there being many entities per segment.
While we strongly encourage you to rely on the new default scene-graph and make any necessary code changes, in the interests of backward compatibility the following option has been added to HInputHandler Options, to allow you to revert to the previous, suboptimal scene-graph creation logic:
- m_bLegacyOptimize
If false, i.e., the new default behavior, then we perform an Optimize_Segment_Tree with the new options to localize/push user options onto each piece of geometry in a segment (Open_Geometry, Set_User_Options, Close_Geometry), thereby allowing for a more optimal scene graph.
If true, i.e., legacy behavior, then we perform the existing Optimize_Segment_Tree which will leave user options in the segments representing DWG and DGN entities. This can result in extremely segment-heavy (suboptimal) scene-graphs.
The DWG import logic has also been enhanced to map any drawing order information over to z-values. This further enables the 'optimize' step to produce a more efficient scene graph, resulting in more entities per HOOPS segment (as opposed to the extremely suboptimal 1 entity per segment) The following option has been added to HInputHandler Options to allow you to revert to the previous logic:
- m_bDwgDepthRangeDrawOrder
If false, i.e., the new default behavior, then we offset (2D) geometry which requires a draw order along the z-axis appropriately to achieve the same effect, thereby allowing for a more optimal scene graph.
If true, i.e., legacy behavior, then we use depth range at the segment-level, to preserve the draw order for those 2D entities which require it. This prevents segments from being merged during the optimize process.
In review, the HIO_DWF module handles loading DWF files which can contain both 2D and 3D subfiles. We have rewritten the 2D-DWF import logic so that it produces a much more optimized and logical scene graph:
There is a new way to obtain correct measurements in a DWF model. A DWF file will usually contain at least one viewport. Each viewport may use a different measurement scale. Upon import, Visualize will group all geometry within a single viewport is together in the same segment. The viewport segment will have the same name as the viewport, and will be located under its parent layer segment. Each viewport segment will contain two user options, as follows:
The workflow to obtain correct measurement would thus be:
In 19.30 a new method has been developed to enable 3D DWF writing. The HW3D_Write_W3D_File function is no longer defined in HW3DStream.h. You should NOT include HW3DStream.h into your application. The function has been moved to its own project, called dwf_hsf_firewall, and is linked directly to hoops_stream. HIO_DWF now links to dwf_hsf_firewall. Doing this removes the previous requirement to include HW3DStream.h and to set ExtendedData in HOutputHandlerOptions. The new code to save a 3D DWF file is this:
options.m_b3dOutput = true; m_pHoopsModel->WriteWithOptions(filename, view, &options);
Visualize v19.28 requires the HOOPS Publish v5.30 libraries for export via Publish.
HOutputHandler * handler = HDB::GetHIOManager()->GetOutputHandler("pdf3d"); if (handler) result = handler->FileOutputByKey("c:\\temp\\my_3D_PDF_File.pdf", my_view->GetModelKey(), &output_options);
The HIO modules that require HOOPS 3DX are now dependent on 3DX v4.1 See our supported file formats for more details.
The HIO_DGN module has been updated to support a newer version of the DGNDirect 3rd Party Toolkit: Teigha 3.04.01
Support for importing the .iv file format has been dropped. Import logic was initially provided as a proof-of-concept to assist developers evaluating HOOPS, and only imported a limited set of .iv files. Developers who wish to import the .iv format should review the scene-graph creation guidelines to build their own import logic, and can contact Develper Support with any questions.
The U3D file format is no longer supported. However, the U3D format is still supported via HIO 3DX. See our supported file formats for more details.