Error message gives no clue for cause

unhandled

#22

Andrew,

It seems that the Dot bake has a little issue : Dots which don’t have a “Point” input are nevertheless baked at the Origin (0,0).
The expected behavior is that when there is no “Point” input, no dot is created :

Regarding the attributes, I’m not finding the same functionnality as with Elefront : the properties I need to retrieve are those of the objects inside the blocks, and not the attributes of the block instances :

I was also wondering if I could use the “Name” filter instead of the filtering mecanism that you propose :


(Andrew Heumann) #23

The expected behavior is that when there is no “Point” input, no dot is created

oh come on, you can handle that yourself with a dispatch or something. Point3ds are not nullable in rhinocommon so null points become 0,0,0.

I was also wondering if I could use the “Name” filter instead of the filtering mecanism that you propose

No - object names and block definition names are not the same.

the properties I need to retrieve are those of the objects inside the blocks, and not the attributes of the block instances

try this… there are two approaches, one that duplicates work by getting the keys/values multiple times (once for each instance of the block) and another that is more components but likely more efficient (only getting attributes/geometry for one instance per block name)

Text Dot Block Stuff -2.gh (14.3 KB)


#24

Dispatch is a pain because it only works with a single toggle.
This is not so easy : when there is no data at all for the “Point” input, any component you put after that will just turn orange complaining that there’s no data.
How do you turn that into a “true” or “false” ? I know there’s a funky workaround, but I can never remember what it is…
In any case, if you consider adding a dot bake, it would be convenient to manage this inside the component.

Ah, of course… May I suggest a bit of disambiguation here ?
Maybe labeling the inputs or outputs “Block name” in one case , and “Rhino name” in the other.

Thanks for the Block stuff, I’ll test it, but I need to catch a plane at present.


(Andrew Heumann) #25

use the “null item” component with “dispatch multiple” from human for an easy solution…image - can even fold everything into a cluster for re-use if you want


#26

Thank you Andrew


#27

Hi Andrew,

I do not assign user texts to the blocks, but rather the objects within the blocks.
This is why your definition outputs no result with the attached example.

The problem is that the “Geometry” output does not reference the actual objects, and therefor I can’t retrieve their attributes.

Is there a way to achieve this with Human ?

User text of geometry inside blocks.3dm (39.7 KB)


#28

Hi Andrew,

Any thoughts on this issue ?


(Andrew Heumann) #29

It works for me with the file you uploaded


#30

OK, I’m completely lost :
When I do the exact same thing, I get no data :

Time to update my "Human.gha" ? Edit : just downloaded the latest version for V6 : same problem ; I think that’s the version I had.

Then, I feel that this is not going to work anyways, because I need to reference blocks which are nested inside others.
If I filter blocks through the “Block Name Filter” of the Human "ExplodeBlock component, I can only reference blocks which have an instance in the model, but if they are nested inside others, they are not found.

The elefront component "Reference Block By Name" will reference the block definition even if there are no actual occurences in the model. EDIT : in fact, no : the Elefront component can only see referenced blocks, but there is an option to find blocks which are nested within others. Therefor, it can reference a block by name, even if it is not at the top level :

You can test this out with these files :
Test files.rar (34.0 KB)

But Elefront keeps making Rhino crash, so I seem to be like this…Preformatted text


(Andrew Heumann) #31

try this C# script
Block Defs By Name.gh (7.8 KB)


#32

Thanks Andrew,

This component works, and it is very efficient because it doesn’t require to first reference all the blocks in the model and then filter them by name !

Yet, there is definitely something fishy with the “attribute” output of the “ExplodeBlock” component, as you can see here (and with the files I added in my previous message) :


(Andrew Heumann) #33

that’s odd. when I open the TEST FILES.rar you sent and change the block name filter to Block 01, I get user data back. Maybe you have an odd version of Human? this is the one I have (for rh6 only!) Human.gha (416 KB)

in any case glad the script suits your needs. I’ll probably add to human eventually…


#34

I’ll probably add to human eventually…

In complement, you might want to add also a component that gives a list of all the block names defined in a file.


(Andrew Heumann) #35

good idea. that’s an easy script to write as well to keep on hand in the meantime:


#36

Hi Andrew,

In fact this still produces unwanted dots at the origin.
I didn’t see them at first because indeed, they have no text, so they are tiny, but they are here and it’s quite troublesome.

Any idea how to stop those critters from popping up into existence ?


(Andrew Heumann) #37

hadn’t considered the case of a list with no valid points. try this: