半夜失眠，码点关于技术美术的字

机缘巧合做了一段时间技术美术。

遇到过几次有人说技术美术一将难求，难以找到合适的。

实际上对于技术美术，我的意见是，空降不如自己培养。至于原因要从头说起。

我上一篇帖子说，美术和程序之间的沟通容易出现问题，所以才出现了技术美术。其实技术美术到不一定非要是做美术的，程序了解一些美术的工具，和制作过程，也可以称其为技术美术。不过因为大部分程序平时不用美术的工具，所以这样的技术美术，就比较偏程序，相对来做起的作用不如偏美术这边的大。

以我所知，某公司，定期会强制一部分程序学习美术用的工具、了解美术的制作过程。这个措施不错，虽偶尔也会有一些问题出现，但总体说利大于弊。

双方沟通之所以容易出问题，一方面是因为专业不同的缘故导致双方的知识有不同，还有一方面原因就是，双方在一开始，就已经划分了阵营。

先说第一个，我举两个例子。

第一个，比如大部分美术脑海里，颜色 RGB都是0-255.然后如果跟他们说颜色范围是0-1，会不理解。255是啥呢？是2的8次方...，0-255来表示颜色是很偏程序的方式，但是因为先入为主很多美术就觉得0-255才是正常的。写着色器都是0-1表示颜色，一些美术反倒觉得不正常了。0-1的范围很好理解嘛，就是RGB三管颜料，每管挤出一些，1就是全挤，0.5就是半管，0就是不挤，完了混合一下........。

再说一个，过去工作中曾有美术感觉材质贴图在Max当中看到的与引擎中看到的不同，于是提出需求想要二者统一。当时的美术这边的技术思路是在Max的材质上下手，因为Max可以用HLSL来做实时显示的材质。然而这个事情一般也只能找程序实现，这种需求的优先级恐怕是低的不能再低了。当时我对该项目的引擎有所了解，于是我就尝试了一下，用引擎写了一个简单的程序，作用是加载一个简单的场景然后加载模型，每秒重新读取贴图文件刷新一次。这样美术画贴图的时候，同时开着这个程序，想看引擎的效果时，只要保存一下，程序就更新贴图了。此处有个插曲，美术大部分画贴图的时候是用Photoshop保存Psd文件，贴图最后完成后再另存一个引擎所用格式。当时所用引擎不能直接读取PSD，所以我又写了一个Photoshop的脚本，在保存文件时同时另存一个DDS文件。并且如果有名字为"UVW"的图层，会在保存前隐藏，保存后恢复。实质上因为游戏中场景各有不同，这个程序并不是一个完善的贴图查看工具。不过可以在正式的工具出现之前暂时使用。而且游戏中的材质有可能有自定义的参数传入，如果是给Max写一个HLSL很可能跟不上游戏中着色器的改变速度，慢慢就被拖得毫无意义了，而用引擎做，其实对程序来说并不需要做多少工作。这就是为什么我上一个帖子说技术美术需要可以自己用当前项目的引擎做一个简单的游戏。此外也可以看出技术美术的工作实际上很杂。可以说是需要什么就学什么。此外也是必须杂，先求广度而后求深度，这样遇到情况可以综合各方面来思考最优方式。

此外还有一些效果的实现，比如寒霜引擎中的温度计。除去模型生成的部分，其实就是用这一个参数去控制着色器和场景效果（比如粒子）的混合。这种需求如果是没接触过程序的美术去描叙，可能就描叙成神话故事了....

 关于自动划分阵营，我可以说一种情况，比如说下图：

上图是来自街头霸王4的角色隆；左面的画面很有风格，于是很多美术会喊着这是程序做的风格化渲染效果，但是其实是法线贴图上做了一层纹理叠加，如果没有这层纹理就是右面的样子。

再比如下图

上图来自 火影忍者 究级风暴，可以看到里面角色运动较快的地方有很卡通的拖尾效果。很多美术也会认为这是程序实现的，是引擎功能，实际上主要是美术制作的手段，就像图片的上半部分。

上面两图的这类情况，如果是程序去告诉美术“这个和程序无关，是美术制作的事情”。

美术的感觉是“你就不想做、我们美术只能这么山寨”等等。

但如果是美术去对美术说这种做法，听到的美术的感觉就是“我去，还可以这么做，太帅气了，我们也不是非要有程序支持才能有突破”

这也是为什么我上一篇关于技术美术的帖子说千万不能把技术美术当作程序来看。一旦你有意无意使得技术美术在团队中被当作程序，他就被放到了美术的对立面。实际上我做技术美术这两年多以及长久以来和人的交流中发现，很多时候问题本来简单，就是双方不知不觉的就有了一种对立的心理才导致问题变得复杂。也是为什么我认为空降技术美术很不合适，因为空降过来的如果是了解一些程序的，很容易被当作程序对待，尤其是团队中美术过去并没有和技术美术合作过的时候，非常容易导致空降的技术美术被当作程序。

 当然，对于做技术美术的人来说自己也要多搞一些美术技术方面的东西，自身也要避免给美术一种整天写代码的感觉。

 

 

 

转载于:https://www.cnblogs.com/sitt/archive/2012/03/26/2417313.html