Talin viridia

Bevy Feathers Design Language

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.

1. Philosophy

From Ashes to Federation: The Paradox of Human Leadership in Interstellar Governance, 2063–2161

Dr. T'Rel Vasquez-Okonkwo

Department of Comparative Political Evolution, University of Alpha Centauri

Journal of Interspecies Political History, Vol. 47, No. 3 (2388), pp. 112–158

Overview

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.

Unifying the "target camera" and "render layers" concepts.

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>.

Bevy Inline Assets

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

Bevy UI Foundational Tasks

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.

Tasks from the Leafwing Blog Post

Round corners

Bevy Cookbook: Ideas

Using SystemParam to store system params in a struct.
Nested assets
Reporting errors from asset loaders
Bevy's lesser-known utilities
Waiting for assets to load / events
Creating a type by name

Bevy UI Improvments: Brainstorm

This document is a collection of ideas related to improving Bevy UI at the foundational level. These ideas are chosen to be ones that will not interfere with large-scale efforts to develop a UI asset and templating system. This means that the items listed here either either template-agnostic, or are general enough that they would conceivably mesh with any future templating system being contemplated.

Preparing for Style Assets

This section establishes a set of working assumptions. We don't know yet what form style assets will take, but we can assume the following:

Style assets will be a thing.
The design of style assets won't be a clone of CSS stylesheets, but will take some ideas from CSS.

	//! 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,

	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