Topological Relationships between BIM Elements

Hey,
So I am having a play around with detachable properties, and I have this thing I want to do:

I have a series of level objects and I want to set a property for the level below and the level above each level. I can attach each level to each level above and below and set the property to nullable but when I deconstruct the object, I only get the above/below properties for the first iteration, and not the ones after (see below).

Is there a way to do this in Speckle?

2 Likes

Hey @compdesigner-nz1,

we don’t support “circular references” (i.e. Level A has an upperLevel that points to Level B, which has a lowerLevel pointing back to Level A) at the connector level, and Grasshopper wasn’t really designed for such tasks either (as it works on a per-node, per-item basis, with no context about the rest of the graph)

Basically, you are expanding each level to attach the above and bellow, but the levels you’re attaching haven’t been expanded yet, as grasshopper works on a “per item” basis, it will expand one item at a time without knowing about any other items you’ve plugged in. Hence the above and below levels “missing” those expanded props (expected behaviour)

Our object model does support circular references (the Brep class and subclasses are full of them) but they have to be modelled in a specific way so that they’re serialised accordingly (usually, using indexes/unique ids/names)

Whats the use-case for this? Having a flat list of levels that are sorted by height should already allow you to do operations relative to an individual level without having to add those to the object.

1 Like

@compdesigner-nz1 This would be useful to understand. I have had some luck with prepopulating consistent Detached properties with GH, but it requires planning.

2 Likes

Hey,
Thanks for the response. I see! The use case for this is to store the topological information for each element within each element so that it is aware of what other elements relate/are connected to it, regardless of data structure. The end result is to be able to query an element, and retrieve all other elements associated with it. I should be able to do this from an entirely flattened structure of elements.

Very similar to how Topologic behaves, but at an element level (beam, column, slab, floor, level etc), rather than at an abstract level (edge, face, vertex).

1 Like

https://topologic.app/ FYI

I think we should be able to construct circular topologies in GH even if we can’t deconstruct them - means that you could pushing topological data to another app that can handle it natively.

For the poster, It might be that you need to abstract it out one level from the speckle sender, defining a bunch of elements and thier topology and then submitting that to speckle as a “model.” Look at Sandbox Topology - Addon for Grasshopper | Grasshopper Docs for example, so you’d pull out a flat file of elements and all the topological connections between them.

1 Like

The same goes for elements of different types The below image details the definition of floors with the levels attached. I am then assigning the floors back to their respective levels and I get the same issue, where deconstruction misses the attached element properties. It probably falls under the same case, but I figured I would add this with slightly different use cases.

1 Like

You can, but you’d have to make your own script for it, and the limitations about circular dependencies are highlighted in that part of the docs:

In order to enable circular references on send/receive, these would need to be part of the Object Model design, not something you can dynamically add; as you’d need to provide a way to serialise the raw topological information when sending, and a way to reconstruct it on receive. This is usually done with a combination of computed properties that are ignored by the serialisation process.

In essence, it’s pretty similar to what Sandbox Topology does. The information that you want to save is not the object (i.e. the level above or below), but the index of that object in the flat list. Though it’s easier said than done…The BREP class was super tricky to implement.

Yep, this is the same case; and it’s the default way Grasshopper works. Each object is expanded without any knowledge of how many other items you’re trying to expand. It does this by design: There is no way for the node to know that the first item it’s expanding is related to the second, and vice-versa.

If you want to create your own circular references, that’s fine by us; but you’d need to do so with code (c# or python script), where you have total control over what happens and how everything is output. And they won’t work on send/receive (you could send the Send node on an infinite loop)

2 Likes

Thank you for the clear summary Alan!

2 Likes

Thanks for the advice and direction. I’ll have a look into it and see what I can come up with!

1 Like