Whoopsie...

Evidently a few of the links (most notably the God Is In The Data materials) werent working, as i had typed them in with their FTP addresses, and not the download addresses.  They should be fixed now.  My bad.

What can i say that hasn't been said already?

Well its been a LONG time since ive felt like writing.  About Revit, about BIM, about the community of people that we all work in and with, and all that it entails. Its actually been over a year since ive logged in to the blog, and wanted to write.  I've had plenty of topics i wanted to cover, but i guess there is a certain amount of Burnout that comes with some of the *hardships* of being a Design Technologist and a Support Technician.  That could be a topic in and of itself (What do we call ourselves, and what does that mean we do?)

I've spent a fair amount of time on the road, having traveled to Australia for RTCAUS (which included a phenomenal road trip to Sydney from Melbourne, courtesy of our RTC Father, Wesley Benn. RTCAUS remains one of the highlights of my year.  The vibe is just *different* from the conferences in America.  I cant really explain it.  But, ill save that for another post, that i hopefully stay motivated enough to write in the near future.  Regardless, the trip was amazing. Seeing #VividSydney was epic.  What a heartstopping show.

Between the Australian event, and the North American RTC, i had the privilege of presenting 4 different classes, and helping with a few others (truth be told, 5 of us from Beck Group taught a total of 14 classes between the two events!), and it was an honor to see my colleagues do their thing.  Unfortunately, because im a constant over-reacher in terms of scheduling, a lot of my materials (all of them) were extensively late, getting to the committee members.  Thats my bad. Without a justifiable excuse in sight, i mentioned on Revit Forum that i would post them here.  Some of them were great conversation (i thought), but perhaps that's my unwavering desire to talk about the nuances of the unsexy stuff in Revit, and not focus on the new shiny toys.

RTCAUS- Abusing Groups in Revit (A Healthcare Project)

I saw this class as sort of a follow up to a 2010 class i did at Autodesk University, on Links and Groups and Documentation, and making it all work.  Back then, hardware was a real concern for the projects we were doing.  Now, the computers have caught up enough that- even as extensively as i intentionally hyper-model (over model implies its too much), were able to stuff the whole building in one model, and have it perform admirably. The extensive use of Groups help to propagate similar situations throughout the building, but using Revit Groups is never without incident.  It can be- however- without much difficulty, *IF* you know a lot of weird tricks about what revit Groups like and dont like.  For instance, there are rumors that Groups cant be mirrored, and cant be rotated. It turns out thats not true at all, its just that Revit wants them set up a certain way to BE rotated or mirrored.  Want to know what that means?  Check out the handout.  Ill bet the "One Hosting Face for each Face Based Family in a group" will solve a lot of your problems.  The materials are here:

RTCAUS- Abusing Revit Groups in Healthcare Architecture

This was my favorite class to teach, because i had a lot of fun with it.  Was also a treat to get the model in to Revizto. Weve been using it more and more, and this coming week its getting installed on EVERY architecture machine in the company (more on that later).  The gents from Vizerra even presented some of our models in their class in Chicago, which was fun to watch. We dont buy massively powerful GPU cards for our computers, and even so- it runs like a champ.

RTCNA- The Fireproofed Revit Model (A Collaboration with LA Fuess Engineers)

Another class i was proud to be a part of, surrounded the collaborative efforts of a Structural Engineer i work with pretty closely (Scott Wilson, of LA Fuess Engineers (www.lafp.com)).  Without being too promotional, LAF is a Structural firm thats always willing to help us push the envelope, and take things a bit farther if its beneficial to the project downstream.  Scott and i got together to see about a Data Exchange setup, where they could Model the applied Fireproofing on Structural Steel content, but then have a vehicle for our Architects at Beck Group to control the specifications, locations, and thicknesses, of the Fireproofing. 

While the workflow wasnt *sexy*, Scott and i live and work in the real world, and this is reproducible and works reliably.  Weve shown it to the staff at Beck Group already, and we are showing it to the rest of the teams at LAF shortly.  It hinges on some simple API data exporting and importing.  While that isnt sensational in terms of the wow factor, we can ask software vendors to make new functionality all day long, or we can take what we have and make it work.  A very special thanks goes out to 3 people, for helping with some last minute API troubleshooting we had with out toolset:  Adam Sheather, Jason Howden, and Frank Fralick of Beck Group. Ironically, once they fixed the app, i had a typo in the parameter name, during the live demo.  Well, thats what i get for not staying in Powerpoint Safety Land. Always good for a laugh, right?  Thanks for presenting, Scott. Check out the datasets and the handouts here:

