Invalid References

Ever see this message?

There are a number of reasons why it occurs. This is one example that can occur when swapping families. Not all families are created equal. Shocker I know...sorry. When you swap one family for another after applying dimensions you run the risk of confusing the dimensions. Let's take this simple family, GM01.rfa.

The Right and Left reference planes have corresponding names and IsReference settings. Now lets look at GM02.rfa

In this family I've made a mistake (on purpose of course), the Right reference plane has a different IsReference setting, it is set to Weak Reference. Technically the family is also a little bit wider than GM01, but that won't matter. If I've added dimensions that reference this family, as soon as I try to swap GM01 for GM02 I get the message I mentioned at the beginning.

The essence of the warning is that something has changed in a way that Revit can't transfer the dimension reference to the new object. The tricky part is figuring out what that "something" is. Sometimes it is how the family is made.

[Edit: Btw, I wrote, and scheduled this to post ahead of time, in response to an question via email and a last night I read a post at RevitForum.org that asks why almost the same thing is happening. Serendipity.]

Working in the Central File

We are supposed to work in local files. Occasionally people will fire up Revit and end up working in the central file instead. These days it is more deliberate because they have to un-check the Create New Local option to do so.

Revit has been tweaked over the years to deal with central file editing. I've read claims in a couple books recently that working in a central file prevents other users from using Synchronize with Central (SwC). It isn't true in my experience. If I'm working in a local file I can use SwC as much as I need. The person working in the central file on the other hand will be forced to create a local file when they try to use SwC. They'll get this message.

I can work in a central file as long as necessary, as long as nobody else is working on the project in local files too. Isolation is fine, collaboration is where the conflict arises. We encounter the message above when a change has been made via a local file while the central file is being edited. While someone is editing the central file a local file user has been able to add or alter an element and then use SwC. When the local file user completes a SwC and the person working in the central file attempts to use SwC the central file editor will get this message (remember Save is disabled in a Central File).

The message also explains how to resolve the situation, just Save As to save the file with another name, which turns it into a local file. Now SwC will work.

There are some legitimate reasons to work in the central file, just do it in isolation.

View Discipline

Daryl wrote on Monday that the concept of View Discipline isn't documented well. Software documentation tends to be a bit dry, too often a very literal, "Un-checking this turns the feature off". Well that is obvious but "why" would I want to turn it on or off? Unless it is truly self evident, why a feature exists is a bit more involved but much more satisfying help.

The concept of View Discipline appeared with Revit Structure. It was meant to make it simple to alter the appearance of our model to be more in sync with what a structural engineer wants to see. When MEP (Systems as it was called then) appeared a year later they extended the concept to Mechanical and Electrical (plumbing lumped in with Mechanical till release 2013).

Daryl used plan views as his example of how the help documentation isn't accurate. Plan views are not the best view type to see the truth in the help claims. Ducts for example, he wrote, don't show up when the architectural discipline is chosen. They CAN show up, they probably won't be visible because they are above the cut plane. When Mechanical is assigned Revit changes the nature of what plan and reflected plan mean. Ducts at 10'-0" AFF will appear in a plan view with the view discipline Mechanical assigned. They won't with Architecture. They are there, just above the view.

This subtle change occurs because the notion of a plan and reflected plan view means slightly different things to architects and engineers. A reflected plan, architecturally, means that elements that are lower mask elements that are higher, such as a ceiling and light fixtures mask elements above that ceiling. A HVAC plan is different because most engineers want to see the highest duct masking lower ducts. It isn't a reflected plan, it is a plan whose cut plane is, in a way, altered to be above the highest elements and "look down".

Technically the view range settings can be identical but switching to mechanical discipline will show ducts that weren't there a moment ago when architectural was assigned. They were there but the discipline change altered how Revit calculates the display of the elements. Engineers don't generally do reflected plans so Revit made it easier to generate regular floor plans that show their elements in a way they expect to see them.

The combination of View Discipline, Object Styles, Visibility/Graphics Overrides and View Range are all responsible for what we see in a given view (technically there are more). Changing one of them is not going to ensure that we see what we really want. We've got to make sure they all have complimentary settings. There is no real difference between Mechanical and Electrical disciplines graphically, based solely on the View Discipline parameter changing. The views dedicated to each of those disciplines also use V/G and possibly view range settings to make them look correct. If you examine the stock templates you'll find that these views have each others element categories turned off (with V/G) to achieve the look we are after. Apart from the automatic graphically biased changes they make, they really just help us segregate views in the project browser.

In my own way:

Architectural - All model elements treated "equally", according to Object Styles, but with architectural bias with respect to view range and cutting elements.

Structural - Similar to architecture but hides non-load bearing walls and some hidden line behavior with respect to concrete floors/slabs and foundations.

Mechanical - All other disciplines are half-tone and transparent (help says "on top"), duct and pipe and related element categories take priority and behave according to Object Styles. Mechanical elements like duct and pipe will appear in plan regardless of their true elevation with respect to view range, as long as they are within the Primary Range.

Electrical - Same as Mechanical.

Plumbing - (new to 2013) Same as mechanical.

Coordination - Same as Architectural but provides for segregation from it for easier management of views.

Then there is the Sub-Discipline parameter, a Project Parameter that first showed up in Revit MEP templates. I see architecture firms, that have been exposed to RME, using the same parameter now in their architecture templates because of the added (for consistency as well) control over the Project Browser sorting. That's the essence of the parameter's existence, to manage the Project Browser according to the kinds of views each discipline typically creates. Such as Power and Lighting plans for electrical and HVAC Duct vs HVAC Piping.

Keep in mind that views in stock project templates are also configured to only show certain element categories according to the discipline bias implied by their name and discipline parameter setting. The combination of the View Discipline parameter and Visibility/Graphic Overrides is responsible (among other possible view properties) for the final result of what you see in a view.

Shared Parameters aka Dictionary

A Shared Parameter is like a definition and the Shared Parameter file is like a dictionary.

Consider that a family parameter is confined to a family. It can be seen from within a project but not scheduled or tagged unless it is a built in parameter like those listed under the Identity group (and provided for us by Autodesk).

Consider that a Project Parameter is part of a project and applied to categories of families so that it can be scheduled, but NOT tagged. Like a Family parameter it is "trapped" there, in the project.

A shared parameter bridges both trapped conditions, acting as a definition we look up in a dictionary (the shared parameter file). We store our common definitions there so they can be applied in other projects or families. When you create a family or project parameter using a shared parameter (definition from the dictionary) it is really just another parameter but it has expanded possibilities because it is "shared", the data stored with it can be scheduled AND tagged.

RTC Session Datasets for Shared Coordinates

To the people that attended my session at both RTC events.

I apologize for being slack!

It's been months now since Wollongong (May) and only one less since Stone Mountain (June). I'm apologizing because until tonight attendees couldn't actually get the data set files I promised. I've let this issue slip and slide underneath everything else going on and that's not fair. I did try several different times to upload the data but between spotty connections at hotels, the distance and the size of the dataset the upload kept failing. So finally last night we got past that with Bo's help at the BD Group/RTC Events office...thanks Bo!

Thanks for being patient, even if you gave up on me ;)

Session Title: Coordinating Projects with Shared Coordinates

Session in Wollongong, to login for the Materials: CLICK HERE
Session in Stone Mountain, to login for the Materials: CLICK HERE

You'll need to refer to the email you received that provided the login password for the conference you attended.

The only difference between the files offered? There is one project file with "slides" for each location of the conference. The Large and Small project folders contain the same collection regardless of where you attended the session.

Parameter Related Post Summary

Updated May 30, 2017

Posts from 2005

