Hi All,
Thanks for answering all/most of my Revit related questions this past year or two
I know this one has been done somewhat to death, I've certainly spent more than enough hours reading, discussing and trying to resolve, but I am still yet to come to any practical solution. When working with apartment groups in multi level res we are trying to streamline the documentation process (specifically for kitchens, although I imagine the work flow can be repeated else where).
My current conclusion is that having individual apartment types as model groups is the best way to go. (Links have been tried and discounted as a solution, but am happy to review this if there is a strong enough argument). Within the apartments we obviously have kitchens, and debate rages around how we should be modelling them.
The biggest issue is that when it comes to documentation, we need dedicated interior elevations of kitchens showing door swings, shelf heights, etc. Currently the kitchens are modeled with generic "cubes" and then all detailing is applied via 2D Detail Components in the relative elevations. (e.g. The kitchen island is one generic 3D block, or a series of 3D blocks, and then in an elevation view 2D Detail Components for door swings and shelf heights are applied.) The issue with this is it leaves the door ajar for conflicting information to be shown when/if people change one drawing and forget to update others.
I would therefore like to have 3D Models of the individual kitchen parts, the bench top, casework, the sink, etc. and compile these elements as "Kitchen Type 1" (either a family or a group) and nest it into our apartments. Detailing is done within the individual casework familes. Taking a section/elevation through the overall kitchen therefore immediately shows the door swings and what not. The kitchen is modeled as it would be constructed, no further detailing needs to be done in 2D, and any updates are immediately reflected in all drawings.
Problems (Kitchen as family):
-2D annotation added to individual casework families shows up when not wanted. (Because the entire kitchen is one family, cutting through it causes *all* 2D elements to show, even from casework not seen in the view.)
-making the casework families shared solves the above problem, but opens another can of worms (causes all sorts of issues with updates not being loaded into the project correctly)
-the patience and skill required to properly maintain the kitchen families is likely beyond many of the staff
-churn times when updating can quickly get to mouse slamming levels of frustation (yet to fully test)
Problems (Kitchen as model group)
-using a model group means not being able to link parameters (as far as i'm aware). this means that every single individual cabinet type needs to have it's material parameters set, rather than having a complete kitchen family where all those parameters can be linked to one common parameter, allowing much faster changes.
-i've also heard as a general best practice guideline that nesting groups should be limited as much as possible. making a model group of the kitchen would then require nesting it into apartment groups, which are potentially already nested into a level group.
- if each bit of casework has a whole bunch of parameters (thickness, material, height, number of shelves, etc.) and there are a range of casework pieces (1 drawer, 2 drawer, single swing, double swing, etc.) across a range of kitchen types, then some are concerned about all this information bogging down load times and over complicating the project. they argue the time and effort involved in correctly modeling 3D kitchens is far greater than putting 2D Detail Components into kitchen views.
hope that all makes sense! what is your preferred method of modeling/documenting kitchens in apartment groups?
Thanks for answering all/most of my Revit related questions this past year or two
I know this one has been done somewhat to death, I've certainly spent more than enough hours reading, discussing and trying to resolve, but I am still yet to come to any practical solution. When working with apartment groups in multi level res we are trying to streamline the documentation process (specifically for kitchens, although I imagine the work flow can be repeated else where).
My current conclusion is that having individual apartment types as model groups is the best way to go. (Links have been tried and discounted as a solution, but am happy to review this if there is a strong enough argument). Within the apartments we obviously have kitchens, and debate rages around how we should be modelling them.
The biggest issue is that when it comes to documentation, we need dedicated interior elevations of kitchens showing door swings, shelf heights, etc. Currently the kitchens are modeled with generic "cubes" and then all detailing is applied via 2D Detail Components in the relative elevations. (e.g. The kitchen island is one generic 3D block, or a series of 3D blocks, and then in an elevation view 2D Detail Components for door swings and shelf heights are applied.) The issue with this is it leaves the door ajar for conflicting information to be shown when/if people change one drawing and forget to update others.
I would therefore like to have 3D Models of the individual kitchen parts, the bench top, casework, the sink, etc. and compile these elements as "Kitchen Type 1" (either a family or a group) and nest it into our apartments. Detailing is done within the individual casework familes. Taking a section/elevation through the overall kitchen therefore immediately shows the door swings and what not. The kitchen is modeled as it would be constructed, no further detailing needs to be done in 2D, and any updates are immediately reflected in all drawings.
Problems (Kitchen as family):
-2D annotation added to individual casework families shows up when not wanted. (Because the entire kitchen is one family, cutting through it causes *all* 2D elements to show, even from casework not seen in the view.)
-making the casework families shared solves the above problem, but opens another can of worms (causes all sorts of issues with updates not being loaded into the project correctly)
-the patience and skill required to properly maintain the kitchen families is likely beyond many of the staff
-churn times when updating can quickly get to mouse slamming levels of frustation (yet to fully test)
Problems (Kitchen as model group)
-using a model group means not being able to link parameters (as far as i'm aware). this means that every single individual cabinet type needs to have it's material parameters set, rather than having a complete kitchen family where all those parameters can be linked to one common parameter, allowing much faster changes.
-i've also heard as a general best practice guideline that nesting groups should be limited as much as possible. making a model group of the kitchen would then require nesting it into apartment groups, which are potentially already nested into a level group.
- if each bit of casework has a whole bunch of parameters (thickness, material, height, number of shelves, etc.) and there are a range of casework pieces (1 drawer, 2 drawer, single swing, double swing, etc.) across a range of kitchen types, then some are concerned about all this information bogging down load times and over complicating the project. they argue the time and effort involved in correctly modeling 3D kitchens is far greater than putting 2D Detail Components into kitchen views.
hope that all makes sense! what is your preferred method of modeling/documenting kitchens in apartment groups?
)
Comment