Design Layer and Sheet Layer Hierarchy

[ericjhberg]

We are facing a couple of issues with implementation of Project Sharing. As landscape architects, with previous versions we would create separate files for each different plan set (i.e. hardscape, demolition, irrigation, planting, etc.) and reference them together with referenced viewports. This allowed multi-user to work on the same project at the same time, but just on different aspects.

With Project Sharing, I can see the benefit to having everything together in one project file and checking out design layers/sheet layers for other users to work on; however, the issues we are facing are as follows:

1. Because of our use of multiple design layers to separate information, the list of design layers in one combined project file will become too cumbersome, often hundreds long. It would be great if there were a way to create 'folders' for design layers or a hierarchical system similar to that used in classes. This would streamline the document organization into information sets (i.e. Hardscape-, Demolition-, Irrigation-, Planting-, etc.). We would still need to maintain proper inter-mixed stacking orders though. I could also see the same being very useful for sheet layers, essentially creating sheet layer folders for varying plan sets.

2. File size. Some of these files, when combined into one Project File will be enormous. Considering our varying workstation situation, I can forsee dramatic problems with file loading, crashes, and update times. This is a general issue Vectorworks needs to address in order to compete in the growing data-rich, 3d, BIM world. We have top of the line workstations that still struggle with the complexity of some of these large project files.

[Christiaan]

1. Because of our use of multiple design layers to separate information, the list of design layers in one combined project file will become too cumbersome, often hundreds long. It would be great if there were a way to create 'folders' for design layers or a hierarchical system similar to that used in classes. This would streamline the document organization into information sets (i.e. Hardscape-, Demolition-, Irrigation-, Planting-, etc.). We would still need to maintain proper inter-mixed stacking orders though. I could also see the same being very useful for sheet layers, essentially creating sheet layer folders for varying plan sets.

I recently asked for something similar for the same reasons. Something we love to do is flick through levels of a building model (using the keyboard shortcut command-up and command-down). The more we split information up onto the separate Design Layers the better Project Sharing becomes, but we increasingly lose this ability to navigate building levels easily. In this respect we may need some kind of new design layer visibility column, some kind of "active group" visibility + hierarchical display.

2. File size. Some of these files, when combined into one Project File will be enormous. Considering our varying workstation situation, I can forsee dramatic problems with file loading, crashes, and update times. This is a general issue Vectorworks needs to address in order to compete in the growing data-rich, 3d, BIM world. We have top of the line workstations that still struggle with the complexity of some of these large project files.

Agreed. One thing we're doing to mitigate this is something we've always done which is to separate out Sheet Layers from the model file. So our Project Sharing files generally only contain Design Layers. We then WGR the Project Sharing file to create separate files for plans, sections, elevations and schedules (in your case hardscape, demolition, irrigation, planting, etc.). Essentially we've adopted the new way of working in teams for the model (Design Layers)—in fact all our projects, big or small, are now Project Sharing files—but we're sticking with the old way of working in teams for presentation (Sheet Layers). There is the file administration overhead, which is an ass, but it works reasonably well other than that.

[ericjhberg]

Thanks Christiaan, I think the workflow suggestions are worth exploring as a mitigation of file size and operability.

The Hierarchical or Folder organization is absolutely critical for us. We often experience Irrigation files that can contain 50+ design layers. Even before Project Sharing, this was often cumbersome. The ability to clean up some of this clutter and better streamline and organize design layers/sheet layers is a no brainer.

[Christiaan]

No prob. One suggestion: keep your Section Viewports in Working and Project File. I'm having quite a few problems with Section Viewports in WGR files and it's very difficult to deal with when you're the minimum time between updating model and seeing the changes in your section is 2 minutes:

1. Update model in Working File

2. Save and Commit to Project Sharing file (30 seconds a layer)

3. Update WGR file (70 seconds)

4. Update Section Viewport (20 seconds)

[Razzman]

Something I've always wondered. In the Design Layer Navigation window, is there anyway to group, expand and collapse Layers? AutoCad lets you do this when I import projects.

Even graphic programs like Photoshop has a similar method to organize layer after layer. I look at that window now and it's one long list.

[Art V]

Not yet, I have requested hierarchical layers (similar to hierarchical classes) through my local distributor. Maybe you could do the same, the more people requesting something like this the better the chance for it to be implemented.

A temporary workaround could be using saved views, that way you can quickly turn sets of layers (and classes) on and off, similar to layer states in AutoCAD

Edited March 29, 2016 by Art V

[MSLD]

Is there a way to set a hierarchical view in sheet layers? For drawings with over 100 sheets, it's a pain to scroll through everything. Is there a way to minimize non-active sheet layers?

 

[PVA - Admin]

Not currently, however there is a wish for this here, which I encourage you to vote for via the widget at the top left of the original post:
 

 

[PVA - Admin]

Combined a number of similar request threads on the issue, upvoted as well!

[Art V]

Upvoted too, thanks Jim.

[Jim Smith]

