Troika: 改进文本抗锯齿的快速想法

感谢您的建议！ 我肯定会调查这个，因为我也注意到倾斜角度的那些模糊边缘并且想消除它们。

从理论上讲，我认为distance的变化和vTroikaGlyphUV * vTroikaGlyphDimensions的变化应该是等价的，因为它们都代表了字体空间单位的距离，但是我必须有一些细微的差别被忽视了。 如果我可以避免您展示的工件，那么我很乐意整合您的更改。 :)

伟大的！ 更改就像那一行一样简单（并传入该距离参数以适应它）。 如果您仍然想要原始代码，我可以在明天工作时发送。

从理论上讲，我认为距离的变化和 vTroikaGlyphUV * vTroikaGlyphDimensions 的变化应该是等价的，因为它们都代表字体空间单位的距离

我不完全理解衍生品是如何相同的。 distance是我猜的 SDF 距离，但另一个是缩放的 uv 位置。 我没有查看代码以及它们的比较方式，但感觉它们的衍生产品应该不同。 据我所知， fwidth只是将作为参数传入的特定输入值与相邻片段中的相同特定输入值的差异，这是可能的，因为相邻片段同时并行执行。 我今天早些时候用gl_FragColor.rgb = vec3(fwidth(gl_FragColor.x + gl_FragColor.g + gl_FragColor.b));进行了一个测试，看看它是否像边缘检测/索贝尔过滤器一样渲染边缘，试图稍微确认一下这个事实，它确实做到了。

感谢您的讨论，这些东西有时会破坏我的大脑。 ;)

当我说它们是“等价的”时，我的意思是它们都代表相同单位的距离，但你是对的，它们并不完全相同。

备份，我们在这里想要的是片段之间的_潜在_变化率。 像您建议的那样使用distance变量中的更改通常是准确的，但在某些情况下它会非常不准确。 这是因为从中采样该值的 SDF 是_non-uniform_； 它弯曲并在字形上切换其变化方向。 因此，相邻片段之间的distance的导数最终可能会变得太小，甚至为零，例如距离字段在字形路径之间从增加变为减少的位置，或者太大，例如在显示文本时在小尺寸和片段网格覆盖在不可预测的位置的 SDF。 我怀疑这至少可以解释您所看到的一些文物。

那么我们如何在不使用distance的情况下确定_潜在_变化率？ 好吧，您所说的“缩放的 uv 位置”本质上是字形矩形内的 x/y 坐标，使用与distance相同的单位。 x/y 的导数为我们提供了片段之间的潜在移动速率。 总体而言，这比使用distance提供了更好的结果，因为它基于字形中的 _uniform_ 变化率，因此我们不会得到伪影，并且在小尺寸下更准确。

但是，正如您所看到的，它在斜角处分解。 在这些情况下，垂直方向的潜在 x/y 变化率与水平方向的变化率大不相同。 因此，我们最终对一个方向的潜在变化率使用单个值，该值在一个方向上太大而在另一个方向上太小，根据 SDF 在该片段的实际变化方向给出模糊和/或断断续续的线条。

所以，是的，倾斜情况肯定有改进的余地，但仅使用distance的导数本身是不够的。 当然，我对改进这一点的想法持开放态度。 一种可能性是尝试检测场景（斜角的大文本大小，靠近路径）并仅在这种情况下使用distance导数。

是啊，这东西想想就让人费解，哈哈。 我可以看到距离场不太平滑，是的。

那些有问题的像素可能只是因为那里的片段有一些奇怪的距离值。

从远处看它并不是令人难以置信的波涛汹涌，但你肯定可以看到紫外线更好。 也许在距离变量和依赖于相机距离的 UV 之间进行插值会很好； 就像在靠近时选择更多的 fwidth(distance)，在远离时选择更多的 fwidth(uv)。

为了比较（没有在完全相同的相机位置和方向捕获两者，但我认为它无论如何都很好地显示了差异）：
距离（0.8 因子）：

紫外线：

我注意到此修改显着改善了自定义文本转换的结果。 这是一些文本，使用createDerivedMaterial修改为遵循曲线（请参阅此技术）。 这使用当前的三驾马车三文本着色器：

这是相同的屏幕截图，但@asbjornlystrup对troikaGetAADist的修改：

在第二张照片中，你可以看到极度拉伸的“GREAT！” 比较清脆。

有趣的是：我还发现将常数调整为 0.25（从 0.5）也会产生很好的清晰边缘：

return length(fwidth(vTroikaGlyphUV * vTroikaGlyphDimensions)) * 0.25;

谢谢@canadaduane ，我绝对可以看到拉伸部分的改进。 我还可以看到 HELLO 中的 L 之间出现了丑陋的伪影，在采用此更改之前，我们肯定需要弄清楚这一点。