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.