Three.js: WebGL2渲染器

创建于 2016-10-29  ·  84评论  ·  资料来源: mrdoob/three.js

本周Chrome 宣布他们打算发布 WebGL 2.0 ,所以我想是时候开始添加支持了!

已经有一些 PR 为WebGLRenderer的一些新功能添加了支持,但不知何故,让WebGLRenderer同时支持webgl并不是一个好主意和webgl2

WebGL2Renderer打个招呼! https://github.com/mrdoob/three.js/commit/2ff9d410753b72a5e43b211dc3be26f0f0ab8a0e 👋

一个新的渲染器不仅可以让我们摆脱大量的条件,还可以让我们有机会清理它们; 开始只支持BufferGeometry ✌️

对不起所有因为我的犹豫不决而没有合并 PR 的人! 😔

Enhancement WebGL2

最有用的评论

计划下周开始调查这一切! ✌️

所有84条评论

非常好。 :) 我其实有点担心如何处理 WebGL 2 和 1 的复杂性。

更喜欢使用 UBO 会很棒。 :) 而且我喜欢只支持 BufferGeometry 的想法 - 这应该会极大地简化事情。

如果我们坚持使用前向渲染(这似乎是 UE4 为 VR 的速度所做的事情),支持大部分相同的着色器会很酷。我认为我们可能会改变它? 你怎么认为?

我想我想保持着色器的兼容性,这样如果 WebGL2 不可用,我们可以退回到看起来相似的东西,只是速度更慢。

@mrdoob嘻哈万岁! 很高兴听到BufferGeometry将被专门使用。 👍

赞同@bhouston的建议,即优先选择 UBO。

是否也可以将光照和阴影处理与渲染器更完全地分离? 默认值非常方便,但是当您想要完全控制照明和阴影逻辑时, WebGLRenderer和 co. 感觉他们在打架。

当我列出愿望清单类型的项目时,排序算法是否可以“可插入”? 我有超出三个范围的排序需求,并且似乎不必要地难以覆盖当前WebGLRenderer中的排序功能。 也许这可能是创建渲染器对象时的可选设置?

我几乎想知道是否应该只修改 WebGLRenderer 1 并删除对 BufferGeometry 对象以外的任何东西的支持。 这可能是一个更容易的前进方式。 如果有一个简单的函数可以将 Geometry 转换为 BufferGeometry 迫使人们调用......

我想我这样说是因为我担心试图保持 WebGLRenderer 和 WebGLRenderer2 之间的功能奇偶性。 发展单个代码库比同时维护两个代码库更容易。

我几乎想知道是否应该只修改 WebGLRenderer 1 并删除对 BufferGeometry 对象以外的任何东西的支持。 这可能是一个更容易的前进方式。 如果有一个简单的函数可以将 Geometry 转换为 BufferGeometry 迫使人们调用......

已经有这样的功能了。 但没那么简单...

我认为从头开始构建WebGLRenderer2更好,这样我们就可以重新考虑 API 和支持的功能。

Firefox 51 现在支持 WebGL 2:https: //www.mozilla.org/en-US/firefox/51.0/releasenotes/

等不及了!

支持 WebGL 2.0 的 Chrome 56 发布了!
https://developers.google.com/web/updates/2017/01/nic56

向前推进WebGLRenderer2的好时机? XD

我们还应该创建一个 WebGLDeferredRenderer2 吗?

计划下周开始调查这一切! ✌️

任何机会你已经有一些时间来研究它! 呜呜呜好期待! (3D 纹理)

@mrdoob
任何更新?
如果您有一些顾虑,请与我们分享!
我们可以讨论和帮助;D

还没来得及。 快快快! 😇

任何更新? 我对用于体积渲染一些医学图像的 3D 纹理特别感兴趣。 我也愿意帮助使这个拉取请求成功。

当前的three.js webgl2沙箱不起作用:( https://threejs.org/examples/webgl2_sandbox.html
可能是three.js 版本构建问题?

至少 Mozilla 正在研究它https://bugzilla.mozilla.org/show_bug.cgi?id=1240072

@mrdoob ,这是否意味着我们可以期待 Three.js API 在更新到 WebGL 2.0 时利用<script type="module">的优势? ;)

顺便说一句,我认为同时将 WebGL 2.0 支持添加到 WebGLRenderer 是最简单的。 我认为这将允许增量采用,我们可以进行功能检测,看看我们是否可以使用 WebGL 2 功能。 我不认为这是最难做的事情。 我知道与纯 WebGL 2 渲染器相比,它会导致一些复杂性,但它是近期和中期最简单的路径。 一旦 WebGL 2 的采用率超过 90%,我们就会慢慢发展,最终将 WebGL 1 抛在脑后。

