IfcFragmentSettings:coordinate usage?

[onderilkesever]

Describe the bug 📝

Hi,
the ts doc of the property IfcFragmentSettings:coordinate says

/** Whether to use the coordination data coming from the IFC files. */

However, I cannot see any usage of that field in the codebase. I wonder is this forgotten? If not, can you please explain how does it affect the geometries created? I was hoping to set it to true, and my geometries would be in the coordinate system that is used by the IFC file.

Reproduction ▶️

No response

Steps to reproduce 🔢

No response

System Info 💻

System:
    OS: macOS 14.6.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 54.56 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.19.0 - ~/.nvm/versions/node/v18.19.0/bin/node
    npm: 10.2.3 - ~/.nvm/versions/node/v18.19.0/bin/npm
  Browsers:
    Chrome: 128.0.6613.115
    Edge: 128.0.2739.63
    Firefox: 123.0.1
    Safari: 17.6

Used Package Manager 📦

npm

Error Trace/Logs 📃

No response

Validations ✅

• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a repository issue and not a framework-specific issue. For example, if it's a THREE.js related bug, it should likely be reported to mrdoob/threejs instead.
• Check that this is a concrete bug. For Q&A join our Community.
• The provided reproduction is a minimal reproducible example of the bug.

[agviegas]

@onderilkesever you are right, the coordination is on the web-ifc settings. This should be removed!

[onderilkesever]

thanks for the response @agviegas ! Can you please elaborate what do you mean with below?

the coordination is on the web-ifc settings

[onderilkesever]

Basically my end goal is georeferencing IFC files, and I am trying to understand if I need to transform geometries created by the library when IFC is carrying some spatial reference system information.

[agviegas]

@onderilkesever I mean this. When loading an IFC, web-ifc has a flag called COORDINATE_TO_ORIGIN that brings the models to the origin using its first vertex. That way, we avoid nummerical stability issues.

This transformation (which is just a translation) can be found here. You can use this to coordinate models with each other, or to know the absolute location of a building

[onderilkesever]

Thanks for the answer @agviegas, I am not interested about bringing models to origin. What I understand from your comment is that COORDINATE_TO_ORIGIN is there to carry models to the origin (and if second model, to the first one if i am not wrong) that is clear. But I am not following how come this can be also used to know the absolute location of the building? Can you please explain? Thanks in advance!

[agviegas]

@onderilkesever Let's say we have 2 models, A and B. Both are in the absolute coordinates (10,000,000, 10,000,000, 10,000,000).

If you try to load any of them with COORDINATE_TO_ORIGIN=false, you will run into nummerical stability issues. If you google "three.js shaky geometry precision" you'll see what this means. Three.js can provide solutions if you want to work far away from the origin, but I wouldn't do that, as you might find other issues down the line.

If you load A with COORDINATE_TO_ORIGIN=true, our libraries will take the first vertex that it finds and move it to (0,0,0). That means that if the first vertex was (10,000,001, 10,000,001, 10,000,001), and now is (0, 0, 0), the whole model has been translated (-10,000,001, -10,000,001, -10,000,001). This translation is saved in FragmentsGroup.coordinationMatrix. That means that if you want to know the absolute coordinate of any point of the centered model, you just have to make something like point.applyMatrix4(modelA.coordinationMatrix).

If you load B with COORDINATE_TO_ORIGIN=true, the same will happen. But of course, B won't be aligned with A, because centering the model using the first vertex found doesn't keep the alignment among models. So if you want to aling B with A, you will need to:

const transformBInvert = modelB.coordinationMatrix.clone();
transformBInvert.invert();
modelB.applyMatrix4(transformBInvert);
modelB.applyMatrix4(modelA.coordinationMatrix);

This is handled automatically by the library when loading an IFC. If you want to handle this yourself, I suggest you that you keep using COORDINATE_TO_ORIGIN=true (to avoid nummerical stability when computing the geometry), but when loading a new IFC model, apply the inverse of the coordination matrix to the model, and you'll get the model in its absolute position. Then you can do whatever you want with it

[onderilkesever]

Thank you for your detailed answer here @agviegas, I understand the precision issue might occur. But at the same time, we would like to be able to position IFC models in our scene based on their georeference so that our users see the buildings in their correct place in real world. I guess this means the model can be far away from the origin naturally. I guess this could be solved if we could use spatial coordinate systems i.e a coordinate system that is more accurate on some part of the world. And i assume if model was using such coordinate information, we would need to apply set of transformations to our model geometries before displaying. That is why actually I was hoping that this coordinate flag could be useful. But i am afraid it is unused at this point of time. My question is that, do you think such use case achievable with current state of library solutions? If so, how we could achieve without hitting "three.js shaky geometry precision" problem?
Thanks in advance

