Tuesday, January 6, 2009

The Unique Benefits of History-Based Modeling

As the awareness of history-free modeling increases, there seems to be a growing desire to somehow merge the benefits of history-based modeling with the benefits of history-free modeling.  This may be a bit difficult to consider as we may all have slightly different ideas on what benefits each of these technologies bring to our own CAD requirements.  As we consider these technologies we should try to be specific about how they may or may not support our requirements.  Much talk has been made regarding the benefits of history-free modeling, but what are the benefits of history-based modeling that we may miss by moving to a history-free environment?  As an example, Siemens with Synchronous Technology makes it easy to switch, but what benefits will you miss out on by doing so?

I added the following comments in a previous blog, but I want to restate them for the purpose of this discussion.  There are a few absolutes regarding CAD technology.
  • A CAD system is either history-based, i.e. tracks the modeling history (features are ordered with a parent/child relationship) OR it is history-free, i.e. does not track history (explicit or direct with no parent child relationship). If it has history, it is not history-free. Features are either ordered or they are not. Once history is gone, it is permanently gone – there is no getting it back without starting over.
  • A CAD system either has parametric capabilities (constraints) or it does not. It doesn't matter if it is history-based or history-free.  Parametric capabilities can exist in both history-based and history-free modeling. The capability either exists or it doesn't.
  • A CAD system either has direct geometry editing capabilities, or it doesn't. A history-free CAD system depends on direct editing, (it can’t exist without it). For a history-based system, direct editing is a nice to have feature.  In both cases, history-based or history-free, the direct editing capabilities will apply to both native and imported data.
In my enthusiasm for history-free modeling I certainly have not kept my opinions secret with regards to the positives of history-free modeling (or the negatives of history-based modeling).  However, history-free modeling still may not satisfy all of your requirements.  Today it cannot replace all of the benefits of history-based modeling.  A few years ago, the list of unique benefits of history-based modeling as compared to history-free modeling, was a long list.  Today the list is much shorter, but there is still a list.  With this post I will try to describe some of these remaining benefits.  I hope others will add to the list, but keep in mind I am only referring to the benefits that come from a history-based system, specifically the ordered feature tree with its parent/child relationships, as compared to todays history-free technology.  There are certainly many other criteria to consider when evaluating a CAD tool.

So what benefits can be realized from "ordered" modeling features that are not available in the history-free environment (no order)?  That’s the question.  Here are the ones I’ve considered.
  • The “Shell” is an obvious modeling feature that benefits from a parent/child relationship.  When a change is made to the parent, the child feature (shell) will conform to the modified parent during the model regeneration.  So far there is not a common method in history-free modeling for managing a consistent wall thickness on a part.  At this time the current history-free modeling systems each handle this problem a little differently.  While you get much more flexibility in your shell with history-free modeling you don’t get the natural consistency that comes with the shell feature when properly structured in a history tree.
  • Support for multiple states, i.e. secondary operations (stock-finish).  There could be two different states such as a cast part that is machined.  Or perhaps even three states such as individual parts that are welded into one and then machined.  In these situations a part exists in more than one state, but from a design intent point-of-view you want to utilize the same geometry wherever possible such that a change to geometry in the first state is realized in the second state, and so on, i.e. associativity from one state to the next.  By properly structuring the history tree and the related parent/child relationships, you can support this requirement fairly well with a history-based system.  Features can be added/suppressed allowing the representation of a part in different states.  There are ways to solve this in a history-free environment but to date I have not seen a good solution for it, although I don’t think it is too far away. 
  • Ease of controlling a model/assembly parametrically.  Parametric modeling is completely possible in a history-free model or assembly.  It is nothing new.  The reason I keep this benefit on the list is not that it can’t be done in a history-free environment, but rather that it is still somewhat easier to capture this information by properly utilizing the parent/child relationship.  The parent/child relationship seems to make it a bit more intuitive when we want to drive the effects of one parameter into different areas of the part or assembly.  This translates into the ability to more intuitively support requirements for family-of-parts, configure-to-order or perhaps design optimization.  This benefit may have more to do with "familiarity" than being "intuitive".
  • Ease of controlling freeform shapes and surfaces in a solid model.  There is very mature technology out there for defining and controlling freeform surfaces without the need for history.  Surface modeling systems have been doing it for years.  Controlling freeform surfaces on a solid model is a bit more complex, however.  A solid model that includes freeform surfaces can be very difficult to accurately edit in a history-free environment.  Add complex blends to the model and it gets even more difficult. There are many ways to control and edit surfaces in a history-free environment, but one of the things you can’t do is to go back to the original sketches and/or curves (parent) that were used to generate the complex surfaces (child) originally, make the modifications to the curves and regenerate the surface geometry.  If the tree is structured appropriately for this type of edit, the change will work well.  Today it is hard to beat the benefit that a well structured parent/child relationship brings to accurate surface editing in a solid model.
So. what did I miss with regards to the benefits that come from ordered modeling features, i.e. history?

Some may want to add control for blend/round features to this list of benefits since these features are typically order dependent.  In other words, depending on what order you add a blend/round, the vertex region can be different.  This is true of history-based and history-free systems.  In history-free the order is not available to the user to manipulate and as such getting a different vertex region may be difficult. But it can be equally difficult to reorder the features in a history-based environment, especially if you also need to add or remove edges within the feature.  I am not convinced that either technology makes this very easy.

