When trying to use the Human component ‘BlockExplode’ to do just that on a very simple block, I get the error message “Solution exception:Object reference not set to an instance of an object.”.
The block contains just a brep box for testing, nothing else.
What am I doing wrong?
Thanks a lot!
This component expects a reference to a Rhino Block Instance, not a normal piece of geometry. You can get references to blocks with the Dynamic Pipeline, for example. There are no native Blocks in grasshopper so you have to refer to one in the rhino document.
Thank you, Andrew!
- What is the difference between a Rhino Block Instance, and a ‘normal piece of geometry’, in my case a… block?
- What is the ‘Dyamic Pipeline’?
- How do I refer to a block in the Rhino document?
Do I need to dig into coding here in order to get this to work?
When you select the object in the Rhino viewport, does the command line read the following?
1 block instance added to selection.
If not, your object isn’t a block and you should probably read this page of the help file.
That is a standard Grasshopper parameter on the
Parameters > Geometry tab:
If I understood that right, Andrew says you can do that with that pipeline parameter, but I’m not so sure.
Yes, it’s definitely a block. Run the ‘Block’ command on a simple brep box.
I get it what Andrew meant: simply that a block must exist in the Rhino scene and loaded into GH with a geometry parameter.
Two geom params deal with blocks: BlockInst and BlockDef. Tried both without luck.
What to do with the Pipeline component, I could not figure.
BlockInst and BlockDef must be from another plug-in — those aren’t compatible with Human. And when I say Dynamic Pipeline I don’t mean the native Geometry Pipeline that ships with Grasshopper, I mean the Dynamic Geometry Pipeline that comes with Human — it can support a lot more geometry types.
Try Elefront or InstanceManager.
I find that this component just does not work with nested blocks : with the attached files, only two random instances make it to the component’s output :
P20_MOD_Modele test 01.3dm (334.4 KB)
Explode Blocks not working.gh (6.6 KB)
If you input only the blocks without sub-blocks, it will work fine.
Did this ever get resolved? Just coming back to this and wondering why Human’s Explode Block fails on some blocks and not on others, even though the basic hierarchy of all the blocks is the same?
explode_block_fail.gh (4.7 KB)
explode_blocks.3dm (914.0 KB)
All the blocks are simple shapes and simply contain an upper and a lower part (they are both blocks themselves).
@gankeyu I find Elefronts block tools harder to use, especially setting certain blocks (I want to just be able to select some blocks in the viewport). InstanceManager is always a bit fishy, because it gets random updates that break previous things. Actually, its not called LegoBlocks.
Extended Geometry component will allow you to select particular blocks, if i’m understanding you correctly.
I think you mean something different. I want to be able to select some block instances in Rhino, click a button in Grasshopper and it knows which blocks I have selected to explode them.
In Human you have a component called Objects by Selection. In Elefront however you can only list all the blocks in your document and then have to filter them somehow.
You can use something like the Stream/Freeze Gate from Heteroptera and then you can use a button:
set_blocks_from_selection.gh (5.4 KB)
I finally tried a few things with Elefront and the main difference between retrieving a block by name in Elefront and Human is: If you set a block in Human it will basically retrieve the instance definition, whereas in Elefront if you find a block by name it will retrieve ALL instances.
That bug seems related to that some in-block RhinoObject doesn’t have an attribute.
Hm, now I am wondering if this missing parameter is related to the “Wrong parameter” error message we keep getting when saving to a file server. "Parameter is Incorrect" - Rhino 6 but maybe it’s a different kind of parameter. Whoever wrote that error message could have been a little more precise
Maybe @andheum could take a look at what seems to be the problem with the explode component. It appears some index is too large or negative!?