First, not only is it POSSIBLE, its very EASY. Its not something you actually have to work at, once you have it set up. For the record, every project in our office has every workset set to visible, in every view of the project. We have no issues. The staff (while they dont vocalize it) have been asking me for help with *i cant find this stuff* WAY LESS than when they used worksets. So lets go through your items one by one.

Our Filter is preloaded in to every View template, and its also already turned off in the appropriate views. (All but finish plans). So our users never have to bother with it. Ours Filters by Type names, which makes it easier than having to go through all of the assembly codes that count as Finishes.

Consultants: What consultants model finishes besides architecture? MEP finishes?? Either way, not a big deal. Design consultants and equipment consultants maybe... But its easy enough to spell out in your BIM Execution document. And we tell them all to have all worksets visible globally anyway, since pre-2011 worksets set to Not Visible By Default could not show up in Linked Files.

So Finishes are handled with Filters, and the users never have to touch it. Ever.

We dont use ANYTHING for Transfer of ownership, since... Once we transfer the ownership, our stuff gets vaporized. if i had too, however, a Filter would do it quite simply. We have an NIC filter in place, for when we show equipment in design presentations thats not in our contract, but we want it in the drawings for reference. Theres no reason you cant use the same Filter for this stuff. The nice thing about it is we have a few Filters that search Comments for "contains," so you can have multiple values. Way better than worksets, since worksets can ONLY go on and off.

This is exactly what worksets were made FOR, hence... we use them for this still. But it has nothing to do with VIEW control. We selectively load and unload worksets all the time. In fact, we dont use the Default "Last viewed" setting you talk about, since that is an option we select when making a central file. We have it on Specify, to demand that users select worksets every time they open the file. When youre doing a Worship Center with 6000 seats in it, and youre detailing the Vertical Circulation or the Toilet Rooms, having 6000 chairs loaded and spinning around in the model, is stupid.

Selective loading handles this wonderfully, and since no one ever makes a workset INVISIBLE, we dont have to worry about someone getting something on the wrong workset. It just means it might get selectively unloaded accidentally. But they all get loaded for printing, so we dont have an issue there.

Sorry, but i just dont think this is true at all. Its not FAMILIAR, but its not more complicated. Being organized is an issue regardless, and i havent found anyone squalking at the number of Filters in our projects. FWIW, our views ALL start with about 15. Healthcare adds a couple more for specific Equipment they load in the projects.

The other nice thing is that since Filters are hierarchal, you can put them all in one view and move them up and down to see what conflicts exist between the different filters, if any.

Also, since we do it all with View Templates, and every Filter basically gets put in every view (Since a filter with no overrides and set to visible doesnt do anything), and every view gets view templated, its very simple to have that "check view" that you talk about.

Plus, since we put them all in every view, it never looks like a guessing game. The Filter tab all looks the same.

The downside is still Selective Loading. You cant do it with Links, and Manage Links is a File Based setting, not a user session setting, so you cannot selectively load links without affecting everyone else. Nor can you shut off parts of the project to mitigate computer performance.

We have some HUGE projects, and one has 65,000 elements just between Mullions and Curtain Panels on the Skin. Theres no way in hell most fo the team needed to load the skin, unless they were detailing or plotting.

So we use them for parsing stuff for selective open. Having said that, yes: On some of our smaller jobs, now that they dont use them, the users have stuffed everything on one workset, and proactively come to ASK me "Do we even need worksets anymore?" Selective Load is really the only reason at that point. If they came up with a more intelligent "Subsetting Tool" worksharing could go completely transparent, as far as im concerned.

I really dont think of it that way. I honestly, in my heart of hearts, dont think the tool was ever designed as a visibility kludge. The fact that those features have slowly crept in (Linked file workset control in VG, etc) is evidence of that. Since Worksharing went element borrowing, ive been waiting for the day Worksets disappear alltogether. Ive asked that question to the Factory (If they will, and any indication of when) and of course there was no response about any future behavior or potential dates of any future behavior, but the logic (solely in my own mind) seems to be that since its NOT a visibility tool, if *the tool* were to change, being tied to it for a crap workflow would really suck.

You really need to have those items set up in your template though. Seriously, i wish more of our users posted here. A few users who were out in the field or on maternity leave have re-emerged, and are loving the way Revit runs now. The Filter tab has consistant items in it, just like VG: Model, VG: Annotations. They simply have to learn which ones are which.

BTW: We keep a view in the model that lists every filter, and what its criteria are.

Now, thats how we do it. Im not going to argue the merits of it in another fruitless debate with people who insist on Worksets for Visibility control. If you use them, and youre happy, good for you. But dont let anyone MIS-speak about them being NECESSARY. I havent done any trickery here. And its not a hassle, at all. I would wager its EASIER to deal with, since now the users can *technically* get lax about workset placement. Id PREFER all 6000 seats be on the Workship Center Seating workset, but if the last 367 of them get mis placed, it doesnt eff up the entire set of documentation, like it used to.

