USER FORUM
(you are viewing a thread; or go back to list of threads)
Friendlier file format for version control? (by stubeans)
I see a lot of repeated data in my slvs files. The last portion of the file looks like it contains a lot of calculated data that, when removed, don't seem to break the file.
The slvs file for a simple hollow cylinder is 1382 lines long. Changing the outer diameter constraint results in a file with 280 different lines. Ideally, for me, it'd have only one line difference.
What are your thoughts on a file format where constraint parameters are only mentioned once? A file containing just enough information to recreate the model. And if saving calculations is needed for other reasons, maybe having them in a separate file. Like same name different extension? So we could git ignore those files.
The slvs file for a simple hollow cylinder is 1382 lines long. Changing the outer diameter constraint results in a file with 280 different lines. Ideally, for me, it'd have only one line difference.
What are your thoughts on a file format where constraint parameters are only mentioned once? A file containing just enough information to recreate the model. And if saving calculations is needed for other reasons, maybe having them in a separate file. Like same name different extension? So we could git ignore those files.
(no subject) (by whitequark)
> The last portion of the file looks like it contains a lot of calculated data that, when removed, don't seem to break the file.
This data is needed to link a slvs file into another during assembly. Unfortunately the existing architecture of SolveSpace does not allow to recalculate that when opening the assembly sketch.
> And if saving calculations is needed for other reasons, maybe having them in a separate file. Like same name different extension?
That would be a rather nasty breaking change for comparatively little benefit. The reason is that the rest of the format is not VCS-friendly either. Try resizing one little thing and see how the change propagates across the .slvs file.
I recommend: 1) marking the slvs file as binary in git; 2) using the upcoming command-line tools to perform a visual diff of 2d renders (at some point visual diff of 3d renders, like GitHub diffs STL files, could be possible too). The main remaining issue is that none of the git tools support anything richer than text for diffs, but I'll leave fixing that to someone else :)
This data is needed to link a slvs file into another during assembly. Unfortunately the existing architecture of SolveSpace does not allow to recalculate that when opening the assembly sketch.
> And if saving calculations is needed for other reasons, maybe having them in a separate file. Like same name different extension?
That would be a rather nasty breaking change for comparatively little benefit. The reason is that the rest of the format is not VCS-friendly either. Try resizing one little thing and see how the change propagates across the .slvs file.
I recommend: 1) marking the slvs file as binary in git; 2) using the upcoming command-line tools to perform a visual diff of 2d renders (at some point visual diff of 3d renders, like GitHub diffs STL files, could be possible too). The main remaining issue is that none of the git tools support anything richer than text for diffs, but I'll leave fixing that to someone else :)
(no subject) (by Jonathan Westhues)
Even if SolveSpace could regenerate imported models (which would be nice, for a few different reasons), you'd still want to cache a NURBS or mesh model of the part. Load times for complex assemblies would otherwise become extremely long, as every part and sub-part regenerated. Essentially all commercial parametric CAD systems keep that cache.
(no subject) (by whitequark)
> 2) using the upcoming command-line tools to perform a visual diff of 2d renders (at some point visual diff of 3d renders, like GitHub diffs STL files, could be possible too)
This tool is now implemented.
This tool is now implemented.
Post a reply to this comment: