Manufacturer Content - Lighting

I originally wrote the following on the HOK BIM Solutions blog and have since received some additional comments/observations that I would like to add here before re-posting (thanks a lot to Dan Stine!):

1. Revit does not support absolute photometry (i.e. LED IES files). This probably has to do with the format of the IES file where there is a -1 in place of the wattage value for an LED file and Revit is not currently able to handle this, which means you cannot produce renderings for LED Photometry.
2. An IES file describes how light is emitted from a fixture and takes into account all geometry, color, reflectivity and all other characteristics of the fixture. The reflector is only required to be modeled if you’re using a light source to make the fixture look more believable, or through using a self-illuminating material on the lens (the post below will describe all this in detail). These are also invaluable for lighting calculations, not just renderings.
3. Once an IES file is used, the family remembers the information and a link to an external file is not necessary. This is similar to the behavior of MEP families in 2014 which contain embedded lookup tables (note that even though it appears that the Photometric Web File parameter can be connected to a custom text parameter, it does not seem to work. A support request was filed to confirm if this is a bug).
4. Things get more complicated when doing lighting analysis such as with ElumTools, which require lighting content to be created with specific standards:
• Nested light sources must be shared
• Light source ignores all geometry in the host family
• Light from nested families “sees” geometry in host family (e.g. shadows from the arms of a chandelier)
5. Another challenge with rendering in Revit is reflectance. The Daylighting Analysis for Revit uses a formula based on the RGB values of the appearance asset for a given material. ElumTools uses a similar technique (which can be overridden in their Material Mapping dialog) but is based on the RGB value used in the Revit Material Dialog’s Graphics tab.

NOTE: This is a re-post from the HOK BIM Solutions blog

I will reluctantly kick off this post first with a little rant: is it too much to ask from a Lighting Manufacturer, that their BIM content render appropriately? I think not!

I am sure (hopeful, really) that there is good lighting content out there, but I’d like to take you through a specific journey that in my opinion, was unnecessarily painful and is probably quite representative of today’s common reality. So here we go…a user needed to do some “quick” renderings of an interior, utilizing a fixture by Focal Point called “Equation”. Based on the marketing brochure, this is what these should look like:

Here’s the resulting render using the Architectural family downloaded from the manufacturer’s website (for the purpose of this post, I kept the exposure settings constant so you can easily see the relative differences):

It is clear that the family is built incorrectly. The overall geometry might be close enough (it wasn’t to my liking either, so what you’re seeing in this post is a rebuilt version, where I broke it down further so materials could be assigned to different parts of the family, including the internal reflector), but lighting is not emitting through the fixture. Editing the family revealed that the lighting definition was not set to Photometric Web. The MEP version of the family did have the lighting set to an IES definition, but who do we really expect to do an interior rendering? In my opinion, if you have photometric definitions for your fixtures, you should use those definitions exclusively, no exceptions.

After downloading and adding the IES definition to the Architectural family (which was ceiling-hosted…more on that later on), we end up with this:

This is clearly darker than the original version, so the luminance of the original family far exceeded reality. Now, I understand that we’re not designing a lighting strategy/layout based on a rendered image, but we do expect the result to be perceived as close to the built reality as possible. The IES definition gets us closer, however we still need to do something about the fixture itself. The quickest, most efficient technique is to use a self-illuminating material for the lens, which results in a decent render if the fixtures are far from the camera, but would not be suitable for close-ups due to their “flat” appearance. In the example below, the material’s Luminance setting was set to 300:

Self-illuminating materials add to the general brightness of the image beyond what you get out of the IES definition, but there’s really nothing we can do about that, except tweaking the resulting render exposure to get it close to how we perceive the scene should look like.

For a more realistic look, the fixture needs to be built differently. You need to rough-in the internal reflector, place a tubular light source to mimic the lamp as closely as possible, and then nest the family into another one so you can set the additional Photometric Web light source. Since the family I was editing was already hosted, I nested in an empty family into it instead:

The most noticeable and perplexing issue are the inconsistent artifacts around some of the fixtures. I was able to reduce them a bit by shortening the light source, but they would not go away completely (I think this is a bug, but have not yet confirmed…comments welcome!).

The other issue are the harsh shadows, which are a result of the lens material being incorrect (used frosted glass) and can be easily tweaked as we’ll see shortly. With this method you add a significant amount of light to the scene, above and beyond the Photometric Web definition. The image on the left uses the tubular light source only with no Photometric Web. I noticed that I was using the original family’s metallic paint for the reflector and once replaced with a non-metallic white, the scene improved slightly:

Tweaking the lens material was necessary to get this scene closer to the lighting atmosphere resulting from these fixtures, although those pesky artifacts mean that post-processing cleanup is still required to get a presentation-worthy product.

Just in case you’re curious about the lens material, here are the settings I used after some trial and error (click to enlarge).

What an adventure! I really don’t think it should be this painful to make a “quick” rendering using manufacturer-provided content, especially when dealing with lighting. We really need to be able to drop in such families, complete with appropriate material settings, and move on with our design work, rather than requiring a total rebuild, tweaking of their materials and several test renders.

Lighting Content Building Tips for Manufacturers

1. Start with a non-hosted lighting family so you can use the light source that is built-into the family template to emit light from the fixture. This also gives you the flexibility to simply nest into any other hosted family template, rather than rebuilding each one from scratch and making change management difficult for you and your users!
2. By doing #1, the end user can then decide whether using a self-illuminating material for the lens is a better solution and they can simply edit the family to remove the light source (emitting from the fixture) if that is the chosen path;
3. Nesting into a hosted template means you can now also use the Photometric Web definition in addition to the other light source used to make the fixture appear to emit light. If an IES file is available, the fixture should not use anything other than these definitions. Also, make them downloadable together with the families, not separately! It is torture to figure out which IES file belongs to which fixture and which configuration. See #5 to manage these better;
4. Include proper materials!
5. Use Type Catalogs instead of making a plethora of individual families. It is more difficult for you, and for us, to manage them otherwise;
6. Don’t miss building the reflector and the cavity within the fixture where the “emitting” light source will reside. If you only consider the exterior of the fixture, your end users will have to spend a lot of time re-building them in order to produce acceptable renderings. And once they find another manufacturer that does a good job with their content, guess what is bound to happen?

Manufacturer Content - Lighting

Fine-tuning of material surface patterns

When materials with surface patterns are used, there is a good chance that you need to tweak its position, and perhaps even rotate it to some degree.

With system and in-place families, this is very easy to achieve, the latter being a little more tricky. So let’s take a wall with a surface pattern for example. You can tab and pick one of the lines and nudge/move/rotate as desired. Even the align tool works like a charm in cases like this. In fact, we use it all the time for tile-work in interior elevations (filled regions are a bad idea for this purpose as you cannot control the fill position/orientation, so painting the wall with a material and fine-tuning the joint locations represented by the surface pattern, is a much better solution). You might be mostly familiar with doing this on ACT ceilings, where you control the position and orientation of the grid by fine-tuning the surface pattern positioning.

When it comes to in-place families, Revit doesn’t allow you to directly control surface pattern positioning. To achieve this, you have to be in in-place edit mode. This is a very subtle, but important fact as you’ll see shortly.

Unfortunately with component families, there seems to be no way to adjust material positioning in the project environment. But recall my point above about the subtle fact…you can adjust the surface pattern in the in-place family editing environment, so why not add some parameters to expose this functionality in the project environment while editing a component family?

As it turns out, you can only adjust the pattern rotation, which is better than nothing. It is really finicky to get it to work and you have to do it a certain way or it won’t work properly. I could not find a way to modify the position of the the fill in the x-y directions, no matter what I tried: ref. planes, ref. lines, constraining to the geometry etc. None seem to work. However rotation works well and I was very surprised to find that even when you change material or the surface pattern (from orthogonal to slanted etc.) in the project environment, the functionality kept working and did not cause the notorious “can’t create type” error.

It is very peculiar to note that you cannot actually flex the rotation parameter in the family editor more than once, or the family will break. Here are the main rules you have to follow:

• The angular parameter has to go from a reference plane to one of the pattern’s lines. I found it easier to use an orthogonal crosshatch while building my test;
• Make sure to set the angle to zero before applying the label to the angular dimension or it’ll somehow try to rotate the pattern (this is definitely a bug) and cause a “constraints not satisfied” error;
• When loading the family into the project environment, the angular parameter has to be zero, otherwise the surface pattern comes in skewed. I noticed that if you load a family with a pattern rotation of say, 10 degrees, the pattern in the project will actually be rotated at twice that amount (20 degrees in this example) and the family doesn’t react when changing the angle between 0 and double the original angle (20 degrees in this example). So make sure the angle is zero when you load it! Just don’t try flexing it in the family editor either or it’ll break.