The Fireproofed Revit Model

RTCNA- God is in the Data

God, i had a riot teaching this class. If im being honest, i only got 90 minutes of sleep the night before. I was petrified at the concept of teaching Excel in front of the Revit Community.  I am *not* an excel genius, and most of what i did in this class was taught to me by a former colleague Cory McDermott, while we collaborated on making Room Data Sheets and FFE Packages out of Revit. Hes a bit of a badass, and he taught me some psychotic things in Excel.  Many thanks to you, buddy.

So lets just get this out of the way:  I know doing this stuff in Excel and Mail Merge sucks.  I know a real database is better.  I know there are tools that are better.

Ironically, we did this in house because we HAD to.  Buying software isnt always in the cards.  Setting up a database or deploying Access (its not on our machines) requires IT and/or Management, and i like to say:  Im in this for the users.  Sometimes you have to use what you have, for the short term.  I submitted the class after sharing our workflow on RevitForum.org, and at the suggestion of several users there.  I was surprised at some of the snide and haughty comments on twitter, about it.  Its like... Im good with it, if you are too good for our workflow or if you have unlimited budgets and IT control to deploy a better solution.  But dont flex on me because youre a twitter badass.  Thats why i practically hate writing now. Its not enough to want to share and help people, you have to worry about internet tough guys. What a joke. What can i say?  I know of at least two offices that have now adopted the workflow.  Which means even if its hacky, it helped someone.  And thats all i ever claimed to want to do.

Check out the Materials here, Excel Templates, and Revit schedules, and Mail Merge Templates included.

What would Thomas Jefferson Do?  AKA Classical Architecture in Revit.

I got to talk one last time, about our project at Old Parkland, while i was in Australia.  What made me more proud, was that the person responsible for most of the modeling and actual detailing/Documentation, was able to lecture about the class in Chicago at RTCNA.  Its one thing for me to get in front of people and talk about how the content was built, and how we kept the model functional at a hefty 800MB of a lot of individual bricks and stone work, but id rather an actual user get up there and talk about their experiences.

Im proud of our Parkland Team, and we even had a Happy Hour that followed a Jobsite tour of the current state of the project, last night.  Its coming together well.  A lot of people have hated on this project as well, and i concede that Classical Architecture isnt for everyone. In the end, however, its the clients satisfaction were after.  And that trumps more twitter tough guys. :)  Classical Architecture lends itself very well to the parametrics of 3D Modeling, and it was a trip to get to make it work for us in the detailing of this building.  I know i have a new appreciation for the classical architecture education i DIDNT get, ha! In Mia's class feedback, someone mentioned they were disappointed that the nested parametric radial array wasnt explored live in the class, to talk about how to build it.  Probably the one thing Mia forgot to mention in the class, is that those families themselves are included in the dataset (of both lectures, AUS and NA).  We proposed an entirely separate class on the Parametric Radial Array, because unfortunately those families can eat up the entire 75 minutes, without the rest of the Building. LOL.  We threw the Cycloid in for good measure.

If you want to check them out, check out both class sessions Materials here:

Classical Architecture in Revit: The Old Parkland Project

More fun with Deployments and User Experience.

So ive been home for a month now, since RTCNA in Chicago.  Were late as heck, deploying 2015 this year.  Thats due (mainly) to some disappointing infrastructure struggles, aside from my travelling.  So getting a late start, i got to work (for the third year in a row) with Gordon Price's Pragmatic Praxis Deployment toolset.

Gordon took on a pretty serious endeavour this year, as he stripped his entire product offering from last year down to nothing, and rebuilt it on a Powershell backbone, instead of a VBS backbone. The switch made a lot of things more graceful, but it also meant MANY more possibilities, and options in the scripts. Some of the biggest changes (for us at Beck Group) are the inclusion of:

1. Machine Conformity.  You can now create "Software Package Sets" (lists) that reside on the network. Then to update any machine in the future, you no longer even need to kn

ow which script to run.  You simply run one called "Conform" to every machine, regardless of which Software Package Set it uses, and it can uninstall platforms, or addins, or install platforms and addins, to conform to that master Spec.

