Sure, below is the RiR workflow I’m testing. It is for bulletins and addendums.
Grab a bunch of changed elements or elements in the area of change.
Found which views/sheets they are located in. (Key Step, takes longest time to compute, get stuck here)
Make bounding boxes. (maybe compute power costing, too)
Use the plan projection of the bounding boxes on the views/sheets they are located in to generate the boundary for cloud
Cloud everything.
I am not aiming to compare it with an outside source, that is a different way of thinking. It can be done with Bluebeam or other workflow involves computer vision.
Location change is one of the scenarios. We use how the item is shown in the documentation package(Sheet View) as a driver, because that is where the Liability is for architects.
Here is a list:
Item changed to a different one. (Easiest one, same location, just cloud it on sheets)
Item moved to a different location, the previous location is empty. (Has grey area, documentation team decide if the left emptiness needs to be clouded or not. Where the item is moved to needs to be clouded on sheets of its shown)
Item moved to a different location, the previous location has a new item. (Cloud both area on sheets the element is visible.)
Item is deleted. (Similar to 2 and 3 about the emptiness)
Are you only putting the revision on Enlarged plans or do you make bubble around all on the larger plans (bounding box) then go individual on the enlarged?
A simple text parameter would help narrow things down as well. Yes/No if the item had changed. The old location (now empty) might need a temp placeholder family if you were going to mark that too.
There is the possibility of swapping a view template/visibility override to really making the changed items stand out as well, to allow for quicker reviews.
To answer that question. It is different in every project actually, but the ultimate logic is we need to cloud all the changes in the documentation package. In lots of cases, we cloud to the exact location in all the sheets doesn’t matter if it is Enlarged Plans or Overall Plans. There are also cases that the drawing has so many changes and we cloud the entire view on the sheets to make it graphically less heavy.
The text parameter is workable with RiR’s “Replacement Mode” or changes don’t affect element ID. Theoretically, when new elements are introduced, the new ID is acting like the “If New Parameter”. Some time it can be tricky. For instance, when a really long wall is extended, the common way is to cloud the end of its extension, instead of the entire wall. In that scenario, the cloud location is based on adjacent elements, not necessarily the element that is changed. When that happens, it relies on the rule of thumb/human judgement.
It is a great suggestion to use view template/visibility, but need to test it in the project. My worries are:
View Template is a overall setting, it has to be made very clear in a large team that the “Temp View Property” needs to be used, otherwise there is a risk that the graphic setting of the whole model would be messed up. Team members would be swamped in hundreds of “View Templates” and didn’t know which one to use.
The method relies on filter, filter relies on parameters that attached to an element/object, without the place holder you mentioned, there is no way to show the deleted elements. It may make the model very heavy in a large project/team. They probably can be put in a workset, but it revokes the “Workset Paradox”: If a workset with a large amount of data is not loaded, you get better Revit performance, but no operation can happen with objects in that workset. If you want operation to objects in that unloaded workset, you have to load it, then data pour in, Revit becomes slow.
BIM data needs to be tamed. Some sustainable way to manage BIM data needs to be developed.
Hey Kike, I’m back. Sorry, not with good news. Please see the warning screen shot.
Previously, it doesn’t render the view or sheet out. In this version, I see it still goes through rendering the graphic, but seems not go through every sheet/view like you mentioned.
No problem, thank you for developing RiR in the first place! If this node can be achieved, it will save tons of time on tracking changes in Revit Architectural Documentation.
The “Element Visibility” is 5 times faster than previous method! (even though I pick a different element, I am in the same file with a similar amount of sheets, so the method you described above really worked)
