德语文法小记

最近在用Duolingo学习德语，感觉效率有点低，而且截至Section 2了Duo也没有给出任何比较学院派的语法解释。正好最近搞了个一年免费的Gemini Pro，便想着配合网上的资料和AI补充下德语语法，也权当作为验证不用课本是否能够学好语言的一个小实验😎。

说在前面

为了不产生歧义，对所用的标注订一些标准

• 专业名词的翻译英语用圆括号()，德语大括号{}

分类

按照语言形态学(Linguistic typology)的分类，大多数语言可以归为以下的两大类，分析语(Analytic)和综合语(Synthetic)，分析语又可细分为孤立语(Isolating)，而综合语又可细分为屈折语(Fusional/Inflected)、黏着语(Agglutinative)、多式综合语(Polysynthetic)和少式综合语(Oligosynthetic)。

一些典型的例子，汉语和越南语属于孤立语，日语属于黏着语，阿伊努语属于多式综合语，而德语则属于屈折语。

屈折语在Wiki上的定义如下：

1

屈折语（英语：fusional language，或称inflectional language）为综合语（synthetic language）之一种。屈折语和同为综合语的黏着语之间的分别在于屈折语的词素趋向连在一起，较为难以分割，意即屈折语的一个词缀经常同时表达多种意思，而黏着语的一个词缀一般倾向于只表达一种意思。不过黏着语和屈折语之间的界限很多时候并不明显，因此可将黏着语和屈折语之间的关系视为一个连续体，而很多语言则落于“完全的”黏着语和“高度的”屈折语之间。

[2]中定义屈折语通过单词本身的形式变化来表达语法功能，屈折语广泛存在于印欧语系中。

[4]中答主提到了一个很有意思的概括：

• 学黏着语主要是背词缀

• 学屈折语主要是背表格

• 学分析语主要是背字典

读音规律

下面的内容基本来自Gemini总结和[10]，个人也大致验证了下，基本是对的。德语的音标与IPA大体是一致的。

长短元音(Monophthongs)

德语的长短元音不仅时长不同，口型和音标也往往不同。简单来说：**长元音通常发得“紧”且“闭”，短元音通常发得“松”且“开”。**具体的读音强烈建议参考[12]。以下是发长短元音的不同情况。

长元音

• 元音后面没有任何辅音，或者只有一个辅音
• 元音重复（双元音字母，如aa/ee/oo）
• 元音后有无声的 h {Dehnungs-h}
• 特殊组合 ie ieh 在德语中是长音 i 的标志
• 元音后是 ß （相当于ss）前面的元音永远是长元音

短元音

• 后面有两个或更多辅音（闭音节）
• 后面是双写辅音
• 某些特殊辅音组合（如ck/ tz/ sch/ ng）等同于双写辅音

特殊规则

• 虚词例外（看起来像长音，实际发短音），如an/mit/um/im/das/es/was，也有一些例外，比如er/wir/ihr/wen/dem中的元音就发辅音
• 词形变化保持元音长度

读法示意

下面的表格来自[12]：

e的特殊读法

在某些音节中，e的读法会有变化，参考下面的表格：

双元音(Diphthongs)

德语中的双元音一共有4个，分别是ei(ai,ay,ey)/au/eu/äu。[12]中给出的音标如下图所示，其中eu/äu的音标在Netzverb Dictionary中一般标注为[ɔɪ̯]，ai/ay/ey的读音与ei保持一致。

对应的IPA示意图如下：

辅音

与英语存在着一些不同，需要注意看到W读V，看到V读F，看到Z读Ts。V只有在某些外来词中才会都V，如Vase。

词尾清化 Auslautverhärtung

浊辅音（包含爆破音(plosives)、擦音(fricatives)和塞擦音(affricates)）在句尾时需要清化，[14]中给出的音标例子如下：

• 爆破音：b$\rarr$p，d$\rarr$t，g$\rarr$k
• 擦音：z$\rarr$s，v$\rarr$f

特殊辅音组合

德语中的特殊辅音组合很多，比如tsch/sch/sp/st/ch。

• tsch和读音就像英语中chair中的ch

• sch的音标始终为[ʃ]

• 当且仅当位于音节开头时sp/st读[ʃp] / [ʃt]

• ch有三种读音

  • 一般情况下，发硬腭清擦音[ç]，比如在单词Ich和Chemie中。舌头和摆放位置如下：

    1	Its place of articulation is palatal, which means it is articulated with the middle or back part of the tongue raised to the hard palate.

    另可以参照Wikipedia上的示意图来发音：

    

  • 在元音a/o/u/au后面变为软腭清擦音[x]，示例单词为Bauch/Rauch/Buch/Hoch

  • 在后面跟s变成chs以及在某些外来词的开头时变为[k]，示例单词为Sechs/Chaos

还有一些别的辅音组合未在[10]中列出，罗列如下：

• qu发[kv]，如Qualität
• kn/gn/ps中的n也要发音
• ig在词尾时的音标变为[iç]，如König

特殊词缀ion

德语中的某些词汇会以ion结尾，读音听起来就像英语中的eon，IPA音标为[i̯oːn]，示例单词为Addition/Aggression/Definition。

词法特征

德语作为屈折语最大的特征便是变格(Declension){Deklination}，[1]中定义变格在语言学上是指名词、代词、冠词、形容词在句子中为了实现特定的语法功能而产生的词形变化。动词的这种屈折变化一般被称作变位。...词通过变格能够反映自身的性（阴性、阳性、中性等）、数（单数、双数、复数等）、格（主格、宾格、与格、从格、属格、处格等）及其他语法范畴上的归属。注意这里的变格是一个大的概念，包含了德语中的格(Case){Kasus}，不要混淆了。

按照[4]中的说法，要开始背表格了，即名词、代词、冠词和形容词的性、数、格所对应的表格。

性、数、格这三个东西本质上只能是归属于名词的，其他的代词、冠词和形容词是是遵从语言学的一致（或称对协）(Agreement){Kongruenz}原则而发生变化的，[5]中给出了常见的一致性语法关系：

• 动词与形容词与主语一致：性、数、身

• 名词与修饰语一致：性、数、格

• 名词与指代它的代词：性、数

所以说核心在于掌握名词的性、数、格，以及对应代词、冠词和形容词的变格表格以及谓语动词的变位表格。

性

德语中的无论是表示人还是物的名词都可以分为阳性{maskulin}、阴性{feminin}和中性{neutral}三种，词性的变化会遵从一致性原则体现在修饰名词的冠词和形容词上。阳性对应der，阴性对应die，而中性对应das，这三者又会随着数和格发生响应的变化，如下表所示（要开始背表格了）：

所以说在记忆名词时必须要记住它的性，这方面也不能想当然，比如[6]中提到了一个例子，太阳Sonne是阴性的{die Sonne}，而月亮Mond则是阳性的{der Mond}，如果从中文的语境中出发应该大概率会搞错。[6]的作者给出了一个猜测：温习北欧神话时才猛然意识到，对于古日耳曼人来说，掌管太阳的是女神Sól / Sunna，而掌管月亮的则是男神Mani，这样若是将这个词性视为远古日耳曼神话的吉光片羽就说得通了。

当然词性的规律并非完全无迹可寻，有很多资料都有总结能够应对大部分单词词性的诀窍，这里大致记录下[9]中提到的方法。

名词的性规律

有两种分类方式可以大致判断名词的性，一是按照名词的主题(Noun Groups)分类，而是按照名词的拼写(Forms)分类。

按主题

以下只是大致的分类，每一类中都有特例，具体请参考[9]。

说实话感觉这个规律并没有很普遍🤣。

阳性

• 部分Animals

• Cars

• Currency

• Days, Months, and Seasons

• Directions

• Drinks: Alcoholic and Plant-based

• Male Persons

• Mountains and Mountain Ranges

• Non-German Rivers

• Outer Space

• Rocks and Minerals

• Weather

阴性

• Airplane, motorcycle, ship makes/models/names
• 部分Animals
• Female Persons
• Numeral used as nouns
• Rivers within Germany, Austria, Switzerland
• Trees, Fruits, and Flowers

中性

• Alphabet letters and music notes
• Continents, cities, provinces, and most countries
• Gerunds（-ing动名词）, colors, languages, English -ing forms and other parts of speech used as nouns
• Hotels, cafes, restaurants, and movie theaters
• Metals and chemical elements
• Scientific units
• Young persons and baby animals

按拼写

按主题分类的体系中有很多的例外，很多都可以用按拼写分类的方式的解释，相当于这条规则的优先级会高不少。这里的按拼写一般情况下指的是根据后缀来判断。如果某个词是缩写形式的话需要从原型出发判断。

阳性

• -ant/-ast/-ich/-ig/-ling/-or/-us
• nouns formed from strong verbs
• ~60% of nouns ending in -en/-el/-er

阴性

• -a/-anz/-enz/-ei/-ie/-heit/-keit/-ik/-sion/-tion/-sis/-tät/-ung/-ur/schaft
• -in or -frau denoting the female counterpart to a male person
• 90% of nouns ending in -e
• most nouns (coming from verbs) ending in -t

中性

• -chen/-lein/-icht/-il/-it/-ma/-ment/-tel/-tum/-um
• most nouns that start with the prefix Ge-
• ~70% of nouns ending with -nis and -sal
• -al/-an/-ar/-är/-at/-ent/-ett/-ier/-iv-/-o/-on (foreign loan words for objects)

