This is a quick little note exploring the current state of High-Dynamic Range (HDR) and Wide-Color Gamuts (WCG) in Bevy. Display-Referred and Scene-Referred Colors Display-referred colors are defined by a display standard (typically sRGB, BT.709, BT.2020, BT.2100 or Display P3). sRGB and BT.709 are SDR, Display P3 and BT.2020 are WCG, BT.2100 is HDR + WCG. All display-referred colors have bounds on chromaticity and intensity, and usually have coefficients between 0 and 1. Scene-referred colors are defined by quantities of light. They typically use the primaries from a display standard and are expressed in luminous units, such as lux or candela per square meter. They have bounded chromaticity but unbounded luminosity (meaning the light can be arbitrarily intense intense), which translates to allowing their coefficients to go above 1. WebGPU WebGPU allows us to create canvases in either the sRGB or Display P3 color spaces. Additionally, when the attachment format is set to rgba16float, WebGPU converts the output color values to the color space of the actual screen and then clamps them to the [0, 1] interval in that color space.

Overview Tracking issue: https://github.com/bevyengine/bevy/issues/18151 This is a design document for a unified volumetrics system that combines the functionality of FogVolume, Atmosphere, and other volumetric effects into a cohesive, physically-based system. The system focuses on providing robust defaults for common volumetric effects while maintaining a clean, extensible architecture for more specialized implementations. Current State Bevy implements volumetric effects through three systems: Atmosphere - Physical scattering using Rayleigh/Mie phase functions, precomputed LUTs for transmittance (2D), multiscattering (2D), and inscattering (3D), with full planetary curvature support FogVolume - Localized volumes using bounded meshes, arbitrary 3D density fields, and Henyey-Greenstein phase function for anisotropic scattering

This is a list of questions that must be answered as part of the editor design process. I've written this up as a result of some recent discussions I've had about editor progress, and my main goal is to demonstrate that The Editor Is Not Blocked On UI. f There is a tremendous amount of work that will go into the official Bevy editor that has nothing to do with how it looks. In fact the UI is the least of my concern. :::success When project leadership blesses an answer to one of these questions, I will write it here in a green box. ::: :::info

A Bevy CLI is a long-outstanding feature request, with even more discussion and analysis. Let's start building it! Rather than being a single-purpose tool to accomplish a specific task, the vision is to create a single CLI entry point for tasks that best fit the CLI format. Under the hood, the editor can then call the CLI for many of its tasks, avoiding duplication of effort and providing a mechanism for basic automation. So what might it do? A number of ideas for functionality that would fit well in the Bevy CLI have been floated: project generation from a template

Problem: pressing buttons without clicking on them (hotkeys, focus) Aevyrie's thoughts: multiple ways to do a lot of things with UI thing I'm trying to do is an abstraction level above picking options: create an Interact event, mock picking events, another abstraction layer within picking? rough idea: keep existing types for Pointer<Click> etc, but generate them from a lower level tool. Move physical picking data into an Option. picking is generally in a pretty solid spot: capable and robust

Input managers have one core goal: transforming messy, raw user inputs from the meat hands of your players into a pure, beautiful string of actions, which represent semantic tasks or states for the game (or business) logic to interpret. This seems simple: define a set of inputs, a set of actions, create a hashmap and you're golden. Right? Wrong! Many years ago, I sat down to build leafwing-input-manager, creating a clean, ergonomic API for setting up keybindings in simple games. In the years that have passed, my horror has only grown as the sheer complexity of the domain has slowly unfolded. Can we make something that's simple enough for beginners, pleasant enough to spark joy, and powerful enough to handle the complexities of even a demanding finished video game?

The core data structure is the classic "hash-map-in-a-resource" design. When designing this, we want to make the "fast enough, robust path" really obvious and easy, but avoid requiring it, to allow for easy refactors to custom update strategies as perf characteristics are refined in each project. NOTE: the current design assumes uniquness. That might not be desirable! #[derive(Resource)] struct Index<C: Component + PartialEq, L: Lookup<Key=C>> { // Might be a hashmap, a btreemap, or even a vector storage: L }

Requiring two queries and manually joining them sucks. We should make some WorldQuery types to make this process easier. Four types of query filters desired: Does my parent have this component? Do any of my immediate children have this component? Do any of my parents or grandparents etc have this component? Do any of my children or grandchildren etc have this component?

authors: tychedelia, nth :::warning This is a work in progress, and may contain omissions or mistakes. If you notice an issue or have a question, please don't hesitate to: Bring it up in #documentation-dev on the bevy discord Leave feedback in the form of a comment or suggested edit Or just fix it yourself ==This is a community document, which anyone can edit!==

This document proposes a small tweak to kickstart writing the release notes as part of the normal development process, instead of waiting to start writing until the last second as we do now. The key points of the proposal are as follows: We add a bevy/release_notes directory to the main repo. Files within this folder are named bevy/release_notes/{feature_name}.md. Each file will become a single entry in the blog post for the next release (just as the release-notes files in the website repo do now). The release note files in the main repo are considered temporary drafts and apply only to the version currently under development. During the release process, they are moved to the website repo and finalized (we will say more on this later). Each release note file will contain both content and metadata. The exact format is up for discussion. The list of metadata should include at minimum the list of PRs that contributed to the feature, and set of all authors and collaborators. This metadata will be manually curated rather than auto-generated (note: in both previous releases we extracted this information automatically and later discovered issues). When a maintainer decides that a PR should be highlighted in the blog post, they add the M-Release-Note tag to it. This tag indicates that the PR author should append their name and the PR number to the metadata for relevant the feature file (creating it if it does not exist). To ensure the PR does not get lost, updating the metadata should be mandatory, and failing to do so should prevent merging. Maintainers can always do this step themselves by commiting to the branch before merging. The M-Release-Note can also be added to issues to indicate PRs that implement/close those issues should have the tag applied. Most issues and PRs do not need to be highlighted in the blog post, and should not be tagged with M-Release-Note. PRs without the tag shouldn't touch the release notes directory. When a PR has the M-Release-Note tag, maintainers can request content be added to a release note as part of normal PR review. They may choose to accept a simple TODO line that expresses the author's intentions, but they may also request more detailed explanations. There is concern that, if content is mandatory, it will be a burden on some highly active contributors. We trust the maintainers to make the right call, but suggest as general guidelines:Content in the notes should be considered "rough drafts".

flecs treats virtually all of data used by the ECS in a single homogenous way: as components on entities. In Bevy terms, this means: the row-ish identifier is always Entity the column-ish identifier is always ComponentIdno bevy_ecs code uses TypeId: it's all ComponentId (except when generating ComponentId for Rust types) each resource is an entity, with its data stored in a component each system is stored as an entity, with metadata and system state on components ordering constraints are stored as relations between systems

Author(s): @doot @bushRAT @Victoron Contributor(s): @quartermeister @Diddykonga Working Group Goals Reduce code duplication within the "Entity pointer" APIs Minimize breaking changes where possible (these are heavily used APIs) Ensure the main entity pointer types and the filtered variants provide consistent access to operations on an entity pointer.Current APIs are missing various operations for the filtered variants that are present on the main ones. Unresolved Questions [ ] Should Shared/Exclusive capabilities be renamed?

Virtual cursors are terrible: lots of time wasted travelling between interactive elements, poor discoverability, bad for unconventional input devices (a11y) Tab cycling is... better, but still doesn't take advantage of full capabilities The natural choice is to navigate directly between elements based on quadrants (or octants, or directions) This creates a focus graph, made out of focus pathsDigraph time! A good focus graph would be: Fully connected: no stranded UI elements Reversible: reversing the input should go back to the previous element Intuitive: paths map to the directions displayed on the screen

This attribute can be attached to an impl block to easily generate a structure containing the DynamicFunction equivalent of items within that block. Definitions Impl Block - The implementation definition of a type. These included standard impl blocks (e.g. impl MyType {/* ... */}) and trait impl blocks (e.g. impl MyTrait for MyType {/* ... */}). There may be zero or more impl blocks for any given type. Impl Item - Any method, associated function, associated constant, associated type, or macro invocation within an impl block. For the purposes of #[reflect_impl], the latter two are ignored. These may also be referred to as "members" or simply "items" depending on the context. Method - A function within an impl block that takes some form of self as the receiver (e.g. &self, &mut self, self: Box<Self>, etc.). Such functions are callable as my_type.my_method(). Associated Function - A function within an impl block that is merely associated with the type. These do not take self and must be called as MyType::my_function(). Associated Constant - A constant within an impl block. These constants become associated with the type and only accessible as MyType::CONSTANT. Associated Type - A type alias defined within an impl block—specifically within trait impl blocks where the trait requires that the implementor define the type. Signature - A function signature. This normally includes the function's name, its ordered set of argument types, and the return type.

