GH Player not working with blocks!

Hi !
i have some block files and i want to do some scripts in GH and run it in GH Player .
i downloaded Elefront Plugin to deconstract the block so i dont have to explode it.

it’s working nice in grasshopper , and completely fine (as you can see in top of the image) , but when i save the project and run it on GH Player , its not giving me the result ( see down in the image).

can you explain to me what’s the problem here ? (8.2 KB)

Hi -


Blocks are not supported natively in Grasshopper.

1 Like

Hi JP-Mike,

Can you tell us a little more about what you’re trying to achieve? The final outcome, workflow and geometry wise?



1 Like

TL;DR: Set it so the Get Geometry input feeds into a GUID Param, then Elefront’s Extended Geometry param. This will reference the block and pass it into the rest of the script.

As @wim explained, Blocks are not native in Grasshopper, but of course Elefront is able to handle them, so if we can find a way to get the block into the script, we have a shot. In this case, the problem is that Grasshopper doesn’t realize it’s referencing a block, because it’s not set up for that. For example, if we have it print out what it thinks it’s operating on, we would expect to see Referenced Blocks:

However when you run this through Grasshopper Player, you get the a different result:

This tells us 3 things:

  • Grasshopper IS reading in the two objects
  • It knows that they are referenced objects
  • It thinks they are Breps (so the Deconstruct Block Elefront component will fail)

This also checks out if you look at the options for the kinds of geometry that the Get Geometry input will accept:


Blocks are not listed, because they are not native to Grasshopper.

However, we know it’s properly getting the item in Rhino. So, it’s a bit of a hack, but since you are getting the object, you can get the GUID, then pass that into Elefront’s Extended Geometry parameter which will then convert the Guid into a Referenced Block before passing it into the rest of the script:

That said, I agree with @Japhy that it would be helpful to know what you are trying to do, because this is a bit round-about and there could be better ways to get what you’re after.

1 Like

Thanks for your replies ,
I receive block files , which contain a designs like table or beds legs (as blocks )

sometimes i need to connect or make a bridge (PIPE) between these objects which cross the block in a certain distance then stopped . but the main thing is the pipe need to go inside the block then to be cut
i thought if i can deconstruct the block -select the top face - scale inside - then make it solid - and solid difference from pipe.

this routine makes me bored every time

that’s why I’m thinking of make it a grasshopper script and just give it like a blocks input and entrance points and it will be calculated automatically

I just came across this and tried something similar - using GH Player to get Blocks.

It seems like Rhino (using 7.28) intentionally removed the ability to use the workaround. If you select more than one block using GetGeometry you now get a warning “Cannot use these objects. Removing them from selection.”

A real shame, because it means either having to explode blocks beforehand, which is pointless and and not a great user experience or I guess not using GH Player for this, but having to use Python for example.

I heard from the developer of a very famous render plugin, that McNeel IS working on native support for Blocks, Materials, etc. in Grasshopper - even in GH1! But apparently still some ways to go on that.

I’d say not supporting certain Rhino native data types in Grasshopper was a huge mistake from the beginning. They could have started very small and improved on it. By now if and when they come out with it, it needs to be at least as good as Elefront/Human/etc., which is quite the task.

Seems like for now the workaround does not work any more.

new GH1 types in Rhino 8 are getting rolled out, but like you mention, its quite a task to get those to Elefront/Human level, these two have been used in 10’s of thousands of production work hours. New GH1 types, maybe 10 hrs.

I understand and I promise we will be supportive. It’s one of those areas that has always been so finicky. Native Block support is huge!

For our use cases it would be good to:

  1. Define new block definitions
  2. Place a block definition from the document
  3. Place an external definition as a linked block
  4. Replace block instances with other block definitions
  5. Get all block definitions in a document
  6. Get all block instances in a document (especially things like their transforms)
  7. Play nice with GH Player
  8. Still be usable even with large numbers of instances (think at least 50.000 instances)

Ideally all this should be doable without any of the right-click menu options that a lot of plugins use. Ideally everything needs to triggerable by booleans.

Those components that do something that might be async or take a short moment (like define blocks, place blocks, replace blocks), need outputs that populate once the thing is done, so as to be able to trigger things down-stream and be sure that task has finished first.

I’m super excited for it and I am sure it will be great. I don’t see Elefront and Co. really going anywhere soon though and that’s fine too.

1 Like