Is history-based modeling a flawed idea?

As a prelude to comparing history-based systems to other types of modeling systems, I want to try to spend some time thinking about history-based systems on their own. Specifically, I want to see if without comparison to anything else, the idea of modeling something based on the software sequentially rebuilding geometry from a recipe has any gaping conceptual flaws.  Most of us have lived with this system for years now, whether it is SolidWorks, Solid Edge, Inventor, Pro/ENGINEER or one of several others. I find it is difficult to be objective about it because I’m admittedly too close to the topic to have much perspective. But unless you don’t use anything regularly or are switching regularly between radically different CAD packages, you’re in about the same boat as me.

If you think back to when you were first introduced to SolidWorks, can you still remember the new concepts and vocabulary you had to learn? You’ve got terms like history, feature-based, parametric, associative, solid and surface modeling, and so on. As I remember it, none of this was particularly intuitive. I thought it was cool once I understood the process, but that’s the first thing to be aware of: that history-based modeling involves a process.

Something that has been slightly mind bending for me is trying to separate history-based nature of contemporary CAD systems from those other buzzwords. For example, can you imagine a CAD scenario that uses parametrics, but not history modeling? How about using features without history? Those concepts may be difficult to imagine if you’ve lived in a history-based world for your whole professional life, but we will get around to having a look at those things. For now, I just want to extract the history part of it and look at that by itself if possible.

If you think about what part of the modeling workflow exists specifically because of the history-based nature of SolidWorks, you think of things like:

• FeatureManager
• reordering features
• rollback
• rebuilds, including waits and errors
• parent/child relations

If your experience was anything like mine, when you were first introduced to history-based modeling the topics above weren’t easy to learn. I know I’m constantly doing battle with each item on the list, even after studying history-based modeling for the past 14 years. I frequently refer to the conflict between draft, fillets and shell as “rock, paper, scissors” (the game where each option can either win or lose depending on what the other player chooses), which is primarily due to the effects of feature order, one of the by products of history modeling.

The main difficulty associated with history-based systems has to do with the fact that the process involved with modeling becomes very important. That’s why people say history-based CAD requires a specialist just to understand the modeling process. There is a lot of validity to this complaint. Getting the right process for different types of models is sometimes tricky. We have become familiar with the term “best practices”. What if there were no such need for best practice, because the only thing that mattered was the final product, not the process by which you arrived at the final product?

How about accepting the idea that the model you really want is the finished model, which is just a set of boundary representation (b-rep) faces created by the software. Do you really care how you got to the finished model, or do you just care about the model itself? Lists of features are one thing, but does (”should”) it really matter what order those features were created in?

If you have ever struggled with parent/child relations between features or feature order or broken relations due to features removed or added while in rollback, you have experienced some of the difficulties induced by the history-based nature of the software. Most of us just accept this as part of the price of waking up in the morning and using history-based 3D CAD software because we don’t know anything else.

To be fair, there are also some advantages of history-based modeling. For example, fillets. Whether or not a modeler remembers the order in which fillets are applied, the effects of applying them in a particular order can be seen in the resulting geometry. A history-based system enables you to deliberately alter that order. It turns out that fillets are simultaneously both a strength and weakness of both history and non-history modelers. This seems like a contradiction, but at the end of this series of blog posts, I hope you will agree with me on this point.

So, like the rest of life, history-based modeling has its pluses and minuses. It is a system that has served us well for a couple of decades, and most of us have been able to figure out how to use it profitably in our businesses. However, there are enough examples of painful experiences around working with history-based systems to consider if there might be some viable alternative out there. That’s what the next blog entry will be about – alternative modeling paradigms.