Hi,
I’m desperately trying to automate hatching with grasshopper in rhino, I don’t know how to orientate successfully my hatches to my geometry, it always seems to work with certain direction but not other…
(in this example, the idea is to have the hatch always perpendicular to the longest side)
Any help would be greatly appreciated !
hatchtest_20.09.2024.gh (8.2 KB)
hatchtest_20.09.2024.3dm (76.6 KB)
Hi @Romain3,
The problem seems to be in the direction of your input curves. In Rhino, I used DIR and/or FLIP to make them all counter-clockwise while testing, then I added the FlipCurve component. I did some testing and a bit of reconfiguring in GH to get it to work, too. See attached.
hatchtest_20.09.2024_fix2.gh (16.4 KB)
hatchtest_20.09.2024_fix2.3dm (61.9 KB)
Maybe it’s just me, having a bad day, but for something so conceptually simple, I find this way more difficult than it should be 
P.S. This would be so simple with a ‘D’ input (Direction vector) instead of an ‘R’ input (Rotation angle). Is this another R8 flaw? Really strange…
I give up, for now. FRUSTRATING
The highlighted List Item shows the longest edge of each curve. The Rotate component shows the direction wanted for hatch lines (90 degrees to the longest edge). The Gene Pool angles selected by eye are approximately correct. The Degree component wired to the text panel may be wired to the Hatch ‘R’ input instead of the Gene Pool. When you do, it’s obvious that hatch angles are wrong for curves 11, 12 and 13. I don’t know how to fix it. 
Next morning: I see that when the GH file I posted last night is opened before the R8 Rhino file, the ‘P’ (Hatch Pattern) is missing (null). Messing with it, there seems to be a series of related bugs? But if you open the R8 Rhino file before the GH file, the problem doesn’t happen.
R8 is still full of bugs! What a complete disaster it has been
@Joseph_Oster, I just swapped A and B from your definition.
hatchtest_20.09.2024c.gh (35.2 KB)
The issue you mention is not a bug, same way the geometry input is referencing existing geometry from the model, the hatch pattern input P is also referencing a hatch pattern from the model.
If the pattern is missing in the current model it warns you as the geometry parameter would do in this case.
Unfortunately there is still no option to internalize the pattern.
Based on your definition I did this one that uses the Plane input, the benefit is that it works on any plane orientation and not only on Word XY.
When used like this Boundary is projected to the input Plane.
hatchtest_20.09.2024d.gh (21.5 KB)
And that makes sense to you? I’ll have to think about it… 
For something so simple, this was WAY TOO HARD!
In your image, I see that you moved curve #10 so maybe you struggled with it too?
Your solution has the hatches parallel instead of perpendicular to the longest edge of each curve, but that is easily fixed by using the Rotate output instead.
Yes, this is the first time I can recall where the Rhino file must be opened before the GH file.
I understand that but… why is the Angle ‘P’ (Plane) input required at all?
I squandered too many hours working on this. And failed. 
I hadn’t actually looked at your version ‘d’ when I replied before. When I did, the code looks odd to me and, as noted before, “the hatches [are] parallel instead of perpendicular to the longest edge of each curve”. I did it this way instead, using Planar:
<snip>
Wait a second!! The Hatch component in your version ‘d’ doesn’t use the ‘R’ (Rotation) input at all It uses a hidden ‘P’ (Plane) input instead Wow, who is the evil genius that thought up rotation instead of plane for this?
Flip curve was all nonsense. After more changes to handle different planes, I end up with this:
To test it, I modified the Rhino file: (same GH file)
hatchtest_21.09.2024b.3dm (99.6 KB)
I think both the Rotation and Plane input would be very valuable weapons for the Hatch component
thinking of a way to have them coexist in the same component, the only non-idiotic thought that came to my mind is to replace the Hatch “Base Point” input with a “Hatch Origin” input
if the Hatch Origin input is left empty, then it defaults to World_XY Plane with Origin {0,0,0}
if a point x,y,z is input then it’s interpreeted as XY_Plane with Origin {x,y,z}
if a “proper Plane” is input then that Plane is used
in such a way the Rotation would always happen around that Hatch Origin plane
I also believe that would not demolish any old definition, as Base Point is not very commonly used, and even if it’s used it would be interpeted as an XY Plane?
They exist now in the same component, though by default, plane input is hidden. What does rotation do that plane input cannot do? Measuring angles is fraught with difficulties while orienting planes is easy. I see no reason to have rotation. What happens if the two are in conflict?
Would have saved me a lot of grief if I had known about plane input instead of struggling so long (and in vain) to measure angles.
P.S. Then again, a plane is implied by the ‘B’ input (“Planar surface or curve that defines the boundary of the hatch”) so rotating (aligning?) that plane is the only issue, which can be done with a ‘D’ (Direction) vector, same as Align Plane.
We tried to keep as much as possible Rhino UI nomenclature for the user to discover what the input does. This is why is called ‘Base Point’.
In this case I think is really convenient to have both ‘Plane’ and ‘Rotation’ where the plane is the base plane where the hatch lays and the rotation is a rotation on that plane.
This way the user can define what the base orientation should be, but apply an additional rotation on this plane like in this case to make it perpendicular.
In some way Boundary and Plane define the geometry of the hatch, where it is in the model and how is it oriented, while Base Point, Rotation, Scale and so on define how the pattern is applied on it.
I make it visible by default on v8.12.
oh, wow, well… you are right 
had no idea it was already there!
this opens a little door in my head and I’m asking myself how many hidden inputs of the new R8 component I might have completely missed… 
on this very topic @kike is there any way to add a GH option/preference checkbox like “always show all parameters” ?
I tried searching for it in the forum but didn’t find any thread… I think it would be useful to familiarize even more with the new R8 components, then you can always disable that option once you get used to them
I know I can click on the little mark on the bottom to show all of them, and I can also right click on the component and chose “show all parameters”… but it wasn’t enough, at least for me they won the hide and seek game
I think I need to always see all of the inputs on a daily basis at least for a couple of months, in order to get used to their presence and be able to remember what is were… after those two months of forced training I could for sure hide again most of them like in the current state of the art
Hi, thanks a lot for your answers !
Seems it wasn’t so obvious, I thought I was becoming crazy !
