# Grasshopper Hatch Rotation Plane Input (WISH)

I’m finally testing out the Model Hatch components in Rhino 8 and I have some questions. Previously I have used the Human or eleFront hatch components to create hatches in Grasshopper and I expected the new native Model Hatch component in Rhino to work similarly. For the most part, it does work as expected, with the exception of the base plane for the hatch rotation. See image below.

In elefront’s DefineHatch and Human’s CreateHatch components, it appears that the base plane uses the XY plane for all curves parallel to that plane. For the new native Model Hatch component, it seems to inherit the base plane from the curve, but how it does so is unknown and not predictable.

• In curves 1 and 2, both rectangles, it seems to construct a base plane in relation to the vector of between points 0 and 1.
• In curve 3, a Control Point Curve, it seems to use the base XY plane for its rotation
• In Curve 4, a polyline, it strangely uses the vector from point 1 to 2 for its rotation
• In Curve 5, a filleted polyline, it appears to use an arbitrary vector for the rotation (possibly based on some random selection of the control polygon vertices).

My wish is that the Model Hatch component be more consistent in how the base plane is selected. Elefront and Human simply used the base XY plane which is a default behavior for many components. This was useful, as I could input different rotations for each curve based on some angle in relation to the X axis. But Rhino 8’s Model Hatch component is inconsistently creating a base rotation for different types of curves.

It seems like there are a few options to make this better:

1. Always use the vector created by the curve’s index 0 and 1 control vertices.
2. Always use the XY plane.
3. Require an input plane in the Model Hatch similar to how a Circle requires a input plane.

The second option seems the most problematic in that I don’t know what to do if the curve is not on a plane parallel to the XY plane. But somehow both Human and EleFront have figured it out. Option 3 may also be too much for most users, but it would still be a nice optional input for Model Hatch that might override the behavior of options 1 or 2 if those are used as the default.

Rhino 8’s Model Hatch already has a Base Point input so it seems like that could be changed to a Base Plane input and this would resolve most problems. The Rotation input would then rotate around that plane.

Hi @matsys,

Thanks for reporting this.
Currently input boundary is converted to a surface and the hatch is using the resulting UV space.

This will be fixed on next SR8.

Thanks for the reply. This makes perfect sense. Having an optional plane input that overrides the UV space of the surface could useful. I see now how, by untrimming a planar surface created from the curve, I could find the current angle and then rotate it as needed.