jon_banquer
2012-06-29 18:02:56 UTC
http://www.cloud-invent.com/Parametric-CAD/Bottleneck2.aspx
"The troubles of parametric feature-based approach, described in Part
I, are not finished in 2D sections – they are only started there and
grow up to much bigger problems in 3D history-based models.
As you know, features are created in history-based applications (like
Creo Parametric, SolidWorks, Sloid Edge, Inventor, etc.) one by one in
hierarchic order. Each feature in this hierarchy corresponds to some
sketch and this sketch is driven by the corresponding system of
equations.
The problems of feature-based methodology may be described as problems
of parent/child relationship. If a parent level feature is deleted or
changed in some way, it can cause unexpected effects on child-level
features. As a result after any changes in the top-level features we
are to regenerate all the child features, i.e. to solve all the
systems of equations, corresponding to the 2D sections of these
features. For complicated parts (containing, may be, 1000 features)
this might be a significant amount of time. In extreme cases (and
sometimes in cases that are not particularly that extreme), user might
be forced to recreate the model from scratch.
The drawback of the feature-based (in other words – history based)
design technique, which is founded on regenerating a model from its
history tree, is that, as more features are added, the geometry is
dependent upon more and more features created earlier. This often
leads to problems, if designer decides to do modifications in some
features at the top of the feature hierarchy.
In order to avoid these modification problems, users of a history-
based application have to plan carefully the design, defining ahead of
time which major elements would be dependent upon other elements. But
planning a long hierarchical sequence of features (if the parts to be
designed are complicated enough) might be not an easy task.
On the other hand, non-efficient 2D Solver (that is not able to
resolve really big sketches) leaves to designer no way around but to
create a lot of small features. Very often designers have to divide
parts into numerous “unnatural” features, because the “natural”
features have such a complicated underlying sketches, that 2D Solver
is not able to solve corresponding systems of equations. As a result
this leads to the history tree of the part, which is much more
extended. And the whole design process becomes much trickier.
These observations show that when it comes the time to do some
modifications in the existing feature-based models we are in front of
numerous problems. But interactive modification of the model is the
fundamental aspect in any design activity! Designer is constantly
going forward and backwards, re-elaborating once and again some
particular aspect of the model, or its general layout, or even coming
back to a previous solution that had been temporarily abandoned. With
feature-based CAD these modifications are tricky.
The principal limitation of the parametric feature-based approach is
the lack of simple instruments to modify interactively a model once it
has been created.
As a respond to all these history-based troubles the CAD industry
proposed the history-free approach. In explicit modeling applications
(like Creo Direct (formerly CoCreate), SpaceClaim, KeyCreator,
SketchUp etc.) users have these simple modification instruments for
their convenience.
But adepts of the history-free approach went from one extreme into
another. Throwing away the features history-tree (which is definitely
step in the right direction) they throw away the most brilliant part
of the history-based approach – the parametrics. History-free models
are no more driven by the constrains systems of equations! So all the
advantages of the parametric approach are lost!
Why it happened? Why parametric modeling and explicit modeling exist
as two separate worlds?
If both parametric feature-based and direct-modeling approaches have
their advantages (and their drawbacks) why not to merge their best
characteristics in one system (and throw away their drawbacks)? Isn’t
it strange that until now nobody managed to implement such a system?"
"The troubles of parametric feature-based approach, described in Part
I, are not finished in 2D sections – they are only started there and
grow up to much bigger problems in 3D history-based models.
As you know, features are created in history-based applications (like
Creo Parametric, SolidWorks, Sloid Edge, Inventor, etc.) one by one in
hierarchic order. Each feature in this hierarchy corresponds to some
sketch and this sketch is driven by the corresponding system of
equations.
The problems of feature-based methodology may be described as problems
of parent/child relationship. If a parent level feature is deleted or
changed in some way, it can cause unexpected effects on child-level
features. As a result after any changes in the top-level features we
are to regenerate all the child features, i.e. to solve all the
systems of equations, corresponding to the 2D sections of these
features. For complicated parts (containing, may be, 1000 features)
this might be a significant amount of time. In extreme cases (and
sometimes in cases that are not particularly that extreme), user might
be forced to recreate the model from scratch.
The drawback of the feature-based (in other words – history based)
design technique, which is founded on regenerating a model from its
history tree, is that, as more features are added, the geometry is
dependent upon more and more features created earlier. This often
leads to problems, if designer decides to do modifications in some
features at the top of the feature hierarchy.
In order to avoid these modification problems, users of a history-
based application have to plan carefully the design, defining ahead of
time which major elements would be dependent upon other elements. But
planning a long hierarchical sequence of features (if the parts to be
designed are complicated enough) might be not an easy task.
On the other hand, non-efficient 2D Solver (that is not able to
resolve really big sketches) leaves to designer no way around but to
create a lot of small features. Very often designers have to divide
parts into numerous “unnatural” features, because the “natural”
features have such a complicated underlying sketches, that 2D Solver
is not able to solve corresponding systems of equations. As a result
this leads to the history tree of the part, which is much more
extended. And the whole design process becomes much trickier.
These observations show that when it comes the time to do some
modifications in the existing feature-based models we are in front of
numerous problems. But interactive modification of the model is the
fundamental aspect in any design activity! Designer is constantly
going forward and backwards, re-elaborating once and again some
particular aspect of the model, or its general layout, or even coming
back to a previous solution that had been temporarily abandoned. With
feature-based CAD these modifications are tricky.
The principal limitation of the parametric feature-based approach is
the lack of simple instruments to modify interactively a model once it
has been created.
As a respond to all these history-based troubles the CAD industry
proposed the history-free approach. In explicit modeling applications
(like Creo Direct (formerly CoCreate), SpaceClaim, KeyCreator,
SketchUp etc.) users have these simple modification instruments for
their convenience.
But adepts of the history-free approach went from one extreme into
another. Throwing away the features history-tree (which is definitely
step in the right direction) they throw away the most brilliant part
of the history-based approach – the parametrics. History-free models
are no more driven by the constrains systems of equations! So all the
advantages of the parametric approach are lost!
Why it happened? Why parametric modeling and explicit modeling exist
as two separate worlds?
If both parametric feature-based and direct-modeling approaches have
their advantages (and their drawbacks) why not to merge their best
characteristics in one system (and throw away their drawbacks)? Isn’t
it strange that until now nobody managed to implement such a system?"