Hello,
I am unable to use data exported from Reality Capture into UE5 using the following path:
file:///C:/Users/Francis/Documents/EndCap/tileset.json
I get this error in the Output Log:
LogCesium: Loading tileset from URL file:///C:/Users/Francis/Documents/EndCap/tileset.json
LogCesium: Loading tileset from URL file:///C:/Users/Francis/Documents/EndCap/tileset.json done
LogHttp: Warning: 00000AAAF0829B00: request failed, libcurl error: 37 (Couldn't read a file:// file)
LogHttp: Warning: 00000AAAF0829B00: libcurl info message cache 0 (Couldn't open file /C:/Users/Francis/Documents/EndCap/tileset_Salinas_End_Cap_(Just_Pad)/Geometry/lod4_0.b3dm)
LogHttp: Warning: 00000AAAF0829B00: libcurl info message cache 1 (Closing connection -1)
LogCesium: Error: [2022-08-16 15:27:52.523] [error] [Tile.cpp:497] An exception occurred while loading tile: Request failed.
Is there some guide to show how to export data from Reality Capture to UE5? I am using the built-in option for Cesium 3D Tiles. Any help would be greatly appreciated as I am on a time crunch for a project!
LogCesium: Loading tileset from URL file:///C:/Users/Francis/Documents/EndCap/tileset_EndCap.json
LogCesium: Loading tileset from URL file:///C:/Users/Francis/Documents/EndCap/tileset_EndCap.json done
LogCesium: Warning: [2022-08-16 16:03:26.898] [warning] [TileContentFactory.cpp:112] No loader registered for tile with content type '' and magic value ' ?
Until Shehzan or Kevin can chime in here: The file name ...Cap_(Just_Pad)/Geo....might cause trouble due to the ( brackets ). These are reserved characters for URLs, and I don’t know from the tip of my head how well libcurl handles these. (Some escaping might be necessary, and maybe that does not work so smoothly when accessing files).
If it is possible to do this with reasonable effort, you could try creating the tileset with file names that do not contain reserved characters.
UE5 was still not able to import it for some reason. It gave me the following error:
LogCesium: Warning: [2022-08-16 16:03:26.898] [warning] [TileContentFactory.cpp:112] No loader registered for tile with content type '' and magic value '?
The screenshot in the second case looks like it did load the tileset_EndCap.json file. The error message comes from the TileContentFactory, and the tile contents are, for example, B3DM files.
My guess was mainly based on the first output log, which said
Couldn't open file /C:/Users/Francis/Documents/EndCap/tileset_Salinas_End_Cap_(Just_Pad)/Geometry/lod4_0.b3dm
(This error might cause other errors later - maybe even the one that came from the TileContentFactory. In doubt, this would have to be investigated further, if the (brackets) do not turn out to be the root cause here…)
Edit, maybe as a clarification:
The JSON file contains URLs that refer to the tile content. So the JSON file may contain something like
uri: path/to/file(with brackets)/example.b3dm
In this case, it could load the JSON file, but might have difficulties loading the file from the path with the (brackets). But again: This is a guess for now.
The message itself is not unexpected when there really is an unknown content type. But indeed, when it mentions a content type and magic value that involves strange characters (like in your screenshot), then this indicates that it received garbage data.
You could try out the workaround that was mentioned in the thread that you linked to, but … if the problem is originally caused by libcurl not being able to access the path with (brackets), then the same error might appear again.
Is it possible (with reasonable effort) to export the data with paths that do not involve special characters?
(Otherwise, Kevin or maybe @agallegos might have further ideas about the reason for the error, and possible workarounds or solutions…)
I am going to try re-exporting the data to my Documents folder to see if that resolves the issue. I will exclude any special or reserved characters. If that does not work, any suggestions?
If it does not work after re-exporting, you might try deleting the cesium-request-cache.sqlite file as well (handwavingly: for the case that it has cached garbage data there, when it tried to access the path that it couldn’t access). After that, … I’d be out of ideas for now (I’m currently not sooo deeply involved in CesiumForUnreal), but maybe someone else could give further hints then.
@FrancisCheck can you try serving this tileset from a local web server, instead of using file URLs? Unfortunately, the file URL support in Unreal’s version of libcurl is shaky at best.
One problem we’ve seen - but I’m not sure if ContextCapture does this - is that some tools will generate files with extensions like .b3dm, but under the hood they’re gzipped. Cesium for Unreal has no way of knowing this, so it treats the compressed data and uncompressed and ends up reading garbage. The solution in that case would be to gunzip the generated files in bulk before pointing Cesium for Unreal at them. Or maybe change a setting in ContextCapture so it doesn’t do that. But again, this is only a shot in the dark.
I didn’t have that on the radar. And one could argue about the naming here, and consider this as a “bad practice”. But … the question about “how to determine the type of data” is indeed subtle. The current order is
by magic bytes
by response content type
by file extension
and I think this makes sense. But wouldn’t it make sense to extend the loader detection with something like
if (startsWithGzipHeader(data)) { // or 'while' ;-)
data = unzip(data);
}
?
(one could also check the content type, but with caveats)
Yeah doing something like that would be reasonable @Marco13. At the moment, though, all the gunzipping is handled automatically by Unreal’s libcurl according to HTTP response headers. So to add something like that, we would first need to integrate a gunzip implementation that we can call from cesium-native. Or perhaps add the necessary indirection so that we can use Unreal’s.
@FrancisCheck we’re not aware of any action on our end for that. Let me know if I have that wrong. Either way, perhaps something has changed in Reality Capture to improve its compliance with the 3D Tiles spec?
Unfortunately, I don’t think there has been any updates. I’ve been testing this over the last few months occasionally, and there has been no progress made. It does seem to throw up different error codes now than before, but it never displays the tile sets.
Is there a sample tile set I could perhaps download and try? I have a big project coming up that will require hosting data locally. I’d really like to get this figured out once and for all.
Sure, there’s an example tileset linked in the section of the tutorial that explains how to use local data:
But I’m not really clear on what problems you’re having with the Reality Capture tileset. Aside from some subtleties with gzip discussed above, it should work. (Reality Capture may output gzipped files, but when loading from a file URL, Cesium for Unreal has no way of knowing this is the case, so it will be unable to interpret the files correctly. The solution is to manually gunzip the files output by Reality Capture)
Can you share a small, non-working tileset with me and I can take a look?
I can’t believe it, but I just figured out what was causing the issue. The errors were indeed caused by gzip. I just noticed that you can modify the compression method in the dialog box before exporting.
So, in order for scan data to work within Cesium for Unreal, set the compression method from “Gzip” to “None”. I can now load tiles with no issues inside Unreal Engine!
Thank you all for your help! I’m glad we can check this one off the list.
