Go Parametric

[sbaer]

moved from wiki(http://wiki.mcneel.com/rhino/wishlist) It would be great if Rhino could in its future development become a completely parametric modeling application (e.g. like some catia modules) - history is already a great step in this direction.

Following recent discussions amongst a few power-users in the Netherlands, it can be questioned if Rhino should go parametric as there are already several good parametric modellers around. Parametrics also introduces some restriction on free modelling. Therefore, it could be incorporated at a second modelling route, or perhaps McNeel should choose not to go parametric, but excel in free modelling and interface really well with parametric software for rationalisation. - Jeroen

[sbaer]

hey jeroen,

a parametric approach in rhino could offer the possibility to combine the ease of use of its free modelling with the power of parametric modelling where needed. especially in [[rhino:architecture|Architecture]] but also in other disciplines, parametric apps are not only used for production but also for design (gc - at aa etc., top solid - at the berlage, catia/ dp - at the ETHZ). so export - import bewteen applications is just too time consuming. another problem is that e.g. in catia you can switch off the parametric behaviour but it is still completely inconvenient and clumsy to model quickly and efficiently with it (same goes for topsolid, i don't know gc). exactly in this area i would see rhino profit a lot from a parametric approach. FAST+PARAMETRIC

[sbaer]

I completely agree that parametrics would be a useful path next to the current free modelling path. However, still the questions remains if one will not suffer if trying to be good at both. But if it is possible while maintaining quality, please make it so.

• Jeroen

[sbaer]

We already have parametric modellers. The value of Rhino to us is the freedom we have of not being parametric. I would suggest that feature based modelling, like KeyCreator - http://www.kubotekusa.com/swf/dimension-driven.html has, would be a better way to go. -Dan

[sbaer]

IMO, parametrics is better added as a plug in. There are already parametric plug-ins being developed for Rhino for various applications. That would leave the base application more open and less expensive for those who do not need/want parametrics. Of course, the main Rhino core, not being based on parametrics, may limit what can actually be done by plug-ins to some degree (I'm not a programmer).

I agree with Dan that direct editing (based on features or whatever) is really the way to go, and that this would be good to have in the core, as a next implementation of the editing toolset. The problem with UDT is that it's not feature based and very hard to control accurately (besides the fact that it usually makes very knotty complex surfaces) and the solid editing tools currently available only work on a very limited set of simple objects. -Mitch

[sbaer]

Hi, I second that feature based modeling with geometry recognition is a direction to go in, because it is flexible and universal. Preametres do not have to interfere in the modelling process in a negative way. Keycreator is a good example of this.

History can be tied up to feature recognition and parameters, so it is easy to change the radii of fillets and holes for example. The fillet and makehole commands can possibly be parameterized automatically in history. Then a Record Paremeters =yes/no option could be in history. It would require a smart way of collecting parameters though, maybe pre selecting what kind of features should be auto parameterized is required.

What if Rhino models and Imported geometry can be scanned for parameterable features; a checklist of what you want to scan for, and one for selecting which parameters you want to keep once the scan is finished? Some kind of filtering in advance is required i think, there can simply be to many parameterable features in some models. A diagram view of all the parameters, where one could change their values directly would be nice too.

• the UDT commands have an option for fast/accurate; if you choose fast, the resulting surfaces keep their original point structure and do not get knotty (in most cases).

[sbaer]

A clear strength of Rhino is it's surface modeling. RhinoScript and the SDK further strengthen the product. //PLEASE// work on stabilizing the code, improving the user interface and related functionality 'bends'. Only McNeel can know when 'its good enough' and where they reach for diminishing returns. We have a very affordable, extensible, flexible tool. Please don't create more headaches. You have done a very respectable job so far.

• Paul F.