(2005) What are parameters and why should I care?
(2005) Sharing Parameters - An Overview
(2005) Shared Parameters - Part 3
(2005) Shared Parameters - Part 4
(2005) Making a Shared Parameter File
(2005) When is an Instance really a Type?
(2005) Ignore Good Advice

Posts from 2006-2008

(2006) Walking on Thin Ice
(2007) Family Editor - Parameter Order
(2008) Duct Size Parameter - Inches - Revit MEP
(2008) Dept. of Subtle - Filter Parameter in Tags (really subtle)
(2008) Shared Parameter File - A Little Clarification
(2008) Shared Parameter - No you Can't -Yes you Can

Posts from 2009

(2009) The Order of Parameters - Revisited
(2009) Titleblock Parameters
(2009) Which Group? Choosing a Parameter's Parameter
(2009) Revit Family Style Guide
(2009) Titleblock Parameters
(2009) Dept. of Subtle - Family Editor Parameter and Formula
(2009) Back to Basics: Mark and Type Mark
(2009) Dept. of Subtle - Three Parameter Tips?
(2009) Revit API SDK - AutoParameter

Posts from 2010

(2010) Export a Shared Parameter
(2010) BIM Family Toolkit at Autodesk Labs
(2010) Dept. of Subtle - Parameter Shuffling
(2010) Family Editor - Use a Default Type
(2010) Dept. of Subtle - Omni Class Parameters Missing

Posts from 2011

(2011) Parameters Again
(2011) Parameters Again
(2011) Dept. of Subtle - Family Editor Parameter Lock
(2011) Dept. of Echo - Type Catalog Formatting
(2011) Dept. of Echo - Shared Parameters for Manufacturer
(2011) Family Type Parameter Gotcha
(2011) Revit Content Standards - ANZRS
(2011) Dept. of Subtle - Connectors and Diameter
(2011) No Math Characters in Parameter Names
(2011) Family Category and Parameter Dialog
(2011) Shared Parameter Utility - Revit SP Writer

Posts from 2012

(2012) Connecting Parameters
(2012) Connecting Parameters in Nested Families
(2012) Pushing Parameters Around
(2012) Parameter Grouping
(2012) Shared Parameter Article at AEC Bytes
(2012) The Shared Parameter File has no Relationships
(2012) A Small Collection of Family Editor Advice
(2012) Parameter Pecking Order or Priority
(2012) Shared Parameter Czar
(2012) Which Overwrite is Right
(2012) Shared Parameters aka Dictionary

Posts from 2013

(2013) Working with Type Catalogs
(2013) Associate Family Parameter

Posts from 2014

(2014) Visible Parameter and Associate Family Parameter
(2014) A Case for Project Parameters
(2014) Hidden Parameters
(2014) Parameters with Math Characters
(2014) Setting Yes No Parameters with Formulas

Posts from 2017

(2017) Recover or Acquire a Shared Parameter

RTC AUS 2013 - Seeking Abstracts

Just to further getting the word out the Revit Technology Conference 2013 - Australasia is now accepting abstracts until Wednesday October 31, 2012. CLICK HERE to Submit.

The abstracts requested, at this time, are ONLY for the conference in Auckland, New Zealand this year, May 16-18, 2013. Separate requests will go out for the other two conferences a little later this year.

If you want to keep track of RTC information you have options; Naturally the main RTC Site, and I have a page on this site dedicated to RTC, You can follow RTC on Twitter RTCNA - RTCAUS - RTCEUR and RTC on Facebook as well as the RTC Blog and Linked in and Instagram. We're working on a single You Tube channel.

Have a couple minutes? Considering attending RTC in 2013, then check out this video (00:01:44) to see what RTC is all about. It was created with footage taken from the event in June (Stone Mountain, GA).

Missing Survey Point

Traded a couple emails with Paul Aubin regarding a client's Survey Point that went missing. It turns out that it had been moved up quite high. I'd never tried to move either the Survey or Project Base Point symbols "up" before so it took me by surprise that it could be done.

Moral of the story, take care when you are selecting things and moving them. You could move your survey point unintentionally.

