Layout DrawOrder is causing so many problems. Can you please focus some resources on this?

Hi @stevebaer,
I have just noticed that the draw order issue is still in V7.
This is the first project done entirely in V7 (The others so far was started in V6, so I thought it could have been some stuff that was carried over)

As you can see the print (and also the PDF) shows the large green hatch behind the brown hatches on print, but not in layout nor in Top view.

Do you want the file to check it out?
This stuff is super important to fix, having to look through every PDF with a fine tooth comb to see if it has some errors is not only a pain, it is also a liability since today we sent one of to the client with out the proper check and they wondered why we hadn’t done some of the changes we should have :expressionless:

PLEASE let us help you out in ironing out this bug once and for all. Thanks.

1 Like

I just made several large changes to how order is defined that still need internal testing. The goal is to have layer order be the primary factor in deciding how geometry is output when it comes to vector output. I can get you an internal 7.9 build tomorrow if you want to see if we are heading in the right direction" for defining order for vector output. Just let me know.

The order rules should be:

  • Send to back objects
  • Layer order
    • for objects on the same layer; text and transparent objects are drawn after other object
  • Send to front objects

OK, I found something for you to play with.

The green hatch is “physically” below the other hatches in Z position. (Edit: in the image above)
BUT the layer is higher in the hierarchy.
So the display pipeline draws it correctly since it is closer to camera, but the print which is 2D probably ignores that.
Could you add that to your priority list?

Personally I think physical position should out rank draw order.

And I see that the display pipeline supports the layer order. Great stuff:
And updates in realtime when I move the layers:
(When on same plane)

But here I moved the yellow one up in space:

And this shows in view and in layout but fails in print.

Physical position is currently not part of the algorithm, but can be added. This gets really hard to get right when the objects aren’t planar and I know a whole slew of bugs will crop up if I just turn on physical position as the highest sort criteria.

This is something I hope to add, but am still not quite sure about the best approach to take.


Yeah, I can imagine… :grimacing:
That would probably be a whole lot of code to adjust too, but imagine how many lives you will save :wink:
At least now I know what has messed up so much for so many years, so MAYBE a solution is to send the trouble over to the display pipeline guys and have them struggle with always drawing hatches in layer order instead… I know, a new can of worms, but now not yours :wink:

No really, from a users point of view, as we work in 3D in a 3D program, I think that what you see in Layout should print is paramount, and what you see in top view should be the same in Layout, so following that chain of logic I still think 2D should respect 3D order.
Anyway, now I know, so you won’t get tons of new posts from me. Wish I knew earlier why what Layout showed didn’t print the same. That would have saved me countless hours and frustration, so for all the others out there I hope you find a solution. And please use me for experience, to discuss, bugtrack etc.

Still my problem. Who do you think the “display pipeline guys” are? :slight_smile:

I agree that depth sorting is important; I’m giving you the current status of our in-house build. The depth sort is up next. We’ll get there; I promise

1 Like

Haha… Good point on the who’s-who… :joy:

For us designer, when sketching and making drawings, we often draw a curve in space, snapping to stuff, not always making sure everything is at Z=0, and sometimes we need hatches above the geometry too, so yeah, z-stuff is important.

Regarding crossing hatches… Ouch… finding intersects and running curve boolean and such sounds difficult and time consuming, so maybe boundingbox center should be enough to start with, even though the viewports shows something else… baby steps :wink:

As a side note; I am currently working on all of this sorting madness and hope to have this working in SR9. This week’s SR8 already has several printing related bugs fixed, but the sort order code is going to take me until SR9 to complete.


@stevebaer Great news. Thanks for working on the sort order. While you are at it, would it be possible to get draw order working for blocks too: Draw order with blocks. Bug? - #3 by Alan_Farkas. SendToBack and BringToFront do not accept blocks anymore. I guess because the above mentioned bug is not resolved yet.


Yes, very good news!
+1 for sort order for Blocks!


Thanks for working on this! And, schucks, @silvano I feel so heard…! :grinning:

1 Like

Those pipe line guys :))


Please try SR9 if you are on this thread and want to test out the changes made for draw order.

Just a quick’n’dirty test. In a Top view, hatches get indeed sorted by layer now, nice! Moving the layers up/down immediately reflects draw order in the viewports. PDF export looks correct, too.
So far, so good!

