Stream Cache Workflows
This document outlines the different workflows and methods of storing and accessing the Stream Cache representation of a CAD assembly.
In monolithic mode, a CAD assembly is represented as a single Stream Cache Model. The tessellated geometry, the assembly tree and all non-tessellation related data (PMI, measurement data, views, user attributes, etc.) are stored within this single model. Depending on various Viewer settings, certain data within the Stream Cache Model will reside on the server and may be requested "on-demand" (for example, user attributes), while mesh data is usually streamed in a prioritized fashion based on the current camera. Depending on the stream mode, geometry with a "hidden" default state might not stream to the client until the mesh becomes visible.
A Stream Cache Model can be written as an SCS (Stream Cache Single) file, which is a standalone, non-streamable single-file version of the Stream Cache Model. Using models in this format does not require the Stream Cache Server and can either be served from any standard web server or loaded directly from the local file system.
converter --input "cadassembly.CATProduct" --output_sc "mymodels\cadassembly" // creates a single SC model directory
Shattered mode refers to the ability to split a CAD Assembly into separate files and (largely) retain its original hierarchy. This approach to storing CAD data allows for updating of individual components of a larger Model without having to reconvert the whole Assembly.
Creating the Shattered Parts
The first step is to use Converter to build a Stream Cache (SC) model file for each part of the assembly and an XML file containing its structure. By providing an output directory for the converted parts with the --prepare_shattered_parts command-line option, the resulting SC model parts will be stored with the native CAD part filenames. To avoid naming conflicts, the relative path from the head of the assembly to the filename is appended.
The XML referencing the SC part is created by specifying --prepare_shattered_xml. The generated XML file contains the assembly structure which references the SC model parts and will use an "external model" markup to specify those dependencies. While the XML file is created for you when importing a CAD Assembly via Converter in most real-world scenarios, this file would have to be generated by the customer based on the desired configuration of the assembly.
<ProductOccurence Id="7" Name="" Behaviour="1" IsPart="false"> <ExternalModel Name="Cube.par"/> </ProductOccurence>
In this example "Cube.par" is the name of the native CAD part, and becomes the name of the generated SC model part.
Creating a Master SC Model
To view a shattered assembly created via the process above we need to create the SC equivalent of the XML file generated in that process. To accomplish this, Converter needs to be called with the following options:
--sc_shattered_parts_directory: Directory containing the SC part models. --input_xml_shattered: Path to XML file. --output_sc_master: Name of the master SC model.
Note: The master SC model will only contain links to its external model dependencies – there is no need to rebuild the master SC model if the content of the external models changes.
Additional Use Cases
An external model link can point to a full monolithic assembly SC model. In the example below, a full car assembly that was converted to a monolithic SC model called "car" is referenced in the XML file via an external link.
<!--HC 4.9--> <Root> <ModelFile> <ProductOccurence Id="0" Name="assembly" Behaviour="1" Children="1 2"/> <ProductOccurence Id="1" Name="child_1" Behaviour="1"> <ExternalModel Name="car"/> </ProductOccurence> <ProductOccurence Id="2" Name="child_2" Behaviour="1"> <Transformation RelativeTransfo="1 0 0 0 0 1 0 0 0 0 1 0 0 -100 0 1"/> <ExternalModel Name="car"/> </ProductOccurence> </ModelFile> </Root>
You should get the following output:
One current limitation of the shattered assembly approach is the handling of per-instance colors.
In the below example a model consists of four cubes, each one an instance of the same part but with a different color.
In shattered mode, however, the four cubes are all the same color.
This limitation currently exists only when using different materials on multiple instances.
If materials are set within the assembly and only affect a single part, then the behavior will be correct. When we build the shattered parts we bake the fully resolved materials into each part, resulting in the same materials applied to multiple instances.
We plan on improving this behavior in an upcoming release of Communicator.
Assembly features refer to modifying a part (thus applying features) within an assembly.
Using the cube example once again, consider the following four cubes:
In the native CAD software a fillet is applied to two of the cubes:
In this case, the cube part itself is unchanged – it remains a cube without a fillet. The native CAD software will add the fillet to the assembly data, which means that the same part could have multiple representations: One from the part itself, and one from the assembly.
Currently we support this in monolithic mode, but not in shattered. In shattered mode, you'll get the unmodified parts, so in this example, you'll get four cubes without a fillet.