Back

A. https://github.com/bevyengine/bevy/pull/13443

Ah ECS, true home of the combinatorial explosion of methods. This time we're filling in the feature grid by implementing sorts over queries that iterate multiple entities at once. https://github.com/bevyengine/bevy/pull/13443#discussion_r1826890815 has a nice table!

Well-made and definitely annoying to be missing if you want it. But I agree with Chescock's concerns about duplication. We should merge this and try to abstract over it once we have more of the grid filled out I think.

B. https://github.com/bevyengine/bevy/pull/15473

Retained mode gizmos. Wild! I was initially skeptical of adding an optional more performant retained mode to these debug tools, but talking to users in the CAD space convinced me that they're useful and perf-sensitive enough for this to matter.

Perf is uh, 80 *times* better. Geez. Code is remarkably simple :) I think that we should consider refactoring the gizmos API completely once BSN is in. It's obscuring a "make anything immediate mode" API. Merge conflicts :(

C. https://github.com/bevyengine/bevy/pull/15519

Oh-ho-ho: petgraph begone! This is a no_std replacement of petgraph, extracted from that crate and degenericized. Here in the ECS schedule construction is the only place we use it.

no_std is useful for weird platforms, but apparently this PR also improves schedule building perf meaningfully. No one was expecting that but it seems to reproduce. Sure I'll take that. Merging :)

D. https://github.com/bevyengine/bevy/pull/15810

And similarly, no_std-ification of bevy_math. This was delayed to 0.16 because it was not very useful at all on its own.

But now that we're in a new cycle, it's time to press the button! There's even a CI check to validate that this keeps working :) Good stuff <3

E. https://github.com/bevyengine/bevy/pull/15844

Another simple change that was delayed due to risk management. This time, it's a taffy version bump. Should fix a few minor UI layout bugs, but it's useful to keep up with the latest changes as a matter of principle.

Merging.

F. https://github.com/bevyengine/bevy/pull/15884

Bevy cares a lot about providing a flexible base to its users who are trying to do weird things, and so a lot of assorted internals end up exposed. This means more breaking changes (and ways to shoot yourself in the foot), but that's generally a tradeoff the advanced users are willing to take.

In this case, it's exposing the raw windowing events from Winit. Good docs telling people not to use this :D Seems solid, merging.

G. https://github.com/bevyengine/bevy/pull/16050

A fun little rendering optimization PR that skips a normalization step when computing face normals for meshes. This will mostly be useful for procedurally generated geometry: normals are shipped with the mesh for authored meshes (usually) and can be tuned by artists.

The side-by-side investigation (and especially the GIF) was great, but the "it's the same picture" effect is why I'm not a rendering engineer Looks good though, merging.

H. https://github.com/bevyengine/bevy/pull/16095

Ah, another rendering PR :) This time, we're getting "native unclipped depth". Uh, what does that mean exactly? Well, it turns out that GPUs have tools to quickly and automatically clip objects that are outside of a predefined range. For some things (like shadows), we want to turn that off. But only some platforms (namely native OS's like Windows or Linux) support this.

The rendering people think this is a good idea, and I have no reason to disagree. Merging :)

I. https://github.com/bevyengine/bevy/pull/16132

Oh my god, entity cloning?? I opened an issue for this back in February 2021, when I was trying to get PoE-style projectile duplication working.

I really like the solution presented here: sensible reflection-powered defaults (clone everything you can, skip everything else), with a nice configurable override. There's optimization work to do here, but that's fine for followup. It even has hierarchy support?? Really nice Merging with pleasure.

J. https://github.com/bevyengine/bevy/pull/16161

As part of our effort to get rid of our junk-drawer that is bevy_utils and contribute back to the broader Rust community, we've been spinning out useful micro-crates from stable well-contained functionality.

In this case, it's a set of tools to fake variadic generics with macros, called `variadics_please`. This is already published, we just need to update Bevy to use it. Trivial PR, merging :D

K. https://github.com/bevyengine/bevy/pull/16256

The no_std-ification of Bevy continues: this time with bevy_reflect. Because bevy_reflect is useful to #rustlang more broadly (seriously, it's nuts), I'm particularly excited about this work.

Shockingly easy: these changes are quite mechanical. Bushrat has been doing an awesome job leading this initiative, and I'm excited to see where it leads. Do send me photos of Bevy running on your toasters! Merging :)

L. https://github.com/bevyengine/bevy/pull/16286

Ah rendering feature interactions: so hard to test and so fiddly. This combination is hierarchical levels of detail dithering plus prepasses. Thank goodness for pcwalton testing Bevy in serious, rendering-heavy projects.

Straightforward enough, merging :) Good bonus bug found and fixed by BenjaminBrienen here. I love community reviews :D

M. https://github.com/bevyengine/bevy/pull/16331

bevy_picking bikeshedding time! We're moving from Pointer<Down> / Pointer<Up> to Pressed / Released for consistency with other forms of buttons.

I like this change, but it got punted from 0.15 to make the migration from bevy_mod_picking to bevy_picking as smooth as possible. With that done, everyone likes this, so it's time to merge.

N. https://github.com/bevyengine/bevy/pull/16359

A simple version bump for our audio crate. Again, delayed due to last minute bug risk, but now it's time to press the button!

O. https://github.com/bevyengine/bevy/pull/16368

The first steps to the fabled "bindless" rendering?? From what I've been able to piece together, data needs to be assigned to various predefined slots in rendering. This sucks, but it doubly sucks because there's fixed limits for how many of each kind you can use. This triply sucks because these limits vary by platform.

It might also be faster, but mostly I want to stop having rendering features break on random platforms

O cont. The PR description by pcwalton has more technical details, and is totally worth a read.

This very much warrants a release note, so it gets the labels. Well-made and well-reviewed, as expected. Let's merge this and see what nonsense the rendering folks get up to with it :D

P. https://github.com/bevyengine/bevy/pull/16372

Okay, time for another banger: immutable components. While it seems like removing functionality might be pointless, when combined with hooks (and lifecycle observers) you can get incredibly powerful control over invariants.

Well-made, but there's a few things that will be easier to fix now. Requesting changes but those should be easy to resolve. Very very excited for this.

Okay, time to hit the brakes on this merge train for a bit! It's time to migrate to another location with free wifi >.> See you in an hour or so!

Alright, back on the #bevymergetrain, this time from the library! To steal a joke, it's just like an ordinary merge train, except I don't say "choo-choo!" after each merged PR ;)

It sure is beautiful up here, even if Nanaimo is *very* car-centric.

Q. https://github.com/bevyengine/bevy/pull/16388

Okay, another fun PR: sprite picking that only selects non-transparent regions of the sprite. This is a good default behavior: much more intuitive!

Really pleased to see this sort of improvement being made from random community members: this stuff is a big part of why I'm excited about bevy_picking being upstreamed. Bevy is *ours*: if you see something you want to improve, take a crack at it!

Merging :)

@chrisvest That was the intent! Great for showing colliders and view frustums and so on. Turns out though people will do all manner of things with your pretty polylines :p

@alice_i_cecile so that explains why they’re (now) drawn over all other stuff regardless of Z coords