However, curves’ draw order don’t seem to be coupled to the layer order (yet).
Using a ‘SendToBack’ on the circle indeed brings it behind the rectangles, but not the fact that it’s on the bottommost layer.

Is there any (sane) way to make draw order by layer work on geometry, too?
In this example, the surfaces are planar, on xy.

However, in a Perspective view, z-fighting still occurs, for the hatches, too.


I don’t know how difficult (or if its even possible) it is to achieve, but all these issues would go away if you were to just be able to set a numerical visual priority on a per object and per layer basis.

Microstation have got it right in this case, as per TomasTs suggestion above.

1 Like

The order is for vector printed output and may not exactly be the same as what you see on the screen. Curves do pay attention to layer order. The draw order commands like “SendToBack” override all layer order and place objects behind everything else.

Definitely worth a try! Sounds not too hard to implement, too.
However, the trick will be to make editing/ handling these indices conveniently.

  • What if you like to raise the index by, say, 1 for the topmost 15 layers?
  • Do new layers automatically get a continuous index, or is it all left to the user?
  • What happens when object indices are the same? Newer created object are drawn on top?
  • What happens if layers share the same index? I guess what happens now - higher up layers are drawn in top.
  • The MicroStation way of multiplying the layer index by 1000 (or something) and adding the object index sounds a bit hacky. Are there maybe even 2 independent indices, one for objects, one for layers, where layer index always takes precedence?
  • Layout details should definitely be part of draw order sorting! If a detail sits on a higher layer than another detail, everything inside it should be drawn on top of the other, no matter what the indices inside are.
  • Any changes needed to the old bringtofront/sendtoback commands then?
1 Like

Hi Eugen - Yes it would solve a lot of issues, at least when working in 2D. To your questions:

  • For layers, presumably there would be another column for Priority in the layer manager. Like print width for instance, you can change multiple layers at a time, though you can’t increase them all by one you can set an absolute number for each. Perhaps you could use grasshopper to do something like this.

  • I believe the default priority in Microstation is 0 (you can have negative and positive priorities). I think all new layers should get a default priority which can be set by the user.

  • If all layer priorities are equal then it could revert to layer order as you suggest. Additionally newer created objects would appear above older ones.

  • I agree its inelegant to some degree, but it works well because it means layer priority sets the major priority levels and object level is more for fine tuning. Two independent indices is overcomplicating it for me, but I’m sure there is a more elegant way to do it! At least the object properties could display the objects effective priority (layer + object) so one would have an exact numerical value displayed.

  • Re: Layout details, this is why microstation multiplies references by 1 million. (Ie. object > Layer > Reference priority steps up by a factor of 1000 each time.) But it still gives you the flexibility to bring other objects above/below if you wish.

  • I would eliminate bringtofront/sendtoback as priorities would supersede this method. A major problem with these is that their positions are relative, like a deck of cards and all you can do is move cards around and sometimes multiple shuffles need to be made to get the correct order.

Priorities I imagine as more like one of these:


Every level has an absolute position, allowing you to shuffle objects per layer, but also giving you the flexibility to put an object exactly where you want it.


Waiting for this issue to be solved since I started working in Rhino in 2016.
Last year I had an idea to implement Rhino workflow in the whole office. I really hoped it could become a standard in my work environment. However, one of the reasons it did not happen was the draworder issues. I guess I am not the only one here on the forum…

You do amazing work with this software - subds, nurbs. Please don’t let such a basic issue spoil Rhinoceros!


Any update on this? I’m running Rhino 7SR30. Solid hatches appear to respect layer order, but curves do not. “Non-solid” hatches also do not respect layer order. Edit: I should have read your earlier reply more closely Steve–it looks like they do respect layer order when vector-printed to PDF, but it’s admittedly very confusing that this also does not appear in the Rhino window.

Here is the test case:

And here is where I actually need it to work:

White door hatches should appear above wall curves, but below flooring hatches, and door swing curves should be above all of it. And to further complicate things, everything in the drawing is a block (per building component), which per other posts I’ve read on this forum, appear to freeze the draw order of their objects upon creation of the block.

I like the microstation suggestion above best, as it allows for the most fine-grained control, which is critical when there are 100,000+ 2D objects in a model.