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
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.
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?
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.
Yes.
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. YouTrack
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.
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
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)…
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.
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.
