parametric modeling

[Er Presidente]

I had the pleasure to exchange some opinion with ozzy on fb in reference to the eternal discussion on "parastrubbolite".
Having a little time to lose, I put my hand on an old project as a "breed" and I put myself to "parameterize it".
new experience for me, even if I have always worked with the parametric module, and (apart from a series of intestinal discomfort, side effect not eliminateable :smile: ) I had the opportunity to focus on philosophy of approach and work.

I hope that ozzy wants to participate and I will try to be short and concise (as usual!).

Hi.

 

[MBT]

How? Are you converting to parastrubboli? ? ? ?

then, after this, everything becomes possible! also that aliens come down on earth!!!!





of the truth. . .
Beautiful parastruder, he???? ;-)

 

[Er Presidente]

How? Are you converting to parastrubboli? ? ? ?

then, after this, everything becomes possible! also that aliens come down on earth!!!!





of the truth. . .
Beautiful parastruder, he???? ;-)

My mom!
On the one hand it is exhilarating, making "live" a model (especially if imported step) is rewarding, but on the other a nightmare!
I have made my own precise idea, which confirms my initial hypothesis, needs something new that makes the parameter more "conscious" and less "alienant".

just to introduce the topic, I have an idea in the head, the parametric should be divided into two "areas", the "vincolation" and the "parametrization" that, instead, seem too confused and superimposed.
binding should be a dimensional control of the model, while parameterization should be the "life" of the model.

I think them apart because, for what I think, the first phase (win) should be carried out with the tools we already know as designers, the q&t (quotes and tolerances).
as a designer I would have no difficulty thinking how to bind a piece and I do not see why I should learn to bind it differently just to please the sw, the rules at the base of q&t are universally valid and known.

What different the parameterization, that is to establish which quotas (wins) can vary (and with what limits) to generate "adactive" models or models families.

 

[cacciatorino]

as a designer I would have no difficulty thinking how to bind a piece and I do not see why I should learn to bind it differently just to please the sw, the rules at the base of q&t are universally valid and known.

sketches and processing should be quoted (and tolerated for cads that have this possibility) in the same way that the piece will be worked on m.u. There wouldn't be the difference you're talking about.
to get this, when you model a part better from the semi-finished crude available in stock and proceed to excavation force, and never use additions of material.

then there are modeling techniques in the axieme with links between the parts that make it impossible to deal with reasoning in these terms, but in some cases they are of great convenience.

 

[Parametric_Ozzy]

I had the pleasure to exchange some opinion with ozzy on fb in reference to the eternal discussion on "parastrubbolite".
Having a little time to lose, I put my hand on an old project as a "breed" and I put myself to "parameterize it".
new experience for me, even if I have always worked with the parametric module, and (apart from a series of intestinal discomfort, side effect not eliminateable :smile: ) I had the opportunity to focus on philosophy of approach and work.

I hope that ozzy wants to participate and I will try to be short and concise (as usual!).

Hi.

I've already told you everything...

 

[cacciatorino]

m

just to introduce the topic, I have an idea in the head, the parametric should be divided into two "areas", the "vincolation" and the "parametrization" that, instead, seem too confused and superimposed.
binding should be a dimensional control of the model, while parameterization should be the "life" of the model.

I think them apart because, for what I think, the first phase (win) should be carried out with the tools we already know as designers, the q&t (quotes and tolerances).
.

other important aspect not mentioned: the story of features. It's a partially disconnected fact from quotation and parameterization, but it's very important to have it always to have a modeling flow similar to that of processing at m.u.
you can also use it to extend the processing cycle, by re-executing the steps of the various modeling steps.
These are now "assimilate" concepts for those who use traditional parametric cads, but perhaps new ones for those who are accustomed to contextuals.

 

[Fulvio Romano]

I'm intruding and quoting hunter. "parametric" software (better to call them feature based, which is opposed to nurbs based, or even old octree) does not serve to find a way to represent an object, but rather to optimize its production by putting it in the foreground already during modeling/design. This principle, often leads to brain operations to get rather intuitive objects, but unfortunately these objects do not marry well with the basic principle of features based.

In addition the parameterization (not necessarily feature based, there are some examples of parametric nurbs based...for the truth are a bit sad as results) is useful to quickly change objects, and to create changes to cascade, but this is a side value of the basic concept above exposed.

 

[re_solidworks]

I have made my own precise idea, which confirms my initial hypothesis, needs something new that makes the parameter more "conscious" and less "alienant".

