For Rhino 9, we’ve redesigned Rhino’s hatch pattern interface with a fast, visual grid. This will allow better management of large collections of hatch patterns.
Instantly search, sort, and filter hatches by model or layout. Multi-select for batch actions, use right-click menus, drag to copy, and easily spot hatch types with new color and icon markers—all without UI lag.
The smaller Hatch panels can now also import and search thru the patterns in the control.
Show Hatch Types
There are two hatch types that can be used for different purposes.
Layout Hatches (outlined in blue borders) - 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.
Model Hatches (outlined in red borders) - 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.
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.
