0.14 release crew

[soft estuary]

thx for the pointers 🥲

[lethal urchin]

https://github.com/bevyengine/bevy-website/issues/1396 for those who would like to help 🙂

[gray moat]

trailing comma breaks the link for me fyi

[gray moat]

Dropping a note here because it's late and I don't have time to look into this.

Doing an update to bevy_editor_cam to 0.14 required almost no changes, however behavior of orthographic projection math seems to have broken something. Anyone aware of changes in this realm? The only suspect is that the projection matrix changed to get_clip_from_view for some reason.

Specifically, once I resize the window, and in ortho only, computing drag deltas is now broken

Hmmm, the math behind get_clip_from_view is unchanged, it's behaving as if the camera is not being updated with window updates for ortho projections.

Huh, camera projection is being updated when the window resizes.

Definitely seems tied to window resizing somehow. I have a split screen example with a different aspect ratio for the viewport. Everything works fine to start, but the projection math for the ortho viewport breaks when I resize the window.

Oh dear, there is a system ordering bug, it only happens some time. So it seems like there is some new system ordering change, but somehow only affects ortho.

[short lake]

Here's the reason for the renamed btw https://github.com/bevyengine/bevy/pull/13489

I don't think the ordering issue is related though

[lethal urchin]

https://github.com/bevyengine/bevy/pull/13873 needs a review to make sure that the retargeting to the release branch was done correctly. Compare against #10839 to validate

@forest forge was this the last thing you needed before cutting the next release-candidate?

[forest forge]

and https://github.com/bevyengine/bevy/pull/13858

[lethal urchin]

I've pressed the button

[forest forge]

oh I missed that it was approved, nice 🎉

[heady frigate]

I did a review of this one

[lethal urchin]

@forest forge both are merged now, you should be unblocked

[forest forge]

released!

[heady frigate]

Before https://github.com/bevyengine/bevy/pull/12936 there were 2 systems updating time: time_system and virtual_time_system . That PR removed the second one and the first one isn't pub, so I'm having a hard time porting a plugin that wants a system to go in the TimeSystem set but after the bevy systems run. I'm not sure if the best solution is to make time_system pub, or if it's better practice to make a new system set for custom timers?

[lethal urchin]

We should make time_system pub again

Please open a PR for this 😉

Although in general public system sets are the blessed pattern for solving this sort of thing

[heady frigate]

https://github.com/bevyengine/bevy/pull/13879

[gray moat]

Any suggestions? I still haven't been able to figure out what changed, or how to fix it.

[lethal urchin]

Have you run the ambiguity detector?

We may have regressed main again because I didn't set up CI to deny them yet

[gray moat]

Nope. I'll give it a shot!

[hybrid junco]

can someone add this to 0.14 milestone? mb not a blocker but should be in a point release at least. i'm going to try to get to this week https://github.com/bevyengine/bevy/issues/13701

[obsidian peak]

Done!

[obsidian peak]

No worries, 0.14 isn't going to be released for another week or 2 :)

[hybrid junco]

i hit my limit for debugging weird macos issues before vacation but am ready to get back at it 💪

[obsidian peak]

Best of luck :D

[lethal urchin]

3D rendering notes are written finally, now to pick the next thing to work on

I think that my next task is going to be tackling hooks and observers: I really want to nail the framing

[wise juniper]

FYI #general message

[ionic fulcrum]

not sure about this one too: https://discord.com/channels/691052431525675048/1252298542840545402

[lethal urchin]

@ionic fulcrum your text layout behavior change looks like the result of an intended bug fix: namely https://github.com/bevyengine/bevy/pull/13846

[ionic fulcrum]

ah! thank you! i'm glad it's a known issue 💜

oh! i misread that

[lethal urchin]

"Working as intended" :p

[soft estuary]

attempting to update bevy_mod_debugdump has a difficulty on the world being behind getters/setters, if anyone wants to help #1082388621216206926 message

[heady frigate]

I have a solution, I'll make a suggestion on the PR in a sec

[lethal urchin]

I think I'd like to get https://github.com/bevyengine/bevy-website/pull/1411 merged as is. The Tera issues are out of scope, and the screenshot quality is best done in an editing pass

[forest forge]

editing screenshots once on main means both versions will live in git

[lethal urchin]

Ugh, okay

So that needs to be done before merging

[forest forge]

removing the windows bar and reducing size?

[lethal urchin]

Yep

What's your target size for screenshots?

[forest forge]

I think the website has a column width of 992px on the largest screen size, so around that

then when my image has the resolution I want, I use https://tinypng.com which is very good at reducing size and very easy to use

I don't know how that compare to pngcrush that was used in https://github.com/bevyengine/bevy-website/pull/1276 though

[undone solstice]

https://squoosh.app/ is what I use for thisweekinbevy, and will let you resize as well as test out different formats and settings as well as previews

also .avif will typically significantly reduce filesize and is well supported these days https://caniuse.com/?search=avif

[lethal urchin]

There's a few release notes in the milestone that I don't think I can do justice, please claim one or two if you can (or tell me that they can be cut):

• Add BufferVec cut
• Throttle render assets
• Add AsyncSeek to seek inside of asset loaders
• Implement the AnimationGraph

[heady frigate]

BufferVec can safely be cut, unless we want to have a list of all the renderer optimizations

[lethal urchin]

Great, cutting

[warped iron]

I read through the hooks/observers release notes and I'm still unsure about the exact behavior. It seems like observers run on command flush, but I'm not sure when hooks do. Is it the same as observers? Also, I just realized that components will be in valid state because nothing can observe changes made through commands until a command flush, so even though there is a delay (for example, insertion -> command flush) it wouldn't be possible to observe that invalid state during the delay. This wasn't obvious to me at first so maybe that could be added to the release notes.

Also, if I were to insert a component with mutable world access, would that run hooks immediately or on command flush?

Oh, also it could maybe talk about why hooks should exist at all. It seems like observers are just more powerful and do the same things hooks can do.

[short lake]

yeah, agreed, it's too low level/niche for a public release notes

[lethal urchin]

@knotty stirrup @harsh mango @bold abyss do y'all have a compelling explanation I can use here?

[harsh mango]

One key difference is that hooks run first. If you want to maintain some guarantee about a component type in your crate you can't necessarily stop users from adding OnAdd or OnRemove observers that may run before yours since ordering isn't guaranteed.

Hooks also have less overhead than observers, there's no need to consult an index, the hook function pointers are stored directly in the component info.

Since hooks aren't entities you also don't need to worry about them being despawned, they are tied to the component type intrinsically.

[harsh mango]

Hooks (and OnAdd/OnInsert/OnRemove observers) run immediately when you do the operation, so if you queue an insert it will happen during command flush, but if you do it with &mut World it will run immediately.

If the hook or observer then queue's additional commands you will have to wait until a flush

[forest anchor]

From my perspective the important distinction is that hooks are tied directly to the Component type / are hard requirements. Observers are behaviors "tacked on" later

[lethal urchin]

https://github.com/bevyengine/bevy-website/pull/1431 revision PR is up 🙂

[forest anchor]

I do think its worth considering marrying them conceptually (and statically) though. Aka hooks are literally "default observers"

[lethal urchin]

Yeah 🙂 But that can be done later

[forest anchor]

Agreed. Not a 0.14 thing

[forest anchor]

They would probably also be "anonymous observers" in that they don't have an Entity representation with an Observer component and are instead stored directly inside the component info

[bronze stream]

hooks are the base system sets of observers :)

[lethal urchin]

@hybrid junco do you have time / interest in tackling the release notes for https://github.com/bevyengine/bevy-website/issues/1316 ? I think you'll do a much better job explaining why it matters than me 🙂

[forest anchor]

Approved! I think this section would benefit from illustrative code examples (ex: something like a Trigger<Explode> observer example and an on_add hook example)

Lots of time spent on abstract "where observers and hooks fit into the global ECS picture" and no time spent illustrating what they actually are (which I think will go a long way in getting people excited about them)

(I do like whats there / describing their positioning is useful)

[lethal urchin]

Yeah, I was a bit nervous about adding code to this section, since it's already super long

[forest anchor]

I would trade a couple of the current paragraphs for code examples

[lethal urchin]

🤔 Okay, I'll see what I can do

[forest anchor]

Imo for space reasons it should be fully minimal. Just "baseline observer system and event trigger boilerplate"

[lethal urchin]

Agreed. One for observers and one for hooks?

[forest anchor]

I added a bunch of content to the observers PR description that you could use:
https://github.com/bevyengine/bevy/pull/10839

It was written with the blog post in mind

[lethal urchin]

Oh perfect: I didn't think to check that

And I'll convert the TargetedBy example into code

[forest anchor]

I'm worried that might be harder to grok than a Trigger<Resize> or Trigger<Explode> example

[lethal urchin]

I think we want both

[forest anchor]

I also don't see mention of the "component target" case (ex: Trigger<OnAdd, Transform>). Imo that is cool enough / powerful enough to include

Maybe also "multiple trigger targets"

Ex:

commands.trigger_targets(Resize { x: 10, y: 10 }, entity);

vs

commands.trigger_targets(Resize { x: 10, y: 10 }, [e1, e2]);

[lethal urchin]

I've just finished up a triage pass on the milestone now. Anything in this search needs someone to claim and write it: only 12 left

[forest anchor]

(Although resize is a bad pick relative to Explode)

[urban meadow]

@lethal urchin fyi considering doing the AsyncSeek release note too, doesn't seem like anyone picked it up (?)

[lethal urchin]

That would be awesome

[urban meadow]

Tried making an interesting example. I've verified this compiles on main:

#[derive(Default)]
struct UniverseLoader;

#[derive(Asset, TypePath, Debug)]
struct JustALilAsteroid([u8; 128]); // Each lil' asteroid uses this much data

impl AssetLoader for UniverseLoader {
    type Asset = JustALilAsteroid;
    type Settings = ();
    type Error = std::io::Error;
    async fn load<'a>(
        &'a self,
        reader: &'a mut Reader<'_>,
        _settings: &'a (),
        _load_context: &'a mut LoadContext<'_>,
    ) -> Result<JustALilAsteroid, Self::Error> {
        // The universe is big, and our lil' asteroids don't appear until this offset
        // in the celestial file format!
        let offset_of_lil_asteroids = 5_000_000_000_000;

        // Skip vast parts of the universe with the new async seek trait!
        reader
            .seek(SeekFrom::Start(offset_of_lil_asteroids))
            .await?;

        let mut asteroid_buf = [0; 128];
        reader.read_exact(&mut asteroid_buf).await?;

        Ok(JustALilAsteroid(asteroid_buf))
    }

    fn extensions(&self) -> &[&str] {
        &["celestial"]
    }
}

