Global Gamejam 2025 Review

いつも通りの世界を

今日だって駆けてゆくんだ

—— 《雑踏、僕らの街》

开发记录

24年末(期末)的时候突然看见了 Global Gamejam 的微信推送,我一直是有着做游戏的梦想的,而且平时也没有时间逼着自己看冗长的网课学习 Unity 或者 UE,作为一个实战派的选手还是觉得得在实战中锻炼自己,随加群暗中观察。

一进群就被大佬的招人信息吓到了(打过好多次别的 Gamejam 放作品集的简直太恐怖了orz),然后就在群里潜水。后来水群的时候突然发现认识的学长 YXH_Xianyu 也加了群!后来想想,自己编程能力还是不足以单人支撑起一个团队,怕搞砸最终的项目,于是就和咸鱼鱼,还有美术选手 DWTornier 以及音频选手 AzurIce 组成了2程1美1音的队伍(但是没有策划,这里也埋了一个不大不小的坑),组队上还是十分幸运的!

临近开始的一周内咸鱼鱼用了 BJTU 软件学院的服务器配了 SVN,简单的测试了一下项目协作,没有太大问题后来到了周五。在起队名的时候,我们一行人想到的全都是少女乐队2333 最后有人说了一句“熙熙攘攘”,我便加了两三个字“熙熙攘攘、我们的Jam”,这便是我们的队名了。

今年的题目是泡泡(Bubble),公布之后,咸鱼提议让我们先自己思考一下idea,然后再汇总,毕竟我们没有策划,在立项的时候得大家都一起想~不得不感叹学物理还是有用的,正好这学期末刚考完波动光学,就想到了泡泡的薄膜干涉。入射光线和干涉后产生的光线颜色是随观察角度变化的。

咸鱼鱼和 AzurIce 的想法其实都很好玩(尤其是一个关于水蛛,织网把泡泡带到巢里呼吸的想法很有意思233),但是要么是因为Gamejam的开发时限可能做不出来,要么是玩法有些复杂/重复,最后我的这个泡泡薄膜干涉的方案得到了启用。周五当晚我们开展了大规模的头脑风暴大脑升级,首先是量化游戏机制(把泡泡抽象成三个参数),设计各种分裂、充气抽气的机制,然后探索机制可能的关卡上限(第六和第七关就是在这个过程中设计出来的)。当晚还和美术等一同讨论了游戏导引的事情。

