[FEATURE] LASLoaderPlugin point transform options

[xeolabs]

Center LAS points as they are loaded:

const lasLoaderPlugin = new LASLoaderPlugin(viewer, {
    center: true // Default is false 
});

Bake X, Y and Z-axis rotation into LAS points as they are loaded:

const lasLoaderPlugin = new LASLoaderPlugin(viewer, {
    rotate: [-90, 0, 0] 
});

Bake 90 degree X rotation into LAS points as they are loaded:

const lasLoaderPlugin = new LASLoaderPlugin(viewer, {
    rotateX: true 
});

Bake transform into LAS points as they are loaded:

const lasLoaderPlugin = new LASLoaderPlugin(viewer, {
    transform: [
       1, 0, 0, 0, 
       0, 1, 0, 0, 
       0, 0, 1, 0, 
       0, 0, 0, 1 
    ]
});

Then go ahead and load some point clouds:

const lasSceneModel = lasLoaderPlugin.load({
    id: "myModel",
    src: "example-no-1.laz"
});

Any centering, rotation or transform we've configured on our LASLoaderPlugin gets applied to the point coordinates of all LAS models it now loads.

The plugin applies centering first, then rotate, then rotateX then transform.

In practice, users are not likely to use the combination of transform and either rotate or rotateX, since transform could just contain a rotation matrix. The rotate and rotateX options are shortcuts for common transform cases.

The SceneModel itself is not transformed as a result of our LasLoaderPlugin configurations (it has zero rotation and position properties), because the plugin transformed the values of the point coordinates before it loaded them into the SceneModel.

[MichalDybizbanskiCreoox]

Alternatively the API could provide easy ways to define such transformations, to still be passed under a single property.
As in e.g.
const lasLoaderPlugin = new LASLoaderPlugin(viewer, { matrix: rotate([-90, 0, 0]) });
or
const lasLoaderPlugin = new LASLoaderPlugin(viewer, { matrix: rotateX() });
This doesn't expand the API surface, doesn't introduce confusing semantics about which property is being applied first or even overruled, and on top of that the abstractions can be combined freely by users, or even reused in other contexts.

[xeolabs]

Alternatively the API could provide easy ways to define such transformations, to still be passed under a single property. As in e.g. const lasLoaderPlugin = new LASLoaderPlugin(viewer, { matrix: rotate([-90, 0, 0]) }); or const lasLoaderPlugin = new LASLoaderPlugin(viewer, { matrix: rotateX() }); This doesn't expand the API surface, doesn't introduce confusing semantics about which property is being applied first or even overruled, and on top of that the abstractions can be combined freely by users, or even reused in other contexts.

Yeah that's what the new 'transform' param is for - I need to keep the rotateX and rotate params though, at least for now so as not to break BW compatibility for anyone.

[MichalDybizbanskiCreoox]

What BW compatibility is being considered here?
Isn't the "previous" rotateX parameter a member of the load method's argument, and not the whole LASLoaderPlugin, and also meant to do a different thing than the "new" rotateX?
After this change there's an "old" set of transformation controls that represents model's "runtime" transformation that are specified by the load method arguments, and another - a bit similar but different - "new" set of parameters meant to apply a "loadtime" transformation, that is specified by a Plugin's constructor argument.
Is there a reason the "loadtime" transformation is defined for the whole LASLoaderPlugin, and not for specific models loads, like the "runtime" transformation is?
Going through the code is looks like there's ten parameters spread across two methods, which all logically represent two operations - a "loadtime" and a "runtime" transformation.