Hi @HumbleTraveller,
Thank you for trying, and I apologize for it not working.
As you found, HabitatSim is not supported on Windows. As a result, we’re pursuing two main paths forward. One is to decouple Monty from a specific simulator implementation, like HabitatSim. The other is to integrate with a simulator that does work on Windows.
On the path of decoupling Monty, it should now be possible to run Monty benchmarks/experiments that do not require HabitatSim. This is only marginally useful, as the tests and development still rely heavily on a simulator. The next decoupling tasks on this path are to 1) separate unit tests from integration tests, 2) remove HabitatSim dependency from unit tests, and 3) decouple Monty integration tests from a specific simulator, like HabitatSim. We believe Monty will be fully decoupled from HabitatSim once this work is completed. However, with HabitatSim being the only simulator available, Monty will still rely on it. This brings us to the second path, integrating a different simulator.
The second path involves integrating a second simulator. Once a second simulator is integrated, Monty should become more accessible, assuming the second simulator works on all platforms. One benefit of the already completed initial decoupling work is that it grouped the HabitatSim simulator code into simulators.habitat. This may serve as a guide as to what code needs to be written to integrate a second simulator. As to what the second simulator could be, I shared my thoughts on it so far in The Next Monty 3D Environment Simulator post.
This diagram [1] illustrates what I described above, highlighting work to be done as “injections.” Injection #11 has been completed so far. The general way to read this is that things above require the things below.
Monty’s current target is the CPU (we use Numpy v1 for computations). Monty on the GPU is future work. HabitatSim does expect a GPU, which we emulate via xvfb in some cases.
Technically, this is a Future Reality Tree. ↩︎