Announcement

Collapse
No announcement yet.

Face based sink family vs model groups

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

    Face based sink family vs model groups

    I have made a face based sink family that cuts a hole in a countertop. It works great - until I try to put it in a model group. If I put the counter and the sink in a model group and copy it, everything is fine. But, if I pick the model group and "create similar" or choose the model group in the browser and "create instance" or try to substitute one model group with another, I get a message that says "Changes to groups are allowed only in group edit mode. Use the Edit Group command to change to all instances of a group type. You may use the "Ungroup" option to proceed with this change by ungrouping the changed group instances." with an option to Ungroup. There is a nested error message that says "Can't cut instance(s) of SinkHole out of its host.".
    What is really odd is that if I choose the Ungroup option, I can then "create similar" or "create instance" or substitute groups just fine. I have played around with family categories (casework vs generic), nested face based voids to no effect.
    Can someone tell me what I am doing wrong or is this working as expected? I have included an example project with the counter and sink hole families loaded.
    Attached Files

    #2
    Face Based with cutting will always have some issues, if they are in Model Groups, or nested families. I use a non-hosted with Voids in them, and cut geometry. Works perfectly in model groups. Still wont cut if its in a nested family, but i dont put mine in nested 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


      #3
      Thanks, Aaron. So I guess this is expected behavior. I suppose I will now remake all my face based sink families. :banghead:
      There is certainly something to be said for tribal knowledge on the Forum versus Autodesk help resources.

      Comment


        #4
        Originally posted by jsnyder View Post
        There is certainly something to be said for tribal knowledge on the Forum versus Autodesk help resources.
        It is odd. It's almost like they don't want to admit some of this. I get it but they're not doing anyone any favors.
        Greg McDowell Jr
        about.me/GMcDowellJr

        Comment


          #5
          Originally posted by GMcDowellJr View Post
          It is odd. It's almost like they don't want to admit some of this. I get it but they're not doing anyone any favors.
          While I freely admit the idea of being able to schedule groups in 2018 is potentially a large improvement (I reserve judgement until I know what the limitations are - I assume I will learn about them here, not from Autodesk), I think this whole group workflow needs more attention from them.
          Having to do the same stuff over again because of undocumented limitations in the software is ridiculous.

          Comment


            #6
            Originally posted by jsnyder View Post
            Thanks, Aaron. So I guess this is expected behavior. I suppose I will now remake all my face based sink families. :banghead:
            There is certainly something to be said for tribal knowledge on the Forum versus Autodesk help resources.
            Well, i wouldnt say its EXPECTED behavior, but thats what it does. I dont mind having unhosted instead of FB, but i mind that neither works correctly in different circumstances. I find it inexcusable that an Unhosted with a void can be put in a family, and will cut in the family. Then you load it in, and its not cutting anymore. Its insane.

            But yes, you pick which way you want it to work, because FB can work sometimes in Nested families, but not well in groups. UH can work in groups, but not in nested 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


              #7
              FWIW, here is the relevant part of the response I received from Autodesk on this issue:

              Unfortunately I was not able to reproduce this Model Group behavior in Revit 2018. Create Similar in version 2018 works with your group properly. I checked this also in Revit 2017.2 and there this noticeably issue.

              I will try to find workaround for You and at the same time I will register this issue for correction, Development Team will try to make an initial assessment. Once I have any update from the development team I will keep you posted.


              Since it would appear that this issue may be resolved in 2018, I am not sure I would call it "unfortunate", but that is semantics. A glimmer of hope perhaps for our grouping future...
              Last edited by jsnyder; May 15, 2017, 06:21 PM. Reason: Added italics to "may"

              Comment


                #8
                Woah. If they resolved it in 2018 i might have to reconsider the changes i made to my libraries, LOL... *MAYBE*
                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


                  #9
                  I have tested these issues in 2018.2, and it is not looking like its fixed. When I swap one group for another with face-based cutting families (sinks) in the group, I am getting a different error message to v2017 - now it does not mention anything about groups - instead it just says 'Instance origin does not lie on host face. Instance will lose association to face' it then has a hidden nested warning saying 'Elements were deleted'. The non-hosted sinks seem to behave ok in groups, as Aaron says. I guess the face-based ones want to remain hosted to the countertop in the original group, not in the copy of the group.

                  The problem I have is that I don't want to be assembling the kitchen components in the project as a group - I want them as a kitchen family that I can load into a project (or multiple projects), and not have to use groups. I certainly don't want kitchen groups nested in apartment groups.
                  As Aaron pointed out (albeit the other way around), when in the family environment, non-hosted sinks will not cut the countertops at all,; while face-based sinks appear to cut the countertops in the family, until you load it into the project - then they un-cut. That means neither option works in the family environment.
                  Revitcat
                  revitcat.blogspot.com

                  Comment


                    #10
                    I absolutely do kitchen groups inside of unit groups... And i love it.
                    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

                    Working...
                    X