Blast from the Past: History and Sketching

[editor] With this article I reach back to consider some of the contradictions of sketching in a history-based system. If history isn’t necessary for sketches, why should it be needed for other constructions? Parts of this have been edited to fit with current realities, it was originally published 3 years ago.[editor]

I’ve been thinking a lot about history modeling, and history-free modeling. I’ve also been thinking about why sketches in history modelers are somewhat hypocritical about the whole history deal. I mean, the sketch entities within a single sketch are not history based. The relations aren’t history based. Technically, on some level that the user isn’t meant to know about, it does matter what order things are drawn in, but even if we knew about that, it would be pretty esoteric.

Just imagine for a second that all of your sketches were history-free as they relate to other sketches. They have to have some relation to history as they relate to solids and surfaces, because of the whole parent/child thing. But all sketches would be basically just one big sketch on several different planes.

If all of your sketches were piled into a single 3D sketch, you would have the advantage that there would be no history conflicts between sketches. You know, like you want one entity to drive another, but in order to make that happen, you have to remove a bunch of relationships, redo a plane definition, and then reorder a sketch and a plane and recreate a pile of sketch relations. Sometimes a feature gets thrown in there, and a sketch is dependent on a feature which is dependent on another sketch, so reordering becomes even more tedious.

Think about it. What advantage do you get from your sketches being “history dependent”? I don’t think you get any. In “classic orthodox history-based modeling”, you have one sketch, one feature. A sketch on a different plane means an additional sketch. You have one sketch for a sweep path, and another for a guide curve, even if they are coplanar. But “classic orthodox history-based modeling” has been going by the wayside, if you haven’t noticed. Multibodies, regions/contours, the SelectionManager, extruding from a 3D face or 3D sketch, they all work to undermine the “classic orthodox history-based modeling” to the point now that people are only orthodox out of habit, or a belief in “best practice rules”.

And then we can take the argument one level further to assemblies. Assemblies are only history-dependent in special circumstances. If Part1 makes a sketch relation to a Part2 edge in the context of an assembly, and later the referenced edge of Part2 is removed by a fillet, you’ve got a dangling sketch relation. That’s because there is no such thing as inter-part history in an assembly. And thank goodness. How complicated would that be?!?

Solid Edge has this thing called the Blue Dot, which puts all sketches it touches on an equal footing, history-wise. So if you make a mesh of sketches to create something like a Blue Surf in Solid Edge, the order of the sketches doesn’t matter at all if you put a blue dot where they intersect. It’s a beautiful idea when you run into it, and you realize the freedom you gain, and that you have lost nothing. It’s hard to find reference info on this function.

If I were to create a new CAD system from the ground up, the first thing I’d do would be to just allow sketching where ever you want to sketch, and to eliminate the concept of curves as we know them in SolidWorks (all curves would be sketches). So there would never be any history-based conflict between sketches, and all of the special-case problems would disappear. Sketches also would not be “modal”, that is to say that they would always be “on”. And sketches would be able to have both parent and child relationships with the solid, which would create the same kind of circular relation possibilities that we now have with assembly in-context modeling, but there would be some fast and easy visual way to identify parents and children.

How much time do you waste exiting one sketch, waiting for the model to rebuild, then opening another sketch, waiting for the model to build back to that point, making a change and exiting again, rebuilding the model yet again? That’s a huge amount of wasted time. How about make a change to the sketch, make several related or unrelated changes to sketch geometry, and when ready, click on an update button. All the features related to changed sketch entities update. Nothing updates until you tell it to, and you don’t have to jump “in” and “out” of sketches, waiting for unnecessary rebuilds. That would be a huge improvement in workflow and time, even with a fully history-based modeling system.