Referenced block instance trouble into grasshopper rhino 8

Grasshopper
1

Hi,

I recently upgraded from Rhino 7 to Rhino 8, but it seems that Rhino 8 handles blocks differently.
I have a large Grasshopper script that relies on block exploding using the Human plugin.
Apparently, there is no Rhino 8 version of Human. After downloading Elefront for Rhino 8, I still couldn’t figure out how to make it work.
It seems that block handling is no longer functioning as I expected.

Sans titre
Sans titre1912×634 124 KB

Is there any way to solve this issue?

2

Do yourself a favor and get rid of EleFront and Human. Grasshopper has native tools to do most of what was possible with EleFront and more new things.

3

Thanks for your answer.
But I would say that it would have been a bit more helpfull if you have gave me some elements to replace them, such as “try this tool in grasshopper to replace the block pipeline selector” or "try python code to do this or that.

4

Martin, I would not say that you can replace EleFront with new R8 components straight away. Maybe you can replace Human… But how about some EleFront-specific features? Eg.:

  • Reference nested blocks
  • Easily accessible block info (plane, name, transform)
  • Attach attributes to a geometry and pass them together
  • Elefront attributes (all-in-one set)
  • Generally streamlined block-handling experience

These features I really miss in R8. If you were aware of a native R8 solution to these problems, I would love to hear, because we also want to get rid of excessive plugins. Unfortunately, there has not been sufficient replacement for EleFront so far.

I also dislike the fact that Keys/Values are detached from object attributes in R8 components. EleFront has them all in one attribute set. I dislike that some properties or operations done easily with elefront are annoyingly complicated in Rhino 8. Eg. reference blocks with certain name (see below). And if you - god forbid - want to reference nested blocks, you are screwed. And 100 other things.

image
image1539×669 74.4 KB

I am then asking - am I missing something, or is UX of new long awaited R8 components that bad? If I were you, I would not recommend replacement at this point. At least there is chance that these components get improved in the future, unlike Human that is “dead” and EleFront where I do not have any info if it is still being developed actively.

5

I haven’t used Elefront much so I don’t know exactly what you need, but it is trivially easy to make any kind of block tools you need with R8

image
image1471×616 98.4 KB

Cluster 1 -

image
image1663×315 68.5 KB

This takes block instances, looks only for unique block definitions

Cluster 2 -

image
image1835×535 90.2 KB

For each block definition, it isolates only other block instances and then converts it into block definitions

You can make your own clusters based on what functionality you need and you can probably replace your elefront tools. These wont require update buttons too!

block tools.3dm (97.9 KB)
block tools.gh (19.7 KB)

6

I did not mean to express that I can not build me a cluster :slight_smile:
What I try to say is, that proclaiming “just replace with native components” without further details is misleading because just for the sake of using native components you probably make your scripting experience worse. Surely you are not doing yourself any favor.
The example you gave for getting nested blocks only works for one level of nesting. Again, did not want to say that you can not get nested block at all. But you can not do it effectively and recursively. You had to stitch together two damn clusters while 3rd party EleFront can do the thing recursively in one component.
I am slightly disappointed here because I had only the best expectations from these new components, waiting patiently that this time it will be “the real thing”. They could have just copied what EleFront does and improved it a bit, because it is not perfect either. Initial impression is just meh. Will continue testing, maybe I change my mind over time, but for now I see that as a missed opportunity.

Back to the OP question:

  • There is R8 version of Human. Explode component has been pretty buggy since I know it IRRC, so it might be just a bug, that unfortunately won’t get fixed.
  • Try EleFront if you want to do a lot of fiddling with blocks. Be aware that is has its problems too. Furthermore EleFront can not be combined with Human or native block components, because it utilizes its own Block class. So you have to go “full EleFront”
  • If you only want to read block name and attributes (and nothing more), you might as well use the new Rhino components or try simple Python code of your own. That depends on what you need to do with the blocks.
7

I had it as a single cluster originally but I tried to replicate elefront cluster you showed.

Yeah, if you don’t know how many nests you want to look at this won’t work. Some custom scripting component probably might be needed, or perhaps we can query the entire block definitions table to see which one nests where and return accordingly. What happens when you have block which can have ‘n’ nesting? Do you just get a flattened list of all nested blocks or does it output a data tree to which give information about the nesting?

8

Two things…

  1. the op didn’t share a file.
  2. For my purposes I was able to replace EleFront with the Grasshopper Rhino components. The only thing which I’m missing is exporting geometry with native grasshopper components but I have a few good scripts…