On 2015-12-07 at 5:12 AM, Christiaan said:

 

 

Agreed. One thing we're doing to mitigate this is something we've always done which is to separate out Sheet Layers from the model file. So our Project Sharing files generally only contain Design Layers. We then WGR the Project Sharing file to create separate files for plans, sections, elevations and schedules (in your case hardscape, demolition, irrigation, planting, etc.). Essentially we've adopted the new way of working in teams for the model (Design Layers)—in fact all our projects, big or small, are now Project Sharing files—but we're sticking with the old way of working in teams for presentation (Sheet Layers). There is the file administration overhead, which is an ass, but it works reasonably well other than that.

Our projects tend to be smaller so we've not yet used Project Sharing. We have been short listed for a larger project and would have to implement Project Sharing protocol. I'm not sure where your Sheet Layers "Live" for producing your drawing set. I think I follow that the Model is the "Master File" where all the Design Layers live.  Do you mean that  Sheets only live in the Referenced files; or do I have this backwards? 

[Christiaan]

Yes, Sheet Layers only live in the referenced files.

 

However, since then, we've done a turnabout and we now try to keep everything the same file. We only start splitting into multiple files if the project becomes big enough to start slowing VW down.

 

The reason for this is partly to do with the inconvenience and some historic bugs relating to WGRing, but the straw that broke the camels back is that Edit Section In-Place only works if your Section Viewports are in the same file as your model Design Layers.

[ericjhberg]

Just now, Christiaan said:

We only start splitting into multiple files if the project becomes big enough to start slowing VW down.

 

The reason for this is partly to do with the inconvenience and some historic bugs relating to WGRing, but the straw that broke the camels back is that Edit Section In-Place only works if your Section Viewports are in the same file as your model Design Layers.

 

We have been doing the referenced sheet layer file approach for awhile but haven't ventured into project sharing yet...mainly for the two reasons mentioned in the original post.

 

@ChristiaanHave you found your new all-in-one approach to be better/faster than the old referenced technique? I ask because although I could imagine all-in-one file sizes to be much larger, they may in fact be faster and easier to use because of the seeming cumbersomeness of references.

 

I also find it amazing that these workflows are not fully considered when developing tools like Edit Section In-Place. For one feature of the program to completely drive how you use it is frustrating. Plus, the only way to find this pitfall or "straw that broke the camels back" is to completely go down the road and then realize the lack of functionality...then have to reverse course and rebuild.

 

Unfortunately Edit Section In-Place is only one of these issues we uncover. There are many more that affect best workflow practices that I hope VW can consider. They include, but aren't limited to,

• VW2018 Titleblock Styles - Still unsure how these are truly used in a referenced file project workflow
• Detail-Callout Markers - Forces detail viewports to be in the same file as the plans/model
• Worksheets - Many incapable of determining information when attempting to pull through Viewport References. This forces the worksheet to appear in the design layer/model file and be referenced into the sheet file.

 

We have been struggling with this issue for a long time and I still haven't ever gotten a straight answer of how the one-file approach is supposed to work in regards to extremely large files and potentially hundreds of sheet layers and design layers. Hoping to get a better answer someday.

[Art V]

23 minutes ago, ericjhberg said:

We have been struggling with this issue for a long time and I still haven't ever gotten a straight answer of how the one-file approach is supposed to work in regards to extremely large files and potentially hundreds of sheet layers and design layers. Hoping to get a better answer someday.

I tend to put everything in one file, but that is more out of practical purpose as I need to split imported layers into show/not show/sometimes show parts without affecting classing as well has having multiple options with common bases etc. where referencing wouldn't be that much more efficient. I only reference items for which it is very unlikely I need to modify them.

 

It's an example I've mentioned before in the past...at some point I had a file with (rounded) 1,500 classes, 50+ design layers and at some point 100 sheet layers before trimming down on sheet layers in the final document and close to two million objects. VW was very slow but did not crash. AutoCAD wasn't that much faster anyway at that point but it was less efficient to work with than VW. So I don't see much of a problem with a single file workflow and it saves the hassle of referenced file management.

 

It all boils down to the software being able to handle large amounts of data/objects efficiently before slowing down, and generally AutoCAD and the likes used to be better at that than Vectorwork, though Vectorworks has improved a bit with VW2017 but with VW2018 it remains to be seen how it will eventually turn out. This is probably an area where VW could use some additional improvement, so that working with large files is no longer an issue other than from document structure perspective.

 

The only downside is that the backup files will be large to, so it does consume quite a bit more disk space than a small(er) working file with referenced files.

[Jim Smith]

In our world we tend to have two or three separate files that are part of the project that have been referenced out & are basically stand alone files. A cover page, the reference info is a symbol of part of our title block as the cover often has a scan of a hand made concept  illustration - so including the image in the master file makes VW grind to a crawl. The other one or two pages are site plans as we have to use Metres with 2 Decimal points and our plan sets are generally in mm (with occasional Imperial dual dimensions). 

[Christiaan]

