Add bevy_anti_aliasing

[IceSentry]

Objective

• bevy_core_pipeline is getting really big and it's a big bottleneck for compilation time. A lot of parts of it can be broken up

Solution

• Add a new bevy_anti_aliasing crate that contains all the anti_aliasing implementations
• I didn't move any MSAA related code to this new crate because that's a lot more invasive

Testing

• Tested the anti_aliasing example to make sure all methods still worked

---

Showcase

before:

after:

Notice that now bevy_core_pipeline is 1s shorter and bevy_anti_aliasing now compiles in parallel with bevy_pbr.

Migration Guide

When using anti aliasing features, you now need to import them from bevy::anti_aliasing instead of bevy::core_pipeline

[alice-i-cecile]

That's a very sensible split. I would prefer this even with no impact on compilation.

[IceSentry]

Yeah, I've wanted this split for a long time for various reasons, but compile time started to be a big enough issue that it kinda forced me to do it.

[JMS55]

Why move RCAS to the AA crate too? I don't dislike it, but I'm not sure I like it either.

Also DLSS will added here shortly too, I suppose.

[IceSentry]

Why move RCAS to the AA crate too?

The main reason is that it depends on the FXAA node to be added first and since after this change that node only gets added in the new crate which is after the core_pipeline crate. This means it needs to live there for now. I'm also looking at making a bevy_post_processing crate where this could be moved to, but it kinda make sense to keep it with AA considering it's the main reason to use it.

An alternative solution would be to have a generic AntiAliasingNode that is just a label defined in core_pipeline and depend on that instead of the fxaa node directly.

[JMS55]

An alternative solution would be to have a generic AntiAliasingNode that is just a label defined in core_pipeline and depend on that instead of the fxaa node directly.

Don't think that's a good idea, unless we split it up between AA and TAA marker nodes. Lots of post processing effects need to go before/after TAA/DLSS/FSR/etc.

[hukasu]

I'm also looking at making a bevy_post_processing crate where this could be moved to

how many post processing methods does bevy offer today? if it is just RCAS, then having it by itself now would be too much IMO

i would go as far as having each individual algorithm behind a feature flag (bevy_anti_aliasing/fxaa, bevy_anti_aliasing/taa, etc), each of them have a internal asset for the shader and that is a few bytes you can shave off the binary

[IceSentry]

how many post processing methods does bevy offer today?

bloom, motion blur, depth of field, chromatic aberration, auto exposure. RCAS is kinda post processing too, but it's heavily tied to AA. There's also tonemapping but it's used in core pipelines so it's easier to keep it there and it's kinda a core part of pbr.

The goal isn't to reduce the binary size, it's to group things together that go together and also try to parallelize compilation a bit more.

We could feature flag each technique for people that really want to lean out their app, but most app should offer different AA techniques and let users decide what they prefer.

[JMS55]

Tonemapping I want to combine with our UpscaleNode into a new ResolveRenderTargetNode fyi, just haven't gotten around to it yet.

[JMS55]

In reference to my previous comment: #16721

[kristoff3r]

Seems like a reasonable split, tested the anti_aliasing example and it works

[cart]

I'm on board for this! I'm also fine with RCAS being in here for now. Maybe not its perfect forever home, but I don't think it is (currently) a high-traffic enough feature that we need to worry too much about breaking people (especially given that path changes are easy fixes).