The 2013 Deployment (Debacle?) Process

The Malleristic blog has gone unattended for quite some time, as this has been about the busiest year so far in my career.  I suppose that’s good and bad at the same time.  In the midst of that, two things were happening simultaneously:  A few months ago, Revit 2013 was released; we were planning to purchase 150 new computers for our users at The Beck Group.  Naturally, this meant timing a LOT of deployments, for all Autodesk Verticals: All three Revits, AutoCAD Architecture, two verticals of Navisworks, and two verticals of 3DSMax… All for 6 different offices.  Yes, the licensing Gods were not with us, or the BDS Ultimate cross grades.  Cest la vie.

While this was happening, I was also hard at work making some big changes to our Revit deployment structure, and it seemed like the right time to pull the trigger.  So- this post is:  What was required, and where did it have to go.  In addition, how the ‘PragmaticReviteer’ Deployment tools helped us get there.  You know I'm not much of one for Product Plugging, but the list of necessities for successful deployment was substantial, and this tool saved me hundreds of hours.  (I'm focusing on Revit 2013.  I’ll mention how I used the PR tools to deploy the others, but not about the specific changes to THEIR 2013 deployments.)

2013 saw more file structure changes to Revit, meaning things that control your software aren’t where they were.  Here are the ones I PERSONALLY deem critical for deployment.  Your mileage may vary.  I’ll list them all, then explain the “why do you care” then explain how the PR tools make more of this possible than a standard Adsk deployment. One asterisk (*) means it’s a file you place in the Autodesk deployment.  Two (**) means the PR Deployment Tools take care of it for you.  Three  (***) means it’s your choice (but unanimously the PR tools are more friendly.)  Ill save you my long winded thoughts on where you should store all these files in your library.

First, this list:

Revit.ini / inifile.xml*
Revit.exe.config*
RSN.ini***
MaterialUIconfig.xml***
PhysicalMaterial.adsklib**
AECMaterials.adsklib***
UniformatClassifications.txt***
KeyboardShortcuts.xml***

Revit.ini / inifile.xml*- 2012 saw a shift from standard Text edited Revit.ini (which, in 2011, lived in the native Program Files/Revit Architecture 2012/Program directory) to the ini being seeded in UserProfile/AppData, but still from the Program Files directory.  2012 also so a shift, that we were now intended to edit an XML file called “inifile” instead of the INI itself.  The GOOD news about this, is it made things tremendously easier, if you had to support multiple verticals.  Well, in 2013, they recanted, and decided you could edit the ini text file again, and just append it in the deployment.  Direct support wasn’t give to editing the XML anymore, however Autodesk Revit Support was gracious enough to help me through it:  You CAN still use the XML.  (with 3 verticals * 6 offices, I wanted to reuse whatever I could.  One XML file creates ALL of the verticals deployments for a given location).  This XML goes INSIDE your deployment.  It lives in 3 locations (I thought it was 4, but I only have three).  Which one is the magic one?  No idea.  Replace all 3, and it works though.  Haha!

…\AdminImage\x64\RAC2013
…\AdminImage\x64\RAC2013\Program Files\Autodesk\Root\Program\Setup\Cache\sfCache
…\AdminImage\x64\RAC2013\Program Files\Autodesk\Root\Program\Setup\Cache\sfRxCache

Why do you care?  Here is what is setup from our inifile.xml (each vertical can be configured differently in one file):

UI Colors (selection, etc)
Family Templates
Library Locations* (this can be done through Pragmatic Reviteer tools, which works better. I only put one place here in the xml, because you have to)
Project Paths (local files)
Project Templates (BTW... The syntax changed.  Again.  Sigh)
Allowance for Online content from Autodesk (ours is disabled)
Allowance for users to access Seek (ours is disabled)
Allowance for RSS feeds, email notifications, etc (ours is disabled)
UI changes, including press+Drag, and DisableMPPAutoApply (annoying accidental auto apply of the properties palette)

 

 

