I’m looking for a way to reference geometry made in rhino to grasshopper that will be automatically replace by the new bake geometry.
I’m not sure if it is possible with Elefront. (or even native components…)
What I can acheive is :
referencing the previously made geometries in rhino inside grasshopper.
Assign it attributs (object name)
Bake it with theses new attributs
BUT it didn’t replace the old geometry previously made in Rhino!!!
As I need an iterative process with differents manipulations within grasshopper, I would need the new geomtery to replace the old one each time I bake and more especifically the original rhino created geomteries!
This is what I did.
But it didn’T replace the first original object created originaly in rhino. This orginal object do not have a name (Atttribut) yet, until I bake it for the first time with attributs I gave it inside grasshopper.
Also the elefront website doesn’t provide much of informations.
Are you sure that you want to use Elefront to delete your original Rhino geometry? There are lots of other options, e.g. 1. Internalise the data in gh & then delete the original geometry in Rhino, 2. Keep the original geometry on a separate layer or in a separate parent layer (as a back-up or for reference), …
BUT if you want to use Elefront to delete it, here’s how: In Rhino, select all of the relevant geometry, then go to >Properties >Attribute User Text, then type in ‘BakeName’ for Key, and ‘(whatever BakeName you are going to use)’ for Value. All done, now it will be deleted when you Bake with Elefront.
This is precisly this manual step that I try to avoid and was wondering if it was possible.
In other word If I start from a 3d rhino models with lets say 20 layers, could I just start a .GH definition that will automatically get the layers, and start overwritting the geometries of theses layers on the first bake ?
I haven’t explored Elefront that much but I don’t think so, at least not with Elefront components. Maybe if you give a simple example of what you’re trying to do (i.e. why you want the [child/baked geometry] to nuke/delete its [parent/source geometry]), people can offer suggestions. It seems like what you’re trying to do is loop and, by my understanding, Elefront is not conceived for that; it has the same structure/limitation as Grasshopper: linear/downstream flow only. Elefront is conceived to break large projects/workflows into smaller, inter-communicating chunks, but always with a downstream flow, e.g. Building Volume > Building Facades > Facade Grids > Grid Panels > Panel Detailing; if any of the downstream children deleted their upstream parent, it would spoil the party …
Off the top of my head, you could achieve something close to what you want by putting your Elefront script inside an Anemone loop: Put your 20 layers into a parent layer, “Iteration_0”, get Elefront to reference by layer, “Iteration_X::[wildcard star]” (where X is an Anemone counter starting at X=0), then Bake to layer “Iteration_X+1::[all the child layers]”, Anemone counter ticks over with each bake, etc.
If your objective is to be able to add new Rhino geometry between iterations, whilst maintaining a clean set, then you can; just build the new geometry in the ‘current’ parent layer (and if you really don’t want a record of your source geometry, delete the ‘obsolete’ parent layers manually or with a script, etc.)… but, just to point out the obvious, in grasshopper you can already bake or preview at whatever stage of development you want, whenever you want, and can bake to whichever layer you want (again, maybe a simple example would make your problem clearer)… happy hunting
If you just want to assign attributes to existing objects, you can use the Modify Rhino Object Attributes component. You don’t need a bake name for that. Input only needs to be an object already in the Rhino model.
This is what I was looking for. As I see, without a small C# script that looks tedious… do you mind sharing Gh definition, I’m not familiar with manual scripting.
And I understand more clearly the challenges with the quick info @Jack_Brown provide (thanks also).
