Items here are known features/issues that have yet to be fixed/developed/added.
Sweeps are tile textures and right now for sweeps we use the v1 data () to get the sweep tile uuids and then just brute force all resolutions. This is mostly the "downloadSweeps" function it takes a sweeps array of uuids to download that is just extracted from api/v1/player/models/{pageid}/index.html. This is the V1 api which might go away at any point and doesn't tell us the resolutions so we try all 4 (512, 1k,2K,4K). For models with < 4K max resolution it is a bunch of wasted queries. Instead the getShowcaseSweeps graph request has better data. We can iterate the locations and get the uuid data.model.locations[0].pano.sweepUuid. This would resolve many of the 404s we will get by just bruteforcing each location has its max res (2k 4k etc) stored in data.model.locations[0].pano.resolutions. We can assume 512 and 1K but if it doesnt have 2K or 4K we should skip trying to download those. Technically each location could have a diff resolution so would be preferable to make it per location generated (modifying hte for loops in downloadSweeps shouldn't be too complicated). To partially support defurnished models you can see the start of this code in downloadMainAssets.
Refactor a few download functions to get the model ID to support defurnished (and potentially other) layered views
Recently matterport added AI generated defurnished views where they can automatically remove the furniture (cool). This is largely done by having a whole second model for the defurnished edition. Of course it isn't quite that easy. Right now you can actually download defurnished models if you provide the defurnished model id to matterport-dl.py as if it was the real model. This is not ideal as you can't use the toggle buttons but it works. To support single model defurnished views we need to refactor a few of the key download functions that use graph data to get the model ID to act on. Similarly the fetch graph data need to be able to get the model ID to fetch the graphs for. This would allow us to run these functions twice once for the primary model as we do and optionally a second time for the defurnished model ID. I think we will largely avoid file collisions except: graph data would need to have the model ID postfixed to the name (if it doesn't match the main model id).
98% of the work required for static hosting is in place. It is possible with some custom rewrites to likely even statically host on certain web servers without additional work. To make it work on nearly any web server some changes are needed. Essentially we should write a "publish" action that copies everything into a static folder. Any .modified files would override the originals. A few things would need tweaks the graph posts (or now gets) and potentially the image crops. The good news is this can be done with our JSNetProxy. It can turn post requests into get (although no longer needed I believe). It can rewrite urls to incorporate parameters. So for any graph requests rather than say the url being /api/mp/models/graph?operationName=GetShowcaseSweeps it would simply need to rewrite it to /api/mp/models/graph_GetShowcaseSweeps.