登峰造极者，殊途亦同归。

在使用PDG的时候，对于一个新的节点，总有一种云里雾里的感觉，看官方文档也是迷迷糊糊的，还好基本上每个节点都有提供相应的Sample，并标注了注意事项。 本篇就记录下PDG的一些重要节点，以及使用过程中的注意点 节点 Wedge 主要有以下几个作用 创建Work Item，驱动PDG 用于生成Attribute（可以多个），对于Wedge的Attribute，可以在整个TOP中通过@xxx来引用，当然，在和常规字符混排的的时候，需要加反向单引号例如： 1$HIP/geo/boxsphere_`@wedgeindex`.bgeo.sc 强制覆写某个参数，可以理解为非侵入式的一种数据注入方案 多个Wedege之前关系为嵌套关系，比如WedgeA的WedgeCount为2，WedgeB的WedgeCount为3，当B连接到A的出口，那么B将会输出2x3 = 6个WorkItem Partition by Index 它做的事情非常简单，就是将多个WorkItem按照index和一定的规则merge成一个WorkItem，每个WorkItem的index可以通过双击查看 ...

本篇文章是对ProjectS中地形PCG模块的总结，可能需要一些前置知识，可以前往本文的 参考 部分进行相关引用 先明确下项目需求 20km x 20km的世界大小 大多数地貌为起伏幅度较小的平原 需要分tile编辑，预览 需要导出LOD高度图 支持植被和物件Instance的纹理生成和手工修改 需要一个工具统筹管理整个PCG管线，并实时查看每一步的结果 最终选择Houdini作为目标软件，因为Houdini作为一款相当成熟的PCG向的DCC软件，提供了相当多地形创建，编辑和工作流工具，应对我这个个人项目的简单地形PCG工作自然不成问题 项目概览 项目结构如下： terrian_pdg：地形PDG模块，组织整个地形的PCG流程 terrian_sop：地形PCG中用到的所有SOP集合，大部分都导出成了HDA，供PDG使用 PDG流程 我在学习和解构一个对象的时候习惯从宏观看起，大概掌握每个环节的功能，有个全局的概念，再看具体细节的时候不会有一头雾水的感觉，所以我们从PDG开始看起 整个流程非常的直观 创建地形骨架 拆分地形 根据地形编号查找hda文件，如果存在则进行 ...

Houdini中HeightField相关节点在地形生成中占据了非常重要的地位，虽然可以在Houdini里右键节点-Helper查看详细的官方文档，但未对整个HeightField系统有一个宏观认识的情况下，也不知道要用哪些节点。所以单独开篇文章来记录常用的HeightField几点以及使用心得 （但HeightField手册又何必只是HeightField手册^ ^ _） 基础高度场操作 HeightField 基础的高度场节点，用于指定高度场的大小，细分/模拟粒度等基础信息 这个节点用于生成两个 2D volume 基元：height体积和mask体积，具有给定的分辨率和初始值，这些基元可以由其他地形节点进行修改。 height体积 是一个 2D 网格，表示地图上每个点的地形距离地面平面的距离（这些值可以为负）。 mask体积 可以用作其他地形工具的“mask”输入。它指定了地形节点的效果应该应用于哪些区域：mask值为 0 的区域不受节点影响，掩模值为 1 的区域完全受节点影响。地形节点允许你绘制mask或从地形信息中生成mask（例如，阴影落在哪里，或低于某 ...

地形系统思路来自 ProjectS中的GPU Driven 架构 首先明确ProjectS的世界大小，目前暂定整个世界面积为 20.48km * 20.48km ，实际上可以再大很多，但考虑到资源量级以及对于世界内容的填充需要颇费心思，暂定这么大了 既然地形分了LOD，那么纹理自然也要根据LOD进行区分 LOD0的Node对应的纹理信息（高度纹理，Material Id纹理等）分辨率为128*128，覆盖区域为64m*64m即一个纹素对应0.5m，已经很可以了，再高点画质就要比原神好了 LOD1的Node纹理分辨率为128*128，但覆盖区域为128m*128m LOD2的Node纹理分辨率为128*128，覆盖区域为256m*256m LOD3的Node纹理分辨率为128*128，覆盖区域为512m*512m LOD4的Node纹理分辨率为128*128，覆盖区域为1024m*1024m LOD5的Node纹理分辨率为128*128，覆盖区域为2048m*2048m 这也就意味着我们需要对整个世界做六种不同覆盖区域的纹理，可以理解为Mipmap，不同的LOD Node采样不 ...

