Blocks management in Grasshopper

[osuire]

@ShynnSup

It has never crashed for me either, even when using blocks.

@ShynnSup

If you right click the component, you can see a “Disable auto update reference objects” option checked by default. Try unchecking it and see if it works like you need it to.

This is quite amusing because Alan added the “Disable auto update referenced objects” option to the “Reference Block by Name” component following a crash report I made.
I sent him my file and definition, and he acknowledged there was an issue.

It fixed that crash alright, but I still have crashes with that test file I’m working on.
It’s a typical model for our company, an it’s got over 300 blocks, 200 of which are sub-blocks.
Sadly, sending out my model is out of the question and would get me fired instantly.

Seriously, properties management is such a strategic topic for CAD nowadays with BIM and all the murky competition it generates (yes, I’m looking at you AutoDesk), that I find it suicidal on the part of McNeel not to beef-up Rhino and Grasshopper to be a viable alternative.

Sure there are plugins, but such an important functionnality of the software should have a native, rock-solid feature set.
I, for one, would hate it if I had to switch to another tool when BIM becomes preponderant and more strictly enforced in the construction industry.
Instead of rising up to competition, McNeel is opting to make Rhino a submissive plugin of others.

Some will declare their love to Rhino by flattery and complacency ; my cry is :
“You guys rock, I know you can beat the crap out of Autodesk ; just try a bit harder !!!”

[osuire]

@ShynnSup

The error message gives some clear hints: It does not work in your case because the geometry you are inputting is not referenced from the active Rhino Document.

Quite the contrary : these are blocks from my active document (and not even a worksession ; just a plain old model full’O’blocks).

I think you don’t get it… I want to attach attributes to block instances, not the objects inside these blocks, which is what your definition does.
By the way, I see you really enjoy those “Data description” components.
Since I prefer icons, I can’t make use of them.
On the other hand, Telepathy does the same, works in icon mode, and goes even further because it allows to “call” a container from anywhere on the canvas.

By the way, this is also a good example of something that I’d like to see as a native feature in Grasshopper.

That’s not being dis-respectful to the developper of the plugin ; rather, I’m saying : “Good job ! You managed to do even better than David on that one ! Now let’s add that to the standard feature set of Grasshopper”

[dtmurcielago]

It’s safe to say that there is ample room for improvement in Rhino’s block management, both w/in RH proper and GH as well. My impression from casually tracking this issue over the years is that there would need to be a lot of reworking under-the-hood to make these changes possible.
I have also attempted (though not tried very hard) several of the lovely plugins mentioned above, but either ran into a bug or a workflow issue that derailed my attempts (e.g. Elefront) or didn’t have a severe enough use-case to warrant a delving (e.g. VisualARQ) in preliminary investigatory work, rather than required work.

Instancing, Proxies, and improved block/assembly management are all key features to be able to use Rhino as a more encompassing (architectural) native modeling environment, rather than a “singular-object” output approach. I think that RhinoInside is a smart move from McNeel that jives with current inter-operable application environment trends, offers a potential for new revenue streams, and opens the door to more use cases. At the same time, that doesn’t solve the native RH environment’s shortcomings with regard to instancing, proxies, and block/assembly management.

I find the multitude of freely available RH/GH plugins absolutely amazing and generally highly functional; they fill a lot of holes in various workflow approaches while generating new ones simultaneously (e.g. if I create an object/brep/mesh in GH and want to iterate it 100 times, I’d love to be able to parametrically bake those objects as blocks, potentially with attributes, etc., rather than either having to bake one first, reference it, then array it (in either GH or RH); or, conversely, wind-up with 100 unique objects directly from GH). It’s possible I’ve missed out on a preferred workflow for this dilemma, but I’m under the impression that it hasn’t quite been worked out yet.

[Dani_Abalde]

@lopez

I don’t think is necessary explain more about the blocks in Rhino (if they was not useful, they was not existing in Rhino too, of course…). I don’t understand why, if someone asking some feature in Rhino /Grasshopper, it start a very stupid discussion about “Why do you need”

Where do you think you are? This is a software forum, not a suggestion box or customer service. You have to be miserable to consider it stupid for someone to ask to learn in a place like this, or to disregard someone’s help when it’s not what you expect.

Talking about something even if it’s tangential to the intent of the post doesn’t exclude being helped, in fact, someone from McNeel is more likely to find it if it’s up on the home page. And also, it makes developers with no experience in other industries understand your needs better.

And even on top of that, says this one who never helps and only uses this forum to be helped. Only a selfish person could have this attitude

[Joseph_Oster]

@Dani_Abalde

Where do you think you are?

Sounds to me like you very much misunderstood what he was saying.

[ShynnSup]

@osuire

following a crash report I made.

That’s good! Maybe you can report once again to keep it improving, or contact him with this question to see what he advises you.

