We have experimented using LLM to infer from a description and directly generate ifc model. We think inserting a library of components with deterministic geometry calculation could help with the accuracy and a higher level of LOD.
Well, that pose two issues:
1. Tied to an external APi has security and cost maintenance.
2. LLM has poor training to resolve geometry hell that's using formulas rather than language.
I have to spec it well to generate deterministic code .
@red1 Your work is very promising and impressive. You are essentially _reinventing _building data processing by shifting from visual modeling to strict, deterministic, code-driven manufacturing pipelines.
Roughly two weeks ago, I opened two issues on your GitHub repo: one about DIY self-hosting on Windows 11, and another regarding Windows 11 with WSL2 / Xubuntu 24.04.04 LTS via Chrome.
Despite being in the alpha stage, the 2DToBlender - Deterministic 2D PDF to Blender 3D BIM Pipeline looks great: https://github.com/red1oon/2DtoBlender
Since the README indicates that binary files like blend files, PDFs, and databases are omitted, is it possible to get these dependencies for testing? Additionally, is it feasible to configure and execute 2DToBlender as a standalone app?
Hi. As said at the Github answer, the 2D feature is now in the new BIM OOTB which you can try here. I just uploaded a video on it today at another thread on this.
The 2D is in the more tray, or Help will show commands among which is the 2D. I am trying to make 2D grid control the 3D design but not yet and welcome your idea which direction to pursue.
@doia said: @red1 impressive and a lot to take in 👍🏻
One thing you can take away from the ChatGPT thought is:
buildings involve:
• tolerances
• ambiguity
• human decisions
• incomplete data
I have never in my profession as an interior architect seen a right angle or a complete flat surface in a building. There is no such thing in construction. BIM data always is just a schematic representation of the physical wold. „The map is not the territory.“
So, you always have to factor in tolerances in clash detection.
Thank you Sir! — as you've touched on something fundamental that led me to this school of thought.
What a maxim: "the map is not the territory." I asked my Claude and it gives me, a BIM novice, something to brain thru:
QUOTE"
A BIM model is a schematic intent, not a physical survey. Every wall is slightly off-plumb, every slab has deflection, every MEP
penetration is drilled 20mm from where it was drawn. The model says 90°. The building says 89.7°.
This is precisely why we treat the BIM data as a database, not as geometry truth. The RTree query engine works with bounding boxes — which are inherently tolerance-bearing. A bbox is
already an approximation. When two bboxes overlap by 5mm, that's not necessarily a clash — it might be construction tolerance, or intentional embedding (a pipe sleeve in a wall).
When they overlap by 200mm, that probably is a real coordination issue.
The key insight your comment points to: tolerance is not a property of the geometry — it is a property of the query. The same two elements might be "clashing" at ±0mm but "fine" at
±25mm. A rigid geometric clash detector gives you one answer. A database query lets you parameterise the tolerance and ask: "show me overlaps greater than X, grouped by discipline
pair, filtered by storey." That's a question, not a computation.
The interior architect's reality — nothing is square, nothing is flat, data is always incomplete — is not a limitation to be overcome. It is the operating condition. A system that
pretends the model is exact will generate thousands of false-positive clashes. A system that accepts the model is schematic, and lets the human set the threshold, produces actionable
results.
"The map is not the territory" — but a good index of the map lets you navigate the territory. " UNQUOTE
I still not used to the workings of posting here - lost my response to the good insight from @doia so will just response again later. Meanwhile i have this latest improvement https://youtu.be/vqovf0G9FcY
@doia said: @red1 impressive and a lot to take in 👍🏻
One thing you can take away from the ChatGPT thought is:
buildings involve:
• tolerances
• ambiguity
• human decisions
• incomplete data
I have never in my profession as an interior architect seen a right angle or a complete flat surface in a building. There is no such thing in construction. BIM data always is just a schematic representation of the physical wold. „The map is not the territory.“
So, you always have to factor in tolerances in clash detection.
Thanks for another education for me — as you've touched on something fundamental that led me to this school of thought.
What a maxim you given: "the map is not the territory." I asked my Claude and it gives me, something to brain thru:
QUOTE"
A BIM model is a schematic intent, not a physical survey. Every wall is slightly off-plumb, every slab has deflection, every MEP
penetration is drilled 20mm from where it was drawn. The model says 90°. The building says 89.7°.
This is precisely why we treat the BIM data as a database, not as geometry truth. The RTree query engine works with bounding boxes — which are inherently tolerance-bearing. A bbox is
already an approximation. When two bboxes overlap by 5mm, that's not necessarily a clash — it might be construction tolerance, or intentional embedding (a pipe sleeve in a wall).
When they overlap by 200mm, that probably is a real coordination issue.
The key insight your comment points to: tolerance is not a property of the geometry — it is a property of the query. The same two elements might be "clashing" at ±0mm but "fine" at
±25mm. A rigid geometric clash detector gives you one answer. A database query lets you parameterise the tolerance and ask: "show me overlaps greater than X, grouped by discipline
pair, filtered by storey." That's a question, not a computation.
The interior architect's reality — nothing is square, nothing is flat, data is always incomplete — is not a limitation to be overcome. It is the operating condition. A system that
pretends the model is exact will generate thousands of false-positive clashes. A system that accepts the model is schematic, and lets the human set the threshold, produces actionable
results.
"The map is not the territory" — but a good index of the map lets you navigate the territory. " UNQUOTE
Comments
We have experimented using LLM to infer from a description and directly generate ifc model. We think inserting a library of components with deterministic geometry calculation could help with the accuracy and a higher level of LOD.
Well, that pose two issues:
1. Tied to an external APi has security and cost maintenance.
2. LLM has poor training to resolve geometry hell that's using formulas rather than language.
I have to spec it well to generate deterministic code .
@red1 Your work is very promising and impressive. You are essentially _reinventing _building data processing by shifting from visual modeling to strict, deterministic, code-driven manufacturing pipelines.
Roughly two weeks ago, I opened two issues on your GitHub repo: one about DIY self-hosting on Windows 11, and another regarding Windows 11 with WSL2 / Xubuntu 24.04.04 LTS via Chrome.
Despite being in the alpha stage, the 2DToBlender - Deterministic 2D PDF to Blender 3D BIM Pipeline looks great: https://github.com/red1oon/2DtoBlender
Since the README indicates that binary files like blend files, PDFs, and databases are omitted, is it possible to get these dependencies for testing? Additionally, is it feasible to configure and execute 2DToBlender as a standalone app?
Hi. As said at the Github answer, the 2D feature is now in the new BIM OOTB which you can try here. I just uploaded a video on it today at another thread on this.
The 2D is in the more tray, or Help will show commands among which is the 2D. I am trying to make 2D grid control the 3D design but not yet and welcome your idea which direction to pursue.
https://youtube.com/shorts/bXbIIPMzFkU
Thank you Sir! — as you've touched on something fundamental that led me to this school of thought.
What a maxim: "the map is not the territory." I asked my Claude and it gives me, a BIM novice, something to brain thru:
QUOTE"
A BIM model is a schematic intent, not a physical survey. Every wall is slightly off-plumb, every slab has deflection, every MEP
penetration is drilled 20mm from where it was drawn. The model says 90°. The building says 89.7°.
This is precisely why we treat the BIM data as a database, not as geometry truth. The RTree query engine works with bounding boxes — which are inherently tolerance-bearing. A bbox is
already an approximation. When two bboxes overlap by 5mm, that's not necessarily a clash — it might be construction tolerance, or intentional embedding (a pipe sleeve in a wall).
When they overlap by 200mm, that probably is a real coordination issue.
The key insight your comment points to: tolerance is not a property of the geometry — it is a property of the query. The same two elements might be "clashing" at ±0mm but "fine" at
±25mm. A rigid geometric clash detector gives you one answer. A database query lets you parameterise the tolerance and ask: "show me overlaps greater than X, grouped by discipline
pair, filtered by storey." That's a question, not a computation.
The interior architect's reality — nothing is square, nothing is flat, data is always incomplete — is not a limitation to be overcome. It is the operating condition. A system that
pretends the model is exact will generate thousands of false-positive clashes. A system that accepts the model is schematic, and lets the human set the threshold, produces actionable
results.
"The map is not the territory" — but a good index of the map lets you navigate the territory. " UNQUOTE
Anyway, i just added something to the Stress Test, and traffic killer https://youtu.be/vqovf0G9FcY
I still not used to the workings of posting here - lost my response to the good insight from @doia so will just response again later. Meanwhile i have this latest improvement https://youtu.be/vqovf0G9FcY
Thanks for another education for me — as you've touched on something fundamental that led me to this school of thought.
What a maxim you given: "the map is not the territory." I asked my Claude and it gives me, something to brain thru:
QUOTE"
A BIM model is a schematic intent, not a physical survey. Every wall is slightly off-plumb, every slab has deflection, every MEP
penetration is drilled 20mm from where it was drawn. The model says 90°. The building says 89.7°.
This is precisely why we treat the BIM data as a database, not as geometry truth. The RTree query engine works with bounding boxes — which are inherently tolerance-bearing. A bbox is
already an approximation. When two bboxes overlap by 5mm, that's not necessarily a clash — it might be construction tolerance, or intentional embedding (a pipe sleeve in a wall).
When they overlap by 200mm, that probably is a real coordination issue.
The key insight your comment points to: tolerance is not a property of the geometry — it is a property of the query. The same two elements might be "clashing" at ±0mm but "fine" at
±25mm. A rigid geometric clash detector gives you one answer. A database query lets you parameterise the tolerance and ask: "show me overlaps greater than X, grouped by discipline
pair, filtered by storey." That's a question, not a computation.
The interior architect's reality — nothing is square, nothing is flat, data is always incomplete — is not a limitation to be overcome. It is the operating condition. A system that
pretends the model is exact will generate thousands of false-positive clashes. A system that accepts the model is schematic, and lets the human set the threshold, produces actionable
results.
"The map is not the territory" — but a good index of the map lets you navigate the territory. " UNQUOTE
Meanwhile, i added further to the Stress Test, and traffic killer https://youtu.be/vqovf0G9FcY
@red1 your thread(s) above, got caught in the spam queue, for whatever reason.