Placing elevations on sheet - one elevation behaves differently

I’m working on a tool that automates the creation and placement of views on a sheet based on selected rooms. Basically, from the selected rooms, it creates a plan, RCP, and four interior elevations, and an axon, crops them to slightly larger than the room bounding box or plan boundary, then places them in a specified layout on a newly created sheet.

Because of the way the pilot project’s Revit model is set up (slabs in linked core and shell model), the interior elevations initially span multiple floors vertically, but the script reshapes the crop region using the bounding box of the associated room. After the views are created, but before placing on the sheet, all annotations are turned off to nullify the effect of having grids, levels, and sections outside the crop boundary during placement on a sheet. A series of vectors and relationships are used to locate each view on the sheet relative to either the sheet origin point or a previously placed view. A ‘diagonal’ vector for each view is calculated by taking the view bounding box max and min, subtracting them, diving by 2, then dividing by the view scale to get the center point of the viewport relative to a corner placement reference point.

The issue that I’m having is with the placement of the final elevation on the final sheet. For whatever reason, all of the preceding elevations on other sheets are placed as expected, but the final elevation is placed as if it wasn’t cropped, and thus located much higher on the sheet than normal - see images below. In trying to debug by printing the values of different vectors at different points in time, it seems like the final elevation’s ‘diagonal’ vector always has a Y value significantly larger than all of the other views.

I’ve tried re-ordering the creation/placement of the cardinal directions, but it still happens to the last created elevation. If I change the looping of the view creation and placement on sheets, it can make it so that ALL sheets instead of the last sheet are similarly buggy, but with the current looping it only happens to the last sheet. (see comment a last ‘for’ loop This makes me think that somehow in the view creation / CropRegionShapeManager useage, when the loop is exited, something is not disposed or garbage collected correctly, and the crop region is only partially applied to the last elevation. (Being a self-taught Python programmer, I really have very little clue how garbage collection and element disposal are supposed to work…) I’ve tried manually disposing of different elements, but this doesn’t seem to have any effect.

Any ideas where this bug could be coming from?

Revit 2023
pyRevit 4.8.12
Code here for reference: Github Repo
(Please forgive incomplete commenting, commented out print statements etc - WIP code…)

If you clone the repo and test it out, make sure to rename the titleblock and view type variables.

1 Like

OK, so I didn’t find a fix to the actual bug, but I did find a way to mitigate it.

After placing all of the views on the sheets and committing the transaction, I start a new transaction and re-collect the new sheets and the viewports on those sheets. Then, I sort the viewports by name, and grab the elevations that are supposed to be placed orthogonally to the misplaced view, and the the XYZ center point of each using .GetBoxCenter(). Then I can use the X coord of the below view and the Y coord of the view to the right, and use them to move the misplaced view using .SetBoxCenter(). Then I just have to reset the .LabelOffset for each viewport to be consistent, since the initially misplaced view’s label is way off.

So, in the end, this fixes the effects of the bug, but I still can’t figure out what’s causing it in the first place.

Incidentally, I discovered after posting a demo video of this tool to the office intranet that the Ideate Apps View Creation tool (which we already own and have installed for everybody) does like 95% of what I was trying to do, with the benefits of a well developed interface and user configurable parameters etc.

The only thing I can find that it doesn’t do that mine does is use re-form the crop regions of the plans/rcps as offsets of the room boundary, and similarly crop the interior elevations to an offset of the room bounding box that intersects with the view plane.

So thats kind of discouraging. I think the critical decision now is, do the minor additional features of my script warrant additional development time relative to the time and effort saved by staff using the tools.

1 Like

And there are a few other script and addins on the market that do that.
Top of my head:

  1. Room datasheet in the pychilizer extension
  2. Rush forth tools project setup

Time cost benefit. Yeap, I am with you.
To me, very complex script rarely give you the value for your time spent unless you go all the way to the stage where it looks like a full blown addin.

Yeah, the frustrating thing is, I enjoy the development of the tools more than I actually need to use the tools myself - I’m making things to try to help other people because, honestly, doing normal architect stuff just wasn’t floating my boat. But not having a background in CS and being entirely self-taught and un-mentored in development / computational design, I feel like the only way I’ll learn to make useful tools is by making things that somebody else has probably already made better. Which is exactly the way that every other programmer learns things, but just frustrating and discouraging in the moment.


1 Like