I can get SolidWorks files down to under 100k if the feature tree is less than one “page”.
Note that this, an my comment in the previous thread, are “work-arounds”. These are things that would be better if they were part of the software (a checkbox in save-as sure would be quicker than the method I detail in the link above).
As a whole I agree with all of the sentiments in Matt’s post.
I would love a save as compressed function. Solidworks file size is a problem for me. I sometimes have only a slow and expensive satphone data channel. The actual information content of a solidworks part is very small. It is just the features and relations of sketches, and the selections and parameters of features and bodies. My workaround is to suppress all features of a solidworks part and save. Then I run UnFrag to remove the Widows compound file debris. The resulting file is vastly smaller. The recipient must open the file and unsupress all and the part is resurrected. I have some parts where the Solidworks file is 6.3MB and reduces to 800KB. The true information content is probably only 8KB.
In addition to addressing the primary attack points of Siemens’ marketing (complexity of dependency management and time waiting on rebuild – both valid complaints), other history-based (h-b) CAD companies could also bolt on direct editing tools. SW already has some (freeform, and I’ll add flex for spite). Featureworks could be a foundation for the on-the-fly feature and parameter recognition stuff similar to what ST uses.
In addition to shoring up the weaknesses in h-b modeling, the strengths of the paradigm could be extended. Logical extensions of parametric features like DriveWorks could be driven further towards mainstream, as well as design optimizing analysis tools. These just won’t work with direct modeling. But SE and used-to-be-UG still have their h-b tools intact, so this might be nothing more than a marketing ploy against the direct editing marketing hype.
H-b modeling could also be extended to the point where components and features know what their real-world function are, and contain the relevant non-geometric parameter data. Imagine something like a motor component that has data about it’s torque and power characteristics. With appropriate tools in the CAD system, the motor component could raise an error if it is in an assembly with mismatched performance requirements (or resize itself, it it’s configurable). Similar ideas could apply at the feature level. But then, this is an enormous new layer of complexity for the casual-user-who-shouldn’t-have-his-fingers-in-the-engineer’s-stuff-anyway.
Another way to reduce the pains of h-b modeling is to find parallelism in rebuilds to take advantage of multi-core (and coming many core) processing hardware.
Freezing features and manual rebuild are good ideas, but on some level they are Band-Aids for a bigger problem. SW is stupid about when things really need to be rebuilt. In addition to the huge problem that is, I have a theory that this may be one reason rebuilds aren’t multi-threaded yet. Nobody has done the work on how to figure out what is correctly rebuilt and what is not in order to make the models thread-safe. The modeling kernels themselves have only achieved thread-safety fairly recently. So work on this may not have been practical. Of course, that’s my uneducated speculation.
I’m posting mostly as a response to Rick. I know we’ve talked about this on the forum about a year ago, but check out this link for a way to minimize your file size: http://solidmentor.com/modules/wiwimod/index.php?page=SavingForOnlineCollaboration
I can get SolidWorks files down to under 100k if the feature tree is less than one “page”.
Note that this, an my comment in the previous thread, are “work-arounds”. These are things that would be better if they were part of the software (a checkbox in save-as sure would be quicker than the method I detail in the link above).
As a whole I agree with all of the sentiments in Matt’s post.
I would love a save as compressed function. Solidworks file size is a problem for me. I sometimes have only a slow and expensive satphone data channel. The actual information content of a solidworks part is very small. It is just the features and relations of sketches, and the selections and parameters of features and bodies. My workaround is to suppress all features of a solidworks part and save. Then I run UnFrag to remove the Widows compound file debris. The resulting file is vastly smaller. The recipient must open the file and unsupress all and the part is resurrected. I have some parts where the Solidworks file is 6.3MB and reduces to 800KB. The true information content is probably only 8KB.
Poke my thinker twice today will you?
In addition to addressing the primary attack points of Siemens’ marketing (complexity of dependency management and time waiting on rebuild – both valid complaints), other history-based (h-b) CAD companies could also bolt on direct editing tools. SW already has some (freeform, and I’ll add flex for spite). Featureworks could be a foundation for the on-the-fly feature and parameter recognition stuff similar to what ST uses.
In addition to shoring up the weaknesses in h-b modeling, the strengths of the paradigm could be extended. Logical extensions of parametric features like DriveWorks could be driven further towards mainstream, as well as design optimizing analysis tools. These just won’t work with direct modeling. But SE and used-to-be-UG still have their h-b tools intact, so this might be nothing more than a marketing ploy against the direct editing marketing hype.
H-b modeling could also be extended to the point where components and features know what their real-world function are, and contain the relevant non-geometric parameter data. Imagine something like a motor component that has data about it’s torque and power characteristics. With appropriate tools in the CAD system, the motor component could raise an error if it is in an assembly with mismatched performance requirements (or resize itself, it it’s configurable). Similar ideas could apply at the feature level. But then, this is an enormous new layer of complexity for the casual-user-who-shouldn’t-have-his-fingers-in-the-engineer’s-stuff-anyway.
Another way to reduce the pains of h-b modeling is to find parallelism in rebuilds to take advantage of multi-core (and coming many core) processing hardware.
Freezing features and manual rebuild are good ideas, but on some level they are Band-Aids for a bigger problem. SW is stupid about when things really need to be rebuilt. In addition to the huge problem that is, I have a theory that this may be one reason rebuilds aren’t multi-threaded yet. Nobody has done the work on how to figure out what is correctly rebuilt and what is not in order to make the models thread-safe. The modeling kernels themselves have only achieved thread-safety fairly recently. So work on this may not have been practical. Of course, that’s my uneducated speculation.