Khronos 刚刚在 webgl2 上举办了一次网络研讨会:
https://docs.google.com/presentation/d/11-mTDNmSJzJnRVGu9Vu6AUzOt34yV3PO7oqw4E5wc2o/edit#slide =id.gd15060520_0_38
媒体将很快发布,但演示文稿主要是幻灯片的画外音和幻灯片中的相关演示。

很明显,这需要一个新的开始,而不是从现有的 WebGLRenderer 中“更新”。

在 es6 模块方面,我认为目前的源方法是 es6 模块,然后使用 rollup 进行捆绑仍然是支持“双重构建”的方式。

我已经这样做了一周左右,在 Safari Tech Preview 上测试模块和在所有浏览器上的捆绑包。 真正导致构建/拥有源代码树以及当前包。 您当前拥有的单行汇总,以及源树的副本以供模块使用。

@bhouston诱人...

最新状态?

我对此有某种复杂的感觉。 最初,我正在考虑与@bhouston提议的相同路径,将 webgl2 功能逐步添加到当前WebGLRenderer 。 但这会使渲染器更加复杂,并且难以处理两个版本之间差异最大的功能,最终导致混乱的代码充满分支和条件检查。
一种选择是克隆WebGLRenderer作为WebGL2Renderer的起点,并继续删除/添加功能,而不会弄乱原始渲染器。
如果我们看看像 Playcanvas 这样的引擎,它可能是最早支持 webgl2 的引擎,我们可以看到它甚至没有利用新的 webgl2 功能,如 UBO 或 VAO,因为它会修改发动机的许多部件。

我坚信,如果我们尝试在同一个渲染器上混合两个版本,我们最终会得到更难维护的代码,一旦 webgl2 得到完全支持,我们无论如何都需要重构它,因为我猜我们会是被迫遵循设计以保持这种兼容性,而不是考虑到 webgl2 从头开始​​设计。

所以我的投票是从头开始WebGL2Renderer ,即使我们会慢下来(在 webgl2 获得接近 100% 的支持之前,我们仍有改进的空间)。

除了渲染器本身之外,还必须修改一些文件,例如纹理、程序等。 我们是否应该创建一个子文件夹renderer\webgl2并继续添加将为该渲染器专门创建的文件?

我们可以创建一个问题,列出我们应该做的更改列表,以便让 webgl2 完全兼容的渲染器在编写渲染器时牢记它们,并创建一个我们希望 MVP 拥有的功能列表,以便集中精力讨论这些在这个初始状态下启动了关于实施的更深入的对话。

它的发展有什么更新吗?

还没有。 这个月我优先考虑 WebVR。

正如上面@fernandojsg所建议的那样,我尝试了对 WebGL2 和 ES3 着色器语言的快速就地转换。 这是压扁的差异: https://github.com/tstanev/three.js/compare/master...tstanev :traian/webgl2 实际上,它看起来并不像我最初预期的那么糟糕。 通过一些战略性放置的 ifdef 来支持这两者几乎看起来不会太难看。
[编辑:更新链接。]

@tstanev你有一个可行的例子吗?

链接分支中捆绑的 three.js 示例正在运行(正如您在 diff 中看到的,我转换了之前需要扩展的示例)。 您可以克隆 repo/branch 并在本地运行它们。

@tstanev如何在线比较 webgl2 更改的性能?)很高兴看到它。 (webgl2 上的三个.js 与三个.js)

你好
谢谢你这个最好的主意。
我想在我的程序中使用 webgl2renderer,但我无法在预编译版本(r86)中使用它,所以我获取了源代码并在三个.js 导入中取消注释 webgl2renderer,然后构建它。
现在我的代码和您的示例(webgl2-sandbox)将运行而不会出现任何错误,但它们什么也不显示

编辑:我在 Firefox 54 和 chrome 60 中测试过它们
我使用 bufferGeometry 和 ShaderMaterial 的示例将在 webglrenderer 中正常工作

没人回答我吗? webgl2renderer 现在有什么问题?

@MHA15大概没有包含在构建中,因为它还没有准备好投入生产。

大家好,WebGL2Renderer 的开发进展如何?
我知道决定从头开始重新创建它。 但是已经有一段时间了,这个主题的发展有点缓慢,因为我相信重新创建它需要大量的工作。

