Display order linked to layer order

The current control of the object display order linked to the layer order is laborious and a hassle. Furthermore the object display order of the layout and print preview window (and actual print) are not matching.

In Rhino 6 and earlier Versions of Rhino 7, hatches always printed in the very back, text and dimensions at the very front.

In Rhino 8 (late Rhino 7) the object display/print order is apparently defined by its layer order position (like in graphical/painting programs such as illustrator or photoshop).

It is crucial, that the display order is not inherited by layer order because it is needed to structure layers independently (of the display order requirements). For example there could be both, line and hatches on different/ separate layers, whereas the hatches should never overlap the lines. This is also crucial as in Rhino, objects initially inherit their properties by their mother layer. We know that there is an override as “send to back” but that is to effortsome and causes errors.

Furthermore this is standard in every CAD Software. For us, if this behaviour is maintained, this represents an absolute game-changer against rhino.

Regardless of its layer tree position….

Top objects: Dimensions and Text
Middle Objects: Lines
Bottom Objects: Hatches, whereas solid hatches should be at the very back

For other applications layer order is really good.
I feel you’re right for the print of technical drawing.
Could it be that only printing order will follow your suggested structure?

Top objects: Dimensions and Text
Middle Objects: Lines
Bottom Objects: Hatches, whereas solid hatches should be at the very back

@stevebaer what do you think?

Best would be a fallback to the old behaviour - or alternatively the possibility to choose….

I think it is a No Go that this was changed within Rhino 7 - kind of corrupting all our existing RH7 drawings…

You are right, this is important for technical drawings. On the other hand this is anyway irrelevant for 3d modelling or rendering…

Anyone who wants illustrator/photoshop functionality should use that other banal software….

In order to use layers in their full potential they should not affect display order…

It is sad - we are long time rhino user and we really like it - but this is a small but very critical aspect in our daily work. This causes so much work/print errors that we are considering alternative software.

This was also brought up here:

I added this request to our bug tracker at
I have also made this bug referenced the bug report that Guillermo made while working with you via email.

There were many requests to print using the order that Rhino 7 and 8 currently have in place which is why the change was made. I will see what can be done in Rhino 8 to allow choosing between the existing order and the one that you are requesting.

Thanks for your effort. I have the feeling there is a vast majority of users looking for the previous/old behaviour…

Again, this option limits layer capabilities and therefore rhino. No other CAD software is working like this, only simple graphical apps such as adobe illustrator or drawing apps like sketchbook which are mainly based on pixel…

I also don’t understand why a solid hatch should be able to overlap a text or dimension object or a line…

Blocks that include layers and hatches are incompatible with this display order concept.

This always requires to create hatches in a separate layer…

For graphical reasons, maybe. ‘White out’ something. What is drawn on top of what should be free to choose.

But I did a little test here. Just a few color hatches on different layers, each with a curve frame and a text on the same layer. What I don’t understand is, why are hatches correctly occluded, but curves and text are not?

Here I changed the layer order a bit. It shows that, even in the viewport, draw order of hatches is indeed dependent of the layer order.

But not for text and curves…

Now, when I e.g. select the orange box (layer 05) and use ‘BringToFront’, even curves and text are occluded.

When I try the same with the orange block, it does not work, because blocks don’t participate in draw order.

Furthermore, in a 3d view, objects with a display/draw order other than 0 don’t go into z-fighting, whereas all others do.

What’s my point here: Draw order is a very hard thing to understand and solve for a drawing, for a variety of reasons.

Thanks for your vast comment…. Did you do this in current Rhino 8?

This seems to meet the expectations….

Hatches are the lowest lying objects/ hatches itself follow the layer order/ text and lines are on top unless there is an override via a display order command

Well, I was about to post something about this topic myself, because I find it quite bothersome.

Even if this is what you would expect, I don’t see the logic in it. Why are lines/text not partaking in the sort order given by the layers? What if I want them to? Then I cannot use the layer sorting mechanism but have to use draw order.

Something related that could really need a fix:
Since pictures are always textured surfaces, there’s no way to control their draw order, which is crucial for advanced layouting.

1 Like

Sorry. The problem is also, that the layout display is not matching the printpreview. As you can see in my original screenshot, the layout preview is good for us, but it prints differently. For 2d objects/drawings, where you go for an actual print or a pdf this is crucial.

Can you please check the printpreview of your testfile. Can you also share your testfile?

This is indeed the case with those picture surfaces. Their sorting might look ok in the layout (in a layout directly. Think of a sky background behind a Detail view), but in the print dialog, it’s different.
Regarding lines, hatches etc. I will check again later (and share the file). Looked ok (like in not different). PrintDisplay must be on of course.

test draw order.zip (366.1 KB)

This issue/problem was intruduced in Rhino 7 as well with some of the later serviece releases. Can’t you just make a fallback?

The bug is referenced above and is on my list to investigate.

1 Like


What I have to add is the following: For similar type objects (eg. hatches or texts), the display order by layer order is good.

Important, nontheless is, that the general order is as follows:

Top objects: Dimensions and Text
Middle Objects: Lines
Bottom Objects: Hatches, whereas solid hatches should be at the very back

Overrides are tolerated via the send backward/ send to back… commands.

For my impression, this was the functionality of older Rhino versions and all other CAD Apps i know (Autocad, Nemetschek, Archicad,…).

are you sure ?
I would never dare to speak on behalf of the majority of users !

Display and Print Order was discussed at many topics - so I think there is a need to precisely and clearly control it.
Backward compatibility is another aspect but should not prevent innovation.
(some "use legacy print order checkbox maybe ?)

I somehow like the Idea of having Layerorder = Printorder.
But my main focus is Workflow (Modelling) = Layerorder - which might conflict with this Printorder.

I hate Bring/Send Back/ForWard as there is no way to monitor / display the resulting hierarchy.

my suggestion:

  • printorder should be documented nicely in help (if this is not the case)
  • printorder override should be shown in properties (result of bring/send …) (or is this already the case ?)
  • layerorder = printorder
  • layerstatemanager should save layersorting and layer-nesting
    this would allow to have two states of sorting / nesting layers
    • PrintState
    • Modellingstate
  • legacy print order in the print dialog

Sorry, you are right. I just tried to make a point in relating the many existing Rhino users (many thousands) to rather few users that post a wish to change something (that all the other users are probably OK with)…

what do you think - refering to your old topic ?

other older topics that also show use cases beyond hatch-line-text…

@ells.architects - are you happy with the V8 update on print order ?

I made this tool awhile back just in case it helps anyone…

SetObjDisplayOrderOSD.py (4.4 KB)

Creates an on-screen display with selected objects’ display order number
in the form of dots. Allows the user to then select objects from the group
one by one and change display order. Object display order is updated
in real-time. Works with curves, dimensions (inc. leaders), text and hatches.

1 Like

My hope is to create a display mode in Rhino 9 that accurately displays the output order that you would see when printing to vector. This display mode will be slower than standard wireframe mode as there are a lot of optimizations made to batch geometry in a way that reduces the communication between Rhino and the GPU, but we’ll have to wait and see just how slow it is.

For Rhino 8, I will look at the issue that Matthias is bringing up and see if we can provide some sort of option to output to vector with or without layer order having an effect.