View Single Post
  #8  
Old 04-09-2007, 02:03 PM
phamil1 phamil1 is offline
Registered User
 
Join Date: Aug 2005
Location: Fort Collins, CO
Posts: 46
Re: Cadalyst - MCAD Modeling—History . . . or Not?

#1 fact when discussing this topic: History and non-history is completely independent from geometrical relationships/parametrics (including features-a simple collection of faces). It does however track the relationship from one modeling operation to another. It has to, to be able to rebuild the model on a regeneration. Geometrical relationships can be assigned to geometry, regardless of history or no history, including features.

The big question is how and when do you add this intelligence into the model. For history-based users, you add it into the modeling steps so that the model will regenerate properly when modified. Some modelers won't allow you to finish a modeling operation until you add the relationships. Others will let you go back into the history and add them later. However, it has to be embedded into the history. These relationships are solved serially based on the modeling steps (history).

For the non-history based users, relationships - including features (collections of faces) can be defined anytime, regardless of how, when or where the geometry comes from. These relationships are solved simultaneously using a parametric solver rather than just playing through the recorded steps. One of the big issues with this methodology is getting users to take the time to add this intelligence into the model - as it is not mandatory to the development, and/or modification, of the model. Non-history CAD companies still don't make it too easy to add this intelligence, although it is all there. It would be nice, if while in the modeling process, if it would be easier to add persistent relationships on the fly. It is getting better, but there is still work to do.

Another question: what is a feature? A recorded modeling step - or - a collection of faces that is important to the design or perhaps manufacturing. Actually, a feature that is important to the designer, may be completely useless to the NC programmer. It is not too uncommon for a feature definition to change through the product development process. A shell with 2 bosses with threaded holes in them might be important to the CAD user for a while, but the CAM user sees it as a pocket with two islands, and then two holes. Bottom line, it is important for relationships to adjust while geometry stays consistent, or perhaps geometry adjust while relationships stay consistent - something that a history-based system has huge problems with. The practice of rebuilding models in the history-based world is very common - this is one of the reasons.

I think we can all agree that this intelligence is important. But is history the best way to apply relationship? - Only as long as history makes it easier to add the relationships, (and this will not always be the case). The problem is that since the intelligence is maintained in the history of the model - it is ONLY useful to someone that has that exact same CAD system and really knows how to use it. I’ve seen many users struggle for hours to figure out how someone else modeled the part just so they could make a little change. Also, history structures are proprietary - there is no industry standard for the exchange of this information. Data exchange and interoperability is probably the #1 issue in the CAD business today - and maybe 90% of this comes from history trees. Is history really worth the overhead? In some cases, today it is very much worth it - in others, it is a complete waste. Both have their place.

Too bad we don't capture this intelligence as meta data in a database rather than proprietary data imbedded in the geometry. THEN we would have something.

Oh - sorry this got so long
__________________
Paul Hamilton
Technical Sales Manager (PTC)
http://p-hamilton.blogspot.com
Reply With Quote