此时,我们是否可以重新考虑克隆 WebGLRenderer 并将其更改为 WebGL2,而不是像@mattdeslhttps://github.com/mrdoob/three.js/issues/8125中所做的那样? 然后,我们可以根据@fernandojsg所说的 UBO 等一些新功能修改渲染器。 最终,我们将删除所有这些 webgl 1 遗留代码。

在我看来,从头开始创建渲染器需要大量的工作,理想情况下它只能从少数贡献者开始。 这场对话始于一年前。 除非我们有一个救世主,他会花几个月的时间从头开始构建它,否则我相信明年我们可能会在同一页面上。

在我看来,从头开始创建渲染器需要大量的工作,理想情况下它只能从少数贡献者开始。

这是真的。 但即便如此,我认为这比通过在各处添加条件来使WebGLRenderer更难维护要容易。 在过去的 5 年中,我大部分时间都在努力使WebGLRenderer更易于阅读和维护。

另外,我认为@fernandojsg计划在未来几周内尝试一下。

棒极了。 期待@fernandojsg 的出色工作!!

PS我得说..感谢这个项目的所有贡献者拓宽了我对计算机图形学的视野。 希望我将来能够贡献一些例子。

我同意@mrdoob的观点,从头开始创建一个新的渲染器比修改当前的渲染器更容易。
正如他所说,我想在接下来的几周内尝试一下。 我的方法是开始在屏幕上创建一个简单框所需的内容,并逐步向其添加功能,而不是采用已经存在的内容并尝试对其进行重构。
举个例子,看看WebGLRenderer的当前状态,已经有很多关于使其更加模块化和可定制的讨论,但即使内部代码随着时间的推移不断改进,从那里开始只是一个黑匣子。
一旦我有一些工作,我会打开一个 PR,这样我们就可以继续讨论接下来的步骤。

当我们在做的时候...... 5f889ce296aaf447ec5992a6df726691098a9110 8aab6e0382cd6ba8fd3fb943e7f65141bf3a50bc
webgl2_sandbox再次工作(虽然需要 es6 模块)。

@mrdoob你有什么粗略的估计什么时候可以在主版本/版本中使用? :) 我很高兴它正在发生! :)

@wdanilo不是真的...您需要 WebGL2 的哪些功能?

@mrdoob最大的改进将来自统一缓冲区对象和 Sampler2DArray。 纹理数组将对我当前的项目非常有益,因为我们正面临纹理单元的限制,因为我正在使用一个复杂的着色器,该着色器对由 alpha 贴图掩盖的多个材质进行分层。

@mrdoob glsl中的flat等新关键字也会很有帮助。

我的项目需要 3D 纹理。

有趣的...
了解人们需要 WebGL 2.0 的特定情况非常有帮助。
让他们继续来!

3D 纹理也是我们的一大特色。 我认为我们还使用了一些着色器功能。

有时我想要捷运

+1 也适用于多个渲染目标

WebGL1 已经通过扩展支持多个渲染目标,ThreeJS 中甚至还有一个 PR: https ://github.com/mrdoob/three.js/pull/9358(演示)。

我认为多重采样渲染目标是我最喜欢的功能。 大多数客户都要求进行后期处理(bloom、LUT 等),但他们对后期 FX 实施后缺乏适当的抗锯齿感到失望。 使用 MSAA 渲染目标,我们终于可以拥有一个很好的抗锯齿和后处理场景。

我同意。 使用效果合成器在后处理场景上用于抗锯齿的解决方法着色器不足以实现真正的抗锯齿。

+1 用于绘制反馈。 或者它是否已经被支持为 webgl1 扩展
三?

2017 年 12 月 14 日星期四晚上 9:45,Kyle [email protected]写道:

我同意。 用于后期处理场景抗锯齿的变通着色器
带有效果的作曲家不足以实现真正的抗锯齿。


您收到此消息是因为您发表了评论。
直接回复此邮件,在 GitHub 上查看
https://github.com/mrdoob/three.js/issues/9965#issuecomment-351815640 ,
或使线程静音
https://github.com/notifications/unsubscribe-auth/AHTX1RhYdGuTVSpmOy1ka-6gy1eslHQAks5tAXrFgaJpZM4Kj_9l
.

我在这里有几个用例:

  1. 我需要 MRT - 目前我正在渲染相同的着色器 4 或 5 次,更改属性只是为了获得不同的缓冲区。
  2. 使用抗锯齿渲染到纹理对我们来说是一个重要功能——我们制作了一个带有可视化预览的“节点编辑器”。 每个可视化只是一个纹理,我们也绘制了一些东西,没有适当的抗锯齿在这里是一件痛苦的事情。
  3. “flat”关键字——我现在用浮点属性索引几何,这显然是次优的——比用 uint 索引更差。 我将这个属性从顶点传递到片段着色器,我现在不能使用 uint,因为我们缺乏对“平面”kwrd 的支持。
  4. (较小)3D 纹理非常适合我们希望在不久的将来支持的高端可视化。

