Draw order


I’ve been using Rhino a long time now for architectural purposes. Since the introduction of Rhino 7 I’ve been experiencing issues with the draw order of hatches in certain display modes and with printing.

When making a 2D drawing with curves and hatches the hatches are printed in front of the lines. So when viewing the printed pdf, the lineweight is half of what it should be. And especially pattern hatches in front of the boundary lines look messy. This is solved by selecting all the hatches and using the command SendToBack.

Could the hatches be printed behind the lines by default? If I remember it correctly this was the case when I used Rhino 6 and 5.


A second issue occurs when using the commands SendToBack, BringToFront, SendBackward, BringForward. In display modes like ‘Rendered’ and ‘Arctic’ objects like hatches and curves that were affected by one of those commands are visible through surface and solid objects.

This is fixed by using the command ClearDrawOrder, but now the hatches are back in front of the lines when printing a layout. Why is the draw order affecting curve and hatch objects that are behind other objects? A draw order should only matter if two or more objects are overlapping in the same plane.

Hopefully there is an fix for this issue I overlooked, but couldn’t find one in the other topics.

1 Like

These are known issues but there hasn’t been much progress from the developers yet. Read here, maybe you’ll find some answers:

Spot on, but the problem is that Rhino is in 3D, but (hold your breath) Layout printing is only 2D…
So in print space everything IS on the same plane… It’s a known “bug” that stuff look OK in 3D but prints wrongly. I say “bug” since it is not a technical bug per say, but it surely is a user experience f*ck up as users expect to get what they see and understand: “If it is physically below, then it will draw below”. And if it previews OK then it prints OK. But it doesn’t because the preview is still a 3D camera showing the 3D draw order. (Yeah, it took some time and numerous explanations to me before I got it. But since then I don’t have draw order problems any more. Thus I am silent on the front. BUT you can’t run around and teach every user that the software behaves strangely (from a human point of view) under the hood. So keep on bring the topic up, it’s the only way to push it to the top of the heap of stuff to fix.

What you have to do is to keep a strict layer order, and placing hatches on layers or sublayers below curves. Then it should print OK.

1 Like

This is a good point. I think hatches should by default draw behind curves that are on the same layer and plane.

1 Like

plane yes but layer? it should be optional…

Thank you very, very much! Moved the hatch-layers below the lines in the layer order and the hatches immediately printed behind the lines.

Now I think about it, this opens up also some opportunities for masking out some items in 2D-drawings. A sublayer with a white masking hatch could be useful on some layers, for instance when drawing interior objects.

My pleasure and good luck!

And yes, we use white hatches for masking quite often.

i agree with @Holo that there is some homework to do for mc neel.
It is not only about printing, but also about output to machines.
And for this a .dxf export (drawing-order / Runtime serial number ) but not Display-Order will influence the order. - and for .pdf / svg Display-Order influences…
somewhere in the youtrack there is a precise description of the rules what is printed in which order…

i still miss the info wether it is the order in the layer-palette or the (different) index of the layer (which is the order layers are created)

see this topic as well