Hello,
Here’s an idea that would most likley impove visibility for layouting etc: Instead of using SendToBack and BringToFront - which create a mess, how about using a new layer parameter to sort visibility:
This will look like a new column in the Layers Panel called Visibility order :
Hi Bogdan -
I can’t tell from your comment if you know that the layer order currently sets the draw order - i.e. you don’t need to use SendToBack, etc. if you have organized your geometry into layers for setting the draw order.
Other than that, we have a feature request on the list for being able to set the draw order as an attribute to both an object and a layer. I’ve added your mock-up to this request.
→ RH-69113 Add draw order to the UI
-wim
Hi @wim ,
Thanks for adding
As for the layer order currently setting the draw order, maybe I am in a special situation, because what I have below is not working accodingly:
There is Layer Default holding a pictureframe and layer grid below it.
And as you can see the grid lines are visible, they should be covered by pictureframe, no? Defult is above grid.
Maybe pictureframe is a special case?
(Display mode is set to shaded)
Here is another case where the draworder is correct for the hatches but incorrect for curves
Red rectangle and hatch are both in the same layer, below the blue layer, but they behave differently. Hatch below, curve above.
Hi Bogdan -
When you select something, as in your picture, it will always be shown on top of everything else. Also, the draw order system does not apply to surfaces, such as pictures.
The display code slightly biases all wires so that edges of surfaces are not lost behind the display mesh of the surface. “All wires” includes surface edges, curves, and hatch patterns. Because of this, coplanar curves that are on a layer that is below the layer a solid hatch is on will be drawn on top of that hatch. You’ll still need the send to back / bring to front mechanism to get those to display as you need. Improving this in details on layouts is on the list as RH-64762 File IO: Wire display in “vector mode”
-wim
Most important for proper layouting are curves, hatches, pictures,
If it doesn’t work correctly for those… than it’s not useful.
here’s a video showing the problem with curves and hatches:
Yes, as explained, in that case, you’ll still have to use the explicit commands to set the draw order.
-wim
yes, it’s actually quite annoying
Right, pictures need reliable support for draw order! 
Now they can only be created by a plane with a textured material, also in layouts. (Posted already here).
Since surfaces do not partake in draw order, there’s no way so sort them.
I just tested it again. It does not make any difference if overlapping pictures sit directly on a layout or are visible through a Detail viewport. Zooming with the mouse will result in random flickering of the pictures when they ‘z-fight’.
The only reliable way to sort them seems to be putting each picture into a separate Detail view, and set the draw order for the Details (which is possible).
Not a nice workflow though. Too complicated for such a simple thing, and the pics need to be placed in 3d space somewhere afar from each other.
What could be done?
Added support for draw order for surfaces.
The moment 2 surfaces are coplanar / have equal coords, the one with the higher draw order is drawn on top. If the coords differ (one e.g. has higher z), the draw order is ignored.
Is this technically feasible?
‘Picture hatches’ are added. Work like normal hatches, but can contain a texture, with u and v scaling.
What say you?
