I guess it is possible to handle the modelling process through archipack instead so windows / doors will remains editable and allow any shape. Maybe import + processing urb output directly in blender.
From my attempt to convert urb into pure python, there are many perl libs involved and we must find good python alternatives for some like pygraph. At this point have pure python urb
I think Archipack VS Topologic would be great. Could Archipack be revamped to create models based in cells instead of walls with Topologic's framework in mind?
It would be great if, at some point, layered walls would be created based on relation between cells or between cells and exterior spaces. In the end we could use this to define sets of rules to have thermal, fire and sound insulation or walls based on room finishes. After that we would use Archipack toolset to refine all other architectural elements. If this could be matched with IFC classification on BlenderBIM I think we could have a very efficient BIM modelling workflow principle to explore in Blender.
The idea for me is to find the best workflow between conceptual stage and production stage. Most examples I see for Archipack are based on an imported DXF file or on some predefined design being easily achieved with Archipack. What I'm seeking is for a conceptual workflow that can transition perfectly into BIM and Documentation as fast as possible. This, for me, means more mass modelling than partition modeling and Mass modelling should evolve from an exterior volumetric model to a cell model. A cell model is not much more complex to elaborate, but it is informed with much more than a volumetric model as it has all programatic and functional relations expressed in the model in plan and elevation, so it's the perfect conceptual model of the building... it's the base of architectural thought. Walls are still something too related to floor plan concept which is 2D. What we should do is use 3D to think architecture.
@JuhaW said:
Ok, so the largest windows are always on the wall if it fits there. If its too big project to convert all to Python, then maybe using Blender UI for parameters and send them to Perl when calling Perl routines.
This wouldn't provide enough control. The 'Urb::Topologist' code that processes the blender mesh and identifies cells, walls, floors etc.. needs to be python running in blender - blender has to be able to detect rooms before we can have a GUI for manipulating them, currently it is just an undifferentiated mesh. The rest of the code can be ported to python later when it makes sense.
@brunopostle said:
blender has to be able to detect rooms before we can have a GUI for manipulating them, currently it is just an undifferentiated mesh.
Do you mean that Topologiser cannot identify cells and know they are rooms or that it cannot identify room functions?
I think it would be cool if room functions would be a user input into cells, like painting their floor with a material called living room and the other with a material called toilet. This would serve several purposes:
1 - Allowing architectural elements to be adapted to the function:
2 - Creating 3D functional diagrams of buildings based on color codes - These are great for presentations at conceptual stages;
3 - Use these functions to create zones in analysis software.
Such processing with graphs should be possible, however it is not in my field of expertise. So i think such cell processor like urb will remains and archipack must process the result and provide modifiable IFC entity according.
By the way archipack currently is able to "ifc classify" either on the fly at .ifc export time or at any time using "ifc structure tool".
Layered walls is something worked on, there is an experimental "array" object, but at this time it does lack simple/comprehensive way for users to achieve desired result fast.
Still must find how to implement a "sub object" concept to allow fine and easy control for wood framed like walls structural parts.
@stephen_l said:
I guess it is possible to handle the modelling process through archipack instead so windows / doors will remains editable and allow any shape. Maybe import + processing urb output directly in blender.
From my attempt to convert urb into pure python, there are many perl libs involved and we must find good python alternatives for some like pygraph. At this point have pure python urb
boundary
math
polygon
quad
graph / graph
math / polygon
If you are working on this, I'd love to see what you have done.
Note that the Topologise tool uses hardly any of the code from Urb, most of Urb is related to the binary tree model needed to evolve buildings, but Topologise uses a non-manifold mesh model that doesn't have much overlap (and isn't much use for evolution). So only the Urb::Topologist modules are relevant. It does heavily use the Molior module, but this itself duplicates a lot of code that probably already exists in places like archipack, blenderbim and ifcopenshell - picking Molior apart is a separate job.
The urb-topologist.pl script uses the Urb::Polygon module for drawing pitched roofs, but this isn't very successful and only works for simple shapes, plus it pushes the boolean code in ifcopenshell a bit too hard - for the full range of roof shapes possible with the Topologise tool it would be better to adopt code from elsewhere - for instance FreeCAD has an entire Arch_Roof tool that does a much better job.
As I mentioned before, if you want to build your solution based on Blender, you HAVE TO check Blender's scene graph and other packages/nodes
As far as I see, Urb is somewhat graph/tree/...-based and is so close to the notion of the scene graph
Based on my understanding, Archipack mainly works based on the transform matrix or similar notions, which can be part of the solution, but just a small part
And as I mentioned before Topologies follows an approach that faces limitation, so is not interesting to me (I like its Dual Graph and is part of the solution but in other areas, its approach is "so basic")
And Topologic follows another approach based on Space Syntax which IF USED ALONE has limitations too (as far as I know it just uses Space Syntax)
@ReD_CoDE nothing about the db backend improvement (large entity count support - issue with uniqueness of names)
Beside "Big projects" there is a notable improvement in both snap and boolean areas.
Big projects also too often lead to unpolished features sometimes even left "as it". So will wait and see if things are going to change.
@JQL said:
I think Archipack VS Topologic would be great. Could Archipack be revamped to create models based in cells instead of walls with Topologic's framework in mind?
It would be great if, at some point, layered walls would be created based on relation between cells or between cells and exterior spaces. In the end we could use this to define sets of rules to have thermal, fire and sound insulation or walls based on room finishes. After that we would use Archipack toolset to refine all other architectural elements. If this could be matched with IFC classification on BlenderBIM I think we could have a very efficient BIM modelling workflow principle to explore in Blender.
The idea for me is to find the best workflow between conceptual stage and production stage. Most examples I see for Archipack are based on an imported DXF file or on some predefined design being easily achieved with Archipack. What I'm seeking is for a conceptual workflow that can transition perfectly into BIM and Documentation as fast as possible. This, for me, means more mass modelling than partition modeling and Mass modelling should evolve from an exterior volumetric model to a cell model. A cell model is not much more complex to elaborate, but it is informed with much more than a volumetric model as it has all programatic and functional relations expressed in the model in plan and elevation, so it's the perfect conceptual model of the building... it's the base of architectural thought. Walls are still something too related to floor plan concept which is 2D. What we should do is use 3D to think architecture.
I hope this makes sense.
You are describing my thesis research.
I am following this thread on an off because 1. the discussion is deep into software 2. I'm deep into my thesis research which is much more abstract.
Just a side note, I've worked on the implications of the "compilation" from the abstract phases of architectural thought into the concrete stages of technical documentation. Both ends are architecture, but the early stages of the abstract phases are quite rarely done in depth usgin computation. For one, and I think this opinion has A LOT to do with cultural background, as long as users-creators keep talking about mass/volumes and not space there will be a huge gap.
Feel free to check some of the latest articles on the topic, some are in english. http://arquitextonica.net/
And @JQL if you are interested, I'd love to discuss further on the abstract-conceptual, the coding-software is out of my league (and allow me to say I feel discussing about code before discussing about content can be a HUGE burden when trying to develop design tools).
I fully agree with you then and would love to have that discussion any time. I will check the articles.
There is a gap to fill in software for conceiving architecture while there is a huge focus on the technical side of it. At the same time there's a mismatch between how you think and how you build.
When grasshopper popped up it was interesting as it addressed a new approach into how architecture was thought and conceived, but there is room for much more.
Now i get your point, using blender to "slap" cells and define relationships / properties of each cell, then process through a topologik like workflow, and use result to actually build IFC.
Sounds like huge challenge, but challenges are my fuel.
I guess brunopostle knowledge and experience of graphs and other people around will help to make things like that happen in a forseable future.
@ReD_CoDE said:
And Topologic follows another approach based on Space Syntax which IF USED ALONE has limitations too (as far as I know it just uses Space Syntax)
I will say this as politely as I can, please do not make comments about software that you have not used nor understood. Topologic is NOT just space syntax. We have published 12+ papers on it. Please read so that you can make informed comments.
At its core, and as we wrote in the original proposal to the Leverhulme Trust, BIM has excelled at modelling attributed building components, but has largely failed in encouraging strategic, conceptual, and spatial thinking. I choose these words carefully: strategic refers to the lack of a Vitruvian approach of 'setting out' what you want to do; to describe what you want to do and how you want to do it before actually doing it. Second, conceptual relates to the first term, but adds the dimension of abstraction-- filtering out and representing only what is needed for the task at hand, but also linking that conceptualization to concretization later on. Everything requires connection. Everything requires awareness and everything always exist in a multitude of contexts. Spatial thinking refers to BIM's utter lack of focus on space; and by space I don't mean a Topologic Cell, but this is the best we have in computers at this point. No one said in Topologic that a Cell is void, solid, liquid or gas. No one said its faces represent walls: its faces can represent nothingness and that is up to you the designer to insert, derive, and combine meanings. Space can be bounded or not bounded, but it is always pregnant with meaning. If meaning is too controversial a term, I am happy to use the @arquitextonica's informational term (but he knows I prefer the word meaning).
@brunopostle said:
blender has to be able to detect rooms before we can have a GUI for manipulating them, currently it is just an undifferentiated mesh.
Do you mean that Topologiser cannot identify cells and know they are rooms or that it cannot identify room functions?
I think it would be cool if room functions would be a user input into cells, like painting their floor with a material called living room and the other with a material called toilet. This would serve several purposes:
1 - Allowing architectural elements to be adapted to the function:
2 - Creating 3D functional diagrams of buildings based on color codes - These are great for presentations at conceptual stages;
3 - Use these functions to create zones in analysis software.
Topologic can do exactly that. A room can be given a dictionary with values, But here is what is more interesting: If you intersect a living room with a kitchen, it can tell you that this third space is an intersection of a living room and a kitchen and thus you can decide as a design rule to make that a breakfast area for example. The semantics survive and travel through the boolean operation automatically. And lastly, yes, TopologicEnergy takes these zones and feeds them to openstudio for thermal analysis. It is all there. We just need a collective effort to move Topologic to an open source software such as Blender or BIM. I already have a TopologicCore.so compiled for Linux with the help of Nicholas Wardhana and a second independent compilation done by Theo Dounas.
@brunopostle said:
blender has to be able to detect rooms before we can have a GUI for manipulating them, currently it is just an undifferentiated mesh.
Do you mean that Topologiser cannot identify cells and know they are rooms or that it cannot identify room functions?
Firstly, a reminder that the Topologise blender add-on does some of the same things as the Topologic library, but it is specialised for this particular task (turning a non-manifold mesh into a building). They don't share any code, Topologic does many other things besides, I am regretting giving the add-on a similar name, I thought it was cute.
Currently, the Topologise add-on does everything outside of blender using temporary files and Perl scripts. As far as blender is concerned, a mesh is exported and then an IFC building is imported. To work better, at least the bit that does the topological analysis needs to happen inside blender, so it can do stuff like this:
I think it would be cool if room functions would be a user input into cells, like painting their floor with a material called living room and the other with a material called toilet. This would serve several purposes:
1 - Allowing architectural elements to be adapted to the function:
2 - Creating 3D functional diagrams of buildings based on color codes - These are great for presentations at conceptual stages;
3 - Use these functions to create zones in analysis software.
Colour coding the floor face is a better idea than dropping icons/widgets into the room, which is the approach I took, but both ideas are a bit kludgy - blender should say 'this looks like a room' and offer a GUI element for changing its attributes.
@brunopostle said:
Colour coding the floor face is a better idea than dropping icons/widgets into the room, which is the approach I took, but both ideas are a bit kludgy - blender should say 'this looks like a room' and offer a GUI element for changing its attributes.
Could the BlenderBIM Add-on help? You could use IfcSpace with attributes / psets?
@topologic dear Wassim, could you please share the latest published paper here
If your solution doesn't have anything related to the grammar side, like shape grammar, or other grammars, it would have limitation
As far as I know, Space Syntax doesn't support the grammar side
@Moult said:
Could the BlenderBIM Add-on help? You could use IfcSpace with attributes / psets?
Maybe IFC is not so "blind" when it comes to manage spaces at drafting stage, but at this time no one (no major package) take advantage of it.
Time to take a closer look at TAD approach, as far as im aware it should handle this out of the box.
@stephen_l for DB, it's better to choose a "MODERN" SQL approach, and do everything on the backend (out of Blender), including GA and other things, and use Blender for draw and rendering stages :)
@brunopostle said:
Colour coding the floor face is a better idea than dropping icons/widgets into the room, which is the approach I took, but both ideas are a bit kludgy - blender should say 'this looks like a room' and offer a GUI element for changing its attributes.
Could the BlenderBIM Add-on help? You could use IfcSpace with attributes / psets?
At this stage all we have is a non-manifold mesh, we need the topology processing to be within blender to be able to say if there are any spaces there at all.
@JuhaW said:
I was thinking earlier today how it knows which part is a living room or kitchen, then I think maybe material name.
At the moment the Topologise add-on supports assigning room 'types' by dragging 3d widgets into each room, these widgets are in urb/examples/topologist-widgets.blend
@ReD_CoDE said: @topologic dear Wassim, could you please share the latest published paper here
If your solution doesn't have anything related to the grammar side, like shape grammar, or other grammars, it would have limitation
As far as I know, Space Syntax doesn't support the grammar side
Most of our publications are listed on the website some recent ones are under copyright by the publisher. The two most recent ones is SIMAUD on graph machine learning and one at the formal methods in architecture symposium.
You ask the wrong question and make unsubstantiated statements. Where is the evidence that if something does not use shape grammars then it has limitations? I have been reading about shape grammars since I met George Stiny in UCLA in 1990. I wrote a shape grammar piece of software for an AI class at the computer science department at the University of Michigan in the early 90s. SG is very interesting but sadly has had almost zero impact on the AEC industry. It remains a largely academic project.
Going back to your question: Topologic is a foundational software library. It does not preclude support for shape grammars. In fact, given its brep nonmanifold representation, it is highly compatible with shape similarity and detection algorithms needed for SG.
@topologic I think my message is clear:
If your solution just focuses on the "spatial" side, but doesn't support the "form" side, it's uncompleted Graph, it doesn't mater AI-based or non-AI-based, doesn't support forms
@ReD_CoDE said: @topologic I think my message is clear:
If your solution just focuses on the "spatial" side, but doesn't support the "form" side, it's uncompleted Graph, it doesn't mater AI-based or non-AI-based, doesn't support forms
I think the operative word here is "if".. Please explain to me if you have actually tried using Topologic and found out that it does not support forms. Have you actually used Topologic?
@ReD_CoDE said: @topologic dear Wassim, I clearly know about Topologic.
Also, on your website, you have introductions too
Just remember this part:
Graph, it doesn't mater AI-based or non-AI-based, doesn't support forms
Because soon in the AI world you will find what I was saying about graphs
The approach you follow about form is drawing shapes (geometries) and then work on their topologies, which indeed is about the optimization stage
OK. So you have not used it, but read about it and watched videos. One warning that I give people in my presentations is the following: Just because you familiarized yourself with one aspect of a piece of software, does not define the totality of that software. Example: If you have been using 3ds Max only for rendering and animation, you might not see it as something very suitable for digital fabrication. Keep an open mind.
I will engage you on the graph comment: Topologic is NOT just a graph. Topologic supports a graph class, but it is not a limitation, it is a feature. And I never said Graph supports forms, although the thesis by Kammal Haddad proves that you can go from a graph to forms using generative rules.
Right now, I am teaching myself to convert Topologic entities to IFC as inspired by Topologise. And this is the beauty of this thread. Topologic inspired @brunopostle to use non-manifold meshes and his amazing IFC models inspired me to start adding that functionality to Topologic. But because Topologic has full access to the underlying geometry, topology, and embedded information, I predict it will be able to do some interesting things when converting to and from IFC. Obviously, like Topologise, it can recognise exterior vs. interior walls, roofs vs. floor slabs vs. ground slab. But also, Topologic can recognise that a space is a 'living room' or a 'kitchen' without the need for painting the floor with a certain colour or placing widgets. It can also recognise that a living room has intersected with a kitchen and therefore, a rule could create a 'breakfast room' (all just examples.. design your own 'grammar' here).
Comments
I guess it is possible to handle the modelling process through archipack instead so windows / doors will remains editable and allow any shape. Maybe import + processing urb output directly in blender.
From my attempt to convert urb into pure python, there are many perl libs involved and we must find good python alternatives for some like pygraph. At this point have pure python urb
mostly done.
I think Archipack VS Topologic would be great. Could Archipack be revamped to create models based in cells instead of walls with Topologic's framework in mind?
It would be great if, at some point, layered walls would be created based on relation between cells or between cells and exterior spaces. In the end we could use this to define sets of rules to have thermal, fire and sound insulation or walls based on room finishes. After that we would use Archipack toolset to refine all other architectural elements. If this could be matched with IFC classification on BlenderBIM I think we could have a very efficient BIM modelling workflow principle to explore in Blender.
The idea for me is to find the best workflow between conceptual stage and production stage. Most examples I see for Archipack are based on an imported DXF file or on some predefined design being easily achieved with Archipack. What I'm seeking is for a conceptual workflow that can transition perfectly into BIM and Documentation as fast as possible. This, for me, means more mass modelling than partition modeling and Mass modelling should evolve from an exterior volumetric model to a cell model. A cell model is not much more complex to elaborate, but it is informed with much more than a volumetric model as it has all programatic and functional relations expressed in the model in plan and elevation, so it's the perfect conceptual model of the building... it's the base of architectural thought. Walls are still something too related to floor plan concept which is 2D. What we should do is use 3D to think architecture.
I hope this makes sense.
This wouldn't provide enough control. The 'Urb::Topologist' code that processes the blender mesh and identifies cells, walls, floors etc.. needs to be python running in blender - blender has to be able to detect rooms before we can have a GUI for manipulating them, currently it is just an undifferentiated mesh. The rest of the code can be ported to python later when it makes sense.
Do you mean that Topologiser cannot identify cells and know they are rooms or that it cannot identify room functions?
I think it would be cool if room functions would be a user input into cells, like painting their floor with a material called living room and the other with a material called toilet. This would serve several purposes:
1 - Allowing architectural elements to be adapted to the function:
2 - Creating 3D functional diagrams of buildings based on color codes - These are great for presentations at conceptual stages;
3 - Use these functions to create zones in analysis software.
Such processing with graphs should be possible, however it is not in my field of expertise. So i think such cell processor like urb will remains and archipack must process the result and provide modifiable IFC entity according.
By the way archipack currently is able to "ifc classify" either on the fly at .ifc export time or at any time using "ifc structure tool".
Layered walls is something worked on, there is an experimental "array" object, but at this time it does lack simple/comprehensive way for users to achieve desired result fast.
Still must find how to implement a "sub object" concept to allow fine and easy control for wood framed like walls structural parts.
If you are working on this, I'd love to see what you have done.
Note that the Topologise tool uses hardly any of the code from Urb, most of Urb is related to the binary tree model needed to evolve buildings, but Topologise uses a non-manifold mesh model that doesn't have much overlap (and isn't much use for evolution). So only the
Urb::Topologistmodules are relevant. It does heavily use theMoliormodule, but this itself duplicates a lot of code that probably already exists in places like archipack, blenderbim and ifcopenshell - pickingMoliorapart is a separate job.The
urb-topologist.plscript uses theUrb::Polygonmodule for drawing pitched roofs, but this isn't very successful and only works for simple shapes, plus it pushes the boolean code in ifcopenshell a bit too hard - for the full range of roof shapes possible with the Topologise tool it would be better to adopt code from elsewhere - for instance FreeCAD has an entire Arch_Roof tool that does a much better job.Pushed in public repo
https://github.com/s-leger/urb/tree/master
Archipack implement a polygon skeleton for pitched roofs, basically the same algo than OpenStreetMap.
https://github.com/s-leger/polyskel
As I mentioned before, if you want to build your solution based on Blender, you HAVE TO check Blender's scene graph and other packages/nodes
As far as I see, Urb is somewhat graph/tree/...-based and is so close to the notion of the scene graph
Based on my understanding, Archipack mainly works based on the transform matrix or similar notions, which can be part of the solution, but just a small part
And as I mentioned before Topologies follows an approach that faces limitation, so is not interesting to me (I like its Dual Graph and is part of the solution but in other areas, its approach is "so basic")
And Topologic follows another approach based on Space Syntax which IF USED ALONE has limitations too (as far as I know it just uses Space Syntax)
@stephen_l you talk about Blender limitations, see if your considerations reduce? https://code.blender.org/2020/01/2020-blender-big-projects/
@ReD_CoDE nothing about the db backend improvement (large entity count support - issue with uniqueness of names)
Beside "Big projects" there is a notable improvement in both snap and boolean areas.
Big projects also too often lead to unpolished features sometimes even left "as it". So will wait and see if things are going to change.
You are describing my thesis research.
I am following this thread on an off because 1. the discussion is deep into software 2. I'm deep into my thesis research which is much more abstract.
Just a side note, I've worked on the implications of the "compilation" from the abstract phases of architectural thought into the concrete stages of technical documentation. Both ends are architecture, but the early stages of the abstract phases are quite rarely done in depth usgin computation. For one, and I think this opinion has A LOT to do with cultural background, as long as users-creators keep talking about mass/volumes and not space there will be a huge gap.
Feel free to check some of the latest articles on the topic, some are in english.
http://arquitextonica.net/
And @JQL if you are interested, I'd love to discuss further on the abstract-conceptual, the coding-software is out of my league (and allow me to say I feel discussing about code before discussing about content can be a HUGE burden when trying to develop design tools).
I fully agree with you then and would love to have that discussion any time. I will check the articles.
There is a gap to fill in software for conceiving architecture while there is a huge focus on the technical side of it. At the same time there's a mismatch between how you think and how you build.
When grasshopper popped up it was interesting as it addressed a new approach into how architecture was thought and conceived, but there is room for much more.
Now i get your point, using blender to "slap" cells and define relationships / properties of each cell, then process through a topologik like workflow, and use result to actually build IFC.
Sounds like huge challenge, but challenges are my fuel.
I guess brunopostle knowledge and experience of graphs and other people around will help to make things like that happen in a forseable future.
I will say this as politely as I can, please do not make comments about software that you have not used nor understood. Topologic is NOT just space syntax. We have published 12+ papers on it. Please read so that you can make informed comments.
At its core, and as we wrote in the original proposal to the Leverhulme Trust, BIM has excelled at modelling attributed building components, but has largely failed in encouraging strategic, conceptual, and spatial thinking. I choose these words carefully: strategic refers to the lack of a Vitruvian approach of 'setting out' what you want to do; to describe what you want to do and how you want to do it before actually doing it. Second, conceptual relates to the first term, but adds the dimension of abstraction-- filtering out and representing only what is needed for the task at hand, but also linking that conceptualization to concretization later on. Everything requires connection. Everything requires awareness and everything always exist in a multitude of contexts. Spatial thinking refers to BIM's utter lack of focus on space; and by space I don't mean a Topologic Cell, but this is the best we have in computers at this point. No one said in Topologic that a Cell is void, solid, liquid or gas. No one said its faces represent walls: its faces can represent nothingness and that is up to you the designer to insert, derive, and combine meanings. Space can be bounded or not bounded, but it is always pregnant with meaning. If meaning is too controversial a term, I am happy to use the @arquitextonica's informational term (but he knows I prefer the word meaning).
Topologic can do exactly that. A room can be given a dictionary with values, But here is what is more interesting: If you intersect a living room with a kitchen, it can tell you that this third space is an intersection of a living room and a kitchen and thus you can decide as a design rule to make that a breakfast area for example. The semantics survive and travel through the boolean operation automatically. And lastly, yes, TopologicEnergy takes these zones and feeds them to openstudio for thermal analysis. It is all there. We just need a collective effort to move Topologic to an open source software such as Blender or BIM. I already have a TopologicCore.so compiled for Linux with the help of Nicholas Wardhana and a second independent compilation done by Theo Dounas.
Firstly, a reminder that the Topologise blender add-on does some of the same things as the Topologic library, but it is specialised for this particular task (turning a non-manifold mesh into a building). They don't share any code, Topologic does many other things besides, I am regretting giving the add-on a similar name, I thought it was cute.
Currently, the Topologise add-on does everything outside of blender using temporary files and Perl scripts. As far as blender is concerned, a mesh is exported and then an IFC building is imported. To work better, at least the bit that does the topological analysis needs to happen inside blender, so it can do stuff like this:
Colour coding the floor face is a better idea than dropping icons/widgets into the room, which is the approach I took, but both ideas are a bit kludgy - blender should say 'this looks like a room' and offer a GUI element for changing its attributes.
Could the BlenderBIM Add-on help? You could use IfcSpace with attributes / psets?
@topologic dear Wassim, could you please share the latest published paper here
If your solution doesn't have anything related to the grammar side, like shape grammar, or other grammars, it would have limitation
As far as I know, Space Syntax doesn't support the grammar side
Maybe IFC is not so "blind" when it comes to manage spaces at drafting stage, but at this time no one (no major package) take advantage of it.
Time to take a closer look at TAD approach, as far as im aware it should handle this out of the box.
@stephen_l for DB, it's better to choose a "MODERN" SQL approach, and do everything on the backend (out of Blender), including GA and other things, and use Blender for draw and rendering stages :)
At this stage all we have is a non-manifold mesh, we need the topology processing to be within blender to be able to say if there are any spaces there at all.
At the moment the Topologise add-on supports assigning room 'types' by dragging 3d widgets into each room, these widgets are in
urb/examples/topologist-widgets.blendThese are the minimum things needed to be considered:
This is glTF 2.0's architecture which is good for the start:
Geometry
Topology
Operations
Most of our publications are listed on the website some recent ones are under copyright by the publisher. The two most recent ones is SIMAUD on graph machine learning and one at the formal methods in architecture symposium.
You ask the wrong question and make unsubstantiated statements. Where is the evidence that if something does not use shape grammars then it has limitations? I have been reading about shape grammars since I met George Stiny in UCLA in 1990. I wrote a shape grammar piece of software for an AI class at the computer science department at the University of Michigan in the early 90s. SG is very interesting but sadly has had almost zero impact on the AEC industry. It remains a largely academic project.
Going back to your question: Topologic is a foundational software library. It does not preclude support for shape grammars. In fact, given its brep nonmanifold representation, it is highly compatible with shape similarity and detection algorithms needed for SG.
@topologic I think my message is clear:
If your solution just focuses on the "spatial" side, but doesn't support the "form" side, it's uncompleted
Graph, it doesn't mater AI-based or non-AI-based, doesn't support forms
Oops, fixed.
I think the operative word here is "if".. Please explain to me if you have actually tried using Topologic and found out that it does not support forms. Have you actually used Topologic?
@topologic dear Wassim, I clearly know about Topologic.
Also, on your website, you have introductions too
Just remember this part:
Because soon in the AI world you will find what I was saying about graphs
The approach you follow about form is drawing shapes (geometries) and then work on their topologies, which indeed is about the optimization stage
Ask yourselves why I mentioned "building blocks" from the chemistry field, not other fields
https://www.researchgate.net/project/INSIDE-THE-CIRCULAR-PRODUCT-FOR-LIVING-BRINGING-A-NEW-VISION-TO-THE-BUILT-ENVIRONMENT-BY-THINKING-OF-BUILDING-AS-A-CIRCULAR-PRODUCT
OK. So you have not used it, but read about it and watched videos. One warning that I give people in my presentations is the following: Just because you familiarized yourself with one aspect of a piece of software, does not define the totality of that software. Example: If you have been using 3ds Max only for rendering and animation, you might not see it as something very suitable for digital fabrication. Keep an open mind.
I will engage you on the graph comment: Topologic is NOT just a graph. Topologic supports a graph class, but it is not a limitation, it is a feature. And I never said Graph supports forms, although the thesis by Kammal Haddad proves that you can go from a graph to forms using generative rules.
Right now, I am teaching myself to convert Topologic entities to IFC as inspired by Topologise. And this is the beauty of this thread. Topologic inspired @brunopostle to use non-manifold meshes and his amazing IFC models inspired me to start adding that functionality to Topologic. But because Topologic has full access to the underlying geometry, topology, and embedded information, I predict it will be able to do some interesting things when converting to and from IFC. Obviously, like Topologise, it can recognise exterior vs. interior walls, roofs vs. floor slabs vs. ground slab. But also, Topologic can recognise that a space is a 'living room' or a 'kitchen' without the need for painting the floor with a certain colour or placing widgets. It can also recognise that a living room has intersected with a kitchen and therefore, a rule could create a 'breakfast room' (all just examples.. design your own 'grammar' here).