Open sourcing TAD

S by Sabufrancis on 8 Oct 2020, edited 28 Dec 2020 # +2 votes

Some of you may be knowing about TAD, an old design software that I had developed for my own practice long time back -- which is available as a freeware since 2017. I had promised that from version 7.0x onward it would be made open source. I am serious about it. There are a few issues which I would like to overcome.

One is that TAD was written in two old languages: The business logic is in Visual Prolog version 5.2 and the second is Delphi 5 Professional. Both these languages are no longer available.

Another issue (if I can call this an issue) is that the concepts of TAD started in 1988 -- with the first version in 1989 and turns out it is quite different from the direction that others followed. Since then, thousands of projects were done in TAD; and a lot of milestones were met. Including two research projects in energy analysis of buildings; which was done in association with IIT-Bombay.

In order to change the internal concept map of TAD to something more conventional is hard and I possibly wont go in that direction. I am yet to find another software that can be used as a basis on which TAD could be developed; as the concepts in TAD don't map onto concepts in other software.

One more headache is that internally TAD has a Prolog interpreter which I modified to create ARDELA; the scripting language inside TAD. Internally, there are some meta-programming concepts that TAD uses (data turning into code just-in-time)

Ideally in the open-source version; I would like to use a language which has intricate meta-programming capabilities. I can agree to discontinue the internal scripting language of ARDELA but today it is intricately tied up the meta-programming aspects inside the code.

Another issue: The version of Prolog I used (Visual Prolog) itself is an outlier in the area of other Prolog compilers. So I would need to rewrite everything if I used gnu-prolog or some other Prolog. The Delphi part can be ported onto Lazarus (a RAD system on top of Freepascal). But to rewrite the business code in Freepascal instead of Prolog will be inefficient

Though some people say I should switch over to a totally online browser based TAD; I find that there are some hiccups with that: Many architects are quite guarded about their data. Moreover, the focus of TAD is in the developing countries -- where Internet is sometimes flaky. Another important focus of TAD is that it handles information even when the model is not fully firmed up -- I strongly believe that design decisions made at the very early stages of designs are quite important to the evolution of design

I have two requests in this post

1) I welcome any suggestion on computer languages I could consider. If you have previously used TAD it would help. See www.teamtad.com

2) As part of the TAD project; I am curious to see the open sourcing of architecture itself -- The metaphor being that "open source of software before the software is compiled" is mapped to the "open sourcing of the architecture representation before the building is made" I am gearing up TAD to have a github/gitlab kind of online environment to manage architecture open source projects.

On cursory examination here, I find that this forum seems to be talking of open source software (albeit in the architecture field) and not much about how one open-sources the architecture process itself. I may be wrong as I have not really examined this website/forum in depth. So any suggestion in this kind of open sourcing of architecture is also welcome

C by Cyril on 8 Oct 2020, edited 8 Oct 2020 # +1 votes

Welcome !

@Sabufrancis said:

Some of you may be knowing about TAD, an old design software that I had developed for my own practice long time back -- which is available as a freeware since 2017. I had promised that from version 7.0x onward it would be made open source. I am serious about it. There are a few issues which I would like to overcome.

I already heard of TAD but don't remember in which context. Could it be inside an energy related scientific publication ?

1) I welcome any suggestion on computer languages I could consider. If you have previously used TAD it would help. See www.teamtad.com

I would tend to say that if you want a large as possible audience could contribute to your code you'll have some advantages to choose widely adopted programming languages. Tiobe index shows that C, Java and C++ have been on top for decades but are mainly used by core developers only (like in Blender and FreeCAD). On the other side python is the scripting language which you will find almost everywhere as it is very popular and multipurpose. Rust is apparently very appreciated as it has been designated as the most loved programming language past 5 years which is impressive for a programming language which is more like C/C++ in term of complexity and performances than like python.

I don't really like web-based technology for this kind of software even if some use it but some here will disagree and will also say that web based technologies are the way to go. About your concern in developing countries, you can use stuff like electron (or preferably better as it is commonly considered as too heavy) to make your software available offline.

2) As part of the TAD project; I am curious to see the open sourcing of architecture itself -- The metaphor being that "open source of software before the software is compiled" is mapped to the "open sourcing of the architecture representation before the building is made" I am gearing up TAD to have a github/gitlab kind of online environment to manage architecture open source projects.

On cursory examination here, I find that this forum seems to be talking of open source software (albeit in the architecture field) and not much about how one open-sources the architecture process itself. I may be wrong as I have not really examined this website/forum in depth. So any suggestion in this kind of open sourcing of architecture is also welcome

@theoryshaw has experimented many open source architecture workflows with OpeningDesign.

Also you might want to check last community meeting where Marcin Jakubowski talked about Open Source Ecology which started with open hardware like brick press, tractor, oven etc… and are now talking about solving housing with an modular and open source architecture.

P by paullee on 8 Oct 2020 #

I read about TAD in FreeCAD forum, though have not used it, no Windows :)

R by ReD_CoDE on 8 Oct 2020 #

