Move an entire model and its views #2

Once more I have made some functions which might interest others.

Since I released the nodes for moving objects and views, published in this post 1,5 years ago has many things have been improved. There are still some issues when moving elements where Revit “complains” about elements are being unjoined, however, after moving are the same elements being auto joined again!? Like some constraints will be unconstrained, and some groups need to be fixed.
However, it seems to be smaller issues compared to being able to control the model location at some tangible element or point rather than 0,0,0 is somewhere unknown!

The latest functions developed for this are moving elements in a workshared environment with or without designoptions.

Single model

Workshared model

PDF export nodes

With the arrival of Revit 2022 has it finally become an option to export view to PDF format. This new feature has also arrived in the Orchid nodes which now support exporting into pdf files.

Setting ViewTemplate

Do you use view templates to control views, I do. Especially do I use view templates for views there is put on sheets. Therefore does the latest build contain a series of nodes for view templates. Besides are nodes for views extended.

Move an entire model and its views

Have you ever witness the challenge of working with a model that is started by someone who didn’t know the importance of controlling the project origin!?

As a university and an estate owner do we inherit many models made in projects where the scenario is that someone forgot to control this at an early stage so the model could have been corrected. First when the project comes to the handover phase is it then discovered that this very critical error occurs.

Therefore, I took this challenge to code the bits and pieces to be able to move an entire model including moving elevations, sections, detailing, and 3D views, etc., also including adjustments for grids, crop boxes, views location on sheets. All in all, everything inside the project should be transformed by a given vector.

This work made me walk along many paths, developing a variety of nodes for grouping, views, viewports, and grids. More than 25 nodes have been created.

However, In the final scenario, I ended up only using a few of these nodes, while I continuously tried to figure smarter and smarter ways to tweak data. The nodes developed along the way is released also, while these could be used for other purposes and/or minor other tasks than moving the entire project.

move to origin (the final graph)

---
nodes for spatial element (room, space, and area)

nodes for view, viewport etc.


nodes for grouping etc.

nodes for grids etc.

Minor release 134.5.0 / 202.5.0 and major release 210.0.0

Revit 2020 (and Dynamo 2.1) has been released and therefore have I released my package for 2.1.x series. This has a huge impact on all version of the Orchid package since a large reshuffle of node locations has taken place.

Unfordenetly is the problems concerning migration not being solved with the Dynamo 2.1 release, however, it was not viable any longer to wait for a fix of the migration problem while it was slowing down my development.

This rather big issue will give users errors, and the only thing I can suggest is to address complains over this error towards the dynamo team at dynamobim.com forum and/or DynamoDS gitHub. I don’t find it suitable that I should correct this error, this must be an Autodesk issue.

BuiltInParameter, Transfer/Copy, central/linked files

In this update have I added several new features in different areas.

Nodes for BuiltInParameter

Nodes for copying and transferring elements between different document

Nodes for opening, save and closing central files

Nodes for linking files into documents

Graphs...

I have seen it over and over again. Users calling Dynamo "graphs" as "scripts". Sorry but this is not what it is!

What we do with Dynamo is much smarter, it is directed graph technology. It is a much higher order way to do (visual) programming, than simple scripts known from ex. Java scripts, or even the way Python scripts is widely used in Custom Nodes... or scripts in Code Blocks.

Naming it "scripts" is to patronize what we actually do.

https://en.wikipedia.org/wiki/Directed_acyclic_graph
https://en.wikipedia.org/wiki/Visual_programming_language
https://en.wikipedia.org/wiki/Graph_rewriting


Try also to open a dynamo 1.3 file in a text editor...

<Connectors>
  <Dynamo.Graph.Connectors.ConnectorModel ... />
</Connectors>

Or take a look at the Dynamo Primer...

...and from https://primer.dynamobim.org/13_Best-Practice/13-2_Graph-Strategies.html

Reduce Complexity
As you develop your Dynamo graph and test ideas, it can quickly grow in size and complexity. While it is important that you create a functioning program, it is equally important to do it as simply as possible. Not only will your graph run faster and more predictably, you along with other users will understand its logic later on. The following are several ways that will help you clarify the logic of your graph.

[...]

Maintain Readability
In addition to making your graph as simple and efficient as possible, strive for graphic clarity. Despite your best efforts to make your graph intuitive with logical groupings, relationships might not be readily apparent. A simple Note inside of a Group or renaming a slider can save you or another user from unnecessary confusion or panning across the graph. The following are several ways that will help you apply graphic consistency within and across your graphs.


It does matter to use a "language" thoroughly. Giving up language is giving up the core of whatever a culture stands for. Therefore, I don’t think it is a good idea to let "slang" become the language!

Please let us use the right notation... it is graphs, not scripts!