17 hours ago, ericjhberg said:

@ChristiaanHave you found your new all-in-one approach to be better/faster than the old referenced technique? I ask because although I could imagine all-in-one file sizes to be much larger, they may in fact be faster and easier to use because of the seeming cumbersomeness of references.

 

It's superior in every way except if a file gets so big that navigation and modelling become cumbersome. There comes a point where you have no choice but to break the file up (you'll know when), but we've only reached that once, and that's because we're dealing with a model the size of Oxford in the UK. Every other active project we have are all in one file and happier for it.

 

17 hours ago, ericjhberg said:

I also find it amazing that these workflows are not fully considered when developing tools like Edit Section In-Place. For one feature of the program to completely drive how you use it is frustrating.

 

I understand, I often have these complaints, but if you were head of Vectorworks development and you had a choice between releasing Edit Section In-Place or waiting another year or two until it was compatible with WGRing, what would you do? I don't think the answer is always obvious. Resources are limited, so adding all desired features and improvements at once would break the laws of nature. Therefore compromises always need to be made. All things considered I'm happy that Edit Section In-Place was added to v2018 despite it not working with WGRed files. Edit Section In-Place has turned out to be one of our biggest time savers (despite it being slow to enter and exit the mode)

 

In fact it pushed us to have another go at keeping everything in one file and that's saved us a lot of time compared to managing WGRs.

Edited January 16, 2018 by Christiaan

[ericjhberg]

Thanks @Christiaan. Regarding all-in-one files, that is similar to our testing and what has forced us in to the referenced file workflow. We have a few of those very large projects you speak of and we haven't been brave enough to put them into one file.

 

4 hours ago, Christiaan said:

I understand, I often have these complaints, but if you were head of Vectorworks development and you had a choice between releasing Edit Section In-Place or waiting another year or two until it was compatible with WGRing, what would you do?

 

I don't think the question is whether or not the tool should be released. My biggest problem with this tool, and several others for that matter, is that there is no support or documentation that would help the user figure out that it doesn't work in a particular workflow type. It's as simple as releasing some basic documentation that would state, Edit Section In-Place does not work through viewport references. Instead, you are forced to figure that out on your own, and too often waste the time finding out that it won't work. Also, your assumption is that it will someday work with WGRing. There hasn't been a lot of support or tools that have been developed to support WGRing workflows to date, and I doubt the engineers are spending time trying to figure this out.

 

This workflow based discussion is pretty basic. It's the starting point for the practical use of the software. The first question I have to answer when building a project is All-in-one or WGReference, and if I choose WGReference, there is no support to tell me...wait a second, that means you can't to this, that, this, that... Honestly, much of the time I wonder how in touch VW is with their users and how they actually use the software.

 

The much bigger question to me here is workflow. It is pretty obvious that VW sees the future in the all-in-one approach, and for most projects, most users, that approach probably works fine. We may be on the outside of this discussion in having projects that are so large that (referring back to the original post) they contain hundreds of design layers and sheet layers and the file sizes quickly explode. It is my hope that VW tries to become more competitive in this large project arena and try to mitigate these circumstances.

[Christiaan]

Ah yes, I see what you mean, knowing about the imitations of Edit In-Place ahead of time would certainly have saved me some time and headaches.

 

59 minutes ago, ericjhberg said:

Also, your assumption is that it will someday work with WGRing. There hasn't been a lot of support or tools that have been developed to support WGRing workflows to date, and I doubt the engineers are spending time trying to figure this out.

 

Yes, that's my guess too. That assumption was just to illustrate a point.

 

1 hour ago, ericjhberg said:

The much bigger question to me here is workflow. It is pretty obvious that VW sees the future in the all-in-one approach, and for most projects, most users, that approach probably works fine. We may be on the outside of this discussion in having projects that are so large that (referring back to the original post) they contain hundreds of design layers and sheet layers and the file sizes quickly explode. It is my hope that VW tries to become more competitive in this large project arena and try to mitigate these circumstances.

 

Yes agreed. I know that they are interested in seeing files that push all-in-one to its limits, so if you have files that like that send them to VW and tell them what the problems are. Come to think of it I must to that myself too.

[Grethe Connerth]

A folder hierarchy would be so helpful !!!!

It definitely got my vote.

[Matt Overton]

If this is going to happen sometime.... It would be great if there was an option to auto group all layers with a storey association together.

[phin]

Seven years on and we still can't organise the basic building blocks of Vectorworks?

[Matt Overton]

18 hours ago, phin said:

Seven years on and we still can't organise the basic building blocks of Vectorworks?

Also Project files are still large and can bring good hardware to a crawl. Too many things still block the main thread. Dividing up a project to WGR still takes too much time to do, when as it should be encouraged as a way of improving workflow. Viewport Styles which might help some of these has languished on the roadmap with no progress since the day the roadmap was published. 

 

Hopefully the lack of visible action is a sign of a larger background project.... but I doubt that. Teamwork has never been a thing the company has improved with passion.