Google Analytics (Hidden)

Tuesday, August 30, 2011

Visitors of Revitforum.org around the globe



















This image shows all the countries from where Revitforum.org has been visited during the last 7 months. The greener the color, the higher the number of visitors. The report says that the number of countries or territories is 200. Considering that the United Nations has 193 countries registered, a number of 200 is really impressive, especially considering that Revitforum.org has not celebrated its first anniversary yet. Even more impressive is the interest for this software itself, which was launched in April 2000 by Revit Technology Corporation, and has been part of the Autodesk family for less than ten years.

The list of visiting countries of Revitforum.org is so long that it is easier to spot the countries or territories from where the forum has NOT received any visits yet (the countries represented in white on the map) :

Greenland
Iceland
Western Sahara
Somalia
Congo
Central African Republic
Chad
Eritrea
North Korea
Buthan
Uzbekistan
Kyrgystan
Tajikistan

Well, and probably The Vatican?

See you in Revitforum.org...

Saturday, August 27, 2011

Custom Curtain Wall, pt 0: setup

In this thread there was a question about how to create a curtain wall without mullions, but with a gap between the panels. This is quite similar to a project which I once had, where the panels needed to have an overlap.

Actually, the entire OOTB Curtain Wall system is flawed when it comes to the Joints from panels with mulions. You either have too little (read no) gaps when removing the Mullions all together or to wide (read: entire mullion with) gaps, see image 1. But, with the OOTB content, it’s not possible to create Panels like they’re going to be build.

So, me and my big mouth once told the Curtain Wall Guru here at RFO, Dave Jones, that creating a custom panel with offsets to address this issue was fairly easy to make. Then I realized that I had also promised him once to show I did my CW detailing native in Revit. And since I never got back to him on that, I figured that this is just as good a time to live up to my word as any.
With this in mind I will be looking at a multiple parts weblog. Here’s the index for now (be aware, if I find myself in posts with excessive length I might cut them in more pieces):

  1. Creating custom Panel geometry.
  2. Creating custom Mullion profiles.
  3. Assigning Detail Components to the Panels and Mullions.
  4. Setting up useable schedules and tags
  5. Using Adaptive Components for non-rectangular panels

I think this a rather comprehensive list but if anyone is missing anything, I’d be more than happy to comply. Keep in mind though, this is about the “normal” use of Curtain Walls. I’m not talking about Massing, Divided Surfaces and all that stuff… That’s all covered by the infamous Zach Krohn and his weblog Buildz…

First off, let’s set some basic groundrules for Family Creation. I always use those, and I will always do so whenever I write a blogpost like this:

In Family Creation Shared Parameters are used by default. Only in exceptional cases (parameters needed solely for calculations) I use Project Parameters. Why? Number of reasons, not impotant now.

Shared Parameters are grouped by their category in the SP-file. Not by Family or usage. But by category. Why? Number of reasons, not impotant now.

When creating Families, there’s a set workmethod:

  • Draw the desired geometry layout in Reference Planes and/or Reference Lines
  • Dimension Refplanes / Reflines
  • Add parameters to dimensions
  • Flex parameters and check if they don’t break
  • Add geometry and immediately assign it to a subcategory
  • Add more parameters to define geometry and add data.

In Family Creation, parameters are placed in one of the following views:

  • Plan View, Level 1
  • Elevation View, Exterior
  • Elevation View, Left.

NO OTHER VIEWS ARE USED SINCE I ABSOLUTELY HATE LOOSING VALUABLE TIME IN FINDING A PARAMETER OR WHY A CONSTRAINT ERROR IS GIVEN.

The above groundrules are set now so I don’t have to answer any questions about them. I can go into the method deeper, but that would be for another time. Right now, let’s just get on with it.

Using Shared Instance Parameters from nested families

Following up on this post, I played around with the family posted there. Snowwyweston was working on a sort of Facility Management family designed to keep track of hard- and software in his office, image 1.

The family exists of two components:

1. The parent family: WORKSTATION_QUERY.rfa.
This family contains a solid box which represents a pc. It has some parameters attached such as the dimensions (off course) and hardware specs. It also contains the nested
SOFTWARE family, image 2.

2. Child family: SOFTWARE.rfa.