一起使用抗锯齿和后期处理对我来说是最重要的。

@mrdoob我的前 3 个 WebGL 2 功能/用例(按重要性排序):

  1. 多重采样渲染目标:用于后处理中的正确 (MS)AA。
  2. 整数纹理:用于执行基于图像的算法,如带符号距离场,以及使用更奇特的基于纹理的数据,如 DEM(数字高程模型)。
  3. 变换反馈:用于制作粒子系统。

@mrdoob 顺便问一下,你知道为什么#9358 PR 没有被合并吗? 正如@mattalat所写,它为threejs 带来了多目标渲染。 2年前提交,修复了几次以跟上其他更改,直到现在它还没有:(

我问这个问题是因为我有一个场景大量使用 SDF 形状描述。 每个形状输出 6 个不同的输出,所以现在我计算它 6 次,传递给从 0 到 5 的着色器编号。使用多个输出会更好,它只会带来 5 倍的性能提升。

@wdanilo这可能不是正确的时间(当时渲染器中有许多移动的东西)。 此外,似乎它包括容易引起冲突的构建。 有人愿意做新的公关吗?

/cc @edankwan

我们需要 3D 纹理和多样本渲染目标。

我正在寻找使用它,所以我可以设置 depthTexture.type = THREE.FloatType.. 除非目前有另一种方法可以做这样的事情。

是否有希望 LineThickness 不是 1 可以在 Windows 和 WebGL 2.0 上运行? 如果是,它将改善我们的一些输出。

在这里我回答自己。 在 SO 上使用三线基本材料读取线的粗细,我知道粗线在未来无论如何都需要几何。

@Richard004这与 WebGL 2 无关。我们已经为此功能请求提交了 PR,请参阅 #11349 👍

@mrdoob和@Mugen87
我需要在片段着色器中进行位操作以及动态数组索引。 第一个可能不是很常见,但无论如何我都需要它,因为我正在尝试将 CUDA 内核移植到 WebGL (GLSL) 和其他着色器语言允许位操作,但 WebGL 1.0 (GLSL) 不允许。

第二个我认为很多开发人员可以从中受益:即使用变量访问数组元素。 目前在 WebGL 1.0 (GLSL) 中,这样的程序会失败:

int myData[200];
int x = 3; // 'x' might change later based on my lookup needs
int requestedData = myData[x];

但是在 WebGL 2.0 中,您可以这样做。 在循环中经常需要它,您需要从数组中获取不同的值,但您不能只进行迭代循环(例如上面示例中的 0 到 199),因为这样您就需要检查每一个元素,这真的很慢。

后处理中的抗锯齿肯定是有益的。

所有这一切都是一个问题:是时候为 Three 设计一个新架构了吗?

我最近开始使用 D3,第 4 版。这是一个彻底的重新设计。 ES6
模块。 更重要的是, 30 个模块,每个模块都有自己的
回购。 我真的建议查看 D3 架构。

我不是说我们需要这个三个,但我认为我们可以考虑一个
主要版本凹凸。 部分原因是 webgl2。 但也因为需要
子模块。

一个例子:有一个 D3“选择”回购/子模块。 这是你的基本
jQuery DOM 模块,但 DOM 的所有冗长隐藏在一个
功能性,链式设计。 它可以按原样使用,而无需使用其余部分
D3。

难道你不喜欢制作所有 webgl 的三个独立模块吗?
冗长消失? 甚至可能有多个用于 webgl ctx/shader 的子模块
管理、缓冲区管理等。 实际上,缓冲区几何结构是
很多这样的。 同样适用于从零件创建着色器。

只是一个想法。

@elunty FXAAShader 与原始抗锯齿相比没有产生足够好的结果,我已经在野外使用它。

我最感兴趣的是 VAO 和写 mipmaps,我希望在该规范下是可能的。

@pailhead相关 #8705 :wink:

期待对EXT_shader_texture_lod的原生支持。
它可以解决在大多数 Android 设备以及 MS Edge 和 Internet Explorer 上使用MeshStandardMaterialMeshPhysicalMaterial时生成的工件