复合词

一般情况下，复合词的性是由最后的词决定的，比如der Fahrplan

数

关于复数形式的变化规律总结，请参考[15]和[16]。

格

参考资料为[1]。

为了表明一个名词与居中其他词类的关系，会用名词的「格」形式来表达。德语中共有四种格，分别是主格{Nominativ}，受格{Akkusativ}、与格{Dativ}和属格{Genitiv}。一般来说名词和名词前的修饰词会发生一些小变化，用来指示名词属于哪种格。

主格

主格代表句子的主语，通常搭配疑问词Wer或Was使用，如Ich gebe dir ein Buch。

跟在系动词{sein/werden/bleiden}后的名词也是主格，如Das ist ein schönes Buch。

受格

受格又称直接受格，是句子中的直接受词，也就是动作直接发生的对象，通常搭配疑问词Wen或Was（对谁或发生了什么事情），如Ich gebe dir ein Buch中的ein Buch。注意与与格区分开。

与格

与格用于句子中的间接受词，即间接接受东西或动作的人、事物，搭配疑问词Wem oder Was（这是为了谁或为谁做的），如Ich gebe dir ein Buch中的dir。某些动词永远搭配与格，如danken/glauben/helfen/gehören/gefallen。

有些特定的介词也会搭配与格，如auβer/bei/mit/nach。

属格

表明某物或某人属于谁，即占有或所有权，搭配疑问词Wessen（这是谁的），如Das ist das Buch eines Lehrers。属格通常用于书面语，口语中通常使用介词von+与格来代替。

代词

[7]中提到，日耳曼语中的代词可以被划分为以下几个大类：

• 人称代词(Personal pronouns)，如英语中的me/he/she
• 物主代词(Possessive pronouns)，如英语中的my/your/his/her/its
• 指示代词(Demonstrative pronouns)，如英语中的this/that/such
• 反身代词(Reflexive pronouns)，如英语中的myself/himself/herself
• 关系代词(Relative pronouns)，如英语中的which/who/whose/whom
• 疑问代词(Interrogative pronouns)，如英语中的who/what/why/how
• 不定代词(Indefinite pronouns)，如英语中的someone/something/nothing

每一类代词都会随着性数格发生变化，所以说又多了几张要背的表格。

语法特征 WIP

这部分比较复杂，之后再做补充，先根据[17]和[18]简单总结下。

语态 Voices

德语中也有主动和被动语态。

语气 Moods

德语共有三种语气，分别是直陈式{Indikativ}、虚拟式{Konjunktiv}和命令式{Imperativ}。

时态 Tenses {das Tempus}

首先回忆下英语的若干个时态，由Gemini总结：

而德语中不存在进行时，剩下的就只有6个时态，分别是

• 现在时 {Präsens}：表现在发生的时态，也能表示将来确定的事情，甚至也包含过去开始但目前未结束的事情
• 现在完成时 {Perfekt}：实际为德语的过去时，是口语中表示过去事件的主力军
• 过去时 {Präteritum}：多用于书面或特定文法
• 过去完成时 {Plusquamperfekt}：表示比过去某时间点更早的动作时间
• 未来一式 {Futur I}：对应英语的未来时但主要强调不确定性
• 未来二式 {Futur II}：对应英语的未来完成时，相较于Futur I，强调未来极可能完成的动作

[17]给出了非常好的总结图：

关于Perfekt和Präteritum

这两个时态基本可以看作是可互换的，只要是过去发生且截至当前已经结束的事情都可以表示。在口语中基本会使用Perfekt，但有一些特例，[19]的原话是：

1

There is a single concept of the past (die Vergangenheit) and the Präteritum and Perfekt tenses are interchangeable in expressing it. In practice, Germans use the Perfekt for about 90% of speech; they only use the Präteritum in speech for the auxiliary and modal verbs and a few very common strong or mixed verbs.

剩下的10%特例就是助动词、情态动词和某些词汇了，由Gemini举例如下

• 助动词sein/haben等等，例如
  • Ich war zu Hause✅
  • Ich bin zu Hause gewesen❌
• 由于情态动词的完成时结构很复杂，所以口语几乎清一色过去时，例如
  • Ich musste arbeiten✅
  • Ich habe arbeiten müssen❌
• 极少数常用的动词用过去时更顺口，如wissen/denken/geben，这点存在地区差异
  • Das wusste ich nicht 比 habe gewust常用的多

语法杂记

• 区分nicht与kein

  • nicht用于否定动词、形容词和副词，同时当名词前是由定冠词der/die/das修饰时也要用nicht
  • kein用于替换不定冠词ein来表示某个物体没有了

• 德语中的表语

  • 当形容词跟在系动词{sein/werden/bleiben}后面做表语时，直接保持原样，无需做任何变化
  • 系动词跟英语基本一致，除了上面的三个，还有一堆感官系动词
  • 比如，Die Lampe ist neu/Der Kaffee schmeckt bitter

• 德语情态动词后的动词跟英语一样也是保持原型，如

  • Möchtest du einen Nachtisch bestellen?

一些思考

• 德语好的一点是掌握了元辅音的读音和少数几个音变规律后，单词基本就会念了，不像是英语，乱七八糟的变音，不查音标根本读不对。至于英语的拼读规则为什么会那么随机，问了下AI，大致原因有四个：

  • 拼写深度不同： 德语是“所见即所得”的浅层拼写，字母与发音高度对应；而英语拼写与发音严重脱节，充满了特例。

  • 外来词影响不同： 英语直接保留了大量法语和拉丁语的原始拼写，导致规则混乱；而德语即便引入外来词，也往往会将其规范化。

  • 历史演变不同： 英语经历了“元音大推移”，发音变了但拼写却因印刷术定型而没变，造成了“文不对音”的历史错位。

  • 人为干预不同： 德语国家会定期进行官方正字法改革来修正拼写以适应发音，而英语从未有过统一改革，全靠约定俗成。

• 注意音标ʏ和yː的读音，舌位靠前而非靠后

• 德语发音的一大特点是，所有字母都要发音

• 关于ch前元音是长音还是短音，Reddit网友的回答是没有规律，见[13]

• 确定读音请使用Wikitionary或Duden

• 助动词和系动词的区别：系动词有实义，而助动词没有独立含义，只是为了帮助另一个实义动词完成语法任务。德语中的sein/werden既可以充当系动词也可以充当助动词

参考资料

1. 【德語文法】德文四格(Nominativ, Akkusativ, Dativ, Genitiv)用法整理
2. 常见的语言类型：黏着语、孤立语、屈折语、多式综合语
3. Wiki for Linguistic typology
4. 黏着语、屈折语、分析语的区别是什么？
5. 一致 (语法)
6. 性数格
7. German pronouns
8. Understanding German Pronouns: A Comprehensive Guide
9. German Noun Gender
10. German Diphthongs
11. IPA/Standard German
12. German Vowels Sheet for Native-like Pronunciation
13. Long or short vowel before ? (IPA transcription)
14. Auslautverhärtung
15. German Plurals
16. German Plural Nouns
17. ［德語文法］［初階德語］德語動詞變位：六種時態與三種語氣
18. Summary of German verb tenses, voices, & moods
19. Perfect vs. Preterite

TAA实现小结

项目地址

前言

刚把LearnOpenGL的渲染部分学完，IBL的效果是真不错，但是锯齿挺明显的：

又因为跑的是defer管线，很难上MSAA，想着加一套抗锯齿进去，查了些资料后还是选择了TAA而非FXAA和SMAA等后处理抗锯齿。TAA有很多优点，比如不会随着运动而抖动，同时能够为画面中几乎所有的部分完成抗锯齿，生来就与Defer兼容等等。加入TAA后的效果如下：

锯齿肉眼可见地基本消失了。

实现思路

TAA作为经典算法已经有很多教程了，GDC和Siggraph Course上各大厂商也给出了很完善的解决方案，如果要从头学习的话，建议是先看知乎上的介绍[4]，然后是[1]和[5]这两篇很好的教程，另外[1]、[4]和[5]中提到的的很多技巧基本都是在[2]和[3]中提出来的。

TAA的流程大致可分为三个部分，分别是Jitter、Motion Vector和Resolve。

Jitter

Jitter便是TAA的核心思路。首先回想下最原始的抗锯齿即SSAA的原理：在像素内额外进行多次采样并取平均颜色。TAA本质上是做了同样的事情，不过将所有的采样分摊到了多个连续帧中去做。Jitter便是生成这些采样点的过程，TAA会用一个随机的采样点序列来表示亚像素级的偏移，每帧使用不同的偏移，并在帧间进行累积。

一般来说不会使用一个全随机的Jitter Sequence而是会用低差异度序列来代替，基本上大家都用的是Halton序列。由于Jitter是个二维的向量，在生成Jitter时$x$分量的基数为2而$y$分量的基数为3。项目中使用的Halton序列生成器如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

// https://observablehq.com/@jrus/halton
function halton(index: number, base: number): number {
    let fraction = 1;
    let result = 0;
    while (index > 0) {
        fraction /= base;
        result += fraction * (index % base);
        index = Math.floor(index / base); // floor division
    }
    return result;
}

export function* generateHaltonSequence1D(base: number): Generator<number> {
    let index = 1;
    while (true) {
        yield halton(index, base);
        index++;
    }
}

export function* generateHaltonSequence2D(base1: number = 2, base2: number = 3): Generator<[number, number]> {
    let index = 1;
    while (true) {
        yield [halton(index, base1), halton(index, base2)];
        index++;
    }
}