周六和周日就是主要的开发过程了。我原以为我会去写很多Gameplay相关的代码,到最后还是变成了TA向的工作(动画、Shader等等)hhh,感慨咸鱼OI选手的实力实在是强,抽象化的光线主逻辑基本是一遍过的,让我写估计要debug好久,就做不完了()美术素材画的也非常好,苹果发布会风格非常顺眼,而且工作效率也很高——音频更是牛,一个人处理了音频播放的代码和制作音乐音效,毕竟是BJTU软件出身代码能力也很强(

当然动画也踩了很多坑,主要是Unity用的不熟吧,动画状态机的过渡以及和美术素材的交互确实略有些困难。Shader其实写的也比较抽象,写了一份光线出射的泡泡颜色遮罩,但是效果不好而且适配不了动画遂弃置了;另外一个踩入的坑是SVN,哇SVN的自动代码合并比Git差太多了,每次都要手动去看而且有很多bug,以后开发游戏还是用Git做版本控制……

周日迅速地封包发布了,不仅编译了Windows,我还部署出了Android Apk,然后音频Macbook佬部署了MacOS和iOS(iOS倒是折腾了半天,最后发现重命名文件夹为Payload就能跑了233)

感想

之前一位游戏行业的前辈和我说过,这种活动的最重要的价值就在于可以让不同岗位职能的同学在一起进行团队协作,这是在校内不可能获取到的能力,而且这种能力在游戏开发中是十分重要的。

也是搞明白了策划要干什么233 关卡设计头脑风暴还是很耗费脑力和体力的,尤其是对于解密来说需要专职和专业的策划来完成这个事情,不然实在是非常大脑升级。

我自己的代码水平还是有待提升)这个没办法,只能多写,毕竟我不打OI,整体的coding量自然是比较少的;然后图形学的本职工作基本没用上(。大概是因为Unity的框架不熟(比如Bloom效果对特定物体生效、Shader的编写、修改材质属性等等),然后技术美术向的开发效率还是有点低了。Gamejam还是很需要TA人才的(还好我们美术是TA),如果是只会画画的原画岗位程序对接的成本就会上升——最好是有两个程序其中一个是TA——

整体是一次非常爽,十分开心的开发体验,也认识了很好的朋友!期待未来线下去打Gamejam!

2024 Review

你有多久没有做过梦了?我大抵确实是今年开始不再做梦的。

再放飞的理想都会因为现实的引力怦然坠地,但我确实仍有那么一丝做梦的的能力,以及意愿。

2024,并非特别值得记忆的一年,这一点在今年的游戏行业体现的淋漓尽致:游戏小年,以及TGA作为游戏春晚连饺子都没包成功。

但确实发生了很多事情,其实这一年过的也很像梦。

可以说是回避了大半年的社交,独身的感觉让人实在是感觉自由了不少,有更多时间留给自己的热爱之处。我很庆幸,我的专业是我热爱的事业,并且真的“可以coding一辈子吗,我什么都会做的”这种。

玩模联方面,和一些朋友《剪切线》了,也和另一些朋友不辞而别:说是不辞而别,或许也只是不混那个圈子,然后没什么机会再遇见而已。不过确实不觉得那些时光令人后悔,也并非“从来没有觉得开心过”,它是一段回忆,“我大概这辈子都不会忘记了”,那就够了。

我现在大抵是过了大一那一段热血沸腾、冲劲十足、高考的挫败感的那种动力期;我本身也是不怎么卷的一个人,不感兴趣的课程、不想刷的题目我的确学不进去,我也不过是那些会一觉睡到中午十二点,复习着复习着又去刷B站的一般学生罢了。有人也许会觉得我确实有点能力,尤其是在未来要吃饭的CS领域,但我纯粹只是“喜欢”而已,和那些allin算法比赛的、从零复现原神/鸣潮Shader,魔改UE管线的、allin游戏开发,有两三个demo的、尽管双非,但手上拿着一两篇Siggraph的人相比,我在兴趣上花的时间也只能说是寥寥无几。

可能让我今年精神状态比较稳定的原因是,自己热爱的事业上尚未受到重大打击,不过这也只是因为没怎么继续向前,呆在舒适区里了而已。上半年看完了GAMES101,暑假去了一趟图形学萌新夏令营,结果下半年既没有手搓个渲染器,也没怎么作开发方面的复现效果,也没去挤出时间学104、106或者是202。游戏方面,柚子社的废萌Gal都没打开来,黑神话也没静下心来打通关。技术方面,很多时候就是学了两三天,然后摆了(当然这成功拯救了我不学习flutter这种感觉是期货死人框架,应该快速转向kotlin multiplatform)。

也许很像梦,但过去的一年也十分的现实。可能我的确还秉持着朴素的理想主义,但行事准则和行事风格现实了起来,评估问题也不再用空泛的信念去构建。

可能最大的遗憾,有三个:一个是没有珍惜时间,再多学点做游戏的知识,没有产出一个DEMO;一个是没有静下心来真正连着好几天品味一款好游戏,陷入了很长时间的电子ED;还有一个则是一年中没有看一本书,玩过一部Gal,这让我的创作能力和想象力直线下降。

我早就不记得2024生日或者跨年时候许下了什么愿望了,好像是和学业到事业有关的,诸如graphics一类的事情。但是问题在于,成年人的世界里已经很少有前现代的加冕仪式。一方面,不同人的价值被投影在不同的坐标系上,不讨论参考物的加冕已是空言;另一方面,大多数人是得不到加冕仪式的,但我们的确在进步着。或许今天,我写完了期末项目中一些奇怪的新功能,写完了一套特别难的图论卷子,非常的高兴,但唯一能得到的也只是并非十分重要的两位数字或是一个英文字母。此前已经提过,我对量化成绩评估深恶痛绝,而且确实是此事的受害者。不过这大概才是生活的常态。

2024的感觉就像是确定性的平平无奇。大多数事情从一开始就差不多就知道“我能行”或者“我不行”的结果,我也确实平稳地把控着我的罗盘慢速航行。可能命中注定会从事图形学行业,记得是高中的时候知乎上看到了毛星云前辈不幸的消息,那时候我还不知道什么是图形学,不知道他翻译的RTR是什么东西,只知道他走在我喜欢的游戏行业中很前沿的国人,令人悲叹;此后大概是高考考完开始学GAMES101,只写过百来行MC Java代码的我一上来就碰到了难度顶峰的cpp,古法查CSDN,连学带抄,没用AI搞定了每个项目,现在写了一学期cpp,回过头来看也是挺奇迹的。

不长的人生中,我从未如此期待过第二年的到来。

我始终坚持着我的兴趣,我的理想,My Compass,但我也会质疑它,或许2024的大部分时间都在无意识地质疑了一年。

或许明年,我会去追求一些不确定性,哪怕让理想是粉身碎骨,从废墟中把支离破碎的义体插件再捡回来便是。

略有点想笑的是,已经过了一年多了,我对未来的期望还是一年前的一部番剧的一句很好笑的台词,而且我说的这句话的客体也只有我一个人:

“让我们一起迷失吧!”

虚幻 5.4 打包 Android 环境配置与打包

在 Unreal 5.4 打包过程中遇到了许多意想不到的环境问题,可能因为开发设备曾经配置了 Qt for Android 的一系列环境导致NDK环境不干净。接下来描述可能的解决方案。

Android Studio 配置

  1. 在 Android Studio 中下载 NDK,版本号如图所示

ue_android_studio_ndk

  1. 配置系统环境变量(Unreal会自动寻找ANDROID_HOMEJAVA_HOMENDK_ROOT,请确保以上PATH配置无误;理论上配置过后不会影响其他环境,如Qt等)

ue_android_path

Unreal 配置

  1. 在 Launcher 中安装 Android 必备组件(约8GB)。
  2. 在编辑器内的 Project Settings 中搜索 SDK,配置如图。

ue_android_path

  1. 重启电脑,否则打包会出现未知错误。
  2. 重启后,在 Project Settings 中搜索 .apk,将package game data inside .apk勾选(否则无法运行)。

ue_android_game_data

XMake 下 Vulkan 项目的配置

XMake 相较于 CMake,语法更加简单,且配备了依赖管理机制,并且可以与 vcpkg 等常用包管理器交互,使现在 C++ 项目的构建更加省心。以 Vulkan 项目为例,演示 XMake 的使用配置。

安装 XMake

Windows

1
2
3
4
# Powershell
Invoke-Expression (Invoke-Webrequest 'https://xmake.io/psget.text' -UseBasicParsing).Content
# scoop
scoop install xmake

Linux

1
apt install xmake

项目配置

创建

1
2
xmake create -l c -P ./EasyVulkan
cd ./EasyVulkan

make.lua

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
set_project("EasyVulkan")

set_arch("x64")
set_warnings("all")
set_languages("c++23")

--[[
由于MSVC的一些奇妙兼容性问题,出现了文件中含有中文注释执行错误的情况,应加入UTF-8编译选项
--]]
add_cxflags("/utf-8")

add_rules("mode.debug", "mode.releasedbg", "mode.release", "mode.minsizerel")

add_requires("vulkansdk", "glfw", "glm")

target("EasyVulkan")
set_default(true)
set_kind("binary")
add_files("src/main.cpp")
add_packages("vulkansdk", "glfw", "glm")

main.cpp

来自 Vulkan Tutorial 的演示代码,运行时应该会出现一个程序窗体

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
#define GLFW_INCLUDE_VULKAN
#include <GLFW/glfw3.h>

#define GLM_FORCE_RADIANS
#define GLM_FORCE_DEPTH_ZERO_TO_ONE
#include <glm/vec4.hpp>
#include <glm/mat4x4.hpp>

#include <iostream>

int main() {
glfwInit();

glfwWindowHint(GLFW_CLIENT_API, GLFW_NO_API);
GLFWwindow* window = glfwCreateWindow(800, 600, "Vulkan window", nullptr, nullptr);

uint32_t extensionCount = 0;
vkEnumerateInstanceExtensionProperties(nullptr, &extensionCount, nullptr);

std::cout << extensionCount << " extensions supported\n";

glm::mat4 matrix;
glm::vec4 vec;
auto test = matrix * vec;

while(!glfwWindowShouldClose(window)) {
glfwPollEvents();
}

glfwDestroyWindow(window);

glfwTerminate();

return 0;
}

构建并运行

XMake

适用于 NeoVim 或 VSCode 开发

1
2
3
4
5
# 为 VSCode 添加语法支持
xmake project -k compile_commands
# 编译并运行
xmake build
xmake run

XMake + CMake

这种配置适用于 CLion 的开发,由于 CLion 的 NMake 插件并不好用,故

1
2
3
4
# 生成 CMakeLists.txt
xmake project -k cmake
# 也可以用 CLion 直接打开
cmake --build build

机器学习 + 图形绘制

霍宇驰,ZJU

  • 传统图形学:Modeling -> Rendering

  • 知识驱动 vs. 数据驱动

  • AI -> PPL

Neural Rendering

  • CV
    • Machine Learning + Physics knowledge
    • 照片分析
    • 自由视角视频(体积视频)
  • Graphics
    • 采用机器学习取代部分图形流水线步骤

Scene

  • Mesh -> Voxel + Neural(可微性更好)
  • 基于向量的场景表达
  • Mesh-based: Neural Material
  • 基于点云的表达
  • 基于网络的表达(NeRF)

Render

  • AO
    • DeepAO: 软阴影是个低频信号,运用神经网络预测AO信息
  • 直接光照
    • IBL
    • Texture -> 神经网络方法预测直接光
  • 间接光
    • Caustic难以预测(集中)
    • 多次弹射后的间接光较好预测
  • 体积、次表面散射
  • Human-related Rendering

Global Neural Render Pipeline

  • 缺少场景中多物体交互
  • Object-Oriented Pipeline
    • NeLT: Neural Light Transfer
    • 物体可交互性
    • Caustics, transmission…
  • 动态几何
    • LightFormer: Light Encoding -> Light Gathering

Post-processing

  • 对PT结果降噪
    • 图像域降噪
    • 路径域降噪
  • 改进PT采样策略
    • 神经采样函数(Neural Importance Sampling, TOG 2019)
    • 强化学习引导
  • 多估计器混合
  • 时空样本重用
    • 蓄水池(?
  • 帧预测 - DLSS3.5
  • 神经超分
    • NVIDIA DLSS
    • AMD FidelityFX

神经渲染:NeRF与3DGS 从隐式到显式

于涛,THU

讲的很好,深入浅出,理解率挺高的

NeRF - Neural Radiance Field

  • 最初用于宏观-场景光场重建
  • 远观:黑洞光场重建
  • 微观:显微光场重建

前置概念

  • 全光函数
    • 定义:对某一点看到的物体集合
    • ref: The Plenoptic Function and the Elements of Early Vision
  • 光场
    • 定义:空间中光线集合的完备表示
  • 成像
    • 反向追踪每个像素光线与场景交互(PT)
    • 定义:从某一个角度对光场采样得到图像的过程
    • 对全光函数的路径积分
  • 光场重建
    • 采样是离散的,但光场是连续的
    • 从有限、离散的多个视角重建出整体光场
  • 新视点合成
    • 输入:多视角图像
    • 过程:光场重建
    • 结果:新视角渲染结果

定义

  • 利用神经网络表示的空间辐射场
  • 辐射场
    • 设存在函数 ​ 描述空间光场
    • 为密度值(alpha通道?)
  • 神经网络
    • 多层感知器(MLP)
      • 任意分布数据的拟合
      • 每个节点是一个非线性映射函数(神经元)
      • 通过每个神经元参数的学习,可以实现任意非线性函数的拟合
      • 即MLP拟合全光函数
      • 优化:反向传播、
    • 隐式表征
      • 离散表征:像素插值
      • 神经表征:MLP是连续函数,支持任意分辨率表征和重建
      • 三维表征:Mesh -> 连续化、occupancy networks、DeepSDF、可微Volumetric Rendering
      • 节省存储空间:存储Neural Network函数
    • 渲染质量高、不依赖几何形状、可建模材质效果

实现

  • 问题:得到NeRF,如何进行新视点合成?

    • 渲染:不能对路径采样点直接积分(没有考虑遮挡关系)
    • 方案:体渲染(Volume Rendering)
  • 体渲染

    • 透过率在单根光线 相乘得到,一旦遮挡 (​),则总透过率结果为0

    • 【NeRF二次采样没理解】

    • https://blog.csdn.net/qq_45752541/article/details/130072505

  • 重建 = 优化

    • 体渲染后得到 Rendering Loss
    • 优化参数:神经网络权重
    • 优化目标:与实拍像素一致
    • 迭代训练神经网络,直到在所有输入视角可以与实拍一样
  • 不同观测角对Shading影响

    • 表面材质和环境光决定不同视角观测颜色不一致
    • 引入观测方向影响

其他工作

  • NeRF in the Wild: 网络照片多场景合成
  • Block NeRF: 街景合成
  • InstantNGP: 渲染速度提升
  • Neuralangelo【没懂】

三维高斯溅射 3D-GS

  • 更好的训练效率、更好的重建质量、更快速的渲染

3D-GS vs. NeRF

  • 显式辐射场
    • 使用体素、网络或点云离散集合表示空间辐射场
    • 渲染速度快,但优化困难(Mesh)、渲染稀疏(点云)、分辨率低(体素)
  • 隐式辐射场
    • 使用神经网络拟合空间辐射场连续函数
    • 支持任意分辨率渲染,但渲染速度慢,计算负载高,容易产生floaters
  • 3D-GS 辐射场
    • 综合结合光栅化和体渲染的优势

Pipeline

  1. 使用一组各向异性的3D高斯点实现非结构化辐射场表达
  2. GPU并行可微渲染,实现splatting和显式梯度计算
  3. 通过自适应密度控制添加或滤除3D高斯点,实现完整重建

定义 & 实现

  • 3D-GS 点:四个属性

  • 多元正态(高斯)分布函数

    • 描述3D椭球的位置、缩放程度
    • 协方差矩阵
      • 多元正态分布的协方差矩阵是半正定矩阵
    • 不透明度α
    • 球谐函数(Spherical Harmonics, SH)
      • 描述GS的各向异性颜色
      • 定义在球坐标系中的一组基函数,描述球面上任意方向的光强
      • SH阶数越高,系数越多,表达能力越强
      • 问题:常常选用4阶SH,但4阶拟合并不是很好
        • 空间中不同角度的观察变化一般不强烈,即使不太拟合可以大概描述
      • 问题:阶数越高优化难度越高
        • 源码先优化了0阶,然后再进行后续优化
  • 初始化
    • SfM稀疏点云初始化 3D-Gaussian
    • 输入:一组静态图像
    • SfM估计相机位姿,重建系数点云
    • SDGS Init:位置(u),协方差,不透明度(α)、颜色(SH)
  • 渲染:3D Gaussian Splatting
    • 将三维高斯(椭球)投影到二维图像平面(椭圆)进行渲染
    • 分块光栅化(Tiled-based Rasterizer)
      • 分块
      • Overlapping 检测
      • 存储每个 GS 对应的所有 Tile
      • 3D高斯点的 Key 由 Tile ID 和高斯点深度值构成,Value 为高斯球
      • Radix-Sort 按深度排序,得到了 Tile 对于哪几个高斯点及其深度上的排序
      • 每个像素顺序遍历相关高斯球,进行颜色混合(考虑不透明度)
    • 效率高:做到了像素级并行计算
      • CUDA: SIMT模型
      • 每个 Tile 对应一个 Thread Block,访问 Shared Memory
      • 每个 Thread Block 首先根据 Tile 信息把高斯数据存储到 Shared Memory
      • 只读取一轮 Global Memory,之后计算颜色时只用访问 Shared Memory
  • 参数优化
    • 每次生成像素后可以直接构建Loss
    • 图像差异化计算
  • 密度控制
    • 根据高斯点的梯度判断是否过于稀疏/密集

前沿方向

  • NeRF 的成果挪到 3D-GS 上
  • 4D-GS
  • LLM + Diffusion Model + 3D-GS
  • 3D-GS for MR

实际业务

  • 移动端实时交互
  • 透明物体、复杂结构
  • 占用空间
  • PSNR > 40dB
  • 代码长度(App编译大小)

总结

大学时光确实是美好的。暑假又能抛开校内那些繁杂的行政杂物、落后现实的培养方案,也有时间去学些自己想学的东西,做些想做的事了。也正是沉重的现实引力让兴趣更显光芒。

我自己的微信签名是法国作家Alain Fournier的一段话的节选:

“即便到了今天,我们仍无法自动建模一只在水里游泳的、细节栩栩如生的老虎(…)

The bad news is that we have still a long way to go. The good news is that we have still a long way to go.”

这段话被引用于图形学的基础教材虎书中,用以解释封面的来历;如今,随着NeRF等技术的一系列发展,我们正逐渐接近这个不依赖艺术家和程序员而自动建模的目标。

往小里说,I have a dream,正如毛星云前辈所期盼的那样,期待中国游戏产业能够先进化,由《黑神话》开辟一条3A游戏工业化的道路,作为玩家,自然期待会享受到更多的国产作品。

往大里说,渲染和重建领域的很多学术问题尚未解决,学术界除了热门的AI+CG方向,传统图形学仍在不断前进,正需要科研人不断前行;除了学术之外,工业界仍在探索效率问题,尽管软硬件方面都陷入了一些品鉴,但从30FPS到90FPS,优化的道路漫漫无期。

前路漫漫,亦悲亦喜。

离线渲染:真实感材质建模

王贝贝,NJU

科研大佬!

  • 材质模型的基本概念
  • 几种常见材质模型
  • 材质模型近期进展

  • 材质:定义了渲染方程中的BSDF(BSDF = BRDF + BTDF)

    • Diffuse、Glossy、Specular
    • 前沿:(微结构)表面模型(电梯、茶壶的金属表面)、织物模型

BRDF

  • 定义在局部坐标系,以着色法向 为z轴
  • BRDF:出射的Radiance(辐亮度)和入射的Irradiancce(辐照度)的微分之比
  • 定义:
  • 辐照度Irradiance:单位面积的辐射通量
  • 辐射率/辐亮度Radiance:单位面积、单位立体角的辐通量密度

着色法向 vs. 几何法向

  • 几何法向:三角形面法向

  • 顶点法向:所有相关联的三角形面的法向的平均

  • 着色法向:定点法向插值后的法向

    • 重心坐标
  • 着色法向由于插值,可以近似光滑

方向参数化

直角坐标 或球面坐标

BRDF的不同参数化形式(在神经网络上十分重要)

  • 入射方向 + 出射方向
  • 半程向量 + 差向量
  • 各向同性BRDF ,4D->3D

讨论范畴

  • 几何光学与波动光学:材质细节与光的波长相当时,进入波动光学范畴
    • e.g: 黑色狗毛呈现彩色
  • 表面渲染与体渲染
    • 表面材质模型:入射出射为一个点
    • 次表面散射:光线在介质内传播,吸收、散射导致出射点多个
    • 渲染方程 -> 辐射传输方程(RTE)
    • 扩散理论

常见材质模型

  • 标准
    • 真实性
    • 计算高效性
    • 存储简洁性
    • 表达统一性
    • 物理性:能量守恒、可逆性
      • 白炉测试:材质球在纯白环境光下,如果与背景融为一体则能量守恒
      • 可逆性: 互换不变
      • 不强制要求,但需要考虑衡量
    • 重要性采样便捷(便于生成PDF)
    • 可编辑性

测量模型

  • 每个材质:到BRDF值的数据表格
  • MERL数据集(2003)
  • Pros: 真实性强(真实摄制)、计算高效、表达统一
  • Cons: 存储不简洁、编辑困难、不具物理性、PDF只能用累积分布函数

解析模型

  • 经验模型 / 基于物理的模型
  • Lambertian
    • Diffuse: 视角无关, 为albedo/base color
  • Blinn-Phong
    • 真实性:分布简单,塑料感
    • 高效、简洁、易于编辑
    • 表达效果不统一
    • 能量不守恒,有可逆性
    • PDF:解析公式
  • 微表面模型 Microfacet Model
    • 认为表面由多个微小面元构成
    • NDF - 法向分布函数:Beckmann, GGX, GTR
      • 参数:粗糙度(roughness)
      • GGX常用,GTR拟合更好,但打破了拉伸不变性(面积与roughness的关系)
    • Shadow Masking - 遮挡函数
    • 菲涅尔项
      • 光线在两种不同折射率的介质中传播时的反射比例
      • 金属:接近1,贴地角出反射更强
      • 非金属:垂直入射处折射为主,贴地角处反射变强
      • 与界面折射率(IOR)有关,与材质的物理属性有关
        • 金属的IOR是复数,常规折射率 和消光系数
      • 计算开销:需要考虑偏振,与光线波动性有关
      • 实时渲染:Fresnel Schlick 近似
    • 没有漫反射项、金属度
      • Cook-Torrance模型:Lambertian + 微表面
    • Disney Principled BRDF
      • 广泛应用于UE、Blender等
    • 真实性:在金属、粗糙玻璃有真实感,无法模拟视差、双高光
    • 高效性:实时渲染需要近似
    • 无法表达纤维材质,高光分布不同
    • 有解析解,但每种NDF需要特定的PDF采样

其他BRDF

4D -> 6D 增加了uv维度

  • SVBRDF
  • BTF

近期进展

  • 传统方向
    • 微表面模型多次散射
    • 微结构模型(存储开销)
    • 多层材质模型(SpongeCake)
    • 布料、皮肤、头发
  • AI + 材质
    • 神经网络材质表达
    • 材质推导和重建
  • 展望
    • Physics vs. Data
    • 材质模型何时统一:surface & volume
      • From microfacets to participating media: A unified theory of light transport with stochastic geometry. SIGGRAPH 2024
    • 材质 + AI

当代游戏引擎光照与几何处理前沿技术

王希,不鸣科技

  • 现代游戏要60FPS,10-30ms生成1frame
  • 工业界实现了大量的hack
  • MCRT -> Reflective Shadow Maps,Ray Marching
  • LPV:
    • SVOGI & VXGI:体素化全局光照(前者采用八叉树)
    • SSGI:屏幕空间全局光照,开销小

Lumen

  • 开销最大、最不稳定的问题:Visibility(Ray Trace),每个像素只能承担1/2根ray
  • 空间体素存储光照信息,Screen Probe Structure
  • 世界空间 Radiance Cache
  • 把各种算法在不同情况下结合起来
  • Nanite - Skipped

ReSTIR GI

展望

  • 看起来对的就是对的

  • 从PBR到AI: Data Driven,Neural Network based Material

交流环节

Unity vs. Unreal

  • 并行化问题:UE和Unity仍是几十年前的古典架构,没有太多区别
    • 主线程 + 其他线程
    • 用一些Trick处理并行化的问题(物理模拟、Gameplay AI等),类似 Vic3 的多核优化
  • 引擎魔改问题
    • Unreal高度集成化,底层C++,对于引擎的修改大多数是直接修改源码
    • Unity大多数情况可通过暴露的C#进行修改,大厂会养自己的团队魔改底层;更利好个人开发者
  • Nanite:主要问题在于显存带宽而非算力

脚本选型

  • Apple的更新政策,导致更多开发者倾向采用脚本作为资产的方式开发,以规避更新审核
  • Lua vs. Python
  • Lua: 轻量化、效率较高
    • practice: Roblox
    • Lua-jit,但最初开发者神隐了
    • Luau:强类型的Lua,类似TS和JS
  • 个人更倾向Lua

图形API

  • DX12 vs. DX11:12更底层,上限更高,可以魔改pipeline(可以在传统vertex-fragment基础上修改流水线)
  • Vulkan:类似于DX12,更加底层,同时难度也更高,目前正在适配移动端,属于未来的技术

光线云:云原生实时渲染引擎 - RaysEngine

王锐,ZJU,光线云

公司背景

ZJU CAD&CG,基于渲染技术在工业界发展

EAR制裁(0%美国技术可用)

技术背景

  • Web 3.0:个人化时代

  • XR、三维可视化

  • 端云协同的渲染

端云协同引擎

实时渲染:GPU与渲染流水线

王锐,同上

概述

  • 求解渲染方程

    • Path Tracing
    • 有限元方法,Radiosity
  • 实时

    • 传统:30FPS
    • VR:90FPS
    • 晕3D问题:可能需要更高的刷新率
  • Local Shading:只算直接光:

渲染管线

Rendering PPL

  • 历史:Geometry Engine(SGI 1982) -> Voodoo -> NVIDIA GeForce RTX 4090
  • 图形工作站 -> 2D图形计算卡 -> 3D显卡

早期阶段

  • Model -> Vertices -> Pixels -> Color Pixels
  • Transform&Lighting -> Rasterizer -> Shader
  • CPU应用 -> 系统调度 -> GPU

固定管线

  • 固定函数绘制流水线(Fixed-function Rendering Pipeline)

  • 早期~2000

  • 1992,SGI成立OpenGL
  • Vertex -> Fragment -> Blending
    • Model: Modeling, Vertex-Shading, Transformation, Clipping(裁剪)
    • Screen Vertices: Projection, Rasterization
    • Pixels: Visibility
  • 一个Pixel可能有多个Fragment,故OpenGL命名为Fragment

可编程管线

  • 核心问题:Vertex、Fragment阶段的自定义

  • Programmable Shaders

  • 发展:GPGPU(General-purpose GPU),发展到CUDA,利用GPU并行能力

  • 着色阶段发展

    • 几何着色器(Geometry Shader): 在 Vertex 和 Fragment 中间
    • Tessellation Shader(细分曲面着色器)

Graphics API

  • OpenGL
    • 最新版本:4.6,已停止演化
    • OpenGL ES - 移动端
      • 基于 OpenGL 4
      • Version 3.2
      • Shader based
    • WebGL - 浏览器
      • 基于 OpenGL 3.0
    • 发展历史
      • 2.0 - 可编程管线
      • 3.2 - 几何着色器
      • 4.1 - Tessellation Shader
      • 可拓展插件:Mesh Shader
  • WebGPU
    • W3C维护,发展中
  • Vulkan
    • 最新版 Version1.3
    • Vulkan vs. OpenGL
      • 应用负责内存、线程等管理
      • 上手难度大
      • Driver通用性
  • DirectX
    • Windows
    • 跨平台性差
    • 非向前兼容

着色语言

  • RenderMen: 2019 Turing Award

    • 辐射度算法,引入了着色语言(Shading Language)
  • HLSL、GLSL、MSL(Metal)、WGSL(WebGPU)

    • C Styled
  • SPIR-V Toolchain
    • 从不同着色语言转为跨平台API调用

GPU光追

  • 2018,NVIDIA RTX
    • Previous: OptiX
    • 发布了 Mesh Shader、RTCore

实时渲染方法

王璐,山东大学

Shadow Mapping

  • 2-pass Algorithm
    • Light pass: 从Light方向看去得到深度图
    • Camera pass: 着色点投影到光源矩阵下,比较1st pass的深度
      • Vertex: 着色点对光源作变换
      • Fragment: 根据深度图作Visibility test
    • Shadow Acne
      • 阴影自遮挡问题
      • 方案1:前向面和后向面都做一次着色,计算平均值得到深度图(开销大)
      • 方案2:得到深度图过程中,一个bias的着色(可能会漏光)
      • 高分辨率问题
      • 方案:在视锥中不同区域绘制同样分辨率的材质(近处阴影细节多,远处阴影细节少)
  • Soft Shadow
  • PCF(Percentage-closer Filtering)
    • 2Pass中,查询着色点周围一圈区域(Filter)
    • 受Filter Size影响
  • PCSS
    • 本质:自适应边缘的PCF
    • Step1: 进行一个固定大小的查询,算出周围遮挡体深度的平均值
    • Step2:计算半影半径
    • Step3:PCF
  • VSSM
    • 切比雪夫不等式
    • 借助Mipmap/SAT生成阴影纹理
    • 问题:漏光、存储开销变高(深度图、深度图平方、Mipmap)
  • DFSS
    • Ray Marching:基于SDF
  • UE 应用
    • Shadow Map
    • Virtual Shadow Map
    • SDF
    • RT + 去噪
    • 预计算 / 动态GI

3D Space GI

  • 开销小:One-bounce
  • PRT(Precomputed Radiance Transfer)
  • VXGI(基于体素的GI)
    • 体素存储
      • 八叉树:很难在GPU上存储
      • Clipmap:不同LOD存储不同数目体素
    • 1st pass: Light pass,获得次级光源注入体素
    • 2st pass: 根据着色点查询周围的Cone中的体素,累计间接光
    • 漏光、遮挡问题(体素内部不考虑可见性)
  • Light Map
    • 预烘培光照贴图
  • Light Probe
    • DDGI

Screen Space GI

SSAO

AO:渲染方程中Visibility项

  1. 在屏幕空间中,判断每个像素表面周围(法向半球体)采样点是否落在模型内部
  2. 根据外部点/内部点的比例计算遮挡系数

SSR

【没懂】

  • 在边缘处作一个滤波避免割裂

Real-time RT

  • Graphics API + Hardware
  • 目前只能承担1SPP
    • 取上一帧的大量数据去噪(TAA)
  • 鬼影、遮挡问题
  • 插帧、超分:Tensor Core 利用网络生成高分辨率结果

  • Nvidia Real-time Denoiser(NRD): 非网络

  • Nvidia DLSS

研究进展

  • Neural Basis Function for PRT
  • Real-time Woven Fabric Rendering
  • VR中适用SSR:左右眼显示效果不一致,提出了一致性处理方法

展望

  • 复杂几何体:动物皮毛等复杂结构难以用Nanite处理
  • 复杂材质
  • 复杂光源
  • 更多次弹射的GI
  • 去噪:快速运动场景中可用信息很少,如何去噪

高质量LBVR应用研发分享

XVERSE元象

LBVR简介

  • Location-based VR,沉浸式,在特定地点提供沉浸式体验
  • 幻旅之门项目
    • PICO & Quest: Android平台
    • Vision Pro:闭源,暂不支持UE

VR性能优化

  • 性能要求:90FPS,晕动症问题

  • Meta: ASW(Application SpaceWarp)

    • 插帧实现高帧率
    • UE插件支持
  • 模型减面

    • 边折叠:QEM
    • 顶点合并, etc.
  • QEM

    • 收缩一条边,收缩一条边上的两个顶点,设定收缩阈值,计算损失矩阵
    • 停止迭代:豪斯多夫距离
      • 问题:效果不可控、没有结合业务现状(减面效果与视角无关)
    • 方案:加入剪影Loss

手势追踪绑定

  • 交互动作:适配不同模型的人物需要调整
    • 手K
    • 基于视觉的动捕(不成熟)
    • 动捕设备

资产优化

  1. UE PSO(Pipeline State Project)

    • 降低第一次打包时卡顿
    • 设置开启PSO采集->打包->运行采集->转换缓存->重新打包
  2. 双目视频压缩

    • 全景图(球形、立方体),双目视差

    • MV-HEVC

      • 存一个视角的信息+另一视角的部分信息

CGPC2024 第一日

全息数字人

鲍虎军,浙江大学

多媒体 -> 三维重建与渲染 -> 沉浸式自由视角

关键问题:高精度、多模态

现有技术

  • 几何建模
  • 仿真与渲染
  • 视觉插值(View interpolation)
  • 重建

重建

  • 多视图立体几何(Multiple View Stereo)

    • 开销大、噪点多(需要很多相机)
    • 难点:精度,如何抽取二维特征点
  • 神经辐射场(NeRF)

    • 传统重建

      • 位姿求解->深度计算->点云融合->网格提取

      • 流程长、不可微

    • 神经网络重建

      • 隐式场渲染,可微
  • 低成本方法

    • Sparse multi-view video -> Volumetric video
    • Neural Body
    • SMPL Human Model
    • 体渲染(Volume Rendering)

问题:多人近距离交互情况下,遮挡关系、骨架结构

数字人驱动

多模态信息交互

  • 文本/语音驱动 ASR/TTS
  • 视频驱动 单目/多目影像重建
    • AD-NeRF

未来工作

  • 基于物理的环境交互
  • 数字人-自然人交互
  • 自交互(Audio-Lip/Motion)

渲染

NeRF速度较慢(体渲染)

Efficient NeRF: 生成深度图,导引采样

  • 720p+ 5FPS

发展:4K4D实时渲染

  • EasyMocap
  • EasyVolcap

图像/视频生成:从PBR到基于数据的合成

刘利刚,中科大

基于数据的生成:SoRA等基于深度学习的绘制方法

颜色计算:数据表示、计算方法

PBR:基于第一性原理计算

  • 数据表示:Scene
  • 计算方法:Rendering->Color

建模:几何仿真 渲染:色彩仿真 动画:运动仿真

1. 建模

Model + Texture

2. 渲染

Projection & Shading

解渲染方程:采样、缓存

  • 蒙特卡洛方法:光路采样
  • 有限元方法:辐射度等

GAMES303 要出了!

已知三维场景的渲染

  • 传统:面表达和面渲染

  • 复杂情况:体表达(透明物理,散射光路)

问题

  • 输入:单视点/多视点采集
  • 输出:新视点的图片

方法

  1. 3D重建,渲染计算
    1. 可微渲染(Inverse Rendering)
  2. 不显式计算场景,图像插值2D算法(IBR)

IBR

光路复杂,不可微

方案:体表达,假设直线光路

  • 应用于CT成像可视化

NeRF:场表达

3D物体内部点(坐标)与光量

重要技术:位置编码

3D场表达

高斯函数拟合,点表达

基于数据的合成

纹理生成:根据一定方法,取邻域内的像素生成

Siggraph2019:GauGAN

Sora:text-to-video

国内CG研究成果fast-forward

DRGraph:图布局优化,ZJU SE

三维智能感知与高精表达

物理仿真、学习仿真,任博,NKU

视觉大模型,XVERSE元象

鸿蒙OS、媒体AIGC,华为

动捕、人体重建渲染,北师

智能柔性传感动作捕捉,厦门大学

OctFormer,北大

几何处理,高林,中科院

基于基函数渲染(实时渲染)、光追去噪、可微神经渲染等,徐坤,THU

多视角重建、手势AIGC、Shader简化、连续插帧,霍宇驰,ZJU

NPR+可动文生图,Image-3d,NeRF fast inference,易冉,SJTU

Taichi Graphics,https://www.taichi-graphics.com/

视频生成动态流体仿真,mchu@pku

各向异性材质物理仿真,Data-Physics模型,高阳,BUAA

开放大世界建模&重建、实时体积云、全动态GI,腾讯IEG

物理仿真,无人机重建,https://taodu-eecs.github.io/

材质恢复、神经网络材质、参与介质渲染,王贝贝,NJU

后略

离线绘制:光线追踪算法原理

徐昆,THU

数理原理

  • 随机变量、概率、分布

  • CDF、PDF

  • 无偏估计:

  • 逆变换采样

    1. 求CDF

    2. 求CDF的逆函数

    3. 对[0,1]的随机变量a,令X=P(a)

  • 拒绝采样法

    • e.g: 单位圆的均匀分布
  • 二维流形采样

    • 参数曲面描述二维流形
    • 如何保证曲面仍是均匀分布?构造“保面积映射”

蒙特卡洛积分

  • 给定某随机变量X,按其PDF采样,求f(x)/p(x)的期望即为f(x)的积分
  • 无偏性、收敛性
  • 降低估计量方差方法:重要性采样分层采样拟蒙特卡洛方法

重要性采样

  • 找一个和f(x)形状相似的p(x)

多重重要性采样

Balance heuristic:TODO

拟蒙特卡洛方法

采样时使用低差异序列代替随机数

优点:收敛速度更快

缺点:部分情况出现走样

俄罗斯轮盘赌

给定终止概率q,对积分F构造F’,1-q的概率取(F-qc)/(1-q),q的概率直接取c(c、q任意)

E[F’] = E[F]

增大方差,但舍弃了代价高昂的计算(递归深度大的情况)

光线追踪算法:路径追踪

主流算法:Path Tracing,由Kajiya与渲染方程一同提出

基本概念:辐照度、辐亮度、BSDF(BRDF+BTDF)

反射光强 = BRDF(入射光)的积分

入射光必须递归计算,无穷维积分得到渲染方程,只能采用蒙特卡洛方法求数值解

路径采样

从相机出发逆采样,对每个结点进行采样

全路径概率p(x) = p(x0,x1,….,xk) = 条件概率乘积

问题:

  1. 路径长度限制(何时停止)
    1. 设置最大深度:有偏方法,能量不守恒
    2. RR:可以根据当前材质反射率、当前路径总体贡献、深度等动态计算终止概率q,收敛速度变快方差变大
  2. 收敛速度慢
    • 重要性采样
      • 根据交点的BRDF确定一个和它接近的BRDF
    • NEE(Next Event Estimation)
      • 在路径中的中间节点直接和光源采样(减少相关性)
      • 无论RR是否通过,在光源上采样给得到一个最终节点x0
      • 返回xk xk-1…x0
      • 如果RR通过,方向采样得到下一个中间节点
    • 直接光照估计:MIS
      • BRDF重要性采样:大光源、光滑表面(Glossy材质反射比较集中)
      • 光源重要性采样:小光源、粗糙表面

参考

  • PBRT

  • LuisaRender

前沿渲染

路径引导

学习场景中的光场分布:S-D Tree,在线更新PDF

神经方法:将神经网络视为生成随机数的生成器

渲染降噪

滤波、回归、深度学习

从低spp的渲染结果,利用反射率贴图、法线贴图、深度贴图降噪

离线降噪:权重预测网络

路径复用

神经辐射缓存:使用轻量神经网络你和、存储场景个点辐射场信息

求交加速&GPU光追

求交加速

层次包围体 / 空间剖分

GPU

20系:10Grays/s

30系:同时追踪和着色

40系:硬件光线排序、表面细分

框架:OptiX

LuisaCompute LuisaRender:跨平台统一、编程灵活

实战中的实时渲染

腾讯前沿游戏技术中心引擎专家,袁亚振

项目 vs. 研究

  • 项目的短板不能太短
  • PPT、源代码,是否能快速复现
  • 方案是否Production Proven

全动飞行模拟项目

同步渲染、工业适配

渲染:地球级别的数据组织、标线和灯光渲染、PBR大气云雾

标线、城市:锯齿和闪烁问题

TAA:模糊

方案:UE5 TSR、DLSS、DLAA

UE整合:Aggregate G-Buffer AA(https://research.nvidia.com/publication/2016-07_aggregate-g-buffer-anti-aliasing-unreal-engine-4)

光照烘焙

困难路径采样(间接光采样)

  • Practical Path Guiding

超大规模光源

  • Light Grid + Light BVH

超大规模场景

  • 爆显存问题

游戏资产的智能创建

网易伏羲

3D AIGC

捏脸数据AI

捏脸系统:变量多,输入维度多

角色智能创建:图像识别捏脸、文字生成捏脸数据

  • 生成式模型作为渲染器,模拟渲染
  • 通过神经网络定义人脸相似度,反向传播求解骨骼参数

  • NPC生成,提升开发效率

  • 玩家自定义,提升沉浸感

交互式多轮编辑

  • 可以通过对话来生成捏脸数据,可以和玩家讨论

交互场景AI

文字生成交互场景

  • 书法风格补全
  • 地图生成

华硕幻16颜色显示对比度偏低问题及处理

问题描述

某次重启之后蓝屏,之后同样的颜色(FF0000)

问题排查

  • 在核显和 Optimus 模式下颜色出错
  • 独显模式下正常

问题解决

  1. 重置色彩管理文件(ICC)到出场配置(奥创中心自动生成的)
  2. 在英特尔显卡控制中心重置色彩配置

Minecraft FRP 服务搭建

引言

SakuraFrp 提供的服务在高峰时期经常出现断联情况,故利用自己的小服务器做一下 Frp。

服务端

  1. 下载 Frp:

https://github.com/fatedier/frp/releases/download/v0.57.0/frp_0.57.0_linux_amd64.tar.gz

  1. SSH 到服务器端,进入 frp 目录,给予执行权限:
1
2
3
ubuntu@VM-28-8-ubuntu:~/frp_0.57.0_linux_amd64$ ls
frpc frpc.toml frps frps.toml LICENSE
ubuntu@VM-28-8-ubuntu:~/frp_0.57.0_linux_amd64$ chmod +x frps
  1. 修改 frps.toml
1
bindPort = 7000
  1. 运行服务
1
2
3
4
ubuntu@VM-28-8-ubuntu:~/frp_0.57.0_linux_amd64$ screen -S frps
ubuntu@VM-28-8-ubuntu:~/frp_0.57.0_linux_amd64$ ./frps -c ./frps.toml
# 按下 Ctrl+A+D 离开
# 重新进入:screen -r frps
  1. (可选)配置 Nginx 反向代理
1
sudo vim /etc/nginx/nginx.conf
1
2
3
4
5
6
server {
server_name frp.bearingwall.top; #改为你的域名,记得配置DNS
location / {
proxy_pass http://127.0.0.1:7000;
}
}
  1. 在防火墙放行 25565 和 7000 端口。

客户端

  1. 下载 Frp:

    https://github.com/fatedier/frp/releases/download/v0.57.0/frp_0.57.0_windows_amd64.zip

  2. 修改frpc.toml

1
2
3
4
5
6
7
8
9
serverAddr = "frp.bearingwall.top" #未配置Nginx则改为服务器IP
serverPort = 7000

[[proxies]]
name = "minecraft-main"
type = "tcp"
localIP = "127.0.0.1"
localPort = 25565
remotePort = 25565
  1. 运行服务
1
./frpc.exe -c ./frpc.toml

写于2024元旦

守住自己的内心,守住自己的生活,就是在守住不惑的底线,守住人生的大盘。

即使不知道答案,即使不清楚前路,仍可选择做最值得的自己:去思考、去行动,去迎接、去探索。

——《南方周末》编辑部

并没有写2023的年度总结,并不是意味着去年没有值得纪念的事情,也不因为留下的也不尽是遗憾,尽管的确有诸多遗憾,自己也仅仅只是在数小时前从遗憾的情绪之中走出。

但此刻,更多的是对未来的期许;尽管,没有事业是已经完成的,Manjaro 还有一定量的驱动问题,101也只是看了一半。

我不喜欢说“2024会好起来的”。拥抱过去,创造未来。

我更想说的是,2024,守住初心,守住未来。

Stanley 于 北平