Win10 mitsuba2.0 安装踩坑记
前言
徒刑学大作业要用mitsuba，这种一看就很耗CPU的东西ATP是一点儿也不想用虚拟机弄，于是就决定直接在Win上装一个。
果然配环境配多了不利于身体健康，ATP捣鼓了一晚上血压蹭蹭地涨，气得差点把电脑砸了（一拳打烂屏幕.gif），不过最后还是搞好了，所以ATP决定发一个博客记录一下这个历史时刻，顺便也给后来的人一点前车之鉴。
参考了：
正文
在开始搞所有东西之前，可以先确保一下大前提：
- CMake已经装了。这个好装，百度一下即可。
- Python有较新版本，ATP用的3.7，反正import mitsuba是没问题，具体代码还没写不知道，但应该问题不大
- Visual Studio 2019。重中之重，让ATP血压飙升的罪魁祸首。
第一步：从github上下载mitsuba2及其子模块
上个github太难了155551，直接去参考这篇CSDN叭，人家讲的挺详细的。
官网给的指引是：
git clone --recursive https://github.com/mitsuba-renderer/mitsuba2
这个recursive是非常重要的，因为它确保下载的时候除了主模块mitsuba2，里面要用的一些子模块（都存在mitsuba2/ext文件夹里了）以及子模块的子模块都递归下载了。
但问题是github目前访问非常难，ATP换了两个tz都不大行，老是报什么fatal error啦超时啦访问失败啦这些的。有时候它突然好一小会儿然后下载到一半又不行了，就很生气。
根据官网，如果成功下载了主模块但子模块没下载好，可以用下面的命令更新子模块：
git submodule update --init --recursive
ATP搞的时候其实发现手动下.zip文件是很顺畅的，但不知道能不能这样手动下载解压然后自己去放到正确的位置上。ATP反正没心情试验了，或许有勇士试验一下（？）
不过ATP还是要控诉为什么助教不直接下好了把包给我们1551，反正每个学期大作业都差不多，这得能省多少事儿啊（（
第二部：choosing variants
这一步官网上有，但网上一些教程里没有。ATP合理推测他们都只想用c++写。如果只用c++写确实不需要额外配置这一步。但如果你像ATP一样想试试用python调mitsuba库，保险起见还是按官网上的设置一下吧。
打开\mitsuba2\resources目录，找到一个mitsuba.conf.template文件，把它复制到\mitsuba目录下并改名为mitsuba.conf。
然后打开这个mitsuba.conf，在第70行左右找到"enabled"这一项。这就是要设置的地方，别的都不用改。初始这块内容是这样的：
"enabled": [
# The "scalar_rgb" variant *must* be included at the moment.
"scalar_rgb",
"scalar_spectral"
],
如果你只是想用python import mitsuba并且不考虑GPU，那么直接在里面加一项“packet_rgb”或者“packet_spectral”就可以了。这两个具体的区别请参考官方文档。另外更多的可选variants也请参考官方文档。
文档里指出，这个enabled里面添加的variant数量与编译时间和内存使用量成正比，因此不建议包含超过五个variants。ATP只加了一个packet_rgb。
另外，文档最后说：
If you plan to use Mitsuba from Python, we recommend adding one of packet_rgb or packet_spectral for CPU rendering, or one of gpu_autodiff_rgb or gpu_autodiff_spectral for differentiable GPU rendering.
这也是ATP为什么要捣鼓这个东西的原因。跟着它说的做总不会错叭。。。
第三步：编译，得到sln，并生成exe
接下来只需要在\mitsuba目录下按照文档下一步来运行：
cmake -G "Visual Studio 16 2019" -A x64
ATP是看到这里的“Visual Studio 16 2019”才悲哀地意识到，它的电脑上装的还是VS 2017
（然后这个狗VS，安装新版本的时候竟然还不知道自觉把旧版本卸了，连个“覆盖旧版本”的选项都不给，纯恶心兄弟？？？）
运行完cmake以后，在\mitsuba文件夹下会有一个叫mitsuba.sln的。用Visual Studio打开这个东西。
这里ATP又触发了一个怪bug，如果直接双击mitsuba.sln文件，它倒是会默认自动用VS打开并且加载，但过一会儿竟然报了个错，说“xxx.vcxproj error: 没有安装该项目的应用程序”
如果你也出现了这个问题，只需要先打开空白的Visual Studio，然后在首页选择“打开项目或解决方案”，再打开.sln文件就可以了。
（ATP在写博客的时候本来想复现一下刚才的bug，但这次直接双击.sln文件后，它竟然毫无问题地打开了，也不知道是怎么回事）
等所有东西加载完成后，把菜单栏下面的一个选项从“Debug”调成“Release”，然后生成解决方案。
（这一步巨慢而且巨占CPU，ATP在跑这一步的时候打个字都是卡的，暴躁值++，wdnmd Visual Studio）
此时在\mitsuba\dist文件夹下会有一个mitsuba.exe。说明编译完成了。
（cmake后面的这坨过程在官网上用一句“proceed building as usual from within Visual Studio”带过了，对ATP这种不怎么用VS的也太不友好了x）
第四步：设置环境变量
按照官网的说法，只需要在\mitsuba文件夹下运行setpath这条命令就可以了。
ATP试了一下确实可以，运行setpath以后，如果（在同一个cmd里）随便找个地方这样运行：
> mitsuba
即：直接输入mitsuba命令，不带什么./或者.exe之类的。
如果它输出了一大串帮助信息，而不是报错“mitsuba不是批处理文件也不是blabla”这种，那么就安装成功了。
另外，也可以测试一下，如果（在同一个cmd里）打开python，输入import mitsuba，没有报什么找不到模块的错，那说明前面所有步骤至少是没问题的。
但问题就是这种设置path的方法是临时的，就是你关了cmd重开以后它就失效了。
ATP研究了一下它那个设置环境变量的东西是怎么写的。虽然\mitsuba目录下有三个名字叫setpath的文件，但我们在windows下只需要关注setpath.bat：
@echo off
REM ***************************************************************
REM * This script adds Mitsuba to the current path on Windows.
REM * It assumes that Mitsuba is either compiled within the
REM * source tree or within a subdirectory named 'build'.
REM ***************************************************************
set MITSUBA_DIR=%~dp0
set MITSUBA_DIR=%MITSUBA_DIR:~0,-1%
set PATH=%PATH%;%MITSUBA_DIR%\dist;%MITSUBA_DIR%\build\dist
set PYTHONPATH=%PYTHONPATH%;%MITSUBA_DIR%\dist\python;%MITSUBA_DIR%\build\dist\python
上面这串东西它大概的意思就是在PATH里添加\mitsuba目录下的dist文件夹和build\dist文件夹；在PYTHONPATH里添加dist\python和\build\dist\python。
如果你不确定怎么添加才是正确的，只需要把setpath.bat的第一行那个“@echo off”去掉，然后再运行一次setpath命令。
这样虽然还是临时添加，但这一次的区别是它把添加完成以后的PATH和PYTHONPATH变量都输出来了。
新加的内容一定是在后面两行，找到那两行照着手动加进环境变量里就可以了。
ATP参考了一下它输出来的内容，发现它是添加在“用户变量”而不是“系统变量”里（因为两边都有PATH这个东西，ATP纠结了一下到底该改哪边）。
改完了以后再重新打开cmd，mitsuba这个命令就可以随便用了，python代码也能引用模块了。
这样环境应该就是配好了，如果后面写代码的时候发现什么问题ATP再来更新。
