Sorry for hijacking this post, but his got me thinking if pure IFC is really the way to go in the long term for Bonsai.
Don't get me wrong, I totally get the appeal of building a full featured BIM authoring software that directly saves in the industry standard open format for BIM data. It is great for interoperability and data preservation during interchange, but isn't this going to limit what we can implement and when in can implement it in the long run?
I mean, making standards and schemas is certainly no easy task, it take time and consensus from all intervening parties, and from what I get, buildingSMART is not particularly fast getting new versions out. All the other big industry stakeholders that represent large CAD software probably have no motivation to improve IFCs native parametric capabilities, in fact doing so could pose a threat to their commercial interests, and potentially facilitate users exiting their ecosystems.
Also interchange file formats and open standards are often by nature built for easy implementation, sharing of data and readability , and not necessarily suitable or intended for editing purposes.
A good example I'd like to remind is SVG and Inkscape. Inkscape always strived to keep its native format as the W3C standard for vector graphics, which is, if you ask me, an honestly commendable and welcome goal. However Inkscape is (or wants to be) at its hear a general purpose Illustration program, comparisons to the well established industry leaders are inevitable. Users will naturally request features that are often at odds with SVG standards, like multi-page documents, customizable DPI, non destructive editing, CMYK, among others.
In recent years they have implemented much of this, which has done wonders to it's popularity, but generally at the expense of interoperability. Inkscape SVG (the native way to save Inkscape data) has slowly started to diverge from standard SVG to be able to support all the popular features. Some remain relatively compatible (like the non destructive modifier-like system Path Effects), but others like multi-page documents, or certain text features, will certainly not display well elsewhere; which is a necessary sacrifice the developers had to make, to be free from SVG schema limitations and implement features that will objectively make Inkscape a better, at the expense of compatibility.
I wonder if the same is not true for Bonsai, in the long term at least. Bonsai is actively developed, and moves forward at an astonishing rate, far faster than I'd expect IFC standards to ever do, and being free to implement popular features (like parametric components, true instancing, or other features not in the IFC schema) if and when we want to, rather than hope the next IFC schema version in roadmap standardizes it, would be very desirable. Leaving us at the eternal mercy of the IFC schema and buildingSMART schedules puts us at a very bleak and vulnerable position.
Bonsai is already very capable as we see daily here in this forum, and this may suffice to win over the average non technical CAD user very soon, but at some point in the future if we want to actively grow and win over users from proprietary solutions, we main not be able to idly rely on native IFC features alone.
Now I would not propose to ditch IFC altogether, but I wonder if Bonsai could pull something like Inkscape did with SVG, and maybe find some middle ground between plain IFC and some sort of "Bonsai-IFC". Maybe respect IFC schema as much as possible, keep as much of native base file format and structure as close and as compatible with IFC as possible, but on top of that build our own infrastructure of features, necessary for powerful authoring, expertly deviating from the standard schema strictly when necessary to support our own native editing features, without waiting indefinitely for a new schema version to come out, and without relying on others to accommodate changes we need, and may not necessarily align with the goals of the exchange file format. If we keep close enough to standard IFC, exporting a plain one when needed should be less of a hassle.
If you look closely Bonsai does already the same thing you described for inkscape. There are specific properties and elements in a Bonsai ifc project (for example View properties or parametric doors properties) that are not included in the iso standard (but are allowed). So I don't think the lack of features in the ifc standard will be a limiting factor in the near future.
On the other hand, the benefits of keeping ifc as the native format are massive for me:
I can take any file lying around and use it as a native library for my next project
I can pick up any file lying around and do some renovation planing (this is something no competition can do and in central Europe is really huge. More and more companies are looking into digitalisation of their assets and in my opinion native ifc is the only way that makes sense)
The whole point of IFC is about interoperability. As soon as you create a .bifc (my freshly coined term for Bonsai IFC) - then you immediately lose your interoperability.
You might as well create a completely native program that simply imports/exports to/from IFC, a bit like simpleBIM for example with their .cube format.
And at that point, you're in competition with a whole host of other projects.
Bonsai moving away from IFC won't happen, fortunately. As @JanF said, you can have software features that deviate from the schema as long as they can be implemented following the rules of the schema.
Now, to hijack your hijack... Bonsai moving away from Blender - that could be possible.
It's an awful lot of work to create a standalone Bonsai so chances are it won't happen at least anytime soon.
If it did happen, my imaginary scenario is that the Blender extension would simply be an import/export function, to work as a map between Blender capabilities (for those comfortable in the software), and the IFC format.
For me personally, core Blender must improve their UI customizability. At the moment it is a limiting factor for Bonsai's future with Blender.
Well written @duarteframos. I resonate with a lot of your points. @JanF is right, there's quite a bit of Bonsai functionality that's not codified into the schema: Drawings, Linked Aggregates, Arrays, Parametric Roof/Stairs/Railing and Status.. but it's saved in the IFC through a json dump into a custom Pset. I think anything, it seems, prefixed with a bbim_.
What would be interesting, since i think standards are important, would be to initiate some effort to start standardizing these psets between open source tools. Namely, at this point Bonsai and FreeCAD. The idea was brought up here.
I could see potentially, over time, as these psets became more standardized in the open source ecosystem, that it would be an easier sell for them to be more officially codified into the BS standard.
@zoomer said:
Ouh, I would rather like to hear that Bonsai makes more use of Blender .... to workaround IFC limitations.
@CSN said:
It's an awful lot of work to create a standalone Bonsai so chances are it won't happen at least anytime soon.
For me personally, core Blender must improve their UI customizability. At the moment it is a limiting factor for Bonsai's future with Blender.
As someone who already uses Blender, using more of it would be a welcome development for me. Better cloning, using collection instancing to materialize aggregates, better non destructive modelling, would definitely be improvements I'd like to inherit from Blender.
But as CSN mentions it is a monstrous task to replace the hole infrastructure Blender provides (3D viewport, rendering, navigation, UI, interaction, keymaps, etc.), though the UI, as much as I like it, is indeed not the most adequate for Bonsai in some aspects.
@theoryshaw said: @JanF is right, there's quite a bit of Bonsai functionality that's not codified into the schema: Drawings, Linked Aggregates, Arrays, Parametric Roof/Stairs/Railing and Status.. but it's saved in the IFC through a json dump into a custom Pset. I think anything, it seems, prefixed with a bbim_.
What would be interesting, since i think standards are important, would be to initiate some effort to start standardizing these psets between open source tools.
That is interesting, I did not know it worked that way, and sounds pretty close to what I had envisioned, minus the drawbacks. Also similar to how Inkscape is doing non destructive features, if I understand correctly. Good to know.
Standardizing psets would indeed be a worthy goal. Another development I'd hope to see some day would be "democratizing" the authoring of these parametric geometries, making it more accessible to end users to expand them, rather than be limited to some hardcoded features. Maybe through some coding, or ideally eventually through a more graphical UI.
Fantastic discussion. First, a bit of history. For the first 2 years of Bonsai, we were not IFC native. We used Blender, and imported and exported like everybody else. Then the project basically started from scratch being IFC native. Within a year, we had reimplemented and overtaken existing functionality. In the second year, we had surpassed industry capabilities in 4d and 5d that wouldn't have been possible if we were just Blender. Now, thanks to IFC, we're getting native solid modeling akin to FreeCAD mixed with meshes all in Blender. I have no regrets. More fun history here https://community.osarch.org/discussion/1652/happy-4th-birthday-blenderbim-add-on-by-the-numbers
In the present, we already do a lot that is either IFC pioneering (constraints in parametric 4d and 5d), or stretching the IFC definition (drawings, annotations), or completely not native IFC (stair, railings, sverchok, CSS). The fact that some people didnt realise this was the case is awesome, but perhaps scary too.
In the short run, surprisingly there is still a ton of native IFC we havent yet fully implemented. I mean, look at parametric, prioritised wall layers. Look at circuits and MEP connections. Look at aggregated types. Look at alignments. Look at.. work orders, event triggers? Yikes! We only just caught up on item editing, boolean hierarchies... there's so much more to discover.
In the long run, increasingly more things will be built that is not native IFC (the spec is limited!). This is a good thing. It's also a good thing that IFC cannot do these things , because IFC is in my opinion not really about interoperability... IFC is about standardization. International standardization has a very clear scope: for us to agree of defining the common terms of our built environment globally. So ACME stair generator 2.0 is out of scope of IFC, and that's totally OK. We don't want to standardise that stuff... things like parametric systems, design philosophies, user interfaces, let it all be flexible. The great news is that IFC can reference external systems, so you can have a totally custom design system whilst still being native IFC.
Inkscape is a great parable. But there are differences in the details. For example Inkscape embeds their schema within SVG using their own attributes. This blurs the line between spec and custom. In IFC we can do that too (e.g. parametric railings in a pset) but we don't need to. Instead we can reference external sources (e.g. blender materials, CSS styles, SVG layout documents, ODS spreadsheets), which we already do. This is allowed and appropriate in IFC (they have specific classes to do exactly this). In the long run, these external integrations will get more sophisticated. Slowly, things with merit will transition from purely custom to defacto standard, and if truly universal, to ISO standard. We're in an industry where some fundamentals really don't change much over the decades.
Tldr, standardised fundamental data schemas about our built environment and highly custom external systems can coexist and complement each other. Hooray!
Well that certainly puts my fears to rest. And to think I even doubted your ingenuity for a second.
So basically IFC tries to standardize how data should structured, but doesn't necessarily limit us on what data we can and cannot save. Not being at the whim of schema builders for our growth is much more reassuring.
Forgive my ignorance, about these matters, I lurk around in these forums a lot, but my knowledge about all this is pretty much theoretical at this point. Thanks for the reply, this has been enlightening .
I don't think this is said enough around here, but you guys are doing gods work with Bonsai. Thanks to Dion and all the other developers I don't know by name for keeping this alive and growing.
Hi all, I am also a lurker/learner on the platforms, I was wondering what the impact would be of IFC5 on Bonsai? This questing is totally due to my developer/programming ignorance.
An area where I think IFC is going down is rabbit hole is the creating of all the “IFCType” and “IFCElements” without grouping them into a trade. I understand all these IFCTypes are required for their specific attributes, but it has the potential to create an overload.
As per the attached screenshots
Fully agree that there should be a standardisation of Psets which then maybe becomes an attribute value. It is important we don’t over standardise this limits creativity and problem-solving skills.
All and all Bonsai is something special and well done.
@Roel said:
I was wondering what the impact would be of IFC5 on Bonsai?
I've also wondered how much of Bonsai will have to change whenever a new IFC version comes out, particularly if we started building a lot of non standard stuff on top of IFC spec.
But I guess that is a question no one here can objectively answer beforehand, because that will probably depend largely on how much the IFC changes from version to version.
My uninformed guess is probably not much impact, both because the IFC shcema will not change that much (as Dion said, fundamentals don't change that much throughout the years), and Bonsai is robustly built, (from what I gather the developers know what they are doing, so changes will hopefully be manageable).
I'd like to add that in FreeCAD we have also become nativeIFC. And we do the exact same thing ("standard" IFC structure + custom data that "only FreeCAD reads and uses"). We're still at baby steps compared to Bonsai, no linked documents yet, etc. But the inkscape analogy makes a lot of sense to me.
I think the best answer here is what @theoryshaw proposes, start unifying and publishing "parametric conventions" that both (and hopefully later others) projects could adopt. For example, a series of Psets with description of what parametric behaviour is expected of each property, so applications have a clear path to follow to implement them. A kind of "open source side B" to IFC
@duarteframos said:
I've also wondered how much of Bonsai will have to change whenever a new IFC version comes out, particularly if we started building a lot of non standard stuff on top of IFC spec.
The foundation of the native IFC approach is IfcOpenShell (https://ifcopenshell.org/) - toolkit or API for efficient work with ifc files. This is the backend for borth Bonsai and FreeCAD ifc capabilites and some other tools as well and the part that needs to be heavily adapted with every new ifc version. The tools themselves not so much (at least in theory).
Comments
Sorry for hijacking this post, but his got me thinking if pure IFC is really the way to go in the long term for Bonsai.
Don't get me wrong, I totally get the appeal of building a full featured BIM authoring software that directly saves in the industry standard open format for BIM data. It is great for interoperability and data preservation during interchange, but isn't this going to limit what we can implement and when in can implement it in the long run?
I mean, making standards and schemas is certainly no easy task, it take time and consensus from all intervening parties, and from what I get, buildingSMART is not particularly fast getting new versions out. All the other big industry stakeholders that represent large CAD software probably have no motivation to improve IFCs native parametric capabilities, in fact doing so could pose a threat to their commercial interests, and potentially facilitate users exiting their ecosystems.
Also interchange file formats and open standards are often by nature built for easy implementation, sharing of data and readability , and not necessarily suitable or intended for editing purposes.
A good example I'd like to remind is SVG and Inkscape. Inkscape always strived to keep its native format as the W3C standard for vector graphics, which is, if you ask me, an honestly commendable and welcome goal. However Inkscape is (or wants to be) at its hear a general purpose Illustration program, comparisons to the well established industry leaders are inevitable. Users will naturally request features that are often at odds with SVG standards, like multi-page documents, customizable DPI, non destructive editing, CMYK, among others.
In recent years they have implemented much of this, which has done wonders to it's popularity, but generally at the expense of interoperability. Inkscape SVG (the native way to save Inkscape data) has slowly started to diverge from standard SVG to be able to support all the popular features. Some remain relatively compatible (like the non destructive modifier-like system Path Effects), but others like multi-page documents, or certain text features, will certainly not display well elsewhere; which is a necessary sacrifice the developers had to make, to be free from SVG schema limitations and implement features that will objectively make Inkscape a better, at the expense of compatibility.
I wonder if the same is not true for Bonsai, in the long term at least. Bonsai is actively developed, and moves forward at an astonishing rate, far faster than I'd expect IFC standards to ever do, and being free to implement popular features (like parametric components, true instancing, or other features not in the IFC schema) if and when we want to, rather than hope the next IFC schema version in roadmap standardizes it, would be very desirable. Leaving us at the eternal mercy of the IFC schema and buildingSMART schedules puts us at a very bleak and vulnerable position.
Bonsai is already very capable as we see daily here in this forum, and this may suffice to win over the average non technical CAD user very soon, but at some point in the future if we want to actively grow and win over users from proprietary solutions, we main not be able to idly rely on native IFC features alone.
Now I would not propose to ditch IFC altogether, but I wonder if Bonsai could pull something like Inkscape did with SVG, and maybe find some middle ground between plain IFC and some sort of "Bonsai-IFC". Maybe respect IFC schema as much as possible, keep as much of native base file format and structure as close and as compatible with IFC as possible, but on top of that build our own infrastructure of features, necessary for powerful authoring, expertly deviating from the standard schema strictly when necessary to support our own native editing features, without waiting indefinitely for a new schema version to come out, and without relying on others to accommodate changes we need, and may not necessarily align with the goals of the exchange file format. If we keep close enough to standard IFC, exporting a plain one when needed should be less of a hassle.
If you look closely Bonsai does already the same thing you described for inkscape. There are specific properties and elements in a Bonsai ifc project (for example View properties or parametric doors properties) that are not included in the iso standard (but are allowed). So I don't think the lack of features in the ifc standard will be a limiting factor in the near future.
On the other hand, the benefits of keeping ifc as the native format are massive for me:
The whole point of IFC is about interoperability. As soon as you create a .bifc (my freshly coined term for Bonsai IFC) - then you immediately lose your interoperability.
You might as well create a completely native program that simply imports/exports to/from IFC, a bit like simpleBIM for example with their .cube format.
And at that point, you're in competition with a whole host of other projects.
Bonsai moving away from IFC won't happen, fortunately. As @JanF said, you can have software features that deviate from the schema as long as they can be implemented following the rules of the schema.
Now, to hijack your hijack... Bonsai moving away from Blender - that could be possible.
Ouh, I would rather like to hear that Bonsai makes more use of Blender .... to workaround IFC limitations.
It's an awful lot of work to create a standalone Bonsai so chances are it won't happen at least anytime soon.
If it did happen, my imaginary scenario is that the Blender extension would simply be an import/export function, to work as a map between Blender capabilities (for those comfortable in the software), and the IFC format.
For me personally, core Blender must improve their UI customizability. At the moment it is a limiting factor for Bonsai's future with Blender.
Well written @duarteframos. I resonate with a lot of your points.
@JanF is right, there's quite a bit of Bonsai functionality that's not codified into the schema: Drawings, Linked Aggregates, Arrays, Parametric Roof/Stairs/Railing and Status.. but it's saved in the IFC through a json dump into a custom Pset. I think anything, it seems, prefixed with a bbim_.
What would be interesting, since i think standards are important, would be to initiate some effort to start standardizing these psets between open source tools. Namely, at this point Bonsai and FreeCAD. The idea was brought up here.
I could see potentially, over time, as these psets became more standardized in the open source ecosystem, that it would be an easier sell for them to be more officially codified into the BS standard.
Standardizing is fine, but it's about finding ways to fit Bonsai 'features' into the existing Ifc schema, or else... https://xkcd.com/927/
As someone who already uses Blender, using more of it would be a welcome development for me. Better cloning, using collection instancing to materialize aggregates, better non destructive modelling, would definitely be improvements I'd like to inherit from Blender.
But as CSN mentions it is a monstrous task to replace the hole infrastructure Blender provides (3D viewport, rendering, navigation, UI, interaction, keymaps, etc.), though the UI, as much as I like it, is indeed not the most adequate for Bonsai in some aspects.
That is interesting, I did not know it worked that way, and sounds pretty close to what I had envisioned, minus the drawbacks. Also similar to how Inkscape is doing non destructive features, if I understand correctly. Good to know.
Standardizing psets would indeed be a worthy goal. Another development I'd hope to see some day would be "democratizing" the authoring of these parametric geometries, making it more accessible to end users to expand them, rather than be limited to some hardcoded features. Maybe through some coding, or ideally eventually through a more graphical UI.
Fantastic discussion. First, a bit of history. For the first 2 years of Bonsai, we were not IFC native. We used Blender, and imported and exported like everybody else. Then the project basically started from scratch being IFC native. Within a year, we had reimplemented and overtaken existing functionality. In the second year, we had surpassed industry capabilities in 4d and 5d that wouldn't have been possible if we were just Blender. Now, thanks to IFC, we're getting native solid modeling akin to FreeCAD mixed with meshes all in Blender. I have no regrets. More fun history here https://community.osarch.org/discussion/1652/happy-4th-birthday-blenderbim-add-on-by-the-numbers
In the present, we already do a lot that is either IFC pioneering (constraints in parametric 4d and 5d), or stretching the IFC definition (drawings, annotations), or completely not native IFC (stair, railings, sverchok, CSS). The fact that some people didnt realise this was the case is awesome, but perhaps scary too.
In the short run, surprisingly there is still a ton of native IFC we havent yet fully implemented. I mean, look at parametric, prioritised wall layers. Look at circuits and MEP connections. Look at aggregated types. Look at alignments. Look at.. work orders, event triggers? Yikes! We only just caught up on item editing, boolean hierarchies... there's so much more to discover.
In the long run, increasingly more things will be built that is not native IFC (the spec is limited!). This is a good thing. It's also a good thing that IFC cannot do these things , because IFC is in my opinion not really about interoperability... IFC is about standardization. International standardization has a very clear scope: for us to agree of defining the common terms of our built environment globally. So ACME stair generator 2.0 is out of scope of IFC, and that's totally OK. We don't want to standardise that stuff... things like parametric systems, design philosophies, user interfaces, let it all be flexible. The great news is that IFC can reference external systems, so you can have a totally custom design system whilst still being native IFC.
Inkscape is a great parable. But there are differences in the details. For example Inkscape embeds their schema within SVG using their own attributes. This blurs the line between spec and custom. In IFC we can do that too (e.g. parametric railings in a pset) but we don't need to. Instead we can reference external sources (e.g. blender materials, CSS styles, SVG layout documents, ODS spreadsheets), which we already do. This is allowed and appropriate in IFC (they have specific classes to do exactly this). In the long run, these external integrations will get more sophisticated. Slowly, things with merit will transition from purely custom to defacto standard, and if truly universal, to ISO standard. We're in an industry where some fundamentals really don't change much over the decades.
Tldr, standardised fundamental data schemas about our built environment and highly custom external systems can coexist and complement each other. Hooray!
Well that certainly puts my fears to rest. And to think I even doubted your ingenuity for a second.
So basically IFC tries to standardize how data should structured, but doesn't necessarily limit us on what data we can and cannot save. Not being at the whim of schema builders for our growth is much more reassuring.
Forgive my ignorance, about these matters, I lurk around in these forums a lot, but my knowledge about all this is pretty much theoretical at this point. Thanks for the reply, this has been enlightening .
I don't think this is said enough around here, but you guys are doing gods work with Bonsai. Thanks to Dion and all the other developers I don't know by name for keeping this alive and growing.
Hi all, I am also a lurker/learner on the platforms, I was wondering what the impact would be of IFC5 on Bonsai? This questing is totally due to my developer/programming ignorance.
An area where I think IFC is going down is rabbit hole is the creating of all the “IFCType” and “IFCElements” without grouping them into a trade. I understand all these IFCTypes are required for their specific attributes, but it has the potential to create an overload.
As per the attached screenshots
Fully agree that there should be a standardisation of Psets which then maybe becomes an attribute value. It is important we don’t over standardise this limits creativity and problem-solving skills.
All and all Bonsai is something special and well done.
I've also wondered how much of Bonsai will have to change whenever a new IFC version comes out, particularly if we started building a lot of non standard stuff on top of IFC spec.
But I guess that is a question no one here can objectively answer beforehand, because that will probably depend largely on how much the IFC changes from version to version.
My uninformed guess is probably not much impact, both because the IFC shcema will not change that much (as Dion said, fundamentals don't change that much throughout the years), and Bonsai is robustly built, (from what I gather the developers know what they are doing, so changes will hopefully be manageable).
I'd like to add that in FreeCAD we have also become nativeIFC. And we do the exact same thing ("standard" IFC structure + custom data that "only FreeCAD reads and uses"). We're still at baby steps compared to Bonsai, no linked documents yet, etc. But the inkscape analogy makes a lot of sense to me.
I think the best answer here is what @theoryshaw proposes, start unifying and publishing "parametric conventions" that both (and hopefully later others) projects could adopt. For example, a series of Psets with description of what parametric behaviour is expected of each property, so applications have a clear path to follow to implement them. A kind of "open source side B" to IFC
The foundation of the native IFC approach is IfcOpenShell (https://ifcopenshell.org/) - toolkit or API for efficient work with ifc files. This is the backend for borth Bonsai and FreeCAD ifc capabilites and some other tools as well and the part that needs to be heavily adapted with every new ifc version. The tools themselves not so much (at least in theory).