IFC importer for threejs

I have written an ifc 2×3 importer for threejs. It is very experimental but most of the objects will render.

Is this something that can be included in the distribution ? My hope is that someone would develop it further and eventually also add support for ifc4

Example of imported ifc:
ifc-imported

Author: Fantashit

17 thoughts on “IFC importer for threejs

  1. Any progress here? We’re currently converting IFC to DAE for use with three.js, and would love it if three.js supported IFC directly.

  2. I tweaked the editor to supprt ifc files.
    A few screenshots attached. I have worked on this for quite some time now… currently I have not seen any IFC 2×3 files that it cant render… largest file that I’ve tried is 180 MB…
    Awesome.
    screen shot 2017-11-15 at 19 19 31
    screen shot 2017-11-15 at 19 19 20
    screen shot 2017-11-15 at 19 19 08
    screen shot 2017-11-15 at 19 18 45

  3. @Foosballfan to minimize file size, the steps I would try are:

    1. convert to OBJ
    2. run through obj-simplify
    3. compress the OBJ with Draco
    4. load with THREE.DRACOLoader

    If the file can’t be converted to OBJ or another format, then there’s probably not a lot you can do beyond simplifying the model or using gzip… “pure WebGL using three.js” is a way of rendering the file, but you must still use some format or other to get the file loaded first.

  4. I believe that @kdilayer will have nothing, since it has been 3 years since the publication and no response, nor activity on his profile.
    I don’t understand how the creation of a loader works, and I have a little knowledge in the library, I work with it a little while ago, I would have some links to create a loader, I can get enough disposition and knowledge in the future.

  5. I have outlined here a basic scaffold of THREE.IFCLoader. The most difficult part when writing a loader is to actually understand the respective 3D format. Only then you can parse the format and transform the geometry and/or material data into three.js entities (e.g. THREE.BufferGeometry). I recommend to study a more or less simple loader like THREE.PLYLoader in order to understand this process. And of course the IFC standard (https://www.iso.org/standard/51622.html)

  6. @Mugen87 Well, the main added value is the Node package, as to my knowledge IfcOpenShell is online a CLI tool.

    @jean-noelp You are right. I didn’t mean an export of the “master .ifc file”, but rather a “library .ifc file” BIM stakeholders could import in their own “master .ifc file”. For instance you are a garage door manufacturer, use Three.js to plan the installation for your clients (architects, for instance) and export the BIM library containing your BIM objects (typically the garage door). You see what I mean ? But anyway, there would be no way to have this exporter built in Three.js as each particular use-case is way too much specific (I guess).

  7. Hey! A few days ago I started to implement an IFC parser in JS with the idea of applying it to Three.js. This is a personal project that I do in my spare time, so I have no clear idea how long it will take. However, I saw this thread today and thought you may find it of interest. You can find it here.

  8. I suppose that the code also needs to be adapted to this before doing the PR.

    Yes, it should use the same interface the other loaders use. Maybe the MD2Loader is the simpler reference right now.

    Don’t worry about having everything perfect for the PR. You can submit what you have as a draft and we can help making sure the code fits the rest.

  9. After several stumbles and struggles with the format there are already some results. I have implemented the first version of the parser, as well as some of the geometric entities (including extrusions and b-reps). Much remains to be done yet, but I am happy with the results so far. The image below shows a small IFC generated by Revit running smoothly in Chrome. Each geometric instance has the parsed IFC information associated (in fact, in the scene below each instance has a material depending on its cathegory / ifcclass), so creating filters using properties values (Psets and Qsets) should not be hard to archieve from this point. Any ideas or suggestions are welcomed. 🙂

    20201124_screenshot

  10. @haroldiedema I haven’t implemented the property sets yet, but the current data structure consists of a JS object where the keys are the express IDs and the values are the parsed objects loaded in memory. Each property that was an express ID is replaced by a reference to the object with that ID. In the current implementation, each instance of IfcProduct with one or more geometric representations has an additional property called Geometry , which is an array of references to the geometries of the scene. For example, each IfcWallStandardCase has a property Geometry with a reference to the Path (a Line) a to the Body (a Mesh).

    Probably each geometric instance of Three.js will have a property containing the express ID, so finding back the ifc entity loaded in memory (and the related information) will be easy (f. e. when clicking on the meshes in the scene).

    As for the user defined properties, there will be one or more IfcRelDefinesByProperties (or another indirect relationship object) to bind everything toguether. Perhaps each instance of IfcProduct can have an attribute hasPropertySets which would contain an array of the related parsed property sets (I have seen this pattern in other IFC libraries, and this is what I am doing with other indirect relationships such as IfcRelAggregates). I am not worried about the amount of properties as they will be structured according to the IFC, but let’s see how it goes when I get there. 😅

    I am making everything client-side, and currently the parsing takes less than a second and the geometric generation of the last scene shown around 4 seconds. I am aware that with bigger files this time will increase; however, I hope to be able to optimise the system when I have covered more IFC entities and can load IFCs from real projects. 🙂 I will be extending the CONTRIBUTING document, in case anyone wants to dig into any of this.

  11. @haroldiedema I haven’t implemented the property sets yet, but the current data structure consists of a JS object where the keys are the express IDs and the values are the parsed objects loaded in memory. Each property that was an express ID is replaced by a reference to the object with that ID. In the current implementation, each instance of IfcProduct with one or more geometric representations has an additional property called Geometry , which is an array of references to the geometries of the scene. For example, each IfcWallStandardCase has a property Geometry with a reference to the Path (a Line) a to the Body (a Mesh).

    Probably each geometric instance of Three.js will have a property containing the express ID, so finding back the ifc entity loaded in memory (and the related information) will be easy (f. e. when clicking on the meshes in the scene).

    As for the user defined properties, there will be one or more IfcRelDefinesByProperties (or another indirect relationship object) to bind everything toguether. Perhaps each instance of IfcProduct can have an attribute hasPropertySets which would contain an array of the related parsed property sets (I have seen this pattern in other IFC libraries, and this is what I am doing with other indirect relationships such as IfcRelAggregates). I am not worried about the amount of properties as they will be structured according to the IFC, but let’s see how it goes when I get there. 😅

    I am making everything client-side, and currently the parsing takes less than a second and the geometric generation of the last scene shown around 4 seconds. I am aware that with bigger files this time will increase; however, I hope to be able to optimise the system when I have covered more IFC entities and can load IFCs from real projects. 🙂 I will be extending the CONTRIBUTING document, in case anyone wants to dig into any of this.

    Parsing User Defined IFC Property Sets are super-easy. I have a repo that does that. My parser is not as sophisticated as yours.

    However, I have noticed that some properties tend to break parsers. I haven’t used chevrotain, so I’m not sure how your code would hold up. I have written more about these problems here. Hope it can be of some use to you.

    Anyways, very good job so far! 👍

  12. Update: I have deployed the app in Github pages for easier user testing throughout the development. This includes responsive navigation for mobile and tablet support. Also, here you can find an alternative deploy that loads an IFC model on startup; the logic for clearing the scene and adding multiple IFCs is not implemented yet, but at least you can see how the navigation looks. The parsing is made by the client, so the loading times depend on the device used. My laptop makes it in around 5 seconds, while my Moto G5 Plus needs around 50 seconds for this scene. There are still classes to be implemented before loading a full project, but feel free to send me any IFCs to add them to the testing files.

Comments are closed.