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.

Hi Matt
I like the way you introduce you next series of articles.
I don’t know how relevant will be my reply to our overall thinking but here I go…
Has you may have understand for now, I’m having done/doing a similar thinking/reflection being involve with SEwST for a couple of months now.
Like you, hope I understand well you article, I try to understand what’s’ behind the concept prior to understand the mechanic. I usually define myself has a process person oppose to a technical person.
This way of seeing make me realize that I had to change the wording I usually use. I mainly realize this while I was build training around Synchronous Technology.
One of the first thing I change, instead of talking about History or non-history, I found out that using «linear modeling» (History) and «non-linear modeling» (non history) seem to better reflect the differences between the two approach. It also helps peoples make a better mental representation of those concepts.
Other part of your article, from how I understand it, should we care more about the travel or the destination?
At this point of my reflection, I am in favor of the travel.
In linear modeling if you didn’t care about the travel (how to get to the final product) and focus too much on the destination, it could be very complex going thru our workflow:
•FeatureManager
•reordering features
•rollback
•rebuilds, including waits and errors
•parent/child relations
In non-linear modeling the impact of the travel is less because the travel could be shorter in many cases to apply changes. On the other hand, this could give the false impression that destination is more important.
You mention best practice and if their a need for those?
I would first point out that many people mistaken best practices and best way to model a part.
Yes there is place for best practices, some may disappear others will change/adapt and new one will rise.
Has is there best way to model part?
I don’t think so. I often say the best way to model a part is the way that will make sure you understand/manage your design especially when it comes time to apply/make changes.
Taking a step back and looking at the big picture ….The game of modeling is play at the edition/modification not at the creation. Create something is easy, where peoples lost time/get complicate is when it comes time to apply modifications, this bring me back to travel or destination?
And I answer travel.
From one of you last post about what people would like to hear/read, people search for destination instead of travel and after that they complain about problems and bog
Looking forward to read your next post.
Solid DNA
I’m a bit lost with the travel vs destination analogies, maybe I need a map
I don’t actually agree with Solid DNA with regards to the “creating something is easy” bit. Maybe for simple mechanical parts the creation part is easy but as soon as you get into consumer products with ergonomic surfaces, moulded rib details etc the creation part is complex. Yes editing is hard too but sometimes you can go straight to the end result.
Also in most industries you fix the primary surfaces (like a car body) and work backwards from them, so there are two editing phases – the first where you are tweaking the visible surfaces and the second where you are tweaking the internals to fit components. If you are really unlucky you need to edit both!
The comment at the start of the post about parametrics and non history is interesting and takes us back to the late 80s with software like Ashlar Vellum where we had wireframe parametrics but no history. In fact you could say parametrics with no history is more of a 2D concept – most 2D systems or AEC systems use this concept now. Take Vectorworks for example, very powerful hybrid 2D/3D parametric objects but little history.
The way I look at it you can have both in most systems anyway, and if you work across multiple CAD platforms you need to do this anyway. As an example my workflow will include roughing out wireframes and 3D curves in something like Ashlar-Vellum Cobalt, maybe surfacing as well, then exporting to SolidWorks. Or, simply roughing out the form in SolidWorks and exporting and reimporting as parasolid.
Might be an odd way to work but it gets around the fundamental problem with all history modellers, that being, if you have issues with the tree you can end up losing the model as it cannot rebuild, or rebuilds in a different way. It also serves to provide a staged data release secure that you will always be able to use the data.
I’ll be interested to see the ST review and how this would work for consumer product design and how it compares to the above process.
****
Kevin,
ST and consumer products is probably not a great fit right now.
Working between different systems is something I think most SW users are not amenable to. It’s expensive, it’s confusing, and it limits the types of changes you can make. If you can make it work for you, that’s great.
I meant to add to my post that one feature I’d love to see in SolidWorks (and other modellers) is a freeze history command. What this would do is let you model up to a point then when you invoke the command it saves out a file – with history – and in your active document removes the tree, leaving you only with the lump or surfaces. The same effect as exporting and importing as I do now.
But the clever part would be to let you go back to the freeze history command in the new tree and open the saved out part with history to make changes, then reapply that new part (with the history removed) to the active file.
Sure this would be a nightmare in terms of internal IDs for the faces but that would at least let you access an updated part without the overhead of a big tree up to that point. Kind of like a two stage history.
The process might also be beneficial for multi user working on the same file.
****
Kevin,
Yeah, I agree with you on the freeze history thing. Sounds like a great idea.
Is history-based modeling flawed? A flawed what? What is it supposed to be that it fails to be? I think it is what it is. It is one way of working with models that has pluses and minuses. So is direct editing modeling, “synchronous technology” modeling or any other [marketing name]-modeling. I don’t think any of the three are flawed. They are what they are. Implementations of any of those in a CAD system may be very deeply flawed.
Is it possible to have parametric features without history? I think not. “History-based” modeling has become a pejorative term for systems where one feature can modify another in an automated way. A feature has input and output and therefor has dependencies. The output is dependent on the input. History is inherent in the process, whether the CAD system manages that or not.
Yeah, we fight with the feature tree, etc. but that is just managing dependencies between features. Errors are broken dependencies, or features receiving input they can’t handle. Non-history modelers just leave all that completely to the user to notice and deal with. It still has to be dealt with, it just doesn’t automatically get an angry red symbol on the monitor.
What truly sucks is when the angry red symbol is actually the result of a limitation or bug in the CAD system. That’s not the fault of the history-based modeling paradigm, though.
It seems that ST is a middle ground between direct modeling and parametric feature modeling. It has strengths and weaknesses of both. I suspect that ST-style model edits could theoretically be captured as parametric features.
I think the real question should be whether the benefits of capturing design intent, feature dependencies, etc. in an automated way is worth the baggage that comes with it.
****
Ok, I agree and disagree. I agree that what I should be talking about is the SolidWorks implementation of the history modeling paradigm.
I disagree that history and parametrics can’t be separated. I will make my case on that in a later blog post. This was a question I had a year ago or so
Kevin,
“import parts…” in SolidWorks makes it so you can split your history into two. I use it for machining and casting drawings all the time. Import the casting (ergonomics) part file into the machining part file (prismatic cuts), and it doesn’t have to rebuild the surfaces.
Most people don’t know this though. I would think this would be a slam-dunk enhancement for SolidWorks. I know it has been mentioned multiple times, I don’t know why it hasn’t been implemented.
To me the biggest issue with the history-less models is the loss of a link between models and drawings. Sure on the surface a lot of it sounds applealing but how much of your design intent do you lose. Without the feature tree you lose the intent you build in by naming features. You lose the ability or at least in cocreate to link a machined part from its raw form ie. casting. It sounds good but to me once you dig down you give up lot of the work savings that drove the appeal to history based modeling.
****
I think you must be talking about a specific software package, because the model/drawing link is not broken by all history-free modelers. Did you say that you work with CoCreate? I worked with that briefly, and thankfully wasn’t scarred for life with the memory. Do you still use Me-10 for drafting? That’s where the break is, I think. Me-10 is a separate 2D package. Other direct edit systems don’t necessarily have that limitation.
Matt , I can’t follow you when you say that
all you want is a Brep model at the end.
Yes but what is the end ? How can you say
that you will not need to modify it next
week ?
Also the relationships you setup between
the features are design intent as much as
the Brep shape! If you constraint the
thickness of a shell to be greater than
an hole diameter you are putting information
in the design. As I already expressed in
another post I also would add something to
the last stamenent of Dale Dunn : not only
it is yet to be understood if the automatic capturing of design intent worths the baggage , but also how can it
really intepret the designer’s intent.
****
Roberto,
Thanks for the comment. A month ago, I think I looked at things the way you do now. I don’t need to try to make you see things the same way I do, but I want to at least explain why I think the way I do now.
If you could edit the dumb b-rep as well as if it were a feature based history model, would there be any advantage to the overhead that the feature/history model drags around?
What if you could set up relationships on the finished b-rep instead of using intermediate sketches and feature definitions? What if you could put geometrical relations, dimensions, and equations directly onto the part faces/edges?
Even after teaching for years and writing books on SolidWorks, I’m still a little fuzzy on what exactly is “design intent”.
“Is it possible to have parametric features without history? I think not.”
I think it depends on your defintion. To me, parametric means it uses parameters. A hole might have radius and depth parameters. Feed in a new value and the hole changes. There is no history here.
Matt,
thanks for the explanation. I begin to
, however I see
understand what you mean. It is urgent
for me to try ST
nothing intrinsically wrong in directed
relationships between features, that imply
a before and an after. As you said this
could be not wrong but just not enough
competitive in the future.
I just would add that I do like
direct editing and indeed I have developed
it in thinkdesign since several years and
got enthusiastic feedbacks but I see
direct editing as a complement and not an
alternative to traditional history based
editing. Could be that ST stays in the middle…
****
Roberto,
Yes, I think we are connecting on these ideas.
Spaceclaim believes that their product can coexist with other types of modelers. Siemens believes that ST is going to completely displace history modeling in 10 years. Similar approaches, very different outlooks on the future. I’m not willing to go out on that limb yet.
In the case of what we’re seeing with ST, is there some form that allows for configurations? For instance, I’ll often design die-cast housings with nasty large draft angles. These must be machined out for proper seating of pins, etc. In a case like this, I often have the master part for the housings, each peace of the housing split from the master, and configurations of each of the split parts.
Perhaps I can learn to do things in a different way (provided the trade-off is worth it), but having all three types of these parts/files linked is something I really value. How could I do something like this with ST?
****
Jeff,
I was going to get to this eventually, but I don’t think there is anything that prevents configurations. It depends on what the configs change. I don’t think that the current incarnation of SEwST has configs. You could concievably make a table of values and use it to drive versions of the b-rep. Not sure right off the top of my head about inserted parts. Not sure why it wouldn’t do that either. If it doesn’t now, it certainly could in the future. This is the first release of what is essentially a new CAD program. It uses some of the interface bits of regular Solid Edge, but the ST functionality is completely new software. I’m quite sure some of the other concepts from SE will become available.
The creating of the configurations doesn’t seem to be the problem, so much as the proper editing of them (while keeping the right things untouched). I don’t doubt that something could be figured out. In fact, with a first release of this nature, there are probably a great many things that require some attention to round out the software (much like SW1997).
Gonna be interesting seeing how this shakes out. I’m reluctant to throw new money at a new CAD package, but will certainly do so if my ROI is significantly improved.
HI kevinquigley
Ok I can elaborate a little bit on the travel-destination…
To give a general view, let’s take a look at one or two examples.
The famous hole command, even after couple years of solid modeling, we can find people using cutout to place hole.
The use of assembly feature to save some work instead of opening part to place the correct feature.
When we talk about part associativity inside an assembly, how many designers are experts in creating spaghetti?
So when speaking of travel I refer to take the necessary step to make sure you keep our design healthy not messy. Too often I saw designers using shortcut because they are lazy.
I think I saw on Matt blog an article where he mention that designer drop or cut the link between part and found them self face with a mess. This is a perfect example where destination is place in front of the travel.
Hope this brief explanation will help.
Has when I talk about creation is easy, we have to put that in perspective with other action in a process. If we talk about creating a simple cube and editing this is relatively easy.
That same cube, become a plate with hole and boss, it is easy to model, but edit could become more complex relative to what kind of edition need to be done.
If we push this further, a system compose of many plates in an assembly with interaction between them and you got a big challenge when it comes time to apply modifications.
In our situation, from what I can understand, you design complex car/consumer shape. Designing the correct shape could be really hard. But look at the time and effort you place in modifying those parts once you place the initial surface. Here I do not talk about placing a final touchup to round off some values.
So from my point of view I make distinction between initial draft of the part, where you create the initial feature three (recipe) and the moment where you need to play back with that recipe. It is when it comes time to tweak that recipe that I say; this is where the game is play.
I could make the loop with initial question Travel or Destination?
If your recipe is messy you probably do not care about the travel making your life harder.
Kevinquigley, I the addition to your initial post, I am happy to detect that you seem to have taking some sort of attention to the travel , has you seem to have define process in order to help you in your work.
You also point out that it could be a mess. This is another point that I have, but will keep it for another topic.
Managing files is the key to success and many are afraid of managing because they found this too restrictive. But it is part of the travel..
Kevin does this brief explanation help see the analogy?
Matt,
I do work with CoCreate and we use both ME10 and the Drafting part of CoCreate called the annotation module. You’re right ME10 and the model have no link at all. There is a link with annotation but there is no auto-dimension option like in SW or Pro-E. My complaint comes in where there is no link between a casting model and a machined part. You also can’t name features ie. inlet port. I havn’t used Solid Edge since V15 or V16 but from what I recall it wasn’t a bad package, on par with Inventor at that time from what I could tell. If you could get the history free but still maintain the history as far as a manufacturing history and be able to name features in a feature tree you’d have an ok solution but so far I havn’t seen one do it.
Hi Matt
Hope i do not steel any punch. If i go too far, just let me know and i will watch on the side quietly.
Freeze design seem to be one of the request.
See small video.
http://vimeo.com/2022540
****
Well, thanks for the comment. I’m getting to that. It goes past where I want to be right now. I’m building a case for the whole concept, you’re kind of jumping the gun.