Distill Integration

[B-Reif]

The Bevy community continues to discuss Distill integration in several places. I'm creating this thread to compile previous discussions, identify our needed design decisions, and ultimately make a list of boxes for an RFC to check.

Resources

• @cart initial discussion with Kae on (then atelier-assets) adoption
• Userland integration crate by @jakobhellermann
• Existing bevy issue Migrate Bevy Asset System to Distill #708 was created in October last year. It looks like some of the checkboxes here have been met in subsequent Distill updates.

Questions

• What's involved in the creation of a bevy_asset integration layer? This is currently one checkbox on Migrate Bevy Asset System to Distill #708 and it would be nice to enumerate what exactly is needed here. It's possible that bevy-asset-distill comes pretty close already.
• What's the status of the packfile feature in Distill? Based on a quick search, the packfile feature looks implemented. I'm not sure if it currently checks all of the boxes in Migrate Bevy Asset System to Distill #708.
• What's the status of the Bevy task features? What's needed to implement these?

[jakobhellermann]

Based on a quick search, the packfile feature looks implemented.

Yep, Packfile support works for any platform.

What's the status of the Bevy task features? What's needed to implement these?

I'm not sure if any additional features to bevy_tasks are needed. Currently the packfile loader has an IoTaskPool and the deamon rpc runtime uses an async_executor::LocalExecutor directly which seems to work.

• Migrate Bevy Asset System to Distill #708 also mentions Wasm asset hot-reloading via something like websockets or WebRTC which is implemented by RpcIO on wasm amethyst/distill#112

[jakobhellermann]

One more unresolved question to me is when to enable which features.

For development you usually want to start an asset daemon which listens for file changes in the background while in release you probably want to bundle all assets into a packfile and ship that with the app.

It would be very annoying to have to run cargo run --features bevy/asset-daemon in development, but if we add asset-daemon to the default features you have to run cargo build --release --no-default-features --features all,the,features,required if you want to have a release build without the daemon code in the binary.

[mockersf]

I think it would be OK to have to enable different features for development and release. It could be mentioned in the "how to release a Bevy game" guide #1885 and the "how to develop with Bevy" guide (but I don't remember if @alice-i-cecile opened a ticket for that yet)

[alice-i-cecile]

My plan was mostly to have "how to develop with Bevy" as part of a later book chapter :) There's a stub in place in the outline already.

[minecrawler]

It would be very annoying to have to run [long cargo commands].

Don't most IDEs have run configurations? At least the JetBrains platform and VSCode have, but I assume the same of others... So I think that it wouldn't be too bad to require certain CLI switches or environment variables for development and release builds.

Alternatives I see are:

• revisit CLI tools and have bevy run [ENV], where [ENV] is a runtime config in a file (configurable!)
• revisit CLI tools and have bevy run dev, where dev is a hard-coded config for development (quick-start! Fallback to feature switches for configurability)
• just tell people to use the bevy editor tools, which will offer a solution (profiles / buttons / ?)

[jakobhellermann]

One more thing: Distill assets currently don't implement Default.
This is annoying because e.g. PbrBundle has a non-optional Handle to a mesh.
There are multiple solutions to this:

1. impl Default for Handle in distill, where the resulting handle is some kind of dummy handle (like it is in bevy right now)
2. In situtations like PbrBundle, provide a default asset which is used in the Default impl, like a unit cube for a mesh or a checkerboard texture for images