Families / Types / Instances

The issue here is where does the "category" property reside? Does it remain at the family level as it does now resulting in duplicated families (and duplicated updates, etc...) or does it reside at the Type level allowing a single family to have types in multiple categories. This means we have a single family to update with changes. No one thought the category residing at the instance level made any sense. This would allow instance level overrides of categories and that just sounded too unruly to everyone...

Family : Type : Instance

Changing categories of placed "system" families is of course going to cause a problem with the whole Family:Type:Instance paradigm. Right now, the System Family IS the Wall Layered Construction tool.


However, I do think the family/type/instance relationship should be maintained. What I'm proposing is that the part of the system family that corresponds to "Family" which is the "layered construction family" would now be allowed to be multiple categories. So, if I change the category of one instance, I'm actually changing the category of all instances of that type, and if it isn't already there I'm also creating a Family in the new category called "Layered Construction". This would also apply to creating families. So, when someone picked door and then grabbed the "layered construction" tool instead of place component, it would basically create a family in the door category called "Basic Layered Door" or something and then create a type under it for what you're modeling at the moment.


Of course, based on that last example the clear suggestion is that the Layered Construction family can be used to create ANY category, and similarly use can use a "component family" for any category as well. I think this is also critical because, frankly, there are walls that are neither layered nor panelized nor path arrays (railing tool). Those we need the flexibility of custom component families to create but we still need the "wallness".


I think you could make a pretty good argument for having the category be a property of the type and not the family on a program wide scope, but that would entail re-organizing the project browser (from a UI perspective) and I don't think it is critical to do so for this to be effective. People can always "duplicate" the family and change its category to get a new type in a new category. But that can be a discussion for AU.

Hosting...

Another problem we have with categories overlapping with non-category like behaviors is Hosting. Just like the geometric tools are defined by the category (despite reality), hosting is also defined by category (despite reality). I'll give you an example an Autodesk employee threw my way...

We were discussing the whole category thing, and I was making the point that we should be able to select something modeled on the wrong category (ceiling modeled as a roof for instance) and switch it to the right category (ceiling). He then came back and said it might make sense for system families, but it made no sense to switch between say a door and a wall. Naturally, I disagreed. My counter example? What about a concealed door that is really a hinged wall? It might be constructed more or less the same way the adjacent walls are but it has additional door like hardware to allow it to be opened and closed, and needs to show up in the door schedule and tag like a door. But, we need to host a blackboard or a white board or something on it like a wall. My intrepid collegue's response was to let us assign multiple categories to one object. I'm not into multiple personality disorder, so I think that is a bad idea! Take a wall and "add" door properties and behavior to it. Yuck, but it would work with the current structure. 

Of course, the category / modeling thing is part of the problem. But, hosting is the part that makes us not want to make it a door. If we do, we now have to make a face-based whiteboard family to go along with our wall hosted one, to go along with our unhosted one, etc... Hosting is just as much of a problem as associating geometry decisions to categories. In "reality" I can take screws, construction adhesive, and other "fastening devices" such as pookie and chewing gum, and I can "host" some whiteboard just about any where I so please. I don't have to call the manufacturer and order a different "whiteboard" to screw it onto a door vs. a ceiling vs. a door. So, I kind of feel like Revit should oblige me and do the same...

"Hosting" as Revit defines it is frustratingly static master/slave relationship only available between certain categories. Without launching into a Monty Python monologue about the feudal system, lets just say that sucks.

Hosting SHOULD be a way to define a relationship between multiple objects, regardless of category. What's that you say, make a face-based family? What if I want it to cut non-system families consistently? What if I want it to easily be non-hosted? What if I want it to have access to the host parameters to define information about itself? What if I want to relate three things to each other? What if the master / slave breakdown isn't clear? Face-based hosting is a first paltry step in the right direction that immediately causes us to loose another initial step in the right direction called reporting parameters. It isn't the solution...

So, we're going to be diving in to how to solve hosting as well, since it basically muddies the water in the category discussion and leads us down some bad paths otherwise.