Multi-file and lazy loading

Eyeshot 2021 includes a new feature for saving the whole scene to multiple files using the Eyeshot proprietary file format.
Now you can choose to work on a file representing a single component and see its changes when loading the whole assembly (video), or you can choose to load partially an assembly as well (video). It can be really helpful when handling large assemblies.

Assembly mceclip0.png
Component mceclip1.png
Assembly with only one
Component loaded

(Lazy loading)
mceclip3.png

 

General concepts:

When a scene is built using nested blocks we can call it Assembly.
Using a tree view to better explain the concept, we can call Node each component of the Assembly.
When a nested block does not contain references to other blocks, we call it Leaf.
When a block contains a mix of entities and references to other blocks, we call it Mixed Node.

With Eyeshot 2021, leaves are stored as Standard Eyeshot files (let's say with EYE extension) and nodes (mixed too) are stored with the new Assembly format (let's say with EYEASM extension), that includes also info about paths for all component composing the assembly itself.

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(model1), "assembly.eyeasm" );
wmf.DoWork();

Notes:

  • Thumbnail is stored only for the main file by default, but you can set WriteMultiFileParams.UpdateThumbnails = true for generating it for the other files too. Be aware turning on this option can increase a lot the elaboration time.
  • If you have already created a set of multi-file representing the scene and only a single Block has been updated, you can set WriteMultiFileParams.BlockName for updating only the single file.

Read MultiFile

ReadMultiFile rmf = new ReadMultiFile("assembly.eyeasm");
rmf.DoWork();
rmf.AddToScene(model1);
model1.Invalidate();

Read MultiFile with LazyLoading

ReadMultiFile rmf = new ReadMultiFile("assembly.eyeasm") {LazyLoading = true};
rmf.DoWork();
rmf.AddToScene(model1); 

LazyLoading lazy = new LazyLoading(rmf.TreeItems, rmf.FileSerializer);
lazy.SetBlockName("51729");
lazy.DoWork();
lazy.AddToScene(model1);

 

Additional notes:

  • All the files are stored in the same directory of the file specified in the WriteMultiFile constructor. 
  • If a path or folder does not exist, the WriteMultiFile class will try to create it.
  • If a Block contains a Windows's forbidden char, it will be renamed for allowing the storing of the file on disk.
  • The object graph for the entities is still preserved but only within the same file.
  • If you need to store a component on a different path, you can set it to the Block.FullPath property, that must contain the absolute path including filename and extension (video).
  • If you move the assembly files to another path, the ReadMultiFile class will try to rebuild paths for components located in subfolders (video).
    A log will be written if it fails, otherwise the Block.FullPath property will be updated with the new full path.
  • A file stored with mixed nodes can slow down the lazy loading because the entities will be loaded as well. For better performances, please consider building a tree containing only nodes or leaves.
  • 'Purge' option is useless writing a multi-file because every file already contains only the master collection's items related to the Block's entities.
  • Drawings control is not supported.

WriteFile vs WriteMultiFile

Reading the same scene stored using WriteFile class (Standard Eyeshot file) rather than WriteMultiFile class (Assembly Eyeshot file) you could find 2 macro differences:

  1. The root block's name can be changed. That's because writing it, it got the name of the file chosen for saving the file.
  2. The order of the items in the master collections can be different. That's because WriteMultiFile stores them according to the assembly tree order.

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 differences among the original scene and the one after reading the assembly file.

A good start point for playing with this new feature is the AssemblyDemo source code sample.

 

UNIT TESTING

We perform a huge number of tests to verify backward reading compatibility for previous versions.
If you choose to extend it, please consider doing the same and feel free to send us your unit test project to be notified of any changes that will affect your extended format.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request

Comments

0 comments

Please sign in to leave a comment.