ParticleToy开坑：离线物理+光追渲染引擎

起

前阵子又去油管上看了看正经的navier stokes方程解析。发现所谓的正经公式也就是那些微观离散的简单法则给“正经化”，“连续化”。

我终于意识到，我以前去看所谓微分方程公开课，根本就是阻碍我去真正理解这些东西的拦路虎。

都是很简单的东西，“哪有那么复杂”——《一一》。

今天是初二，没有事情做，结合最近一阵子总是鼓捣Houdini和Niagara的工作经历，还有看各种siggraph的视频，我意识到Particle这种思维方式，才是最简单有效，也是最接近真理的。

自从去年7月份进了S公司以后，自己好像就停止了编程一样。总觉得自己像The Beginner's Guide里的主角一样，心中的Machine已经停止工作，就想拿把机枪把所有傻逼玩意儿扫个稀巴烂。

昨晚还梦见前女友了，她说我丧失了爱的能力，已经不会再爱了。我这才重新意识到我从出生开始一无所有，死亡之后也一无所有。编程是陪伴我最久的情人，不可辜负。

这样想了之后，感觉自己一无所有，又无所不有，心中不再是Machine或者是方块在转动，而是递出了一把剑，与天道相通（老中二了）。

于是想到了写一些正儿八经的Particle代码，感觉会很好玩，也能让自己学很多，而且可以写很长时间，项目起名ParticleToy。

承

我自编程以来接触了各种SDK，只要和图形有关都很恶心。我很痛恨这种东西。

于是灵机一动，Houdini那些复杂计算也是CPU算的，GPU加速在少数。但Houdini在家用机上进行常规操作，不慢。

而且Houdini导出的数据虽然是“死”的，但进到ue4里还是可以再利用，而且很好看。

又结合Teacher马，雷布斯都说过（反正这帮人都喜欢这么说），现在要去做10年以后的事情，不能做当下的事情。

那么结了。我想着用纯C++写Particle逻辑；再通过写个插件ParticleToy导入到ue4里，可视化，debug都可以在ue4里实现。

只要C++还没淘汰或硬件没大变，那么逻辑端永远不会被淘汰（只要写的好）。

其实很简单，甚至看起来很幼稚，无非就是C++逻辑，ue4当渲染器。我不能承认我菜，大道至简吧。

承1

先用Verlet进行物理模拟，搞个g=10的重力的重力小点。由于之后接碰撞检测，为方便验证，接下来准备先做UE4可视化，估计拿UE4.26写个插件。

这是我极其重视并思考代码架构的一次。之前的2D引擎的封装最多是简化操作，基于项目；这次是实打实从哲学和未来上考虑。不知道这次能不能打破菜鸡程序员个人项目最多写2000行的魔咒...

承2

空有一个重力小球的场景验证，基本完成。UE4不愧为一个垃圾引擎。2个大坑：

1.UE4.26+VS2017,创建C++空项目都有问题。我改UE4.22了，反正作验证用的。

2.不论怎么调UE4 Physics的参数，运行前零点几秒UE4的物理模拟总会卡一下，导致模拟不精确。我延迟了1s再让UE4 Physics的物理小球下落，距离才正常。而我的静态txt不受影响。

从结果数据看（1s应该下落490单位），在单个重力小球情况下，UE4 Physics的精度不如ParticleToy，从右图可以看出差别还是肉眼可见的，原因有很多，暂且不管这垃圾。

从现在这个情况来看，下一步我准备暂停UE4作渲染端的工作，转Houdini为渲染端。毕竟验证准确性还是很重要的，而且最主要UE4的模拟结果不稳定。哎，这垃圾UE4，真是浪费时间。

承3

换了Houdini，大家都是离线，果然模拟结果稳定了。

在测试场景的情况下，Houdini的RBD Solver（Substeps==20）竟然还没有ParticleTop(以下简称"PToy")（Substeps==1）的精度高，我猜主要原因是PToy用的是double，houdini是float，在高FPS，长时间下这个偏差越发明显。

下一步，PToy添加三角面组成平面，然后实现球体碰撞。

承4

添加了一个三角面(Houdini未可视化)，和质点与面的弹性碰撞。具体细节太多了，而且网上都有。

值得记录的是我的物理推导都是自己来的，所以没出什么太卡住我的问题。本来想用能量守恒，但碰撞中损失的能量不知道怎么算，没有地面材质具体物理模型和碰撞具体分析，算了直接碰后速度Damp。