ThThis family contains a bunch of shared parameters, all instance parameters. These are yes/no parameters defining what software is installed, image 3.

His question was: how do I get the parameters from the nested software component into the parent family? Do I really need to link them all to a new parameter in the host family?

General rule of thumb until recently when using SHARED nested components:
Type parameters can be accessed through the project, instance parameters need to be tied to the parent in the Family Editor. This means you can do either one of two things:
1. Use Type Parameters. Which creates an humungous amount of family types.
2. Recreate all the child parameters in the parent family. This in turn has two disadvantages:
a. It’s a lot of stupid work.
b. It presents you with a totally unusable parent family. The given example is in fact not that hard. Wait until you need to do this with a door family with nested frame, panel, 2d symbols and so on.

My first idea was:
Tie both families together using a Mark parameter of some sort. For instance a text parameter. To do this, open both families. Start with SOFTWARE.rfa. Open the Family Types screen and click “Add”. Now add a Shared Parameter, “WS_code”, which is an Instance Text parameter see image 6. Load SOFTWARE.rfa into WORKSTATION_QUERY.rfa.

Next step: create the same parameter in WORKSTATION_QUERY.rfa: create the shared parameter WS_code. After this, select the nested family SOFTWARE.rfa and tie the WS_code parameters together, image 5. Load the parent family WORKSTATION_QUERY.rfa in your project.

Now create a new Specialty Equipment Schedule. Add the fields as displayed in image 6. Include the Family And Type, WS_code and all software needed.

At first I thought I nailed it. Task completed, take a beer to celebrate. Then I tried to set one of the No-parameters and change it into Yes. No luck there, the parameters aren’t accessible. To be honest, this kind of confused me. I have developed some workflows (regarding calculating the ratio between egress length and clear door width) which uses instance shared parameters from nested components in the project environment. But according to this, and the above rule of thumb, that shouldn’t be possible. So what’s the trick…?


Well, it’s mindblowing simple: you need to manually import the Shared Parameter into the project. To test this, I went to Manage > Project Parameter > Add and added the parameter “3D Max 2012”, see image 7.

See the result in image 8: SOFTWARE.rfa is still not accessible BUT the Parent Family WORKSTATION_QUERY.rfa is!

(btw: the value of the Yes/No parameter is set to . See this blog post to explain about that. For now, note that you’ll need to click it once to “activate” the parameter and once again to set it to “NO”.

This made me wonder, is this just project-based? So I looked up the family in 3D and selected it. To my surprise, the Shared Instance Parameter from SOFTWARE.rfa is now incorporated in the Parent Family WORKSTATION_QUERY.rfa and it’s also accessible through the Properties, image 9.

After this, I opened the family WORKSTATION_QUERY.rfa in the Family Editor. Here, the parameter “3D Max 2012” is still absent, which to me, is just what I would expect. Recapping, there are now TWO ways of using Instance Parameters from Nested Shared Components in a Family:

1. Recreate all Instance Parameters in the Parent Family and link through the parameters.

2. Import the Shared Instance Parameters into your Project.

The beauty of this all is that you don’t need to choose either one of them. You can choose by parameter which method you want to use. Some pointers though:

Method 1: use this when you need to drive the Child through the Parent. For instance when the size of a Child Family depends on features from the Parent Family.
Method 2: use this when the Child Family Parameter is only used to define data, which is the case in this example. Whether a specific software is installed is not defined by anything in the workstation. So you can use this method to keep the Parent Family relatively simple and NOT have a few dozen extra parameters in your Parent Family.

But what’s the benefit of having two methods? Why not simply import the shared parameters in the Parent family? Well, again there are a number of reasons:

1. Useability of the Parent Family. When you look at this Family you’ll notice that both the Parent and the Child Family have a huge amount of parameters in them. Adding the SOFTWARE.rfa parameters to the WORKSTATION_QUERY.rfa would make this rather impossible to use, also because there still is no way to change the order of the parameters listing.

2. When the parameters exist in your Project Template you can very easily setup a Facility Management Template:

a. Create a new template or copy the existing one you have for Design work.

b. Import the shared parameters used in SOFTWARE.rfa.

c. Create an empty Project and link it into the FM Template file. Save this.

d. Set all schedules you created for FM to “include elements from linked files in the Properties > Field tab.

e. Now if you have a project in which you want to do FM, open the template as a new project, Go to the Manage Links screen and use Reload From to assign the correct Project File.

Happy Reviting…

Thursday, August 25, 2011

Best posts of the month of July 2011

The best posts of the month of July in Revitforum.org are:

1) Post #22648 by Scott Hopkins in Thread: View Title Secrets Revealed
2) Post #24654 by Steve_Stafford in Thread: (Faking) Property Lines in Sections
3) Post #23997 by mdradvies in Thread: Push parameters in the project environment

