Standardizing BBIM property sets?
With the increasing number of BlenderBIM specific Psets, I'm wondering does it make sense to try and start to standardize these? A few for example:
- BBIM_Array
- BBIM_Batting
- BBIM_Dimension
- BBIM_Documentation
- BBIM_Door
- BBIM_Fitting
- BBIM_Linked_Aggregate
- BBIM_Railing
- BBIM_Roof
- BBIM_Search
- BBIM_Section
- BBIM_Stair
- BBIM_Window
- EPset Parametric
- EPset Status
- EPset_Drawing.
- EPset_Productivity
- EQto_BodyGeometryVaIidation
- ePSet_Georeferencing
By standardizing, other programs like FreeCAD, and others, could adopt as well. Ping @yorik.
I took a stab, here, of seeding some documentation around this concept.
...
To make it more universal, could see changing the prefix from BBIM_
to OSA_
. Mocked up, here
Thoughts?
Comments
What
OSA
stands for?Oh, you meant OSA like in OSArch :\
Given that this is hosted on osarch.org I assume OSA ist short for that and would allow other tools (FreeCAD in this respect) to use the same set of parameters. Fitting BBIM_ into the sets would give these sets a proprietary co-notation. Perhaps IOS_ might be another way to indicate sets to be used by all applications that use IfcOpenShell. I admit that I found it weird at first when there were so many entries concerning Apple's mobile operating system when you cannot even run Blender on them.
I'd love a cross-platform standard set of properties! I think we could have all of them: OSA_ for common OSA sets, BBIM for things that are of BlenderBIM only (I would think blender-related things) and maybe another for FreeCAD-only stuff (I don't see any at the moment). But mostly everything non strictly software specific should definitely go into something generic. I'd certainly be happy to have FreeCAD support things like automatic arrays or stairs.
Just one question regarding your Osa_Array @theoryshaw @Moult : child objects are referring to their parent by GUID. Is that not sort of "anti-IFCish"? Shouldn't they be referenced by step ID instead? (although I like the fact that referencing by GUID does not depend on step numbers...)
A more IFC-ish way to do this would be to list all the child objects in an IfcGroup, ie none of this two-way reference stuff.
Great idea! As for
BBIM_Aggregate_Data
, I think I'll change some things. I'm trying to rewrite the code to use IfcGroup as suggested by @brunopostle.Here's a little inspiration... :)
https://chatgpt.com/share/681a28a3-f6a0-8013-8d39-097458695dbb
Great idea, but just a note that epsets are a little special, they are a convention increasingly being adopted for backported functionality in IFC via psets.