I’m trying to find out how to place a view to the right location. I used rhythm’s Viewport.Create to drop the view to the 0,0 point of the sheet. I don’t really understand which point of the view (bordered on the image) is “linked” with the sheet’s origin… or what’s the general logic of this procedure?
(Our titleblock family has been modified without paying attention to its relation to the origin, so the 0,0 point of the sheet is marked with the circle with the cross inside)
Thanks for your help!
Sigh… this has come up a lot. It can be 2 things.
- Your annotations are causing the views to be different sizes than what you think.
Enable your annotation crop to make it the size you are expecting.
- Sheets absolutely have an origin and that is the origin the API uses to make viewports. . How your title block is placed could be very different.
Beyond that, upload a sample file for folks to be able to help more.
Thanks for the quick reply. I think the solution I found is different, but you helped me more that you’d think.
The original dyn is quite complex: it generates multiple views, tags, schedules, and tries to organize them on new sheets created “parallelly”. I started to reduce the dyn in order to upload it here. The simplified one did only the last step: placing a view already existing to the 0,0 point of an existing sheet. It worked as it should: it used the centrepoint of the view(port) as reference.
So the problem might be the uncontrolled behaviour of different processes in the original dyn. I’ve just put a Transaction.Start/End before the Viewport.Create node, and it seems it solved the mystery.
EDITED: Actually, it did not solve it in all test views. Anyway, am I on the right way?
@csaba.szabo, similar discussion in the following post I believe. I’ve not yet spent much more time digging in, but definitely interested to learn if it helps you or not.
Thanks. It was interesting reading.
I think we found the good solution. The key is the proper use of transaction nodes. Now all view(ports) landing as expected.
Rather than using transaction nodes, you could just use a ‘Passthrough’ from clockwork to minimise nodes used and computing requirements by pushing multiple transactions to Revit.