Brief comment about the first post:

In this interesting post, Scott Hopkins, from Peikert Group Architects, explains how he modified a view title family, carefully adding reference planes in it, to facilitate the placement of the view title on the lower left corner of the drafting view, and on the grid of a sheet with details.

This image shows the view title family in the family editor:









For more information, please refer to Post #22648 at Revitforum.org

Brief comment about the second post:

In this post, Steve Stafford, author of Revit OpEd blog, provides an idea in response to the question of how to show property lines and setbacks in elevation views, even with irregular sites. Steve proposes the use of mass elements, one for the perimeter of the site, and another one for the setbacks.







For more information, please refer to Post #24654 at Revitforum.org

Brief comment about the third post:

This post, by Martijn de Riet, MdR Advies, was the result of asking around in a previous thread about the use of a mysterious option in the Parameter Properties dialog box. It's that option on the lower left corner that says "Add to all elements of the selected category". Well, Martijn found a use for this option in his consulting work, and he is sharing the explanation with us. To mention an example, this option is useful when you need to spread a certain custom parameter that exists in only one window type, to all the other windows, so that you can have a uniform parameter that you can use to calculate totals.








Since, for sure, Martijn can explain it better than I do, for more information, please refer to Post #23997 at Revitforum.org

See you next month...

Wednesday, August 24, 2011

Creating a hatch override by Phase, Pt 3

So, here it is: the final part on how to create a hatch override based on Phasing of the overridden Walls.
In the first part I showed the methods on how to override hatch by using Yes/No Parameters combined with a View Filter. The second part showed how to set up schedules to check the proper usage of these parameters.

This method can be used on a lot of things. Combined with the View Filters, it's a very powerful tool. But you don't want to go by an immense set of Schedules one by one to check your model. So you place them on your sheets. But this creates two new problems:
1. If you're working on a big project with, in this case, a lot of Walls, the Schedules will fill up fast and clutter your sheet.
2. When everything is OK, you also don't want to have a bunch of empty Schedule titles and headers sitting there on your sheet, see image 17. Placing them on a separate sheet isn't an option, since that way it isn't "live" on the model. I like to look at my Plan View Sheet and see if there is any problem here.


Luckily, there is a solution for both problems:
1. To keep the Schedule size manageable you can use the Sorting settings in the Properties. Go to the Sorting tab of the Schedule View and Sort by the parameter "override wall hatch". After this, check off "Itemize every instance". This will group all walls into 1 Row, see image 18. This off course makes the schedule a lot more clear. But it also let's you edit the "override wall hatch" parameter for all walls in the schedule at once.


2. There is an exception to the general rule in Revit that there cannot be any empty views in your sheet. You've guessed it: it IS possible to have empty schedules on a sheet.

In order to do this, go to the Schedule, open the Appearence Tab from the Properties and uncheck both "Show Title" and "Show Headers", see image 19.


Having done this, you will see that all sheets have magically disappeared from the sheet, see image 20. Not completely though, hover with your mouse pointer above the area the schedules are supposed to be and you'll find that you can still select them.


But they will only show up if you have a problem with a Wall, like in image 21. Here, I "accidently" checked the "override wall hatch" for a new Wall, which makes this schedule pop up. You're right, it doesn't show it's headers, so you're kind of in the dark on what's going on. Right click > Edit schedule to find out.


Like I said before: it's not a completely automated check, but it's pretty close in my book! Happy Reviting!!

Sunday, August 21, 2011

Creating a hatch override by Phase, Pt 2

In the previous blog post, I showed a method of overriding hatch patterns based on a Yes/No parameter. I also stated that this is a manual usage and should be very thoroughly checked before issuing the documents. But there is a way to (sort of) automate the process of checking using schedules.


