HOOPS Web Viewer component makes it easy to aggregate multiple models together. Such models might consist of the various disciplines in a federated BIM model, different variants of a chassis in a Car Configurator or subcomponents of a complex MCAD assembly. We are using the term "shattered" most commonly in the context of the last example; a complex assembly like a car or an airplane consisting of hundreds or thousands of individual parts. Often in the original CAD assembly, each subcomponent of an assembly will reside in its own file. The goal with "shattered" support in HOOPS Communicator is to largely retain that structure when converting an assembly to the Stream Cache format. Instead of creating a single monolithic Stream Cache (SC) model for the assembly, we generate individual SC models for each part and then an additional "master model" and/or XML product structure file that aggregates those parts into a complete assembly.
Advantages of the Shattered Workflow
One approach to viewing a complex CAD Assembly in HOOPS Communicator is to create a single SC model that contains all the parts of an assembly, using our conversion tools or via direct authoring. While this SC Model could get quite large, the intelligent streaming support in the Stream Cache Server ensures that this model can be viewed almost instantly. In combination with memory limiting or the use of Server-Side rendering, even massive monolithic models can be viewed on a modest laptop or mobile phone. You can also use OnDemand mode to keep the model on the server, and only request the components or subassemblies a user is interested in.
The main advantage that the shattered approach has over the monolithic workflow, is in how it deals with variants and configurations of an assembly, and a PLM system is a prime example. Multiple users working on the same assembly means that the data is constantly evolving and changing, new variants of parts are getting "checked in", some may be deleted, and subassemblies are added and reconfigured. In addition, a user may want to view an older state of an assembly or mock up a different configuration. In each of these scenarios, every time the model changes or a different variant of the model is requested, a new monolithic SC model would have to be generated which can be slow and resource heavy.
With the shattered approach, creating new configurations of an assembly simply involves updating the XML product structure hierarchy of the assembly, and then reconverting the components of a model that have changed. In most case, it makes viewing different variants of a model almost instantaneous.
Utilizing the Shattered Approach
Creating a shattered model on the server is discussed in the Data Import section of the Programming Guide. To quickly review, this involves first creating an XML product structure file. This file describes the structure of the model and its dependencies to other SC models, which in turn typically represent the parts of an assembly. Then in an optional step, a SC master model can be generated by our conversion tools from this XML file. This file can be loaded just like any other SC model into the viewer, via the Stream Cache Server.
See below for two diagrams showing a typical, slightly simplified assembly tree hierarchy and the files associated with this hierarchy.
While you can create a so called "master model" on the server that serves as the equivalent of a top-level assembly file, the disadvantage to this approach is that it requires this master model to be regenerated every time the structure of an assembly changes. In addition, a SC master model must be streamed via the HOOPS Stream Cache Server and cannot be an SCS file. An alternative to that approach is "client-side shattered".
We have already touched on the functions for client-side shattered support in the previous chapter. The general approach is that you are utilizing the XML product structure file generated either when converting a CAD assembly through our import tools, or directly by your application. You simply pass this file to the relevant loadSubtree functions:
As you can see, client-side shattered supports SCS files as well, which means it does not require the Stream Cache Server.
The downside to client-side shattered is that you will need to transfer the XML product structure file to your browser client (or generate it there). Streaming/Loading performance and general framerate are also not quite as good as server side shattered, because less optimization is performed on the model before streaming.
Below is an example of an XML product structure file in its entirety. While we discuss some of the tags in more detail in another chapter here, we provide a quick "recipe" for creating one yourself:
- Start by creating an empty "Root" and "Modelfile" tag
- Each "ProductOccurrence" tag is essentially a node in the model tree of the HOOPS Web Viewer component. The "id" attribute represents the nodeid of the node and has to be unique. The children of a ProductOccurrence node are referenced by the "Children" attribute as a list of nodeids separated by spaces. In the XML they point to other ProductOccurrences.
- Don’t worry about the LayerId, Style, ExchangeId, isPart and Behavior attributes for now. Just set them to the following defaults:
- The "FilePath" attribute is optional when you are creating your XML data. When importing a CAD model, it represents the location of the original CAD file corresponding to the node.
- The Transformation tag is used to set the relative 4x4 transform matrix for this node (if any).
- At the "leafs" to the model tree, you have to use the "InstanceRef" attribute to point to the ProductOccurrence representing the actual SC model associated with that node. This "part"-level SC model can be instanced multiple times in the model.
ProductOccurence Id="2" Name="HOUSING(HOUSING.1)" ExchangeId="" LayerId="65535" Style="0"Behaviour="1" FilePath="C:\test\housing .CATPart" InstanceRef="17" IsPart="false">
<Transformation RelativeTransfo="1 0 -0 0 -0 1 0 0 0 0 1 0 21.5 -0.5 -0.310000002384185791 1"/>
In the above example, we have created effectively a new node with nodeid 2. It’s a leaf node that points to part-level ProductOccurrence with Nodeid 17. It also includes a relative transformation that will be applied to the part instance.
- The ProductOccurrence representing an instanced part will have the "External Model" tag as one of its children. The "Name" attribute represents the name of the SC model that will be attached at that node. Inside the "External Model" tag is also a bounding box tag that is optional, but should be supplied for optimal streaming/loading performance.
This is the ProductOccurrence pointing to the actual SC model. It can be instanced multiple times throughout the Product Occurrence hierarchy. The name of the SC model (as referenced in the ExternalModel tag) is "housing .CATPart"). When generating a shattered model via our conversion tool the name of the SC models will be the same as the name of the original CAD part.
With this "recipe" you should be able to generate your own XML Product Structure XML
Using HTTP Compression to Reduce Resource Size
The XML file for complex assemblies with many parts can grow quite large. As this file grows, the time to transfer the resource to the client for processing increases, degrading the user experience as they must wait longer before seeing something on the screen.
HTTP Compression is an easy way to gain a performance boost when dealing with large XML Assembly files. This scheme is implemented at the server or browser level, and does not require modification to client-side code. When compression is enabled, a compression algorithm is applied to the data on the server before it is sent to the client. The encoding is negotiated between the browser and server.
In the image below, an XML file for a large Assembly is 11.6mb. The response sent back to the client is ~717kb while the resource size is 11.6mb. Examining the response headers, we can see that the content-encoding is set to gzip while the content-type is application/xml.
The steps required to enable compression will vary depending on your server and framework. However, you must ensure compression is enabled for xml files.
SCS XML loading with Cutoff Scale
When using XML loading with a cutoff scale, SCS files will only be requested when they are within the view frustum and also have a projected size greater than the stream cutoff value. Files that pass the cutoff test are prioritized by their projected size, which is recalculated as the camera changes. Using this mode can reduce the amount of resources required when viewing large assemblies by not loading and rendering inconsequential or parts outside the viewing frustum. When using this mode, it is important to note that the promise returned by the appropriate loadSubtreeFromScsXml method will not return until all files specified in the XML Product Structure have been loaded. If you need to load another model before all files specified in the XML Product Structure have loaded, use the Model.clear method and wait on the returned promise before making additional calls to the Model.loadSubtree family of methods.
Stream cutoff mode is disabled by default for SCS XML loading. To enable it, set the streamCutoffScale property of your viewer configuration object when creating your WebViewer or call setStreamCutoffScale directly before calling the appropriate loadSubtreeFromScsXml method. Additionally, this mode requires that bounding information be present in your XML Product Structure.