2. More User side customizations.  Where last year we were running certain addins from our Networked Locations (which causes a performance hit on revit startup time), this year we were able to come up with a better solution with his tools:  I keep a current "copy" of the current addin version on the network, and daily at each login the Px tools copy it in to UserRoamingAppData Addin locations.  Meaning EVERYONE runs addins locally, but they're automatically updated whenever i change the copy on the network.  Were doing it with Family Browser, Beck Points, and.... Dynamo. :)

3. Machine Relocations. For the offices like Beck Group that dont have a DFSR or unified and identical file structure in every office, Gordon now how included "Location based" tools.  It means several thousand lines of code less in our Definitions file, and it means to "repath" all software from one office to another, i change one variable, and tell the machine to "Conform."  And its done.

You know, Design Technology Software Support is so much more than being an expert user.  Its being an expert user, knowing the ins and outs for installations, deployments, configurations, for setting up a positive and predictable user experience.  Its 100% possible, using these tools, to keep every machine tidy, and keep every machine identical, for a predictable experience.  Thats worth its weight in gold, in a large company.  We've been using them for three years, but i am a BIT dismayed this year at how hard im having to fight some "internal struggles" to want to keep things organized, and deployed in a predictable fashion.  If it turns out i lose the 'good fight,' and the powers that be decide to handle their software configurations and deployments through some other means (and other staff), than so be it.  But, you should look at this stuff now.  This file may read like gibberish, buts its a log of a trial run from this years deployment.  Yep, a single click.  And while i typed this, it assured removal of all programs 2011-2014 (except revit), and deployment of all 2015's, and REconfigurations of 2013 and 2014 revit, for our new addin setup.  Thats a lot of mileage with a single click.

Not only that, but its deploying Revizto, Archvision Dashboard, and Dynamo, too.  And its disabling the Autodesk Application Manager, since some platforms force install it.  Not bad for a double click, eh?

So yeah.  Between that, and helping some project teams get some kickass work Designed and Built, ive been plenty busy this year, and haven't had the time or energy to write much. Hopefully i wont be such a stranger to my own blog the rest of this year. =)

Revit Technology Conference 2013- Australasia

My "Calender Sunday" is on its 34th hour, having just crossed the International Date Line on my way back to Dallas following the Revit Technology Conference Australasia, at The Langham Hotel in Auckland, New Zealand. This was a bit of a different trip for me, since it was also a personal vacation that let me bounce around the country of NZ for a few days. 

 

Culturally and experientially, it was a wonderful experience.  A few days on the south island, including an island wide drive, days of hiking, and meeting a bunch of great people, then heading to Auckland for the conference itself. The country was a phenominal host.  People going out of their way to ask if i knew where i was going (i nav with paper maps while i walk), people recommending things, stopping to talk with me everywhere i went.  Fantastic Country. Finally, i made my way to RTC on Wednesday of this week.

 

Generally when i attend conferences like RTC, there are three things i absolutely relish during the experience: 

 

Amazingly Graceful Constraints

The first is the elevated education level that only comes from getting lectures from REAL users who do this stuff day in and day out, and this conference did not disappoint. 

I wont call out "favorites" because i know *I* get sad when im not on others lists of favorites, but there was some serious classware going on here.  I made sure to sit through (or read handouts from) many Adaptive Components and Repeater Classes (I was distracted by someone doing the repeater...).



Tim Waldock does Repeaters



Tim Waldock (Awesome Repeater Magic!), Alfredo Medina (Repeaters with FT parameters based on Repeater location placement), and Marcello Sgambelluri  (Adaptive Components doing just about everything (very cool, even if it gives me implementation heartburn...;) )) all gave me many things to think about teaching during some lunch and learns.

 

Its always humbling to be around such great talent.  Its even more humbling to get to teach for them.  Especially when you forget youre in New Zealand, and ask how many people in the audience are using the National CAD Standard graphical standards.  That gets more awkward when you forget where you are and say *Oh thats right, none of you are from around here.*  Uhhhhh... Anyway.

 

Gala Dinner: Great Talks

The second is finally getting to shake hands and talk (commiserate?) with so many people from our Revit Community, and in THIS the conference excelled... As it always does. 

