[chmod775]

It looks great in a lot of respects, but I can't help but notice the aliasing. In the example scene at the top, when in motion, it probably looks like there's a snow storm going on in the foliage and on most of the wall/floor textures.

To me good anti-aliasing strategies is the single most important factor when it comes to graphics. I don't really care about things looking realistic or whatever, but I do care about my screen not being full of moving, weird, and distracting grainy patterns.

This involves more than just softening the edges around polygons. There's also textures that contain shapes and the borders in textures with transparency to think about (usually foliage).

My go-to solution in games with lackluster anti-alias is to just render them at a super-high resolution (4k/8k) and downscale, but that's not great for performance usually. You can compensate a bit because you won't need as much anisotropic filtering and such if you downscale, but even on expensive hardware that's not a solution in all games.

To get to the point: In some older games I've seen blurring (possibly due to hardware limitations) of further-away detailed textures reducing aliasing. I'd love to see that technique revived in more modern games, possible with the help of AI to detect patterns/edges on textures that may be susceptible to aliasing, and selectively running those through a filter - basically shifting the work from the artists having to design textures that don't create artifacts to something automatic.

In general good AA tends to be a second-class citizen in many modern game engines, partly because of how their renderer is configured by default (looking at you, Unreal). I really wish it wasn't so.

[_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!

[rl3]

This release primarily constitutes a massive rendering API rework. You can think of it more as a foundation that makes it easier to implement better rendering features in the future.

If you check the release notes, you'll see HDR/Bloom support was dropped at the last minute, and several other major rendering features are still pending implementation. [0]

The great part about Bevy is that it's modular, so you can swap out the renderer if you like. For example, there's already several people using Bevy with Embark's kajiya renderer.[1]

[0] https://bevyengine.org/news/bevy-0-6/#more-renderer-features

[1] https://github.com/EmbarkStudios/kajiya

[posix86]

You're the first person I see that also has this position! Anti-alias makes the difference between an image looking like it's a rendered set of datastructures by a computer, or if it's a virtual world you happen to have an image of. All other aspects of graphics - light, shadow, texture resolution, polygon count - can be considered endearing style, but not aliasing and bad texture filtering.

[andrewmcwatters]

> To me good anti-aliasing strategies is the single most important factor when it comes to graphics. I don't really care about things looking realistic or whatever, but I do care about my screen not being full of moving, weird, and distracting grainy patterns.

I don't think I've ever heard this perspective before. Thank you for sharing your thoughts. This one is pretty unique, I think.

[masklinn]

> My go-to solution in games with lackluster anti-alias is to just render them at a super-high resolution (4k/8k) and downscale, but that's not great for performance usually.

By "lackluster anti-alias" do you mean some sort of home-grown MSAA that's garbage?

Because you're hand-rolling SSAA/FSAA, can't you just override the AA settings in the graphics driver to force FSAA or something?

[seoaeu]

> To get to the point: In some older games I've seen blurring (possibly due to hardware limitations) of further-away detailed textures reducing aliasing.

It sounds like your complaint might actually be with anisotropic texture filtering [0] which reduces the blurring you're describing, and is generally considered to improve quality.

[0] https://www.pcgamer.com/pc-graphics-options-explained/3/