WISH -V6 Layer management


#1

The layer hierarchy facilities in V5 have proved essential in complex modelling and I’d like to request an enhancement that would significantly improve workflow in complex layered models: add the ability to assign attributes to layers to provide multidimensional groupings and allow layer selection by filtering on multiple attributes.

Here’s a use case:

I am modelling a building and I start by organising my layers:

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

Initially that’s fine. I turn on a floor and model it. Then another. But later I maybe want to see North wall brickwork for all floors, and nothing else. So I have to pick my way through the layers, turning individual ones on and off. Then again every time I want another combination.

If instead I could assign “Brickwork” as an attribute, “North” as an attribute etc then I could select what I wanted by choosing to show all, and only, layers with the attributes “Brickwork” AND “North”, which would be a lot easier.

(And if I could manage my user defined attributes hierarchically - “Brickwork” being a member of “Building Elements” and “North” being a member of “Horizontal Grid” say - that would help keep attribute proliferation under control).
.


Desperate plea yet again for selected object sees its layer highlighted
#2

Umm, for some reason the carriage returns after each etc in my hierarchy have gone missing. Please make the appropriate mental adjustment when reading!


(Pascal Golay) #3

Hi Constructor- for now, see the layer filtering- the funnel icon at the top of the layer panel- the last item in that menu allows you to set up filtering at least somewhat as you describe, I think.

-Pascal


#4

For those of us who use complex layering and standardised naming, it would be very useful and time-saving to be able to access layer filtering through scripting.


#5

I forgot about the filter in these kinds of cases. It could be helpful, but the parent layers still show up when sublayers are filtered. So it still requires a lot of clicks to get only the North Wall brickwork layers selected (from example above) if there are 100 floors to the building.

I don’t know what the solution is, but it would certainly be helpful to easily select only those filtered sublayers. Or maybe I am missing something!


#6

Hi Pascal,

As far as I can see the layer filtering funnel only controls which layers are visible in the layer list, not which layers are on in the viewpanes. Am I missing something?


(Pascal Golay) #7

No, that is correct but you can select all and change visibility. BTW, LayerStateManager may also be of use.

-Pascal


(Brian Gillespie) #8

This is an interesting idea. I am imagining something like tags on layers - you could tag all the brickwork with “bricks” and everything on the north wall “north”, and all the stuff on the third floor as “floor3”. It seems like all the layers would need to be in a flat structure because of the problem already mentioned with parent layers controlling child layer visibility.

The only advantage Incan see here is that the tags wouldn’t need to clutter the layer names. I’m not sure if this would be an advantage, really.


#9

Hi Brian,

Just to clarify the original wish: I would like to see this filtering directly controlling the on/off state of layers in the viewports, not simply the visibility of layers in the layer list as the filtering in v5 does. To work, it would have to switch ancestor layers on/off as necessary.

I wouldn’t expect it to change the appearance of the layer list (other than the on/off column) as I would expect to need to tweak individual layer on/off states in conjunction. Filtering couldn’t always get me to where I want to be on its own, but it would often be a time saver.


#10

Hi Pascal,

So the v5 work flow would be something like:

  1. select One Layer
  2. filter on “North*” (which will include parent layers)
  3. select All layers
  4. set Property, On
  5. filter on All layers (if you want to see the full list again)
  6. make desired layer active

I haven’t used the LayerStateManager so I’ll give it a try and update this thread with any observations relevant to the v6 wish.


(Brian Gillespie) #11

Thanks for the clarification. I thinking understood your wish - but was figuring that you’d use the layer manager plus tags or filters to first select the layers you wanted to change, then change their state. These selection tools would be useful for not boy visibility but also any other layer property one might wish to change based on the tag or filter state.


#12

I just finished reading this post, and I think that the layer’s tags concept could be awersome. This said, I have some thoughs to share about it. I think the layer’s tags concept should completly replace the actual layers panel.

  1. Instead of having a layers panel, it would be a tags panel. Group layers would be group tag. Each tag could have its own properties (material, line type, etc.). The only big difference is that an object could assigned to more than one layer (tag)…

  2. At least one layer cannot be deleted (current layer). Samething for the tag, at least one tag cannot be deleted which I will name “unassigned” for the purpose.

  3. The tags panel needs to feature the ability to show all of the tags and used combinaisons.

  4. Each tag item in the tags panel needs a new column to add a depth index. This value could be used to determine which tag is over the other in term of display (display order). This way we could sort tag by name without changing the display order. This property should also be available in the object properties, instead of only using “SendToBack” or “BringToFront” commands. The depth index seems to me more “clear” to understand the proper order…

  5. The properties of each object would show the associated tags and offer a way to order them.This way if an object has three tags ordered this way for example, “C1”, “C2” and “C3”, the resulting layer (for comptability like DWG) could be translated as something like “C1::C2::C3”.

