I would like to move revision clouds and Delta’s out of the view and put the in the same spot in the sheet. I can select them but have no idea on how to deal with the scale of the cloud. Any ideas would be appreciated. Thank you
Hi @dbehner, welcome!
This is possible, however it has some complications - I have thought about this but not implemented it
[I don’t have Revit available at the moment]
As I remember Revision clouds cannot be copied from a view to a sheet so the method I thought would work something like this
- Get geometry, comments, associated rev, tag etc. of cloud in view
- Get location, scale and rotation of view on sheet and create translation for cloud
- Create new cloud on sheet, copy geometry with translation and add other parameter values
- Delete view cloud
This topic raises an interesting question for me.
Revision clouds on sheets or views, which is easier from a dynamo management perspective?
I have always thought in view was better, as this means with view movements on a sheet using scripts it is easier to manage.
Personality i run checks to see they are on sheets and report those as issues but would be interesting to hear what others think.
For management of documentation having clouds on sheets means only that sheet will schedule for issue per rev.
Tends to work better in practice than on views which can cause unwanted sheets to schedule and can be harder to capture comments per sheet for change registers
Our reason for sheets stems from sharing and schedules. We use drafting views primarily so we can transfer details to other projects. Schedules can only be clouded on a sheet. For us it only made sence to have a single location to do the work.
Thank you for laying out a framework. I will try to post a graph in chunks and tackle this one step at a time.
I always recommend tagging in views, as if it changes on the view the sheet should be scheduled as revised as well. I also liked that this meant I could print just the view for review (not the whole sheet) and show where the cloud was. This is also particularly useful for legends and details where even if it’s a standard detail that might get copied elsewhere you’d want to see the revision in the project you copy it to as well (to confirm it has the change that the library may or may not have).
That said I do understand the value and need for things to be one way or the other.
The hard part will be getting the transform matrix correct from the view to the viewport, and again from the viewport to the view. Certainly doable, but not an easy fix. I recommend testing with a single sheet that has with 4 plan views at four different scales, 4 RCPs at four scales, 4 elevations at a four scales, and 4 details at four scales (so 20). Then duplicate the sheet and set the duplicate views to using true north instead of project north… stick a cloud in each, and run the automation to copy all 40 clouds to the sheet, but don’t delete the old ones yet (so you can confirm alignment). Short of taking those into account, to run the risk of missing a key aspect and putting the clouds into the wrong position, leading someone to make some costly mistakes at the point of a project where revision clouds are issued.
1 Like
Just going to throw in here and say that in my experience one should NEVER cloud/tag said clouds in a view. The deliverable that is sent as revised is the SHEET, not the view. If that view moves to another sheet, it will take its revision with it and potentially downrev its previous sheet or uprev its new one. This does not work in most common data environments and their revisioning process’, as you may potentially reissue a sheet with the same rev as before even though it is meant to be the next rev.
Whilst its a nice idea for legends to hold their revision, im my xp it is still not safe to mix the two logics together.
My standard practice is:
- Add revision to sheet
- Cloud changes to that rev
This way if the clouds are removed, the rev stays. Once a cloud adds a rev to a sheet it becomes the means of it being on that sheet. If it were to be removed, that rev would drop off, likely unintentionally.
I have seen this cause major issues on jobs in the past, and it’s just a revit thing so clients/pms etc don’t want to hear a word of that side of the excuses/reasoning.
Rev views at your own peril.
1 Like
It has always been a question o have had in general. And with such mixed answers everywhere i ask. I mean i havent had the problems you are descibing Gavin BUT that doesnt mean i won’t
Certainly worth considering because your points are super valid, i just run things a bit differently to avoid such problems. Always willing to learn and change.
I wonder if anyone else had anything to add?
1 Like