I checked your website, so as far as you shared, and now we know, it's based on visual Prolog. (I'm not a programmer, but I'm a fan of Prolog and Datalog,) so that means you were interested in metadata and queries, in general, "logic"

So, the language you choose is dependent on your goal, if you want performance and safe things Rust would be better than even C and C++

Rust, Lua, C++, C, Python, ... it depends

If your software is more simulation-based, then have a look at Modelica

I have a question too:

Which geometric modeling kernel does TAD use?

S by Sabufrancis on 8 Oct 2020 #

@paullee said:

I read about TAD in FreeCAD forum, though have not used it, no Windows :)

TAD works quite well under Linux -- all you need is the WINE layer in Linux. On Macs also it used to work; but AFAIK, the latest Mac does not have a compatible WINE -- not sure if that situation has changed now. Prior Mac OSX used to work quite well. Unfortunately I cant afford Macs so can't test directly. I am stating this problem on Macs from a student someime in February 2020

It works beautifully on a ChromeOS machine from HP -- I could install WINE on it for someone else. The docs has more info on what is needed under Wine http://docs.teamtad.com/wine

S by Sabufrancis on 8 Oct 2020, edited 8 Oct 2020 # +1 votes

@ReD_CoDE said:

I checked your website, so as far as you shared, and now we know, it's based on visual Prolog. (I'm not a programmer, but I'm a fan of Prolog and Datalog,) so that means you were interested in metadata and queries, in general, "logic"

Yes. TAD is highly logical but it is not restrictive. TAD uses a loosely coupled data-structure; and has enough smarts in it to detect errors (thru a separate ARDELA script) and check your architectural design. And your reference to Prolog: Yes, that is the reason it can handle partial data and metadata quite well and why I am quite dissatisfied with other languages.

I had assisted in writing some of the tutorials of Visual Prolog long time back. Not sure if it is still there on the Internet -- I had written an article on the close-connection between Prolog and Javascript. It is quite fascinating. There is also a deep connection between Prolog and XML too. The TAD ascii format can easily be directly interpreted by Javascript.

So, the language you choose is dependent on your goal, if you want performance and safe things Rust would be better than even C and C++

Rust, Lua, C++, C, Python, ... it depends

If your software is more simulation-based, then have a look at Modelica

I am looking at Modelica. Seems quite interesting but not sure if it is industry tested

I have a question too:

Which geometric modeling kernel does TAD use?

None. Everything coded by me. I've been continually updating TAD since 1989 so that is quite a long time. I use one piece of code from Angus Johnson http://www.angusj.com/delphi/ for 2D Booleans and offsets. (I had written my own earlier, but I found Angus's code a lot more efficient)

Today TAD even allows remote collaborations, extensions in many different languages (The entire model can easily be exported to Python, Lua, C, C++, JS ... using the neat Haxe system. Developers can easily make additional applications that use the TAD model)

S by Sabufrancis on 8 Oct 2020, edited 8 Oct 2020 # +1 votes

@Cyril said:

Welcome !

Thank you very much. I am new here. Still browsing around.

I already heard of TAD but don't remember in which context. Could it be inside an energy related scientific publication ?

Possible. A journal article written jointly by me and Dr J K Nayak on a new way to calculate heat energy in buildings using a heat-engine written by Dr Nayak using Fortran. It was published in a solar energy journal -- almost 20(?) years back

I don't really like web-based technology for this kind of software even if some use it but some here will disagree and will also say that web based technologies are the way to go. About your concern in developing countries, you can use stuff like electron (or preferably better as it is commonly considered as too heavy) to make your software available offline.

Thanks for all the suggestions. Electron is just too heavy and moreover it just a wrapper for a browser -- the assumption being that you still write things inside the Javascript. That way Sciter possibly maybe better; but it has some quirks

@theoryshaw has experimented many open source architecture workflows with OpeningDesign.

Also you might want to check last community meeting where Marcin Jakubowski talked about Open Source Ecology which started with open hardware like brick press, tractor, oven etc… and are now talking about solving housing with an modular and open source architecture.

Thank you. I will take a look at that. I am specifically asking about the design process; and not the actual construction of buildings -- I think there are some projects that claim to be open-source of the construction. To me, that is not where open-source in architectural process ought to be (or rather, it is important, but often the horse has already run away from the stables when you reach construction stage) But my point was about an almost exact parallel between software development, and architectural design development. In both cases; there is a lot of discussions, debate, collaboration on the abstractions on designing. I use the term AIM (Architecture Information Modeling) and I believe BIM (Building information Modeling) is just a subset of AIM -- AIM talks about the entire process right from early stages of design, through all the iterative design cycles -- to the finalization (which is where BIM starts coming in) to the construction to the usage and to the eventual destruction/recycling of the project. A few people have joined the AIM forum here https://www.aimnetwork.org I welcome everyone to join it if you are interested

M by Moult on 8 Oct 2020 # +1 votes

Welcome to OSArch @Sabufrancis !

I think all of us completely support the decision to go open source. I cannot give any suggestions on the programming stack going forward, as it seems you already have a strong understanding of the pros and cons of switching to different languages.