export function HaltonSequence2D(count: number, base1: number = 2, base2: number = 3): [number, number][] {
    const gen = generateHaltonSequence2D(base1, base2);
    const result: [number, number][] = [];
    for (let i = 0; i < count; i++) {
        result.push(gen.next().value);
    }
    return result;
}

对于如何应用Jitter，有两种可选的方式，一种是直接修改投影矩阵的第三行，另一种则是修改Vertex Shader输出的Clip Space Position。第一种方法的好处在于不用修改原有的Shader逻辑，但是在计算Motion Vector时需要抵消Jitter的影响。为了逻辑的清晰，本文选择了第二种方法，伪代码[6]如下：

1
2
3
4
5
6

float4 worldPos  = modelMatrix * float4(in.position, 1.0);
float4 clipPos = viewportParams.viewProjectionMatrix * worldPos;
    
clipPos += viewportParams.jitter*clipPos.w; // Apply Jittering

out.position = clipPos;

这里还要额外做一些说明，Jitter其实只是通过扰动NDC坐标而对光栅化产生了影响，但光栅化又与插值相关联，因此到最后下面所有的这些输出都会受到影响，进而达到了边缘抗锯齿的效果：

1
2
3
4
5
6

out highp vec2 fragTexCoord;
out highp vec3 fragNormal;
out highp vec4 fragTangent;
out highp vec3 fragPos;
out highp vec4 fragPosClip;
out highp vec4 fragPrevPosClip;

做完这一部分后，如果进行可视化，可以看到画面是抖动的：

Motion Vector

在将当前帧的画面与历史颜色进行混合之前，我们还要去计算屏幕空间内的Motion Vector。在一个动态的场景中，运动可能来自于以下的几个方面：

• 相机的运动
• 物体的TRS运动
• Skinned Mesh的变化
• 顶点动画
• UV动画

前面四个的基本解决思路就是，保存历史的变换，比如对于第二种就是Previous Model Matrix，在当前帧中同时算出当前屏幕uv和历史屏幕uv，并将uv的插值累加到Motion Vector中。既然有了Jitter Offset，这一步就很好做了，直接在Vertex Shader中输出未Jitter且考虑了四种运动的Clip Space Position以及Previous Clip Space Position，在Fragment Shader中做差值即可。项目中为了方便只实现了考虑相机运动的Motion Vector，关键代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13

   // Vertex Shader
fragPosClip = matrix_VP * vec4(fragPos, 1.0);
   fragPrevPosClip = matrix_Prev_VP * vec4(fragPos, 1.0);

/*********************************************************/

// Fragment Shader
// Motion vector
   vec2 prevNDCCoord = fragPrevPosClip.xy / fragPrevPosClip.w;
   vec2 currNDCCoord = fragPosClip.xy / fragPosClip.w;
   vec2 motionVec = (currNDCCoord - prevNDCCoord) * 0.5;

   GBuffer3 = vec4(motionVec, 0.0, 0.0);

注意这里一定要是未Jitter的Motion Vector，否则可能会错误采样到别的像素。原因也不难理解，Motion Vector代表的是像素间的对应关系，考虑Jitter就不合理了。

[3]也包含了UV动画产生的Motion Vector的计算方法，简单张贴一下：

Resolve

Resolve负责进行帧间的累加，大致流程如下，图源[5]：

Resolve实际上很简单，就是利用Motion Vector算出当前像素在上一帧对应的位置，采样历史颜色并按一定的权重做混合，这样产生的画面就成功完成了抗锯齿，关键代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13

   vec2 uv = fragTexCoord;
   vec2 offset = 1.0 / vec2(textureSize(currentFrame, 0));
   vec2 mv = texture(GBuffer3, uv).xy;
   vec3 currentColorHDR = texture(currentFrame, uv).rgb;
   vec2 jitteredUV = uv - mv;
   vec3 historyColorHDR;
   if (jitteredUV.x < 0.0 || jitteredUV.x > 1.0 || jitteredUV.y < 0.0 || jitteredUV.y > 1.0) {
       historyColorHDR = currentColorHDR;
   } else {
       historyColorHDR = texture(historyFrame, jitteredUV).rgb;
   }

FragColor = vec4(mix(currentColorHDR, historyColorHDR, historyWeight), 1.0);

但是这样会有几个问题，下面逐一来解决。

遮挡造成的鬼影

这里借助以下FSR的图进行说明，在场景发生运动时，遮挡关系也会随之发生变化，如下图所示，Disocclusion Mask的黑色部分是没有历史信息的。如果我们还是拿着Motion Vector去采样便会造成错误的结果。

解决方式也不难，在当前帧中采样3x3邻域内的颜色，并计算这些颜色构成的AABB，然后将historyColor Clamp到对应的AABB中。另外在[2]中UE也提到在YCoCg颜色空间中进行Clamp会更好，最终代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13

// Clamping history color to avoid disocclusion artifacts
vec3 minColor = RGBToYCoCg(currentColorHDR.rgb);
vec3 maxColor = minColor;
for (int x = -1; x <= 1; x++) {
    for (int y = -1; y <= 1; y++) {
        vec3 sampledColorHDR = texture(currentFrame, uv + vec2(x, y) * offset).rgb;
        sampledColorHDR = RGBToYCoCg(sampledColorHDR);
        minColor = min(minColor, sampledColorHDR.rgb);
        maxColor = max(maxColor, sampledColorHDR.rgb);
    }
}
historyColorHDR.rgb = clamp(RGBToYCoCg(historyColorHDR.rgb), minColor, maxColor);
historyColorHDR.rgb = YCoCgToRGB(historyColorHDR.rgb);

AABB Clamp可能会造成偏色，[2]中提出了对应的解决方法，即将historyColor Clamp到AABB的边界而非角落，项目中没有实现就不再赘述了。

闪烁

Clamping很容易导致高光部分发生闪烁的问题。由于我们采用的是周期性指数平均的混合方式并开启了HDR，某些亮点可能会周期性出现并主导混合结果进而导致闪烁。有两个解决这个瑕疵的Trick，第一个是在混合前进行可逆的临时性Tonemapping，第二个则是[2]中提出的根据Luminance降低高亮度样本的权重。两个方法都能一定程度上抑制闪烁，随便用一种即可。当然代价也是有的，高亮部分会稍显黯淡。Shader代码如下：

1
2
3
4
5
6
7
8
9
10
11

// Tonemapping
vec3 currentColor = Tonemapping(currentColorHDR); 
vec3 historyColor = Tonemapping(historyColorHDR);
vec3 blendedColor = currentColor * (1.0 - historyWeight) + historyColor * historyWeight;
FragColor = vec4(InverseTonemapping(blendedColor), 1.0);

// Weighted blending
vec4 currentColor = AdjustHDRColor(currentColorHDR); 
vec4 historyColor = AdjustHDRColor(historyColorHDR);
vec4 blendedColor = currentColor * (1.0 - historyWeight) + historyColor * historyWeight;
FragColor = vec4(RestoreHDRColor(blendedColor), 1.0);

效果

首先是不使用Clamping的效果图：

使用Clamping并抑制闪烁后：

渲染管线的其余部分

天空盒

天空盒也要生成对应的Motion Vector。

SSAO

由于此时的Depth Buffer是Jitter过的，SSAO的半球面采样点投影后也要加上Jitter才行，否则画面会整体闪烁。

Forward管线

Forward管线理论上也是与TAA适配的，不过为了输出Motion Vector的话需要借助MRT或Multi-Pass。

遗留问题

• 当高频的细节如草地或法线贴图与其他部分混合时Clamping会失效，如下图所示，注意下图的草地部分有淡淡的轨迹，[3]中提出了解决方法。

  

• 由于采样history frame时用的是双线性插值，经过TAA的累积后图像可能会变得更加模糊，解决方式为使用5-tap的Catmull-Rom Filter来滤波，参考[1]的Blurring部分。

• 画面在场景发生运动时会变得模糊似乎是这类时间性抗锯齿方法的通病，既然借助于历史信息了就必定会有这个问题，不过怎么说都比发生时域上的高频闪烁好。

更好的方案

FSR2/3、DLSS3往上(DLAA)和TSR都可以在超分的同时抗锯齿，DLSS还能借助光流估计以及CNN或ViT的帮助来减少鬼影并提高稳定性[7]。

参考

1. Temporal AA and the Quest for the Holy Trail

2. HIGH-QUALITY TEMPORAL SUPERSAMPLING SIGGRAPH COURSE 2014

3. Temporal Antialiasing In Uncharted 4

4. 主流抗锯齿方案详解（二）TAA

5. Temporal Reprojection Anti-Aliasing in INSIDE

6. Temporal Anti-Aliasing(TAA) Tutorial

7. DLSS Wikipedia Page

引子

说在前面，本人并非wmc，同样也是音游苦手。本次只是为了探索Steamdeck的潜力，因此对于一些关于Maimai的概念解释和术语可能不准确，请见谅。

目前的效果是，能在Steamdeck的桌面模式下进行竖屏的游玩，只显示P1，解锁全曲目和难度，支持Freeplay但只能以Guest模式进入游戏，同时MelonLoader无法加载，因此没办法加载Mod如AquaMai。

另外请注意，这只是一次探索，并非最优雅的解决方式。

在开始前请速览下一节列出的资料。

资料速览

