position vs. altitude option for WebMercatorViewport #9743
Replies: 5 comments
-
|
seems relevant. |
Beta Was this translation helpful? Give feedback.
-
|
three-loader-3dtiles constructs frameState directly, without viewport: and calls traverser directly. |
Beta Was this translation helpful? Give feedback.
-
|
The frameState appears to be the relevant piece for traversal. This produces the frameState from a viewport: camera.position is the cartesian (I think ECEF) camera position, derived from viewport.cameraPosition by unprojecting and converting from cartographic to cartesian. This means that viewport.cameraPosition is a projected camera position (not sure what that means). viewport.cameraPosition is calculated here from the inverse of the view matrix, eg. its translation column (here row): This should be just the position in world space, after apply potentially a model matrix (perhaps this is why the inverse of the view matrix is used, not some actual position). So how is this considered 'projected' and needs to be unprojected ? I think it may refer to web mercator not perspective projection. Let's next find out how the view matrix is calculated from lat./long./zoom or altitude. viewMatrix is provided by the viewport which calculates from viewport parameters: where it takes altitude into account as a direct translation but along pitch and after relative scaling. Hard to understand. Relative scaling probably means that viewMatrix scales so the extent of one web mercator tile (512px) at this zoom level fits into the (canvas) height. So altitude is also scaled. A default of 1.5 may mean 1.5 times this extent which then makes it equivalent to fovy which is preferred now. ok, then the viewMatrix is centered, by a shift towards the center of the viewport. The center is produced here: The center is the projected lat./long./0 position plus the position property in meters converted to pixels by distanceScale scaling. given a 512px tile size at zoom level 0, scale should be small: 512/earth_circumference = 512/40.03e6=0.0000127904 / cos(lat)= 1.3e-5/0.5(at 60lat) = 2.6e-5 pixels per meter let's see what the projected lat./long./0 position is: for xy: https://github.com/visgl/math.gl/blob/64f7fd537b20113ad528fea4169215590d6053dd/modules/web-mercator/src/web-mercator-utils.ts#L69 Project [lng,lat] on sphere onto [x,y] on 512*512 Mercator Zoom 0 tile.ok so this 'projected lat/long/0' refers to web mercator projection. And the position prop. is in meters, scaled to pixels and added to this pixel position. So it appears that there is a focus on zoom and fovy rather than elevation. (Let's see if there is a fly mode for mapbox). Let's go back to frameState and check what is really used for the tileset traverse. cullingVolume: from here: https://github.com/visgl/loaders.gl/blob/d74df445180408fd772567ca6a6bbb8d42aa50be/modules/tiles/src/tileset/helpers/frame-state.ts#L132 is more or less frustum volume translated from common space to cartesian WGS84 (ECEF). https://github.com/visgl/loaders.gl/blob/d74df445180408fd772567ca6a6bbb8d42aa50be/modules/tiles/src/tileset/tile-3d.ts#L468 sse: https://github.com/visgl/loaders.gl/blob/d74df445180408fd772567ca6a6bbb8d42aa50be/modules/tiles/src/tileset/tileset-traverser.ts#L281 which uses _distanceToCamera, and computeDynamicSSE uses .cameraPosition |
Beta Was this translation helpful? Give feedback.
-
|
#7064 seems related. It seems there is a lot of uncertainty on how to deal with elevation both for the camera and terrain. more history on how 3d is hard to add to 2d maps. has a way to compute zoom from camera elevation/orientation, and a corresponding position. So this is probably the function to adopt. mapbox camera position is a WebMercatorCoordinate: so fractional long., web mercator lat., and Z scaled by small circle circumference at latitude (?). Not sure if the simple scaling by 512 for Z suffices but I guess that is what layers.gl zoom may expect. |
Beta Was this translation helpful? Give feedback.
-
|
Experiments confirm that the position option does impact tile selection, in addition to zoom. For example, in a basic example a zoom of 14 selects all tiles while adding a position of [0,0,2000] does not load the children tiles. In the same example a zoom of 13 does not load the children tiles while adding a position of [0,0,-2000] will load the children tiles. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I would like to get a WebMercatorViewport for a lat.,long., elevation (in meters) camera location, for use with the Tileset 3D loader, outside of deck.gl.
deck.gl/modules/core/src/viewports/web-mercator-viewport.ts
Line 48 in 55af702
shows the position option for WebMercatorViewport. It is not documented but Viewport has it as the offset of the camera in meters. I believe this is in cartesian, ECEF reference frame. Is this the case ? Eg. the position offset would be from lat.,long.,0 to lat., long., elevation in ECEF which I could compute. But perhaps it refers to an offset in the web mercator projection reference frame ? In this case the offset may be [0, 0, elevation].
There is also the altitude option, the "Altitude of camera in screen units. Default to 1.5." which is documented and presumably preferred. How would one compute the altitude in screen units for a given geographic location with an elevation, perhaps at a certain zoom ?
Thanks for any pointers or feedback.
Beta Was this translation helpful? Give feedback.
All reactions