What I meant by divide and conqueror, is the ability to also swap between to external files, so that more than one person can work at once.
I got the idea, but blocks, I don’t see block being efficient in that.
Hey guys, only 54 posts about blocks here ?
This thread has 68 and counting…
Go team ! Go !
Who knows ? We might even catch McNeel’s attention at some point…
That is the intent of Worksession.
you still have hopes, do you? I don’t believe the silence from McNeel’s side is a good thing. Probably @ivelin.peychev is right, that the code behind blocks is difficult to update/ easy to break things.
At least they could tell us just that, to don’t expect any changes regarding blocks because it’ll require too much work. I don’t see how not chiming in and commenting is good for any one including McNeel.
I’m also one of the Rhino users that try to avoid blocks at all costs simply because every time I use them there are some problems: crashes when accidentaly ctrl+shift clicking on a member of a large block or the inability to delete layers once a block was placed on it just to name two things that come to my mind…
now recently I was forced to work with nested blocks since I’m working on two scales of a project at the same time so I have files with the individual buildings and one masterfile where I combine the buildings and the topography. so far no issues (since it’s only about 10 blocks) but is there a way to still render the blocks?
my buildings are mostly made out of blocks itsself and none of these nested blocks are showing up in vray… exploding the blocks in order to render them defies the purpose of having a small masterfile to work with in the first place.
probably this has been discussed before but not being able to render nested blocks seems like an issue worth adding to the list here.
In my experience, blocks will create tons of issues related to graphics, i.e. clipping planes don’t work properly, tons of problem assigning materials for rendering purposes, but not being able to see them at render time is too much, that shouldn’t be happening. Maybe this is Vray related.
Related to blocks in general, I would like to add that, the whole discussion about if blocks are a must feature or not, it’s irrelevant, why? because McNeel took the decision to implement blocks long time ago, so I think it’s McNeel’s responsibility to maintain blocks at least to the minimum, that is working with current tools in Rhino. How can it be that clipping planes don’t work properly alongside blocks?
Watch out you guys, soon someone from McNeel will shoot you out with the “…get a refund…” bullshit.
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
“…block and block management tools could use improvements. …” != The block management will be improved.
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.)
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.
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.
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.