Notes on reducing bevy_gltf dependencies on render crates

[greeble-dev]

These notes attempt to answer the question "why and how would we make bevy_gltf less dependent on rendering crates?". For a TLDR jump to the conclusions at the bottom.

Why?

bevy_gltf currently depends on bevy_render and bevy_pbr. This puts it on the critical path for compiles:

If Bevy acquires more importers then they'll likely have the same issue. Reducing dependencies would also help alternative renderers, but I'm assuming that's more of a bonus than a requirement.

Asking how to reduce dependencies may be useful for the render crate restructure. That discussion has mostly focused on the needs of the renderer, but reducing dependencies is a worthy goal too. Working through a specific case like bevy_gltf could be helpful.

These notes assume that the render crates will be split into smaller crates (e.g. bevy_camera), and there's also a possibility of "data only" crates (similar to how wgpu has a separate wgpu-types).

Background

bevy_gltf turns .gltf files into Bevy-specific assets and scenes. Right now bevy_gltf is commonly used to load files and hand the results straight to the main world and render world. But it can also be an asset processor that reads glTF files and writes Bevy-specific files, and that might be done by an app without a renderer.

There's a possibility that bevy_gltf could itself be restructured to reduce dependencies. This might also fit in with sharing code between other file importers. I'm gonna leave that to one side to avoid complicating things.

bevy_gltf currently depends on wgpu-types through bevy_mesh and bevy_image re-exports. I'm assuming this is not a problem right now.

How?

This section works through all the dependencies I could find and speculates on solutions.

• bevy_render
  • alpha::AlphaMode
  • mesh::MeshPlugin
  • renderer::RenderDevice.
• bevy_pbr
  • DirectionalLight
  • MeshMaterial3d
  • PointLight
  • SpotLight
  • StandardMaterial
  • MAX_JOINTS

The Easy Bits

bevy_render::AlphaMode is a simple enum. I'm not sure which crate it should go in, but seems unlikely to be a major issue.

bevy_render::MeshPlugin is used by bevy_gltf tests (source). Maybe that's fine and bevy_render goes in [dev-dependencies], or maybe the test moves to another crate.

bevy_pbr::MAX_JOINTS is used to print a warning if the glTF has more joints than bevy_pbr can handle (source). I think this warning should move into bevy_pbr, because an asset processor shouldn't be limited by a particular renderer. But making it user friendly might be a problem.

RenderDevice, CompressedImageFormats

(UPDATE: Resolved in #19190)

bevy_render::RenderDevice is used by GltfPlugin::finish to grab bevy_image::CompressedImageFormats for the current GPU (source). This is not used directly by bevy_gltf but gets forwarded to bevy_image::Image::from_buffer. There it's used to choose transcode formats or bail if a format is not supported.

Depending on the current GPU is problematic for asset processing, so there should at least be an option to ignore it. Breaking the crate dependency is trickier. Maybe bevy_render could initialise some global resource Res<CurrentGpuCompressedImageFormats> that doesn't depend on bevy_render types. Then bevy_gltf or bevy_image can find the resource and optionally use it.

Render Components/Assets

bevy_gltf can spawn the DirectionalLight, PointLight, SpotLight, MeshMaterial3d components, and create a StandardMaterial asset.

The light component structs have few dependencies, so they could move to a data only crate or a finer grained render crate. The catch is that their required components pull in more low-level render types and functions.

#[require(CubemapFrusta, CubemapVisibleEntities, Transform, Visibility, VisibilityClass)]
#[component(on_add = view::add_visibility_class::<LightVisibilityClass>)]
pub struct PointLight {

Maybe the solution is for a lower level render crate to do App::register_required_components, so the crate with PointLight and others can remain independent?

The MeshMaterial3d component struct doesn't seem to have any dependencies, so could probably move to a data only crate or a bevy_material crate.

The StandardMaterial asset is trickier as it uses attributes like bind_group_data and bindless. I guess it could be split into a plain data asset type, and a second lower-level non-asset type that does the bind group stuff and is only used in the renderer? I don't know enough about the renderer to say if this is feasible.

Conclusions

• Reducing dependencies would likely help compile times, along with some smaller benefits.
• bevy_gltf mostly depends on creating render component and asset data, not running render code.
• The toughest nut to crack is StandardMaterial, which might have to be refactored to separate the data from lower-level dependencies.
• Other render components should be simpler. The main sticking point is who declares required components.

[mgi388]

Two quick thoughts after reading this, which hopefully help you:

1. Re StandardMaterial dep. No idea if this is helpful, or if bevy_gltf's use of StandardMaterial is too complicated, but I have a create which decodes a mesh format and I pass in a material loader to my plugin like this: https://github.com/mgi388/darkomen/blob/5a04fbbfa8eacb180f60d9ab48284d9d0ebd7870/src/asset/m3d/mod.rs#L30-L65
2. Re bevy_pbr::MAX_JOINTS usage, and the warning. I wonder if we can keep the warning where it is, but just pass the limit into the plugin. Then, callers of the plugin can depend on bevy_pbr. The idea is that you tell bevy_gltf through a plugin variable what its limit should be, rather than it reaching into engine internals to ask about it. I would assume that helps in this case, but I didn't check.

[greeble-dev]

Re materials, my guess is that bevy_gltf uses so much of StandardMaterial that any abstraction will end up recreating most of it. But maybe that's fine - I guess it depends on whether the render folks view StandardMaterial as a cross-renderer abstraction or specific to bevy_pbr.

Re MAX_JOINTS, that's a good point. Also fits with CompressedImageFormats being optional. But I'm unsure whether respecting the limits should require the user to pass them explicitly or if bevy_pbr automatically registers them... explicitly sounds safer, but many users might not realise it's there.