Connecting Parameters

You've just downloaded some content from a manufacturer's site and realize that none (or many) of its most interesting parameters are not going to show up in your schedule. This is due to the lack of a common shared dictionary of parameters that we can all rely on. Revit's "system" parameters like Width and Height for some components (like Doors or Windows) just work automatically. Just starting out with a door template means that at least a couple parameters will work without any extra effort. Not true for enough others though.

The Autodesk Family Style Guide (AFSG) while primarily focused on the needs of Autodesk's Seek site also provides a set of shared parameters we can all use (check out ANZRS too). It's weakness is relevance and timeliness. It has a lot of MEP related parameters but doesn't delve into other disciplines seriously and it's really late to the table. Most of the firms that have been using Revit seriously have already dug into their own shared parameters by now. Redoing their library to be in line with Seek and the AFSG doesn't actually begin to help them unless they really start using a lot of Seek content, which is another can of worms.

Rather than continuing to lament the situation this post is intended to provide one solution to getting "foreign" content to work within your existing project(s) and template(s). Assuming you've already mapped out your own shared parameter strategy you just need to connect the dots between the parameters the family is using and those that you wish it was referring to, your own.

It's rather simple really. Add your own Shared Parameter versions of the critical parameters in the family you are working on. For each, in the formula column enter the name of their equivalent parameter. This maps (connects the dots) their parameter value to yours.

Now you can schedule their component along side your own, even tag if necessary. It's a lot simpler than trying to remap all their parameters to your own by replacing them.

It is a little risky in that people will have two places that the values could be touched, their parameter and yours. I usually just segregate them in a separate Group. Just let your teams know how you are dealing with content obtained from other sources and it's not mysterious anymore.

In-Place Massing and Project Orientation Inequity

In-Place families are necessary for some geometry, in particular the massing environment. I've always stressed that people should start a project without being concerned about site alignment immediately. Revit was (is) designed to allow us to adjust True North easily after the fact. As I've written before, just make it easy to "draw on paper".

A recent post at RevitForum.org underscores that bias when it asked if the two project orientation tools seem to work differently? Actually it was just focused on Rotate Project North (RPN) and that in-place massing didn't play along when it was applied. Rotate True North (RTN) on the other hand does work.

In this image the massing has been created aligned with the "site" but we've realized that it would be easier to document if Project North were aligned along one building edge.

In this image I've used the Rotate Project North and picked the reference plane I sketched to mark the East/West bearing I wanted. I had to rotate the text but the tool rotated the reference plane correctly but the massing is unchanged.

As I wrote in my reply there, RTN is sleight of hand while RPN is really altering the entire model and related views to change orientation. In other words RTN rotates the world under the building and RPN rotates the building on the world. Rotating the world is actually "easier" (less work) for Revit than grabbing every element and everything in every view and rotating it (the building).

If you heed my Two Pieces of Advice, you'll start a project off better...

Revit LT

Autodesk has announced a new version of Revit that they are calling LT. It is the formal repackaging of the Autodesk Labs Project Spark. Users referred to it as a Revit Lite then and it seems Autodesk agreed with the branding.

When you visit the product site you will see it's being paired up (suite pricing) and compared with AutoCAD LT as well as the obvious comparisons with the full featured Revit. A number of posts and tweets have run down the list of things that it doesn't have. Chief among the features that are missing are worksets, design options, rendering (only through Autodesk 360), no export to IFC, conceptual massing, interference checking, and parts or assemblies. The intended customer is the small firm, small enough that no network licensing either is a detriment.

I worked for a firm years ago that this product could work for, a small office where each person did their own work for the principal. Sure, there were projects or design considerations that the missing features would prove frustrating but a single seat of full Revit would probably have covered it, collaboration with outside parties that is. I also worked for another guy once that it would fit perfectly but he'd never pay for it. Still using an ancient version of another brand and probably will until retirement. I have also provided support to small firms via my Revit Lifeline that LT could serve well. I can't help but wonder how they'll feel having paid for full Revit with a less expensive option now available?

It seems unlikely to me that Revit LT will truly serve any notion of BIM other than "lonely BIM". Then again it isn't uncommon to hear people working in the market LT is focused on saying something like, "BIM doesn't matter to what we do." The downside of that perspective is Revit LT may not either.

[Edit 9/6/2012: I received an email from Autodesk regarding Design Options. Revit LT is intended to include Design Options when it is released. It was not part of Project Spark so that information was carried over into the current press release and web site preparation.]

Which Overwrite is Right

When we reload a family a dialog appears asking us how we'd like to deal with the existing family definition. Technically a more involved dialog can also appear if nested and shared families are involved. The first choice or top most button asks if we just want to overwrite the family. The second choice and next button down asks if we want to also overwrite parameter values.

So what's the difference? The first button is effectively acknowledging the changed family but preserving values that we may have entered or altered in the project, they may be different from the original family. Said another way the project is correct (the project version of the family). The second button is challenging the version of the family in the project, in effect saying, "You are wrong, we'll fix that!"

I've seen confusion with this result in uncomfortable changes. For example a standard duplex electrical outlet that is set to 180VA is suddenly reporting 360VA. A user changed the default value for a heavy duty type but accidentally assigned it to the standard type too. A reload with "choice two" ends up creating some confusion, replacing the correct values with the new higher value. This kind of change should have been done with the "first choice".

On the other hand, if the user had changed the type value in the project we could easily fix the mistake with "choice two".

When reloading families pause long enough to consider the options carefully. Often the best answer (or safest) is the uppermost button.

Changing a Username

Revit stores your username in the Options dialog, Application Menu (the Big R)> Options. Usually this is the same as the username you use to log into your computer. When you enter a different username Revit stores this in the Revit.ini. This stored username is persistent from this point forward. You'll have to manually change it if necessary. Keep in mind that there is a master Revit.ini and a user specific Revit.ini. You can edit them to make sure no username is specified and this will restore the original behavior, using the login username instead.

That's not the gist of the post though. When Worksets are enabled your username takes on greater significance. There should never be any identical usernames working on a workset project. If there are two Steve's then the first Steve that synchronizes with the central file wins. The other Steve sits in abject misery, quietly imagining how the first Steve will suffer. Don't be the second Steve.

Still not the point of the post...

You can change your username before you open a local file but not after. Once Revit identifies you with a file, that files is yours. You can't be someone else and work on that file. You can't change your username until you close that file. Then you can create a new local file after changing the username.

You can however change your username anytime you want when you work in a central file. It isn't a great idea to actually work this way, switching usernames as you go. It is however a way to clear out users that have not relinquished worksets properly though. When nobody else is working on the project you can open a central file and pretend to be the ill mannered users that haven't relinquished elements properly. It's another reason you might consider working in a central file, even though it is generally frowned upon.

This is not something you should do casually. If you do this to someone who hasn't saved changes yet, just wasn't ready to do so, you will prevent them from doing so. This won't make you popular at the office. It is an awesome way to resolve little matters when people are all out of the model. In a perfect world you'd never need to do it. Sadly I don't live in a perfect world. If you do, invite me over sometime?

Linked Files have Instance and Type Workset

Linked files are assigned to the active workset, when worksets are in use naturally. When you select the link you can see the Workset parameter in the Properties Palette. Less obvious is that they also have a Type Property called, you guessed it, Workset. This can trip you up when you are trying alter visibilty graphics because they need to match.

The reason they have both is that the Type Parameter is for the definition of the link in the database and the instance parameter is for the actual link. There is a row in the Visibility Graphics dialog for each link as well as a single row beneath it for each instance of the link.

I say each instance because a link can be copied. If you import a file it is both the definition and the instance. If you copy it and put the second instance elsewhere you'll see that another row will appear beneath the first one and both will be under the primary entry. This is done to make it possible to alter each instance of the same linked file differently via Visibilty Graphics.

