Hi, no luck unfortunately
@vanman, your template sheet input must be one single element(sheet) like this example below;
Try this way, if not i will take a look at your dyn file.
Cool thanks, list first item did the trick
Hey @jean !
Great package Quasar! A lot of useful things!!
I was giving a try to the ViewUtility.ElevationInRoom node and it seems to work pretty well, but it seems like all the views cut all the rooms short in height.
Do you know why this happens?
I tried to have a look at your repo to have a look at the code behind it but I can’t find the specific node.
Thanks for your reply @jean !
The offset would create an homogeneous offset around the original crop of the view, so in order to get the height of the view correct I would have to set an incongruous offset that would probably be too big.
I was looking at the code. Is the reason why all the views get cropped too low this line maybe:
BoundingBoxXYZ bcrop = Utility.crop_box(bbox, Offset / 304.8);
I really don’t understand where that number 304.8 comes from.
Thanks for the help,
@ATassera , that’s unit conversion millimeters to feets.
I see @jean
Thanks for clarifying.
So do you get shorter views too or is it just me?
@ATassera if you want shorter (than your room height) views you can provide minus offset value like " -200 " …
@jean sorry for the misunderstanding.
What I’m saying is that the room elevations are coming out shorter from your dynamo node (see the first image I posted above - the elevation has the correct width but a shorter height, hence the top of the room is cut out by the crop box). What I want is actually the view to have the same shape of the room with just an homogeneous offset around it. But, reading the code, it seems it doesn’t depend on that.
That’s why I was wondering if it was happening to you too that the
ViewUtility.ElevationInRoom node generates views that have the correct width but the wrong height (again, like in my image above).
@ATassera, Elevations views’ crops are shaped based on the room boundingbox’s max and min values.
On top of that, desire offset will be applied. Which means if you use offset value " 0 ", view crops will be the same shape (height and width) with the room. One of my concern is the unit conversion because, in my node, I have already divided by 304.8 assuming that the project unit is millimeter.
Anyway, I will check again, is this node really have an issue or not?
Thanks mate, have a great day.
Let me know what you find out and have a great day you too
Just noticed something with the view ViewPortAlignment. If there isn’t matching views and legends it can use the location of a legend for a view. Highlighted area below is where it put the view. Awesome node otherwise.
@vanman thanks for your info. Of course, that will be improved in the upcoming version, too.
Quasar View Extension on Dynamo Version 2
Quasar Package version 2.x.xxx offers a view extension to organize the scripts. Upcoming features are under development. For now, please do enjoy as so.
The CopyLevelAndGridFromLinkedDocument node works,but if the code is run more than once, it copies the levels and grids again.
Can it be updated so that it doesn’t copy anymore once there are already grids and levels?
hi @Revit_Noob, thanks for trying out. My answer is if you’ve already successfully copied why do still need to use this node again.
in reality i will not of course, but it may happen
just testing out the code
I’ll toss a good reason out there:
Let’s say the source file was updated as the design team made a change in floor to floor height to add another level.
If Dynamo maintains ownership of the Revit elements you can update the levels and elements / data built up on them by opening the graph which created them, and hitting run a second time.
See here for an example: Element Binding in Revit
@JacobSmall nice one, thanks for the info … Let try it out later.