是时候来讨论一下CG人的学习机和工作机的问题了

是时候来讨论一下CG人的学习机和工作机的问题了

又到了尬聊时刻:)

经过十几年的社区运营,我们观察到绝大多数学习Blender的用户对自己的电脑性能状况,现有的资源是否符合自己预想的工作模式,在构思自己的作品和设计内容需要架构在什么样子的平台上面,如何将自己所学所思内容和一些用户的需求结合通过实际的智力劳动变为等价的劳动收获方面,等等等,都不是非常的清晰,或者说每个用户你问到他这些问题的时候,回答往往是“车到山前必有路”,没有预先思考和琢磨过这些事情的细节。

在国内学习Blender的用户越来越多,斑斓社区的各个自媒体平台号都在超过了一万人和接近一万人的过程中。当然多的不止这个数,我们这里只谦虚的谈最少的,这样比较符合我们社区一向都因为制作很多的基础性免费全面的内容并不容易获得吸引眼球导致的很低调的行为方式。

在这篇内容中,我们不去谈机器的配置等等,我们会把这个课题留到 “Blender的2.83发布后,如何让自己硬件适应Blender的功能里”这样的专题中去讨论。让我们先来熟悉一些概念,让用Blender的用户们可以产生一些全局性的意识,就非常好了。

硬件社区有个很重要的概念:“量产”,把可以推向大众用户的硬件从实验室里面放到工厂里大批量的生产。这个时候,怎么保证产品的质量,每天的产品生产数量,如何平衡效率、花费的资源、不牺牲质量都是每个硬件创业者费尽心思都要去思考的问题。

那么,作为软件社区有一些什么可以借鉴的呢?

这是仔细观察过这么多的学习软件的人和组织后一些对比思考:从统计学意义上来看,就是随着用户们从学习软件往找工作赚钱方面迁移,这个过程的每个阶段用户数量的多少。从个体独立的角度看,就是一个用户能够把多数的软件功能变成自己的工具,可以生成自己的创作并获得(精神或者物质的)收益。从社区整体来看“量产”可能指的是,每段时期有多少用户可以独立的产生作品,以及从社区内极个别的用户学习生成教程,到一定量的用户可以生成教程并且这个过程能够以链式增殖的模式进行下去。

学习Blender并不是一个容易的事情,开发一款每天都有功能更新的软件也不是一件轻松的事。个人用户进入量产状态,比起社区进入量产状态,是两种等级的难易度。

因为这个话题在搜索引擎里没有找到,我们只能逐步来构建起一些概念。

在这里,我们首先要考虑我们的最终美术产品(特别指数字美术)是需要通过各种软件配合,靠我们的智力生产出来的产品。这个跟软件产生的过程形式差不多,开发者用代码指令调用各种硬件功能,美术工作者用美术知识调用各种软件功能。

这里观众就要讲了,你刚才才把美术生产和硬件生产做了类比,现在又把美术生产和软件生产来进行类比,你把两套概念混合在了一起,这让我们如何适从。实在不好意思,因为数字艺术就是建立在硬件更新和软件功能更新的基础上的,有了基础平台的效率和功能,我们才得以在这之上高屋建瓴,创造自己的艺术形式,只能这样去类比构筑概念,才好让我们的Blender用户又有了一些大局观。

现在让我们来看看软件的产生模式,首先我们来熟悉一下现在普通的流程:软件一般都会有开发,测试,上线。这种基本的过程。对应的就是开发环境,测试环境,生产环境。各种环境可以对应的就是一系列软硬件资源,和对应的操作规范。

对应到Blender用户这里。我们将电脑分为学习机和工作机两种类型或者说是工作机和测试机。类似软件生产中的测试环境和生产环境。

这是一个工作站还未拆箱

学习机:试错用,可能为自行配置机器或者低价电脑等。

工作机:稳定做项目用,生成自己的数字美术最终产品,可能是有质量保证的一些硬件和软件。