It's of course not the most realistic scenario but I think it gets the point across. If you agree I'll write up a small text section around this example and make a PR

[lethal urchin]

Great, this is fun 🙂 As long as you call out a realistic use case or two too I'm on board

[urban meadow]

Sure! Coming up

[urban meadow]

Posted the async seek notes PR as well as the removal of the render layers # limit. Will stop writing for today

[lethal urchin]

I ended up using a classic combat-themed example for observers: https://github.com/bevyengine/bevy-website/pull/1437

[knotty stirrup]

They take precedence over observers which is important for using them to uphold archetype level invariants.

They are lower level constructs. That's why they're comparable to constructors/destructors. Where as observers would be something higher level.

[hybrid junco]

yes! apologies it slipped my mind

[lethal urchin]

There's an open PR for this now I believe 🙂

https://github.com/bevyengine/bevy-website/pull/1436

[hybrid junco]

quick one from the winit upgrade. a bit confused why this logic was changed https://github.com/bevyengine/bevy/pull/13942

[lethal urchin]

Mostly because that PR was very large and hard to review

[lethal urchin]

The end is in sight for the release notes 😄

https://github.com/bevyengine/bevy-website/issues?q=is%3Aopen+is%3Aissue+label%3AS-Ready-For-Implementation+milestone%3A"Release+v0.14"

4 left, 3 of which are waiting on contributors 🙂 I'm going to tackle the SSR notes after lunch

And then see about getting better screenshots for the 3D rendering features

[lethal urchin]

And SSR notes are up to review too: https://github.com/bevyengine/bevy-website/pull/1442

That means it's pretty much just editing from here <@&1064695155975803020>

[forest anchor]

Excellent. I'll do a pass!

[forest anchor]

Just put out https://github.com/bevyengine/bevy/pull/13954 to flag a method as unsafe that accidentally made it into the Observers PR as safe. This should be merged and backported to 0.14 as it is (1) a safety issue and (2) very straightforward to fix.

Actually it can just be cherry picked, so lets do that post-merge

[night gale]

@analog yacht was working on something. Not sure if it was for use as a demo image for the release article but perhaps something could be used?

[lethal urchin]

Yep I'm going to aim for "clean screenshots of the examples" for now, with the expectation that we might upgrade a couple

I suspect the demo scene is probably going to be a good splash image 🙂

[analog yacht]

They go into both bins. The goal of that change was to sort up front so that the mesh rendering code doesn't have to look at things that aren't meshes.

[analog yacht]

It won't be ready in time. We'll have to defer it for later.

I have an artist (ex-dreamworks) doing concept art for it, so it'll be good 🙂

[forest anchor]

Looks like we're currently dumping images in two places:

1. release-content/0.14
2. content/news/draft-bevy-0.14

Images in (1) are broken. We should probably move those over right?

[lethal urchin]

Correct

[forest anchor]

Cool cool. I'll do that

[forest anchor]

Also probably worth trying to ensure people put images in the right place going forward

[lethal urchin]

Yep; we weren't sure about the correct place at the start of this cycle

FYI @forest anchor https://github.com/bevyengine/bevy-website/issues/1424 is the other major blocker and we need to either figure out a technical solution or somehow avoid using the templates for this release

[forest anchor]

https://github.com/bevyengine/bevy-website/pull/1446

[forest anchor]

gotcha. looking now

[forest anchor]

@lethal urchin welp i gave it a shot but I also hit a wall: https://github.com/bevyengine/bevy-website/issues/1424#issuecomment-2181745928

We probably just manually combine them for this one

[short lake]

Yeah, sorry about that, I was aware of the limitation but completely forgot to mention it

@lethal urchin do you still need new screenshots for the rendering features? I can work on that this weekend if you haven't already

[short lake]

uh, wait, that's weird, I thought the setup we decided to use was specifically so terra templates would work like that

@wary adder any idea on that one?

[lethal urchin]

Yes, that would be incredibly useful

[night gale]

Ooooooo!

[wary adder]

ups, a minor detail 😅

I'm looking for a workaround, and looks like that if we use the Zola | markdown filter on release_note_body (in release_notes.md:15) the shortcodes are evaluated, but there are some limitations: section or page are not available in that context

so it ends-up breaking because compare_slider.html uses page.colocated_path… but maybe if there is a way to remove that usage of page then compare_slider would work

or… the page needs to be generated by generate-release 😬

(Tera's {% include ___ %} is discarded as it doesn't allow passing variables as path)

[heady frigate]

You can make compare_slider take the path as an extra argument and use it if set

@wary adder that works!

{% if path %}
    {% set img = get_image_metadata(path=path ~ left_image) %}
{% else %}
    {% set img = get_image_metadata(path=page.colocated_path ~ left_image) %}
{% endif %}

{{ compare_slider(
    path="news/draft-bevy-0.14/"
    left_title="Without PCF filtering",
    left_image="before_pcf.png",
    right_title="With PCF filtering",
    right_image="after_pcf.png"
) }}

A bit ugly, but easy to do

[wary adder]

for extra hackyness that path could be a "variable" that gets replaced in release_notes.md => {{ release_note_body | replace(from="POST_PATH", to="...") | markdown }} so that the shortcode could be used with path="POST_PATH"

the whole setup was already ugly, it's getting worse xD

[heady frigate]

That would make it less fragile though, it seems bad that the release note has to care about what the path to the news post is xD

The more I use it the less I like Zola for sites like this, it's too blog focused

Something more Jekyll-like with code would allow us to solve stuff like this properly

[wary adder]

oh, true, release_notes would need a path parameter that is passed down via replacement… ugly 😬

that's why I was saying that maybe the way to go is to generate the blog post via generate-release… but, I just don't like any option

[heady frigate]

@wary adder I made a PR here, I think it's good enough for this release: https://github.com/bevyengine/bevy-website/pull/1448

Perhaps we can find a better way later

[wary adder]

idea, can you try just doing replace(from='POST_PATH', to=page.colocated_path) instead of passing post_path to release_notes()? I think that should work 🤞
also, the PR target should be #1411?

[forest anchor]

https://github.com/bevyengine/bevy-website/pull/1453

[night gale]

https://github.com/bevyengine/bevy/issues/13965

[winged meteor]

is there a reason base_color on StandardMaterial is a Color, but emissive is a LinearRgba?

[ionic stirrup]

I don't know about base_colour, but the point about LinearRgba is because of f32 scaling due to light calculations afaik

because you can put in a colour that is scaled beyond the 0 - 1 range

and the scaling makes sense only in a linear space like LinearRgba

I'm not, however, a rendering person so don't quote me on this.

[winged meteor]

*forgot to mention they were both Color in 0.13.

[lethal urchin]

Precisely

Anything other than a LinearRgba here is likely to be totally wrong

[tropic lark]

Hi- I pinged you @lethal urchin on a couple of PRs which have release notes or migration guide issues. Found those will trying to upgrade Hanabi. Note sure how critical given I don't think many crates integrate a custom render node, but I'm still struggling to migrate some of those changes (notably the whole sorted/binned phase items, which have a couple of breaking changes building on top of each other).

[lethal urchin]

Can you open issues on the bevy-website repo so we can track them please?

https://github.com/bevyengine/bevy/pull/13277 is the PR in question

[hybrid junco]

seems like there's already one https://github.com/bevyengine/bevy-website/issues/1386

[tropic lark]

Cross-posting from #rendering-dev for visibility: potential 0.14 blocker
#rendering-dev message

(directly related to above post from @hybrid junco )

[lethal urchin]

Going through the milestones on Mastodon: https://elk.zone/mastodon.gamedev.place/@alice_i_cecile/112677463729045537

[lethal urchin]

And done 😄

I'm going to tackle https://github.com/bevyengine/bevy/issues/13980 and https://github.com/bevyengine/bevy/issues/13969 today

@forest forge, you wanted to take a look at https://github.com/bevyengine/bevy/issues/13728 right? I'd prefer a fresh, minimal fix at this point

[lethal urchin]

Don't show .to_bits in Display impl for Entity ready for review now

[lethal urchin]

@forest forge, @graceful sinew remade the EventReader::par_iter bug fix targeting the 0.14 branch for you

Every day I curse merging that events code reorganization PR during the release candidate phase 🙃

[graceful sinew]

Sorrrryyyyyy

[lethal urchin]

Ha, at least you are paying the price for your hubris yourself here :p

[graceful sinew]

If you need any other event retargetting doing let me know, happy to pay that price myself as often as I need to

[short lake]

@lethal urchin I'll make the new screenshots for the rendering changes today. I decided to not write or read any code for a few days but I'm planning on starting again today

[lethal urchin]

Thank you ❤️

[lethal urchin]

Fingers crossed that's the last critical bug fix for events this release

[lethal urchin]

And the BackgroundColor fixes are in too. More involved than I expected, but I like the design we ended up on

[forest forge]

https://github.com/bevyengine/bevy/pull/14020

[forest forge]

@lethal urchin do I cherrypick https://github.com/bevyengine/bevy/pull/14017 for the 0.14?

[lethal urchin]

Yes

Apparently I forgot to label this

But yeah, this is in response to strong user dissatisfaction with that change

[forest forge]

yeah I was going through all the PRs merged and the missing milestone on it surprised me, that's why I wanted to check 🙂

[lethal urchin]

Thanks again for handling the branch and shipping the release candidates

[forest forge]

can't let you have all the fun

[lethal urchin]

Ah yes, "fun"

[glad osprey]

Meh, fun is overrated.

[lethal urchin]

I am enjoying the release candidate process, as much as I grumble

It's good to properly polish

[split agate]

I believe, it's quite important to once in a while be required to make everything fit together and work together.

I am quite impressed on how well it is handled in this community 🚀

[short lake]

@lethal urchin could you merge the compare slider fix (https://github.com/bevyengine/bevy-website/pull/1448) so it can be tested with the rendering PR? I guess I can just trust that the sliders work correctly

[lethal urchin]

It would need to be rebased to no longer include my PRs changes, otherwise we'll end up with the mediocre images in the main branch

Which is why I haven't merged the rendering PR already 😅

I would just trust it TBH

[short lake]

oh, I didn't realize it had those changes

[short lake]

@lethal urchin here's the PR. I wanted to make the images prettier than that, but I didn't do as many changes as I wanted. I made sure there wasn't text or the toolbar present in the image https://github.com/alice-i-cecile/bevy-website/pull/11

and all images are now 720p

[lethal urchin]

Much better!

[lethal urchin]

Are you in the mood to do https://github.com/bevyengine/bevy-website/pull/1442 too?

[short lake]

oh, and I added a slider for volumetric fog

[short lake]

yes and no, I'm not sure how to showcase this well 😅

[lethal urchin]

TBH I rather liked the Bevy cube on water

[short lake]

right, I guess we can just use that

[lethal urchin]

https://github.com/bevyengine/bevy-website/pull/1411 could use a quick review now that the images are in

[short lake]

I'll PR it soon

[lethal urchin]

Thank you very much ❤️

I was definitely procrastinating this 😅

[short lake]

@lethal urchin https://github.com/alice-i-cecile/bevy-website/pull/12 ssr images

[short lake]

@obsidian peak good catch on the filmic_color_grading missing. The main reason was that I had no idea how to show a before after, but I can still generate a screenshot without the titlebar

[short lake]

@lethal urchin https://github.com/alice-i-cecile/bevy-website/pull/13 new filmic color grading image

[lethal urchin]

It's so filmic!

I love the UI elements in that example

[hybrid junco]

getting this panic on exiting an app i'm upgrading on 0.14.0-rc.3. has anyone seen this?

thread 'main' panicked at /Users/char/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_ecs-0.14.0-rc.3/src/system/system_param.rs:629:17:
Resource requested by (bevy_ecs::event::EventWriter<bevy_window::event::WindowResized>, bevy_ecs::event::EventWriter<bevy_window::event::WindowBackendScaleFactorChanged>, bevy_ecs::event::EventWriter<bevy_window::event::WindowScaleFactorChanged>, bevy_ecs::system::system_param::NonSend<bevy_winit::winit_windows::WinitWindows>, bevy_ecs::system::query::Query<(&mut bevy_window::window::Window, &mut bevy_winit::system::CachedWindow)>, bevy_ecs::change_detection::NonSendMut<bevy_winit::accessibility::AccessKitAdapters>) does not exist: bevy_ecs::event::Events<bevy_window::event::WindowResized>

[forest forge]

I'm seeing this on the rc and on main too. it's when using a subset of Bevy features, but didn't have time yet to track it down

[calm bison]

is there a draft link for the release notes? I know the one for the migration guides, but the notes don't seem to live there as well

[lethal urchin]

Yes, lemme find it

https://github.com/bevyengine/bevy-website/pull/1442 needs a quick once-over before merging 🙂

https://bevyengine.org/news/draft-bevy-0-14/

[calm bison]

thank you!

[lethal urchin]

Seconding request for this: I'd like to tackle https://github.com/bevyengine/bevy-website/pull/1448 today, but I really want to get all of the sliders merged first

[heady frigate]

I can also target this to your repo if you want, I kinda thought the 3D release notes would be merged faster which is why I didn't bother

[lethal urchin]

I'd prefer to have this rebased off of main: the 3D rendering PR is merged now and there's a ton of conflicts 😅

[heady frigate]

Ah I didn't see it was merged, I'll rebase now

[heady frigate]

Done

[lethal urchin]

Fantastic, thank you so much

[lethal urchin]

https://github.com/bevyengine/bevy-website/pull/1459 I gave y'all a shoutout 🙂

[elfin temple]

Write away right away
Very nice

[lethal urchin]

I have fun with my commit names and branch names since we squash it 😄

[calm bison]

Is there a way to preview how a release note will look like before it is merged?

[short lake]

you can pull the change locally and run zola serve

speaking of, @lethal urchin the motion blur video doesn't seem to load at all for me

https://bevyengine.org/news/draft-bevy-0-14/#per-object-motion-blur

[calm bison]

Not just you, same for me

[forest forge]

loads for me, probably a codec issue...

also, the car model left front tire is painful to look at

[short lake]

auto exposure video is also broken for me, but differently. It shows the player but refuses to play, while the motion blur video just shows the alt text and nothing

[forest forge]

auto exposure broken for me too

there actually isn't a file for the auto exposure video 😄

[lethal urchin]

@rocky rover trade reviews? You rubber-stamp carefully evaluate my 28 line release notes PR, I complain about docs carefully evaluate your 2000 line function reflection PR

[rocky rover]

As long as you’re fine getting review from someone who doesn’t have the slightest clue about rendering (although I guess that’s often helpful)

Either way, I’m on it!

[lethal urchin]

Yeah, this was largely copy-pasta'd from the PR description, and IceSentry and Jasmine have both skimmed it too

[rocky rover]

(also again no pressure to review my PR right now, it is a 0.15 feature after all haha)

[lethal urchin]

Yeah, but I want something to procrastinate with :p

[rocky rover]

Well, enjoy!

[glad osprey]

Wouldn't that be anticrastination?

[lethal urchin]

No, it's pro-ductive-crastination

[rocky rover]

You have been successfully nitpicked

Next time don't give me such a long PR to review

5 lines or less please

;P

[forest forge]

we're two PRs away from the next (and final 🤞 ) rc!

[lethal urchin]

One ECS PR, one rendering: https://github.com/bevyengine/bevy/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.14

And a wgpu upgrade is also needed before Bevy 0.14 is shipped for real, but that shouldn't be an issue

[forest forge]

@rocky rover the ECS one is ~2 lines of actual changes 😄

[rocky rover]

Now we’re talking!

[lethal urchin]

@calm bison thanks for getting the Query sorting release notes in 😄 I've reviewed it now, take a look when you get a chance

Since this is the last release note, I'll probably fork your PR and finalize it myself tomorrow if you don't have a chance to get to it in the next 12 hours or so (zero pressure but giving you a heads up); I'd really like to get this in and move on to editing

[lethal urchin]

And I've pressed the button 😄

That's all of the release notes for 0.14 drafted <@&1064695155975803020>

[calm bison]

Already was addressing the review as it was being made!

I do apologize for not getting that done earlier, I overestimated how much work I could get done at the conference last weekend 😄

[lethal urchin]

Ha, I've learned to abandon hope for all other tasks at conferences

[calm bison]

I thought the "Impl Days" specifically reserved for sitting together and working were safe, but alas, I was proven wrong XD

But hey, I managed to receive credit to some cursed rust quiz addition instead

[lethal urchin]

Ha, Boxy did tell me they met you!

[calm bison]

We did have a nice conversation where we talked about our contributions on bevy! Boxy did have some code in the very query iterator file I worked on!

[forest forge]

wgpu 0.20.2 released: https://github.com/gfx-rs/wgpu/releases/tag/v0.20.2

[night gale]

I’ll take a look at the rendering PR

[obsidian peak]

Awesome! We should pin that as the minimum version, so the 0.20.1 and earlier don’t get pulled in by accident

[lethal urchin]

I don't think that works with cargo? I remember weirdness around patch versions here

[jaunty ermine]

if you just set it to 0.20.2 cargo will pick this version or any higher 0.20.x one with no issues 🙂 not sure what issues you remember about patch versions? this is just the normal behavior, and i don't think we would have conflicting wgpu versions?

[obsidian peak]

Yup, wgpu = "^0.20.2" should do it

[forest forge]

The ^ is not even needed

Cargo adds it by default

[obsidian peak]

Nice!

[lethal urchin]

okay great, I must have been misremembering

Oh wait, it was that setting crate = 0.20.2 will silently upgrade you, which is bad when crate authors don't respect semver

[obsidian peak]

Yes, you're likely thinking of one of dtolnay's crates for that

[jaunty ermine]

that is the case for everything unless you use =0.20.2 syntax?

[split agate]

not only that, sometimes the patch they use, use a rust feature they just found, and the MSRV gets increased, also sometimes messes with things 😛

[forest forge]

only wgpu-core was bumped to 0.20.2, and Bevy doesn't depend on it. I don't think it's worth it adding a direct dependency for that...

[lethal urchin]

The memory leak reported by @mystic forum needs investigation: reproduction and bisection are both essential

https://github.com/bevyengine/bevy/issues/14054

[forest forge]

probably not... it's on macos intel, that pretty much doesn't really work and isn't maintained anymore

also can't reproduce on macos arm

[lethal urchin]

Ah, that would explain why it hasn't been reported yet

[hybrid junco]

i can't reproduce

cargo 1.81.0-nightly (bc89bffa5 2024-06-22)

also macos arm

[forest forge]

closed it, easier that way 😄

I don't want new bugs in the 0.14 milestone 😠

[hybrid junco]

x86 mac is like soooo retro hehe

[mystic forum]

my main editor goal is to be able to run around the ECS world entities like the SGI 3D file explorer from Jurassic Park, so that checks out

[forest forge]

triggered a merge for https://github.com/bevyengine/bevy/pull/14027, I would like to publish a new rc once it's merged

any objection?

[lethal urchin]

No objections. The memory leak isn't new (and only hits a minor platform), https://github.com/bevyengine/bevy/pull/14048 needs more time to bake and is niche

[lethal urchin]

https://github.com/bevyengine/bevy-website/pull/1467

Bonus release note! Rendering folks please advise

[magic osprey]

Should I make PRs to remove myself from release notes where I feel like I shouldn't be an author, or will that be done in some final cleanup pass?

Asking because I am apparently an author of the working group process together with Alice, even though I was already removed from the list once before

There are also some PRs where I don't even have any recollection of reviewing anything, although I must've considering I'm listed

[lethal urchin]

Yes please

I'll try and sanity check them, but I'm liable to miss some otherwise

[magic osprey]

I wonder if we could also split these into "authors" and "reviewers" in the future, where the list of reviewers would be fully auto-generated, but "authors" would only have the primary author, and other people deemed as meaningful authors could be added manually

I don't necessarily love that I'm added as an actual author to PRs where I just reviewed a bit of docs for example, I'd prefer if the actual authors had more credit there. And cleaning it up manually feels kinda arduous and error-prone

dunno if GitHub's API lets you distinguish authors and reviewers like that though, haven't checked

[forest anchor]

Yeah I think authors should be filtered down to "primary contributors"

Reviewing, while valuable, is not the same as developing a feature

[gray moat]

oh dear, I feel like I should remake a more polished version of that video

[forest anchor]

@lethal urchin maybe we should default to Authors being populated by the original PR creator, then have a second (not actually rendered) list of "potential authors", populated by commit authors

Which we could then manually select from

[magic osprey]

Also I'm not familiar with how the release note metadata was generated, but I find it strange that this PR for example has seven authors including me, even though three of them haven't even commented on the PR from what I can see, and there are only two commit authors. I don't think I was even aware of this PR until after it was merged.

at least I have had zero connection with this work from what I can remember, so I don't know how I ended up there

[lethal urchin]

Agreed with this

[lethal urchin]

https://github.com/bevyengine/bevy-website/issues/1468

[obsidian peak]

Hey, all! I know @forest forge said that 0.14 is scheduled to release by the beginning of next week, but I don't think the migration guides can be finished by then. I'm only 44% of the way done, and don't think I can hit that deadline while maintaining quality

I think I can probably finish around the 5th or 10th, but not much earlier without significant help

[lethal urchin]

I'll pitch in once the release notes are done too, but we don't have to hit the quality level that you've been working at, especially initially ❤️

Our past releases were nowhere close, and it was largely fine

[obsidian peak]

Fair, but what we have right now is unacceptable. There are quite a few guides that just have "TODO," and nothing else

[short lake]

Yeah, most of the previous migration notes mainly had minor clean ups

[obsidian peak]

That reflects really poorly on Bevy, especially since those can be the PRs that need migration guides the most

[lethal urchin]

Prioritizing the "totally unacceptable" ones seems like the right call to me then

[obsidian peak]

I agree. I also want to run the generate-release too once more to catch any new changes

[short lake]

Oh, true, I did rewrite a few TODOs while making them, but what I generally did at the time was just look at the diff of an example and use it as the migration guide. There weren't that many in the past though

[lethal urchin]

Yep 🙂

[obsidian peak]

Well, unless anyone else wants to sacrifice volunteer themselves :P

[obsidian peak]

https://github.com/bevyengine/bevy-website/pull/1471

[mystic forum]

wow that is a lot of places events changed

[wary adder]

first author should be the PR author, after that come the contributors… it's a matter of splitting this into two props in the generated TOML (change generate_metadata_block to accept these in two separate vecs). Then update the release_notes.md template.

[wary adder]

no idea what's going on there, the list of contributors come from GitHub API 🤷‍♂️

[urban meadow]

https://github.com/bevyengine/bevy/issues/13861 I'm sad this still happens.
Just tried @gray moat 's bevy editor cam crate but I changed it locally to rc.4 and I get the wgpu warning spam still..

[wise juniper]

• https://github.com/bevyengine/bevy/issues/14059
• https://github.com/bevyengine/bevy/issues/14045

These two seem bad 👀

[lethal urchin]

Milestone them please so we can triage

[tropic lark]

I'd say it was ok-ish. I'm all for raising the bar a bit. There's a lot of upgrades where I had to cross-correlate several sources, dig into git history, etc. to understand how to upgrade. There's still some room for improvement. (I do am grateful for the guide to be there and any contributor to it, just want to support any effort in making it better)

[short lake]

To be fair, not to say there isn't room for improvements in other areas, but with hanabi you are uniquely positioned to hit much harder migrations than a lot of other users. For me at work, most migrations have been mostly fine for everything that isn't rendering but migrating rendering stuff always takes way longer and requires me looking at the diff of a bunch of PRs.

[tropic lark]

That's a fair point

I guess rendering also sees a lot more complex changes than any other area, which doesn't help

[wise juniper]

Personally, past migrations followed a similar pattern: everything was pretty easy until something touched rendering (or assets V2) and I had to dig through git

[split agate]

Jumping in quite late here, but is there a workflow on how to help anywhere? If there is a need for help from people like me that are not directly involved?

[vernal moss]

There is! We are sort of in the process of rewriting these guidelines (and that work is on hold because of the release) but let me direct you to https://github.com/bevyengine/bevy/blob/main/CONTRIBUTING.md

Specifically the section on how you can help. There’s lots of ways to help, and all of them are greatly appreciated!

[tropic lark]

Re-posting here from GitHub : confirming that Hanabi works again as of 8a7d3ce4 with the fix for BinnedPhaseItem. Thanks @analog yacht and @forest forge 🙂

[wise juniper]

That's great to hear 😄

[tropic lark]

Yeah I had little concern after the bug was root caused, but nice to double-check. Also confirmed another bug (need ktx2 and bevy_pbr dependencies) is gone, I reverted those features and everything builds fine

[lethal urchin]

Very pleased to hear about both 🙂

[wise juniper]

Dunno if this was noted already, but the meshlets screenshot should probably have its window decorations removed for parity with the other screenshots.

[obsidian peak]

Could you make an issue for that on the website repo?

[wise juniper]

Done: https://github.com/bevyengine/bevy-website/issues/1474

[obsidian peak]

Thanks!

[lethal urchin]

@tardy oracle would you be interested in submitting the beautiful tilemap editor screenshot you shared in #ui for the release notes? I'd love to supplement our rounded corner notes with it

[tardy oracle]

@lethal urchin sure! I'm about to deploy live on my website if you want to get a better screenshot yourself.. or feel free to use the one here 🙂

[lethal urchin]

Link it here and I'll make an issue for it (and include a link to your site in the notes)

[tardy oracle]

so a couple more things I've done a lot of UI work, something interesting is if you make 1 corner with no radius and the other 3 completely rounded, can sort of act as a pointer.

Another idea is if you have a node with a lesser curve and a different color on the outside of a sharper inner node. I think you get a sort of cool effect, shared in this screenshot.

[split agate]

Thank you,I will have a look tomorrow if not to hangover. Usually don't have that much time

[tardy oracle]

@lethal urchin
You can go to https://satoshisettlers.com click "Play as Guest" -> "Play as Guest" to check it out and play around.

3 main pieces of UI to show off, the art palette that you posted above. The "Go To" overlay ui menu and the "Buy" menu (you can see if you select a tile). Screenshots attached.

The reason for the keyboard is if you are on mobile sometimes it's difficult to trigger the keyboard, so I just made one in bevy.

Also, I think it's very kind of you to offer to list the website in the notes, but I just want you to know that people can go to the website and buy things so just as a disclaimer in case that's an issue.

[lethal urchin]

Yeah, I don't mind linking commercial projects made in Bevy as an incidental part of showing off features

EDIT: double-checking with the other maintainers here

[tardy oracle]

i spent like an hour making this as pixel perfect as possible.. lol maybe this screenshot would be better

if you want to see it on the map for yourself you can go click this icon then type in 299070 and hit enter, it'll take you there.

[gray moat]

FYI, I'm seeing a ton of dropped inputs on the RC, not sure if it has gotten worse since rc.2, but I was revisiting updates in bevy_editor_cam, and panning is super choppy. It looks like the framerate is poor, but it's just inputs. I'm running on a 120hz display, but it looks like input updates are happening somewhere around 30-60hz.

Pretty sure this is macos specific last time I looked at this.

[gray moat]

RenderLayers::all() no longer exists. Entities expecting to be visible on all layers, e.g. lights, should compute the active layers that are in use.
Are we now supposed to constantly compute this for all entities in the world? This doesn't seem like an adequate solution.

/// Entities without this component belong to layer 0.
If I'm reading this correctly, does that mean that cameras can now only see the renderlayers they have opted into? Previously they saw all layers when the component was not present, this seems like a pretty major undocumented breakage.

Also, what if I have a plugin that has no knowledge of how users are using render layers?

Was this change added after the initial RC? I wasn't expecting new features like this to land. That seems to defeat the purpose of the RC.

[languid meteor]

Isn’t that this PR: https://github.com/bevyengine/bevy/pull/13317

[wise juniper]

Are you sure this wasn’t the same behavior in previous versions?

[wise juniper]

Would you appreciate me trying to replicate it on both macOS and Windows?

[gray moat]

Nope, I was wrong, it has always been layer 0 by default. For some reason I recalled cameras having special behavior. with layers.

Oh, I think that confusion was from a while back. The docs say that cameras with the renderlayers component only show entities with intersecting layers, which seemed to imply that cameras without the component would render everything.

[wise juniper]

Oooh, I can see how one would come to that conclusion!

[hybrid junco]

this is why it says "compute" since a crate you don't control could in theory be doing RenderLayers::layer(random()) or whatever, although this language seems to have tripped a few people up when upgrading

[hybrid junco]

https://github.com/bevyengine/bevy-website/pull/1478

[short lake]

@hybrid junco do you have an idea about that? IIRC you looked into it at some point

[hybrid junco]

it improved after we merged winit 0.30, i'm wondering if it could be related to https://github.com/bevyengine/bevy/pull/14023 since we forward winit events inside run_app_update? theoretically it shouldn't matter since we buffer the events but tha did change post rc.2 if @gray moat's perception of degraded performance is correct

[gray moat]

It does seem noticably worse than rc.2, which had seemed to be a big improvement over 0.13.

[forest forge]

nop because I forgot to cherry pick that PR for the rc 😄

I did it today

[hybrid junco]

lolol, well that answers that!

[magic osprey]

ETA for 0.14 in #dev-announcements was the beginning of next week, which starts in two hours for me... I assume it won't actually be tomorrow though and it's getting pushed back a little again, so do we have an updated release date?
(asking because I'm wondering how much I need to crunch to get the Avian release ready...)

[forest forge]

no, tuesday at best, wednesday likely

still begining of the week 🤞

[magic osprey]

okay, thanks

[gray moat]

It could be placebo, but I did notice the dropped inputs immediately when running examples.

[forest forge]

how could I test that? is it a feeling thing, or is it observable?

[gray moat]

If you control camera rotation with your mouse, you can see it clearly in recorded video

Even more obvious with motion blur on, because the blur will flicker on and off as bevy sees zero motion

Last time I looked into this, it was solvable, but the only workaround I found was to re-run the winit loop as many as ten times for a single frame, just to ensure no inputs were missed.

[gray moat]

oh noooo

@forest forge good news

I think this is a me problem.

It looks like it is being caused by bettersnaptool

I used to use Magnet for the same purpose, but it also caused bugs in bevy apps, where the frames would stutter when dragging the window.

So, good news is it's caused by an app, bad news is that app seems to affect bevy, but not all other applications - similar to magnet.

[forest forge]

thanks for the news!

were you testing the 0.14-rc.2 on a computer without that?

[gray moat]

Nope, that's the strangest part

I even updated the smoothing settings on the camera after rc.2, because I noticed the input dropping was better, and I even tested going from 0.13 to 0.14-rc.2 to make sure it wasn't placebo.

So I have no idea what is going on, but it seems to be fixed after killing the app. It's possible there were multiple confounding factors.

[gray moat]

Any ideas why framepace systems don't appear to be running in RenderExtractApp? I went through the changes/migration, but don't see any reason why the systems seem to be not running any more.

Does the sub app no longer run its schedule after the extraction change or something?

I've verified that the subapp actually exists, before accessing it and inserting my own resources and system to the Main schedule. The system just never runs.

Everything works as expected if I do this in RenderApp instead.

It seems like something has changed with pipelined rendering and extraction.

Another issue, looks like wasm builds fail due to a misconfigured import for depth of field:

error[E0432]: unresolved import `crate::core_3d::DEPTH_TEXTURE_SAMPLING_SUPPORTED`
  --> /Users/aevyrie/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_core_pipeline-0.14.0-rc.4/src/dof/mod.rs:59:19
   |
59 |         Camera3d, DEPTH_TEXTURE_SAMPLING_SUPPORTED,
   |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `DEPTH_TEXTURE_SAMPLING_SUPPORTED` in `core_3d`
   |
note: found an item that was configured out
  --> /Users/aevyrie/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_core_pipeline-0.14.0-rc.4/src/core_3d/mod.rs:53:11
   |
53 | pub const DEPTH_TEXTURE_SAMPLING_SUPPORTED: bool = false;
   |           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: found an item that was configured out
  --> /Users/aevyrie/.cargo/registry/src/index.crates.io-6f17d22bba15001f/bevy_core_pipeline-0.14.0-rc.4/src/core_3d/mod.rs:63:11
   |
63 | pub const DEPTH_TEXTURE_SAMPLING_SUPPORTED: bool = true;
   |           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[obsidian peak]

Ideally once I finish all the migration guides, but I don’t think that will happen

(I’ll finish, just likely not before 0.14 is released)

[gray moat]

looks like there is an extraneous feature = "webgl", on the depth support const

huh, looks like the webgl backend is not automatically specified anymore.

[forest forge]

could you share the features you have enabled?

[gray moat]

one sec, I'm trying it with default features enabled

The issue is that the DEPTH_TEXTURE_SAMPLING_SUPPORTED cfgs have a gap - if you don't enable the webgl feature, DEPTH_TEXTURE_SAMPLING_SUPPORTED won't exist at compile time.

It seems like it should just fall back to false

[forest forge]

it's defined like that:

#[cfg(all(feature = "webgl", target_arch = "wasm32", not(feature = "webgpu")))]
pub const DEPTH_TEXTURE_SAMPLING_SUPPORTED: bool = false;
#[cfg(any(feature = "webgpu", not(target_arch = "wasm32")))]
pub const DEPTH_TEXTURE_SAMPLING_SUPPORTED: bool = true;

[gray moat]

Yes, and those cfgs are not perfectly opposite

if you are on wasm without webgl, it should be false, but the cfg is not met and the const is ifdef'ed out of existence

[gray moat]

It should be

#[cfg(not(any(feature = "webgpu", not(target_arch = "wasm32"))))]
pub const DEPTH_TEXTURE_SAMPLING_SUPPORTED: bool = false;
#[cfg(any(feature = "webgpu", not(target_arch = "wasm32")))]
pub const DEPTH_TEXTURE_SAMPLING_SUPPORTED: bool = true;

I'm able to compile and run in wasm after making that change

[forest forge]

well consider it an advanced feature issue detection, because bevy_core_pipeline won't work in wasm without either webgl or webgpu 😄

[gray moat]

though - that last part isn't totally true, oops, I also added back default features

[forest forge]

still would be nice to not fail to compile, for a plugin for example that doesn't want to select a backend

[gray moat]

If I fix the above, the wasm build fails at runtime with a helpful message, which seems much more correct to me

No wgpu backend feature that is implemented for the target platform was enabled

Right now, it's just DOF that fails at compile time in this one spot

[forest forge]

we should really tackle https://github.com/bevyengine/bevy/issues/13168 (supporting both webgl2 and webgpu in one binary), those features are a pain

[undone solstice]

I noticed some issues in the observers code in the release-notes: https://github.com/bevyengine/bevy-website/issues/1479

[gray moat]

https://github.com/bevyengine/bevy/pull/14081

[lethal urchin]

@odd crane if you can get the "deregister events" PR or an issue up, I think I'm okay putting it in the release candidate. Looks like we'll want another quick one anyways

[odd crane]

I'll jump on that RN

[lethal urchin]

Sounds great ❤️ Not to pressure; I just don't have a good enough understanding of your needs to do it myself

[odd crane]

For my stuff, I may need something else (ran into deeper problems so uncertain ATM - I can add detail, but don't want to mess up this thread) - but I can still add an initial version of this

[azure kestrel]

Ping me for review, I could use that myself

[odd crane]

@azure kestrel @lethal urchin https://github.com/bevyengine/bevy/pull/14083

[azure kestrel]

I didn't expect it to be this simple tbh

Scoped events don't seem that difficult now, just need to figure out how to handle non-existing Events<E> with EventWriter and EventReader

[hushed thistle]

There’s an open issue for this somewhere — someone tested with wgpu and/or winit and thought it may actually be a bevy thing somehow.

[lethal urchin]

Writing code without a compiler is hard 😅 https://github.com/bevyengine/bevy-website/pull/1482

[azure kestrel]

?

ohh

[lethal urchin]

Final release note is being merged: https://github.com/bevyengine/bevy-website/pull/1467

@west osprey let me know if you have follow-up concerns; I want that in ASAP to making editing feasible

[hybrid junco]

for nannou, we test our markdown using https://github.com/budziq/rust-skeptic which works great!

[lethal urchin]

👀 Very interesting; we ended up hand rolling something similar for the new book

[west osprey]

Will check during my.lunch break in 1h

We're not planning on doing the release today, are we? I need to adjust the meshlet section slightly tonight

[lethal urchin]

Nope 🙂 Still need to grab a couple of last-minute fixes, and there's quite a bit of editing to do

I'm going to do the mechanical cleanups next

[west osprey]

Looks fine. A typo for the word accurate, and the first sentence of the second paragraph is not grammatically correct.

I still want to show/have an example, and clarify the difference between CPU time spent recording the commands, and GPU time spent executing the commands (later on, separate from recording). Maybe at the end where it says CPU time, GPU time, clipper invocations, etc, put what I just said on parentheses after the CPU/gpu bullets.

Example can be skipped though, sure

[lethal urchin]

https://github.com/bevyengine/bevy-website/pull/1484 needs a quick review: just mechanical cleanup

[lethal urchin]

Dead section yeet time 🙂 +0/-52

[forest anchor]

I think its worth covering motion vectors / TAA for animated meshes. I can write that today

Also currently doing an editorial pass for the release notes

[lethal urchin]

Great, please do. I'll revert that change

Quick gizmo condensation change for review: https://github.com/bevyengine/bevy-website/pull/1486

[forest anchor]

Approved

[lethal urchin]

And a tiny PR to help justify the SpriteSheetBundle deprecation: https://github.com/bevyengine/bevy-website/pull/1487

[forest anchor]

Approved

[lethal urchin]

@analog yacht @tropic lark @undone solstice are any of you able to take https://github.com/bevyengine/bevy-website/issues/1386 ? I don't feel confident tackling this one myself

Other than that, the website milestone is looking pretty good. Just migration guide polish, one more release note and editing passes to do

In terms of actual engine work, we just need https://github.com/bevyengine/bevy/pull/14048 in

@forest anchor I'm going to let you do your editing pass, and then review it again tomorrow.

[forest anchor]

Sounds good

[undone solstice]

I'll get on it now and get something up for review

[lethal urchin]

Awesome, thank you so much

[tropic lark]

Nope. I understand vaguely the bug but not enough to explain the overall change.

[forest anchor]

As a heads up, we aren't currently running markdownlint on the release notes content

I'm running it locally + fixing things this time around. But we should tie it up to CI

[undone solstice]

I did a pass here. https://github.com/bevyengine/bevy-website/pull/1491 (and cc/ @obsidian peak )

[forest anchor]

https://github.com/bevyengine/bevy-website/pull/1492

[obsidian peak]

https://github.com/bevyengine/bevy-website/pull/1493

I'm going to sleep now

[west osprey]

Can someone else try recording the meshlet example? I'm sorry, I can't seem to get a good video. This one is choppy :/

nor particulary well directed lol

[forest forge]

anything you want to show off specifically in the video? just a camera zooming in an out? no orbiting?

[west osprey]

Angle dosen't really matter. Just zooming in and out, but ideally a better job than I did, leaving some pause time at the different levels 😅

You can also go to https://github.com/bevyengine/bevy/blob/main/crates/bevy_pbr/src/meshlet/visibility_buffer_resolve.wgsl#L164 and replace cluster_id with triangle_id to visualizes triangles, fi you think that's better (it's probably harder to see)

Up to you what you think looks good

[forest forge]

@west osprey is that good for you?

[west osprey]

Perfect, thank you!

I'll go submit the release notes

Shame I never built the cluster/triangle count overlay

would be neat to show the changing geometry count as you zoom in/out

[forest anchor]

https://github.com/bevyengine/bevy-website/pull/1495

Didn't make it all the way through all of the sections, so I'll continue tomorrow in another PR

[forest forge]

removed the most far zoom out, and replaced it by a closer zoom in at the end. and more bunnies and better shadows! I feel it's prettier that way 🙂

[pulsar terrace]

something else that would be cool is having a stationary shot while seeing LOD's changing, but I'm not sure how much work it'd be for it to be separated

[forest forge]

setting up the view is easy, but I don't know about it using the LOD of the other camera

[wise juniper]

Looks super nice! 😄 How did you setup that in code? Did you hatdcode a list of camera transforms and then just lerp between them after a delay?

[forest forge]

yup, "hatcoded" a few transforms, and lerp between them with bevy_easings, but that wouldn't be complicated to set it up without a third party plugin, it's just the one I'm used to

[lean axle]

I think it would be better if the links to examples on the release blog (at the end of many of the sections, there are calls to action, to try the feature being showcased using an official example) point to the bevy website, instead of the GH repo source file

since we have all the official examples viewable on the bevy website, we should make use of that

[lethal urchin]

Agreed 🤔

[west osprey]

Not easy to setup

[west osprey]

@lethal urchin Francois made an even better video. Do you want me to open another PR, or do you want to just replace the video yourself in whatever the next PR you make is?

[night gale]

Nice 😊

[lethal urchin]

I'll swap it 😄

[short lake]

Some examples don't work in wasm, but for the ones that do it would probably be a good idea yes

[night gale]

Was the problem with how we drive the app schedule from the winit loop fixed @lethal urchin ? Iirc the call to run an app was discovered to have been moved from what on web corresponds to requestAnimationFrame to instead being called outside of that callback. That resulted in potentially trying to render multiple times per refresh

Pretty sure that was reported as an issue

[lethal urchin]

@forest forge shipped a robust mitigation, but a proper fix is probably still helpful

[lethal urchin]

https://github.com/bevyengine/bevy-website/pull/1498

[forest anchor]

Today I'm continuing my editorial pass

[lethal urchin]

@forest anchor I'm going to do a pass on the migration guides now

[forest anchor]

Excellent!

[lethal urchin]

Opened https://github.com/bevyengine/bevy/issues/14113 so we don't forget

[lethal urchin]

And the migration guide editing pass is ready for review: https://github.com/bevyengine/bevy-website/pull/1499

[lethal urchin]

Tackling this now

The backport PR needs a review and then I'll merge it in

<@&1064695155975803020>, all that remains to be done is:

• [ ] merge the migration guide edits
• [ ] finish editing the release notes
• [x] cherrypick the final PRs onto the branch
• [ ] generate the change log
• [ ] generate the contributors list
• [ ] release Bevy 0.14
• [ ] undraft the release notes
• [ ] pick and add a splash image
• [ ] announce the release

[west osprey]

Are we releasing today? Finally 🤩 , this has been such a long release 😅 . Feels twice as long as usual.

[lethal urchin]

Yeah, I think we can do it, but no crunch!

There was so much stuff, and the release candidate proces really did take ages (with good reason)

[forest anchor]

I think at this point we should hold off until tomorrow in the interest of releasing early / in the morning (I understand the world doesn't revolve around the PST time zone, but if we do it this way we can field social media responses as they come in).

[lethal urchin]

Yeah, the first few hours are always a flood

And my dad is getting in tonight so I won't be around to work "overtime" :p

[forest anchor]

I do have an appointment at 1pm tomorrow, but it shouldn't take long. I think we should aim to release before then

[forest forge]

🍒 ⛏️

[glad osprey]

Will there be a release process post-mortem?

[lethal urchin]

I want to talk about it, and then I'll write up a discussion post

Nothing too formal

[forest forge]

everything is cherrypicked, the branch should be ready

[forest anchor]

We should re-encode the media content prior to release. We're clocking in at 51 MB right now 🙂

Also the SMAA section is missing an image / currently references one in its text

[lethal urchin]

https://github.com/bevyengine/bevy-website/issues/1500 🎟️

[forest anchor]

Hmm also weirdly all the media is broken when I run zola serve now

(I am running 0.19.1 right now, but I was doing it yesterday with no problems 😢)

[forest anchor]

Its making requests for /news/selected_extrusions.png instead of /news/draft-bevy-0-14/selected_extrusions.png

[obsidian peak]

Seems to be this line: https://github.com/bevyengine/bevy-website/blob/1fc8745aef74aef910fcac864b6b2cec6ddb582e/release-content/0.14/release-notes/13270_Extrusion.md?plain=1#L67

[calm bison]

zola 0.18 worked for me, though it the way 0.19.1 was broken might not be the same as what you're referring to

[obsidian peak]

@lethal urchin, I reviewed your pass on the migration guide, thanks!

[lethal urchin]

Merging 🙂

[forest anchor]

Removing that doesn't fix anything for me

Ah you're saying thats the source of that broken link

Sadly every link is broken with zola serve

(to media)

[obsidian peak]

Huh, I would definitely try building Zola 0.18 and trying it again

[forest anchor]

Running zola build and hosting with a python web server makes everything work

So its definitely an zola serve state problem of some kind

[forest anchor]

Innnnteresting 0.18 is also broken

[lethal urchin]

No choice, have to re-install your OS

[forest anchor]

😭 nooooooo

[lethal urchin]

I think a cache is borked somehow

[floral parcel]

I noticed in the component hooks/observers release notes it mentions component hooks always run before observers, but is it not the case that on_remove component hooks run after observers?

[lean axle]

also i think it is worth explicitly pointing out that observers do not run in parallel with scheduled systems.

also, minor nit: in the HLODs section, there was a sentence that said that objects can be hidden/revealed based on "distance to the player". that should be "distance to the camera". not all games are first-person 😉

[split agate]

some are even applications...

😄

[lean axle]

i am not going to bother making a PR, because, surprisingly to me, i dont really have any more comments regarding the release notes

i read through the whole thing today, looking for all the usual things i used to comment on before (when i reviewed older bevy releases), and it was actually pretty good imo

all the sections are in a reasonable sequence and a lot of the unnecessarily verbose explanations have been cut down. though maybe some of the code examples feel a bit long ...

but that is often unavoidable with code examples

i would recommend making them collapsable

i started doing that in cheatbook and i think it is pretty good

you get the explanation and a prompt to expand the code, you click on it, and you see the code

helps reduce the clutter on the page, when the code snippets are longer than 10-20 lines or so

which they often have to be

small code snippets are fine without being behind a collapsable thing, ofc

[lethal urchin]

Issue please

[split agate]

I was trying to build the webpage from source, to have a lookover before bed. But cant seem to find the 0.14 version when doing zola serve, do I need to add something?

[lean axle]

http://127.0.0.1:1111/news/draft-bevy-0-14

make sure you use the correct URL

[split agate]

ah, manaully going to the content, thx

[lean axle]

the 0.14 page is not listed in the blog, because it is a "draft"

[calm bison]

broken in what way? I forgot to mention that I had to use a 6 month old nightly to get 0.18 to compile from source

[forest anchor]

Zola serve produces incorrect links for linked media content (I described the problem above)

[split agate]

under "whats next" in the news part, the link to the design doc of the better scenes is still towards a TODO

https://github.com/bevyengine/bevy-website/issues/1502

[forest anchor]

As a general thought: we should be doing fewer "large blocks of code" and instead progressively disclose things piece by piece, with each block of code preceded by a small amount of text describing it

Makes things feel less daunting by breaking things up logically and gives people some breathing room

(I'm doing that as I go for my current editorial pass)

[wise juniper]

Don’t have time to reproduce it right now, but it would be good if someone checked out https://github.com/bevyengine/bevy/issues/14117 before the release. Tagged it in the milestone for triage.

[forest anchor]

https://github.com/bevyengine/bevy-website/pull/1504

[undone solstice]

possible issue with the rc when trying to upgrade aery: https://github.com/bevyengine/bevy/issues/14118 cc/ @knotty stirrup (I think you maintain aery?)

[forest anchor]

Did another pass (still have more to cover though)

[knotty stirrup]

Oh I already have a 0.14 branch https://github.com/iiYese/aery/tree/014

I can work with the NopWorldQuery removal in my case.

I just haven't released an rc versions.... which I probably should have because it would have been good to have people test if the reflect was working correctly

[undone solstice]

ok cool, I missed that there was a branch already 😅 , sorry for the ping

[knotty stirrup]

You're good. No worries.

[lethal urchin]

I love the heavily-commented code style, but I'll defer to you :p

[lethal urchin]

Ticket created

[floral parcel]

I think I was wrong, I remembered that being the case but I'm looking at the code and it looks the on remove hooks/observers do run in the same order as the others

[tropic lark]

I'm conflicted about this. I don't think third party crates should release an RC. For me the Bevy RC is for those crates to make sure they can upgrade. If we start to have a more formal RC process where all crates release, this puts a huge burden on crate maintainers by adding several releases per cycle.

(we're not at a point where Bevy is in 1.x and stable, and we have long RCs for external end user apps to test)

[forest forge]

one of the point of the rc was to reduce pressure on plugin authors to be ready on release day. if we put pressure on them to be ready on rc day, that doesn't change anything

[bronze stream]

releasing an RC for a 3rd-party crate allows other 3rd-party crates that depend on it to upgrade early

if there are no dependent 3rd-party crates, then that point is moot ofc

also you should only have to release once to be compatible with all bevy 0.14 RCs. they're semver-compatible and (ideally) shouldn't include big breaking changes

[forest anchor]

https://github.com/bevyengine/bevy-website/pull/1506

[forest anchor]

https://github.com/bevyengine/bevy-website/pull/1507

[lean axle]

i absolutely agree. but i still stand by my suggestion that, should it not be possible to make code blocks small for whatever reason, they can be made collapsable/expandable by wrapping the whole thing in a HTML <details> tag, which can be done within Markdown source, like:

<details>
<summary>Code Example:</summary>

// code block here as usual

</details>

[forest anchor]

Agreed. I actually added one in my "third pass" PR above

[lean axle]

awesome

i love that the bevy website can adopt some of these stylistic tricks to make content less cluttered and more readable/presentable

i've started doing both of these things (split code examples into multiple blocks/sections, with interleaved explanation + make them collapsable/expandable if long) in cheatbook with, i think, great success. it really improves the presentation

it looks like the 0.14 release notes will be on a whole new level of quality

the RC period is good ❤️

[split agate]

while waiting for my wife to get ready ( the legendary 5 minutes ) I thought I might as well add the link to the bsn implementation I read about ( and saw some prototype code for ). But it seems to have gotten lost in the discord somewhere

and now I got to go 🙂

[lethal urchin]

@forest forge we've got another PR to cherrypick: https://github.com/bevyengine/bevy/pull/14121

[lethal urchin]

https://github.com/bevyengine/bevy-website/pull/1508 opinions on the cover image selected here?

[lethal urchin]

Oh and thanks @hushed thistle and @rapid yoke for spotting and fixing this 😄

[oblique sparrow]

Personally I find this image clearer and more appealing #rendering-dev message

The proposed image feels like the sun is shining in my eyes

[magic osprey]

At least to me that image looks much more fake and boring though, there's no skybox, the buildings and props look almost like plastic, and the lighting feels off apart from the god rays

The PR's image is maybe a bit too bright but otherwise I like it a lot

[lethal urchin]

How about this one?

[lethal urchin]

We're already using this in the body FYI

[wise juniper]

This still feels like I'm being blinded by something trying to annoy me with a flashlight, imo

[magic osprey]

Pretty good, not sure if I prefer it over the original though. If I'm nitpicking, I don't like the close-up tree on the left since you can see the lack of detail clearer and it kinda jumps out from the rest of the image. Also feels slightly oversaturated and/or bright

[vernal moss]

We are getting to the point where taking advantage of the rendering features requires skilled artists. Everything we have is dev-art, it will be fine for showcasing the new features.

[wise juniper]

That's fair

[wise juniper]

With that in mind, this one is best imo 🙂

[vernal moss]

I agree, it shows off rays, screen-space reflections, bloom, hdr/tone-mapping and color-grading.

[magic osprey]

I'm getting weird noise in the horizon running this myself :P

[forest forge]

we should build a gene with the parameters available (position of the camera, color grading, lighting, ...), make a script that takes the screenshot corresponding, post it on discord, and evolve the gene depending on the emoji reactions

[lethal urchin]

Yeah, we definitely need both better assets and actual artists :p

[vernal moss]

Those are kind of the same thing. Funding and tools, then maybe we will start to attract some.

[lethal urchin]

States migration guide and Hooks vs observer release note clarification are up and need review

[magic osprey]

What about something like this?

[lethal urchin]

I like that better!

Has the strengths of IceSentry's image without the ugly low poly tree in the foreground

[magic osprey]

yeah I just adjusted the config a bit to make the sky slightly less bright and more pleasing, and tried to showcase all the rendering features

(also vaguely follows the golden ratio lol)

the hot reloading is nice for getting the details right

[vernal moss]

I like that best

the skybox is nicely done

good exposure

[wise juniper]

Great job 😄

[magic osprey]

Thanks :) now back to Avian release prep lol

[oblique sparrow]

To each their own. Personally I think it's much clearer what the god rays are doing. Honestly, I still feel like the alternatives are shining light into my eyes but I'm just one vote.

[magic osprey]

I was going to say we have the image in the body already like @lethal urchin said ^ but it doesn't actually look like it? Unless it's in some unmerged PR

Either way, I agree it might be clearer for god rays specifically, but I think for the cover image we should pick what is overall the most appealing and showcases the engine's (new) features best. Not just god rays, but also screen-space reflection, filmic color grading, etc.

[lethal urchin]

Ah maybe we didn't end up going with this

[oblique sparrow]

What about a different angle that isn’t staring into the sun?

With the right sun angle the god rays should point downward under the tree

[magic osprey]

that's a lot harder to get right without losing a lot of the scale while also trying to showcase stuff like the water shader

[short lake]

The point of the three was to test depth of field. I didn't post that screenshot expecting it would be used though lol

[short lake]

It was a bit annoying to setup, but really nice once it was ready

[magic osprey]

if the sun comes from above, you need to put the camera much lower and closer to the trees for the god rays to work

[short lake]

That's why I picked something with the sun low, so I could easily see the god rays from various angles

[west osprey]

It would be neat to convert everything to meshlets, take a screenshot of the meshlet debug material showing the clusters, and then composite them together like the nanite screenshots. A decent amount of work though.

[short lake]

The terrain is a procedural mesh, so I'm not sure how that would work. The trees could do that pretty easily though

[azure kestrel]

Does debug view do edge highlights?

[short lake]

no, but that's trivial to do with EDL (eye dome lighting)

I'm 98% sure that's what they did here

[lethal urchin]

SMAA slider images: https://github.com/bevyengine/bevy-website/pull/1513

@forest anchor I'm going to run errands now, but for when you're around:

1. Resolve merge conflicts and merge https://github.com/bevyengine/bevy-website/pull/1507
2. Merge or close https://github.com/bevyengine/bevy-website/pull/1513
3. Swap to @magic osprey's forest screen shot and merge https://github.com/bevyengine/bevy-website/pull/1508
4. Do the small tasks in https://github.com/bevyengine/bevy-website/issues/1188 to finalize the release
5. Cherrypick https://github.com/bevyengine/bevy/pull/14121

I'm fine to release today; I think we're pretty much all good and I'm fine to spend my evening on social media

[night gale]

it's giving me twin peaks vibes

[forest anchor]

Cool cool. I'll get started on that stuff now. If we're in a good spot at a reasonable time im down to release today.

[hushed thistle]

Seems like https://bevyengine.org/learn/migration-guides/0-13-to-0-14/#decouple-backgroundcolor-from-uiimage is a bit out of date now.

[undone solstice]

what's out of date about it?

[hushed thistle]

Oops, my bad, brain malfunction. Seems fine.

[bronze stream]

no i think you're right. the ButtonBundle has a BackgroundColor component now that you can continue to use the same way as in 0.13, so the second code block can be deleted

well both code blocks can be deleted. and probably replaced with an example where UI image tinting is the actual intent:

// 0.13
ButtonBundle {
    image: UiImage::new(my_texture),
    background_color: my_color_tint.into(),
    ..default()
}

// 0.14
ButtonBundle {
    image: UiImage::new(my_texture).with_color(my_color_tint),
    ..default()
}

made a quick pr: https://github.com/bevyengine/bevy-website/pull/1515

[obsidian peak]

In this PR, the text on both images are on opposite sides of the screen

Check the actual diff, not the screenshots in the PR description

[lethal urchin]

That's intended

[obsidian peak]

Ok, sounds good

[lethal urchin]

Anyone want to bump bevy_color to 0.14.1? Targeting the release 0.14 branch please

[forest forge]

this needs to be done after the release command has been executed on the branch to bump everything

[undone solstice]

https://github.com/bevyengine/bevy/pull/14125

[lethal urchin]

Ack I merged it before checking this thread

[forest forge]

I'll force push to the branch to remove it 🤷‍♂️

https://github.com/bevyengine/bevy/pull/14126 here's my take on bumping bevy_color to 0.14.1...

[lethal urchin]

If anyone wants to be helpful, one of the very last remaining tasks for the release is to generate the changle log and contributors list 🙂

the generate-release tool should have a script for this already

[undone solstice]

I'm happy to take a try at it

[lethal urchin]

Sounds good, ping me here if you run into any trouble

[undone solstice]

I ran this for each

cargo run -- --from v0.13.2 --to main --release-version 0.14 <command>

• contributors: https://github.com/bevyengine/bevy-website/pull/1517
• changelog: https://github.com/bevyengine/bevy-website/pull/1516

[forest forge]

I don't remember how those scripts work but shouldn't they be --to release-0.14.0? main has commits that won't be in the release

[undone solstice]

If that's the case then the README needs an update too

(I'm happy to rerun it)

[forest forge]

well it's the first time the release won't be from main because of the rc

[undone solstice]

hah, right. that makes sense 😆

so to v0.14.0-rc.4 then

or branch release-0.14.0

[forest forge]

🤔 and --from v0.13.0 instead of the latest patch means the contributors who did things in those patches will be credited in the release, otherwise their commits won't be visible in a contributors list or a changelog

I would say the branch

[undone solstice]

cargo run -- --from v0.13.0 --to release-0.14.0 --release-version 0.14 contributors

[lethal urchin]

@undone solstice we also need to update the numbers at the top of the blog post to match 🙂

Currently those are just TODO

[undone solstice]

updated and alice beat me to an approval before I messaged 😆

[lethal urchin]

Feel free to just toss the number updating into one of your two open PRs

[undone solstice]

changelog pr has them now

[lethal urchin]

253 contributors, 901 PRs

Christ...

[undone solstice]

its a lot lol

[vernal moss]

a significant increase from the previous releases

[undone solstice]

+55, +229

[hushed thistle]

looking at diff / raw new contributors file contents in that PR, I happened to notice that maniwani is no longer listed, which seemed odd. I am pretty sure they contributed this cycle: https://github.com/bevyengine/bevy/pull/9202 was merged on Mar 30.

[vernal moss]

We added 18 new contributors from 0.12 to 0.13

[undone solstice]

they are in the list of "PRs not found"

PR not found for refactor: Extract parallel queue abstraction sha: e34fb68677aef4269d376273903800cb4228d8b7
PR not found for also look in just_pressed touches for position sha: 4134351d9b4d14a352c1eccff6dc334fda1593ce
PR not found for Added `add_group` to `PluginGroupBuilder` sha: bb00d9fc3c06dbd27e9e4bea25ad8bc71e07677d
PR not found for bevy_reflect: Recursive registration sha: ccb9d0500f88fe93bf7c43647fe6a8efc5d82030
PR not found for Add table showing complexity of methods for Input sha: 1b3c2b0fed4821d2a8a7554330310ae7f675373d
PR not found for Add pipeline statistics sha: 737b719dda79e15aa70b3a390c871070519f34e0
PR not found for Meshlet rendering (initial feature) sha: 4f20faaa43a5f3c8743be1c9eef13c3debbd1be5
PR not found for Refactor `App` and `SubApp` internals for better separation sha: 01649f13e2d7891573e3f128b27848d286536a89
PR not found for Per-Object Motion Blur sha: ade70b3925b27f76b669ac5fd9e2c31f824d7667
PR not found for Add error when extract resource build fails sha: 4b446c020e476eadb5da2af923965946abdb826a
PR not found for Add doc comments explaining the different behaviours of `alignment` and `Anchor` with `text_2d` sha: be217ab037b6fe763f42542204773a18d0108e3b

for the changelog output ^

[hushed thistle]

Ah, ok.

[undone solstice]

same for the contributor output

[lethal urchin]

We should add those in manually

[undone solstice]

I added the tool output to each PR description

that also bumps the numbers up (993 merged prs)

901 made it to the changelog

Should I add the missing PRs to the changelog? I've already added the missing contributors (3) to the contrib list

[lethal urchin]

Yes please 🙂

[undone solstice]

IMO: all of the missed PRs look like they got excluded because they were originally opened before the "from" date for the release

most have sub-10k ids

[lethal urchin]

I'll open an issue 🙂

[undone solstice]

prs added to changelog

[lethal urchin]

Awesome, merging both

[short lake]

IIRC it should be based on the closed by date, but it's very possible github is just returning something wrong

[lethal urchin]

https://github.com/bevyengine/bevy-website/issues/1188

• [ ] Undraft the release notes
• [ ] Bump bevy_color to 0.14.1 and other crates to 0.14.0 using: https://github.com/bevyengine/bevy/pull/14126
• [ ] Release Bevy 0.14 on crates.io following https://github.com/bevyengine/bevy/blob/main/docs/release_checklist.md
• [ ] Announce Bevy 0.14
  FYI @forest anchor 🙂 We should be able to do this first thing tomorrow morning when you're ready to face social media

[undone solstice]

yeah its basically that the set of PRs fetched by page doesn't include the older PRs because the issues url is sorted by id descending and stops at the 0.major.1's date

and you can't sort the issues api by "closed_at", only "created, updated, comments"

[undone solstice]

would it be possible to get a "lower bound estimate" on the earliest the release could go out tomorrow? I have a 0.14 video I'd like to push out after the release goes live and want to make sure I'm awake to do it.

[forest anchor]

Excellent. I think we should probably merge the version bump now just to get ahead of things?

[lethal urchin]

No sooner than 15 hours from now (9 am PST)

[lethal urchin]

Yep!

We can also prepare but not merge the undrafting PR

[forest anchor]

good call

[forest anchor]

Just merged the version bump

[west osprey]

Very excited for the release tomorrow!

[languid meteor]

Cover image is deformed on mobile

(Also seems to be the case for 0.13 cover image)

[languid meteor]

removing the hardcoded width seems to fix it:

diff --git a/templates/news-page.html b/templates/news-page.html
index 704ebc1..738e473 100644
--- a/templates/news-page.html
+++ b/templates/news-page.html
@@ -52,13 +52,11 @@
       {% if page.extra.image_subtitle %}
         <img src="{{ page.extra.image }}"
               alt="{{ page.extra.image_subtitle }}"
-              width="926"
-              height="521" />
+               />
       {% else %}
         <img src="{{ page.extra.image }}"
               alt="An image representing the article"
-              width="926"
-              height="521" />
+               />
       {% endif %}
       {% if page.extra.image_subtitle %}
         {% if page.extra.image_subtitle_link %}

[hybrid junco]

it should probably be using a media query

[languid meteor]

there is a max-width of 100% on the image. Wouldn't that do in all cases?

[forest anchor]

Yeah this was introduced here: https://github.com/bevyengine/bevy-website/pull/1026/files#diff-672b08946ef5cbc8db5c086bf50651b69b29e9d7be0708a1de7ded170b440e99R56
Adding hardcoded widths/heights everywhere definitely rubbed me the wrong way when it was done. I don't understand the rationale there.

We should remove them both imo

Putting together a PR now

[languid meteor]

what do you mean with "both" and do you want me to make a PR

[forest anchor]

Both the hard-coded width and height

[languid meteor]

ah, thought i missed one in the diff

[forest anchor]

https://github.com/bevyengine/bevy-website/pull/1519

We'll see if the linter yells at me

[languid meteor]

(merging now in the interest of this not holding up tomorrow morning's release)
as it is already "today" in my timezone. what time is the release planned in your timezone?

[forest anchor]

we're aiming for 9am-ish PST

https://github.com/bevyengine/bevy-website/pull/1520

[languid meteor]

that would be roughly <t:1720108800:R>

[wise juniper]

https://time.is/0900_4_July_2024_in_PT?Bevy_0.14_Release

[languid meteor]

I think the discord timestamp will also count down. i hope 😅 we'll see in an hour

[runic igloo]

Note that this feature does not use GPU "mesh shaders", so older GPUs are compatible for now. However, they are not recommended, and are likely to become unsupported in the near future.
In the virtual geo section, the wording makes it sound like mesh shaders are not recommended and may become unsupported. It also sounds awkward to say older GPUs are "not recommended".
Note that this feature does not currently use GPU mesh shaders(https://developer.nvidia.com/blog/introduction-turing-mesh-shaders/), so it will work on older cards. However, due to the advantages of mesh shaders when dealing with virtual geometry it's likely they will be used in a future release, and therefore will no longer run on GPUs without them.
Aside: is there a better place to post this, github issue?

[wise juniper]

I think you can go ahead and just do a PR directly on the website

[runic igloo]

the final pr is coming from carts repo though, so he'd have to merge back in again to get any changes, bit awkward

[wise juniper]

Ah heck, you're right 🤔

[forest forge]

It can be fixed after the release too

There always are a few language or tech fixes in the following days

[magic osprey]

The "generous sponsors" link in the release notes intro goes to https://bevyengine.org/community/donate/. Shouldn't it be https://bevyengine.org/donate/ now that the foundation exists?

[lethal urchin]

Yep!

[lethal urchin]

Fixing now

https://github.com/bevyengine/bevy-website/pull/1521

[obsidian peak]

I believe hard-coding the width and height lets the browser allocate space on the page for the image, before it or the CSS has to load

If you have a slow internet connection, or the image is particularly big, it prevents elements on the page from shifting around after its initial paint

Since we can't use any server-side scripting to generate these values for specific screen sizes, it's probably best to just remove the hard-coded values

[magic osprey]

Yeah explicit image sizes are generally recommended on web to prevent cumulative layout shift, and its something e.g. Google Lighthouse flags about. It shouldn't be needed if we just use aspect-ratio though

see for example this
https://web.dev/articles/optimize-cls?utm_source=lighthouse&utm_medium=devtools#images_without_dimensions

So I would disagree about straight up removing the size without at least specifying an aspect ratio, but it's not that big of a deal

[obsidian peak]

Cool! I'll try to open a PR for this

Here's what it now looks like with the aspect-ratio tag

Here we go: https://github.com/bevyengine/bevy-website/pull/1524

[lost shadow]

Oh cool, I'll stick that into my bag of tricks.

[glad osprey]

We need some dramatic music!

[hollow coyote]

That was indeed part of the rationale for the change from what I can remember; it's just generally best practice to define width and height on images to prevent the weirdness of stuff popping in and layout shifting. Though, I didn't know about aspect-ratio; I wonder well that works with the mobile use case.

[obsidian peak]

I tested it using Firefox's screen ratio dev tool, so it seems to work

[forest anchor]

Cool yeah aspect-ratio (with the addition of auto) seems like the right pick here. TIL

The new docs.rs build queue setup is absolutely tearing through the bevy deployment. Very nice

[obsidian peak]

Oh, what changed?

[forest anchor]

not fully certain. vaguely remember hearing about an upgrade?

At the very least, what used to build up as a long queue is now processing them about as fast as they come in

[obsidian peak]

Sneak peek: https://github.com/bevyengine/bevy/releases/tag/v0.14.0

[forest anchor]

https://github.com/bevyengine/bevy-website/pull/1525

[undone solstice]

docs are live: https://docs.rs/bevy/0.14.0/bevy/index.html

[bronze stream]

complete set of filmic color grading tols

[azure kestrel]

States docs direct to old example files

That's on me, forgot to update after separating them

[bronze stream]

Better colors: type-safe
should be Type-safe for consistency

[azure kestrel]

Copied from #off-topic , mistyped type names for meshlets

[lethal urchin]

Awesome work y'all

Thank you so much

This was much less painful than previous releases for both Cart and I

[azure kestrel]

And that's with the release notes system being introduced pretty late, isn't it?

[bronze stream]

We still [have] a lot left to do

[lethal urchin]

Yeah, that was really added at the start of the stabilization phase

[vernal moss]

When are we going to start rolling notes for the next cycle?

[forest anchor]

Sooo much better

[lethal urchin]

ASAP ideally

Although I want a couple days vacation and ideally a couple days doing feature work first lol

[azure kestrel]

Doesn't compile, should use get_mut and fix the resulting errors

I hope it's alright to post the problems here, we want to fix them right?

[forest forge]

Better to post issues or PRs

[grim socket]

Issues:
https://github.com/bevyengine/bevy-website/issues/1526
https://github.com/bevyengine/bevy-website/issues/1528

[tardy oracle]

@lethal urchin looked at the release notes, didn't see this, i'm guessing I didn't make the cut? If you wanted an image with the bevy logo and the rounded paint palette ui, here's one for you.. but im guessing it might be too late.

[lethal urchin]

Yeah it was cut for space in the end ❤️

[reef tapir]

@lethal urchin It doesn't appear wgpu 0.20.2 was actually pushed to crates io. Do you know if this is a mistake by the wgpu people? related to: https://github.com/bevyengine/bevy/issues/13559

[vernal moss]

<@&1232768967341375599> ?

[atomic tinsel]

0.20.2 does not touch the wgpu crate, just wgpu hal and core 0.21.1

[reef tapir]

I see that now, sorry for the ping 🙌

[atomic tinsel]

Nw

[lethal urchin]

Yep, not a problem: it confused me initially too

[night cave]

I ran into this problem a few days ago. I had to downgrade to rust 1.77 to prevent a crash.
Upon upgrading to 1.79 today (and bevy 0.14) I ran into this issue again. I had to manually set wgpu-core and wgpu-hal to 0.21.1 to stop the seg faults.

[atomic tinsel]

cargo udpdate should take care of it

[reef tapir]

To confirm, I am indeed no longer experiencing this issue on 0.14 🙂
I was just confused for a sec when synchronizing all my dependencies to the new wgpu version

[night cave]

Heck yeah! Can confirm this works. Amazing how many times cargo has bitten me in the ass today xD

[lean axle]

should this working group be marked as "Competed" now?

[glad osprey]

I'd like to see the post-mortem, a summary of what worked well and what needs to be improved.

[forest forge]

are patches part of the release?

[jaunty ermine]

The release crew is dead, long live the maintenance gang!

[lethal urchin]

IMO yes

Also fixing up the migration guide as things are reported