So I’m just trying to wrap my head around the different document types and not having much luck.
I need to undertake several tasks on background opened models, for this reason I am using Rhythms’ Applications.OpenDocumentFile node. This node returns a Revit.Application.Document object. This is the same object type that an OOTB Document.Current node outputs.
The issue I have is, when I try to use the output of this background opened document as an input to a lil Python code I have which is collecting all view templates from said Application.Document I get the following error:
If I feed in an archilab ‘Current Document’ which outputs a Autodeks.Revit.DB.Document, the same thing that is returned when calling the typical DocumentManager.Instance.CurrentDBDocument everything is gravy and my lil script works.
Clearly, there is something going on here with the document type I am trying to use off the back of the background opening, but I do not know what.
I tried the Dynamo Python Primer but if it is explained there, I couldn’t work it out.
John does nod to the difference in document type here but the post isn’t solved and my document object is not orchid so the context of the error is different.
Please help educate me on whats going on here and what I need to do to account for this.
The Dynamo Revit.Application.Document is the Dynamo conversion of a Revit API document.
The Autodesk.Revit.DB.Document is the Revit API object.
Use the Rhythm Documents.DynamoDocumentToDbDocument node to perform the required “conversion” between these two document types.
Ahhhh ok thanks for clarifying. That node does indeed solve the issue.
Curious why Unwrapping doesn’t convert the Dynamo version of the document into a API object though? Isnt that exactly the role of the Unwrapping function?
Because the dynamo team refuses to give us converters for that object type. I’m not sure the reason either but it’s frustrating as heck because giving us wrappers would also enable background documents to work better.
Here’s a cool discussion on this conversion process with the author of the orchid package. Essentially he took some ideas and made a bunch of sweet converters for us all to use. This resulted in greater compatibility between our Dynamo packages, which is awesome.
I recall discussing this with a Revit developer waaaaaaaay back in the day. There was some conerns about RAM consumption when opening documents via nodes and passing them around the graph as it was believed this would lead to significant performance issues based on insights from design automation. There were also worksharing and corruption concerns to boot. Their opinion was that Individually processing the documents (opening, performing the action, and saving) within a custom node or sequentially calling a graph in the context of opening an RVT, running a .DYN, saving and closing the RVt one at a time via an external add-in (like Bird Tools MultiPlayer does) relieves that issue. Such methods may be worth pursuing for the time being.
That said I can only remember one issue which was believed to be related to processing this way, and that could have been a fluke, so I think it’s certainly worth reviewing again when the team gets a chance, even if to document and communicate the concerns. I’ll raise internally to the Dynamo for Revit team.
I agree, using something like bird tools is a better route.
I don’t think the issue is worth raising with the team again, as last time they were pretty uninterested and I honestly don’t care to discuss it further. We worked around it and eventually you guys will break it. That’s how it is these days. Sorry, but it’s true.
Also RAM consumption is a pretty ridiculous answer. The problem more from my understanding is the way Dynamo is essentially hijacking the idling event of the current file. Making it difficult to work between files.
I agree, but the reasoning is sound. Ram requirement is 20x the file size when opening the file, sum those up for each file opened and all the various links… all in it means bulk of users were going to get have a resource shortage. By opening > acting > saving > closing (the bird tools route) the resulting performance issue is removed.
I do recall the idling event issues as well, perhaps the more significant one for the time being. Either way, I’ll raise it for the internal conversation.
Maybe my comment doesn’t follow the conversation, I opted to use link Document as it will be reloaded when opening the project revit file that has the links, discarded opening in background unless the task is done quickly or need to edit the file
