Controlling Display Order

@ 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

Yes please add a feature that control display order in some kind of way. I desperately want to use Rhino as my only drafting/modeling tool but this display order issue is making it seem difficult. I’m trying to clean up a plan that was cut from a 3D model using Visual ARQ. The plan comes out as a block and I don’t want to explode the block because I want to refresh it as I make changes. There are parts of the plan that I want to mask over but it’s impossible. Covering up those areas with a solid white hatch doesn’t work because the black lines show through it. I can BringToFront the hatch, but then I would need to do that for all the details lines and other hatches that I plan to put on top.

PLEASE PLEASE PLEASE add this feature. We’ve been asking for it long enough

1 Like

Hello- please start a new topic from scratch describing what exactly it is that you need to accomplish with draw order.

-Pascal

I just need what everyone else has been saying – a system for organizing 2D objects that occupy the same location on the Z axis. The current system is not robust enough because there is no way of knowing the order of object relative to others, so it is very easy to lose track of the order.

1 Like

Here are a couple of scripts that might help -

This one just prints the display order of a selected object. By default newly-created objects have a display order of 0, higher numbers display in front of lower numbers. Negative numbers are also allowed.

PrintObjDisplayOrder.py (350 Bytes)

The following script allows you to set an object’s display order number directly. It also gives you the object’s current display order and optionally allows you to select some other objects and will indicate the min-max range of those objects’ display order.

SetObjDrawOrder.py (1.6 KB)

5 Likes

Thank you I’ll test these out!

So, here is another thing to try…

I tried to concoct an on-screen, real-time way of seeing what the display order selected objects is and then being able to change them (one-by-one). Run the script, select the objects - limited to curves, dimensions (including leaders), text and hatches.

I tried to put the text dot indicating the display order of the objects in a logical place on the object - but that’s hard to decide. For curves, it’s the midpoint, dimensions and text it’s somewhere near/on the text. As hatches could be any shape, I put the dot somewhere on the outer border. Right now the dot color is fixed at a light gray with black text.

The procedure is just to select everything you want to see the display order of and Enter, dots will show up on the screen with each selected object’s display order. 0 is the default, the numbers (integers) can be either positive or negative. The display order is from largest to smallest (smaller numbers behind larger ones).

Once the dots are up, you can re-select any of the originally selected objects (but nothing else) and type in a new number for it and hit Enter. The object’s display order should update on screen. You can continue to pick objects one by one to change the display order. As soon as you hit Enter without selecting anything or hit Esc., the on-screen display should disappear and the script will terminate.

Please note that changes are made immediately, so hitting Esc. while in the script will not undo any changes you already made during that run. However, Undo will undo all of the changes at once.

I just did this out of curiosity to see if I could actually make something that works as well as a way to learn more about dealing with a “heads-up” on screen display. Perhaps to be considered as a protohacktype for a future native Rhino function. FWIW…

SetObjDisplayOrderOSD.py (4.4 KB)

3 Likes

Hi all,
if display order exists already as hidden object property, why not just add it to Properties panel?

thanks!

Disappointing a feature like what @luca4 mentioned hasn’t been added in Rhino8.

The best solution for this I have found is to just use the z-axis in top view to separate the layers but haven’t found a solution to combine them again in a readable order.