aplavin

> I do wonder if you do like, size estimates of a black hole in my room. Suppose I have a black hole in my room, I'd be curious to know what the mass of that is, like a fun fact, tidbit somewhere.

Forgot to answer this first!

Basically, ~1 cm radius black hole has the mass of the Earth – really, Earth would need to get this small to become a black hole. I've made a very simple demo for a kids lecture I gave recently, https://plav.in/outreach_demos/squeeze-earth-v2.html. Also see https://xkcd.com/1680/ of course :)

Would MSAA compute more samples, effectively multiplying shader computation? Ideally, it should be something adaptive, to the number of pixels/device compute power, eg compute 2x smaller resolution on phones/retina, compute 1x resolution on larger-pixel screens, and maybe even 1x + MSAA beyond some pixel sizes... Just wanted to avoid reinventing these heuristics.

> I thought "oooh this is interesting I wonder how they are going to do physically accurate on an end device" Recalling how the original particle sim was something like 100TB, took 2 weeks to generate and seemed to write in a way that killed disks. but that was >10 years ago, so what clever stuff has been done to model it locally.

Yes, totally reasonable question! Those terabytes surely were things like fluid/matter motion around the black hole, stuff like this.

Here, I definitely don't simulate matter motion around the black hole as a particle/fluid sim does – instead, I focus on simulating the effects of the black hole itself. Matter distribution and motion (where it is used at all, ie not in camera mode) is described by simple functions phenomenologically.

The single most notable effect of a black hole is strong light bending (+ time delays), and it is properly simulated in all modes in this app. Next, relativistic beaming (Doppler boosting) and gravitational redshift are simulated for the accretion disk emission as well. If you zoom out, the jet is visible as well – it's relatively far away, so it is rendered with special relativity only; ie, no GR, but full volumetric rendering taking all SR effects into account. Admittedly, the GR-SR seam implementation can be improved somewhat.

Hmmm I think I see what's happening here. Basically, all devices I tested (laptops/phones/tablets) seem to have small pixel size, and to save on compute power for weaker devices I decided to render with half as many pixels as the screen has, letting the browser upscale the result. In your case, pixels are probably quite a bit larger, and half-res rendering has these prominent artifacts.

Can you try if increasing "render scale" in params->display helps?

The vast majority of scientific images, be it in papers on press releases, are using an arbitrarily-chosen colormap to map whatever numeric values are there to actual visible pixels. For the Event Horizon Telescope speficially – it is a radio telescope, so what it sees has no intrinsic "color" as perceived by a human eye at all. Same with this simulation here.

To describe cow's gravity? Pretty much so. Then, for visualization and even for many biological purposes, it's accurate enough to mode the cow as a bunch of organs with known processes happening in them. But that's still far from atoms and quarks that constitute the cow.

>> I follow the by-far-dominant approach in scientific literature, where color mapping choice is completely unrelated to physical accuracy of the plotted observations or simulations.

> It is not true at all that this is the dominant approach in the literature

Just to clarify: you are saying that there are not a lot of images in literature rendered with a non-perceptually-uniform colormap (eg, any matplotlib colormap aside from the 5 uniform ones)? Or that there is only one correct way to choose colormap for a given image?

> why the stars surrounding the black hole are just points, and more over why the lines are straight to the centre of the hole

Sorry for confusion! Points + lines are just other users looking at the black hole right now, their camera locations and lines of sight. Nothing more! In the first hours of HN frontpage, there were a lot – and I can see how one can understand them as parts of actual scene :)

I decided not to change their style, not to make them more subtle – half a day later, there are already way fewer users online, and these points/lines don't look as crowded as they did.

That would be fun indeed! Not sure I would literally want to put this into my room though.

You mean, without a camera and a screen, out of pure physical objects? You can actually reproduce gravitational light bending quite accurately with a properly-shaped lens (some wine glasses are surprisingly close!), see eg https://www.youtube.com/watch?v=PviYbX7cUUg for a classical wine glass experiment, or https://sites.google.com/view/jeansurdej/gravitational-lense... for purpose-made lenses. It only reproduces the so-called "weak field" bending, not light that makes half a turn (coming from behind you) or more.

Could you please share a screenshot so that I investigate what actually happens? I tested on a few different devices, but far from anything extensive.

Hmm, interesting! I saw that it's a draft, and didn't investigate further. Maybe it does work indeed on some browsers.

Generally, the compatibility story turned out more fragmented than I expected. Eg, on my phone, Chrome can do AR – but cannot do two camera feeds at once; while Firefox is the exact opposite – no AR but can do both cameras at once, so that you see both front and rear lensed around the black hole properly (in the camera mode).

> not using a perceptually uniform colormap in the year 2026 is quite a blunder

Then you are up for a big surprise if you browse through modern published papers :)

> What exactly is physically accurate here though?

I'll assume this is a good faith question, hope it was intended like one. I view strong light bending as the key distinguishing property of a black hole, and something we are fairly certain about. This is reproduced accurately in all modes, up to the fundamental technical constraints of the browser environment. Gravitational redshift is another one, and it's also reflected.

Things like the precise matter configuration in the disk (and correspondingly its radial brightness profile) are much less well known, and are less fundamental for black holes as objects. This part is represented in a simplified way – thin disk, with a reasonable-shape analytic function defining radial emissivity distribution.

