Block Management Tools Need Improvements

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.

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…
:slight_smile:

2 Likes

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.

2 Likes

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.

2 Likes

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?