• Maimai版本与Dump的对应关系：https://web.archive.org/web/20230730211439/http://teknoparrot.link.free.fr/multi/maimai%20finale.html

• SDEZ 1.55 DX Prism Plus Download：https://www.emuline.org/topic/3489-reposted-maimai-finale-dx-dx-splash-universe-festival-sega-ringedge/page/12/#comment-165666

• SDEZ 1.56 Download：https://dc.evilleaker.com/?lang=zh-cn

• SDEZ配置指南1：https://performai.evilleaker.com/manual/games/maimai_dx/setup/

• SDEZ配置指南2（主要看评论区）：https://www.94joy.cn/maimai/267/

• Segatools Git Repo：https://gitea.tendokyu.moe/TeamTofuShop/segatools

建议首先遵循SDEZ配置指南1完成相关资源的下载和配置，出现问题后再从Emuline和SDEZ配置指南2的评论区中寻找解决方案。

P.S. Emuline目前已经关闭了注册渠道。

部署指南

Steamdeck的初步配置

1. 进入Desktop Mode，打开应用商店，安装ProtonUp-Qt和ProtonTricks。

2. 打开ProtonUp-Qt安装GE-Proton，这是Proton的一个开源的增强版本，添加了若干的Patch。另外补充一下，Proton是在Wine的基础上改动的，因此如果要在Linux跑游戏的话还是首选Proton，不行了可以再尝试Wine。

   P.S. 在GE-Proton的官方Repo中看到说在Proton是会跑在容器中的，如果要在Steam之外运行程序的话只能借助某个特定Launcher才能做到。不过本人并没有使用该Launcher，我猜是该容器只是为Proton配置好了对应的环境变量和文件系统，当然可以借助其他的方式完成。

下载和配置SDEZ

1. 在电脑上下载1.55或1.56版本的SDEZ，如果是在evilleaker下载的话，请按照SDEZ配置指南1解压和配置Segatools，在Emuline提供的Pixeldrain下载的则是已经配置好的版本。
2. 配置好后可以先在PC上试试，如果OK的话说明配置大体没问题，这里不用虚拟Aime卡并注册AquaDX和MuNet也行，因为目前来看Deck上也用不了。
3. 将配置好的传输到Deck，由于文件不小，建议的传输方式为使用Wrapinator，如果网络的好的话用SMB或SFTP也行。

SDEZ在Steamdeck上的配置

注意，下面的所有操作都在桌面模式中进行！

1. 将Package/Sinmai.exe右键添加到Non Steam Game，打开Steam，首先将游戏执行文件的路径改为Package文件夹中的Start.bat或Launch.bat，注意路径中不能有中文；然后设置兼容性，改为GE-Proton。

2. 此时试着启动游戏，Sinmai会闪退，只有bat和inject的命令行窗口出现，在Steam中停止游戏即可。

3. 打开刚才安装好的ProtonTricks，进入到SDEZ默认的Wine容器，选择第一项即安装Windows DLL或组件，安装下面的功能：

   • dotnet 3.5
   • dotnet 4.0
   • dotnet 4.8
   • dxvk
   • ucrtbase2019
   • vcrun2012
   • vcrun2019

4. 装好后还是使用ProtonTrick对SDEZ的容器运行Wine配置程序，选择驱动器一栏，删除掉根目录到Z盘的映射，添加容器根目录到D盘的映射。

5. 修改Package/segatools.ini，dns一栏中的default填aquadx.hydev.org或play.mumur.net都行，keychip请留空，否则游戏会卡死。

6. 修改config_client.json，lan_install/server和net_delivery/enable都修改为true，否则会卡配信サーバーcheck过不去。

7. 修改config_common.json，找到credit项修改为如下所示的内容，开启freeplay：

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

   "credit": { "enable": true, "max_credit": 24, "config": { "coin_chute_type_common": true, "service_type_common": true, "freeplay": true, "coin_chute_multiplier": [ 1, 1 ], "coin_to_credit": 1, "bonus_adder": 0, "game_cost": [ 1,2,2 ] } }

8. 修改Start.bat（或Launch.bat），将Sinmai的启动参数改为：

   -screen-fullscreen 1 -screen-width 1600 -screen-height 1280

9. 因为没有找到让窗口变成portrait的方法，最抽象的一步要来了：打开系统设置，找到显示和监视器一栏，将屏幕的方向调整为第一个也就是800x1280。由于这一步的存在，之后进行游玩时也只能在桌面模式下玩。如果有人能找到旋转屏幕的方法就好了，实测config_common.json中video一栏的配置不会生效。

10. 打开Steam，完成最后的按键映射，新建一个控制器布局，将ABXY和D-Pad一一映射到键盘的QWEADZXC八键上，分别对应洗衣机（bushi）的每个按钮，同时建议把背面握持键也做一下映射，比如R5映射到Esc，这样可以方便退出游戏。

大功告成

可以开玩了！

注意事项

• 游玩前请进入到桌面模式，并调整为竖屏。
• 长按右侧手柄的三道杠按钮可以切换按键绑定，在游戏中需要使用我们之前配置好的布局。

简介

暴雪在2017年的GDC上做了关于守望先锋中ECS系统设计的分享，那个时候的暴雪啊，反观现在。B站有大佬的译制版本，链接在此。

ECS系统

ECS的核心目的是将行为与状态严格解耦。为了做到这一点，ECS系统将架构划分为了实体 Entity、组件 Component还有系统 System，见下图：

• Component只包含状态以及一些用于读取状态的辅助函数，辅助函数无行为且无副作用，Component的生命周期管理会使用多态来实现，即重写构造和析构函数。

• Entity基本就是一个Components的集合，另外有唯一的Entity ID作为标识符。

• System负责纯粹的行为，可以读取并更新Components，System的更新逻辑大致如下，EntityAdmin发起System的更新，每个System会重写自己的Update。System在Update时会遍历行为所涉及到的所有Component，并利用Component中保存的状态完成行为，必要时还可以使用访问同一个Entity上作为Sibling出现的其他类型Component。

  

行为与状态的解耦

上面的设计初看已经能解决行为与状态的耦合了，但是必须还要考虑System中的一些细节。比如系统A与系统B存在交互，系统B需要访问系统A并且保持一些状态，同时B的行为还会在A中产生副作用。暴雪最初的方法是创建一个全局变量用于维护这些一次性状态，这样做有若干的问题：

• 增加编译开销，改全局变量会使所涉及到的任何System都重新编译
• System间产生了耦合，无法确定Side Effect是该在A还是在B中

解决方法就是将这些一次性状态和逻辑移动到每个EntityAdmin中只有一个的Singleton Component中。说它时Component也不尽然，它既有行为又有状态，同时也不归属到Entity而是由Admin直接管理，不过考虑到有状态这一点叫Component也不是不行。

使用Singleton Component后，B就可以执行其中所实现的辅助行为函数了，这样就防止了A和B间的行为互相渗透。暴雪也对这些Utility Function提出了具体的要求，如下图所示：

副作用

对于Singleton Component的辅助行为函数，我们当然是希望其中的副作用越少越好，并且副作用所影响的东西也是越少越好。对于这种共享的行为来说，当然副作用是难以避免的，同时与共享该行为的System数量有关。一旦Side Effect的数量增多，实际上也就产生了很严重的耦合，这里我猜可能的例子就是Side Effect有先后顺序的情况。

暴雪因此提议将所有的Side Effect延迟执行，一个系统会将要发生的Minor Effect提交到一个对应类型的Pending列表中，并在Entity Admin的Update步骤最后添加对应类型Side Effect的ResolveSystem来将所有待执行的Minor Effect合成为每帧一个的Major Effect。

Tim举了个形象的例子，比如猎空（应该说闪光？）和法鸡（还是讲法老之鹰？）都在设计同一个位置，猎空的双枪会带来大量的弹痕贴花，法鸡的火箭炮则会带来一个爆炸贴花，理论上如果猎空的子弹先命中那么法鸡的爆炸贴花应该是要覆盖弹痕贴花的。将每个贴花视作一个Minor Effect，完全可以延迟到ResolveSystem中再应用LOD和覆盖等等规则，从而大幅降低开销。

初步总结

通过ECS系统的约束，可以大幅提高工程的可维护性、解耦度以及可读性。

分享的后半部分是关于Netcode与ESC的结合的，这个先挖个坑。

这篇文章是对于GAMES 104游戏引擎物理系统一节中GJK算法的学习总结。

Minkowski Sum 闵可夫斯基和

首先明确，一个闭合形状可以通过边界点集来定义。

对于两个形状 $A$ 和 $B$ 来说，他们的闵可夫斯基和即为两个集合中的点两两相加形成的点集，记作 $A+B$ 。一个直观的理解就是将其中的一个形状 $A$ 所在坐标系的原点平移到另一个形状 $B$ 的边界上，并沿着 $B$ 的边界扫过一周，这样得到的新边界即为Minkowski Sum，如下图所示：

闵可夫斯基和有一个重要的性质，即闵可夫斯基和的凸包等于两个形状各自凸包的闵可夫斯基和。这样的话，如果两个形状本就是凸的话，Minkowski Sum的凸包就会恰好包含两个形状内无穷多个点两两相加的结果。

Minkowski Difference 闵可夫斯基差

如果两个形状相交的话，那么一定会存在至少一对 $A$ 和 $B$ 中的点 $p_A$ 和 $p_B$ ，使得 $p_A-p_B=0$ 。尝试将这个观察与上面所述的Minkowski Sum联系起来，定义闵可夫斯基差为 $A-B=A+(-B)$ ， $(-B)$ 即 $B$ 中的点绕原点翻转后得到的点集。

