Block Management Tools Need Improvements

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.

4 Likes

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.

2 Likes

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.
:joy:

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.

2 Likes

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.

1 Like

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

2 Likes
  • Search by name would be handy too :wink:
  • Reverse sorting, sorting on different properties (You know, that annoying triangle which you make by misclicking in your layers panel)
    image
  • Some grouping/folders?

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?

1 Like

It would be petty of me to mention that I am not alone with my feelings that the block manager needs some love, still…
Toldya. :crazy_face:

4 Likes

Thought I would add in my voice to the angry mob as politely as possible too
Adding Light functionality to this sad list of block improvements:

Better block ! Better blocks ! Better blocks !

6 Likes

I believe that Blocks in Rhino are not only a good concept, but make they make larger Rhino projects practical. Blocks reduce meshes, allow replacements, allow faster saves with smaller files, allow work-groups to divide-and-conquer a project, allow global updating, and have other uses.

With a little TLC, they can do even more, such as allowing a bill of materials and part lists to be made, which is important when you want to bring your thing to market.

[I drew a machine with over 1,000 fasteners, screws, washers, bolts, grub-screws, etc. . It had parts, too. Unfortunately, at the time, and this might have changed, non-blocked parts needed to be blocked to be counted in the block manager. Sigh.]

For me, still most frustrating Block defect still is: defining a block locks it to a layer, which then, makes it harder to work with the layer. You cannot delete a layer if a block was defined on it. So, I define every one of my blocks on the “Default” layer, which usually present, BUT, the trouble comes when you want to explode a block because those objects must be grouped, moved, and organized as not to make a mess. This workaround means that any objects I want to blocked have to be copied into the Default layer before I do, and then I have to move the blocked instance back to the lay I want it to be on. It gets tiresome. In repetition, it’s easy to explode something where it will be mixed up with everything else, or accidentally define a block on a layer.

I am sure that the boat people would want to know the volume of a block, so then masses could calculated. This falls under the category of UI uniformity.

For me, I would still like an A/B substitution toggle for blocks, kind of like an impostor system in video games. This allows a pared down representation of something to be used for work, and then toggled to the real McCoy for the final render. This also would lay the foundation for impostors at a distance, when rendering buildings and details on buildings, at a later date. It would also allow a black-box situation where someone only need concern themselves or let others see certain characteristics, such as the outside of the thing, but not the inside.

[Oddly, I have even found a use to reference blocks in Grasshopper, but apparently we cannot. This would allow Grasshopper to do Grasshopper-like arrays and translations of objects, cheaply for memory. An vendor-provided wall sconce can be blocked and placed in every room of a hotel, using a single rendering mesh. Perhaps they could be counted, too.]

It would also be a little upsetting to have to choose between better blocks and faster draws–because both are required to work on larger projects.

6 Likes

If that’s what you use for that, I think you need to rethink your workflow. But then again, since there’s no database per se in Rhino…

Anyways, worksessions are for that IMO, alas, yet another incomplete technology in Rhino. :crazy_face:

facepalm

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.