As for open sourcing the design workflow, @theoryshaw indeed does that with his OpeningDesign firm. All design work is done collaboratively online, tracked in a Github repo, using a type of online whiteboard where people can collaboratively scribble and mark-up designs called First-Draft. His work is absolutely fascinating.

@yorik has also worked on the Wikihouse project, where the community collaboratively designs, and then also builds, a small house.

Although Open Source Ecology currently seems to mostly market its machines and construction, the OSE project is designing a house, and the design process from what I can see seems to be also open to all to collaborate.

A few other comments - I think BIM vs AIM seems to be simply a matter of semantics. BIM (or AIM, which I see as interchangeable) should be used right from early feasibility studies, then through concept design, and so on. The fact that most people don't do it that way is due to the software that exists - which tends to encourage its use only further down the design development stage. As a result, we do feasibility studies and concept design with mediums that don't retain semantics very well.

To explain my point, consider this concept model which is also a full BIM model. Half of it is just sketches, but it is also semantic. Another example is the work done by Topologic here. The Topologic approach uses spaces to model, especially useful during early concept phase, and similar to your approach. Yet, it is still a fully capable BIM model. The BlenderBIM Add-on also supports storage of design objectives, design strategies, and constraints, which may be categorised (e.g. design intent, legislative constraints, etc) - the brainstorming, prioritisation, and then realisation of design intent is all stored in BIM.

S by Sabufrancis on 9 Oct 2020, edited 9 Oct 2020 # +3 votes

As for open sourcing the design workflow, @theoryshaw indeed does that with his OpeningDesign firm. All design work is done collaboratively online, tracked in a Github repo, using a type of online whiteboard where people can collaboratively scribble and mark-up designs called First-Draft. His work is absolutely fascinating.

@yorik has also worked on the Wikihouse project, where the community collaboratively designs, and then also builds, a small house.

Although Open Source Ecology currently seems to mostly market its machines and construction, the OSE project is designing a house, and the design process from what I can see seems to be also open to all to collaborate.

I can understand. I will take a deep look and try to understand.

A few other comments - I think BIM vs AIM seems to be simply a matter of semantics. BIM (or AIM, which I see as interchangeable) should be used right from early feasibility studies, then through concept design, and so on. The fact that most people don't do it that way is due to the software that exists - which tends to encourage its use only further down the design development stage. As a result, we do feasibility studies and concept design with mediums that don't retain semantics very well.

With due respect; that last two statements you made there actually captures my point about the difference between BIM and AIM. Among many architects (I know there are exceptions) we actually do distinguish between the term "architecture" and the term "building" -- The former captures the entire process (...well let me not repeat myself). For non-architects a building is what one could be concerned with. As they say the proof of the pudding is in the eating. But for the cook, there are lot of issues that needs to be considered and possibly even thrown away (like the water that boils off when cooking rice, for example) Pardon me for jumping into an analogy. It is not a strawman argument. I believe the term "architecture" got usurped into other areas because architecture process does the setting up of the context. (e.g. There is a phrase "architect of the nation" but nothing called "doctor of the nation" or "engineer of the nation") And context setting is an iterative process; and anything iterative needs to be really fast, else it becomes flatened. A loosely-coupled data structure helps a lot to ensure that iterations are done rapidly. It is something that rigid data structures dont do well.

To explain my point, consider this concept model which is also a full BIM model. Half of it is just sketches, but it is also semantic. Another example is the work done by Topologic here. The Topologic approach uses spaces to model, especially useful during early concept phase, and similar to your approach. Yet, it is still a fully capable BIM model. The BlenderBIM Add-on also supports storage of design objectives, design strategies, and constraints, which may be categorised (e.g. design intent, legislative constraints, etc) - the brainstorming, prioritisation, and then realisation of design intent is all stored in BIM.

Yes, the Topologic system is quite fascinating. I will study it more. Long time back I had written to Bill Hiliers who is a central figure in the Spatiality movement. But did not get a reply.

I was a practicing architect (and in my minds eye I am still visualize myself as a hard-core architect) -- that too from a small town in India and not really a theoretician, and yet talking about core theory. So it was really tough to get some meaningful conversation going. I now have several journal and conference papers; but I still do not regard myself to be a pure theoretician. TAD did not emerge from a "publish or perish" paradigm.

I get the impression here that BIM and IFC is the standard datum from which everything emerges. It seems to be accepted as the uncontested starting point. It would be nice to see some healthy debates about that itself.

Long time back when IFC was being formulated; I was curious to know what the internal debates were -- and did see some conversations on the Internet long time back. It was difficult doing it from India, but whatever I heard left me puzzled and disappointed. I find there are huge flaws in IFC itself; for example it has nothing in it to prevent data explosion. Though there is some gesture towards recognizing space itself as an entity, I find it does not go the whole way.

It seems to assume that everyone has tons of gigabytes of RAM and storage. A building (and before that, the ongoing architectural design process stages) is possibly the largest, continually growing hard-disk one can ever have! But I find IFC hugely reductionist, and impractical to handle all the representational issues that architects face. And the structural rigidity of the internal components in BIM/IFC; as hinted earlier, can really make design iterations very stultified.

