VYZN: Rendering of individual nodes

[Adrian62D]

Technical changes:

• Currently the rendering happens per-model
• This needs to be changed so that individual nodes can be rendered

This is a precondition to #384, #475, #417

We'll provide a more detailed assessment on this issue.

[Ibrahim5aad]

There are two paths that could be followed. Implementing this as a PR towards IFC.js is tricky for multiple reasons but the most important reason is that the current IFC.js per-model rendering in my opinion is a design choice to reduce the number of draw/render calls to the GPU; one draw call per model. And a lot of their Three.js abstractions and wrappers depend on this design.

To overcome the drawbacks of having one mesh per model, they offer what is called subsets operations which allows for creation of subsets of the model mesh by creating new geometry that copies a specific range of indices from the combined model indexed mesh.

This subsets operations feature is one way we could follow to achieve what we want. [Option 1 in the referenced image]. We let IFC.js load/parse the geometries but interrupt their pipeline at the point they add the mode mesh to the scene, and create a subset per IFC element and add those created subsets to the scene instead.

Second option is about overcoming one drawback for the first option; those subsets are already identical meshes to the elements meshes created while IFC.js stream the loaded buffer geometries, but we don't take advantage of those created geometries, they will be disposed after combining them into the model mesh. So instead of interrupting the pipeline after those meshes are merged, we collect them before they are merged.

Both option will require to break some IFC.js abstractions and some of their three.js wrappers. It's unfortunate that the library don't offer much customizations to how their parsing-meshing-rendering pipeline is assembled. But it shouldn't be a complicated task, the examples already gives glimpses of how to do part of we are targeting, like using subsets to hide elements (of course with breaking some of their out-of-the-box features like selection).

[Ibrahim5aad]

Also to be noted that, the hiding/isolation feature is the one requires this fundamental change. With the current design, we can add colouring, filtering, multi-selection, because fundamentally those features are just subsets operations; generating elements subsets that mimics the highlighting/selection visuals. Unlike hiding/isolation which require access to the element mesh itself not a a copy of it, as well as collision detection mentioned in #248.

[Adrian62D]

@Ibrahim5aad Thank you! @pablo-mayrgundter Do you have a preference regarding these approaches?

[pablo-mayrgundter]

Hi @Ibrahim5aad, thanks for the writeup!

I am a bit confused. I have seen this subset API:

https://ifcjs.github.io/info/docs/Guide/web-ifc-three/Tutorials/Highlighting/

Are you aware of this? Could you elaborate on why this is insufficient and why you think a PR to ifcjs is needed?

[Ibrahim5aad]

Hi @pablo-mayrgundter, actually a PR to ifcjs was not my idea, and I don't think it's required at all. Subset operations are indeed sufficient (with side-effects) to implement the behaviour wanted (it's the first option I'm mentioning), but with breaking some of the higher level abstractions (the ifcjs examples clearly shows naïve implementation of this.)

For example the link you posted shows an implementation of adding and removing highlighting subsets to the scene, which comes out of the box if you decided to use the the higher level ViewerAPI to load the model.

[Adrian62D]

I updated the issue description. No PR to ifcjs needed.

[OlegMoshkovich]

So is the current plan to proceed with Subset operations as described here https://ifcjs.github.io/info/docs/Guide/web-ifc-three/Tutorials/Highlighting/?

[Adrian62D]

This is to be decided. Both options seem similar. Do you have a preference?

[OlegMoshkovich]

Whatever is the simplest way forward. When the data model work is complete we might have to rewrite the feature.