Showing posts with label Schedules. Show all posts
Showing posts with label Schedules. Show all posts

Friday, December 17, 2010

I am busy creating a schedule for an area plan. I need to get the number of trees that I need to cut down, can keep and plant new. For this I created a Planting family with a few type parametes that change the appearance of the tree (e.g. the Yes/No parameter kappen (which means to cut down in Dutch) is linked to the visibility of a cross across the tree symbol).

So far so good.

I can then create a schedule with my familty types and totals. Cool.


But now I want to only see the trees left at the end of the project.

One option would be to phase the trees (set the phase demolished parameter of all trees to be cut down to the phase of the new construction), but for other reasons I did not want to go that way.

So I figured I would simply set the filter of the schedule and filter out the appropriate family type. But, lo and behold, I don't get that option!

A quick Google-search reveals that this is not a bug but a feature (or something like that).

So for a workaround I am now using the Type Mark parameter, setting it to different values for the different family types. (The other option would have been to create my own shared parameter and attach it to both the project and the family, but I'm just lazy. Plus I can now use this to tag the trees as well.)


But I don't get why I cannot filter based on family type. What would have been the trouble with this? Can someone explain?

Tuesday, October 5, 2010

Since I have been slow to discover new things that I absolutely have to share with the rest of the world (who propably already knows...) I figured I will start writing a few things about basic concepts in Revit. My aim here is to further understanding of the program so that you don't just know the "to do this follow these steps" but the "why" behind it.

Today we'll start with something relatively simple: Views and Schedules. What are they, what are they for and how do you use them.

The first thing we need to let go as we transition from a 2D/3D CAD program (like AutoCAD) into a program that uses a Building Model (like Revit) is the way we view a drawing. In a 2D program a drawing is just a digitized version of lines on paper, which represent a floor plan or an elevation.

In Revit that is not true.

In Revit you build the (almost) entire building inside the computer, putting the information into a database that runs in the background. This means that instead of two lines representing a wall in the floor plan I put into the database an object that is a wall with a certain length, height, position in the building, structure and other characteristics. And from this information Revit will then calculate a drawing that shows the parts of the building that fall within the visible range, e.g. a floor plan or an elevation.

Once we get our minds around this we start to see the possibilites opening up. We have a database! And databases are great not only for storing information but also retrieving the specific information you need.

One way of retrieving this information is by creating Views. This is basically a way to ask the database to "show me any and all objects that I can see from this point, looking in this direction for this distance." This specified by the type of View (Floor Plan, Elevation, Section, etc), the View Range, the Far Clipping, etc. Any 3D object that is in the line of sight will be displayed. I can then further customize each view with Annotations (we'll get to that later), shadows, and a few other things, to suit my needs.

The great thing of this is also that when I change an object in the model - move a wall - the change is refelcted in all views where this object is visible. I also means that I can have multiple plans of the same section of the building - floor plan of the ground floor - that convey different information - electrical installations, square meters, wall and floor finishes - without having to redraw them every time. This reduces the danger of drawing errors considerably.

Another way of retrieving information form the building database is using schedules. This is a non-graphical way of looking at the same data, and so as architects and draftspeople something we are not really used to. But tell the builder who does the calculations on how expensive the project is going to be that you can give him exact numbers on the square meters of brick wall or the number of doors and he well love you forever (or at least until he sees what the costs of your funky design are...).

So stop seeing schedules as something alien and weird and start seeing them as just another way of presenting your design. In the end there are (unfortunately) a lot more people interested in the numbers than in the esthetics.

This concludes my first article on Basic Concepts in Revit. As you can see this is all theoretical and no hands-on. I will try to write some hand-on instructions on the concepts that I cover in other posts. If you have some concept of Revit that you are struggling with, please feel free to leave a comment.

Wednesday, July 15, 2009

Just a quick tip on what not to do (as I am learning the hard way right
now):

Don't print preselected sheets when in a schedule view.

...oh, and...

Don't try to import families into a project that only has a schedule view open.

Both lead to unpredictable Revit behaviour or even crashes.