Experiencing control issues with a link? Remember to check the workset assignments.

Egress Post Summary

As with my recent Worksharing, Site and Reference Plane summaries, I've added a link to this post which will serve as my summary landing spot for Egress Path posts. It's been about six years now since I demonstrated the new line based family as an egress path. The subject is still going strong and there are more options to choose from now.

Summary of Egress Path Posts

(2012) Egress Path Options
(2011) Bending Railings To Your Will
(2011) Stair Headroom Clearance
(2009) Egress Path Update
(2008) Egress Family Video
(2008) Egress Path Tags New Versions
(2008) Egress Math Error Bug Report
(2008) Egress Family Arc Version
(2008)Egress Example Update
(2007) Egress Path Of Travel Uh Oh
(2007) Egress Regress
(2007) Egress Path

Railing as Egress Paths

I've written about this before, egress stuff seems to be popular at times. A railing is a path and profile based element is easy to sketch something like the path to an exit. Straight and arc segments as well as even sloping conditions. Some of the other methods that I've written about here have the advantage that they can document the total length easily. A railing schedule will report the total length but we can't tag them with their total length.

Case-Apps to the rescue!

They've written a little application that is part of their larger suite of free, subscription and beta software for Revit. It's called "Send Railing Length to Selected Parameter".

Create a shared parameter called "Egress Path", add it to your project and assign it to the railing category. Sketch your railings disguised as egress paths. Now tag them. Oh right you can't show that value. Edit the tag family to create your own and use the same shared parameter. Reload the family and still nothing. Now use the Case app. It will let you select the parameter to use and plug the total length into each railing and that value will appear in your tags!

It's not automatic or fool proof. But it does make it a lot easier to consider a railing. If you like special graphics at the beginning and end of your egress paths then a railing is a bit fussier because you need some special "balusters" to get unique "symbols" at each end. Not impossible just a bit more work. Not necessarily more or less work than the other techniques, pick your poison!

While you are at it you should consider the rest of the pile of apps they have. You'll get their apps manager application which really makes it pretty easy to get and install them. I had both 2012 and 2013 installed in a few minutes after registering.

Thanks Case-inc guys! (wearing my T-Shirt as I write this, they gave me a shirt at RTC in Stone Mtn. in the interest of full disclosure)

Use the Front Door

I find myself looking for metaphors as I help people learn Revit. We rely on them all the time, work them into our speech without even thinking about it. Lately I've settled on another to describe the various ways Revit lets us do things. There are usually at least a couple ways to start something or solve something in Revit, like life.

I'm frequently asked which "way" is the best or the correct "way". It seems to me that Revit provides any number of "doors" to access information and tools.

Let's take the notion of working with materials. I have a desk and I'd like it to have a specific material. These days I can select the desk, click Type Properties and, assuming the person who made the family provided a parameter to manage its material, I can click on the material value, which exposes the sneaky "Browse" button. This is a "side door" that lets me select and possibly alter material settings. If I don't find a material I want I can make one while I'm here, click my way back out of the dialog and have a desk that looks great (hopefully).

In the past, if I didn't like the material and there wasn't one listed that sounded like one I wanted I'd have to bail out. Once out of the family's Type Properties I'd open the material dialog and create it. Then I could go back to the desk and assign the material. They created the side door access so we could avoid that inefficient back and forth process.

I run into people that think the side door is the only way to create materials. That's how they learned to do it and they keep doing it that way. The "front door" for materials is really on the Manage tab, the checkered globe button. This front door is the administrative task minded entrance while the side door is more the "spontaneous task" minded access point.

Another example is changing the number of a sheet. We can select the sheet view name, right click and rename. We can open the sheet view and select the title block family which in turn let's us select and edit the sheet number. We can select the sheet number parameter in the properties palette too. Then again we can deal with it in a schedule instead. Keeping count? That's four "doors", a front, side, back, and "secret" door to accomplish the same task.