P.S. 按照Wiki上的说法，这其实不是Minkowski Difference的正统定义，而是Hermann Minkowski，不过在碰撞检测中只会用到上面的定义，这里就不再深究区别了。

根据Minkowski Sum的性质， $A-B$ 的中含中包含了所有点对的差值。也就是说如果这个凸包能够包围原点的话，这两个形状就是相交的。这样我们就把一个本来要做无穷次判断才能得到答案的问题成功转化为了一个有界的问题。乍一看，单纯按照这种方法来测试的话复杂度仍是平方级别的。可以证明得到的凸包至多只有 $|A|+|B|$ 个顶点，[3]中给出了在 $O(n\log n)$ 内直接构造Minkowski Sum凸包的算法，大致的思路就是首先按照逆时针的顺序对于两个点集中的顶点排序，再使用双指针比较Polar Angle来保证不重不漏，具体可以参考原文章，这里我们不会用到这种算法。

GJK算法

当两个形状的点数很多时，由于我们的目标只是判断包不包含原点，相应闵可夫斯基差的凸包可能会有很多冗余。比如在2D的情况下，我们实际上只需要判断闵可夫斯基差中最接近原点的三个点与原点的关系即可。这就是GJK算法的Motivation。

单纯形定义为 n 维空间中最简单的几何体，比如在2D空间中就是三角形，3D空间中就是四面体。GJK 是一个迭代算法。它的目标是构建一个位于 $A-B$ 内部的单纯形，并检查这个单纯形是否包含原点。

GJK算法引入了支撑函数的概念，用于感知形状的边界。支撑函数的定义如下：给定一个方向向量 $d$，形状 $C$ 的支撑函数返回在 $C$ 中沿着方向 $d$ 最远的点。支撑函数的一个关键特性是：闵可夫斯基差的支撑点可以通过原形状 $A$ 和 $B$ 的支撑点来计算，即support(A - B, d) = support(A, d) - support(B, -d)，这点也很直观。

GJK的伪代码如下。NearestSimplex(s)会接收一个若干维单纯形 $s$ ，返回 $s$ 上离原点最近的子部分（比如对于三角形可能返回的是一个三角形或是低一维即一维单纯形的线段）、从简化后的单纯形指向原点最近的方向向量（比如简化后的单纯形是线段时返回线段的垂足到原点的方向向量）以及判断原点是否在单纯形内的判断结果。

1
2
3
4
5
6
7
8
9
10
11
12
13

function GJK_intersection(shape p, shape q, vector initial_axis):
    vector  A = Support(p, initial_axis) − Support(q, −initial_axis)
    simplex s = {A}
    vector  D = −A

    loop:
        A = Support(p, D) − Support(q, −D)
        if dot(A, D) < 0:
            reject
        s = s ∪ {A}
        s, D, contains_origin := NearestSimplex(s)
        if contains_origin:
            accept

对于GJK算法的说明如下：

• dot(A, D) < 0说明支撑点在接近原点的方向向量的投影比原点要近，由于支撑点已经是最接近原点的点了，因此这个代表闵可夫斯基差的单纯形就绝不可能包含原点了，可以直接返回reject。
• NearestSimplex(s)内对于单纯形的处理如下，以输入为三角形 $ABC$ 为例，步骤如下：
  • 检查原点 $O$ 是否在 $AB$ 的内侧，可通过计算 (B - A) × (O - A) 的符号来判断。如果 $ABC$ 逆时针排列则叉积的结果小于$0$则在外侧，否则为内侧。
  • 同样地，检查边 $BC$ 和 $CA$。
  • 若是都在内侧，直接返回。
  • 否则原点一旦在任意一条边的外侧，则将单纯形简化为这条边对应的线段（即更靠近原点的子部分），同时返回从该线段指向原点的垂直方向。

总的来说，GJK通过迭代维护了闵可夫斯基差的一个最接近原点的子集，利用这个子集作为闵可夫斯基差的代理来判断是否包含原点，从而大大提高了算法的效率。

具体的实现先挖个坑 ;)

EPA算法 (Expanding Polytope Algorithm)

EPA算法算是GJK的扩展，当检测到碰撞时，EPA可以算出来穿透方向和穿透深度，当我们需要把两个物体分离时会很有用。这部分也暂时留个坑，可以先参考[4]。

参考

1. GJK算法的Wiki
2. GJK算法的可视化展示
3. Minkowski sum of convex polygons
4. EPA (Expanding Polytope Algorithm)

前言

近期去了海南旅游，有幸观赏到了美丽的日落，配上洁净的沙滩和硕果累累的椰树可以称得上是种享受。现在想想，这种美丽的晚霞也非首次目睹，然而即便是欣赏了上千次，每当通过那绚烂的大气层看向那浩瀚无垠的银河时仍会感到头晕目眩。

此外，在本人玩过的游戏中，欧卡2中的大气和云也是令人印象深刻，比如下面这张（忘了是在哪里截的了，好像是在荷兰？）。不过这个云感觉不是用噪声做的，太逼真了，层次也分明。之前特意观察过，云似乎是有多张实拍的贴图，随着时间做简单的线性插值的。

当然巫师3的大气也很美，下面这张图好像是在陶森特截的。一个题外话，GAMES104也拿类似的场景举过例子，最终的画面表现中Bloom功不可没。不过感觉这张截图中的Fog似乎用力过猛了。

既然无论是湛蓝的晴天还是翠绿兼血红的晚霞都能让我们浮想联翩，不如手动去创造一个出来。

参与介质和体渲染

显而易见地是，大气是一种参与介质，光会与参与介质发生以下的几种交互：

自发光

粒子吸收能量后释放光能就有了发光现象，对于大气可以先不考虑这种交互的影响。

散射

散射分为两种，首先是外散射，表现为光线被散射后脱离视线方向。然后是内散射，对于某个粒子来说，周围粒子发生外散射后一部分光线偏向了该粒子，为它带来了额外的能量。也就是说，其实只有一种散射即外散射，但是对于它发生一次或是多次的情况需要分别考虑。这里就把单次散射和多次散射建立了联系，后面会看到具体是怎么回事。

定义散射系数为$\sigma_s$，基于大气的密度在高度上的分布是不均匀的，以及粒子对不同波长的光散射率不一样这两个观察，可以知道$\sigma_s$是关于波长$\lambda$和高度$h$的函数。为了方便后续的讨论，我们希望能够将散射系数拆分为为两个函数乘积的形式，这两个函数分别以$\lambda$和$h$作为参数。选择某一高度作为基准平面（海平面），计算此时的散射系数为$\sigma(\lambda,0)$，并使用$\rho(h)$来表示介质密度随高度的分布，散射系数可表示为

$$\sigma_s(\lambda, h)=\sigma(\lambda,0)\rho(h)$$

吸收

介质的吸收系数用$\sigma_a$来表示，[2]中提到了它是一个概率密度函数，因此取值范围不是0到1。在一段极短距离$dt$上（其实应该用导数符号的，偷个懒），辐照度的吸收量即

$$dL_o=-\sigma_a L_i dt$$

解微分方程即得到某段距离$d$上的能量保留率，在计算时我们会使用分段求和的方式来逼近这个积分

$$e^{-\int_0^d\sigma_a(p+\omega t, \omega) dt}$$

同样的，吸收系数也是关于波长$\lambda$和高度$h$的函数，我们也会使用它的分解形式来计算。

透射率

外散射也可以理解为一种衰减，不妨考虑一条光线沿直线传播，将散射系数$\sigma_s$加上吸收系数$\sigma_a$，再定义湮灭系数$\sigma_t=\sigma_a+\sigma_s$。仿照计算能量保留率的思路，可以算出来光线透过某个介质后的能量还剩下多少，称之为透射率Transmittance：

$$T=e^{-\int_0^d\sigma_t(p+\omega t, \omega) dt}$$

由于指数函数，很容易可以看出某一段路径的Transmittance等价于多段子路径Transmittance的乘积。同时把指数上的积分单独拎出来看的话，它也等价于所有子路径上积分值的和。不妨为这个积分（不考虑符号）起个名字，叫光学深度$\tau$，数学上即为对应的积分：

$$\tau=\int_0^d\sigma_t(p+\omega t, \omega) d$$

只要能算出$\tau$，透射率自然就能拿到了。不过在实现大气散射的过程中，只需要知道Transmittance的计算方法就行了，我们不会去单独计算和存储光学深度。

相位函数

我们已经定义了散射系数，它的意义是在某一点上能量被散射的概率，那被散射的能量在不同的方向上是如何分布的呢？这就要请出相位函数了，它是一个在球面上积分为1的函数，描述了某个方向上逃逸的散射光能量的百分比。为了简化问题，假设相位函数是各向同性的，定义为$phase(\theta)$，其中$\theta$即为外散射方向与入射方向的夹角。

散射函数

将散射系数与相位函数相乘就得到了我们所需要的散射函数

$$S=\sigma_s \cdot phase(\theta)$$

常见的散射方式

大气中常见的两种散射为瑞利散射和米氏散射，他们对应了不同的基准散射系数$\sigma(\lambda,0)$、相位函数$phase(\theta)$和密度分布函数$\rho(h)$。

瑞利(Rayleigh)散射

