EDAboard.com | EDAboard.eu | EDAboard.de | EDAboard.co.uk | RTV forum PL | NewsGroups PL

parametric and feature based

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - Synthesis - parametric and feature based

yogesh
Guest

Wed May 26, 2004 5:28 am   



Do parametric and feature based design mean the same thing?
because both of these terms appeared almost synonymously whenever I
searched for them.(eg."parametric/feature based")
What is the meaning of each term in CAD perspective?

regards,
Yogesh Joshi

MM
Guest

Wed May 26, 2004 5:48 am   



Yogesh,

Parametric means that the models features can be driven rules or parameters
set up by the user. They can be dimensions, geometric constraints (tangent,
concentric, co-linear, etc,), equations, design tables, and many others.

Feature based is a construction methodology. It means that the model is
constructed using three dimensional objects (features), as opposed to
individual lines arcs splines and surfaces. This term pretty much fits all
modern systems, but fifteen years ago it was a very big deal.


Regards

Mark



"yogesh" <ypjofficial_at_indiatimes.com> wrote in message
news:f88a27e4.0405252028.30ed18a4_at_posting.google.com...
Quote:
Do parametric and feature based design mean the same thing?
because both of these terms appeared almost synonymously whenever I
searched for them.(eg."parametric/feature based")
What is the meaning of each term in CAD perspective?

regards,
Yogesh Joshi


Paul Salvador
Guest

Wed May 26, 2004 6:23 am   



Answer = no

parametric = parameter based (values, variables, equations,...)
feature = object or sketch based (box, sphere, cone,.. line, circle..)

parametric + feature = objects with parameters

...

yogesh wrote:
Quote:

Do parametric and feature based design mean the same thing?
because both of these terms appeared almost synonymously whenever I
searched for them.(eg."parametric/feature based")
What is the meaning of each term in CAD perspective?

regards,
Yogesh Joshi


Andrew Beckett
Guest

Wed May 26, 2004 8:41 am   



By the way, one of the groups you are cross-posting to, comp.cad.cadence has
nothing to do with autocad issues - it's for the Electronic Design Automation
tools from Cadence Design Systems. The terms you're talking about aren't
meaningful in our arena.

So you might want to desist from cross posting to that group.

I suspect that comp.cad.synthesis is also not appropriate.

Regards,

Andrew.


On 25 May 2004 21:28:16 -0700, ypjofficial_at_indiatimes.com (yogesh) wrote:

Quote:
Do parametric and feature based design mean the same thing?
because both of these terms appeared almost synonymously whenever I
searched for them.(eg."parametric/feature based")
What is the meaning of each term in CAD perspective?

regards,
Yogesh Joshi

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

Paul Salvador
Guest

Wed May 26, 2004 9:03 am   



FYI, this was not a autocad specific question.
And, EDA tools do have parametrics and can create feature based models.
And, although comp.cad.synthesis is related circuit/chip building,
parametrics and model creation do have a role there as well and the word
synthesis is related to parametrics.

So, should he "desist" or "cease" before? ;^)

...

Andrew Beckett wrote:
Quote:

By the way, one of the groups you are cross-posting to, comp.cad.cadence has
nothing to do with autocad issues - it's for the Electronic Design Automation
tools from Cadence Design Systems. The terms you're talking about aren't
meaningful in our arena.

So you might want to desist from cross posting to that group.

I suspect that comp.cad.synthesis is also not appropriate.

Regards,

Andrew.

On 25 May 2004 21:28:16 -0700, ypjofficial_at_indiatimes.com (yogesh) wrote:

Do parametric and feature based design mean the same thing?
because both of these terms appeared almost synonymously whenever I
searched for them.(eg."parametric/feature based")
What is the meaning of each term in CAD perspective?

regards,
Yogesh Joshi

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd


Andrew Beckett
Guest

Wed May 26, 2004 9:26 am   



OK. I stand corrected. It's obviously just terminology I've never heard used in
an EDA context (although I have heard it used in other CAD contexts).

Andrew.

On Wed, 26 May 2004 08:03:03 GMT, Paul Salvador <p.salvador_at_verizon.net> wrote:

Quote:
FYI, this was not a autocad specific question.
And, EDA tools do have parametrics and can create feature based models.
And, although comp.cad.synthesis is related circuit/chip building,
parametrics and model creation do have a role there as well and the word
synthesis is related to parametrics.

