The inability to Group Design Layers is a Major FLAW in Vectorworks

[pjs8888]

I find it unbelievable that in this day and age Vectorworks still does not allow grouping of Design Layers!!

Has anyone working on the development of this application actually used it? 

 

We need this ASAP. The software, in my opinion, is cumbersome at best without this standard functionality.

Fix this soon.... PLEASE!!!

 

 

 

 

[pjs8888]

Dear "line-weight"- Good question. This is how I would use the layers. Say I am modeling a table. I would have the top on one layer, the legs on another. I would then group those layers into one group called table. I then group all of  the groups that make up the set into one master group. I can then duplicate this and move each one, keeping that individual heirarchy in each group that is the entire set. At least that is the work flow I am used to. I have been using classes to establish a "line weight" for all my dimension lines, for example. One for construction lines. One for sections, etc. Not much more. But you are saying, I should be using classes like I would layers? The elements of the table, if assigned the same class will be grouped as the table? No matter what layer they reside on?

 

Thanks again for your insight

P

[Tom W.]

5 hours ago, pjs8888 said:

I would have the top on one layer, the legs on another.

 

Why?

 

See:

https://app-help.vectorworks.net/2024/eng/VW2024_Guide/Structure/Organizing_the_drawing.htm#h

https://app-help.vectorworks.net/2024/eng/VW2024_Guide/Structure/Concept_Layers overview.htm#h

https://app-help.vectorworks.net/2024/eng/VW2024_Guide/Structure/Concept_Classes_overview.htm#h

[line-weight]

8 hours ago, pjs8888 said:

Dear "line-weight"- Good question. This is how I would use the layers. Say I am modeling a table. I would have the top on one layer, the legs on another. I would then group those layers into one group called table. I then group all of  the groups that make up the set into one master group. I can then duplicate this and move each one, keeping that individual heirarchy in each group that is the entire set. At least that is the work flow I am used to. I have been using classes to establish a "line weight" for all my dimension lines, for example. One for construction lines. One for sections, etc. Not much more. But you are saying, I should be using classes like I would layers? The elements of the table, if assigned the same class will be grouped as the table? No matter what layer they reside on?

 

Thanks again for your insight

P

 

Have you transferred to VW from something like Autocad?

 

I think you may be using layers where you should really be using classes yes.

 

But I still don't understand why you would put table tops on one layer and legs on another. There's not even necessarily any reason to put them in different classes.

 

Legs & top could all be in the same class and on the same layer, then you can group them together. Or they could be on different classes, and if they are in different classes then as long as they are in the same layer you can still group them together.

[grant_PD]

 I just tried this and grouping between layers moved everything from its original layer to the layer I was active on when creating the group, so I'm not really sure how this workflow is possible.  

 

In any case, I would agree with @line-weight that this workflow seems to work against the structure of VW.  Classes define the object, Layers define the position.  In theater a lot of times Layers can also loosely define "Departments," so there can be an "audio" layer, a "lighting" layer, etc. 

 

I'm not sure what @pjs8888 means when writing that there will be multiple iterations of the design in various places around the venue.  Perhaps an example could help. 

 

The example of the tabletop and legs makes no sense to me.  Unless you were a furniture shop and you wanted different tops to go with different legs?  Even still classes would be preferable there, since you could nest them and control textures etc.  

[pjs8888]

Thank you all. I obviously need to change my workflow in VW. The tools are there, just a different way of doing it. Thanks so much for showing me the light!!

 

P

[grant_PD]

@pjs8888 I did a webinar on scenic drafting for theater/tv, explaining some methods for organization.  It's somewhere in the Vectorworks University.

[pjs8888]

Hi grant_PD,

Looking at one of your webinars, I think the creation of symbols for each scenic unit, is the thing that allows me to move multiple copies around the venue, but allows me to continue drafting in a isographic view. Love that.

It looks like you have each scenic element on a separate design layer. But each piece of each unit is separated by class. I would have done that with each design layer grouped as I am advocating for. Same workflow but different tools to get there. 

Any way, thanks for the thoughts!!

P

 

[grant_PD]

@pjs8888 yes, that's the thinking exactly.  Symbols allow objects to be in two different orientations at the same time, so creating a DRAFT layer with the symbol on it can greatly speed up your drafting time.  Kind of like how a scene shop does not care what the orientation is of the scenery on stage, they build it in the most efficient manner possible.  

Separating out scenic elements into their own design layer allows for groundplans to remain fluid, which they often are.  Could you do it with classes....yes...but isolating layers is much quicker. 

Classes on the the other hand control textures, so if you are going to be rendering that is the importance of classing your scenery.  

[line-weight]

@pjs8888 it's worth also understanding about "container" classes - you can have a collection of objects in various different classes, grouped together into a group, and the group can have its own class. A group can just have one object in it if you want.

 

This means that the objects' classes can control things like texture while the container class can control the visibility of the whole group. Likewise you can put a symbol in a class that's used purely to control its visibility. Doing it this way allows you to have a lot of control over which elements are visible at any one time, without relying on the layer system. I tend to try and keep my number of layers to a minimum but that's somewhat a personal preference/habit.

 

What all this means is that you can have several overlapping methods of controlling the visibility of any object, something you can't do in an application that just has a simple layers system. For example, I tend to use layers to divide building models into storeys. Then classes define what objects are made of *and* what type of object they are.

 

So, one object might be on the first floor, made of steel and a structural beam. I can set things up using a combination of classes, layers and container objects so I can choose to show:

- all objects on the first floor

- all objects on the first floor that are made of steel

- all objects on the first floor that are structural objects

- all objects on the first floor that are structural objects made of steel

- all objects on all floors that are made of steel

- all objects on all floors that aren't structural

- all objects on all floors except the first floor that aren't made of steel

 

....and so on - the list can get quite long.

 

 

Edited December 11, 2023 by line-weight

[Pat Stanford]

@line-weight I think about is slightly differently.  I don't think about "Container Classes" but rather "Container Objects".

 

Symbols, Groups, Data Tags, Certain Plug-in Objects are all "Container Objects"

 

As you stated, the Container has a class but the objects inside the container can have a different class.

 

The "trick" to Container Objects is that for something to be visible, both the class of the object and the class of the container it is in BOTH have to be set to visible.

 

This is why many people try and keep the class of the Container Objects set to None and always have the None class set to visible and never use the Active Only setting for classes.  Unless you are careful, you can end up hiding objects that you intended to see and have a difficult time finding them again.

[line-weight]

5 minutes ago, Pat Stanford said:

@line-weight I think about is slightly differently.  I don't think about "Container Classes" but rather "Container Objects".

 

I guess what I have is "object classes" and these are intended to control visibility per object type.

 

In these classes might be a mixture of simple objects and "container objects".

 

Like so you have to be careful about unintentionally hiding things but if you are deliberate about it, I find it's a very useful way of making visible/invisible things that satisfy two criteria rather than just one. I name my classes such that it's always quite clear whether they are a "material class" or an "object class".

[Pat Stanford]

Lots of different ways to work in VW and lots of different ways to think about things.

 

I try to never say that a way that works for someone is not correct, even if it would not work well for me and the way my brain works.

 

👍