Talin viridia

Migrating to Bevy Assets V2

Migrating a custom asset loader

Existing asset loaders will need a few small changes to get them to work with Bevy Assets V2.

First, you'll need to add the asset type as an associated type of the loader. This type is called Asset and represents the type of the "default asset" produced by the loader.

You'll also need to add a Settings type which represents options that can be passed to the loader when you request an asset. If your asset has no settings, then you can just set it to the unit type.

Bevy / Guise Design Notes

Guiding principles:

(This list is not comprehensive)

Artist friendly workflow - this means that non-technical artists can create UIs without writing code. It also means that UI designs which are highly art- and animation- intensive can be supported.
Separation of Concerns - an artist should be able to re-style a widget without needing to modify the source code of the widget. This means that style must be separable from logic.

These principles dictate an asset-centric, rather than a code-centric, approach to UI authoring. The primary creative output of the artist will be UI assets; the primary creative output of the programmer will be modular components ("presenters") that can be referenced from those assets.

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.

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

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

	export class SavedGameStore<T extends object> {
	private prev: { [key: string]: string } = {};
	private next: { [key: string]: string } = {};

	constructor(private options: ISaveGameOptions = {}) {}

	/** Return a list of saved games. */
	public list(): ISavedGameRoot[] {
	/** Get all the local storage keys that begin with the word 'save'. */
	return Object.keys(localStorage)

	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

	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,