So, should he "desist" or "cease" before? ;^)

..

Andrew Beckett wrote:

By the way, one of the groups you are cross-posting to, comp.cad.cadence has
nothing to do with autocad issues - it's for the Electronic Design Automation
tools from Cadence Design Systems. The terms you're talking about aren't
meaningful in our arena.

So you might want to desist from cross posting to that group.

I suspect that comp.cad.synthesis is also not appropriate.

Regards,

Andrew.

On 25 May 2004 21:28:16 -0700, ypjofficial_at_indiatimes.com (yogesh) wrote:

Do parametric and feature based design mean the same thing?
because both of these terms appeared almost synonymously whenever I
searched for them.(eg."parametric/feature based")
What is the meaning of each term in CAD perspective?

regards,
Yogesh Joshi

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

--
Andrew Beckett
Senior Technical Leader
Custom IC Solutions
Cadence Design Systems Ltd

yogesh
Guest

Wed May 26, 2004 10:48 am   



Quote:
Parametric means that the models features can be driven rules or parameters
set up by the user. They can be dimensions, geometric constraints (tangent,
concentric, co-linear, etc,), equations, design tables, and many others.

Feature based is a construction methodology. It means that the model is
constructed using three dimensional objects (features), as opposed to
individual lines arcs splines and surfaces. This term pretty much fits all
modern systems, but fifteen years ago it was a very big deal.
Mark,

I would certainly like to hear a detailed eloboration about the
scenario fifteen years ago.(I am studying the history of cad as a part
of my project and also collecting the information about the softwares
in use then..Your information will be definitely welcomed..)

regards,
Yogesh Joshi

Doug Dingus
Guest

Sun May 30, 2004 7:28 am   



Yogesh,

I am going to take a crack at your future questions because I have a
bit of free time at the moment. I personally find this topic pretty
interesting.

15 years ago...

CAD systems were pretty simple. They provided an interface to build
geometrical representations of models, a data structure to contain
them, and a means of viewing combined with tools for basic analysis of
and between the various elements input by the user.

They were not feature based or parametric, other than through some
macro type capabilities.

The primary difference between then and now is this:

The older systems did not capture design intent, only the result of
it. If a user were to make a change, they must analyze the structure
of the model, then use the tools available to them to manually change
the model.

Today, we basically tell the program how the model should be built and
how it should respond to changes and the system builds the model.

Another primary difference between then and now is the quality and
nature of the model representation. Early systems were limited to
wireframe only. They represented the intersections of surfaces only.
Today, we have full boundary representation models. (B-rep) These
models include all the intersections present in the older systems plus
surfaces and volumes along with material property definitions. All of
this comes with increasing demands for compute power of course.


Lets take a very simple example; namely, a cube that will change size
and have a hole cut into it.

Early wireframe systems would require a manual process for this:

- Draw a rectangle anyway you want. 4 lines, rectangle command,
whatever because it does not matter. Lines are lines...

- Transform along vector normal to rectangle and construct the 4
additional lines that represent the intersections of the side
surfaces.

Modern day systems:

- Draw a rectangle. This time the method matters somewhat because the
system can capture your design intent. So, a rectangle drawn with the
rectangle command will act like one when changed. Since the user
asked for a rectange, as opposed to 4 lines, the system can make a
number of assumptions; namely, the two parameters for width and
length, each line end point being coincident with its nearest
neighbor, two lines perpendicular, two lines parallel, etc...

Or, one could construct the same rectangle manually using the line
command as well, then proceed to specify each necessary constraint and
parameter as needed until the result acts like a rectangle.

The idea being you are building instructions for use later, not just
constructing geometry. Notably, the rectangle drawn and constrained
in the modern system is not really part of the model, it is a
representation used to tell the system how to build the model.
Contrast that with the earlier method.

- Extrude, linear sweep, whatever to form a solid. Additional
parameters are supplied during this step also. (Depth, draft, etc...)

The system then builds the model according to the parameters given.

It is interesing to note at this stage, construction can sometimes be
more involved during the initial create process, compared to the time
required for the simple geomtery constructs used in the early systems.

The amount of information captured is significantly greater however.

The older system only knows a bunch of lines have been added to its
database of entities, along with some elementary attributes:

1. line x,y,z x1,y1,z1, color, level, style, etc...
2. line x,y,z x1,y1,z1, color, level, style, etc...
..
..
..
12. line x,y,z x1,y1,z1, color, level, style, etc...


