[_cart]

The aliasing you're seeing is "texture aliasing" from a lack of mipmaps. We have an implementation in the works, it just didn't make it into this release. This is a straightforward and well understood problem. Thankfully our mesh edges are already crisp (thanks to MSAA) and we have a number of other anti-aliasing implementations in the works (TAA, SMAA, FXAA), each with their own strengths and tradeoffs.

[chmod775]

That's cool - as are mipmaps, but even with those you'll still have patterns emerge that don't exist on the original texture. Humans are really good noticing patterns, so they're distracting (a tiled floor doesn't doesn't look like it has u-shaped curves in reality). Those patterns not having sharp/grainy edges anymore already helps a lot though.

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.

Though to be honest, I didn't even consider that it may just be missing mipmaps making it look like that. My perspective is much that of a consumer who spend a lot of time trying out various settings/technologies and ordered them into "looks bad" and "looks better".

[lewispollard]

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-ba...

(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 better details at scaled down sizes, with much less flickering, even though the actual rendered texture at a distance can be much lower quality.

They can also save a bit of GPU power and possibly VRAM, as the lower res, distant textures stream much more quickly than the ultra high res, near ones.

[camjw]

> (May have been featured on HN recently, I can't remember how I got there).

John Carmack tweeted about it a few days ago (it always annoys me when I can't remember where I saw something).

[lewispollard]

Ohh, yes that's right, thanks!