如何优化我的自定义地图格式 (Java)
我正在创建一个 3D 游戏，其中有一个使用高度图的大型开放世界（200×200 公里）。我将高度图划分为 200×200 = 40,000 个 1000×1000 米的区域，然后将它们再次划分为 20×20 = 400 个 50×50 米的块。高度图是从 PNG 文件生成的。
我正在考虑存储地形的方法。我尝试过一些方法，但它会生成每个区域约 16MB 的文件，这对于全世界（40,000 个区域）来说是 640GB。
可以在此处找到区域文件的示例： http://updo.nl/file/e10ce974.umap
我的问题：如何紧凑地存储区域文件里有这么多信息，以后再读？
I'm creating a 3D game where I have a large open world (200×200 kilometers), that uses a heightmap. I divide the heightmap in 200×200 = 40,000 regions of 1000×1000 meter, and those are again divided in 20×20 = 400 chunks of 50×50 meter. The heightmap is generated from a PNG file.
I am thinking about ways of storing the terrain. I have tried something, but it generates files of about 16MB per region, which is 640GB for the whole world (40,000 regions).
An example of a region-file can be found here:
http://updo.nl/file/e10ce974.umap
My question: how can I compactly store so much information in region files and read them later?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果每个坐标的值通常不同并且不同的方式不可预测，则高度图是存储信息的有效方法。换句话说，当您处理随机数据时，高度图非常有效。如果您的数据存在某种模式，通常会有更好的解决方案。
考虑
y = x< 描述的行/a>.您可以使用分辨率为 1 的高度图来描述该坡度，类似于[(1, 1), (2, 2), (3, 3), ...]。如果高度图具有高分辨率，则该列表将会非常大。或者，您可以将该斜率描述为穿过点 (1, 1) 和 (2, 2) 的线。在这种情况下，通过特定点/顶点定义线/体积要高效得多。对于类似地形的数据，由于它通常是非随机的，我建议通过多边形网格。您可能会发现像 JMesh 这样的库可以使用。
为了进一步阅读，这里是一个很好的答案（坦率地说，比我的要好得多）在与此主题相关的游戏开发堆栈交换中。
Heightmaps are an efficient method of storing information if the values are typically different at each coordinate and the way the way are different is not predictable. In other words, heightmaps are efficient when you are working with random data. If there is a pattern to your data, there is usually a better solution.
Consider the line described by
y = x. You can describe this slope with a heightmap of resolution 1, which would be something like[(1, 1), (2, 2), (3, 3), ...]. If you heightmap has high resolution, that list will be very large. Alternatively, you could describe that slope as the line that goes through the points (1, 1) and (2, 2). Defining a line/volume via particular points/vertices is much more efficient, in this case.For terrain-like data, since it typically non-random, I would recommend the second approach via polygonal meshes. You might find a library like JMesh of use.
For further reading, here is a great answer (way better than mine, frankly) on the Game Development Stack Exchange related to this topic.
一些 2D FFT 怎么样？
http://fourier.eng.hmc.edu/e101/lectures/image_processing /node6.html
http://paulbourke.net/miscellaneous/dft/
How about some 2D FFT?
http://fourier.eng.hmc.edu/e101/lectures/image_processing/node6.html
http://paulbourke.net/miscellaneous/dft/