（以下视频链接。）
附加的项目文件打开如下：
The project file contains all the JSL files and some other bits and pieces like a credits slide.项目文件包含所有 JSL 文件和一些其他点点滴滴，如致谢名单幻灯片。
我喜欢独立的项目；他们的学习曲线很短，一旦我明白保存 JSL 文件（灰色磁盘图标，顶部左起第 5 个）保存在项目打开的临时位置，而不是项目的存档文件中，一切都有意义。 另一个看起来很奇怪的图标，从左数第 4 个，将所有未保存的 JSL 文件保存到临时位置，然后重建/保存项目存档。 该项目有自己的命名空间；我注意到没有任何泄漏。 我已将项目的日志窗口停靠在右侧。
如果您决定查看该项目，或尝试运行它，这里是我如何使用它的概述。 首先，雨滴管理器构建了一个巨大的表（每张图片 300 行乘以 32768 张图片）行。 这是在几个小时内完成的，并且必须按顺序完成，因为它逐帧跟踪 300 个雨滴的位置。 其次，启动号码服务器。 它在另一个选项卡中打开一个 GUI 窗口来管理 Linux 机器场。 Number Server 实际上主要是一个 Python 程序，它运行一个网络服务器，确保每台农场机器在序列中处理不同的图片。 第三，GUI 启动场进程以使用生成图像中的 JSL 创建图片。
这是一个相当复杂的设置，但结果却非常稳健。 它至少跑了 3 次才完成，每次大约 55 个挂钟小时。 结果证明效果很好：不要使用 NFS，而是使用 Windows 共享文件夹。 在 VirtualBox 中运行 Windows；使用 VBoxManage 启动和停止 Windows。 使用 Windows 启动目录启动 JMP。 如果我要再次运行它，我会添加到 GUI 中：“蓝色”状态表示工作人员已完成并关闭。
55 小时后，农场中机器的工作分配：
Several classes of hardware in this Beowulf Cluster.此 Beowulf 集群中的几类硬件。
计数表示每台机器创建的图像数量。 每次机器完成一幅图像时，它都会询问 Number Server 下一步应该处理什么图像。 由于雨滴位置是预先计算好的，缩放级别由图像编号决定，因此农场中的所有工作人员都能够独立工作，将完成的图像推送到共享文件夹中，在视频组合时按名称排序。 当前设置的代码以反转位顺序制作图像，生成中间图像，然后是 1/4 图像，然后是 1/8 图像……按顺序生成。 在 27 小时标记处，每隔一张照片都已制作完毕，因此可以轻松查看概览。 （遗憾的是，需要第 3 次运行 55 小时的问题只能在相邻图像上看到......有时......闪烁的雨滴！）
我上传了 4K 60FPS 视频。 我的硬件允许我使用 4K 30FPS 或 2K 60FPS，所以我从来没有同时看到这两者。 如果你只选择一个，选择 60FPS，它非常流畅。
下载后删除.zip 扩展名，JMP 16 将打开它。 它将需要大量调整才能使其正常工作。
