渲染地图上地球大小的Minecraft需要什么样的硬件？

我一直在思考这个问题。使用当前技术是否可以在基于体素的游戏中创建地球的1：1复制？存储这张巨大地图的最佳数据结构是什么？应该使用哪种算法实时呈现此数据结构？

这些问题做出以下假设：

• 每个体素的分辨率为1立方米。

• 为了简单起见，每个体素仅需要1个字节的元数据信息。该信息将用于存储识别体素的“类型”（地球，水，岩石等）。

• 土方体积为1 * 10ˆ21立方米。

• 在“当前技术”中，我包括市售的任何东西，但不包括超级计算机。

• 仅将地球地形和测深法用于生成地图。排除人类建筑，植物或洞穴。地下街区将根据地质研究进行选择，例如：如果深度大于3000 km，则渲染“岩浆”体素。

• 就像在《我的世界》中一样，地图不是静态的，可以在游戏中进行修改。

• “无限”的绘制距离是一个很大的优势，如果您不能飞起来观察整个星球，那么将整个地球放在地图上有什么意义呢？

当我想到这个问题时，我得出的第一个结论是，以线性方式存储地球数据是不可行的，假设每个体素仅占用1个字节的内存，那么仍然需要1个零字节来存储地图。因此，需要某种压缩方式。

我认为体素八叉树可以压缩地图，但是我不确定多少。该体素贴图的熵可能很低，因此我猜想可以实现很高的压缩水平。

免责声明

这是一个理论问题，我无意编写体素地球

编辑

ESA GOCE已经以1cm-2cm的精度绘制了大地水准面。我相信这些信息可用于生成非常精确的地球高度图。这样就无需使用算法来填补地球地形中的空白。

这取决于您使用的空间细分方法，尽管由于数据结构开销和其他逻辑/数学因素，所有细分方法（如任何压缩方法）最终都无法进行进一步的压缩。在八叉树中可以找到一个例子。对于八叉树中的每个节点，必须保留指向其父级和/或子级的指针（取决于您处理数据结构的方式），以实现有意义的遍历。任何树结构都可以包含n个孩子。1：n比率越低，您获得的空间使用效率就越高，因此树遍历的开销也越大，因为您必须有更多的祖先节点才能包含相同数量的叶体素（在您的情况下，约为510万亿）其中代表表面积）。

考虑到在您的实例中，主要问题是存储成本并以合理的距离绘制整个星球（或其部分），因此我不建议在八叉树上使用任何数据结构。必须进行Mipmapping：最接近2的较高幂的1280万米直径为2 ^ 24 = 1680万。要遍历24个八叉树，将导致大量分支-对于GPU和CPU而言都非常昂贵。但是，只要您做正确的事，您一次只需要遍历几个级别。但是，鉴于所需的空间量，替代方案很少而且相差很远（见下文）。

八叉树的mipmapping功能是使它成为如此庞大的工具（如您所描述的）的强大工具。与所有其他已知的细分方法（KD树除外）不同，八叉树使每个级别的细分保持最小，这意味着mipmap级别之间的视觉和物理差异也保持最小，这意味着在您向上行走时粒度上的细微差异要大得多。在树上。

另一方面，如果要生成一个层次结构网格遍历保持最小的世界，则需要权衡空间以提高速度。

说到理想的1：n比，在这方面没有比kd树更好的结构。在八叉树为每个轴划分为2的情况下，导致2 ^ 3 = 8个单独的子单元格，而kd树在每个细分级别精确地分裂一次。这样做的问题是，您必须选择一个要分割的超平面，并且可以围绕3个轴中的任何一个选择该超平面。尽管就空间而言它是最佳的，但它却使3D遍历（例如在raymarches期间，使用八叉树进行物理或渲染时的基本操作）比八叉树困难得多，因为必须保留动态门户类型的结构来进行记录各个kd树节点之间的接口。

RLE是另一种压缩方法，但是由于RLE压缩是一维的，因此您必须选择在其中运行的轴。行星，可能会选择极轴，但是任何单轴选择都将在从某些非最佳角度作用时为渲染和物理引入遍历问题。当然，您也可以同时在3个轴上运行RLE，使存储成本增加三倍，或者在6个轴（-x，+ x，-y，+ y，-z，+ z）上运行RLE，以进一步优化。

因此，回答您的问题（或不回答！）

我不会直接回答什么样的硬件，但我认为从八叉树的角度来看它会开始让您了解实际上在哪种硬件上可能会发生什么。我鼓励您走这条路，如果您真的想知道，实际上实现一个简单的稀疏八叉树可能是最容易的（请参阅参考资料中的莱恩的论文），然后在其中放置一个表面体素的球形外壳，并查看由此产生的空间使用情况。从那里站起来。看看在系统内存开始释放之前您能得到多少。除非您需要可视化，否则不需要编写渲染器。还请记住，最好在CPU上完成此操作-GPU大体上没有处理这种规模问题的内存容量。这就是英特尔希望转向大规模并行处理器的原因之一：GPGPU的优势（在这种情况下更胜一筹）可以应用到更广阔的内存空间，而无需应对系统总线瓶颈。在此或mathematics.stackexchange.com上可能还有其他内容，

当然，就无限远视距离的要求而言，但问题总是归结为“在什么距离下有多少细节”。渲染无限的细节将需要无限的资源。这就是每个场景可变mipmapping发挥作用的地方。还请记住，所有数据结构都体现了一定的空间速度权衡，反之亦然。如果您希望在相同的工程量下拥有更大的空间，则意味着更少/较慢的渲染。

当我想到这个问题时，我得出的第一个结论是，以线性方式存储地球数据是不可行的，假设每个体素仅占用1个字节的内存，那么仍然需要1个零字节来存储地图。因此，需要某种压缩方式。

由于您极有可能永远无法找到现实世界中每个立方米的属性，因此您将需要某种方式来生成基于假设不确定的数据。因此，如果您确定了这一点，就无需计算和存储所有数据，而可以即时生成它。

首先，您可以丢弃地球上的所有体素，因为仅当有人实际挖洞时才需要计算这些体素。体素变得可见。

对于地球表面，我可能会以图像作为计算的起点。也许某种温度和湿度图可以让您计算要应用的图块类型。例如。水，沙（沙漠），草，雪等。由于图像可能不会对地球每平方米提供一个像素的信息，因此您必须将其与一些噪声混合在一起才能在图像上产生一些变化。表面。如果您始终使用相同的随机种子，那么您的结果应该是确定性的。

另外，高程图将很有用，以便您可以确定曲面特征的高度。这样，您可以添加山脉等。

因此，这归结为一些2D图像的数据量，其中包含有关地球表面的信息。对于内部的所有内容，您都将恢复为纯程序性方法，根据距地球中心的距离，您可以渲染不同类型的块。但是如上所述，这些值仅在有人挖洞时才需要计算。

为了使更改持久化，我只会保存对世界的修改。因此，如果有人挖了一个洞，我将存储有关已删除哪些体素的信息，因为我应该能够按程序渲染周围的体素。

至于渲染：您将需要一些复杂的细节级别和剔除算法来完成这项工作。当相机处于显示整个世界的缩放级别时，渲染所有表面体素是愚蠢的。在这个级别上，体素应该更大，也许即使是简单的纹理球体也足够了。

我想最棘手的事情是拥有一个固体生成器，该生成器甚至可以针对不同的“分辨率”来计算体素属性，以便您可以使用它生成不同级别的细节。

您基本上可以执行与Minecraft相同的操作。无需制作大量数据，您可以将世界定义为数学公式，每当需要显示一条数据时，您都可以使用公式生成该数据。

这样的公式通常是使用Perlin噪声的概念构造的，这允许在各个级别上都有详细信息，您可以拥有与真实世界一样大的山脉，而只选择生成其中很小的一部分。您可以生成自己喜欢的细节量，因此可以为近距离细节制作非常精细的细节，同时还可以在所需的细节层次上生成远景。

Minecraft会保存您访问过的所有这些块，并进行任何更改，只需保存已生成世界和更新后世界之间的差异即可，但是我想保存大块会更容易，并且它们的压缩效果也相对较好。

我认为没有任何游戏能真正达到极限，但是使用公式化生成大型游戏世界中所有“不重要”细节的情况非常普遍。我不知道何时生成所需的方法有多普遍，而不是简单地生成批量并将其放到光盘上。

您可以查找地球陆地的矢量数据，因为矢量数据具有可缩放至所需比例的优势。将其与地球的高度图结合以生成地形的高度。最后一步是一些详细的卫星图像，您可以从中根据图像选择顶部区块的类型，这样就可以在有岩石的地方得到岩石，在有沙子的地方得到沙子，等等。可能应该生成行星的实际内部就像Minecraft一样，除非您可以找到要使用的详细地理数据。基本上，您想要做的就是找到地理数据，并从中推断出数据，仅给出XYZ坐标输入。这意味着您的数据有限，您可以尽可能精确地推断其余数据。