=)

I was thinking of going this route, but I am finding that the assembly code offers some other opportunities.
I can have a filter for "Assembly Code Begins With C30" and I will pick up all my different wall and floor finishes for visibility only.
Then I can have another filter for "Assembly Code = C3010150" that catches ONLY wall tile finishes. This allows a nice trick where the finish wall is really nested and joined walls, and the filter forces those walls to have a projection line that actually matches the line weight and color of the grout lines, rather than the big black line of an actual wall edge. So a very complex tile wall made up of bits and pieces of 5 different Finish Wall Types still looks right. A similar trick is good for complex floors. In School work we often do more "design" with cutting in interesting patterns in carpet or resilient flooring than just about anything else. Being able to do it all with floors, rather than floors and floor hosted families, is rather nice.
Also, I can't filter a Schedule by Type name, so getting a schedule of ONLY finishes with total areas and such is hard. I CAN filter a schedule by Assembly Code, however. God forbid Autodesk ever just makes all things called Filter actually work the same way!

Not so much that the consultants need to have finishes as that they don't need to see ours. In the workset approach they just don't load the Finishes workset when they link. Now they will need their own filter and view template effort otherwise they will be seeing our finishes in all their views, which could get frustrating. Even if all they look at is Course LOD plans they will still see our very complex floors, which can only get in their way I think. Elevations and 3D views become even more of an issue. Do you not run into this at all? It is honestly my biggest fear. I don’t want consultants complaining we are making their jobs harder.




We run into a situation where one whole area of the building is still in flux and the engineer should ignore it for the moment, but the rest is ready for them to take ownership of. And we also find that often we need to do a presentation while the engineer is still working on getting their model up to speed. Almost all of our Focus Group effort happens in DD, when the Engineer is working on their stuff, but before it is done enough to use in a presentation. So invariably there is some stuff that needs to exist in both models for a while, and some that needs to only exist in our model to avoid frustration on their part as it changes literally with every model we post for them. I would love to have a clean break at the handoff, but I just don't see it happening any time soon.




Agreed. In our situation I suspect that 99% of projects will not need selective load, but when it IS needed, we would do exactly this. But at less than 200MB average right now, even 8GB of RAM is enough, and the machines could go to 16. Also, for the average school, even a large high school, there is no one thing that makes sense not to load, other than perhaps the site. I hope to avoid the whole issue of separate worksets for Shell & Core, Interiors, Finishes, Vertical Circulation, etc. The way we staff projects doesn’t support that very well either, mostly because I don’t think worksets work well for breaking a model up into work areas that aren’t spatially split up. For wings, yeah. But we might staff someone on classrooms, while someone else does all the offices and the gym/cafeteria. The heavy weight stuff could be spread over both ares of responsibility. On a really large project with a large team and more specialization then we would shift back to a workset base split.


Yeah, I agree familiarity is the main issue. I will still argue that Filters require two concepts, the Filter, and the Graphic Override. Worksets are simpler. BUT, worksets are more limited. Basically ALL you can do is turn them off as you noted. Filters allow much more control, which is why I say they are more complicated, but also more powerful.







Agree with you 100% there. Worksets are not designed for this, but then nothing else in Revit was intended to address these issues either. So users scream that the tool fails them in very fundamental ways the Factory just didn’t anticipate, and Autodesk just keeps adding features without thinking about the implications with a systems view of the software. Now we have the double mess of two ways to do the same thing, and neither of them a fully thought out solution, just another kludge/tool that kinda works. I think the Factory is starting to see this as a problem, but it will take years to fix.

Gordon

No, we dont have two ways to do the same thing. Worksets ONLY turn stuff off, they dont alter stuff at all. And they arent viable in Schedules either. So at the end of the day, theres really only one way to do it.

Re: The Assembly Codes: <shrug> Seems like a nice way to do it if you want all of those benefits. I go with Type Name because the user HAS to enter a Type Name when they make new finishes, so its a pretty easy sell to get them to include the proper Prefix. They dont HAVE to add an Assembly Code when they make a new type, and working in a Design Build firm, telling designers to input Assembly Codes (for some reason) makes them think im trying to force them to do someone elses work. Granted, all of the Assembly Codes are IN all of the stock walls (and i dont recall if they stay or clear out when we Duplicate wall types), but regardless... Type Name works great for us. Im sure Assembly Codes would work great too.

Re: Consultants: Ive never had a single one complain. Not a single one. In fact, since they now have the OPTION to show or not show them, or to show them ALTERED, ive found some are happier. They may want to kill interior finishes and not exterior finishes, if they have Masonry ledges to worry about. They can override our items, etc. And again- i have to ask: If currently you send models out with worksets set for them not to load, do you do a Workset review every single time you send files out? If not, youre risking something important not showing up. Yikes. But, ive never ever had a consultant complain.

