jxwr's blog

修复了resize和静态模型渲染，但是picking挂了。

试一下ImGui的Docking分支，非常的傻瓜，调整了一下调试窗口的布局，稍微有点样子了。

不过，按原计划，该写一点AI代码了，但是很想把CG的代码彻底重构一遍。发觉如何做好代码设计，前提是对流程都清楚，所以第一次切入一个陌生领域，最好写一遍平铺直叙的垃圾代码，是有助于理解概念的，上来做设计未必能得到效果，直接参考现成设计又无法理解设计的本意。昨天读了Esoterica的Render部分的代码，似乎挺教科书的。

发觉好久没记录了，但并没有一直停滞，偶尔时间空档就写一点。前段时间在写PRB渲染，研究了一段时间理论和数学公式，写完之后在写动画。

端午第二天写了半天之前写了一半的动画代码，因为理解错了gltf中inverseBindMatrix和jointMatrix数组索引导致很长时间未能正常渲染，以为inverseBindMatrix的索引就是node_index，其实应该是skin.joints数组的索引。

接下来想花点时间研究一下imgui的菜单和Layout，控件多了以后UI特别乱。不过最近有些忙，原计划的上半年完成图形学基本入门应该大体差不多完成，最早没懂的Texture、Material、Shader、Mesh之间的关系自己实现一遍自然就懂了，实现了基本的Camera、Picking、PBR渲染、Skeletal Animation，可以渲染非常逼真的模型，学PBR又复习了一遍概率论，只是代码6月底之前没时间重构了。

疫情严重了。

把light随便找了个sphere画出来了。

支持了坐标轴和包围盒渲染，支持UI控制位置和灯光，代码结构做了优化，改了项目名。整体还不错。

下一步要把Light和Camera的位置显示出来。

红码了，只能宅家。最近不太平，写码修心。

为了换成Linux环境，买了一台二手Thinkpad P50，几乎全新，非常满意。

前些天闲时看了Nanite的视频和相关资料，相当震撼，virtual texture之后virtual geometry也搞定了，下一个大话题是什么呢，似乎Nanite没解决animation的问题。

周五忘记在哪看到Gaea发布了新版本，看了看功能，感觉很有趣，正好在愁下一步要写点什么。打算模仿Gaea写一个Procedural Terrain Generator，估计可以很快接触到渲染大型Mesh遇到的诸多问题。

傍晚新建工程开始写，写的异常顺利，最初只渲染了mesh，后来发现下载的资源里有个bitmap的贴图又做了顶点着色。

最近没写代码，工作上事情较多，空闲时看一些光照模型的资料。翻了两遍《3D数学技术》和《全局光照算法技术》中光照有关的数学内容，又看了而一些PBR有关的资料，原理差不多都搞清楚了。《3D数学技术》这本书写的真不错，精读了前十章。

另外把概念差不多区分开了，不确定CG专业领域怎么区分，按目前的认识，lambert、blinn-phong、phr都是着色模型或者光照模型，ray/path tracing和rasterization是基于这些模型渲染到图像的技术，ray tracing用于离线渲染，path tracing用于实时渲染。经典光照模型就是环境光(ambient)、漫反射(diffuse)、镜面反射(specular)的组合，PBR是另一套基于光物理的模型，二者需要的材质模型不同，需要各种类型的贴图，贴图需要美术基于低模生成高模再烘焙出来。还有一个叫MatCap的有趣技术，是用View坐标系下的法向量作为uv坐标和一张球型的材质贴图实现的着色技术，性能开销低，但是不能响应灯光位置。光照模型这块有太多高级主题，例如阴影、菲涅尔效应等等，暂时不打算细看了。

差不多明朗了，接下来还是回到代码，先把imgui集成进来。

上周末把代码重写了，集成了v8，粗略做了点设计，比之前顺畅多了。最近看了不少资料，尤其是翻了Bitsquid和OurMachinary的Blog，看了一遍Stingary的代码串讲视频，理解起来不吃力，但怎么自己按Command List的思路基于OpenGL组织代码想了一下没想清楚，跟对OpenGL的API不熟悉有关系，目前用的还都是“Naive Loop”的写法，没有任何Batch，左右资源和bind都是per mesh的。另外，对Material和Shader、Mesh、Texture的关系还没理解透彻。得拿一些具体的例子，渲染一下复杂场景才行。