authors: IQuick 143, nth This is a short but rigorous little handbook on the science of Color, both in general and as applied within Bevy. Introduction To understand color, one must begin with Light. Light is curious because it has both objective physical properties and common subjective qualia (eg. sensory experience). Both, as it turns out, are measurable. The measurement of the physical aspects is called Radiometry, and of the qualia, Photometry. We will cover both in sequence before getting into Colorimetry, the which deals with color directly and lets us mostly ignore light. If you are not comfortable with calculus or physics, you can just skim the next few sections. Knowing some optics is important for understanding bevy's Physically-Based shading system and working with lights, even if you don't fully follow all the math. Radiometry Lets start with the basics: What is light? For us, light is waves which have energy and can interact with visible objects. These interactions notably include: Absorbtion (light hits the object and deposits its energy), Emission (the object emits waves), among many others (such as reflection, refraction, etc...). Since light is a wave, we can decompose it into a spectrum of pure waves with a given wavelength (the distance after which they repeat). This is useful, since most objects interact with different wavelengths differently, and we will see later that this is what gives rise to color. Each interaction of light and surface (bouncing off, emitting from, transmitting through, or being absorbed by) gives rise to a quantity of energy, in one of the following forms.

This document is a proposal for a Bug Hunting Week within the Bevy contributor community. :::info This proposal is currently put on hold. If you're interested in helping run this event, please reach out to BD103! ::: Motivation Bevy is largely volunteer-driven, meaning most changes are implemented because a developer wants them as compared to the engine needing them. While these views mostly overlap, certain categories of changes go underappreciated. (Mainly bug fixes, code quality, testing, and infrastructure.) This event aims to encourage more bug fixes, shrink the ever-growing issue tracker, and increase engine stability.

:::warning Warning This document is outdated. For the latest information, please see the repository at TheBevyFlock/bevy_cli. ::: See the MVP for motivation behind the Bevy CLI. The prototype repository can be found at TheBevyFlock/bevy_cli. Goal The goal is to write a linter, like cargo check and Clippy, that checks projects that use the Bevy game engine for best practices, potential footguns, and style.

Authors: @doot Contributors: @bushRAT @quartermeister @Diddykonga @Victoron This document details an alternative design to Unified EntityPtr Types. We have a few types within Bevy ECS that allow access to an Entity's metadata and components: EntityRef: provides read-only access. EntityMut: provides mutable access. EntityWorldMut: provides structurally mutable access, like adding/removing components or despawning.

TL;DR We can reduce code duplication for the following sets of types because they differ only in semantics: EntityRef, EntityMut, and EntityWorldMut FilteredEntityRef, FilteredEntityMut EntityRefExcept, EntityMutExcept What they look like currently: pub struct EntityRef<'w>(UnsafeEntityCell<'w>);

Summary Relations allow users to create logical connection between entities. Each source entity can have multiple kinds of relations, each with their own data, and multiple relations of the same kind pointing to a different target entity. Queries are expanded to allow efficient filtering of entities by the relations they have or the targets of these relations. This RFC covers the very first step of a minimal user facing API for relations that can replace the current Parent/Children hierarchy that is in use. It does not make decisions on implementation issues, nor does it make decisions between fragmenting and non-fragmenting relations. It should be future-proof in the sense that we estimate that there's a reasonable path forward from it without breaking backward compatibility too badly, but it is not meant to solve the full set of challenges around a relations API. Motivation Relations have been talked about for a long time in Bevy, and a lot of work has been done towards them, but the long term solution is gated behind a lot of implementation issues. At the same time, many people have tried to make incremental improvements to the current situation, which have been largely thwarted by them not aligning with the long term solution. Yet, the requirements set by the long term solution have not been written down, and there isn't a generally accepted consensus as to what they exactly are. This puts everybody that tries to work with relations against an impossible task of adhering to requirements that are unstated. The primary motivation for this RFC is meant to break that deadlock by explicitly specifying the requirements for the relations API, so that any incremental improvement that fulfills those requirements can avoid having the design discussions mixed in with the implementation discussions in the same pull request. This means it can be very incremental from the current hierarchy implementation in Bevy, as long as it enables movement forward in this space.