Cesium 加载 ArcGIS 动态图层的方式
如果你在 Cesium 中加载过 ArcGIS 的动态图层,你会发现,Cesium 对于动态图层仍然采用类似切片图层的逻辑进行加载。也就是每个固定的瓦片 export 一张图片。
这样会造成一些问题:
- 请求量大,如果访问人数多,后端服务容易崩溃
- 如果动态图层中含有标注,会造成标注文字变多(ArcGIS 动态图层如果一个大图形被分割在多个 export 中,那么每个 export 回来的图片都会含有大图形对应的标注)
没找到合适的带标注的动态图层数据,这里用 ps 简单模拟一个效果
ArcGIS 4.x 三维场景加载动态图层的方式
通过查看 ArcGIS 三维场景发送的请求可以发现,ArcGIS 每次相机停止运动时,会首先给动态图层服务发送两个范围大小不一样的 export 请求。再根据请求回来的两张图片进行叠加显示。
效果大概如下(同样用 ps 模拟)
当然,如果同一个面被分割在了两个服务,一样会出现标注多的问题
在 Cesium 中实现仿 ArcGIS 三维的动态图层加载方式
要实现仿 ArcGIS 三维的动态图层加载方式,首先当然是得先获取 ArcGIS 是如何计算两个 export 参数的。
这一步没什投机取巧的办法,只能去翻 ArcGIS 的源码,把这段逻辑抽离出来。(npm 包里的 arcgis 源码,代码经过了压缩,不过大致逻辑还是能看出来的)
如果抽离的逻辑正确,那么请求的范围应该类似下面这样
抽离出两个 export 参数的计算方法之后,就该考虑如何展示了。
利用 GroundPrimitive 展示
将请求回来的两张图片通过 GroundPrimitive 展示是最简单的办法,需要做的额外操作只有在第二张大的图片中,挖去和小图片相交的部分
优点:实现简单,性能高,能实现影像贴模型的效果
缺点:无法和其他通过 ImageryLayer 方式加载的图层交换图层顺序
编写 ImageryLayer 展示
ImageryLayer 请求方式就是 Cesium 原生的方式。它能够解决 GroundPrimitive 无法和其他图层交换顺序的问题,但是会有一些性能问题。
性能问题源自于 ImageryLayer 会按切片方案将展示的内容切割成一个个小的瓦片。而我们 export 回来的两张图片并不是严格按照切片方案请求的。
因此, 每次请求回来的图片, 都需要根据当前正在显示的瓦片进行切割, 并将切割出来的内容更新至瓦片的缓存中。( ImageryLayer 内置缓存机制,一旦当前瓦片请求成功,则后续直接读取缓存不会再请求。实际渲染时,也是读取缓存中的内容渲染的。如果不更新缓存,那么当重新显示已缓存的瓦片时,其内容会和当前的图片对应不上 )
更新瓦片缓存这一步相当耗时和耗内存,并且如果瓦片多,甚至会出现阻塞主线程的情况。
有的同学可能会说,是不是可以考虑采用 WebWorker 来计算每张瓦片的内容?
事实上,我尝试过,但是由于需要同时更新的瓦片比较多,就会导致 export 请求回来的两张图片都需要复制一份到各自的 WebWorker 中,这样会导致更严重的内存问题。
采用 SharedArrayBuffer 让图片在 WebWorker 之间共享?
事实上,我也尝试过,但是 SharedArrayBuffer 似乎存在一些兼容性问题,最后还是放弃了 😑。
如果各位大佬有解决方案,欢迎提供!
修改源码的方式展示
在编写 ImageryLayer 方案时,我想到,实际上我可以只向着色器传入两张纹理,和对应的四至范围。在计算 Globe 上的影像纹理时,单独为动态图层进行切割即可。
就目前而言,这个可能是最理想的方案,只是需要去对 Globe 和 ImagerLayer 相关的源码进行修改。
这个方案还有待尝试,累了…晚点再试…😑
原文链接
Cesium中实现仿ArcGIS三维的动态图层加载方式