Optional explicit compressed image format support

[DGriffin91]

Objective

• Allow compressed image formats to be used with ImagePlugin and GltfPlugin in cases where there is no RenderDevice resource. (For example, when using a custom render backend)

Solution

• Define a CompressedImageFormatSupport component that allows the user to explicitly determine which formats are supported.

Not sure if this is the best solution. Alternatively, I considered initializing CompressedImageFormatSupport from render device features separately, it would need to run after the render device is initialized but before ImagePlugin and GltfPlugin finish. Not sure where the best place for that to happen would be.

Update: decided on going with @greeble-dev solution: defining the CompressedImageFormatSupport resource in bevy_image, but letting bevy_render register the resource value.

[greeble-dev]

I've sketched out an alternative solution: define the CompressedImageFormatSupport resource in bevy_image, but let bevy_render register the resource value. This has the advantage that bevy_gltf and custom renderers wouldn't need to depend on bevy_render. Might be worth considering?

main...greeble-dev:bevy:gltf-compressed-image-format-support

It feels awfully fragile to rely on plugin initialisation order... if anything goes wrong then it silently fails. But I think that's kinda true of the current situation and this PR as well, so at least it's not a step back?

[DGriffin91]

@greeble-dev I think I like your alternative design better. It's similar to the alternative I mentioned, and now seeing it I think I like it better than what I initially had. The plugin order initialization issue is unfortunate, but it does seem like bevy was already dependent on the initialization order that this requires, so agreed that it doesn't seem like a step back.

One thing to note, your example is missing the extra check needed here:

bevy/crates/bevy_render/src/texture/mod.rs

Line 114 in 673e70c

let supported_compressed_formats = match app.world().get_resource::<RenderDevice>() {

But I tested adding it there and it seemed to work as expected.

@greeble-dev How would you like me to get your changes into the PR? I want to make sure you get credit on the commit. I'm fine adding the check in bevy_render and the needed docs. Thanks!

In case it's helpful for testing here's a version of the FlightHelmet using BCn textures: FlightHelmetBCn.zip

And a minimal usage example:

use bevy::prelude::*;
use bevy_image::{CompressedImageFormatSupport, CompressedImageFormats};
use bevy_render::{settings::WgpuSettings, RenderPlugin};

fn main() {
    App::new()
        .insert_resource(CompressedImageFormatSupport(CompressedImageFormats::BC))
        .add_plugins(
            DefaultPlugins.set(RenderPlugin {
                render_creation: WgpuSettings {
                    backends: None,
                    ..default()
                }
                .into(),
                ..default()
            }),
        )
        .add_systems(Startup, setup)
        .run();
}

fn setup(mut commands: Commands, asset_server: Res<AssetServer>) {
    commands.spawn(SceneRoot(asset_server.load(
        GltfAssetLabel::Scene(0).from_asset("models/FlightHelmetBCn/FlightHelmet.gltf"),
    )));
}

[greeble-dev]

@DGriffin91, no credit necessary :]. I'm fine if you want to copy across whatever works for you.

Re the missing check, that got me thinking that this PR unlocks the possibility of moving the registration of ImageLoader entirely into bevy_image? Which is a scarier change and too big a step for this PR, but seems to align with the general direction of moving stuff out of bevy_render (#15812).

[DGriffin91]

CI appears to be failing for reasons unrelated to the PR

[greeble-dev]

For the benefit of other reviewers - this is not adding a dependency, just making it explicit. Previously was implicit bevy_image -> bevy_app -> bevy_ecs.

[tychedelia]

This seems sketchy but not your place to refactor plugin initialization. I guess it's okay for now!

[alice-i-cecile]

Marking down as something to consider for #69.