Note that I have worked extensively in IFC -- I wrote this SaaS product: www.queryprojects.com which takes an IFC file and Microsoft Project file (or anything that generates the standard MSP XML export) and combines both together, and queries an ongoing construction. On a side note; if there is anyone here who wants to take up that project -- let me know. I do not have people or resources and so I am looking for partnerships and ideas to take that up ahead. Currently, the project is just that wonderful SaaS which can do a NavisWorks+Revit kind of analysis in seconds

The reason I decided to go on a different path and not follow the IFC route came after a lot of debates and heartburn. So when I see claims being made that here is a system that talks about spaces and can handle early stages of designs too; and it uses IFC my bias comes up strongly. Pardon me for that. I need to resist that and take a re-look.

D by DADA_universe on 9 Oct 2020 # +2 votes

@Sabufrancis said:

Some of you may be knowing about TAD, an old design software that I had developed for my own practice long time back -- which is available as a freeware since 2017. I had promised that from version 7.0x onward it would be made open source. I am serious about it. There are a few issues which I would like to overcome.

One is that TAD was written in two old languages: The business logic is in Visual Prolog version 5.2 and the second is Delphi 5 Professional. Both these languages are no longer available.

Another issue (if I can call this an issue) is that the concepts of TAD started in 1988 -- with the first version in 1989 and turns out it is quite different from the direction that others followed. Since then, thousands of projects were done in TAD; and a lot of milestones were met. Including two research projects in energy analysis of buildings; which was done in association with IIT-Bombay.

In order to change the internal concept map of TAD to something more conventional is hard and I possibly wont go in that direction. I am yet to find another software that can be used as a basis on which TAD could be developed; as the concepts in TAD don't map onto concepts in other software.

One more headache is that internally TAD has a Prolog interpreter which I modified to create ARDELA; the scripting language inside TAD. Internally, there are some meta-programming concepts that TAD uses (data turning into code just-in-time)

Ideally in the open-source version; I would like to use a language which has intricate meta-programming capabilities. I can agree to discontinue the internal scripting language of ARDELA but today it is intricately tied up the meta-programming aspects inside the code.

Another issue: The version of Prolog I used (Visual Prolog) itself is an outlier in the area of other Prolog compilers. So I would need to rewrite everything if I used gnu-prolog or some other Prolog. The Delphi part can be ported onto Lazarus (a RAD system on top of Freepascal). But to rewrite the business code in Freepascal instead of Prolog will be inefficient

Though some people say I should switch over to a totally online browser based TAD; I find that there are some hiccups with that: Many architects are quite guarded about their data. Moreover, the focus of TAD is in the developing countries -- where Internet is sometimes flaky. Another important focus of TAD is that it handles information even when the model is not fully firmed up -- I strongly believe that design decisions made at the very early stages of designs are quite important to the evolution of design

I have two requests in this post

1) I welcome any suggestion on computer languages I could consider. If you have previously used TAD it would help. See www.teamtad.com

2) As part of the TAD project; I am curious to see the open sourcing of architecture itself -- The metaphor being that "open source of software before the software is compiled" is mapped to the "open sourcing of the architecture representation before the building is made" I am gearing up TAD to have a github/gitlab kind of online environment to manage architecture open source projects.

On cursory examination here, I find that this forum seems to be talking of open source software (albeit in the architecture field) and not much about how one open-sources the architecture process itself. I may be wrong as I have not really examined this website/forum in depth. So any suggestion in this kind of open sourcing of architecture is also welcome

Good to have you here @Sabufrancis.

About rewriting the code, this clearly can't be done at once, so I guess you'll be breaking the entire TAD solution into chunks and having those rewritten piecemeal. I'm sure there will be optimizations and opportunities to refine things even further as things unfold, and of course, a few gothas, but you're clearly on top of that.

