Three.js: IFC importer for threejs

forgot to mention that it depends on ThreeCSG

Never heard of this format. Where is it usually used?

As far as I konw, It's used mainly in the construction business, building modeling. Supported by Autocad, Revit, Tekla and Solibri to mention a few.

I see I see!
What does it need ThreeCSG for?

For example; a Wall object (extruded shape in threejs) might have an opening. And the easiest solution I found was to use ThreeCSG. Also used in other cases like IfcBooleanResult.

Link to the IfcOpeningElement spec:
http://www.buildingsmart-tech.org/ifc/IFC2x3/TC1/html/ifcproductextension/lexical/ifcopeningelement.htm

you can reference at
http://www.ifcquery.com

@mrdoob , IFC stands for Industry Foundation Classes and is meant to be a standard exchange format for Building Information Model/Management (BIM) projects. Software packages typically related to this are Revit, ArchiCAD, VisualARQ, and quite few others. While I am generalizing, BIM software provides standard object types such as walls, slabs, roofs, stairs, windows, etc all driven by a family/style definition where the operator defines the parameters for the object. Therefore if I have a wall with a layer of CMU, Plasterboard, and Tile, I can define the thicknesses of all of the layers. I something changes, I change the family/style definition, and everything automagically updates! Reality is not so magical! It is a contentious format, as each software vendor is free to play around with the definition of what a wall may constitute in import/export http://buildingsmart.org/compliance/certified-software/.
It is a great format to support, and I thank @kdilayer for setting it up. @johnney88 is that viewer using threejs?

Yes, The Viewer use Threejs.
The saved file 'ifcquery.min.js' is writed by Three.js, but it is encoded.

I can confirm that ifc is used in ConSci. I actually used an ifc converter app to convert my companies files into .objs with .mtl files and they read really well. So taking out the middle man would be really helpful since our customers tend to upload ifc files anyway

@rhairston An ifc converter app?It can convert ifc file into obj file so that Threejs can load it well.
Am I right?

here is an ifc converter app?

Thanks everyone for chiming in!

@kdilayer a PR would be great. Please, include ThreeCSG too 😊

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.

Hi kdilayer,

I am very interested into having a look and taking it further.

Hi everybody,

I've seen that too https://www.npmjs.com/package/ifc-convert
With that you can convert IFC to DAE, OBJ, STP and IGS.

@kdilayer Any progress ?

@kdilayer Any progress here? It will save a lot of things if three.js could support IFC format directly.

@dslwz2008 https://github.com/mrdoob/three.js/issues/9860

Nobody has any news ?

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 2x3 files that it cant render... largest file that I've tried is 180 MB...
Awesome.

Hey, awesome work!
Can this be accessed directly from master branch or the tweaked code for IFC support sits somewhere else?

Yer ! Awsome ! How can we have access to this loader code, please ? :o

I vote for a PR 😊 . THREE.IFCLoader would be a great contribution!

We would love this feature as well, for now, I'm converting IFC files to obj with https://github.com/IfcOpenShell/IfcOpenShell, but some more complicated geometries are still not parsed, so sometimes is the object, not 100% complete.

Hi, I was wondering if you were able to get some of the complex things such as doors and transparencies with windows loading in your viewer and loader. It looks awesome so far! I'm curious if you planned on putting out any version of this in the near future.

Good luck!, Thanks for updating.

Hi @kdilayer, could we please have access to your application?

I'm interested to see the file size difference between .ifc and three.js formats.

Thanks!

@Foosballfan I think an IFC is not an interesting format for the size, since it's very verbose. It's just an exchange format for architecture software like AutoDesk.
It's a standard of BIM. (ask to google this term which is famous in this kind of profession)

@jean-noelp Thanks for the reply.

I have an ifc file for a building which is 34MB and am trying to display this data on the web with the smallest possible download size.

With Unity WebGL I can get it down to about 11MB but would like to see whether it is possible with more pure WebGL using Three.js. Hopefully I can achieve an even smaller download size.

Do you have any experience with a similar situation?

@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.

@donmccurdy That looks great, thanks!

I'll give it a go and see how it turns out.

I originally gave up on obj as the one I made is 220MB from the 34MB file.

Closing the issue since @kdilayer is obviously not willing to share his implementation. I've added IFCLoader as a task to the loader wish list in #5524.

As long as there is no IFCLoader, try to convert IFC files to other formats like OBJ. Looks like the following tool can perform this conversion: http://ifcopenshell.org/ifcobj.html

Also see https://github.com/IfcOpenShell/IfcOpenShell