Some may want to add capturing “design intent” to this list.  All four of the benefits I mention above fit into the category of “design intent”.  Don’t just list design intent.  Be more specific.

Some may want to add "knowing how someone created the model".  But you need to be more specific than that.  What benefit do you get from having this knowledge?

There is one benefit of history-based modeling that most will miss when moving to a history-free environment and that is “familiarity”.  You will need to move past this one while considering this topic.

With an understanding of the unique benefits of history-based and history-free technologies, perhaps we can have a more uesful discussion on what the term “best of both” refers to in this context.  When a CAD vender claims to be deliverying the best-of-both, what are they talking about?

Paul

8 comments:

al dean said...

Hey Paul

This is all very true, but I think your absolutes aren't quite as absolute. There are some systems which mix both history and non-history-based modelling, those that don't rely on history, and those that combine a mix of everything. I think the lines are much more blurred than might initially appear and trying to granularise things like this doesn't really tell the whole story. One of the most interesting technologies is avialable in a couple of places - within ImpactXpft's development work for Catia V5 (for functional modelling of plastic part design), in Caleum XXen. This uses features no doubt and parametrics, but doesn't use history in the traditional sense to assist with maintaining design intent (predominantly shells of course). Check it out if you ever get the chance

Cheers

Al

Blake Courter said...

Great post, Paul. A few further thoughts:

* At least one direct modeler, SpaceClaim, does a great job managing shells without history. Although there are clear driver / driven sets of faces, that relationship can be flipped on a face-by-face basis. The result is a much more flexible model.
* One benefit of parametrics in some direct modelers is that users can set up multiple sets of conflicting dimensions to edit their designs. For example, one could dimension a hole from two opposite ends of a beam. In most feature-based systems, this hole would be over-constrained. In some history-free systems, users can edit either dimension, even if one is shown as a reference. Design intent can change over time without needing to redo constraint setups.

Full disclosure: I am a founder and employee of SpaceClaim Corporation.

Best,
-Blake

Paul Hamilton said...

Al,
I still think a CAD system is creating structured data or it is not. It is certainly blurry as many history-based systems can interact well with unstructured data.
Maybe the question to ask is: can the system interact with IGES or STEP data (unstructured)as well as it can with native data? Is there ANY loss in functionality with the model and if so, why? Is it due to the loss of structure?
Thanks for the pointer to Caleum XXen - looks interesting.

Blake,
In an earlier draft of this I made mention of the shell capabilities in SpaceClaim, but I started getting too deep into capability comparisons. I think you may be the closest to eliminating this benefit from the list. Similar to your mirror - or symmetry capability. It almost seems like a single node feature tree??
You probably don't want to hear this but CoCreate does just what you are talking about regarding parametrics in direct modelers. :<)

Paul

jonbanquer said...

"When a CAD vender claims to be deliverying the best-of-both, what are they talking about?"

My interpretation of what Siemens might mean when it comes to NX goes something like this:

A designer can use the history based modeling part of NX 6 to create original data and when he tosses his non-manufacturable design over the wall to us in manufacturing we don't have to figure out what his design intent is and can use the Direct Modeling / Synchronous technology tools in NX6 to modify his model so it can be made / made more economically.

One system, many ways to use it, best of both worlds.

Jon Banquer
San Diego, CA
http://jonbanquer.wordpress.com/

Mike said...

Paul,

Pretty interesting read. We are having this internal struggle right now where I work on what the best path to go is. We use CoCreate some where I'm at but the only person who really likes it is the CAD manager. The best I can tell the only reason we use it is because we've had ME10 in place for 10 or 15 years. I think History free modeling is great for one off or very short run parts. On the other hand I think that a traditional history based modeler excels when you have what I would call "production parts" or parts that you're going to be using for years to come. The other place I see traditional systems having the edge is where you see parts starting in a "raw" from and you're doing secondary operations to the parts and/or assemblies.

Design Intent is a tricky word. What I consider design intent is feature names when you need them such as holes, bosses, porting, ect. You really don't have any more design intent with history based modeler unless you name those features.

One thing I've noticed with using a history free modeler I feel like I'm still using autocad mechanical except it shades my parts in for me.

Paul Hamilton said...

Mike, thanks for the comments.

I had considered adding "management for long lifecycle parts" to the list. With long lifecycle parts it may be justified to spend the extra effort to add the intelligence and properly structure the tree to firmly capture the intent - but, in 5 or 10 years down the road, is your CAD system going to be able to read the file? Upward compatibility is not a given with history-based systems. And, is the next CAD guy accessing the file going to get useful information from the logic you put into the structure? IMHO, I’m not sure the effort justifies the benefit. Some history-free systems can already, easily, capture the types of information that may be useful to the support of long lifecycle parts.
It's a good one to consider
Thanks,
Paul

rr said...

Lets say, we have a 4 sided boss in a model. with the two face filleted on all sides.
Will a history free modeling environment allow me to make it a 5sided boss?

Paul Hamilton said...

rr,
This is a good example where a parent/child relationship can help IF you have a sketch function for automating the creation of multi-sided profiles. Make a change to the number of sides in the profile and replay the history to get a new boss or pocket in 3D. The other way to handle this is through an intelligent 3D feature. This method does not require a parent/child relationship and can be done in either technology. There are several examples of intelligent features in history-free modeling, although I have not seen your particular example covered in any of them. It would be trivial to add in most any of them.

Thanks for the addition,
Paul