The other critical thing would be building a community around the code rewrite effort as clearly this is not something you should do alone (you have over a million lines of code if I'm not wrong?) and having a community built around code development is one great advantage of going open source. This is going to require community building efforts from you, not just to onboard people to use TAD, but to attract Architect-Software Developer types who are curious about the code and adventurous enough to jump in with you to tweak things. You probably don't need more than 3 - 4 main collaborators, but you'll need an active GitHub repo where people can test, break and report issues for the core devs to fix. If this works well enough, you should get minor code contributions from people as well, and all this will add up. You will find this forum can aid in that process, lots of magical collaborations are happening just from people sharing ideas here.

Concerning programming languages, you would want to take full advantage of the opportunities the open source ecosystem present in terms of not reinventing the wheel where possible (you will still have to carefully navigate licensing issues even with open source libraries, some licenses are more permissive than others and your choice of libraries to integrate could complicate things down the line based on the licenses they are released under), and achieving interoperability between tools. Both BlenderBIM and Freecad for example are benefiting from this, with @Moult and @yorik comparing notes, sharing information and sometimes even exchanging code, while both tools are indeed unique. It helps that both Blender and Python have a C / C++ and Python code base in common, I don't know how well the advantage you found in using a Prolog-centric approach for the business logic can be replicated with this combination, but you are likely to have more people who can understand and participate in conversations on TAD development if you took that route, plus the added advantage of some level of interoperability between TAD, Freecad and Blender (and other tools already plugged into that ecosystem). All this should lead to increased discoverability and adoption for TAD.

I recommend you peruse this thread. Topologic addresses one of your key interests in having representation for / ways of manipulating spaces / volumes outside of the representation for the boundaries between / envelopes around them (walls, slabs et al) and the implications of this for early stage design. I find it quite fascinating how the conversation in that thread is influencing the evolution of another tool (Homemaker by @brunopostle) , which is in turn also influencing further work by @topologic etc. There are many other examples of this sort of organic growth powered by collaboration and openness on this forum and like Dion Moult has suggested, this is also applicable to the design workflow as well, though that definitely presents its own set of challenges. If TAD shines at facilitating this, then it would make it an invaluable addition to the ecosystem and people would be interested in engaging with it.

P.S. I don't see any critical reason for TAD to be fully online and browser based.

S by Sabufrancis on 9 Oct 2020, edited 9 Oct 2020 # +1 votes

@DADA_universe said:

Good to have you here @Sabufrancis.

Thanks. Nice to see you here too

About rewriting the code, this clearly can't be done at once, so I guess you'll be breaking the entire TAD solution into chunks and having those rewritten piecemeal. I'm sure there will be optimizations and opportunities to refine things even further as things unfold, and of course, a few gothas, but you're clearly on top of that.

The other critical thing would be building a community around the code rewrite effort as clearly this is not something you should do alone (you have over a million lines of code if I'm not wrong?) and having a community built around code development is one great advantage of going open source.

True, there are lots of things need to be done. Yes, there is a lot of code that was written (When I include the code for the RAD components in Delphi, it is quite a lot) Maybe a whitepaper needs to be written and circulated.

...achieving interoperability between tools.

There are fundamentals to be agreed upon before interoperability. The issue with me possibly is that I have OCD at the level of the deepest concepts -- and I am still not in agreement with several fundamental points

I recommend you peruse this thread. Topologic addresses one of your key interests in having representation for / ways of manipulating spaces / volumes outside of the representation for the boundaries between / envelopes around them (walls, slabs et al) and the implications of this for early stage design. I find it quite fascinating how the conversation in that thread is influencing the evolution of another tool (Homemaker by @brunopostle) , which is in turn also influencing further work by @topologic etc.

I am taking a deeper look at @topologic and now you point to Homemaker. Will take a look at that too

I have my biases due to TAD; and following are the points from that bias, so my assessment of other spatial approaches would need to at least satisfy these criteria:

a) Design decisions ought to happen from very early stages of design. The data structures and algorithms need to understand the merits of this. Read Marvin Minsky's paper on neatness and scruffiness. https://web.media.mit.edu/~minsky/papers/SymbolicVs.Connectionist.html Though that is about AI, the core points are quite valid. The real world is very scruffy and come to India (or maybe Africa? @DADA_universe ;-) ) to know what one means by the scruffy world of designing.

b) Early stages of design means there WOULD be logical mistakes too such as intersecting spatial volumes. I see a lot of effort to make the ongoing efforts to make the model as closely precise to some eventual real building as possible -- I would shy away from those. For some reason computer science algorithms tend to promote the feeling of completeness, preciseness and conflate all that with the idea of clarity. Clarity is an emergent phenomenon and in a design field where decisions need to be taken using abductive logic, those taking the decision need to know what was discarded and what was then promoted. That is why I shied away from having generative routines in TAD (to some extent, though I did insert some amount of parameterization -- which frankly I dont use much but others may)

c) Rapid iterations need to be promoted. Any data-structure that is top-heavy intrinsically don't allow iterations or maybe they allow rapid iterations as long as the designer walks the pre-determined line. Added to it, the additional headache of combinatorial explosion of data as the design evolves

d) Both space and solids need to be represented, with as little redundancy as possible. (The D-R-Y principle) There was this interesting data structure (I think it was called the "Split-wing" database) by Dr Yehuda Kalay and others had this clever topological capability of talking of both built matter and space; but it was a structurally rigid data structure (See next point)

e) Loosely coupled data structure. I am convinced that is the only way to achieve rapid iterations. If the design system continually keeps correcting the designer to keep the model correct at all times, it is a negative point disguised as a positive one

f) No pre-decided properties. I use the term "just-in-time" modelling here. Architectural design process is full of surprises. As an example; in India, suddenly in the middle of the designing the client's wife would quote some ancient religious text (called Vastu-Shastra) and insist that some properties from that topic need to be analysed in the project. So the modelling really need to be done just-in-time

g) Shying away from real world analogical connections. TAD uses an abstract symbolic classification system for its data-structure -- I wrote a paper in 1999 titled "The importance of being abstract: An Indian approach to models" http://papers.cumincad.org/data/works/att/b1db.content.pdf