just to introduce the topic, I have an idea in the head, the parametric should be divided into two "areas", the "vincolation" and the "parametrization" that, instead, seem too confused and superimposed.
binding should be a dimensional control of the model, while parameterization should be the "life" of the model.

I think them apart because, for what I think, the first phase (win) should be carried out with the tools we already know as designers, the q&t (quotes and tolerances).
as a designer I would have no difficulty thinking how to bind a piece and I do not see why I should learn to bind it differently just to please the sw, the rules at the base of q&t are universally valid and known.

What different the parameterization, that is to establish which quotas (wins) can vary (and with what limits) to generate "adactive" models or models families.

dividing binding and parameterization is very difficult in my opinion. the two things intersect often and when you put the constraints generally you try to "predict" the feasible or probable changes and what "parameterize" in the future. For example, if you go to create a variable and this begins to wander with a bond it is already a problem.
Moreover the speech gets complicated and not little when you put in between the top down and the skeletons. This is (in my opinion) the real strength of the parametric, although it is frequent cause of headache.

sketches and processing should be quoted (and tolerated for cads that have this possibility) in the same way that the piece will be worked on m.u. There wouldn't be the difference you're talking about.
to get this, when you model a part better from the semi-finished crude available in stock and proceed to excavation force, and never use additions of material.

then there are modeling techniques in the axieme with links between the parts that make it impossible to deal with reasoning in these terms, but in some cases they are of great convenience.

not only links between the parts make this type of execution impossible, but I got used to speculate every thousandth of a second looking for the modeling + light possible for the management of the big assemblies. In this way I always use the features + read to be rebuilt disinteresting me to have a tree of the model equal to the working cycle.

 

[Matteo]

according to me modeling "parametric" and "direct" (or "feature based" and "explicit" that you want) are two sets partially overlapped. Many things are feasible (and with some efficiency) with both systems, while some specifically require one or the other instrument.

 

[Matteo]

according to me modeling "parametric" and "direct" (or "feature based" and "explicit" that you want) are two sets partially overlapped. Many things are feasible (and with some efficiency) with both systems, while some specifically require one or the other instrument.

the ideal would be an explicit software that included the possibility to manage parameterically only some features. for example: we imagine a design object, for example a bottle like this: http://www.piliscomp.com/~motorola/.../product/34fe074c6b7bfda4a2a0a48f9815f584.jpg (I had modeled everything at the time using the advanced surfaces of proe wf2, but the model, formally still parametric, was almost impossible to change parameterically).

the "style" part is convenient that it is "explicit" (rhino? Cocreate? spaceclaim 2009sp2?) while the threaded part for the connection of the spray or plug would be convenient that it was parametric (in order to vary diameter, step, etc.).

with various tricks (e.g. importing the geometry of "design" in a proe type parametric) the thing can be done, but communication between explicit and parametric is still quite difficult (also cad that propose both technologies, in fact include two distinct modeling environments).

 

[Fulvio Romano]

the "style" part is convenient that it is "explicit" (rhino? Cocreate? spaceclaim 2009sp2?) while the threaded part for the connection of the spray or plug would be convenient that it was parametric (in order to vary diameter, step, etc.).

with various tricks (e.g. importing the geometry of "design" in a proe type parametric) the thing can be done, but communication between explicit and parametric is still quite difficult (also cad that propose both technologies, in fact include two distinct modeling environments).

a similar approach follows it. the software is unique, but in reality the modules for mechanics and for the surfaces are actually two different things, they buy separately and install themselves as they were plugins. the convenient thing though and is that "commuting" the two packages, visually changes only the set of features available, while all the rest of the interface remains unchanged.

 

[Matteo]

a similar approach follows it. the software is unique, but in reality the modules for mechanics and for the surfaces are actually two different things, they buy separately and install themselves as they were plugins. the convenient thing though and is that "commuting" the two packages, visually changes only the set of features available, while all the rest of the interface remains unchanged.

Proe style surfaces also work so big. my impression, however, is that these are "non-parameter" elements in a parametric context (for those who use proe: how to make an "external copy geometry not dependent").

as stefano said (if I did not understand badly) it would be interesting to do the opposite: have an explicit context in which to build "zones" parametric by specifying references only when needed (I think technical difficulty is right here).

 

[cacciatorino]

Proe style surfaces also work so big. my impression, however, is that these are "non-parameter" elements in a parametric context (for those who use proe: how to make an "external copy geometry not dependent").

as stefano said (if I did not understand badly) it would be interesting to do the opposite: have an explicit context in which to build "zones" parametric by specifying references only when needed (I think technical difficulty is right here).

