Emergency Lighting

[BMcCallum]

We are investigating ways to please everybody. I know, huge task. But, we are a multi-discipline firm and everybody deserves to be happy.

Here's the issue:

Electrical and Mechanical have their fixtures and devices and that content needs to be displayed in the Architectural views. However, our Architects aren't always happy with the way that M+E content displays:

Don't want to see emergency lighting shading
Outlets and switches are too big
No air flow indicators on diffusers
Sprinkler heads are too small
Not really stuff we want to, or can, control with sub-category, visibilty parameters or filters.

And, we want a solution that will be:

Beneficial
Efficient
Elegant
Repeatable (thanks Phil!)
To us, this means that it is a solution that benefits all disciplines, is easy to implement and maintain, looks great and will work in linked files and single-model collaboration. Wow, how are we going to do that?

We've been down the road of adding Generic Annotation or Generic Models as nested families in the M+E content then controlling the display with sub-category but it just doesn't work in every situation. Plus, it adds a fairly high level of complexity to the views for each discipline. We'd have to configure additional View Templates to control the display of those items in each view. To make matters worse, sometimes we override the display of those links so now we'd have to control the sub-category By Linked View and By Host View. Just too much to go wrong.

My thought: we have to agree. Gulp. Yup, we all have to get along.

For all disciplines, can we agree on Medium detail level? We can all use Coarse and Fine for our discipline-specific views but Medium will be where we get together.

Electrical has traditionally shown emergency lighting plans with solid fill hatch patterns. Sorry, we can't put them on a sub-category and can't control a visibility parameter through a linked model. Again, it needs to work the same in all ways. Maybe you can use a different type mark for those ones?

And Mechanical, those tiny little sprinkler heads are too small to see on the plans. Can we use a generic model so they always show as 300mm circles?

It will be easiest for us to agree internally and we've begun discussions with external consultants. As prime consultant, it will be easiest to make these decisions early in the project. There will be some long faces when we try to make these changes to a project in the late stages of construction drawings.

I think this will be best communicated in the BIM Project Execution Plans at one of the earliest meetings.

So, what is everyone else doing?

[BMcCallum]

We've started the process of updating the consultant family files so they display properly in Medium level of detail. These updated family files will be sent to the consultant so they can review the changes and update their files. We'll see the results the next time we get updated files from them.

I'd still like to hear what others are doing for the same situation. I'm sure we're not the first to go down this road.

~B

[SamuelAB]

How about a line type for ARCH and a linetype for MECH. You would have to draw the annotation twice, but you could easily control which one shows up on the drawings. All arch templates would have MECH turned off and all mech templates would have ARCH line turned off.

You could also have it that mechanical views see sprinkler geometry while architectural views see the annotation. For switches, arch would see the 3d model and mech would see the annotation. Not sure why arch would even want to see the switched on their own drawings.

[BMcCallum]

Hi Samuel, it's not just lines, otherwise we might be able to control the display with sub-category also.

In some cases the Architects don't want to see the actual object, just a representation of the object. For example, sprinkler heads are too small and some PTZ cameras are too big so they've asked for a 300mm radius circle. Sprinklers will get a filled circle while the cameras would get a 'C' inside the circle.

You're right, the Architect doesn't usually want to see the switches and receptacles in plan but they do want to see them in elevation.

[SamuelAB]

Hi Bruce,

I am uncertain as to how you would use sub-categories to hide or show elements. I would be curious to know how this is normally done.

In your previous example, using line types (arch and mech) I would use ARCH lines for the sprinkler and camera circles that the mech people do not want to see. Same thing with the emergency circuit filled hatch (I've seen people using tight lines as hatches).

For switches/receptacles, I would use the 3d model for arch and the mech lines for mech.

[BMcCallum]

VG can be used to hide by sub-category. We considered this option because it would work on linked models and when the discipline was working in the same file as Architecture.

We don't want to use linetypes because of the extra work involved to coordinate the linetypes and configure the view templates. Ultimately, we have ruled out line types, sub-category and visibility parameters because of the complexity.

IMO, using lines as hatch is reckless. We are talking about a 2 million SF building with many light fixtures. Introducing that many symbolic lines in each fixture could have disastrous consequences. We didn't even consider it as a possible solution.

The 3d model is generally fine for display in elevation. Most of the changes are to do with how these elements display in RCP.

We have landed on the Medium level of detail because of the relative ease of implementation. All we need to do is agree on how the element displays in one detail level. Coarse and Fine are still available to the discipline, Medium is the common ground.

[sbrown]

I think the right approach is an accurate size model, can be simple, then tag the items instead of using the Generic annotations.

[BMcCallum]

Our Architects simply want to coordinate the location of the elements and are not concerned with tagging.

[SamuelAB]

I still think my solution is the simplest for your objective.

You say there is complexity in setting up templates, but it would only require you to modify your temples to not include one element (arch or mech line). If you want a different look by discipline, then you will be required to change your view template no matter what.

The work would be as following:
1-Create two line types: ARCH and MECH
2-Load them into the models
3-Remove them from the proper templates (no ARCH on MECH drawings, no MECH on ARCH drawings)
4-Reapply templates to views
5-Add additional annotation to families using the correct line types (ex: big sprinkler circles for ARCH)
6-Re-load families

[Ning Zhou]

I think the right approach is an accurate size model, can be simple, then tag the items instead of using the Generic annotations.

does tag include any symbols? i mean current "traditional" plan view symbols for MEP dispilines, i like tag approach but ...

[SamuelAB]

Actually, tags is a good way to approach it since you can tag with symbols and it does not change the object under it. I'm not sure if Revit would be able to place tags OVER the objects, I think it may want to try and place them next to the object by default if you use Tag all objects.

[BMcCallum]

The work would be as following:
1-Create two line types: ARCH and MECH


I guess I didn't explain clearly: some of the updates involve text and filled regions. Line type settings are not enough to get this done. Text and Filled Regions cannot be assigned to sub-category.

[Ning Zhou]

Text and Filled Regions cannot be assigned to sub-category.

that's typical case for factory's half-baked "approach", subcategory is great tool but ...

what about selection or filter based on subcategory? or at least in API environment, hope i'm wrong.

[SamuelAB]

What solution did you end up using for this?