i) Forgot to add: Wellformed-ness of volumes need to be adhered to -- if a volume is not well formed, then it must be possible to separate those out clearly and not pollute the data. That means if you make a cube, then later on remove one face of the cube; and later on add the face back again (as a surface modeler such as sketchup would do) that strictly should not be allowed, unless there is a clear way to detect and remove ill-formed volumes such as that example of the cube where a face was removed. Maybe this is a programming limitation due to my own understanding -- never found a rigorous algorithm that can automatically detect all ill-formed volumes without fail. The cube example is of course a trivial one. (Hmmm...maybe not so trivial either, if you want to be finicky about it. If you consider ALL the faces of the cube to be editable and re-arrangeable, then the total combinations is over 188,000,000 if you have an OCD of putting the faces back in some previously accepted order. See the excellent 3BlueBrown channel (Grant Sanderson) explanation

Many software allow the data to remain in a corrupted state which is not really accessible even to the program itself; not because the designer would get a specific advantage to allow errors (as mentioned earlier) but possibly because of continuing a legacy of old graphic editing routines more than anything else

The other point which I want to add is due to the way it is done in TAD: To obtain huge data efficiency, TAD uses an OOPs paradigm of classes and objects -- and it is quite detailed but subtly different from a computer language. In a computer language, you have "Private" and "protected" and "public" fields/methods. But in TAD, you can set properties and methods to be "inheritable" or "non-inheritable" and like OOPs, it even allows object overrrides. So you have flexibility both at the macro level as well as at the micro-level; and you decide what you want to use. This is one major reason why TAD's file sizes are extremely small. But when assessing other approaches to cover the entire lifecycle of architectural design process; I will not hold this particular point to be important as I am sure there are other methods too which are available to make the data structures extremely efficient (Hence this is not really in the above list)

P by paullee on 11 Oct 2020, edited 11 Oct 2020 #

@Sabufrancis Hi again. Just read your introduction in the separate thread. Just curious about your idea of "alphabets" in Architecture. Better still, could you do a concise demonstration of the worflow in TAD. Thanks.

S by Sabufrancis on 11 Oct 2020, edited 11 Oct 2020 # +2 votes

@paullee said:

@Sabufrancis Hi again. Just read your introduction in the separate thread. Just curious about your idea of "alphabets" in Architecture. Better still, could you do a concise demonstration of the worflow in TAD. Thanks.

Thank you for your questions. Yes, TAD started as a way of putting together the "alphabets" -- If you see the history of technical drawings, one major event happened during the Renaissance -- when Brunelleschi solved the problem of the half-finished cathedral dome. In doing so, he ended up showcasing the importance of drawings. I believe that and later on other similar use of drawings (such as the assembly instructions of canons in France) all led to the belief that technical drawings are the means to express architecture.

What many (not all) forgot is that Brunelleschi was talking about construction and not really about the design process.

Architects have to deal with both built as well the un-built in a hopelessly intertwined "figure ground" illusion. We have spaces because the walls around them create them; but then we the walls are created because spaces are separated from each other. Kind of a barber-paradox.

If I hazard an analogy: this is something what musicians also deal with: They too have a figure-ground between the sound that emerges at an instance (the note) punctuating the backdrop of silence. The silence between notes is needed to highlight the note but by highlighting the note, we notice the silence!

The musicians solved their figure-ground confusion by inventing the musical notation, where one sees abstract "alphabets" both for the notes as well as for the silences. They know that if they have to make sense of their music, they would need to represent BOTH and retain the representation right across.

But we architects largely lose our representation of spaces over the design process. By the time the design is finalized; what is left behind is pithily represented by the French term: poché -- it stands for the marks we leave behind to represent whatever is built. What is not built, well; good earnest people thought that they no longer need representation because we build only the built-matter; so why should we talk about spaces anymore.

My strong contention is that we cannot afford to stop representing spaces. They are always needed in the representation. We need the spaces to be represented and remain represented right across; because in future someone poring over the TAD model would know what were the built matter, and what were the parts of the space -- and when the architects and other collaborators kept embellishing them, future users (which could be an AI program) can easily know what happened as the design emerged -- and it is not just the geometry

(BTW, there is only one universal space, though we use the term "spaces" to usually indicate parts of that one space. We architects simply either promote opportunities or demote opportunities on whatever that happens in those parts of the space)

To finally answer your question: The workflow in TAD actually inverts the conventional process (and that is why it is sometimes hard to get accepted or understood)

Instead of expressing the edges of built matter, TAD expresses the edges of spaces. (It can express built-matter like regular 3D too but you will know how it does that in a moment) So here is an example; the entire silhouette of a building would be the alphabet called "envelope" inside that envelope, are a set of "atoms" -- which are spatial volumes whose characteristic is that it is not further sub-divided.

Then there are "connectors" which are spatial volumes that connects two or more of its faces with other spatial volumes, so that now you can actually form the "graph tree" of the spatial organization. The built matter now becomes the boolean subtraction i.e. BUilt matter = envelopes - (atoms+ connectors) ... but then you may decide to put in regular built-matter too; such as columns, beams, etc -- the volumes of those actually do NOT get subtracted as such (the philosophy being that a column came into say the corner of a room to support the wall due to some strength of material issue, and not really because of the demand of the space itself -- such pure solids can always go away)

These fully solid material are called "artefacts" but then when you later examine an artefact deeper, you find that itself could be actually a collection of Atoms, Envelopes and connectors but now at a different scale of examination. For example; initially you placed the column as one solid mass; but on closer examination that column was actually a doubly-laced steel column; and hence could be broken down into atoms, envelopes, connectors.

In short; any built environment, can be expressed as a collection of atoms, envelopes and connectors at various different scales of examination. (Hence I use the term "fractal" ... maybe a better term is "iterative" data structure) I think there are couple of solutions here (topologic and HomeMaker) which do recognize the need for spaces. But I think TAD does it quite differently. One crucial difference is that TAD retains the classifications right across with no attempt to really do the actual booleaning inside TAD itself... There are many other differences and many reasons too but let me not make this even longer than what it already is

Recently I came across the Sumerian method of expressing architecture -- which is actually remarkably similar to the TAD method -- I could easily identify on their 5000 year old clay tablets the three kinds of spaces: Envelopes, atoms and connectors.

Actually it is not just me who have noticed these 3 types of spatial volumes. The well known architect; Rob Krier, also spoke of those in a book... but he did not call the 3 types by my terminologies; and I read that book long after I had published my thesis with the JIIA -- the Journal of the Indian Institute of Architects in 1991

I think I have made this reply too long. Maybe you should take a look at this video I had made. Pardon the quality of the video -- I am stuck at home due to Covid19 and I ramble a bit -- been working quite late in the night and this one was made in the wee hours of a morning.

If you have even more time, here is a video I had made after I gave a Keynote speech at an International conference that had happened in Kerala; south India in February 2020 It is much broader, and brings in social and economical aspects too:

C by carlopav on 11 Oct 2020, edited 11 Oct 2020 # +2 votes

Hello @Sabufrancis . I find the approach you and @brunopostle are exploring really inspiring. Hope to have some time to explore it soon. :)

