“Geometry” container acts as a bouncer for some breps in blocks.
Generally, it happens when there are large underlying surfaces in smaller brep faces.
The Breps are completely valid though (not “Bad”, volume can be calculated,…).
When referenced directly (not in a block), this doesn’t happen.
Geometry container acts as a bouncer.3dm (1.4 MB)
Geometry container acts as a bouncer.gh (10.5 KB)
August…
Hi @osuire,
Is the issue that block definition geometry reads as Referenced <xyz> in a panel, as opposed to something like Block Definition <xyz>?
– Dale
No, the issue is not with what’s displayed in the panel.
What is wrong is that, as soon as the geometry goes through a “Move” component, it vanishes : output is null.
This mostly happens with solids that have faces which are trimmed surfaces much smaller than their untrimmed version.
Hi @osuire,
Ah yes. Well, a standard Move component is not going to be able to transform block definition geometry.
For now, try:
1.) Get all the block definition geometry
2.) Make a copy of what you want to modify
3.) Modify what you want to modify
4.) Update the instance definition by calling InstanceDefinitionTable.ModifyGeometry.
– Dale
Dale, you don’t understand.
I reference the block geometry to do stuff with it in GH, not to modify the block.
What I do here works with the majority of my blocks.
I just gave you examples of blocks containing geometry for which it doesn’t work.
Best,
Yes it is : it considers the block definition geometry as referenced geometry ; the only twist is that the geometry is placed as if the insertion point of the block was on the origin.
I use it all the time. The only problem is with those specific solids which I mentionned.
Hi osuire
The problem is in geometry itself.
Try exploding and joining breps in your blocks (in rhino).
I don’t know why Rhino considers it as valid because if you extract the geometry from blocks in c# it would say ‘invalid geometry’.
This is precisely what I’d like to know.
Maybe I should have phrased my question like that to get an answer from McNeel.
Either Rhino is being lenient, or GH too strict, but it is clearly inconsistent.
The breps are valid. The issue appears to be with the blocks. Here’s why:
If in Rhino you recreate the original objects by using Insert Block Instance with the Individual Objects option you get valid objects. If you then create new blocks with them, your Grasshopper move is happy with the new blocks.
If I had to guess, I’d say that some prior manipulation of your blocks or their contents has caused the issue.
HTH
Jeremy
I’m not sure what you mean exactly here…
The objects that end up causing trouble have commonalities : they have underlying faces that extend far away the solids.
“Manipulation” of blocks is not involved here.
Hi @osuire,
When I open your Geometry container acts as a bouncer.3dm file in my developer build of Rhino, I’m seeing several of these messages.
Stored Bounding Box extends far outside of computed bounding box.
This is causing GH to tread your Breps as bad objects.
I’m looking deeper into this.
Sorry for the delay.
– Dale
Thanks Dale, I think this is exactly the problem.
Well this was just the side salad, not the entree. A guess, not a conclusion. The meat here is that the polysurface within your block is ok but the polysurface “within” your block instance is not.
If I create a new instance of your block it contains a valid polysurface. So something has caused your block instance to behave differently from mine. All I did was to create a block instance and explode it. To understand how your problem arises it would help to know what was done with yours that differs.
And if I create a new block from your standalone (and valid) polysurface and explode the block instance I just created I get a valid polysurface. So we can eliminate the proposition that the problem relates to the initial instance and not to later ones (assuming your polysurface is identical to the one within your block).
Hi @dale, Sidetrack I know (sorry @osuire!), but I thought that the bounding box was just calculated on demand, quickly or accurately as required. How do you access the Stored Bounding Box?
Hi -
My understanding is that all that is required for this to happen is that the object was created in Rhino 6 or an early version of Rhino 7. As Olivier wrote in post # 4 of this thread, this happens with objects “that have faces which are trimmed much smaller than their untrimmed version”. Back in the days, the stored bounding box was calculated from that untrimmed version. This could cause issues in other places and that was fixed in Rhino 7 where the trimmed versions are used to calculate the bounding box.
The problem is that, when Rhino opens a file, it compares the stored bounding box with a bounding box that is calculated on the fly, and, if these two are very different, the object is flagged as a bad object. In plain Rhino, simply moving that object and then back to the original position and then saving the file, will fix this. Apparently, doing something with such objects in blocks in Grasshopper (which doesn’t have any native components to deal with blocks) deletes those objects/blocks.
The issue is on the list as RH-64277 but is not visible to the public.
-wim
