v8i Associated dims possible across dynamic views

We're paying close attention to threads from those of you blazing the v8i trail ahead of us...thanks.  We'll get our first test deployment of BAv8i deployed soon but in the meantime here's my question:  If one sets up their 2D plot sht files such that the model sides of them contains assoc dims and references the 3D model file containing the various dynamic views definitions instead of a DEM extraction...and this views definitions model file, in turn, references various "federated" 3D model files which contain the actual BIM graphic model data...can the dims in the 2D sht file remain associated across this file linking such that they will revise rather than break as the model is dynamically modified throughout the design process timeline?
Parents
  • NO my experience - with what yo described - does NOT work.  And I have not been able to develope a mehtod that does.

    Even If I idmension within the model I have problems making association be reliable

    Ustn since 1988
    SS4 - i7-3.45Ghz-16 Gb-250/1Tb/1Tb-Win8.1-64b

    Eric D. Milberger
    Architect + Master Planner + BIM

    Senior  Master Planner NASA - Marshall Space Flight Center

    The Milberger Architectural Group, llc

  • Thanks for the feedback.

     

    The graduation from the DEM extractions to dynamic view portals by itself elevates BA to the same BIM playing field as Autodesk's Revit (which our firm also uses) and is more than enough to encourage our firm to move from XM to v8i as quickly as possible...but it sure would've been nice if associative dims had already worked in this revised environment too.   We hope this is a primary focus area for the Bentley developers as soon as the pending bug fix cleanup release is issued.

  • I'm not sure about anyone else, but to be honest, I'm not completely following the workflow.... It may help if you could use what I'd call the "ABC" approach - file A contains this, file B contains that, and file C contains the other thing.  File A is referenced into file B, which is referenced into file C.  I'm placing my dimensions in file X.

    I'd leave out any other terms and just go with the basics.  Maybe we can figure out why this isn't working for you.



  • The project team I'm participating on right now is our firm's second BA XM (our client's FM group is not yet prepared to accept v8i deliverables) project and after fussing with DEM for a while (with the dims placed as an overlay in the model side of the plot sht dgn file along with other annotations pertaining to this plot sht) we're a little frustrated by the inefficiency of this production method.  One unfortunate aspect of this method is that you cannot associate the dims to the underlaying bldg graphics (residing in a separate extraction file) because, of course, as soon as you manully update your extraction to reflect the changes which have been occuring in the design model (split amongst several other separate dgn's) the associations are simply destroyed. [re: attache3d image file]

     

    So this leads me to the question noted in the subject line of this thread: if instead of this underlay being an extraction it were merely a portal (dynamic view) into the design model would one then be able to associate these dims (still residing in the model side of the plot sht file) to the bldg graphics now residing in the actual design model files as opposed to a snapshot copy (extraction) of it?

     

    Or will it be necessary at BAv8i to have the dims reside in the same dgn file as the bldg graphics to which they are associated in order for them to automatically revise themselves when that bldg graphic data was modified?

     

    The heart of the matter I'm trying to get to I suppose is whether the "federated" strategy is flexible enough to accomodate this level of integration across separate files.  We accept the notion that this federated files strategy might be a superior approach compared to the appearant Revit approach of all things that need to be associated in this way shall remain in the same rvt file but we don't know yet.  Eventually we'll have to tackle a very large project using one of these products so I'm trying to understand the pros, cons & limits of each of these competing products' somewhat different conceptual approaches.

  • x.dgn       I build a model

                     from this create Building View

    a.dgn       From this create a DrawingView  (Also called an Engineering view.  Ourtside file wiht the Building View Attached)

                      On this I place all annotations

    p.dgn - p10.dgn             Then I create a sheet or 10 with Borders

    Then I reference a.dgn onto each sheet p-p10  (One Overal Plan, and then 4 Quad Plans, Kitchen Locker, Toilet, etc)

    x.dgn is in the \Drawings directory
    a.dgn is in hte \Drawings\Sections and Plans   directory
    p.dgn is in the \Drawings\Sheets Directory

    Ustn since 1988
    SS4 - i7-3.45Ghz-16 Gb-250/1Tb/1Tb-Win8.1-64b

    Eric D. Milberger
    Architect + Master Planner + BIM

    Senior  Master Planner NASA - Marshall Space Flight Center

    The Milberger Architectural Group, llc

  • Mr. Cocchi:

     

    Please note the diagram appended to my post which describes our current XM workflow.  I think this should clarify my initial question.  If not please let me know and I will attempt to untangle the description further.

     

    Is your assessment of Mr. Milberger's reply that one cannot associate dimensions across dynamic views in v8i correct or incorrect?  And if those smart associations indeed cannot span across files in this way is this merely because of a minor bug which can be fixed in an upcoming release?

    Reply from another Bentley personnel would be welcome as well in case Mr. Cocchi may have become busy attending to other, more pressing issues.  Thank you.

  • Ah...  I missed that PDF the first time around, and yes, it does help clarify your workflow.  What you essentially have is geometry existing in file A, that is then referenced into the design model of file B, dimensions added there, and then that referenced into a sheet model also in file B (I don't think that last part is as relavant).  So whether the geometry being dimensioned is extracted, or the true 3D geometry from a DV, it's still one reference file away. 

    The behavior your describing is certainly possible when using an extraction, that has been done many times before.  Though if you are modifying the initial geometry *after* the dimensions are placed, you may want to turn On the Keypoints for Associative Dimensions option under the TriForma preferences...  That should help keep those associative dimensions associated, hence its name.  :) 

    When it comes to DVs, that could be a different story.  We don't have this type of historical data in support, and there's little experience in this area on our end.  In a quick test I just did, I could not seem to retain the dimension association as I could with an extraction file, which would line up with what Eric described.   Why?  I honestly do not know.  It's possible that I'm just missing something, but I'd have to do more investigation to be sure.



Reply
  • Ah...  I missed that PDF the first time around, and yes, it does help clarify your workflow.  What you essentially have is geometry existing in file A, that is then referenced into the design model of file B, dimensions added there, and then that referenced into a sheet model also in file B (I don't think that last part is as relavant).  So whether the geometry being dimensioned is extracted, or the true 3D geometry from a DV, it's still one reference file away. 

    The behavior your describing is certainly possible when using an extraction, that has been done many times before.  Though if you are modifying the initial geometry *after* the dimensions are placed, you may want to turn On the Keypoints for Associative Dimensions option under the TriForma preferences...  That should help keep those associative dimensions associated, hence its name.  :) 

    When it comes to DVs, that could be a different story.  We don't have this type of historical data in support, and there's little experience in this area on our end.  In a quick test I just did, I could not seem to retain the dimension association as I could with an extraction file, which would line up with what Eric described.   Why?  I honestly do not know.  It's possible that I'm just missing something, but I'd have to do more investigation to be sure.



Children
  • Your comment that our XM assoc dims should remain associated even after the extraction files are updated made me do a little test to confirm.  My simple test did indeed confirm that assoc dims will remain associated if graphics 2 files away from the dims are stretched; the dims will respond appropriately even after the extraction is regenerated.  We have some dims on our existing project which were previously created which do not though so I'll try to figure out what has happened in those situations that is different.  I've ruled out the different directories theory which sounds like it may be the culprit in the case of the v8i situation described.  I'll log a ST with tech support to compare notes and see if we can uncover this particular problem.  Thank you for your response.
  • after speaking with Brian it seems that when they had Recreate Model toggled on for some of the Extraction Definitions in the DEM, after recalculating, Elements from the Recreated Extractions were losing the Dimension Associations - apparently resolved :P
  • For the benefit of other users new to the Bentley software:  If you select the "Recreate Model" option (re: attached PDF) this will wreack havoc on your production team's workflow.  I still have absolutely no idea what bizarre workflow situation this switch is intended to be address in the first place.  And the help doc does not even refer to this toggle option at all.

     

    For the benefit of the Bentley developers:  Even though the clear intention is obviously to move users away from reliance on DEM at v8i toward the DynamicViews I understand the DEM tool probably won't be removed from the options for some time.  I'd suggest that for the upcoming release you should revise the DEM help doc to describe the purpose of "Recreate Model" and clearly warn that this option will break the links which associative annotations have to items in the resulting extractions.  Please consider this post a formal request for this specific help doc revision.

  • Huh...  I never noticed the main DEM help section only includes this - "Recreate Model - Click on the column heading to sort in ascending order. Click again to sort in descending order".   Which doesn't really state what it does...

    However, the DEM batch process section does inclde this:  "Deletes the output model and creates a new extraction."

    That doesn't cover every possible outcome, but it does state what the option will do.  I guess part of the problem is that it's not practical (or maybe even possible) to cover every scenario that could fall under this category - associated dimensions that reference the extraction model, annotations placed directly in the extraction model, manual changes to geometry in the extraction model, PW reference file integration (which relies on Model ID),  etc, etc.   The list could go on and on...

    But thanks for posting - hopefully more people will better understand this option now!