@Coen said:
What's the roadmap for a shared collaboration between Archipack and BlenderBIM? Archipack has really great tooling, can't the draw wall functionality of Archipack be incorporated into BlenderBIM, so one could start drafting with IfcWallTypes for example?
I see a bottle neck in BlenderBIM <=> Archipack interoperability in frequent breaking changes needing one or both tools to also update to stay in sync. Is there a way to isolate the handshake between both, maybe into one specific bpy file that can live in a github repo, available for anyone in the community to update / create pull requests for. Potentially this could even make it possible for further innovation to occur collaboratively by members of the community, incorporating both tools without having to get both @Moult and @stephen_l to update the core code for BlenderBIM and Archipack. They can then pick the best examples that make the most sense to integrate into either tool for better implementation, at their own convenience, while the community still has working options to continue with. Is this practicable?
I don't know if it's the same with others but for me, my hierarchy of needs for the Blender AEC workflow, of which Archipack has become my default tool, is as follows:
1) Design ideation with Grease Pencil, block models, etc.
2) Architectural 3d modelling with Archipack, including renders for presentation (if it generates a BIM model automagically at this point without me having to think about it, that would be awesome, but not absolutely necessary based on my exact needs).
3) CAD drafting with dimensions and annotations, which BlenderBIM seems almost ready to take care of.
4) Imputing, extracting and exchanging BIM data from the model, especially related to cost
5) Anything else.
Right now, I get stuck at #2, not being able to generate a BIM file from my Archipack model, so I'm not able to use BlenderBIM for #3 and #4.
Previously, when the BlenderBIM Add-on was merely an export tool, such a interface was created. Right now, as the BlenderBIM Add-on is native IFC, there is a bit more work for ArchiPack to do, but actually results in less breakage, just that @stephen_l hasn't yet gotten around to implementing it I believe.
Comments
I see a bottle neck in BlenderBIM <=> Archipack interoperability in frequent breaking changes needing one or both tools to also update to stay in sync. Is there a way to isolate the handshake between both, maybe into one specific bpy file that can live in a github repo, available for anyone in the community to update / create pull requests for. Potentially this could even make it possible for further innovation to occur collaboratively by members of the community, incorporating both tools without having to get both @Moult and @stephen_l to update the core code for BlenderBIM and Archipack. They can then pick the best examples that make the most sense to integrate into either tool for better implementation, at their own convenience, while the community still has working options to continue with. Is this practicable?
I don't know if it's the same with others but for me, my hierarchy of needs for the Blender AEC workflow, of which Archipack has become my default tool, is as follows:
1) Design ideation with Grease Pencil, block models, etc.
2) Architectural 3d modelling with Archipack, including renders for presentation (if it generates a BIM model automagically at this point without me having to think about it, that would be awesome, but not absolutely necessary based on my exact needs).
3) CAD drafting with dimensions and annotations, which BlenderBIM seems almost ready to take care of.
4) Imputing, extracting and exchanging BIM data from the model, especially related to cost
5) Anything else.
Right now, I get stuck at #2, not being able to generate a BIM file from my Archipack model, so I'm not able to use BlenderBIM for #3 and #4.
Previously, when the BlenderBIM Add-on was merely an export tool, such a interface was created. Right now, as the BlenderBIM Add-on is native IFC, there is a bit more work for ArchiPack to do, but actually results in less breakage, just that @stephen_l hasn't yet gotten around to implementing it I believe.