NV_path_rendering 替代方案 [关闭]

Posted 2023-03-16

【中文标题】NV_path_rendering 替代方案 [关闭]

【英文标题】：NV_path_rendering alternative [closed]

【发布时间】：2012-10-08 17:20:49

【问题描述】：

我刚刚观看了 Siggraph 2012 上令人印象深刻的演示：

http://nvidia.fullviewmedia.com/siggraph2012/ondemand/SS106.html

我的问题是，这是一个专有的 Nvidia 扩展，在 GPU 上快速渲染 Bezier 路径的其他可能性是什么？或者，是否有希望最终成为 OpenGL 标准的一部分？是否有可能给出最终发生的时间估计？

你知道处理 GPU 路径渲染的任何其他（最好是开源的）项目吗？

编辑：原论文现在有一个新的“附件”：

https://developer.nvidia.com/sites/default/files/akamai/gamedev/files/nvpr_annex.pdf

【问题讨论】：

"或者，是否有希望最终成为 OpenGL 标准的一部分？" 不。OpenGL 是一个低级渲染API。绘制曲线等并不是低级的。此外，OpenVG 已经存在；如果 NVIDIA 真的想推广 GPU 路径渲染，他们会实现 that。他们真正想要的是人们使用他们的硬件，所以他们通过 OpenGL 的扩展机制来制作专有的 API。

@Nicol Bolas：GL 过去包含了曲线绘制——还记得评估者吗？并且标准更多的是“这是 GL 实现可能比更抽象的层更有效地做的事情吗？”，我认为 NVPR 可以合格。至于 OpenVG，这远没有紧密集成。

"GL 过去包含了曲线绘制 - 还记得评估者吗？" 是的，他们做到了。然后他们把它们拿出来。 OpenVG 当然可以直接在 GPU 上实现。这就是他们设计它的工作方式。所以我不知道“紧密集成”在这方面意味着什么。

我的意思是与OpenGL紧密集成； NVPR 绘图可以转换为 3D 空间、针对场景中的“真实”3D 几何进行深度测试、纹理化、在片段级别以编程方式着色等。AIUI OpenVG 不支持任何这些。

关于 Nicol Bolas 的 cmets：我不想把这变成一场争论，但 Khronos 的总裁 Neil Trevett，你可能知道，他也是 Nvidia 副总裁，一直在大力宣传 NV_path_rendering几乎他在过去几年中发表的每一次主题演讲/演讲。 khronos.org/assets/uploads/developers/library/…khronos.org/assets/uploads/developers/library/…slideshare.net/NeilTrevett/…

【参考方案1】：

现成的替代品

