It's a fairly common practice to create separate floors for structure and finishes. The structural "layer" of a floor may actually be modeled by the structural consultant, assuming the structural engineer we are working with uses Revit and isn't working directly in the same model with us (architecture bias in this post).
Architects usually document floor finishes. Quite often I see this done as a Filled Region exercise. The effort required to sketch a filled region is not much different than sketching a floor boundary. The benefit of using a floor instead is that's it modeled and it will be available in many views, as needed. We can tag and schedule them to study and document the design more effectively. External applications like Revolution Design's Revit Workflows offer a specific set of tools to manage creating finish floors very effectively. KiwiCodes offers their own version as part of their Bonus Tools app. These tools make the notion of using finish floors that much easier to consider.
One side effect of modeling finish floors is that they can compromise the door graphics we use, for example the panel and swing we are used to seeing in plan views. This happens because these graphic features are usually created on the work plane of the host level. The other issue is that, even if the floor doesn't obscure the graphics, the door panel, if just lines, probably won't mask the floor finish fill pattern (if one is used).
If we create a masking region (or lines) directly in the door family, to represent the door panel it will mask the floor finish as long as the Draw in Foreground parameter is checked.
Quirkiness ensues if a nested family is used. I happen to prefer to deal with swing graphics as a nested family. My logic is to make it once and use it in many families; a "kit of parts" mindset. Unfortunately the Draw in Foreground setting fails to work when the nested component is brought into the host door family.
To resolve this we need to make it possible to raise the graphics higher. Filled and Masking Regions can be assigned to a Reference Plane; Model and Symbolic lines too. This means we can use a parameter to change the elevation of the graphics, via the parameter and associated reference plane, to compensate for various floor finish conditions. The setting Draw in Foreground will allow this to work as long as we don't check it, which seems counter-intuitive.
In this image I've use the Draw in Foreground setting on native lines and masking regions, not checked on the left and checked on the right. I've also nested a swing family. The red elements are visible and the highlighted (purplish) are not visible except that they show up because I've got my cursor hovering over the family.
To get the nested swing family to show up above the floor is was necessary to not check the Draw in Foreground parameter for the masking region and lines. It was also necessary to place them on a separate work plane in the family that I could control with a parameter to raise it above the floor elevation in the project.
In the image above the only graphics that don't show up now are the bottom left line and masking region. They won't show up because the Draw in Foreground parameter is not checked. It's easy to sort out once you know.
Speaking of 3rd party applications, I used the Revolution Design tool to create floors for my testing. The app coughed when I tried to put in some floors. After looking at the error message I noticed that the doors I was working with don't map a value to the stock Width parameter, they use their own parameter to control the width. This annoyed the floor tool because it's looking for that parameter, the stock "Width". It's hard enough for programmer's to create applications that suit our varied needs. It's even harder when we create content in a different way than what they might reasonably expect in order to complete their tasks.
At first I was a bit confused but then I remembered that their floor tool will create a sketch that turns into door openings to define where the edge of the floor will stop for thresholds. The application looks at any doors it finds along the boundary of the room and creates a sketch based on the door Width parameter it expects to find. In this case the value was zero width and that made the application mad, Revit too. It was easy to fix. I just used a formula in the Width parameter that mapped it to the parameter these doors were using instead. Just another subtle thing to consider when we make content.
Architects usually document floor finishes. Quite often I see this done as a Filled Region exercise. The effort required to sketch a filled region is not much different than sketching a floor boundary. The benefit of using a floor instead is that's it modeled and it will be available in many views, as needed. We can tag and schedule them to study and document the design more effectively. External applications like Revolution Design's Revit Workflows offer a specific set of tools to manage creating finish floors very effectively. KiwiCodes offers their own version as part of their Bonus Tools app. These tools make the notion of using finish floors that much easier to consider.
One side effect of modeling finish floors is that they can compromise the door graphics we use, for example the panel and swing we are used to seeing in plan views. This happens because these graphic features are usually created on the work plane of the host level. The other issue is that, even if the floor doesn't obscure the graphics, the door panel, if just lines, probably won't mask the floor finish fill pattern (if one is used).
If we create a masking region (or lines) directly in the door family, to represent the door panel it will mask the floor finish as long as the Draw in Foreground parameter is checked.
Quirkiness ensues if a nested family is used. I happen to prefer to deal with swing graphics as a nested family. My logic is to make it once and use it in many families; a "kit of parts" mindset. Unfortunately the Draw in Foreground setting fails to work when the nested component is brought into the host door family.
To resolve this we need to make it possible to raise the graphics higher. Filled and Masking Regions can be assigned to a Reference Plane; Model and Symbolic lines too. This means we can use a parameter to change the elevation of the graphics, via the parameter and associated reference plane, to compensate for various floor finish conditions. The setting Draw in Foreground will allow this to work as long as we don't check it, which seems counter-intuitive.
In this image I've use the Draw in Foreground setting on native lines and masking regions, not checked on the left and checked on the right. I've also nested a swing family. The red elements are visible and the highlighted (purplish) are not visible except that they show up because I've got my cursor hovering over the family.
To get the nested swing family to show up above the floor is was necessary to not check the Draw in Foreground parameter for the masking region and lines. It was also necessary to place them on a separate work plane in the family that I could control with a parameter to raise it above the floor elevation in the project.
In the image above the only graphics that don't show up now are the bottom left line and masking region. They won't show up because the Draw in Foreground parameter is not checked. It's easy to sort out once you know.
Speaking of 3rd party applications, I used the Revolution Design tool to create floors for my testing. The app coughed when I tried to put in some floors. After looking at the error message I noticed that the doors I was working with don't map a value to the stock Width parameter, they use their own parameter to control the width. This annoyed the floor tool because it's looking for that parameter, the stock "Width". It's hard enough for programmer's to create applications that suit our varied needs. It's even harder when we create content in a different way than what they might reasonably expect in order to complete their tasks.
At first I was a bit confused but then I remembered that their floor tool will create a sketch that turns into door openings to define where the edge of the floor will stop for thresholds. The application looks at any doors it finds along the boundary of the room and creates a sketch based on the door Width parameter it expects to find. In this case the value was zero width and that made the application mad, Revit too. It was easy to fix. I just used a formula in the Width parameter that mapped it to the parameter these doors were using instead. Just another subtle thing to consider when we make content.
5 comments:
Steve-
Great post. As I'm sure you recall, our panel and swings are noted as well, but ours happen to be all model lines as well, so the issue still exists for us. We don't want the architects working around at with the sill height parameter (since it's incorrect construction wise... The door opening is framed with the rough wall) so we actually have all of the items (the panel family, swing representation, and panel symbology) tied to a second reference plNe in the parent door family, that has a floor clearance parameter tied to it, set to (default) 3/4".
It also serves as a nice safety check. If the swing disappears, we know the door is in the wrong spot. :)
At our practice the reference levels for the door swing is set at the undercut height of the door leaf. We model our floor finishes therefore the disappearance of the swings indicate that the door leaf needs raising up, or the undercut height needs increasing. As a result, having door swing linework not to 'draw in foreground' provides a great checking mechanism.
We make Revit work a little harder for us.
Thanks for the post and comments: excellent information.
What category is your swing family?Door or Detail Item?
I prefer to use the door category so the object styles are the same as the rest of the elements in the door. This allows the end user to adjust the door's appearance in the same place in Object Styles or Visibility/Graphics.
I concur, I use the door category also for the door swing. We don't use model lines though.
Post a Comment