Steve
I would prefer to retain the current layout “object order” and change/repair the print preview/output.
We are happy with the layout preview/behaviour. For us it is mainly the print output…
Is there any progress on this topic? Thanks.
We are currently delaying upgrading due to this.
1 Like
This feature is not available yet in Rhino 8. I am currently working on some printing code that will eventually allow us to implement the feature, but the feature itself does not exist yet in Rhino. The link I provided above in this thread points to the issue in our bugtracker and is still not in a “closed” state.
https://mcneel.myjetbrains.com/youtrack/issue/RH-78958/Sort-Options-for-Objects-When-Printing
@matthias the latest 8.5 release candidate that was published an hour ago contains a hidden command called
TestPrintSortOrder
This will not autocomplete so you will have to type out the entire command to run it.
If you run this command and change UseLayersWhenSorting to no, the I believe you should get items printed in the order that you want. Please give this a try and let me know if this produces the desired results.
Thanks,
-Steve
Here are instructions to get the latest 8.5 release candidate
Steve. Thanks. That is a solution, thanks. For us it would be great to see this in one of the next regular versions!
What is still confusing is, that the layout view shows a different order of objects to the print preview. For example, there is a line pattern on the orange layer. It shows correctly in the printpreview. The pattern should be on top of the solid fill (both are on the same layer).
In older Rhino versions, the Layer Order was used for objects of the same type. So for example, solid fills where always at the very back. But when there were 2 solid fills overlapping - the one on the upper layer was in front. This was also good.
Independently of Layer order:
Top objects: Dimensions and Text
Middle Objects: Lines
Bottom Objects: Hatches, whereas solid hatches should be at the very back (behind pattern hatches)
The same should apply to block instances…
Oh man… the display order issue is endless. Now using Rhino 8, the software is somehow confused…
First of all, printing seams right.
But the viewport display itself is weird.
- Text displays below lines
- line/pattern-hatches are sometimes below/sometimes on top of solid hatches (although they sit on higher layer positions)
What we require, both for printing and viewport:
independently of Layer order:
Top objects: Dimensions and Text
Middle Objects: Lines
Bottom Objects: Hatches, whereas solid hatches should be at the very back (behind pattern hatches)
The same should apply to block instances…
Print Order2.3dm (856.5 KB)
The next Rhino 8.7 release candidate will use layer order as the last thing to test when TestPrintSortOrder is run and has UseLayersWhenSorting set to no.
1 Like
Dear Steve
We are happy with the printpreview/ printing. The only problem we have is, that the viewport appearance does not match the required printing result.
We do not need an order defined by layer tree (uselayerwhensorting).
1 Like
Yes, very happy.
joining the conversation,
has it been discussed to have a simple right-click option : send to back, bring to front ? I’m using it in archicad all the time, and try to transfert all of this workflow inside rhino.
For designing, drawing, it would be usefull to control order without having to make a printpreview each time.
** I can’t see which curve is above which while drawing…
*any tips ?
Regards,
-CC
Just to add something i didn’t hear somebody talking about, but in my case it would be nice if the drawing order would stick to the Z-Value of the elements; Ive to combine a lot of different data coming in from other architects/planners so i layer 2d drawings in 3d, simply putting them above; when printing it out in pixel, rastered pdfs, this z-layering works quite well, and it goes along with the rhino viewport behaviour; so wouldnt it be an option to link the drawing order to the z-value? I know it can be done a lot of other ways as well, but stapling the content in z-direction gives me a fast visual feedback of who the output should look like; what i dont like is the concept of photoshop or illustrator, where the drawing order is mainly linked to the order of the layers, thats quite a handicap for architectural drawings, because i need my layers to be arranged “content sensitive” so sticking to the materials for example, and i dont want to change my layer order to fit the drawing order; the real problem of all this vector drawing problems occuring is the industry itself, right now im working in 3d/IFC with visualarq, that produces the documentation pretty fast, but other planers participating in the current project still use a 2d vector based workflow, so ive to deliver 2d vector drawings, so i cant really use a contermporary workflow of: ifc 3d model and documentation/2dplans in pixel graphics; printed out on the construction site, no one knows if it was a pixel or a vector in the pdf container….. so ive to fiddle around with the vector drawings… and this specific topic is the only thing about rhino that drives me a little bit mad, on the other hand nobody really needs this features anymore, but again: most of the bueros still use *.dwg/dxf exchange; thats an annoying fact, because outputting IFC’s with visualarq and building parametric objects from grasshopper is just great and joyfull, aslong as it stays 3D; anyway, have a nice day..
HI Jakob -
That is [mostly(*)] how it has worked all the time.
I’m not sure from your post if you are reporting a bug with this workflow?
At any rate:
(*) curves are drawn towards the camera to ensure that they stay on top of the display meshes of non-flat objects in shaded modes. The distance that those curves are pulled towards the camera depends on the scene. When you have enough z-separation between your sets of objects, this is unlikely to cause issues.
Apart from that, new in the Rhino WIP is that, when you print to vector PDF, you can opt for a sort order by object type instead of the sort order by layer. This way, you are not forced to change the layer order based on vector output requirements.
-wim
I just did this to organize the drawing order:
Problem is that right now im working combining visualarq and worksessions and the visualarq drawings (2dplans) are actually one block definition, so that can cause some issues; Right now i got some 2d drawings coming from visual arq, generated from a linked model (via worksession), combined with data coming from interior architects, hatches and so on xD; The 3D Model is quite complex, so i want to keep all annotaions and stuff from beeing in my 3d model, as well as the stuf coming from external participants… but for now the grasshopper patch should work for me, with a little help from raven ai it took me a few minutes…. And well im reporting a bug, because all of my different data coming together in the worksession is layerd in z-direction, and this works for ratered pdf, but not for the vector drawings; But i guess this is not just a simple BUG to fix, thats a chain of events that can be caused by so many variables that is simply try to get the drawing order static, and thereby fixed; Thanks for your answer!
Hi Jakob -
To report a bug, please submit the files that are required to reproduce the issue on our machines. If files are not possible, a detailed description of the workflow is the bare minimum.
-wim
I cant do this, its current work, and a detailed description would cost me like half a working day; But this little thingy fixed my issue pretty good, and i would simply like to get properties for each layer, to set its drawing order value; It seems that the drawing order is simply defined by numbers, so less is under and more or greater is up; so why not add a simple input box to each layer, to set the drawing order order of each object on a current layer? Works quite good for me right now. Really i would like to report the bug in detail, but its not only a rhino bug, visualarq is involved and so on…. i just want to report my little solution for further, posssible improvement, because setting drawing orders without any feedback is just the way i worked when i was 15, in freehand mx.. and that was an awsome programm, but well, things moved on xD
Greetings from NBG Germany! Make Rhino even greater xD!