Exactly! In architecture design, every repeated element goes into a block by definition. It’s not just for reducing file size, it’s for maintaining your model synchronized and to reduce user errors as much as possible. Imagine you have six different types of columns in your design with a total of 200 columns in your building, and you have to change those profiles, can you imagine going one by one 200 times? And those columns may have several screws (nested blocks), so you would have to update every single screw!!
or just edit those 6 block definitions and be ready to go! Imagine hoy many repeated elements you have in a building…
Blocks are a must have feature in any CAD, 3D and design software and not having a proper block system can be a deal breaker for many users. IMO, McNeel should put everything related to block on top of that famous priority list before adding any new feature to V7.
Back in the day, I fought long and hard to get a sorted list of blocks in the BlockManager.
Imagine that ! The whole shitload of blocks was just listed randomly !
(By the way, you can thank me for that one folks)
I’m no programmer, but how hard can it be to sort a !$#%*! list ?
McNeel please respect your users time more.
Some things in Rhino which are possible are implemented in such way that it is a pain to work.
If you, as a developers, are testing your stuff and some tasks are possible to accomplish but they are taking e.g. 25 minutes instead of 15 minutes long, than it may not look as a big thing. But for real users this may mean that insted of 3 days they will need 5 to do it.
Another thing is that real life tasks may be more vast and complicated so it multiplies even more in comparision to testing samples.
I agree with you that Fillet aren’t the best sometime, but when you’re working in product design with project made with more than 500 (different) pieces and you have to manage how to build it (the BOM) better block management would save huge amount of time, much more than fixing a couple of bad fillet.
I do work in product design, and you are correct, as we only use Rhino for small odd jobs in production, and then put those into assemblies in Solidworks/Catia, as those applications not only are made to handle thousands of parts but also have robust PLM/PDM systems.
(Not to derail this thread, but do you use any PDM for Rhino, and if so, how do you handle the embedded files issue?)
Well, we could make a little museum of horrors here with meshes, booleans, non-interactive 2D-projections and section, … But this thread is about Blocks. So how about sticking with that topic ?
adding my voice. even though rhino is not a bim software. some basic managment tools and quite simple as blocks should be implemented to work just fine and robustly enough. current block manager is like from 2005
Since it was me who suggested the Grasshopper as a solution. I feel I need to add something. You all talk about having block management. Advanced block management. Please open your minds “block” object may not be what you actually want/need. It is the Reference/Instance model. (Reference - understand definition, Abstract Class if you will). All of that could be relatively easy to implement if McNeel simply make the decision to move from file-based system to database-based system.
Is it worth it to continue developing and complicating an obsolete technology, compared to investing in a better organized scalable technology like a reference data model?
I’m trying to keep my expectations really low for blocks in Rhino, just to keep my ulcer under control. Here’s what I hope to see in my lifetime.
Sure enough, your data base thing looks slick, but hey, at the present pace of progress on blocks, the Himalayas will have eroded completely by then.
You can call it whatever you want, and I really don’t bother what kind of technology is under the hood, but what we need is something easy to use and reliable. I also think there is no need to reinvent the wheel here, it already exist in most CAD/ 3D packages
By definition, anything that is going to be repeated in a file should be a block, and making then has to be as easy as selecting the geometry and assigning a name. If among those selected objects there is already a defined block, then you create what we call a nested block but it should work the same. Once that block has been created, we have to be able to modify it at our will.
On one hand you have to be able to edit it “in place”, the faster way I’m aware of doing that, after many years of using blocks in many different apps, is by double clicking to enter in edit mode, do whatever you want and double click outside to exit. We should be able to double click inside a block of block too, in order to edit nested blocks and so on.
On the other hand we need to see and manage the structure of a block via a management tool, again, nothing new here, it just have to work properly like many systems already do.
What I don’t want is a procedure that adds another extra step to that process, and using grasshopper for creating blocks is not the solution at all.
The problem with blocks in Rhino is that it doesn’t work at all, it’s full of bugs and limitations, and McNeel should create a new block system from scratch instead of wasting time “patching” the already broken tool.
Thing is we don’t really get any answers or even hope from McNeel that this ever gets realized. If you look at the bugs and requests on youtrack regarding blocks, you’ll find many of them are long standing bugs and requests either being worked on by none, or scheduled to something called ‘future’
Not that I don’t love a nice heated argument, but let’s focus back on specifics about this whole “Blocks need to get better” thing.
And what could bring the testosterone level down better than Brenda’s Block wishes ?
In that thread by the way, you’ll see Dale Fugier’s attempt at pleasing everyone with his “BlockCommander”, just to be shot down in flames because he didn’t get the point and his thing was mostly crashing Rhino.
Yeah, you are right. Also it is quite difficult to understand, for me at least, that such an open company as McNeel has been so quiet about this and its plan regarding blocks. Some times I really think that they don’t get the real issue we are having working with blocks in Rhino. I don’t know haw many times I read here on the forums " I don’t use nested blocks because they are very problematic"… and I don’t understand how anyone can work without nested blocks, I really can’t!