I got to meet so many people in person for the first time, after talking on Twitter or RFO or Blog Comments for months or years. I got to meet Andy Milburn in person for the first time, and he and i took turns heckling (and #tweckling) Marcello, which was great. =). I also got to meet the entire crew from Christchurch, whom even invited Steve Stafford and myself down early for the #RUGCC, which was an honor! (BTW, i owe you guys some materials, will post them once im home!).  And, while on early vacation, i got to finally have a drink (and lunch, and wasp trapping...) with Phillip Miller, after 4 YEARS of emailing and Instant Messaging.  Awesome! 
 

Steve Appleby and i at Dinner

I have to be clear though:  It isnt just a meet and great schmooze fest, either.  Thats what i LOVE about RTC. Three nights in a row, i was sitting in the Hotel Lobby Lounge, talking shop with others until 3 in the morning.  Great conversations that always lead to more questions and new answers. I cant say enough about the great talks that were had.  And the "Brothers in Arms" feeling of fighting with hardware and software together (Phil Read, Adam Sheather, Silvia Taurer, Wes Benn, and Steve Stafford)... This event always sends me back to my office ready to take over the world (again) after meeting so many passionate people who fight the same fight i do every day.

 

The final thing i always enjoy about these events, is the opportunity to Meet and Greet, and share our dreams/passions/war-stories/jokes, with the Software Developers themselves. 

Some of the best conversations ive had with Revit Developers, and Autodesk Staff in general, has been at RTC Events.

 

Sadly, they werent here.

 

Obviously its none of my business why, but the disappointment is NOT the type of "im angry at Subaru for not inflating my ego after i already bought their car," but its more like the "Im disappointed my father didnt think it was important enough to play Catch, in the front yard."  Granted, we have already all bought our licenses, so there is little money to be made. But this is an event put on by GREAT people, to "rally the troops" in an industry that isnt always willing to take on what were pushing.  If you work in sales, "selling the software" is the end game.  Thats polar from us, where thats "go time."  This is the Rubber Hits the Road convention, and if Subaru (or Dad...) was there with me, i think we would have a better Race Team (or family).  But i digress.  To be clear: Its not a slam, its more heartbreak than anything else.

One of my favorite RTC memories of *all time* was standing around the Huntington Beach Dinner Venue, talking *shop* with the Autodesk Reviteers, for HOURS.  Anyway, thats a decision well out and way above my head... But you guys were missed.  Maybe we can toss the football around one day soon.  Or maybe not. :-/ (But Daaaaaad....)

 

One more special Thanks to Wes, and the entire staff at RTC and the committee.

In 2006, when i first submitted my first class to Autodesk University, i had emailed a prominent Revit User on AUGI for advice.  They told me "not to give up, and to keep the passion, because sometimes teaching its thankless." What he meant was, its a LOT of work, and the reward isnt always there. (But teaching at RTC is amazing because everyone is so in to it when its happening, hence im trying to teach at as many as i can!)  But, the entire RTC staff and committee puts this entire event on "for the love of the game," and for us: The Users.  (Tron fights for the users!) And they do a splendid job.  This is their passion, and they share it with us so we can share ourt passion with each other, in a very personal, close knit venue. I also say thank you to any event organizer who will- not only TOLERATE my bullshit antics- but celebrate them, bequeath me presents, have me parade around on stage, and send me home in Colored Toe Socks as a reminder. =)

 

And in closing:  The Air New Zealand Safety Video.  First, because they are the first airline to actually hold my attention for 4.4 minutes, and second because (as someone with a serious affinity for Accents, i fell in love with Marina Roodt in the same 4.4 minutes.) I dont know what Haere Mai means, but i like it.

 

 

By the way, if you read this far, email me for your Gold Star.  If you are interested in seeing pictures from the entire journey, they are in a Public Folder HERE. I didnt seperate my vacation journey from the RTC pics, so they are all together. Hope you enjoy, i know i did!

 

 

"The Helen of Geometry"

 

... Otherwise known as the Cycloid.  Not gonna lie, i had never even heard of the mathematical description before, and the reading on these fine shapes is absolutely astonishing.  But i digress.  Last week i was showing off one of our projects (the large "classic" Brick building), and if you see the image from last weeks post, there is a very wide Stone Arch above a drive lane coming under the second story of the building.  Early in Design, a lot of the Columns, and Capitals, and Profiles, and Trim pieces were appropriately placed in rough form, and as the design progressed they were iterated in to something properly proportioned for their appropriate style.  So, they bequeathed me the Wikipedia entry describing the shape of the Cycloid, a.k.a. The Helen of Geometry, which is what shall actually be placed above the Drive Lane.

