【问题标题】:Process THREE.Texture in webworkers在 webworkers 中处理 THREE.Texture
【发布时间】:2018-06-29 20:55:31
【问题描述】:

我想在 web Worker 中处理 THREE.Texture 以帮助后期处理效果,例如绽放。例如,对于绽放效果,我会首先在 THREE.Texture 对象上绘制场景,然后我想在 web worker 中处理模糊过程。将 THREE.Texture 数据传递给工作人员并根据从工作人员获得的数据创建新的 THREE.Texture 的最有效方法是什么。由于理想情况下我会每秒执行 60 次,因此我需要一种快速且内存友好的方式来执行此操作(内存友好:不是在循环中创建新对象,而是重用现有对象)。

我知道 canvas2DContext.getImageData 可能会有所帮助,但这可能不是最好的方法,因为我每秒会在画布上绘制 60 次,这会减慢速度。

谢谢!

PS:我应该指定在这种方法中,我不打算等待工人完成处理纹理来渲染最终结果。由于大多数对象都是静态的,我认为这没什么大不了的。不过,我想测试一下它对动态对象的影响。

【问题讨论】:

  • 您为什么不坚持使用three.js 示例并使用例如UnrealBloomPass?它使用 GPU 进行非常高效的处理。我不认为,当你使用 webworkers 时,你会在性能方面得到任何接近的东西。你的方法对我来说听起来很奇怪。 threejs.org/examples/#webgl_postprocessing_unreal_bloom
  • 我知道,但我想进行实验。我的想法是处理工作人员内部的模糊,并减少一次 WebGL 渲染调用(模糊通道)。
  • 您可以使用canvas.getImageData() 检索代表原始图像数据的Uint8ClampedArray。然后,您可以通过Transferable Objects 将相应的ArrayBuffer 发送给工作人员。如果您要使用多个工作人员,则必须将原始 Uint8ClampedArray 拆分为多个数组缓冲区,因为可转移对象仅在单个执行上下文中有效。无论如何,你的表现会比使用 GPU 更差。所以我不确定在这方面投入时间是否有意义。
  • 好吧,我知道 getImageData 真的很慢,所以在我的问题中,如果可能的话,我要求使用 getImageData 以外的方法。
  • 在下面的例子中使用WebGLRenderingContext.readPixels() 也应该可以工作:stackoverflow.com/questions/13626606/…

标签: three.js webgl


【解决方案1】:

将基于 GPU 的纹理传递给 Web Worker 不会加速任何事情,事实上它会明显变慢。

与在 GPU 上执行所有操作相比,将内存从 GPU 传输到 CPU(以及 CPU 到 GPU)非常慢。将纹理内容传递给工作人员的唯一方法是要求 WebGL 从 GPU 复制到 CPU(在三个中使用 gl.readPixels,无论 gl.readPixels 的包装器是什么),然后将结果传输给工作人员.然后在工作人员中,您所能做的就是基于 CPU 的慢速模糊(比在 GPU 上慢),然后您必须将其传输回主线程,然后才能通过 gl.texImage2D 再次上传或告诉three.js 为您完成,这也是将数据从 CPU 复制回 GPU 的缓慢操作。

应用模糊的快速方法是在 GPU 上进行。

此外,没有办法在主线程和工作线程之间共享 WebGL 资源,也不可能很快实现。即使您可以共享资源,然后从工作人员那里要求 GPU 进行模糊处理,这也不会节省时间,而且在大多数情况下,GPU 不会并行运行不同的操作(通常不是像 CPU 那样的多进程),所以你最终要做的就是让 GPU 做同样多的工作。

【讨论】:

  • 是的,我知道它应该更慢,但我想尝试这样的原因是基于 GPU 的绽放效果首先将场景渲染为纹理,然后将此纹理传递给模糊着色器然后在另一个着色器中组合结果和当前场景。在我看来,这已经是一项昂贵的操作,并且无论如何都会进行大量 gl.textImage2D 和 WebGL 绘图调用。由于workers除了传递数据并接收它之外并没有阻塞主线程,我认为我应该给workers一个尝试。
  • 初始设置后不应调用gl.texImage2D。如果您发现代码中存在错误,或者它被用于不相关的事情(例如上传视频)
  • 是的,我的错。我想说我想尝试这样的事情的原因是尝试减少用于绽放效果的 WebGL 绘制调用的数量。我还在我的问题中添加了一点 PS。
  • 这确实不是您应该采取的路线,应该接受这个答案。
猜你喜欢
  • 2016-02-14
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多