Tuesday, August 30, 2011
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) :
Central African Republic
Well, and probably The Vatican?
See you in Revitforum.org...
Saturday, August 27, 2011
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):
- Creating custom Panel geometry.
- Creating custom Mullion profiles.
- Assigning Detail Components to the Panels and Mullions.
- Setting up useable schedules and tags
- 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.
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
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.
Thursday, August 25, 2011
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
Sunday, August 21, 2011
Go to Filter tab > Add a filter and filter on "override existing hatch" to equal Yes, see image 13.