Add support for file:// URLs

[kring]

Unity's UnityWebRequest does not support file:// URLs, meaning that - unlike Cesium for Unreal (at least on Windows) - it's not possible for users to use them to access local files. It does support raw file paths, but this sometimes breaks in cesium-native when uriparser doesn't consider a local file path to be a valid URL.

So, we should add explicit file:// URL support to UnityAssetAccessor. When it sees these URLs, it can either read the file from disk directly, or it can turn the URL into a regular file path and pass it to UnityWebRequest.

[rossoe]

@kring this would certainly be useful, is there any chance file:// support might appear in an upcoming release?

[kring]

I believe this issue is outdated and file URLs are supported now. Have you tried it?

[jhaverkost]

Just tested a file URI in hopes of seeing the new Ion Clipping feature (https://cesium.com/blog/2024/05/08/cesium-ion-clipping/) in action but didn't have any luck.

Cesium SDK: 1.10.0
Unity: 2022.3.10f1
OS: Windows 10
Tileset URI: file:///C:/<redacted>/tileset.json

Attempting to load the tileset results in the following error which appears to ignore the file scheme for resolving the relative paths within the tileset.json and attempts to use HTTPS instead.

[2024-05-08 09:21:44.687] [error] [TilesetContentManager.cpp:997] An unexpected error occurs when loading tile: Request for `https://localhost/tiles/00000000000000.glb` failed: Cannot connect to destination host

UnityEngine.Debug:Log (object)
Reinterop.ReinteropInitializer:UnityEngine_Debug_CallLog_FA05wu8x__otZNsgdHTnU9A (intptr) (at ./Library/PackageCache/com.cesium.unity@1.10.0/Runtime/generated/Reinterop/Reinterop.RoslynSourceGenerator/ReinteropInitializer.cs:60677)
CesiumForUnity.Cesium3DTileset:Update () (at ./Library/PackageCache/com.cesium.unity@1.10.0/Runtime/generated/Reinterop/Reinterop.RoslynSourceGenerator/Cesium3DTileset-generated.cs:606)

[kring]

I just tried a file URI in Cesium for Unity, and it worked well. In my case it was Unity 2022.3.20f1 and Windows 11, but I don't expect that to make a difference (it could be worth trying a Unity upgrade if it's easy for you to do).

I'm not sure what might be going wrong in your case. Are there any spaces or other non-URI-safe characters in your <redacted> path name perhaps? Did you use forward / slashes everywhere instead of back \ slashes? Can you try clearing the console before setting the URI, just to be 100% certain that the error your pasted above is coming from the most recent URI that you entered?

[rossoe]

This worked for me file://E:/.....

Using 2021.3.10f1 and cesium plugin 1.9.0

[r-veenstra]

A tip that may be useful. On Windows I copy the file path from Windows Explorer and paste it into a browser like Chrome or Edge. It will automatically reformat the path to a URI, which can then be copy and pasted directly into the Cesium UI. I find this eliminates any human error that might creep into manually reformatting the path.

[kring]

That's a great tip, thanks @r-veenstra! If you use right-click, Copy as Path in Windows explorer, the copied path will be surrounded in quotes. Remove those after you paste into the Chrome address bar and before you hit enter.

[jhaverkost]

I just tried a file URI in Cesium for Unity, and it worked well. In my case it was Unity 2022.3.20f1 and Windows 11, but I don't expect that to make a difference (it could be worth trying a Unity upgrade if it's easy for you to do).

I'm not sure what might be going wrong in your case. Are there any spaces or other non-URI-safe characters in your <redacted> path name perhaps? Did you use forward / slashes everywhere instead of back \ slashes? Can you try clearing the console before setting the URI, just to be 100% certain that the error your pasted above is coming from the most recent URI that you entered?

Thanks for looking into it everyone. It looks like the space characters were the problem. With and without spaces it seems like the tileset.json itself is resolved but the behaviour for handling the relative file paths within changes depending on whether there are spaces or not.

Without spaces, using something like file:///C:/test/tileset.json works as expected.

With spaces (encoded or not), file:///C:/test%20spaces/tileset.json or file:///C:/test spaces/tileset.json (non-encoded isn't valid anyways but often resolves in many applications), fails with the error I previously mentioned.

Testing out some other characters, it seems like any character that requires encoding for the URI path segment causes the problem. Since it affects the path segment, characters that are considered reserved characters in other URI segments, such as +, =, (, ), etc. work just fine because they are allowed to be used in the path segment either literally or encoded. However, characters that require encoding in the path segment, such as (space, as %20), % (as %25), do not work (as previously described).