A functionality that is often underutilized, is the Cut Line Style for Revit elements. This entry will discuss both lineweight, as well as colour overrides for wall layers. As you can see from the image below, the border of the wall is showing in a thick lineweight, while the other wall layers are showing in a thin line thickness.
What we aim to achieve in this exercise, is to manipulate the lineweights, and colours, of the individual wall layers.
The Cut Line Style override functionality can be found in the visibility graphics of a view. These overrides are view specific, so if you want to apply the overrides to multiple views, either modify your existing view template, or create a view template based on these view overrides.
When we select the wall category from our visibility graphics, the Cut Line Styles checkbox activates in the bottom right of our Visibility/Graphics Overrides window. We will now be able to edit the cut line styles for our wall category.
We will see all of the wall functions a wall layer can have, listed in the Function column. We will be able to override the Line Weight per layer function, the Line Colour per layer function, as well as the Line Pattern per layer function. We will also be able to specify what method should be used to clean up the core layers of a wall's structure.
In the image below, the Structure [1], Substrate [2] and Thermal/Air Layer [3] functions have been overridden with a lineweight category 3. The Finish [4] and Finish [5] functions have been overridden with a lineweight category of 1. Colours have been assigned to the various layer functions, to graphically indicate the changes being applied in this exercise. Notice that the Core Layer Cleanup property has been set to Default.
We now change the Core Layer Cleanup property to Use Function. See the Red Line.
When we change the Core Layer Cleanup property to Use Common Edges, Revit will use the overrides applied to the Wall Category's Common Edges subcategory.
And lastly, when we change the Core Layer Cleanup property to No Edge, the core edge line disappears.
Search This Blog
Thursday, 27 November 2014
Monday, 24 November 2014
Decals
Revit decals are quite a useful tool that is used to add images to faces of elements one selects, as well as adding realism to a rendered scene. There are a multitude of ways that one can utilise Decals in Revit. We will go through some of the most often used ways, and see how far we can "push" the decal functionality.
I have created a simple project file in which I have the following walls, to which we will apply decal images:
1. Straight Line Wall
2. Curved Wall
3. Straight Wall with an edited profile
4. Generic Wall Family
5. Straight Curtain Wall
6. Curved Curtain Wall
7. Custom Curtain Wall
The Decal command one will find in the Insert tab, Link panel, Decal icon dropdown
One needs to create a path to an external decal file, much like one creates a path to an image file in Revit. By clicking on the New icon at the bottom right of the Decal Types window, one needs to specify a name for the new decal image
After browsing to the decal image location on your computer, one can now pre-set certain properties for the decal, such as Brightness, Reflectivity, Transparency, etc.
We are able to place the decal image on any face that exists (In this example we will use the Straight Line Wall example), and resize the image using the blue control nodes. The decal image will show as a border only when one is in any visual style other than Realistic mode. In a Realistic visual style, the actual image will be visible.
The big advantage of a decal is that it can be placed on a straight face, as well as a curved face, where the decal will conform to geometry changes
A decal can even be placed on a wall which profile has been edited, as can be seen from the image below. However, note the border around the decal image when in a Realistic visual style. Even though this border will not be visible if one renders an image, there is a workaround for "hiding"most of the border in a Realistic visual style.To "hide" the decal border, we need to create a Decal Line Pattern which contains a Dot, and a large Space in between each consecutive Dots.
One will now be able to select the decal image and Override its Graphics in the View, by Element, so that the Projection Lines are using the previously created Decal Pattern Line Pattern, and that the colour of that line pattern is white. Even though one will still see white border lines, especially at the corners of the decal image, it is much better than having a black continuous border around the image.
When we look at the Generic Model Family wall (Drawn as separate start-end-radius- arcs to represent a spline, as a decal cannot be placed on a spline), one will see that the decal image "freaks" out when it extends past the starting point, and ending point of each separate curve. This is because we have a starting and ending point of each curve. One cannot morph a single decal image around two or more curved lines. So how do we get past this?
The solution to the problem is actually quite simple: Break the single image into separate portions, i.e. smaller images of the same size. Yes, this will be accomplished much faster and with less "hassles" in a post-processing program such as Adobe Photoshop, but I am having fun over here!
One can now place the cropped decal images on each wall segment (curve) and make each consecutive image meet up with the previous. It does take a bit of time to properly line these images up, and having a consistent size.
One can see from the two rendered images below, that the individual border lines of the decal images disappears, and the image inherits the bump map applied to the wall.
When looking at the Curtain Wall examples, one will notice that irrespective of the decal image size, the decal itself is bound by the curtain grids applied to the curtain wall. Makes sense, doesn't it?
By manipulating the curtain grid layout, one will now be able to apply the decal image to a larger area, i.e. a larger panel
The same principle applies to our Curved Curtain Wall.
What can we do with a decal image after it has been applied to a face? Well, as we can see from the image below, splitting the wall face and applying a different material will not take precedence over the decal image, because the decal image is placed on the face of a wall. However, when one adds a wall opening, one actually edits the face profile of the wall, thus the decal image will conform to the wall profile change.
Lastly, let us have a look at the reflectivity options for decal images. A simple room was created, containing walls, floors, ceiling and windows. Luminaires were added to the ceiling to increase the visual effect.
By selecting the decal image and entering the Type Properties, one will be able to edit the Decal Attributes, complete with its Reflectivity settings.
The more Reflectance one applies, the less the image reflects. The image below was set to have a Reflectivity of 80%
This image was set to have a Reflectivity of 65%
And this image was set to have a Reflectivity value of 50%. One can see that the reflected image is more predominant now.
Thursday, 20 November 2014
Pipe Accessory Part Types Explained
The part type properties and functionality of Revit MEP elements are quite often at the center of debates. What does the part type settings mean, and how does it behave when inserted into a project?
This entry will explain the part type functionality within Revit MEP, focussing on the Pipe Accessory category.
For this exercise, I have created a square extrusion that I have added connector elements to. This will be my pipe accessory. Both the primary and secondary connectors have the following properties:
Flow Configuration: Calculated
Flow Direction: Bidirectional
System Classification: Global
The Part Type settings one will find in the instance property panel of the pipe accessory family. There are quite a lot of part types one can select, each with different behaviours. Please note that the behaviour of these part types differs according to the placement of the pipe accessories on the pipe segment.
(The pressure drop tag extracts the pressure drop per pipe segment length, not the accumulative pipe pressure loss for an index run).
Pipe Accessory part type: Attaches To
Any pipe accessory with this part type property will attach itself to the face of any pipe in Revit. No pressure drop will take place, as the pipe accessory is not breaking into the pipe, effectively creating two pipe segments.
Pipe Accessory part type: Breaks Into
Any pipe accessory with this part type property will break the pipe it is placed on into two separate pipe segments. Pressure drops will take place, as the pipe accessory breaks into the pipe, causing two pipe segments to be created.
Pipe Accessory part type: Endcap
Any pipe accessory with this part type property will attach (Snap) itself to the end of a pipe. No flow or pressure drop will take place on the pipe segment on which the Endcap is attached. Flowrates and pressure drops will however show on a pipe segment before a branch on the piping system, as indicated in the image below.
Pipe Accessory part type: Inline Sensor
The Inline Sensor Any pipe accessory with this part type property will attach itself to the face of any pipe in Revit. No pressure drop will take place, as the pipe accessory is not breaking into the pipe, effectively creating two pipe segments.
Pipe Accessory part type: Valve - Normal
Any pipe accessory with this part type property will attach (Snap) itself to the end of a pipe. If one connects a pipe to the secondary pipe accessory connector, that pipe will be seen as another pipe segment
Pipe Accessory part type: Valve - Breaks Into
Any pipe accessory with this part type property will break the pipe it is placed on into two separate pipe segments. Pressure drops will take place, as the pipe accessory breaks into the pipe, causing two pipe segments to be created.
Pipe Accessory part type: Sensor
Any pipe accessory with this part type property will break the pipe it is placed on into two separate pipe segments. Pressure drops will take place, as the pipe accessory breaks into the pipe, causing two pipe segments to be created.
Pipe Accessory part type: Normal
Any pipe accessory with this part type property will break the pipe it is placed on into two separate pipe segments. Pressure drops will take place, as the pipe accessory breaks into the pipe, causing two pipe segments to be created.
This entry will explain the part type functionality within Revit MEP, focussing on the Pipe Accessory category.
For this exercise, I have created a square extrusion that I have added connector elements to. This will be my pipe accessory. Both the primary and secondary connectors have the following properties:
Flow Configuration: Calculated
Flow Direction: Bidirectional
System Classification: Global
The Part Type settings one will find in the instance property panel of the pipe accessory family. There are quite a lot of part types one can select, each with different behaviours. Please note that the behaviour of these part types differs according to the placement of the pipe accessories on the pipe segment.
(The pressure drop tag extracts the pressure drop per pipe segment length, not the accumulative pipe pressure loss for an index run).
Pipe Accessory part type: Attaches To
Any pipe accessory with this part type property will attach itself to the face of any pipe in Revit. No pressure drop will take place, as the pipe accessory is not breaking into the pipe, effectively creating two pipe segments.
Any pipe accessory with this part type property will break the pipe it is placed on into two separate pipe segments. Pressure drops will take place, as the pipe accessory breaks into the pipe, causing two pipe segments to be created.
Pipe Accessory part type: Endcap
Any pipe accessory with this part type property will attach (Snap) itself to the end of a pipe. No flow or pressure drop will take place on the pipe segment on which the Endcap is attached. Flowrates and pressure drops will however show on a pipe segment before a branch on the piping system, as indicated in the image below.
Pipe Accessory part type: Inline Sensor
The Inline Sensor Any pipe accessory with this part type property will attach itself to the face of any pipe in Revit. No pressure drop will take place, as the pipe accessory is not breaking into the pipe, effectively creating two pipe segments.
Pipe Accessory part type: Valve - Normal
Any pipe accessory with this part type property will attach (Snap) itself to the end of a pipe. If one connects a pipe to the secondary pipe accessory connector, that pipe will be seen as another pipe segment
Pipe Accessory part type: Valve - Breaks Into
Any pipe accessory with this part type property will break the pipe it is placed on into two separate pipe segments. Pressure drops will take place, as the pipe accessory breaks into the pipe, causing two pipe segments to be created.
Pipe Accessory part type: Sensor
Any pipe accessory with this part type property will break the pipe it is placed on into two separate pipe segments. Pressure drops will take place, as the pipe accessory breaks into the pipe, causing two pipe segments to be created.
Pipe Accessory part type: Normal
Any pipe accessory with this part type property will break the pipe it is placed on into two separate pipe segments. Pressure drops will take place, as the pipe accessory breaks into the pipe, causing two pipe segments to be created.
Friday, 14 November 2014
Assemblies
Welcome to my blog: Revit-Alizing. This blog aims to broaden your mind to what Revit can achieve, what it's limitations are, and how to overcome those limitations. Too often I experience students who were taught a design or drafting concept using a specific example or dataset, where after the students believe that the software program is only capable to complete that specific concept. Strange? Not really. You have to teach yourself to think "out of the box", however cliché it sounds.
I hope that you will take as much value and inspiration out of this blog, as I have from the following blogs and sites. Even though I am not affiliated with any of these blogs and sites, I believe that one has to give credit where credit is due, so here goes:
1. http://buildz.blogspot.com/
2. http://paulaubin.com/category/blog/
3. http://therevitkid.blogspot.com/
4. http://forums.augi.com/
5. http://www.revitforum.org/
(Please note that the aim of the blog is not to provide training, or to say that the content is the only way of achieving a design or drafting goal. I am sure that many users have found better workarounds to certain challenges and they are more than welcome to tell us if they have).
My first entry will focus on the brilliant concept of assemblies, and investigating the practicality thereof. I will not be designing in these posts. Look at these entries as testing sessions, seeing how far one can take a concept without breaking it.
We will use a very simple curtain wall system to play around with and test the assembly functionality
Curtain Grids cannot be part of an assembly, so we will deselect its checkbox. We will also exclude the Walls category.
From the current selection's Modify/Multi-select tab, we will now be able to create an Assembly from the Create panel in the ribbon.
A name for the assembly needs to be provided. It is always a good idea to think about the naming convention of these assemblies before it is created, as Revit will rename and increment numerical numbers in the assembly name for any other sequential assembly. For the purpose of this entry, I have named the Assembly: Shopfront 1_South.
There are quite a lot of options for the type of views as well as the schedules that one can create from the assembly itself. We can specify a scale for these views as well, but be aware that the scale for these views (upon creation) will be global. In other words, if we specify a scale of 1:50, all of the view type checkboxes that are checked, will be at a scale of 1:50. After the views have been generated, the scale of selected views can be changed without affecting the other assembly views. Depending on the amount of information required, you will even be able to create a schedule for your Curtain Panels, and Mullions.
Revit will now create all of the selected views, and group them in our project browser, under the Assembly category, Shopfront 1_South assembly type.
Only the selected items included in the Assembly will show in the views.
We can tag these assemblies as well. The Assembly Tag is located in the Annotations folder of the OOTB (Out Of The Box) Revit library.
We have the option of tagging the assembly itself, or the Curtain Panels inside of the Assembly, by hovering your mouse cursor over an element and pressing tab until the assembly element highlights. In the assembly view, if you try to now add information to the selected assembly element, you will notice that the Instance Properties are not editable, nor are the Type Properties. This is due to the fact that these elements are assigned to the Assembly itself.
To add or change information to these elements, we have to Edit the Assembly, select the assembly element, and only then the Instance- and Type Properties will be editable.
Let's investigate if bi-directional associativity still exists within the assembly views. I will be working in both the project's South elevation as well as the assembly's Shopfront 1_South Detail View plans. When Curtain Grids are deleted in the South elevation, the change propagates to the Shopfront 1_South Detail View as well. A "warning" does appear, but is only a notification that the Curtain Grid will be deleted within the assembly. Happy? I am.
Should a Storefront Door be added, all assembly views update. Happy? I am.
We now need the same assembly to be located in another location. A simple Copy command should suffice, shouldn't it? Unfortunately not.... An assembly is not a group. Thus a new assembly type is created for the copy.
The new assembly type will be named according to the naming category of the assembly being copied. In this case, the naming category was Curtain Panels.
Can you not just change the type of assembly for my copy? Unfortunately not. An assembly is not a group. Remember the Curtain System explanation in the beginning of this entry? "A Curtain System is created using 3 core element categories: Curtain Grids, Curtain Panels and Mullions". Due to the latter, the nested parts or elements of the Curtain System will not allow a type change to occur.
So let us test this with a Component family, i.e. something created not within the project environment, but rather in the family creation environment. I have created a new assembly for a double flush door, and called the assembly name: "D01" (Tip: Even through there are pro's and con's, on smaller projects assembly views can be used to generate door legends). The previously explained steps were followed to create assembly views for the D01 assembly.
The assembly view was placed on a normal Revit sheet, even though one can create a sheet from the assembly view itself. Previous Revit versions would only allow you to place assembly views on assembly sheets. The door was annotated and the annotations propagated through to the sheet. Happy? I am
No, it does not. Happy? Not really. Should I run to the corner of my office, crawl into the fetal position and cry? No. Accept it and man up. An assembly is not a group.
What if we create a copy of my D02 assembly? Yes, we do get a warning that my assembly copy will receive a new name, however, it still remains part of the same assembly type: D02.
An interesting thing happens when we access our door schedule. Our Count field states we only have one double flush door in our project, while we clearly have two.
Within our door schedule, when entering the Formatting tab and selecting our Count field, by checking the Calculate totals checkbox you will be able to calculate the schedule field total either by Assembly Instance, or Assembly Type. By selecting Assembly Type, the correct amount of double flush doors will show. Happy? I am.
With a fortunate miss-click in the Edit Assembly command, I changed one of my D02 assembly door opening orientation by mistake. When accepting the change, a strange thing happened. Because the door opening direction has changed, Revit has created a new assembly type. Because in actual fact, it is.
Do not confuse the assembly type functionality in Revit with the architecturally correct method of indicating door type and opening orientation. Revit still recognises that something big (the orientation of the assembly) has changed, and thus it needs to create a new assembly. Kind-of makes sense, doesn't it?
Personally, the more I try and delve into the programming, the why, how, what and where of Revit, the more respect I have for the creators and developers of Revit. That, or I am just starting to think like they do...
The D05 assembly door schedule will only show assemblies belonging to D05. Happy? I am.
However, the following situation makes me unhappy. What if I had two D02 assemblies, with different Mark values? Changes to instance parameters unfortunately do NOT update assemblies. Even though I changed the door Mark value, my schedule still shows that both of my doors are of the mark: 85. Even though this has been a wishlist item for quite a long time, it hasn't been addressed yet.
Let's hold thumbs that in the next Revit release, assembly instance parameter changes will be bi-directional. Until then, what are our alternative options? Some innovative users prefer to use Phasing, others prefer to use design options and I am sure that there are many other ways to come across this obstacle that I do not know of yet.
More often than not I use reverse engineering only to find out why something happened, and then I ask myself the question: Is it worth the amount of time and work to find out what happened to each and every assembly and fix what is needed by retracing my steps, or: Shall I save myself time and frustration by recreating an assembly from the updated elements? Obviously this way of thinking will differ from project to project, but it is something to ponder on.
I hope this blog entry made some sense and more importantly, made you think about the different ways to apply a functionality in Revit to challenges you face in your daily routine. Please feel free to post some comments or even share your experiences. We might even discover a new workaround! Wouldn't that be revitalizing?
I hope that you will take as much value and inspiration out of this blog, as I have from the following blogs and sites. Even though I am not affiliated with any of these blogs and sites, I believe that one has to give credit where credit is due, so here goes:
1. http://buildz.blogspot.com/
2. http://paulaubin.com/category/blog/
3. http://therevitkid.blogspot.com/
4. http://forums.augi.com/
5. http://www.revitforum.org/
(Please note that the aim of the blog is not to provide training, or to say that the content is the only way of achieving a design or drafting goal. I am sure that many users have found better workarounds to certain challenges and they are more than welcome to tell us if they have).
My first entry will focus on the brilliant concept of assemblies, and investigating the practicality thereof. I will not be designing in these posts. Look at these entries as testing sessions, seeing how far one can take a concept without breaking it.
We will use a very simple curtain wall system to play around with and test the assembly functionality
I have selected all of the elements in my view. Remember that a curtain wall is a System family, in other words, it is created within Revit's project environment. A Curtain System is created using 3 core element categories: Curtain Grids, Curtain Panels and Mullions. If we would like to create an assembly from the element categories of the curtain wall, we will need to filter our selection.Curtain Grids cannot be part of an assembly, so we will deselect its checkbox. We will also exclude the Walls category.
From the current selection's Modify/Multi-select tab, we will now be able to create an Assembly from the Create panel in the ribbon.
A name for the assembly needs to be provided. It is always a good idea to think about the naming convention of these assemblies before it is created, as Revit will rename and increment numerical numbers in the assembly name for any other sequential assembly. For the purpose of this entry, I have named the Assembly: Shopfront 1_South.
It is important to understand that the assembly will be "grouped", so if we try and select a single Curtain Panel, the entire assembly will be selected. However, the behaviour of the assembly is completely different to the behaviour of a Model or Detail group.
With the assembly selected, we can Create Views for the assembly. Now the big question is: What views can we create?
There are quite a lot of options for the type of views as well as the schedules that one can create from the assembly itself. We can specify a scale for these views as well, but be aware that the scale for these views (upon creation) will be global. In other words, if we specify a scale of 1:50, all of the view type checkboxes that are checked, will be at a scale of 1:50. After the views have been generated, the scale of selected views can be changed without affecting the other assembly views. Depending on the amount of information required, you will even be able to create a schedule for your Curtain Panels, and Mullions.
Revit will now create all of the selected views, and group them in our project browser, under the Assembly category, Shopfront 1_South assembly type.
Only the selected items included in the Assembly will show in the views.
We can tag these assemblies as well. The Assembly Tag is located in the Annotations folder of the OOTB (Out Of The Box) Revit library.
We have the option of tagging the assembly itself, or the Curtain Panels inside of the Assembly, by hovering your mouse cursor over an element and pressing tab until the assembly element highlights. In the assembly view, if you try to now add information to the selected assembly element, you will notice that the Instance Properties are not editable, nor are the Type Properties. This is due to the fact that these elements are assigned to the Assembly itself.
To add or change information to these elements, we have to Edit the Assembly, select the assembly element, and only then the Instance- and Type Properties will be editable.
Let's investigate if bi-directional associativity still exists within the assembly views. I will be working in both the project's South elevation as well as the assembly's Shopfront 1_South Detail View plans. When Curtain Grids are deleted in the South elevation, the change propagates to the Shopfront 1_South Detail View as well. A "warning" does appear, but is only a notification that the Curtain Grid will be deleted within the assembly. Happy? I am.
Should a Storefront Door be added, all assembly views update. Happy? I am.
Should Curtain Panel types change, the change is applied to the schedules. Happy? I am.
We now need the same assembly to be located in another location. A simple Copy command should suffice, shouldn't it? Unfortunately not.... An assembly is not a group. Thus a new assembly type is created for the copy.
The new assembly type will be named according to the naming category of the assembly being copied. In this case, the naming category was Curtain Panels.
Can you not just change the type of assembly for my copy? Unfortunately not. An assembly is not a group. Remember the Curtain System explanation in the beginning of this entry? "A Curtain System is created using 3 core element categories: Curtain Grids, Curtain Panels and Mullions". Due to the latter, the nested parts or elements of the Curtain System will not allow a type change to occur.
So let us test this with a Component family, i.e. something created not within the project environment, but rather in the family creation environment. I have created a new assembly for a double flush door, and called the assembly name: "D01" (Tip: Even through there are pro's and con's, on smaller projects assembly views can be used to generate door legends). The previously explained steps were followed to create assembly views for the D01 assembly.
The assembly view was placed on a normal Revit sheet, even though one can create a sheet from the assembly view itself. Previous Revit versions would only allow you to place assembly views on assembly sheets. The door was annotated and the annotations propagated through to the sheet. Happy? I am
If we edit the D01 assembly and change the type of door from a double flush to single flush, the change dynamically takes place. One will obviously get a warning notification of dimensions becoming invalid, as their references for the double flush door does not exist anymore in the single flush door family. Happy? I am.
If a new door is added, and a new assembly is created for that door (D02), would Revit still not allow me to change the assembly type, as we saw with the Curtain Wall example?
No, it does not. Happy? Not really. Should I run to the corner of my office, crawl into the fetal position and cry? No. Accept it and man up. An assembly is not a group.
What if we create a copy of my D02 assembly? Yes, we do get a warning that my assembly copy will receive a new name, however, it still remains part of the same assembly type: D02.
An interesting thing happens when we access our door schedule. Our Count field states we only have one double flush door in our project, while we clearly have two.
Within our door schedule, when entering the Formatting tab and selecting our Count field, by checking the Calculate totals checkbox you will be able to calculate the schedule field total either by Assembly Instance, or Assembly Type. By selecting Assembly Type, the correct amount of double flush doors will show. Happy? I am.
With a fortunate miss-click in the Edit Assembly command, I changed one of my D02 assembly door opening orientation by mistake. When accepting the change, a strange thing happened. Because the door opening direction has changed, Revit has created a new assembly type. Because in actual fact, it is.
Do not confuse the assembly type functionality in Revit with the architecturally correct method of indicating door type and opening orientation. Revit still recognises that something big (the orientation of the assembly) has changed, and thus it needs to create a new assembly. Kind-of makes sense, doesn't it?
Personally, the more I try and delve into the programming, the why, how, what and where of Revit, the more respect I have for the creators and developers of Revit. That, or I am just starting to think like they do...
The D05 assembly door schedule will only show assemblies belonging to D05. Happy? I am.
However, the following situation makes me unhappy. What if I had two D02 assemblies, with different Mark values? Changes to instance parameters unfortunately do NOT update assemblies. Even though I changed the door Mark value, my schedule still shows that both of my doors are of the mark: 85. Even though this has been a wishlist item for quite a long time, it hasn't been addressed yet.
More often than not I use reverse engineering only to find out why something happened, and then I ask myself the question: Is it worth the amount of time and work to find out what happened to each and every assembly and fix what is needed by retracing my steps, or: Shall I save myself time and frustration by recreating an assembly from the updated elements? Obviously this way of thinking will differ from project to project, but it is something to ponder on.
I hope this blog entry made some sense and more importantly, made you think about the different ways to apply a functionality in Revit to challenges you face in your daily routine. Please feel free to post some comments or even share your experiences. We might even discover a new workaround! Wouldn't that be revitalizing?
Subscribe to:
Posts (Atom)