This technique works for all material application methods on geometry in the family editor:

• Painting a material directly on the geometry face
• Painting a material parameter on the geometry face
• Assigning a material directly to the geometry
• Assigning a material parameter to the geometry

I’m not sure how useful this workaround will be to anyone, but there you have it! Hopefully the Factory will resolve this issue and we’ll be able to fine-tune surface pattern positioning directly like we can on system families.

Fine-tuning of material surface patterns

Face Painting in the Family Editor - FIXED!

Following up on my previous post on the topic, the Factory provided a hotfix for this today. You can read all about it courtesy of Kathryn at Revit Clinic. 13 is such a lucky number, isn’t it?!

To use this functionality, create the parameter first in the Family Types dialog. When you then launch the Paint tool, the parameter will be available as a material in the dialog.

Installation of the hotfix is a snap…just copy and paste the dll.

Face Painting in the Family Editor - FIXED!

Immaterial? I don't think so

This is a follow-up post to Immaterial? from almost a year ago. I promised to write about a new method we’re employing in one of my comments but got too busy. Finally I’m getting around to it. Be warned: it’s long.

I originally held off posting to see whether 2012 would bring any solutions on this front but that didn’t happen. At least now the bottom of the Custom Parameters section adjusts with the Materials dialog…hurray!

The least-worst solution I prefer is ugly workaround #1 as mentioned in the previous post. I hit a serious snag while experimenting but finally got through it. I like to refer to this methodology as the Materials sample board concept. Think about your office for a minute: you probably have a vast library of samples. This is analogous to the Materials dialog in your Revit project file. You don’t use all materials in your library in every project, nor do you schedule all materials used in your finish schedule (Ex: insulation, gypsum board, etc.). The same applies to Revit projects. Even assuming every material was actually used in some form or fashion, you’d want to only schedule a select few as finishes, which requires some filtering mechanism.

When crafting office-wide workflows, you have to be careful to keep things simple. This is a hard thing to do when the tools don’t do exactly what you want. So compromise is absolutely necessary in order to arrive to the best-possible solution. It won’t be perfect or satisfy every requirement, but will result in an improvement over how things are done today.

We all understand materials sample boards: designers pick paints, flooring materials, ceilings, glass, cladding, masonry & brick finishes etc. and present them on a board to get client approval. Those materials then find their place in the project, usually within room finish schedules, tagged elevations, etc. So my goal was to extend that concept into Revit. Presentation of those materials was not at all considered as you just cannot achieve that through print.

As discussed before, Revit will only schedule a material if it is used on a placed object. So the starting idea was to place “material swatches” in the project template and make them very difficult/impossible to delete by mistake, without resorting to obtuse ways of concealment such as through worksets, phasing or design options. This was a very important requirement so everything could be pre-set in the template, including the finish schedules. It was also very important to have the same materials used in the material finish schedule as materials in the objects themselves and utilize built-in & custom material parameters to store information that we want to see scheduled such as Manufacturer, Color, Pattern, etc. This would open up possibilities of building material libraries per client and/or project type to be re-used in the future.

Another important requirement was grouping of finishes by surface/object, such as Floor, Walls, etc. Since various materials (such as paints) could be used on different surfaces, it was also essential to have the ability to add unique schedule notes to each material in each application, which meant that this information could not be stored within the material itself. This issue, coupled with concealment methods, turned out to be a head-scratcher.

Material Swatches

The starting point was a simple generic model family that was to be placed multiple times in the template. After several iterations and reasons, it became clear that shared and nested families were required. Each shared “swatch” was nested multiple times into a base family that would represent the application/surface of those materials.

Multiple types were then placed in the template and editing these family types becomes the UI when building the finishes information. Type Comments is used for the schedule sub-headers and Schedule Order is for defining which application order is displayed in the material schedule.

In this example, I have 5 placeholder materials for each application but of course you could add more to suit your needs. Since we have 8 applications, 8 instances were placed in the template. The solid geometry of the swatch family was then set to not be visible and finally reloaded, making them completely invisible and unselectable.

Concealment

Here are some interesting family facts that made all this possible:

• If family geometry is made to not be visible, material take-off schedules still pick up the materials used and properly report quantities (volumes/areas of materials on non-visible solids are excluded). Hence the use of this technique will not skew your take-offs.
• Families are selectable in-canvas even with no visible geometry unless all reference planes are set to “Not a Reference”.

