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 ?
I completely agree with this. Recently I asked how get around the block system and the answer was grasshopper.
Grasshopper is incredible but it’s no replacement for block management, especially with nested blocks.
Please bring this basic and industry standard functionality to Rhino.
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’
I think the block as it is is good for the initial purpose. A completely new type needs to be invented to target your work flow.
Could you elaborate about what has to be invented to improve the workflow? I really don’t follow you here, thanks.
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!
For that I need to know your workflow.
In general currently in Rhino a block can contain most RhinoDoc objects including the block type.
I believe a better organization of the blocks will be if there is a new type (let’s call it block-container) A block container can contain only blocks and block containers. No other objects. A block should be unable to contain other blocks instead a block-container should be used. Also a Block Reference Object should also be invented and accessible (this was also requested here). This kind of object-model could remove the complexity from the block object regarding nesting and organization and only let it deal with the objects it can contain.
Block-Container type should have its own coordinate system. Blocks should have attributes for which Block-Container holds it, what are the global coordinates and the coordinates relative to the coordinate system of the block-container.
This could evolve further depending on your actual workflow, this is basically how I see it.
Thanks @ivelin.peychev, I need more time to digest your post, but I will think about it and I will come back to it. Thanks again.
Forgot to mention one thing - each time a block is instantiated it will create a block-container it will go in to. If no container is specified upon instantiation.
Btw, this kind of data-model might help translating SolidWorks/Inventor models better.
Ivelin,
you remind me of that math teacher I had in college.
The more I listened to him, the less I understood math.
That explanation is not for an User to understand but the developer.
You really step on my nuts with your contemptuous remarks.
Currently they are overloading the Block data type with too much properties and since it is an old technology the code behind it becomes more complex. And complex code is not easy to modify without breaking it. If there was another type to deal with the blocks’ positional and hierarchical attributes it will become easier to maintain and to provide the advanced management you need
Let’s say that I have a lot of blocks, they sort alphabetically (wow), so name prefixes will keep them in one place. But what if I want to filter the list based on some word inside the names (suffix e.g.)?
Some search bar? Something like that maybe? Searchbar maybe?
