Ben Golus writes technical articles on graphics and shader programming, including outlines, mipmapping, and grid rendering in Unity.
HN commenters praise his depth, liking the Jump Flood outlines article and linking his posts on texture filtering and sphere rendering.
There's a really good blog post about the engineering of mipmaps from the perspective of mipmapping messing up their VR game's text legibility here:
https://bgolus.medium.com/sharper-mipmapping-using-shader-based-supersampling-ed7aadb47bec
(May have been featured on HN recently, I can't remember how I got there).
Often mipmaps are pretty much automatic from the player's perspective, it's often kind of baked in by the developers when processing the texture files. It can probably be disabled but I can't remember seeing that option in a game for a while.
I'm curious to see how Bevy's doing it. I'm making a game in Godot at the moment, and their is the option there to generate mipmaps or not for an imported texture, and you can choose use a bilinear or trilinear filtering for the mipmaps, but that's about it (maybe there's more in the API, I haven't checked.)
> Maybe what I'm asking for is impossible, because fighting those patterns any further would just go too far into blurry territory. It might just be an inherent property of projecting something on a grid of neatly ordered pixels, which is very unlike the receptors in our eyes.
Basically it solves this exact problem - that rendering a high res image at a lower size can lose details at points you don't want them to (e.g. because some part of the texture like a line is entirely in subpixel "space"), and pre-processing a lower res image to switch to at different distance thresholds from the camera. The result is actually…
A lower FOV actually translates to better PPD. You can use a basic formula: sqrt(hRes^2+vRes^2)/FOV. So a 100 degree FOV would give you about 36PPD, but a 90 degree FOV would actually give you an even better 40PPD. 60PPD is Apple's target for a "Retina" display, although there's a strong argument that you need double that at least for line pairs. For computer work purposes, we really should only care about matching PPD of a monitor. 36PPD is about equivalent of a 27" FHD monitor from 2ft/60cm: https://qasimk.io/screen-ppd/ and is probably good enough to start on focusing on other aspects of your optical design.
For a bit more nuance, here's a nice article that talks about how rendering geometry maps to FOV https://risa2000.github.io/vrdocs/docs/hmd_fov_calculation.html although notably this does not account for the distortion shaders used in modern HMD pipelines to correct both for geometry and chromatic aberrations. There can be more techniques for improved text rendering, like what Oculus does with their timewarp layers: https://www.facebook.com/permalink.php?story_fbid=1942692682631906&id=100006735798590
For those interested, here's some discussion focused on optimal text rendering in 3D engines: https://bgolus.medium.com/sharper-mipmapping-using-shader-based-supersampling-ed7aadb47bec
In a previous thread, @kanetw was actually kind enough to chat in more detail about some of the Simula's optical specs: https://news.ycombinator.com/item?id=29930547
For some basic…
I loved the article that this links to about 'Jump Flood Algorithm'!:
https://bgolus.medium.com/the-quest-for-very-wide-outlines-ba82ed442cd9
So fascinating! Thanks for indirectly leading me to this! I love thinking about all the various approaches available at the pixel/texel/etc level!
It's also another case where it's a very clever way of generating a type of SDF (Signed Distance Field) that is doing a lot of the heavy-lifting. Such a killer result here as well! Any-width-outline-you-like in linear time?!! Amazing when compared to the cost of the brute-force ones at huge widths!
I wholeheartedly endorse SDFs, whether they are 'vector' ones, function-based, like Inigo Quilez's amazing work, Or 'raster' ones like in the article, texel-or-voxel-based. Houdini supports raster-SDFs very well I think, has a solid, mature set of SDF-tools worth checking out (there's a free version if you don't have a lic)!
And of course there's all the many other places SDFs are used!! So useful! Definitely worth raising-awareness of I reckon!
True, this is something I struggled with writing and ended up with just a small note commenting that this is not widely applicable. Will clarify more in coming posts. It's all incredibly context specific. The reason for this order, is that you can very much can use all these approaches (SSAA, FXAA, MSAA etc.) for rendering simpler shapes and HUDs. So going through them, where these approaches break down and when it does make sense to go the extra mile with SDFs.
Still, non-standard rendering approaches are very much a thing [1] and I could see setups like [2] be used in scientific particle visualizations.
[1] https://www.youtube.com/watch?v=9U0XVdvQwAI
[2] https://bgolus.medium.com/rendering-a-sphere-on-a-quad-13c92025570c
This is one of those things that feels like a broken/half-assed/oversimplified implementation got completely proliferated into the world a long time ago and it took several years for the right person to do a full-depth mathematical analysis to reveal what we should've been doing all along. Similar to antialiasing and sharpening, texture filtering, color spaces and gamma correction, etc.
It reminded me of this article specifically: https://bgolus.medium.com/the-best-darn-grid-shader-yet-727f9278b9d8
SV_Depth disables early z culling for that draw. But doesn't disable early z culling for subsequent draws. It does disable some z buffer compression that some older / mobile GPUs implement, but that's less of an issue for modern GPUs.
As for disabling early Z culling when drawing the impostor, the section titled "Fragmented Depth" covers this problem, and the solution.
https://bgolus.medium.com/rendering-a-sphere-on-a-quad-13c92025570c#bb36