Thoughts on using IFC.js and IfcOpenShell in combination?
I was wondering whether anyone has tried roundtripping IFC files between IFC.js and IfcOpenShell? This could be particularly useful for leveraging the strong authoring capabilities of IfcOpenShell while at the same time taking advantage of the extreme speed of IFC.js. I guess there are some issues that have to be overcome (like IFC.js holding the model client-side), but those seem to be manageable. Has anyone here tried to use both in a single project?
Cheers!
Tagged:
Comments
Interesting topic! I think that once you are working on a webapp, that determines the type of libraries you'll want to use (JS or wasm), such as IFC.js. Having said that, I recently needed to use Python from a Node.js backend (not in particular to use IfcOpenShell, but an ML library), and achieved that by using node's
child_process.spawn():https://github.com/cvillagrasa/speckly/blob/main/src/discord_agent/index.js#L27
Roundtripping IFCs will work with any native IFC software, including IFC.JS, IfcOpenShell, and Homemaker. The issue here is how exactly you'd like to integrate IFC.JS and IfcOpenShell. IFC.JS's strength is in web-based visualisation, not authoring. IfcOpenShell's strength is in non-geometric authoring, and through the BlenderBIM Add-on interface, its strength is also in geometric authoring.
From a geometry perspective, IFC.JS's speed will likely come with a technical sacrifice for geometric authoring. In the BlenderBIM Add-on, although it takes longer to load, once it has loaded, moving around / editing bunches of objects or portions of objects are easy and fast. That's because Blender's geometry systems are designed for editing, not viewing. So it's probably not possible (or at least not easy) to magically get the best of both worlds, the "viewing-optimised" speed of IFC.JS with the "editing-optimised" speed of Blender. Actually, when it comes to large federated models, if you process it in Blender for the purposes of viewing, Blender is significantly faster than IFC.JS - but again, it comes with the trade-off that you can only view, not edit geometry. For example, I can completely load 1GB of IFC data in only 10 seconds and walk around like a FPS game in Blender.
Note that so far, we're discussing Blender's geometry system, but remember that IfcOpenShell is agnostic of Blender. So what happens if you use IfcOpenShell without Blender? Well, that's what Xeokit does, and the results are even faster than IFC.JS once the preprocessing is done.
You may be interested in this study done to see exactly how much each open source technology currently is capable of scaling: https://github.com/IfcOpenShell/IfcOpenShell/issues/2224 - yes, I know you were originally talking about speed, but speed is related to scale. IFC.JS currently has a bit of a way to go compared to existing solutions that lack the marketing capabilities of IFC.JS - not saying IFC.JS can never be on par, just that at this point in time, it's not quite there yet. Logically, since IFC.JS is optimised for viewing, I would expect IFC.JS to at a minimum surpass Blender sooner or later.
When it comes to non-geometric authoring, each tech can really start to play to their strengths. Using IFC.JS as a visualiser, coupled with maybe a web-based gantt chart, spreadsheet, or series of input forms or tables, I reckon IfcOpenShell would be very well suited to work in combination. IFC.JS last I heard lacked things like inverse attributes, which are critical for making edits across the IFC graph. I think @myoualid has done work on this already.
Wow, thanks for the verbose answer! Some really good points you made, I'll try to address the points individually :)
First of all, I agree that IFC.js' marketing is on another level (which I feel is crucial if we want to see exciting, monopoly-breaking software emerge in this industry) and at times it's a bit hard to get a good grasp of its downsides because of that - you pointed out the lack of authoring capabilities, which is probably one of its strongest drawbacks as of now.
As for the Blender/IfcOpenShell combination, I think the one big disadvantage is that it ties you down to a rather bloaty piece of native software. So if you want to go ahead and develop something on your own based on the OS libs out there, especially web-based, that's not an option (which is unfortunate, because BlenderBIM is awesome and extremely powerful in what it does, with some drawbacks).
Using IfcOpenShell+Xeokit isn't something I've considered so far tbh, maybe because Xeokit lacks the social media firepower IFC.js has. Though it seems like Xeokit also lacks the tools for geometric authoring ? At least that's what I'm gathering from their FAQs. In any case, I'll start playing around with it.
With regard to IfcOpenShell's authoring capabilities - I thought I'm able to author geometric objects programmatically? Does that not count as geometric authoring?
Again, thanks for going into so much detail (seems like other people are finding this discussion insightful as well, great!)
Cheers
Thought I'd mention, but you might know already, that every single feature in the BlenderBIM Add-on is first built in IfcOpenShell, and only then exposed through Blender. So pretty much everything you can do in the BlenderBIM Add-on, you can do it without Blender. So you could recreate the BlenderBIM Add-on purely using a web interface if you wanted, that pings a local web server. People have done this already, and built little local dashboards. The new IfcTester webapp I'm doing does this too.
In theory you could even compile IfcOpenShell to WASM and replace portions of IFC.JS (i.e. the IFC portion only, the rest of the browser rendering code is still a huge ton of work) and do things client-side (see https://github.com/IfcOpenShell/IfcOpenShell/issues/2265 ) but nobody has done this yet, so it's all speculative. I probably wouldn't call Blender bloaty, it's a tiny fraction of the filesize of proprietary equivalents (Autodesk software is regularly multiple GB) despite having equivalent features, and loads in a fraction of the time (a couple seconds on my machine).
If you're developing for the web, you'll need a server call somewhere if you want to use IfcOpenShell. This has been done with the BIMServer options linked in the previous post, and currently have much better performance than IFC.JS. However, nobody is actively developing it for years so unless you're a guru with this stuff like Lindsey, the guy behind Xeokit and a lot of the BIMServer stuff, it's probably not appropriate. If you're developing for the web and using a server call is acceptable because you're not editing geometry, then mixing IFC.JS and IfcOpenShell would be awesome. If you're developing for the web and want real-time offline and/or client-side IFC manipulation, then IFC.JS is the way to go.
Xeokit, when judged from the authoring perspective, is significantly worse than IFC.JS - it's not designed for authoring, it's designed purely for viewing, and the optimisation trade-offs show. Any IFC data to be shown in Xeokit has to be preprocessed, and this is a one-way trip.
When I talk about geometric authoring, I mean user-friendly geometric authoring :) There is a huge amount of work to do to decide how to expose authoring to the user - which although "it's just an interface", it's still a huge undertaking. Rebuilding some of the interface capabilities that comes out of the box in Blender on the web is a mammoth task. Really excited for anyone doing it, but just like the rest of us here, it's a marathon.
I have linked back to this discussion from https://wiki.osarch.org/index.php?title=IFC_-_Industry_Foundation_Classes#Software_Libraries_for_working_with_IFC
Maybe could be useful https://gitlab.com/evifist/dataportal