In the beginning Save As was a bit complicated in that it would ask the user to save all of the files associated with the model so they would be different from the original model. We had simplified the process that Save As would just rename the SMTK model and would not touch the other associated files like Auxiliary Geometry images and vtp files.
The above interpretation assumed that only the SMTK model file was being changed and that we didn’t want to unnecessarily copy files (which in the case of mesh files could be large).
For polygon models the above seems to work well but things began to go south with discrete models. The main reason is that the native model information for polygon models is stored in the SMTK file while for discrete models the information is stored in two places: the SMTK file and the discrete CMB file (in version 2.0 of SMTK the cmb file will be replaced with a SMTK mesh file but that will not change the fact that the data is stored in 2 files for each discrete model). The same is true with respects to CGM and Exodus models.
Currently when the user changes a discrete model and does Save, it is expected that both the native file and the cmb file are going to be modified. However, when the user does Save As, the system only changes the name of the SMTK file prior to saving and therefore the native model filename is not changed but its contents is modified. This means that the old SMTK mode file (under its original name) is no longer valid since its native model file “no longer exists”.
To address the above I propose that the native file and the smtk file should have the same base name when importing and saving in a CMB application. To do this the following rules would need to be adhered to
- When opening a non-smtk file the created SMTK model should be of the same name. So if I read in foo.3dm, the model created should also be named foo instead of Model A
- When doing a Save As, both the smtk and native model files should get renamed
Note that assemblies might get a bit tricky since a single smtk file might refer to a set of native model files.
I think the above behavior would be what the user expects.
I would also like to suggest we change Export Model to be Save As Directory - meaning that a new directory will be created and all files related to the model (or maybe even all associated resources like attribute system) be stored under that directory creating the self contained package export is suppose to create.
There is another potential problem concerning the non-native model files associated with a SMTK model. These currently include images and point clouds. In present workflows there are no operators to modify these files but that will not always be the case. For example both glyph generation and point could modification operations (like terrain extraction) will create and modify the auxiliary geometry files. So we will find ourselves in a similar situation as we currently have with the smtk and native model files. Meaning that we have a smtk model foo with several aux geometry files associated with it, the user does a Save As bar (which will fix the smtk and native model files but not touch the aux files) and then modifies the aux files thereby hosing model foo. In this case the safest recourse is the save as directory option which copies all of the files.
One possible way to address everything would be to have the SMTK model to be a directory (and not just a single file). The directory would contain the following:
- the SMTK topological file (which is currently referred to as the smtk file)
- a modifiable native model (or models in the case of an assembly)
- a set of modifiable aux geometry files
If instead of calling it a model file but instead called it a resource collection it could then additionally include:
- a set of meshes
- a set of attribute systems
Note that I used the term “modifiable” when addressing the native model and aux geometry. If the user wanted to have a repository of meshes, native models, and aux geometry that the model references but not duplicated we could support that by having the smtk file refer to files outside of its directory but in that case the file is considered “read only”. For example suppose the user has a directory of step files . A cgm model could just reference a step file without copying it (it just would be in the model’s directory. However, if the user then make a change to the model in ModelBuilder and then does a Save, the modified native model would then be saved in the SMTK model directory.