All right. Thanks so much for being here and thanks so much for having me.
So this is not really a hardware topic per se yet,
unless buildings qualify as hardware too.
But let's talk a bit about them.
So we have exchanged buildings for a long time.
So these are just like sets of line drawings without really computer readable semantics associated to them.
I don't know, maybe there's a parallel to how the PCB community exchange models.
But I don't know, I would say for the last 10 years or so,
we're more and more exchanging buildings as rich, semantic data models,
where the models we exchange have also a meaning that computers can relate to.
And so in 2011 I started IFC OpenShell, which is a software library for dealing with these kind of models.
IFC is the open standard.
It's called the industry foundation classes, which is kind of a meaningless name.
But that's where the name comes from. IFC OpenShell is one of the geometrical forms you can use to exchange representations of your building elements.
IFC is also very much inspired by STEP, which is probably a standard familiar to most of you.
So if you're familiar with STEP, you know, OpenShell.
And in IFC we just prefixed everything with IFC.
And then right there is some point, you see that there is, well, I wouldn't call it a spike.
It's really like, I don't know, a mountain ridge of new contributors that came on board and that's with the Blender Boom add-on.
So in my work I'm mostly focused on analysis of these kind of models.
And then, yeah, Dion Mold came on board and he started actually writing an authoring tool on top of IFC OpenShell that allowed people to really graphically create models.
And, well, you can see the effect of that in terms of contributors.
So we have quite a bit of modules, but in essence we have a parsing library, geometry, geometry interpretation,
so that we use predominantly open cascade, hopefully familiar to some of the people in the room,
to read these kind of geometry definitions and translate them to BRAPs and then interact with them in a bunch of ways,
convert them to desolated formats or, yeah, some other things.
So I started my module mostly in C++.
The Python has been hovering around zero for quite some years.
And it basically had to do with the ecosystem, so open cascade is C++.
Because, yeah, it doesn't leave you much of a choice.
But quite soon on we realized that if you really want a wider movement, a richer ecosystem connecting different modules,
but also the BIM world is rather academic, so we have quite a bit of students,
or software developers doing rapid prototyping.
So it really made a lot of sense to have an interpreted language with a more accessible syntax.
Yeah, so also quite early on we started having Python bindings.
And then, yeah, you see the same spike here basically in terms of contributors.
That Blender BIM add-on is built on top of Blender, you might have guessed.
And Blender is also obviously a wonderful piece of software, very extensible.
And also, yeah, the client-side code is mostly in Python.
But it's not only that, it's also really a higher-level API that was being built on top of a low-level,
let's say instance manipulation we had.
So, yeah, I see it's really an extensive schema.
It's roughly a thousand to a two thousand classes or data types.
And if you really want to interact with that in a meaningful way, you need to operate on a bit of a higher level.
And that's also where the steep increase in Python code is coming from.
But what my topic for today is really the geometrical challenges that I encounter.
Because our industry is really multidisciplinary.
So, for example, what we exchange as building models are really detailed decompositions of the building into very specific elements.
So, one wall, one ceiling plate, and all the kind of supporting structure.
But if you look at the building code people, this is from the city of New York, for example,
they want to ask questions on much higher abstract levels such as the facade.
So, this is, well, it's New York.
So, they envision there is something like a base on top of which a tower is built.
And there are requirements about the proportion regarding base and tower.
But none of these things exist in bin models.
We don't even have a facade, we just have this bag of elements.
But we have other, let's say, different perspectives on geometry.
If you want to do thermal simulation.
If we are here in this room generating a lot of heat and that heat dissipates to neighboring spaces.
And then you're also not really interested in all the detailed elements that make up your building.
You just want to have basically a graph of spaces and thermal interfaces between them.
And there are ways to exchange this information as part of IFC building models.
But the generation of them is still rather buggy.
And that's also the challenge, of course.
Does every authoring tool need to implement this kind of generation of data?
Or are we going to opt for a more collaborative ecosystem of tools?
Where you just generate a building model and there is other tools to enrich those models.
And that is what I'm really hoping for, but it's not what we're currently seeing in the industry yet.
Geospatial people, they really want to focus on the things you can see.
They come from GIS, so they can only observe what is actually visible to them.
So they don't really want to deal with this kind of invisible surfaces.
They just want to have manifold representations of interior or exterior shells.
But so this is what we have as a building model.
And as a summary, what we want to generate, for example, is this representation of just a facade that joins across these walls.
And it could be thousands of wall elements.
The further you are in your development process of the building,
the more you're going to decompose these things into the actual physical things that are going to exist in reality.
But yeah, the data comes from heterogeneous sources.
I really want to advocate for an ecosystem because we already have an open standard.
Yeah, let's have a more collaborative ecosystem where we can augment this data.
Here, the interior, where you really want to know, for example, will I bump my head here?
But in normal models, these kind of representations don't exist.
You don't have this higher level representation of the interior.
You might have a description of the space, but it wouldn't be enriched with all the geometries that further eat out of that volume.
And of course, none of this is ultimately very precise.
So there is gaps either accumulated due to floating point rounding errors or manual sloppiness or also on purpose.
If you're building a building, you have to accommodate for the fact that the walls, especially this metal,
they are expanding and contracting depending on the temperature.
So there are also actual gaps between these elements in reality in more detailed models.
So maybe that representation that I just showed of the facade doesn't in reality really exist as a volume.
And then, so how to solve that?
Naively, you would maybe think, yeah, let's just Boolean union these things together and call it a day.
But yeah, that's quite a challenge in terms of performance.
But you also have to make a choice there.
Are you going to rely on these kind of fuzzy Boolean operations that allow for a certain imprecision or still join these disjoint volumes,
even if there is a nanometer or millimeter gap between them?
Or that's the open cascade paradigm, for example.
Or are you going to rely on these kind of exact Boolean operations that, for example, CGAL offers?
CGAL has a very interesting number type, I think, where a number is just not just a number.
It's basically a binary tree of all the operations that were used to construct a number.
And as such, it is really arbitrarily precise.
There is never any rounding occurring.
But it obviously has a monumental performance impact.
And it's also not maybe necessarily what you want, because you want to join across these kind of imprecision issues.
So earlier attempts, yeah, they made the performance problem even more extreme by using a Minkowski sum.
So you have kind of a padding volume that you apply to every element and enlarge it slightly,
and then union them together and then shrink.
But this is not really feasible on detailed models.
So what I try to do for this particular problem, and I hope this is going to end up in...
Yeah, I'm showing mostly experiments, but I hope that this will really at some point also be part of, let's say,
the core parts of my software library.
But what I'm doing here, for example, is decomposing these solid volumes into trees of half-spaces.
And then the neighboring half-spaces average these out.
So the two faces here, here and here, of these two disjoint walls, yeah, they are merged or aligned.
And the same here and the same here.
So this really allows for some sort of local adjustment, so that you're really sure that things snap into place.
And also, it really causes very neat models because there is almost no intermediate vertices
because all the nearly coplanar surfaces were exactly aligned.
But this is still a challenge to make this work on the really detailed models.
Another example where I used half-spaces is if, yeah, for example, the facility management people,
they also operate on a much higher level.
They don't care about every rentable unit.
They want to have aggregates of those.
How many square meters of rentable space do I have across these models?
And these interior partitions, you don't really care about them because tenants can remove them anyway.
So you include them in your square meter counts, which means that you basically need to take this volume
and extend it to this volume for them to touch and then union these together.
So for that, I used Sparkle, RDF Lib in Python.
I built, this is what you see here, is a graph of spaces, the half-spaces bounding the spaces.
These are touching the faces of the wall.
And in the wall, you have an opposite.
And so we really form a graph.
And then I query that graph based also on sabantics.
And of course, only the non-load-bearing walls that I can aggregate over.
And, yeah, as such, this is this kind of patchwork blanket,
is all the individual spaces that are in a model like this.
And then what the facility management people want to know is this.
So this is all inhabitable spaces, I think.
So without utilities are these kind of things.
But, yeah, there are large performance problems still with these kind of approaches.
These arbitrarily precise operations in Seagull, it's really immensely robust.
The first I really come from, let's say, I've 10 years of working experience with Obakas Cade.
So you come to lower your expectations a bit in terms of what works,
how many crashes did you encounter when you load complex models.
And then in Seagull, everything just works.
It's not always what you want, but that is then your own fault, typically.
But, yeah, still really computationally intensive.
So as a side project, I've also written my own foxalization library.
Because, yeah, especially these kind of challenges, superimposing a lot of elements into the same domain,
closing certain minimal gaps, yeah, that's really what foxalization is perfect for.
And, yeah, this, so maybe if you would want to union all these kind of building elements in, yeah,
in Obakas Cade, it just wouldn't work.
It's not robust enough in Seagull.
It will take a considerable amount of time.
And in foxalization, it's really just, yeah, I wouldn't call it instant.
You have to deal with a different set of challenges.
Suddenly, the complexity is no longer based on, let's say, vertex and face counts,
but it's really based on, yeah, actual, the physical dimensions of your building.
So if you're building a larger building, your computation takes longer.
But it's still, yeah, it does perform better than Seagull, I would say.
Yeah, and then you can do topological queries on those again.
So, yeah, this is a very famous testing model that we use in our industry,
but I expect it's a little bit cryptic for you to read.
But let's say this is exterior space, and here is a door, here is a door, here is a door, here is a door.
Here you see a little bit of a stairway.
So it's really three-dimensional, but I've kind of folded every 3D volume.
I flatten it over the Z-axis to kind of get a 3D volumetric,
a foxal grid of just, yeah, let's say, the mast that we can walk on.
Yeah, and then you can just do topological queries again on those
to see how long is the evacuation distance from a particular point in time.
And I'm not saying it's not possible on, let's say, regular polyhedra or B-Rab's,
people have been doing that.
Yeah, but I came to really appreciate how trivial those kind of operations are on foxal grids.
Same for the headroom, basically.
It's the same kind of idea where I start from the 3D volumetric space interior that we can breathe in.
I flatten that over the Z-axis to just the little surface where we can stand on.
But I remember how many foxals I flattened downwards,
and based on some sort of color coding or threshold, that's either sufficient or not.
So, yeah, you can see here under the stair that there is obviously a little bit less space to stand.
So for this, these kind of, yeah, when we started this project,
we envisioned that end users would be writing their own kind of analysis scripts.
So here you see visually all the operations that were involved in one of these,
in one of these, I don't remember which one,
but one of these computation graphs to union those foxals,
subtract a bunch of things through these traversals,
to really figure out the space where we can stand.
We also do some sort of padding so that we don't start walking in like two centimeter areas.
We kind of assume that we have a little bit of a body, so all the obstacles are dilated a bit.
Some of these things are also element-specific, so we do specific things with the railings.
I don't remember the details, but we really created our own little scripting library for these kind of things.
I don't remember why we just didn't create Python bindings.
That seems like it's easier than really creating your own language with your own interpreter,
but at that time that's what I did for some reason.
Obviously nobody has ever tried to create their own little analysis script to do these kind of things,
but as you can imagine it also requires some documentation and stuff that we also didn't provide,
but it was really fun to work on.
What I see as the advantages of this kind of foxalization, you can also associate numbers to yourselves.
What you see in the headroom analysis where you can stand and the evacuation analysis,
you can really associate a number with every cell.
It's also in a uniform way across every dimension.
That's also a bit harder on poly-heat writing.
Bullying operations are really just that, bullying operations.
If you superimpose two cells, a one and a one becomes a one, a one and a zero becomes a one.
That was really, if I can implement bullying operations, then it's trivial.
It's efficient to calculate distances also, and we close these gaps.
I think for our built environment sector it's really quite a good match for some analysis.
I've seen OpenShell going back to where it all started for me.
It's quite an extensive software library.
It has all the different revisions of the IFC schema.
It has these geometry mapping functions.
There's about, let's say, 200 classes in IFC that somehow affect geometry or representation.
They have an implication on our B-Wrap conversion to OpenFascade.
They have these conversion functions.
Then we rely on OpenFascade.
It's gotten quite a large code base.
In the new version, I have been playing, well, if it's been happening for various years now,
so I shouldn't call it playing anymore, but let's say working on the idea to support multiple geometry libraries.
The robustness of OpenFascade has really improved dramatically over the past 12 years.
It's really a usable, very powerful software library now.
But there are still cases, if there are issues being reported on my get up,
where I have to say, yeah, this takes me two months of investigation.
I'm sorry, I just cannot help you with this.
In that sense, I have some hope.
If I have a secondary geometry implementation in Seagal,
that I can really provide the best of both worlds,
also to people that want to do these kind of analysis that I just showed earlier,
like aligning these half spaces.
They have a better starting point with Seagal.
But for that, I created my own taxonomy in the middle of geometrical concepts,
so that this kind of implementation here is a little bit easier.
Yeah, so what I've learned in all of this,
so Seagal is predominantly only polyhedra.
They have some sort of curved things in some packages hidden somewhere,
mostly polyhedra.
The exact rational number type I've talked about,
they have an interval that wraps them for performance.
They have good documentation,
but I find their set of packages somewhat incoherent and chaotic.
You don't always know where you need to look,
and it's not always easy to go from one package to the other.
And I think the focus is rather academic.
A lot of the CAD concepts that maybe we rely on,
they don't necessarily offer out of the box.
And maybe you can read for yourself what I think about OpenCascade.
And that's it for me today.
Thank you so much.
Thank you.
Okay, do we have any questions?
Yes.
Do you see any use for the Seagal library to help with the OpenCascade geometry?
Yeah, great question.
So the question is, to what extent can maybe these libraries also help each other,
enrich each other, and not only exist as two choices at runtime,
but also how do we make sure that the library is not only available
and not only exists as two choices at runtime.
I haven't really explored that yet.
So far I'm only at the point of, yeah, you can try one, if it fails, try the other.
I think what I would at least want to do is kind of automate that process.
So that the software tries the first one, and if they're precious or produce bad results,
automatically try the second one.
As a next step, I would envision that I'm able to rewrite the results from one library to the other.
And yeah, by that time, you would maybe use, indeed,
a more intelligent combination of the two.
Like this Minkowski sum that I showed make an element a little bit larger
and also relies on convex decomposition that you decompose your element into convex parts.
Yeah, that is really quite powerful and something that I think only Seagal offers.
If you can bring that maybe to OpenCascade for some reason,
that's a very good use case in mind.
I think that would be quite powerful.
But so far no plans. It's quite slow process.
Thanks for the question.
Yeah, please.
I had a question regarding the open spaces that you have between walls for dilutation.
Exists there a class for defining the dilutation?
Because then the next thing would be that you interpret it in a different way.
Does it all put a flexible material in it for strength calculations?
Interesting question.
So the question is, I mentioned earlier that walls are not always connected to account for, yeah,
dilutation that elements can grow and shrink a bit.
And is there a specific class to encode that information in the models so that that can also be handled?
I would say yes and no.
If you would want to, I would say the standard is flexible enough to encode that information.
The standard is also very asparic.
There's a geometry description.
There is a taxonomy of types of elements.
And you can also refer to other classifications.
So if you want, you can encode that information.
And the problem with that is also that I've seen is used to exchange information from one person to the other.
And there's a lot of inherent knowledge that we all rely on.
So, yeah, if two walls don't exactly match, there is probably some textual description there that still says,
well, this needs to be sealed with that and that.
And that's obviously also much more efficient.
It's difficult to interpret for a computer.
Yeah, but people in our industry, I have to admit, don't really care about that.
I mean, it is a machine interpretable standard, but people still use it predominantly only for communication and coordination.
So you can, let's say, superimpose the geometries.
If there is a beam going through a wall where there is no hole, yeah, you have to call each other and solve that.
But actual computational analysis on these models is rather rare.
Thank you.
Thanks.
Yeah?
Two.
There is a microphone on this way.
Hello.
When we say about IFC, we should remember about the versions of IFC.
What is about the versioning with your libraries and all this stuff and how you are related to all these things?
I mean, the versions of the standard because it's also going on.
Yeah, and it's actually also one of the reasons why I had to create this mapping layer,
because I didn't discuss it, but we indeed, for example, here, IFC 2, X3, IFC 4, we have more or less the same concepts.
There are minor differences.
But I haven't really found a way, for example, to account for the fact that these two classes, the polyline and 2, X3 and the polyline and IFC 4,
that they are, let's say, 99% compatible.
So it also really dramatically increases the compiled size of my platform,
because everything is compiled multiple times with slight variations to account for the same, for the different schema versions.
And yeah, there are other software libraries that maybe more start from above, have a unified schema and then allow to serialize that as version 2, X3 or version 4.
But I have the more side-by-side as really computer-generated code from the schema.
So yeah, we have migration scripts to go from the one to the other, but they are written by hand and probably not complete.
Okay, one last question and then we're going to change over.
Let's change over.
Yeah, look at the render on what.
So your voxelization code, how did you set the voxel size?
Because I assume if you set them too small, you don't find the holes in the wall,
and if you set them too big, you close up corridors.
So do you have to do an optimization for the size of the voxel?
And what sort of size are we talking about for a building?
Yeah, great question.
And the main consideration was actually performance and also memory usage,
because yeah, it's really a cubic relationship.
If you have the size of your voxels, your memory usage increases eightfold.
So, but the good thing about the construction sector, as opposed to let's say general purpose CAD,
is well, it all relates to us human bodies.
So we're pretty sure about, let's say, the size of the geometries we're going to expect.
And yeah, for that kind of reason, I also didn't create an optimization step to find the optimal voxel size,
mostly just five centimeters.
Okay, so thank you very much.
We're going and that was excellent.
Thank you.