aplavin

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.

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.