如何把现实城市搬进 MinecraftArnis 地理数据转世界流水线深度解析【免费下载链接】arnisGenerate any location from the real world in Minecraft with a high level of detail.项目地址: https://gitcode.com/GitHub_Trending/ar/arnisArnis 是一个地理数据转 Minecraft 世界的转换引擎读取 OpenStreetMap 矢量与数字高程数据逐方块输出 Java 版、基岩版或 LuantiMinetest世界。引擎用 Rust 编写附带 Tauri 桌面图形界面也支持纯命令行模式。本文拆解它的坐标转换、元素处理流水线以及大区域生成背后的工程取舍。从椭球到方块网格需要补上的三层差距输入数据有两种形态OpenStreetMap 矢量对象道路是 way建筑是闭合多边形各带一组键值标签和高程瓦片提供地表高度。但方块世界只认一件事(x, y, z) 处放什么方块。中间隔着三层差距。一是坐标系。经纬度在椭球面上方块坐标在平面网格上一度在不同纬度对应的米数不同。二是语义。highwayresidential标签要变成有宽度、有材质的路建筑多边形要拉伸成带墙和屋顶的立体。三是规模按 1 格对应 1 米计算10×10 km 的区域就有 10⁸ 量级的列整世界一次性放内存对普通机器不可行。Arnis 的做法是逐层解决坐标模块管映射元素流水线管语义世界编辑器管写入。坐标转换一个转换器里的两种投影整套坐标系集中在src/coordinate_system/核心是transformation.rs里的CoordTransformer输入是地理边界框与比例尺每米对应几格输出是世界边界框和逐点转换能力。内部有两条投影路径。Local 模式做线性插值用半正矢公式算出边界框的米数长宽乘比例尺再按点在框内的相对位置线性插值。速度快小区域误差可控。WebMercator 模式改用球面墨卡托投影以边界框中心为原点保证 x 随东向增大、z 随北向减小大区域和高纬度下形变明显更小。世界边界框不是简单拉伸角点算出来的WebMercator 模式把四个角都投影后取轴对齐包络保证框内任意点都不会落到世界范围之外。图形界面里用户在地图上画一个矩形框选区域就是靠这个模块换算出对应的方块范围。元素流水线与世界写入输入、处理、输出主流程在main.rs取数、解析、分派、写入。取数阶段用std::thread::scope并行跑三个任务——OpenStreetMap 查询、Overture 建筑数据、高程与地表覆盖——总耗时取决于最慢的一个而不是三者之和。解析阶段把原始 XML 变成带优先级的处理元素基础类要素比如道路先于建筑处理。分派阶段在src/element_processing/按要素类型一个文件一个职责buildings.rs做拉伸与立面highways.rs做中心线与宽度参数化water_areas.rs、natural.rs分别管水体和植被。每个模块只负责自己那类元素→方块的实现。写入阶段在src/world_editor/。common.rs维护 region、chunk、section 三层组织的世界数据结构java.rs、bedrock.rs、luanti.rs各自序列化成对应格式。版本间方块差异靠映射表解决bedrock_block_map.rs与luanti_block_map.rs分别把 Java 方块名翻译成基岩版和 Luanti 的名字后者派生自 MC2MT 项目LGPL文件头保留了署名。开发者也可以完全不用图形界面。克隆仓库git clone https://gitcode.com/GitHub_Trending/ar/arnis编译后直接指定经纬度框生成cargo run --release -- --output-dir存档路径 --bboxmin_lat,min_lng,max_lat,max_lng大区域生成的工程细节分块并行。src/tile.rs把世界切成 512×512 的瓦片——正好一个 Minecraft region且按 region 边界对齐——每块四周再留 64 格光晕避免跨界元素被裁掉。每块有自己的WorldEditor实例处理完按严格边界合并回主世界线程之间互不冲突。泛洪填充预计算。多边形填充是热点。src/floodfill_cache.rs先把所有填充并行算完、结果缓存主循环只做取用。缓存用位图存坐标每列 1 bit相比 HashSet 每条目约 24 字节内存省约 200 倍超大的闭合环直接放弃填充防止单个森林多边形把内存吃光。确定性与流式写盘。并行带来一个麻烦同一元素可能在不同瓦片里被处理多次随机值必须跨次一致。src/deterministic_rng.rs用元素的 OSM ID 给 ChaCha8Rng 播种同一元素无论在哪、按什么顺序处理拿到的随机颜色与样式都相同。同时WorldEditor支持流式写盘region 序列化后交给后台线程落盘、从内存中移除峰值内存取决于驻留 region 数而不是世界总大小。再配合 mimalloc 分配器和 90% CPU 上限的线程池这些是普通桌面机也能完成中等规模城市生成的原因。适用边界与展望项目对自身规模边界说得比较直白生成开始时若换算面积超过 250 平方公里会打印警告——耗时与内存都会上一个量级大查询还会给公共 OpenStreetMap 与高程服务带来真实负载。合理用法是先小区域验证效果再逐步扩大。功能完整度因平台而异物品框招牌路牌、象形图标、海报只写入 Java 版世界基岩版与 Luanti 输出的装饰细节更少--mode提供完整生成、仅对象平地面、纯地形三档便于单独测试地形或做对比。演进方向可以从代码结构推断元素流水线已按类型拆分新增一类要素就是新增一个模块文件投影抽象在 trait 后面接入新投影不难。真要覆盖更大范围路径是分布式生成或浏览器端服务——作者已推出对应的云端生成产品——而不是压榨单进程。对想把真实地理→方块世界这件事做扎实的开发者Arnis 给了一份可以通读的实现参考问题切分干净取舍写进代码注释没有玄学。【免费下载链接】arnisGenerate any location from the real world in Minecraft with a high level of detail.项目地址: https://gitcode.com/GitHub_Trending/ar/arnis创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
如何把现实城市搬进 MinecraftArnis 地理数据转世界流水线深度解析【免费下载链接】arnisGenerate any location from the real world in Minecraft with a high level of detail.项目地址: https://gitcode.com/GitHub_Trending/ar/arnisArnis 是一个地理数据转 Minecraft 世界的转换引擎读取 OpenStreetMap 矢量与数字高程数据逐方块输出 Java 版、基岩版或 LuantiMinetest世界。引擎用 Rust 编写附带 Tauri 桌面图形界面也支持纯命令行模式。本文拆解它的坐标转换、元素处理流水线以及大区域生成背后的工程取舍。从椭球到方块网格需要补上的三层差距输入数据有两种形态OpenStreetMap 矢量对象道路是 way建筑是闭合多边形各带一组键值标签和高程瓦片提供地表高度。但方块世界只认一件事(x, y, z) 处放什么方块。中间隔着三层差距。一是坐标系。经纬度在椭球面上方块坐标在平面网格上一度在不同纬度对应的米数不同。二是语义。highwayresidential标签要变成有宽度、有材质的路建筑多边形要拉伸成带墙和屋顶的立体。三是规模按 1 格对应 1 米计算10×10 km 的区域就有 10⁸ 量级的列整世界一次性放内存对普通机器不可行。Arnis 的做法是逐层解决坐标模块管映射元素流水线管语义世界编辑器管写入。坐标转换一个转换器里的两种投影整套坐标系集中在src/coordinate_system/核心是transformation.rs里的CoordTransformer输入是地理边界框与比例尺每米对应几格输出是世界边界框和逐点转换能力。内部有两条投影路径。Local 模式做线性插值用半正矢公式算出边界框的米数长宽乘比例尺再按点在框内的相对位置线性插值。速度快小区域误差可控。WebMercator 模式改用球面墨卡托投影以边界框中心为原点保证 x 随东向增大、z 随北向减小大区域和高纬度下形变明显更小。世界边界框不是简单拉伸角点算出来的WebMercator 模式把四个角都投影后取轴对齐包络保证框内任意点都不会落到世界范围之外。图形界面里用户在地图上画一个矩形框选区域就是靠这个模块换算出对应的方块范围。元素流水线与世界写入输入、处理、输出主流程在main.rs取数、解析、分派、写入。取数阶段用std::thread::scope并行跑三个任务——OpenStreetMap 查询、Overture 建筑数据、高程与地表覆盖——总耗时取决于最慢的一个而不是三者之和。解析阶段把原始 XML 变成带优先级的处理元素基础类要素比如道路先于建筑处理。分派阶段在src/element_processing/按要素类型一个文件一个职责buildings.rs做拉伸与立面highways.rs做中心线与宽度参数化water_areas.rs、natural.rs分别管水体和植被。每个模块只负责自己那类元素→方块的实现。写入阶段在src/world_editor/。common.rs维护 region、chunk、section 三层组织的世界数据结构java.rs、bedrock.rs、luanti.rs各自序列化成对应格式。版本间方块差异靠映射表解决bedrock_block_map.rs与luanti_block_map.rs分别把 Java 方块名翻译成基岩版和 Luanti 的名字后者派生自 MC2MT 项目LGPL文件头保留了署名。开发者也可以完全不用图形界面。克隆仓库git clone https://gitcode.com/GitHub_Trending/ar/arnis编译后直接指定经纬度框生成cargo run --release -- --output-dir存档路径 --bboxmin_lat,min_lng,max_lat,max_lng大区域生成的工程细节分块并行。src/tile.rs把世界切成 512×512 的瓦片——正好一个 Minecraft region且按 region 边界对齐——每块四周再留 64 格光晕避免跨界元素被裁掉。每块有自己的WorldEditor实例处理完按严格边界合并回主世界线程之间互不冲突。泛洪填充预计算。多边形填充是热点。src/floodfill_cache.rs先把所有填充并行算完、结果缓存主循环只做取用。缓存用位图存坐标每列 1 bit相比 HashSet 每条目约 24 字节内存省约 200 倍超大的闭合环直接放弃填充防止单个森林多边形把内存吃光。确定性与流式写盘。并行带来一个麻烦同一元素可能在不同瓦片里被处理多次随机值必须跨次一致。src/deterministic_rng.rs用元素的 OSM ID 给 ChaCha8Rng 播种同一元素无论在哪、按什么顺序处理拿到的随机颜色与样式都相同。同时WorldEditor支持流式写盘region 序列化后交给后台线程落盘、从内存中移除峰值内存取决于驻留 region 数而不是世界总大小。再配合 mimalloc 分配器和 90% CPU 上限的线程池这些是普通桌面机也能完成中等规模城市生成的原因。适用边界与展望项目对自身规模边界说得比较直白生成开始时若换算面积超过 250 平方公里会打印警告——耗时与内存都会上一个量级大查询还会给公共 OpenStreetMap 与高程服务带来真实负载。合理用法是先小区域验证效果再逐步扩大。功能完整度因平台而异物品框招牌路牌、象形图标、海报只写入 Java 版世界基岩版与 Luanti 输出的装饰细节更少--mode提供完整生成、仅对象平地面、纯地形三档便于单独测试地形或做对比。演进方向可以从代码结构推断元素流水线已按类型拆分新增一类要素就是新增一个模块文件投影抽象在 trait 后面接入新投影不难。真要覆盖更大范围路径是分布式生成或浏览器端服务——作者已推出对应的云端生成产品——而不是压榨单进程。对想把真实地理→方块世界这件事做扎实的开发者Arnis 给了一份可以通读的实现参考问题切分干净取舍写进代码注释没有玄学。【免费下载链接】arnisGenerate any location from the real world in Minecraft with a high level of detail.项目地址: https://gitcode.com/GitHub_Trending/ar/arnis创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
