IFCLoader: Geometry optimization, select, hide and property fetch

[agviegas]

This PR is one of the big ones. From now on, any user can create a complete IFC viewer using the IFCLoader:

• Geometry optimization: IFC files can contain hundreds or thousands of objects, and this caused larger scenes to have lag in the previous implementation. It is now possible to load scenes of hundreds of megabytes at 60 fps. This optimization is achieved by mixing all the meshes into one. Obviously, this makes accessing the individual objects more difficult; for that reason we have implemented additional methods that allow the user to continue working with those individual objects, even if they have been merged. This methods include:

• Object highlight: where the user can choose the highlight material.

• Object hiding: using shaders.

• Object property selection: finally, we are able to get the metadata of the IFC and all its information (materials, construction characteristics, price, etc).

• IFC spatial structure tree retrieval: users can easily get all the tree of entities of objects in the scene to create visual menus that show, for example, how many floors the building has, which objects belong to each floor, etc.

[mrdoob]

Thanks!

[mrdoob]

@agviegas What do you think about adding a IFCScene (extends Scene) class inside IFCLoader.js?

I think these methods would be more fitting in a IFCScene class and IFCLoader's parse could return a IFCScene.

[agviegas]

We can do it, but we handle all IFC models centrally 🤔 if the IFCLoader returns an IFCScene, how would it look like for multiple IFC models? Having multiple models (one for architecture, other for structure, other for HVAC, etc) is the commonest use case.

[mrdoob]

You mean that the developer uses a single IFCLoader to load multiple files and then they manipulate all these files via that single loader?

[agviegas]

Yes, because when you instantiate the IFC Loader, you are also instantiating the WASM parser, which occupies some space in memory and needs some time to initialize. The idea was to use the Loader as an API to interact with the models (e. g. access individual objects of the IFC or their metadata). In BIM there are several operations where the IFC models are closely coupled, and this is the reason behind centralizing everything in the IFCLoader instance. The library works like a database in memory, and having it all toguether helps us manage everything more efficiently. But maybe there is another way of doing this! 🙂

[mrdoob]

Maybe adding a reference to the wasm library in the IFCScene class?

[agviegas]

Ok, sounds good! Where would the IFCScene class be? In the same file? Just to be clear, the user would have a different IFCScene for each model (even if they belong to the same building), right?

[agviegas]

Btw we were actually planning to update the IFCLoader and the types this weekend, so we can include this right away.

[mrdoob]

Ok, sounds good! Where would the IFCScene class be? In the same file?

Yep!

Just to be clear, the user would have a different IFCScene for each model (even if they belong to the same building), right?

It could also be a IFCModel (that extends THREE.Group). It just seems more intuitive to me to have these methods in the actual "data" than in the loader.

Btw we were actually planning to update the IFCLoader and the types this weekend, so we can include this right away.

That'd be great!

[agviegas]

Actually the term IFCModel makes more sense and is more coherent with the IFC domain. Can we use it instead of IFCScene?

[mrdoob]

Yeah, IFCModel extends THREE.Group.

[agviegas]

How does this look @mrdoob? mesh is the IFC.Mesh, and ifc gives access to all the functionality to interact with the IFC file. Here you can see the IFCModel being returned.