BlenderBIM: automatic IFC export when saved

Perhaps this is the ultimate plan, but it would be nice if BB automatically exported the IFC file, every time you hit 'save'.


  • edited May 19

    At the moment it's the opposite - BB saves the Blender file every time you export :)

    Press the file menu, then hotkey "e" then "i" is a quick way to do this. Or you can add it to the quick favourites. You will notice it doesn't ask you for a filename as well which makes it quite fast.

    The logic behind doing it this way around is that sometimes people want to read the file and manipulate it without saving the IFC if they aren't authoring. Perhaps I need to rethink how to do it the way you suggest, without confusing people who just want to view the file.

  • edited May 19


    you will notice it doesn't ask you for a filename as well which makes it quite fast.

    Yes, i noticed that. Under a scenario where there's an IFC attached to the blenderBIM file, how do you do an 'export as'?... that is, export the IFC under a different name, for example.

  • @theoryshaw in the IFC Project panel, just clear the "IFC File" text field. Then it'll prompt you for a new file path when you export again.

    It's pretty crappy UX. Thoughts of how to improve?

  • i guess, intuitively, i would opt to have 'save', both save the blenderbim file, and export the IFC file, in one action.

  • ... and if you, at a later time, wanted to export the IFC as a different name, the file>export>ifc, would work as you would expect.

  • edited May 19

    @theoryshaw I think that is the way to go. I guess right now I have prioritised non-authoring users of BB ... so what would be the behaviour be if I only wanted to import a file, but not edit the original? E.g. if I just wanted to derive something, or analyse it in a "detached" way? I don't want these users to accidentally damage their files or experience very long save times potentially.

    One option is that users can disable authoring mode, but that button is pretty hard to discover...

  • @Moult isn't it an idea to ask the first time after IFC import, when the user wants to save the file, prompt them if they want to save it as a new IFC file, overwrite the imported one, or to not update IFC at all? Save that in the settings, and reuse next time the user saves the blender file.

  • edited May 19

    Well saving 2 files is pretty uncommon and realy troublesome.
    While testing i often found myself with a saved blend where i didn't want it to be saved.
    I guess at least clear settings must be the rule here, like a "export ifc on blender file save" / "save blender file on ifc export" option.

  • @LaurensJN yes, that solution also crossed my mind. I've been trying to minimise popup dialogs as much as possible given that the Blender UX paradigm is "no dialogs!" (which is really quite fascinating to me and I love it!), so let me see if I can pull something together!

  • @Moult, What's your thoughts about saving solely to the IFC and not having a Blender file at all?
    I have found there's a lot of times, while modeling, there's somewhere along the line that I model something that isn't translated into the exported IFC properly.
    The only way to insure that I know the IFC is correct, is to either view it in an IFC viewer, or import it into another Blender session. As you can imagine, this is pretty time consuming.
    How about just taking the stance that IFC is the "first class citizen" and is the only native file of BlenderBIM?
    I know there will be a lot of Blender bells and whistles that will be unavailable, but if the IFC-stance is taken, it would prioritize trying to translate these bells/whistles into the IFC format. It would just be 'clearer' what's supported, and what's not.
    Just thinking outloud--this might not be feasible.

  • In the future, this may very well be the case. However, right now Blender loading is still too inefficient (there are efforts to improve this now, and in the future HDF5 could further improve this) so we need to use the Blender format as a cache especially on larger projects.

    Many of the issues are probably because we simply haven't dedicated too much time to stabilising native authoring. I expect this to drastically improve in the coming release (right now, also switching to v7 branch) where you can start trusting what you see on the screen. I see these as teething issues.

Sign In or Register to comment.