虚拟环境中程序式生成建筑的建模逻辑应当在一定程度上参考现实世界中建筑的建构逻辑。虚拟环境的建模固然比现实世界轻松很多。一堵混凝土墙,虚拟环境中建一个低模分UV然后程序式生成贴图就可以了,现实世界中还要支模打钢筋灌浆。比如建造一座雅典城,可能需要几万人几十年的时间,而刺客系列可以一千人两年铺完。诚然如此,对提高建模效率的追求永无止境。这自然也需要参考现实世界的建构逻辑。

现实世界中为了减少建造成本,加快建造速度,一定会探讨快速的建造方法。装配式建筑就是这个背景下产生的。历史上大概早有这个概念,但是现代建筑史中最著名的大概就是魏森霍夫住宅(Weissenhof Estate)了,魏玛德国时期现代主义大师密斯凡德罗主持的一个建筑展,大量使用了装配式的方式建造住宅。二战后欧洲的重建中,住宅建筑大量采用了这种方式降低成本。苏联自然也是如此,这也在60年代传到中国,那个时期大量的工人宿舍住宅都采用了这种方式。

然而涉及到虚拟环境,它又会有自己独特的问题,如何优化渲染效率?如何平衡灵活性与高效性?如何布置建筑?下面就是几个不可避免的问题。

最近也在研究这个事情,挑了宏村水镇的房子作为研究,目前只生成了几种规则的房子,探讨了一下贴图规划。

untitled1.jpg

array.png

components.PNG

BaseColor.png

nodes.PNG

以下是制作过程中的思考,很多还没有成熟解决方案,只是列出一点自己的感受。

Prefab Scale 预制体的尺度?

这是一个涉及灵活性与高效性的问题。预制体的尺度太小,就必须要大量的逻辑代码控制预制体的分布,而且这些代码可能还是无法重用的,仅能实现一种类型的建筑。

比如赋值际村,基本没有UV的概念,没有预制的概念。全部程序式生成,这个就比较难以灵活应用在不同建筑上了。

我也做过一个类似的效果,之前在雷火做的实验,软件使用的CityEngine中。

比如Procedural House这个例子

Lineup-1024x576.jpg

比如Procedural Lake Village这个例子。预制体小到一个窗框,一个屋顶的瓦,一个屋脊的装饰。这样预制体的灵活性很高,可以随意设计。但是组装系统的灵活性很差,很难改变成为另一个类型的房子。

maxresdefault.jpg

装配式建筑中也会有这样的考虑,首先很多建筑构件必然是工厂制造现场组装的,比如管道/窗户/砖等。这些构件过小,如果它们也算是装配式建筑的话,那就没有非装配式建筑了。一般住宅的装配组件可能会使一面墙,一块楼板,甚至一个整体的卫生间。

ACUnity这套就更像建筑工业制品,Artist建模了Module,在引擎中拼装。Module有墙,屋顶,烟囱,地下室等等。有意思的是工业革命时期的英国的房子肯定不是装配式建造的,但虚拟环境中可以简化成装配式建造的。

Procedural Environment for Unity with Houdini这个例子也是比较好的,房子都是方块比较简单,也就比较容易用组件去拼。

image2-10.jpg

也可能会更大尺度的预制体,比如房间尺度,这样也就只需要考虑房间的布置/连接/分布了,比如笔者之前做的这个实验,外形基地和太空站的建造逻辑应该都是房间尺度的组件拼装的,这就可以使用L-System。

Texture Planning 贴图规划?

预制组件必然要考虑贴图共用。考虑到DP优化,甚至很远的房子LOD都可以公用一张atlas贴图。为了防止atlas贴图串色,就必然意味着如果要使用四方连续贴图,必须要切面。没有四方连续的问题,那其实一套房子的贴图都可以放在一张贴图上了。因此反推回来建筑组件建模时,就必须要考虑好贴图规划,这是一个美术制作上很严重的问题。