NVIDIA的OpenGL资料都挺好的，不过稍微读一读资料就发觉，不论是engine还是driver，都把基于Command List的Data Oriented的渲染方式作为性能优化手段，而OpenGL如果要支持这种风格，必须要用扩展，但是OpenGL的扩展是比较乱且不一致的，加上苹果已经禁用了OpenGL，Vulkan已经（基本？）成熟，让基于OpenGL考虑高性能设计有点显得徒劳（虽然我并不真的在意性能），所以我在考虑，要不要切到Vulkan，但我现在没有一台PC。

另，掌握OpenGL基础之后，想要精进读这篇《Approaching zero driver overhead（AZDO）》似乎就够了。

看了一天TI11比赛，LGD首日表现极差，看得郁闷。计划还是学一下贴图、光照、材质，然后再搞骨骼动画，都通了再搞物理。仍是先自己摸索，再看标准做法，费点事，但是训练一下数学思维。

用assimp重写了模型加载代码，导致之前随便写的代码更乱了。下载了个有骨骼动画的模型，加载了包含diffuse、emission、specular的材质贴图，自己胡乱加减乘除出来一个勉强可看的光照渲染效果。最开始贴图贴上去不对，仔细对比发现不知道为什么贴图和原图比在Y轴上是反的，需要(1 – vex_coord.y)变换一下贴图坐标的y分量才行，花了好长时间，莫非是因为左右手坐标系的问题？没注意模型文件里是不是有坐标系的描述。

接下来摸索法线贴图的原理，然后要停下来把代码重写一遍。大概是时候认真设计一下场景、实体这些东西的数据结构，考虑如何构建基本的pipeline，支持操作模型移动旋转，然后支持UI查看编辑实体属性、帧率等调试信息。一个简单的CG程序就不太好写，涉及到的对象太多，Entity、Mesh、Vertex(Positions/Indices/Normal/TexCoord)、Texture(Texture Unit, Texture)、Material、Shader、Antimation、Bone、Camera、SceneGraph之间的关系都要理清楚，还要考虑如何组织OpenGL接口的调用，正确且清晰的处理缓存数据和状态，另外稍微有点用的程序还需要支持扩展，支持编写实体的游戏逻辑。

最近处于窗口期，抽空看了点游戏引擎和游戏开发相关的资料。

在琢磨游戏行业是否像互联网行业（这里可以特指电商）一样，进入了一个技术成熟期，大部分从业者基于成熟的组件、按成熟的套路做一些逻辑开发，剩下的留给管理，行业客观上已经低端化了。想看看游戏行业在架构方法、开发模式、发展方向上有没有什么可以启发的。

还没想通，隐约觉得有些类似，区别在于大型游戏一般是绑定在某个私有引擎之上，互联网技术是基于许多开源组件，没有严重的捆绑。另外如电商系统的开发，不论团队还是系统，天然是服务化和分布式的，这种开发模式是否适用于大型游戏的开发？不太了解大型游戏的实际开发过程，粗想没问题，无非是个模块划分的问题。

我好奇的是：一个成熟的工业级的游戏引擎本身（而非其上的游戏）是否可以按互联网公司的做事套路，拉一个大规模的团队，做好顶层设计，拆分成一堆独立的小组，依靠执行力，在一到两年的时间里，完成一个功能完备可用、有竞争力的产品。

我实际好奇的是：互联网公司的开发套路，对于一个技术含量很高的产品，是否也可行？例如，是否能通过将系统拆分成数百个模块，配备几十个团队，一两千人，在一定周期内，复刻一个UE出来？我们可以假设每个单点Feature都有团队负责且能够攻克（不用原创，仅实现），也假设引擎的Kernel部分和整体架构有能力搭建，在这个基础之上，是否能将其拆分成可以规模化的劳动密集型的工作。

打算一边写些代码了解引擎整体架构，一边想问题的答案。白天顺着这个思路想，打算初期就按服务化方式写起：

• 最核心的是3D数据对象的数据结构和API，算是Model。
• 渲染服务用C++写，仅做Rendering，基本是个只读的进程，不会更新Model，算是个View。用Blender的话说，是一个”struct visualizer“。
• 游戏逻辑和场景对象更新包括EditorUI用Electron试试看，算是Controller，这里的UI还算不上是View。
• Controller和View之间通过网络交互，可能对象多了以后性能是个问题，不过允许逻辑分布在不同节点，有会有很多其他可能性。这是不是网游的思路？有没有游戏引擎是按网游的思路设计的，例如支持多人协作编辑大规模场景会不会更友好。（育碧的scalar似乎在探索这个方向）

另，发现MVC是个很天然的模式，其实不需要谁来提出。