I understand the controversy about RH-69172 and although it doesnt seem ideal, your solution to set the print color of all other elements except the white surface to black works for now to achieve the desired b/w result.
RH-70320 is a much bigger issue though, because it makes working with hatches and lines in Rhino blocks almost impossible if the correct display is of importance. The change of rotation, base point and scale messes up your drawing for good.
Thats of course my personal perspective and I understand that there are probably a lot of other issues with a high priority. I was just a little surprised to find it in a state like it seemed to be put on an eternal waitlist.
I wouldn’t trust any other release target than 8.0 right now. That is the list of requirements in order to ship the initial version of Rhino 8 and is what we a focused on.
These hatch issues are a major problem for us. They still exist in the latest updates of Rhino. Hatches in blocks are vital for architectural drafting. At the moment it’s very difficult, as the hatches randomly change (move or rotate) when you edit a block. Big thanks in advance to devs who will fix this!
Hi there i have been facing a similar issue here which is that if i edit a block with hatches in it, their angle is modified post editing.
I have found a workaround to this:
if instead of editing a block, you create a new block with the same name as your previous block and overwrite it, the hatches aren’t corrupted.
although please note that for this fix to work you need need to have the same block base point and orientation.
This is indeed a big issue and interupts a great part of the block workflow, a proper fix would be much appreciated, in the meantime i hope this helps
This problem has been around for quite a while now. But as blocks modify the design here, it seems to be rather a major problem. As the design cannot be controlled, blocks have to be avoided which is very restrictive, even just in terms of file organisation.
Editing embedded and linked blocks in another copy does not encounter this problem. The problem reappears as soon as an embedded and linked block is modified via the _BlockEdit interface. I therefore wonder if the problem comes from the _BlockEdit interface. But I don’t know anything about it, so it probably doesn’t help much.
I imagine it’s complicated, but I hope it can be solved soon. Thank you in advance for your efforts
This problem unfortunately still persists in Rhino 8, Mac, latest release Version 8 (8.22.25217.12452, 2025-08-05)
Setting the basepoint and rotation of the hatch so that it is perpendicular to the walls works while editing the block. After applying the changes and leaving the Block Edit, the hatch Basepoint and Rotation jumps to some random value. I assume it has something to do with the basepoint of the block?
Any idea when this is going to be fixed? Otherwise using hatches in Blocks becomes not really useable.. Thanks in advance!
For now the only workaround I have found is the following:
If the block doesn’t repeat itself: explose the block, set your hatches, reblock
If the block repeats itself (for example a pillar with a hatch, repeated several times on your plan): create the initial block with the geometry in ortho at 0,0,0. Then duplicate and move the block wherever you need it to be. If you need to edit it later, always do it on an instance in ortho at 0,0,0 (doesn’t need to be the initial instance).