At the moment just downloaded TAD.

Edit: this reminded me about https://www.goodreads.com/book/show/231678.Architecture_As_Space

S by Sabufrancis on 11 Oct 2020 # +1 votes

@carlopav said:

Hello @Sabufrancis . I find the approach you and @brunopostle are exploring really inspiring. Hope to have some time to explore it soon. :)

At the moment just downloaded TAD.

Thank you. I am grateful. If you have any issues when exploring TAD; please ask at our discussion forum at Discord. I or someone else over there may help you. You can contact e.young if I am not online.

Edit: this reminded me about https://www.goodreads.com/book/show/231678.Architecture_As_Space

Yes, that is a good book. Sometime in the late fifties. But it does not have anything much mathematical -- lot of evocative prose. I forgot the name of the book by Rob Krier -- if anyone knows where he had mentioned the same 3 categories of space; I would be grateful

P by paullee on 13 Oct 2020 #

@Sabufrancis Thanks for the detailed explanation and the videos, I finish the 1st one :)

Not sure if you have a look at 1st August Monthly Meetup and Discussion Thread on Talk on Topologic? and some other related discussion. Seems some conceptual similarity?. I have some initial idea how CellComplex concept in Topologic may initially work along in FreeCAD workflow. Probably representation in architectural magazine and available (computer) tools shapes how architects draws and develop designs but it is also intuitive to think about form before void (otherwise, nobody needs to keep reiterate concepts like 'figure-ground' etc. :D)

S by Sabufrancis on 13 Oct 2020 # +2 votes

@paullee said:

@Sabufrancis Thanks for the detailed explanation and the videos, I finish the 1st one :)

Not sure if you have a look at 1st August Monthly Meetup and Discussion Thread on Talk on Topologic? and some other related discussion. Seems some conceptual similarity?.

Yes, seems so. I am still looking at it -- The block for me currently is that Topologic seems to be a plugin for something else (Dynamo) and I am currently not equipped to handle that -- so I am going thru whatever that is available here and on their website. I will make more comments at those conversation threads at some point in time when I am confident that I have reasonably understood

Probably representation in architectural magazine and available (computer) tools shapes how architects draws and develop designs but it is also intuitive to think about form before void (otherwise, nobody needs to keep reiterate concepts like 'figure-ground' etc. :D)

Possibly true to some extent. The vision is a highly biasing sensation -- and the way vision works is to bounce light off built-matter. Hence it looks even more obvious. But this is the fragility of being a human. Jaques Derrida, the French linguist pointed out the nature of written communication. Whenever we encounter binaries we tend to lean towards one side and side-line the other. For example; ideally when describing what people do; ideally one should be referring to both the male AND female gender. But it is clumsy to write down a paragraph peppered with him/her, his/her, he/she and so on -- hence; for practical reason, we gravitate towards one of the genders -- usually the male

