Block Management Tools Need Improvements

Watch out you guys, soon someone from McNeel will shoot you out with the “…get a refund…” bullshit.

1 Like

Not only that, but they are also promoting Rhino V7 as having improved display speed of blocks !!!
@stevebaer : I suggest you get the Blocks walking straight before you try to make them run.


hahaha, well @stevebaer you have to admit that this is funny, and one reason more to give blocks some love.

@7556 if blocks don’t render in V-Ray, certainly something is off, better start a new thread for this

@Gijs okay good to know that that’s not normal. will open a new thread tomorrow, thanks

Yes, I know that block and block management tools could use improvements. I appreciate the input from you and most of the community. I wish we had something to provide you in this week’s WIP, but we don’t.

Well, I’ve been waiting 20 years for this, I can wait until next week :wink:


“…block and block management tools could use improvements. …” != The block management will be improved.

1 Like

Since this thread seems to have become a repository for all Block Manager complaints, let me link a few more on this topic:

I like that Rhino can be scripted, but at some point, there must come a breaking point where things should go “native”.

I’m guessing, since the only time a Rhino file is part of a bigger project is in architecture, and since there are architecture add-ons which cost more than Rhino itself, these add-ons probably circumvent/fix the block manager so users don’t get frustrated by it, and the only people still pulling their hair out are industrial designers, which Rhino isn’t really suited for anyway? (And my last claim is due to filleting and pdm incompability, before anyone asks.) :slight_smile:


I would like also to point out that RhinoCommon for blocks is also lame or at least cumbersome and implemented partially - eg. for URL of blocks only getter is provided… And for few yrs you guys are telling to use scripts inside the code (import/export) instead of providing a complete toolset for this.

Besides …

Oh, really? Do you mean when I put in 100 projects the same tree which weight is 100mb I’m a fool that I want to save 10 GB of disk space? If we would go to small production cases when I would use up to 20/30+ trees bushes etc I don’t even want to sum how much space I’m wasting cause of wishy-washy handling of blocks…


May all our V5 bug fixes and wishes make it into V8!

Here’s one more for the pile: Exclude ref geometry from a block definition.

I’m working on a complex part. I need to bring in a neighboring reference geometry to check fit and alignment, but I don’t want that ref geometry to be included in the parent model (the actual neighbor is there).

Either that or be able to edit the linked block in place in the parent model.

It’s already been mentioned, but needing a clipping plane in a block is a real feels bad. There’s no way to disable (or exclude). Your consuming model is stuck with an enabled clipping plane no matter what.

1 Like

Hi @EricM ,

Can you explain more about this? Yes, currently you can include a linked block nested in a block definition. You can change the block insert layer to a locked layer, so it can be excluded.

I logged the linked block “Linked blockedit in place” RH-62146

And finally you would like to “disable clipping” to be an object property? So a block or any object could be tagged to not use the clipping plane? Currently the clipping plane is set to the view.

Thanks for your help.
Mary Ann Fugier

I think this may be what I’m wanting, but can you explain how to do it?

And yes, if you have a clipping plane in a block, each instance will include that clipping plane. Then you have to disable every instance for the view.

A clipping plane in a block definition is only useful when editing the block. It doesn’t make sense for each instance to repeat the clipping plane. It should be disabled, hidden, and locked on the instance.