HOOPS Publish Integration
HOOPS Publish is the 3D PDF export library from Tech Soft 3D. Publish enables the developer to export a HOOPS Visualize scene to a 3D PDF file or an HTML file. An introduction to Publish can be found here.
All Publish classes are members of the HPS::Publish container class.
Prerequisites
A separate license is required to use HOOPS Publish. The interface described on this page is the way to connect Visualize with HOOPS Publish. To use HOOPS Publish, the execution environment must support the SSSE3 instruction set.
Steps for integrating HOOPS Visualize with HOOPS Publish are delineated below:
Step 1: Install Publish
HOOPS Publish is distributed from the Tech Soft 3D Developer Zone - the first step is to download and install it. You do not have to generate a separate key to use the Publish component. The key will be embedded with your Visualize license key.
Step 2: Set up the environment
Publish uses the environment path to find the location of the supporting libraries. Add the location of the libraries to the path (note the different locations for 32 and 64-bit DLLs), for example, C:\Program Files\HOOPS_Publish\bin\win64_v140.
Step 3: Include the libraries in your project
The Visualize-Publish interface library must be included as a dependency. C++ users will need to link to hps_sprk_publish.lib or hps_sprk_publish.so. C# users need to reference the hps_cs_sprk_publish_vc11 assembly.
Step 4: Include the header file in your source (C++ only)
Your source files that use the Visualize-Publish interface must include sprk_publish.h.
At this point, Publish is ready to use in your application.
Simple export
When initializing the HPS::World object in your application, you must also set the Publish resource directory. This directory is part of the Publish installation.
To export a Visualize model using HOOPS Publish, the view hierarchy must already be in place with the model residing in the HPS::Model segment. Once that prerequisite is met, only a few calls are required:
The Publish API is completely synchronous, so the export is complete once the call to Export returns.
IMPORTANT: The filename parameter in HPS::Publish::File::Export must include a fully-qualified path, or the export will fail.
Exporting HOOPS Exchange data to 3D PDF
For those developers who are using HOOPS Exchange to load a CAD model, the export process is slightly different. If your model contains B-rep, and you want that data to be exported, you need to export using a HPS::CADModel instead of a HPS::SprocketPath. Doing so will export both the CAD model and any Visualize data as unified model. If you don't specify a HPS::CADModel, the Exchange geometry will be exported as tessellated triangles, and the B-rep data will be lost.
Complex export
To make a more complex PDF document, more work is required. In the following example, a document with two views is created, but the logic could be extended to accommodate other enhancements. Performing this complex export means interacting directly with the Publish API, including creating and configuring the Publish document object hierarchy.
To set up each of the views, we'll use a regular Visualize HPS::CameraKit. The views are contained in an HPS::Publish::ArtworkKit object.
Setting the export source
Next, you'll need to set the HPS::KeyPath (which contains the view hierarchy) as the source of the HPS::Publish::AnnotationKit. The HPS::KeyPath should point to the segment in the scene graph where the data export will begin. That segment and all of its subsegments will be exported.
NOTE: For those developers who are using HOOPS Exchange to load a CAD model, the export process is slightly different. If your model contains B-rep, and you want that data to be exported, you need to export using a HPS::CADModel instead of a HPS::KeyPath. Doing so will export both the CAD model and any Visualize data as unified model. If you don't specify a HPS::CADModel, the Exchange geometry will be exported as tessellated triangles, and the B-rep data will be lost. This behavior is controlled by setting the source of the annotation kit. Possible options for the source are shown below:
- CADModel - Only the Exchange data is exported. If you added any Visualize data, it will not be part of the export.
- KeyPath or KeyPathArray - Everything is exported, except B-rep data from the Exchange model (tessellation is still exported).
- CADModel and KeyPath - Everything, including B-rep and Visualize data, is exported.
The Export function has overloads to handle all of these cases.
Putting everything together
When configuring the HPS::Publish::PageKit object, it is possible to specify what portion of the page that HOOPS Publish will appropriate for the 3D model. This is done by passing an HPS::IntRectangle, specified in points. Annotations are always specified using a rectangle. The origin is the bottom left corner of the page. Annotation kits can also be compressed by setting the compression options before export, as shown in the code snippet below. The compression algorithm is a lossy algorithm.
IMPORTANT: The filename parameter in HPS::Publish::File::Export must include a fully-qualified path, or the export will fail.
Exporting with a template
A PDF template is a special type of PDF file that might contain text fields, graphics, and blank areas that you can fill in with your data in order to compose a complete file. In Visualize, templates are manipulated using the HPS::Publish::PageKit object.
A few sample templates are included with the HOOPS Publish package. This particular example is using BOM_A4Table_L.pdf. Whenever you are working with templates, you need to know beforehand the internal names of the fields that you want to fill in with data (there is no way to programmatically enumerate the field names). The template file in this example was generated using the source file found at <PUBLISH INSTALL DIR>\samples\publish\publishsource\BillOfMaterial\BillOfMaterial.cpp, and the field names can be found inside that file.
To export with a template, you would follow the steps in the previous snippets, but add the following template export code to your calls to HPS::Publish::PageKit. This code example will put the Visualize model into the "My3DWindow" field:
You may have noticed the "_1" suffix on the field names. The suffix indicates the page number of the PDF that you're exporting to. So, to export to page 2, you would use a suffix of "_2". In this way, you have control over the data that gets inserted at the page level. This example only has one page, but the field suffix is required nonetheless.
Exporting a subtree
It is possible to export specific subtrees of a scene to a 3D PDF document, instead of having to export the whole model. To do this, you must use one of the HPS::AnnotationKit::SetSource methods and build a path to the segment you wish to export. SetSource accepts one of:
- HPS::SprocketPath
- HPS::KeyPath
- HPS::KeyPathArray (for exporting multiple paths)
This example demonstrates how to export using a HPS::KeyPathArray:
Widgets
Links
Publish allows you to add links in the PDF document on the exported pages. In the context of a PDF document, links are regions of the page which, when clicked, will invoke JavaScript embedded in the document. It's important to note that the link itself is just a rectangular region on the page, which may have an associated color, border, and highlight mode. It does not contain text or images. If you want a text string or an image to appear at the link location, that needs to be inserted separately using the appropriate API functions.
Buttons
Buttons can be added anywhere on the page. Size is specified with a rectangle - all other options are set in the HPS::Publish::ButtonKit.
Button logic is handled with Javascript that you add to the PDF document's HPS::Publish::PageKit.
Tables
In HOOPS Publish, tables added to PDF documents are defined in HTML and styled with CSS. A HPS::Publish::TableKit is required when inserting tables.
Tables can be filled with data hard-coded in the HTML, or you can fill the fields programmatically:
Additionally, buttons can be added to tables in the following way:
Slide tables
A slide table is an HTML table that can be scrolled using buttons. Slide tables are defined in HTML, just like normal tables. HOOPS Publish expects a "previous" button, and a "next" button to control the scrolling. You do not need to write logic for the slide table buttons - it is written automatically by HOOPS Publish.
Modifying PDF files
So far, we have talked about building and exporting PDF files, but HOOPS Publish also allows you to open, inspect, modify, and write a PDF that already exists. To create an in-memory copy of a PDF, use the following code:
The code snippet above loads the file specified by filename and returns a HPS::Publish::DocumentKey. The HPS::Publish::DocumentKey can then be used to query and modify the structure of the PDF. Most of the functions correspond with the functions on HPS::Publish::DocumentKit, however, the Unset and Show functions are not available due to limitations in the Publish API.
If you need to make changes to a particular page, rather than make a document-wide setting, use the HPS::Publish::PageControl:
After you are finished making changes to the file, simply re-export the document the same way you would export a newly created file. The only difference is that you would use the HPS::Publish::DocumentKey instead of a HPS::SprocketPath or HPS::Publish::AnnotationKit.
Associated memory in HOOPS Publish is freed when the last HPS::Publish::DocumentKey reference goes out of scope, or the developer calls Delete on it.
Exportable data
Not all data in a Visualize scene is exportable via Publish. For those entities that are supported, Publish has its own internal representation; others are not supported at all. The table below lists entites that are exportable. If an attribute or entity is not mentioned in this list, you can assume it will not be exported.
| Visualize entity | Notes |
|---|---|
| Color | Color is exportable in general, however, vertex and edge color interpolation is not exportable. When exporting a point cloud, only vertex color defined at the segment level is exported (vertex colors defined on a shell are ignored). |
| Curves and lines | All non-facetted geometry is converted to polylines for export. Line patterns are not exported. |
| Edges | The implicit edges of a tessellated piece of geometry are exported. However, viewing them requires setting a particular rendering mode in the resulting PDF, and there is no granular control for the visibility of different types of edges like in Visualize. For example, you can set any of the rendering modes with Wireframe in the name, such as Publish::Rendering::Mode::[SolidWireframe, TransparentWireframe, Wireframe]. Edge patterns are not exportable. |
| Facetted geometry | All facetted geometry, including NURBS surfaces, is converted to a shell for export. Note that if face visibility is off, the geometry will still be exported but will not be visible by default (the user can toggle this using the tree control from within PDF Reader). Per-face visibility and color are supported for shells. Face patterns are not exportable. |
| PMI data | PMI data is exportable if the original model was imported with PMI data |
| Text | All text is exported as UTF-8 and comes through as markup in the PDF. Font name, size, alignment, bold, italic, overline, strikethrough, underline, transforms, and line spacing are exportable. Some information is lost in the translation from Visualize to PRC. For instance, the text insertion point for PRC is always the lower left, so any alignments are translated into moving the insertion point. PRC doesn't have multiline text strings, so these must be split into multiple lines (though still in a single markup), and things like line spacing are implicitly defined by the position information for multiple text strings in a markup. Additionally, screen-facing text will always be a fixed size. |
| Textures | Only diffuse and environment textures are supported. Multitexturing is not supported. If you require multitexturing, we recommend you composite the textures into a single texture. |
| Vertices | Vertices are visible if you set HPS::Publish::Rendering::Mode::Vertices or HPS::Publish::Rendering::Mode::ShadedVertices However, there is no rendering mode which allows vertices to be visible with faces and lines. |
Other limitations
PRC: PRC data is exportable only if it was originally loaded with Exchange. If you use Publish to export a model that was loaded from Exchange, just the PRC data imported from Exchange will get written to the PDF (no scene graph changes will get exported). However, if you export a model that did not come from Exchange, the PRC data will be constructed from the scene graph and put into the PDF.
CATIA drawings: CATDrawings cannot be exported to 3D PDF. Attempting to export a CATDrawing to 3D PDF will result in an exception of type HPS::IOException, which will have a result field set to HPS::IOResult::UnsupportedFormat.
You can check whether an imported model is a CATDrawing by asking the HPS::CADModel for the "Filename" metadata, then checking whether its extension is CATDrawing (case insensitive). Alternatively, you can also check whether any of the HPS::CADModel subcomponents has the type ExchangeDrawingMask.
Error handling
During the import process, Publish will trigger events when it detects a problem or has information to give you. For example, if Publish couldn't find a referenced subcomponent in an assembly, or if there was some sort of import failure, a warning or error could be triggered. It the responsibility of your application to catch these events and respond appropriately.
The Visualize-Publish interface will capture all events and wrap them into one of three types: HPS::InformationEvent, HPS::ErrorEvent, or HPS::WarningEvent. Each of these types derive from HPS::Event, thus, handling them is identical to handling any other type of Visualize event (event handling is discussed here).
HPS::WarningEvent contains both a code and a message, while HPS::InformationEvent has only a message.
Exceptions
When you attempt to add any object to a Publish page, Visualize pulls the data out of the kit and passes it to HOOPS Publish. Thus, if you pass an empty or invalid object, Visualize will pass the equivalent structure to Publish. If Publish returns an error, Visualize will throw an HPS::IOException, which includes a string describing the problem as well as the error code generated by Publish.
Exporting to HTML
In Visualize, there are two ways to export to HTML, either through the HTML sprocket or through the Publish sprocket. With the Publish sprocket, it's possible to export a CADModel that was originally loaded via HOOPS Exchange - this offers a performance benefit because the model data can be read directly from the PRC created in Exchange without incurring the overhead needed for data conversion.
Exporting via HOOPS Publish means the result will include all of the PRC data embedded in the model. Exporting to HTML will export the model geometry only.
To export your CAD model to HTML, first import it via the Exchange sprocket:
Once the import has completed, set a new CADModel object to the CADModel retrieved from the import notifier. Then, call Publish::File::ExportHTML() with your CADModel object, the output file path, and the HTML template file.
HOOPS Publish export template
To facilitate export using HOOPS Publish, we provide a template in the HOOPS Publish package, located at <HOOPS_PUBLISH_DIR>/samples/data/html/export3dtohtml_template.html. The template also provides handling for a model browser.
HOOPS Visualize export template
For exporting via the HTML procket, we provide two template files in the Visualize package, HOOPSCommunicatorTemplate.html and HOOPSCommunicatorMinimalTemplate.html. The standard template includes advanced UI features, whereas the minimal template only includes the basic functionality for viewing a model.
For more information on modifying an HTML template file, please see Modifying the HTML Template.