January 19, 2011

ACA Section Tail Scaling

Here is a heads up to anyone who may be placing Section Marks with "tails" in Model Space from a Layout through a Viewport. The AecCallout command has an apparent defect in the way it creates the anonymous block for the tail. It works fine when placing the Section Mark from the "Model tab" (when "Model" or TILEMODE 1, rather than a "Layout" or TILEMODE 0 is current). It also works correctly when in a Layout and working through a Viewport when the scale of the Viewport is the same as the scale set for "Model".

But if the Viewport's scale is not the same as the "Model" scale, then the anonymous block that gets created is improperly sized. The correct annotation scale (matching that of the Viewport) is applied to the tail block, but the improper size of the block definition results in the final block displaying the same size as one placed through a Viewport that has the same scale as "Model".

To avoid this problem, you can do one of the following:
  • Place all callouts from the "Model tab" (TILEMODE 1), setting the desired drawing scale prior to placement.
  • Remember to switch to "Model"/TILEMODE 1 and set the drawing scale to match that of the Viewport and then switch back to the Layout.
  • Place the callout in the Viewport and then, after placement, change X-scale factor of the block to get it to be the right size [Viewport scale factor/Model scale factor]. The anonymous block created has uniform scaling, so the change to the X-scale factor will be applied to the Y- and Z-scale factors as well.
I imagine that I would generally be placing the callout in TILEMODE 1, but if not, I would most likely change the scale factor of the anonymous block, rather than hopping back and forth from "Model" to "Layout". As noted in this thread in the AutoCAD® Architecture Discussion Group, this problem has been observed in the 2009, 2010 and 2011 releases.

The block at the other end of the Section Mark, displaying the Section Number and, possibly, the Sheet Number, does not suffer from this defect.

January 10, 2011

Old AUGI Forums Restored

The pre-December 2010 AUGI Forums are back on line and ready to receive new posts, at http://forums.augi.com/. This is being described as a "beta", as there are still additional changes to be make to incorporate previous customizations into the more recent version of vBulletin that is now being used (where such customizations are deemed worthy of keeping, of course).

At this time, if you log into the main AUGI site and choose the Forums link, you will need to click on the http://forums.augi.com/ link to get to the new forums. The old ExpressionEngine forums are now read only, but can be viewed (separately) for reference. At some point in the future, those posts are to be merged into the vBulletin forums.

The archived AUGI Training Program (ATP) classes are also available again. You can navigate to the archived course material download pages from the Education link on the main AUGI site.

If you experience problems logging in to the site or accessing the old forums, try logging out of the site and deleting your AUGI cookies. When you then log in again, new cookies should be generated that will get you in to both sites.

January 05, 2011

Revisions and Dependent Views in Revit

I came across an issue related to my previous post on Revision Clouds and Dependent Views in Revit® Architecture. The floors on my project are shown in three sectors on three separate sheets at 1/4" = 1'-0", and I had a relatively small change to make within a single room in the middle or "B" sector that happened to be right next to the match line separating it from Sector "C" on my project. Due to the floor geometry, the match line is neither straight nor parallel to the dependent view cropping boundary, and at the revised area, a good deal of the room in which the change was made appears on the Sector "C" sheet as well.

I had made the change, clouded it and reissued the Sector "B" sheet without giving any thought to the Sector "C" sheet. Some time later, I opened the Sector "C" sheet and was checking to see if the revisions on it agreed with the plot in my half-size set and was surprised to find that an additional revision was listed. I quickly determined that the revision was for the change that I had documented in Sector "B" and that the reason it showed up was because the revision cloud, as I had drawn it, ended up being entirely within the annotation crop boundary for the dependent view shown on the Sector "C" sheet. That annotation crop boundary was a substantial distance beyond the model crop boundary, at what I believe was the initial default location.

Since the revision was generated by the revision cloud, there was no way to manually remove it from the list of revisions on the Sector "C" sheet. In order to remove the revision from the Sector "C" sheet, I edited the annotation crop boundary, dragging it as tight to the model crop boundary as possible, and then modified the revision cloud so that part of it extended beyond the annotation crop boundary. As noted in the previous post, once the revision cloud was not entirely within the Sector "C" annotation crop boundary, it no longer showed up in the Sector "C" dependent view and the revision no longer showed on the Sector "C" sheet, and I was good to go.

Modifying the annotation crop boundary caused a few annotation objects that had previously showed on the Sector "C" sheet to disappear, but these were all beyond the match line and still show on the Sector "B" sheet. I will need to remember to edit the annotation crop boundaries that are beyond a match line from the default location on future projects, and to keep in mind where those annotation crop boundaries are when placing future revision clouds in the vicinity of match lines.