@mrdoob您或您的团队是否有计划将 Threejs 更新到 Webgl 2.0? 该线程实际上需要数年时间,而所有其他框架都已经向前发展,但没有什么真正改变。 我很快就会做出一个艰难的决定,我们可能不得不迁移到巴比伦之类的地方,我真的很想留在三号。 我会,如果有的话,只是任何现代化的计划。

@wdanilo如果 WebGL 2.0 是您项目的优先事项,我建议您迁移到巴比伦。 我知道一些 three.js 贡献者正在计划开发它,但我个人专注于 WebVR 和艺术家工作流程(svg 支持等)。

@mrdoob我非常感谢您在这里的快速回答。 我真的不想放弃three.js。 我喜欢这个库是如何在底层构建的,它的假设是“通用”框架,而不是“以游戏为中心”等。无论如何,感谢您提供的信息并保持这一点。

(再次感谢@takahirox ,我知道这个线程)。 我刚刚提出了一个拉取请求 #13692。 我知道重点不在于它,而是为了我们的目的,它一直运作良好。

相关#13702

我在 #9965 和 #12250 之后创建了 WebGL2 基础分支

回购: https ://github.com/takahirox/three.js/tree/WebGL2Base
示例: https ://rawgit.com/takahirox/three.js/WebGL2Base/examples/index.html

你可以用它启动 WebGL2.0 + Three.js。

(抱歉与@yoshikiohshima 的作品有冲突)

@mrdoob我们可以为 WebGL2Renderer 提供一个分支,例如three.js/dev-2.0吗? 或者我们可以将它合并到 dev 中,webgl1 和 webgl2 之间仍然有很多重复的代码吗?

我对这个问题的过去发展不熟悉。 @takahirox ,您能否总结一下您正在采取的策略以及https://github.com/takahirox/three.js/tree/WebGL2Base 支持什么? (再次为我的无知感到抱歉)但我没有看到需要大量重复的代码来支持 WebGL2。 有哪些问题?

@mrdoob我们可以为 WebGL2Renderer 提供一个分支,例如three.js/dev-2.0吗? 或者我们可以将它合并到 dev 中,webgl1 和 webgl2 之间仍然有很多重复的代码吗?

不知道为什么这需要一个新的分支。 为什么会有重复的代码?

似乎没有冲突。 现在对WebGL2.0有两个需求。

  1. 制作WebGL2Renderer以支持完整的 WebGL2.0 功能并优化好
  2. 为现有的WebGLRenderer添加webgl2支持。 但是我们并不完全支持 WebGL2.0 的特性,也不针对 WebGL2.0 进行优化,因为我们不想让渲染器混乱。 所以基本上这只是为了早期访问 Three.js + WebGL2.0 + GLSL3.0

我的是 1。他的工作是 2。我们没有重复的代码,也不需要为 2 创建新的分支。

@takahirox我认为暂时在同一个分支工作会更好。

如果你改进...

https://github.com/mrdoob/three.js/blob/dev/src/renderers/WebGL2Renderer.js

webgl2示例直接导入类(不需要构建)...

https://github.com/mrdoob/three.js/blob/dev/examples/webgl2_sandbox.html#L39 -L47

不应该有冲突。

到目前为止,您可以忘记我的 WebGL2Base,因为我们似乎在一个WebGLRenderer中开始了 WebGL2.0 支持。

我们还在考虑实现 WebGL2Renderer 吗?
我最近一直在寻找添加 WebGL2 支持的方法,我正在等待 takahirox 更改以重新调整我的基础。 但在做了一些更改之后,我开始认为重写渲染器以及 WebGLTextures 对象将是一个非常好的主意。 如果它仍然是热门话题,我很乐意参与。

我认为是的。 我认为为当前的WebGLRenderer添加基本​​的 webgl 2.0 支持只是为了在我们处理WebGL2Renderer时有所收获。

随意开始重写渲染器并发送 PR(最好是一步一步)。

抱歉,如果问明显的问题,但是在阅读了整个问题之后,最后一篇文章是半年前的,并且在主源代码和示例中都找到了一些对 webgl2 的引用,我似乎仍然无法弄清楚.

想知道 webgl2 在 Three.js 的当前状态下是否可用? (即使只是渲染简单的缓冲几何网格)EffectComposer 是否可以与启用 webgl2-context 的渲染器一起使用? 渲染目标是否必须以任何方式进行调整?

当然,最大的问题是当前是否可以在使用带有自定义通道的 composer 时获得适当的抗锯齿?

似乎最后我们只是在WebGLRenderer中添加了 WebGL 2.0 功能。
不过,WebGPU 肯定需要WebGPURenderer

此页面是否有帮助?
0 / 5 - 0 等级