The newer one knows a number of things; namely, (In the case of
I-deas)

- an Untitled part is now present on the workbench
- said part consists of:
- a local coordinate system, currently at the origin
- one feature composed of
- 1 sketch with its own constraint network and lines in this case
- feature operation parameters detailing type, etc...
- one solid volume composed of:
- 6 trimmed planes
- surface information mapped in the UV coordinate space (ST for
ideas)
- 24 lines defining the limits of the planes (4 per)
- boundary information detaling common edges
- material definition, I believe the default for I-deas is
Styrofoam.
- other relevant information
- geometry pick list
- labels for relationships (vertex, face, edge, volume, curve,
etc...
- display information (tesselation, color, etc...)
- etc...

The difference in datasets is significant, as are the results

Change size of block model:

In the manual system, the user must determine the nature of the change
to be made, develop a mental picture of the result, then finally map
those two to both the tools at hand and a process for using them to
achieve the desired result. This process involves more than simple
geometry elements, the intended design intent must be communicated in
some fashion outside the tool used to make the change. Typically,
this information is represented in a drawing or design notes the user
can use to help with this task. Additionally, the older system knows
nothing of parts, volumes and other things taken for granted today.
The attributes are used to convey this information in a limited way,
again the idea being to help the user process the change correctly.

A CADKEY user might decide to BOX MOVE the model to change its size.
If other models are on the screen, the user may have to pick via
attribute masking, and check that pick to verify it includes only the
entities necessary, where a modern system would know what entities are
involved because it has the additional data necessary to do so. Other
systems might involve a transform step and several trim/extend steps
to complete the change. The end result is the same though --a manual
change directly on the model representation itself.

Once the change is complete, the user must verify the operation in
order to determine the new representation meets the requirements.
Measurement and dimensioning tools can be used for this. Again, the
user must process both the low level data (dimensional size and
geometric shape) and the higher level data involving design intent, in
order to achieve a correct result.

If the model has a drawing associated with it, the user must also
view, modify, and in many cases re-render the drawing to better
represent and communicate all they have learned about the model in the
hope that others will understand it. Since the limited dataset does
not include enough information to properly detail the model, many of
the view processing options we see today are done manually as well.
(Hidden line removal, etc...)

In the modern system, the larger volume of data, combined with the
captured design intent make this a simple process.

-Change the parameter that most directly controls the change, then ask
the system to show the new result. Given the change results in
geometry, within the limits of the already specified design intent and
the system is able to correctly interpet this intent, the change will
be made without significant user intervention.

An associated drawing can be mostly updated as well, normally only
requiring minor cosmetic adjustments to complete the task.

Overall, this is a much shorter and mentally easier process!

Adding the hole in the manual system involves the same tedious steps
as required for the block. Common representations, during this time,
involved two circles, connected by a single line. So, three more
entities get added to the database. The attributes might be used to
communicate feature related information, but the system can do nothing
but display the differences. It is all up to the user to understand
what those attributes mean in the future.

The parametric, feature based approach is basically the same, in
I-deas at least, for parts as it is for features; namely, sketch
something and create a solid from it, then tell the system how that
solid relates to the part at hand. (Boolean operation add, join, cut,
intersect.) Many feature based systems today include specific feature
types intended to make this process faster. (Hole and rib commands,
for example.)

Users of the parametric model representation can browse the
instruction set (history/feature tree) to choose among features to
modify. Ideally, the modifications are considered in the context of
the other features for a fast and accurate result. Many minor details
are invisible to the user as a result of this process, compared to the
older systems.

Additionally, the higher level representations permitted in modern
systems, like I-deas, allow the user to think about their model in
terms that can greatly help with accuracy and problem solving. Fully
constrained models help the user determine if they have really thought
about the entire feature in question during create, for example.
Breaking down new features into their component constraints and design
intent needs helps to build functional designs without having to also
worry about all the numbers.

Doug's rule of CAD: In a properly designed CAD system, you should be
able to construct a fully functional model without having to input and
calculate specific numerical aspects of the model. (I-deas is
fantastic at this, BTW where many CAD packages demand more information
from you than necessary.) This is also true of many older systems,
within their limits as well. (CADKEY has a very nice position menu
that allowed users to directly determine coordinates based on other
model entities, greatly reducing the number of numbers one had to
remember and process in order to construct new model entities.)

(Hello NX! <-- I sure hope they fix this!)

Lets say you want to make a simple tube handle for a door. Said
handle will consist of a planar path, consisting of three lines, two
arcs tangent to their respective lines, one profile; namely a circle,
and a sweep operation to form the solid, followed by a shell operation
to represent a hollow tube.

In I-deas, this model can be easily built, constrained to represent
design intent, and drawing made without actually having to input
numbers or do calculations. When the model is put into context, such
as the door assembly, changes can be made via the measure command and
simple addition/subraction to determine optimal model size. If the
data is known in advance, it can be input at that time, or not...
depending on the nature of the model and data available at the time.

All one needs to do is draw any handle meeting the engineering
requirements, then adapt that model, given the information already
present in the system as a minimum, then work forward from there as
the requirements become more clear.

In the older, non parametric systems, drawing something the wrong size
generally is a waste of time because modification is difficult. This
places a high burden on the user to more fully mentally realize the
model details than would be strictly necessary at the time.

In newer systems, I-deas in particular, getting the model right
involves higher level thought about the nature of the model and how it
relates to other ones, not low level details, such as size. When
dealing with complex representations, this difference is significant
because the manual calculations required to verify the model
representation become increasingly time consuming.

I have mentioned I-deas specifically in the above mess, because some
of the terminology is specific to it. I-deas really is different from
almost every other CAD system in a number of key ways; namely, hybrid
modeling, variational math, shared multi-user global coordinates,
integrated data management...

(Another day.)

Guy Edkins
Guest

Tue Jun 01, 2004 10:21 pm   



Hi,



Doug's synopsis is excellent and quite thorough. I do have a minor thing to
add. There is a subtle but important difference between a parametric modeler
and a variational modeler. Typically parametric modelers let you create an
equation (rule) that lets you drive one value from another. And only in that
"direction".



For example a cube has a hole in it and the face the hole penetrates is 2
inches on each edge. There is also a pair of locating dimensions for the
hole from the two edges of the cube. These are set to be of the face
dimensions, i.e. the equation for the value of the locating dimensions would
be HOLEDIM1 = EDGELENGTH/2 (and the same for the HOLEDIM2). In this case the
locating dimensions would each be 1 inch. Now, in a true "parametric"
modeler you would be restricted to changing/modifying only the cubes edge
dimensions (driving dimension) as the hole dimension is located by way of a
simple equation (the driven dimension). In a variational modeler you can
create the same equation and then alter either the hole location dimension
or the edge dimension. It is more or less a solving a simultaneous equation.
Slicker for sure, but slightly longer to calculate.



On last thing to throw in to the mix. The "original" parametric modeling
engine; PTC's Pro/ENGNIEER (gosh I am dating myself) developed by Dr. Samuel
Geisberg while originally at Applicon (which went on to become Schlumberger
Technologies) is based on the a branch of calculus called variational
calculus or what is often referred to as the calculus of variants or
variations. This is not to be confused however with aforementioned
variational modeler.

Dr. Geisberg, the founder of PTC is a brilliant mathematician from the
University of Leningrad. If you Google him, I am sure you will find a lot
on the history of CAD as he played a very large part in defining the
industry today.





"Doug Dingus" <doug_at_opengeek.org> wrote in message
news:d017c747.0405292328.4fca767c_at_posting.google.com...
Quote:
Yogesh,

I am going to take a crack at your future questions because I have a
bit of free time at the moment. I personally find this topic pretty
interesting.

15 years ago...

CAD systems were pretty simple. They provided an interface to build
geometrical representations of models, a data structure to contain
them, and a means of viewing combined with tools for basic analysis of
and between the various elements input by the user.

They were not feature based or parametric, other than through some
macro type capabilities.

The primary difference between then and now is this:

The older systems did not capture design intent, only the result of
it. If a user were to make a change, they must analyze the structure
of the model, then use the tools available to them to manually change
the model.

Today, we basically tell the program how the model should be built and
how it should respond to changes and the system builds the model.

Another primary difference between then and now is the quality and
nature of the model representation. Early systems were limited to
wireframe only. They represented the intersections of surfaces only.
Today, we have full boundary representation models. (B-rep) These
models include all the intersections present in the older systems plus
surfaces and volumes along with material property definitions. All of
this comes with increasing demands for compute power of course.


Lets take a very simple example; namely, a cube that will change size
and have a hole cut into it.

Early wireframe systems would require a manual process for this:

- Draw a rectangle anyway you want. 4 lines, rectangle command,
whatever because it does not matter. Lines are lines...

- Transform along vector normal to rectangle and construct the 4
additional lines that represent the intersections of the side
surfaces.

Modern day systems:

- Draw a rectangle. This time the method matters somewhat because the
system can capture your design intent. So, a rectangle drawn with the
rectangle command will act like one when changed. Since the user
asked for a rectange, as opposed to 4 lines, the system can make a
number of assumptions; namely, the two parameters for width and
length, each line end point being coincident with its nearest
neighbor, two lines perpendicular, two lines parallel, etc...

Or, one could construct the same rectangle manually using the line
command as well, then proceed to specify each necessary constraint and
parameter as needed until the result acts like a rectangle.

The idea being you are building instructions for use later, not just
constructing geometry. Notably, the rectangle drawn and constrained
in the modern system is not really part of the model, it is a
representation used to tell the system how to build the model.
Contrast that with the earlier method.

- Extrude, linear sweep, whatever to form a solid. Additional
parameters are supplied during this step also. (Depth, draft, etc...)

The system then builds the model according to the parameters given.

It is interesing to note at this stage, construction can sometimes be
more involved during the initial create process, compared to the time
required for the simple geomtery constructs used in the early systems.

The amount of information captured is significantly greater however.

The older system only knows a bunch of lines have been added to its
database of entities, along with some elementary attributes:

1. line x,y,z x1,y1,z1, color, level, style, etc...
2. line x,y,z x1,y1,z1, color, level, style, etc...
.
.
.
12. line x,y,z x1,y1,z1, color, level, style, etc...


The newer one knows a number of things; namely, (In the case of
I-deas)

- an Untitled part is now present on the workbench
- said part consists of:
- a local coordinate system, currently at the origin
- one feature composed of
- 1 sketch with its own constraint network and lines in this case
- feature operation parameters detailing type, etc...
- one solid volume composed of:
- 6 trimmed planes
- surface information mapped in the UV coordinate space (ST for
ideas)
- 24 lines defining the limits of the planes (4 per)
- boundary information detaling common edges
- material definition, I believe the default for I-deas is
Styrofoam.
- other relevant information
- geometry pick list
- labels for relationships (vertex, face, edge, volume, curve,
etc...
- display information (tesselation, color, etc...)
- etc...

The difference in datasets is significant, as are the results

Change size of block model:

In the manual system, the user must determine the nature of the change
to be made, develop a mental picture of the result, then finally map
those two to both the tools at hand and a process for using them to
achieve the desired result. This process involves more than simple
geometry elements, the intended design intent must be communicated in
some fashion outside the tool used to make the change. Typically,
this information is represented in a drawing or design notes the user
can use to help with this task. Additionally, the older system knows
nothing of parts, volumes and other things taken for granted today.
The attributes are used to convey this information in a limited way,
again the idea being to help the user process the change correctly.

A CADKEY user might decide to BOX MOVE the model to change its size.
If other models are on the screen, the user may have to pick via
attribute masking, and check that pick to verify it includes only the
entities necessary, where a modern system would know what entities are
involved because it has the additional data necessary to do so. Other
systems might involve a transform step and several trim/extend steps
to complete the change. The end result is the same though --a manual
change directly on the model representation itself.

Once the change is complete, the user must verify the operation in
order to determine the new representation meets the requirements.
Measurement and dimensioning tools can be used for this. Again, the
user must process both the low level data (dimensional size and
geometric shape) and the higher level data involving design intent, in
order to achieve a correct result.

If the model has a drawing associated with it, the user must also
view, modify, and in many cases re-render the drawing to better
represent and communicate all they have learned about the model in the
hope that others will understand it. Since the limited dataset does
not include enough information to properly detail the model, many of
the view processing options we see today are done manually as well.
(Hidden line removal, etc...)

In the modern system, the larger volume of data, combined with the
captured design intent make this a simple process.

-Change the parameter that most directly controls the change, then ask
the system to show the new result. Given the change results in
geometry, within the limits of the already specified design intent and
the system is able to correctly interpet this intent, the change will
be made without significant user intervention.

An associated drawing can be mostly updated as well, normally only
requiring minor cosmetic adjustments to complete the task.

Overall, this is a much shorter and mentally easier process!

Adding the hole in the manual system involves the same tedious steps
as required for the block. Common representations, during this time,
involved two circles, connected by a single line. So, three more
entities get added to the database. The attributes might be used to
communicate feature related information, but the system can do nothing
but display the differences. It is all up to the user to understand
what those attributes mean in the future.

The parametric, feature based approach is basically the same, in
I-deas at least, for parts as it is for features; namely, sketch
something and create a solid from it, then tell the system how that
solid relates to the part at hand. (Boolean operation add, join, cut,
intersect.) Many feature based systems today include specific feature
types intended to make this process faster. (Hole and rib commands,
for example.)

Users of the parametric model representation can browse the
instruction set (history/feature tree) to choose among features to
modify. Ideally, the modifications are considered in the context of
the other features for a fast and accurate result. Many minor details
are invisible to the user as a result of this process, compared to the
older systems.

Additionally, the higher level representations permitted in modern
systems, like I-deas, allow the user to think about their model in
terms that can greatly help with accuracy and problem solving. Fully
constrained models help the user determine if they have really thought
about the entire feature in question during create, for example.
Breaking down new features into their component constraints and design
intent needs helps to build functional designs without having to also
worry about all the numbers.

Doug's rule of CAD: In a properly designed CAD system, you should be
able to construct a fully functional model without having to input and
calculate specific numerical aspects of the model. (I-deas is
fantastic at this, BTW where many CAD packages demand more information
from you than necessary.) This is also true of many older systems,
within their limits as well. (CADKEY has a very nice position menu
that allowed users to directly determine coordinates based on other
model entities, greatly reducing the number of numbers one had to
remember and process in order to construct new model entities.)

(Hello NX! <-- I sure hope they fix this!)

Lets say you want to make a simple tube handle for a door. Said
handle will consist of a planar path, consisting of three lines, two
arcs tangent to their respective lines, one profile; namely a circle,
and a sweep operation to form the solid, followed by a shell operation
to represent a hollow tube.

In I-deas, this model can be easily built, constrained to represent
design intent, and drawing made without actually having to input
numbers or do calculations. When the model is put into context, such
as the door assembly, changes can be made via the measure command and
simple addition/subraction to determine optimal model size. If the
data is known in advance, it can be input at that time, or not...
depending on the nature of the model and data available at the time.

All one needs to do is draw any handle meeting the engineering
requirements, then adapt that model, given the information already
present in the system as a minimum, then work forward from there as
the requirements become more clear.

In the older, non parametric systems, drawing something the wrong size
generally is a waste of time because modification is difficult. This
places a high burden on the user to more fully mentally realize the
model details than would be strictly necessary at the time.

In newer systems, I-deas in particular, getting the model right
involves higher level thought about the nature of the model and how it
relates to other ones, not low level details, such as size. When
dealing with complex representations, this difference is significant
because the manual calculations required to verify the model
representation become increasingly time consuming.

I have mentioned I-deas specifically in the above mess, because some
of the terminology is specific to it. I-deas really is different from
almost every other CAD system in a number of key ways; namely, hybrid
modeling, variational math, shared multi-user global coordinates,
integrated data management...

(Another day.)


Doug Dingus
Guest

Wed Jun 02, 2004 6:20 am   



"Guy Edkins" <gedkins_at_deltagl.com> wrote in message news:<8k7vc.23196$oh7.3321_at_nwrddc01.gnilink.net>...
Quote:
Hi,



Doug's synopsis is excellent and quite thorough. I do have a minor thing to
add. There is a subtle but important difference between a parametric modeler
and a variational modeler. Typically parametric modelers let you create an
equation (rule) that lets you drive one value from another. And only in that
"direction".

Nice addition Guy. Was heading there, but ran out of steam... Smile

elektroda.net NewsGroups Forum Index - Synthesis - parametric and feature based

Ask a question - edaboard.com

Arabic versionBulgarian versionCatalan versionCzech versionDanish versionGerman versionGreek versionEnglish versionSpanish versionFinnish versionFrench versionHindi versionCroatian versionIndonesian versionItalian versionHebrew versionJapanese versionKorean versionLithuanian versionLatvian versionDutch versionNorwegian versionPolish versionPortuguese versionRomanian versionRussian versionSlovak versionSlovenian versionSerbian versionSwedish versionTagalog versionUkrainian versionVietnamese versionChinese version
RTV map EDAboard.com map News map EDAboard.eu map EDAboard.de map EDAboard.co.uk map