如果你点开 Matterport3D Simulator 的 GitHub 仓库，会发现README.md第一行写着“Ubuntu 16.04 / macOS 10.11+”，没有任何 Windows 的字样。但做 Vision-Language Navigation 研究的同学，很多主力机就是 Windows。我属于那种“明知官方没支持，偏要装到 Windows 上跑通”的人。前面两篇记录了 Conda 环境准备和基础依赖折腾，这篇是第三篇，核心就是 Windows 下编译 Matterport3D Simulator 全过程的排坑记录。整篇按“源码准备 → CMake 配置 → 编译报错拆解 → 数据放置 → 运行验证”这条完整链路来讲，所有命令和报错都是我在 Windows 11 + VS2017 + CUDA 11.3 环境里实际跑出来的结果。
1. 为什么 Windows 下编译 Matterport3D 会变成一场持久战
首先要认清一件事：Matterport3D Simulator 本身是个 2016 年开源的老项目，当时的开发环境是 Ubuntu + 老版本 CUDA + 老版本 OpenCV。它依赖的 Pangolin、OpenCV、CUDA 库版本都卡在特定历史节点，任何一项版本新了旧了都有可能出问题。Windows 下编译它，本质是“用当代工具链去编译一个没考虑过 Windows 的老 C++ 项目”，所以所有坑都集中在三处：编译工具链的兼容性、基础库版本匹配、以及源码里隐含的非跨平台假设。
网上相关的中文资料不算多，而且很多零散地分布在各种问答评论区。我写这篇，就是想把它一次性整理清楚，尤其把“为什么这么配”讲明白，而不是只丢几条命令。比如 VS 版本的坑：Matterport3D 源码里用了ssize_t、_wfopen_s这类函数，VS2015 和 VS2017 的处理方式都不一样，选错版本会出现大量莫名其妙的 C++ 编译错误。我最终用的是 VS2017，后面会解释理由。
另外还要明确一点，Windows 下编译 Matterport3D Simulator 并非官方支持的路径，所以不要期望cmake ..能一次通过。整套流程实际上分四步：拉源码、配依赖、编核心、验数据。前两步决定你能不能走到编译那一步，后两步决定你能不能真正跑出仿真画面。每一步都有那种“让人抓狂但真相特别简单”的坑。这一篇会把四个阶段的问题全部过一遍，能帮你把总耗时从三五天压缩到半天以内。
2. 源码获取与目录结构里的隐性约定
2.1 拉取源码前先想清楚数据放哪
Matterport3D Simulator 运行时有非常明确的目录依赖，它要求场景数据、元数据文件和编译出来的可执行文件遵循固定相对路径。如果你之前已经申请过 Matterport3D 数据集，手头会有三个东西：matterport_metadata目录（包含各 scene 的 house 文件、图像位姿等）、scans目录（存放下载的未压缩 scene 数据）、以及一个downloader.py下载脚本。这个matterport_metadata不是模拟器源码仓库的一部分，而是独立仓库https://github.com/niessner/Matterport，通常要把它 clone 到模拟器仓库的同级目录，仿照如下结构存放：
E:\VLN\ │ ├── Matterport3DSimulator\ │ ├── build\ │ ├── CXX\src │ ├── ... │ └── matterport_metadata\ ├── downloader.py ├── matterport_metadata\ │ ├── house │ ├── matterport_skybox_images │ └── ...这个结构的隐性约定在于：Matterport3DSimulator的可执行程序编译后，会在运行时去读取../../matterport_metadata这样的相对路径。如果你把matterport_metadata放到别的位置，编译正确也照样跑不起来。我是踩过两次这个坑后，才彻底养成“先规划目录、再拉代码”的习惯。
2.2 Clone 命令里的 Windows 专属陷阱
官方 README 建议用git clone --recursive https://github.com/peteanderson80/Matterport3DSimulator.git，但 Windows 上直接执行这条命令，Pangolin 这个子模块大概率出问题。Pangolin 在 Windows 下有自己的符号链接文件，而 Git for Windows 默认并不启用符号链接支持。结果就是 clone 下来的 Pangolin 目录不完整，编译时连头文件都找不到。
解决方法是先关闭core.symlinks再 clone，或者 clone 之后把子模块目录删掉重新拉。我的做法是：
git clone https://github.com/peteanderson80/Matterport3DSimulator.git cd Matterport3DSimulator git submodule update --init --recursive如果 Pangolin 目录里出现大量只有几字节的“文本文件”，那就是符号链接坏掉了，需要先跑：
git config core.symlinks false git submodule deinit -f Pangolin git submodule update --init --recursive Pangolin另外建议把源码放在盘符根目录附近、路径中不要带中文和空格。Matterport3D 的 CMakeLists 和自己的 C++ 代码对于 long path 支持很差，某些依赖库的 CMake 脚本在路径过长时会直接不生成项目文件，报错信息还不直白。Windows 的“启用长路径支持”策略对部分第三方库无效，别在这种地方浪费时间。
2.3 必须准备的基础依赖
编译 Matterport3D Simulator，核心依赖有四样：CUDA、OpenCV、Pangolin、以及一个 C++11 支持的编译器。Windows 下比较稳的组合是：
- Visual Studio 2017（v141 工具集），原因后面单独说
- CUDA 10.x 或 11.x，我测试时用 11.3 是能编过的
- OpenCV 3.4.x，4.x 版本接口变动过大，源码里大量函数直接编译不过
- 如果要用
test_scene或show程序，可能还需要 FreeImage，不过它通常可以直接去掉
Pangolin 作为子模块会随源码一起拉到本地。它本身对 Windows 支持不算好，需要自己在 CMake 阶段做一些处理，我是在配置阶段的“关闭 Pangolin 的音频和视频捕获模块”来规避问题的。如果某个依赖版本不对，整个过程会在非常后期才报错，比如链接matterport可执行文件时出现上百个 unresolved external symbol，那时候再去翻版本就非常痛苦。所以我在编译前把基础库版本统一成一个清单，避免边编边试。
| 依赖 | 推荐版本 | 备注 |
|---|---|---|
| Visual Studio | 2017（v141） | 对老项目兼容性最好 |
| CUDA Toolkit | 10.2 或 11.3 | 需要匹配 NVIDIA 驱动 |
| OpenCV | 3.4.10 ~ 3.4.16 | 4.x 不可用 |
| CMake | 3.16 ~ 3.24 | 太新可能引起策略警告 |
| Git for Windows | 尽量新 | 需要处理符号链接 |
3. CMake 配置本质上是一次“老代码改新环境”的妥协
3.1 编译器选择：VS2015 与 VS2017 的真实差距
Matterport3D 官方没有 Windows 安装文档，但从源码提交记录和社区讨论看，早期有人用 VS2015 编过。_wfopen_s这类安全增强函数在 VS2015 引入了，理论上 VS2015 和 VS2017 都可以。但实际编下来，VS2017 更适合现代环境，原因有三点：
第一，VS2015 对 CUDA 11 的支持极差，而 Windows 上安装老 CUDA（比如 9.0）会和现在主机的 NVIDIA 驱动版本产生兼容性问题，装完总是提示驱动不匹配。VS2017 配合 CUDA 11.3 就顺很多。
第二，VS2017 的 v141 工具集对 C++11 特性的实现更完善。Matterport3D 的 C++ 代码里用了不少 C++11 的智能指针和std::unordered_map，VS2015 的某些早期更新版本在模板实例化时会报奇怪的内部编译器错误。
第三，VS2017 能更好地处理 CMake 3.16+ 生成的 Visual Studio 工程文件。CMake 新版本对旧 VS 版本的生成器改动很大，VS2015 会出现“无法解析的外部符号”这类与代码无关的链接错误。
如果你的电脑里同时装了 VS2019/VS2022，编译时一定要显式指定生成器，否则 CMake 默认选择最新安装的 VS 版本，会带来另一批问题。我最后的做法是：
cmake .. -G "Visual Studio 15 2017 Win64" -DCMAKE_BUILD_TYPE=Release3.2 CUDA 版本选择的计算逻辑
Matterport3D Simulator 源码中有大量 CUDA 文件，它们用了较老的 CUDA API 函数（比如cudaSetDeviceFlags、cudaGraphicsGLRegisterBuffer），所以 CUDA 版本不能太新。CUDA 11.3 是我测试的下限，CUDA 11.0/11.1 在 VS2017 下会有某些__half类型冲突问题。CUDA 12.x 就不要尝试了，源码里的 PTX 语法和老cutil头文件已经完全不兼容，连 CUDA 编译阶段都过不去。
在 CMake 配置阶段，CMake 会自动检测 CUDA 版本，并设置CUDA_NVCC_FLAGS。如果检测失败，大概率是 CUDA 路径没进系统环境变量，或者 VS 与 CUDA 版本不匹配。可以在命令行先验证：
nvcc --version看到能正常输出版本号后，再执行 CMake。如果 nvcc 可用但find_package(CUDA)仍然失败，可以在 CMake 命令行手动指定：
cmake .. -DCUDA_TOOLKIT_ROOT_DIR="C:/Program Files/NVIDIA GPU Computing Toolkit/CUDA/v11.3"3.3 OpenCV 路径与OpenCV_DIR的匹配问题
Windows 上编译 OpenCV 依赖最优先要做的是“让 CMake 能找到 OpenCV”。官方推荐的是使用预编译的 OpenCV 3.4.x Windows 包。下载解压后，目录里会有一个build文件夹，里面有include和x64/vc15/lib（VS2017 对应的是 vc15；VS2015 对应 vc14）。
CMake 查找 OpenCV 依赖这个变量：
cmake .. -DOpenCV_DIR="E:/libs/opencv-3.4.16/build"需要注意，OpenCV_DIR必须指向包含OpenCVConfig.cmake的目录，而不是build/x64/vc15/lib。很多人在这一步填错，导致 CMake 报Could not find OpenCV。另外，如果编译出的matterport.exe在运行时提示缺少opencv_world3416.dll，记得把 OpenCV 的build/x64/vc15/bin加入系统 PATH，或者直接把对应的 DLL 复制到 exe 同目录。
CMake 配置阶段还会有Pangolin_DIR的坑。Matterport3D 的 CMakeLists 用find_package(Pangolin)查找 Pangolin，而这个 Pangolin 是子模块源码，并不会主动安装到系统。需要先单独给 Pangolin 跑一次 CMake 构建，或者直接在 Matterport3D 的 CMakeLists 里把 Pangolin 相关的选项剔除。我是在 Matterport3D 的 CMakeLists.txt 里搜索 Pangolin 相关语句，把构建示例程序的部分注释掉的。
3.4 配置阶段常见失败信号
CMake 配置阶段最容易卡住的三种情况：
CUDA_SOURCE_DIR为空。检查 CUDA 环境变量，确认C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.3目录真实存在。- 报
GL相关错误。这是 Pangolin 引入的 OpenGL 依赖问题，最常见的是缺少opengl32.lib或glew。VS2017 自带的opengl32.lib一般是可用的，多余的 GLEW 依赖要从 Pangolin 的 CMake 中关闭。 - 报
Unknown CMake command "cuda_add_library"。这是因为 CMake 没找到 CUDA 的FindCUDA模块。老项目常用cuda_add_library而新版 CMake 已经默认不用了，需要把cmake 3.10+的Cuda模块重新指向或者安装 CMake 时选择旧版本（3.12 左右）。
这些情况看着吓人，实际上都是配置路径问题，不是代码本身的问题。把依赖路径逐一验证清楚，基本能过配置阶段。
4. 编译连环报错的完整拆解：从 M 到 Z，逐个击破
当 CMake 成功生成.sln文件后，真正的重头戏才开始。我习惯先打开生成的Matterport3DSimulator.sln，直接编ALL_BUILD，让报错一次性全部暴露，然后一条条修。下面按我实际遇到报错的顺序，把几个高概率问题完整拆开讲。
4.1ssize_t未定义：老 Unix 代码移植 Windows 的典型症状
Matterport3D 的源码是从 Linux 环境直接搬过来的，代码里到处用ssize_t，但这是一个 POSIX 类型，MSVC 里没有。报错信息类似：
error C2065: 'ssize_t': undeclared identifier出现在src/lib/Pangolin相关头文件或者src/utils下的跟文件读取相关的代码中。解决办法是在错误文件里加入：
#ifdef _MSC_VER #include <BaseTsd.h> typedef SSIZE_T ssize_t; #endif如果你不想改太多文件，可以在项目里找公共的头文件（比如src/headers.h或src/common.h），把这段全局包含放进去。这样一次修改就能覆盖所有源文件。这也是我比较推荐的方式，因为项目里分散在不同子目录的多个文件都会用到ssize_t，逐个文件加既繁琐又容易漏。
4.2_wfopen_s参数不匹配：Windows 安全函数的引入
有一个地方用了fopen或_wfopen_s，但传给它的路径参数是普通的char*，而在 Windows 下安全版本要求用wchar_t*。报错通常长这样：
error C2664: '_wfopen_s' : cannot convert argument 2 from 'const char *' to 'const wchar_t *'这个其实很好修：在调用位置把路径转换一下。如果你不是做深度二次开发，可以直接把_wfopen_s改回fopen，这个项目里这里没有实际的安全需求，用标准fopen是没问题的。我改的时候只动了一个文件，大概两三行代码。
也可以用MultiByteToWideChar做运行时转换，但那样改动更大，没必要。
4.3std::to_string链接不上：VS2017 的一个老问题
有一处报错会显示std::to_string相关函数找不到，这是 VS2017 某些更新版本下 C++ 标准库的to_string模板实例化 bug。这个坑比较隐蔽，因为编译时它不一定报错，是在链接阶段报一堆unresolved external symbol "class std::basic_string..." __cdecl std::to_string(int)。
一个相对省事的办法是在 CMake 里强制使用静态运行时库。在 CMakeLists.txt 里找到CMAKE_CXX_FLAGS_RELEASE等变量，加入/MT（静态链接运行时）代替默认的/MD。这个改动会让一部分std::to_string相关符号被正确解析。
如果加了/MT还不行，干脆在源码里写一个自己的转换函数：
template <typename T> std::string to_string_ll(T value) { std::ostringstream oss; oss << value; return oss.str(); }然后把报错处的std::to_string替换成to_string_ll。这个办法治标治本，而且完全不依赖编译器版本。因为项目里用到std::to_string的地方不算多，我全量搜索一下也就改了五六处。
4.4 Pangolin 与 CUDA 的__CUDACC__宏冲突
Pangolin 子模块里有很多 OpenGL 和 CUDA 互操作的代码，Windows 下编译会出现这种报错：
error C2059: syntax error : 'constant'通常出现在cuda_gl_interop.h或pangolin/gl/glinclude.h附近。原因是 Pangolin 的某些头文件在 MSVC 环境下没有正确处理__CUDACC__宏，导致__host__或__device__这样的 CUDA 关键字被当成了普通标识符。
这个问题最省力的解法是绕开 Pangolin 的使用。Matterport3D 用 Pangolin 主要是为了生成鸟瞰图和可视化窗口，编译仿真器核心部分时完全可以不依赖它。找到src/CMakeLists.txt，把和Pangolin相关的target_link_libraries注释掉。但要注意，src/lib下还有几个工具函数直接引用了 Pangolin 的头文件，只注释链接库还不行，需要把源码中#include <pangolin/...>的地方也一并处理。
如果你确实需要 Pangolin 的可视化功能，我的经验是单独编译 Pangolin，然后让 Matterport3D 链接外部 Pangolin。Pangolin 的 Windows 支持虽然弱，但只要关闭它的BUILD_PANGOLIN_VIDEO和BUILD_PANGOLIN_GRABBER选项，能编译过的概率还是很大的。
4.5 OpenCV 4.x 引起的CV_LOAD_IMAGE_COLOR等常量丢失
如果你不小心用了 OpenCV 4.x，会遇到大量类似：
error C2065: 'CV_LOAD_IMAGE_COLOR': undeclared identifier error C2065: 'CV_8UC1': undeclared identifier这类常量在 OpenCV 4 中被重命名或移除了。坚持用 OpenCV 3.4.16 可以完全避开这个问题。如果因为某些原因必须用 4.x，那就得在项目里额外定义这些宏：
#define CV_LOAD_IMAGE_COLOR 1 #define CV_LOAD_IMAGE_GRAYSCALE 0这只能解决常量缺失问题，函数签名层面的变化还是会有一堆。所以我的建议是不要和 OpenCV 4 死磕，换回 3.4.x 的时间成本远低于修代码的时间成本。
4.6 链接阶段出现unresolved external symbol大量堆积
当编译全部通过但链接失败，且报错数量超过百条时，通常不是代码逻辑问题，而是 CMake 配置中没有正确链接某些 Windows 系统库。加这几个库一般在链接阶段能解决一半问题：
opengl32.lib glu32.lib winmm.lib ws2_32.lib修改src/CMakeLists.txt，在target_link_libraries里追加这些系统库。这里有个判断技巧：如果报错符号大量以gl开头，就说明 OpenGL 相关库没链上；大量以WSA或socket开头，就说明ws2_32.lib缺失。逐个看符号前缀，能快速定位缺的是哪一类库。
还有一个隐藏链接问题来自 FreeImage。Matterport3D 源码中src/lib/FreeImage自带一部分源码，但 CMake 不一定能把它们编译成静态库。如果遇到 FreeImage 相关符号缺失，直接注释掉 FreeImage 相关代码是最快的，因为仿真器核心流程（加载 house 文件、渲染 RGB-D 图像）并不需要真正的图片保存功能。
4.7 语言标准与警告等级：克制修改冲动
老项目在 MSVC 下的编译还会有一大堆 C4996 这类“使用了不安全的函数”警告。默认设置下，这些警告不会中断编译。但如果你的 CMake 配置不小心指定了/WX（把警告当错误），整个编译会死在无关紧要的警告上。建议检查一下 CMakeLists.txt，把和/WX相关的选项去除。
还有一个细节：Matterport3D 源码没有明确指定 C++ 标准，MSVC 默认使用 C++14，这个可以顺利编译。但如果你安装了 VS2022 并用 VS2017 工具集去编，可能会默认启用更高的语言标准，导致部分代码行为发生变化（比如std::unary_function在 C++17 中被移除，而代码里用了它）。最稳妥的方式是在 CMakeLists.txt 中显式加上：
set(CMAKE_CXX_STANDARD 11) set(CMAKE_CXX_STANDARD_REQUIRED ON)Matterport3D 的代码按 C++11 标准编写，加上这个设定能规避很多后续莫名其妙的兼容问题。
编译阶段做完这些处理，matterport.exe应该能顺利生成。生成的位置在build/Release/目录下。这个成功其实只意味着“能编译”，离“能跑”还有数据准备这一步。
5. 数据下载与目录放置：决定仿真器能否真正运行的最后一环
5.1 申请 Matterport3D 数据集的注意事项
Matterport3D 数据集本身需要去官网申请，提交一个硬件配置和研究方向说明，审核通过后下载脚本会发到你的邮箱。这个下载脚本就是之前第 2 节丢到matterport_metadata目录里的downloader.py。
这里有个关键点：下载脚本里面写的是需要把 scene 数据放置到指定目录，默认路径是相对于脚本位置的../scans。如果你的目录结构和我上面的E:\VLN\结构一致，那么在matterport_metadata目录下执行：
python downloader.py -h会看到若干参数。下载时建议加上-m matterport_skybox_images选项，Matterport3D Simulator 渲染全景图时必须用到 skybox 贴图。如果只下载了undistorted_color_images和undistorted_depth_images，仿真器加载场景时会有部分功能缺失。
数据集比较大，一个 scene 往往几个 GB 甚至十几 GB。Windows 下downloader.py的下载速度有时会非常慢，如果中断了，脚本支持断点续传，重新执行同样命令即可。我的经验是不要用代理，保持直连反而更稳。
5.2 下载后的目录对齐：仿真器的“默认血统”
Matterport3D Simulator 运行时会在build/Release目录下生成可执行文件，而这个可执行文件对数据路径的查找逻辑是写死的。打开src/CMakeLists.txt，你能看到类似DEFINE_string(scene, "", "scene json")这样的命令行参数定义，但实际场景模型加载模块里，会把传入的 scene 路径拼接成相对路径。
具体来说，仿真器默认期望的执行目录是build/Release，然后通过--scan_id参数传 scene 名，它自动去找../../../../scans/<scan_id>/。如果你直接把 exe 放到别的地方运行，就会报Cannot open scan。
我在实际项目里总结了一个更可控的目录结构，直接绕过它相对路径的“怪脾气”：
E:\VLN\ │ ├── Matterport3DSimulator\build\Release\ │ └── matterport.exe │ ├── matterport_metadata\ │ ├── downloader.py │ └── matterport_metadata\ │ ├── house\ │ ├── matterport_skybox_images\ │ └── ... │ └── scans\ ├── 17DRP5sb8fy\ │ ├── matterport_skybox_images\ │ └── ... └── ...在给 exe 传参时，直接传入 scene 文件夹的绝对路径：
matterport.exe --scan_id 17DRP5sb8fy --room_number 0 --render_type 1这样就能避免很多路径拼接上的黑盒报错。
5.3 测试运行：先跑test_scene再看可视化
编译成功后，可以用一个最小的 scene 先做测试。没有完整数据之前，可以先用仿真器自带的示例数据，不过这个在 Windows 下不一定齐全。如果你已经下载好至少一个 scene，建议按这个顺序验证：
第一步，测试模型加载。运行：
matterport.exe --scan_id 17DRP5sb8fy --headless 1--headless 1表示不弹出可视化窗口，适合先确认数据加载流程没问题。如果这个命令能正常执行且不报错，说明模型和 house 文件已经能正确对应。
第二步，测试渲染。把--headless换成0：
matterport.exe --scan_id 17DRP5sb8fy --headless 0 --resolution 640 480此时会弹出可视化窗口，显示全景相机在场景里看到的画面。如果这一步也能正常显示，说明 OpenGL 渲染管线没有问题。
第三步，测试图像输出接口。部分 VLN 训练代码依赖仿真器输出的 RGB 和深度图，可以调用 Python 接口来验证。Matterport3D Simulator 提供了 Python 包装，我这里用的是预编译的MatterSim模块。测试代码很简单：
import MatterSim sim = MatterSim.Simulator() sim.setDatasetPath("E:/VLN/") sim.setRenderingEnabled(True) sim.init() sim.setCameraPose(0, [0.0, 1.5, 0.0], [0.0, 0.0, -1.0]) sim.makeViewpoint()能顺利输出画面数据就说明整个仿真器已经可用了。
5.4 Windows 下 Python 接口的另一个坑
官方仓库里的 Python 接口编译出来的是MatterSim.pyd，这个文件必须放在 Python 能 import 到的地方。很多人在 Windows 下编译成功后，在 Jupyter Notebook 里import MatterSim失败，原因基本都是.pyd所在目录没有加入sys.path，或者 Python 版本和编译时用的版本不一致。
用 Conda 管理环境的话，直接把build/Release目录加入PYTHONPATH是最省事的：
set PYTHONPATH=E:\VLN\Matterport3DSimulator\build\Release;%PYTHONPATH%但要注意，因为 Matterport3D 编译时使用的是 VS2017 运行时库，你的 Python 环境如果是用较新 MSVC 编译的，运行import MatterSim有概率直接崩溃。这是一种典型的 MSVC 运行时混用问题。建议用同一个 VS2017 环境下的 Python 版本，或者干脆用python 3.7这类比较老的版本会稳很多。我自己试下来是 Python 3.7 + VS2017 组合最稳定。
6. 编译成功后必须马上做的一次“备份快照”
整个过程中最心累的时刻不是最终编译通过，而是当你为了调一个可视化参数，不小心把某个第三方库的版本升级了，结果原封不动的代码突然编不过。所以我的铁律是：一旦成功编译出matterport.exe和MatterSim.pyd，立刻把整个build目录压缩备份。
备份有几个好处：第一，后续如果改代码导致编译坏了，可以随时回滚到干净状态；第二，换电脑或换环境时，不需要重新踩一遍所有坑；第三，VLN 项目通常要和 PyTorch 等框架结合，如果为了仿真器升级把系统环境搞乱了，至少仿真器是完好的。
另外，建议把编译时用的 Cmake 命令行和关键依赖版本号写进项目 README。很多坑之所以反复踩，就是因为版本组合是“能跑的那一次”留下来的，但没人记录为什么能跑。
我这边留下的“黄金组合”是：
VS2017 v141 + CUDA 11.3 + OpenCV 3.4.16 + CMake 3.20 + Python 3.7如果后续有同学在 Windows 上编译 Matterport3D 卡住，优先把环境调整到这个组合，成功率会高很多。
7. Windows 下继续深入 VLN 研究的两个扩展建议
Matterport3D Simulator 编译通过只是第一步。做 Vision-Language Navigation 研究时，通常还需要配合 PyTorch 训练模型、加载预训练视觉特征等。Windows 环境里把这套链路串起来，有两个建议供参考。
第一个建议是不要纠结于在 Windows 里跑完整的训练流程。仿真器编译到 Windows 上，最好只是用来生成训练数据和做小规模验证，真正的大规模训练放在 Linux 服务器或者 WSL2 里跑。因为很多 VLN 相关的数据处理代码（比如预先提取 ResNet 特征的程序）依赖 Linux 生态的某些细节，Windows 上会额外消耗大量排除环境问题的时间。
第二个建议是记录仿真器的输出格式。Matterport3D Simulator 输出的深度图实际上是视差图（disparity），不是真正的深度值。你看src/features/相关代码或者 Python 接口文档都会提到，在使用前要用1.0 / (depth + 1e-8)之类的操作转换成实际深度。这个细节对后续训练视觉特征非常关键，很多人在数据处理阶段结果异常，原因都出在这里。
我在 Windows 下跑 Matterport3D 的最大体会是：这个仿真器本质上还是“活在 Linux 时代”的项目，Windows 编译成功只是第一步，后面遇到的每一个问题，几乎都绕不开“源码假设你用的是 POSIX 系统”这个前提。但把所有坑都踩过一遍后，Windows 作为日常主力开发环境，跑跑数据生成、看看可视化结果、调试一下导航算法，是完全够用的。希望这篇能让你在自己电脑上把仿真器跑起来的时候，少翻几次车。
