Orillusion

每个bindgroup 就相当于资源集合， 你创建了两个 binggrouplayout, 说明shader 里面 有两个分组 与之对应 ...,包括资源类型。 你只给出app 里设置的 , 不去检查 shader 中布局， 如果不匹配肯定报错！

@shuangliu 你们真是忙，连这些非引擎端的业务侧都需要考虑

threejs 那么多成熟案例，你说对gpu 支持的不好..., webgpu 性能是可以，但至少目前商用起来还需要段时间，只能做储备方案。你架构设计的好，何必关心用那种渲染引擎呢？ 自己写个中间层对接其它渲染引擎即可。

@Temurayl 引擎应该有的功能。

透明对象叠加，不能简单的用blend ，否则会出现白边， 用alpha mask 或 alpha to coverage.

@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 是不是靠谱了。

@shuangliu 我是尽量避免创建descriptorset 资源，但引擎内部用了很多临时性的对象，每一帧都会重构，看样子也只有改进下对象创建策略，尽量复用 texture 和 buffer 了。我觉得还是有手动控制资源释放的接口会好一些。在固定的某一时间段找准时机释放GPU 资源。 以前看到过一些资料，描述符集的使用可以按频率分组分配， 比如 vulkan , 线性分配完，reset一次就回收了，下次接重分配。

bindgroup 与当前绑定的资源息息相关，在开发过程中，我发现如果频繁的分配和删除 bindgroup ， webgpu 实现并不能很好的回收内存或根本不回收内存，这造成内存占用会越来越大，即使一开始分配大量的 bindgroup , 再删除掉，我发现webgpu也没有回收内存。这对于小场景的测试看不出问题，但当场景规模一大，对象一多，很快的就暴露了问题。 控制台 会报 描述符分配 out of memory 了。请问有没有好的解决方案， 去控制bindgroup 的分配或回收。 资源回收 ， webgpu 官方应该是考虑到一些问题， 在 device , texture , buffer ,query 上都提供了 destroy 方法， 唯独这个资源描述符， 并没有提供相关的机制去控制。