I just wanted to understand with Revit how speckle decides to duplicate elements or update an element (do updates exist yet?)
I was looking around the platform and came across this thread, but I wasnt clear on where things are currently.
So I just took the sample house, sent the walls and pulled the walls back in, I got duplicates across most walls. Is this expected because I need to bring in doors, windows and the rest? So is it anticipated I could update my walls or should I be looking at writing those API’s myself?
Morning @adam, welcome to these parts! Revit is supremely annoying, and I suspect you got your error partly because of this issue.
Long story short, if you’re measuring something twice in Revit, you get two different numbers. This trips us off - objects get different hashes, and diffing becomes a nightmare. You gave us an easy way to reproduce this bug, so we’ll follow up on this! There might be some extra fine tuning we can do on our end on the update/diff logic in Revit too beyond the rounding numbers issue too.
Wall updates should be working, as it’s supported from the API!
Thanks dimitrie, haha Revit does it have its challenges
So right now the update/diff runs on hashes which is the entire object and it’s property and as you pointed out in the other posts due to Revit floating point storage it just changes each time and thats tripping the duplicates?
So the hashing occurs on the entire base object? Just playing with the API so if diff’s are determined that way I should also be careful with doubles too right?
I actually think the problem you are facing is this, hashes are used internally by Speckle to identify the uniqueness of objects but not when receiving updates in Revit.
Let me explain how updates currently work in Revit - then I’ll add this in the docs as it’s quite an important topic ;):
BuiltElements have a property called applicationId, this is different from the hash, and represents the id of such element in the host application in which it was first created. If the element was created in Revit it’s the UniqueId, if coming from Grasshopper/Rhino an analogous field
when a stream is received in Revit the applicationIds of all BuiltElements created are cached in the receiver
when receiving a second time from the same stream, if the received elements have the same applicationId of something that was previously received (and it still exists in the document), the connector will attempt to modify them instead of creating new ones. If the update fails (or is not permitted by the API), it’ll delete them and create new ones.
if an element being received doesn’t have an applicationId (eg it was created in python) no update mechanism will happen
In your specific case, as the issue above explains, since the elements weren’t previously received and cached, then the connector won’t update them.
But we’re planning to change this, so that the connector checks all the elements in the document (and not just cached ones) when something is received.