瑞利散射发生于粒子远小于波长的情况下，它的方向性较弱，但是散射率随波长的变化较大。瑞利散射对于蓝光的散射率很大，因此有了蓝天；它对红光的散射较弱，在傍晚由于蓝光由于传播距离增大和多次散射而几乎衰减殆尽，而红光则能够顺利地到达地面，因此傍晚的天空呈玫瑰红色。瑞利散射和吸收不会同时发生。瑞利散射的各种属性参考本节的表格。

米氏(Mie)散射

当大气中粒子的直径与辐射的波长相当时则发生米氏散射。它有很强的方向性，不过对于不同波长的光基本一视同仁。同时，发生米氏散射的粒子同时也会发生吸收，且散射和吸收共用一个密度随高度的分布函数。米氏散射的各种属性也请参考本节的表格。

光与介质的其他交互方式

为了实现更真实的大气，我们还需要考虑臭氧层，它的特点是不发生散射只发生吸收。

参数速查表

通过上面的描述，可以总结出我们需要的所有参数分别是：基准平面处的散射系数$\sigma_s(\lambda,0)$、密度随高度的分布$\rho(h)$、
基准平面处的吸收系数$\sigma_a(\lambda,0)$以及相位函数$phase(\theta)$。两种散射的高度函数都是以指数衰减的形式定义的，使用标高$H$来进行归一化，而臭氧层的密度由于不是随高度单调变化的，所以它的$\rho(h)$会有所不同。之后会使用上标来区分这几种交互方式。

对于米氏散射而言，它的相位函数带有额外的各向异性参数$g$，用于调节散射波瓣的形状。

散射系数和吸收系数在不同的参考资料中有细微的差别，下面的具体值与参考资料[1]相同。

通用的相位函数

查阅资料发现，其实还有一些更通用的相位函数，比如HG(Henyey-Greenstein)和Draine相位函数。米氏散射的相位函数就是Draine（见下式）相位函数在$\alpha=1$时的特例：

单次散射模型

有了上面对于某种粒子的散射与吸收的模型，我们来着手考虑光从太阳到相机的这段路途上发生了什么。在不考虑自发光的假设下，只需要累加视线上所有粒子的内散射乘上该粒子到相机中间的透射率即可得到来自大气的辐照度，表达为数学式如下：

$$L_i(c,v)=\int_{t=0}^{||p-c||}T(c,c+vt)L_{in-scattering}(c+vt,-v)\sigma_s dt$$

上式中的$L_{in-scattering}(c+vt,-v)$包含了某个粒子的所有内散射，即周围粒子传递给该粒子的能量乘以相位函数的总和。它实际上是一个球面上的积分，显然很不好算，我们不妨来考虑一个简化的模型：对于积分路径上的粒子，我们只考虑有多少阳光直直地穿过大气并到达了这个粒子，它散射到视线方向上的光又有多少成功透过大气到达了相机。也就是说模型统计了如下路径的贡献：太阳$\rarr$透射$\rarr$粒子$\rarr$散射$\rarr$透射$\rarr$相机，称之为单次散射模型。同样的，我们只需要在视线上做如下的积分即可，下面的示意图来自[1]：

也就是说，我们需要计算的量为从太阳到某点$p$的透射率$T1$，点$p$的散射函数$S$以及点$p$到相机的透射率$T2$。由于要使用分段求和去逼近积分，所以肯定需要遍历路径上的每一个点，中间可以顺手把$T2$和$S$算出来，但是$T1$的话会额外增加一层循环，对于实时渲染来说难以接受平方的复杂度。所以考虑能否将太阳到某点$p$的透射率预计算出来。

预计算Transmittance

首先一个最简单的观察，在相同的高度上，透射率是各向同性的，也就是说天顶角相同时的透射率也相等。根据这个观察就只有两个参数要在意了，即离地心的距离$r$（减去半径就是高度）和天顶角的余弦$\mu=\cos \theta$，可以制成一张二维的LUT供查询。这样就需要将$r$和$\mu$映射到UV，根据[1]，使用归一化地平线的切线长度作为$u$，并用归一化后的视线上下扫射能够所取到的距离作为$v$，能够提高查找表的利用效率并避免在极点处产生瑕疵。

实现UV的映射后，只需要一个全屏的Pass就行了，计算出来的结果如图：

然后我们就可以利用这张LUT，在自定义天空盒材质中采样了，最终的渲染结果如下。

在实验中发现使用距离来归一化天顶角还是会在头顶上产生畸变，如下图所示，之后试着用一下[5]中提到的映射方式：

多次散射模型

只考虑单次散射大多数情况下是足够的，不过当太阳高度角很小甚至为负时就会显得有些不足了，特别是头顶上会显得死黑，我们来尝试处理一下多次散射。将光线在大气中发生散射的次数称为大气散射的阶数。

定义$L_n(p,\omega)$为在经历了$n$阶散射后从$p$沿着$\omega$方向看向天空的光照，也就是我们最终要求的量，$G_n(p,v)$为考虑$n$阶散射的情况下$p$点散射到$v$方向上的能量和，注意在下面的定义中$G$项的积分内部并没有乘上散射系数，公式截图来自[1]：

将$G$的定义带入到$L$中可以看出这是一个三重积分，计算复杂度很高。不过球面上的采样数并不需要太高，这个性质可以利用一下。传统方法中，$n$阶散射由迭代更新得出，输入$L_{n-1}$，根据四个参数$r,\mu,\mu_{s},\nu$，计算一次二次散射，即可得到$L_n$并制成一张4D的LUT，如下图所示：

Epic基于对于Path Tracing Reference的观察，提出了一种简化的计算方式，基于下面的两个假设，分别是：

1. 大于等于2阶的散射中的相位函数趋于各向同性
2. 计算大于2阶的散射时，认为某点周围任意一点的$G_n$与其相同

第一点意味着，在相位函数变为各项同性时，可以把4个参数中的$\mu$和$\mu_{s}$这两个角度干掉，将LUT降低到2维。

新方法的主要亮点在于第二点，[1]和[4]中都给出了简要的推导，这里复制了[4]中的推导过程，首先再次给出$G$和$L$的定义：

根据假设2，在计算大于2阶的散射时，$G$项对于路径上的点来说都是常数，可以从积分里提出来

定义$L_f$和$f_{ms}$为，$f_{ms}$为传输函数

可以注意到刚才的式子中的积分部分其实就是$L_f$，将定义带入到式子中可以得到相邻阶$G_n$之间的一个比例关系

这样，如果能算出$f_{ms}$和$G_2$的话，就可以直接利用等比数列求和算出来无穷阶的$G$了

$f_{ms}$和$G_2$都是三重积分，原论文[5]中在球面上均匀取了64个采样方向，每个方向步进20步，最终的结果保存为一张32*32的二维LUT，UV代表的分别是归一化高度和太阳天顶角

具体实现中，使用Fibonacci采样预先生成64个方向，做Ray Marching时计算Single Scattering并积累到$G_2$上并利用之前的Transmittance LUT顺便计算$f_{ms}$，渲染Sky View LUT时累加多重散射项即可。加上多重散射后的对比如下，最明显的不同就是天空会更蓝一点

Atmospheric Fog

远景的物体也会收到大气散射的影响，我们实际看到的颜色应该为(远处物体的反射光×远处物体到相机的透射率+远处物体到相机对应视线路径上的大气散射光)。这样的话需要对于每一个着色点都需要做Ray Marching来计算透射率和散射光，考虑如何做成LUT提高计算效率。

方法就是将视锥按照深度分层，每层的分辨率都很小比如32x32，每层都单独计算Scattering和Transmittance，后处理时对这个LUT做三线性插值并与Color Buffer混合即可。这种方法的不足就是没有体积效果。

在项目实现中，会从最近的分层开始逐渐向远处计算，这样就能复用之前累加的光学深度了。将视锥按照线性深度均匀地划分为16层，每层最多步进4步，相当于32*32条光线在带有距离限制的情况下步进了64步。

[1]中提到可以利用光学深度的性质采样两次Transmittance LUT来查询一段路径上的Transmittance，窃以为有两点不足，一是多了两次采样，二是Transmittance LUT本身对应的光线覆盖距离区间很大且精度不高，而View Frustum一般不会有那么大，所以不如在步进中重新算一遍来的实在。

下面是加上Atmospheric Fog的效果，远处的山多了朦胧的感觉

总结

最后附上项目地址：Github

参考资料

1. 实时大气散射渲染实战
2. Physically Based Rendering：体积散射
3. Supplemental: An Approximate Mie Scattering Function for Fog and Cloud Rendering
4. UE4新版大气实时渲染-论文导读
5. A Scalable and Production Ready Sky and Atmosphere Rendering Technique
6. Physically Based Sky, Atmosphere & Cloud Rendering

本文为GAMES 202 PBR Material的笔记

PBR和PBR材质

所谓PBR，指的是渲染过程中的一切都是基于物理的，包括材质、光源、相机和光照传输，不过在实践中一般单指材质。

实时渲染中的PBR Materials

表面的材质主要有两种，Microfacet模型和Disney Principled BRDFs。不过按照课件所说，这两种其实并非是基于物理的，它们仍然遵循着RTR领域的优良传统：hack和近似。

体积渲染的话，关注点更多是在如何快速近似单次或多次散射。

Microfacet(微平面)模型

Microfacet模型将表面近似成若干微小的镜面，并通过控制微平面的法线朝向来模拟不同的材质。回顾一下Microfacet BRDF的公式：

