android、ios、web 有没通用的 3D 技术？

unity 了解下~

WebGL?

unity +1

blender 可以导出 glb 让 three.js 加载啊

@westoy three.js 让我想起了那个能够在 Nokia 8110 4G 上以 20 多 fps 运行的 3D 飞船游戏，就是这个东西带动的

在 android 、ios 里嵌个 webview 就都是 web 的 3d 技术了（通用了）

主题说放到 UI 里面，我不是很清楚具体是怎么一个用法
比如你做图标的话就直接调好参数渲出来就行了，我头像就是个 3D 模型渲染图。
理论上你还可以转成 SVG ，不过没试过。

直接在现有的 UI 里面渲染 3D 模型，除了 DCC 和游戏之外我能想到的就只有用于作为“主展示区”一种用途，比如电商预览商品，或者苹果之前搞得什么 Memoji （当然还有更冷门的 3D UI 和 AR 之类的，那是另一个话题）。

首先你要了解实时渲染一个模型，并且渲染得好看，不是那么容易的事情。Cycles 渲染出来可以比较精致，但是那需要大量的计算量堆起来，游戏可以做得看上去真实，但是需要使用各种乱七八糟的算法+稍微少一点的算力，不用现成的渲染引擎的话，灯光、阴影、反射、全局照明、表面凹凸、动画之类的都需要逐个实现（而现成的渲染引擎一般不小）。
所以如果可以的话用 2D 图（或者 2D 图序列）要比实时渲染 3D 好做，而且处理 2D 图更方便，更灵活。你在电影和游戏里面看到的许多东西其实不是模型渲染出来的，是后期合成加上去的。简单裸写实时渲染能写到什么程度，你可以以“opengl beginner demo”为关键字搜索。

然后是把模型导出成一个文件，一般每个 DCC 有自己的文件格式，比如 Blender 是 .blend ，Maya 是 .ma 和 .mb 。这种文件一般没法直接用，因为他是根据 DCC 的需求来设计的。业界有若干种比较通用的格式用来 interoperate：Wavefront OBJ ，非常古老又非常简单的一种格式，因为完全是文本，很简单就能写个 parser 。3DS ，老 3D Studio 的格式，也很老（从这货单个 mesh 限制 65536 面你就大概能民白发生了什么 ...）。FBX ，后来自动麻将桌重新弄来的一个格式，所有自动麻将桌产品都支持，实际上非自动麻将桌软件也支持。COLLADA 和 glTF ，俩 Khronos 的开放标准，我没咋用过，具体好不好用要看软件支持情况。Alembic ，VFX 现在的业界标准。
不过这些主要是作为转换的中间格式，渲染引擎可能会直接支持这种中间格式，也可能有自己的专有格式。这里的问题其实主要还是 DCC 和渲染引擎支持的功能可能是完全不同的，两边的语义并不对应，而中间格式作为一个类似 LSP 一样的角色更没办法完美耦合这两者。

最后是渲染引擎。现在主要实用中是使用 GPU 渲染（ CPU 渲染并不是没有用，据说 ZBrush 就是 CPU 渲染）。GPU 渲染依赖于使用特定的 API 调用 GPU 中的相关专用硬件（当然理论上你也可以使用 GPGPU 来模拟这一过程，不过这依然是非主流做法，能写 CPU 渲染器或者 GPGPU 渲染器的大概不会问这个问题）。目前图形 API 发展大致可以分成三个阶段，第一个阶段是完全固定的原始阶段，只能按照硬件设定好的方式去渲染，程序员只能调几个参数；第二阶段是从 D3D8 ，GL1.4 开始引入 shader 之后的可编程阶段，程序员可以对 GPU 编程来自定义渲染过程，大大增强了灵活性，并且派生出很多意想不到的应用（包括最原始的 GPGPU ）；第三阶段是从 Mantle 开始，以 D3D12 ，Vulkan 和 Metal 为代表的将更多 GPU 底层细节开放给开发者，并全面支持多线程的低开销阶段，但是写起来就跟汇编一样，太麻烦。

从目前情况来看，第一阶段的已经彻底淘汰，第二阶段的总体支持较好，第三阶段一些老硬件和老软件不支持，并且由于比较底层，需要折腾的东西比较多。所以现在入门的话推荐从第二阶段开始，需要注意的是如果不考虑性能和具体实现的坑的话，理论上第二阶段和第三阶段 API 的渲染能力，以及不同厂商 API 的能力是一样的，只是调的接口不太一样，因为算法是你自己写的，所以出来的结果只取决于你程序怎么写。

楼主问这三个平台有没有通用的技术，首先仨平台的开发语言就不一样，Android 和 iOS 好歹还都能用 C/C++，Web 直接锁死了 JavaScript 。API 支持方面，Android 可以支持 GLES 和 Vulkan ，但是鉴于 Android 大区优秀的设备和驱动支持情况，Vulkan 貌似现在总体还不是很稳定，iOS 也支持 GLES ，不过是 deprecate 状态，现在推荐 Metal ，Web 是基于 GLES2 的 WebGL ，这个属于第二代 API 中比较老的一种了，还有比较新的基于 GLES3 的 WebGL2 ，这个其实依然比较老 ... 但是最近两年才得到全面支持，对应第三代 API 的 WebGPU 现在貌似有安全问题难产，现在 Web 连做 GPGPU 都得用十多年前的老 trick ...
所以 API 层面大概能统一到 GLES2 或者 GLES3 这个层面，语言还是得自己想办法。由于很多程序需要支持很多硬件和软件，而不同的 API 能力是差不多的，为了解决 API 支持问题，一般会做一个通用的接口将他们抽象掉，应用不依赖于底层 API 。比如 bgfx 就声称支持各种平台和各种 API （在 Web 使用 Emscripten 解决）。另外个别情况下还会涉及到的一种做法是不同 API 之间互相转换，比如 Apple 强推 Metal 不做 Vulkan 支持，有个 MoltenVK 项目是用 Metal 实现 Vulkan API 。这个 Linux 和开放社区玩得最欢，有用 D3D/Vulkan/Metal 实现 GLES 的 ANGLE ，用 Vulkan 实现 GL 的 Zink ，Vulkan 实现 D3D 的 DXVK 和 vkd3d 。微软还给 WSL 搞了个 D3D12 实现。
当然，这些 API ，无论是哪个阶段，都属于用户所能直接接触的最底层 API （注意 Console 不包含在内，Console 是单独的一个故事），总是非常底层的，也就是不存在调一个函数就帮你把模型渲染出来这种事情。所以再上层还会做一个抽象，实现类似“调一个函数把模型渲染出来”的效果（实际依然没那么简单，渲染一个模型需要考虑投影、灯光、材质、半透明等各种问题，只是这些问题直接用底层 API 来处理只会更麻烦），这才有 Ogre ，OpenSceneGraph ，Three.js 等。
Unity 之类的游戏引擎是比较高层的抽象，因为一般“游戏”是一种各方面都比较特殊的应用，就连 iOS App Store 对游戏也有不同的审核要求。特别是公开可用的游戏引擎，大多会有广泛的平台支持需求，以及 Console 支持的需求（不过相关的东西应该要 NDA ）。in-house 的则是各有各的需求。一般游戏引擎会做成“框架”式的东西，也就是他会直接接管你的整个程序，想要把一个游戏引擎和另外的应用集成起来可能成本会比较高。我认为可能的 sweet spot 还是在上一层，也就是渲染引擎上。

modelviewer.dev, react three fiber

@lodisy pmndres 全套都和 3d 相关

@secondwtq 感谢前辈指点