I tried to import the following stream into the Revit demo project but got a decentralization error and wonder what went wrong? The file is originaly an IFC imported into Blender with BlenderBim with added custom properties and changed color.
https://speckle.xyz/streams/b54e8ff61d/commits/4ae4a5e413
Hi @MaxT
I can reproduce this issue with the commit you have linked.
The problem is caused by some of the objects in this commit contain a lot of heavily nested properties.
This one in particular has more than 64 levels of nesting which exceeds the limit of our current Newtonsoft based deserializer.
Please can you look at the link to the object I sent, Are these properties structured how you expect? particularly the BIMObjectProperties, It looks like maybe these properties are being duplicated many many times with each level of nesting.
I’m wondering if there’s something messing up, either with the IFC import in BlenderBIM, or in the way the Speckle connector pulls these properties.
If it’s possible for you to share the ifc/blend file, this would help me determine if this is a bug in our connector, or if our connector needs to handle certain IFC data better.
1 Like
Thanks for looking into this. The process was rather simple. I exported the following IFC from Revit https://github.com/maxtillberg/ICEBridge/blob/5a5dd34c677e965d5088e66d0edae4026735671b/RAC_basic_sample_project_spaces.ifc from the standard demo file, imported it into Blender 3.6/BlenderBim, selected the IfcSpaces to Speckle and tried to import them into Revit again. The latest version with no changes to the IFC or Blender can be found at Speckle
I’ve just pushed 2.17.0-alpha1 of the blender connector.
This contains a quick fix for you, where we are limiting the max depth of properties we grab in blender to the 64 limit that connectors requires.
I suspect there is a deeper bug here with the way we pull the properties, maybe some circular references are to blame. But at least with this fix you should able to receive the IFC file in our C# connectors.
Thanks a lot, you are the best.
1 Like
I should mention, you’ll need to re-send your commit from the new blender connector.
1 Like
Thanks Jedd! It is fair to say BlenderBIM compatibility is something that deserves a bit of a deep dive from us. The fact that you have anything is a lucky outcome due to @Jedd ’s dedicated work.
BlenderBIM is amazing but it’s true data is “NativeIFC” piggybacking on Blender data so this may be where we look to improve compatibility in the future without resorting to hacks.
2 Likes
BlenderBIM Thanks for the ping! Indeed something seems suspicious here.
In BBIM, each object will have a BIMObjectProperties associated with it, but that’s where it ends … there is no recursive nesting, and so if there is a duplication, it’s sounds like it’s to do with the Speckle end, but more than happy to jump on a screenshare with @Jedd to solve it. There definitely shouldn’t be 64 levels deep of properties.
But taking a step back, as @jonathon says BBIM does not actually store any data in Blender - the true data is in IFC and I’m almost certain within an afternoon of someone like @Jedd and I working together we can create a BBIM-variant that supports basic IFC data and will be a stepping stone to a BBIM-agnostic IFC-based Speckle connector. Win-win! So for example BIMObjectProperties is most likely blank a lot of the time and if it ever contains any data, it’s purely temporary for that Blender session and doesn’t hold anything meaningful.
If you’re up for a shared dev / debug session give me a ping 
4 Likes
Now I get excited
1 Like