@Moult said:
the append_asset API now also supports appending occurrences and will retain all properties, materials, styles, and types.
I'm not sure how to use this api. I currently have this function to merge everything from a 'source' file into the current file (this doesn't copy materials):
def merge_file(self, source):
original_project = self.by_type("IfcProject")[0]
temp_project = self.add(source.by_type("IfcProject")[0])
for element in source.by_type("IfcRoot"):
self.add(element)
for element in self.get_inverse(temp_project):
ifcopenshell.util.element.replace_attribute(
element, temp_project, original_project
)
self.remove(temp_project)
If I replace the add() method with the new api, everything gets copied over but with no hierarchy, it is just a collection of objects:
def merge_file(self, source):
original_project = self.by_type("IfcProject")[0]
temp_project = self.add(source.by_type("IfcProject")[0])
for element in source.by_type("IfcRoot"):
run(
"project.append_asset",
self,
library=source,
element=element
)
for element in self.get_inverse(temp_project):
ifcopenshell.util.element.replace_attribute(
element, temp_project, original_project
)
self.remove(temp_project)
Hmm yes the append_asset only imports the occurrence and makes no assumption about the hierarchy. The ExtractElements recipe goes a little further and imports both occurrences (via the append_asset API) and also a bit of the spatial hierarchy.
Hmm, thinking about it, I would like to import all the Object entities, but merge Type, Material, Profile, Context and Project Library entities when the name matches. This is a bit more complicated!
I think what you're describing is a common thing people would need. How about I look at making the MergeProject recipe more advanced that it supports various settings for different types of merges. Like a "dumb merge", or "enable merging materials by name" or something like that.
@Moult said:
I think what you're describing is a common thing people would need. How about I look at making the MergeProject recipe more advanced that it supports various settings for different types of merges. Like a "dumb merge", or "enable merging materials by name" or something like that.
Ultimately (and this is maybe a bit ambitious) you should be able to merge another IFC file into the current file, but do various things:
Import just selected sites / buildings / storeys/ ifc classes, or none
When there is a Name collision with Site, Building etc.., it should be possible to clobber the existing Product, or create a new Product
When there is a Name collision importing Type, Material etc.. there are four useful options: 1. put the new types/materials in a second Project Library, 2. clobber existing types/materials, 3. use the existing types/materials, 4. create new types/materials in the current Project Library only if they differ
Uninstanced types/materials may be imported into the current Project Library, or not
..and all this should work with copy and paste between models ;)
There has been a lot of talk about null guids in the community. A guid of all zero's basically basically saying the element does not have a strong identity in itself and it should be possible to freely merge it with instances from another file with identical attribute content. Instead of null-guids (it's currently not allowed, because it would create duplicates) we could also use some form a deterministic guid derived from attribute values. uuid v5 is an option for that, we could use to just hash the attribute values into a uuid.
Maybe that's a way to encode the preferences for merging into the authoring process?
@aothms said:
we could also use some form a deterministic guid derived from attribute values. uuid v5 is an option for that, we could use to just hash the attribute values into a uuid.
How would this work when you change attributes? If I change the height of a wall, wouldn't I want the uuid to stay the same? even though the hash would now be different.
@brunopostle said:
How would this work when you change attributes? If I change the height of a wall, wouldn't I want the uuid to stay the same? even though the hash would now be different.
Yes, good point, I was considering them to be immutable after construction, but I'm not sure how feasible that is in your workflows.
Yes you're right, maybe null guids is the only real option then. For object types I wouldn't be opposed too much of the guid changing if their definition changes, but for elements themselves it seems undesirable. Also it's really the question if attribute values are sufficiently different to generate different guids off of them for example in the case of property sets. Let's park this discussion ;)
@brunopostle
Didn't read the 7 pages thread fully, but I wanted to tried the homemaker add-on. Downloaded the zip.
When ticking the checkbox it said 'no module named topologic'. So I thought I better read the OP carefully.
There is a link to topologic in the OP but it doesn not work anymore, I am talking about this link: https://github.com/wassimj/topologicPy
If you download the homemaker-addon git repository as a zip file, it will install as a blender add-on, but it doesn't include all the dependencies (because git just contains the Homemaker add-on code). I have bundled releases that include all the dependencies (including Topologic) for Linux, Windows and Mac here: https://github.com/brunopostle/homemaker-addon/releases
Firstly, the Topologic library has a new API and as a result the Homemaker add-on is several times faster. Plus a related memory leak that seriously degraded performance on Linux has been removed. Users installing from source will need a version of Topologic from 2022-01-30 or later.
To facilitate future development there has been an awful lot of refactoring, deletion of unused code, bugfixes, stability, naming consistency, and fixing of tests.
Fixed a bug when creating multiple buildings where subsequent buildings were missing colour and other properties.
An API allowing other tools to use the library to create IFC Wall, Slab, Roof, Space etc.. entities from Topologic models.
Structural profiles for Beam, Footing and Column entities are configurable in the style.
Roof shells are now assigned to the nearest storey instead of the ground floor.
Create Space elements for non-habitable 'void' cells (#21).
Fix a bug in the 2022-01-31 release that caused Windows and Doors to be attached to Storeys not Spaces
I don't really expect it to work everywhere, but would like any error messages or any reports of success, please add a comment to this issue.
The blender 3.1 release ships with a bundled Python 3.10, the Windows and Linux versions of this add-on now include suitable 3.10 versions of the Topologic Python bindings
The 'Homemaker Topologise' menu item is now called just 'Homemaker'
Topologise menu item now keeps the original mesh name
Topologise menu item now repopulates new mesh with original materials
Lots of impovements for Space Boundaries and the energy model
Space Boundaries should now point away from the space
Assign EXTERNAL_FIRE & EXTERNAL_EARTH PredefinedType to boundaries
Set PredefinedType for Space elements
Boundaries were missing CorrespondingBoundary
Don't set IsExternal for elements that could be internal
Fix for Space Boundaries having incorrect normals
Don't create space boundaries for grillages
Fix for gable eaves ends not being clipped
Fix incomplete top/bottom conditions resulted in off normals map
Align grillages of co-planar faces
Make stashed CellComplex translucent, fixes #43
Give all projects a PLANEANGLEUNIT
Add some more metadata for elements
minor fix EPset in structural surface
Give the Site a dummy latitude, longitude and elevation
Virtual Elements for open trace and framing roof shell
I don't really expect it to work everywhere, but would like any error messages or any reports of success, please add a comment to this issue.
pyyaml ? how to install for noobs :-)
downloading the zip file and try the handle it as an Blender add-on does noot seem to do the job? pip? from where? here on win10.
Modules Installed () from 'C:\Users\alberts\Downloads\pyyaml-master.zip' into 'C:\Users\alberts\AppData\Roaming\Blender Foundation\Blender\3.1\scripts\addons'
But :
import yaml
Traceback (most recent call last):
File "C:\Program Files\Blender Foundation\Blender 3.1\3.1\python\lib\code.py", line 90, in runcode
exec(code, self.locals)
File "", line 1, in
ModuleNotFoundError: No module named 'yaml'
Or how do I check it is there?
even worse? ezdxf .. how to handle wheel?
@lukas you need one of the ZIP packages from the Releases link, these should contain all dependencies (apart from blenderbim).
It is possible to install a snapshot directly from git using the Github download link, but this will only work if you already have yaml, ezdxf, topologic and blenderbim working in blender.
Ok, my mistake.. did not scroll far enough down to the release download.. was trying the code/zipfile..
of course one has to download from the release page... buuhh. shame.
I have put the Homemaker add-on documentation online. For now it is just an API reference extracted automatically from the code, but readthedocs makes this really easy, so I might do some user documentation.
This release includes major changes and refactoring, with an emphasis on utilising new BlenderBIM features:
You can now edit your Homemaker styles in BlenderBIM! DXF assets and the dependency on ezdxf have been removed and replaced by Native IFC libraries. Walls, slabs, extrusions, grillages, profiles, layersets, materials, psets and predefined types are all now defined in a single IFC file for each style
Walls are now editable in BlenderBIM, change a layerset, move or rotate a wall and mitred corners will be regenerated when you run the BlenderBIM Regen function.
Extrusions are now modelled as multiple mitred extrusions rather than a complex lofted path, this matches the BlenderBIM system used for modelling extruded elements. Edit a profile, move or rotate the extrusion and the BlenderBIM Regen function will tidy-up the mitred corners (note: this currently only works in BlenderBIM if your extrusion class is Beam, Column or Member). For compatibility, shipped Profile Sets now only contain a single profile, multiple profiles will be reintroduced later.
The shipped style definitions have been moved from ./molior/style/share to just ./share. This should make them easier to find and modify.
Origins for window/door Types are now aligned with wall face rather than Axis, so they can be used as-is in BlenderBIM. Some windows and doors have been updated with Plan, Clearance and Profile representations. If a Clearance representation is present, then this will be used to cut the wall opening, allowing for arbitrary arched, splayed and recessed openings. Now that IFC assets can have richer representations, it will take some time to improve all the shipped styles, contributions welcome!
Floors are now drawn as aggregations of slabs corresponding with faces in the CellComplex. The Floor module is now only used for covering finishes
The stashed Topologic CellComplex is now in an aggregate rather than a system, context is now Surface. In a future release this will allow one-click regeneration of the entire model using this stashed CellComplex
Refactoring, lots of defunct code deleted, typos, tests and code reformatting. Add a requirements.txt file. The materials.yml file is now obsolete.
Many bugs fixed: use IfcElementAssembly for repeating element aggregates, more robust handling of element classes that don't have PredefinedType, extrusion objects now have Type assigned, fix bug where materials and type representations always had Body context, orient IfcPolyline profiles properly, fix bug where repeating items didn't appear, ignore blender objects with no vertices, consistent naming of Types and typed Elements, generate normal map from external walls not cellcomplex outer surface, fix Layer Set Usage, extrusions were upside-down and mirrored, set Space Pset_SpaceOccupancyRequirements OccupancyType, add default contexts if needed to existing IFC projects, start grillage offsets from lowest point on face
Here's a new toy in the Homemaker add-on, faces in the Topologic CellComplex can be sliced into grids and filled with repeating objects (as well as parallel extrusions). This model has chairs and tiers filling the surface:
Homemaker has nothing on the wiki! Any volunteers to fix that?
And @brunopostle Gould you maybe ADD some links to cool videos and stuff to the github repo? I'm pushing a link out on mastodon but there's really not much info out there (a very long thread is not ideal).
I know Bruno is busy with other things at the moment so either of these suggestions would be a great way for anyone else to help the project!
@theoryshaw said:
Very cool. Dumb question: is there any how-to documentation for users out there?
Not exactly ?...
Basically, it takes whatever geometry you give it and discards whatever doesn't enclose closed cells. Each of the cells then becomes a 'space'. The full tool that generates IFC models can be found at Object -> Homemaker Topologise, but if you want some sense of how these cellcomplexes are generated from the faces in the blender object there is a Object -> Topologise tool that gives you the intermediate geometry.
It assumes that all dimensions are metres, sorry. This will be fixed, but I need to figure-out how units are done in blender/blenderbim/ifcopenshell.api, and I have no clue.
The workflow is: draw some geometry as a single blender object, run Homemaker Topologise to generate the IFC model, Ctrl-Z to discard the IFC, modify the blender object as needed, run Homemaker Topologise to see how this changes the IFC, Ctrl-Z, etc..
It assumes that floors are horizontal and walls are vertical, anything else is 'roof' or 'soffit' depending on if it is on top of the building or below (the soffit code is broken in this release, but fixed in git). A room has a floor and walls all the way around the perimeter, so an attic room can have sloping ceilings, but they need to meet vertical walls (for now anyway). Floor-to-floor heights can be whatever you like, and floors don't have to run through the building, so you can have double height spaces, split-level etc..
By default it assumes that all rooms are 'living' rooms, so they get windows and connecting doors. The 'default' style is a kind of Georgian based on measurements of the previous house I lived-in.
At the moment the behaviour of room/space types are all hard-coded, but eventually it will be configurable. There are currently several space types: living, kitchen, circulation, stair, toilet, bedroom and retail; these primarily control which door and window configuration gets used: retail on the ground floor can get a series of shop fronts, no doors are created between kitchens and toilets etc.. I haven't got around to porting the stair drawing module just yet. There are two special space types: 'outdoor' and 'sahn', these generate outdoor spaces that the 'default' style constructs with a flat roof supported by perimeter posts. 'sahn' is an outdoor space type that is treated as internal circulation - think of a private courtyard in a riad house.
By default every space in your model has a 'living' type, so you get windows, doors between rooms, but no external doors. You can manually assign types by placing new blender objects (such as a new cube) in each of the spaces: give the new object the name 'retail' (or 'retail.001' etc..) and the space becomes a room with this type. If you forget to name or mis-spell this placeholder you will get a very small cube-shaped building inside your main building :). Once you start using these placeholders in a model, any unassigned spaces become 'outdoor'. There are some cute low-poly widgets shipped in a widgets.blend file that you can use instead of making your own, though I find that it is sometimes easier to change a room-type by renaming the widget/placeholder than replacing it.
Styles are assigned to walls and roofs by assigning blender materials to faces in the blender object, the styles are massively configurable and use an inheritance system, they control the size, types and spacing of windows and doors, wall thickness, psets, decoration, repeating items, nested repeating items (like railings with intermediate posts). The styles shipped with the add-on are a bit limited, they are called: 'default', 'courtyard', 'fancy', 'pantsy', 'arcade', 'rustic' and 'tuscan'. I'd love to see some different styles, but currently they are defined using DXF polyface meshes, DXF 2D polylines and YAML files, that are converted on-the-fly into temporary IFC Project Libraries for each style - I want to get rid of the DXF files and just use IFC Project Library files (and maybe replace YAML with JSON), but I'm not sure how to handle details like profiles and window/door openings.
Hope this makes sense, please ask if you have more questions because there is no other way that documentation will be written. The software has a long way to go, and there are a few more glitches than I'd like, but I think this approach to designing buildings has a lot of potential.
Bumping this to nudge @brunopostle to please add this to a 'how things work' / 'getting started' page both on the documentation and on the repo's readme (it can be edited incrementally as things change). Ditto links to your YouTube channel to help with easier on-boarding of people previously unfamiliar with your work.
Just switched to a Linux build from Windows and trying to catch up with Homemaker. Please how do I get past the following error after installation and clicking on Object > Homemaker on the default cube: File "/......../.config/blender/3.3/scripts/addons/blenderbim/libs/site/packages/ifcopenshell/api/__init__.py", line 66, in run result = usecase_class(ifc_file, **settings).execute() TypeError: Usecase.__init__() got an unexpected keyword argument 'name'
I have the latest BlenderBIM (v0.0.230107) installed with the 2022-12-11 release of Homemaker, running Blender 3.3.1
@DADA_universe thanks, I need nudging.
There error is because 230107 blenderbim broke lots of stuff (partially bad me using undocumented APIs). It is fixed in the homemaker-add git repository, so you can overwrite the installed add-on using a git snapshot, or wait for me to do a new release, which is my next task.
@brunopostle said: @DADA_universe thanks, I need nudging.
There error is because 230107 blenderbim broke lots of stuff (partially bad me using undocumented APIs). It is fixed in the homemaker-add git repository, so you can overwrite the installed add-on using a git snapshot, or wait for me to do a new release, which is my next task.
@brunopostle, what are the chances that your next release uses topologicpy instead of the core topologic? It is a bit of work to change the API calls, but wondering if your calls to topologic are fairly concentrated at the start of the process (which I suspect), you could quickly update your code. In general, I am moving towards making everything run through topologicpy and to hide the topologic implementation as much as possible. In the future, this means one can even swap out topologic for another engine and code calling topologicpy would still work.
Comments
Awesome, I tried (and failed) to fix this a couple of times, but got lost with all the backward and forward searches
I'm not sure how to use this api. I currently have this function to merge everything from a 'source' file into the current file (this doesn't copy materials):
If I replace the add() method with the new api, everything gets copied over but with no hierarchy, it is just a collection of objects:
Hmm yes the append_asset only imports the occurrence and makes no assumption about the hierarchy. The ExtractElements recipe goes a little further and imports both occurrences (via the append_asset API) and also a bit of the spatial hierarchy.
But if you want to import absolutely everything, maybe a better approach would be fixing this bug? https://github.com/IfcOpenShell/IfcOpenShell/issues/1000 If so I can have a go at it.
Hmm, thinking about it, I would like to import all the Object entities, but merge Type, Material, Profile, Context and Project Library entities when the name matches. This is a bit more complicated!
I think what you're describing is a common thing people would need. How about I look at making the MergeProject recipe more advanced that it supports various settings for different types of merges. Like a "dumb merge", or "enable merging materials by name" or something like that.
Ultimately (and this is maybe a bit ambitious) you should be able to merge another IFC file into the current file, but do various things:
..and all this should work with copy and paste between models ;)
There has been a lot of talk about null guids in the community. A guid of all zero's basically basically saying the element does not have a strong identity in itself and it should be possible to freely merge it with instances from another file with identical attribute content. Instead of null-guids (it's currently not allowed, because it would create duplicates) we could also use some form a deterministic guid derived from attribute values. uuid v5 is an option for that, we could use to just hash the attribute values into a uuid.
Maybe that's a way to encode the preferences for merging into the authoring process?
How would this work when you change attributes? If I change the height of a wall, wouldn't I want the uuid to stay the same? even though the hash would now be different.
Yes, good point, I was considering them to be immutable after construction, but I'm not sure how feasible that is in your workflows.
I hadn't even thought about Homemaker workflows - it really ought to be generating replicable uuids ?.
I was thinking of the blenderbim usecase where objects are edited, so the hash changes, but the uuid should still be persistent.
Yes you're right, maybe null guids is the only real option then. For object types I wouldn't be opposed too much of the guid changing if their definition changes, but for elements themselves it seems undesirable. Also it's really the question if attribute values are sufficiently different to generate different guids off of them for example in the case of property sets. Let's park this discussion ;)
@brunopostle
Didn't read the 7 pages thread fully, but I wanted to tried the homemaker add-on. Downloaded the zip.
When ticking the checkbox it said 'no module named topologic'. So I thought I better read the OP carefully.
There is a link to topologic in the OP but it doesn not work anymore, I am talking about this link:
https://github.com/wassimj/topologicPy
@Coen, Wassim moved the TopologicCore C++ library and the new pybind11 python bindings to a new repository here: https://github.com/wassimj/Topologic
If you download the homemaker-addon git repository as a zip file, it will install as a blender add-on, but it doesn't include all the dependencies (because git just contains the Homemaker add-on code). I have bundled releases that include all the dependencies (including Topologic) for Linux, Windows and Mac here: https://github.com/brunopostle/homemaker-addon/releases
@brunopostle
What a fun add-on. ?
Man, this is so cool. Really excited that the IFC export works so well as well.
And the spreadsheet writer add-on works. haha
[oops, I forgot to announce the last Homemaker add-on release]
New-ish blender-homemaker-2021-02-03 release
This is a test of packaging the Homemaker add-on and dependencies for Linux, Windows and Mac.
This repository is one year old! ???
This release includes lots of changes:
I don't really expect it to work everywhere, but would like any error messages or any reports of success, please add a comment to this issue.
New blender-homemaker-2021-02-03 release
This is a test of packaging the Homemaker add-on and dependencies for Linux, Windows and Mac.
This release includes lots of changes:
I don't really expect it to work everywhere, but would like any error messages or any reports of success, please add a comment to this issue.
New blender-homemaker-2022-03-14 release
This is a test of packaging the Homemaker add-on and dependencies for Linux, Windows and Mac.
This release includes lots of changes:
I don't really expect it to work everywhere, but would like any error messages or any reports of success, please add a comment to this issue.
New blender-homemaker-2022-05-14 release
This release includes various changes:
I don't really expect it to work everywhere, but would like any error messages or any reports of success, please add a comment to this issue.
pyyaml ? how to install for noobs :-)
downloading the zip file and try the handle it as an Blender add-on does noot seem to do the job? pip? from where? here on win10.
Modules Installed () from 'C:\Users\alberts\Downloads\pyyaml-master.zip' into 'C:\Users\alberts\AppData\Roaming\Blender Foundation\Blender\3.1\scripts\addons'
But :
Traceback (most recent call last):
File "C:\Program Files\Blender Foundation\Blender 3.1\3.1\python\lib\code.py", line 90, in runcode
exec(code, self.locals)
File "", line 1, in
ModuleNotFoundError: No module named 'yaml'
Or how do I check it is there?
even worse? ezdxf .. how to handle wheel?
Sorry
Lukas
@lukas you need one of the ZIP packages from the Releases link, these should contain all dependencies (apart from blenderbim).
It is possible to install a snapshot directly from git using the Github download link, but this will only work if you already have yaml, ezdxf, topologic and blenderbim working in blender.
Ok, my mistake.. did not scroll far enough down to the release download.. was trying the code/zipfile..
of course one has to download from the release page... buuhh. shame.
I have put the Homemaker add-on documentation online. For now it is just an API reference extracted automatically from the code, but readthedocs makes this really easy, so I might do some user documentation.
New blender-homemaker-2022-12-11 release
This release includes major changes and refactoring, with an emphasis on utilising new BlenderBIM features:
You can now edit your Homemaker styles in BlenderBIM! DXF assets and the dependency on ezdxf have been removed and replaced by Native IFC libraries. Walls, slabs, extrusions, grillages, profiles, layersets, materials, psets and predefined types are all now defined in a single IFC file for each style
API and user documentation can now be found at https://homemaker-addon.readthedocs.io/ Contributions welcome!
Walls are now editable in BlenderBIM, change a layerset, move or rotate a wall and mitred corners will be regenerated when you run the BlenderBIM Regen function.
Extrusions are now modelled as multiple mitred extrusions rather than a complex lofted path, this matches the BlenderBIM system used for modelling extruded elements. Edit a profile, move or rotate the extrusion and the BlenderBIM Regen function will tidy-up the mitred corners (note: this currently only works in BlenderBIM if your extrusion class is Beam, Column or Member). For compatibility, shipped Profile Sets now only contain a single profile, multiple profiles will be reintroduced later.
The shipped style definitions have been moved from
./molior/style/shareto just./share. This should make them easier to find and modify.Origins for window/door Types are now aligned with wall face rather than Axis, so they can be used as-is in BlenderBIM. Some windows and doors have been updated with Plan, Clearance and Profile representations. If a Clearance representation is present, then this will be used to cut the wall opening, allowing for arbitrary arched, splayed and recessed openings. Now that IFC assets can have richer representations, it will take some time to improve all the shipped styles, contributions welcome!
Floors are now drawn as aggregations of slabs corresponding with faces in the CellComplex. The Floor module is now only used for covering finishes
The stashed Topologic CellComplex is now in an aggregate rather than a system, context is now Surface. In a future release this will allow one-click regeneration of the entire model using this stashed CellComplex
Refactoring, lots of defunct code deleted, typos, tests and code reformatting. Add a
requirements.txtfile. Thematerials.ymlfile is now obsolete.Many bugs fixed: use IfcElementAssembly for repeating element aggregates, more robust handling of element classes that don't have PredefinedType, extrusion objects now have Type assigned, fix bug where materials and type representations always had Body context, orient IfcPolyline profiles properly, fix bug where repeating items didn't appear, ignore blender objects with no vertices, consistent naming of Types and typed Elements, generate normal map from external walls not cellcomplex outer surface, fix Layer Set Usage, extrusions were upside-down and mirrored, set Space Pset_SpaceOccupancyRequirements OccupancyType, add default contexts if needed to existing IFC projects, start grillage offsets from lowest point on face
Here's a new toy in the Homemaker add-on, faces in the Topologic CellComplex can be sliced into grids and filled with repeating objects (as well as parallel extrusions). This model has chairs and tiers filling the surface:
It is amazing how far homemaker has come since I last checked. Congratulations!
Homemaker has nothing on the wiki! Any volunteers to fix that?
And @brunopostle Gould you maybe ADD some links to cool videos and stuff to the github repo? I'm pushing a link out on mastodon but there's really not much info out there (a very long thread is not ideal).
I know Bruno is busy with other things at the moment so either of these suggestions would be a great way for anyone else to help the project!
Bumping this to nudge @brunopostle to please add this to a 'how things work' / 'getting started' page both on the documentation and on the repo's readme (it can be edited incrementally as things change). Ditto links to your YouTube channel to help with easier on-boarding of people previously unfamiliar with your work.
Just switched to a Linux build from Windows and trying to catch up with Homemaker. Please how do I get past the following error after installation and clicking on Object > Homemaker on the default cube:
File "/......../.config/blender/3.3/scripts/addons/blenderbim/libs/site/packages/ifcopenshell/api/__init__.py", line 66, in run result = usecase_class(ifc_file, **settings).execute() TypeError: Usecase.__init__() got an unexpected keyword argument 'name'I have the latest BlenderBIM (v0.0.230107) installed with the 2022-12-11 release of Homemaker, running Blender 3.3.1
@DADA_universe thanks, I need nudging.
There error is because 230107 blenderbim broke lots of stuff (partially bad me using undocumented APIs). It is fixed in the homemaker-add git repository, so you can overwrite the installed add-on using a git snapshot, or wait for me to do a new release, which is my next task.
@brunopostle, what are the chances that your next release uses topologicpy instead of the core topologic? It is a bit of work to change the API calls, but wondering if your calls to topologic are fairly concentrated at the start of the process (which I suspect), you could quickly update your code. In general, I am moving towards making everything run through topologicpy and to hide the topologic implementation as much as possible. In the future, this means one can even swap out topologic for another engine and code calling topologicpy would still work.