I’m struggling to understand the “natural” draw order that rhino uses when printing to PDF as vector.
Is there some sort of primer on how Rhino groks all this, before one goes about and manually adjusts draw order?
I’ve been able to glean some information that it is related to layer order, and layer hierarchy, just as in photoshop or illustrator, etc.
I think the biggest thing is that the model space, and even on as shown in a layout, don’t operate by the same principles as the PDF printer. So what you see, is not what you get.
It seems like it tends to go down the list and put lower layers behind higher layers.
Nested layers tend to follow the same hierarchy. Objects in the “parent” layer of several sublayers don’t seem to situated in the stack relative to sub-layers with any consistency however.
Curves seem to get drawn above hatches however, also inconsistently.
Z height seems to not matter when printing, but it does matter for model space.
There seems to be some sort of preferential treatment for the creation order of objects, but there’s no way I can figure that out.
It also seems clear that locked layers are always sent to the back, and then drawn in order of layer structure.
If the system is just way it’s going to be, and can’t be made more predictable, can the logic behind the system at least be explained somewhere?
As far as I know, the draw order should be the same as in the viewport.
When we get reproducible samples of situations where this doesn’t seem to work, we can try to fix the issue.
-wim
You’re right, but only in about 70% of situations, or at the least with very simple drawings.
Here’s an example that’s a recreation of several other forum posts. None of the objects have a manually applied draw order.
One is the green hatch has a higher z value than the other objects, including the white crv.
The other situation are the two purple hatches that show up in front and behind the red hatch, seemingly of their own volition.
Another common issue found through out forum posts is how 2D blocks work with draw order.
The bigger issue in all of the cases is that even if PDF did print exactly what was in the viewport 100% of the time, controlling the final draw order across many layers and objects at once is very difficult without a defined set of rules. print draw order.3dm (64.4 KB)
Thanks for that example. I’ve put this on the list as RH-64173.
Z-fighting objects without draw order in parallel views adhere to the layer order in the current Rhino 7 version (RH-61463 - not visible to the public). Z-fighting objects in perspective views will require a new way of displaying these and is on the list for Rhino 8.
I see that RH-63737 was recently put on the list and seems to be covering what you mention.
Apart from these 3 specific bug reports, there are several more open items that mention draw order.
-wim
I think there’s still some confusion of how the objects are layered and the order the objects are drawn.
In either case, is there a definitive outline for understanding the logic Rhino uses?
Like even if it’s buggy and imperfect, is there any documentation on the procedure so I know better what to expect?
