Set scale bar value - run time problem ('Generating graphics for Sheet:xxx...')

Hi,
I’ve been developing a script to automatically set our titleblock scale bar values that I was hoping to nest into our office PDF scripts. The script runs well at determining the scale based on a combination of the scales and sizes of the views on the selected sheets, using Rhythm’s Viewport.LocationData.

The problem is the excessive run-time. The script prompts Revit to run ‘Generating graphics for Sheet:…’ for each title block that is processed, adding heaps of time onto a process that is really quick when changing the scale value via ‘Select All’. Is this because the Viewport.LocationData is generating the viewport curves in the Revit views?

Can someone tell me what the cause of this is and if there is a way to avoid it?

Thanks.

Hey,

Interesting, I like your idea!

Could you sequence this node before all the rest of your nodes run? You might need an End Transaction node to force the 2 transactions…

Hope that is useful,

Mark

Thanks @Mark.Ackerley … it does really surprisingly well at setting the scale bar value accurately. The scale bar is often overlooked prior to PDFing drawings, with the default value often not being relevant to any view on the sheet. So I’m nearly there, but the run time is just no good.

Forgive me, where do you see the split in the transactions/sequences?

Thanks…

Hi again @Mark.Ackerley … Despite having used the Transaction.End node successfully in the past, I gotta admit that I don’t really understand how they work. This is my first attempt at using them as I think you suggested. I’ve also filtered any titleblocks that don’t need the value setting at the end of the script. Both with no change whatsoever (actually I think the Trasaction.End node placement made the run time l longer :upside_down_face:).

Hey,

Sorry for the confusion, I thought you were saying that this set of nodes is part of a bigger graph which also does printing?

Were you saying that this set of nodes runs again and again each time a sheet is printed when printing, which is the cause of the slowness?

My thought was that if you could force this this set of nodes to run as its 1 transaction, then the rest of the graph to run as a separate transaction, that would avoid the problem.

So… Most things we want to do in Revit are done in a Transaction… If place a family, Revit pauses its Idling process, Starts a Transaction, you click to place the Family, Revit Commits the Transaction and then the Idling process resumes.

If you place a family using Dynamo, Dynamo takes care of the Transaction calls to the API for you. It makes 1 Transaction for the Graph (if you are doing something that needs it).

But sometimes we want to force the graph to run as multiple Transactions… Say you want to place the family, then set its parameters. You need 1 Transaction to place it, then you need a 2nd one to set the value. Revit can’t set a parameter of an element until it has placed it.

So you would use an End Transaction node to make Dynamo create 2 Transactions for the Graph.

Hopefully that is broadly correct and makes sense :slight_smile:

Cheers,

Mark

Hi… thanks for your reply (again)

At the moment this is simply an attempt to set the scale bar on title blocks, that I was hoping ultimately to nest into our PDF graphs to avoid drawings going out with incorrect scale bar values… the problem being at the moment is that the run time on this graph alone is unacceptably long. When (if?) I can get the run time down, then I’ll drop this section into our office PDF graphs. Now I see why you proposed the Transaction.End node - yes this would be useful in the PDF graph… (apologies for the misdirection )…

This graph isn’t placing any families, only analysing the views on sheets, and calculating and setting the scale bar value - an instance parameter of the titleblock, which has a scale bar built into it.

I might be wrong, but the thing that I suspect is causing the ‘Generating graphics for Sheet:xxxx…’ is the Rhythm node Viewport.LocationData which creates the curves (needed for the calculation) based on the crop regions on each sheet. Perhaps someone could confirm this? Is there a way to avoid this?

Scott

  1. Try running the TuneUp view extension to confirm which node is taking the longest.

  2. Why do you need the viewports? The scale of a view is known as it’s a parameter. Working with a number is always easier than working with geometry.

Hi @JacobSmall … I am trying to set the title block scale bar by deducing the scale of the views which occupies the most space on each sheet. Where there are sheets with multiple views with different scales, this seems to be the most reliable (and seemingly quite accurate) way to do it. There may well be another (really obvious) way to do it (grateful for any suggestions).

I’ve just gone through the script freezing unfreezing sections until it prompted the ‘Generated graphics for Sheet:xxx’ response in Revit. This is the point at which it occurred (I closed and opened Dyanmo before and after each run as I was getting confusing results):

image

I’m not familiar with the TuneUp system, but will look into it.

In the case of this node, collecting all views (all elements of category) filtering out the ones you don’t want (schedules, 3D views, etc) by asking if they have a valid scale value, and then grouping by their sheet (a property of the view) will likely be faster.

Go to the well once for simple data when possible. :slight_smile:

1 Like

The great advantage of the Sheet.GetViewportsAndViews node is that it correctly sequences Viewport and Views. I found that there could be mis-sequencing between Views and Viewports if they were gathered separately.

I did filter out all sheets with no views placed (Drawing Issue Sheets, sheets with only schedules / raster images etc…)

@JacobSmall Thanks for pointing me to TuneUp. As suspected…

With 5 sheets (28 ViewPorts / Views) processed, it took nearly 3/4 of the runtime. It took me just under 1/4 the runtime for me to manually select the sheets in DataShapes :slightly_smiling_face:. On a larger selection this obviously gets unacceptably long.

Hey,

So the GitHub for rhythm’s node is here…

Obviously a zero touch node will run faster than a Python version, but perhaps you can optimise it such that you get a performance increase?

The node will be very versatile but you have a specific use case.

E.G. the node is looking for schedules, and then you are filtering them out in your graph, so that is inefficient…

I do worry that there is something fundamental about how the sheets are being interrogated that is slow.

I suspect that Jacob’s advise is the best… I would grab the view scale, the view bounding box extents, divide one by the other and use that instead… see what your results are like and make a call :slight_smile:

Hope that helps,

Mark

3 Likes

Hi Mark … thanks for your message… just as I was typing ‘I might have to give up on this’ :slightly_smiling_face:

I have been all around the houses now attempting to eliminate what I thought was the problem… I tried creating a dictionary to map Viewport to Views, then of course found the Rhythm Viewport.GetView node (excellent!).
TuneUp now seems to be pointing where my original suspicions lay, the creation of the viewport curves, and (I think) the prompting of the Generating graphics for Sheet:xxx response in Revit.

I’ll look into yours and Jacob’s suggestions next. Thanks again.

1 Like

@Mark.Ackerley @JacobSmall … I hadn’t worked with bounding boxes until now but this worked a treat. Processing time down to acceptable levels and flawless calculation of the sheet’s scale value.

Thanks so much for all your help with this :grinning:

3 Likes

All the things in the abstract section of the geometry library are worth learning. They are often overlooked but as the industry moves into more Generative Design uses they’ll be a must know for more of us.

Could make a good AU class… :thinking: