Eyeshot 2021 introduces a new feature that allows you to save the entire scene to multiple files using the Eyeshot proprietary file format.
With this feature, you have the flexibility to work on a file representing a single component and observe its changes when loading the entire assembly (video), or you can choose to load only a partial assembly, loading specific components as needed (video). This selective loading capability is especially beneficial when working with large assemblies, as it helps optimize performance and streamline the workflow.
This new feature provides enhanced control and efficiency when working with complex assemblies, allowing you to focus on specific components while still maintaining the overall context of the assembly.
| Assembly | |
| Component | |
| Assembly with only one Component loaded (Lazy loading) |
General concepts:
-
Assembly: When a scene is built using nested blocks, it is referred to as an Assembly. The Assembly represents the overall structure of the scene, composed of various components.
-
Node: Each individual component within the Assembly is referred to as a Node. Nodes can be thought of as building blocks that make up the larger Assembly structure.
-
Leaf: A Leaf is a type of Node that does not contain any references to other blocks.
-
Mixed Node: A Mixed Node is a type of Node that contains a combination of entities and references to other blocks. It represents a component within the Assembly that includes both internal geometry and dependencies on other blocks.
Starting from Eyeshot 2021, a specific file format is employed for managing Assemblies.
Leaves, which are standalone components, are stored as Standard Eyeshot files (let's say with EYE extension).
On the other hand, Nodes, including Mixed Nodes, are stored with the new Assembly format (let's say with EYEASM extension). The Assembly format includes information about the paths for all the components that compose the assembly, enabling efficient management of the overall scene structure.
Relevant classes:
devDept.Eyeshot.Translators namespace
- WriteMultiFile: helper class to save the scene in multiple files.
- ReadMultiFile: helper class to open a fully shattered file.
- LazyLoading: helper class for loading partial MultiFile.
Code snippets:
Save MultiFile
WriteMultiFile wmf = new WriteMultiFile(new WriteMultiFileParams(design1), "assembly.eyeasm" );
wmf.DoWork();Read MultiFile
ReadMultiFile rmf = new ReadMultiFile("assembly.eyeasm");
rmf.DoWork();
rmf.AddTo(design1);
model1.Invalidate();
Read MultiFile with LazyLoading
ReadMultiFile rmf = new ReadMultiFile("assembly.eyeasm") {StructureOnly = true};
rmf.DoWork();
rmf.AddTo(design1);
LazyLoading lazy = new LazyLoading(rmf.TreeItems, rmf.FileSerializer);
lazy.SetBlockName("51729");
lazy.DoWork();
lazy.AddTo(design1);Additional notes:
- Thumbnail: By default, the thumbnail is stored only for the main file in Eyeshot.
However, you have the option to generate thumbnails for the other files as well by setting WriteMultiFileParams.UpdateThumbnails = true.
It's important to note that enabling this option can significantly increase the processing time, so it should be used with caution. - Single file update: If you have already created a set of multi-files representing the scene and only a single Block has been updated, you can use WriteMultiFileParams.BlockName to specify the name of the block.
This allows you to update only the file corresponding to that specific block, instead of regenerating the entire set of multi-files.
This feature provides a more efficient way to manage updates and modifications within a multi-file scene, allowing you to selectively update individual components without the need to recreate the entire set of files. - Directory and File Creation: All the files generated by WriteMultiFile are stored in the same directory as the file specified in the WriteMultiFile constructor. If the specified path or folder does not exist, WriteMultiFile will attempt to create them.
- Handling Forbidden Characters: If a Block contains characters that are not allowed in Windows file names, WriteMultiFile will automatically rename the Block to ensure successful storage of the file on disk.
- Object Graph Preservation: The object graph for entities within a Block is preserved but limited to the same file. Cross-references between entities in different files within a multi-file structure are not maintained.
- Custom Path for Components: If you need to store a specific component on a different path, you can set the Block.FullPath property. The FullPath should include the absolute path, filename, and extension for the component (video).
- Moving Assembly Files: If you move the assembly files to a different path, the ReadMultiFile class will attempt to rebuild the paths for components located in subfolders (video). The Block.FullPath property will be updated with the new full path if the operation is successful.
If any failures occur during this process, a log will be written. - Performance Considerations: Files stored with mixed nodes (containing both entities and references to other blocks) can slow down the LazyLoading due to the need to load the associated entities. For better performance, it is recommended to build a tree structure that contains only nodes (blocks) or leaves (standalone components).
- Purge Option: The "Purge" option is useless when writing a multi-file structure because each file already contains only the necessary collection of items related to the Block's entities. Therefore, using the Purge option in this context has no effect.
- Drawings Control: The WriteMultiFile class does not support the preservation of Drawing control. This means that any associated Drawing will not be included in the multi-file structure.
WriteFile vs WriteMultiFile
When reading a scene that was stored using the WriteFile class (Standard Eyeshot file) instead of the WriteMultiFile class (Assembly Eyeshot file), there are two major differences to note:
- Root Block's Name: The name of the root block may be different. This occurs because when writing the scene using WriteFile, the root block takes the name of the chosen file for saving.
- Order of Items in Master Collections: The order of items in the master collections could be different. This is because WriteMultiFile stores the items based on the assembly tree order, whilst WriteFile does not consider the assembly hierarchy.
Example
We add nested blocks named "one" and "two", and then the parent block named "box".
The whole assembly was stored using the name "MultiFileFullPathTest.eyeasm".
The image below shows the differences between the original scene and the one after reading the assembly file.
A good starting point for playing with this new feature is the AssemblyDemo source code sample.
UNIT TESTING
We perform an extensive number of tests to verify backward reading compatibility for previous versions.
If you decide to extend the functionality of Eyeshot or make customizations, we highly recommend conducting similar tests to maintain backward compatibility.
By running unit tests on your customizations, you can ensure that they work seamlessly with different versions of Eyeshot.
We encourage you to share your unit test project with us. This will enable us to notify you of any changes that might impact your customizations.
By staying informed about updates and changes, you can adapt your customizations accordingly and ensure a smooth transition between different versions of Eyeshot.
Comments
Please sign in to leave a comment.