How to check if all parameters are applied correctly? Well there can be a limited amount of scenarios here:
1. All existing walls have parameter "override wall hatch" applied, none of the new walls have it. So everything is fine and works as aspected.
2. Somebody (not you off course) accidentally checked the parameter "override wall hatch" to one or more new Walls. Result: some new walls get overridden like shown in image 9.


3. Somebody accidentally unchecked the parameter "override wall hatch" for an existing wall resulting this wall to have the wrong hatch, see image 10.


4. This is a tricky one: there is no value applied yet. Using this method you are bound to run in a weird bug: A yes/no parameter can actually have 3 values: Yes (1), No (0) and (not defined), see image 11.


This never happens for loadable families because either Yes or No is already applied in the Family Editor. Newly created System Families however ALWAYS start with the value . For this image, I created a new Wall in the Existing Phase. Doesn't matter how you do it, by using the new Wall command or the Create Similar command: result is the same.
A -value is a programmatic term for a value that's supposed to be there but isn't (a Yes/No is supposed to be either Yes or No, 1 or 0). But since it's not defined it's neither of them. What is it? Well, I don't know, but Revit sees it as less then 0. So you can use it in a schedule.

So go to View > Schedule > Add a Wall Schedule. Name it "check override new walls" (or something less lengthy). Set the Phase to New and the Phase Filter to New only.
Go to Fields tab > Add the system parameter "Type" and your custom "override wall hatch" parameter to list and identify all Walls created in the Phase "New" with this parameter applied, see image 12.


Go to Filter tab > Add a filter and filter on "override existing hatch" to equal Yes, see image 13.


This way you are showing all Walls created in Phase New which have the "override existing hatch" applied (which is wrong, since these walls are New).
So, if all is well there shouldn't be ANY walls in this schedule. To check this, go to Plan View New and check the "override wall hatch" for any Wall created in Phase New, see image 14.


So this takes care of the "accidental" override of New Walls. Now to check if you correctly applied the filter parameter to all existing walls:

Duplicate the Schedule View and rename it to "check override existing walls" (or something). Set the Phase to Existing. This will show all Walls created in this Phase.
Go to the Filter Tab. Change the Filter for the "override wall hatch" to "Less then or equal to" No. This will filter for 2 things:
1. Existing Walls that have the "override wall hatch" parameter not checked (value = No or 0), see image 15.


2.. Exising Walls having the "override wall hatch" not applied (value = or less then 0), see image 16.


So now we have all the bases covered: you can use these schedules to check whether you applied the corect parameters in reference to the Phase the Wall was created in.
The third part of this weblog will deal with making this all look nice and work user-friendly.




Wednesday, August 17, 2011

RFO Post of the Month Nominees

So I recently volunteered to write a blog post on the RevitForum Post of the Month nominees. Since this is the initial post I have been thinking about how to set this up. There are generally two kind of nominees:

1. Initial postings with tips and/or tricks.
2. Responses to a problem posted by someone else.

So the first one will be easy to handle. But reading back the different nominees, there might be a problem since our threads have a way of swirling into different directions from the original post. But let's give it a try anyway. Nominees are in random order and this blog is written while trying to be as unprejudiced as possible.
As for the nominees: if you feel I misunderstood or wrote anything that doesn't do justice to your post in any way, please don't hesitate to contact me. You probably know where to find me...

There's a huge problem with setting up sheets in Revit: it's very difficult to align Views and View Titles. This is partly solved by the introduction of the Guide Grid in Revit 2012, but this method has it's limitations. One major being that you still need to place the View Title on sight.
In this post Scott gives a tutorial on how to create and use a Detail View and View Title that has the View Title automatically jump to the correct position on the sheet without having to eyeball it. Further more, sample files are provided.

Schedules are a very strong feature in Revit. Their most common use is generating quantities for the modelled elements. But what if a building model has families with inconsistent usage of parameters, for instance multiple window families that all have different parameters for the width. Your schedules are bound to be a huge mess, since it's impossible to get all the "widths" into one column.
For this, there is a tiny checkbox in the Schedule properties dialogue box which let you, just for this project, push parameters between different families without having to actually edit the families.

