Still a big nuisance in the workflow that blocks are not able to hold groups.
Is there a particular reason this can not be implemented?
1 Like
Indeed, it would be really useful to be able to use groups in blocks. This would enable a continuous workflow.
At the moment, if you decide to create a block with a drawing that contains groups, you have to convert all the existing groups into sub-blocks first, otherwise you lose the grouping. And if theyāre coordinate points grouped with headings (txt, etc) or other recurring elements, it gets really complicated.
Hopefully soon, 
!
Groups are mainly selection sets.
They do not work in blocks as blocks are meant to be repeatable instances.
Using sub-blocks is the organizational way to set a set of objects within blocks that when changed, change in the other blocks they are contained. As it follows the instancing logic.
Any specific examples on this would really help us better understand the problem.
Hi @scottd,
Thanks your for your feedback. Here are a few examples:
Hatches and boundary
When working with hatches, particularly solid hatches, you need to duplicate the border if you want the colour and thickness of the border to be different from that of the hatch itself. This creates a large number of duplicate forms. One solution is to group the hatches with the borders in order to manage them better. Losing this when creating a block is a nightmare. Especially if you have hundreds of hatches. (see topic: Hatch object including outline and solid background - #2 by Helvetosaur)
Alternative: Ability to manage hatch colour/weight and hatch boundary colour/weight separately and by layer/material specification.
Linetypes
The same applies to linetypes. Groups are needed as a workaround to allow watertight, symbol or multiple colour lines to be drawn. (see topic: Dual color linetype - #14 by Helvetosaur & Symbol (Block) Linetypes)
Alternative: Possibility of managing all types of lines internally.
CSV Survey points Import
When importing survey points, it is necessary to attach the name of the points or other information to the coordinates. To do this, you need to create groups. Losing these groups because it is suddenly necessary to make a block is very complicated. (CSV Survey points Import - Naming/labelling points)
Iām sure there are other examples, groups are useful for speeding up workflow and selection.
As long as blocks are not only used for repetitive objects, but also to organise part of a file, it would be nice if they could handle most of Rhinoās functions. Itās tedious to have to abandon groups because you have blocks, or abandon blocks because you have groups.
All 3 of these examples we can handle better and are great suggestions.
The Hatches took a step toward this option in Rhino 8. That thread referenced shows some additional steps we might be able to make. Seems rolling that all into one Hatch object would simplify things.
The Linetypes one is a request we are getting. not necessarily to two color option. But other options such as letters and such in the linetype definitely. The Alternative solution there seems like a good one to get on the list.
The last one is the realm of blocks and attributes. The amount of survey data needed to handle all the various configurations really does need Block Attributes and userdata. I wrote a quick Grasshopper script off the CSV from that thread to show how that might work. As the CSV file changes the Grasshopper script would be easy to adapt.
surveypoints.3dm (51.3 KB)
surveypoint_CSV.gh (21.8 KB)
TEST_Number+TagSD.csv (200 Bytes)
Hi Scott,
Thank you for your detailed answer and especially for the Grasshopper script. Iām going to take the time to delve into it, as Iām not very skilled with Grasshopper yet.
As far as hatches are concerned, there are many messages on the forum asking for the ability to control the outline of hatches.
As for line types, itās good to know that this is something thatās being developed. But as this is a starting point, letās think about it so that itās flexible from the beginning, so that it can handle all the Rhino attributes, colour, multiple colors, line width etcā¦
āā
Regarding the evolution of group management by blocks, Iāve just seen in the documentation that since Rhino 8 grouped objects retain their group status within a block. Good news! But it seems that when you edit the block, and modify a group or even just move it, the next time the block is edited, the group will no longer be saved.
Is this some kind of bug? Are there plans to be able to modify groups within blocks without losing them?
Hi Pipouille -
We have the feature request on the list as RH-69609 Annotation: Hatch: Background and Pattern
Links to relevant forum threads are found in that report.
ā RH-29232 Complex SHP Linetypes (2d Linetypes wish)
Can you post a simple 3dm file and instructions to reproduce the behavior?
-wim
Hi Wim,
Thanks for your track report.
Here is a file, there is one block, with 2 groups inside:
By running BlockEdit, we enter into the block,
The two groups are there. If we try to select them the objects are selected together,
Then just SelNone,
Close block Apply
Start again a second time,
Select the Block,
BlockEdit,
then the objects are not grouped anymore.
Iāve just realised that you may not be seeing the objects in the block as being grouped. It seems that simply saving the file breaks the fact that the blocks keeps the groupsā¦ So maybe you need to explode the block, create the two groups, create a new block and do the steps above.
GroupAndBlock.txt (4.5 KB)
GroupAndBlock.3dm (2.8 MB)
I can confirm that, atleast after saving the block and reopening it the group inside of a block gets ungrouped and you are left with single objects.
in Rhino 8 SR10 Release Candidate 1 for Windows and Mac (8.9.24198) is now available
it states that * Block: Groups can be saved in block definitions (RH-39190 )
which is not the case right now, atleast not after reopening the group.
best regards,
sebowim
Have you had the chance to use this plugin from Food4Rhino?
I feel this needs to be native to Rhino and itās improved my workflow a lot. Your groups wonāt be dissolved when you reopen the block it is in plus you can go inside nested blocks/groups as well and edit them isolated.
great plugin - but even with it, it would be great to have grouped geometry inside a block, that preserves its grouped state.
blocking everything can become tedious in regards to changes that would influence different block, when you have groups you can just sub-select, ā¦ etc.
cheers,
sebowim
Groups stay grouped within blocks in the plugin above so you can do selectionsā¦ you donāt need to make them as blocks.
thank you for your respone - I canāt reproduce this, with the latest block-edit-new version and the lastes service release candidate.
best regards,
sebowim
1 Like
@wim regarding the grouping inside the block are you working on that, or is there a youtrack?
thanks for your effort,
sebowim
Hi Sebastian -
That issue is on the list, yes: RH-83967 BlockEdit: Ungroups objects in block
-wim
1 Like