Tuesday, November 2, 2010

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.

No comments:

Post a Comment