[Rhino 8 Beta] Can we "hack" Serengeti to make it partially-parametric?

I have an idea about how to use Grasshopper Attributes with something like GHPython to add “Parametric-like” features to Rhino 8. But don’t know if it’s actually feasible. Or even if it is feasible, if it would be practical and useable. (Or if I’m trying to solve the wrong problem. XD)

Brief description below:

What I want:
I would like to have snippets of Grasshopper code linked up to specific instances of geometry in a document. Running each snippet would generate and/or modify geometry that is (automatically) baked into the document. When I want to, I can click on one of these generated geometries, and tell it to update. (The update might or might-not be recursive, as the geometry could depend on other GH generated geometry.)

How might we do this, in a very hacked-up way?
I suppose we could use Attributes in Grasshopper to store meta-data about how to generate a geometry. For example, the meta-data could have a links to the geometry it depends on, as well as a Grasshopper file. (The tricky bit might be how to assign inputs to the Grashopper file?)

In theory, it seems like that could contain all the info for how to create the geometry. You could then feed this geometry to a python script in Grasshopper which reads the geometry’s Attributes and figures out how to update it (say, delete the geometry, but then run the Grasshopper snippet that re-creates the geometry).

Wait, what??? Wouldn’t this be fragile as heck and cause problems?!
Well yes. You could easily shoot yourself in the foot with a cycle in the graph of dependencies, which would mean an infinite loop. Plus if you try to update geometry, but some dependencies (other geometries) were deleted, then everything breaks.

If it would be so fragile, why do you want this?
Well, I mostly work on relatively “small” projects, so I’m thinking I could get parametric-features in Rhino this way, but the fragility would be limited for small projects. Because, hopefully, small projects would only have a small dependency-graph.

Why are your projects so small?
I’m mostly a maker-hobbyist with a 3d printer. So I’m not designing full assemblies (like in architecture, or product design).

Would this even work at all?
Not sure. So I’m asking if more experienced Grasshopper users and developers can weigh in. Would this work? Would it be a good or bad idea?

Sincerely,
–Anthony K. Yan

1 Like

Exactly… me, too!

I think what you want is something like this:

especially this (don’t get rejected by the title ‘furniture’ - it can create anything):

or this:

Both (commercial) plugins make it possible to embed Grasshopper scripts in dynamic blocks, in a way that only the input parameters of the GH script are exposed in the standard property panel of the object. Changing the parameters updates the object in realtime then.
→ parametric Rhino!

I have a VisualArq license, and thus know this feature quite well, and used it one numerous occasions. However, since VA is not for free, and sells itself as an architectural extension, it eludes many people that this powerful feature is even there.

APE I just gave a quick test and gave it up since I already have VA…

In a perfect Rhino world, parametric GH blocks would be a standard feature, so we could start building an infrastructure of ‘smart objects’ of all kinds, ready to use in a standardized way, instead of a litter of random Grasshopper scripts, all quite different to use.

1 Like

I think that McNeel will work on some parametrics starting with Rhino9? There was an attempt in some RhinoWIP but the project get stagnant.

Interesting… will dig in youtrack.

Rhino WIP Feature: Constraints - Serengeti (Rhino 8 BETA) / Constraints - McNeel Forum

Ok, no. Constraints are something very different from what I meant, and I believe also what Anthony meant.

It was about ‘feeding’ GH scripts into a ‘smart block’, thus exposing input parameters in the regular property panel, which can be tweaked without the need of a floating GH panel.

Xpanel then?

1 Like

Nice, look at this…! Thanks, will check it out!

Ok no, XPanel is just another version of the Grasshopper Remote Panel.

I’ll rephrase what I meant:
Objects can ‘embed’ the GH script that drives their geometry, thus the script becomes part of the object description. Save/load the scene, and it’s still in there.
The input parameters of the GH script are automatically exposed as the object’s parameters, and can be accessed and tweaked in the regular property panel.
In the VisualArq solution these parametric objects are blocks, which contain then whatever the embedded script generates. Dynamic blocks.

What makes the big difference: you don’t need to store / handle all the GH scripts togeher with the Rhino scene. You don’t need to have GH open to use the dynamic objects. No baking necessary.
You could have many of such dynamic objects in the scene (which is typlical in e.g. architectural planning), all editable just by tweaking their input params. The person using this dynamic block does not even need to know how the internal script works. Black box principle. (Of course, the script itself is editable at any time, if needed)

Comparable with Blender (with geometry nodes) and of course numerous other applications.

In fact, plugins for Rhino already exist that do exactly this - see before. There’s a price barrier, though.
The big step forward would be if McNeel embraced this idea and brought a solution of their own.

@Anthony_Yan: apologies if this deviates from your initial idea, in which you seem to try to find a solution with o.o.t.b. tools. I’m trying to raise awareness to there’s a bigger picture to this, and that it is desirable enough to challenge McNeel for it.

1 Like

Hi Eugen -

We have this request on the list as RH-34030 “GrasshopperBlocks: AKA ParametricBlocks AKA DynamicBlocks AKA SmartBlocks”.
I’ve added this thread.
-wim

3 Likes

Thanks for the discussion.

What I’m looking for is fairly broad and general, and could be handled in several different ways.

(1) One way is Constraints, that are coming (probably in the next version of Rhino).
(2) Another way is to “embed” or “link” Grasshopper code (and/or Python).

Each has different tradeoffs. Ideally, it would be nice to have a constraints-solver that combines nicely with Grasshopper (and/or Python).

But for me, I was looking for something that I could use right now, or in the near future, while I waited for a better solution. And I thought, why not use Attributes to embed GH code in geometry objects? If you can do that, plus some internal-automation, then you could kludge together (2) without too much effort or expense.

As a hobbyist, I can’t justify the purchase of fancy tools, so as mentioned, I’m facing some price barriers. So looking for a work-around, until Rhino has constraints that inter-operate with GH.

Maybe I just need to accept using Rhino WIP on my projects? A little scary if a future beta version breaks an older project. Perhaps I can accept that risk.