View Full Version : Double counting in material takeoff
Archman
2007-07-20, 05:59 PM
I am finding that unless you model specifically with a material takeoff in mind early, that it is darn near impossible to get an accurate material takeoff later.
My dilema is as follows. I have a lobby that has been modelled, documented and rendered. We have a combination of stone and wood on the walls. At the time we created the model, we were only concerned with getting good renderings out and creating the construction documents for the project. Now, a need has come up to do a material takeoff of the wood and stone in the lobby.
Now originally we created a wall type in the lobby that had stone defined in the wall editor as the finish material. Then we painted areas of the lobby walls with wood material with the paint bucket tool as needed. We did this becasue the wall type in our documents is the same regardless of wood or stone veneer. We were relying on the interior elevations to show where the stone and wood occurs. Now I am finding that Revit is doulbe counting the stone in the material takeoff because stone was defined in the wall editor as the finsh material of all walls. The wood number is pretty much correct becasue it's just counting what was painted.
I guess I'm just ranting here a little bit, as I'm frustrated that a material takeoff was promised in the first place. I know how to correct the problem, but it will be time consuming. Thanks for listening.
aaronrumple
2007-07-20, 08:05 PM
Set all the walls to generic using a "Default" material.
Paint everything. Throw any default materials out.
Calvn_Swing
2007-07-20, 08:54 PM
We usually model finish materials with a thickness (be it stone veneer, wood, etc...) with a second wall. So, in your case we'd have the studs and gyp modeled as Type C3, and then draw a stone veneer next to the wall and then align them together and join them. This way you can control things more directly. We also would have either a named reference plane for the height between the stone and the wood, or a level. The upside of the level is you can lock a wall's base or top to a level in their properties dialog, while locking them to a reference plane has to be managed graphically. If only they'd let me select named reference planes in the drop-down list...
We do exactly what Aaron recommends for paints and other sub 1/4" coatings. Since we're placing them over gyp, we want the gyp to be "double counted."
The best part? You can easily change your finishes without ever effecting the core walls, their tagging, etc...
Archman
2007-07-21, 03:55 AM
Set all the walls to generic using a "Default" material.
Paint everything. Throw any default materials out.
This is what I was planning to do to correct the problem. It will be time consuming, but it's doable.
Archman
2007-07-21, 04:05 AM
We usually model finish materials with a thickness (be it stone veneer, wood, etc...) with a second wall. So, in your case we'd have the studs and gyp modeled as Type C3, and then draw a stone veneer next to the wall and then align them together and join them. This way you can control things more directly. We also would have either a named reference plane for the height between the stone and the wood, or a level. The upside of the level is you can lock a wall's base or top to a level in their properties dialog, while locking them to a reference plane has to be managed graphically. If only they'd let me select named reference planes in the drop-down list...
We do exactly what Aaron recommends for paints and other sub 1/4" coatings. Since we're placing them over gyp, we want the gyp to be "double counted."
The best part? You can easily change your finishes without ever effecting the core walls, their tagging, etc...
I see that this would be a great solution if I had known I would need to do a material takeoff from the beginning. This reinforces my belief that if we as architects are going to start providing material takeoffs, we should be charging additional fee for it. In order to get accurate numbers, it necessitates modelling to a level of detail we would not be thinking about otherwise. Also, material takeoffs seem to put more liability on the architect. What if a price were based on the architect's material takeoff, and he or she were wrong. I'm not saying we shouldn't do it; only that we should be adjusting the fee to account for the additional amount of detail required and the additional liability incurred.
chris.needham
2007-07-21, 07:26 AM
I see that this would be a great solution if I had known I would need to do a material takeoff from the beginning. This reinforces my belief that if we as architects are going to start providing material takeoffs, we should be charging additional fee for it. In order to get accurate numbers, it necessitates modelling to a level of detail we would not be thinking about otherwise. Also, material takeoffs seem to put more liability on the architect. What if a price were based on the architect's material takeoff, and he or she were wrong. I'm not saying we shouldn't do it; only that we should be adjusting the fee to account for the additional amount of detail required and the additional liability incurred.
I totally agree, this is not the architects/designers job. I have provided some basic material takeoffs in the past, but have always made sure that the client understands they are only a rough estimate, for preliminary pricing only.
Chad Smith
2009-04-21, 04:32 AM
I've just encountered this issue.
In the attached image, I have a brick wall that has a change in brick directions above and below the window. It's still the same material (brick), just orientated differently, even though they are defined as two separate Materials in Revit. So even if I give the vertical bricks the same material properties as the horizontal bricks material there is still a duplicate in the data.
Coming across this has now made me very nervous about the data which is extracted out of Revit. Something as simple as this which looks straight forward enough produces incorrect results. This is not good for a BIM application.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.