Here's the scenario. It's very common, and Revit doesn't have an ideal solution. You are designing a hotel, or maybe an apartment block: any building with repetitive modular layouts, where each module contains 2 or more rooms subdivided by walls. The construction technique is traditional wet trades, eg blockwork & plaster.
One solution is to use groups. There are many disadvantages, especially when groups have to be maintained in several different buildings which are slightly different but share the same "typical units". Another solution is to use links. One of the downsides is that the walls will not join properly, you lose the self-healing property between walls in different files. Ideally, Revit would give us the ability to enable self-healing of walls in links. Perhaps this is a difficult coding problem. Perhaps this type of construction is not commonly used in the US so it's not seen as an urgent issue. I don't know, but I desperately need a solution.
In recent times, we have been maintaining two files. The first file contains "Typical Layouts". There may be 8 or 10 different types here. Perhaps there are also 20 or 30 obsolete layouts, remnants of the design process. It is a working area, but it is also the source of several sheets in our Concept Report. Here we blow the rooms up to a larger scale and show more detail than in the General Arrangement plans taken from the project file.
The layouts themselves exist as groups. Typically the surrounding walls are outside the group. We don't want to duplicate walls as we copy the group around in the project. So the project file consists of the outer shell of the building, plus the main dividing walls which separate the hotel rooms or apartments.
We used to place the modules as groups from day one, but now I prefer to delay that transition. We place them as links, with the intention of binding them as groups later on when the cycles of design changes have run their course. The downside is that we don't have clean joins in the GAs but we have learnt to live with that.
Last weekend I resolved to clarify my understanding of group insertion points and link origins in order to define a clear protocol for saving groups out multiple times as the designs develop, confident that the links would maintain their positions when reloaded into the project. This is quite easy to do. But along the way I had some interesting thoughts for "self-healing workarounds".
The first step was to disallow join, and pull the internal walls back to the core face of the surrounding wall, instead of jumping to the centre line. This minimises the area of overlap.
My next idea was to somehow embed a detail patch in the group to clean up this junction further, A detail item cannot belong to a model group, so I decided to embed the detail within a Generic Model. The GM family contains only one model element, an "invisible centre pole". You may be familiar with this device. Because the cut-plane of the view intersects this invisible line, the detail item will become visible.
With a little tweaking, I soon had a family with parameters for wall thickness & plaster thickness, linking through from the GM to the detail item. You can place it at wall junctions and lock it to the centre line of the partition wall.
One final trick is to join geometry inside the Typical Layout file. Now you can have birds-eye cutaway views of the rooms with nice clean wall junctions.
The diagram below summarises the whole process. I have yet to implement this in a live project, so there may well be problems that I have not foreseen, but I am optimistic that it will prove to be a useful technique.
I played with room separation lines & also a protocol for marking the origin point of the group. Actually this all took place a few weeks ago and since then we've been implementing. The idea of exporting from group to link repeatedly does not work well. The buildings that the layouts are linked into treat the resulting links as totally new objects. Any dimensions that reference them are lost. So it's not a robust workflow. In practice you need to make changes directly in the link files and load these back into the typical rooms file to make this update.
Rooms within the links cannot have unique numbers in the project. This would also be a nice enhancement & I am guessing that it would be easier to code than the wall joining behaviour. Make the rooms into separate groups, save as separate links. Can be bound as groups at an early stage than walls etc. Could be placed directly in project, but changes will be harder to manage. Room numbers need not be added in the earlier stages. Room group/link should also have an origin marker
To allow the rooms in the project to detect the walls of the links you need to select the link, go to type properties, check "room bounding".
Normally the only parameter that can vary between groups is "room number". One added bonus with 2014 is that we can now specify other parameters that vary between groups. For example we could add a shared project parameter for rooms called "apt no"
Would be interested to hear how other people handle these scenarios. These little workarounds are all very fine, but ultimately I am left feeling "there has to be a better way"
One solution is to use groups. There are many disadvantages, especially when groups have to be maintained in several different buildings which are slightly different but share the same "typical units". Another solution is to use links. One of the downsides is that the walls will not join properly, you lose the self-healing property between walls in different files. Ideally, Revit would give us the ability to enable self-healing of walls in links. Perhaps this is a difficult coding problem. Perhaps this type of construction is not commonly used in the US so it's not seen as an urgent issue. I don't know, but I desperately need a solution.
In recent times, we have been maintaining two files. The first file contains "Typical Layouts". There may be 8 or 10 different types here. Perhaps there are also 20 or 30 obsolete layouts, remnants of the design process. It is a working area, but it is also the source of several sheets in our Concept Report. Here we blow the rooms up to a larger scale and show more detail than in the General Arrangement plans taken from the project file.
The layouts themselves exist as groups. Typically the surrounding walls are outside the group. We don't want to duplicate walls as we copy the group around in the project. So the project file consists of the outer shell of the building, plus the main dividing walls which separate the hotel rooms or apartments.
We used to place the modules as groups from day one, but now I prefer to delay that transition. We place them as links, with the intention of binding them as groups later on when the cycles of design changes have run their course. The downside is that we don't have clean joins in the GAs but we have learnt to live with that.
Last weekend I resolved to clarify my understanding of group insertion points and link origins in order to define a clear protocol for saving groups out multiple times as the designs develop, confident that the links would maintain their positions when reloaded into the project. This is quite easy to do. But along the way I had some interesting thoughts for "self-healing workarounds".
The first step was to disallow join, and pull the internal walls back to the core face of the surrounding wall, instead of jumping to the centre line. This minimises the area of overlap.
My next idea was to somehow embed a detail patch in the group to clean up this junction further, A detail item cannot belong to a model group, so I decided to embed the detail within a Generic Model. The GM family contains only one model element, an "invisible centre pole". You may be familiar with this device. Because the cut-plane of the view intersects this invisible line, the detail item will become visible.
With a little tweaking, I soon had a family with parameters for wall thickness & plaster thickness, linking through from the GM to the detail item. You can place it at wall junctions and lock it to the centre line of the partition wall.
One final trick is to join geometry inside the Typical Layout file. Now you can have birds-eye cutaway views of the rooms with nice clean wall junctions.
The diagram below summarises the whole process. I have yet to implement this in a live project, so there may well be problems that I have not foreseen, but I am optimistic that it will prove to be a useful technique.
I played with room separation lines & also a protocol for marking the origin point of the group. Actually this all took place a few weeks ago and since then we've been implementing. The idea of exporting from group to link repeatedly does not work well. The buildings that the layouts are linked into treat the resulting links as totally new objects. Any dimensions that reference them are lost. So it's not a robust workflow. In practice you need to make changes directly in the link files and load these back into the typical rooms file to make this update.
Rooms within the links cannot have unique numbers in the project. This would also be a nice enhancement & I am guessing that it would be easier to code than the wall joining behaviour. Make the rooms into separate groups, save as separate links. Can be bound as groups at an early stage than walls etc. Could be placed directly in project, but changes will be harder to manage. Room numbers need not be added in the earlier stages. Room group/link should also have an origin marker
To allow the rooms in the project to detect the walls of the links you need to select the link, go to type properties, check "room bounding".
Normally the only parameter that can vary between groups is "room number". One added bonus with 2014 is that we can now specify other parameters that vary between groups. For example we could add a shared project parameter for rooms called "apt no"
Would be interested to hear how other people handle these scenarios. These little workarounds are all very fine, but ultimately I am left feeling "there has to be a better way"