CesiumLab V1.4 分类3dtiles生成(倾斜单体化、楼层房间交互)我记得我是写过一篇关于倾斜单体化的简书文章的,可是如今找不到了。不过找不到也好,就让他随风逝去吧,由于当时我写那篇文章的

    我记得我是写过一篇关于倾斜单体化的简书文章的,可是如今找不到了。不过找不到也好,就让他随风逝去吧,由于当时我写那篇文章的时候,就发现了cesium实际是有另外一种更高效的单体化。就下面这个示例html

https://cesiumjs.org/Cesium/Build/Apps/Sandcastle/index.html?src=3D%20Tiles%20Photogrammetry%20Classification.htmlnode

 
sandcastle中分类3dtiles

咱们来看看他的代码:算法

 

 
示例代码

第1 ~ 第9行 添加了大楼的3dtiles,而且相机定位过去。性能优化

第12~第19行添加一个分类3dtiles。这里面最关键的是第14行,设置了一个classificationType 属性。工具

第22~最后一行 实际是添加这个分类3dtiles,可是没有设置classificationType ,用来和第二个对比。咱们切换以后是这样的post

 

 
没有设置classificationType 的默认3dtiles效果

    从这个示例,咱们得知,cesium可使用一个3dtiles B 对 另外一个3dtiles A 进行分类,而且使用可使B包含A的部分高亮和鼠标交互。至于这种紧贴模型的效果怎么出来的,不是今天的重点,能够提一句,其实就是经典的shadow volumn 阴影的渲染方法。 性能

    类比咱们曾经倾斜单体化,咱们所须要的就是点击倾斜模型A的一些部分(好比一栋大楼)能单独高亮显示,而且附加gis属性。那么咱们前提须要两个3dtiles:第一个就是倾斜模型的3dtiles A,这个ok,使用cesiumlab的倾斜处理工具很容易就处理了。第二个就是这个携带gis属性的分类3dtiles B,下来咱们就要重点说说这个分类3dtiles如何生成。测试

  咱们这个分类3dtiles有以下的特色:优化

1, 考虑到咱们通常是用来分割建筑物 或者 建筑物的楼层,那么这个分类3dtiles必然是个柱体,也就是说侧面是垂直的,顶面是平行地表的。ui

2, 考虑到shadow volumn算法的要求,阴影体必须是包围的,因此咱们必须构造一个封闭的柱体,也就是须要底面。

    咱们再来看这个需求,很简单,只要咱们有了建筑轮廓矢量 以及 这个矢量面的 底面高度 和 顶面高度,就能够构造这个3dtiles。因此我就在个人另外一个工具,建筑物矢量面工具中扩展了这个功能

 
这个工具
 
增长了构造底面和底面高度的功能

用这个工具,咱们来生成一个分类大雁塔3dtiles(参数渲染见上图,数据仍是上次作大雁塔的单体化示例矢量数据)

 
矢量面工具生成的楼层3dtiles

    本觉得咱们加上   classificationType: Cesium.ClassificationType.CESIUM_3D_TILE 这个属性,就万事ok了,但是没想到折腾了一天多,才搞定。咱们来讲说我踩到的坑。先来看看cesium官方对这个属性的解释

 