On the other hand, I am beginning to think that you don’t really want any help. You desperately need some flaw or limitation in order to prove your point. If you actually wanted some help you would have tried harder to get it, providing definitions and not screenshots, let alone incomplete screenshots to deliberately misguide the people trying to help you.

@osuire

Then, there’s these silly “update” buttons like on the “Reference blocks by name” which forces to use Metahopper’s “Expire object” if you want to trigger it through Human UI.

As it has been cleared, by unchecking the “disable auto update reference objects” you don’t need to do this.

+1 to Elefront.

@osuire

I think you don’t get it… I want to attach attributes to block instances, not the objects inside these blocks, which is what your definition does.

I will never get it if you don’t want me to get it. Attaching attributes to a block instance is fairly easy, you simply define a block and bake it with attributes, as with any geometry.

Errr… did you actually check the definition I posted? Those are Blocks, with Attributes.

+1 to Elefront.

@osuire

One thing that I couldn’t figure is the “Modify Elefront Attributes” ; I was never able to make it change the attributes of a referenced block instance…
Since you seem so learned about Elefront, maybe you can help me out…

I just tried it and it works OK. As you can see, it took about 1.5s to bake my blocks. So, instead of rebacking them just to change attributes I can use Modify RhinoObject Attributes.

+1 to Elefront

Btw, I am done helping you, maybe you can post a new thread explaining your specific problem and attach your example files. Start here:

Help Us Help You

Asking questions and getting answers is what this forum is all about. Although people are generally very helpful, there are things you can do to improve your chances of getting good and quick answers. Below you will find some suggestions, but don’t think of them as rules and especially don’t think of them as guarantees. 1. Choose a descriptive title for your post Don’t title your question Help! or I have a problem or Deadline tonight!, but actually describe the problem you are having. 2. Be s…

[gustojunk (Gustavo Fontana)]

[lopez]

Thank you, Joseph.
Roy

[osuire]

Hi ShynnSup

Still in a patronizing mood ?
I might have pin-pointed the flaw with Elefront that prevents me from actually doing useful property management on blocks.

Elefront allows to reference “Top level” block instances , as well as sub-blocks present in the model.
The problem is that it can’t chage the properties of sub-blocks.
The attached definition shows it quite eloquently.

If that’s really the case, then it’s a no-go for me…And also I keep crashing.
I’d be curious to see the block structure of your models, and their block count…

Change attributes on sub-block.3dm (32.5 KB) Change attributes on sub-block.gh (7.6 KB)

[Rickson]

Are you expecting to modify instances of nested blocks? You can have usertext on the nested objects and blocks, but they won’t be modified on the instance level of the top-level blocks. It gets a bit paradoxical, for instance you can’t edit a block in rhino, change the subblocks usertext and only expect that one instance of the block to be changed.

If you have Assembly 1, Assembly 2 Blocks then the common sub block A & B can differ.

what is your opinion of using linked blocks? i went a little overboard and did a project with 3-4 levels of nested ‘assemblies’ it worked, just a lot of ‘Update Linked blocks’ when opening files.

[jayandrewscadd]

Recently on here I saw a post requesting the ability for gh xref’ing other gh files. A reply showed that it already a current feature. Could this not be used in a workflow to act as external reference blocks? I’ve already considered it for that, just still mostly using Solidworks while I’m still in the learning stages of GH.

[osuire]

You are probably alluding to the “Data output” and “Data input” components.
It is still quite buggy. In practice, we couldn’t use it.

[osuire]

@Rickson

Are you expecting to modify instances of nested blocks?

Yes. We typically have two levels of blocks, and if we want to get a BIM-like workflow running, it is absolutely necessary to have the possibility of modifying the attributes of sub-blocks.

I fully understand the implication that any property of a sub-block will be propagated to all it’s instances in the Instances of the top level block.
In fact, we plan to enforce the rule that all instances of a sub-block definition will have the same attributes, in an attempt to keep our sanity.

I therefore conclude that Elefront is a dead end to achieve our purpose.

[Rickson]

Thanks for sharing.

[ShynnSup]

@osuire

Still in a patronizing mood ?

Try “Thanks”.

@osuire

I therefore conclude that Elefront is a dead end to achieve our purpose.

No need to jump to premature conclusions. I don’t see you trying any workarounds. For example with linked blocks as @Rickson suggested. Maybe consider being a little more flexible when things don’t suit your workflow.

I can think of at least one workaround for your need to modify attributes of sub-blocks: Modify the attributes of the sub-blocks outside the top level block, and then redefine the top level one.

Also, and here comes the part @Dani_Abalde said was important. Why do you need to modify sub-blocks’ attributes? “We absolutely need to” is not really a reason is it? If we can’t tackle the problem one way maybe we can eliminate the problem altogether.

