One of the key ways we use Speckle in our workflow is to bridge Revit and Rhino for visualization purposes. Our typical flow involves assigning placeholder materials in Revit, sending the model via Speckle to Rhino, and then refining those materials into Enscape-ready versions. This allows us to:
- Keep Revit models focused strictly on documentation and building logic.
- Empower our landscape design team—who work in Rhino but not Revit—to take full ownership of visualization for their discipline.
In Speckle v2, this process worked well because:
- Materials assigned in Revit could be overridden in Rhino without being wiped out during updates.
- We could send only changed elements from Revit, and Rhino would update just those, preserving existing context.
In v3, however, the emphasis on strict source fidelity causes friction:
- Material overrides in Rhino are lost on update.
- Partial sends from Revit result in deletion of prior elements in Rhino, breaking the modular, incremental update workflow.
We understand the value of maintaining fidelity between platforms, but for workflows like ours—where Rhino becomes the place for visualization logic and overrides—this becomes too rigid.
Unless Speckle can support something like an “override-preserving” mode or build Enscape-compatible materials directly from Revit data, the v3 connectors limit the flexibility we had with v2.
We’d love to see a way to preserve Rhino-level modifications during update cycles or have finer control over what gets overwritten on update.