cesium官方文档对分类属性的解释

     这段话下面少见的标注了 试验性提示,大意说这个3dtiles的分类属性还没有完成可能随时修改,这个属性在1.37版本里都有,到如今快一年了居然仍是这样子,只有一个可能,需求太少了,几乎没人在作这种3dtiles。:(

     其中还有很关键的指出来,这种3dtiles对gltf有一些限制:

1,必须有position和batchid。

2,相同batchid的索引须要连续存放。

3,全部shaders 和 techniques会被忽略。

4,只支持这两个扩展。

5,gltf只能包含一个node,这个node只能包含又给mesh,这个mesh只能包含一个primitive。

好吧这段话是我碰到默认奇妙问题的时候才看见的,因此这些坑一个不落的所有踩到。总结一下全部的坑:

分类3dtiles的gltf必须有以下限制:

1,必须有position和batchid,最好不要有其余好比normals或者textcoord,一个是没有用,另外一个是可能会影响position的偏移值,致使坐标不正确。这个坑真的跟了好久源码才发现。不设置分类属性的时候,渲染正常,设置以后也不报错,就是没效果,这种最麻烦,折腾了大半天。

2,相同batchid的索引须要连续存放,这个若是不知足,就会碰到一个访问array越界的错误,依然是跟踪源码发现,cesium的解析部分有点问题。

3,全部shaders 和 techniques会被忽略。这条最坑人,偏偏相反,至少目前gltf2.0,若是只用pbr材质,代码就会崩溃。而必须自定义shader。由于这个,我又对这个工具增长内置的自定义shader功能,增长自定义shader带来不少代码,这个又是熬出来的,哎。

4,只支持这两个扩展,这条却是真的,至少draco压缩的扩展是不支持的,因此若是作分类3dtiles,请不须要选顶点压缩。

5,这条没什么,由于以前有人尝试过,发出了他的错误提示,当时我就注意到了这个要求,无非花点时间,把个人多个primitive组织在一块儿。可是这也变相要求,咱们生成分类3dtiles的时候,不能设置侧面纹理

6,还有一个小坑,就是在node里必须设置transform,若是不设置,就报错

咱们先欣赏一下效果,很完美,精确裁剪,再也没有之前作的那样的毛刺了

在线示例:http://www.cesiumlab.com/demo/classify3dtiles.html

 
最终的分类效果

代码也很简单

 
分类3dtiles加载代码

     注意 其中的颜色设置,这里也有点小坑,这个透明度不能设置为0,设置为0,cesium内有性能优化,就不渲染了分类3dtiles,不渲染本身就没有效果了。因此咱们设置了一个极低的透明度。让他没交互的时候不影响原来的3dtiles。

咱们再来引伸几个问题:

1, 是否只能对倾斜3dtiles作这种单体化?

      回答:不是的,只要是3dtiles均可以,因此对于经过cesiumlab场景处理工具,bim处理工具生成的3dtiles均可以作相似的操做,以下图

 

 
对于max模型生成的3dtiles依然能够作相似操做

2,既然这种方式能够作分类交互和属性绑定,和3dtiles中默认的对象交互有什么区别,咱们该怎么选择?

回答:分类和交互以及属性更贴近实际业务。 咱们在数据,尤为是作max场景的时候,更多的是考虑的数据的美观性,因此数据分割不是那么严格,也不多考虑业务须要,致使不少状况下,好比咱们想选中第四层,可是max里第四层可能属于不一样的node,咱们就很难作交互了。这种状况下,咱们就能够把max场景和属性交互独立出来。max场景只作数据展现,这种数据更新的可能性较小,数据长期不变。分类交互使用分类3dtiles去完成,这种分类3dtiles通常原始数据较小,处理也快,适应属性多变的状况。

固然下述两种需求不适合分类3dtiles去实现:

  a,须要对原始3dtiles进行部分隐藏或者部分透明,上述效果咱们也看到了,分类3dtiles是附着在原始3dtiles上去显示,他的透明度只能影响附着颜色的透明度,并不能影响原始3dtiles对应部分的透明度,也不能去隐藏原始3dtiles的覆盖部分。(使用scene.invertClassification 能够隐藏或者设置分类3dtiles不能覆盖到的地方)

  b,对于bim数据或者原来建模的时候已经按照构件去组织的数据,不建议使用分类3dtiles。这类数据已是和具体业务关联的,并且能够更好的存储场景属性,因此不必再作分类3dtiles了。

3,分类3dtiles的性能如何,可否实现对城市级的数据分类

 回答:这个我没有具体测试,若是大家有数据,请联系我一块儿测试。可是显而易见的,分类3dtiles依赖的是阴影体算法,他会至少把原始3dtiles多渲染一次,这个必然会下降性能,至于下降多少,只能本身测了。

欢迎你们进入实验室,一块儿讨论cesium,3dtiles,单体化,等等。

 

在线示例:http://www.cesiumlab.com/demo/classify3dtiles.html

 

 
欢迎你们加入



转载于:https://www.cnblogs.com/cesium1/p/10062839.html