These are the key elements needed to let us place “swatches” to host finish materials and prevent accidental deletion. Note that one can still pick the family in the browser and delete it, but you also get a warning that you’re about to delete “x families”, so it would be a deliberate mistake or done purposefully and not accidentally.

Material Facts

As mentioned in the other post, only the material name can be used in room schedules. Revit does not permit duplicate names so this can be used very effectively as a “Type Mark” since duplication cannot occur. The only hitch is that you cannot rename a material in the schedule: you have to rename it in the Materials dialog.

By using the Material Class, you can isolate the materials that represent finishes to make navigation easier.

In the above picture I’m also highlighting a big shortfall in Revit: the inexistence of multi-value parameters. For example walls in certain rooms often receive multiple finishes: a paint and ceramic tile or FRP panels. My workaround is to create materials whose name represents a group of multiple finishes. This is solely used in room schedules. For the record, this is not something I’m happy about! However there’s no other way to achieve this and when using text parameters, we’re essentially doing the same thing.

The Finishes Schedule

To build a material take-off schedule (for Generic Models) to filter only the materials in the “material sample board”, I simply filtered for shared parameter “Schedule Order” as “parameter exists”, which is also used for sorting the application order (Floors, Base, etc.).

Conclusions

So why all this pain you ask? Well, keep in mind that once this is set in your project template, all it takes is for users to pick the materials and edit as necessary or create new ones. It also opens up the possibility to save material libraries rich with information that can be re-used. Not to mention that with material tags that read the material name, you’ll have flawless coordination with the “type marks” used in your finish material schedule. Room finishes can also utilize these materials in lieu of text parameters, although for multiple finishes you have to resort to the workaround mentioned above. Finally, we also have to make another check: that each finish that shows up in the finish material schedule is actually used in the project since these are manually added. For this purpose we also set up a “checking sheet” that contains a series of filtered schedules to make sure no finishes have been missed or added. Obviously it would be great if things were all automatic, but at this point this is as good as it’s going to get.

Immaterial? I don't think so

Face Painting in the Family Editor

You might recall Steven Campbell’s post Revit Families: To Split or Not to Split… (no, this isn’t his photo. I know, he’s in hibernation at the moment or so it seems). I honestly was unaware of that hidden feature until his article as in the past, I habitually just assigned material parameters directly to solids and never thought of face painting as a parametric option.
Unfortunately in Revit 2012, we lost that ability with the arrival of the new UI that gives us a visual palette of materials when painting surfaces. I really hope we’ll get it back in the upcoming service pack. The functionality is still there as families upgraded to Revit 2012 function properly. However if you “unpaint” the surface, you won’t be apple to re-apply the material parameter. So in the meantime if you need this functionality, start your family in 2011 and upgrade it once you’re done.

EDIT: This has since been fixed through this HotFix. Thanks Factory!

Face Painting in the Family Editor

Immaterial?

Materials in Revit are a source of frustration, at least for me.

When it comes to documenting a project as it evolves from SD to subsequent, more detailed phases, Revit fails to provide a solid solution that acknowledges the need for continuity in documentation. Not that there are no ways around the issue, but we’re not after disconnected workarounds in the end. We want a solution that provides seamless integration between the 3D model and visualization aspects, and the documented information such as material schedules.

Let’s take rooms as the prime example. In itself, a room is not a physical object that exists on it’s own. You cannot buy a “room”: it is made up of walls, floors, finishes, ceilings, lights, electrical fixtures, casework, furniture…you get the point. Traditionally, we schedule room finishes in tabular format with a column for each element of interest. Now we can argue whether this is or is not the best way to show finishes, but guess what? We’re not going to change how the industry expects it just because Revit wants you to do it differently perhaps!

So how does one integrate the Materials in Revit with the documentation expectations? Over the years (and recently too) I have toyed around with several ideas but they all break somewhere:

• We can add a Material parameter to the room category. This gives us access to the actual Materials through a room object or a room schedule. Since a material parameter is a text entry pointing to a material name, it is easy to modify and doesn’t require you to take a trip to the Materials dialog if you know the material name.

• The first issue we encounter with the above is that we can only schedule the material name through the room schedule. We expect to see names such as “CPT” for carpet etc. in the room finish schedule. To work around this, we can name our materials in abbreviated form and also assign a common Material Class to easily filter these “Scheduled Finishes” from any other materials used for visualization. The advantage of using real materials is that if we decide to change the type mark or keynote, it will update anywhere that material is used/tagged in the project. This gets us closer to using Materials throughout the entire project lifecycle and not just for visualization.

