Ways to improve measurement accuracy

[xeolabs]

The biggest factor affecting the accuracy of measurement tools (DistanceMeasurementsPlugin, AngleMeasurementsPlugin) is the way that convert2xkt encodes geometry vertex coordinates from 32-bit floats to 16-bit integers, partitioned into tiles.

In doing so, the coordinates lose a certain amount of accuracy.

We can mitigate that by controlling the size of the tiles created by convert2xkt's. Currently these tiles are hard-coded to a value of ~1000.

We can make convert2xkt calculate optimal tile sizes that will lose less accuracy.

We could also make it possible for the user to specify a maximum tile size to the convert2xkt tool:

node convert2xkt.js -s foo.gltf -o foo.xkt --maxtilesize 500

[Amoki]

Is there any impact on the xkt size or loading time?

[xeolabs]

I have no hard numbers, but as tiles get smaller, file size gets bigger, but not at a scary rate.

[Amoki]

I think it could be better to set the default to an accurate enough value for building measurements, and if the user wants smaller file/doesn't care about measurements let them change the maxtilesize value. When using a BIM viewer, we expect it to have valid measurements by default and having to learn this makes it way harder to use imho.

[xeolabs]

Yes, I'd like it to be transparent - ideally I want convert2xkt to automatically calculate the optimal tile sizes for the magnitude of the coordinate values to be tiled. So, as coordinates get larger, tile sizes get smaller in proportion, to compensate for diminishing precision with floats as they get bigger.

[simplylogicninjas]

Is this also relevant how fast Xeokit zoom's in on a model object? Because we experience zooming issues on particulary GLTF converted models. With IFC models, no problem so far.

Zoom problems occur while dollying with the mouse wheel. When dollying on an empty space, zooming is way to fast and the model moves out of the canvas. I looked at some settings, but have no idea how to control this zooming behaviour better

[xeolabs]

No this has no relationship to zooming speed.

Finding a zooming speed that works out of the box for all models is a difficult task; some models are big, some are small, some have objects sparsely distributed over large areas, some have objects packed closely within small areas. To find a rate of movement that works for all scales and densities was an extremely difficult problem that we spent several months on.

In the end, we went for a movement rate that is inversely proportional to the distance to the object under the mouse. When no object under the mouse, rate is set to a default.

PRs are most welcome in case anyone has a better design, or a way to calculate that default rate.

[xeolabs]

This is addressed by our new measurement snapping feature.