Wish Rh6: Symlink Layers and Mirror Layers

Serengeti (Rhino WIP)
1

Yes, the names “Symlink Layers” and “Mirror Layers” indicates the basic idea.

I often find myself mixing the concept of grouping curves and surfaces into separate layer groups (under separate root layers) and the concept of placing layers for helper curves and surfaces next to each other.

As I see it, there are two basic needs to be met regarding “helper layers”:

  1. Helper layers&lines needs to be easy to hide & show separately from the “final” surfaces/objects.
  2. Helper lines needs to be near at hand at all times while doing the actual drawing.

One approach to organizing helper lines is to group them under separate “root” layers, like so:

  1. Surfaces
  2. Curves

Shared structure - Organized like this, the “helpers” can easily be toggled Off and On, and also cleaned up with just one click. But this approach works best if the layer branches also share the same structure, as to make it easier to find helper curves that belongs to a specific surface layer.

Clumsy - But when a layer structure becomes deep, it also becomes inconvenient to jump between the curve & surface structures due to the UI distance between them. Which leads to helper curve layers being inserted also in the part of the layer structure containing the “final” drawing objects. Thus ending up with layers “littering” the model. Not good.

Classic File Structure Problem

The problem with Layer structures is essentially the same problem as with ol’time file structures on disk; You can place and find a file or folder only in one place in one single structure.

This means that although a file belongs to a certain basic category (represented by its location in the file structure), it may also belong to another category (or structure). For this reason many Operating Systems offer “Symlinks” that can provide multiple references to the one “physical” file/folder, and so one can access a specific file or folder from many places.

Symlink Layers

In a similar way Symlink Layers in Rhino could provide a solution for organizing Layers in a basic structure serving one purpose, while assigning references (Symlink Layers) to those “true” layers from anywhere else in the layer structure as to provide easy access.

Mirror Layers

Another approach, although not as generic as Symlink Layers, would be to have the option of defining any existing Layer (anywhere in a structure) as a “root” of a “master structure”, and from then on Rhino would automatically create a parallel “Mirror Structure” of layers reflecting this Master Layer structure.

The two layer structures would both be “true” layers (not “Symlink Layers”), and the two layer structures would always stay in sync regarding their Structure and the Names. Rules:

  1. Addition - Adding a layer in the Master structure would add a layer with the same name to the Mirror structure, but adding a layer in the Mirror structure would not add a similar layer to the master structure (mirror/helper layers OTOH would be allowed to have non-synced sub layers ).

  2. Root Names - Only the names of the “root layers” would be different between the master and the mirror layer structures (if the two are on the same layer level).

  3. Renaming - Renaming one layer would rename the co-layer in the Mirror or Master.

  4. Deletion - If deleting a master layer, also its mirror/slave layer is deleted (but not the other way around).

  5. Assigning objects - Assigning an object to a Symlink Layer would add the object to the “true” (mirror/helper) Layer.

  6. Attributes - Modifying attributes (color, material etc) to a Symlink Layer would apply the changes to the “true” (mirror/helper) Layer as well (two-way).

  7. Display - Visibility of the two structures would be separated so that they can be toggled On and Off separately. Symlinks OTOH would behave like Block references - hiding the “true” helper layer/original Block also hides it’s “instances” (symlinks). Hiding a Symlink layer would hide the layer, but Show Layer would show the layer only if the “true” layer is visible (enabling to hide the entire helper/mirror structure at its root).

Both

In the best of worlds Rhino would support both Symlink Layers and Mirror Layers (or Co Layers, or Helper Layers or whatever suitable name). Any or both approaches would help immensely in organizing projects.

Now, waddayathink?

// Rolf

2

It reminds me a bit of the discussion on the use of tags that comes up once in a while.

One of the older threads is here:
https://discourse.mcneel.com/t/wish-v6-layer-management/?source_topic_id=36366

3

Good ideas! Adding the third basic feature - Tags - to the layer concept (and filtering according to Tags) would make Rhino layering complete. :slight_smile:

// Rolf

4

I think symlinks might be useful, but it’s hard to tell without testing them before …
Same for tabs … but there’s been talk about different things in that thread.
Pretty confused about mirrors … :flushed:

Anyway what I’d like to see is complete scripting control over the layer panel.
I think that would allow us to build several useful things to make using the layer panel more fast and easy,
or customized for particular needs, and maybe even symlinks, mirrors, tabs, filters etc.

5

“mirrors” would be a “parallel structure” where to place all kinds of helper & support lines which are not actually part of the final drawing. By separating into two parallel layer structures (sharing the layer names) it would be easy to show/hide as well as clean up the model when done with the actual model.

Layer CPLanes

With the reservation that it might already be a similar solution in place, I would also like to be able to assign a unique CPlane to a Layer, with the option that the views would automatically panorate the assigned L(ayer)Plane into focus when selecting a certain layer as the Current Layer (or perhaps, when double clicking it, or some key combination).

