CesiumLab中对输入人工模型的格式要求 CesiumLab系列教程

本文介绍了CesiumLab中对人工模型数据的要求,包括原始格式、交换格式和渲染格式。建议使用fbx作为交换格式,因为它是Autodesk产品的官方标准,而obj格式由于缺乏单位、向上轴和几何体共享信息,不适宜用于数据标准化处理。尽管gltf是渲染格式,但由于其标准新且导出插件存在缺陷,不推荐用于切片输入。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

人工模型数据(或者手工模型数据)是三维 GIS 行业发展的最早的需求来源,通过3dsmax,maya 等建模工具人工建模的数据。

编辑

人工模型

这张图是cesiumlab上对人工模型来源的流程,在上面我们只罗列了四个建模工具,其实建模工具远多于四个,手工模型格式可以多达 50 多种。

说到人工模型,我们不得不先提及几个概念。

  1. 原始格式(max、skp等)

比如 3dsmax 的 .max 格式等,这些格式存在的意义在于是各种建模工具存储自定义信息的,一般来说格式都不开放,我们无法直接去读取和处理这些格式。所以有这些格式,一定要在建模工具内导入交换格式。

2.交换格式(max、skp等转obj、fbx)

比如比较古老的 obj 格式,以前流行的 3ds 格式,曾经的标准 collada(dae)格式,现在事实上的交换格式标准 fbx 格式。这些格式存在的意义是为了各个软件之间能够相互导入导出模型成果。一般这些格式是开放的。所以我们模型切片的大部分输入格式,应该是交换格式。

既然有obj和fbx两种格式,我们在输出格式的时候应该选择那一种呢?这里我们还是推荐fbx,原因是 fbx 是 autodesk 相关产品(3dsmax,revit,maya等)的官方交换格式,定义的比较完善,而且 autodesk 提供了官方的 fbxsdk,这样更稳定。

相反对于obj,我们实践中发现一些大的模型,在 3dsmax 里导出 fbx 经常崩溃出错,但是导出 obj 反倒很稳定。然是 obj,但是我们也推荐使用 3dsmax 导出的 obj,obj 格式太灵活太简单,反倒对于数据标准化处理来说是缺陷,比如它没有单位信息(处理后模型大小不对),没有向上轴信息(处理后模型是垂直的),没有几何体共享(无法做实例化优化)。

另外还有两种交换格式dae或3ds,对于这两种格式我们cesiumlab暂时不支持直接作为输入格式,可以把他们用 max 导出 fbx 再处理。

3.渲染格式

这里说的渲染格式其实就是gltf,其实对于gltf很多人跟我们提过需求或者问过我们,为什么不支持 gltf 进行切片。虽然对于 gltf 我们可以说是很了解的(3dtiles 的切片大部分都是构造 gltf)。但是几个原因:

1.gltf 格式标准还比较新,目前已有的导出 gltf 插件或多或少有缺陷,并不推荐大家使用。

2.gltf 格式定义的目的基本不是为了在各个软件之间交换三维模型,而是为了让引擎去高效渲染。

它的结构组织相对简单,目前来说也不是很合适做为切片的输入格式。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值