It’s already v6 now, 3 years from the first post in the thread…
And the draw order is still not functioning - it’s impossible to control the draw order between blocks and other elements.
Please solve it. It is such an essential feature!
It’s already v6 now, 3 years from the first post in the thread…
Hello - you could be the first one in the thread to actually supply an example file - you won’t get a medal, but that would be the best first step in troubleshooting.
Ok, so I was able to recreate one very basic issue in a matter of seconds.
I think you don’t even need any example file (anyway it’s in the attachment)
Precisely: Try to use BringToFront command on the block (hatch A) so that this block is displayed in the front of another hatch(B). Impossible.
1808121330-draw_order_problem.3dm (36.6 KB)
Another one, this time no blocks involved.
A simple task - make this:
using two commands only: BringToFront and SendToBack,
within this file:
1808121950-draw_order_problem-2.3dm (44.2 KB)
Or am I doing something fundamentally wrong?
Hello - here, the dot hatch does not display at all. If I switch the hatches to ‘+’ I can manipulate them as needed, so far…
Thank you, so it seems that we unintentionally touched another issue which is the dot pattern. Discussed here:
Problem printing hatch. Am I right? Can you somehow coordinate it with John Brock to see if the problems are connected and will be solved in SR9?
The thing with dot pattern is that you can’t really replace it with any other pattern that I know, because they do not behave in the same way during scaling. ‘+’ pattern is not really a satisfactory workaround.
Now I realized, that display order issues concerning blocks are present also in other threads, since a long time (at least 3 years now!), so I doubt it is worth to send another files and go through it again.
What I can do to contribute to the discussion is advocate for top-priority when it comes to solving all the display order bugs. All three threads have over 5,5k views now, which seems to put it (correct me if I am wrong) in top-10 bug-related threads ever.
After all Rhino has a great potential to be treated as a serious drafting tool! Please announce it once it is solved, I will happily be back using the software. Looking forward to see the change soon!
Hello - the printing problem appears to be fixed, but display, here at least, seems broken with the Dot hatches. I’ve asked some other techs to confirm… since it could be machine/card/display specific, I suppose.
good to see the discussion continued here, thank you for still keeping it alive
This is similar to how vectorworks utilizes their system of layers and it would be big help to be able to assign draw order to layers, I am struggling at the moment with 2d drawings as whatever I draw that’s new seems to always go to the back instead of to the front.
So I’ve been using a work-around that’s similar to a “display order” idea. As long as you are working in parallel view, you can pull the hatches (or other objects) closer towards the camera. For example, in plan, you could switch to elevation, pull the geometry above, and switch back to plan. This way, you can use elevation as a sort of draw order and use tools like align (bottom) to keep things really organized. This way totally circumvents any draw order commands. The only exception to this might be white hatches, which vary in success.
Let me know if this helps!
What happens when you export the resulting file to something like ACAD LT?
Based on my workflow I just plot to PDFs from Rhino. If i was exporting to something else I would likely do a different workflow, likely not hatching in Rhino whatsoever.
Being new to Rhino I could not understand why some of what I drew appeared or disappeared at random. It was finally traced to the fact that the Layer Order did not affect the draw orders I was used to from other packages.Whilst I can understand that with 3D work, where the draw order can be ascertained from the item position, it makes no sense in 2D work where it quickly becomes impossible to keep track of draw order especially when there are large numbers of layers. Please bring in a switch in the Layer menu to turn on or off the draw order of the layers.
I’ve included three attachments (two screenshots & a Rhino 7 file) explaining the display order issue as I’m experiencing it as a graduate student in architecture.
I’ve set up gridded construction lines in the Construction Lines layer (red), which in the Panels: Layers appears to be below/under the Walls layer (black). However, after drawing my box on the Wall layer, using those Construction Lines as my reference, when I finish drawing the box, those black lines are not visible anywhere.
To make them visible, I need to go the step of selecting the box and entering BRINGTOFRONT.
One time? Not a big deal. However, replicate this across a 40 hour project, and then across multiple projects, and it makes work flow less effective.
Hopefully I’ve clearly articulated an issue that I’m not alone in experiencing. Thank you for taking the time to consider our feedback.
Hello - yes, I understand the problem. Currently layer order does not determine draw order.
-Sellayer Pause BringForward SelNone
may help ease the tedium for now.
This sums up what is wrong with the current set of commands. I hardly use the BringFoward or SendBackward commands at all.
BringForward - of what?
SendBackward - of what?
The user can’t control that and worse still, the logic driving how Rhino makes those decisions isn’t exposed either, so it’s impossible to work around it as you can’t predict how it’s going to behave. The best one can do is stick to BringToFront or SendToBack and hope that Rhino remembers the sequence in which items were picked/ordered. The command set really does need to be brought under control in a way that’s evident to the user.
Not sure if this has been posted already.
A solution could be adding an attribute “Display Order” like in Microstation?
Yes, thanks Pascal, I definitely make frequent use of those commands.
One other thing – you’re probably already aware – but when I use the BringForward or BringtoFront command, and then I Join or Trim that object, 30-50% of the time I find myself searching for it because it’s gone back in the draw order. So I end up needing to repeat the BringForward or BringtoFront command.
Have to agree with @luca4 display priorities are essential in my opinion.
Why the current system is problematic:
- difficult to keep track of the relative places of things
- Display issues once there are many competing hatches etc. (as mentioned by others)
- Constant repetition of the command to get results.
- If I draw linework on the face of a 3d box for instance, and then bring to front, the linework is always visible in front of the entire box, even when viewed from underneath ie. the linework isn’t occluded by the other face of the box.
The Microstation implementation of display priorities is the way to go for me. I don’t know how easy this is to implement, but would make a huge difference.
ps. weirdly on the install of V6 on my desktop the layer order does indeed determine the draw order, when I change layer order, the draw order also changes. It’s amazing! Wish I could replicate it on my laptop R6 and R7 installs…
On work around I have been using is to clear draw order, and raise objects in the z direction in the order that I want to print. This is not ideal, but it is a useful work around.