这也是一个矛盾,开始规划贴图时还没有建模,不知道会有什么东西怎么规划贴图。所以可行的解决方案是 1. 建草模,想好需要什么组件,做好拼装的效果 2. 根据草模预留贴图位置 3. 建高模和LOD0

这样的好处当然就是优化DP了,甚至由于共用了一张贴图,直接在引擎中将模型合并成一个Mesh都可以,也更方便地做HLOD。意味着可能都不需要引擎GPU Driven Pipeline,手游上只要控制LOD让mesh的内存撑得住,都可以用。

Interactive vs Procedural 交互式还是程序式?

一个房子使用哪个的部件是遵从随机数还是可以手动修改?手动修改能否和程序式生成的修改进行融合?

赋值际村这个例子中,所有东西都是程序化生成的,可以手动控制的只是周边环境(上 水 POI),交互程度比较低。基本已经有一个整体的效果了,但是细节上十分欠缺。

个人认为,完全程序式生成是无法达到游戏的要求的,这不是一个技术上的问题。理论上讲可以花费很多时间修改规则,使得程序式生成更贴近目标。但这可能需要的成本太高,不如手动进行一些调整。融合交互式修改会更加具有灵活性。然而交互的到何种程序是需要讨论的。也需要引擎工具链的支持。

建筑的组件是一定需要可以交互式编辑的,但是建筑组件的分布是完全手工?还是程序分布?还是程序先分布再做手动调整?路网的生成,是完全手工?程序分布?还是程序分布完再做手动调整?地块的划分,建筑的布置,地形的生成也是如此。

地形和植被目前来看是完全可以程序生成再手动调整的,路网亦是。这在Ghost Recon Wildland 2这作中基本已经实现了,之后Anvil上的作品猜测都用了类似的技术。

建筑可能稍微麻烦一些,工业界能用的可能还是手动布置居多。比如Anvil在ACUnity中哪个talk.

Isolated vs Stacked vs Courtyard Placement? 孤岛还是紧凑布置?

建筑的组成方式可以有几种。

孤岛式的布置是最容易的,一个地块的中间放置一个房子就行了。Procedural Lake Village, 独栋别墅住宅,市区高楼都是如此。这完全可以程序式生成。房子好办,都是独立的方盒子就行。这种用cityengine的思路完全可以,房子和周边环境的关系较弱,可以独立处理。

堆叠式布置,比如favela贫民窟,比较大的问题是道路的布置,堆叠还有没有路呢?还是完全跑酷?房子还好办,反正都是独立的方盒子。

Procedural Environment for Unity with Houdini这个例子中

庭院式布置,这个最为复杂,首先院子的形状是不规则的,院子间肯定需要道路。房子是布置在院子中的又有很多不规则的形状。比如北京四合院,江南水乡等。赋值际村在道路生成上甚至是先划Lots,在用最短路径找道路的方式,跟cityengine类的先道路再划lot的方式相反。另外源自不规则,每个lot中又定义了复杂的规则划分为小院落建房子。不规则形状实在太多,以至于很难采用预制拼装的方式。

14488219426_4e507c3c34_b.jpg

Regularity 规则性

可以说上面讲到的孤岛和堆叠式的布置最容易,房子模型完全可以模数化,模块化。但是如果地块有不规则,房子基地又要顺应不规则的话就很难了。

转角怎么办?非模数的地方怎么办?

建筑中也会遇到这个问题,构件的精度有差距怎么办?金属门窗精度可以到毫米,但是砖石只能到厘米。二者的接缝处就需要软性材料连接。但是建模用的构件,精度只能到米???但是一面墙的长度可能精度会到厘米。怎么办?拉伸?填可变长的部件?固定转角角度?各有各的处理方法。

Foreground vs Background

像上文讲到到装配式建筑,一般也都是用在比较没有个性的住宅建筑中,前景和地标式的建筑,很少采用装配式的方式,游戏里大概一样吧。