Bad texture on objects

[databird]

I just download a MM tour and got bad textures on objets... Any ideas ?

See picture :

[SamuelHouse]

I have the same issue. The textures in both the the floor plan and dollhouse views are wrong.

[rebane2001]

The dollhouse/floorplan textures being messed up is a known issue; this is due to how query parameters are ignored at the moment. If you go "inside" the rooms, the textures there should be correct.

I don't plan on fixing this issue at the moment, but I'll leave this issue up in case anybody else wants to take a shot at it.

[mitchcapper]

The problem is (as mentioned) the same url is used with different arguments is used for the different texture types. While fetching all those additional resources is fairly doable the problem is how to allow them to be used. They cannot be saved in the full original url (ie textures/4/5/file.jpg?type=0 and textures/4/5/file.jpg?type=1) as the question mark is not a valid file character (in windows) and even if it was, no standard web server would serve it up. In all cases we would need to change the filename to something like file_type_0.jpg and file_type_1.jpg. This is pretty easy to do while downloading but the trick is how do we then get matterport to try for the new file.

There are 3 possible solutions I see:

1) We try to do what we do other places. We try to rewrite the client javascript to access something slightly different. This is tricky as they may change the javascript instantly breaking it. It may be hard to find the exact code we need to rewrite in it too. The benefit of this solution is it continues to work on any web server as we have just modified the client to access different urls.

2) We stop trying to rewrite the client code for uri changes and change to using a javascript proxy. A proxy in javascript is a newer feature that sits between a real object and anything trying to access it allowing any of the accesses to be changed. The benefit here is we, in theory, would need less updating as matterport javascript changes. If we were to proxy the xhr fetching tools (ie XMLHttpRequest) we could see what url is being requested and then use a list of patterns to rewrite it as desired. A sample of such a proxy is: https://gist.github.com/valotvince/ef8f70e8a565fbd723a7a0c806709a55

We would need to inject our JS into the standard JS but this isn't hard. We would need to account for how they load resources but most of it seems very straightforward. At that point we don't care about the changes to the client JS as they all run requests through our proxy ( so don't even know the url is different). This has a one time larger programming cost to setup said proxy but if we got that working any required updates in the future would likely be minimal.

This has the benefit of being more robust in terms of changes matterport may make to the JS client and it works with any web server as we are still only modifying client side behavior.

3) With my latest PR (https://github.com/rebane2001/matterport-dl/pull/6) I started introducing a more complex built in web server. It would be technically quite easy with it to rewrite any request to any file we wanted (so the client would still request textures/4/5/file.jpg?type=1 but we could easily change it on the server to textures/4/5/file_type_1.jpg. This has a few benefits. First, again as matterport changes client side code it is unlikely to break anything because we rewrite the urls server side. Secondly it is less complicated to implement just some regex calls to rewrite on the server. The big downside of this method is the fact it would not work with other web servers by default. Now it may be possible to generate the right apache and nginx regex's so you could have it work, but certainly that would make 3rd party servers harder.

The first step would probably be to start saving them off even if not hosting it back yet.