下一步，1.给质点以斜向上的初速度/力，检验在平地的弹跳结果 2.生成作为高尔夫球场的地形三角面Mesh，然后在Houdini中可视化。

承5

1.斜初速度平地碰撞验证 2.地形生成点云，在houdini简单可视化了一下。

地形生成的算法非常简单，参考realistic-terrain-in-130-lines。由于我想定制化网格大小，所以在原算法基础上稍微改了一下，其实就是"resample"的处理。

下一步：现在只是输出地形点云txt，下一步在PToy端三角化地形，然后验证质点在地形上的碰撞。

（思考：做地形算法，改bug的时候脑子完全陷入意识流状态，不知道是最近太累了还是我脑容量不够了）

承6

（图中小球只是为了可视化质点位置，所以下半部分会穿插）

质点在地形上碰验证完成。

对于80*80的地形上碰撞，我都懒得去生成。可优化地方，优化方案很多，但懒得去做。（虽然当下“大世界”火爆，做这方面似乎也是很有意义的）

但是这个工程叫ParticleToy，主攻点不在大世界和优化上，先放着。

而且有些优化方案也是基于1个particle和地形碰撞的，10000个particle放下来呢？互相碰撞呢？优化方案也许就不同。从这点考虑，先做多Particle相关的事情，而不先优化，也是好的。

下一步：PToy端实现质点“三体问题”，Houdini可视化

承7

三体之前，先2体。加上了万有引力，两球初速度都是向右，但是卫星质量小被捕获了。

然后突然很好奇万有引力的G为什么全宇宙“不变”，结果也长见识了，感觉我们对宇宙还是知之甚少。

下一步：添加碰撞到了之后，卫星黏上恒星，并使用动量守恒计算。（之前碰地板，地板不动，所以不符合动量守恒）

承8

3种情况，月日质量参数：0.1 10，1 1，5 10。

总结：在强者（大质量）面前，弱者只有被吃掉，而且弱者几乎影响不了强者的轨迹；实力相等的情况下，两者会不断周旋；弱者如果提升自己，但如果还是不足以匹敌强者，只能成为强者的“加速燃料”。

速度并不重要，质量才是王道，在足够长的时间下，该发生的总会发生。

下一步：增加模拟时间，然后看一下三体情况

承9

三体特解我虽随便搜了一下，也没找到直接给参数的。然后让太阳不动，按直觉双月参数调了一下，貌似进入一种循环轨道了。怪不得VS图标用无穷符号，星球之间都是这种轨迹啊。

阶段思考

1.接下来干什么 尝试分子键物理建模

2.思考PToy对开发流程的意义，可能是未来的一种趋势。

Houdini和HoudiniEngine对UE4或其他游戏引擎的绑定，还有商业游戏开发越来越“插件堆叠”化，说明了一件事情：游戏行业已经迈入制造工业，流程化，模块化，专业化是必然趋势。

我觉得类似PToy的流程已经在游戏开发中用起来了，只是没有这么夸张而已。为什么今天没有这样？0.硬件成本也太高1.硬件厂在挤牙膏2.传承下来的垃圾架构

可以说，是因为没有共同富裕，而差异化发展又引起了人超前的欲望，整个架构成了“快速实现，能用就行”。短期内实现了人的超前欲望，但是长远眼光下拖慢了发展节奏，给一部分人带来了长久而不可改变（难以改变）的痛苦。

承10

带半径的碰撞检测，比想象中复杂得多，主要是球轨迹->胶囊与三角面判断相交。精确碰撞解算确实复杂，让我想到了有时候Houdini/UE4有时碰撞检测出问题，可能就是换用了粗略的检测手段。

下一步：带g/引力/物理碰撞的两球场景。（之前的太空碰撞规定了消失点和融入点，是完全非弹性碰撞，和一般碰撞有区别）。

承11

带碰撞，重力，万有引力。

还是那句话，实现起来比想象复杂。离散和连续的思维方式混合，处理极限情况...

下一步：分子键

承12

带碰撞，重力，万有引力，“分子键力”

为了克服重力，垂直方向的分子键力得大一点。调整得当，两”分子“间的来回震动会小一些。

启发1：期间又碰到了解算碰撞PBC（Physic Based Collision）的bug，才发现我之前的推导是基于匀加速运动的。而加入分子键力后，这个条件就不一定成立了。

