以下内容转载自木的树的文章《WebGL着色器32位浮点数精度损失问题》
作者:木的树
来源:博客园
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
前言
Javascript API GL是基于WebGL技术打造的3D版地图API,3D化的视野更为自由,交互更加流畅。
提供丰富的功能接口,包括点、线、面绘制,自定义图层、个性化样式及绘图、测距工具等,使开发者更加容易的实现产品构思。
充分发挥GPU的并行计算能力,同时结合WebWorker多线程技术,大幅度提升了大数据量的渲染性能。最高支持百万级点、线、面绘制,同时可以保持高帧率运行。
同步推出基于Javascript API GL的 位置数据可视化API库,欢迎体验。
问题
WebGL浮点数精度最大的问题是就是因为js是64位精度的,js往着色器里面穿的时候只能是32位浮点数,有效数是8位,精度丢失比较严重。
分析
在基础底图中,所有的要素拿到的都是瓦片里面的相对坐标,坐标范围在0-256之间。在每次渲染时都会重新实时计算瓦片相对中心点的一个偏移来计算瓦片自己的矩阵,这种情况下精度损失比较小,而且每个zoom级别都会加载新的瓦片,不会出现精度损失过大问题。
但是对于一些覆盖物,比如marker、polyline、label使用的都是经纬度,经纬度小数点后位数比较多,从js的数字传入到gl中使用的gl.FLOAT是32位浮点数,小数点只能保证到后4位或者5位。在18级会出现严重的抖动问题。
文章中提到了几种解决方案,像mapbox使用的是第二种方案,将覆盖物比如marker、polyline、polygon都按照瓦片切分,经纬都转换成瓦片网格里面的0-256数字。这种方法每次zoom变换都要按照新的网格来重新切分。尤其到了18级往后,比如室内图22级,网格非常小,导致切分时间特别长。
继续尝试发现mapbox中也有类似问题:https://github.com/mapbox/mapbox-gl-js/issues/7268
mapbox这里也是使用了转换到视空间。但这种方式并不适合我们。
继续思考,实际这个问题原因是32位浮点数有效位不够,我们要找一个相对坐标为基准,其他的覆盖物坐标都是以这个点为基准,这个相对原点的坐标保留大部分数字,剩下的相对坐标数字