Tuesday, February 19, 2008

My first "negative" post

I'm a pretty positive person, but when I smell an odor I don't like, my face will show it. So please accept my apologies for this somewhat negative post. It doesn't have to do with Revit, but it has to do with the direction that the marketing engine within Autodesk seems to be taking.

Autodesk is hosting World Press Days and thanks to the wonders of blogging, you can see exactly what is going on almost in real time. Take a look at this post and judge for yourself. I love fish, but I don't like the smell of this.

Now I don't know about you, but it seems that Autodesk is going to take the route of pushing other products into our industry and this makes me very pessimistic regarding the improvement of Revit's modeling tools. The beauty that most of us see in Revit is the fact that it brings together a lot of people within a firm that are talented in varying parts of project delivery. I find that the use of Revit helps to build a better team, a wholistic work environment. When we allow a practice to be fragmented in departments and separate disciplines (design separate from documentation for example), it gets to be quite destructive in the long term. BIM is not an easy thing to implement. Learning Revit or any other BIM capable software is a monumental task. I shudder at the idea of having to learn/teach/support more complex programs in order to find the forms that create great architecture (ps: most of us don't really need fancy tools as we don't design blobs). I'm not advocating the use of only one tool: always use what's best to craft the idea that's brewing in your mind.

Now you don't need to be a rocket scientist to understand that the larger the number of products you own that can be sold separately, the more money you can make. I honestly hope I'm wrong, but this marketing strategy doesn't bode well for making Revit do a lot more than it currently does. What's the incentive if Autodesk can sell you more software? Keep in mind how hard it is to learn and teach complex tools and use them at full capacity....now multiply that by 3 or 4.

I would rather learn a complex software so I'm able to use every single tool available properly and produce at 98% efficiency, than learning 4 different softwares that have different interfaces and lots of different tools to achieve different things, and be lucky to hit 40% efficiency. I'm not so sure it's "healthy" to have desigers becoming specialists of designing in one software versus another one. By the way, I know that already happens, but now if we introduce more packages into the mix, we start losing the fidelity that we're all striving for in a BIM environment, requiring us to hire a lot more software expertise within firms, because you need even more specialists to understand the complex behaviors and interactions between different software packages.

At the last AU, one of the big points that Autodesk made was that they were going to focus on interperability between their software. I actually chuckled when I heard that: partly in disbelief that such comment was a key hot topic of Autodesk's strategy (hmmmm, what have they been waiting for to make this happen?!) and partly because of a dose of cynicism that this could actually be achieved. And as I said, if the key goal is to sell us software, our industry will get tools that aaaaaalmost get us there: "But hey, if it doesn't fulfill all your needs....take a look at what other wonderful tools we can sell you to get you there!"

Ok, I'll put an end to this. I promise to be more positive next time :) I would really like to hear your points of view. I hope I'm dead wrong about my perceptions.


Share/Save/Bookmark

Saturday, February 16, 2008

Excellent Blogs

I have been recently following Greg Mcdowell's blog Life's too short to drink cheap wine. It deals with Greg's thoughts about BIM (and Revit) and professional practice from his perspective. I think he's got an excellent writing style and I really relate to most of his thoughts on the subject. I just had to recommend this blog!

On a slightly different subject (corporate culture, marketing, thought-provoking dialogue, etc.) is Seth's Blog (from best selling author, Seth Godin). Both these have now become part of my daily routine :)


Share/Save/Bookmark

Thursday, February 14, 2008

"Balustration"

I was in a state of baluster frustration last week as I came across a couple of things that flustered me for some time until I realised that I wasn't losing my mind!

Railings can be quite complex and I see users struggle with them quite often. You can pretty much achieve any design you want, but it takes some serious muscle to master this tool and a lot of trial and error.

The railing tool is a System Family made up of a series of horizontal Rails and vertical Balusters. Rails are defined through Profile families - imagine them as beeing sweeps. You define a vertical height, a horizontal offset, a profile & a material and you're done. Balusters are a little more complex and we need to assign the main pattern and then define the posts by selecting a Baluster family and defining the spacing rules, offsets and materials. Balusters could be a simple round or square post or a complex panel, depending on your design.


To master this tool, you have to spend some time experimenting and trying out what each parameter does. The most challenging part is building a complex baluster panel family that flexes correctly with the angle of the stairs/ramp in your project. But here, I'll highlight just a few problematic baluster issues so you can steer around them and not get stumped.

In the Railing Type Properties dialog, the parameter Baluster Offset offsets the baluster in the same direction as the Offset value in the Edit Rails Dialog. However, the Offset value in the Edit Baluster Placement dialog moves the baluster in the OPPOSITE direction of the other two parameters. This was reported and confirmed as a known "defect".

The main problem with this is that for example, if I use an offset of 3" for my rail and then I type in an offset of 3" inside the Edit Baluster Placement dialog, I end up with a 6" gap between the centerlines of the rail and baluster, whereas you would expect their centerlines to coincide! If I then type an offset of -3" in the Edit Baluster Placement dialog instead, the rail and baluster centerlines coincide, but the baluster top will not stop at the underside of the rail and will instead go to the top of the rail.


For the post top to properly clean up, the two baluster offset settings have to be either the same value, or the offset in the Edit Baluster Placement dialog has to be zero. This means that one should avoid the use of that offset value and instead use the type parameter "Baluster Offset". If you have multiple baluster patterns with different offsets, that might not be possible.

Another issue is that the Baluster family origin seems to be fixed. If you move the reference planes that have the option "Defines origin" checked together with the 3D geometry and then you reload the family back into the project, the baluster geometry will move. This shouldn't happen because these reference planes are supposed to define the origin. Since the relative distance between them didn't change, the geometry shouldn't move when the family is reloaded in the project. This seems to be an issue with the baluster family templates.

One last thing...in the stair image above, notice that the leftover spaces are filled with vertical baluster posts that go all the way down to the host surface. If we look in the Baluster Placement dialog, you'll notice that there is no control over the Top and Base (plus offsets) of the "Excess Length Fill" optional balusters.

If you want the vertical fillers to be located off the host surface, you might have to create a custom baluster with the correct offsets and number of balusters built into the family. I'll go into more detail about this in a future post.


Share/Save/Bookmark

Tuesday, February 5, 2008

Who's in the CENTRAL?!

Haven't you ever heard someone yelling that phrase across the office? Well today I was more collected as I tried to solve a problem that popped up in one of our Revit projects. And oh by the way, there are cases where you could work in the central file, but unless you REALLY know all the nuances of worksharing in Revit, I wouldn't risk it (talk to your local BIM Manager for details...)

A user was complaining that he couldn't Save To Central (STC). I went to take a look and found that he was getting a dialog with a Cancel button and a key symbol, saying that the Central is being accessed by someone else (don't you wish it would also tell you the username?). This dialog typically disappears after a while and can pop up if two users try STC'ing or borrowing elements simultaneously, or if your network is really slow. For some reason, this dialog was persisting and would not go away.

My first instinct was to see what the Worksharing Monitor tool was reporting. The tool wasn't installed so first, we saved the local file, exited Revit and installed the tool (by the way, if you have an early build of RAC 2008, this tool will report and recommend that you install a newer build as it is not compatible with the June 2007 build). The Worksharing Monitor reported that two users where working in the Architectural Central file.....both where in the Structural group. Let the blame begin!

A few seconds later, one user dropped off the list and I could swear that the remaining user knew better. So I go to his desk and as expected, he wasn't in it (Revit wasn't even open). I tried opening the central file from this machine and auditing it, but the same dialog popped up. Even a Detach from Central resulted in the same thing. Next I tried to rename the file to confirm it wasn't physically open on some machine and it let me, which confirmed that no one had it open. This started to hint at a network problem.

I called up our Network Administrator (another David!) to see if anyone was accessing the Central file, but no one was. Interstingly enough, the Backup folder in the Central File folder showed up as being accessed by the user that raised the flag the first time, even though he closed out of everything. So David worked his magic and forced him out. We tried opening the Central and....ahhh...it worked! We were able to re-open the local file and save the work back to central.

The Backup folder contains a lot of rws and dat files that Revit writes so it can keep track of permissions etc. You should never mess around with this folder. So if something like this happens in your office, take a deep breath and lay that brick sample down (ouch!) and troubleshoot for any network issues before assuming that the central file has become corrupt.


Share/Save/Bookmark

Friday, February 1, 2008

My First Revit Project - Part 1

You're probably saying...you got it backwards Dave! Well, not really. It was all calculated ;)

I planned to visit several projects last Wednesday and I wanted to get some good pictures as I walked my first Revit project. Everyone on the team is very happy about how the project is turning out. Since the learning curve was fast and furious, we're calling it a "painful success". It sure paved the road for other endeavors. You have to start somewhere!

This Junior High School is slated to open in August and we're hoping it will be at Substantial Completion in June. I'll keep this post devoid of text and let the images speak. You'll also see some sectioned shaded views and other Revit presentation materials. Feel free to post comments with questions if you want to know more.


Library

Entry


View towards Entry


Commons

Second Floor

Adjacent to Dining Room

Fine Arts

Overall Exterior

Library Exterior (Bottom is a Revit shaded view)


Share/Save/Bookmark