The Class

So, the class went great! (or at least I thought so...) I suppose we'll see with the surveys. Please fill them out if you were in the class.

We had a full house with 40+ people all told in attendance including many people who weren't registered (naughty!) but the conversation was just better for the additional ideas. Thanks to everyone who came and participated and PLEASE post on the blog. I'd love to get a ton of comments to prove to the factory how important this really is.

All the material is now successfully on the AU site, and for those of you not registered it should become available after AU, or you can download it here

Graphic Display by Category? Really?

Yet another example of categories being used to hard code non-category specific behavior is how they are cut in views. Basically, Autodesk has decided for us that lighting fixtures don't cut in section views. If it is a curved fixture and it obscures a bunch of other stuff, too bad. You have to hide it, and manually draw the section cut in. Can we say yuck?

I do understand that part of the point  in having the category control object display is consistency, and I'm not really suggesting we change that. Some have suggested it be managed at the family level, not the category level. I disagree though. All I think we need to fix this is end user control over ALL the currently hard-coded display settings for categories. I just want a checkbox in Object Styles to control whether a category cuts in section, or whether view depth clip works, etc... Here's why:

And there isn't anything we can do about this currently...

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.

Categories, not Modeling Tools

So, IF we reinvent hosting, I'd say that we can then make some serious changes in how categories are assigned...

Rather than have it assigned by the modeling tool chosen as if there is some inherent relationship between the two, have it be chosen either prior to selecting a modeling tool or after the modeling operation is completed (and allow no choice to be made). 

I would imagine two different ribbon panels for these two different workflows. One would look much like what we've got today (minus architectural columns because if you uncheck "structural" in a regular column, guess what, it is architectural!, and some of the other redundant tools in there). Then, in the draw wall mode you basically get a bunch of modeling options in the ribbon just like you do now when you enter sketch mode - line, ellipse, circle, spline, etc... - except this time you get path (should support 3D paths), profile, face, panelized, etc... Pick one and your drawing mode changes appropriately, and it should default to whatever you used last probably. Same thing for floors, ceilings, roofs, etc... You set the category and then choose the modeling tool that best fits your intent. Alternatively, there should be a tab that gives you the layered construction, panelized construction, swept construction (railings anyone?) tools and when you finish the category is basically unset (a real reason for a generic model category) and it can be set later. This effectively gets rid of a lot of redundant tools like Curtain Wall / Curtain System.

The point here is that we can choose smart modeling tools that allow us to achieve both peak efficiency and modeling accuracy, AND have the end result be in the correct category...

This is crucial to achieving data consistency downstream.

The separation of categories from geometric tools also allows us to potentially change the category and the modeling independently. So, if we switch from a panelized wall to a layered one, instead of deleting it we can just change it and retain both the element ID and any wall meta-data already stored in that wall at the instance level. Or, we could realize this is no longer a roof but a ceiling, and we can switch the category and get all the ceiling meta data parameters without loosing the Element ID or the geometry we created. And, since we reinvented hosting and removed it from the category realm, we can do all this without loosing hosting associations.

Ahhhh, Nirvana...

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.

Non-category specific behaviors...

So, the first question we should all ask is "what are categories really for?".

I think this is the fundamental root of the "problem" we have right now. Like many tools and features in Revit (worksets anyone?) the actual intent of the tool has been left to pasture and instead it is being using for many additional things it was never intended for.

My position on all this is that categories are simply a tool to assign non-geometric data sets (classes) to objects in an efficient manner. In other words, instead of you and I having to manually associate multiple parameters to objects one by one, we can make something a "wall" and certain parameters and properties are inherited as a result of that choice!

Basically, assigning the "wall" category associates anything that we deem as "wallness" to that element. Sounds good to me? You?

But, what it Autodesk or other users have decided certain things should be included in the "wallness" that you or I think otherwise? This is exactly what has happened with the wall tool. The only supported way to make a wall category object is with the wall tool. This tool not only assigns wall properties, it also creates the geometry using a layered construction assembly wizard. Right? You draw a wall, and as Shrek would say, "it has layers donkey."

But what if we're drawing a panelized wall system? It's assembly type is no longer "layers" but "panels". We can make a panelized construction using the curtain wall or curtain system tools, but we can't call them a "wall" anymore. Same thing goes for ceilings (ACT anyone?). Autodesk (and formerly Revit) have forced our hand and told us "all walls have layers" and "no walls are panelized except glazing". That leaves us with two options: Grossly misuse the tools we are given to correctly model the things we need (use a curtain system for ACT) or grossly misuse our time and attempt to model something panelized using a layered construction tool and adding reveals to it to mimic panels (like a metal panel wall or ACT). You notice I didn't offer "use a surface pattern as an option... Surface patterns don't export to Navisworks or any other 3D coordination tool on the market, which means your panelized system can't get coordinated against properly. I don't think that is an option...

So, that is the real problem with categories in my book. That the program is associating non-wallness things with walls and gives us no supported option to get the needed result (a panelized wall).

Now, some people will say that all that "wallness" that gets associated with the wall category isn't that important. If your models stay in house and never leave, then you're probably right. But you also probably don't care if it gets better. If, on the other hand, your models frequently leave the architectural world and make it over into construction management and fabrication worlds (like ours do); then you probably do care. I can't count the number of times I've had to explain over the phone to a subcontractor, estimator, or project engineer why we modeled ceilings or walls as curtain systems. There is no reason we shouldn't have that modeling (geometry) tool available to make walls, ceilings, roofs, or whatever!

My 2 cents...