Today

• Acceleration 加速结构：使用AABB来加速光线追踪
  • Uniform grids
  • Spatial partitions
• Basic radiometry（辐射度量学）
  • 进阶：不同于Whitted-Style的光线追踪

光线追踪加速结构

均匀网格方案：Uniform grids

预处理：构建加速网格

找一个包围盒，在包围盒中构建均匀网格，记录每一个与物体相交的网格

光线与场景求交

射出一道光线，让光线与格子求交，若格子内存在物体，再让光线与物体求交：光线与格子求交是快速的，而与实际物体求交是很慢的，通过这样的理念来优化

经验告诉我们

当格子数等于C * 对象数时，结果会比较好；三维空间下常数C可以取27

缺陷

当细节物品在空间中分布不均匀时，存在大规模集中、大规模空白：”Teapot in a stadium” problem

*在一些场景下还是好用的，仍有在使用

空间划分 Spatial partitions

参考

1. unity documentation-Scripting restrictions 2018.4
2. unity documentations-Scripting restrictions 2022.3

内容相差不大，2022.3在2018.4的基础上做了一些补充，并去除了一个关于泛型虚方法例子。

Ahead-of-time编译（AOT）

一些平台不允许运行时的代码生成（运行时开辟内存用于存放可执行的机器指令）。因此，一切依赖于just-in-time（JIT）的托管代码（managed code）在这些平台上都无法运行。为此，你需要把所有的托管代码都进行AOT编译。在一般情况下，这个限制不会带来什么影响。但在AOT编译的平台上，也存在着一些需要额外注意的要点。

翻译自Godot引擎贡献指南，原文：best_practices_for_engine_contributors

#1 问题总要放在第一位

许多代码贡献者非常的有创造力，他们享受设计抽象数据结构，搭建优秀的交互界面的过程，又或许他们只是单纯地热爱编程。代码贡献者们总是有一些很酷的想法，但这些想法或许能、或许不能解决真实的问题。

这就被称为寻找问题的解决方案。在理想的世界，它们也许并不有害，但在现实世界中，代码是需要时间去完成的，它们占用空间，而且一经存在就需要时间去维护。避免一切不必要的事物，在软件开发中一直被视作一种好的实践方式。

TableCraft is finally here!

TableCraft 发布！

从21年起经过两年断断续续的开发，TableCraft终于发布了v1.0.0版本，并开始提供给项目组同事使用了。这篇文章会介绍从最初立项到最终发布TableCraft的设计发生了怎样的变化，TableCraft现阶段存在的一些问题，以及未来的发展目标。

第四章 类型基础

4.1 所有类型都从System.Object派生

GetHashCode() 与 Equals()

如果对象要在哈希表集合中用作键使用，那么应该重写GetHashCode方法；如果两个对象具有相同的值，那么Equals应该返回true。

Object类的Equals和GetHashCode具体实现都是internalcall，由CLR实现，Equals源码实现可参考以下：