@topologic said:
Yes all possible through adding aperture faces to the CellComplex. I will let you explore that one on your own. ?
Probably needs a few more tips from you to move on testing :)
1. So should I in FC build Shell rather than Solid for each 'Cell', and then punch holes with the doors in the Faces of the Shell (Cell)
2. Topologic could identify a room / Cell from all those Faces even with with aperture (rather than Solid) ?
Thanks in advance for enlightening.
@paullee said:
Probably needs a few more tips from you to move on testing :)
1. So should I in FC build Shell rather than Solid for each 'Cell', and then punch holes with the doors in the Faces of the Shell (Cell)
Solids are fine. They became Cells in Topologic and I built a CellComplex out of them. I am talking about the ones you named Space. Do NOT punch holes. This is not how Topologic works. Instead add a zero thickness face representing the door coplanar with the wall it is supposed to sit within.
Topologic could identify a room / Cell from all those Faces even with with aperture (rather than Solid) ?
There are a couple of ways to build a CellComplex. You either build it by Cells that happen to touch each other. Or you can give it a whole group of faces that are intersecting and form closed volumes. Another way is to start with a large volume and set of faces that slice it.
So should I in FC build Shell rather than Solid for each 'Cell', and then punch holes with the doors in the Faces of the Shell (Cell)
Solids are fine. They became Cells in Topologic and I built a CellComplex out of them. I am talking about the ones you named Space. Do NOT punch holes. This is not how Topologic works. Instead add a zero thickness face representing the door coplanar with the wall it is supposed to sit within.
Hope I get it right currently:D Now, in FreeCAD it should be mostly automatic to create Space / Cell whilst architect draw Walls and create a Plane whilst adding Doors. See if you can have a look if the Solids and Planes in the Folder BldgPart__1F_Cells is what Topologic can understand, and create the 'bubble diagram' / graph representing the spatial relationship.
One additional question is what is proper way to model a flat roof space / terrace / courtyard in a building for Topologic to understand ? The 'Cell__1F_Room-008' is in fact a terrace on on a flat roof of the building.
As I say often, a cell in Topologic is space. It makes no assumption what that space is filled with: air, water, concrete, metal etc. So if you need to spatially compute “voids” then model them as cells as well.
I am tempted to work on the new model you provided, but I really think you should try to download Topologic and try it on your own and then ask questions. This is the way to move forward. Best wishes.
@topologic said:
As I say often, a cell in Topologic is space. It makes no assumption what that space is filled with: air, water, concrete, metal etc. So if you need to spatially compute “voids” then model them as cells as well.
Good to know that :D
I am tempted to work on the new model you provided, but I really think you should try to download Topologic and try it on your own and then ask questions. This is the way to move forward. Best wishes.
Indeed thanks taking so much time in answering all the questions. Had tried download but compiling is a real hurdle for me :oops The best thing for me for the moment is probably creating tools to automate generation of objects Topologic understand when modeling traditional Walls, Slabs, Doors
Looking forward to someone build complied Topologic package for use in FreeCAD + Linux hopefully in near future :D
Something different: about graphs and Co.. https://community.osarch.org/discussion/comment/6024#Comment_6024
Is topologic also good for this kind of mindmap/diagrams graphs? keep the relation intelligence between nodes. Topologic as a rdf/ontology/ifc organisation tool (before the geometry integration which is in fact what it is for..so kind of under-usage).
@lukas said:
Something different: about graphs and Co.. https://community.osarch.org/discussion/comment/6024#Comment_6024
Is topologic also good for this kind of mindmap/diagrams graphs? keep the relation intelligence between nodes. Topologic as a rdf/ontology/ifc organisation tool (before the geometry integration which is in fact what it is for..so kind of under-usage).
Topologic has a 'graph' class, and can embed dictionaries in its vertices and edges and do some computations on it (or augmented by extra python custom programming), but it does not have a full-fledged diagramming/mindmap functionality. @arquitextonica recently showed me how he is integrating yED (https://www.yworks.com/products/yed) with Topologic in Grasshopper.
@lukas said:
Something different: about graphs and Co.. https://community.osarch.org/discussion/comment/6024#Comment_6024
Is topologic also good for this kind of mindmap/diagrams graphs? keep the relation intelligence between nodes. Topologic as a rdf/ontology/ifc organisation tool (before the geometry integration which is in fact what it is for..so kind of under-usage).
Topologic has a nice Graph implementation, but it is very specialised - it is an undirected graph where every node has a position in 3D space, basically it is good for describing relations between 3D objects in space.
I have a crude GraphViz output from topologic Graph, this diagram represents the circulation graph of a single 3 storey building. I haven't indicated a distinction between 'cells' and 'faces' other than cells have a room 'usage' and faces have a 'style' (they are both shown as nodes since that is what they are). Note that this house layout is a failure because there is no way to get to the toilet:
[The text in the nodes is a dump of the Dictionary attached to the referenced Topology entity]
@topologic said:
The zoom recording is available on YouTube at:
I went thru this youtube and got a rough idea of what Topologic does. Let me see if I can summarize what I learnt: Topologic handles "cells" together and can detect some topological and graph properties using those cells. Such as detecting if two cells are adjacent or not, etc. Using that, it is possible to detect external surfaces and internal surfaces. The cells are guaranteed not to overlap.
Pardon my naive questions -- possibly others have asked these before. Pardon also asking questions from my jaundiced point of view of TAD
One question I have is that of logistics. What happens when the cells are not really cuboids? What kind of computational and memory complexity would one be dealing with then? For e.g. when the 6 surface-cell (cuboid) increases to say an "n" surface cell, what happens to the speed and storage requirement of computations such as adjacency determination? Are there are any test cases or mathematical calculations that can determine this? An allied question is, what happens when there are concave volumes?
It has been amply established in that video that Topologic is agnostic of what happens inside the cells. They are merely volumes -- and if one "pours" solidity into the cell then it represents built matter, else it represents spaces. That is what happens to volumes in TAD too. But are there any other underlying logic that reflects the "figure-ground" representational challenge that is seen in architecture? If not, what would be worst case scenarios?
I got the feeling that as there are no any data-attribute optimizing technique intrinsic in the underlying engine, it can easily create a "combinatorial explosion" as the design gets more and more embellished with properties. I did see somewhere in the video where additional properties were used used to enrich those cells. Are there any test cases that determine how many attributes can be added and how that would affect the speed and computation power requirement? (I know theoretically limitless attributes can be added, but I am talking more from a practical point of view of computer memory, etc)
There does not seem to be any much attempt to represent design in various states of "grey" -- architects do not tend to think in closely-coupled data structures. Instead our "data structure" that we hold in our mind as we start designing is one that is very loosely-coupled. That means, during the bubble-diagramming stages an architect can happily intersect two spatial volumes -- knowing very well that such intersecting volumes are illogical. I got the impression that Topologic was being portrayed as an early stage design tool and hence was looking out for this aspect and couldn't find anything much.
In early stages lots of haziness and illogical handling happens -- and gradually, over several iterations, the architect clarifies the design. For e.g. In one resort I was to do (it never got built for non-tech reasons) I was at that mountainous site for only a few hours. So I captured the various views I could get from the site: I was going around that site like a movie director holding up my fingers in front of me to frame various views. I modeled the "window openings" -- and they were like transparent cuboids hanging illogically in the air. Nothing else was modeled on that site. I returned back to the office and fleshed out the rest of the requirements that client needed. So here was a situation where a design started from a very unusual starting point: Illogical window openings hanging magically in the air. In fact, after having done hundreds of projects (large and small of all kinds of typologies) I am of the firm unshakeable opinion that one cannot dictate a systemic way how a design ought to start. Here I gave the example of a design that started due to the views that needed to be respected in the beautiful mountainous landscape around that project plot. In another design, the builder may be supremely focused on the municipality approvable floor areas and in another one it could be rough energy calculations and so on.
I got the feeling that possibly the use of parametric and shape generation techniques has certain disadvantages. I am not very much in favor of a generative approach to design systems, for the simple reason that the bye-product of any generative approach is that data structure necessarily becomes very closely coupled. I am then of the opinion that closely coupled data structures intrinsically do not allow haziness that is seen in the initial design process. TAD also does have some amount of parameterization (More can be done thru scripting and writing add-ons) but I introduced them only very hesitatingly and in very clear cut manner. I would love to know how generative strategies such as the one used in Topologic would really help even in early stages of design
@Sabufrancis Thank you for your comments. There is a lot of ground to cover, but while J understand your “jaundiced” point of view, I need to clarify a few things before answering some of your more specific questions:
Topologic is not commercial software. It is a research project that yielded a piece of open source and free software. This means I am happy for anyone to use it only if they find it useful.
Design as you said can start from various points. Again, if you find Topologic useful at your starting point or at any other point during your design process then that where it should be introduced. Topologic assumes that you want to use digital processes to represent your design and I think it is more suitable in the early phases, but others have used it in Revit/BIM analysis workflows.
Now to answer some questions:
Topologic represents more than cells: Vertex, Edge, Wire, Face, Shell, CellComplex, Cluster, Graph, Aperture, Content, Context, and Dictionary.
Topologic uses Opencascade, exactly like FreeCAD, ifcOpenShell, and BlenderBIM add on for Blender. As such, I am confident it can handle complex shapes. I demo cuboids because they are easy to create and simpler to understand.
Topologic has no limitation regarding convex and concave shapes. It also has no limitation regarding planar surfaces. Objects are breps and can be quite complex and include NURBS surfaces.
Your question regarding mathematical complexity is not something we addressed. We are not mathematicians so we did not have resources to carry out formal calculations. I would refer you to opencascade to see if they have any metrics
The dictionary class uses opencascade attribute system. So again, you can study that for any limitation. We simply rationalised it and did some interesting combinatorial work where Boolean operations affect and are affected by dictionaries. Obviously computer memory will always be a limiting factor, but it is so for Word and PowerPoint and AutoCAD. It is not a specific thing that limits Topologic. That said, there might be memory leaks due to bugs. We can never get it 100% perfect, but the source is available and anyone can suggest improvements and bug fixes.
While Topologic started within the generative and parametric world of Dynamo and Grasshopper, it is starting to move into the world of direct editing in Blender. However, I have also developed an initial version for sverchok that is proving to be very powerful. The reason is that I am striving for an end to end open source solution for Topologic.
Computer software and digital representation will never imitate the greyness of sketching and manual design, but there comes a point where knowledge, information, topology, logic, and geometry need to be represented. That is when J believe Topologic can help.
@JQL said:
Great! Fingers crossed. Would that have more probability to be usable by win users than topologic for freecad?
I am not sure. I think the main hurdle right now is that of lack of familiarity and a bit of "wait and see" attitude. Many people on twitter and here are very supportive and curious about Topologic, but have not yet downloaded it or tried it. It might be that the installation is more involved, but from what I have seen, not more involved than other open-source projects that need to be compiled from source. If you know what you are doing, it is of moderate difficulty to get it working. It is all on github (http://github.com/wassimj) with instructions for Linux, Windows, and Mac and it has been tested on Blender (python and sverchok), FreeCAD, and the python console on all three platforms. Sverchok is alpha software and has some bugs and limitations (I work on that daily and squash bugs on a continuous basis).
I had the idea it was only ready for linux. I'll check that.
EDIT:
Hi again Wassim,
I followed every step of your windows install instructions here: https://github.com/wassimj/topologicPy/blob/master/README-windows.md
But got to an error on step 9:
I don't want to give you too much trouble, but I'm in complete darkness at this point.
@topologic said:
I am not sure. I think the main hurdle right now is that of lack of familiarity and a bit of "wait and see" attitude. Many people on twitter and here are very supportive and curious about Topologic, but have not yet downloaded it or tried it. It might be that the installation is more involved, but from what I have seen, not more involved than other open-source projects that need to be compiled from source. If you know what you are doing, it is of moderate difficulty to get it working.
Compiling and understanding all the dependencies are hurdles for me. Though had been successful in a few time to compile FreeCAD with a few people's patient guidance, I had been using pre-compile AppImage on my Fedora for a few years and had been trying to assist by contributing simple python codes on github :D
Below is the problem at the moment -
No match for argument: libgl-dev
No match for argument: libglu-dev
No match for argument: libpng-dev
No match for argument: libxmu-dev
No match for argument: libxi-dev
No match for argument: libtbb-dev
No match for argument: tcl-dev
No match for argument: tk-dev
No match for argument: zlib1g-dev
No match for argument: libharfbuzz-dev
No match for argument: libfreetype-dev
No match for argument: libfreeimage-dev
No match for argument: libocct--dev
Error: Unable to find a match: libgl-dev libglu-dev libpng-dev libxmu-dev libxi-dev libtbb-dev tcl-dev tk-dev zlib1g-dev libharfbuzz-dev libfreetype-dev libfreeimage-dev libocct--dev
@brunopostle said: @paulee these are all names of Debian/Ubuntu packages. On fedora they would be -devel not -dev.
I assume you are looking to install opencascade-devel
Thanks taking time for the advice:D I followed the github's instruction though understanding it is not for fedora so simply replacing 'apt' with 'dnf'. Replacing '...dev' with '...devel' return below. I followed without knowing what exactly almost all and each package do. I have not included occt for the moment as I did something similar (ifc++ or ifcopenshell ?) and it was 1GB. And tracking down all the dependencies in previous attempt to compile other software (like FreeCAD), not to mention compatibilities problem, usually take me a numbers of days (w/ other's help) to finish if successful at the end or not :)
So what I am trying to do in parallel rather than compiling is to find in FC the simplest workflow to build the CellComplex for Topologic to work on in future :D
[paullee@f31 build]$ sudo dnf install bzip2 unzip cmake make g++ git libgl-devel libglu-devel libpng-devel libxmu-devel libxi-devel libtbb-devel tcl-devel tk-devel zlib1g-devel libharfbuzz-devel libfreetype-devel libfreeimage-devel
...
No match for argument: libglu-devel
Package libpng-devel-2:1.6.37-2.fc31.x86_64 is already installed.
No match for argument: libxmu-devel
* Maybe you meant: libXmu-devel
No match for argument: libxi-devel
* Maybe you meant: libXi-devel
No match for argument: libtbb-devel
No match for argument: zlib1g-devel
No match for argument: libharfbuzz-devel
No match for argument: libfreetype-devel
No match for argument: libfreeimage-devel
Error: Unable to find a match: libgl-devel libglu-devel libxmu-devel libxi-devel libtbb-devel zlib1g-devel libharfbuzz-devel libfreetype-devel libfreeimage-devel
Topologic is not commercial software. It is a research project that yielded a piece of open source and free software. This means I am happy for anyone to use it only if they find it useful.
I understand that. I have never been a pure researcher nor am I a pure practitioner either :-) We in India, have an interesting mythological story of Narasimha -- where the fragility of sharp boundaries are highlighted . (Here is an article I wrote on FB for my students about it https://www.facebook.com/sabufrancis/posts/10153842658865549) The real challenges are because of the boundaries we create in our knowledge. But then those challenges could get converted to opportunities too.
Design as you said can start from various points. Again, if you find Topologic useful at your starting point or at any other point during your design process then that where it should be introduced. Topologic assumes that you want to use digital processes to represent your design and I think it is more suitable in the early phases, but others have used it in Revit/BIM analysis workflows.
I understand that position. I was merely pointing out to the pragmatic architect who may not be so empathetic to the internal theories of such efforts. (I will attempt to address this later below, for another point)
Now to answer some questions:
Topologic represents more than cells: Vertex, Edge, Wire, Face, Shell, CellComplex, Cluster, Graph, Aperture, Content, Context, and Dictionary.
Topologic uses Opencascade, exactly like FreeCAD, ifcOpenShell, and BlenderBIM add on for Blender. As such, I am confident it can handle complex shapes. I demo cuboids because they are easy to create and simpler to understand.
Topologic has no limitation regarding convex and concave shapes. It also has no limitation regarding planar surfaces. Objects are breps and can be quite complex and include NURBS surfaces.
I would love to take a look at any examples that do not use cuboids. Even if the innards are not explained that is fine -- just the eventual output of complex real world geometries, and their practical use would really be very nice
Your question regarding mathematical complexity is not something we addressed. We are not mathematicians so we did not have resources to carry out formal calculations. I would refer you to opencascade to see if they have any metrics
I was looking for information along this lines: https://carlalexander.ca/what-is-software-complexity/ (I am not sure if that is an authoritative article, but there are many of that nature) There does not seem to be much mathematical training for such calculations. If such calculations are attempted in this project, it would really help as it can give confidence on what else that could be explored using Topologic. As this is open source, I am sure this is addressable by someone or the other.
The dictionary class uses opencascade attribute system. So again, you can study that for any limitation. We simply rationalised it and did some interesting combinatorial work where Boolean operations affect and are affected by dictionaries.
I've been following opencascade (and other such projects) for many years. What I find (and I hope I am not making a strawman argument here) is that much of the graphics data structures arose from the fact that the original pioneers were facing really hard problems in terms of computer resources (memory, etc) Those limitations gave the overarching direction on how the math of vector graphics proceeded. Those directions are still with us
In fact not just the math but even operational strategies -- there is this fascinating video on "Computerphile" Youtube channel (and other places) where one of the pioneers of Unix ( Brian Kernighan) methodically explains the procedure of using "pipelines" : Different utilities are piped together to give a huge amount of power both in terms of computation as well as data handling capability in those early days of highly limited resources. It is fascinating how they zeroed in on the correct way to slice and dice the problems they were facing. They got the "Narasimha" thresholds correctly.
I am of the opinion that when it comes to architecture; we need to first lay out what really is the challenge here. I always try to see if I am forcing the designer to slice and dice the data in ways that cannot later on be joined back to get back the holistic
Obviously computer memory will always be a limiting factor, but it is so for Word and PowerPoint and AutoCAD. It is not a specific thing that limits Topologic. That said, there might be memory leaks due to bugs. We can never get it 100% perfect, but the source is available and anyone can suggest improvements and bug fixes.
I get what you say -- but I meant something more nuanced. Even if there is not enough RAM there are surely data handling strategies that allow efficient handling of extremely large data -- for e.g. the column based database used by Google to handle the big-data search problem. Obviously, there is no computer on earth that can take in the entire Google search space into RAM and then zero in into the search the user asked for. Yet the job is done.
In my hunt for data structures; I have found that a proper OOPs based approach and a fractal-esque approach are the only two ways where one can achieve efficiency in handling really large data. (I am of course biased: TAD uses both)
Computer software and digital representation will never imitate the greyness of sketching and manual design, but there comes a point where knowledge, information, topology, logic, and geometry need to be represented. That is when J believe Topologic can help.
I understand this -- and I always struggle with the question myself on where the boundaries are; and how to negotiate those boundaries. I always end up questioning all reductionist approaches. Architecture is a "giant synthesis machine" -- The architecture around us holistically provides the context for each instance of our experience. Basically things are quite stickily connected to each other and to capture that "sticky connections" adequately and "manageably" inside a representational model is important.
The reason I keep asking questions of such nature, and the need of preserving the holistic as much as possible is this: Today, much of the ideal pursuits in the modeling of the built environment (sustainability, carbon footprint, energy consumption, global warming, etc) are not getting done possibly because where the tyre hits the road (i.e. where the practical architect actually gets down to designing) he or she is facing a tug-of-war in many areas.
For e.g. If there is a modeling system that is good at doing some calculations on sustainability, the same system may go against some other goals that the architect wants -- maybe aesthetics, maybe acoustics ... maybe things that arose in that specific project just in time (such as the ones i faced in that mountain resort). I therefore felt that if all I thought was that let me handle at least part of the problem well -- then the question ends up "Who will define that part? Where should the model be cleaved?" And then I am again facing the same problem of multiple modeling methods all over. Instead, I used a different technique: Have a holsitic "fountainhead" of a model -- and from there let each goal get met.
As I said earlier; I am not really a pure theoretician and nor am I a pure whatever ... but I do feel it is important to keep this point alive in the minds of those who have the time, money and energy in delving deep into architecture modeling. (Kindly pardon my pedantry... been teaching for many years)
@Sabufrancis Very interesting points. I am quite busy these days, but here is an example of a non-cuboid in Topologic. This is the result of intersecting two Cells with NURBS surfaces resulting in a third Cell with NURBS surfaces. While Topologic is fully capable of this using Dynamo and Grasshopper, I don't yet have the code to convert Blender NURBS to Topologic. However, if you create such an object as a Part/Shape in FreeCAD, it will be 100% identical in Topologic (because as I said, Topologic uses OCCT same as FreeCAD). For Blender and sverchok, I am only dealing with planar surfaces for the time being until I find time to understand how NURBS work and translate them to their equivalent Topologic entities.
May I suggest that installation issues are sent to the GitHub issues rather than here? I think this forum is better suited for discussing ideas than for debugging. Also, for issues with installing 3rd party software such as cppyy, they have their own GitHub and can help you if you face issues.
@topologic said:
May I suggest that installation issues are sent to the GitHub issues rather than here? I think this forum is better suited for discussing ideas than for debugging. Also, for issues with installing 3rd party software such as cppyy, they have their own GitHub and can help you if you face issues.
Agreed, would transfer transferred to github soon :D
For any potential user of FreeCAD (AppImage) + Fedora (31), TopologicPy seems works after more than a weeks trial and error most importantly helps from e.g. Dr and wlav at github / bitbucket. Would try to find documents to see how to use TopologicPy without visual tools :D
Comments
This is amazing work. Kudos. Let me know when I can help on how to call the BlenderBIM Add-on for any IFC manipulation needs.
Thanks, I definitely will.
Probably needs a few more tips from you to move on testing :)
1. So should I in FC build Shell rather than Solid for each 'Cell', and then punch holes with the doors in the Faces of the Shell (Cell)
2. Topologic could identify a room / Cell from all those Faces even with with aperture (rather than Solid) ?
Thanks in advance for enlightening.
Solids are fine. They became Cells in Topologic and I built a CellComplex out of them. I am talking about the ones you named Space. Do NOT punch holes. This is not how Topologic works. Instead add a zero thickness face representing the door coplanar with the wall it is supposed to sit within.
There are a couple of ways to build a CellComplex. You either build it by Cells that happen to touch each other. Or you can give it a whole group of faces that are intersecting and form closed volumes. Another way is to start with a large volume and set of faces that slice it.
No problem
Hope I get it right currently:D Now, in FreeCAD it should be mostly automatic to create Space / Cell whilst architect draw Walls and create a Plane whilst adding Doors. See if you can have a look if the Solids and Planes in the Folder BldgPart__1F_Cells is what Topologic can understand, and create the 'bubble diagram' / graph representing the spatial relationship.
One additional question is what is proper way to model a flat roof space / terrace / courtyard in a building for Topologic to understand ? The 'Cell__1F_Room-008' is in fact a terrace on on a flat roof of the building.
Thanks again !
As I say often, a cell in Topologic is space. It makes no assumption what that space is filled with: air, water, concrete, metal etc. So if you need to spatially compute “voids” then model them as cells as well.
I am tempted to work on the new model you provided, but I really think you should try to download Topologic and try it on your own and then ask questions. This is the way to move forward. Best wishes.
Good to know that :D
Indeed thanks taking so much time in answering all the questions. Had tried download but compiling is a real hurdle for me :oops The best thing for me for the moment is probably creating tools to automate generation of objects Topologic understand when modeling traditional Walls, Slabs, Doors
Looking forward to someone build complied Topologic package for use in FreeCAD + Linux hopefully in near future :D
Something different: about graphs and Co.. https://community.osarch.org/discussion/comment/6024#Comment_6024
Is topologic also good for this kind of mindmap/diagrams graphs? keep the relation intelligence between nodes. Topologic as a rdf/ontology/ifc organisation tool (before the geometry integration which is in fact what it is for..so kind of under-usage).
Topologic has a 'graph' class, and can embed dictionaries in its vertices and edges and do some computations on it (or augmented by extra python custom programming), but it does not have a full-fledged diagramming/mindmap functionality. @arquitextonica recently showed me how he is integrating yED (https://www.yworks.com/products/yed) with Topologic in Grasshopper.
Topologic has a nice Graph implementation, but it is very specialised - it is an undirected graph where every node has a position in 3D space, basically it is good for describing relations between 3D objects in space.
I have a crude GraphViz output from topologic Graph, this diagram represents the circulation graph of a single 3 storey building. I haven't indicated a distinction between 'cells' and 'faces' other than cells have a room 'usage' and faces have a 'style' (they are both shown as nodes since that is what they are). Note that this house layout is a failure because there is no way to get to the toilet:
[The text in the nodes is a dump of the Dictionary attached to the referenced Topology entity]
I went thru this youtube and got a rough idea of what Topologic does. Let me see if I can summarize what I learnt: Topologic handles "cells" together and can detect some topological and graph properties using those cells. Such as detecting if two cells are adjacent or not, etc. Using that, it is possible to detect external surfaces and internal surfaces. The cells are guaranteed not to overlap.
Pardon my naive questions -- possibly others have asked these before. Pardon also asking questions from my jaundiced point of view of TAD
One question I have is that of logistics. What happens when the cells are not really cuboids? What kind of computational and memory complexity would one be dealing with then? For e.g. when the 6 surface-cell (cuboid) increases to say an "n" surface cell, what happens to the speed and storage requirement of computations such as adjacency determination? Are there are any test cases or mathematical calculations that can determine this? An allied question is, what happens when there are concave volumes?
It has been amply established in that video that Topologic is agnostic of what happens inside the cells. They are merely volumes -- and if one "pours" solidity into the cell then it represents built matter, else it represents spaces. That is what happens to volumes in TAD too. But are there any other underlying logic that reflects the "figure-ground" representational challenge that is seen in architecture? If not, what would be worst case scenarios?
I got the feeling that as there are no any data-attribute optimizing technique intrinsic in the underlying engine, it can easily create a "combinatorial explosion" as the design gets more and more embellished with properties. I did see somewhere in the video where additional properties were used used to enrich those cells. Are there any test cases that determine how many attributes can be added and how that would affect the speed and computation power requirement? (I know theoretically limitless attributes can be added, but I am talking more from a practical point of view of computer memory, etc)
There does not seem to be any much attempt to represent design in various states of "grey" -- architects do not tend to think in closely-coupled data structures. Instead our "data structure" that we hold in our mind as we start designing is one that is very loosely-coupled. That means, during the bubble-diagramming stages an architect can happily intersect two spatial volumes -- knowing very well that such intersecting volumes are illogical. I got the impression that Topologic was being portrayed as an early stage design tool and hence was looking out for this aspect and couldn't find anything much.
In early stages lots of haziness and illogical handling happens -- and gradually, over several iterations, the architect clarifies the design. For e.g. In one resort I was to do (it never got built for non-tech reasons) I was at that mountainous site for only a few hours. So I captured the various views I could get from the site: I was going around that site like a movie director holding up my fingers in front of me to frame various views. I modeled the "window openings" -- and they were like transparent cuboids hanging illogically in the air. Nothing else was modeled on that site. I returned back to the office and fleshed out the rest of the requirements that client needed. So here was a situation where a design started from a very unusual starting point: Illogical window openings hanging magically in the air. In fact, after having done hundreds of projects (large and small of all kinds of typologies) I am of the firm unshakeable opinion that one cannot dictate a systemic way how a design ought to start. Here I gave the example of a design that started due to the views that needed to be respected in the beautiful mountainous landscape around that project plot. In another design, the builder may be supremely focused on the municipality approvable floor areas and in another one it could be rough energy calculations and so on.
@Sabufrancis Thank you for your comments. There is a lot of ground to cover, but while J understand your “jaundiced” point of view, I need to clarify a few things before answering some of your more specific questions:
Now to answer some questions:
Topologic represents more than cells: Vertex, Edge, Wire, Face, Shell, CellComplex, Cluster, Graph, Aperture, Content, Context, and Dictionary.
Topologic uses Opencascade, exactly like FreeCAD, ifcOpenShell, and BlenderBIM add on for Blender. As such, I am confident it can handle complex shapes. I demo cuboids because they are easy to create and simpler to understand.
Topologic has no limitation regarding convex and concave shapes. It also has no limitation regarding planar surfaces. Objects are breps and can be quite complex and include NURBS surfaces.
Your question regarding mathematical complexity is not something we addressed. We are not mathematicians so we did not have resources to carry out formal calculations. I would refer you to opencascade to see if they have any metrics
The dictionary class uses opencascade attribute system. So again, you can study that for any limitation. We simply rationalised it and did some interesting combinatorial work where Boolean operations affect and are affected by dictionaries. Obviously computer memory will always be a limiting factor, but it is so for Word and PowerPoint and AutoCAD. It is not a specific thing that limits Topologic. That said, there might be memory leaks due to bugs. We can never get it 100% perfect, but the source is available and anyone can suggest improvements and bug fixes.
While Topologic started within the generative and parametric world of Dynamo and Grasshopper, it is starting to move into the world of direct editing in Blender. However, I have also developed an initial version for sverchok that is proving to be very powerful. The reason is that I am striving for an end to end open source solution for Topologic.
Computer software and digital representation will never imitate the greyness of sketching and manual design, but there comes a point where knowledge, information, topology, logic, and geometry need to be represented. That is when J believe Topologic can help.
Just to add that representing solids vs voids is easily handled by a dictionary attribute in Topologic similar to any other CAD system.
Great! Fingers crossed. Would that have more probability to be usable by win users than topologic for freecad?
I am not sure. I think the main hurdle right now is that of lack of familiarity and a bit of "wait and see" attitude. Many people on twitter and here are very supportive and curious about Topologic, but have not yet downloaded it or tried it. It might be that the installation is more involved, but from what I have seen, not more involved than other open-source projects that need to be compiled from source. If you know what you are doing, it is of moderate difficulty to get it working. It is all on github (http://github.com/wassimj) with instructions for Linux, Windows, and Mac and it has been tested on Blender (python and sverchok), FreeCAD, and the python console on all three platforms. Sverchok is alpha software and has some bugs and limitations (I work on that daily and squash bugs on a continuous basis).
I had the idea it was only ready for linux. I'll check that.
EDIT:
Hi again Wassim,
I followed every step of your windows install instructions here:
https://github.com/wassimj/topologicPy/blob/master/README-windows.md
But got to an error on step 9:
I don't want to give you too much trouble, but I'm in complete darkness at this point.
@JQL please post this on GitHub issues. I’ll take a look tomorrow.
Compiling and understanding all the dependencies are hurdles for me. Though had been successful in a few time to compile FreeCAD with a few people's patient guidance, I had been using pre-compile AppImage on my Fedora for a few years and had been trying to assist by contributing simple python codes on github :D
Below is the problem at the moment -
@paulee these are all names of Debian/Ubuntu packages. On fedora they would be -devel not -dev.
I assume you are looking to install opencascade-devel
Thanks taking time for the advice:D I followed the github's instruction though understanding it is not for fedora so simply replacing 'apt' with 'dnf'. Replacing '...dev' with '...devel' return below. I followed without knowing what exactly almost all and each package do. I have not included occt for the moment as I did something similar (ifc++ or ifcopenshell ?) and it was 1GB. And tracking down all the dependencies in previous attempt to compile other software (like FreeCAD), not to mention compatibilities problem, usually take me a numbers of days (w/ other's help) to finish if successful at the end or not :)
So what I am trying to do in parallel rather than compiling is to find in FC the simplest workflow to build the CellComplex for Topologic to work on in future :D
@paullee This should work to build the TopologicCore library on fedora:
This will likely install the library and headers to
/usr/localso unless you have already edited your library path you need to do something like this:I understand that. I have never been a pure researcher nor am I a pure practitioner either :-) We in India, have an interesting mythological story of Narasimha -- where the fragility of sharp boundaries are highlighted . (Here is an article I wrote on FB for my students about it https://www.facebook.com/sabufrancis/posts/10153842658865549) The real challenges are because of the boundaries we create in our knowledge. But then those challenges could get converted to opportunities too.
I understand that position. I was merely pointing out to the pragmatic architect who may not be so empathetic to the internal theories of such efforts. (I will attempt to address this later below, for another point)
I would love to take a look at any examples that do not use cuboids. Even if the innards are not explained that is fine -- just the eventual output of complex real world geometries, and their practical use would really be very nice
I was looking for information along this lines: https://carlalexander.ca/what-is-software-complexity/ (I am not sure if that is an authoritative article, but there are many of that nature) There does not seem to be much mathematical training for such calculations. If such calculations are attempted in this project, it would really help as it can give confidence on what else that could be explored using Topologic. As this is open source, I am sure this is addressable by someone or the other.
I've been following opencascade (and other such projects) for many years. What I find (and I hope I am not making a strawman argument here) is that much of the graphics data structures arose from the fact that the original pioneers were facing really hard problems in terms of computer resources (memory, etc) Those limitations gave the overarching direction on how the math of vector graphics proceeded. Those directions are still with us
In fact not just the math but even operational strategies -- there is this fascinating video on "Computerphile" Youtube channel (and other places) where one of the pioneers of Unix ( Brian Kernighan) methodically explains the procedure of using "pipelines" : Different utilities are piped together to give a huge amount of power both in terms of computation as well as data handling capability in those early days of highly limited resources. It is fascinating how they zeroed in on the correct way to slice and dice the problems they were facing. They got the "Narasimha" thresholds correctly.
I am of the opinion that when it comes to architecture; we need to first lay out what really is the challenge here. I always try to see if I am forcing the designer to slice and dice the data in ways that cannot later on be joined back to get back the holistic
I get what you say -- but I meant something more nuanced. Even if there is not enough RAM there are surely data handling strategies that allow efficient handling of extremely large data -- for e.g. the column based database used by Google to handle the big-data search problem. Obviously, there is no computer on earth that can take in the entire Google search space into RAM and then zero in into the search the user asked for. Yet the job is done.
In my hunt for data structures; I have found that a proper OOPs based approach and a fractal-esque approach are the only two ways where one can achieve efficiency in handling really large data. (I am of course biased: TAD uses both)
I understand this -- and I always struggle with the question myself on where the boundaries are; and how to negotiate those boundaries. I always end up questioning all reductionist approaches. Architecture is a "giant synthesis machine" -- The architecture around us holistically provides the context for each instance of our experience. Basically things are quite stickily connected to each other and to capture that "sticky connections" adequately and "manageably" inside a representational model is important.
The reason I keep asking questions of such nature, and the need of preserving the holistic as much as possible is this: Today, much of the ideal pursuits in the modeling of the built environment (sustainability, carbon footprint, energy consumption, global warming, etc) are not getting done possibly because where the tyre hits the road (i.e. where the practical architect actually gets down to designing) he or she is facing a tug-of-war in many areas.
For e.g. If there is a modeling system that is good at doing some calculations on sustainability, the same system may go against some other goals that the architect wants -- maybe aesthetics, maybe acoustics ... maybe things that arose in that specific project just in time (such as the ones i faced in that mountain resort). I therefore felt that if all I thought was that let me handle at least part of the problem well -- then the question ends up "Who will define that part? Where should the model be cleaved?" And then I am again facing the same problem of multiple modeling methods all over. Instead, I used a different technique: Have a holsitic "fountainhead" of a model -- and from there let each goal get met.
As I said earlier; I am not really a pure theoretician and nor am I a pure whatever ... but I do feel it is important to keep this point alive in the minds of those who have the time, money and energy in delving deep into architecture modeling. (Kindly pardon my pedantry... been teaching for many years)
@Sabufrancis Very interesting points. I am quite busy these days, but here is an example of a non-cuboid in Topologic. This is the result of intersecting two Cells with NURBS surfaces resulting in a third Cell with NURBS surfaces. While Topologic is fully capable of this using Dynamo and Grasshopper, I don't yet have the code to convert Blender NURBS to Topologic. However, if you create such an object as a Part/Shape in FreeCAD, it will be 100% identical in Topologic (because as I said, Topologic uses OCCT same as FreeCAD). For Blender and sverchok, I am only dealing with planar surfaces for the time being until I find time to understand how NURBS work and translate them to their equivalent Topologic entities.
Thanks! This should be included in the original github Readme ? :D
Maybe below warning shoud be discussed in github ?
oops:
Installing cppyy ...
May I suggest that installation issues are sent to the GitHub issues rather than here? I think this forum is better suited for discussing ideas than for debugging. Also, for issues with installing 3rd party software such as cppyy, they have their own GitHub and can help you if you face issues.
Agreed, would transfer transferred to github soon :D
Just thought I'd share the latest progress here on Topologic Sverchok:
https://youtu.be/zN_fTeuIuXM
And this is if you are tired of cubes: https://youtu.be/bGpb0vMbuoA
For any potential user of FreeCAD (AppImage) + Fedora (31), TopologicPy seems works after more than a weeks trial and error most importantly helps from e.g. Dr and wlav at github / bitbucket. Would try to find documents to see how to use TopologicPy without visual tools :D