两者的操作上也会有一些不同。工作用电脑上,很多操作可能需要自己克制下,比如插入U盘就右键乱点什么的,最后直接导致格式化盘这样的事情就不能做,这个需要随时警醒自己,因为永远不知道自己什么适合会犯迷糊,如果能从操作上隔离这些风险,那是再好不过的(因为这种悲剧在社区里看到的太多了)。

创作者工作站拆箱以后就这样了

以上这种措施,这是需要用户自己根据自己的资源和工作能力来决定的,也许你会说,我一辈子都学习,我在破旧的几十年前的电脑上也能制作作品。那,那我们就无话可说,沉默以对了。从经济理论来说,试错有时间成本,获取收益的时候有机会成本。当然你也可以为了缩短试错的时间成本,构建一个比其他人的工作机都好的机器,快速的试错,最终获得所有技能。其实大家根据这种模式,构筑适合自己的一些平台和规范,因为大部分的Blender用户都是soho,有句话叫“凡事预则立,不预则废”,前面的很多话题都是社区用户经常碰到的,如果能有个事先的思考,能给大家带来一些基本的判断,就非常好了,祝愿所有人都可以很快的学会Blender,快快出师。

刚刚讲了普通的软件产生流程,那么按照常理,一定会有不普通的流程。下面,就是介绍Blender为什么开发迅速,为什么发布可以每日都出新功能。可能Blender用户看完这个就一个大致了解了。

比如最近的devops流程:

DevOps(Development 和 Operations 的组合词)是一种重视“软件开发人员(Dev)”和“IT 运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。更详细的介绍可以大家搜资料。网上说这个的很多。

对应到Blender上,我们来谈谈广义上的devops,是这样的:收集用户需求,软件开发们开发出软件,用户使用,反馈意见上报bug/又收集需求,开发修改,继续发布,继续反馈。如此往复。这就是一个devops循环。

Blender基金会有自己的组织架构和形式去应对这样一个循环,配备有一组开发者(对应于开发基金),一个自己的美术组(对应于Blender研究所),开发/使用/回馈,大的功能进展和反馈都能在一个组织内完成,再加上全球一千万左右的用户,随时可以互相了解用的新版本是软件上有缺陷还是自己操作上的问题。软件缺陷就上报,然后官方雇佣的三十多位开发和非官方的一千位开发人员对自己熟悉的领域进行修复和新功能增加。正是因为有其他软件实践的成功,以及Blender本身的开发流程二十多年的打磨,保证了这样的开发运维的循环得以持续进行。使用Blender的很多用户也尝试到了这种软件模式的快感:头一天才在群里看到别人发的一个炫酷的功能,第二天就可以得到新版的Blender开始自己使用和应用到自己的创意当中;早上发现了一个界面或者使用上的瑕疵,跟其他用户核对以后确认是软件的问题,直接提交到官方问题汇总站,下午就得到答复“你的问题已经修复,请下载新版验证”! 这整个过程,我们可以看作Blender整个社区的良好运作,产生了类似于硬件上量产的效果—每个新功能,只需要非常快速的时间就部署到了各位用户的电脑上,这是多少软件制作人员梦寐以求费尽几多资金和心血也想达成的一个标杆性事件,在Blender社区里就这样成了。这种效率机制在其他同类型的软件中是不存在的,想想一年一个版本三个补丁,遇到问题的正版用户需要等齐一个时间点可能就是三五个月才完成补丁升级,谈好的业务刚好需要没有问题的这个功能,时间蹉跎。

效率,是的刚才我们又一次的提起了效率,上次尬聊我们也是交流了一下这个话题

这些是建立在在技术层次都达到一定基准,质量和速度都平衡的基础上的。以上,我们的内容只是作为一个参考,具体怎么去配置自己的创作平台和是否加入到快节奏的软件变革,都是可以自己选择定制的。个人角度的量产,大规模组织角度的量产的平衡与抉择,都是值得我们Blender用户以及社区去不断试错总结。