$$ f(\mathbf{i}, \mathbf{o}) = \frac{\mathbf{F}(\mathbf{i}, \mathbf{h})\mathbf{G}(\mathbf{i}, \mathbf{o}, \mathbf{h})\mathbf{D}(\mathbf{h})}{4(\mathbf{n}, \mathbf{i})(\mathbf{n}, \mathbf{o})} $$

其中$\mathbf{F}$项是菲涅尔项，可以让材质展现菲涅尔效应，$\mathbf{G}$项是阴影-遮挡项（阴影和遮挡其实是两码事，下文会解释），$\mathbf{G}$是法线分布。

F

大多数材质在观察视角接近掠射时反射会增强，这就是菲涅尔效应。对于绝缘体来说，这种效应尤其明显，而导体（金属）的菲涅尔效应则没有那么明显，因为无论观察角度如何反射率都很接近$1$。

菲涅尔项的计算非常复杂，不仅要考虑光的极化（偏振），对于金属还会涉及复数域上的计算，因此RTR领域中必须找到快速近似的方法。常用的近似是Schilick’s approximation，它不考虑极化。Schlick’s appoximatio的公式如下，其中$n_1$和$n_2$分别是入射介质和出射介质的折射率：

$$ R(\theta)=R_0+(1-R_0)(1-\cos \theta)^5, R_0=(\frac{n_1-n_2}{n_1+n_2})^2 $$

D

描述法线的分布，分布越集中则高光更明显，分布越分散则越接近diffuse材质。常用的模型有Beckmann和GGX。

Beckmann NDF

Beckmann NDF在形式上类似高斯分布，都是指数族的。各项同性Beckmann分布的公式如下：

其中$\alpha$代表粗糙度，$\theta_h$代表半程向量与法线的夹角。老师也解释了为何其中会有$\tan \theta$项，因为Beckmann是定义在Slope Space（就是垂直于半径的切平面）上的，所以原来的$x$值就被替换为了$\tan \theta$（见下图）。

GGX(or Trowbridge-Reitz)

与Beckmann相比峰度更小，拥有更长的尾部，因而材质会展现出更平缓的高光过渡，公式如下（$m$就是半程向量）：

GGX还有一个通用的形式GTR(Generalized Trowbridge-Reitz)，它可以通过额外的参数$\gamma$进一步控制long-tail的程度，下面是GTR的可视化：

Unity 2022对于GGX的实现如下：

1
2
3
4
5
6
7

inline float GGXTerm (float NdotH, float roughness)
{
    float a2 = roughness * roughness;
    float d = (NdotH * a2 - NdotH) * NdotH + 1.0f; // 2 mad
    return UNITY_INV_PI * a2 / (d * d + 1e-7f); // This function is not intended to be running on Mobile,
                                            // therefore epsilon is smaller than what can be represented by half
}

G

G项为所谓的Shadowing-masking term，用于计算微平面间的自遮挡现象。Shadowing是指入射光被微平面所遮挡，而masking是指出射光被微平面所遮挡，分别对应下面左右两张图：

同时也可以直接从BRDF公式的角度来说明G项存在的必要性，由于归一化常数$(\mathbf{n}, \mathbf{i})$的存在，分母在观察角度近乎垂直时会接近$0$。此时不考虑自遮挡的话，边缘会异常明亮。

Smith Shadowing-masking term

Smith是常用的阴影遮挡项，它假设shadowing和masking是独立的两项，公式如下：

Unity 2022中对应的实现如下：

1
2
3
4
5
6
7

inline half SmithVisibilityTerm (half NdotL, half NdotV, half k)
{
    half gL = NdotL * (1-k) + k;
    half gV = NdotV * (1-k) + k;
    return 1.0 / (gL * gV + 1e-5f); // This function is not intended to be running on Mobile,
                                    // therefore epsilon is smaller than can be represented by half
}

Kulla-Conty Approximation

上文中的Microfacet BRDF存在一些问题，考虑下面白炉测试(white furnace test)的结果，菲涅尔项固定为$1$：

上图是渲染的效果，下图是cosine-weighted BRDF在半球上的积分，从下图中可以很明显地看到有能量损失。消失的能量去哪里了呢，由于菲涅尔项为$1$，而不同法线的分布又不会造成能量的损耗，说明问题只有可能出在$\mathbf{G}$项上。此前我们假设了那些被遮挡的光线被吸收了，然而这与微平面是镜面的假设是相悖的，被遮挡的光线应该在多次弹射后重新射出。只有额外考虑经历Multiple Bounces的光线后，BRDF才是守恒的。

Kulla-Conty即采用了这个思路去实现能量守恒，首先计算反射率：

Kulla-Conty近似希望使用一个额外的BRDF来补全多次弹射的能量，这个额外的BRDF的cosine-weighted积分为$1-E(\mu_o)$。又因为BRDF需要满足reciprocity，Kulla-Conty干脆就假设额外的BRDF满足形式$c(1-E(\mu_i))(1-E(\mu_o))$，这样需要计算归一化常数$c$就可以了。经过一番计算后，可以得到BRDF的公式：

不过$E(\mu)$和$E_{avg}$都是积分，需要预计算才能用在实时渲染中。$E(\mu)$可以制成一张关于roughness和$\mu$的2D纹理，而$E_{avg}$由于对于$\mu$进行了积分，只需要一张1D纹理即可存储。

Kulla-Conty Approximation with Color

如果BRDF带有颜色信息呢？这时我们就不能简单地将菲涅尔项固定为$1$了，因为颜色信息就在$\mathbf{F}$中。颜色就是对光线的吸收，也就是能量损失，所以思路就是再去计算一个衰减系数乘到$f_{ms}$前面。首先定义平均菲涅尔项为：

这时候经历了$k$次弹射的能量为：

$$ F_{avg}^k(1-E_{avg})^k\cdot F_{avg}E_{avg} $$

将各次弹射的能量累加起来进行无穷级数求和后得到：

$$ \frac{F_{avg}E_{avg}}{1-F_{avg}(1-E_{avg})} $$

将这个系数乘到额外的BRDF即可。

结果

使用Kulla-Conty近似后，明显明亮了许多：

GAMES202 HW3的完成记录~

总览

在延迟渲染管线下，为一个光源为方向光，材质为漫反射 (Diffuse) 的场景实现屏幕空间下的全局光照效果（两次反射）。

作业3共分为三个部分：

1. 实现对场景直接光照的着色 (考虑阴影)。
2. 实现屏幕空间下光线的求交 (SSR)。
3. 实现对场景间接光照的着色。

作业文档里使用的术语是BSDF，不过既然本次作业只会涉及到漫反射材质，下文可能会出现BSDF和BRDF的互换。

Part 1：直接光照

这部分的两个子任务是计算漫反射材质BSDF的值以及光照的强度（包含可见性），非常简单。

首先是EvalDiffuse函数的实现。虽然EvalDiffuse接收了三个参数$w_i, w_o$和$uv$，但是对于漫反射材质来说，前两个代表方向的参数都是不需要的。作业说明中提示要用到保存在G-Buffer中的法线信息，意味着计算出来的BSDF是cosine weighted的。知道了这些之后，实现EvalDiffuse就是随手的事啦：

1
2
3
4
5
6
7

vec3 EvalDiffuse(vec3 wi, vec3 wo, vec2 uv) {
  vec3 albedo = GetGBufferDiffuse(uv);
  vec3 n = GetGBufferNormalWorld(uv);
  float cos_theta = dot(n, wi);
  vec3 bsdf = albedo * max(0.0, cos_theta) * INV_PI;
  return bsdf;
}

漫反射BSDF

要注意的一点是，对于最终的漫反射值我们要乘上$\pi$才能保证BSDF的能量守恒。这个结论之前是知道的，下面给出一个简单的推导。首先根据反射率$\rho$的定义有（$E_i$和$E_o$分别代表irradiance和radiant exitance）：

$$E_o=\int_\Omega L(\omega_o)\cos \theta_o \mathrm{d}\omega=\rho E_i$$

由BRDF的定义可得：

$$\mathrm{d}L(\omega_o) = f_r \mathrm{d}E(\omega_i)$$

我们知道漫反射材质的$f_r$是常数，两边同时积分可得（注意$E(\omega_i)$和$E_i$不是一个东西）：

$$L(\omega_o) = f_r E_i$$

带入到反射率的定义后：

$$\rho E_i = \int_\Omega f_r E_i \cos\theta_o \mathrm{d}\omega = f_r E_i \int_\Omega \cos\theta_o \mathrm{d}\omega = \pi f_r E_i$$

从上式可知：

$$f_r = \frac{\rho}{\pi}$$

然后是EvalDirectionalLight的实现，需要考虑可见性项，也就是要从GBuffer中提取阴影信息：

1
2
3
4
5

vec3 EvalDirectionalLight(vec2 uv) {
  vec3 Le = vec3(0.0); // 自发光项
  vec3 Ld = uLightRadiance * GetGBufferuShadow(uv);
  return Le + Ld;
}

至此第一部分就结束了。

Part 2：Ray Marching

第二部分需要实现一个RayMarching算法来完成屏幕空间的求交，基本思路就是从某个像素对应的世界坐标出发，沿着给定的方向按照一定的步长行进若干步，直到当前坐标在屏幕空间中被遮挡，说明找到了交点。

