HOOPS/HIO Release Notes

1.0 New Features

2.0 Enhancements

3.0 Functional Changes



1.0 New Features

Maintenance Release 19.16

HIO_Exchange adds CAD 'views' and HIO Connector support

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.

 

Maintenance Release 19.14

HOOPS Publish Integration

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.

Major Release 19.00

HOOPS Exchange Integration

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.

DGNdirect

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.

SketchUp

With the SketchUp HIO Component, we now support SketchUp 8.


2.0 Enhancements

 

Maintenance Release 19.25

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.

 

Maintenance Release 19.19

HIO_Exchange supports import of 2D text

The HIO_Exchange module now imports non-PMI 2D text, and maps it to HOOPS/3DGS scene-graph 'text' primitives.

 

Maintenance Release 19.16

  • HIO_Exchange and HIO_Publish integration now supports HOOPS Exchange v5.0, and HOOPS Publish v5.0

  • HIO_DWF supports DWF Toolkit v7.7

 

Minor Release 19.10

64-bit HIO_DWF and HIO_DGN

Support for 64-bit HIO_DWF and HIO_DGN is now included.

HIO_DWG and HIO_DGN modules produce more optimized HOOPS scene-graphs

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.

Change to handling of DWG drawing order information

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.

HIO_DWF Optimizations and changes to the default scene-graph

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:

  • All layer segments live under the segment "layers"
    • There's a non-layer segment for geometry that does not reside in a layer
  • Layer segments are named
    • The name is encoded as a URI (percent encoded)
    • The name of the segment is the layer name, if available
    • If a layer name is not available, it is named with H_FORMAT_TEXT("layer #%06d", number);
      • The segment dwf_information/layer_info_deprecated is obsolete and will not be created
      • The segment dwf_information/layer_info is also obsolete and will not be created
        • Use HC_QShow_Existence to see if a layer exists
        • Use HC_Begin_Contents_Search in the "layers" segment to list the layers
  • Each layer has a User_Options attribute with the name like so
    • layer name = `uri-encoded-layer-name`
  • The segment tree under each layer is sorted by attribute
    • There is a segment path, named by the attributes, which defines the attribute state
      • For example, "layer #000001/edge line weight 1.0 oru/color 1 0 0/etc..."
  • URL's and Object Id's are now set directly on the geometry as User_Options
    • the url user options are formatted like so...
      • url = (uri-encoded-url1, uri-encoded-url2, ...)
    • the link_info segment now has one segment per URL.
      • Each of these segments contains geometry references to all geometries which belong to the URL (In the future, this may be enhanced to include the path and attributes for each linked reference)
      • There are two User_Options set in each URL segment: min and max
        • Each are three ints/float representing the bounds of the URL. For example, "min = (1, -2.5, 0), max = (5.5, 2.5, 0)"
  • Depth Range is no longer used to maintain draw order.  The draw order now relies on the z-values
    • Each layer has a translation matrix defining the draw order.
    • Each layer has a priority set defining the draw order which would be honored by the "HSRA = priority" Rendering_Option
    • The z-range is 1/3rd of the diagonal of the 2D drawing (not including the background and non-layer segments)
  • 2D Drawings
    • all have background "paper"
      • you can disable the background paper by deleting or hiding the "background" segment
    • The Camera is changed to look down the -z axis, and y axis is up
    • The camera Projection is set to orthographic
    • The Pan operator is set

 


3.0 Functional Changes

Service Pack 19.35

DWF import changes

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:

  1. "viewport units" -- this specifies what measurement units this viewport uses (i.e. millimeters, inches, etc.)
  2. "measurement scale" -- this number is used to scale the measurements in world coordinates to the the DWF measurements.

The workflow to obtain correct measurement would thus be:

  1. use an operator to measure the distance between two points in world space
  2. figure out in which viewport the points reside (one way to do this would be through a selection)
  3. divide the distance in world coordinates by the measurement scale of the viewport

Service Pack 19.30

3D DWF export changes

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);

Service Pack 19.28

Visualize v19.28 requires the HOOPS Publish v5.30 libraries for export via Publish.

Maintenance Release 19.14

HIO_3DX changes

  • HIO_3DX has been renamed - Because the HOOPS 3DX product has been renamed to HOOPS Exchange, we've likewise renamed the HIO_3DX module to HIO_Exchange.
  • HOOPS Exchange v4.2 support - The HIO_Exchange module is now dependent on HOOPS Exchange v4.2
  • Exporting a 3D-PDF now requires that you obtain the HIO handler for the '3dpdf' file type, and call its FileOutputByKey method as follows:
            HOutputHandler * handler = HDB::GetHIOManager()->GetOutputHandler("pdf3d");
            
            if (handler)
                result = handler->FileOutputByKey("c:\\temp\\my_3D_PDF_File.pdf", my_view->GetModelKey(), &output_options);
    

 

Minor Release 19.10

HOOPS 3DX v4.1 Support

The HIO modules that require HOOPS 3DX are now dependent on 3DX v4.1 See our supported file formats for more details.

HIO_DGN updated to support newer version of 3rd party toolkit

The HIO_DGN module has been updated to support a newer version of the DGNDirect 3rd Party Toolkit: Teigha 3.04.01

OpenInventor (.iv) format is no longer supported

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.

Major Release 19.00

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.