Talin viridia
A formal specification of the design language embodied by the Bevy Editor mockups and the bevy_feathers widget crate. This document exists to make the implicit rules of the design explicit, so that future contributors can add widgets, themes, and layouts that feel cohesive without needing to reverse-engineer the original designer's intuition.
Where the mockups and the existing code disagree, the mockups take precedence. Where both are silent, this document fills the gap and flags it as a new rule.
| //! This example shows how to manually render 3d items using "mid level render apis" with a custom | |
| //! pipeline for 3d meshes. | |
| //! It doesn't use the [`Material`] abstraction, but changes the vertex buffer to include vertex color. | |
| //! | |
| //! [`Material`]: bevy::pbr::Material | |
| use bevy::{ | |
| core_pipeline::core_3d::{Transparent3d, CORE_3D_DEPTH_FORMAT}, | |
| pbr::{ | |
| DrawMesh, MeshPipeline, MeshPipelineKey, MeshPipelineViewLayoutKey, RenderMeshInstances, |
| use bevy::{ | |
| core_pipeline::core_3d::{Opaque3d, Opaque3dBinKey, Transparent3d, CORE_3D_DEPTH_FORMAT}, | |
| pbr::{ | |
| DrawMesh, MeshPipeline, MeshPipelineKey, MeshPipelineViewLayoutKey, RenderMeshInstances, | |
| SetMeshBindGroup, SetMeshViewBindGroup, | |
| }, | |
| prelude::*, | |
| render::{ | |
| extract_component::{ExtractComponent, ExtractComponentPlugin}, | |
| render_asset::RenderAssets, |
There's a desire to refactor the existing "Target Camera" and "Render Layers" mechanisms into a more unified approach. This breaks down into three separate but related features.
The motivation here is just API simplicity: we have two different mechanisms for controlling visibility (well, three if you count Visibility), some of which are specific to UI and some which are not.
Logically speaking, both "target camera" and "render layers" are representations of sets: the target camera is a set whose members are entity ids, and render layers is a set whose members are the integers 0..31. There's an additional restriction that there can only be a single target camera in a set, this is mainly for performance reasons so that we don't end up having to have a Vec<Entity>.
An "Inline Asset" is an asset whose data is encoded entirely within the asset path itself, without the need to load data from a filesystem or anywhere else. This is similar in concept to a "data URL", which allows a image or resource to be encoded directly within the URL itself.
There are a couple of reasons why you might want to use an inline asset:
- The asset data is very small, and encoding the data within the path eliminates the overhead of loading a file.
- You want to use Bevy's asset system as a cache of algorithmically-constructed objects.
For example, let's say you have a game that has a lot of procedurally-generated materials, using an algorithm that depends on the game state. Or perhaps you have a complex scene asset which contains serialized descriptions of various materials. In either case, you'd want to avoid creating multiple copies of the same material - that is, if two materials have the same parameters, it would be nice to have both handles point to the same material
| X11_COLORS = ''' | |
| alice_blue #F0F8FF 240 248 255 | |
| antique_white #FAEBD7 250 235 215 | |
| aqua #00FFFF 0 255 255 | |
| aquamarine #7FFFD4 127 255 212 | |
| azure #F0FFFF 240 255 255 | |
| beige #F5F5DC 245 245 220 | |
| bisque #FFE4C4 255 228 196 | |
| black #000000 0 0 0 | |
| blanched_almond #FFEBCD 255 235 205 |
This is a list of "prerequisite" tasks needed to bringing the Bevy UI to a level of quality suitable for production games and tools. It is not a UI framework, but rather a set of features which a UI framework can build on.
Caveat: this started out as an attempt to objectively assess each issue, but I found I couldn't resist putting in my own opinions about things.