The question raised in this thread is how to show Property Lines in section views. Since they really are 2d components you cannot visualise them in section views. To add to the complexity the solution needed to also work when the Property Line is not cut perpendicularly and the graphical representation needed to be adjustable, ruling out a lot of options.
Steve came up with a solution using Masses for this, which complies to all demands and added some functionality.

The thread started with a general tip on why Grids sometimes do not show up on a certain level. Mr Spot added a comment explaining on how to use a Scope box in a 3D view to regulate the control of Grids, Level Annotations and entire View Extents for the entire project in one simple action.

The original post was asking for a way to change a Plan Detail Callout type from Plan View to Detail View. As it was pretty soon clear this cannot be done, the thread evolved into a discussion about the pro's and cons about the different ways to setup detail views and which type to use.
CBukowski came up with a thorough analysis of the way the View Depth and Cut Plane works for Detail Callouts. He stipulated that View Depths of these Callouts is defined by their parent View and explains what happens if the Parent View gets deleted.

Following up on different previous threads regarding the conversion of Revit projects to 3D Max using the fbx export Gaby424 wrote up a thorough tutorial on how to properly setup your export from Revit and import in Max in a way that you can reuse the materials and textures in Max (or replace them without any problems).

There have been quite a few threads regarding the speckles appearing on surfaces with a painted material when rendering in Revit. Sdbrownia did some testing with the Paint materials and posted his findings here.

Following up on another thread, mdradvies posted a tutorial on how to align Wall Sweeps with other Revit components in 3D, which is a more precise method of controlling the extents of the Sweep then simply dragging the blue dots at the end of a Sweep.

The thread started out as a simple question on how to create a roof with two different plate heights but as it seemed later on this problem wasn't all that easy to fix. mark b accomplished this at last and provided the correct roof AND a tutorial on how to create it as an attachment in his posting, along with some tips and tricks on how to set up roofs in Revit.

A remark showing a hint of frustration on the difficulties in implementing a different approach of building projects in a thread that was dedicated to the new annotation options for 3D Views in Revit 2012.

So here they are. Some required more explaining than others. All nominees are located in threads well worth the reading. Off course, anyone reading this is also going to click through into the postings... Please let your preferences be known by voting here for your favourite post!!!

Tuesday, August 16, 2011

Creating a hatch override by Phase, Pt 1

In this thread here on RFO there was a question on how to override a hatch depending on phasing of the object, in this case a Wall.
To be honest, it cannot be done. But you can get close... For arguments sake, let's say you're starting on a blank project without any template.

I created a Project File with two OOTB Phases: Existing and new. Both have a Plan View Level 1. Then I created a simple square box in Phase Existing and added some Walls in Phase New.
I created a Section View in Phase New to top it off, see image 1.


Then I created a Phase Override to show new only. Set existing and temporary to not show, image 2. This is not directly needed for the example at hand but can come in handy when you are working on large projects.


At this time you can't filter on Phasing, so you need to work around that.
Create an extra project parameter to filter on. Go to Manage > Project Parameters > Add > Project Parameter > Create a parameter of the Yes/No category. Name it "override wall hatch" or something. Apply it to the category Walls, see image 3.


Open a new 3D View which has all walls in them, temporary apply the Phase Filter "New Only" to only show the Walls created in Phase New, see image 4.


Select all Walls visible, check OFF the parameter "override existing hatch", image 5.


Now you can create a View Filter for the section / elevation views by filtering for the yes/no to equals No, see image 6.


To do this, take the following steps:
a. Go to the Section / Elevation View in which you want to apply the filter.
b. Go to Visibility Graphic Overrides, Filter Tab.
c. Click Edit / New. Create a new Filter.
d. Apply the filter to category Walls.
e. Select the "override wall hatch"-parameter that you just created and set it to Equals "Yes". Now click OK. This filter will select all Walls which have been marked by the "override wall hatch"-parameter.
f. In the Filter Tab of the Visibility / Graphics box, select the Cut Pattern and set it to non-visible or any other override you might like (image 7).


Image 8 shows the desired effect.


BIG WARNING: This is NOT a automatic method. You need to keep checking if all the parameters are applied correctly. Besides that, Revit has some quirks when it comes to System Families using Yes/No-parameters. More on that on the next post.