Define the origin of the model as being the origin of one site

[favreau84]

Context

-When the site origin is far far away from the world origin, some discrepancies appear in the 3D geometry (example : https://github.com/IFCjs/web-ifc-three/issues/30). -Thanks to the COORDINATE_TO_ORIGIN:true config, a new model's origin is computed (let's call it IFCjs origin), the model is loaded in Three.js with the origin positioned at (0,0,0), and the discrepancies disappeared.

• From the ifcAPI.GetCoordinationMatrix, we can access to the IFCjs origin in the world coordinates system.

Problems

Problem 1

• The discrepancies do not disappear for all the models.
• Example : station.ifc.zip

Problem 2

• Use case : I need to load several models sharing the same ifcSite in three.js.
• Problem : I have to compute one additional translation based on the ifcSite origin position for each model in order to place them correctly with respect to each other.

Possible solution to solve 1 & 2

Solving Problem 1

• When I manually modify the ifc file, taking (0,0,0) for the ifcSite position coordinates, all the discrepancies disappear.
• Here is the modified ifc. Just one line changed : (expressID: 638645) station_0.ifc.zip

Solving Problem 2

• Setting the ifcSite position to (0,0,0), the model geometry is located at the right place for models that share the same ifcSite.

=> Solution

• With one new loading option, the model would be loaded as if we would have manually reset the ifcSite origin to 0,0,0 (cf scenario 3).
• In real life, I've been mosty working with ifc file with only one site (export from Revit...). However, since we may have several sites in one ifc file, we could specify the site to be set at the origin.

[agviegas]

What do you think @tomvandig?

[tomvandig]

How would you propose we choose the site? We can give the user the option to scan the sites beforehand and determine the coordination they want, but this is possible already now, although not easy.

Do you propose that this process should be easier, i.e: get its own API endpoint?

[favreau84]

Hi @tomvandig, as far as I'm concerned, in the vast majority of the ifc files used in a construction project, there is only one ifcSite. So taking the first (and only one) site will definitely solve 99% of the use cases. For the edge cases were there are several ifcSites, well, it's not really a pb : the user will be able to translate the model afterwards from the ifcSite locationPlacement.

In other words, we could have 2 options (already implemented) + 1 additional option to load the model :

• coordinate_to_origin = false
• coordinate_to_origin = true And
• first_site_as_origin = true (or something like that :-) )

Please keep in mind that I'm looking for a programmatic solution to avoid the manual settings of the ifcSite coordinates to 0,0,0 that do solve geometry discrepancies in the model I'm using.

What do you think ?

[tomvandig]

@favreau84

Sounds good, I'll update the ticket when first_site_as_origin (or similar) is in

[loicroybon]

Hello, I opened this issue which seems quite close : https://github.com/tomvandig/web-ifc/issues/91

[autra]

As a side note, it would be really useful if ifc.js would store the chosen offset somewhere in the generated mesh, for instance on .userData.originOffset.

[agviegas]

@autra In the new components repository, we import IFCs as a group of meshes called FragmentsGroup that has a property with the applied matrix 🙂

[sguimmara]

@autra In the new components repository, we import IFCs as a group of meshes called FragmentsGroup that has a property with the applied matrix 🙂

What is the name of this property ?

[agviegas]

@sguimmara it's coordinationMatrix. You can check it out in the flatbuffer schema here!