NanoVG (https://github.com/memononen/nanovg) 似乎有一点吸引力 (http://www.reddit.com/r/opengl/comments/28z6rf/whats_a_popular_vector_c_library_for_opengl/)。所以你可以看看他们的实现。不过，我自己并没有使用过 NanoVG，而且我对它的内部结构也很陌生。我所知道的是他们已经明确拒绝使用NV_path_rendering:https://github.com/memononen/nanovg/issues/25

正如我在上面的评论中已经提到的，NV_path_rendering 现在已经在 Skia 中实施，并且似乎也受到了 cairo 的青睐，请参阅我在 tjklemz 上面的答案下方的评论以获取有关这些详细信息的链接。 NV_path_rendering 的一个问题是它在某种程度上依赖于固定功能管道，因此与 OpenGL ES 2.0 有点不兼容。但有一个解决方法https://code.google.com/p/chromium/issues/detail?id=344330

我会远离任何与 OpenVG 相关的东西。从事这项工作的委员会于 2011 年解散；它现在基本上是一个遗留产品/API。 OpenVG 的大多数实现（包括 ShivaVG）也很古老，并且根据https://github.com/memononen/nanovg/issues/113 使用固定功能的 OpenGL 如果你真的必须使用类似 OpenVG 的库，MonkVG 似乎是维护得最好的 [阅读为：最近放弃的] 在免费的（代码：https://github.com/micahpearlman/MonkVG；2010 年公告http://www.khronos.org/message_boards/showthread.php/6776-MonkVG-an-OpenSource-implementation-available）中。他们声称它可以通过 OpenGL ES 1.1 和 2.0 在 Windows、MacOS X、ios 和 android 上运行。 [相当大的] 警告是 MonkVG 不是 OpenVG 的完整实现。请参阅他们代码页上的“TODO”部分了解缺少的内容。

我还发现 cairo (& pango) 开发人员 Behdad Esfahbod 编写了一个新的字形（即字体）渲染库 (https://code.google.com/p/glyphy/)：“GLyphy 是一个有符号距离-使用 OpenGL ES2 着色语言的字段 (SDF) 文本渲染器。[...] GLyphy [...] 使用提交给 GPU 的实际矢量表示 SDF。这会产生非常高质量的渲染。”据我所知，它还没有在开罗使用。 （Behdad [从 Red Hat] 搬到 Google 并且 cairo 已经有一段时间没有看到发布了，所以也许 GLyphy 会转而进入 Skia，谁知道......）我不确定该解决方案对任意性的普遍性路径。 （在另一个方向上，NV_path_rendering 也可以渲染字体和字距调整，以防你不知道。）如果你对 GLyphy 感兴趣，你一定要看看 Linux.conf.au 2014 上的一个演讲：@ 987654329@如果不熟悉（原始）SDF方法，请参阅http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf

我发现了一位 Mozilla 开发人员的演讲，其中总结了当今使用的常用方法：https://www.youtube.com/watch?v=LZis03DXWjE#t=828（时间戳是为了跳过他告诉你 GPU 是什么的介绍部分。）

DYI（可能）

顺便说一句，很多路径渲染的东西都是命令/状态更改密集型的。我认为 Mantle、DX12 和它的 OpenGL 等价物（主要是扩展 http://gdcvault.com/play/1020791/）可能会改善这一点。

我想我还应该提到，Nvidia 已获得（至少）四项与 NV_path_rendering 相关的专利：

https://www.google.com/patents/US8698837 https://www.google.com/patents/US8698808 https://www.google.com/patents/US8704830 https://www.google.com/patents/US8730253

请注意，还有大约 17 份与这些相关的 USPTO 文件“也发布为”，其中大部分是专利申请，因此完全有可能从中授予更多专利。对此的更新：谷歌并没有完全将它们所有联系在一起，所以肯定还有更多：

https://www.google.com/patents/US8786606 https://www.google.com/patents/US8773439

我不确定他们愿意根据什么条款许可这些...

我找到了 Kilgard 自己的一个非常好的常见问题解答，关于“矢量图形/路径渲染的特别之处”，不幸的是它被埋在 OpenGL 论坛http://www.opengl.org/discussion_boards/showthread.php/175260-GPU-accelerated-path-rendering?p=1225200&viewfull=1#post1225200 的某个地方。对于任何考虑快速/破解替代解决方案的人来说，这都是一本非常有用的读物​​。

Direct3D 11.1 中还有一项新功能可能很有用，因为 Microsoft 使用它来改进他们在 Windows 8 中的 Direct2D 实现；它被称为目标独立光栅化 (TIR)。除了微软有一个专利申请外，我对此知之甚少。 http://www.google.com/patents/US20120086715 问题在于，似乎只有 AMD GPU 真正支持这种“口水战”http://www.hardwarecanucks.com/news/war-of-words-between-nvidia-and-amd-over-directx-11-1-support-continues/

采用

我不知道 NVpr 何时会被非 Nvidia 采用，但我认为他们正在努力推动它。 OpenGL 4.5 Nvidia presentation 几乎已经被它取代了——至少就演示软件而言，我认为这有点愚蠢（因为它不是 OpenGL 4.5 核心的一部分）。 Neil Trevett 还不止一次报道了 NVpr（例如 https://www.youtube.com/watch?v=eTdLwfOLoG0#t=2095）和 Adobe Illustrator beta 2014 is using it 以及 Google 的 Skia。

【讨论】：

非常感谢您的详细解答！请，如果您知道任何新的发展，请再次在这里分享。

这东西有什么更新吗？已经2年了。

【参考方案2】：

ShivaVG 是路径渲染的开源替代方案。有关 OpenVG 实现的列表，请参阅此 Stack Overflow 问题：Best OpenVG Implemenatation

基本上，您有几个选择：使用 OpenVG 实现（如 ShivaVG），使用 OpenGL 实现或扩展（如 NV_path_rendering)，或者完全使用其他东西，例如 Direct2D。

但是，NV_path_rendering 的其他替代方案甚至无法接近其功能集和渲染质量。 NV_path_rendering 可以原生处理字体（这是一个大 交易 - 没有字体，你是烤面包），以真实视角缩放等（在 Illustrator 中尝试！），与 3D 混合，使用 sRGB ，使用片段着色器，并以惊人的速度完成这一切。它还实现了用户交互，OpenVG 没有指定 AFAIK。

独特地，NV_path_rendering 没有发明了一个新标准。相反，它实现了几个行业标准，例如 PostScript 和 SVG，重点关注质量和速度（很少同时具备这两者），这是您目前在其他任何地方都找不到的.

（另外，Mark Kilgard 是项目负责人。来吧。这家伙很聪明。）

---

它会成为标准吗？很难知道。至于使用什么，这实际上取决于您此时的目的/需求。寻找应用程序的高质量路径渲染？ NV_path_rendering 肯定。在应用程序（尤其是移动设备）中寻找基本分辨率无关的图形？ OpenVG 可能会更好。 Nvidia 的解决方案不是完全可移植的，这太糟糕了，但我不会回避使用它。我更喜欢有质量的解决方案；有时可移植性并不是一切。

Nvidia 将他们的解决方案与 OpenVG 进行了比较，不幸的是，OpenVG 并没有提供太多好处。所以，是的，它可能有希望成为一个标准。但是，根据 IBM 的说法，未来一切都将被嵌入，也许希望它是开放的，而不是想要更多的标准。

“标准的好处是你有很多选择。” -- 计算机网络，第 2 版，p。 254

---

有关 NV_path_rendering 功能的更多信息，我建议您查看：An Introduction to NV_path_rendering。

【讨论】：

关于 NV_path_rendering 的更新演示文稿位于 on-demand.gputechconf.com/gtc/2014/presentations/… 。 Skia（Google Chrome 的 2D 库）现在支持它。开罗人似乎也对它感兴趣 lists.cairographics.org/archives/cairo/2013-March/024134.html 但 AFAICT 那里还没有实现。

【参考方案3】：

在 GPU 上快速渲染贝塞尔路径的其他可能性是什么？

使用细分和/或几何着色器将一组控制点原位细分为由三角形外壳定义的凸块。然后将曲率参数传递给片段着色器，如果片段在每个补丁的边界内，则执行每个片段的测试，否则将其丢弃。

如果一个近似值是有序的，那么只需镶嵌成一个三角形网格就可以了。