Donate Now Goal amount for this year: 2500 USD, Received: 1869 USD (75%)

Page 11 of 12 FirstFirst ... 789101112 LastLast
Results 101 to 110 of 112
Like Tree36Likes

Thread: Documenting typical apartments

  1. #101
    Forum Co-Founder Twiceroadsfool's Avatar
    Join Date
    December 7, 2010
    Location
    Dallas, TX
    Posts
    10,277
    Current Local Time
    02:06 AM
    Quote Originally Posted by sdbrownaia View Post
    The trick to that is how do you assure the users actually update the ones outside the main project and not edit group in the project, what if they edit a material in the host? they have to remember to do it in the outside project. Its a disaster waiting to happen. However, I have done that on ONE job where we had multiple apartment buildings on the same site that shared the same unit types, in that case I did have the groups as sep files, but I wouldn't do it again. Way too much management headaches.
    It gets way worse than that:

    Some Object TYPES (wall definitions, material definitions) simply WONT update when the group is reloaded from outside. Period. You get the "the type from the project will be used" message, and now you have disparities in your groups.

    If the unit cloud is the "worst thing ever" then tell them to put on their grown up pants and document all the units in context. It's the only "better way," and it's a lot slower to set up and maintain.

    Doing it in an outside file is LOL bad.

    Sent from my Pixel 3 XL using Tapatalk
    tidalwave1 likes this.

  2. #102
    Senior Member DavidLarson's Avatar
    Join Date
    July 10, 2015
    Location
    Boise, Idaho
    Posts
    680
    Current Local Time
    01:06 AM
    That's good to know. The more reason to use the unit cloud the better

  3. #103
    Member
    Join Date
    July 21, 2018
    Posts
    57
    Current Local Time
    05:06 PM
    we currently do our unit documentation in context, and i suspect the idea of unit copies off in a "cloud" may cause riots, but obviously seems like something worth pursuing/pushing.

    [QUOTE=boujou99;219275]
    Quote Originally Posted by Twiceroadsfool View Post
    Aaron,
    If you don't include the exterior envelope walls in the unit groups, do your unit sheets not have exterior walls? Are you showing a generic stud wall without an exterior finish on the unit sheets? Do you separate the exterior envelope walls from the unit core walls and if so, do you have to match the openings in both walls or do you join the walls?
    Quote Originally Posted by Twiceroadsfool View Post
    They show a generic wall that isn't even called a stud wall. Exterior walls are detailed in wall sections and plan details. Unit plans are explicitly for what happens inbound of the unit boundary. I don't call out materials or wall types on the demise walls or corridor walls, either.
    agree with exterior walls and core/party walls not being in the unit groups, but am curious what people recommend when it comes to applied finishes to walls (e.g. bathroom wall tiles) and where they belong. for the sake of simplicity and reducing wall types, and the fact that we don't actually care about the applied finishes in a lot of our construction documentation, we currently tell people to model a tiled wall separately to the structural wall and just position it at the face.

    given these tile walls and the internal walls are part of the unit group they will show in the "Cloud Unit" no problem and can be blacked out along with the generic cloud walls. but it's not uncommon that some of the units/bathroom walls may have an external window whilst others do not.

    aaron you said you don't recommend showing windows at all in the cloud unit plans, but what if the client demands it? e.g. they really want to sell that there is a window to the shower or extensive glazing to the living area, etc.

    1) we currently just use join tool to join the tile wall to whatever wall it aligns with if there are doors/windows present. this means that the tile wall will cut automatically and it also seems to be completely fine varying by instance. the same unit with the same tiled walls can be placed throughout the model and where it coincides with an external window that specific tiled wall instance can join the external wall. i know interaction with elements outside of the group isn't often advised, but in this case it seems to work fine? are you strongly for or against this method?

    2) assuming the client demands it, would you put in windows/doors to the generic cloud walls and how do you ensure consistency when the building updates? unit entry doors, as another example, aren't often in our unit groups but often clients would want to see them on unit plans. curious how consistency is maintained when/if these elements are adjusted in the main model?

  4.    #104
    Forum Co-Founder Twiceroadsfool's Avatar
    Join Date
    December 7, 2010
    Location
    Dallas, TX
    Posts
    10,277
    Current Local Time
    02:06 AM
    Quote Originally Posted by LeChumpOfStultz View Post
    we currently do our unit documentation in context, and i suspect the idea of unit copies off in a "cloud" may cause riots, but obviously seems like something worth pursuing/pushing.
    For what its worth, the Unit Cloud *works fine* and *doesnt have any issues,* but the only major benefit to it is having the Unit Documentation not move around, presumably so it can be started BEFORE the building shape is finalized, which is a lot of the time, for my clients. If the teams are currently HAPPY with doing everything in context (and re-setting up the sheets time and time again), i dont know that i would PUSH them to the Unit Cloud.

    aaron you said you don't recommend showing windows at all in the cloud unit plans, but what if the client demands it? e.g. they really want to sell that there is a window to the shower or extensive glazing to the living area, etc.
    I mean, if the client demands it... I guess you are doing it?

    1) we currently just use join tool to join the tile wall to whatever wall it aligns with if there are doors/windows present. this means that the tile wall will cut automatically and it also seems to be completely fine varying by instance. the same unit with the same tiled walls can be placed throughout the model and where it coincides with an external window that specific tiled wall instance can join the external wall. i know interaction with elements outside of the group isn't often advised, but in this case it seems to work fine? are you strongly for or against this method?
    I wouldnt say strongly either way. If one of my teams asked me about it, here is what i would say:

    If you have something inside and something outside of the group, and they need to be joined, if you use Join Geometry and it starts wanting to *ungroup* itself later, this would be the first thing i would check. Ive seen joined elements do funky stuff, but not always. So if its *working* great. When its not... stop doing it, of course.

    But it also begets the question from earlier: If your client is demanding to see the fenestration in the unit plans, then obviously with and without a window is a different unit? At which point, even if the Join Geo starts causing problems, there isnt a downside to having it as another group, and using an opening family or an edited profile instead of the in/out join geo?

    2) assuming the client demands it, would you put in windows/doors to the generic cloud walls and how do you ensure consistency when the building updates? unit entry doors, as another example, aren't often in our unit groups but often clients would want to see them on unit plans. curious how consistency is maintained when/if these elements are adjusted in the main model?
    Im a bit confused by the question "If the client demands it, would i do it?" Given the nature of your question is "the client demands it (inferring i do not have a choice), whats the alternative answer to yes? Its just a weird and confusing question. Obviously if a client demands it, i assume its going to get done one way or another. So i guess in that case, i would put the doors and windows in the Unit Cloud?

    How would i make sure consistency was maintained? With my eyeballs. Completely manually. Yes, im serious.

    I use Groups on facade elements too, but not in a way that would ever interact positively with the unit clouds. I would simply look at my projects drawings, and coordinate them... Something we should still be doing, even with modeling software.
    LeChumpOfStultz likes this.

  5.    #105
    Member
    Join Date
    July 21, 2018
    Posts
    57
    Current Local Time
    05:06 PM
    That answers all of my questions perfectly and then some, and leaves me with literally no follow-ups or confusion (a rarity for me ) so thanks a million aaron, much appreciated.
    cellophane and tidalwave1 like this.

  6.    #106
    Member
    Join Date
    September 23, 2015
    Posts
    154
    Current Local Time
    03:06 AM
    Good thread. As I try to understand this workflow which I we tried to use a while back somewhere doing VDC work - What is the significance of having 9 quadrants in the template, and what exactly is a "Modeled Legend" ?

  7.    #107
    Forum Co-Founder Twiceroadsfool's Avatar
    Join Date
    December 7, 2010
    Location
    Dallas, TX
    Posts
    10,277
    Current Local Time
    02:06 AM
    Once you surpass 9 of anything, naming and numbering conventions tend to have to add an extra character. The 9 partial plans are just 9 30x42 sheets, set at 1/8". If the project is bigger than that, yes: More need to be added. If its smaller than that, an app that ships with our template removes the extra Scope Boxes, Sheets, Views, etc.

    A Modeled Legend: Do a search for the Previous Phase Annotation Legend, and youll find them. None of the legends are legend views.
    Profoxcg likes this.

  8.    #108
    Forum Addict GMcDowellJr's Avatar
    Join Date
    December 21, 2010
    Location
    Phoenix, AZ
    Posts
    2,627
    Current Local Time
    12:06 AM
    Quote Originally Posted by Twiceroadsfool View Post
    Once you surpass 9 of anything, naming and numbering conventions tend to have to add an extra character.
    I always/sometimes use 2 digits for my numbers for just this reason. I can be a little anal and having the numbers align makes me smile.

    Quote Originally Posted by Twiceroadsfool View Post
    None of the legends are legend views.
    totes
    Profoxcg likes this.

  9.    #109
    Forum Co-Founder Twiceroadsfool's Avatar
    Join Date
    December 7, 2010
    Location
    Dallas, TX
    Posts
    10,277
    Current Local Time
    02:06 AM
    Quote Originally Posted by GMcDowellJr View Post
    I always/sometimes use 2 digits for my numbers for just this reason. I can be a little anal and having the numbers align makes me smile.
    Sure, but you are assuming that right now there is only a single digit there.

    **The following example is just as a discussion point. I am NOT soliciting feedback, and i am NOT looking to change our numbering system. I am aware of ALL of the alternatives of numbering strategies.

    For instance, currently my L1 Plans are numbered as such:

    A2.10- Floor Plan- Level 1- Overall
    A2.11- Floor Plan- Level 1- Area 1
    A2.12- Floor Plan- Level 1- Area 2
    A2.13- Floor Plan- Level 1- Area 3
    A2.14- Floor Plan- Level 1- Area 4
    A2.15- Floor Plan- Level 1- Area 5
    A2.16- Floor Plan- Level 1- Area 6
    A2.17- Floor Plan- Level 1- Area 7
    A2.18- Floor Plan- Level 1- Area 8
    A2.19- Floor Plan- Level 1- Area 9
    A2.20- Floor Plan- Level 2- Overall

    Certainly, yeah... I can add another character so that the single digits are (character count) on par with the double digits, if and when a job is above 10 areas, or ten stories. But to add a leading character for the Area, we are at A2.101 for Area 1. To add one for the Levels too, we are at A2.0101. Im 100% fine with that system ON the larger projects, but i cant justify relegating everyone to a 7 character sheet number (including the decimal), when a large portion of projects ARENT larger than 9 areas, OR 9 levels.

    its easy enough to run a script to modify it to the more extensive system, on the larger jobs.

    FWIW one client has a variant of our template that goes up to 35 levels. Still only has 9 areas, so they split the difference and have A2.011. Im on board with that too. Just not going to START the template that way, for me.
    tidalwave1 and d.stairmand like this.

  10.    #110
    Member
    Join Date
    September 23, 2015
    Posts
    154
    Current Local Time
    03:06 AM
    thanks, I didnt realize that is what you called the phased legends.
    tidalwave1 likes this.

Page 11 of 12 FirstFirst ... 789101112 LastLast

Similar Threads

  1. Documenting a family element
    By D_Incognito in forum Architecture - Family Creation
    Replies: 25
    Last Post: October 17th, 2016, 11:51 PM
  2. Documenting Grouped Units
    By GMcDowellJr in forum Architecture and General Revit Questions
    Replies: 16
    Last Post: February 11th, 2016, 11:28 PM
  3. David Light: Scheduling Apartments
    By David Light Blog in forum Blog Feeds
    Replies: 0
    Last Post: May 10th, 2013, 07:15 AM
  4. Documenting a Revit Library
    By LeanneZ in forum Architecture and General Revit Questions
    Replies: 9
    Last Post: December 21st, 2012, 06:15 PM
  5. Documenting the Revit Template
    By kpcarch in forum Tutorials, Tips & Tricks
    Replies: 14
    Last Post: August 16th, 2012, 10:42 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •