Hi.
I am just wondering if we can control the amount the 2D grid Extends out from the scopebox controlling that view.
Ok so basically based on the image Below, Notice how the Grid Bubble goes beyond the Scope box and create the Grid bubble. Now what I want is to control the amount this grid bubble extends. Ideally I would want it to remain somewhere inbetween the Matchline (Dark Line) and the scope Box.
I know there have been Pythonscript through which it has been managed to control the 2D extents of the Grids but I donât want to go through 400 sheets one by one and do the extents of the grids and rather have a magic number figured out and apply it for all the sheets. Hope it makes Sense and I really hope someone can help me out in figuring how do we get around this problem.
Hi Jeff,
I did read the forum post you mentioned but the issue is the Propagate Extents works for parallel Views and even if it works (Alas it doesnât work properly) Ihave some 25 Tiles which means a lot of Manual work.
Have a look at this video
If what they do in the video is possible I am guessing it might be quite possible to change the 2D extents of the Grid based on the nearest matchline or just maybe move the grid bubble by a certain distance parallel to itself in all views selected.
To be able to figure out the âmagicâ value which is sheet-specific or more appropriate viewport-specific, I think we can learn from that plug-in.
I guess it takes a reference plane and finds the intersection between grids and the plane then shrink grids to the individual intersection. But it requires appropriate ref planes locate right at the places where red arrows are pointing at.
how to construct these ref planes at the right place? I guess it wonât be necessary to construct one for every single viewport/view.
I will give it try by scaling down the bounding box to 0.95, see if it intersects with the grids. Then shrink the grids if possible. (Not setting the new boundingbox to the view)
Notice that I am using the shrunk boundingbox (a new box) to intersect with grids to generate a series of new ends, not actually apply the new box to the view.
I was wondering why Grid class has just a SetVerticalExtent() without a SetHorizontalExtent().
But the method I need reside in its base class which has a SetCurveInView(). Since the method requires curves, I was thinking about generating new curves for grids using dynamo lines and turn them to Revit lines but it throw an âNot Coincident with Original Grid Lineâ exception when applied them to SetCurveInView(). After excluding reasons stated in exception message, I think it could be precision issue. So I just use dynamo to calculate the difference between the orginal curves and new curves.
Getting the original curves from GetCurvesInView(), shrinking it with the difference.
About SetCurveInView(), DatumExtentType.ViewSpecific is another key to this case since I think as long as it is ViewSpecific, change happend in the current view wonât affect other views. It makes sure that grids on other views still âremain unsolvedâ instead of having a new length due to the changes in current view. So the â0.9â theory still holds true for the rest of views.
The .dyn just operate on a single view, the next step is to propagate it to all views / viewports on sheets. Have not tested it though, I hope nothing goes wrong when it comes to batch process.
Hi Jeff, Firstly thank you so much for spending the time and the effort into this.
Ok so first Jeff I havenât moved to Revit 2019 so I couldnât open your sample file so I created another file on version 2018 (Attached Below)
So for me I have 2 issues currently.
When I have Grids that are in different directions, that is horizontal and vertical. the script fails so I think we need to group the Grids based on their angle of plane before doing the intersection. It gives me an error like below.
When I run it with only having grids on one plane it acts strangely as well. Instead of being shorter they tend to extend. Not sure why its happening though. images below
The Grids do work in only the current view and they donât affect other views so that part works perfectly.
Have a look at the file below. ShrinkGrid_2018.rvt (364 KB)
I just tested it on a single floor plan view, not looped through every view. And I just tested it on one direction. you can continue developing it.
Essentially, I used dynamo to calculate a difference then let the start point and end point plus or subtract that difference (Y coordiante). Plus or subtract depends on how you drew the grids. So in this case, you can open the Python Node, switch " + delta" and â- deltaâ, then it should be shrunk instead of being extended.
For the other direction, the difference should impact on X coordinate of start and end.
I found an irritating issue, I thought the outmost boundary is the cropbox of the view whereas it just the top surface of the cropbox. the real stand-alone surface is from the boundingbox of the âUnknown Elementâ. I created another topic for this problem. you might want to track that as well.
Iâm curious about why you need to shrink the grid into the box? The box wonât be visible when you print the sheet. Is it because the grids from different viewports on the same sheet overlap with each other so you have to shrink them in, making them more controllable?
Hi Jeff, I was having issues with intersection and getting the exact cropbox aswell. Also the intersection when eventually done for some 700 sheets is going to be very task intensive so I was thinking of other ways to deal with the same issue.
What I was thinking is as follows:
Since from Revit 2016, the Grid class provides the methods GetCurvesInView and `SetCurveInView.
Use GetCurvesInView to get the start point and end points of the Grids in the view. Also get the default 3D start point and end point of the same Grids. If the X,Y of the points coincide we filter out those grids cause they are not being trimmed in view. For all other grids we reduce the the points by a certain distance (Magic No.) using the extend and trim curve by distance option. In theory I think it works.
I am right now trying understand how to use the âgetcurvesinviewâ command for the grids correctly.
I am getting most of the information from the sdk 2018 here (http://thebuildingcoder.typepad.com/blog/2017/05/sdk-update-rvtsamples-and-modifying-grid-end-point.html#4)
I think the outmost frame we need is from view.CropBox, specifically, from the top surface of the CropBox. I tested it on Level 1 and Level 2 which are both floor plan views. Notice that even itâs Level2.CropBox, its MaxPoint still has a zero Z value after converting the box to Dynamo Geometry. (Also notice they both have 10 meters depth, MinPoint.Z = -10000, I thought itâs a view range thing, but it doesnât change with view range )
import clr
# ProtoGeometry (Dynamo)
clr.AddReference('ProtoGeometry')
from Autodesk.DesignScript.Geometry import *
# API
clr.AddReference("RevitAPI")
import Autodesk
from Autodesk.Revit.DB import *
# RevtiServices
clr.AddReference("RevitServices")
import RevitServices
from RevitServices.Persistence import DocumentManager
from RevitServices.Transactions import TransactionManager
# RevitNodes, ToDSType method, Geometry conversion
clr.AddReference("RevitNodes")
import Revit
clr.ImportExtensions(Revit.Elements)
clr.ImportExtensions(Revit.GeometryConversion)
# Unwrap views to make it work with Revit API
view_Level1 = UnwrapElement(IN[0])
view_Level2 = UnwrapElement(IN[1])
# View.CropBox returns a boundingboxXYZ, converting them to Dynamo Geometry, ToProtoType() Method
OUT = view_Level1.CropBox.ToProtoType(), view_Level2.CropBox.ToProtoType()
I thought it should be simpler because I used Select Model Element to pick that âUnknownâ element as the outmost frame. Its BoundingBox worked well but I still donât know how to collect all of them.
)