还是最喜欢这个拜念三归，地狱的压迫感拉满！ 最近玩了暗黑破坏神4，感触颇多 技能Build 技能Build其实没什么好说的，依旧是基础技能+符文系统完善Build，但相较于恐怖黎明的星座，流放之路的技能树+升华，暗黑4的理解成本和玩家友好程度更加出色。它的巅峰系统居然是可以旋转的。。。，这意味着玩家可以不用太过拘泥于设计好的巅峰树，而是能最大限度地按照自己的意愿去体验整个系统 之前在内测时体验过所有角色，感觉到暗黑4是想让玩家尽可能的把手参与到战斗中，而不是进个图，几个buff一加，技能一开，直接跑跑跑完事，虽然说增加了一些上手难度，但确实是能让玩家更用心的去体验战斗的刺激。很合我胃口，毕竟我玩剑圣的，哈哈（顺带吐槽，狗曰的一如既往对平A近战不友好，各种暴毙 玩了这么多暗黑Like作品，技能流派来来回回就那么回事，什么双持+AOE剑圣，大风车，召唤平推流，万剑齐发。。。其实这类游戏发展到这种地步，Build上很难再做出让人眼前一亮的设计了，就像LOL最近新出的英雄，就是基于各种技能元素，缝来缝去，然后得到一个全新风格的英雄，不是说不好，反而是相当健康的一种发展模式，能让玩家在低 ...

本文是对https://www.gdcvault.com/play/1025480/Terrain-Rendering-in-Far-Cry 进行的中文翻译，翻译动机是PPT涵括了ProjectS的GPU Driven系统所有功能模块，需要学习下工业流程 大纲 地形渲染：渲染地形，将部分转移到GPU管线中 基础知识 GPU管线 着色：对上一步渲染的地形进行着色 悬崖着色：针对悬崖做的着色方案和优化 高级地形：将基础地形和其他几何结合 屏幕空间着色：在一个屏幕空间的Pass对地形进行着色 基于地形的特效：使用GPU上的地形数据来增强对其他资产的渲染，如树木、草和岩石 地形渲染 地形渲染基础 流程概述 一个简单且GPU友好的方式来渲染一个小区域的地形步骤如下： 首先渲染一个Mesh，作为地形的最小单位。 在VS中采样高度图，来改变顶点位置 使用一张albedo贴图在PS中进行着色，作为地形基础色 计算光照时再用一张normal贴图 使用四叉树来划分地形区域，整个世界构成item粒度从小到大依次为（LOD0）： Patch（Tile）：单个Grid，原分辨率1 ...

架构 前阵子敲定了ProjectS GI方案的大体架构，但只对着那几个Cube可看不出落地效果，也没法做针对性的优化，所以准备启动地形相关的开发工作 立项之时就考虑到美术成本问题，所以采用程序化生成作为构建ProjectS世界的主要手段，程序化生成意味着大量重复instance和大地形，这时候就得利用GPU Driven来作为整个PCG系统的底层支柱之一了，我们常说的GPU Driven包括以下几个方面 地形渲染 制作 Houdini 生成高度图+Mask VS 直接生成Mesh Houdini生成高度图+Mask方案对于Houdini来说更加轻量，不需要处理地形Mesh 直接生成最终Mesh可以离线对Mesh做处理，包括岩壁重展UV，LOD计算等 但对于ProjectS来说，没有太特殊的需求对Mesh做处理，一些岩壁拉伸问题也可以通过处理贴图渲染进行解决，最终选用高度图方案 渲染 DrawInstanceIndirectly通用Quad Mesh + LOD + 高度图采样 实现地形渲染 VS Mesh Cluster Rendering + LOD 实现地形渲 ...

