Ill tell you what:

Unless you are planning a system where someone is going to manually place every single mullion and every single panel- and size them- (which ill bet is NOT what youre planning, so read on...) you are going to end up with:

1. Complex families with enough math formulas in them to make Nested Families populate along arcs.
2. A LOT of Shared Nested Families with type parameters and nested instance parameters
3. Difficulties with constraints
4. Difficulties with Wall Joins and Room Boundaries
5. Having to build "Super Families" that encompass all possible options, or the "stray mullion" someone wants will be impossible.

It will be place every object, or go with all of the above, which will be a way harder performance hit than Revit Curtain Walls, i can guarantee you.

Weve got a ton of mullions, nested detail components, and custom curtain panels, since outs encompass Shim spacing, glass channels, and many variables for sizes, as well as custom panels for things like Louvers, shadowboxes, false fronts, etc. So far i havent found a better waty to make a more detailed curtain wall, that performs better, inside Revit.

Although we ARE experimenting with making a "basic frame" in Revit, punting it to Inventor, making Inventor model the fabrication level model constrained to the frame work, and roundtripping it. A few hiccups, but its working so far.

Hi Aaron,

Thanks for the reply. I have a bunch of questions for you based on the list above:
1. Populate long arcs?
3. Do you have an example of what type of constraints would be a problem?
4. As for the comment on Room Boundaries, we would still be using the native curtain wall host (system family) so I wasn't thinking we would have any issues with that... I'd like to get your full thoughts on that to make sure I am not missing something.

Just to clarify what I am proposing to do with all of this. We would still be using the native curtain wall host, and curtain grids. The only component family would be the panel. I have made nested mullions which are loaded into the curtain panel component family, and I have made window families which are basically the 'infill panel' (includes items such as awning, sliding, louver, shadowbox etc...). These infill panels are also loaded into the curtain panel family.

I am not proposing to make a new “wall family”, but rather just a curtain panel family with mullions included.

I completely get what you are saying with having "Super families" that do everything. I don't want that, and I defiantly don't want to over load this with too many parameters etc.

Just out of curiosity, by your definition, what is a "ton of mullions"? Do you agree that having a ton of mullions will create a performance drag? Especially in elevation?

Thanks again Aaron.

Let me get this straight: you want to use the curtain walls, but nest the mullions in the panel families? That sounds like a world of hurt to me. How many components are loaded into the panel family? The amount of possible configurations is endless if you ask me. How about the joins of the mullions, how is this hanled? How does your panel respond to sloped walls? or curved walls?

Are you talking about something like this?

Mine is just the frame and glass....but as long as your not over-constraining all the other elements you should be fine... Panels are very fussy... if you get too many constraints it will not obey.

Yes. If you are doing a lot of serious high rise, im sure not all of the curtain walls are straight. If this is the case, and you want them to... "look correct..." youll be adding a bunch of angle parameters (which means more family type definitions, complex constraints in that family, and so on) to make it actually happen.
Not really, because i wouldnt be venturing down this type of road, lol. But shared nested families have limitations with how many nests can use family type parameters, which relegates you to having a bunch of instance parameters in everything that gets nested, and having it ALL controlled from the parent family. (I mean, youre talking about nesting mullions in to a panels. 4 mullions per panel, 4 potentially different mullions, with variable dimensions for mullions, if you are serious about doing curtain walls). Youll have all sorts of issues if you actually try to do it.

So the plan is to still use the Curtain Wall for the System Wall / Room boundary, then to just use custom panels with mullions nested in... Just to save having System Mullions in the project? I think you are barking up a tree best left not barked at, but here are a few other things to consider:

1. Custom panels + Edge of non-uniform Curtain Wall = not happy Revit. Its going to beat the heck out of your team.
2. Custom panels + non-rectangluar shape = not happy Revit. I forsee many panel deletions and replacements with system panels = mullions gone.
3. Graphically? If you are embedding all of the mullions in the panels, you are going to have very strange mullion joint lines everywhere. Either from dividing the mullions in half around every panel, or only having mullions on 2/4 sides. Either way, massive joint lines.

I get what you are saying, and im not bashing the idea just to bash it. I honestly believe it is an exercise in futility, frankly. I dont believe you will get it to perform better, or look better. Im not always thrilled with the way Mullions and Panels work, but i think it needs to be fixed by the Factory, and i believe- even with as good at building content as i am- i cannot make a more efficient, better performing, and better looking system, than what is in the program already. Thats just my opinion, of course, and i dont pretend to know much.

I believe a ton of mullions will make a file slower than having a gypsum wall around the outside of the building, yes. I do not believe it will be a bigger performance hindrance than having a few hundred or thousand custom panels though, not at all.

Ive got a few active projects in our office currently: One is a 700,000 SF story building (15 floors) with a complex Curtain System facade. In total, something in the neighborhood of 30,000+ total pieces in the skin alone. (Thats how we helped uncover this problem: http://revitclinic.typepad.com/my_we...selection.html). That model performs fine. Do the elevations take longer to regenerate than a Wal Mart model? Well of course!

The other project is almost as large, with a complete Curtain Wall system built around the exterior. In addition, every floor also has two rows of Custom curtain panels including every modeled louver in a LightLouver series, and a bunch of shadowboxes at the Floor Decks. Its also got line based families placed down the outside of every single mullion, as exterior sun control devices. My point is, i think they are as much a performance hog as something needed to document those buildings would be, and anything we buit custom would be just the same, if not worse, in some ways or another.

BTW, when considering that our Curtain Walls perform fine and arent considered a tremendous performance hog: Most of our mullion profiles are the full 8 sided mullion (they have the glass channel), and the ones for the perimeter are 11 segments in the profile, with the Shim space). They arent even as lightweight as they could be. If i thought they were underperfoming, i would simplify them, but i see no ROI on replacing the system in any way.

Hi Martijn,

After reading through this very thoroughly, I can see your point here on all the issues you questioned. I appreciate your input. For curtain wall, epically if it's curved/angled, this will undoubtedly be a problem, so there would be quite a few angle/cut parameters to handle these issues as well as the issues with the joins. We have been testing the concept on a couple of smaller jobs but we are not really drawing “curtain wall”, it’s more “window wall”, and some the joining issues have popped up. We also end up with a lot of types per project, so it does become cumbersome in that regard as well. The only real benefit to this is that we are able to update one family/type at the same time – and for a window wall system it would be nice to be able to treat this more as a component family instead of a system family. However, with all the said, so far the pro's do not outweigh the cons. Thanks again for sharing your thoughts.

Mr. Maller,

Between the replies posted by both yourself and Martijn, I have decided to reconsider this approach. Based on the quote above, you made me realize this is probably not the first time this issue has popped in to someone’s head, and like the stair and railing tool (which I will leave completely out of this discussion) I agree this is a problem for the factory. Hopefully the factory is reading this!

Instead of trying to reinvent the wheel, we are going to focus our efforts on properly utilizing the system tools. I know a lot of thought has gone in to these and although we feel they are not perfect, they do work the way they do for a reason. What we were really attempting to do hear was make the panels work more like component families to eliminate some of the necessity for excessive grouping and ease of editing. After testing this all out though, as I mentioned above the pro’s just simply do not outweigh the cons. Plus I will need to train EVRYONE in the office on this new “system” and by the time that happens, it will probably be all for not.

Thanks again.