OSArch Community

IFC > WEBGL

1. D by DADA_universe on 17 Dec 2020, edited 17 Apr 2021 # +2 votes

   While many projects we discuss tend to be targeted at AEC professionals, there is also a need to communicate with non technical people who need more interactive ways of engaging with BIM.

   WebGl provides an opportunity to do this. I've looked into this for a while and generally speaking, Babylon.js seems to be a preferred choice for an open source library for putting up content on the web. Of course there are pros and cons, but the fact that it works with fewer lines of code (in Javascript or Typescript) and is simpler to work with, seems to give it an edge over Three.js. Another close contender is the Godot Game engine, which is also good for cross platform authoring. Godot has the added advantage that it is even more painless to get a 3d model into it, from Blender for example.

   Seeing these example projects also really got me interested in Babylon.js for this use case:

   Example 1,

   Example 2,

   Example3.

   While there's ifc.js, a Three.js library that allows you to view ifc files in the browser, I'm yet to see a similar library that does this with Babylon.js, well, apart from Tridify, if you're signed in to their monthly payment plan. I've also not seen any project that attempts to read .ifc files in Godot. I would definitely like to know if stuff like that exists.

   I'm also curious to know how this might be implemented in Godot and Babylon. I'm aware of the thread on parsing .ifc files to JSON. Would this serve in some way? How does IfcConvert work? If you convert an Ifc to a .glb file (which both Babylon and Godot support), will you only be carrying along the geometry? Will the metadata be stripped off? If so, can you use both IfcConvert and IfcCSV to ferry both types of information across? It would have been so handy to integrate this right inside Blender, but with the game engine ripped out, Armory Engine still in limbo and UPBGE not supporting WebGl export, I see these two external tools as likely options, but not sure how that can (or should) happen.

2. B by bernd on 17 Dec 2020, edited 17 Dec 2020 # +1 votes

   Are you aware of http://view.ifcopenshell.org/ It is based on ifcopenshell (IfcConvert), bimsurfer and flask.

3. D by DADA_universe on 17 Dec 2020, edited 17 Dec 2020 #

   @lukas's post here might need more attention.

   I had a look at BOT and my immediate reaction is that it does seem less complicated than IFC and might just be able to do what Speckle promises with less complexity. Would love to have more people weigh in on it with reference to my first post here.

   I've looked through the live demo and the draft w3c specification and all did look accessible and full of potential.

4. D by DADA_universe on 17 Dec 2020 #

   @bernd said:

   Are you aware of http://view.ifcopenshell.org/ It is based on ifcopenshell (IfcConvert), bimsurfer and flask.

   Thanks, good to know of this. Having a look.

5. M by Moult on 17 Dec 2020 # +1 votes

   To clarify, in case there are some confusions here: WebGL is a lower-level technology which is then used by higher level technologies like ThreeJS and BabylonJS, or BIMSurfer (v3). Then, there is the method of transferring IFC data. Typically data transfer is split into two parts: geometry and metadata. The geometry transfer is quite restrictive (and the restriction depends on sever->client, or just client-based), as to ensure scalability binary formats like glb are preferred. If it just client-based, like IFC.js, another paradigm can be used and IFC data can be parsed directly. Both paradigms have pros and cons and are suited for different usecases. Transferring metadata is generally more flexible. IFC-Pipeline (view.ifcopenshell.org) uses XML. IFCJSON is a contender, but a little unstable right now. For pure client side, none of this applies.

   I haven't looked into BOT.

6. D by DADA_universe on 27 Dec 2020 #

   @Moult said:

   To clarify, in case there are some confusions here: WebGL is a lower-level technology which is then used by higher level technologies like ThreeJS and BabylonJS, or BIMSurfer (v3).....

   Spot on.

   My bias is for BabylonJS, and I'm more interested in a client based implementation at the moment.

7. D by DADA_universe on 27 Dec 2020 #

   Found this: https://xeokit.io/

   It's 'open source' but you have to pay for commercial use.

8. M by Moult on 27 Dec 2020, edited 17 Apr 2021 # +2 votes

   @DADA_universe Xeokit has been the subject of a bit of controversy. The author, Lindsay, is making a false claim about it being open source. It is not open source and he has agreed to remove his marketing claim, but despite numerous reminders, has still failed to do so. Edit: recently, the author has modified the license, so now it is open source, hooray!

   Xeogl, however, is open source.

   It is also not client-based.

9. D by DADA_universe on 28 Dec 2020 #

   @Moult said:

   @DADA_universe Xeokit has been the subject of a bit of controversy. The author, Lindsay, is making a false claim about it being open source. It is not open source and he has agreed to remove his marketing claim, but despite numerous reminders, has still failed to do so.

   Xeogl, however, is open source.

   It is also not client-based.

   Ah, I see, the licensing did seem odd.

10. D by DADA_universe on 17 Apr 2021 #

    Linking here for reference, to a separate discussion on the same subject and subsequent progress made with parsing IFCs through IFC.js and Babylon.js

11. D by DADA_universe on 17 Apr 2021 #

    Ditto an unfolding experiment with Godot.

Login or Register to reply.