I have created a graph that checks all sheets in the project if the titleblock has a size that corresponds with a sheet instance parameter that gets filled out (so we can schedule sheet sizes).
As far as i know, you can’t schedule titleblock parameters when scheduling sheets so the users have to fill in “A0” in a sheet instance parameter if the titleblock is an A0 size. This results in errors when users change a titleblock but forget to change the instance parameter.
I made a script that corrects these errors but it takes very long for in my opinion a relatively simple procedure. The reason is that Revit starts to generate graphics for the sheets when I run the script, even though i don’t have anything to do with whatever is on the sheet.
Is there a way to read titleblock parameters, edit sheet parameters without ever generating the graphics for the sheets?
I tested it with tuneup (cool function, i did not know about that)
The Sheet.Titleblock is taking by far most of the time to load:
I don’t think doing it the other way around would speed things up as i still need to edit all the formsize parameters for all sheets, and that (i assume) requires Revit to generate the graphics on the sheet?
I’m Sorry, @jacob.small i should have tested it instead of asuming
I swapped out the Sheet.Titleblock node with the Element.Ownerview node to approach the other way around, it improved the speed drastically (i restarted the revit model and Dynamo before trying this)!:
Anyone smart who wants to explain to me why this approach is so much faster? The Element Ownerview doesnt even seem to need to generate graphics for the sheets while the sheet.titleblock node does generate graphics before continuing
I haven’t checked the GitHub for Rhythm, but I assume it’s using some degree of filtered element collection to identify the title block. If that’s true, then logically it makes sense if you break it down.
Instead of sheets let’s use jars, and blue marbles instead of title blocks. Each time you create an object on a sheet (view, annotation, etc.) you add content into the jar. So early on when you first make the jar (sheet) and all it has is the blue marble (title block), it’s pretty easy to find the blue marble in the jar as there isn’t anything else in it. But after adding a few views, and revisions, and view titles, and the rest… suddenly you have 100’s or 1000’s of other marbles mixed on top of the blue marble. So starting with the jar it’s pretty tough to get the blue marble as you have to move everything else out of the way.
But the cool thing with blue marbles (titleblocks) is that when we create them we write on them which jar (sheet, via the owner view) they are in. So by collecting all the blue marbles (titleblocks), you can just glance at the marble to read the jar (sheet). Revit can easily write this data as the jar (sheet) has to exist before the marble (title block) does, but that opposite is not true.
There are other ways to collect things besides filtered element collectors, such as parent and/or dependent elements, so all of my speculation could be for not. But for now it’s as good a theory as any.
I just now realised my PDF print script also uses the sheet.titleblock node on several occasions…
Going to add an enormous improvement to this graph, so thanks again!
