I have a shapr3d design which is huge (converted from Solidprt files).
I organised it in sub-assemblies, represented in folders within the design.
In total it amounts over 1.1GB in size.
To split it I was planning to load the file, delete all but one sub-assembly and then backup the remaining Shapr3d file. And that a number of times until I end up with a Shapr file for each sub-assembly.
I find that after doing this the size of the remaining parts still amounts to the same size (even a slightly bigger).
So it looks like S3D is not clearing/cleaning the info when deleting the sub-assemblies (folders).
After reloading the newly saved file, I find that indeed only the remain ing subassemblies are available, however after again backing up the design in a new shapr file, the size is still exactly the same size as the earlier version.
Loading the file takes about 20 miniutes on my windows workstation. Because of this I would like to split the design, however it does not help at all.
I haven’t tried loading it in my ipad version as I fear that this would take much, much more time given the size of over 1.1GB.
So, what is the advice to split such a huge design in separate sub-assemblies
I tried the same thing on MacOS version, with the same result as you reported : the size does not decrease.
What reduces the size for me is to export in .step and import the .step in a new project.
Thanks, but for such a large project as this, I would loose too much when exporting to step.
@Shapr Could you please explain this behaviour and preferably tell me how to split up a design in manageable parts?
Bumping this one, as I really would like to here from Shapr (@Istvan)?
We definitely delete deleted parts from the database. However SQLite (the database technology under Shapr3D) is trying to be super efficient with CPU cycles, and doesn’t necessarily clean the actual data from the disk, just removes the references from the database. We could do that after every SQLite operation, but we don’t, because it could lead to performance problems. Because of this the actual file size might not decrease when you are deleting parts from your workspace. However, the file size has nothing to do with the iPad’s ability to load the workspace, so feel free to try it Nothing bad can happen.
But… definitely do not export and reimport in STEP format. STEP is an intermediate format used to translate data between CAD systems. That means that all sort of black magic happens when you do that, and as we all know since Harry Potter, black magic can hurt you. If you for any reason want to export and reimport a file in Shapr3D, then it’s strongly recommended to do it using X_T (Parasolid) format which is the native format of Shapr3D, and doing so gives 10 points to Gryffindor. If you do that, it might decrease the size of the workspace file as well.
Thanks @Istvan . That explanation sheds a bit of
light. Just to be sure. Doe SQLite play a role when exporting in native shapr format? Is that actually an export of the SQLite DB?
Yes, basically it is the zipped sqlite db, with some other files.
@Istvan couldn’t you run an SQL VACUUM on save (or at least, have an option to do so)? Auto Vacuum could help, too.
@Pouln Do you have any reference on how you are using subassemblies? My understanding is that such functionality is not yet available in Shapr
I noticed this too but I think I stumbled upon a fix…
(this worked for a small file size model but I guess it should work for larger models too)
I exported a model (in native Shapr3D format) and checked the file size - 283KB
I then deleted ALL of the bodies and sketch planes in the model except for ONE single body and expected to see a drastic reduction in file size.
I exported the model again ((in native Shapr3D format) and checked the file size - 278KB
Hardly any reduction at all right?
Now, hear me out…
I then loaded the loaded the model back into Shapr3D and exported a second time…
(in native Shapr3D format) …and checked the file size - 16KB
It seems that deleted bodies are not ‘purged’ during the first time export but when the model is reloaded and exported a second time then only the remaining bodies (the ones you actually want to keep) are exported.
@Pouln Please let me know if this works for you.
Yes, we could, but it would be quite expensive. Just imagine running a VACUUM on a large design every time after drawing a line. It would be slow and would quickly drain the battery. On the other hand, it’s not really causing issues too often, simply because workspaces tend to grow over time, not shrink.
Yes, because in this case we read the database’s content and then write it out to a new database.
@Istvan I can understand that, but maybe you can give the user the option to clean out the design, by supplying a command to execute the SQL VACUUM?
Based on our experience it would rarely matter at all, and we haven’t heard about any cases so far where this caused any problems.