Grasshopper

algorithmic modeling for Rhino

Reference>Rhino Delete>bake cycle, triggered by GH change (interactive geom)

Hi All,

I'm trying to find a simple way of getting Rhino to interact with grasshopper geometry so that a curve can be manipulated in Rhino, but would also allow changes to it from grasshopper.

I have set something up that achieves this to a point, using some components from Lunchbox and Human to demonstrate a Rhino curve following a gh surface, which works just about well enough for what I need, except it doesn't allow the curve to be modified very well in Rhino as GH is constantly re-writing the geometry.

See attached files - I should mention this seems to go against GH rules so it's prone to crashing everything - be careful if you take a look!

...I am wondering if there is a way to create a trigger which listens for changes in GH, to cycle the process - ideally it could also temporarily disable re-referencing so there is no chance of crashing...  is such a trigger component available?  a delay timer might also be useful to go with it.

or is there a better approach to this altogether?

Any help or thoughts greatly appreciated!

Views: 1315

Attachments:

Replies to This Discussion

Hi Tom, thanks for the reply.  Unfortunately I'm not able to code much at all...  I can see the logic problem you refer to, but wondered if there could be some clever way to avoid an infinite loop.  

In my mind I thought if it were possible to 'listen' for a change in GH (in this case a height change) then tell it to run a loop with anemone that would bake a new curve at the new height, delete the old one and reference the new one back in from Rhino.  I think this would need the following things to happen that I don't know how to achieve:

1, listen for change then trigger next steps:

2, pause referencing or hold referenced object (maybe with a data dam, time buffer component in anemone or capacitor component in Heteroptera?)

3, delete and re-bake 

4, re-start referencing

Do you think this might work in theory?  Can you see any way to achieve it?!

Many thanks

I Mattew, I had kinda the same problem and I solved this way:

1. I use Elefront bake component

2. Elefront block has this wonderful feature that asks for the name of the object, so when it recognize a name that already exist it overwrite it!

3. I give my curves names

4. I manipulate my curves and bake after manipulation

5. the Elefront bake block recognize the curve being the same and update it ---> I can control Rhino from GH

Known Issue: the first time I do that GH returns a error. I ignore it and the system works in all further iterations.

Hi Gabriele, thanks for your advice - however, I don't think this overcomes the original problem of being able to also modify the geometry in Rhino too.  Or am I missing something?!!

Essentially, I'm trying to find a way to be able to modify the same geometry in either Grasshopper or Rhino continuously.   In my example I was intending to show that whilst GH could control the height of the curve, the shape of the curve could be modified in Rhino if that makes sense?  

What you can do is using bake with name (elefront) + reference by name (elefront or human)

By doing so you create a continuum pipeline between GH and RH

GH to Rhino = Bake with name (e.g. OBJ_001 of course, you need to find a way to generate new names, i did it by python script)

Rhino to GH = Use reference by name (elefront, humana), this wonderful component take names as input and returns a geomety as output. Since the geometry previously created have a name you gave, next time you bake it the geometry will be overwritten!

Try and let me know. But it works, for sure.

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service