Controlling Display Order

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!

3 Likes

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.

-Pascal

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.

4 Likes

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?

1 Like

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.

4 Likes

@ Pascal Golay

BoardB.3dm (4.8 MB)

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. :nerd_face:

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.

-Pascal

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.

2 Likes

Not sure if this has been posted already.
A solution could be adding an attribute “Display Order” like in Microstation?Screenshot 2021-02-10 18.46.09

5 Likes

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.

@Ben_B

1 Like

Any development on the Draw Order issue? I have a suggestion, make the draw order reflect the order of layers like in Photoshop, I think that would be intuitive for anyone drawing in 2D.

2 Likes

absolutely agree, such an basic feature! Something I’m personally waiting for since Rhino SR3. Also all the issues with hatches inside blocks, which are impossible to control. Unfortunately no improvements here at all. would love to see people from rhino take this a little more seriously. For me the integration like in microstation, which was suggested above, makes the best sense.

1 Like

I think in theory it already does. If you start a new drawing, make 2 overlaying hatches on 2 layers and swap them around the draw order should change. But I’ve also had trouble with this in layouts, especially when using blocks.

1 Like

I think Mcneel have already acknowledged that DrawOrder doesn’t work with blocks. It even appears to ignore the DrawOrder that’s set within the blocks (when viewed from outside the block), from what I’m seeing.

Setting DrawOrder by means of the Layer order is a clumsy solution. For one thing it’s not granular enough; it wouldn’t allow precedence to be set for objects on the same layer, for example. Another is that if new layers are introduced or Layers have to be reorganised for some other (unrelated) reason, it’ll upset the DrawOrder and that might be overlooked if more than one person is working on the file. It would however be an improvement over the current DrawOrder toolset.

just use top view and z+ on objects above, can use gh to sort objects by whatever