With such a solution it would be dead easy to spread out any number of small parts/details to be drawn, over a larger drawing area, with an individual Layer & CPlane assigned to each part. In this way each detail would conveniently have its own “zero center”.

Finally one would copy or make Blocks of the parts and assemble into the whole, using the world coordinate system.

In this way one would have very very powerful ways of organizing, sorting and displaying any complex model in many different ways.

// Rolf

6

Lots of interesting ideas here and in the thread Wim referenced, but I have a more basic complaint.

I don’t make very good use of layers, because I see them partly as a way to control visibility, but the implementation dictates visibility for me.

If I put “helper” curves on a child layer, and then I want to turn off everything except those curves so I can edit them, I would expect to just turn off visibility for all the other layers and leave the curves layer on, but Rhino won’t let me. I have to leave the parent layer above the layer with the helper curves on, and any parent layers above that as well.

I would like to see either a checkbox in options to disable parental control of visibility of child layers, or some kind of over-ride in the layers panel to turn on visibility when the parent is off. I should be able to view any combination of layers without having layers I don’t want to see enabled.

Until then I’m stuck using SelLayer/Invert/Group/Hide to control layer visibility. Clumsy.

7

That would be solved with separate “mirror/helper layers” combined with “symlink layers”. Which means that you can have child layers (symlinks) and turn off the “parent” surface layers (which won’t turn off the true curve symlinked layers)

// Rolf

8

Hi Mark

I never put objects into parent layers, exactly for this reason.
( I also try to make them easily recognizable as parents using a particular color and upper case names )

HTH, regards

2 Likes
9

Same here, as @emilio suggested. It is a good best-practice for files with complex layer structures.

( one long-time wish of mine was the ability to color layer text filed background for even better distinction - that combined with upper-care naming and/or name prefixes would make life easier, too /Photoshop has layer name coloring just as visual cue - helps a ton with files that have 100s of layers…/ )

-j

10

Why is it good practice?

Say I want to put the assembled model on the top layer, multiple polysurfaces that constitute the assembled model on first level sub-layers, component surfaces and curves of each polysurface on second level sub-layers. If all those parent layers have to be empty, where do I put the geometry?

Why should I clutter the layer panel with a bunch of empty layers? So I can spend my time scrolling to find a layer with stuff on it instead of modeling?

To crib from the earlier thread, how would you set up layers for this:

Model
…Floor 1
…Brickwork
…North Wall
…South Wall
…etc
…Insulation
…North Wall
…South Wall
…etc
…Floor 2
…Brickwork
…etc…etc

Just in this snipet that is six empty layers and four with actual stuff, and that is assuming you didn’t want to put the curves and helper geometry for each wall on another sub-layer so you could turn it off when you just wanted the completed model visible.

I’m fine with you organizing your layers in a way that makes sense to you, I just want a tiny change so I can organize my layers in a way that makes sense to me. An options checkbox on parent control of sub-layer visibility would let us have it either way.

11

I think he meant that it’s a good practice given how layers work today, in that hiding one context doesn’t hide the other (because they’re placed on the same level, so to speak).

Given how easy it is to actually develop structures like this (and yes, it IS easy, even simple, especially compared to algorithms manipulating graphics) it really should be implemented over this weekend, and debugged a few weeks after. All of it.

(most programmers having done anything of significance have done more complex stuff than such a structure which we’ve been discussing here).

Your idea of having an option to define a certain layer as a parent sounds very good as well. If I understood you right, you meant with “parent layer” a layer that could be located anywhere in a structure, and being a “parent” would be represented by a property related to visual control?

If so then yes, but that would already be covered by Tags together with Filtering (tags would represent anything you can imagine). The only reason Tags would not be fully covering all needs is that Tags, just like Properties, are not “inherently visible” (at least not unless you explicitly make them so, somehow). For this reason Structures serves as a visible representation of… well, hierachies. But all these ideas combined would make for a very powerful tool for managing complex models.

It’s not a technically a very difficult task to implement. It’s more about significance. And I think the structure of the model as well as it’s helpfulness in supporting different workflows, is a very significant thing.

// Rolf

12

Makes sense.
I agree ( … not only for this particular problem ) :slight_smile:

13

@Mark,

‘Good practice’ in the current state of things, obviously. Basically thinking of Parent layers as Folders in the file system structure that help to keep things organized but hold no content of their own (other than files and sub-folders).

–jarek

14

OT, maybe, but another suggestion to improve the layers window: I think it would be very helpful to move the filter information outside the dialog? Currently using the filter to find a layer by keyword is tedious, requires several clicks, and is a little hidden in the row of buttons.

Pasted image732×453 120 KB
:

1 Like