Go Parametric:

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

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 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

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

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 has, would be a better way to go. -Dan

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

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).

<Fredrik>

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.>

I am in agreement that any parameteric features in new versions of Rhino should exist along side its current functionality. Being able to do things fast and without setting up relationships is very powerful, not only for workflow in certain situations, but also for new users being able to use the software effectively (something I have always thought rhino was exceptional at). Having either certain commands that are either parametricly based, or adding that (optional) functionality to existing commands. For Example...Within a fillet command (fillet, filletEdge, FilletSrf, what have you) there can be an option for the command to be parametric (in the command line Parametric=No/Yes) which would record the value. Once within the parametric option, there could also be an option to retrieve a parameter which could enable a user to pick from other pre-existing parameters/values. An EditParameter command would then allow the user to go back and edit things by click in a parameteric feature.

My other concern with moving towards Rhino being parametric would be the scripting side of things. Scripting becomes suddenly a whole lot more work because all of the elements/inputs have to be created and defined parametrically. This leads to scripting being much more tedious and far more difficult to implement.

Those are my thoughts... part of me wants parametrics, and the other part of me enjoys the freedom that Rhino gives me.

-Damien

I've been working with GenerativeComponents and its not all that bad mainly because you don't need to build models over and over again, instead you lay out ground rules and use the variables to explore your designs. I guess if Rhino could have a parametric module, more powerful then ParaCloud lets say and takes into consideration the lines of production then you'd have a fairly powerful tool at your disposal.

-jack

hi i work as architect and now i have also teaching lessons at the university with the machinery studies. Pro/e etc. For architecture Rhino is the best tool you can wish. but i have also respect in the Pro/E parametrik approch. The problem seems in the kernel of Rhino. Specially the boolean function has still problems. I think that the concept of the "explict history" is really good. It should get a possility to get nodes for external execute programms for heavy calulations. So it would be possible to implement a 2d sketcher and maybe a better boolean operation. Also a Hex-mesh or a Matixsolver could be Integrated later in explicit history. this would give Rhino the ultimate power. I think i the far future it would be really cool to integrate the workflow of Pro/E on top of "explict history" and then relink it with flags defined in the sketch...maybe the on top tools have a different kernel (sat,granite...) lol

michael