Vello, Minecraft Settlements, and destructible planets

This week we have multiple vello-related projects, some great working group progress, gizmos are seeing more usage, and more.

Bevy Jam 5 voting is finishing up within the next 24 hours. Congrats to all who participated.

Bevy's 4th Birthday happened this weekend with a great post from @cart (Bevy's creator and Project Lead). The post includes a great overview of the last year as well as a call for the community to write their own "Bevy Birthday post" and publish it. One month from now, a followup "Reflecting on Bevy's Fourth Year" rollup post will aggregate these in one place.

FixedUpdate vs Update Schedules

#14600 helps answer the question of "how often should your gameplay logic run?" by adding some new documentation on the FixedUpdate and Update schedules. This can be an important distinction since Update will run once-per-render frame, which can affect behavior when players play your game at different framerates (or varying framerates). FixedUpdate by contrast runs at a steady 64 Hz by default and is where you can put behavior that includes game logic that shouldn't "speed up" at higher framerates.

Adding additional context, the Unofficial Bevy Cheatbook has a section called "Should I put my systems in Update or FixedUpdate?".

Mesh::invert_winding

Winding is the order of the vertices that define a triangle. If you connected a thread to one vertex, it would be the direction you have to "wind" the thread around the rest of the vertices to form a triangle: either Clockwise or Counter-Clockwise. This direction affects what is considered the "front face" of your mesh, which in turn can affect whether the mesh is rendered or not (depending on whether you're viewing the front or back).

#14555 introduces Mesh::invert_winding for inverting the winding on a mesh which can effectively switch the front and back faces without affecting other attributes.

Function registry

#13152 added support for reflecting functions. Now #14098 added a FunctionRegistry similar to the TypeRegistry that already exists, allowing the registering and retrieving of functions.

fn foo() -> i32 {
    123
}

let mut registry = FunctionRegistry::default();
registry.register("my_function", foo);

let function = registry.get_mut("my_function").unwrap();
let value = function.call(ArgList::new()).unwrap().unwrap_owned();
assert_eq!(value.downcast_ref::<i32>(), Some(&123));

2d Depth Buffer

Depth buffers are effectively grayscale textures you can write to from a fragment shader, where the value of a given pixel describes how far away from the camera that pixel is. wgpu can use this texture to determine whether a pixel should draw in front of another pixel. In a 2d environment, you're typically restricted to having all of a sprite in front of or behind all of another sprite, but with a depth texture you have control of this per-pixel.

#13069 adds a depth buffer to Bevy's 2d processing. The image shown in this section uses custom fragment shaders to simulate a "3d"-like depth control on 2d meshes, allowing one sprite to walk "through" the middle of another.

If you want to take advantage of the depth buffer in a fragment shader, you'll want to use Material2d and write to the frag_depth builtin.

struct FragmentOutput {
   @builtin(frag_depth) depth: f32,
   @location(0) color: vec4<f32>
 }

@fragment
fn fragment(in: MeshVertexOutputCustom) -> FragmentOutput {
    var out: FragmentOutput;
    out.color = vec4(1., 0., 1., 1.);
    out.depth = 0.5;
    return out;
}

bevy_mod_picking: the upstreamening

The bevy_mod_picking upstreaming working group has made significant strides this week with upstreaming the remainder of bevy_picking_core in #14686. Much of this work can be found in the bevy_picking crate but do note that this work isn't yet functional for end-users. More work is still to be done building on top of the already-merged event propagation for observers.

A Curve trait for general interoperation — Part I

The Curve Crew working group is also making progress with #14630 implementing part of the Curve RFC.

Part 2 is already up for review.

Skins

Skins are the data that tells a bone which vertices it should be deforming when moved. #14343 makes this data available to users in a way that enables skinned mesh creation without spawning a scene.

---

Alice's Merge Train is a maintainer-level view into active PRs, both those that are merging and those that need work.