The math behind it sounded pretty entertaining to me, although i admit pretty quickly that Grasshopper is probably a much better candidate for something like this. EDIT:  Zach says Python as well... Still, armed with wikipedia and Wolfram, providing formulas for coordinates and arc lengths along the form, i figured it was doable.  My first attempt seemed pretty straightforward: 

 

Armed with formulas for X and Y along the shape, i would generate 10 X points, all equidistant.  Their X distances calculatable since the overall width of the form is a direct relation to the Radius of the acting circle (The width is an unrolled circumference of the circle, exactly).

 

Then, id use the formulas to generate their Y coordinates, based on those X's.

 

(Let me start by saying:  I am not a world leading mathematician.  I got through Calculus like a champ, but i dont know how i would put a Differential Equation in a Revit Family.  That takes some Buildz skills.)

 

You can see in the image that the final product didnt go the way i originally planned, but thats because there were options:  I had intended to plan the X values, and infer the Y values based on them.  You can do it, as Wolfram has a badass Equation describing X and Y in relation to one another.

 

But there wasnt much point: My intent was simply to have an instance parameter in the family that let me type in a value from 0 to 1, with decimals.  (0, .1, .2, .3...).  From there, i wanted it to build the Y values.  But did i really care if it put them at predefined X coords?  Negatory. So in the end, xPercent still exists, but now all of the families "sit" on the same origin, and the X coord is also "pushed out" using the formulas, instead of locking the different instances to the reference planes.  It involves a few wacky variations moving between degrees and radians (and a "Number" since we know how Revit is about units...), plus a throwback reference to David Light's blog on how to enter Pi as a variable in Revit "Pi()".  That was handy. =)

 

After making it so the users could input either "r" or the CircumferenceTotal (a.k.a. the width of the drive lane), it was a Connect The Dots exercise.  I am still IMMENSELY frustrated that the Conceptual Massing / Adaptive Component Editor is the only place we can Spline Through Points (where points are the end of other Model Lines) and have them stay constrained.  But i digress.  No, i dont digress.  It pisses me off.  Because an AC cant nest in to a Face Based Family, and its not an AC for ANY other reason.  Which means i have to have my project team place an Unhosted component, then edit the Profile of a wall to trace the stone Cycloid, which they cant "trim" the sketchlines of because its a Picked Spline.  REALLY?? Sigh. (Ill post the imaged in the project once they refine the placement and the Profile). BTW, there were other issues, as well.  In a REAL Cycloid, the 0 point and the 1.0 point are tangent to vertical.  In Revit, a Spline through points wont let that happen.  I even placed two additional vertical points underneath the 0 and 1.0 points to force it *tighter,* but it doesnt matted.  So it takes a void to lop of the bottom of it.

 

Anyway, since thats the case, Adaptive Component it is.  The AC has a nested "Stilt" family, and thats whats doing everything except Connect-The-Dots, which means we will use it "for reference" inside the Window Family where we need to describe this shape as well.  The Window just wont be able to be parametric.  I would love for every Line to have Reference Points at the end that could be woven through, in the traditional Family Editor... But that continues to be my wish. 

 

Wrapping it up, the obvious question (i hope) that i had to bring to the Design Team was:  Whos building this?  And how are we documenting it?  The reason being, while a Cycloid is graceful to form in a GIF image at the top of a blog... Its awfully close to a semi-ellipse, which is awfully close to approximated arcs.  Im all for modeling it correctly, but im all for having it built correctly as well.  And if they arent going to bother, i can certainly make tangential arc segments in the traditional family editor with far less effort, and then we can tie down real X and Y dimensions for the subcontractors.  In our heart of hearts though, we wanted a Cycloid.  And... As a small part of me hopes we end up the GC on this job as well (at which point we can zing out some awesome fabrication models from this information), we figured we would do it. 

 

Its full value for the Project will ultimately live or die on "what happens" with this geometry now that its there.  It must be described for its audience, in such a way that it can get built as desired, or transmitted in such a way that it can be used again.  Otherwise, having a fancy Revit Family in a fancy Building Model just to hack dimensions on it is rather... well, basic.

 

Here is hoping we can keep this somewhere past basic.

 

 

The Elusive Origin aka The Original Origin aka Not the Current Origin

I must admit:  It has been a few years since i ran up against this problem, even though i was reminded of it while explaining to someone interally why there are THREE origins in Revit:  Shared, Project, and Relative.

 

Alas, this isnt a post on Shared Coordinates, just a small reminder about another gotcha that appears in the Family editor:  The Original Origin (The Elusive Origin) versus the Real Origin.  If you know me well (or if you dont know me at all), you know one of my hundreds of obsessions is Door Content, and how it affects Architects abilities to document efficiently... Of course, the bigger picture is:  What does it REALLY mean to document doors correctly for buyout and installation?  But ill check that at the door.  Todays is a smaller issue. Im redoing the CW Doors in addition to the Regular doors to make some changes:

 

1.  Parent Families by Action.  (Most people do this, my last library iteration was a bad choice. The "action" definition was part of the Panel Type.  Horrible idea.  I have to own that).
 

2.  Panel Typology including Materiality (not finish) at the Type Level, not instance.  Less fields in the "door schedule" as more is defined by Type of Panel.
 

3.  More options to reflect the real world.  This meant adding in the potential for CW/SF doors to have a Frame inside them as well.  Sometimes Doors in Storefront Systems get an additional frame jamb and head aside from the surrounding mullions, and i wanted that capability.  So the new options looked like this. (You can see the door at left has the frame).

 

But we all know the way Doors are Curtain Wall Panels in Revit means you get two choices: 

 

1. Door Panel Sizes flex with Curtain Wall Grids, runs risk of Door Schedule showing wacky Dims.

2. Door Panel Locations flex with Curtain Wall Grids, runs risk of gaps in between the Doors.

 

I personally prefer the latter.  Reason being BOTH infuriate Project Teams, but the Door Schedule is sometimes already seen as a WonderWall of data that is more like PowerBall and less like steadfast decisions.  So any chance i can get to make the schedule not go nuts, i "jump in it."  But, i also have Check Value Reporting Parameters in our Curtain Wall Doors.  They tell the user how much they have to adjust the CW grids to make the model AND the schedule legit.

 

While working on my new CW Doors to finish out the Door Library, i found this beauty:  A rogue 7/128" hanging out somewhere between the CW Grid dimensions (which are correct:  All dims and units are rounded to 1/256" in our files), and the Reporting Parameter dims of the Doors.  Nicey nice. First i tore through the Door (CW Panel) itself, assuming i had missed something minor... But there isnt even any complex math in it.

 

So then i realized whatever it was had to be in the Mullions of the CW/SF in the Project.  Joy. Although it drives people crazy, we have a LOT of Mullion Types, and a lot of Profiles, so we can accurately model varying shim spaces, glass pockets, etc.  So i opened up the Mullions, and re-certified that the Origin-defining Ref Planes were locked centered.

 

Then i remembered this minor bit of stupidity that hit me back in 2009, when i was making NCS Compliant Section Heads in New York State:

 

That Revit sometimes forces you to use the Original Origin of a Family, and not the currently defined origin.  In that regard, its sort of like Relative versus project.  And in the Profile Family editor, you cant see origins (aside from ref planes), so i pulled the old school "Insert CAD drawing with an X at the origin OtO, and see where it comes in."

Sure enough, it wasnt sitting pretty on the 2 ref planes that were defining my origin currently... It was the ever elusive 7/128" off that my Curtain Wall Panels were reporting.

 

Thankfully its got an easy (albeit stupid and shouldnt be necessary) fix:  Picking up everything in the family and moving it towards to "original" origin by the offending amount.  In this case, 7/128".  I hadnt seen this issue in a number of years, so i forgot that back in the day it caused a few issues for me where Section Heads had a gap from the system Witness Line, and tags were somehow offset from the leaders that were supposed to be touching them.

 

It still feels a but odd that i can have Reference Planes Defining the origin and have them not be the Finite Origin that all things referencing that Profile are, but i guess its just another day with Revit.  

 

Having solved that riddle, everything now appears to be playing by the rules.  I cant say my users will be any more happy to have these CW Doors over the old ones (they are Revit Curtain Walls, after all), but they will be more functional, and will more accurately represent what i would like them to be for Documentation and Construction.

 