As for colormapping: I follow the by-far-dominant approach in scientific literature, where color mapping choice is completely unrelated to physical accuracy of the plotted observations or simulations. Having a preference for different color schemes is a matter of taste; suggesting a linear intensity->pixel mapping is a reasonable feature request, but far from a bug or inaccuracy.

Note that most of the points you raised are clearly not bugs – most notably, things like non-rotating black hole or colormap choice. At the very most, these can be considered missing features, but they don't affect correctness in any way.

Arguing about colormap choice seems very strange to be – this is such a common practice in astronomy (and other fields!). The vast majority of images you see in published papers apply some arbitrarily-chosen colormap and color scheme. No matter if you look at observational or theory papers, it's very rare to find a real true-color image. And for a bunch of good reasons!

The only difference here is that I don't show a colorbar with explicit color-number mapping, for simplicity sake.

That option for rotating (Kerr) black holes generally works, but not on all devices in my experiences. Debugging on someone's phone is not that straightword, so I went with the most accessible experience by default.

Also note that the visual difference for the camera warp is really marginal between rotating vs non-rotating black holes.

> AR + camera warping don't work together, unfortunately – browser API limitations.

So, you either choose AR and see the simulated emission from around the black hole, properly warped/boosted – but the camera feed remains flat, the browser itself does the overlaying.

Or, alternatively, choose the camera mode, and see the warping of your camera feed.

Not both at once!

Yes, even observing a single jet pointed towards us (typically, at just a few degrees) is routinely used a strong argument for existence of many similar powerful sources, just misaligned with the Earth. Arguments like:

- See a jet at redshift z ~ 6? There are thousands more!

- See that well-aligned blazar jets are among strongest gamma ray (or neutrino) sources? Gamma rays/neutrinos are preferentially emitted along the jet direction, otherwise we'd seen thousands more equally strong sources.

It's purely my color map choice – the underlying simulated image is simply a number at each pixel. Transforming that number to the actual displayed color is generally an arbitrary choice, as common for the vast majority of images in astronomy/astrophysics papers. The only difference is that I don't show a numeric colorbar here, for the sake of simplicity.

Sure, see https://blackhole.plav.in/ar_example.mp4 for an example. Should work on most Android phones, even old ones (mine is 7 years), the Chrome browser is generally best for AR.

Interestingly, Firefox seems to be better for the camera mode – for me, Chrome only gives one camera feed at a time, while Firefox allows both front & rear cameras.

And AR + camera warping don't work together, unfortunately – browser API limitations.

Sure, most of the raised questions are reasonable potential feature additions to be made – things like rotating black holes, or linear brightness-to-screen-pixel mapping. They just aren't "inaccuracies", in my opinion.

Eagerly awaiting WebGravity API support to control your device's builtin gravity field generator!

Yes, as said in the text, unfortunately this is a limitation of browser APIs. You either get AR and no access to the camera feed (this is the AR mode here, black hole floating in your room, simply overlaid on top of the camera feed) or get access to the camera feeds but no AR (this is the camera mode). I didn't find a way around it...

Colormap/colorscale is generally considered an arbitrary choice in scientific plots or visualizations. Linear mapping of simulated emission brightness -> screen brightness could be a reasonable alternative mode, I agree – but it's weird to say that colormap choice makes it not accurate.

Yes, linked in the readme! They simulate light bending, but ignore time delay effects.

I think the earliest of these black-hole-camera renderings is https://dominic-chang.com/bhi-filter/ though (also linked in readme) – a direct inspiration for the camera mode in my app!

> Its titled a "physically accurate black hole"! Please don't do this, if its intentionally not physically accurate and heavily simplified!

It also doesn't exert the gravity an actually accurate black hole should :) And also, even on a phone with two cameras, they only cover a part of sphere – while a real black hole would bend light coming from all 4pi directions. Some simplification is generally required ("the map is not the territory") and I don't see "simplified" as being opposite to "accurate".

Colormap choice: it can be a useful mode to show proper linear power -> linear perceived brightness mapping – true! But that's only one of many possible choices, and scales like logarithmic are very common in scientific images.

Now I think I see what you meant. There actually are no upper/lower limits on the black hole size (in classical physics – ignoring quantum effects). Compressing the Earth to ~1 cm in size would give you a black hole, and its event horizon size would be ~1 cm, not kilometers. And even black holes this small are stable, according to our physics knowledge.

Actually, the jet was the first part of the app – I wanted to just see and "feel" relativistic beaming in practice, in physical space. And it was fun and instructive indeed! Really puts into perspective how tight is the jet vs line-of-sight alignment for those bright jets we see across the universe. And how beaming is the dominant effect that determines the jet/quasar appearance.

Some are fair – of course this is a simplified visualization! Observationally, we don't really know how fast a given black hole is rotating, and here I indeed assumed a non-rotating one. It's not an inaccuracy per se, more like a missing feature. The camera mode has a (half-hidden) toggle to enable Kerr metric and set spin, but even there it's not a default.

I consider the colormap choice to be completely arbitrary though, without affecting accuracy. Basically, it represents intensity at a given frequency, the image like one would get from a telescope. It wasn't intended as a faithful optical color representation! And really, in my (admittedly biased) view of a radio astronomer, I tend to assume frequencies invisible to the human eye anyway.