This request exists all over the place. Mostly called parametric tree, parts tree of something like that…
There are a number of them available in Rhino at this time.
MatrixGold and others for Jewelry Parametrics
Orca3d and ExpressMarine for Hulls and ships.
Architectural - Visual ARQ, APE and Grasshopper in Revit, Grasshopper in Tekla
Grasshopper for Freeform Parametrics
All of these have various ways to optimize, split the components and different ways they interact. Each engine above needs to be specific to the modeling task to try and keep performance at least somewhat reasonable.
At this point we are not sure what is in Rhino 9.
Rhino 8 content cache has more options in tracking components in Rhino. We can work on example in another thread if that is of interest.
I guess it is full parametric modeling, which would be a wonderful and much-requested feature to add to Rhino. GH has always felt like an overly complicated parametric workaround.
At least in the jewelry plugin space, it’s not the same thing. Jewelry plugins are fancy automation scripts that create a specific type of geometry with a few numerical inputs.
That History Visualizer is generic. It’s a GUI front end for the CRhinoHistoryRecordTable. We won’t see that type of functionality exposed in plugins until RhinoCommon has full access to that table.
I want to echo the importance of having a tree (management of feature dependency over time that is robust to changes at any point in time). Designing complicated parts without this is crazy. One must be very very good––like sculpting a rock (cannot add more rock if carved away too much) rather than with clay (can always add more clay).
One reason GH is much more appealing to me (99% time, Rhino window is there to visualize GH geometry only) is that its interface organizes features in a tree.
I wouldn’t confuse parametric modeling with a robust history. To me they are different things and often the aformentioned word makes the McNeel developers turn around and say that’s not their thing. The discussion around this in Rhino would be very different if McNeel hadn’t neglected the little history support they already have and instead made it robust, with geometric ID matching and “nested history”…
But that looks to be a different issue. In that screenshot at least, it looks like the surface structure of the top surface changes significantly, and so will its edge domain. I don’t believe there is a fix for that (yet). I believe the gh solution that I offered earlier in this thread should be able to handle that case though, did you try that?
Well, yes, the top surface changes (along with the bottom). This bug file, which was logged as RH-81297, has one repro step - Scale2D that one curve.
I don’t understand what was fixed. So far, I can see no difference to BlendSrf’s V6 behavior.
Grasshopper is not an option. I use copy/paste history to drop 20 of these in a file. GH gets way too complicated when you try to match up 20 sets of surfaces to get a blend between them.
(although, it is infuriating to know that gh works without a problem while v8 works like v6)
well, the gh file I sent doesn’t work flawlessly either and is hard to set up in gh. I am not trying to sell it as a solution. I agree that having to do this for many items becomes cumbersome.
What I don’t quite get from your file is that you set up the base shape with a sweep. This makes a huge change to the surface structure when you scale the sweep rail, while it can stay a simple revolve. If you do the latter, then the BlendSrf seems to stay in tact: BlendSrfBug_revolve.3dm (3.9 MB)