Have you contacted Ramon or Alan with this requirement? Maybe they can think of other workarounds.

Out of curiosity, how are you handling while you can’t change sub-blocks attributes parametrically?

There we go, maybe you find this useful? I feel I have been trying more stuff than you and I don’t even need this.

Change attributes on sub-block_re.gh (11.9 KB)

[jayandrewscadd]

I knew it, I just finally got around to watching this Morpheus video I’ve been meaning to, and my suspicions have been confirmed. Obviously this video was produced by the same people who faked the moon landing, as there is definitely no way they actually had usable workflows!

[nperillo.np (nperillo)]

YES, YES YES! Grasshopper needs better block management! Anyone trying to ‘solve’ @osuire’s problems is totally missing the point. This is the sort detail that could crush the competition and make the software as a whole better for everyone.

There is so much locked up potential in this software because of a lack of ambition and this weird forum culture that defends Rhino’s shortcomings. I do not understand why so many flock to defend the lack of a feature rather than having a constructive discussion about why such things would be useful. Push to be better! don’t squash potential.

Anyone who’s used blocks extensively knows that they are gods gift to CAD for anything more complex than a few unique parts.
The simple fact that these amazing plugins exist and are being used by world class firms should be proof enough that it is a highly useful set of features that should be native.

I’ve personally never needed to do anything as complex as @osuire but countless times I have encountered roadblocks where simple features are missing naively that just don’t make any sense. Why have have blocks in Rhino but not Grasshopper?

I design large scale architectural light artworks and there is currently no software suite that caters to the nuances of our workflow better than Rhino pared with grasshopper for going from high level concept renders, to usable construction and mapping data. That is NOT a complement. It a gap in the market that could be filed by fixing ‘insignificant’ issues like this.

P.S Fix Layouts while your at it and kill make 2D. Absolute nonsense!

[osuire]

Man, you picked the wrong guy to make fun of by comparing him to the moon landing hoax morons.
I am a huge fan of the Apollo program.

[osuire]

Hey, ShynnSup,

We started on a bad foot together, and I think that’s because you feel I am criticizing one of your pet tools.
In fact, I admire the efforts of those plugins trying to compensate for GH’s shortcomings.
Pufferfish and Wombat come to mind as the perfect example of plugins that expand the feature set nicely, providing one handy component where multiple native components would otherwise be needed.
Other plugins like KUKA|prc which I use a lot are great extensions for specific needs.
But when it comes to manage the whole structure of a model, and the properties of objects, it seems obvious to me that it should be done natively.
This is serious business, and paying users should have the leverage to be somewhat demanding regarding such important tools.

We did very practical tools, mixing some Human here, some Elefront there, trying to manage the bugs and limitations, but we don’t want to hear stuff like “You should’nt complain too much because the folks were kind enough to provide it for free”.

@ShynnSup

For example with linked blocks

Linked blocks are out of the question for us, as this is adding yet another level of convolution.
As we have multiple offices, linking to network paths would be a complete nightmare.

@ShynnSup

I can think of at least one workaround for your need to modify attributes of sub-blocks: Modify the attributes of the sub-blocks outside the top level block, and then redefine the top level one.

I thought of that one too. This is like sqwashing a fly with an imperial destroyer…

@ShynnSup

Why do you need to modify sub-blocks’ attributes?

Errr… are you trying to tell me what I need to do in the field that I work in ?
Well, OK, let me explain.
Our low-level blocks are typically your humble steel gusset or length of pipe of some kind. They correspond to the basic unit that is cut from raw stock in the workshop.
These folks have a name, a material,a volume, a weight, a price, etc…
Our top-level blocks are welded parts that are made from the low-level blocks.

You understand that some properties are “given”, like the name, but others are “measured” like the volume, and yet others are “calculated”, like the weight, or the price.
In a dynamic modeling context where solids are modified all the time due to design changes, or mistakes, how can you make sure that all your attributes are consistent if you can’t modify sub-block attributes ?

[osuire]

@nperillo.np

I design large scale architectural light artworks and there is currently no software suite that caters to the nuances of our workflow better than Rhino pared with grasshopper

Thanks Nperillo,

I’d like to hear the voices from more firms like yours and mine.
Businesses who find that Rhino is the best choice as a “central” tool in their workflow, but as their projects grow larger and more complex (and with the advent of BIM), they find that they might need to dump Rhino because it can’t manage the data and make 2D drawings interactively. **

This is disheartening because I can see the crash coming, and McNeel is precipitating it by pushing Rhino forward as an accessory, a widget for the so called “big players”.

They are either going to be swallowed whole, or remain a standalone tool, but just for hobbyists and craftsmen, who are already courted by Fusion 360…

** The ability to import and export IFC wouldn’t hurt, and don’t get me started with the VisualArq plugin !