At the very beginning, a plane is plugged into a Model Object component. This turns the plane into a Block Instance with a pre-defined layer.
Plane blocks are baked with a Grasshopper::Planes layer
I don’t think this is how it is supposed to be and the layer should be able to be set by the user.
After some baking and exploding I realized a plane is baked with all this curve geometry…
I don’t think this is something I would use and I would probably bake a surface instead.
A possible workaround is to create a Grasshopper plane block on XY, explode it, define it as a block instance on my preferred layer and reference that as a block definition in GH to bake it at an arbitrary orientation.
At this point I’m wondering what the benefit of such a plane is. If I want to draw something on the block plane, I can set the CPlane to object.
A Grasshopper plane has 8 divisions and the size 1000 results in a 125 units grid. Also not so sure about this. To me this feels like a bit of a conflict with the regular Rhino CPlane.
Maybe instead of baking the plane to a layer with all these curves, a named CPlane could be saved?
A CPlane could be saved the same way a view is saved as a Named View…
Thanks @martinsiegrist for bringing this to our attention. I think there are two issues here. First is the issue where baking a plane as a Model Object makes the block definition (not the instance) be assigned to the Grasshopper::Planes layer. I’ve created a YT for this issue to see if we can figure out a better way to handle that.
Secondly is how the plane/block instance is handled when it is baked into the document. Typically, if you were to bake just a plane parameter, it would be inserted as a Surface into the document. I believe the reason it shows up as a set of curves is to preserve the visual representation of a Grasshopper “plane” in the Rhino document. This representation does give you an indication of the coordinate system of the plane but as you pointed out, it’s like adding additional bloat to the file which may not be needed. I’ll need to discuss this more with @kike. As I said, the most 1 to 1 correlation would be to bake a surface, but that doesn’t really give you as much information as to what the plane represents. Let me see what we can come up with.
Thanks for the reply @AndyPayne
I think the surface was a simple representation for a plane but if we really reduce things as much as possible, a point in a block is all we need.
An empty block could be baked but I don’t know how to select it.
A block with a point is simple to select, does not offer any additional OSnaps and Auto CPlane orients to the block plane. A point is the least ?intrusive? and selectable object.
My test file:
block_plane.gh (38.2 KB)
I updated 8.1 to allow you override the ‘*Grasshopper::Plane’ block with whatever representation the user likes.
By default it works as before. Geometry pushed without a layer is assigned to a default by-type layer under Grasshopper.
You can assign a layer as you do to any other geometry type like this.
And now in 8.1 you can define your own ‘*Grasshopper::Plane’ block just baking it or creating one with this name using Rhino. You can have you own now defined on your Rhino template and will also be respected.
Grasshopper will create the default one if missing or if is empty.
I hope this helps.