It's not so futuristic. I use solid edge can very well leave a profile or a sub-wine feature, there is no problem, and I do not need to export in step and reimport to do so,
problems can arise at a possible regeneration of the model, but they are things that one takes into account when he does not want to bind to have greater freedom.

 

[Er Presidente]

my intention was to discuss how to have a parameterization of a universally recognized and manageable model, not so much on the eternal conflict between parametric and contextual.

p.s.: I am at the sea so I read you from an internet point, hello to all

 

[cacciatorino]

my intention was to discuss how to have a parameterization of a universally recognized and manageable model, not so much on the eternal conflict between parametric and contextual.

p.s.: I am at the sea so I read you from an internet point, hello to all

do you mean an independent software parameterization? Is that some sort of paramount step?

 

[Fulvio Romano]

Proe style surfaces also work so big. my impression, however, is that these are "non-parameter" elements in a parametric context (for those who use proe: how to make an "external copy geometry not dependent").

That's not what I say. modeling with surfaces (catea, but also alias, rhino) does not mean ignoring the parameterization. each surface has its own history (repeto, also for example with alias), and modifying the native elements it is possible to update the whole story of the surface. of course the concepts are different from processing features, but the principle is the same.

do you mean an independent software parameterization? Is that some sort of paramount step?

If that's what the president means, I think he's already talked about it somewhere else. the idea seems good, but actually losing history in neutral formats can be useful to keep "secret" or "unchangeable" files provided to customers or suppliers. ..certo, you could turn on or off any "export feature" function

 

[cacciatorino]

If that's what the president means, I think he's already talked about it somewhere else. the idea seems good, but actually losing history in neutral formats can be useful to keep "secret" or "unchangeable" files provided to customers or suppliers. ..certo, you could turn on or off any "export feature" function

In addition to this, a real interoperability of formats, although very useful to users, would be extremely detrimental to the economic interests of the software house, so it will hardly be implemented (see for example the battle conducted by microsoft against odf).
But I would ask the stefano to be more explicit about what he means otherwise by force of things the discussion is dispersed in various revels and repetitions of things already said.

 

[Er Presidente]

do you mean an independent software parameterization? Is that some sort of paramount step?

I mean a philosophy of parameterization, where a user can recover the same guidelines, regardless of which software he is using.

 

[MBT]

I express my personal opinion.

I used 3 sw modeling, always drawing pieces for the construction of machines. no strange styles or shapes, always mechanical mold pieces, carpenters, worked pieces aimed at functionality.

of the 3 used sw, all parametric, I have always hated the concept of "rigidity" that is the prerogative of the features-based.

my impression is that all these software are excellent, exceptional, in case of "development" or improvement of the product, but pop up when it comes to design starting from "white sheet".
I make a classic example. If I built gearboxes, let's put endless screws, I'd take the maximum advantage from the parametric. once studied and prepared the first reducer, we say of size 32, changing the parameters it is very simple to get the other quantities, as they are "homothetic". the construction is identical, change the quotas.

but if I had to start from "white sheet", this capacity is useless to me.
I need to draw without having to think about how to change later.
I can't worry about thinking whether this sheet will remain sheet metal forever or if I have to add a welded reinforcement tomorrow, turning it in fact from side to side.
I do not have to waste time and mental resources (always more limited) in deciding whether to build a tree by extruding a circle or revolutionizing a rectangle, knowing that an option leads to certain advantages and certain disadvantages compared to the other.

claim that the features tree should be a track of cam processing is a truth and an idiot at the same time. It's true in the "optimisation" cases I mentioned above. I already know everything about the product, I have to optimize it and therefore I can devote mental resources in the care of the features, in the choice of relationships between quotas etc.
but if I have to "invent" the component, I can't spend time thinking about what steps will have to be done. the important thing is that the component is feasible and that it is realized as it serves me.
even, I can have the need to indicate in the constructive sketch of the quotas that then would not make sense to trace in the table, or vice versa.

I happen to realize a component with a certain order of features.
then, in the advance of the design, I need to review the construction of this component, heavily changing some features and keeping others. and in these cases I have to redefine those that, for various reasons, fail even if not directly involved in the change. but they had taken, perhaps of their own spontaneous initiative, references in the modified features and so... hours to solve the failures.... idem in the assemblies, when the constraints fail because you have eliminated a ray or revised some features of the "coinvolt" components.

 

[MFT]

I fully share the analysis of mbt also I found the same problems.

Mar