Wall cleanup issue

Am trying to cleanup the intersections of my various interior partitions such that the intersection lines/ not in a plan view of these shapes will communicate appropriately the boundaries of the wall types at the various wall intersections.  I understand that the connect forms tool is the correct way to perform this task but it does not work as expected.  Am attaching an image file which describes what I am expecting to be able to do.  This is a very basic exercise that so far has taken way way longer than is reasonable to expect and I fear that it might not even be achievable in BA.  Or perhaps I'm using an outdated tool and should instead be relying on a different command for this task?  Any guidance would be appreciated.
Parents
  • I strongly reccommend that you DO NOT BOOLEAN walls together to make your 3d model look nice.
    If you have say a thicker wall to part of a wall leave it as a separate object.
    Live with the fact that you have 2 objects in your 3d model but know that this will "Join" together in your 2d output.

    At the end of the day BA will work 100 times faster for you if you dont join similar walls together. When you start booleaning walls together it will slow down your DEM's and Dynamic Views something horrible.

    When you model a 200 meter long building and try to do a plan Dynamic view it can mean it takes hours instead of minutes.

     

    my 2c
    Damon

  • Thanks for the responses thus far.  They have truly been helpful.  What I'm finding is that yes indeed during our early schem modeling while we're using the generic/simple walls in the dataset we do get the auto-cleanup of the wall intersections as Steve has described.  Once we progress to using more complex walls defined in the dataset as compund parts this ceases to be true however.  Using more complex walls (compund parts) The extractions produce the same result whether the "Perform Unification" option at the CutPlaneView tab within DEM (we're still working along in the latest version XM - at our client's request) is checked or unchecked at this stage.  The "Unify All" option works as expected but, of course, the objective is to join only adjecent like wall types so this is not ideal.  Please note the attached images for further clarification.

     

    If this is a bug that has been fixed at v8i that's a perfectly fine response BTW - not helpful, of course, for this proj work being done at v08.09.04.46 but acceptable nonetheless.

  • Brian, just to be sure...  do the parts used by those wall assemblies have unification turned on in the Cut Plane and Forward/Reflected View?   It sounds as though when you went from single walls to wall assemblies the behavior changed, but the parts are likely to change along with them.

     



  • Yes I did try checking and unchecking the box at the other tabs within DEM (Forward view & rcp view) and have not yet come up with a combination of checkboxes checked that produces the desired result.  Is there some setting within the compund parts themselves in the dataset which we need to address - I have not looked there yet for a lock/unlock key/setting.

     

    Our ideal workflow would be to allow the schem single walls to morph along; switching from simple parts/forms to various compund parts/walls.  Creating the indiv wall components (ie: gyp, brick, studs, etc..."parts" in Bentleyspeak) and the complex wall assemblies (ie: "compound parts" in Bentleyspeak) in the dataset seems pretty straightforward to us but so far our experience has been that once placed these compound walls/parts don't continue to understand themselves to be grouped together as assemblies at all.  This is a BIG productivity downer for us so I'm hoping you'll tell me that we're simply not "getting" something here.  Our users have reverted, instead, to a workflow in which each time a wall needs to evolve/morph it simply gets deleted and replaced with a new wall assembly.  I played a little with the build wall assembly command which seemed to be trying to accomplish this morphing along workflow but I didn't get that experimentation to a point where it worked satisfactorily.  It's more important in the bigger productivity picture of the project to create each partition type in the dataset anyway so we continue to "do over" our walls assemblies.

     

    Incidentally: for the walls to be able to morph along as we'd like it'd be best if we could just change them with a mouse click from being one compound wall previously defined in the dataset to another.  I'd think that for this to work properly, though, it would be necessary to have the actual 3D entities that are those schem walls to understand where they are to be joined to adjacent walls and where they are not.  Sometimes differences in the widths is sufficient to communicate the boundaries of the different adjacent wall types but not always.  Hence the reason initially for me to be trying to get my walls to clean up properly at the model itself

  • Brian, I was referring to the Drawing Symbology checkboxes in the Family/Part definitions accessed from Dataset Explorer.

     



  • Oh, OK, I understand what you're asking now.  The short answer would be NO.  If I navigate, from within DatasetExplorer to a "parts" family then Yes I do have multiple options at the PartsView pulldown one of which is Drawing Symbology.  And our parts do already have those symbologies defined and they do display the proper hatch patterns, etc. appropriately when sliced through in our extractions.  When I navigate to one of our "Compound Parts" families where our wall assemblies are defined the only option in the CompoundPartsView pulldown there is "definition".  If we were able to define an override pattern for these assemblies as a whole just as we can now with the individual parts I could see instances where that would be helpful as long as there was some flexibility built in to that tool w/ regards to the scale of the particular extraction underlay.  Am I missing a config variable setting or something somewhere which would enable this feature for compund parts families as well?
Reply
  • Oh, OK, I understand what you're asking now.  The short answer would be NO.  If I navigate, from within DatasetExplorer to a "parts" family then Yes I do have multiple options at the PartsView pulldown one of which is Drawing Symbology.  And our parts do already have those symbologies defined and they do display the proper hatch patterns, etc. appropriately when sliced through in our extractions.  When I navigate to one of our "Compound Parts" families where our wall assemblies are defined the only option in the CompoundPartsView pulldown there is "definition".  If we were able to define an override pattern for these assemblies as a whole just as we can now with the individual parts I could see instances where that would be helpful as long as there was some flexibility built in to that tool w/ regards to the scale of the particular extraction underlay.  Am I missing a config variable setting or something somewhere which would enable this feature for compund parts families as well?
Children
  • I haven't had a chance to return to this problem which is still unresolved but expect to get back to it later this wk.  Here's a thought I just had and would like a feedback response from the Bentley folks please.  If the "compound part" which is int wall A was created using 4" mtl stud "part" which is defined in "parts" family which is named per the Uniformat nomenclature for int walls but the "compund part" which is int wall B was created with an identical copy of that 4" mtl stud "part" but within a "parts" family which is named per the Uniformat nomenclature for ext walls.  Am I correct in assuming then that the 4" mtl studs in the two intersecting int walls will not clean up where they intersect since they are actually two different (although identical) parts (ie: from two different "parts" families)?

     

    Although I haven't tested this yet I'm guessing that it may not necessarily be intuitive to our users that one should only pick "parts" from the family with the corresponding Uniformat designation.  And since we're using the USACE XM workspaces right now and I haven't thoroughly investigated this yet I'm not sure yet whether this cataloguing of "parts" using the Uniformat system rather than MasterFormat2004 categories is relative to the USACE customization or the Bentley delivered libraries.  We like the Uniformat system very much when it comes to "compound parts" but I think this may be a good example of why we struggle with this system for cataloguing the basic building blocks (ie: CMU, gyp bd, mtl stud, etc.)  of those "compound parts" assemblies.

     

    Could this be the source of the wall cleanup issue described in this thread?