I mentioned in a post last week about Alan Wooldridge’s request for help in getting Revit Structure 2012 UK localisation back into the package. Scott Grant, from Excitech, has tweeted about a fix involving “a quick W7 registry edit”. He warns that a reinstall will be needed.
Databases are at the core of any information management system. As a system for Building Information Modeling, Revit is no different. And by definition, databases are only as good as the data they contain. So one thing that’s covered in any study of databases is the importance of accurate and consistent data for maintaining data integrity.
Recently, a customer sent me their shared parameters file to use in modeling their families. The families involved had electrical connectors. When it comes to connectors, you always want to associate the parameters within the connector to parameters in the family. And if you want that information for schedules or calculations, the latter will most likely be shared parameters.
In this case, the electrical connector had a parameter to store the phase called Number of Poles. I entered the information from the customer in the connector parameter, and went to associate it with a shared parameter from the customer’s shared parameters file. The problem was that the shared parameter for phase had been created with a datacategory of number, whereas the connector’s phase parameter was, as its name implied, in number of poles.
The difference in datacategory meant that the connector’s parameter couldn’t be associated with the family’s shared parameter. A new shared parameter with a different name had to be added to the family in order to pick up the phase from the connector. And the two shared parameters couldn’t be linked via a formula either (unless they were made unitless), due to the same issue of having different datacategories.
This kind of inconsistency can easily compromise a project’s data integrity in Revit. For example, an engineer might be working with the family in a project. He updates the connector’s phase parameter, thinking that this information will carry through for scheduling, but the schedule is actually using the first shared parameter for phase, the one formatted as a number. Or maybe the engineer updates the number-format shared parameter and assumes that he’s updated the connector’s phase parameter, not noticing the second shared parameter formatted as number of poles. The point is that an inconsistency in data entry led to having redundant shared parameters thereby weakening the project’s data integrity.
Just something to keep in mind when creating shared parameters…
Yesterday I attended the MEP track of Excitech’s Spring User Forums. It’s possibly one of the best such gatherings I’ve attended. All the talks were interesting in their own right and together they did a great job covering the key needs, goals, and recent developments for Revit MEP users.
Among the talks was Gary Ross excellent presentation on Electrical Design for the UK with Revit MEP, where he showed us the new customizations and additions that Revit MEP 2012 has seen for the UK electrical market, an area in which he played a big part while working for Autodesk (he’s now working for Capita Symonds). It might be worth pointing out the other side of the coin with the latest release of Revit Structure, where the UK customizations have seemingly disappeared.
Revit Server and its alternatives were thoroughly covered, and Carl Collins from Arup showed us the Excel/Revit link tool that allows you to drive any editable parameter in a project from a spreadsheet and viceversa, as well as to view all non-editable parameters.
David Shepherd of Excitech gave a fast-paced presentation on Revit families that covered an incredible breadth of material. I’m always learning about families and this occasion was no different. I also got some ideas to blog home about, so stay tuned for some of those in the near future.
There were presentations by Johnathan Ward on Vault and by Phil Palmer on MEP projects, and one on point clouds and surveying services. The latter included a live demonstration where we were all scanned in 3D in a couple minutes. The machine doing this could capture a million points per second! A glitch focused the beam on one of the attendees and he disappeared in a puff of smoke, which was also amazing. Jokes aside, with Revit 2012, support for point clouds and accurate survey data in your projects has never been easier.
There were a number of other talks I won’t go into, but there was one in particular that I wanted to highlight here. Stuart Barcock and Andy Robins of MAP Software gave a talk about Driving Fabrication from Revit MEP with FABmep+.
For years I used CadDuct Solids (now called CADmep+), which is where I started creating content and what later led me to become interested in content development for Revit. Being as it was at the time a CAD-only product, and being immersed in Revit myself, I lost sight of MAP over the years. Stuart and Andy’s talk on a newer piece of software called FABmep+ put them squarely back on my radar.
Andy showed us a Revit MEP project with duct, piping and cable trays. He then exported it to FABmep+ where the model got all the manufacturing info, allowing for the fabrication of the duct, the creation of piping spool drawings and more. Then, with a few clicks here and there, he brought all the new fabrication geometry back into Revit – including system duct runs cut to standard lengths and all connected! But better than me explaining it, go and check MAP’s FABmep+ page and see for yourself. If the connection between Revit and fabrication was holding anyone back, FABmep+ looks like it’s the answer you’ve been waiting for.
After a full schedule of interesting talks and following British tradition, we all hit the pub for a couple pints. Great day, and many thanks to the team from Excitech for making it happen!
I’ve been wanting to write about a technique I used recently while working on some families that allows for the symbols nested in them to be moved around independently of the modeled family. I learned about the process from R. Robert Bell, who explains the problem-solution as follows:
There are times in a model where elements are placed in the same location on a wall at different elevations. Obviously this presents an issue with the BIM. The 3D model of each element needs to remain on the wall but then the plan symbols will be interfering with each other on the sheet.
In Revit it is possible to create a family that can move a plan symbol independently of the modeled parts of the family. This requires the use of a nested annotation family. This permits a length parameter to be changed to offset the plan symbol from the wall. Note that the length used must be in the annotation’s units rather than the view’s units, e.g. 3/16” rather than 18” on a 1/8” = 1’-0” view.
The elements that make up the symbol are grouped to allow a dimension to move them all together. The parameter created for the offset is set as:
[...] instance-based, grouped under Constraints, named, “Plan Symbol Offset”, discipline as Common, type as Length.
Below is a video demonstrating a quick version of the process. I recommend using this technique as a standard for any family that has plan symbols like the ones shown here, at least up until a change in Revit renders it unnecessary.
Last week I found out about a standards project for foodservice equipment Revit families. Having just completed a couple food service equipment families for a customer, I thought it would be good to dig into the standard and see if I could apply it in the future. I checked out their Foodservice Industry Revit Task Force and began reading their published standard for foodservice equipment families. The standard looks like a great first step and one I hope other industry groups will follow. It builds on top of Autodesk’s Revit Model Content Style Guide available through Seek, which is a good place to start. As I reflected on the food service families I’d just delivered, however, I found a few areas that I think miss the mark when it comes to manufacturer-sponsored content. I thought I’d share those here as I think they could apply to many other industries as well.
1. Revit Architecture vs. Revit MEP
“Food Service Equipment Industry content can be created successfully in Revit Architecture or Revit MEP. In general, since some content might include System Family Types for architectural objects like Walls, it is recommended that you use Revit Architecture unless the equipment you are creating has specific needs only available in Revit MEP.”
To my knowledge, there is nothing in the Revit Architecture family editor that can’t be done in the Revit MEP family editor. Connectors are one thing that you can only do in the MEP family editor.corr And while there are plenty of families in the Foodservice Industry that don’t need connectors, I think it makes more sense to use a broadest case standard here. Given the audience at which the standard is aimed, namely manufacturers – who have multiple products to model for their customers – and content creators – who need to model various kinds of products for different manufacturers or projects – there is bound to be a need for connectors. In fact, both of the food service families I just delivered had electrical connectors required by the customer. So if this standard must recommend any version of the software, it should be Revit MEP.
2. Modeling Levels of Detail
“It is possible to include all three levels of detail in a single Component Family. An alternative approach is to include the Coarse and Medium detail levels in one Family for use in design development and construction document drawing sets and create a separate high detail Family for use in rendering and visualization.”
The key assumption here is that good visual detail will make a family heavy, and so you’ll gain performance by isolating that geometry in its own family. This is a misconception that leads to unnecessary work. Not to mention that it would force you to break a project model whenever you need to do a rendering. Families can be made small and perform well while still looking really nice at a fine level of detail and covering 80%, if not more, of your rendering needs. I know because that’s what we sell here at Andekan!
But more importantly, by keeping all levels of detail in the same family, you save yourself time and effort. Again, the customer who ordered the Zumex and Imbera families required the coarse geometry to match the medium geometry, which isn’t necessarily a common scenario. But if all levels of detail are already in the same family, making this happen is a matter of clicking a few checkboxes rather than moving geometry between files and keeping track of versions. Plus Revit keeps improving when it comes to performance, as do computers in general, so the outlier cases where performance actually requires separate geometry will disappear over time.
3. Coarse View Geometry
Here we’re looking at a family in coarse view and being told to use extrusions to create the 2D geometry. Instead we should be using masking regions, which require less of the application and will improve the family’s performance in this view. Extrusions in coarse views are a shortcut for the content creator, but, like any thing in software, the user doesn’t care if the programmer (or modeler in this case) has to spend an extra half-hour on the family, if that means the product is easier to use and more effective. In general, the parts of the standards document covering levels of detail could be made clearer by breaking them into 3D levels of detail and 2D levels of detail.
4. Who’s Using the Standard?
“The type and size of the project that a family is intended for use in is a critical point to consider when deciding what representations should be included in the family and what level of detail each representation should have.”
The above text appears under the “Design and Performance Considerations” section header. This section seems taken from a tutorial about the family editor intended for the general user, and it doesn’t quite fit when you take into account who this standard is meant to serve: foodservice equipment manufacturers. The above guideline makes sense from the architect’s or engineer’s point of view, because they are most concerned with their particular project requirements. For a manufacturer, however, this would mean having to rebuild families for every customer that wants to use them.
If a manufacturer sees enough consistency in their customers’ use of Revit over time — say 90% of customers only need 2D linework — perhaps then it would make sense to incorporate some of those shared project criteria into their families, but that’s not a situation that I believe should be suggested as a guideline for all manufacturers. I would suggest instead that families include all representations and views that might reasonably be required by anyone working on a project that includes their family. Again, there’s no reason this can’t be done while keeping families light and smoothly functioning. If the standard is also meant to cover the needs of architects and engineers building their own families, then having separate sections for each audience would be best.
So those are a few of the things that have stood out to me so far. There were many good things that caught my eye as well, and I encourage you to check out the project even if you don’t work with foodservice equipment families. Developing family standards is critical for Revit’s potential. Industry-level collaboration and iterative definition are definite requirements for success, and those seem to be happening with the Foodservice Industry Revit Task Force. In fact I saw today that they updated their shared parameters file and naming convention standards! So I’ll be joining in the discussion there and continue to share any key updates through our blog.
This week I worked on a project that brought back memories of my homeland. I created two families, an orange juicer from Zumex and a refrigeration display from Imbera. Being from Spain, it was nice to create a family for a local product. The Zumex is a juicer that you’ll see in just about any bar or café there.
In this particular case, the families were being created for our customer’s customer, in the US. The juicer took some time with its geometry, the orange slider and canister in particular. It came out at 496K, oranges not included. The refrigeration display was straight forward, weighing in at 384K. See images of both of them below.
Both families included electrical connectors, tons of shared parameters, and levels of detail. The levels of detail were interesting in that the customer requested both medium and coarse to be exactly the same. While it’s not a request I often see, a change like that would be a piece of cake if the manufacturer already had a family with three levels of detail built-in (they didn’t in this case). You’d select the medium-level geometry and check one extra box. If there is coarse-only geometry, select it and delete it. Boom! A manufacturer-specific family is updated to a particular customer’s/project’s standard. More on standards in my next post.
Last week, we issued our third release of “Andy”, Andekan’s fully parametric human Revit family. The announcement and link was sent out to anyone who signed up to receive Andy on our Meet Andy page. For those of you that were on the list but haven’t yet downloaded, you still have until the end of today to get your copy! 
Andy has been a part of Andekan since almost the very beginning, and it’s been fun to see him “grow up” alongside us. First he learned to run and point and sit, and with those sweet moves he then he found a companion named Ann to join him in his Revit projects. When the download for Andy 3.0 closes tomorrow, we’ll be turning our attention to Andy’s next evolution, and we’re excited to see that wisdom truly does come with age. With Andy 4.0, we’ll be making Andy act smarter in your projects, from adding options within the family for RPC rendering and male/female geometry (no more companion family required!), to offering a wider range of pre-configured types for functional poses such as climbing stairs or using a wheelchair.
This upcoming release also marks a turning point in how we’ll offer Andy to the public. In the past, visitors to our site had to subscribe to a special list to receive a download link whenever we issued a new version of Andy. Moving forward, we’ll announce new versions publicly through our blog and offer Andy as a low-cost paid family with an initial price of $10 USD. That’s right, it’s time for Andy to stand on his own two feet, and we know he can do it!
Thank you to the many of you who’ve followed and supported our work on Andy over the years. We look forward to bringing you Andy 4.0 very soon, and welcome your feedback or suggestions for future versions here.
Below there are two images I included in a recent blog post. Do you know those photo hunt games they have in bars? Well then, can you spot the difference?
The medium view in one of them has materials applied to it while the other one doesn’t. There is no existing Revit standard that indicates which approach to follow, but that shouldn’t deter us from trying to develop one.
So what would be our starting point for deciding whether materials should display in a project at a given level of detail? All things being equal, I would propose that it makes sense to display materials whenever a family’s geometry is meant to “depict” the geometry of the actual object. In coarse view, for example, most families have their geometry reduced to a volumetric representation or linework (which doesn’t even carry materials in Revit), so it doesn’t make sense to apply materials at that level of detail. Having materials visible at a coarse level detracts from being able to quickly interpret the visual information presented. On the other hand, there won’t be any more accurate depiction of an object in a project than at the fine level, so at that level of detail we should definitely apply materials to any families that have them. But what about at the medium level of detail? This one seems more open to debate.
In general, materials should be assigned to a material type parameter in the family, and the geometry’s built-in material parameter should be linked to the former. When working in large projects with many families, it’s not uncommon that geometry for the fine level gets “re-used” for the medium level of detail. If some or all of the geometry is shared between the fine and medium levels of detail, we can’t just turn off that geometry’s material for the medium level without doing the same for the fine level. So if we want to hide materials, we have to create completely new geometry for the medium level and leave that geometry’s material parameter set to “<By Category>”. But replicating geometry always increases file size, which we want to avoid whenever possible.
On the other hand, if we make materials visible at the medium level, then we can re-use as much geometry from the fine level as we want without any increase in file size, and in theory with little or no impact on the overall performance of the family within a project. Doing so might imply a few extra clicks per family to assign materials for geometry that only exists at the medium level, but the overall result will be a more accurate depiction of the project. Given that a family’s medium level of detail usually attempts to approximate its real world geometry, it seems best to settle with materials displaying at both fine and medium levels of detail, while not displaying at coarse levels of detail.
Again, I’m proposing this as a general rule of thumb and as a starting point for a more thorough standard for how to use materials in Revit families. I can certainly imagine there are cases where turning off materials at the medium level might make sense, but on the whole I believe making them visible offers greater benefit for projects with minimal to zero downside.
Are we on the right track here? Have you come across this issue when working with materials, or do you have a different standard that you follow for your projects? I invite you to share your thoughts or questions in a comment.
To make the most out of Revit content, including improving its performance when placed within a project, families should generally be modeled at Revit’s three levels of detail in 3D views as well as 2D views (see previous posts for examples of content I’ve created as such).
In today’s video, I’ll cover how to use masking regions with symbolic lines to create more accurate and efficient 2D views in Revit. I’ll use an example where left and right views need to be different at medium and fine levels of detail, and where geometry is simplified at the coarse level.
The resulting family, shown below, hides all 3D geometry from plan and section views, displaying only symbolic lines and masking regions. The first image shows the distinct left/right elevation views at the fine level of detail.
This next image shows the distinct linework for plan view at fine, medium, and coarse levels of detail.
Finally, I’ll show you a workaround for a bug in the Revit family editor that keeps you from hiding specific boundary lines in a masking region, so that you could do something like what’s shown in the image below.
Here’s the video. Enjoy!
