This is about Blocks managed with the ELEFRONT plug-in. Perhaps @fraguada have a solution which I failed to find on my own.
Short version: I would like to get rid of the first Block Instance when baking Blocks ( = that is, I want to keep only the Block Definition).
Plug: And for anyone using Grasshopper, the Elefront plug-in is very powerful in enhancing Grasshopper with Block management and User Attributes that can be attached to any object.
Longer version:
I don’t seem to be able to create a Block Instance directly from the internal GH Geometry without first baking a Block Definition (correct?)
When I bake a Block Definition, I also get a Block Instance (which I don’t want, because I don’t have a proper name for it, since the instance names are defined later & elsewhere).
When I later create/bake Block Instances (see picture), I would like to auto-delete the first Block Instance which came when the Block Definition was baked (that unwanted instance from §1 above), not only any previously explicitly baked Block Instances.
If no other solution exists, the above could be handled if enhancing the Bake component as follows:
4.a. The Bake component doesn’t seem to remove named Block Instances as specified in a List of different names (only one name in the List, if feeding a List to the (N / Name) input). Wish: Delete multiple instances with different Object/Instance names as specified in a list.
4.b. Also, if many Block Instances with the same Object/Instance name exist, only one Instance is deleted (if defined in 4.a.). Wish: Delete all instances with any name(s) specified in the N / Name property. That would be gold.
UNCERTAIN
I’m not 100% sure of if the Bake/Delete Name refers to named Instances or to Block Definition names, but if I conflated the two, then it would be a good idea to clarify the difference in the components’ mouse-over hints.
OTHER WAY?
Is there a way to get rid of other (named) instances not covered by the Bake component, other than with a custom coded Script component?
// Rolf
Fig.1. The first line in the panel shows an example of a baked Block Definition, which resulted also in an instance, with the same object/instance name as the Block Definition, the instance which I want to get rid of in addition to any other re-created Block instances :
Here is a gh def which shows how to add an InstanceDefinition inside a c# script. The main logic is to access the InstanceDefinitions in the current RhinoDoc. In a GH component, this can be done by using RhinoDocument.InstanceDefinitions.Add();
Trying to “deconstruct” one single Block Instance (see screenshot of Object Property panel) by referencing its Block Definition (only one instance of this block exists) :
I expected the Instance (object) name to be returned (“Roller_SH1_Instance”) but it seems that it returns the Block Definition name instead (“Roller_SH1_Def”).
I also expected the instance layer “ROLLERS” to be returned (“ASM::BEARINGS::ROLLERS”) but it returns “Default”, and when I deleted the “Default” layer, it returned “Layer 02” (which actually exists, although not shown in the picture below). Both layer names are obviously wrong. In this case the block Definition resides on “ASM::BEARINGS::ROLLERS::BDef”, so no layer info seems to be correct. At least it’s not returning the expected names.
Baking Layers doesn’t seem to behave as expected. If I specify layers as pictured (connecting the name-panels in due order) the result is a flat structure as shown in the screenshots below :
Fig 1: Layer Structure before baking, with “flat” structure as the result :
If I delete any of the layers below “ASM” and recreate (re-bake) them, then the expected structure is achieved, but not if starting from an empty layer structure. Strange.
Using Rhino 5 with latest GH & Elefront plugin.
Additional Q: Can I expect the layer components to accept a list of Layer names, or do they need to be individually specified as in the pictures above? Could for example the following layer names be baked in “one go” with one name list and only one Layer component? :
@RIL if these are perceived bugs with elefront components, you should direct those questions to @ramon though I’m not sure if he frequents discourse. You could check the gh group for elefront on grasshopper3d.com or the elefront download page on food4rhino.com for the developer’s preferred means of receiving bug reports.
[quote=“RIL, post:6, topic:42032”] Get Rhino Attributes (RHAtt)
Trying to “deconstruct” one single Block Instance (see screenshot of Object Property panel) …
I expected the Instance (object) name to be returned (“Roller_SH1_Instance”) but it seems that it returns the Block Definition name instead (“Roller_SH1_Def”).
I also expected the instance layer…[/quote]
After trying some other component combinations for referencing Objects/Block Instances I found some differences that explains why it seemed to return the wrong results. The correct use of components that gives the expected results is the following :
Fig 1. In both cases the one and only Block instance, and it’s name ("Roller _SH1 _1"), is correctly retrieved. First by filtering on the Block Definition (could have returned multiple instances), second by filtering on the Rhino Object Name. Also the Layer name is correctly returned. :
I’m glad you’re enjoying EleFront. Please note that you can right-click the deAtt component to select "return full layer path"
Kind regards,
Ramon van der Heijden
The two problems I experience with baking Blocks is that
§1. the Bake component doesn’t seem to care about the destination Layer for the Block Definition (the Definition always ends up in the Default layer, and only the Block Instance is placed in the specified layer path) and
§2. I would like to be able to Bake the Block Definition without a Block Instance.
For this reason I’ve played around a bit trying to make my own BakeLayer & BakeBlock components (see link here). So far my block creation is “unsafe” (it doesn’t care about IsDeleted or Locked states etc. but will be fixed) but they do demonstrate how I’d expect the Bake (block) to function. To my own Bake component I’ll add an option “MakeInstance” with default = False.
My own components is useful when not using Elefront in general, but when I do use Elefront (which I plan to use in most GH projects) I would prefer using Elefront components also for the block baking.
Yes, the Instance goes to the specified layer but not the Definition, which seems to always land on Default (or, at the first layer). See : [quote=“RIL, post:11, topic:42032”]
I experience with baking Blocks is that §1. the Bake component doesn’t seem to care about the destination Layer for the Block Definition (the Definition always ends up in the Default layer, and only the Block Instance is placed in the specified layer path) and
[/quote]
The second GH file (04-Layer Tests_01.gh) couldn’t be opened :
Edit: OK, it actually did open, if I just ignored the message. Yes, this seems to work. Then I must have had some problem specific to the Rhino file which I used. I will try investigate that some more. Sorry for the false lead.
