How would you improve history-based modeling?
Thanks to the comment from Dale Dunn from the previous post for pointing out that the main problems with history modeling are really with the implementation. It is possible that other implementations of history modeling don’t have the same problems.
With new modeling paradigms (or old paradigms with new interest) out there, history modeling is going to have to prove that it is up to the challenges of the 21st century. In order to do that, it is the old “evolve or perish” mantra. History modeling has value, but does it have more value than other ways of doing things?
Let’s assume that the history-based idea as implemented in SolidWorks causes some inefficiencies. Let’s say that we don’t want to throw away the whole idea yet, we just want to update it so that it fits users needs rather than some developer’s fixed idea of what history-based modeling “should” be, or an industry tradition. How would you fix SolidWorks history modeling if you could?
Straighten the tree
The first thing that I’d do, and I’ve suggested this before, would be to completely straighten out the feature tree so that it can be shown as a straight history list without any of the counter-intuitive twists added by the reverse dependencies exhibited by how features vs sketches are shown (child on top, parent indented underneath). I’d also want to be able to manipulate the features in this state.
SolidMap-like display
For a while there was a product called SolidMap. I’m not sure what happened to it. I gave it a rather bad review here, but that post isn’t available anymore. Here’s a review from Jeff’s Blog. Again, a lame implementation of a great idea. It graphically showed relations between parts or features. In order for model history to be a useful tool rather than a millstone around your neck, you need to have options like this.
With these two ideas, straight tree and SolidMap, I would want them to be options in addition to the current scheme, not replacements.
Freeze features
The second thing I’d do would be one of the ideas suggested by commenter Kevin Quigley. You really need to be able to freeze all or a portion of the history. To some extent you can already do this by using inserted parts, which is a technique I’ve used to cut down on rebuild times by segmenting the rebuilds, but it is more than a little clumsy. It sounds like this is the same technique commenter Charles Culp is talking about. Let’s say you could just make a folder and freeze the features in that folder. SolidWorks uses Parasolid body data to represent the content of the frozen folders, and integrates the active parametric history-based data with the frozen bodies.
It may or may not be obvious, but SolidWorks data in the end is just dumb Parasolid body data. SolidWorks makes a dumb body intelligent by updating it using the parametric relations and feature definitions. It gives you detailed control over all the geometry, but it also implies the need for a feature order, which is where we get history from.
Manual rebuild
Similar to the freeze features idea is the idea that the user should be able to tell SolidWorks when to rebuild instead of automatically rebuilding whenever you twitch. And maybe the ability to rebuild only portions of the tree would be nice too. There might be some limitations, such as if you froze a child, it’s parent might need to be frozen as well. Anyway, some things in the current implementation of rebuilding just don’t make sense, like rebuilding when suppressed or failed features are deleted or reordered, or when features with no children are changed. The biggest case against history modeling is the rebuild times. There are a lot of low-hanging opportunities for SW to improve things in this area.
This would include suspending rebuilds when exiting edits to sketches and features. Maybe even allowing the user to go directly from the sketch to the feature PropMgr even for an existing feature (without the intermediate steps of exit sketch and enter feature).
Limit saved data
What kind of data is really in SolidWorks files? If you have configs, SW stores parasolid data for each config. Plus it stores display data, not just 2D thumbnails, but 3D tessellation as well. Some versions saved parasolid data for rollback states. 3rd party data can be put in, Cosmos, CAM, Photoworks, etc… All of this stuff is put in there for a reason, but is it really a reason that matters to you? Does something else matter more? I’m sure there is a lot of stuff in there that users don’t care about at all. Applications like Eco-Squeeze are officially panned by SolidWorks, but they strip out much of the unused or onwanted data. Why can’t SolidWorks allow users that type of control, instead of forcing on us one-size-fits-all data bloat?
It’s understandable that it is faster to read data than it is to recalculate it, and that hard drive space is cheap these days. Unfortunately, those ideas don’t completely represent the range of users concerns. Transmit time for people who work across vpn or ftp is a big consideration. Tons of people work remotely in this age, and when you don’t have unlimited bandwidth, file size, especially the file sizes we have grown to expect from SolidWorks, can become a problem.
=================================
I know these suggestions mean that users would have more control because they limit the automation of the software, which seems to be opposite to the current trends at SolidWorks, but hey, we’re dreaming, so we might as well go all out. Having a wider user base does not just mean that they have to dumb down the software and automate everything, I think if they are going to avoid alienating power users, they have to consider higher levels of functionality and user control.
In all of this, we need to keep in mind that Catia V6 is around the corner. Wikipedia points out that the V6 kernel is based on direct editing (in the Future Implementation section). Of course I don’t have any type of real information from DS on this, but I expect it to apply some lessons learned to the Synchronous Technology scheme. It remains to be seen what if any functions from V6 will be pushed down into SolidWorks, but I expect that to compete with Solid Edge, coupled with the newly chummy relationship between SW and DS, SolidWorks will shortly get a V6 make-over.
While assembly and drawing documents get faster by SolidWorks using clever tricks (lightweight, configurations, SpeedPak), the part documents just get slower due to automation bloat.
How would you update history modeling in SolidWorks? This is a collaborative effort, leave your ideas as comments.
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.
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.
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.