Show meshes and images with rerun foo.obj bar.png

[emilk]

What

I was investigating a performance issue when loading .glb files and wanted a simple way to test this. So now you can run rerun foo.obj to quickly show a glb, gltf, obj, jpeg, or png file. Other image file types will also work if you enable their features in the image crate. You can also load multiple files at once, e.g. rerun *.rrd.

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct

PR Build Summary: https://build.rerun.io/pr/2060

[teh-cmc]

Nice to see this coming alive.

I find it a bit weird that one cannot load both a file and an HTTP resource at the same time, especially since the HTTP link will be treated as a path which will result in something along the lines of Failed to load "https://app.rerun.io/data/colmap_fiat.rrd": Failed to open file.

More importantly, I only see downsides to using MsgSender here: the feature doesn't seem to rely on sending messages at all, it just needs to crafts rows of data.
Implementing this directly as an extension to DataRow will make it reusable by others and remove the dependency on re_sdk.

[emilk]

I find it a bit weird that one cannot load both a file and an HTTP resource at the same time, especially since the HTTP link will be treated as a path which will result in something along the lines of Failed to load "https://app.rerun.io/data/colmap_fiat.rrd": Failed to open file.

Yeah, I agree it is a bit weird, but implementing this balloons the PR from "Support loading files" to also include things like "Support hosting multiple web viewers at once, all connected to different web socket addresses, while also showing a viewer which loads two different .rrd files at once" etc etc. Hence I am leaning towards leaving that as a ticket:

• Support loading multiple http:// and ws:// streams at once with rerun #2121

I will make sure to improve the error message though, and add TODO:s to the code

[emilk]

Added DataCell::from_file_path

[teh-cmc]

Nice!

Trying to load a non-existing file path results in the websocket path being taken, which might be very confusing to end users not familiar with what's going on internally:

[2023-05-16T07:31:23Z INFO  re_viewer::remote_viewer_app] Connecting to WS server at "ws:///home/cmc/Downloads/i_dont_exist.png"…
[2023-05-16T07:31:23Z INFO  re_ws_comms::client] Connecting to "ws:///home/cmc/Downloads/i_dont_exist.png"…
[2023-05-16T07:31:23Z ERROR re_ws_comms::client] Connection error: HTTP format error: invalid format

[teh-cmc]

nice

[emilk]

Trying to load a non-existing file path results in the websocket path being taken, which might be very confusing to end users not familiar with what's going on internally:

[2023-05-16T07:31:23Z INFO  re_viewer::remote_viewer_app] Connecting to WS server at "ws:///home/cmc/Downloads/i_dont_exist.png"…
[2023-05-16T07:31:23Z INFO  re_ws_comms::client] Connecting to "ws:///home/cmc/Downloads/i_dont_exist.png"…
[2023-05-16T07:31:23Z ERROR re_ws_comms::client] Connection error: HTTP format error: invalid format

Not sure how to fix that easily. It can be really hard to tell a file path from a websocket address. Is example.zip a file or a domain name?

We can add heuristics, like "ends with .png, jpg, …"… I'll do something

[teh-cmc]

Just pointing it out, don't think we necessarily have to fix today.

Maybe the easiest way for now is to add some explanation as to what's going on in the error message when everything else failed ("hey we tried opening 'xxx' as X, Y and Z and none of them worked").