[笨蛋熊] 【大道至简】颜色里的秘密 - 偏色篇 [复制链接]

在使用大漠插件等工具辅助脚本开发时，我们经常会遇到一些颜色没那么纯正但需要提取字形的场合。
如果是游戏里的大字就还好，虽然需要设置一些偏色，但是偏色范围通常不大，随手写一个101010或者202020之类的值，就可以对付过去了。

再复杂一点的情况，可能需要偏色计算器之类的工具，但这也只能用于辅助解决一些最简单的问题。

现在越来越多的游戏装备了抗锯齿字形渲染能力，让本就蛋疼的偏色处理雪上加霜，如下图：




当然，这是比较极端的情况，今天我们就一起循序渐进的尝试去解决不同难度的偏色识别。



难度 Lv0：整体容差偏色

这应该是大家最喜欢的同色字形，选择一个点之后整个字的轮廓立刻就出现了，不需要任何处理。

一些比较老的游戏引擎，或者游戏引擎支持的点阵字库一般使用这种方式处理图像。

通常我们在选取颜色之后，会象征性的添加一点偏色，以避免在不通电脑上，字的颜色有轻微差异，这种偏色添加的一般都比较随意，比如：080808

这里 080808 的意思就是拆分成RGB之后，每种颜色的值允许偏差8，想要大一点也可以填101010之类的数值，代表每种颜色允许偏差16（因为是十六进制）

不太建议设置为更大的数值了，比如202020，每种颜色偏差32，已经超过了所能表示最大颜色的20%，很容易出问题。





难度 Lv1：渐变色

渐变色也是处理起来比较简单的，方法是取3个颜色值，最上面取一次，中间取一次，最下面取一次（也就是截图里，我取的前三个颜色）。

然后对RGB分组进行处理，取3个数据的最大值和最小值，求两个值的平均数，以及平均数和最大值或最小值的差值，平均数就是分组颜色，差值就是分组偏色。

这个数值的范围应该适当扩大，然后取个整，方便计算，红绿蓝三种颜色分别计算一下，颜色和偏色就都出来了（也就是截图里，我填的第四种颜色）。

这个颜色填写进去，就能看到大漠插件二值化后的字形了，如下图：





难度 Lv2：动态字

很多游戏在自动寻路的时候，会有这种动态字出现（例子我选择了一种动态幅度不太大的，但是和环境色接近的，这种其实更难识别，红色那种一个HSV就解决了）

动态字一般都比较大，做了特效，可能会燃烧、闪烁、跳动；表面有类似流体的效果，这种处理起来比渐变色还要更麻烦一点。

但游戏毕竟是给人玩的，既然是给人看的，那就能解决，偏色不决，上HSV！

HSV上一篇文章科普过了，就是一个角度值加两个百分比值，角度值是360度，其中每60度是一种颜色，红绿蓝三原色和黄青紫三间色。

然后两个百分比值是颜色的纯净度和亮度。



你看这张图，用人眼的规则来分析，是不是非常简单，任他怎么变，总有一个数值是不变的，如果特效是发光，那颜色本身没变，变的是亮度。

如果是流水，那颜色本身和亮度变的不大，纯净度会有区别；当然，还有可能是形变，这种情况下针对每一个字单独做字库，然后合一起去找就行了。

剩下的和渐变色一个处理方法，采集两个极端点，一个中间点，对比颜色找到区别，然后计算偏色填进去就解决了，小意思（如下图）。

记得每个字单独录字库啊，不然字上下跳的时候就找不到了。





难度 Lv3：抗锯齿小字

也就是本篇一开始我发的那张截图，我特别喜欢处理这种字的偏色，因为它特别牛逼，解决了非常爽，但其实弄多了难度也就那样。




这种字最糟心的就是放大之后，取样的时候，取出来的颜色花花绿绿的，啥色都有，字是白的，但是取样发现，黄的、绿色、褐的、青的，各种颜色全都有。

真服气人类的智慧，把字渲染成这个样子之后，反倒更容易被眼睛识别，而且边缘看起来更清晰，你服不服气？

既然眼睛能识别，那说明这种字形必定要隐含的数据帮我们解决这个问题，采样的数据HSV分析一下。

发现原来是亮度，字形通过一组亮色和一组暗色，形成清晰的轮廓，而颜色反而是没必要的，反正你看到了啥，脑袋里混合一下之后，都是附近颜色的插值。

因此我们会使用一种技巧，叫做舍一保二调三。

什么意思呢？舍弃颜色的一个维度，保住颜色的第二个维度，然后调整第三个维度来把字形和其他数据区分开来。

对于我们现在的范例来说，舍弃颜色，保住亮度，调整饱和度（也就是颜色的纯净度），直接上结果吧，大家可以看一下截图里的颜色和偏色设置：



当然，这个其实不是最优值，比如亮度，我采集了这么多颜色，亮度实际范围是80 - 100，那我可以设置为90，偏色设置为 10，效果也是一样的，甚至更好。



难度 Lv4：3D游戏内特殊含义的符号

比如3D游戏打怪，怎么是别怪物呢？是不是很难，识别怪物随身附带的特征就容易多了，比如光圈，血条什么的。

我手头也没个游戏，不好做示范，这种东西的识别，颜色原理其实已经不是最重要的了，经过上一小节的洗礼，估计静态的光圈啊，血条啊，根本难不倒你。

难度其实集中在动态这两字上，因为3D游戏的动态非常凶猛，经常不同角度，不同距离，都有不同结果，所以识别问题主要在这呢？

能不能解决，其实可以的，咱们能把颜色给二值化出来，就能得到字形对吧，剩下的其实是程序问题了，比如多种采样，配合鼠标动作来检测。

挖个坑，之后有时间写一篇教程讲这个吧。



难度 Lv5：3D游戏的视角

比如吃鸡啊，画面摆在那里，你的角色朝着哪个方向啊？是看着天，看着地，还是目视前方啊。

3D游戏要是没有自动寻路的话，用脚本做寻路那可是极其蛋疼的，但也不是实现不了，小地图有视锥吧？视锥二值化不难吧？

然后配合代码识别吧。

这东西我也没办法讲很深，因为它其实是融会贯通的事情，当你对颜色的理解足够深厚的时候，你总是能在游戏画面里发现很多东西帮你做判断。

当你理解不够深的时候，可能就会思考，这玩意到底怎么实现的呢？不能够啊？

当然，颜色是一方面，逻辑和流程能力，又是一方面，再往大了走，数据的管理能力又是一方面。

很多商业作者实现的3D寻路，都是配合非常庞大数量的地图数据库的，把地图分区分块，先找特征定位，再一块一块的去处理。

这东西说是最难吧，有时候也就那样，难的其实是融汇贯通，和编程基本功，任何事情走到最后，拼的往往都是基本功。