Re: Clean Break: Im just not sure it matters. We do the same thing. Our Healthcare end users (The clients, not ours) are looking at Workbooks with 3d views, elevations, plans, etc, and neither the MEP folks or the Equipment folks are there yet. So one of two things happen: We model it, and when theres catches up we delete ours item by item, or we model it and when theres ISNT caught up it remains. But if i have stuff in flux, i dont "turn it off" for the consultant, i just send them a model transmittal that says *this is in flux, dont mess with it.* Especially since in 2011 it doesnt matter anymore that you put it on a workset globally off, they can see it anyway.

Demand Loading: I have two schemes for workset delineation. Geographic versus Systemic. Most projects fall under one of the two fairly easily, as their PRIMARY method of breakup. "Nonvertical" buildings get geographic, and taller buildings get Systemic. If the project is big enough to require Links, Links get used for the Primary, and the other system gets used for Worksets. If the project ONLY requires worksets, they are whatever the Primary method is. So in your case, a school is more than likely Geographic. So if someone is working on "Classroom wing A" they dont have to load the Gymnasium Wing. Users feed me that crap all the time about "I need the whole thing loaded," and i call BS. I watch them work. They think they need it all loaded because they dont realize they can go in after the fact and close some and open some later. The *only* time you need an entire model loaded is to print.

My computer has 8GB of RAM, and our new ones have 16. I *still* dont load entire projects. Why sit around with my thumb up my behind just because my computer can handle it? Thats silly.

Re: Two concepts: Thats the beauty of them. How many times have you had to explain to a ****** off PM that "its not that simple" because they changed their mind: Instead of NOT showing FFE, they want it dashed. Or halftoned, or whatever. Drives me bonkers. I Love that we can do different things with the filters in different views. For instance: Fire Rated walls. We have 4 filters for them (the different ratings), and those are in every view. As visible, non overridden (so they do nothing). In the code plans they are overriden, even though we use a Fire Tape Model. But heck, users know now that they dont have to make ANOTHER filter to turn them colors in their working views, or whatever.

Heck, i had a user voluntarily make a few filters to turn walls green, to check that the Worship Room of a seriously geometrically complex church, was- in fact- closed. She then cut a plan at every foot from floor to ceiling in the room, to check for a continous green line. Awesome use. (I tried to find the cutaway through the actual room, but cant find it)...

Anyway, those are my thoughts. Time for dinner!

First off, I'm against worksets as a visibility tool. An organized model with organized families and naming conventions can be leveraged through filters. Which then get pushed into view templates. The only use of worksets I use are geographic, a current project has west addition, courtyard infill, and an east additon. These three are on there own workset.

Aaron - If you look at his post he needs another parameter to filter his schedules with. Thats why he is looking at Assembly Codes (correct if i'm wrong Gordon). Whether that be Assembly Code, Type Comments, or a SP, etc.

We use Type Names as well to filter by for visibility. Like Aaron says, its easy for them to enter the prefix convention. Getting somebody to always enter an assembly code I think would be harder to enforce. Really I find that its more about keeping your families and system families properly named with naming convention really leads to easy setup of filters.

Re: Consultants - I think there is enough control in the VG for this now that it isn't a problem.

Re: Clean Break - We are usually ahead of the engineers, so we are modelling a lot of stuff we won't keep in our model. It needs to be shown for the end users (docs/nurses) so we can get sign off for the design. We then delete ours as the engineers eventually put it in their model.

As for "Render" elements, I render in Max so I'm reapplying materials regardless, so thats not an issue for us.

As for things in flux. I use the old fashioned way of phone/email and saying this area is in flux, its not ready for you yet.

Basically, the way do ours isn't that different from Aarons approach. Worksets are used for wings/geographic separation. Filters/View Templates take care of the rest.

The reason we differentiate between geographic and systemic is tall buildings. A 25 storey tall building with a small footprint doesnt efficiently break up by geography. (1st five floors, second five floors, etc. doesnt make sense because the person editing the elevator shafts are doing it for every floor... Hence systemic. Same with Skins on tall buildings. The skin doesnt relate to just one floor, it relates to many of them.

The "tall buildings" are the only time we deal with the Systemic system.

I missed the past about the schedules. I would probably go with Type Mark for it, but yeah... At that point its not much different than AC.

EDIT: I should expand- If i HAD to filter schedules, i would do what you are both suggesting: Go with Type Mark or AC for BOTH... I wouldnt use Type Name for graphical AND someting else for the schedule.

But, we have an entire couple of sheets with schedules of quantities at the back of our template, for our Pre-Con Estimating group. It has a floor schedule that sorts them totalled out by Type, so we just dont bother filtering the schedule, it lists all the types.