Hi guys. @pascal@wim
I have reported this so many times and each time I see the same trouble.
Things that looks OK in Top view isn’t always the same in Layout.
Things that looks OK in Layout isn’t always the same in the exported to a PDF:
Rhino to the left, Acrobat to the right:
And to right this we have to spend a lot of time moving things out of the plane they are drawn on.
AND draworder is not respecting fully a block that has BringToFront. (I have to BlockEdit and fiddle with the objects in there too)
Just to make clear:
WYSIWYG all over the views and to the PDF is PARAMOUNT. As long as we see what we get we will adapt. This is so much more important than the logic behind any draworder stacking theory. But obviously having a user friendly logic behind this is important too.
So if a block has an internal draw order and I move the block UP in the hiearchy OR if I edit a block and use SendToBack, I expect the entire block to be handled as one element within the file draw order.
But first of all PLEASE work with us to get at least the Layout Detail to draw the same order as the top view AND have the output use the same draworder as the Layout.
I sorry but I can’t afford spending time reporting this and sending files unless I have a dialog with you guys, It’s timeconsuming enough trying to fix and QC the output on deadlines as it is.
And here I deleted the trouble tree and replaced it with a copy of one of the others AND THEN SUDDENLY A NEW ONE IS THE TROUBLE… I am going crazy here. Need a big cup of coffee!
(Obviously I have to mess with the three block now, but this shouldn’t happen)
And here is the PDF… It’s all a roll of the dice what Rhino does, and THAT’s the part that’s killing me.
(obviously it is a logic here for someone to find)
To fix the threes I had to blockedit it and sel crvs and bringtofront.
(But it already apparently had a draworder that worked, but why not on all instances???)
Lines drawn OK on top in Rhino and Layout but not in PDF.
OH! And the man… he is a block that both lines in block and block has thickness sat to default and print has default as 0.35 mm and the PDF is OK, but the Layout shows hairline…
Keep in mind that the white hatches are NOT sent to back, I cleared their draw order AND they are physically 0.5 units elevated from the picture frames.
So why does layer lock state affect draworder when printing???
Those are in vector.
To fix a good print I had to select the white hatches and bring to front, hide, select all other hatches and bring to front, hide select all curves and bring to front, hide and then fix the blocks internally.
The thing is that that process would have been all OK IF what I saw in top view was the same as in the layout and that again was the same as in the PDF, but since I don’t get what I see I constantly have to check the final output to see what is wrong.
I guess some of the issues I see is that the layer hierarchy kicks in too, and that too is totally OK IF what I see in view, detail and pdf is the same. Because then I would adjust it on the fly instead of spending so much time on bugtracking on the deadline because the output is not what I was presented earlier.
Hope that makes sense. And that you understand the frustration that comes from being delayed on delivery because of finecombing the final pdf for potential changes made by the export. I’m more than eager to spend time with you fixing this. (BTW this is from an ongoing project that has not been ported to V7, so it is still V6, just to make that clear. We can’t swap platform mid project)
Oh,
I can feel the pain while reading this…but you are not alone, I am going nuts as well when deadlines are coming in. And draw order is one of my favourites
Thanks for the support
I hope I wasn’t too short or direct in my typing. Prioritizing bug reporting while working tends to come out a bit harsher than what’s optimal.
Draw order and PDF printing is painful. I think Rhino 7 is slightly better but still very unpredictable.
I use linked blocks for batch printing of 2D drawings. Sometimes the order you see on the original file is completely different to when you see it linked to when you print…
I find printing in Rhino PDF raster more reliable and that’s what I use unless vector is absolutely necessary, just for that draw order reason.
@Holo, I feel ya, too!! Been in that WYSIWYG hell with my diploma project, which I took as a test balloon to learn Rhino layouting thoroughly. It turned out it’s really awkward, because of the reasons you mention, for the fact that model view layers mess with layout/detail layers, and other stuff.
In the office nobody (except me sometimes) produces layouts right out of Rhino, but mostly Illustrator, and even AutoCAD (!). That really hurts. @McNeel: please, please! It’s time!
Same problem here! Super frustration. I gave up on the drawing order because of its inconsistency. At one point i thought i could work around the drawing order by clearing the drawing order and project my hatches and lines at different Z-heights. Worked for a while. It still looks correct in TOPview but once i print it as vector rhinoPDF it messes it up again. Seems likes it flattens the Z-height and uses the drawingorder again which i already cleared for all objects.
It would be great to be able to open draw order and change manually the order.
For example if I want that Layer 2 is drawn before Layer 1,
Also it would be great to change hatch printing order (sometimes we want the plain hatches in the back, sometimes in the front).
I work with another office who has Autocad and exchanging plans is a mess because they really love mixing hatches (and I would like to).
I already spent hours playing with “Sendtoback” “Sendbackward” “Deletedraworder”… without any significant step forward.
PLEASE explain what is the problem and if there is a possible solution !
This means that the draw order set at the block level takes priority over the draw order set at the layer level. Draw order set at the layer level takes priority over the draw order set at the object level. However, because this is just a single value, you can override it. For example, if you have a layer with a low draw order (e.g., background images), but you want one object in that layer to be displayed in front of all other objects in the scene, you can open the object properties and type in priority 999 999 999. This will make it appear in front of all other objects in different layers and blocks.
It is not a very intuitive system, but it works. The draw order is not concealed. At any time you know what Draw Order value each object has and why it appears in front or behind other objects. I think this transparency is critical. The most frustrating thing with the draw order is not knowing why some objects are shown behind when you want them in front. BIM software (ArchiCAD, Revit) is bad at this because draw order is also set by the type of object (a wall will be in front of the slab by default). So another set of criteria is added to the mix, making it difficult to figure out why elements appear on the screen the way they do. This Microstation approach is brilliantly dumb - each object gets a number that can be amended in the object, layer and block settings and the object with the highest number is drawn in the front.
This is a must!!!
Desirable: draw order control per layer. And an exposed draw order index in the properties panel, please!
What in god’s name, dear McNeelies, is holding you up so long on tackling these things?
Here are two primitive python scripts that query draw order index and set it directly - which is possible: GetDisplayOrder.py (222 Bytes) SetDisplayOrder.py (285 Bytes)