[agviegas]

@onderilkesever your user only knows where your model is when you show them coordinates. So you basically have 2 options:

• 1. COORDINATE_TO_ORIGIN=true. Bring the model to the center, and apply the transformation to any coordinates (or anything that allows the user to know where the model is) before displaying it. This is the approach followed by most 3D/BIM apps. In other works, you work at the center, but transform the displayed numbers so that the user perceives you are working far away from it. Happy to help you with this if you have any questions. This approach works even if you want to display a GIS underlay under the model using Cesium, Mapbox or a similar solution.
• 2. COORDINATE_TO_ORIGIN=false. Work in global coordinates and use the logarithmic renderer. I strongly discourage this approach. You might find problems down the line where we are not able to help you. But if you really want to go down this route, using that renderer is the way.

[onderilkesever]

Thanks for the guiding answer @agviegas ! I will try your described approach but I have a small follow up question. Now that I am focusing on option with COORDINATE_TO_ORIGIN=true, your example shows that I should be applying inverse coordinationMatrix of the first loaded model to the second one too. I wonder what to do say third model is uploaded? Should I again apply inverse coordinationMatrix of first model to that? Or somehow create a chain? Wouldn't it make sense if each model had their own coordinationMatrix to bring themselves to their original position? I hardly follow the reasoning why latter models has to use first(or all prior) models coordinationMatrix . Thanks again!

[onderilkesever]

Or can I simply pass coordinate as false to my load methods on IfcLoader and FragmentsManager ? Would that allow me tackle models separately(only apply inverse coordinationMatrix to itself, and not worry about previously loaded models)?

[agviegas]

@onderilkesever

wonder what to do say third model is uploaded? Should I again apply inverse coordinationMatrix of first model to that?

Yes, every new model that you load, you have to do that. Apply the inverse of its own matrix, and then the matrix of the model you are using as "point of reference". Keep in mind that this should be automatically done by the library in many methods (the parameter coordinate).

The reason each model has its own coordination matrix is that we use the first vertex found in the model as reference point to bring it to the origin. We do it this way because any other way (e.g. using the IFC spatial structure reference) is not reliable for 100% of IFCs. This is.

Or can I simply pass coordinate as false to my load methods on IfcLoader and FragmentsManager ? Would that allow me tackle models separately(only apply inverse coordinationMatrix to itself, and not worry about previously loaded models)?

You can do that, and models will be automatically aligned, but then you'll run into nummerical stability errors for models that are far away from the origin as described above.

[onderilkesever]

Or can I simply pass coordinate as false to my load methods on IfcLoader and FragmentsManager ? Would that allow me tackle models separately(only apply inverse coordinationMatrix to itself, and not worry about previously loaded models)?

You can do that, and models will be automatically aligned, but then you'll run into nummerical stability errors for models that are far away from the origin as described above.

Thanks for the answer @agviegas, but I do not understand your last sentence. Isn't COORDINATE_TO_ORIGIN=true supposed to bring model to origin itself and supposed to fix stability errors when they are fay away from origin? How come setting the coordinate parameter to false can still have those influence?

[agviegas]

@onderilkesever my bad. What the coordinate parameter does is to apply the transformations as described above, so that you don't need to.

[onderilkesever]

Thanks for quick response @agviegas, I think I understood you correctly, but given there has been too many comments on this issue I would like to ask for your last confirmation just to ensure we are both at the same page.

1. COORDINATE_TO_ORIGIN is the parameter that helps with large coordinates. when set true, coordinationMatrix is holding the transformation applied to the model. so we can apply reverse of each coordinationMatrixto fragments, and that should bring each model to the coordinates that it was created.
2. coordinate this parameters(parameters on load methods of IfcLoader and FragmentsManager) is designed to help coordinating multiple ifc models with respect to each other. And if we would like to manage the locations of the models ourselves, we could safely disable that flag and we can manage the positions by ourselves.
   Are these statements correct :)
   Thanks again for your continues support here, helps a lot understanding library internals.

[agviegas]

That's correct @onderilkesever!

[onderilkesever]

Thanks @agviegas! I leave it up to you to close this issue as the initially reported property is still unused and can be removed.

[agviegas]

Removed from @thatopen/[email protected]!