viridia

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

viridia

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

viridia

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,

viridia

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

viridia

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

viridia

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

viridia

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

viridia

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

viridia

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.

viridia

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.