由于我们不知道光线会行进多远，所以必须设置一个最大的行进步数。同时我们也不知道光线每步要走多远，所以这个值也是个超参数。当然，这种所谓线性搜索地方法是很慢的，老师在课上提到了使用HiZ方法来自适应地调整步长进而提高求交效率，不过在作业框架中实现HiZ是很困难的，这里就先留个坑，有意实现可以参考[2]。

回到算法的实现上来，其实就是一个步进光线然后与深度图比较的过程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

bool RayMarch(vec3 ori, vec3 dir, out vec3 hitPos) {
  const float threshold = MARCH_STRIDE * 2.0;
  for (int i = 0; i < MARCH_MAX_STEPS; i++)
  {
    ori += dir * MARCH_STRIDE;
    float ray_depth = GetDepth(ori);
    vec2 uv = GetScreenCoordinate(ori);
    float geo_depth = GetGBufferDepth(uv);
    if (ray_depth > geo_depth) { // intersection found
      if (ray_depth - geo_depth > threshold)
        return false;
      if (dot(dir, GetGBufferNormalWorld(uv)) >= 0.0)
        return false;
      hitPos = ori;
      return true;
    }
  }
  return false;
}

其中关于threshold会放在第三部分之后解释。其实在其他同学的实现中，只需要判断ray_depth > geo_depth就足够了，不过我这边如果这么写的话阴影部分会出现严重的噪点。分析了一下发现遮挡物如果是背朝光线的话一定不会对最终的结果有贡献，就额外增加了一个判断光线与法线夹角的判断。按照文档的提示验证镜面反射效果：

由于步长并不是非常小，所以在图像中间会有明显的瑕疵（跳变），不过整体效果是对的，说明实现基本正确。

Part 3：间接光照

Part 3是最有意思的一部分，需要实现支持one-bounce的间接光照。当然，如SSRT的名字所暗示的，采样是不可避免的。对于每个像素点，我们采样一条光线，然后使用Part 2实现的方法来完成屏幕空间内的求交，计算该交点的直接光照后加权并累加到最终的间接光照中去，按照给出的伪代码实现即可。框架提供了均匀采样和按照余弦分布采样两种半球采样方式，后者算是一种重要性采样了，直接无脑选择。代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

vec3 EvalIndirectLight(vec3 wo, vec2 uv, vec3 worldPos, vec3 lightDir, inout float s) {
  vec3 n = GetGBufferNormalWorld(uv);
  vec3 t, b;
  LocalBasis(n, t, b);
  float pdf;
  vec3 hitPos;
  vec2 uv1;
  vec3 L = vec3(0.0); // one bounce
  for (int i = 0; i < SAMPLE_NUM; i++)
  {
    vec3 dir = normalize(mat3(t, b, n) * SampleHemisphereCos(s, pdf));
    if (RayMarch(worldPos, dir, hitPos))
    {
      uv1 = GetScreenCoordinate(hitPos);
      L += EvalDiffuse(dir, wo, uv) * EvalDiffuse(lightDir, -dir, uv1) * 
           EvalDirectionalLight(uv1) / pdf;
    }
  }
  L /= float(SAMPLE_NUM);
  return L;
}

由于采样出来的方向向量是在局部空间的，所以需要构造局部坐标系的基向量并将方向向量转换到世界坐标系中。LocalBasis所用的方法似乎是叫Frisvad方法（GPT说的），很容易验证它是对的，但是不知道原理是什么。

改进

终于可以看到结果了，却大失所望，画面中有很多的噪点，而且不同角度下的渲染结果非常不一致，尤其是在圈出的部分有漏光现象：

转动视角后更加明显：

来探究一下原因，其实与老师上课讲的是一样的：屏幕空间会丢失信息。具体来讲，由于GBuffer只会记录位于最前面的表面的信息，当前视角中被遮挡的表面的任何信息都是未知的。在RayMarching的过程中，由于判断交点存在的条件只是深度更大，所以会出现对于遮挡关系的误判。算法错误地认为某个可见的表面会对结果产生贡献，其实真正的交点在更远处的表面上或根本不存在。为了减少误判，[1]中使用了加threshold并动态调整步长的方式在优化。在试验中发现只需要threshold就能达到较好的效果，所需的改动就是如果某一次判断时光线的深度与GBuffer中的深度相差较大就认为交点不可见并返回false，改进后的算法如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

bool RayMarch(vec3 ori, vec3 dir, out vec3 hitPos) {
  vec3 last_ori;
  const float threshold = MARCH_STRIDE * 2.0;
  for (int i = 0; i < MARCH_MAX_STEPS; i++)
  {
    last_ori = ori;
    ori += dir * MARCH_STRIDE;
    float ray_depth = GetDepth(ori);
    vec2 uv = GetScreenCoordinate(ori);
    float geo_depth = GetGBufferDepth(uv);
    if (ray_depth > geo_depth) { // intersection found
      if (dot(dir, GetGBufferNormalWorld(uv)) >= 0.0 || ray_depth - geo_depth > threshold)
        return false;
      hitPos = ori;
      return true;
    }
  }
  return false;
}

其中threshold的大小与STRIDE呈正相关，降低在某些STRIDE较大的场景中错误地舍弃交点的几率。

最终的结果如下

场景1，采样数=8, stride=0.1, max_steps=50：

场景1，采样数=8, stride=0.1, max_steps=50：

场景3，采样数=8, stride=0.6, max_steps=30（记得在engine.js中切换灯光，要么场景会很暗）：

暗处的噪点说实话并不明显，场景三还是很震撼的，除了硬阴影的锯齿有点扎眼外。

参考

1. Games202 作业三 SSR实现
2. GAMES202-作业3

该文章内容主要来自于虚幻5的官方文档[4]。

介绍

一开始只觉得Lumen听起来很高大上，以为它除了渲染之外还有一些内容，最后发现是和Nanite搞混了（难绷）。按照文档的介绍，Lumen其实就是UE5新推出的全局光照(GI)和反射系统。最离谱的是，Lumen可以近似反射了无限次的漫反射光照和高光光照，甚至能在复杂环境中达成实时渲染。Lumen是此前各种屏幕空间技术(SSGI)和距离场环境光遮蔽(DFAO)的替代品。P.S. DFAO是虚幻4中所用的环境光遮蔽方法，文档里描述其与SSAO最大的区别是遮蔽在场景空间遮挡物中进行计算，因此出屏丢失数据不会导致瑕疵，至于原理吗，我猜与GAMES202中所讲的距离场阴影类似。

要启用Lumen，需要在Project Settings->Rnedering中启用Dynamic Global Illumination和Reflections这两项（新项目应该是默认启用的）。

特性

全局光照

• 不限制弹射次数的间接漫反射光照
• 真实阴影（在光线追踪器中，阴影就不需要用传统方法去做了）
• 要求实时性的情况下会以较低的分辨率来计算间接光照

天光(Sky Lighting)

天光在UE中负责模拟来自天空或远景的间接光照[1]，Skylight计算的光照会填充场景中的阴影部分，增强环境光照。Lumen也会为半透明材质和体积雾计算一个低质量的全局光照。

自发光材质

自发光材质的贡献在Lumen的Final Gather Process中被计算。目前Final Gather还不太理解，留个坑。

反射

Lumen支持各种粗糙度材质反射，包括清漆（clear coat）和不透明材质的glossy反射，打开对应选项后也能渲染出半透明材质在最前面一层surface上的反射。Lumen还支持渲染单层水面的镜面反射。

Clear Coat材质

即基础层上覆盖了薄薄的一层透明涂料，比如车漆[2]。Clear coat材质也可以使用Cook-Torrance microfacet BRDF来表示[3]。

双面树叶

允许光线在树叶中的次表面散射，效果出奇的好。下图右边是开启Two-Sided Foliage之后的效果

设置（略）

补充说明

Lumen的更新速度

因为lumen似乎使用的是类似光照探针的技术并将计算压力分摊到多帧上来保证实时性的，所以局部光照条件的变化会快速传播，而全局的光照变化（如禁用阳光）需要一定的时间才能收敛。实测如果在项目中将主要的平行光设置为不可见的话，场景会缓慢变暗。而且如果仔细观察的话，直接光照会立即消失，间接光照则是缓慢黯淡。

Lumen反射

Lumen Reflections没有与Lumen GI耦合，可以单独拿出来配合静态烘焙光照（Lightmap）来使用。

材质环境光遮蔽（AO贴图）

由于使用了光线追踪，屏幕空间的AO和AO贴图也就没有必要了，不过还是可以在项目设置中启用的。
P.S.1 UE编辑器界面中Buffer Visualization->Ambient Occulusion似乎指的是SSAO，此时由于未启用SSAO所以应该只能观察到纯白色。
P.S.2 [5]中提到，Buffer Visualization其实就是绘制了G-Buffer中的内容，但是材质里面的AO贴图并不会被写入到G-buffer中，而是会被叠加到Lightmap，Stationary sky light和Reflection capture specular中去，因此预览Material Ambient Occlusion无法得到正确的内容。

参考资料

1. What exactly is a Skylight in UE4?
2. 车漆渲染做法Clear-Coat
3. Physically Based Rendering in Filament#Clear coat model
4. Lumen Global Illumination and Reflections
5. Unreal | AO那些事

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.

Quick Start

Create a new post

1

$ hexo new "My New Post"

More info: Writing

Run server

1

$ hexo server

More info: Server

Generate static files

1

$ hexo generate

More info: Generating

Deploy to remote sites

1

$ hexo deploy

More info: Deployment