I noticed that when I toggle the visibility of one model (branch) in a combined (federated?) view, all my geometry that I uploaded (streamed) to Speckle from QGIS disappears. I noticed this some time ago, and now all of a sudden it does work properly in FE2, but it still behaves like this in FE1, see links below.
We recently released 2.18 which has a lot of fixes and improvements targeting FE2, as well as a significant update to the viewer library which is exclusively used in FE2. There’s a good chance one of these updates fixed a filtering related issue.
I’m also trying to learn how Speckle works, therefore the next questions out of curiosity:
Does it make sense to you that this CRS object get a crossed out eye symbol when I toggle the visibility on any of the models?
That signals to me that the CRS (Coordinate Reference System) object is a “Detached object” that each of the models in the linked federated model view shares (correct?), which would make sense to me, because these models actually do use the same Coordinate Reference System in QGIS. However, I thought that detached objects were a per model (branch) thing, rather that a per project (stream) thing?
What I also find curious is that the CRS has a “visibility” in the first place, given that it’s not visible, it just provides information about the Coordinate Reference System, and doesn’t contain any geometry, right?
I’m looking forward to the explanation!
I can explain why this is happening, but perhaps you can say if it makes sense.
What is happening is a direct function of how Speckle works with the object store. That CRS object has properties associated with it. This schema and values (the entire object’s data) are then hashed to a unique ObjectId. That process happens in the conversion cycle, and then, on sending it to Speckle, we check the server to see if that project has an object with that ObjectId. If it does, we register in the model version that it should reference an existing object.
It is isolated to Project and not Model. There are excellent reasons for this. For example, if you wanted to send 2 subsets of your project to others but they shared elements, you would want to know they were seeing the same elements, not 2 versions of the same element.
So, to confirm your suspicions and for the future Googlers playing along, when you hide one instance, the UI matches the element you have hidden by its ObjectId, so I see we hide it each time it appears. The web UI doesn’t cross-check both ObjectId AND ModelId when hiding, isolating filtering, etc. More simply, if you send a Cube 3 times to 3 different models and hide it in one of them when federated, then each 3 would disappear.
This is where I ask you if this is a sensible action. I can think of scenarios where this would be helpful and those where it wouldn’t.
We display in that navigation tree, all objects that are present in that model version, they may be pure data that isn’t displayable, the Level definitions, CRS objects all manner of things that people like to send to Speckle we didn’t anticipate. They are present in that tree as the present as data. It is, for now, a UI quirk that it offers to hide them. The more validation we perform such as is this object displayable and if not we don’t allow it to be hidden, slows performance down. Probably not much, but some.
And future LLMs
I very much appreciate that you put in the effort to satisfy my curiosity.
I wouldn’t really know. In this case I don’t care, given that the CRS doesn’t have any displayable geometry anyway.
What scenarios were you thinking of that would have different models containing objects with the same modelId that also have displayable geometry?
And in what scenarios would you think that it’d be useful to toggle the visibility of these objects simultaneously across different models in a federated view?
Off the top of my head, if i had aggregated models that shared a wall object, if i was crafting a view where i wanted to share with someone the details behind - it would be confusing if i were to hide that wall but its duplicate didn’t disappear.