Problem when rendering IfcBuildingElementProxy which are rectangle extruded shapes about web-ifc-three HOT 8 CLOSED

Short outline of the problem: IFC has enough precision in its serialized form to represent rather big numbers (I guess doubles), combined with allowing composition of transformations, which makes it possible to accurately represent quite large distances. When reading in the IFC, we convert it to (less accurate) floating point, for two reasons: it uses half the memory, and your GPU can't handle doubles anyway, so you there's no reason to keep them around.

Normally this is not a problem, but if the IFC model is far away, the coordinates are too big to be represented accurately in floats, and you get the kind of distortions visible above. What we can do to prevent this is apply a transformation before converting to floats, this way all the numbers are small and floating point accuracy is sufficient. This is what happens with the COORDINATE_TO_ORIGIN flag in web-ifc, which basically takes the first point in the IFC and translates the entire model such that this first point lies at the origin (0,0,0).

The trouble is that you then lose the relative positioning of models if you attempt to load in multiple, because they are now all coordinated at the origin. This can in turn be solved by partially undoing the first transformation, by reapplying the original relative transformation between the models. It's a little annoying, but not particularly complicated, and requires some more code in both repositories

A neater way to do this is to look at the transformation of the site, and apply the inverted transformation to all elements in the model. This way you can choose to transform all models identically and they will appear correctly relative to eachother. This can be done right with the current web-ifc code, but only works for models where the site is far away, I'm not sure if that covers all cases.

There's probably more ways to solve this problem, let me know what you think.

from web-ifc-three.

Maybe web-ifc could give us how much it moves it when using COORDINATE_TO_ORIGIN.
So we can adjust for it when loading next file ?

from web-ifc-three.

@favreau84 In terms of side effects: the hierarchy of objects is separate from their placement, so the modification you did should be correct. However, obviously I would like to solve the problem without modifying the IFC 😄

I will look at a way to easily do what @vegarringdal suggests, there's already an open issue in web-ifc about this, and it sounds like a very good idea.

About the inverted transforms: I think you should forget about the idea for now, the only advantage on top of the COORDINATE_TO_ORIGIN is that you can visualize multiple far away models that are also far away from eachother, which is a different edge case. What you did with the site is essentially the same thing: undoing the transformation of the site for all elements.

from web-ifc-three.

Sorry, we forgot to mention it here with all the fuss of this month 🙂 It's already solved in the current version. You just need to use the following code, and the model should display in the origin, thus solving the nummerical stability issue:

       ifcLoader.ifcManager.applyWebIfcConfig({
            COORDINATE_TO_ORIGIN: true,
            USE_FAST_BOOLS: false
        })

The USE_FAST_BOOLS flag has nothing to do with this problem, but it's necessary if you want to stick to the config object typing. 🙂

from web-ifc-three.

@tomvandig , great, it was exactly that. The ifcSite was indeed far far away from the origin of the WorldCoordinateSystem.

I found an article which is describing this discrepancy problem : here

Quick & dirty

As the article suggests, I manage to display correctly the model by setting from the editor the origin of the IfcSite to 0,0. I don't have enough knowledge on the location inheritance between Project>Site>Building>Storey>... to identify side effects, but the model is displayed correctly.

COORDINATE_TO_ORIGIN

That's a clear and simple to understand solution. Is it possible to call this flag with the web-ifc-loader ? As @vegarringdal suggests, getting the transformation as an output would be great to adjust next loadings.

Inverted transformation

@tomvandig, my understanding is way to superficial to provide any feedback on this option. When you say that the inverted transformation can be applied to every element, does it mean that the coordinates of the relative placement of these elements will then become large numbers ? Don't we fall back in the same scenario ?

from web-ifc-three.

@tomvandig , great ! Is the COORDINATE_TO_ORIGIN implementation intended to be called from web-ifc-three at some point ?

from web-ifc-three.

Please see https://github.com/tomvandig/web-ifc/blob/main/examples/usage/src/coordination.ts for an example how you can retrieve the coordinated position.

from web-ifc-three.

@tomvandig , great ! Have you scheduled to implement it for the web-ifc-three lib ?

from web-ifc-three.