dev-docs/RFCs/v4.0/non-geospatial-viewports-rfc.md
Notes:
Problems with Current Viewport
Other Design Considerations
A possibility is to split current viewport class into 3 classes. The idea is that any of these viewports can be used with deck.gl (and they will share some code), but they provide different interfaces to the application:
BaseViewport - completely generic and linear, works with matricesScaledViewport - generic and linear, but calculates view and projection matrices for center/zoom/...MercatorViewport - understands lng/lat/zoom/pitch/bearing// BaseViewport works in a [0,1] world system. Any standard matrices can be used.
new BaseViewport({
// Window width/height in pixels (for pixel projection)
width,
height,
// Defines the coordinate system
worldMatrix,
projectionMatrix,
viewMatrix,
})
// ScaledViewport takes center, zoom, pitch, bearing etc parameters
// Calculates ViewMatrix and ProjectionMatrix from these
// Still allows app to set worldMatrix and modelMatrix
new ScaledViewport({
// Window width/height in pixels (for pixel projection)
width,
height,
worldMatrix,
// Current center (in 0-1 coordinates? Or worldMatrix coordinates)
centerX,
centerY,
zoom,
altitude,
pitch,
bearing,
})
MercatorViewport adds non-linear WebMercator project/unproject.
new MercatorViewport({
lng, lat, zoom // converted to centerX, centerY, scale
})
Proposal : Add modelMatrix parameter to the BaseViewport.getMatrices call. The viewport will right multiply in the modelMatrix into the combined matrices. This would work for all Viewport classes.
The viewport interacts with the deck.gl shaders mainly through uniforms.
viewport-mercator-project