However, there are lots of architects who do start by "bubble-diagramming" (That is the term we use in India, possibly a legacy from the Britishers) where we diagram spatial relationships especially when one starts designing. Walls are almost never pointed out in that stage. If you had seen the video I had made referring to Sumerian clay tablets, I make claim to what i believe is a fact that people do recognize spaces. You can try this out yourself: Ask somebody not involved in computer graphics or in architecture (as they can come with their biases) to describe their own houses, and you will find that they will invariably point out those 3 "alphabets" I have tried this many times, and invariably they will actually delineate (albeit in a crude manner) those 3 kinds of spaces. So maybe those spatial intuitions get buried with formal learning ;-)

P by paullee on 13 Oct 2020 # +1 votes

Yes same, bubble diagram, since good old days in school. :D

S by Sabufrancis on 17 Oct 2020 # +5 votes

@paullee said:

Yes same, bubble diagram, since good old days in school. :D

Just in case you are interested in trying out TAD ... This video is a very easy introduction to TAD. It shows how you can rapidly sketch out a design. Please don't get the impression TAD does ONLY rectangles -- You can create practically any shapes, including those with curves but I haven't shown those commands here. When working with TAD, you get the logic of the objects correct. Once that is done, you can happily keep editing everything till your design is fully done. TAD can do all the objective calculations that you would need as you work, right across your design process. You can do lots of intense querying with its internal scripting system; as well as in other computer languages too.

You can work from very early stages of designing, all the way to how much ever detail you need. Then you can export all of that as DXF and do the final drawings in a suitable CAD software.

M by Moult on 18 Oct 2020 # +2 votes

Thank you for sharing your insights @Sabufrancis - I find that when working in Blender, I follow a very similar workflow. I start with modeling spaces, not walls. Walls are only added when the designs starts to mature. Blender has a Solidify modlfier, which allows walls to be auto generated around spaces, to help visualise both space and their envelopes when designing.

C by carlopav on 8 Dec 2020 #

Hello @Sabufrancis, inspired by your workflow and thoughts, I was thinking: have you ever considered about porting your workflow to a new FC workbench ? You have the possibility to write your own objects and take advantage of Opencascade technology for boolean operations and parametric shape modelling directly in 3d... And I think this could couple very well with @yorik Draft/Arch/BIM workbenches.

Also: do you think IFC can support the structure of the model you are using? IfcSpace seems quite matching with tad spaces, but what about connectors and building envelope?

P by paullee on 9 Dec 2020 #

Good suggestion :D

S by Sabufrancis on 9 Dec 2020, edited 9 Dec 2020 #

Thank you @carlopav and @paullee I am examining FC for sure. Actually, TAD went in quite a different direction ... not because I have any real problem with existing approaches to 3D modeling. It is not just the point of having IFCSpaces which can model some of the spaces in TAD. There are several other hiccups too, which I will try and explain.

(Note: I initially wrote all that here, but removed and am now writing an article at LinkedIn; as I think others may also need to know. I will provide the link to the LinkedIn article here soon)

Maybe I have got some misunderstanding; and so the article was more to clarify for myself ...

Regarding the suggestion to use FC; I am looking at its underlying principles of 3D geometry modeling. Some parts of are obviously very good, and uses recent mathematical algorithms and clever data structures.

But a lot of CAD and even BIM and even FC, frankly are all built on the top of earlier work of giants. Which is fine (and that is correct too), but we must remember that those earnest giants in the 50s and 60s were facing real hard problem in the hardware of computer, the tiny number of pixels on screens, etc. They had not yet reached real-world problems in one sense; as they were like old time car mechanics. They were under the car, with grease all over solving some really hard problems looking "bottom up" in more ways than one :-)

So I have great respect when they decide to chop up graphics to individual geometrical parts. Their logic was not of the real world logic we now discuss, but the headache of getting a very tiny computer and monitors to draw in the first place. They had no other choice!

But this resulted in some limitations in the legacy they passed on: There are many crufts of problems still around. Three main ones are: allowing ill-formed 3D objects, problem of parallax errors when doing 3D (Sketchup people often have unexplained headaches when they suddenly see some face going askew... All that can be traced to parallax errors; when editing ) and the philosophical problem of infinite regress when one tries to do one-to-one correspondence based modeling.

In short; I would love to have a separate workbench in FC as long as I am able to map the concepts in TAD into it very snugly. So far; I am still studying FC and I feel they are in a different direction. Impressive and powerful alright but still, in a different direction

C by carlopav on 9 Dec 2020 #

Well, also in FC there are different attempts to manage both bottom-up and top-down workflows in mechanics... If from one side you are right to point out the software is conceived around the Part and assembly approach, It Is also true that its geometry kernel Is not - as topologic proves - and the possibility to implement some completely custom objects sounds really exciting to explore a workflow that could combine conceptual elements with constructive ones... At least that's what i was thinking... :)

P by paullee on 10 Dec 2020 #

@Sabufrancis That's very true. I am not a programmer though I am trying to add some features to improve architecture workflow by working on an add-on/wb. I find Topologic and TAD has something similar, if i read it correctly, i.e. about creation of space as core concept / 1st step. I have been using Sketch in my experiment, and have been thinking to reconcile the concept of creation of space in same workflow ...