Incorrect boundary in output GLB manifest

[xeolabs]

Seems there's a bug in ifc2gltf's calculation of the modelBoundsMax and modelBoundsMin in the output GLB manifest.

Having converted the IFC for the Duplex IFC model into GLB, the manifest looks like this:

{
    "inputFile": "/home/lindsay/xeolabs/xeokit-model-conversion-tests-feb12/inputFiles/ifc/Duplex/Duplex.ifc",
    "converterApplication": "ifc2gltfcxconverter",
    "converterApplicationVersion": "3.0.14",
    "conversionDate": "2024-02-29 22:15:56",
    "gltfOutFiles": [
        "convertedModels/ifc/projects/Duplex/models/Duplex/model.glb"
    ],
    "metadataOutFiles": [
        "convertedModels/ifc/projects/Duplex/models/Duplex/model.json"
    ],
    "numCreatedGltfMeshes": 857,
    "numCreatedMetaObjects": 246,
    "numExportedPropertySetsOrElementQuantities": 386,
    "modelBoundsMax": [
        17.491500000000002,
        4.382734000000028,
        9.0
    ],
    "modelBoundsMin": [
        -8.691499999999998,
        -22.182734,
        -1.5500000000000007
    ]
}

However, once the model is converted with convert2xkt to XKT and the XKT is loaded into xeokit's Viewer, the AABB is:

[-0.24150000512599945, -1.550000011920929, -4.3827338218688965, 9.041500091552734, 6.634799883270084, 22.1827335357666]

This AABB is the original boundary of the Duplex IFC model.

I confirmed that by also loading the IFC model directly into xeokit's Viewer, using our WebIFCLoaderPlugin, where the AABB in the Viewer was also:

[-0.24150002555848182, -1.55, -4.3827339109344585, 9.041500011920919, 6.634799883270084, 22.18273391093445].

[ifcapps]

There might be a problem with computing the bounding box of rotated geometric items, and these bboxes get unionized with parents bboxes. I will check this.

[ifcapps]

One question: do you need exact bounding boxes? They are expensive, because every point needs to be transformed into global coordinates. That requires typically 5-10 matrix-vector multiplications for each point (or a convex hull, which is also expensive).

A simplified way with bounding spheres of each mesh, would be significantly better for performance. But not accurate of course. Or transforming only the bboxes of each mesh, without rotation.

Maybe the best solution would be to implement both, with an option in the input config file.

[xeolabs]

Bounding spheres is fine.

I use the boundary in convert2xkt to set the overall uber-boundary for the kd-tree (at the root), which I then use to subdivide that boundary (recursively halving it) to form the RTC coordinate tiles.

That is done separately for each glTF file it processes.

By using the same boundary at the kd-tree's root for each glTF, we end up with RTC tiles that tend to have the same origins, which translates into the minimum number of tiles in the renderer, which means less draw calls.

In short, the boundary means less renderer draw calls, and the boundary does not need to be snug, just in the general vicinity of the 3D position ranges.

[ifcapps]

I updated the current beta release with the exact approach. Turns out that it doesn't make a measurable difference in compute time.

[ifcapps]

The boundary compute method is fixed with version 3.0.21.

However there re is still one model that causes a similar issue: The overall boundary is correct, but there are some objects that have coordinates of 7000000 or so, and a transform matrix above with -7000000 translation, which cancels out the large coordinate. During conversion to gltf, the matrix remains intact, becauase it has double precision values, but not the meshes itself. So some meshes end up having a wrong position. I will try to implement a solution per-mesh + transform matrix, similar to the approach for the overall model.

[ifcapps]

You can imagine, that was hard to even figure out what was going on...

[ifcapps]

Solved meanwhile