游戏建模为什么不能是 blender + Zbrush 的工作流呢?
举个例子——
blender允许不为任何面所有的独立边。
它允许存在poly curve。
将svg线条导入blender会将所有点自动识别为smooth点。
它的constraint和geometry node非常强大,但是却恰恰是因为强大,反而与其他体系很难兼容。
那意味着导出之后这些属性都会有些问题。
很多这类设定会导致它在导入其他软件或者引擎时出现隐患。
这种隐患很可能不立刻在下一个流程里体现出来,而是在最后导入引擎后出现奇怪的法线问题、碰撞检测问题、缩放问题。要定位这些问题常常非常困难——甚至是不可能的。
blender对fbx格式的支持自己都分legacy版本和新版本,是用插件实现的。
这些成本对这些工艺已经成熟的企业是很不想去花时间适应的。
反过来,那些正版max、maya、zbrush的授权费用,比起那些资深游戏美术的薪资来说根本不值一提,谈不上多大的成本节省,更不必说这笔钱花出去,其实主要是买了一个热情而随叫随到的客服。
企业运行有这个客服非常重要。
blender的前途是很远大的,只是现在还没到时候。
说它前途远大,其实主要是因为omniverse可能成为未来的新中间件标准。
所有的DCC软件都会渐渐趋向于去支持omniverse工作流,而ominiverse主推的USD格式有希望替代FBX格式。而blender看上去赶上了这个新浪潮。
换言之,USD可能抹平blender在这方面的技术欠债。
一旦这个被抹平了,blender很有希望成为一个和max和maya分庭抗礼的对手。
尤其是,现在这个blender app的方向很有意思,可能成为blender的新优势。
并且,也不能忽略blender core直接孵化出新的游戏引擎的可能性。
总之,blender虽然现在还不太能直接顶替max,但是作为个人工作流还是很不错的。
毕竟它一家就足以免掉你买那么一大堆软件的费用。
尤其是,它不依赖x86架构,你可以在mac甚至linux上使用它——这个可是真正重要的特性。
这意味着有一天max、maya可能会给操作系统陪葬,但blender一定不会。
本博客所有文章除特别声明外,均采用 CC0 1.0 协议 。