Next is Revit.exe.Config*.  This lives in your Program Files\Revit Architecture 2013\Program Directory.  This also ONLY matters if you are doing what I am with addins.  Once the API opened up in 2010, I began to get worried about the Black Hole of support that would be coming, and- sure enough- its starting.  So many addins are coming out, and people want them. Then updates and changes becomes a management sinkhole.  Well… You have options.  Installed typically, they sit on the users machines.  If you have robust SCCM support, or some other mechanism, you can auto-push updates to DLL’s on to machines.  We have it, but it’s still cumbersome.  So, we are putting all of the DLL’s (basically installing the addins) on the Beck Network.  We configure those Shares with Sync Center (formerly Offline Files in WinXP), so disconnected laptops still work.  In 2012, you could do this without any changes to the program.  In 2013 (thanks to .net4.0), you need to edit Revit.exe.config, to add the following line under the

    <loadFromRemoteSources enabled="true"/>

That enables addins to run from non-local places.  The end result?  The next time an addin sends an updated DLL, I replace one file on the network, instead of 150.  Everyone’s is updated, as they sync or work off the network.  NOTE:  Don’t forget to re-path the locations in your Manifest Files. Also don’t forget to Unblock the DLL’s when you copy them to your network.  By the way, this isn’t without side effects:

1.        Its not supported by Autodesk.  Their official policy is that you shouldn’t do this, and that you should all have SCCM or some other software copying things to local locations, for performance reasons.

2.       It DOES have a performance hit, but only on STARTING up Revit.  Our start times ARE slower.  From icon click, to Revit UI responsiveness (past the splash screen), we have 36 seconds.  I accept this, as its usually a once or twice a day occurance.  Responsiveness in the program is completely normal.

3.       You want to configure those networked resources with offline files, or they wont work when you’re offsite.

