For Rhino WIP, we’ve redesigned Rhino’s Hatch pattern interface with a fast, visual grid. This will allow better management of large collections of hatch patterns.
Previous versions of Rhino managed hatch patterns through a simple dropdown list interface that became unwieldy and slow as pattern libraries grew. This created several workflow issues:
Visual identification was difficult: Text-only pattern names made it hard to quickly identify the right pattern without trial-and-error
No batch operations: Importing, organizing, or deleting multiple patterns required repetitive one-at-a-time actions
Performance degradation: Large pattern libraries caused noticeable UI lag when opening dropdowns or property panels
Limited organization: No ability to filter, search, or separate patterns by type
Unclear scaling behavior: Model vs. Layout hatch types weren’t visually distinguished, requiring users to remember or test each pattern’s behavior
The new tabbed grid system addresses these issues with instant visual previews, organized tabs for Model Units vs. Layout Units patterns, search capabilities, batch operations via right-click menus, and optional visual indicators (color outlines and unit icons) that clearly show each pattern’s scaling behavior.
Model hatches do not adaptively scale to the layout size. So, they can be used to represent specific material patterns. Say a 4"x4" tile on a wall or floor.
Layout hatches will resize to have the correct drafted spacing in layouts. For instance a symbolic pattern that represents aluminum needs lines 0.25" apart no matter what scale the drawing is printed at.
1.layout hatch: A 40x40 cm grid of a tile hatch defined as a layout hatch will appear as 40x40 cm in model space. In layout space (e.g. 1:100), it keeps its proportion in relation to the model — so on the paper print, it will appear as 0.4 x 0.4 cm.
2.model hatch: A 40x40 cm grid of a tile hatch defined as a model hatch will appear as 40x40 cm in model space. Since it is not scaled separately from the model in layout space (e.g. 1:100), it maintains its scale — meaning the hatch will appear as 40 x 40 cm on the paper print.
Am I right here? If so, what is the “Use hatch scaling” option for?
This is very important and awaited feature but I have some doubts about the way it was implemented.
I don’t understand why you went with distinguishing between two completely separate Hatch types. This for me doesn’t align with other Rhino elements, such as Layers, which are a single object but have separate settings for Model View, Detail View, and Layout View.
This could have more sense If we would be able to assign different Hatch for every Model View, Detail View or Layout for one Rhino Model Object. Actually, good system of per view overrides is important while producing documentation.
Now:
One object, but two Hatches to choose from. I have to decide on just one, one that might look good in Detail Views but bad in Model View, or vice versa.
In Model View layout units hatch scaling is too big in this case
In my opinion, there could be just one type of Hatch object with optional separate Layout Scaling settings. This way, for a single Rhino object, we can set the correct scaling in both the Model View and the Detail View. Now, we can only set the scaling of Layout Units scaling Hatches in Model Views with a global multiplier.
Unless, as I mentioned at the beginning, you’re actually moving towards a system that allows you to assign a different Hatch overrides to a single Rhino Model Object in each view, but still, at minimum this would mean that sometimes we need to assign two differently scaled hatches for the Model Views and all the Detail Views.
The general rule on drafting poche is that it should be the same size on the page regardless of the View Scale. The model scale hatches are for real world sizes such as concrete block.
There is the ability to override a hatch in Section via its Style.
Yes, the same size regardless of the View Scale is perfectly understandable.
The point is, however, that the representation of these Layout Unit Hatches in Model View can only be controlled by the global scale multiplier. It’s possible that I’ll have two good-looking hatches in Layouts (because they are Layout Units Hatch types) for which I can’t find a common, good-looking multiplier in the Model Views. Therefore, it seemed to me that maybe a better solution is to simply define for each hatch how it should appear in Model View and how it Detail View. If we want the scaling to align well with the detail scale, then we would simply check this option.
This one I don’t know how to do. You mean that I can override Hatch style of one Model Object so it has different hatch in only selected Detail View? The same as in Revit by Graphic Override?
The difference here is if the hatch pattern has some final standard scale or not. The example shown is a reinforced concrete hatch. By standard it should have 0.25" between the lines when printed on the final sheet. So it needs to be a Layout Style Hatch. Hopefully people do not have to worry about scale because the pattern will come out properly when printed And when creating the patterns, we encode into that pattern what the standards are: ANSI, ASMI, ISO etc.
If a hatch pattern needs to be a specific size in Model space and not change no matter what scale it is printed, then that is a model scale hatch. In this case the definition itself may have an exact scale “4x8 Brick” or be set to one unit “tile” so that it can be scaled to whatever the size needed on the hatch itself.
Hatches can be switched between the two, but technically the two hatch patterns do have different uses and therefore are actually defined differently in their original code.
Ahh, that makes more sense! But I didn’t intuit it from the names. Might it be helpful to give them names that don’t carry the placement implications of Display and Layout? Scaling and Non-scaling maybe?
As a university student—and speaking on behalf of many of my colleagues—it would be extremely helpful to have the ability to generate insulation batting directly from a single line in Rhino, similar to how it works in AutoCAD. This would be especially valuable for complex or irregular shapes and geometries, where being able to apply a “line-type” insulation batting quickly would save significant time and improve workflow.
In Rhino 8, hatch editing is still very limited: hatches cannot be trimmed, split, joined/merged, or used in boolean operations, and control points can only be moved, not added or removed.
It would be great if Rhino 9 could address these limitations and provide hatch manipulation options similar to those available for surfaces.
Is this already being considered or planned for Rhino 9?
These are welcome new features but let me complain about the long standing bug of wrong print order of hatches in PDF output - ie. hatches unexpectedly obscure other geometry.
It is still present in 9.0.26048.12305, 2026-02-17