实际上，可以用”匀变“加速运动重新推导，但我暂时不想推导重来，就对不能解方程的情况（就是不能用匀加速运动近似的情况）直接上移，反弹速度。

启发2：让我想起Veritasium的两个视频，严肃向：液体凝固结晶只是齐共振？，搞笑向：分子键之歌

下一步：看看能不能给8个原子搞分子键，形成一个稳定的正方体结构

承13

整个“晶胞”在相对力的作用下像是在呼吸一样。每点有3个分子键力，缺一整体结构就散架。

下一步：让分子键力随时间慢慢减弱，看结果。照理应该是吸在一起（启发：冰融化体积变小也是类似原因？）

承14

下一步：估计得有一段时间以后了。找到一个“实际”需求，然后用PToy开发出来。

阶段思考

1.PToy对开发流程的意义（重思考）

之前我说类似流程已经可能用起来了，结果发现Houdini-Niagara就是一模一样的流程，只不过它把输出文件txt换成了hbjson。

不过这只解决了“模拟”的问题，不解决“渲染”的问题。比如我尝试将Houdini火焰移动效果移植到UE4，这套流程尽管可以支持大量点动画，但还不足以支持“VDB动画”，渲染端只能想办法fake。

2.接下来干什么

光子离线渲染。

UE5出来后，它的渲染流程，包括GI一定是未来TA的“基本要求”。当然这不是我的动力，我主要也对光子渲染比较感兴趣，而且PToy有基本的质点碰撞反弹，改起来应该比较方便。

还有，由于充分考虑了变数和序列化等，现在PToy效率有点低了，像“承14”这种计算已经计算量上去了，往后走有点不敢想象，得做一点优化了。

而光子渲染正好比较简单，光子之间互不影响。考虑上CUDA或者OpenCL。看网上评价关于用户友好，可能CUDA试一下...

承15

考虑到渲染效果和效率，先不上photonMap。先搞软渲rayTrace。rayTrace了个球，相交就往frameBuffer上写红色。

目前还未CUDA加速，也没写材质和光照模型。

我很暴力地将frameBuffer写进txt，然后python用Image转txt到图，不费劲；C++用libpng好恶心。

下一步，上材质，先用blinn-Phong。

承16

Blinn-Phong，看着确实很“欠世代”，有Unity那味儿了。

自己写软渲，有一点好处是对GPU负荷，overdraw等更直观体会，瓶颈会出现在哪，因为算法一样，只不过一个在CPU一个在GPU。

期间意识到Blin-Phong的spec会有“反向穿透”问题，不过对于SDF Trace来说没这问题。

CUDA还是先不上，目前软渲速度还在接受范围内。

下一步，光源换成点光源，光照模型换PBR，加5个面形成房间，多Trace几次，把光追的特性显现出来，看起来好看些。

承17

承18

尝试用常见FFT海面中的Phillip Spectrum公式造型（风速渐大）

合

上图，零碎时间搞了半年多，把PathTrace光追渲染搞好了。但是没有用ParticleToy这套自己写的代码。因为整合CUDA，写自定义并行脚本语言太麻烦，看了一眼Unity的Compute Shader，就决定不造轮子了。

上一个用ComputeShader做的PathTrace图：

鉴于Compute Shader做并行这么方便，ParticleToy做并行就没啥意义了。之后可能就是作为代码范例，算法验证。

“代码范例”是因为C++的OOP和ParticleToy我自己的类，提供了非常直观的命名和调用方式，使得算法思路能一目了然。（比如同样是光追代码，看ParticleToy远比看非常“raw”的ComputeShader好理解多了）

“算法验证”是因为ParticleToy是可扩展但不依赖任何第三方的，就是个控制台程序。所以到不同的工作环境都能改改，跑起来，写点算法验证一下。而且C++断点方便，信息多。（比如同样的SDF-SphereTrace代码，ComputeShader/PS你都没法debug，也不会报错inf或者/0，也没法断点，时不时还出奇怪硬件-relate的问题比如while循环里提前return有时候没用。出了问题只能靠猜。）

至于Particle模拟物理的范畴，ComputeShader可以做MPM。ParticleToy可能会做一些MPM算法验证。

至于渲染方面，ParticleToy可能会关于PBR中Geometry项的推导和扩展。

可以说已经是一大串我个人代码试验的集合，再写文章分享出来也没有太大的意义。以后结合具体的问题再分享另外的文章吧。