Manual Interacting within Grasshopper: Caché geometry?

Replies to This Discussion

Permalink Reply by kleerkoat on October 1, 2011 at 10:44am

dunno if that's been requested before, but that's a pretty cool idea!

ryan

Permalink Reply by Vicente Soler on October 1, 2011 at 11:33am

Try this. I just put it together quickly so its a bit rudimentary.

The m input is for a mesh object, the n input is for a unique name for that object. If you plan on using multiple objects use a different name for each. Every time the definition is changed upstream, the baked mesh will be reseted and you manual changes will be discarded.

Permalink Reply by Vicente Soler on October 1, 2011 at 5:29pm

Updated the script with these changes:

- Now works for a list of objects using the same object name.

- Every time the definition is updated upstream, a dialog box pops up asking if you want to replace the baked geometry or not.

Use this one instead.

Attachments:

• autobakeref.gh, 4 KB

Permalink Reply by Doctor No on October 2, 2011 at 3:19am

Hola Vicente; thanks for the reply, and the component, I already knew your advances in autobaking long time ago; May be I should ask David, but I was wondering if it is possible to have this feature inside the commands for every geometry component or geometry parameter soon, just to have it available in long tree-data definitions, trying not to slow down the solutions, and automatically deleting unused baked geometry inmediately after modifications, without clicking on both bake and load caché geometry as the example above.

Permalink Reply by Vicente Soler on October 2, 2011 at 3:43am

This is the first time I've done this script. Maybe you are referring to a different one I did some time ago were I was modifying a referenced object.

I agree it could be useful. If it's not done yet is probably because there is not an elegant way to quickly deal with it. My script above does roughly what you ask for but there are many things that can go wrong.

Permalink Reply by dominic on October 4, 2011 at 7:36am

 

Hi NaN,

 

Interesting request. I am intrigued by the mixing of GH script based geometry and the traditional 'point and click' direct modifications that you are grappling with.

 

I am not sure what you mean by 'Activate Direct Rhino Modifying'. Perhaps you could expand?

 

I like the idea of mixing and matching script and 'direct' modeling. There seems to be a lot of potential platforms for this:

 

1. Implict History: Is there a way for GH to read the direct modifications (with History activated) and translate this as a component (or cluster of components?)? IH seems to record the UI events and the associated elements. GH would need to write as well as read the IH info, in order to preserve as much flexibility downstream as possible. You mentioned Houdini. H seems to record all 'implicit' or direct mods, done via the CAD mouse-based UI, in its network graph. Maybe, this should be captured in the IH cluster/component mentioned above.

 

2. RhinoParametrics: RP has done a lot of work to intercept and translate Rhino commands into its version of Implicit History. Seems to be centred on points, which makes sense as so much of the traditional 'dumb' way of inputing CAD info is based on mouse clicks on screen (points) predicated by commands, active locks, workplanes etc.

 

3. Gumball: Rubberduck's use of the new Gumball tool to capture 'direct' modeling inputs thru the Gumball points to a good source for capturing this kind or input, that is related to the 'macro recorder' approach taken by RP and IH.

 

4. The new Geom Cache component seems to be able to preserve a lot of info about the baked object. There may be even a way to read tagged info generated both GH baked with the "reference" object, and external to GH (by IH, the gumball or even third party apps like RP).

 

Would be interesting to know what kind of info is 'preserved'. Houdini seems to have a pretty consistent approach to geometric data, that seems to allow parallel NURBS/subD/mesh versions of the geometry. It also seems to have a coherent heirarchical approach to vertices/edges/loops/faces etc that allows the subelements to be arbitarily grouped for 'direct' modeling, and still be part of a procedural script.

 

I guess the polygon / mesh approach to geometry lends itself to this. If all the procedural commands/components all understand mesh geometry in either vertex, edge, face format, then combining direct and script modeling is doable in transparent way?

In your example above, the Geo Cache node 'flattens' the object to dumb geometry which is manipulated using Rhino, then used as a Reference object, in the next section of the graph. I guess there is nothing to stop the follow on components reading the precedenting graph for parameters, for additional intelligence?

 

Does GH 'get' or 'put' parameter data?