@Foosballfan : IFC is the most efficient way to compress geometry. Problem is, the procedural approach required to render it is not really compatible with triangles. A 34MB IFC can easily extract to a 4GB of triangle streams. IFC describes an elbow pipe with just 4 vertices, but it will take hundreds of triangles to render it. One look at the OP's renderings, and I can tell there is no spoon. Sure, he can do straight lines and one axis toroidal shapes. But, IFC specification includes definitions of a surfaces swept by two bezier splines. So, it's 8 3D vertices defining a practically infinite set of triangles. Architects love that tool, but even rendering a 2D representation of it on a computer is problematic, since the formula doesn't allow thef(x) = y approach.
Here, have a look at official IFC specificatoin: http://www.buildingsmart-tech.org/ifc/IFC4/final/html/schema/ifcgeometryresource/lexical/ifcbsplinesurface.htm

@kdilayer are you still active on github ? would you like to share your implementation ? :ok_hand: Thanks !

The approach I settled for was to use BimServer for streaming the binary IFC data and then constructing it in ThreeJS. The download size over the web socket is satisfactory and I have full control over the model in Three.

You can take a look at the way BimViewer works as a starting point.

any answers?

@Joao-b4 What about?

about a possible IFC loader

Ah, I guess it's up to @kdilayer...

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.

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)

thanks, an ifc loader would be really useful, and i need one right now, i'm using what they mentioned above, to convert to OBJ, but i don't think it's the best way

This was 1.5 years ago so my memory is rusty but I believe our solution was to use bim server to deliver the geometries from the server and then use Three on the front end to handle the rendering.

It took a bit of messing around but eventually worked.

IfcConvert is an IfcConverter for Node.js. It converts from .ifc to .dae, .obj, .stp and .igs. I didn't try it yet, but if it works as described, I guess we would not need any .ifc loader in Three.js anymore, right ?
.ifc contains much more information than just the 3D model, but as far as Three.js is concerned, only the 3D model should be imported.
For an exporter, this would be different, as one could want to export his own BIM library in an .ifc file, alongside the actual exported 3D model.
Does it make sense ?

It still could be interesting to directly load IFC into the browser without the need for a separate conversion tool. However, the mentioned node.js tool is just a wrapper around IfcOpenShell. So it does not do something really new...

I think the import workflow through IfcConverter could be good!

On the contrary, the ifc export does not make any sense for me, because you loose every relevant ifc data (architectural components, BIM stakeholders...) in a lambda Three.js viewer, unless to build an Ifc Editor with Three.js.

@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).

I find a TOOL, IFC can be resolved ,
It's not free ，
But parsing IFC structure is free and open source
http://www.apstex.com/

Greetings, theare aren't any news from @kdilayer right? he never released the source code?

? 

------------------ 原始邮件 ------------------
发件人: "Daniel Ramos"<[email protected]>;
发送时间: 2020年5月28日(星期四) 晚上10:08
收件人: "mrdoob/three.js"[email protected]>;
抄送: "漏网de鱼"<[email protected]>;"Comment"<[email protected]>;
主题: Re: [mrdoob/three.js] IFC importer for threejs (#9764)

Greetings, theare aren't any news from @kdilayer right? he never released the source code?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

any news about this ?

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.

@agviegas looking forward for what you do with it ! a PR could be really welcome

Indeed! @agviegas we may get more people helping on it if you do a PR with it 😍

Unfortunaltey I was unable to release my work on the ifcimporter, but I can help @agviegas

@mrdoob That sounds great. I am still working on the core functionalities of the parser; it can already load all spatial structure elements and I will start building the geometry soon. I suppose that the code also needs to be adapted to this before doing the PR. Is there any references to check to prepare the code for the PR? We can do this whenever you want. Any help regarding this will be welcomed.

On the other hand, the IFC format is very easy to implement, although it can be a little intimidating because of the harshness of the official documentation. I consider that I know the IFC format relatively well, so if anyone is interested in participating, we can surely get this ready sooner. 🙂

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.

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. 🙂

@agviegas Excellent!

@agviegas Very well done!

As for ideas for property management. How are you storing these now? Just as userData on the meshes or geometry I suppose?

Most of our customers use software like HiCad or ArchiCAD for their modeling and they store A TON of information that is very important for the constructionworkers (thermal density, wind resistance, measurements, weights, etc. etc.).

I'm also very curious about the parsing/loading speed. The models I've tested my implementation with take about 5 seconds to parse, but to generate the geometry, the process takes nearly 2 minutes to convert to a DAE model. (I'm converting it server-side due to the lack of time and experience on my end :sweat_smile:, which is why I'm so excited for this loader to work 'natively')

@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.

@agviegas that sounds awesome!

I've tried cloning the main branch of your repo to test some of our customers models, but unfortunately every single one of them produces an error in the console about _ExpressId is undefined (not all models are 100% coherent when it comes to referencing records that actually exists). I think some CAD software don't clean up references nicely to removed properties.

I could share some of these models with you, but we'll have to do that privately. You can reach me at [email protected] if you're interested in some more test cases of models exported with ArchiCAD or HiCAD.

@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! 👍

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.