Build 0.2.0 (Beta 18)
It looks like referenced data file locations are encoded as absolute paths in .sq project files. It would be nice to have paths relative to the .sq file so we can have a project structure like the following that can be easily be moved between machines/data stores.
project_dir/
[list] [*]project.sq
scans/
[list][*]scan001.e57
scan002.e57
…
[/:m][/list:u][/:m][/list:u]
I ran into the problem last night where my sequoia .sq file broke completely because I moved it off the network over onto a laptop, breaking the links to the data files. Would be better if the file could at least open, and I can then re-point to the local files.
Thank you for your suggestion! We have added this to our wish list.
Sorry, how did the file break? I expected it to work how you described: the .sq file should open, and then you should be able to change the Point Loaders to use your local files.
That’s what I observed.
We’ve modified how paths get saved/loaded to support this in the latest build. Any files that are in the same subdirectory or deeper than the .sq file get saved as relative paths, so you can copy or move around the folder containing it.
Cheers,
Mark
That’s great. I’m curious though, what’s the advantage of only using relative paths for files that are next to or below the .sq file?
The reason I ask is that our actual project structure is a little more complicated than the simple example I posted and with the current (0.30) setup we will still end up with broken links. At the top level of our structure we make a distinction between published assets that are immutable and working files that are subject to change so the structure looks like:
So the relative path from project.sq to scan01 would need to be:
../../published/scans/v01/scan01.v01.e57while it’s cached version is at:
./scan01.v01.sprt
Alternatively, if we could manually set the project root directory I could do something like:
PROJECT_ROOT = "project_dir"and the paths would be:
$PROJECT_ROOT/published/scans/v01/scan01.v01.e57
$PROJECT_ROOT/working/sequoia/scan01.v01.sprt
We’ve done another attempt to improve this, as follows:
When saving, the .sq file absolute path is saved in the file, and all other paths are saved as relative where possible.
When loading, if a path exists relative to the .sq file, that path is used, otherwise, the original .sq file path is recombined with the relative path to get the original absolute path.
The effect of this is, files which move around with the .sq file will be treated as relative paths, and any other paths will fall back to absolute. I think this should cover all the styles of workflows reasonably well, how does this sound?
We’ve updated our documentation to elaborate a bit more on this here: rabop.com/temp/Sequoia_Beta/manu … paths.html
Thanks,
Mark
That looks quite nice and pretty comprehensive.
Off hand the only other improvement I could think of would be to make repairing data sources a little easier. For example, extending the first example in the documentation:
If the Assets/Points/ directory starts off with four files somepoints.e57, someotherpoints.e57, plus their associated .sprt caches and you rename the directory to Assets/Scans/ the links will be broken as expected. Pointing to the new location Assets/Points/somepoints.e57 will also repair the link to its cache somepoints.sprt. The links for someotherpoints are still broken though. It would be great if fixing the link for one data object would automatically try to fix any other broken data objects in the project based on that new root directory info.
Cool, I think it would be nice to have any deeper path manipulation be done via script, once we flesh out scripting more. One possibility is to set up the loading so you could augment or replace the relative/absolute path logic with a scripted hook, that does something appropriate for your conventions.
-Mark
It would definitely be nice to have this sort of thing exposed. More generally, this sort of bookkeeping and data management type stuff seems to be what most of my scripts in other applications end up doing a lot of.