Some comments about the above image: When are we going to see that darn Custom Parameters area be resizable instead of just tall enough for one parameter?? Also if you’re going to give us a Keywords parameter, let us schedule it! Otherwise what’s the point? Perfect use case: schedule filtering (ex: Keyword contains “Floor”). However for the time being, we have to add a custom project parameter assigned to Materials in order to do this (and scroll!).

• We need to schedule the materials used in the project together with relevant information, such as Manufacturer, Line, etc. However unless materials are used in a model element that is placed in the project, they won’t schedule. Sadly, rooms are not seen as a model element, so creating a Room Material Take-off schedule is out of the question (big bummer). In SD, I don’t care about the area or volume of material used (for documentation purposes, we hardly ever care except if we’re doing detailed cost analysis), but I care about the material description, the manufacturer, etc. I don’t want to schedule every single finish that exists in the Materials dialog, but only those called out in the Room Schedule. So having some sort of “Material Schedule for Rooms” is sorely lacking in Revit. If this were possible, one could schedule materials as they’re added to rooms.

During SD, we only have a limited amount of modeled information. Simply put, the need for “documentation continuity” mentioned earlier means that as the design is refined and the information granularity increases, it needs to find its place in the documentation infrastructure that already exists in the project. For example if all I know is that I’m using paint P1 on walls in Room A100, I need to show P1 as my wall finish in A100 in a room schedule and once that happens, the material schedule should automatically add material P1 to it with all the relevant info. about that material. As design progresses and we pick a real material, that information should be reflected in the material rendering appearance and parameters, resulting in richer, coordinated visualization and construction documentation.

How are firms doing this right now? Unless I’m missing something and there’s actually a way to achieve what I’m describing, we can safely say that firms are doing it the old way: just type it and coordinate manually. This is just not acceptable with all the BIMwashing and hype out there.

Currently, possible ugly workarounds include:

1. Making fake model families (ex: Generic Models) in some unused future phase and assign materials to them. This is synonymous with a physical “Material Sample Board” which is a standard thing in the industry. Now you create a material take-off schedule for the Generic Model category and go from there. However now we’re starting to have disconnected information: Just because a material schedules doesn’t mean it has been called out in a room schedule, and vice versa. Note that a similar technique is to use Design Options to segregate/hide these workaround elements in lieu of Phasing.
2. Typing it! Can’t get uglier than that. With this solution (sadly, the most common one), you manually type up & draft a finish schedule in a drafting view, which you then have to manually coordinate with materials used in modeling elements, room finish schedule dumb text parameters, tags, etc. This is as un-Revit-like as it gets!
3. Adding a zillion project parameters to the room category for each individual finish material application (floor, base, etc.) and then multiplying that by about 5 more (each one will need a unique description, manufacturer, etc.). Also with this you end up having to create separate schedules for each material application (Ex: walls) and…the actual Revit materials still have no connection to this information! This is the current solution we’re using in lieu of #2. It’s workable, but still not pretty. There are a lot of schedule gymnastics that need to happen to make it somewhat efficient.

Other shortfalls crop up while trying to make this work, such as the inability to have nested key schedules and the inability to use shared parameters in key schedules. But I’ll stop here today! Hopefully it is clear enough that we’ve exhausted a lot of avenues trying to get this to work and even though we build projects successfully, the software fails us from a BIM point of view. Despite these problems, we still love it and hope it gets better.

Immaterial?

Got Bump

Do your rendered images appear a little flat or the materials have no depth? Try adding a bump map to give them depth. A few well placed materials that show depth can make a big difference in a rendering.In the image above the brick on the left has no bump map assigned, making it appear flat and unrealistic. Also, concrete material on the left has no bump but in the right one I added a bump map that gives it grout lines and surface texture.

A typical bump map is a gray scaled image in which the dark areas create the deep cuts into the material creating texture depth.
You can create new custom materials based on mixing a generic material with a bump map.
In the case above I created a generic material with a RBG color value of 204, 102, 0.




Then I added a leather bump map from the OOTB material library with a sample size of 4’-0” and a bump amount of 94 to create this decaying orange looking material.

Sorry if you were eating lunch…




More fun can be had by trying different bump maps and you can also invert the bump by checking the Invert Image box in the texture editor. The image below on the right side has an inverted bump.

Enjoy…

Got Bump