create3000 / x_ite

X_ITE X3D Browser, view and manipulate X3D, VRML, glTF and other 3D sources in HTML.
https://create3000.github.io/x_ite/
Other
67 stars 15 forks source link

Loading world from object URL hangs at loading screen if more assets are requested #142

Closed WumboSpasm closed 1 year ago

WumboSpasm commented 1 year ago

I'm developing a web frontend for the Flashpoint Archive that loads files from zip archives and uses open-source players such as Ruffle and X_ITE. While refactoring the code, I noticed that if a multi-asset world is loaded from a blob: URL created using the URL.createObjectURL() method (which is necessary when loading from a zip), X_ITE would get stuck on the "Loading X files..." screen with no errors present in the console. Single-asset worlds, on the other hand, load without problems.

I previously avoided this issue by overriding the fetch method so it would serve files from zips. However, this override was primarily meant for Ruffle and has the ability to cause a slew of other issues.

Here's a very simple example of the bug in action: https://jsfiddle.net/u8nhfk0o/2/

create3000 commented 1 year ago

The problem are the relative URLs you are using in https://cgg.mff.cuni.cz/~jaroslav/projects/celts/world/kelti.wrl. Normally relative URLs are resolved agains the scene's URL. For instance "sever.jpg" would be resolved to https://cgg.mff.cuni.cz/~jaroslav/projects/celts/world/sever.jpg.

But when the scenes URL is a blob, the relative urls cannot be resolved anymore, because there is not knowledge about the URL https://cgg.mff.cuni.cz/~jaroslav/projects/celts/world/kelti.wrl.

For this case, there is the possibility to set the baseURL of the browser, see https://create3000.github.io/x_ite/reference/browser-services#baseurl, which would be in your case look like this:

player.browser.baseURL = "https://cgg.mff.cuni.cz/~jaroslav/projects/celts/world/kelti.wrl";
WumboSpasm commented 1 year ago

My code does use baseURL - I just didn't include it in the linked fiddle because the issue occurred regardless. However, it seems like it's been fixed now. Thank you for the swift response!