Face Based Families – What’s wrong with them?

I hear this quite frequently “We don’t use face based families because…”.  However, I believe they are one of the best family types there are.

Common Misconceptions & Benefits:

  • We don’t use face based families because when the host is deleted so is the element.  Below you can see this is completely untrue and in fact is one of the main benefits of a face based family:

Delete host of Face based family

  • This is only the case for wall, floor, ceiling, roof based families.  They are even more robust than an unhosted family with regards to hosts being deleted.  A non-hosted family is essentially level based, if you delete the level the family is deleted.  A face based family can be hosted to a face or a workplane, if you host a face based family to a level and delete the level, the family remains!
  • Why would you want to manually coordinate the alignment of a wall fixture with its wall if you don’t have to?  Yes you can create an alignment constraint, but these types of constraints are manual and too many can really start bogging down the performance of a your file.
  • They are flexibly as you can apply them to any face, so if my basin needs to be hosted by a piece of casework it can!
  • They are very easy to create and constrain in the family, there is no need to flex the thickness of the host element, as it doesn’t care about its thickness.
  • They can interact with their host automatically, such as cutting recesses or penetrations without losing their host
  • For vertical mounting you can specify default mounting heights, so when placed in  plan they are at the correct elevation on a vertical face.
  • Sometimes I will use an unhosted family with the workplane based option checked, this gives very similar functionality to a face based family, with one limitation – it can’t cut its host automatically, and one extra benefit, it has the “Always vertical” option.  This is really useful for creating pendant lights hosted to raked ceilings…
  • Sometimes people make the suggestion if you make it unhosted then the end user can choose to simply nest into a face based template and make it face based later if they want.  Sure they can, but it makes the file size larger, parameters need to be linked through, connectors need to be replaced in the host family… Its just extra work for no real benefit.
  • Face based families can be hosted to linked elements, so are very useful when worksharing.  You can also reconcile hosting if a linked is removed and replaced.

I hope this helps to dispel some of these misconceptions are people feel more comfortable using them.

This entry was posted in Training and tagged , , , . Bookmark the permalink.

3 Responses to Face Based Families – What’s wrong with them?

  1. R. Robert Bell says:

    First, let me state that I create face-based families the majority of the time. I agree with you on some of the benefits. However (you knew that was coming!), as an MEP guy, this is a win-lose situation. You offer the perspective of using face-based families directly in the same model as the hosting elements. This is evident because you talk about cutting the host. The picture is not quite so rosy with linked models.

    Oh, don’t get me wrong, I insist on using face-based families in our model because it is the only way to get our elements to react automatically with positional changes in the linked architectural model. The negative is the sheer number of elements that go unhosted or not associated with every linked model update.

    Unhosted elements are usually the “fault” of the architect deleting the elements to which our elements host. Yes, sometimes a deletion is unavoidable. However, Revit’s tools to fix the issue are tedious to use. It is common for us to have 50-200 elements per update that need rehosting. In some cases we had architects that could not seem to get it thru their heads to stop deleting ceilings despite many conversations about the issue. But even great architects still need to delete elements that we host to. Hence the 50-200 element count on average.

    “Not associated” elements are another ball game entirely. These are elements that seem to be hosted per the Reconcile Hosting dialog but are really not associated with the face that they appear to be on. These elements that are not associated can only be discovered by using Model Review or selecting an element and noticing that they are not associated. What causes an element to be not associated? There is no documented cause. But I think it has something to do with rounding issues in Revit. Regardless of the cause, not associated elements roughly double the count of elements that need to be fixed with each update. This is a hidden cost of doing a BIM for MEP using Revit and a significant cause of overhead on projects.

    Let me wrap this up by saying we won’t be going to non-hosted families just to resolve these bugs/poor implementation because, if my elements don’t react to changes in the model, IMHO, that isn’t BIM. So we will continue to use face-based families but we increase our fees to account for the cost of coordination with linked Revit models.

    • Chris says:

      Good Points Robert and all perfectly valid. The reconciling process needs to be better, and if a new face exists in the exact same spot, I’d probably be okay if Revit just automatically rehosted to these…

      I guess the other item the MEP guys dislike is many don’t like having to place the components in a RCP. If they try to place in their plan views the fixtures on hosted to the wrong side of the ceiling. Personally though, I think its just lazy to then decide I don’t like face based families because I have to go to a different view to place them…

      • R. Robert Bell says:

        Our folks don’t complain to me too much about having to place elements for a ceiling in an RCP. What they don’t like is the lack of coordination with furniture while in an RCP view. The issue is that the Underlay View option is useless because the furniture exists in a linked model and the Underlay View option is only usable with the current model’s views. We have workarounds that help but they are still a kludge. (But now I’m wandering off-topic.)