OSArch Community

1st August 20:00 UTC Monthly Meetup

  1. T by topologic on 2 Aug 2020, edited 2 Aug 2020 # +2 votes

    I think this thread shows exactly the pitfalls of trying to go from a BIM model to a conceptual model. One possible solution perhaps is to look at the spatial relationship information (if it exists -- eg. this door belongs on Wall A and connects room B to room C), and largely ignore the idiosyncratic geometry (but I don't yet see good ways of doing that). You can probably build the conceptual dual graph, but the actual CellComplex might still fail.

    This approach will always have caveats and sources of error. The truth of the matter is, BIM models such as the one above are not created from a conceptual point of view. BIM software does not require nor impose restrictions on spatial relationships. Nor does it have the depth of implementation to focus on more important spaces and ignore or trim away less important ones. I believe it is a losing battle. There will always be those who will tell me, "but I have hundreds of BIM models that I want to analyse." Sadly the solution will be bespoke and imperfect in many cases.

  1. P by paullee on 2 Aug 2020 #

    I am not sure what architects feel about the Topologic2FreeCAD route, any comments :)

    I am thinking a workflow this can be done somehow efficiently in FreeCAD :-

    • Sometime clients provide some bubble diagrams illustrating the spatial relationship of the accommodations

    • Maybe a numbers of dummy ArchSpace + dummy Doors / Connection Objects could be made like the sample model above just to match the bubble diagrams / make dual graph

    • ( Better still, if this kind of bubble diagram is some kind of Graph or Chart, that it can be translated automagically into the series of dummy ArchSpace + dummy Connection Object by a script ...)

    • Then, Walls are drawn to define rooms, and these are assigned to each of the ArchSpace; and likewise for Doors ... until all ArchSpace (required accommodation) and connection (Doors) are created to match the graph

    To this end, a few issues maybe worth further discussion :-

    • The area of room resulted are usually worth checking to verify it meets client's requirement. That's one use of ArchSpace in FC.

    • But sometimes the floor layout is complicated that a numbers of walls define an irregular room, take Villa Savoye as an example

    • (ArchSpace may then also can have Attributes, e.g. Required Area for the space the client requests for ease of checking ? ...)

    • Then, a lot of time, the spatial relationship of client's bubble diagram is volatile. I am not sure if the Villa Savoye Spatial relationship is driven by clients or the architect (or at least not contravening client's concept?)

  1. P by paullee on 3 Aug 2020, edited 3 Aug 2020 # +1 votes

    Hi @topologic, I try to do some mock-up of Spatial Order to BIM workflow, see how it sounds to you.

    1. With ArchSpace Only

    • To start with, there is no ArchWall, Slab, Roof etc. Just 2 Spaces and 2 doors (maybe some kind of 'Connection Object' instead ?).

    • As the final ArchSpace represent the void of the room at later stage, 2 'adjacent cells' do not share a common surface - querying adjacent cells in Topologic may fails ?

    • Apparently, this workflow does not make use of the Topologic.ByGeometry in general

    • Door/Connection - - - Room 01 - - - Door/Connection - - - Room 02

    2. With Geometry of 2 Cells

    • There is only a compound of shells / surfaces forming 2 'Cells'

    • Apparently there is no ArchSpace - only pure geometry - have no idea how to put no semantic meaning e.g. room names for the 2 Cells

    • And have no idea how to put a Door / 'Connection' between 2 Cells

    Thanks

  1. P by paullee on 5 Aug 2020, edited 6 Aug 2020 # +1 votes

    Hi @topologic

    Have attempted another workflow that streamline the generation of the 'CellComplex' suited for Topologic Workflow and the general Architectural Worflow.

    Now, can have ArchSpace which share common surface between adjacent Rooms - just like the CellComplex

    The ArchSpaces are now created just like a Conceptual Volume - not the actual void of the rooms, so the volume does not represent the actual physical room.

    [re-post file]

  1. P by paullee on 9 Aug 2020 # +3 votes
  1. P by paullee on 16 Aug 2020 #
  1. M by Moult on 16 Aug 2020 # +1 votes

    It seems as though the biggest problem is @topologic 's dependency on .NET. It's theoretically cross-platform, but in practice it's quite Windows-centric and a pain elsewhere.

  1. T by topologic on 16 Aug 2020 # +1 votes

    @Moult said:

    It seems as though the biggest problem is @topologic 's dependency on .NET. It's theoretically cross-platform, but in practice it's quite Windows-centric and a pain elsewhere.

    The reason I approached this community was to see if there is anyone with the expertise and willingness to look at the C++ TopologicCore and port it to other platforms. Theoretically, Topologic has exactly the same dependency on OCCT (and no other library). So it should be feasible to compile just TopologicCore on Linux for example. But we need someone with time and expertise willing to step up and do it.

  1. B by brunopostle on 16 Aug 2020 # +4 votes

    @topologic said:

    The reason I approached this community was to see if there is anyone with the expertise and willingness to look at the C++ TopologicCore and port it to other platforms. Theoretically, Topologic has exactly the same dependency on OCCT (and no other library). So it should be feasible to compile just TopologicCore on Linux for example. But we need someone with time and expertise willing to step up and do it.

    OK, had a quick go and I can compile libTopologicCore.so using a cmake build created using cmakeconverter.

    • I had to add some missing #include statements.

    • There are lots of VC usages of std::exception() which I replaced with std::runtime_error()

    • There were a couple of C++ namespace things that I might have fixed correctly (I'm really not a C++ coder)

    • There were a few lines that I commented out completely, I don't know what this code is trying to do:error: conversion from ‘handle<Geom_BSplineCurve>’ to non-scalar type ‘handle<Geom_Curve>’ requested

    • It could use some cmake niceties, I hard-coded /usr/include/opencascade for example

    • It looks that it may be possible to compile some other libraries: TopologicEnergy and TopologicStructure maybe?

    I'm guessing compiling is the easy bit, probably this needs a SWIG python library to be useful.

  1. B by brunopostle on 16 Aug 2020, edited 16 Aug 2020 # +2 votes

    I have a ceiling to paint! Here are a couple of patches if anyone else wants to try this, they should apply to the master branch of Topologic

    @paullee

  1. P by paullee on 16 Aug 2020 # +1 votes

    @brunopostle

    Thanks for your efforts :D

    Being merely a beginner in Python, could only help to test or explore the worflow as an architectural practitioner :p Hope this works out and more peoples can help in various aspects.

  1. T by topologic on 16 Aug 2020 # +3 votes

    @brunopostle said:

    OK, had a quick go and I can compile libTopologicCore.so using a cmake build created using cmakeconverter.

    • I had to add some missing #include statements.

    • There are lots of VC usages of std::exception() which I replaced with std::runtime_error()

    • There were a couple of C++ namespace things that I might have fixed correctly (I'm really not a C++ coder)

    • There were a few lines that I commented out completely, I don't know what this code is trying to do:error: conversion from ‘handle<Geom_BSplineCurve>’ to non-scalar type ‘handle<Geom_Curve>’ requested

    • It could use some cmake niceties, I hard-coded /usr/include/opencascade for example

    • It looks that it may be possible to compile some other libraries: TopologicEnergy and TopologicStructure maybe?

    I'm guessing compiling is the easy bit, probably this needs a SWIG python library to be useful.

    Thanks @brunopostle! I do not recommend dealing with TopologicEnergy and especially not TopologicStructure. I will let the original developer know about these glitches. Perhaps he can find the time to patch them and update the software on github.

  1. M by Moult on 16 Aug 2020 # +4 votes

    @brunopostle fantastic work! Agree that SWIG is needed. After this is solved, there still needs to be builds provided (in particular OSX could be a little tricky as you need Mac hardware) and only then can it be integrated in to UIs like Blender / FreeCAD easily.

  1. P by paullee on 19 Aug 2020 #
  1. B by brunopostle on 19 Aug 2020 # +1 votes

    @paullee the next step is to create a SWIG wrapper for Topologic, this makes the C++ library available as a normal python library.

    This isn't especially difficult, it just requires a bit of understanding of python and C++, but more importantly you need to have some idea of how Topologic wants to be used. Particularly understanding how the existing opencascade python library exposes geometry, so that the new python library is complementary to this.

    Note that freecad seems to have two ways of accessing opencascade.

    @topologic do you want me to break those patches up into smaller chunks? They are currently a mixture of lots of obviously correct changes, and a handful of hacks that need a bit of more work by somebody who knows the code.

  1. B by brunopostle on 19 Aug 2020 # +1 votes
  1. T by topologic on 19 Aug 2020 # +1 votes

    @brunopostle said:

    @topologic do you want me to break those patches up into smaller chunks? They are currently a mixture of lots of obviously correct changes, and a handful of hacks that need a bit of more work by somebody who knows the code.

    Yes that would be very helpful. Also if you send me the so file, perhaps I can experiment with it. I already sent your patches to the original developer, but sadly he is not responding.

    I imagine a topologic workbench in FreeCAD that would offer the same methods as it does within Dynamo and Grasshopper. We have been able to build interesting spatial analysis workflows with it. As to interfacing with opencascade geometry, it should be very easy as topologic uses the native geometry. Plus we have import/export of brep built in. Thanks again everyone for continuing to push this forward.

  1. B by brunopostle on 19 Aug 2020 # +1 votes

    @topologic said:

    @brunopostle said:

    @topologic do you want me to break those patches up into smaller chunks? They are currently a mixture of lots of obviously correct changes, and a handful of hacks that need a bit of more work by somebody who knows the code.

    Yes that would be very helpful. Also if you send me the so file, perhaps I can experiment with it.

    @topologic you can apply these patches with patch -p1 < patchfilename

    • topologic-cmake.patch This just adds six files for a basic cmake build system, it won't affect the existing VC build (this cmake system needs some work, it doesn't have an install target or detection of include paths, but it is good enough to start with).

    • topologic-include.patch This adds some missing standard C library #include statements, this shouldn't cause any problems either.

    • topologic-exception.patch This is a big patch, it replaces all the calls to std::exception() with std::runtime_error() because only VC lets you pass a string to std::exception() - you need to check that error messages still do what they are supposed to do on Windows.

    • topologic-dllexport.patch This just puts dllexport and dllimport inside an #ifdef WIN32 as these mean nothing on Linux - however I'm not 100% sure if WIN32 is defined in VC, so you do need to check this still works on Windows.

    • topologic-gcc.patch This fixes some namespace issues, though this needs confirmation from a real C++ programmer that I have actually done the right thing.

    • topologic-misc.patch This comments out two bits of code that I don't understand, which don't compile and which may be bugs, someone who understands this codebase needs to fix this. The error is error: conversion from ‘handle<Geom_BSplineCurve>’ to non-scalar type ‘handle<Geom_Curve>’ requested

    (I can send you the .so file though I'm not sure it is suitably portable)

  1. P by paullee on 19 Aug 2020 #

    Sorry I can't make sense of the programming discussion above :oops

    It seems it is a lots of works. Hope @nmt in FC may join this effort to make things easier :)

  1. T by topologic on 25 Aug 2020 # +5 votes

    Dear @brunopostle The developer has informed me that he has implemented all the patches and updated the source code on github! Thank you very much for your help with these. If you have any extra time, it would be fantastic if you can confirm that indeed the code now works and can be easily compiled on Linux.

  1. B by brunopostle on 25 Aug 2020 # +3 votes

    @topologic it now builds ok here:

    git clone https://github.com/NonManifoldTopology/Topologic.git

    cd Topologic

    mkdir BUILD

    cd BUILD

    cmake ..

    make

    ldd TopologicCore/libTopologicCore.so

    linux-vdso.so.1 (0x00007fff37984000)

libTKCAF.so.7 => /lib64/libTKCAF.so.7 (0x00007f65584d8000)

libTKLCAF.so.7 => /lib64/libTKLCAF.so.7 (0x00007f65583e8000)

libTKOffset.so.7 => /lib64/libTKOffset.so.7 (0x00007f6558238000)

libTKIGES.so.7 => /lib64/libTKIGES.so.7 (0x00007f6557dd8000)

libTKPrim.so.7 => /lib64/libTKPrim.so.7 (0x00007f6557d60000)

libTKMesh.so.7 => /lib64/libTKMesh.so.7 (0x00007f6557c70000)

libTKXSBase.so.7 => /lib64/libTKXSBase.so.7 (0x00007f65579a8000)

libTKBool.so.7 => /lib64/libTKBool.so.7 (0x00007f6557538000)

libTKBO.so.7 => /lib64/libTKBO.so.7 (0x00007f6557290000)

libTKShHealing.so.7 => /lib64/libTKShHealing.so.7 (0x00007f6556fb8000)

libTKG3d.so.7 => /lib64/libTKG3d.so.7 (0x00007f6556e70000)

libTKG2d.so.7 => /lib64/libTKG2d.so.7 (0x00007f6556e08000)

libTKGeomBase.so.7 => /lib64/libTKGeomBase.so.7 (0x00007f65568a0000)

libTKGeomAlgo.so.7 => /lib64/libTKGeomAlgo.so.7 (0x00007f6556280000)

libTKTopAlgo.so.7 => /lib64/libTKTopAlgo.so.7 (0x00007f6555f50000)

libTKernel.so.7 => /lib64/libTKernel.so.7 (0x00007f6555d78000)

libTKMath.so.7 => /lib64/libTKMath.so.7 (0x00007f6555ab8000)

libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f6555aa8000)

libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f65558b8000)

libm.so.6 => /lib64/libm.so.6 (0x00007f6555770000)

libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f6555750000)

libc.so.6 => /lib64/libc.so.6 (0x00007f6555580000)

libTKCDF.so.7 => /lib64/libTKCDF.so.7 (0x00007f6555520000)

libTKBRep.so.7 => /lib64/libTKBRep.so.7 (0x00007f6555418000)

libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f65553f0000)

libtbb.so.2 => /lib64/libtbb.so.2 (0x00007f65553a8000)

libtbbmalloc.so.2 => /lib64/libtbbmalloc.so.2 (0x00007f6555360000)

libdl.so.2 => /lib64/libdl.so.2 (0x00007f6555358000)

/lib64/ld-linux-x86-64.so.2 (0x00007f6558818000)

    Note that the cmake system still needs a little bit of tweaking so that it works on all platforms, it is also missing an install target, these are probably straightforward fixes.

  1. T by topologic on 26 Aug 2020 # +3 votes

    @brunopostle said:

    @topologic it now builds ok here:

    git clone https://github.com/NonManifoldTopology/Topologic.git

    cd Topologic

    mkdir BUILD

    cd BUILD

    cmake ..

    make

    ldd TopologicCore/libTopologicCore.so

    linux-vdso.so.1 (0x00007fff37984000)

    libTKCAF.so.7 => /lib64/libTKCAF.so.7 (0x00007f65584d8000)

    libTKLCAF.so.7 => /lib64/libTKLCAF.so.7 (0x00007f65583e8000)

    libTKOffset.so.7 => /lib64/libTKOffset.so.7 (0x00007f6558238000)

    libTKIGES.so.7 => /lib64/libTKIGES.so.7 (0x00007f6557dd8000)

    libTKPrim.so.7 => /lib64/libTKPrim.so.7 (0x00007f6557d60000)

    libTKMesh.so.7 => /lib64/libTKMesh.so.7 (0x00007f6557c70000)

    libTKXSBase.so.7 => /lib64/libTKXSBase.so.7 (0x00007f65579a8000)

    libTKBool.so.7 => /lib64/libTKBool.so.7 (0x00007f6557538000)

    libTKBO.so.7 => /lib64/libTKBO.so.7 (0x00007f6557290000)

    libTKShHealing.so.7 => /lib64/libTKShHealing.so.7 (0x00007f6556fb8000)

    libTKG3d.so.7 => /lib64/libTKG3d.so.7 (0x00007f6556e70000)

    libTKG2d.so.7 => /lib64/libTKG2d.so.7 (0x00007f6556e08000)

    libTKGeomBase.so.7 => /lib64/libTKGeomBase.so.7 (0x00007f65568a0000)

    libTKGeomAlgo.so.7 => /lib64/libTKGeomAlgo.so.7 (0x00007f6556280000)

    libTKTopAlgo.so.7 => /lib64/libTKTopAlgo.so.7 (0x00007f6555f50000)

    libTKernel.so.7 => /lib64/libTKernel.so.7 (0x00007f6555d78000)

    libTKMath.so.7 => /lib64/libTKMath.so.7 (0x00007f6555ab8000)

    libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f6555aa8000)

    libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f65558b8000)

    libm.so.6 => /lib64/libm.so.6 (0x00007f6555770000)

    libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f6555750000)

    libc.so.6 => /lib64/libc.so.6 (0x00007f6555580000)

    libTKCDF.so.7 => /lib64/libTKCDF.so.7 (0x00007f6555520000)

    libTKBRep.so.7 => /lib64/libTKBRep.so.7 (0x00007f6555418000)

    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f65553f0000)

    libtbb.so.2 => /lib64/libtbb.so.2 (0x00007f65553a8000)

    libtbbmalloc.so.2 => /lib64/libtbbmalloc.so.2 (0x00007f6555360000)

    libdl.so.2 => /lib64/libdl.so.2 (0x00007f6555358000)

    /lib64/ld-linux-x86-64.so.2 (0x00007f6558818000)

    Note that the cmake system still needs a little bit of tweaking so that it works on all platforms, it is also missing an install target, these are probably straightforward fixes.

    Fantastic! many thanks for confirming that it builds. I will let the developer know that it still needs some minor tweaks.

  1. Page 1
  2. 2

Login or Register to reply.