Thanks for reading,


(Pascal Golay) #13

Hi Sideprojek=

What would be the consequence of a layer having more than one tag- say material?

-Pascal


#14

In the concept I’ve described more than one tag means more than one material… so rhino needs to know which material to use for display purposes…

I guess each object properties will need more options, let’s say “By Layer”, maybe this could be interpreted as “Use the first tag”, or maybe (posssibly better) allowing the user to select a specific layer for each property.


#15

Hi Sideproject,

You seem to have much higher aspirations than my original desire to have a more efficient way of controlling the visibility of like elements of complex multi-dimensional models in the viewpanes! Could you give us some ideas of what we could accomplish with your vision for the product?


#16

Sorry, I can’t read! I should have said sideprojek, not sideproject. Mea culpa.


#17

I see a disadvantage to applying tags directly to objects rather than layers. We would have to apply (presumably by picking from a list or by typing the name) each tag needed by it to an object - and do that for every object we created. By applying tags to an intermediate group object (currently called a layer) and creating objects in an active layer one avoids that labeling overhead.

I also think that it should not be necessary to apply a depth attribute to every tag value. Depth has relevance to drawing layers but not to, say “north”.


#18

I’m not sure that tags are the answer, seems like they could over-complicate an already dense layer panel.

What about a checkbox option for “Select Filtered Sublayers” in the Show Filtered Layers dialog? When clicking okay with that checkbox, just the filtered-for layers and sublayers would be selected in the Layers panel. Any parent layers would still be visible same as currently exists, but are not selected.

For example, this would allow easily changing the layer color of every Brick sublayer from each floor at the same time without needing tons of selection or deselection mouse clicks.


#19

Tags sound great. Keep the layer panel and its functionality as is. But rather than an object only being assigned to a layer, a tag is assigned to an object, or many tags could be assigned to an object. This is how I have used userdata/objectdata in the past. Maybe this just needs a front end panel with userdata in the background.

There could be classes of tags too, say material tags, direction tags, supplier tags, finish/paint tags, custom tags, bolt/screw/generic fitting tags. This could be used to ensure two competing tags weren’t assigned to the same object.

And then annotation dots could be filled with tag data!

I like this!


#20

This all sounds like there’s a lot of potential in the idea, but it could also go completely sideways. @Constructor, I know exactly where you’re coming from and have often wished for something similar. Here’s my take on it, and let me know if it seems like it would solve the same thing your looking for.

In Vectorworks, (at least the old versions, I haven’t used it in a very long time) there are layers and classes. Classes act a lot like sub-layers, but without being tied to a specific parent layer. For example, you could make a brickwork class and objects could be in the brickwork class but also be in any of the layers, i.e. Floor 1, Floor 2, etc. If you want to see all the brickwork and nothing else, you turn on all of the Layers but only the Brickwork class.

It works similar to the tag idea, but with a built in hierarchy. The issue I see with just tags is that if you start adding tags to everything, you could have an object with 15 tags, and if you need the exact right combination of tags on to see the object, you’d get totally lost.

The hierarchy gives the tag system a little more organization. Maybe it needs more than two levels so it becomes Layer::Class::family::Species… So for an architecture project maybe it would look like this:

Kingdom: (General,) Architecture, Mechanical, Electrical…
Layers: Plan, Section, Elevation, Details
Classes: (Default,) Level 01, Level 02, North, South, East, West…
Families: (Default,) Area, Wall, Floor, Ceiling, Door, Roof, Furniture…
Species: (Default,) Fixture, Level, Centerline, Stairs, Handrail, Elevator, Hatches…

(For those that aren’t aware, I just stole these from standard AIA Layer Conventions, which use hyphens to create a hierarchy. http://www.cadinstitute.com/download/pdf/AIA%20Layer%20Standards.pdf page CLG-43.)

So @Constructor, you could use layer A-Elev-North-Wall-Brick for one wall and A-Elev-South-Wall-Brick for another. Maybe you don’t need that many levels, but for example’s sake it’s there.

Maybe it needs more levels, maybe not as many. Maybe each user could add or remove levels from the hierarchy as they needed. I’m really just trying to illustrate an organization that I think might work. I’d love to hear what other people think about this.