RSN.ini***.  The good news is, you only need this If you roll with Revit Server 2013.  It goes in ProgramData\Revit Server 2013\Config\.  It is a simple text file listing all of the Host servers on your RSN.  It needs to be there for the workstation to have access to the Revit Servers.  This file (I think) causes a lot of confusion for new Revit Server users:  When they try to connect, they “see” the servers but cant access them.  Well, you don’t really *see* them, this file just tells your machine to list them.  We have 5 offices, and we are using all five servers as Hosts and Accelerators now, so this file just lists all of our servers.  It **only** has to list the Hosts (formerly Central's).  So if you are hacking workstations in to local servers like we are, that doesn’t matter.  Getting it on the machines:  Supposedly the Deployment tool can do it, but gosh… It’s too complicated for my simple brain.  So I used the PR_Deployment Tools to put this on every machine in the office.  Didn’t even have to think twice.

Why do you care? If you aren’t using RS, you don’t.  If you are, because copying it around on to every machine is a pain in the ass if you have 150 machines. 

Next is the Materials debacle, and it’s a doozy.  The short version:  The Material Editor changed in 2013, and it morphed in to a raging piece of junk (my opinion).  HOWEVER, the UI of the material editor CAN be made to ALMOST resemble the one from 2012 (although not the nice one from 2011… But hope is on the Horizon).  Here is where that gets interesting:

MaterialUIconfig.xml:  This is a file that lives in C:\ProgramData\Autodesk\RAC 2013\UserDataCache.  That means it also gets copied in to the UserProfile’s Appdata\Roaming location, with the Revit.ini.  This, you CAN do with your deployment, by placing it in the UDC of the Adminimage, but since the PR tools help you in so many other ways, simplify your deployment and have the PR tools do it.

 

Why do you care? If you aren’t aware, this little file does a lot for you:

It saves the UI state of the Material Editor.  (Switch all the mat lists to text style, no rendered preview, open the Mat Editor and place it next to the Mat selector, then close it.  Then grab this file from your machine and everyone will see it that way by default.  If not?  They are in rendered preview hell.

ALSO, this file is HOW YOU DEPLOY with a NETWORKED OFFICE MATERIAL LIBRARY.  If you have started an .adsklib for your custom materials, load it on your machine in the mat editor.  Then grab the UIconfig.xml file, and place that in your deployment, and EVERYONE has your materials.  We discussed this in Harlan Brumm’s class at RTC, and I misspoke, as I thought it wasn’t possible.  Thanks to Gordon at Pragmatic Reviteer for setting me straight.

Now, if you are me (which you aren’t, and I'm sure that makes you happy) part of setting up the Material UI is GETTIGN RID OF the Autodesk Materials.  And guess what:  They made it harder and harder.  I'm not sure why ,they are bent on us using their overly generic materials.  Well here is the deal: 

PhysicalMaterial.adsklib- This is the autodesk materials that you want to vaporize.  Trouble is, this file doesn’t EXIST anywhere in the deployment, it is instantiated later. The Pragmatic Reviteer deployment tools, however, include an executable that is run post-deployment, to automatically go in and REPLACE this file with a blank variant.  That’s the ONLY way to get rid of the Adsk materials.  (Note:  I'm not talking about getting rid of the render images, or assets.  The overall MATERIALS for revit.  If you have your own, you don’t want users having single click access to these, and the new UI forces them in your face.)

AECMaterials.adsklib*** - These are the materials called AEC Materials, which you CAN replace in the deployment if you want to strip them out and put your own in… But since youre already using the PR tools (if youre me) its easier to not have to mess with the deployments.

Why do you care?  Maybe you don’t.  But trying to tag all materials intelligently, using QC approved terminology, and getting correct Quantities from the models, and such, I cant have random junk Materials showing up in Models just because they are easily accessible in the UI.  So they are removed.

And finally, there is User Data.

UniformatClassifications.txt- Now, this one is easy to take care of.  It goes in UDC and User App Data, with the other stuff above.  So you can handle it in the deployment, OR with the PR tools.  Since I have all three verticals to deploy, using one script to handle it, versus copying it in to all 18 deployments, was the way to go.

Word of warning:  We were years in the making, on pulling the trigger for this change, but it’s not something to take lightly.  You want to do it at a version change, and you want to make it a year you DON’T force project teams to upgrade.  Here is why:

1.        It involves opening every single file in your library, and redoing assembly codes for Every Family Type, in every file.  A family Type that has an old assembly code will still work, as long as no one goes in the type properties.  If they do, it will force them to pick a currently functional assembly code, or it will cancel their changes.  If your users don’t understand this, they’ll be lost. 

2.       A project upgraded from the last year, will have the old codes.  But since Revit 2013 will have the new text file, the problem above rears its ugly head, unless you keep switching text files in AppData.  Yikes.

Why do we care?  For us at The Beck Group, this file is paramount.  In the 2013 release, re completely rewrote out UniformatClassifications file, and completely discarded the Autodesk one.  This isn’t a slam on the adsk file, at all:  Our Timberline Cost Database is organized completely different, and in the shorter decimalized format (B1010.150 instead of the longer old format the Autodesk one is written in.  It was also organized differently (Autodesk’s has wall finish and backup in one assembly code, we itemize them out.)  So it’s a great change to make, as exporting data OR schedules from Revit can now be mapped easier.

KeyboardShortcuts.xml***- Obviously you know what this one does: it’s your keyboard shorties.  You can handle it in UDC, either within all of your deployments, or with the PR deployment tools.  But here is one more place where the PR deployment tools give a massive advantage over standard deploy:  You can tell it to GET the Shorties from the last version of Revit that’s CURRENTLY on the users machine.  That way, you aren’t just deploying the OFFICE standard, but that users.  I didn’t get to do this, since we were deploying brand new machines with new hard drives, but it’s a great feature.

Why do you care?  Because users don’t want to start over every year, making Keyboard Shorts.

More on the Pragmatic Reviteer Deployment Scripts:

You can visit Gordons site, to understand more about how it works, but the system gives you some other benefits which might seem small, but have pretty decent returns.

1.       Places (File open, save dialogues).  Of course we can handle this with the Revit.ini, and they end up underneath all of the standard Windows stuff (out of sight and sometimes out of mind).  The PR tools afford you the ability to place your libraries in the Places, but do so ABOVE the standard windows things. It’s a nice benefit.

2.       Desktop Cleanup and Taskbar Shortcuts.  Again, it’s a quickie, but I like that, since I place icons in the taskbar to let people know ive installed something new.

3.       Multiple Deployments.  This is where the rubber hits the road, for me.  The PR tool is a single click instantiation, to deploy whatever you have told it to deploy.  So with a single click on a Users Workstation, here is what happens at Beck, in order:

a.       Navisworks Simulate 2013, Navisworks Manage 2013, RAC2013, RME2013, RST 2013, ACA 2013, RACupdate1, RMEupdate1, RSTupdate1, 3dsmax 2013, 3dsmaxdesign 2013, all installed per deployments.

b.      Kiwicodes Family Browser installed and configured. Revit DB link, Model Review, eTransmit, hatch22, AaronsGETid, all installed.

c.       Revit Server Configured

d.      Comm Center disabled (bonus)

e.      Material issues Fixed.

Then the user logs in, and one final script runs (three minutes) that seeds their user data shortcuts, etc, and they are off to the races.

Obviously, for this to have a big time save, you need to disable UAC prompts temporarily through either Group Policy, SCCM, or using an elevated admin that isn’t subjected to UAC at all (even clicking OK).  If UAC prompts exist, you still need to be there to click OK, which is to be expected.  So we push the single script through SCCM, and UAC never pops up.  Literally, from home I can deploy every Autodesk Product and API addin (something we havent gotten from Autodesk yet, sigh), and be cooking dinner while 50 machines get 11 installs.

What does it take to use the Pragmatic Reviteer setup?  Well, there are some scripts to edit.  Here is the thing about that:  Writing code is the one class in I actually failed in school, and these are set up simply enough that I can handle it.  That means any of you can, without hesitation.

Here is what I suggest, though:  Sit and talk with Gordon while planning out your next deployment.  File locations, permissions, and access play an important role in this.  As his solution is new, 2013 was my first year using it, but I am CERTAIN our 2014 deployments will be seamless.  And ill remain ever optimistic that 2014 really delivers, to make up for this Material Editor. J  Check out his website, he’s got a lot of interesting solutions in the works.

http://www.pragmaticreviteer.com/

The #Mallerisms, as heard at #RTCUSA / #RTCNA

(Long post, no pictures) While attending RTC North America, i had the privilege of teaching a couple of classes. Its always an honor to have anyone want to listen to whatever i have to say. Unfortunately, for the particular topic i had chosen, i knew coming out of the gate it was too long for the time slot i had, and in a moment of #Malleristiclogic (def: thoughts in a Maller that appear justifiable and sound from a logistical point of view, but are widely received as insane and/or ridiculously stupid to others (read: Normal People)), i decided to shotgun it and try getting through all of the material.

Side effect: I was talking in a pretty rapid fashion, instead of watching and remembering the script for my slides, and some #Mallerisms snuck out. After this started some conversations, i had to explain about the different #Mallerisms that i occasionally let fly, and so i promised a short list, along with the defining (and differentiating) characteristics. (References to Revit are similar to "lets use this in a sentence." Let it be known that i adore revit, so this is not to mock the product.

Lets do this:

 

1. #BagOfFail: A minor series of circumstance, in which failure is obvious because of poor planning but good intentions. Bag Of Fail is kind of what happens when Copy Monitor tries to rename grids, and you start at a grid who’s new name is already in use. It’s a Bag of Fail.

2. #BagOfDisaster: Bag of Fail, at a nuclear level. Honestly, you should have seen this shit coming. Your plan sucked. Really. Bag of Disaster is like: Using Split Face and Paint. (Scott Brown says "Friends dont let friends use SFAP...")

3. #BagofSmashedAss: This is the MOAB of Bag of Fail. When a BagofSmashedAss presents itself, i cant help but wonder if someone woke up and said "Hey, lets see how bad we can **** this situation up, hey! Here is an idea!"

4. #Failboat: The Failboat is the entire situation which results IN the Bag of_____ above. When someone asks you the one word question of "Failboat?" you politely ask: "Have you ever seen an entire boat of Fail, that didnt sink?" They cant say no, which means it is legitimate. That, folks, is Malleristic.

5. #DinosaurArms: When imitating people whos decisions are often present in a Failboat and are creating a Bagof_____, evidently my arms become locked: Elbows to waist, and they just wave around. I was told they look like little T-rex arms, so now when we are imitating people while telling Lessons learned, we have #DinosaurArms. Rawr. All up in this.

6. #Buttdyno: Its like when youre driving a Ford Fiesta but you think youre fast. You arent. So when youre working in a Model Group, and you think its small enough to be legit? Use the Butt Dyno. Yes, youve been working for an hour. No, you havent saved. The Buttdyno says youre in trouble.

7. #AssAche: Its really just less syllables for Pain in the Ass, right? Sometimes when i work with Stairs and Railings, i yell out what an assache it is. I cant afford the extra syllables, since im trying to efficiently model stairs and railings. (But if you took the class by 2*Manna's+D-Light, you can probably say PITA, since they made you better at Stairs than i am, thus you have more time. (I heard the class was sweet...)

8. And of course... #Screwtastrophe. Its the PG version of a similar word that is one letter shorter. A #screwtastrophe is the PLAN for the Failboat, resulting in the Bag of ______. Copy Monitor is definetely a screwtastrophe, but then again... So is playing VBall with sunglasses on your head, and so is swimming underwater in a 2 foot deep pool.... As i validated the night prior. So is.... Falling off the back side of the stage. It takes talent, to be that kind of a #Screwtastrophe. You get a PRIZE for that. =)

There you have it. If you hear a #Mallerism in the wild, be sure to post up. It catches, like a cold. Ive heard people in the office referencing Bag of Fail. Its the #VocabthatBIMBuilt.

#RTCUSA / #RTCNA (Revit Tech Conference 2012)

Most of us have made it back home by now, after attending the Revit Technology Conference North America, in Stone Mountain Georgia. Compared to other conferences i attend, what i enjoy the most about RTC is that since its a smaller occasion filled with the people pushing on Revit as hard as can be done, its a great venue to really have some serious conversations with those same folks.  That also means an elevated technical level, in many of the classes.  While i went in with that as my expectation, it was even more present than expected, in execution:  Some of the classes were simply badass, in what they showed off.

I have to say that my *only* regret, was that i didnt get in to ANY of Marcello Sgambelluri's classes this year:  Two were during my classes, and the third was during a class i have a pretty vested interest in (The Material Editor in 2013... and Props to Harlan Brumm for teaching it, that couldnt be a fun class to teach this year). (Also props to Marcello for teaching three!)  I heard nothing but amazing things, and if i could have cloned myself, id have been in all three.  Of course, if there were two of me at this conference, im pretty sure no one else would have stuck around.  Evidently one of me was enough.

I wont go classs by class, because pretty much everything i sat in was a great experience.  Scott Browns class on Interiors in Revit, however, was absolutely insane.

The conference itself... I tip my hat to the committee for what they set up for us. Perhaps a bit ironic that Bentley was the main sponser, but what the heck do i know about anything?  The fireside chat, with Dick Morley, was intense. Not intense like "woah, really?" but intense like:  "Yes, we have someone here who can talk about innovation in ANY dimension," and that really struck home with this being a "Revit" conference, and all the directions Revit can now push us in.  Awesome, for that.

The second night Bar B Que dinner was awesome, boat ride included.  No one can control the summers 105 degree heat, but it wasnt stopping this group (although we did assault the pool later, and the pool fought back).  When we ran out of tables, we converted the foyer fixture pieces in to one, and then it was on for some no holds barred (and no rules) beach volleyball.  John Tocci and i are now a part of the club called "hit in the face with a VBall by a fellow BIM-er."  In his defense, i was the one that hit him.  Oops. In defense of whoever hit me, well... I have a huge head and it was obviously in the way.  #Failboat.

The third day did not fail to raise the bar.  Again, amazing classes. (Even if i failed to make one while i tracked down my belongings...)  I said it on Saturday and ill say it again:  THIS is the conference and the group of speakers i want training every user i work with. 

Glorious Gadgets really DID show some interesting devices, and Desiree Mackey and I joined another club called "You get a nice tablet stylus as a present for being someone who FELL OFF STAGE while presenting."  That, encompassed with having to #dinosaurarms in front of everyone, and it was time for dinner (and a drink)!

The Gala dinner was great, (amazing conversations... You folks always inspire me), the Packway Handle Band had some entertaining Bluegrass for us (which i enjoyed.  The music was great, and if you dont think so, i support your right to be wrong!), and it was a perfect way to close the conference.  I also have to give a shoutout to @jakeberrettdj, Jake Stafford.  A few of us were lucky enough to have him fire up some tunes for us while kicking back after the Gala.  Two years in a row, #MusicByJake at RTC.  I hope thats a tradition we get to keep having. 

RTC is an event i happily attend running through a Saturday, and if it was a day longer running through Sunday... Id have been there too. The only bad part about the event is it has to end.  Until the next one!

Looking forward to the 2013 series, and im planning an honest attempt to make all three.

There was some serious camera equipment there, not counting mine.  Sadly, mine had the settings all jacked up from being in extreme daylight in Washington DC, on my way to RTC.  Still, i will post a link to a public folder, with the few pics that turned out alright, shortly.  See you all in Vancouver! (And Delft?)

EDIT:  My public pictures are HERE. They are mediocre at best, though. Darn camera settings!

Class Materials- Autodesk TA event- Dallas

How has it been so long since i wrote here last?  Certainly, things are way too busy right now.  In any event, it so happened that an Autodesk Reseller Training event was happening up the street from my home / office, and the folks running the event were kind enough to let me come do a repeat of one of the classes i taught at AU2011. 

So first, a public "thanks!" to Amy Fietkau, for letting me come be obnoxious- i mean, teach some stuff- to a great (and entertaining) audience.

Secondly, Armadillo racing isnt what i thought it would be.  Those little suckers are fast!  It was a humbling experience, to be sure, but i am proud to say i motived my armadillo to kick some ass and win the race.  FIRST OR LAST baby.  (If i was chasing me down the street, id probably run like hell too!)



Thirdly, i owe you people some downloads, which- if you got the ones from AU, save the bandwidth, they are pretty close to the same thing.

So here they are!

Sample Data Sets
Class Handout

Imagine my surprise to get a goody bag on my way out the door!  Youll never be able to say i wasnt animated, but i just get super excited when i get presents!

So aside from that, many many things have been progressing, some definetely blog worthy, and some not.  I dont mind, though.  I would rather write less, but when i have something worth discussing, than post more frequently. 

The project mentioned in the last few posts, with the CME driven facade, is wrapping up Design Development, and- while im not technically part of the project team- i have had an immense amount of fun helping them along with it.  Some of us have twittered about possible sharing the Mass family, and ill ask about it when in the next meeting.  I like it, as a real example of a seat-of-the-pants-Mass-on-the-fly.  No doubt, it doesnt compare to Kelly Cone's   sa Rang church Mass, in terms of overall parametrics and flexibility, but alas... It was built by the seat of my pants.  :)  Here is what it looks like today.  Obviously some structural coordination is still going on.

There is more, too.  The project i talked about at the Ontario Revit Users Group last year, is HEAVILY under construction (major concrete pour today, in fact), so more on that later.  Both of these projects and more have gotten me in to the API a very tiny amount.  The API programmers among you will laugh at my novice capabilities, and i big public thanks to Phillip at KiwiCodes and Don Rudder at Case-inc, both who have helped me learn to develop, and to develop thigns for us.  Two class acts, cant wait to talk more about it.  Ill save that for the next post!

What is your role as an Architect? (How i spent my week in the CME)

If youre on my Facebook page or Google+ or Twitter, youve seen these images already.  However, this week and last i got to engage one of our Project Teams, and help them kick off their Revit Model.  During that time, through Twitter and Social Media, i read two things, and reacted:

1.  All architects should be Programmers.  (Tweeted, and i disagreed when i read it)

2.  Using Revit is frustrating every day. (Facebooked, and i got annoyed)

Then, happenstance had it that i was asked to write a paragraph on how Emerging Technologies change our jobs... And i laughed.  It isnt the most original comparison out there, but i liken us to the Record Industry:  Are Architecture and Engineering Firms still making Casettes and wanting to sell them for 14 dollars?  Certainly a CD or an online album is a better product, so... Isnt it a little justifiable that the road towards a better product is a harder road?

The interaction was interesting.  The design started in other wares, due to familiarity for the team involved.  At this, im not as displeased or as intolerant as my Revit Persona on forums.  Why?  They used it (in my subtle humble opinion) just the right amount:  They didnt toil hours on mullions and entourage, didnt get overly complex.  They told a story, and asked about moving to Revit.  Props to them, i love this crew. 

A few things about working with Revit Massing and the Form Editor:  Reading this post, youll discover i had to do 3 "major" rebuilds, with destructive editing that made us lose Face Association.  Two interesting things about that: 

1.  I cant even be upset about it.  Even deleting the entire skin of the building, and reskinning the entire mass, took less than an hour each time i did it. (Were in early design, so Curtain Grids hadnt been customized)

2.  Most of the *redo's* were because *I* didnt understand what was driving the Design Intent, and *I* wanted it to be constructed more parametrically to suit those needs.  So on with it.

Kelly Cone and his infamous SaRang Mass, reminded me that Nested Families with Lines in them could come in handy for this sort of thing.  So i made one.  (Time investment: 15 minutes).

Important to note: The Curves werent there in the first version, since they werent in the project yet.  But Constraining a Parametric Tangent Line was a massive help (Thanks Zack Kron for the lesson!): 

If you have a flexible Reference Line (parametric length or angle, or both), constrain a Reference line Normal to its end (90 degrees).  Any tangent arc will have its centerpoint on that second reference line, so the constraint is a simple "Align and Lock." So Indent Front and Angle affect the arcs beginning, Indent Rear affects the arcs end, and (invariable) the arcs radius, which has its centerpoint locked down.

This brings me to the two points above:  Architects as programmers, and Revit being difficult.  All the promises out there about BIM... "Integration, streamlined documents, coordinated drawings..."  I mean, doesnt it make SENSE that Designers learn this?  I got the masses design intent wrong the first few times, because i was deconstructing a design model and didnt ask what was "driving."  But by definition:  Someone knew what was driving, they drove it.  And if making seamless and beautiful forms comes from parametric centerpoint constraints... Then wow. This was when i realized i was WRONG for disagreeing about Architects and Programming.  I mean, this isnt writing code.  But, how DOES a "Coordinated Model" get built from a "design intent" unless the "designers" are doing the "modeling?"  (BTW, midway through this model the designer is now playing with Divided Surfaces and Intersects and Patterns.... I love this crew!)

So onward. These are pretty simple things, but they make alterations a snap.  (These are the early versions, before the tangent arcs were there). 

Well, i wont bore you with writing and writing and writing (its just making a Mass, for crying out loud), but what i love about the process is being able to watch the subtle changes, as the design team makes it real.  Too often, its beautiful when designed, made real in some other program, and the two never meet, and are never the same.  So, the progression.

From the first Revit iteration, to the current. It certainly doesnt LOOK like it changed much, but there were a bunch of iterations in between where it had lost its grace as parameters changed.  This is why i love the process!

The angles are constantly differing, floor to floor.  And they were all changing (as were the locations of the Relief) as the program was fit in to the building.

  

The walls of the first floor "Tunnel" were constrained as well, as they were complex curves that began based on the facade elevation, then proceeded to vertical.  Again, that question of "Who should be doing the constraining?" 

The more iterations we played with, the more the walls shifted.  It became evident that there was going to be some pretty extreme shapes, for these panels.  And that they werent all going to work out flat.

Aside from that, i had a pretty good idea that the Mullions werent all going to end up so ordinary as well, i had just UZI'd Curtain System on it as a placeholder.  So we went back to CME and started playing with Divided Surface.  There's a GOOD reason why:  The v1 Mass i made, the "relief" on the facade was a consistant angle, all the way through. Why?  I made it that way.  The SU/FZ Model showed angles, but the interpolated "lines" i was seeing in plan were skewed and arc'd.  So i ASSumed (big mistake) that the team meant for it to be consistant.  As that wasnt the intent, you can see why i then rethought the Order of Operations i had gone through.  Making the shape this way didnt make as much sense.

But then i got to thinking:  Wow, its going to helix, then.  Between every different angle on the Floor Plates.  Then i got to thinking about the expense of such helixed objects, and whether or not you could NOTICE while looking at the building?  (I was told in Studio:  Do it severe enough to look like its not a mistake...)

With that, after the latest version was massaged to the correct shape, i went back to the Mass to Divide the Surfaces and Apply Patterns to them.  For now, i kept it rectangular and normal.  The designers are taking their pass at it after Tuesday.  Still, a nice Curtain Panel made by Zach Kron that uses Reporting parameters to evaluate the sizes, angles, and deflections of the panels was put on.  There are a few versions of this family floating around, but this one uses parameter values instead of different nested families for visibility.  But wow, it tells the story quickly. Load it in to a Project and include a few different views using Filters to color the panels based on a variety of the reporting parameters, and you can color by length, clolor by area, color by deflection, etc.

And this is where the analogy of the Casettes and the CD's comes in for me.  And honestly, this is what this post is about:  Its not about Form Editing, or Revit, or Massing, or Modeling. 

Someone came up to me when they saw this on the screen, and wondered why i was looking at the deflection at all?  Why bother?  To be fair, i was doing it of my own volition... Not at the behest of the project team.

But i was asked "Why would you care?  Why not let the Fabricators deal with it?" i actually have to admit- i got a little snippy (shocker!).  I mean, this IS our "better process."  Right?  How many times in our careers do we watch something get Value Engineered because its expensive?  I can tell you how to make this entire project cheaper, right this second:  Straighten everything out.  Then again, i hear we can save some money, you know, if we just leave all the glass off, too.

But to be able to say:  We kept the design, but we looked at it for extreme cases that could drive the cost up, tried to minimize them, worked at keeping the design intent while TRYING to keep in mind that someone downstream would have to "make a baby" out of this thing... Isnt this why we are here?  Is this the "New Role" of our jobs?  Not just to make something pretty, but to make something pretty HAPPEN without getting marginalized out of the concept by pragmaticism that we cannot respond to?

Yeah, Revit frustrates me at least once a day too.  But this is (imVho) our jobs now.  I dont want to deliver the same thing i did yesterday.  And i want to know we did the most we could to create the best Built Environment, as efficiently as we could. Its harder, and it should be.

This is NOT a Trick Question.

Ive been remiss, as i have a few posts "sitting in the queue" waiting to write, but ive been crazy busy this month, with little downtime to write. 

Im having to write a brief piece for work, and it brought this question to the forefront of my mind.  I know- asking it here- that it will feel 1. Like a trick question, 2. Like im pushing people towards a predetermined answer, and 3. Like its focused on our technology and methodologies.... But thats not what i want.  Leave the software at the door, leave the computers behind (you know, except to type your answer).

So let me ask you: 

1.  Are you an Architect, an Engineer, or a Contractor/Subcontractor?

2.  What do you think "your job is?"

(Shortest Malleristic Post EVER).