Announcement

Collapse
No announcement yet.

Door & Window frames: which approach do you use?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Door & Window frames: which approach do you use?

    Over time I have seen two approaches to window and door frames.
    One is the OOTB approach, in which a ref plane jig is built, and the frame is modeled as a single extrusion. The result looks most appropriate for a Hollow Metal Frame, as there are no joints in the frame. Model Line joints can be added if needed to show a Storefront based system.
    The other approach is to use nested "Frame" pieces, which are just non hosted or 2 pick generic models converted to Window or Door families, with a simple extrusion on the Frame/Mullion subcategory. The result looks more correct for a storefront framed door or window/relite, as there are joints.
    I am curious what others are doing here? And what drove the decision to use that approach?

    Also, do most people model the frame in the "final" door or window? Or do you do a nested Frame Type? Part of me thinks going the nested & shared route could be useful, because then I can have a Door that actually contains a Door (Leaf) Type and a Frame Type, so the Revit content matches real world construction better. But then I want nested and shared Hardware Groups too, and I find that graphic control of a face based object goes to pot once that item is shared. For now Door and Frame types are just data from a Key Schedule, and only the user can ensure that everything is correct. Call it BiM.

    Gordon
    Pragmatic Praxis

    #2
    Originally posted by Gordon Price View Post
    Over time I have seen two approaches to window and door frames.
    One is the OOTB approach, in which a ref plane jig is built, and the frame is modeled as a single extrusion. The result looks most appropriate for a Hollow Metal Frame, as there are no joints in the frame. Model Line joints can be added if needed to show a Storefront based system.
    The other approach is to use nested "Frame" pieces, which are just non hosted or 2 pick generic models converted to Window or Door families, with a simple extrusion on the Frame/Mullion subcategory. The result looks more correct for a storefront framed door or window/relite, as there are joints.
    I am curious what others are doing here? And what drove the decision to use that approach?

    Also, do most people model the frame in the "final" door or window? Or do you do a nested Frame Type? Part of me thinks going the nested & shared route could be useful, because then I can have a Door that actually contains a Door (Leaf) Type and a Frame Type, so the Revit content matches real world construction better. But then I want nested and shared Hardware Groups too, and I find that graphic control of a face based object goes to pot once that item is shared. For now Door and Frame types are just data from a Key Schedule, and only the user can ensure that everything is correct. Call it BiM.

    Gordon
    I prefer and encourage the nested approach for companies that want to do frame and panel elevation sheets where the two are broken apart. This allows the legend tool to be used quite effectively, as well as you can have a single door family that you can switch out any number of panels or frames in, making managing doors and windows more effective in a project environment.

    Comment


      #3
      Door-Parent Family (Door category):

      Sizes are all instance, Types are mainly used only for Interior or Exterior. Door swing is currently a type parameter, as is "uneven doors (yes or no)," although those are both mistakes. They are meant to be instance parameters and will update as soon as i get a chance.

      We have different Door-Parent families for each door action type, since i dont believe in Super Families. Single, Double, Double Egress, Commercial Sliders, etc. Although OH doors are still our Door-Single family, with a P60 panel.

      Door-Panel Family (nested, shared, door category):

      Has an individual panel modeled, all type related sizes (panel type) are Types, driven from project. All door size parameters are instance, driven by the Parent.


      Door-Frame Family (nested, shared, Door category)

      Has the frames built as native geometry, NOT as a continuous sweep. That way the head and jamb dimensions can be different.
      The Frame is wall hosted, and has the opening the cuts the wall. (In a perfect world i would move these to the parent and have this family unhosted, but reporting parameters wont work from child TO parent, so this is a deal breaker...).

      The Frame characteristics (called out as Frame Parameters) are type based, driven by the frame family type in the project. All door related parameters are instance, driven by Parent.

      ---

      Ive done an office where the Frame family IS the Parent family. it works okay, for the most part. Harder for people to edit, since the complexities are all so visible. But its doable.

      OOTB versions = barely functional, and the door schedule ends up like garbage.

      EDIT: Glazing is currently not modeled in our Doors, nor is hardware, but thats because our next round of door changes is going to incorporate nested shared Hardware and nested shared glazing.

      Gordon: Graphical control of Face based doesnt go to pot BECAUSE its nested, you just have to know that some things are quirky with face based families: The ANNOTATIONS refer to the NAME of the view in the project browser (if you want a symbol in plan, you place it in plan (even though thats the elevation). But if its object visibility, its based on what view you see it in FROM the family (Front/Back in family = Plan/RCP in project). Once you get your head around their stupid inconsistancy it works great.
      Aaron "selfish AND petulant" Maller |P A R A L L A X T E A M | Practice Technology Implementation
      @Web | @Twitter | @LinkedIn | @Email

      Comment


        #4
        Aaron,
        with regards to visibility, I think I stumbled upon something else. The crazy reorienting I am aware of, so my usual approach is to make objects visible from all directions in the nested part, then manage the visibility on the nested instance. The problem crops up if that nested family also happens to be shared.

        For example.
        Make a door knob as generic model face based. Set it to show in every direction. Make it shared.
        Nest it in a door leaf family.
        Nest the leaf twice in the final door family. Put the leafs at different angles. Make one leaf visible and Course & Medium LOD. Make the other visible at Fine LOD only.
        Place the door.
        The leafs work as expected at different LODs, but the hardware for both are shown no matter what. One set of hardware will be floating in space.

        Do the same, but the hardware isn't shared, and the hardware inherits the LOD controls set on the instances of the leaf. No doubt this could actually be "as intended", but I think it is also wrong.

        Gordon
        Pragmatic Praxis

        Comment


          #5
          Ive got them Shared, with LOD control done in the Nested hardware itself, and it works fine.

          I *have* noticed this: If you load the shared hardware in to the door, then go BACK to the shared hardware and make changes affecting the visibility controls.... You have to completely delete the family definition from the parent family, and load it back in, to get it to work right. Maybe thats what it is affecting your families?
          Aaron "selfish AND petulant" Maller |P A R A L L A X T E A M | Practice Technology Implementation
          @Web | @Twitter | @LinkedIn | @Email

          Comment


            #6
            Bet that's it! I forgot one of my least favorite rules of Revit. Once you have a family working, you better go rebuild it from scratch, or something will sneak up and bite you in the butt.

            Thanks!
            Gordon
            Pragmatic Praxis

            Comment


              #7
              Originally posted by Gordon Price View Post
              Over time I have seen two approaches to window and door frames.
              One is the OOTB approach, in which a ref plane jig is built, and the frame is modeled as a single extrusion. The result looks most appropriate for a Hollow Metal Frame, as there are no joints in the frame. Model Line joints can be added if needed to show a Storefront based system.
              The other approach is to use nested "Frame" pieces, which are just non hosted or 2 pick generic models converted to Window or Door families, with a simple extrusion on the Frame/Mullion subcategory. The result looks more correct for a storefront framed door or window/relite, as there are joints.
              I am curious what others are doing here? And what drove the decision to use that approach?

              Also, do most people model the frame in the "final" door or window? Or do you do a nested Frame Type? Part of me thinks going the nested & shared route could be useful, because then I can have a Door that actually contains a Door (Leaf) Type and a Frame Type, so the Revit content matches real world construction better. But then I want nested and shared Hardware Groups too, and I find that graphic control of a face based object goes to pot once that item is shared. For now Door and Frame types are just data from a Key Schedule, and only the user can ensure that everything is correct. Call it BiM.

              Gordon
              I'm going for nested components for doors and windows. Frame pieces, glazing, hardware, leafs, etc. All are nested. Just because I don't want to be rebuilding a window or door family for every type of frame. Besides that, it's more foolproof. I share my families with newbies and this way they can use the families and make all changes wanted without needing to tamper with the actual families that drive the window/door.
              Martijn de Riet
              Professional Revit Consultant | Revit API Developer
              MdR Advies
              Planta1 Revit Online Consulting

              Comment


                #8
                So, just to clarify... People are using nested Doors and nested Frames. But are those frames made up of nested frame segments? So a simple window frame contains four nested items, maybe all the same, maybe two Frame Jambs, a Frame Sill and a Frame Head, maybe something else?
                Or is the nested frame made up of a single extrusion? Or perhaps a sweep? But still primitive geometry, rather than a set of nested families?

                Thanks,
                Gordon
                Pragmatic Praxis

                Comment


                  #9
                  I nest all frame parts into a frame family which I nest into the host family. Same as hardware is nested into the panel family which is nested into the host family.
                  Martijn de Riet
                  Professional Revit Consultant | Revit API Developer
                  MdR Advies
                  Planta1 Revit Online Consulting

                  Comment


                    #10
                    I create the frame by single extrusions in the frame family, and nest that into the host family.
                    On a few occasions I´ve done a sweep, but in most cases I need at least the frame sill to be different from the jambs and head.
                    Klaus Munkholm
                    "Do. Or do not. There is no try."

                    Comment

                    Related Topics

                    Collapse

                    Working...
                    X