You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For our custom layer implementation to properly match the base map in an interleaved 3D context, we need access to the projection matrix parameters.
CustomLayerInterface.render currently exposes a single matrix argument that is the combined view projection matrix. In our implementation, coordinate transforms are done on the GPU for better performance, but shader uniforms only support up to 32-bit floats. To compensate for lost precision, we calculate the view matrix and projection matrix separately.
Historically we poke into the source code of the Transform class to try match our calculation with the base map. This has become increasingly problematic as the base map could change its near/far plane calculation between versions. It would be much easier if CustomLayerInterface.render could expose the view and projection matrices separately, or even the individual projection matrix parameters (fov, near, far).
Design Alternatives
A non-breaking API change could be adding a third parameter to CustomLayerInterface.render:
The separate matrices and nearZ/farZ etc. are already stored in map.transform as private properties. Making them visible to a custom layer has minimal overhead but will help create much more robust third-party renderers.
The text was updated successfully, but these errors were encountered:
Motivation
For our custom layer implementation to properly match the base map in an interleaved 3D context, we need access to the projection matrix parameters.
CustomLayerInterface.render
currently exposes a singlematrix
argument that is the combined view projection matrix. In our implementation, coordinate transforms are done on the GPU for better performance, but shader uniforms only support up to 32-bit floats. To compensate for lost precision, we calculate the view matrix and projection matrix separately.Historically we poke into the source code of the
Transform
class to try match our calculation with the base map. This has become increasingly problematic as the base map could change its near/far plane calculation between versions. It would be much easier ifCustomLayerInterface.render
could expose the view and projection matrices separately, or even the individual projection matrix parameters (fov, near, far).Design Alternatives
A non-breaking API change could be adding a third parameter to
CustomLayerInterface.render
:Implementation
The separate matrices and nearZ/farZ etc. are already stored in
map.transform
as private properties. Making them visible to a custom layer has minimal overhead but will help create much more robust third-party renderers.The text was updated successfully, but these errors were encountered: