感谢反馈，这个模型里的动画并不是 SkeletonAnimation 骨骼动画，目前引擎中 loadGltf 还没有对属性动画做处理，稍后版本会加入相关处理

嗯 这个是一个已知bug
https://github.com/Orillusion/orillusion/issues/177
稍后版本会解决这个问题

对于大模型，一般是无法直接加载到内存或显存里的，除非配置超大的显卡和内存，所以通常来说，需要配合后端的 模型预处理 和 实时网络分发 来进行大模型展示

一般需要先将模型预处理成特殊的 分片 和 LOD 处理，比如 3dtiles 这种模型标准，常用于 GIS 类的应用，它会将整个模型进行坐标分片 和 lod 处理，再配合上层应用引擎进行选择性加载，比如只加载当前视口内的分片模型和lod，其它的模型会从内存和显存内剔除，根据视口的变换实时向服务器请求不同的分片模型，保证同一时间内引擎其实只加载了很小一部分，并不会全部加载 几十G 的内容

Orillusion 当前版本还没有开发对类似 3dtiles 等主流分片模型的支持，但有计划开发相关的扩展支持，也计划会开发对模型进行分片处理的后端工具和服务，如果您有gis类的开发经验，也非常欢迎提交相关 pr

glb是将所有文件都打包到了一起，有优点，也有缺点，一个大文件并不利于 web 网络加载和缓存，所以实践中，一般我们都建议使用 gltf 将所有文件分开打包，可以把一个模型拆分成多个独立的小文件，1个gltf，多个bin，和多个jpg/png... 贴图，一般每个文件都会小于50mb方便传输和缓存

并且浏览器可以同时发起多个http请求，也就是把一个模型并行加载，使得整体下载时间相较于一个glb大幅度缩减，提升网络传输效率，当然前提条件是你的带宽和服务器带宽足够大

@shuangliu 无法将模型文件打到包里

@shuangliu 感谢回答,用本机nginx发布,手绘的立方体正常,但glb模型文件打包没好使,提示 invalid GLB file

如何提供模型文件个你们呢？

感谢反馈，类似的读取像素或截屏的API会在后续版本中加入

不过，WebGPU 对于 CPU 和 GPU 的数据读写速度可能并不会有额外的帮助。Three 中也是使用 WebGL/2 原生 readPixels 将渲染贴图buffer copy到 CPU/JS 中，这其中 Three 并没有添加额外的处理导致额外的时间，最终传输速度基本取决于设备的 GPU 到 CPU 的物理读取带宽。

使用 WebGPU 并不会加速这一过程，WebGPU 能带来的优势是异步IO，也就是将 readRenderTargetPixels 变成异步读取，减少阻塞主线程的渲染，所消耗的整体时间不一定比 WebGL 快，但主线程渲染帧率不会出现明显掉帧，不会出现ui卡顿，整体体验会好一些

看看后期处理TAA，不过不得不说，加了后期处理后，页面肉眼可见的变卡了，后期处理希望还要多优化

全局光照我们也会在稍后几版中加入

更新版本到0.6.2好了

感谢您的回复，我看到目前的示例中已更新。

@shuangliu 好的感谢

@bestsam 我虽然没用orillusion 引擎，但引擎中也使用了webgpu, 跟 webgl 比， pipeline 和 bindgroup 资源管理有点闹心，尤其是bindgroup, 也就是vulkan 或dx中的描述符, 一旦涉及到场景中有动态更新的对象，这种东西在设计类软件中存在较多， 比如过程话的缩放对象（坐标轴、标注、、、）在屏幕空间中保持大下，会不断的创建描述符，但 webgpu 并没有提供手动回收的内存接口，导致内存占用越来越高，靠javascript gc 机制是不及时的，最后out of memory 就白屏了。管理好内存资源确实是挑战。

@wslyx 我目前在已有的引擎上接入了 webgpu, 用wasm 的形式， 发现比webgl 会占用更多的内存，毕竟要自己创建和管理各种管线资源，尤其 pipeline 和 bindgroup 这些资源。开销主要集中在 wasm 与 js api 的调用上，如果不是利用webgpu 的多线程命令缓冲区的形式构建多线程渲染， 感觉还不如 webgl。 原生效率差多少就得看 dawn 是不是靠谱了。

@aichangqing 只是还没计划吧，webgl对与cesium这种大型的gis引擎来说，简直就是慢性毒药啊，官方不可能不知道

@jkwang007 0.6.2已修复removeChild相关bug