projection changes between v4-v5: how to work with three.js/threebox?

[prusswan]

I am trying to understand what is needed for threebox/three.js to work properly with the latest maplibre v5.

I had asked a similar question at jscastro76/threebox#444 and verified that threebox's example is able to work with maplibre v4 even though that project does not officially support maplibre. I just need some information on the possible changes that are needed if I want to use threebox with maplibre v5.

Sandbox example using maplibre v4 + threebox: https://codepen.io/prusswan/pen/yyLBNgw

[HarelM]

I'm not familiar enough with threebox to answer this question unfortunately.
There is an example of three.js (which I don't know if it is similar or not).
You can try to look into that.
If you don't use globe then I think the changes are not dramatic and a few adjustments should solve the problem.
If you need to use globe, it will require more work I believe.

[prusswan]

If you don't use globe then I think the changes are not dramatic and a few adjustments should solve the problem. If you need to use globe, it will require more work I believe.

Thanks for the response. I am just hoping to be able to use the new features in v5 together with the additional functionality provided by threebox (but in theory, it should also be possible to extend from maplibre v5's threejs example just that it will be more work)

[meyeraj]

@HarelM It seems that changes related to camera height/altitude are the main difference? I have played around with getting threebox to work with the mercator projection under v5, but I can't determine the correct values for a height offset -transform.cameraPosition[2] and transform.getCameraAltitude() give slightly different values depending on pitch/zoom, and using them as an offset to three js objects (i.e to push them on to the ground relative to a stationary three js camera) shows a slight discrepancy between the object and tiles.

[HarelM]

Ahh, yes, camera altitude is a hard one to crack, but unfortunately I don't have a good advice here...

[meyeraj]

No problem, thanks for replying - if possible, could you refer this to someone who might know?

It seems like getCameraAltitude is the correct value when the camera is pointed directly down at the map (i.e panning, there is no discrepancy between 3d models and underlying tiles), but then the value for cameraPosition[2] is better when viewing at an angle (pitch).

I'm trying to understand where the difference in the calculations for these two values is.

[HarelM]

Maybe @NathanMOlson can shed some light on this.

[meyeraj]

For future reference - the Threebox integration relies on point.x and point.y values passed into the render callback for the maplibregl custom layer. It uses these to offset the modelMatrix for the 'world' that holds all the ThreeJS Objects.

It seems in v5 that the point getter has been deprecated/moved? My mistake was assuming that the old point values had been replaced with cameraPosition - but they differ when the camera rotates.

(

maplibre-gl-js/src/geo/transform.ts

Line 486 in 87486a5

project(lnglat: LngLat) {

) - shows how the original point value was computed (if you pass in the long/lat coordinates for the map center), and would be a starting point for patching the original threebox CameraSync class.

[NathanMOlson]

@prusswan Thanks. It looks like the threebox method CameraSync::updateCamera() is very similar to MapLibre's Transform::_calcMatrices(), which changed a bit between v4 and v5. Looking at the changes to _calcMatrices() might help figure out what needs to change in threebox.

In particular, in MercatorTransform::_calcMatrices(), near the top of the function, there are these lines:

        const point = projectToWorldCoordinates(this.worldSize, this.center);
        const x = point.x, y = point.y;

x and y are used later in a similar way to how x and y are used in threebox's CameraSync::updateCamera. So it may be as simple as changing threebox's

        let x = t.x || t.point.x;
        let y = t.y || t.point.y;

to

    const point = t.projectToWorldCoordinates(t.worldSize, t.center);
    let x = point.x;
    let y = point.y;

There may be other complications, but hopefully that gives you a place to start.

[jacopofar]

I am stuck with a similar issue, I was able to more or less reconstruct a shape in Three.js starting from a GeoJSON but is misaligned with the map and slightly scaled.

This is my code: https://github.com/jacopofar/threejs_map_poc

I started from the example on the Maplibre website, adapting it to Typescript, and then since it says the GLTF model uses meters as units I have this function to convert coordinates and shift by the camera view center. I'm assuming the zoom is always high enough to ignore curvature.

The problem is that the 3D shape is misplaced and even a bit scaled up (it looks about 20% bigger than reality), and I can't understand what's the formula to use to place it right.

From the discussion here and the example on the website it seems I should use maplibregl.MercatorCoordinate.fromLngLat, which is in fact used to set the camera projection matrix, but I can't understand how to apply it to the GeoJSON coordinates.

The object does have a translateX and translateY field but I don't understand what those values represent, in this case they are too small to make sense in meters, lat/long or as a scaling factor.

[prusswan]

I was working on other stuff but I believe v5 may have introduced camera bugs that were not present on v4, so I intend to confirm my understanding of how the camera should work in v4 with other working examples, before further work with v5.

A related example: https://dev.to/miqwit/drawing-3d-lines-in-mapbox-with-the-threebox-plugin-5b0

[jacopofar]

Does it work on maplibre? It states it's for mapbox and in the project discussion there's some mention of adapting it to work on maplibre but the repository they link does not exist anymore so I can't see the state of the porting

[jacopofar]

For my case (mapping coordinates from a GeoJSON into meters in Threejs) I was able to fix it now, I needed to scale the values based on the cosine of the latitude. The code on the repo is updated and includes a few sample files of buildings at different latitudes