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"
Andy--
ReplyDeleteI'm in the U.S. and I've used a similar method as you describe, though I didn't create the groups before linking them into the main project. That made quite a mess when I bound the links after the layouts were finalized--some instances "failed" and deleted themselves amongst other issues. I don't have a better solution than what you describe and share your wish for a better way (tried assemblies once--not a good choice). I can; however, definitively say that NOT using a group/link method and just trying to lay out all the rooms/apartments in the main file is bad way of doing things (especially with inexperienced team members)
Thanks Andy. I think there will be some clean up works in exported CAD, or needs to assign object styles+layer mapping carefully in patch family to match each wall layers. Most of our projects we have a DWG as part of deliverable. Still better than leaving walls unconnected.
ReplyDeleteGood article and a subject there has been much debate over in my office.
ReplyDeleteOur method is to use links and live with the wall clean-up issues. We place the rooms in the linked units, which allows us to schedule the rooms grouped per link. We use room separation lines as to contain the extents of the unit, which are indicated in a thick redline for checking.
An added bonus is that in the early project stages we can then also use rooms to indicate the entire unit area and volume, as the unit rooms are not present in the main model, but do schedule.
The biggest drawback of this workflow is that if you change anything like a family, you need to reload or change it in all the linked files, which can be a bit tedious. you also need to aware of how you dimension items. If you dimension to a link you run the risk of them being deleted, which is why we dimension items inside the link and use view templates to control their visisbility.
Overall, links seem to be a fairly robust workflow, if you are aware of the limitations.
Thanks Everyone for the feedback. Sadly DWG deliverables are always a pain, very frustrating when people judge you by whether the DWG exports look as if they were drafted in CAD. That's one reason we always used to use groups, but for the last few projects we have switched to links. As Darryl says it's more robust.
ReplyDeletelinks would be fantastic if we could take the link name!
ReplyDeletethe best I've come up with an area plan created in the host project then turn off everything except the tag (which is there to tag the room / apartment number) and overlay that view onto a plan view on the sheet....not very BIM but works if your're careful!.
perhaps the most annoying issue is not being able to schedule room areas (sop apartment NIA) per floor but at least there are workarounds if you number aparaments carefully and use filters.
that meant to say TAG the link name
ReplyDeleteGood morning. Just found this excellent post. Have a project in revit with this same issue, almost three years later. Are there newer better methods or are we stuck with the same limitations in revit 2017?
ReplyDeleteHi Steven.
DeleteThanks for your comment. I'm afraid that nothing has really changed on this front, so we are still relying on the kind of workarounds mentioned above.