Add LUTs generation on fly if ktx2 is not enabled#13734
Add LUTs generation on fly if ktx2 is not enabled#13734bugsweeper wants to merge 2 commits intobevyengine:mainfrom
Conversation
Cargo.toml
Outdated
| "bevy_internal/bevy_core_pipeline", | ||
| "bevy_asset", | ||
| "bevy_render", | ||
| "bevy_pbr", |
There was a problem hiding this comment.
I don't like pulling in bevy_pbr here. What's causing the failure?
There was a problem hiding this comment.
which wants bevy_pbr for Opaque3dPrepass bindings initialization
There was a problem hiding this comment.
Let me pull in rendering folks, but I think the correct solution is to actually move that code.
There was a problem hiding this comment.
I said about this initialization in description
There was a problem hiding this comment.
I think the correct solution is to actually move that code.
Which code are you proposing to move? Is this Core3dPlugin from bevy_core_pipeline to bevy_pbr?
|
|
As I mentioned in PR there are dependencies, should SmaaPlugin, Core3dPlugin become optional, or everyone must enable all necessary features manualy? |
I'm pretty sure we should move the offending code out of |
|
for ktx2 / ztsd features, like tonemapping LUTs being behind a feature |
179be1d to
ec1d77d
Compare
ec1d77d to
43b9848
Compare
There is only SMAASearchLUT (SMAA search look up table) recreated, SMAAAreaLUT is not ready yet, and I didn't do anything about
|
1ed5bb7 to
7edff96
Compare
|
Generator for search LUT generates exactly the same table, generator of area LUT generates table which absolutely differs up to 2 for some pixel colors. I think it's due to compression loss in ktx2 (Generators are even more precise) |
|
At this moment only bevy_core_pipeline dependences from ktx2/zstd are fixed |
@alice-i-cecile Sorry, I tried to move out code from bevy_pbr to bevy_core_pipeline, that code appeared to be very dependent. As I mentioned earlier The journey started from |
7edff96 to
acea9e2
Compare
|
Sounds good, let's land something more scoped. |
Changes to replace loading SMAA LUT from ktx2 files are done. This PR is no longer waiting for the author. |
|
Should I make unit/integration test (maybe ignored by default) from test code in PR description? |
|
I'm on the fence about an integration test. On the one hand, this is hard to avoid breaking. On the other hand, I worry about the test being brittle. I'd prefer to set up integration tests for feature flags in a separate PR, since they're quite complex to design. |
|
My 2cents: Generating LUTs is a lot of code for no good reason. SMAA just shouldn't be usable without ktx2. Furthermore, we don't need to put SMAA behind a new smaa cfg. We can leave the majority of the code exposed without a feature flag, and simply put the LUT load behind a cfg for ktx2, and panic if ktx2 is disabled. Alternatively, we can include the raw bytes of the image within bevy's binary directly, without parsing it as a ktx2. |
|
The original purpose of this has been superseded by #14020, and I agree with Jasmine's comments above. |
Add LUTs generation on fly if ktx2 is not enabled
Objective
0.14.0-rc.2, minimal app withbevy_core_pipelinecrashes withoutktx2,zstd, andbevy_pbr#13728 .For example
bevy_core_pipelineaddsSmaaPluginwhich wantsktx2textures,ktx2useszstdfor supercompressionSolution
smaa_luts. If enabled SMAA uses LUTs from ktx2 files, if disabled SMAA uses LUTs generated on fly. Generators are based on on Jorge Jimenez code for AreaTex and SearchTexTesting
0.14.0-rc.2, minimal app withbevy_core_pipelinecrashes withoutktx2,zstd, andbevy_pbr#13728 with enabled bevy_pbr and got no panics