NV_path_rendering替代 [英] NV_path_rendering alternative
问题描述
我刚刚观看了Siggraph 2012的一个非常令人印象深刻的演讲:
I just watched a very impressive presentation from Siggraph 2012:
http://nvidia.fullviewmedia.com/siggraph2012/ondemand/SS106.html
我的问题是，这是Nvidia的专有扩展，在GPU上快速渲染Bezier路径的其他可能性还有哪些?另外，是否有希望最终成为OpenGL标准的一部分?是否可以给出任何时间估计何时最终发生?
My question is, this being a proprietary Nvidia extension, what are the other possibilities to quickly renderer Bezier paths on GPU? Alternatively, is there any hope this will end-up as part of OpenGL standard? Is it possible to give any time estimate on when this eventually happens?
您是否知道其他任何涉及GPU路径渲染的项目(最好是开源项目)?
Do you know of any other (preferably open source) project dealing with GPU path rendering?
原始文档现在有一个新的附件":
There is now a new "annex" to the original paper:
https://developer.nvidia.com/站点/默认/文件/akamai/gamedev/files/nvpr_annex.pdf
推荐答案
现成的替代方案
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
Ready made alternatives
NanoVG (https://github.com/memononen/nanovg) appears to have a little bit of traction (http://www.reddit.com/r/opengl/comments/28z6rf/whats_a_popular_vector_c_library_for_opengl/). So you could look at their implementation. I have not used NanoVG myself though and I'm mostly unfamiliar to its internals; what I do know is that they have specifically rejected using NV_path_rendering: https://github.com/memononen/nanovg/issues/25
正如我在上面的评论中已经提到的那样，NV_path_rendering现在已在Skia中实现，并且似乎也受到cairo的欢迎，请参阅上面tjklemz的回答下方的我的评论，以获取有关这些详细信息的链接. NV_path_rendering的一个问题是，它在某种程度上取决于固定功能管道，因此与OpenGL ES 2.0有点不兼容.但是有一种解决方法
As I mentioned already in a comment above, NV_path_rendering has now been implemented in Skia and appears to be courted by cairo too, see my comment below tjklemz's answer above for links on those details. One issue with NV_path_rendering is that it is somewhat dependent on the fixed-function pipeline, so a bit incompatible with OpenGL ES 2.0., but there's a workaround for that https://code.google.com/p/chromium/issues/detail?id=344330
我会远离任何与OpenVG相关的内容.该委员会的工作在2011年已经结束；它现在基本上已经是旧产品/API.根据 https://github.com/memononen，OpenVG的大多数实现(包括ShivaVG)也是古老的，并使用固定功能的OpenGL. /nanovg/issues/113 如果您确实必须使用类似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的完整实现；请查看其代码页上的待办事项"部分，以了解缺少的内容.
I would stay away from anything OpenVG-related. The committee working on that has folded in 2011; it's now basically a legacy product/API. Most implementations of OpenVG (including ShivaVG) are also ancient and use fixed-function OpenGL according to https://github.com/memononen/nanovg/issues/113 If you really must use an OpenVG-like library, MonkVG appears the most well maintained [read as: the most recently abandoned] among the free ones (code: https://github.com/micahpearlman/MonkVG; 2010 announcement http://www.khronos.org/message_boards/showthread.php/6776-MonkVG-an-OpenSource-implementation-available). They claim it works on Windows, MacOS X, iOS and Android via OpenGL ES 1.1 and 2.0. The [fairly big] caveat is that MonkVG is not a full implementation of OpenVG; see the "TODO" section on their code page for what's missing.
我还发现，开罗(& pango)开发人员Behdad Esfahbod已经编写了一个新的字形(即字体)渲染库( GLyphy 是使用OpenGL ES2阴影语言的有符号距离字段(SDF)文本渲染器.[ …GLyphy使用提交给GPU的实际矢量来表示SDF.这将导致非常高质量的渲染."据我所知，它尚未在开罗使用. (贝达(Behdad)[从Red Hat]移至Google，而且开罗(Cairo)已有相当一段时间没有发布了，所以也许GLyphy会进入Skia，谁知道...)我不确定该解决方案对任意性的推广性如何.路径. (换句话说，NV_path_rendering也可以渲染字体并使用字距调整，以防万一您不知道.)在Linux.conf.au 2014上有个演讲，如果您对GLyphy感兴趣，您绝对应该注意: a href ="https://www.youtube.com/watch?v=KdNxR5V7prk"> https://www.youtube.com/watch?v=KdNxR5V7prk 如果您不熟悉(原始)的SDF方法，请参见 http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf
I also found that a cairo (& pango) dev, Behdad Esfahbod, has written a new glyph (i.e. font) rendering library (https://code.google.com/p/glyphy/): "GLyphy is a signed-distance-field (SDF) text renderer using OpenGL ES2 shading language. [...] GLyphy [...] represents the SDF using actual vectors submitted to the GPU. This results in very high quality rendering." As far as I can tell it's not used in Cairo yet. (Behdad moved to Google [from Red Hat] and cairo hasn't seen releases in quite a while, so maybe GLyphy is gonna go into Skia instead, who knows...) I'm not sure how generalizable that solution is to arbitrary paths. (In the other direction, NV_path_rendering can also render fonts and with kerning, in case you didn't know that.) There is a talk at Linux.conf.au 2014 which you should definitely watch if you're interested in GLyphy: https://www.youtube.com/watch?v=KdNxR5V7prk If you're not familiar with the (original) SDF method, see http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf
我发现Mozilla开发人员在一次演讲中总结了当今使用的常见方法: https://www.youtube.com/watch?v=LZis03DXWjE#t=828 (时间戳是跳过引言部分，告诉他什么是GPU.)
I found a talk by a Mozilla dev which summarizes the common approaches in use today: https://www.youtube.com/watch?v=LZis03DXWjE#t=828 (The timestamp is to skip the intro part where he tells you what a GPU is.)
顺便说一句，很多路径渲染的东西都是命令/状态改变密集的.我认为是Mantle，DX12及其类似的OpenGL(主要是扩展名 http://gdcvault.com/play/1020791/)可能会有所改善.
By the way, a lot of the path-rendering stuff is command/state-change-intensive. I think that Mantle, DX12, and the OpenGL equivalents of that (mostly extensions http://gdcvault.com/play/1020791/) will probably improve that a fair bit.
我想我还应该提到Nvidia已获得(至少)与NV_path_rendering相关的四项专利:
I guess I should also mention that Nvidia has been granted (at least) four patents in connection with 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
- 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文档与也发布为"相关，其中大多数是专利申请，因此完全有可能从这些专利中获得更多专利.对此进行更新:Google并未将它们全部 链接在一起，因此可以肯定地授予了更多的信息:
Note that there are something like 17 more USPTO docummets connected to these as "also published as", most of which are patent applications, so it's entirely possible more patents may be granted from those. Update on this: Google doesn't quite link all of them together, so there are some more that have been granted for sure:
- https://www.google.com/patents/US8786606
- https://www.google.com/patents/US8773439
我不确定他们愿意以什么条款许可这些人...
I'm not sure under what terms they are willing to license those...
我发现基尔加德本人对向量图形/路径渲染有何特别之处"发现了一个非常好的常见问题解答，但不幸的是，该问题隐藏在OpenGL论坛的某个地方http://www.opengl.org/discussion_boards/showthread.php/175260-GPU-accelerated-path-渲染?p = 1225200& viewfull = 1#post1225200 .对于任何考虑快速/破解替代解决方案的人来说，这都是非常有用的阅读.
I found a really nice FAQ by Kilgard himself for "what's special about vector-graphics/path-rendering" which is unfortunately buried somewhere in the OpenGL forum http://www.opengl.org/discussion_boards/showthread.php/175260-GPU-accelerated-path-rendering?p=1225200&viewfull=1#post1225200. This is quite a useful reading for anyone considering quick/hack alternative solutions.
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/
There is also one new thing in Direct3D 11.1 that's possibly useful because Microsoft used it to improve their Direct2D implementation with it in Windows 8; it's called target independent rasterization (TIR). I don't know much about it other than that Microsoft has a patent application on it. http://www.google.com/patents/US20120086715 The catch is that only AMD GPUs seem to actually support it per this "war of words" http://www.hardwarecanucks.com/news/war-of-words-between-nvidia-and-amd-over-directx-11-1-support-continues/
关于NVpr何时会被非Nvidia采纳，我没有一个水晶球，但是我认为他们正在努力地推动这一发展. OpenGL 4.5 Nvidia演示文稿已经被它所取代-至少就演示软件而言，我认为这有点愚蠢(因为它不是OpenGL 4.5内核的一部分).尼尔·特雷维特(Neil Trevett)也多次报道了NVpr(例如 https://www.youtube.com/watch?v= eTdLwfOLoG0#t = 2095 )和 Adobe Illustrator beta 2014正在使用它以及Google的Skia.
I don't have a crystal ball as to when NVpr is going to get adopted by non-Nvidia, but I think they are pushing it quite hard. The OpenGL 4.5 Nvidia presentation has pretty much been taken over by that--at least as far as demos ware concerned, which I thought was a bit silly (since it's not part of OpenGL 4.5 core). Neil Trevett also covered NVpr more than once (e.g. https://www.youtube.com/watch?v=eTdLwfOLoG0#t=2095) and Adobe Illustrator beta 2014 is using it as well as Google's Skia.
这篇关于NV_path_rendering替代的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
