We have our rhino.inside.revit workflow running well enough for daily production. However, the biggest problem we face is that the nuances of the Grasshopper setup is more or less incomprehensible to the designers. This means that all transactions between Revit and Rhino need to be managed by the people who developed the Grasshopper setup, which is a very inflexible way of working. Rather than train everyone in the office on how the Grasshopper is working (difficult because the scripts are constantly evolving) I am interested in the possibility of creating a front-end interface or GUI, either in Grasshopper (thinking of Andrew Heumann’s UI work) or in Rhino 8 itself.
I will go into a little detail about our workflow, for context, but I am not sure it is necessary for the question I am asking.
We are using a family-based Generic Models with custom subcategories workflow for the time being. This allows us to send geometry in bundles that maintain the layer organization of the Rhino file. If we have a layer called SITE_SiteWalls with 4 objects on it, our script creates 4 families (one for each object) and assigns a custom subcategory SITE_SiteWalls to all those families. This allows us to control Revit visibility/graphics for that entire subcategory, while maintaining individual Element Hide and Override Graphics for each separate Rhino object (now each a separate Revit family). We are still considering other ways of translating the data structure of our Rhino model, but regardless, the problems on the user’s end will remain the same.
When we add or delete new Rhino layers, or add or delete Rhino objects, the user should be able to single out those changes and send that through easily to Revit without running the entire Grasshopper setup. It seems this calls for a UI using search terms or dropdowns that would allow the user to pinpoint what to update/send through. I am reminded of the ease with which you can do this in Speckle. Currently we use GhPython components that take a search string as an input that filter a list if all layers, and output a filtered list of layers which feeds into the Revit family/subcategory creation. It’s clumsy for our users, and prone to misuse.
Essentially our user needs to be able to intuitively achieve a specific update to the Revit model.
Does anyone have experience with creating a UI or bypassing Grasshopper for the non-specialist user if a rhino.inside workflow? Or any thoughts on approaching the core problem I am describing?
There are a lot of considerations about the interaction with the Revit context (transactions) and any additional UI interactions.
What you are looking sounds just like what Keyan is developing, but uncertain how this would fit into the RiR environment. I have yet to test in the Rhino environment by itself, the demos look promising.
Currently RiR is balancing between 3 ui’s (Rhino,GH,Revit), which is accounted for, a additional custom UI that would potentially interact with each is going to add another layer of complexity, which is fine in Rhino & GH but Revit API transactions have these considerations.
Transaction Scope: Transactions in Revit are used to encapsulate a set of operations that should be treated as a single, atomic unit. Any changes made within a transaction are not committed to the Revit database until the transaction is committed (closed). This ensures data integrity and prevents partial or inconsistent updates.
Nesting Transactions: Revit supports nested transactions, which means that you can start a new transaction within an existing transaction. This can be useful when you need to group related operations together, but it’s important to ensure that nested transactions are properly closed in the reverse order they were opened.
Transaction Names: When starting a transaction, it’s recommended to provide a meaningful name that describes the operation being performed. This name is displayed in the user interface and can be helpful for debugging and understanding the history of changes made to the model.
Transaction Modality: Revit transactions can be modal or modeless. Modal transactions block user input until the transaction is complete, while modeless transactions allow user interaction during the transaction. Modeless transactions are typically used for long-running operations or when user interaction is required during the transaction.
Transaction Failure Handling: It’s important to handle transaction failures gracefully. In case of an exception or error during a transaction, the transaction should be rolled back (aborted) to ensure that the Revit database remains in a consistent state. This can be done using try-catch blocks or by checking the status of the transaction after it has been committed.
Performance Considerations: Transactions can have a significant impact on performance, especially when working with large models or performing extensive modifications. It’s generally recommended to group related operations into a single transaction to minimize overhead and improve efficiency.
Regeneration and Updates: Certain operations within a transaction may trigger regeneration or updates to the Revit model. This can be time-consuming, so it’s often advisable to minimize regeneration by deferring updates until after the transaction is committed.
Concurrent Access: Revit supports multi-user collaboration, but transactions should be used carefully in multi-user environments to avoid conflicts and ensure data integrity. It’s important to understand how transactions interact with other users’ changes and how to handle potential conflicts.
Automation and External Events: When working with Revit automation or external events (such as external database updates), it’s crucial to properly handle transactions to maintain data consistency and prevent conflicts with other operations or users.
Thank you very much for this comprehensive list. It will help guide our development. I think our use case involves discrete and straightforward transactions so we should be able to keep the guardrails up, but I will need to study it further.
In light of the complex interactions among environments/UIs that you point out, if you were in my shoes would your personal inclination be to avoid providing a UI for our designers ? Is there another approach to this problem? Or is there anything coming down the pipeline from McNeel that addresses deployment of R.i.R. in an office of non-specialists?