creating views for each workset

I remember back in the days, when it was my responsibility to make sure that models were in good shape at the end of the week. Each week, I would go into my model, create a set of Views, each named after the workset, and isolate only that workset’s contents in the view. That process allowed me to quickly inspect the contents of each workset, and move stuff around.

It mattered because, we had visibility filters setup by worksets, and our consultants would turn off certain worksets that they didn’t care about. So for example we would have a workset called “furniture”, and our Structural Engineering consultants, would kill that workset in all of their views. Problem was that if by accident a load bearing wall appeared on that workset, and was automatically made invisible in Structural models. The more annoying thing was when I had some diagrammatic Floor Plans, that I didn’t want to see furniture in, but, you know, Furniture was all over the worksets, and turning off that one “furniture” workset never worked. It was such a hassle.

Anyways, I wrote myself a plugin for Revit to quickly generate these views, and isolate each workset’s contents so that I can flick through them, and move stuff around if needed. Here’s a Dynamo version of that. It’s quite simple, but surprisingly required a hefty amount of custom nodes to create:

The above workflow is really simple. We first get all Worksets, and attempt to create a new 3D View from the Workset’s name. Once we have that, we go into each View, and turn on/off certain worksets. By turning on/off I mean changing their visibility settings like this:

So the goal, is to only set one Workset to “Show”, and all others to “Hide”. That’s what we do here:

The result is that we get a set of views matching our set of worksets like so:

As always, all of the custom nodes can be found on the Package Manager:

All download files for this post are available on my Patreon page. Please follow the link below.

Support archi-lab on Patreon!

6 Comments

  1. Sean Johns says:

    So what’s the problem with setting the category parameter rather than filtering an entire category of elements?

    • There is no problem. This is a “theoretical” example. Obviously Furniture is a Category, and can be easily controlled via Categories, but other things might not. The point was, to illustrate the fact that it’s important for people to make sure that what they expect to be on a workset is actually on that workset. Let me give you a different example. Worksets, that are supposed to house a linked model. We had a habit of putting just a single Link on a single Workset, so that if you didn’t want to see that link, you just turned off the workset. It’s actually a much better way than unloading a link etc. Anyways, if someone drops bunch of walls on that “linked” Workset, then it’s the same issue. It might get turned off, and all of a sudden things go missing. So the larger point is, this workflow illustrates how to allow people to quickly create views for each workset, and visually inspect contents of said workset.

  2. Mark Mountain says:

    yeah furniture is in a category. why not use that. Ok I get worksets for some items. eg we use it for internal walls and external walls.

    • Please see my response to Sean. I think you guys got hung up on the specificity of the fact that I used “furniture” workset as an example. It can be any workset, with any content, but the idea remains the same. It matters what content is on that workset, and it matters to make it easy to validate that. That’s all this workflow attempts to do. I don’t intend to tell you how to organize your worksets, or how to control visibility for categories etc. That’s not the point here.

  3. Thanks Konrad, nicely put together.
    I will include that in our set of tools + a reporting window listing what is being created with the script.

Leave a Comment