I requested just this type of functionality for Rhino back in July 2015. Nearly six years on and nothing has progressed.
The fact that some poor souls here are so desperate for a fix that they’ve resorted to physically setting objects higher/lower in Z to try to get some sort of draw order control shows that something needs to be done.
I’m one of those fools…
But maybe McNeel is afraid of opening this can of worms. In fact, nurbs surfaces should also participate in the draw order (in 2d views this makes sense), which they don’t.
This is the heart of the matter.
Out of curiosity, how does Microstation handle display of the layers that have equal priority values, as shown in your second screenshot? It looks as though Microstation will let you assign equal priority to two (or more) objects?
I believe, the first one created gets shown behind the newly created objects by default if the draw order parameter is the same.
McNeel gods, do you hear our cries?
Here’s a script that works for me. See example file below. Hope it can help some of you guys
if(!run)
return;
for(int i = 0; i < layer.Count; i++)
{
int layer_index = doc.Layers.FindByFullPath(layer[i], -1); //doc. = RhinoDoc.ActiveDoc. //-1 = no layerindex > then layerIndex = -1
if (layer_index > -1) //if -1 then script stops
{
Rhino.DocObjects.Layer lay = doc.Layers[layer_index]; //Replace Rhino Layer or subLayer by "temporary new layer (so no sublayer)", FindByLayer function doesn't work with subLayers
Rhino.DocObjects.RhinoObject[] rhobjs = doc.Objects.FindByLayer(lay); //objectlist from lay
foreach(Rhino.DocObjects.RhinoObject rhobj in rhobjs) //loop through every object in layer to change displayOrder
{
rhobj.Attributes.DisplayOrder = i;
rhobj.CommitChanges();
}
}
}
display order test.gh (10.2 KB)
Display order test.3dm (190.5 KB)
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 
PLEASE let us help you out in ironing out this bug once and for all. Thanks.
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:
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… 
That would probably be a whole lot of code to adjust too, but imagine how many lives you will save 
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
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? 
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
Haha… Good point on the who’s-who… 
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
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!
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.
Thanks!!