They certainly havent gotten any more difficult to use, even if the CW Doors are a "wash" with the old ones.  These are compatible with our new Wall Hosted Doors, which (i think) are worlds better than the last set. 

 

At the very least, i got to have a nice stroll down memory lane relearning things i forgot i used to know a couple of years ago... And now we can all make jokes about the Elusive O... O is for Origin.

 

 

 

Malleristic BIM travels

 

 It always amazes me when i look back at the blog and realize three (or five) months have gone by since ive had a chance to update it.... But thats how the last few months have been.

 

Since the last post on the Deployment Debacles from 2013, ive been a Maller on the road:  A stop in Toronto to talk at SolidCAD university, while visiting my hometown in New York, and then the typical 4th quarter jaunts to Autodesk University and the Autodesk Gunslinger event.  But more recently, i was able to finally spread my wings farther than the confines of North America, to make my way to London for a respite from my day to day.

 

Being the passionate work-crazed folks that we all are, of course i turned the personal vacay in to an opportunity to meet with several of the BIMCrew's in the United Kingdom.  There were several nights out with folks from the UK Crew (as well as meeting a fellow RFO enthusiast!), and there was a quick run to Scotland to speak with the awesome folks at the #GRUG. 

 

While this post is light on technical content, i HAD promised both the SolidCAD crew and the Glasgow Revit Users Group that i would post the presentations that i gave, for them to download and look back on. 

 

Presenting and talking with folks in other countries was an eventful experience for me, though.  Having made Twitterquaintance with more people off North America than on it this year, its been an experience to discuss differences- not just in culture- but the state of our governments, the state of our industries, and how it impacts what we all do and champion in our work environments. 

 

What started out as a conversation on leveraging Design Models for Fabrication in Construction at the #GRUG turned in to a conversation about what to share with people downstream (everything), who to let in to your models (everyone), and how to navigate those waters contractually.  Therein, the differences in countries became paramount, and i was excited to spend time talking about such things.  At the end of the day, all the complex modeling in the world is useless if the *people* in the process cant or wont leverage such things. 

 

The differences were staggering, but in neither a positive or negative way.  Time spent abroad- watching other peoples movements, talking in slightly varied vocabularies, and questioning the ins and outs of traffic patterns (special thank you to the wonderfully special person who pulled me out of traffic at least ten times when i tried crossing the wrong way) made me stop and think a LOT about Revit and Modeling: 

 

That countries and locales function so differently in many ways, is it the best we can do to know our own devices and methods?  The constant joking we did all week long about Imperial versus Metric, and about driving and shifting transmissions from the wrong side of the car (Darryl...) made me realize:

 

Its really not enough to be doing the best that i can in one country.

 

Ive met so many insanely intelligent people working towards the same goals, but were all working on islands (pun intended) seperated from one another, but working towards the same goals nonetheless.  Certainly there are limitations (in pay grades above our heads (IE Decision Makers)), about how many resources we can share, but the more i look at this the more i know we (as a small group of BIM enthusiasts) are meant to do more than push our offices farther.  We need a vehicle, for reaching a Global platform.  More on that later.

 

So, for the imagery... If youve seen these presentations before, i apologize for being boring.  But as i promised the SolidCAD Crew and the GRUG crew, find the PPT's and PDF's at the links below. Because of the way my powerpoints are always set up, i get that the images dont read well in the PDF's.

 

There are also videos in the presentations, which are hard to upload and tie back together.  If you ever want to see the videos, shoot me a message.  Happy to share or host, if it is of any value to someone.

 

Glasgow Revit Users Group- PDF.

Glasgow Revit Users Group- Powerpoint

 

SolidCAD University 2012- PDF

SolidCAD University 2012- Powerpoint

 

By the way, i hpoe it goes without saying that i dont post these thinking they are anything more than what they are:  One small groups workflow that happens to get us through some specific needs.  They arent an end all solution for the industry, to be sure.  Having said that, please email if you ever want any of it explained.  The more people we push ahead, the better.

 

By the way- Here is a video from Youtube.  Its the Chrysler Motor Corporations full advertisement for the new Dodge Dart.  If you are in the US, youve probably seen this.  If you were at SolidCAD Uni, i played it at the beginning of the lecture.  While its entertaining, its also extremely relevant.  (The Finance Guys, and the Committees... Who are they to you?)

 

Have a laugh, but get inspired too... Even if its not that great of a car. :)

  

 

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/