我做了一个梦 我是一位书生 梦里似有一壶酒，不见其形，却感受得到它的悠然与清香 听人说，这酒产自故乡，但如今远在异乡 这股清香，一直陪伴着我，在疲惫不堪的时候，我把它当成一种抚慰 后来，我对它愈加喜欢了，我付出的越来越多，用尽全力去了解它，只想永远拥有它 但，酒这事物，越沉醉，越伤身 它总是懒得回应我，无论我再怎么苦苦哀求，它只愿意给我它的清香 哪怕一滴一毫的壶中酒都不愿予我 但，我对它依赖的太深了，我想要更多 它说，让我看看你的模样 我便决定踏遍天涯去找寻它的踪迹 找寻它的路上，太阳是暖的，风是甜的，就连凌晨的星空也是美的 见到它的那刻，我顿住了，它是凛冽的，热辣的，但也有那熟悉的清香 这样的它，让我沉醉 我陪它走了很久很久，我们都很开心，像是久别重逢的新人 它就在我身边，这让我感到从未有过的安心 趁着满天星辰，我问它，能否给我更多 恍惚间，我看它稳了稳身形，酒盖似也紧了些，我心中悲然，这应是它的回答 翌日，我早早来到约定的地点 这里有春天的微风，慵懒的暖阳，翠绿的湖水，簌簌作响的树叶 我们依旧走在路上，但除了熟悉的清香，那疏离的感觉，把我一步步的推往绝望 我陪它走了很久很久，走 ...

前言 前阵子在处理ProjectS中的AI行为时，发现怪物AI规划出的行为很容易造成怪物重叠，这归根到底是个动态避障问题，而当前游戏AI有以下几种常见动态避障算法： VO : 提出速度域的概念，Velocity Obstacle 就是VO的由来。通过相对位置，并从自身出发考虑一个安全的移动方向，即避开VO区域（速度危险区）。但在移动过程中会出现抖动。原因就是反复计算安全区，当第一次避开危险区到达安全区之后，发现最佳移动方向（不一定安全，一般指朝向目标点方向）可能不再危险，就将移动方向转回来，结果发现其他寻路对象也这么考虑，也将移动方向转回来，所以第三次就又将方向转向其他方向。由此引发了移动时的方向抖动 RVO: 在VO的基础上，每次转动方向时，只转动计算出来的变化量的一半。从数学计算角度去减少出错（抖动）概率 RVO2/ORCA: VO与RVO都是在空间计算上来规划一个安全区域，而RVO2则是将其转化成了一个线性规划的问题（即用一个个平面将自己与需要考虑的对象的安全区域分割开来再采取一个共面区域，这个区域就是安全区） 对于这三种算法的详细解析，可参见：GameAIPro3_Ch ...

本文是对GameAIPro2_Chapter18_Context_Steering_Behavior-Driven_Steering_at_the_Macro_Scale 进行的中文翻译 译文 介绍 在游戏行业中，转向行为（Steering Behaviour）是非常普遍的。他们之所以这么流行，是因为其只需要使用简单组件就可以快速实现核心功能。 然而，转向行为并不适合用于某些类型的游戏。当玩家能够挑选并监控单个实体时，避免碰撞和自然的移动就变得非常重要。为了实现这一目标可能会导致行为组件的膨胀并变得紧耦合，实体运动逻辑也会变得脆弱和难以维护。 在本章中，我们将概述如何识别那些转向行为不太适合的游戏，并提出一种针对这些问题的新方法，它被称之为上下文转向行为（Context Steering）。上下文转向行为（Context Steering Monobehaviours）是小巧的和无状态的（StateLess），并提供任何行为本身所期望的运动约束。当上下文转向行为用于取代游戏F1 2011上的原转向行为时，代码库减少了4000行，但AI在避免碰撞、超车和执行其他有趣的行为方面表现得 ...