Support double-precision model coordinates without jitter

[xeolabs]

Problem Description

WebGL only supports single-precision, yet IFC needs double-precision

IFC files often rely on double-precision for large coordinate values. This is often the case when a model origin within the IFC is positioned far from [0,0,0], which causes the coordinates in the model to be very large.

The GPU precision of WebGL is only single-precision, however, with accuracy to approximately 7 numeric places. This results in rounding errors, as double-precision IFC coordinates are squeezed into WebGL's single-precision. The left-hand image in the screenshot below shows the effect, which is known as "jittering" and, at the time of writing this, is a problem for almost every WebGL-based BIM viewer.

Solution

Tiles with relative-to-center coordinates

The solution is to extend xeokit's .XKT format to partition the model's objects into "tiles". Each object's coordinates would then be relative to the center of its tile (known as Relative-to-Center Coordinates, or RTC).

This technique is described in 3D Engine Design for Virtual Globes, and is currently used within the CesiumJS, a WebGL-based JavaScript library for creating 3D globes and maps.

This technique will be implemented in Version 6 of the .xkt format, and will be done in two parts.

Extend xeokit-gltf-to-xkt

• [x] Extend xeokit-gltf-to-xkt to generate .xkt V6

Extend xeokit-sdk

• [x] Extend XKTLoaderPlugin to load .xkt V6
• [x] Extend renderers to support double-precision coordinates
• [x] Extend CameraControl to support double-precision coordinates
• [x] Extend DistanceMeasurementsPlugin and AngleMeasurementsPlugin to support double-precision coordinates
• [x] Extend SectionPlane and SectionPlanesPlugin to support double-precision coordinates
• [x] Make SAO support double-precision coordinates
• [x] Extend annotation occlusion mechanism to support double-precision coordinates

[Amoki]

Hi @xeolabs, is xkt v6 ready to be tested? How could we help?

[xeolabs]

@Amoki not yet, will let you know when it's ready

[Amoki]

Thanks! If you need heavy testing on multiple models at some point, we can run some scripts on our models :)

[xeolabs]

Hi @Amoki , would you by any chance have a small/medium sized model that jitters (like in the screenshot), that can be included as a test model with xeokit-sdk?

This a big feature, but I'm making good progress and it seems the techniques I've described above are indeed working.

Since there are many moving parts to this, I'm factoring out much of the logic within xeokit-gltf-to-xkt into it's own toolkit (https://github.com/xeokit/xeokit-xkt-tools) with components for generating/validating/loading .XKT files, so that those components can be unit tested. That toolkit will then deploy a binary to NPM, which the next version of xeokit-gltf-to-xkt will then import, in order to generate XKT V6.

At the same time, I'm upgrading XKTLoaderPlugin to load the new XKT V6 format, and upgrading xeokit to emulate 64-bit coordinates on the GPU.

Many moving parts, much unit testing, documentation and validation involved, but looking promising.

[Amoki]

Hi @xeolabs! Here is the gltf of our demo model without any offset correction. MAP_jitter.zip

Will "native" coordinates be available from an object or for the camera? Or an offset to apply? They'll be needed for BCF by example. I can update and test the BCF when xkt v6 is ready if you want!

[xeolabs]

Thanks @Amoki - the "native" coordinates will be 64-bit for camera positions, object boundaries, section planes positions and light positions, while geometry positions will be 32-bit, relative to tile centers ("rtcCenter"). That way, we can save memory for geometry positions.

All this means that the 64-bit version of xeokit-sdk will be a beta branch for a while, until we're sure this doesn't break various functionalities.

[xeolabs]

@amoki success - the demo model is jitter free using 64-bit emulation.

Example on the left loads the model loaded using GLTFLoaderPlugin, which does not use tiles and RTC coordinates. Example on the right loads the model with XKTLoaderPlugin from .xkt v6, which does use tiles and RTC coordinates.

Within the xeokit Viewer, the center of this model is: [1842022.2889441466, 10.494778148707642, -5173301.847852561], and the model's boundary is [1842005.8984316802, -3.600000170870336, -5173320.675941065, 1842038.679456613, 24.589556468285622, -5173283.019764056].

[Amoki]

Nice! We'll test asap :D

[xeolabs]

@Amoki could I get the IFC model for the MAP model?

I'm putting together a showcase of examples, so if anyone has any more jittery models they can share publically, I'd love to include them.

Work remaining on my end before full-precision is ready for release:

• Create some more full-precision examples
• Finish blog post on full-precision release
• Extend annotation occlusion mechanism to support double-precision coordinates (1 day max)

The "annotation occlusion mechanism" automatically hides 3D annotations that are hidden behind objects. Currently, the occlusion mechanism effectively ignores objects that belong to full-precision models, but still works fine for objects in normal models. Just need to convert it to use RTC coordinates, not a biggie.

[Amoki]

Here it is! 19_rue_Marc_Antoine_Petit.zip