@JQL said:
What would happen if Homemaker would generate a window on a wall and then a user would manually reposition it? Would it be possible that this repositioning would, somehow, be remembered when redoing a section or building?
At the moment if you regenerate a building with Homemaker, any changes you made in blenderbim are lost, this is a hard problem to solve - at the moment it would require Homemaker to generate consistent GUIDs and STEP IDs for rooted elements. GUIDs are possible (it is on the tracker), but I don't know how to do STEP IDs :(
Some kind of future GUID-aware IFC graph merge tool may be able to do this kind of merging without STEP IDs someday.
What if the input geometry had some guides to where to place elements and, if those elements were moved/stretched in the output geometry, those guides would also move in the input geometry? Of course, one would have to model those guides in the input geometry for them to be editable.
This is a packaged Homemaker add-on with dependencies for Linux, Windows and Mac.
This release adds new features and makes some incompatible changes to the way styles are defined.
New features:
The Homemaker function turns any blender mesh into an IFC building model - using faces as walls and ceilings, and the closed cells/spaces in the mesh as rooms. This process can now be easily reversed, even from a saved model, by selecting any part of the building and running Topologise - then just edit the mesh and re-run Homemaker to recreate the IFC building based on the new geometry. Similarly, selecting any part of an IFC model and re-running Homemaker regenerates the IFC building completely, allowing you to change style definitions and see how this changes the building.
Homemaker creates entire building models in one click, but this isn't always how you want to work. The Homemaker function can now generate fragments of buildings from open meshes and loose faces - allowing you to create buildings bit-by-bit, making some parts in Blenderbim and other parts in Homemaker.
Grillages have a new do_levelling parameter which levels extrusions and repeating elements on inclined surfaces.
Repeats and Extrusions have a new ref_direction parameter to rotate about the directrix.
Incompatible style changes:
It turns out that a Material Layer Set Usage, which is used to offset a Wall or Slab from its axis, isn't allowed on a Type definition and so has to be applied to each Element independently. These offsets are now defined in the YAML style definition for each Wall or Shell object using a new offset parameter.
The assets.yml style definition has been renamed to families.yml to align with more normal BIM terminology. Accordingly the asset parameter in Repeat definitions has been renamed to family. The file parameter for each asset in a family has been changed to name as it refers to a named IFC Type in the library not a DXF file.
In addition there has been some refactoring and small temporary fixes for bugs that will definitely be fixed properly later.
Can ChatGPT or maybe some other AI tool produce several IFC files in different styles using the home-maker add-on? You could just describe the building you want and it would produce technically correct and structurally sound IFC files ready for production. How many years before this becomes a reality?
@Coen the Homemaker add-on is ultimately just a tool to generate a styled IFC model from a Topologic CellComplex. So yes, any tool that can produce a sane Topologic model can be used to build multiple alternative IFC models in different styles.
Creating @Topologic models with AI is definitely going to happen one way or another.
Not an 'AI' technology, but the original Homemaker project designs buildings to a specification (a pattern language, plot-ratio and environment) using evolution rather than AI. It outputs a Topologic CellComplex, so this also kind-of does this thing.
I agree with @brunopostle that @topologic models will be created through AI sooner or later. Just today I was looking at the chatGPT API to see what is possible.
Hello @brunopostle, I've started following your initial exercises from the homemaker with the 2023-05-29 release. I'm working with Windows 10 and Blender version 3.6.2, along with BlenderBIM 0.0.230821.
I believe my computer is powerful enough (Core i7 and 32GB of RAM), but when I have a somewhat complex topology and I run Homemaker, it takes a long time to complete the operation ( Blender not responding message included ). Is this normal or is there something I can do to fix it? Thanks in advance.
@jsoler it depends on how complex your complex model is. The two things that take the most time are finding the CellComplex, and generating the IFC entities, actually loading the model in BlenderBIM is now very fast.
Feel free to share a model that is slow, I'll investigate.
You can try modelling your building in parts, and generating the IFC incrementally. ie. if you generate one building from a mesh called 'Cube', the IFC building will be named 'Cube'. If you then generate from another mesh called 'Cube', then these new elements will be added to the same building. You may need to fix some entities where they need to join, but this technique should scale.
@brunopostle I send you the IFC file from one of your tutorials. Creating the topology took about two and a half minutes, whereas in your tutorial, I saw it took just one second. In the .blend file, the model is present with the Simple Deform modifier that you applied, but it's not working for me.
@jsoler I'll have a look at the files tomorrow. In some of these videos (not all) I have cut out the bits where nothing happens (in particular "model a building in five minutes" is heavily edited to squeeze it into a presentation slot).
@jsoler It takes three minutes here: 30 seconds to find the CellComplex (I'm sure this could be much more efficient, but it wouldn't make much difference in this case), 140 seconds to build the IFC model, and 10 seconds to load the model into BlenderBIM (loading is very fast).
I'm sure there is optimisation that can be done, but Homemaker is doing a lot of stuff assembling an entire BIM model, so it is never going to be as instant as I would like.
Homemaker used to automatically apply modifiers, but I disabled this, I'm not entirely sure why. So for now you need to 'apply' the modifier before running Homemaker (I also had to rotate the mesh by 90 degrees because the blender 'simple deform bend' modifier only bends from left to right):
Hi,
I thought I'd share with you this test that I conducted today. It iteratively created cellComplexes with increasing number of Cells (I used CellComplex.Prism with nSides on each dimension increasing from 1 to 20. And I measured the time it took to create each CellComplex. Topologic is not a speed daemon, but I was happy to see that it completed all 20 CellComplexes and did not crash. 1000 cells take 89 seconds, but then it starts consuming more time on a curve rather than a straight line. I am glad, however, that creating a CellComplex was not the slowest part of the process above. In my tests, 30 seconds were needed to create 500 Cells (in jupyter notebook with pure python, no graphics). Wondering how many cells are in that building?
Oh then that is far slower than just running it in jupyter notebook. I wonder if Blender is slowing it down. Would you be able to send me or post here a brep of the basic cells that build the CellComplex (eg a Cluster or even a CellComplex). I can decompose into cells and rebuild it and measure how long it takes. Thanks!
@brunopostle Do you include dictionary transfer in your computation or just pure geometric processing to build a CellComplex? The chart I provided is the latter.
@brunopostle Indeed InternalVertex and IsInside are computationally very expensive. I would love for a python guru to try and optimise them and speed them up. I've experimented with K-D Trees etc, but was getting inaccurate results. I believe multi-threading or multi-processing might be a way to speed them up.
@brunopostle said: @topologic I can see how my method can be optimised by inverting the loop, but this would only halve the number of comparisons.
It could also be optimised by only looking at face pairs that have parallel normals.
Filtering by normal brings down the dictionary transfer from 100 to 42 seconds. This is the orthogonal model where lots of faces share normals, the 'bent' version is faster at 28 seconds (proof that buildings should always be a bit wonky).
it seems the Shell.ExternalBoundary method is mainly python code,
whilst CellComplex.ExternalBoundary method just return its 'inherent' (C++?) method.
I learned from @topologic earlier code to find external face mainly by python, but I just find FreeCAD Part module already provide something fundamental which seems to be C++ method (hopefully faster).
Just wondering if OCC, like FreeCAD (Part Module), already provide some C++ method to TopologicPy which would be less rely on Python and be more efficient ?
Thanks :)
FreeCAD Part/OCC method -
e.g.
e = shell.getFreeEdges() # Basically returning 'external' edges
Topologic / TopologicPy Earlier Reference Code -
def get_internal_faces(cellComplex):
internal_faces = []
faces = []
_ = cellComplex.Faces(None, faces)
#topologic.CellComplex.Faces(cellComplex, faces)
print(" faces are - ", faces)
for face in faces:
cells = []
_ = face.Cells(cellComplex, cells)
#_ = topologic.CellComplex.Faces(cellComplex, faces)
if len(cells) > 1:
internal_faces.append(face)
return topologic.Cluster.ByTopologies(internal_faces)
@brunopostle said:
Filtering by normal brings down the dictionary transfer from 100 to 42 seconds. This is the orthogonal model where lots of faces share normals, the 'bent' version is faster at 28 seconds (proof that buildings should always be a bit wonky).
Not sure how "filtering by normal" helps in the general case of finding if a vertex is inside a face. Do you think it is specific to your workflow or is it something that topologicpy should include as an improvement?
Comments
At the moment if you regenerate a building with Homemaker, any changes you made in blenderbim are lost, this is a hard problem to solve - at the moment it would require Homemaker to generate consistent GUIDs and STEP IDs for rooted elements. GUIDs are possible (it is on the tracker), but I don't know how to do STEP IDs :(
Some kind of future GUID-aware IFC graph merge tool may be able to do this kind of merging without STEP IDs someday.
What if the input geometry had some guides to where to place elements and, if those elements were moved/stretched in the output geometry, those guides would also move in the input geometry? Of course, one would have to model those guides in the input geometry for them to be editable.
@JQL it is basically the same problem that freecad developers call 'the topological naming problem'.
i imadine it is. as soon as some new id arises or is deleted, it's done
New blender-homemaker-2023-01-29 release
This is a packaged Homemaker add-on with dependencies for Linux, Windows and Mac.
This release adds new features and makes some incompatible changes to the way styles are defined.
New features:
The Homemaker function turns any blender mesh into an IFC building model - using faces as walls and ceilings, and the closed cells/spaces in the mesh as rooms. This process can now be easily reversed, even from a saved model, by selecting any part of the building and running Topologise - then just edit the mesh and re-run Homemaker to recreate the IFC building based on the new geometry. Similarly, selecting any part of an IFC model and re-running Homemaker regenerates the IFC building completely, allowing you to change style definitions and see how this changes the building.
Homemaker creates entire building models in one click, but this isn't always how you want to work. The Homemaker function can now generate fragments of buildings from open meshes and loose faces - allowing you to create buildings bit-by-bit, making some parts in Blenderbim and other parts in Homemaker.
Grillages have a new
do_levellingparameter which levels extrusions and repeating elements on inclined surfaces.Repeats and Extrusions have a new
ref_directionparameter to rotate about the directrix.Incompatible style changes:
It turns out that a Material Layer Set Usage, which is used to offset a Wall or Slab from its axis, isn't allowed on a Type definition and so has to be applied to each Element independently. These offsets are now defined in the YAML style definition for each Wall or Shell object using a new
offsetparameter.The
assets.ymlstyle definition has been renamed tofamilies.ymlto align with more normal BIM terminology. Accordingly theassetparameter in Repeat definitions has been renamed tofamily. Thefileparameter for each asset in a family has been changed tonameas it refers to a named IFC Type in the library not a DXF file.In addition there has been some refactoring and small temporary fixes for bugs that will definitely be fixed properly later.
Can ChatGPT or maybe some other AI tool produce several IFC files in different styles using the home-maker add-on? You could just describe the building you want and it would produce technically correct and structurally sound IFC files ready for production. How many years before this becomes a reality?
@Coen the Homemaker add-on is ultimately just a tool to generate a styled IFC model from a Topologic CellComplex. So yes, any tool that can produce a sane Topologic model can be used to build multiple alternative IFC models in different styles.
Creating @Topologic models with AI is definitely going to happen one way or another.
Not an 'AI' technology, but the original Homemaker project designs buildings to a specification (a pattern language, plot-ratio and environment) using evolution rather than AI. It outputs a Topologic CellComplex, so this also kind-of does this thing.
I agree with @brunopostle that @topologic models will be created through AI sooner or later. Just today I was looking at the chatGPT API to see what is possible.
OMG!
Cool, good thing you didn't ask the Bing AI.
Fixed. Delete :)
New blender-homemaker-2023-05-29 release
This is a packaged Homemaker add-on with dependencies for Linux, Windows and Mac.
This is a maintenance release with some bugfixes and a minor new feature:
I've written a short HOWTO showing the creation of a basic Homemaker style. This covers assembling a Window family, a Wall Type, and how to configure the style for Homemaker.
Hello @brunopostle, I've started following your initial exercises from the homemaker with the 2023-05-29 release. I'm working with Windows 10 and Blender version 3.6.2, along with BlenderBIM 0.0.230821.
I believe my computer is powerful enough (Core i7 and 32GB of RAM), but when I have a somewhat complex topology and I run Homemaker, it takes a long time to complete the operation ( Blender not responding message included ). Is this normal or is there something I can do to fix it? Thanks in advance.
@jsoler it depends on how complex your complex model is. The two things that take the most time are finding the CellComplex, and generating the IFC entities, actually loading the model in BlenderBIM is now very fast.
Feel free to share a model that is slow, I'll investigate.
You can try modelling your building in parts, and generating the IFC incrementally. ie. if you generate one building from a mesh called 'Cube', the IFC building will be named 'Cube'. If you then generate from another mesh called 'Cube', then these new elements will be added to the same building. You may need to fix some entities where they need to join, but this technique should scale.
@brunopostle I send you the IFC file from one of your tutorials. Creating the topology took about two and a half minutes, whereas in your tutorial, I saw it took just one second. In the .blend file, the model is present with the Simple Deform modifier that you applied, but it's not working for me.
@jsoler I'll have a look at the files tomorrow. In some of these videos (not all) I have cut out the bits where nothing happens (in particular "model a building in five minutes" is heavily edited to squeeze it into a presentation slot).
@jsoler It takes three minutes here: 30 seconds to find the CellComplex (I'm sure this could be much more efficient, but it wouldn't make much difference in this case), 140 seconds to build the IFC model, and 10 seconds to load the model into BlenderBIM (loading is very fast).
I'm sure there is optimisation that can be done, but Homemaker is doing a lot of stuff assembling an entire BIM model, so it is never going to be as instant as I would like.
Homemaker used to automatically apply modifiers, but I disabled this, I'm not entirely sure why. So for now you need to 'apply' the modifier before running Homemaker (I also had to rotate the mesh by 90 degrees because the blender 'simple deform bend' modifier only bends from left to right):
Thank you @brunopostle for your help:)
Hi,
I thought I'd share with you this test that I conducted today. It iteratively created cellComplexes with increasing number of Cells (I used CellComplex.Prism with nSides on each dimension increasing from 1 to 20. And I measured the time it took to create each CellComplex. Topologic is not a speed daemon, but I was happy to see that it completed all 20 CellComplexes and did not crash. 1000 cells take 89 seconds, but then it starts consuming more time on a curve rather than a straight line. I am glad, however, that creating a CellComplex was not the slowest part of the process above. In my tests, 30 seconds were needed to create 500 Cells (in jupyter notebook with pure python, no graphics). Wondering how many cells are in that building?
@topologic there are 569 faces and 76 cells in this CellComplex
Oh then that is far slower than just running it in jupyter notebook. I wonder if Blender is slowing it down. Would you be able to send me or post here a brep of the basic cells that build the CellComplex (eg a Cluster or even a CellComplex). I can decompose into cells and rebuild it and measure how long it takes. Thanks!
@brunopostle Do you include dictionary transfer in your computation or just pure geometric processing to build a CellComplex? The chart I provided is the latter.
@topologic Ah you are right, (on my slow laptop) generating the CellComplex takes 6 seconds and transferring the dictionary takes 100 seconds.
I'm iterating with
InternalVertex()andIsInside(), this method isn't particularly optimised.@brunopostle Indeed InternalVertex and IsInside are computationally very expensive. I would love for a python guru to try and optimise them and speed them up. I've experimented with K-D Trees etc, but was getting inaccurate results. I believe multi-threading or multi-processing might be a way to speed them up.
@topologic I can see how my method can be optimised by inverting the loop, but this would only halve the number of comparisons.
It could also be optimised by only looking at face pairs that have parallel normals.
I'm testing Face.IsInside now. It is horrendously slow. I'm going on a mission to optimise it.
Filtering by normal brings down the dictionary transfer from 100 to 42 seconds. This is the orthogonal model where lots of faces share normals, the 'bent' version is faster at 28 seconds (proof that buildings should always be a bit wonky).
Just chip in to ask if this Face.IsInside is original OCC method? (supposedly 'inherited' to FreeCAD Part module, basically OCC)
Studying TopologicPY, some initial observation , e.g.
it seems the Shell.ExternalBoundary method is mainly python code,
whilst CellComplex.ExternalBoundary method just return its 'inherent' (C++?) method.
I learned from @topologic earlier code to find external face mainly by python, but I just find FreeCAD Part module already provide something fundamental which seems to be C++ method (hopefully faster).
Just wondering if OCC, like FreeCAD (Part Module), already provide some C++ method to TopologicPy which would be less rely on Python and be more efficient ?
Thanks :)
FreeCAD Part/OCC method -
Topologic / TopologicPy Earlier Reference Code -
Not sure how "filtering by normal" helps in the general case of finding if a vertex is inside a face. Do you think it is specific to your workflow or is it something that topologicpy should include as an improvement?