Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enhancement(revit): persisting applicationId from Revit receive and send #2873

Open
5 tasks done
dtnaughton opened this issue Aug 24, 2023 · 7 comments
Open
5 tasks done
Labels
enhancement New feature or request revit issues related to the revit connector.

Comments

@dtnaughton
Copy link
Contributor

Prerequisites

What package are you referring to?

speckle-sharp

Is your feature request related to a problem? Please describe.

We have a project workflow that involves sending lighting fixtures between two different Revit models, and requiring the ability to seamlessly update the objects bilaterally. Currently, when objects are sent from model A, they are assigned an applicationId based on the revit element unique Id.

When receiving into model B, some changes are made to the object with the desire to send these objects back to model A to update (e.g. family/type, location). On conversion of these updated objects to speckle objs (of type RevitInstance), a new unique Id (from Revit) is assigned. Therefore, there is no continuity of applicationId which prevents Update functionality on receiving back to model A.

Describe the solution you'd like

On receive, a check is done on previouslyReceivedObjects stored in the StreamState to enable update functionality. Has it been considered on the send operation to also check if there are any previously received objects with revit unique ids stored in createdIds on the ApplicationObject, and if so, maintain the applicationId from this object? This would aid the bilateral movement of objects.

I would be interested to hear if this would pose any wider issues for the create/update functionality or if there are any other reasons this wouldn't be a good idea!

Describe alternatives you've considered

Additional context

Related issues or community discussions

@dtnaughton dtnaughton added the enhancement New feature or request label Aug 24, 2023
@teocomi
Copy link
Member

teocomi commented Aug 25, 2023

Hey Dan, Speckle has not really been designed for this sort of round tripping (this is how we call this workflow internally). Every time you receive in a software, a whole new element is created, and we're not trying to preserve the association between them beyond an A=>B flow.
Going full circle is misleading; think of when a Revit wall is received in Rhino; sending it back to Revit will just cause problems if we try updating the original one...

Having said this, we know round tripping could unlock even further workflows, and have discussed at length how eventually it could be enabled (but maybe not encouraged) at a technical level. One promising solution would be to attach an originalAppId next to the applicationId property the first time we send an element, and that's never removed or altered. When receiving, the update logic could check on both the applicationId AND the new originalAppId fields...
We even have a fancy diagram:

image

@dtnaughton
Copy link
Contributor Author

Hey Matteo - thanks for the prompt response!

Good point r.e. object type mutating. I think in cases where the object type mutates, it's understandable that the situation becomes difficult because of the lack of similarity between objects. In cases where the object type is not mutated (e.g. a Revit -> Revit workflow, or a platform that wouldn't convert the object to another type), I think the implementation using an originalApplicationId property would make a lot of sense. Perhaps performing a check on changes to object type could also form part of this implementation.

Are internal discussions ongoing regarding this issue, or is it parked for now?

@teocomi
Copy link
Member

teocomi commented Aug 29, 2023

It's temporarily parked - but happy to revisit once we have a stronger need for this feature...

Perhaps performing a check on changes to object type could also form part of this implementation.

Good idea :)

@Jeroen-de-Bruijn
Copy link

Thanks Matteo, we have a project team that has a strong need for this feature. They are very interested to explore the round trip workflow for a large project. They have two Revit models (architectural and electrical) and want to exchange light fixtures between them. This issues was also brought up by the project team: #2438

Just to set clear expectations to the project team, any chance this feature will move forward in the near future? Or will it remain in parking lot for now?

@teocomi
Copy link
Member

teocomi commented Aug 30, 2023

Hey Jeroen, I've pinged you on discord, let's chat there!

@Jeroen-de-Bruijn
Copy link

Jeroen-de-Bruijn commented Sep 8, 2023

The project team and I drafted the specific workflow from a user point of view in more detail, which hopefully helps to provide context.

The workflow consists of 2 parts and is aimed at lighting fixtures in 2 Revit models. The architect defines the location and the electrical engineer specifies the technical parameters. Interesting to note that the family name and type name are the same in both models, but the family in the architectural model is a stripped down version from the electrical one so the architect can just focus on the location and don't worry about the other parameters.

  1. Revit architectural model > Revit electrical model
  2. Revit electrical model > Revit architectural model

Speckle round trip

@bimgeek bimgeek added the revit issues related to the revit connector. label Dec 13, 2023
@Jeroen-de-Bruijn
Copy link

What is the current view on looking into supporting round trip workflows?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request revit issues related to the revit connector.
Projects
None yet
Development

No branches or pull requests

4 participants