Rerun OSS beta is released | Hacker News Reader

Rerun OSS beta is released

rerun.io

221 pointsfdb18 comments

Hi there - CTO of Rerun here!

Rerun is still in beta, but we think it’s already good enough to be useful. It is built on wgpu, Apache Arrow, my own egui.rs library, and it also runs as Wasm in the browser.

I'm happy to answer any questions you may have!

PS: Thanks for the shoutout fdb!

I came across rerun from egui too. Egui is a very good marketing funnel.

A bit tangential, but since you're using wgpu in your own product now, do you have any plans to switch to using wgpu by default in eframe, and possibly even eliminate glow? I'm just curious; this probably doesn't have any effect on anything I'm working on. Anyway, eliminating the multiple code paths in eframe would be nice.

Switching to wgpu as the default is a definite possibility, but something should be said for the simplicity of the glow backend. wgpu is a big beast, which takes more time to compile, and for a lot of eframe users it is simply over-kill.

…but then again, if you want simplicity and fast compiles, I can recommend the egui-miniquad backend. It's not as fully-featured as eframe, but with some love it could definitely get there.

A video of it working might be really good, it might make it clearer what this does.

here are some pictures, if like me you have no idea what this is:

https://www.rerun.io/docs/getting-started/examples

I’m currently learning Open Drone Map and Nerfstudio. I feed aerial imagery to them, wait a long while, and then evaluate their output. Then I start over. I wonder if I could log intermediate results to Rerun and perhaps see faster how the work goes. Though I’d need to integrate Rerun logging into the pipelines somehow. In any case the demos on the site looked really nice.

This sounds like the exact kind of workflow that Rerun is intended to support. Any logged data will immediately show up in the Viewer, which runs in a separate process. That said, you are correct that you would need to instrument some function with the rerun log calls to send the data.

The rr command is already somewhat well-known as a debugger from the rr-project[0]. Rerun is definitely inspiring, and good tools do that. Brett Victor is a great inspiration, I’m glad I saw that his work inspired rerun, that’s cool.

[0]: https://rr-project.org/

Exciting! Looks very promising, especially for 3D stuff. I have one task coming up which is to filter somewhat noisy point clouds of body parts. Would you say Rerun is a good tool for that?

Congrats. I'm also a COSS founder and think this is a very smart step for a product like rerun. Feel free to ping me if you want to chat open-source more.

Congratulations!

Thanks! It will be fun to hear what people think after giving it a try

excited to give it a try!

IMO relevant blurb:

> Rerun is an SDK for logging data like images, tensors and point clouds, paired with an app that builds visualizations around that data. We built Rerun for computer vision and robotics developers. It makes it easy to debug, explore and understand internal state and data with minimal code. The point is to make it much easier to build computer vision and robotics solutions for the real world.

I got confused by the usage of the term "log" (and the word gets used so much in many pages that I hit semantic satiation).

> When you log data to the Rerun SDK, Rerun handles everything needed to visualize it. It handles live streams from multiple processes across the network, as well as simple playback from recordings. That means taking care of serialization, transport, synchronizing streams, out-of-order data, and automatically constructing visualizations with sane defaults.

so is "record" / "recording" the right concept? When I think of logging I think of exactly lines in a text file (or maybe the "log" from a logging filesystem).

One of the founders here. I totally see where you’re coming from. If you come from a world where log equals text, then using log for anything else seems strange.

In robotics and autonomy, “log” is commonly used for e.g. sensor data or planning decisions as well. But even outside those fields it isn’t uncommon to talk about logging metrics for instance.

Still, no metaphor is perfect and we have spent a lot of time discussing what word to use. “Record” gives me the sense that the main purpose is to save the data for later. Rerun is also about the live use case. There words like “stream” or “send” could work perhaps.

In the end we decided on “log” because it is short, is already used in a similar way in some of the areas we hope Rerun will be used, and because data can either be stored on disk and/or be streamed/uploaded somewhere (like with regular text logs).

Hello -- Rerun developer here. You are correct on both counts. The terminology used in some places is a bit inconsistent, and "recording" is very much the right concept to apply to the data that Rerun captures.

However, one of the reasons we tend to think of our APIs as being "logging" like is that much like other console-logging libraries, the primary purpose is to get data out of your program and into a user-observable form. Also similar to other logging libraries, the APIs are intended to have no side affects on your program so they can actually be disabled with a function call or by setting an environment variable in situations where you don't need the additional context for debugging or inspection.

I appreciate the feedback though and will make sure to take a pass on the docs to see if I can make the relationship and intent a bit more clear.

Reply on news.ycombinator.com