I'm having an issue and I've tried multiple searches and not really found an explicit answer. So I'm posting it here to see if I can get a clear answer.
I have a multiple families I'm working on creating, and they could be either Face-Based or Wall-Based. But at issue here, is that certain things seem to fall apart in using a Face-Based Family instead of a Wall-Based. In particular it would seem that the Top and Bottom, Left and Right, Front and Back are fixed in the base family regardless. So for example, if I made a window surround that was Face-Based instead of Wall Based it doesn't appear right in Plan because it doesn't seem to cut the element in Plan View. While I've tried setting the settings under visibility to multiple different things, the issue was never resolved. But when I went to the effort to remake the whole family as a Wall-Based Family the issue went away, and now it cuts right in plan.
I used to think that Face-Based was just a generic and made the family more flexible. But I now think that he right answer is Face based only really works for items on a Floor or Ceiling, and if it is on a wall, you better be using the Wall-Based model, otherwise it won't translate right to the model.
Can someone either confirm or deny that I'm on the right track here? If I'm wrong can you correct my line of thinking and point me on the right path?
I do really wish they'd just let us be more dynamic about placement of Faces, and reorientation of the Family so that I wouldn't have to rebuild the whole **** family after finding out that it doesn't work. Little things like this really frustrate me about Revit, because I feel like they make it too easy to just throw away hours and hours of work all because you made a faulty initial assumption.
The orientation in a face based family is based on the host, so if you place the family on a wall in the project then the plan presentation set in the family is the front elevation in the project. It is not that hard to figure out once you get used to it.
See that would concur with my original line of thinking. That Face-Based understands Top & Bottom, Left & Right, Front & Back based on the host it is placed on. But in a couple of cased I have, where I made a trim surround for a window for example, it isn't cutting the family in Plan View. I've tried turning on/off the various visibility settings as it relates to plan, and it didn't change it.
I had another instance were a light fixture I made as a face-based messed up when placed in a ceiling, but when made as a ceiling based item it worked.
The hard part for me is that I don't know where the under-lying assumptions in each family template is documented, so I'm left to figuring it out as I go, and again often this results in many lost hours of work because the selection of the wrong starting template hoses it all up.
This could be because of the Face Based Family category.
Doors and Windows category families (at least the Wall based ones) determine the cutheight from the family's Ref. level and not the project floorplan cutheight.
The Ref. Level in a Face based family is actually the Front view if placed on a wall, so it's Cutheight does nothing.
Try changing the category of the FaceBased family into Generic Model, this category behaves as true 3D element.
We've build most families from Generic Model category because of this.
Some other Categories also behave different, some don't even have a Cut-appearance.
Also the Family template's are different, for instance a Family made from a Generic Model Category template in which it's category is changed to Windows is different then families directly made from Windows Family Template.
- Michel
We personally prefer host element or just face based elements. We start with Generic models and change them to whatever family category we need. Being a subcontractor we will sometimes copy monitor elements, and that changes everything from ceiling/wall/floor based to face based anyhow. (or did last time it was used by us.)
So when it comes to model element control, I'm assuming that your Generic Model Section is rather large in terms of different SubCategories.
For example, if you have a window element that is really a generic Model, then it inclines one to make a Subcategory under the Generic Model for said window element, solely so you can have control of that element.
Sie finden nicht, was Sie suchen? Fragen Sie die Community oder teilen Sie Ihr Wissen mit anderen.