That might seem like too many options, which one should I use? Easy, which one is the closest to you? Where are you? In the back yard? I'd pick the back door then. Not in a sheet view and needing to renumber a bunch of sheets? I'd pick the "secret door" and use a schedule.

Nearly everything you need to do has at least a front and back door, and very often more. Pick the one that best fits your circumstance. When one door closes another opens...or something like that...

Can't Alter Create New Local Selection

Said another way, the "Create New Local" option is disabled (gray'd out).

I've written about this in the past. My post focused on the network relationship between local and central files. It boils down to the central file being created by a user whose computer is mapped to the server and project folder in one manner and the person who can't manipulate the "Create New Local" option is mapped differently. As long as this condition exists this "rogue" person won't be able to synchronize their work, sadness ensues.

Daryl wrote about this occurring because of different software versions and Luke echoed his post later. While this certainly can and does happen we just need to take care that we don't actually save a file that has been opened in a newer version of Revit unless everyone is prepared to upgrade their project files too (assuming a large team all using Revit).

It's been my experience that the network path conflict is the more frequent culprit, or at least the one with the greatest "danger". Remember if you don't know why the option isn't available to you, check with someone to make sure you can continue safely. Said another way, "Be afraid, be very afraid".

Workset Post Summary Updated

In April (2012) I wrote a post that provides links to workset and worksharing related posts I've written over the years. I've discovered that there were some more that I'd missed in my previous attempt to round them all up. I've revisited that post and added them so the total is now forty four.

I've also provided a set of links on the right sidebar of the site to make it a little easier to find them.

You'll see I've added the text (Updated 8/26/12) next to the Workset summary link. I'll try hard to remember to do this as I add future posts or discover some other ones that I've buried in the past.

Vasari Update

This information has been sitting in my inbox for a week now. Busy makes blogging even harder at times, but it's a good problem right!?! I've written about this product before as well as the Vasari Talk web sessions that have happened nearly each month. You can check those out HERE.

Project Vasari has reached a tipping point in its evolution. As you probably know, its been a very popular project on Autodesk Labs. They've seen more than 60,000 downloads over the last 1.5 years and it has dramatically exceeded their expectations. Doing this work via Autodesk Labs has allowed them to quickly test out new ideas as well as respond to user requests.

Attendees of RTC and AU have probably heard Matt Jezyk present sessions (with Zach and David) devoted to Vasari and he wrote, "I'm happy to announce that based on customer demand we are graduating Vasari from Autodesk Labs and are launching a Public Beta on our new site Autodesk Vasari.com!"

Just in case you haven't heard much about Vasari yet, Matt provided the following descriptive summary.

Autodesk Vasari Beta 1 is a slimmed down version of Revit 2013 focusing on conceptual modeling and early analysis. It is meant for architectural designers and energy analysis who are not necessarily using Revit. The new Beta 1 is file-format compatible with Revit 2013 and also contains all the features from previous versions of Project Vasari. The main new features of Beta 1 are Revit 2013 file-format compatibility, Cloud Rendering and Repeat/Divide features. A less restrictive End User Licensing Agreement (EULA) is also in place to allow firms to further test this pre-release product in their environments. Access to Autodesk 360 Energy Analysis is still available via a free Autodesk ID login. The Beta 1 release will expire on January 31st 2013.

Some firms have been leery of putting their project's design data in software that is in a "lab experiment" state. Put another way, as long as Project Vasari was a lab experiment there was no assurance that it would survive long enough (or ever turn into an actual product) to let a firm finish a project that is relying on the Vasari modelling effort throughout. This experimental nature, while providing a great way to see things develop quickly and early, meant uncertainty about its future. This is a step in the right direction so that those concerns can be assuaged.

You can join their forum site and be part of the ongoing conversation and help get the word out too, here's how: Invite your friends to join you and/or Add Content and finally Tell your Twitter followers.