Bevy People should be considered the source of truth for Bevy Organization roles. This replaces inline lists of maintainers and SMEs with links to Bevy People.
We are in the process of rolling out a new Bevy Organization role! (Subject Matter Expert)
This adds a new "The Bevy Organization" document and links to it from CONTRIBUTING.md. This doc describes how the Bevy Organization will work going forward. It outlines the functionality of each role, as well as the expectations we have for them. The previously existing roles (Project Lead, Maintainer) still work the same way, but their definition and scope have been made much clearer.
Tomorrow we will be announcing this publicly in a blog post. This will describe the motivation and announce the first round of SMEs . But before that it makes sense to do a quick review round first.
Given the quick turnaround on this PR, this isn't the best platform to discuss changes to the SME system (or its validity). After you have read the announcement tomorrow, feel free to start discussions wherever is preferable to you (this repo, discord, etc). So for now, please just review for clarity / typos / phrasing / missed info / etc.
[Rendered](08ceae43db/docs/the_bevy_organization.md)
# Objective
`xlibsWrapper` is being deprecated: https://github.com/NixOS/nixpkgs/issues/194054, this pr removes the deprecated xlibsWrapper and makes a couple more improvements
## Solution
- rename NixOS to Nix since this is not specific to NixOS
- remove usage of `xlibsWrapper`
- add instructions for nix flakes with `nix develop`
- add example of a packaged bevy program in nixpkgs
- minor cosmetic/grammatical changes
Add a section about install `vulkan-loader` on Gentoo.
# Objective
- Clarify the dependency about install on Gentoo with NVIDIA GPU and using a proprietary driver.
## Solution
- Emerge `vulkan-loader` to help Bevy to find the correct ICD.
# Objective
Links to `cargo-flamegraph`'s repo point to a [fork](https://github.com/killercup/cargo-flamegraph), not the actual upstream repo. We should point to the source of truth instead of a fork that hasn't been updated since 2019.
## Solution
Change links to point to the upstream repo at [flamegraph-rs/flamegraph](https://github.com/flamegraph-rs/flamegraph).
When running Bevy on Gentoo using an AMD Radeon GPU, it panics unless `amdgpu-pro-vulkan` has been installed (and it took quite a bit of experimentation to find this information). This PR adds a mention of this to the linux dependencies documentation.
for nix build, pkgconfig has been renamed to pkg-config. Very small fix :>
# Objective
- Describe the objective or issue this PR addresses.
- If you're fixing a specific issue, say "Fixes #X".
## Solution
- Describe the solution used to achieve the objective above.
---
## Changelog
> This section is optional. If this was a trivial fix, or has no externally-visible impact, you can delete this section.
- What changed as a result of this PR?
- If applicable, organize changes under "Added", "Changed", or "Fixed" sub-headings
- Stick to one or two sentences. If more detail is needed for a particular change, consider adding it to the "Solution" section
- If you can't summarize the work, your change may be unreasonably large / unrelated. Consider splitting your PR to make it easier to review and merge!
## Migration Guide
> This section is optional. If there are no breaking changes, you can delete this section.
- If this PR is a breaking change (relative to the last release of Bevy), describe how a user might need to migrate their code to support these changes
- Simply adding new functionality is not a breaking change.
- Fixing behavior that was definitely a bug, rather than a questionable design choice is not a breaking change.
# Objective
- Even though it's marked as optional, it is no longer possible to not depend on `bevy_render` as it's a dependency of `bevy_scene`
## Solution
- Make `bevy_scene` optional
- For the minimalist among us, also make `bevy_asset` optional
# Objective
- Document how to do profiling with Tracy
# Solution
- The documentation of setting `RUST_LOG=info` in order to capture `wgpu` spans depends on https://github.com/bevyengine/bevy/pull/5182
# Objective
`nix-shell` reported: ```error: 'x11' has been renamed to/replaced by 'xlibsWrapper'```.
## Solution
Replacing `x11` with `xlibsWrapper` in the Nix section of linux_dependencies.md fixes the problem on my system, and bevy projects build fine.
Change _LICENSE-APACHE_ and _LICENSE-MIT_ file location
Delete _LICENSE_
You can make the license in about on bevy's GitHub page display as **Apache-2.0, MIT licenses found** instead of **View license**
# Objective
- Guide people to the right discord channel to post about their new plugin. #showcase was split into multiple channels.
## Solution
- recommend posting in #crates
# Objective
While playing with the code, I found some problems in the recently merged version-bumping workflow:
- Most importantly, now that we are using `0.8.0-dev` in development, the workflow will try to bump it to `0.9.0` 😭
- The crate filter is outdated now that we have more crates in `tools`.
- We are using `bevy@users.noreply.github.com`, but according to [Github help](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-email-preferences/setting-your-commit-email-address#about-commit-email-addresses), that email address means "old no-reply email format for the user `bevy`". It is currently not associated with any account, but I feel this is still not appropriate here.
## Solution
- Create a new workflow, `Post-release version bump`, that should be run after a release and bumps version from `0.X.0` to `0.X+1.0-dev`. Unfortunately, cargo-release doesn't have a builtin way to do this, so we need to parse and increment the version manually.
- Add the new crates in `tools` to exclusion list. Also removes the dependency version specifier from `bevy_ecs_compile_fail_tests`. It is not in the workspace so the dependency version will not get automatically updated by cargo-release.
- Change the author email to `41898282+github-actions[bot]@users.noreply.github.com`. According to the discussion [here](https://github.com/actions/checkout/issues/13#issuecomment-724415212) and [here](https://github.community/t/github-actions-bot-email-address/17204/6), this is the email address associated with the github-actions bot account.
- Also add the workflows to our release checklist.
See infmagic2047#5 and infmagic2047#6 for examples of release and post-release PRs.
Tracing added support for "inline span entering", which cuts down on a lot of complexity:
```rust
let span = info_span!("my_span").entered();
```
This adapts our code to use this pattern where possible, and updates our docs to recommend it.
This produces equivalent tracing behavior. Here is a side by side profile of "before" and "after" these changes.
# Objective
- Support compressed textures including 'universal' formats (ETC1S, UASTC) and transcoding of them to
- Support `.dds`, `.ktx2`, and `.basis` files
## Solution
- Fixes https://github.com/bevyengine/bevy/issues/3608 Look there for more details.
- Note that the functionality is all enabled through non-default features. If it is desirable to enable some by default, I can do that.
- The `basis-universal` crate, used for `.basis` file support and for transcoding, is built on bindings against a C++ library. It's not feasible to rewrite in Rust in a short amount of time. There are no Rust alternatives of which I am aware and it's specialised code. In its current state it doesn't support the wasm target, but I don't know for sure. However, it is possible to build the upstream C++ library with emscripten, so there is perhaps a way to add support for web too with some shenanigans.
- There's no support for transcoding from BasisLZ/ETC1S in KTX2 files as it was quite non-trivial to implement and didn't feel important given people could use `.basis` files for ETC1S.
Adds "hot reloading" of internal assets, which is normally not possible because they are loaded using `include_str` / direct Asset collection access.
This is accomplished via the following:
* Add a new `debug_asset_server` feature flag
* When that feature flag is enabled, create a second App with a second AssetServer that points to a configured location (by default the `crates` folder). Plugins that want to add hot reloading support for their assets can call the new `app.add_debug_asset::<T>()` and `app.init_debug_asset_loader::<T>()` functions.
* Load "internal" assets using the new `load_internal_asset` macro. By default this is identical to the current "include_str + register in asset collection" approach. But if the `debug_asset_server` feature flag is enabled, it will also load the asset dynamically in the debug asset server using the file path. It will then set up a correlation between the "debug asset" and the "actual asset" by listening for asset change events.
This is an alternative to #3673. The goal was to keep the boilerplate and features flags to a minimum for bevy plugin authors, and allow them to home their shaders near relevant code.
This is a draft because I haven't done _any_ quality control on this yet. I'll probably rename things and remove a bunch of unwraps. I just got it working and wanted to use it to start a conversation.
Fixes#3660
Features must be called with the crate, otherwise the following error is thrown:
> error: none of the selected packages contains these features: trace_chrome
# Objective
- The Linux dependencies document lacks packages for Fedora with Wayland.
## Solution
- Add instructions to install packages for running Bevy apps in Fedora with Wayland.
# Objective
The description of NixOS dependencies is extremely long and spends entire paragraphs just for simple line changes.
With this PR it should be much simpler.
## Solution
- Linking Vulkan in `build.rs` is less effective than adding it in LD_LIBRARY_PATH, so I removed the former (related to #1992);
- I put a simple comment explaining the line in the list of dependencies, instead of making entire paragraphs;
- Clang is not in an absolute path in `.cargo/config_fast_builds` anymore, so that there is no need to specify it in `docs/linux_dependencies.md` (didn't test if this breaks other distros, though I doubt it. Also, maybe it could also be done on Darwin for consistency?);
- Also added optional wayland dependencies.
A few notes:
- The x11 libraries will be linked only during the compilation phase. This means that if you use the `x11` feature without these libraries in the environment (for example because you forget to enter the nix shell before compiling), the program will still compile successfully but won't run. You'll have to `cargo clean` and recompile with the x11 libraries in the environment. I don't know if this is important enough to be added to the documentation, but it's not specified anywhere, though I don't think it's specific to NixOS;
- The wayland dependencies need to be put in LD_LIBRARY_PATH only in certain conditions (IIRC, only if using the `dynamic` feature) and the text doesn't specify it. Because putting them there doesn't increase the number of dependencies (they are already in buildInputs) or alter the performance, I doubt anyone will care;
- Should I comment out what isn't needed by default?
- ~I removed `cargo` from buildInputs. Ignoring the fact that it should be in nativeBuildInputs, having it in `shell.nix` allows to use stable Rust in case it's not in the system environment, but maybe the user wanted to use the version that was already in the system environment and will be caught by surprise. In my opinion, if someone is looking at a Bevy's documentation on NixOS, that user will either have Rust already in the system environment (eg. via rustup) or is capable to add the toolchain they want on shell.nix by themselves. This isn't exactly the place to explain how this works.~ ~EDIT: I replaced `cargo` with Rust from the [Oxalica overlay](https://github.com/oxalica/rust-overlay) in order to have the latest nightly.~ EDIT: Removed `cargo` from dependencies. See comments for details.
# Objective
- Revert #3517 as the dependency added (rust-libudev-devel) has a dependency on cargo which install the package manager version, which isn't compatible with rustup version and may break the setup of users
Co-authored-by: François <8672791+mockersf@users.noreply.github.com>
# Objective
- Using the instructions given for NixOS results in an unnecessarily long time to evaluate the shell expression due to unnecessary dependencies pulled in by `lutris`.
## Solution
- Removed `lutris` dependency.
Lutris is a GUI tool for running games on wine, I'm assuming it was pulled in by accident as it's definitely not necessary for running bevy. A hello world example, at the least, works fine without it.
Thanks for making Bevy. Recommend adding rust-libudev-devel as an additional dependence for Fedora.
# Objective
- Describe the objective or issue this PR addresses.
- If you're fixing a specific issue, say "Fixes #X".
## Solution
- Describe the solution used to achieve the objective above.
# Objective
- mp3 feature of rodio has dependencies that are not maintained with security issues
- mp3 feature of rodio doesn't build in wasm
- mp3 feature of rodio uses internal memory allocation that cause rejection from Apple appstore
## Solution
- Use vorbis instead of mp3 by default
Co-authored-by: François <8672791+mockersf@users.noreply.github.com>
# Objective
- It isn't very useful to be able to enable feature `trace_chrome` on its own
## Solution
- Enable `trace` feature when enabling `trace_chrome` or `trace_tracy`
Co-authored-by: François <8672791+mockersf@users.noreply.github.com>
This makes the [New Bevy Renderer](#2535) the default (and only) renderer. The new renderer isn't _quite_ ready for the final release yet, but I want as many people as possible to start testing it so we can identify bugs and address feedback prior to release.
The examples are all ported over and operational with a few exceptions:
* I removed a good portion of the examples in the `shader` folder. We still have some work to do in order to make these examples possible / ergonomic / worthwhile: #3120 and "high level shader material plugins" are the big ones. This is a temporary measure.
* Temporarily removed the multiple_windows example: doing this properly in the new renderer will require the upcoming "render targets" changes. Same goes for the render_to_texture example.
* Removed z_sort_debug: entity visibility sort info is no longer available in app logic. we could do this on the "render app" side, but i dont consider it a priority.
# Objective
- there are a few new versions for `ron`, `winit`, `ndk`, `raw-window-handle`
- `cargo-deny` is failing due to new security issues / duplicated dependencies
## Solution
- Update our dependencies
- Note all new security issues, with which of Bevy direct dependency it comes from
- Update duplicate crate list, with which of Bevy direct dependency it comes from
`notify` is not updated here as it's in #2993
# Objective
- `bevy_ecs` exposes as an optional feature `bevy_reflect`. Disabling it doesn't compile.
- `bevy_asset` exposes as an optional feature `filesystem_watcher`. Disabling it doesn't compile. It is also not possible to disable this feature from Bevy
## Solution
- Fix compilation errors when disabling the default features. Make it possible to disable the feature `filesystem_watcher` from Bevy
I just updated profiling.md (and accidentally skipped the pr process by not checking "create new branch" in the github ui). The markdown wasn't properly formatted, which broke the build.
- Requires #2997
- Removes `wasm_audio` feature as discussed in #2397
- Closes only task in #2479
Open questions:
Should we enable wasm audio by default or only when building for wasm using `cfg`?
Maybe there should be a global wasm feature for bevy?
# Objective
[Tracy](https://github.com/wolfpld/tracy) is:
> A real time, nanosecond resolution, remote telemetry, hybrid frame and sampling profiler for games and other applications.
With the `trace_tracy` feature enabled, you run your bevy app and either a headless server (`capture`) or a live, interactive profiler UI (`Tracy`), and connect that to your bevy application to then stream the metric data and events, and save it or inspect it live/offline.
Previously when I implemented the spans across systems and stages and I was trying out different profiling tools, Tracy was too unstable on macOS to use. But now, quite some months later, it is working stably with Tracy 0.7.8. You can see timelines, aggregate statistics of mean system/stage execution times, and much more. It's very useful!
## Solution
- Use the `tracing-tracy` crate which supports our tracing spans
- Expose via the non-default feature `trace_tracy` for consistency with other `trace*` features
