Bevy 0.17 Release Crew

[edgy jetty]

Merging https://github.com/bevyengine/bevy/pull/20944

[dry rune]

Yeah I don't want to delay indefinitely either. I'd like 0.18 to be our "everything comes together" release for UI stuff

I'd love to have more attention to give 🙂

[edgy jetty]

@final zinc I'm cutting the window resizing bug from the milestone, per my comment

[final zinc]

I also wouldn't block on it

[edgy jetty]

It sucks, but it's OS + hardware specific, I can't reproduce it, no one has any idea of what's going on and how to fix it, and reverting it introduces a different bug

[final zinc]

Is our default to enable window resizing or not?

[edgy jetty]

Enabled by default, but also it's not very useful for games

[final zinc]

I guess I'm a bit nervous about the fact that this is not a case of "oh this weird feature we have is not universally supported", rather it's a case of "any Bevy app will crash for certain Windows users when they interact with it in a certain way"

Maybe it should be disabled by default for Windows?

Hard to tell when we don't know how many people are affected

[edgy jetty]

I have no idea how to dig deeper to get an error message or something to start debugging this, even if we did have a reproduction. It's just a silent hang

[final zinc]

let me see if I can reproduce

I don't think so

but I didn't try

[edgy jetty]

I would be more in favor of disabling it by default everywhere for consistency

[final zinc]

yeah I think that's a good call

Wanna PR it?

Doubt it's "breaking" behavior really

As you said, it's not very useful for games

As expected, I cannot reproduce it either

though my Windows does other funky things when resizing

[opaque magnet]

Wait wait. Are we talking about disabling window resizing? That's useful for editors.

[final zinc]

note the white thingy that happens in the first half of the video but not the second

Maybe that's a clue??? 🙈

[edgy jetty]

Sure: we're talking about "default settings"

[final zinc]

just changing the default from enabled to disabled

[edgy jetty]

It will continue to work / not work

Independent of this bug, I think that having window resizing enabled by default is the wrong default for a game engine

[opaque magnet]

Lots of games have resizing windows. Stardew valley for example.

[edgy jetty]

And many more of them do not

[final zinc]

isn't that an opt-in kinda thing?

(I really don't know, I play almost exclusively in fullscreen)

[edgy jetty]

My default expectation for a game is "fixed resolution, selectable by settings menu"

And almost always fixed aspect ratio

[opaque magnet]

I hardly ever play in fullscreen

More accurately, if I want to play in fullscreen I'll play on xbox.

For my laptop I tend to play in a window.

[final zinc]

Since I'm on my gaming setup right now anyways, lemme do a quick survey

[opaque magnet]

If I remember correctly, World of Warcraft also lets you play in a resizable window. And Elder Scrolls Online I think.

[eternal elbow]

Especially for testing UI and how it adapts to resizing, I use it very frequently.

Windowed mode is for me the default while developing (with resizing)

[opaque magnet]

Part of the issue for me is that I tend to play/work while sitting on the couch. I have a wide-screen monitor in my office but I haven't used it in 6 months.

[final zinc]

Allows resize:

• Ultrakill

Does not allow resize:

• Quake
• RoR2
• Gloomwood
• Dying Light
• Subnautica
• Half Life 2

Only allows fullscreen:

• Return of the Obra Dinh
• Mirror's Edge
• System Shock 2 (and all other Dark Engine titles as far as I can tell)

This is some random stuff I happened to play recently

Obviously my list is extremely biased, you won't find modern AAA games in there 😛

And this is a descriptive list, not a prescriptive list

Maybe allowing resize should be the default and Bevy has the power to have a saner config than other engines

But at least for the stuff I personally play, it looks like resizing is rare

[opaque magnet]

I think it may correlate with genre. Games which require constant attention, where it's unlikely that you'll pause to answer an email or discord, are less likely to offer a windowed option.

[final zinc]

that's a good insight 👀

[opaque magnet]

I doubt there are too many solitaire games which run in fullscreen 🙂

MMORPGs are a special case, because (a) you tend to be online for many hours at a time, and (b) you often want to run a VoIP app in the background.

[final zinc]

case in point: the pre-installed "Microsoft Solitaire and Casual Games" launches windowed (with resizing) by default

-# And also sports a gigantic "Play Ad Free!!!" button. Microsoft, I already bought your OS. These games were trivial for you to make. You already had a perfectly good FREE implementation in Windows XP. Why? Just Why?!

[opaque magnet]

Also, there's a usage pattern with MMORPGs where, as you progress through the content and the game becomes increasingly grindy, people log on just to chat with their guildmates while doing other stuff.

[final zinc]

-# Jesus Christ it costs 3 dollars a month

[opaque magnet]

For solitaire?!?

[final zinc]

No, for this exciting casual games collection with 14'000+ daily challenges

You also get these giant XBOX achievement popups while playing solitaire

Sorry for the off-topic, but I had to share this

[opaque magnet]

Hey, a soulless machine's gotta eat too, right?

[final zinc]

here's my ad while starting a new round of the pre-installed Microsoft Solitaire

[opaque magnet]

You need to stop. This is an intervention.

Choose life!

[final zinc]

Wow, the world sure has changed since my days as a little kid playing Pinball on Windows XP

Okay, enough

[dull schooner]

On the topic of resizing by default, I'm pretty sure SDL2 doesn't let you resize by default and you need to enable it

So at least there's precedent to making it opt in

winit defaults to true

[opaque magnet]

If you are going to do that, you should at least make the window size default to max

[dull schooner]

Same for raylib, it's off by default and you need to enable it

[opaque magnet]

(Not full-screen, I mean max size with title bar showing)

[dull schooner]

I'm not sure what you mean by max size?

But SDL2 and raylib have a mandatory window size, it just can't be resized by default, most example setup I've seen do enable it though

[opaque magnet]

Right now, when I make a Bevy app with the default plugins, it gives me a window that is about 2/3 of the screen size, centered.

[dull schooner]

I'm not sure it's a good idea to disable it for everyone just because on some cpus on windows it sometimes crashes if you spam the resize

[dull schooner]

It's definitely not centered by default on windows at least 😅

sometimes I wish it was

It's a fixed 720p resolution by default

Anyway, I was just pointing what other libraries do, but I don't like the idea of disabling it

It doesn't really fix anything

And if we keep it we are more likely to find someone that figures it out by just trying out the RC

[final zinc]

Oh, I just learned that it only happens after spamming the resize

that changes things

[dull schooner]

I'm not actually sure about that, but some of the videos in the issue are people spamming it until it triggers

it's not something that happens on every resize

[final zinc]

Hmm one video shows the crash happening when switching from fullscreen to windowed

Ah no wait that's still a resize and not true fullscreen my bad

[edgy jetty]

Yeah that's pretty fair

[edgy jetty]

@opaque magnet I'm planning to tackle https://github.com/bevyengine/bevy/issues/20957 tomorrow, does that work okay with your plans?

<@&1064695155975803020> <@&1064697043869777990>, the only other work in the milestone is https://github.com/bevyengine/bevy/pull/20772 by @south shell, which @dry rune has asked to be given a chance to review. Once that's done, I think we should ship the release candidate, ideally tomorrow afternoon.

That stack overflow PR is gnarly though, I spent a bunch of time going through it today, and while I understand the basic mechanisms and goals and strategies, I don't feel confident in my ability to review it for safety

Also cc @old marlin @naive turtle @onyx oxide, who were helping out with the safety there ❤️

[south shell]

@naive turtle this was originally your design, could I get your info so I can mark you as a co-author?

[edgy jetty]

Does https://github.com/janis-bhm work?

[south shell]

I need their email addresses Janis uses for git or else GitHub or git itself won't recognize it.

[edgy jetty]

Ah

[south shell]

Nevermind, pulled it from one of their other PRs

[opaque magnet]

Fine by me

[south shell]

Tip: you can convert a PR into a git mail style text page by adding .patch to the end of the URL

[opaque magnet]

I'd actually like to take some time off from UI work until we have a new BSN branch. I've been focusing on preferences lately. Well, really what I want to do is make a simple gltf animation previewer that will allow me to experiment with custom materials and outlining, but I need to learn how to use rfd (so that I can load the file) and custom asset sources (ditto), and I want prefs so that I don't get annoyed by having to reposition the damn window every time I run it.

[edgy jetty]

Sounds good 🙂

[opaque magnet]

I considered throwing in my Popover component into the ui_widgets crate, but even though it's a stand-alone component the examples and demos all rely on bsn.

[naive turtle]

I see you already found it but [email protected]

[edgy jetty]

https://github.com/bevyengine/bevy/pull/20972 reviews please!

[dry rune]

Reviewed!

Also reviewed https://github.com/bevyengine/bevy/pull/20772

[edgy jetty]

@james7132 let us know when the last round of comments is resolved

[edgy jetty]

Out for dinner then I'll amend this 🙂

[dry rune]

@opaque magnet https://github.com/bevyengine/bevy/pull/20977

[opaque magnet]

It will do for now.

[dry rune]

Yup certainly not the end game

[south shell]

Last round is up. Addressed most of them, need to file a few new issues as follow-ups.

@dry rune fyi

[edgy jetty]

@south shell, CI failures look real. https://github.com/bevyengine/bevy/actions/runs/17664015425/job/50202454656?pr=20772 I think you broke some doc tests

[south shell]

fat fingered something, yeah

[edgy jetty]

<@&1064695155975803020> I'm off tomorrow for my weekend, but I'm happy with the state of 0.17 once the last two milestone PRs are merged 🙂

[south shell]

I'll have that fixed soon

[south shell]

going to go ahead and merge this

[split jolt]

sometimes following a release, I spam upgrade PRs on crates i use everywhere. 😄 and then in some cases there is more than one of those upgrade PRs with the same diff

[proud bone]

I triggered a merge on https://github.com/bevyengine/bevy/pull/20972 which finish the milestone, I'll publish the first rc in a few hours

[acoustic nimbus]

dlss_wgpu 1.0.1 too please!

[proud bone]

huh that crate doesn't have any CI 🙁

[proud bone]

https://github.com/bevyengine/bevy/tree/release-0.17.0

[ivory nymph]

Good morning, it's saturday during a release cycle which means it's Svendoring Saturday – do you have dependencies that need updating to the release candidate, an eager readiness to take on Structural API Redesigns due to new features–

[proud bone]

I would appreciate an approval on https://github.com/bevyengine/bevy/pull/20986 for the rc

thanks!

[final zinc]

done

[dry rune]

Its soooo pretty 🙂

@acoustic nimbus published!

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

@final zinc @opaque magnet this adds those comments we were talking about in the other pr

[opaque magnet]

Some lints are failing

[dry rune]

Thanks. Fixed!

[final zinc]

Much better! But why does foo appear twice in the pattern?

let foo = foo && !(E::is::<Remove>() && C::is::<Foo>());

[dry rune]

Like the variable name?

[opaque magnet]

Only the Shadow knows for sure...

[final zinc]

let checked = checked && !(E::is::<Remove>() && C::is::<Checked>());
//            ^ is checked                             ^ is checked

[dry rune]

Hehe "who knows what evil lurks in the hearts of rust programmers"

[opaque magnet]

Hey you aren't that old

[final zinc]

It certainly isn't doing the same thing, but at a glance, it looks like were are asking "is this checked?" twice

[dry rune]

I got this one from my dad

[maiden heath]

is there a label for 0.17-rc bugs?

or just the usual

[proud bone]

the 0.17 milestone

[dry rune]

One is reading the event type, the other is reading the component value

[final zinc]

okay... why do we need to read both? 😄

Maybe I'm just being dense

But I still don't really get it

[dry rune]

The comment explains it to a degree. We want to use the checked value in every case except for On<Remove, Checked>, because in that case the value will still be present

Despite it being removed

[final zinc]

oooooooh

You saying On<Remove, Checked> made it click!

[opaque magnet]

It's because the same observer function is being used for different events which have different semantics

[final zinc]

that was the missing piece

[dry rune]

We could remove this weirdness if we had a RemoveFinished event

[acoustic nimbus]

Thanks!

[dry rune]

Which has been proposed, but it comes at the cost of additional removal overhead

[final zinc]

approved 🙂

[acoustic nimbus]

Glad you like it! I put a ton of work into it, I'm very proud!

[warm crystal]

you should be! it looks awesome

[acoustic nimbus]

Sooo happy the release is finally happening

[odd jungle]

I have a request: for early adopters, a very useful document would be a short list of things moved around and renamed. So much of the initial work is figuring out what where things have gone and what they've been renamed to. This would be useful even in addition to the migration guide, because the migration guide takes a while to scan to find this information. Thanks!

The big one is that events are called messages now, apparently.

[south shell]

would an initial unfiltered migration guide be helpful here?

we do have most of that already, just not fully formed/editorialized yet.

[warm crystal]

first one https://github.com/bevyengine/bevy/pull/20993

this may be an issue on 0.16, i'll check later

[odd jungle]

Maybe. The ideal solution would be deprecating things, but I think it would be low effort to require each PR that simply moves things around to add a line like:

bevy_render::mesh -> bevy_mesh

This would make it a lot easier to quickly apply these changes.

It doesn't even have to be 100% correct, just a sort of indication of where things might have gone so I don't have to search the docs/migration guide.

[south shell]

IIRC, @dull schooner was looking at creating automatic migration tools that would handle this.

[dull schooner]

Yeah, I'm waiting on the migration guide to be a thing to start creating more automated migrations

[warm crystal]

renames seem like an absolutely ideal case

[warm crystal]

@maiden heath did you hit this upgrading from 0.16?

[maiden heath]

yes, it worked in 0.16

[warm crystal]

okay cool, then we don't need to backport and it's a consequence of TEM

it also seems like it's not an issue for 2d presumably for this reason

[maiden heath]

yeah I saw that mentioned on the PR

[warm crystal]

am sooo looking forward not needing to copy/paste everything into 2d

[odd jungle]

Got it. 2.5 hours to port!

[dull schooner]

yeah definitely, I'm just waiting on the migration guide to exist to identify all those renames easily 😅

[odd jungle]

Another good thing to mention would be #{MATERIAL_BIND_GROUP} for custom shaders.

A thread for people porting to the latest version would be fun.

[maiden heath]

This is the list of components in diff form if it helps: https://gist.github.com/ChristopherBiscardi/47335be1efd599bba7306e7cdd08a46a

I added the script I use to generate it too, it takes the reflection information for the components and spits it out so probably could be used for any registered types

[odd jungle]

Good idea, but it's a bit too scrambled to be easily usable since many of the components changed modules.

[maiden heath]

I'm not sure what you mean, the names of the types in use for many usages stay the same and just move modules, ex: Bloom, PointLight, etc

[dull schooner]

Here's the repo for the wip migration tool feel free to add new migrations. I won't be able for a few hours https://github.com/TheBevyFlock/arctic_tern

[odd jungle]

I mean the inline diff is too noisy because the old and new components aren't near each other e.g. Bloom moves 138 lines.

[maiden heath]

so sort the lines?

I'm just offering something that I had that could be useful, its ok not to use it if you don't want to

[dry rune]

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

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

[dry rune]

As a heads up, I'm doing a release notes editorial pass

Also: https://github.com/bevyengine/bevy/pull/20997

[edgy jetty]

Good. I did one earlier but it was a very light touch: just cleaning up particularly messy writing and fixing obvious mistakes

[frosty hare]

Are the RC1 migration guides / release notes viewable anywhere, or just in the repos?

[edgy jetty]

Just in the repo for now

Cart or I will compile them in the next couple of days I expect

[fair harness]

will this fix make it into 0.17?
https://github.com/bevyengine/bevy/pull/21002

[south shell]

added it to the milestone

[fair harness]

cool, but its closed so it doesnt actually show up there. whats the process for backport prs? this is not on the rc branch

[south shell]

it'll get cherry picked at a later point in time

[narrow storm]

Just wanted to chime in and let you know that migrating to 0.17 was very smooth for me with the provided migration guides. Good work to everyone involved

[outer escarp]

Same for me, was pretty quick. Are bevy’s API… stabilising??

[ivory nymph]

biggest break in my dependencies has been in the event API split, I feel like that's going to be where most people stumble.

everything being an Event was convenient enough for a decent buy-in despite it muddying the water.

(not a critique of the redesign, just the main point of friction I've run into)

[outer escarp]

I find the new API much clearer. And great use of deprecation warnings to ease the migration. If only rust deprecation warnings could vend fix-its…

[ivory nymph]

the other one being the continued getrandom CI failures :')

[rapid mantle]

Which setup are you using to run into that?

[ivory nymph]

not ones I own, just the ones I'm vendoring & upstreaming.

I know very little about github CI :')

[rapid mantle]

With the web back end?

[ivory nymph]

yeah

and the moment bevy cli reliably fixed my getrandom problems for wasm I switched off taking in any more information about that.

[rapid mantle]

Tbh, that's the goal of the CLI
In the end we just want to make a game and not fight with tooling for days

[ivory nymph]

3 down, some number to go :')

[ivory nymph]

the other one being the removed cosmic-text re-exports 😅

[slim lintel]

https://discord.com/channels/691052431525675048/1416418304226099271

@worn current is migrating in anger, and has been running into issues with the changed feature flags

did those not get a migration guide (@fair harness i think some of them may be from you)

[worn current]

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

Filed an issue with a minimal repro

[naive turtle]

we can add zstd_rust and zstd_c features to pbr and core_pipeline that enable the respective bevy_image feature and it compiles with --all-features

[final zinc]

#1297361733886677036 message
@marsh frigate has been running into something that seems to be related to the moving pointer stuff from @south shell

I haven't looked into it deeply, but it looks like either an unforeseen thing or a missing migration

[worn current]

Should:
https://github.com/bevyengine/bevy/blob/main/release-content/migration-guides/border_color_all_takes_impl_into_color.md
https://github.com/bevyengine/bevy/blob/main/release-content/migration-guides/separate-border-colors.md
Be merged?

Or better yet

Should https://github.com/bevyengine/bevy/blob/main/release-content/migration-guides/border_color_all_takes_impl_into_color.md
Be scrapped?

Because as I understand it, BorderColor::all was added this release, so no need for a migration guide, right?

I think a migration guide for
bevy::sprite::Anchor::BottomCenter -> Anchor(Anchor::BOTTOM_CENTER)
Perhaps should be added to https://github.com/bevyengine/bevy/blob/main/release-content/migration-guides/anchor_is_removed_from_sprite.md or somewhere.

[edgy jetty]

Can you spin up little issues for these so I remember?

[naive turtle]

it looks like implementations of spawnablelist will be complicated quite a bit because of the bundle stackoverflow changes.
we could add another trait that mirrors the old API that hides the moving_ptr parts and accepts the stack borrows for users that know that the bundle sizes won't be excessively large, but that might allow library authors to bring about the exact problem that was just fixed 😐

[worn current]

Sure thing

[final zinc]

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

[worn current]

So all in all my migration to 0.17 (as documented in #1416418304226099271) was pretty smooth this time around!
The only real hiccups were related to weird feature flag stuff.

[fair harness]

i'll see what i can do

is it just this gizmos thing or is someone consuming bevy_internal directly

[slim lintel]

i think it's just this

our flags were so messy

[fair harness]

pretty sure just Anchor::BOTTOM_CENTER works, no need to do Anchor(Anchor

@worn current https://github.com/bevyengine/bevy/pull/21018

mind checking if that fixes it for you?

[naive turtle]

https://github.com/bevyengine/bevy/pull/21011 I think this should be enough btw

[fair harness]

gizmos really shouldnt be doing anything with bevy_sprite directly is the thing tho

it only care about whether the render backend is present

[south shell]

Landing the MovingPtr: Bundle changes would be the cleanest way to approach this, but if we can't land that in time, we may need "raw" variants for insertion/removal.

[naive turtle]

oh you're right, I didn't realise that was the only thing used from bevy_sprite

[fair harness]

also guide notes: https://github.com/bevyengine/bevy/pull/21019

[naive turtle]

I tried my hands at writing a migration guide for this: https://github.com/bevyengine/bevy/pull/21020

[verbal ice]

For my crate I was already on main, but I did not update for some months. Only things I had to change that FilteredAccess is no longer generic. This migration guide mentions that, but I think this one kinda is written like it is still generic. But I am not sure if this really needs to be touched.

Otherwise, Archetype::components now returns a slice and not an iterator, but that is very trival to fix and does not really need a migration.

[final zinc]

Updated all my crates that don't depend on Avian to 0.17-rc, and it was fairly simple 🙂 I opened some migration issues, feel free to close them if they're too picky. Basically whenever I couldn't just blindly CTRL-F my problem, I opened an issue for that haha

[fair harness]

can i get a merge on https://github.com/bevyengine/bevy/pull/21018

[final zinc]

Sorry if this was asked before, but now that https://github.com/bevyengine/bevy/pull/15030 landed, can we deprecate register_type?

[maiden heath]

why would it be deprecated if its the only way to explicitly register a type? (also I think you have to call it for some generic types, but I don't remember exactly offhand what the situation is)

[final zinc]

Do you need to explicitly register types after this PR?

[final zinc]

But yeah generics still need it, it says

[final zinc]

Update on migration process: migrated bevy_new_2d. Evaluated whether core widgets or feathers can replace our shitty DIY widget abstraction there. Result: it really cannot yet :/

core widgets are too scary and feathers' buttons are too small, with no option to make them bigger without writing boilerplate for it

[edgy jetty]

Upgrades for my crates have been very smooth so far

the Message / Event split is really the only work I've needed to do

Whee, I love the getrandom changes: https://github.com/Leafwing-Studios/leafwing-input-manager/actions/runs/17721403364/job/50354400574?pr=712#step:6:215

I'm so glad they're making sure I'm not doing anything insecure in my CI testing for a video game input manager

[marsh frigate]

@south shell have there been any updates on the moving pointer thing?

[south shell]

? It's been merged

[marsh frigate]

what's been merged

[south shell]

The MovingPtr PR?

[marsh frigate]

oh was that only added recently?

[south shell]

Not sure what you mean by MovingPtr "thing"

[marsh frigate]

well i was having issues with it, and a few days i was trying to fix it and i've been busy since then

[south shell]

Oh, it's been merged

And completed

There's a few open questions on how to improve it

[marsh frigate]

does it not exist in rc-1?

[south shell]

It should

its under bevy::ptr::MovingPtr

[marsh frigate]

oh nice

my issue was that i tried to import it under ecs i think

[final zinc]

Pretty sure it’s about this https://github.com/bevyengine/bevy/issues/21014

[marsh frigate]

nvm it still can't find moving ptr for some reason

error[E0433]: failed to resolve: could not find `MovingPtr` in `bevy_ptr`
  --> src/preset/spatial.rs:74:9
   |
74 |         move_as_ptr!(xy);
   |         ^^^^^^^^^^^^^^^^ could not find `MovingPtr` in `bevy_ptr`
   |
   = note: this error originates in the macro `move_as_ptr` (in Nightly builds, run with -Z macro-backtrace for more info)
help: a struct with a similar name exists
  --> /home/lenny/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/bevy_ptr-0.17.0-rc.1/src/lib.rs:1211:41
   |
121-         let $value = unsafe { bevy_ptr::MovingPtr::from_value(&mut $value) };
121+         let $value = unsafe { bevy_ptr::OwningPtr::from_value(&mut $value) };
   |
help: consider importing this struct through its public re-export
   |
 1 + use crate::preset::spatial::MovingPtr;```

[south shell]

Oh hmmm

That might need to be fixed. The macro is not pointing to the right crate

[marsh frigate]

should i try using the github version to test?

[south shell]

I think it's hard coded to use bevy_ptr right now

[marsh frigate]

btw i tried a github code search and it seems there's no other projects using it

[south shell]

yes, we just added it within the last two weeks

[marsh frigate]

that makes sense lol

should i open a pr for bevy?

actually i wouldn't know how to fix it

i'll work on migrating something else

[final zinc]

You could open an issue to track this instead 🙂

Just copy paste your error message and James' response

And ping me so I can put it in the milestone

[marsh frigate]

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

[final zinc]

Labeled and added to the milestone

[final zinc]

I knew this came up before from @naive turtle, but I have to say, now that I'm migrating more stuff, AssetEvent not being an event feels like wrong naming
i know the reasoning, IIRC it’s "the event suffix is not saying anything about the type in this case, but that some event relating to assets occurred"
But given that both Event and Message have intrinsic meaning now and are related to each other, having Message be called SomethingEvent is weird.

[south shell]

Ugh this might actually require proc macros to get it to work with the top level Bevy crate

[fiery raven]

Won't $crate::MovingPtr work everywhere?

[south shell]

Not if it's reexported like it is with bevy_ecs and the top level bevy crate

[fiery raven]

Are you sure? I can reproduce bevy_ecs::ptr::move_as_ptr!(x); failing with

Error[E0433]: failed to resolve: use of unresolved module or unlinked crate `bevy_ptr`

in a project that doesn't depend on bevy_ptr, and if I change the macro to use $crate then the error goes away.

[naive turtle]

is MovingPtr imported into your scope?

nvm you're right

https://doc.rust-lang.org/reference/macros-by-example.html#r-macro.decl.hygiene.crate

[opaque magnet]

Something like AssetStatus then?

[final zinc]

Message<AssetStatus> sounds like it conveys the meaning well: here's a message about how the asset's status changed

I like that 🙂

[final zinc]

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

[final zinc]

@edgy jetty I hope you don't mind that half of the migration issues (13/26) are from me. Feel free to close the ones that are like "this migration doesn't mention where to import stuff from" mercilessly, as IDEs can do that anyways.

I opened them with the mindset of better note too many things than too few things

[edgy jetty]

What no these are great

[final zinc]

But I can also not do that if prefered 🙂

[final zinc]

Alright 👍

Just hope it doesn't look too pessimistic or anything haha

Migration went pretty smoothly for the most part

Currently trying my hand at https://github.com/ickshonpe/bevy_ui_text_input, but I think my limited UI knowledge is throwing a wrench there

[edgy jetty]

We've also been pretty aggressive about refactoring the UI internals to bring them up to par, mostly by @fathom finch ironically

[final zinc]

yeah I'm pretty sure they will know exactly how to deal with the remaining cases haha

[proud bone]

https://github.com/bevyengine/bevy/tree/release-0.17.0 is updated with the latest merged PRs in the 0.17 milestone

[edgy jetty]

Punted to 0.18; this is too complex and critical to be messing with last minute, and any rename is not going to stick around

[fathom finch]

Need to go to sleep but I'll have a look tomorrow first thing, hit me up if I haven't

[final zinc]

cool thanks! I left the PR up with all changes that I felt confident I could do myself 🙂

[edgy jetty]

If anyone wants to help out, I would appreciate a set of eyes on https://github.com/bevyengine/bevy/issues/21006: I have cargo tree output that needs a careful set of eyes to check for @fathom shoal

[slim lintel]

i suspect this may relate to a recent change in bevy_tasks

but i have not had time to check

[naive turtle]

render depends on async_channel with default features which includes concurrent_queue with std?
https://github.com/bevyengine/bevy/blob/beb42aec6786ef39f565635573f66517ccf7c05c/crates/bevy_render/Cargo.toml#L104
https://docs.rs/crate/async-channel/latest/features

but that can't be right

[edgy jetty]

Yeah, it feels like we should be turning default features off there

Can you try making that change?

[naive turtle]

but that hasn't changed since .16

[final zinc]

Got a new one for the milestone: https://github.com/bevyengine/bevy/issues/21074

I'm pretty sure this is a mistake, but it's possible I'm just not seeing something that others are

[naive turtle]

I think i found it, in bevy_tasks, async-channel is a dependency for cfg(arch=wasm32), #20352. not sure exactly what tests to run to verify this tho beyond just running the cargo check that failed in CI

[slim lintel]

this sounds right. i changed this when changing the Task impl.

[edgy jetty]

Rerunning that check should be adequate IMO

[static hearth]

Here’s something I found on lobste.rs that I think y’all would appreciate

You’re doing good work, and others notice! 💙

[final zinc]

I'm migrating Tnua and getting this:

thread 'main' (253822) panicked at /home/hhh/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/bevy_scene-0.17.0-rc.1/src/scene_spawner.rs:621:35:
scene contains the unregistered type `bevy_transform::components::transform::Transform`. consider reflecting it with `#[derive(Reflect)]` and registering the type using `app.register_type::<T>()`
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Encountered a panic in system `bevy_scene::scene_spawner::scene_spawner_system`!
Encountered a panic in system `bevy_app::main_schedule::Main::run_main`!
error: command `cargo run --bin platformer_3d --features avian3d,bevy/debug --profile dev` exited with status code exit status: 101

that seems... odd? I thought regular components like Transform didn't need to be registered explicitly anymore?

@marsh crest do you know more about this?

IIRC you wrote the auto registration PR, right?

Sorry, no minimal example for this 😬

[edgy jetty]

Did you enable one of the auto-registration features?

[marsh crest]

It should register automatically, yes. Maybe reflect_auto_register_static feature is enabled?

or yes, no reflect_auto_register enabled at all, which is in default features

[final zinc]

yep, isn't in there

The migration didn't mention that feature

[edgy jetty]

I smell a migration guide issue :p

[final zinc]

Let me try with it 🙂

Yep that was it, thanks!

[final zinc]

added

[edgy jetty]

Thanks 😄

[fathom shoal]

Just confirming, the new recommendation is to remove all manual type registrations (except where required, i.e. generics), even in library code like Avian, right?

[fathom shoal]

hah also I found a fun naming conflict was pretty confused for a sec

apparently we decided to add a ScalingMode enum to bevy_sprite, even though bevy_camera already has a ScalingMode

the camera version was previously in the prelude, but now the sprite one is (edit: or no?? apparently it was the same before too)

so imports don't break, but all the variants are wack, and you need to explicitly import the correct one

[maiden heath]

this was true in 0.16 as well fwiw

https://docs.rs/bevy/0.16.1/bevy/prelude/enum.ScalingMode.html

[fathom shoal]

ah I guess it's just the imports that changed, probably as part of the rendering crate refactoring where bevy_camera got extracted to its own crate

hmm or I don't see the camera ScalingMode in 0.16's prelude either why did it work for me before

idk I probably goofed something... still would be nice to have the names be distinct

[dry rune]

Yup this violates the “one namespace” rule we go for

[edgy jetty]

Issue please

[fathom finch]

The bevy_sprite ScalingMode enum is misnamed maybe anyway, it controls more than just scaling

and it looks like it should be a per-axis setting as well

[edgy jetty]

FYI, I'm currently buying a house (offer made, working on conditions) and dying in the billion small but vital tasks. I've just booked two vacation days off this week. I intend to do what I can, but my productivity will be much lower than usual for this week. Review and advice work will be much easier for me to help with than making PRs ❤️

[final zinc]

Wow, congrats 😄

[edgy jetty]

Thanks 😅 I'm sure I will be very glad about it once it's over :p

[primal arch]

Is there a migration guide for 0.17?

[final zinc]

only the individual markdown files in release-content/migration-guides/

But you can CTRL-F your stuff and filter that directory for something approximating CTRL-Fing a webpage

[primal arch]

is there a branch to use? I don't see 0.17

oh it's in bevy, not bevy_website

[primal arch]

There's no more way to get the entity's generation as a u32? that was useful for networking

[edgy jetty]

I would be fine to expose a reader on https://docs.rs/bevy/0.17.0-rc.1/bevy/ecs/entity/struct.EntityGeneration.html

[fathom shoal]

yeah I just slap a transmute on it in Avian

core::mem::transmute::<EntityGeneration, u32>(entity.generation())

having to do that feels questionable though

[verbal ice]

nah just do this

fn generation_to_u32(generation: EntityGeneration) -> u32 {
  let mut x = EntityGeneration::FIRST;
  let mut y = 0;
  while x != generation {
    x = x.after_versions(1);
    y += 1;
  }
  y
}

and pray it gets optimized 🙏

[onyx oxide]

Funnily enough it does get optimized

[verbal ice]

neat, no reader method then 👏

[ivory nymph]

is bevy::sprite_render::text2d supposed to be a private module now?

[ivory nymph]

looks like I may just need to drop bevy_slow_text_outline until its author publishes an update, I do not have the chops for vendoring this.

[fathom finch]

I don't think it was deliberate, it only contains the extract_text2d_sprite system which is still marked pub

does the bevy_slow_text_outline crate schedule its system relative to it or something

[dry rune]

Today I'm wrapping up my release notes editorial pass

Only a few more sections

[acoustic nimbus]

I'll have a blog post to link to for solari by the time we're ready to publish

Hoping to finish it by this weekend

[fathom finch]

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

[ivory nymph]

greatly appreciated!

[ivory nymph]

it does yeah

[edgy jetty]

@dry rune, I'll swap you reviews on release note editing for a review on infinite children release note 🙂

[dry rune]

Hehe yup my release notes editorial pass is indeed out: https://github.com/bevyengine/bevy/pull/21108

[dry rune]

reviewed!

[edgy jetty]

Thanks 😄 Suggestions applied and merging

Wow I much prefer the new process for doing the migration guides and release notes

Much lower friction, more gradual and better distributed

[dry rune]

Yup nice and clean

I'm gonna do a pass to make sure we didn't miss something juicy

[edgy jetty]

Good call. We're still going to need to make a number of images, but I'm feeling good about the state of things

https://github.com/bevyengine/bevy/issues/21050 is the only serious bug that I think is a must-fix

[fiery raven]

I think we just need to use $crate to fix that. Let me push up a quick PR... https://github.com/bevyengine/bevy/pull/21113

[edgy jetty]

Put together https://github.com/bevyengine/bevy/pull/21114, for a last minute X-Controversial change 🥲

[dry rune]

I've found a few stragglers that merit release notes coverage:

• Type Erased Materials (@warm crystal https://github.com/bevyengine/bevy/pull/19667)
• Separate Border Colors (@crisp folio https://github.com/bevyengine/bevy/pull/18682)
• SunDisk component (@defuz on github https://github.com/bevyengine/bevy/pull/20434)

[final zinc]

creating issues and adding them to the milestone

[edgy jetty]

You're the best, thanks!

[dry rune]

Have we sorted out the bevy-website side for how to ingest the new format? Is that something I should start banging on

Or is the plan to just copy it in flattened form?

The incentive to keep it in separate files isn't really there anymore, other than the fact that the front matter feeds into html / theming which we don't really want to do manually

The new format has no built-in conception of order, so if we go the "structured / separate file" route, we'll need a way to impose order

As "directory iteration order" by default wont cut it

[edgy jetty]

Copy of in flattened form was my plan

[dry rune]

I don't think porting the front matter will be fun

[edgy jetty]

@slim lintel may have more details

[edgy jetty]

Oh, you must have missed the release note generator that we merged

[dry rune]

I did!

[edgy jetty]

That bit is automated already!

[dry rune]

Rad then I have no concerns

[fair harness]

maybe we should have some kind of tag per note, saying which part of the engine a note is relevant to

so you can tag bevy_render stuff together for example and then sort by that

[dry rune]

We could also just prefix the file names with 1_X 2_Y etc

[fair harness]

(and have a consistent global ordering on tags, release-to-release)

thats kinda hard because it pushes the determination of importance to the pr author lol

how do you know if your feature is 1_ or 9_ lol

[dry rune]

Theres a certain appeal to being able to just copy/paste the folders in. But theres still the matter of generating the contributors list and the other boilerplate

[dry rune]

You don't, but I do

😈

[fair harness]

great then make all our prs for us :P

[dry rune]

In practice, leadership needs to do an "order pass" at some point anyway. Thats not something we crowdsource

It is done at the end, after release notes have been written / files have been named

[opaque magnet]

Easy: rendering always comes first, then ecs, assets, ui. audio and such comes last 🙂

Within each group it's ordered by PR number

[dry rune]

Roughly. I favor "pretty" features highly

[fair harness]

hence the suggestion to have a tag for engine section per note

we dont have that info atm

[dry rune]

In practice I violate this categorization on the regular to give prominence to the headliner features first

[fair harness]

i at least think changes affecting similar parts of the engine should be next to each other more often than not

[dry rune]

There is a loose preference for this though

Ooh @slim lintel that command-line section reordering is slick

Yeah that tool will do nicely / I have no notes

[frosty hare]

Can you keep separate files, and have a index file with ordering, and anything missing goes to the end

[slim lintel]

sweet! I left it pretty bare bones. Once we’ve used it a bit, I’m sure we’ll run into cow paths we can pave. happy to make any modifications that may be needed.

the tool is pretty tiny, so it shouldn’t be too hard for anyone to maintain if I disappear as well

[edgy jetty]

Honestly I wonder if we'll put the Firewheel migration at the top with a good demo 🤔

[slim lintel]

at some point after the 0.17 release I do also plan on going back and converting the 0.15 and 0.16 many-file releases back to monolithic posts, and cleaning up some of the infra we built for that.

[acoustic nimbus]

But but, you already have the perfect demo to showcase! /s

[final zinc]

Either my local system is borked, or we published something else than what is git-tagged as the RC: https://github.com/bevyengine/bevy/issues/21129

and also https://github.com/bevyengine/bevy/issues/21115 (see discussion)

[final zinc]

Since I got this failure on CI too, I don't think this is a local issue

Pinging @proud bone because I think you did the release

Maybe the new cargo publish --workspace did something unexpected?

[final zinc]

Either way, would be happy if someone could quickly reproduce this in a fresh project

[proud bone]

are you sure you didn't bork your cargo cache somehow?

the code it's complaining about is not the one published, see https://docs.rs/crate/bevy_feathers/0.17.0-rc.1/source/src/controls/checkbox.rs#119

does it still happen if you rm ~/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/bevy_feathers-0.17.0-rc.1?

[final zinc]

ha, that fixed it

thanks

local issue after all 🙂

[ivory nymph]

All my dependencies are finally updated or vendored 😌

[warm crystal]

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

[ivory nymph]

Okay in my ~20kloc, ~150 file project the main thing I am having to do is redo imports (I've moved away from blob imports following advice on how to keep rust analyzer happy in large workspace projects) as there's been a lot of re-arranging where things are.

[proud bone]

I would like to do a new RC with https://github.com/bevyengine/bevy/pull/21151, anything else to do before a 0.17.0-rc.2?

[slim lintel]

seconding a second rc, I have already merged some fixes for wasm tasks that need testing

[maiden heath]

https://github.com/bevyengine/bevy/pull/21148 and https://github.com/bevyengine/bevy/pull/20981 have two accepts and would be nice to have

[frosty hare]

There's still a couple of issues / PRs in the milestone, should we wait for the non-doc ones at least?

In particular https://github.com/bevyengine/bevy/pull/20990

[maiden heath]

https://github.com/bevyengine/bevy/pull/21150 also got its second review

[naive turtle]

There was discussion around adding pub API for spawning bundles as moving ptrs to make custom spawnableList implementations take advantage of the bundle overflow PR because they currently have to copy everything to the stack

[edgy jetty]

I think this is a good idea, but probably won't block on it

[maiden heath]

merged main on this after some other prs went in for merge queue

[edgy jetty]

I think I've got all the 0.17 Ready-For-Final-Review PRs in the queue now

Time to start writing I think 🙂

[edgy jetty]

https://github.com/bevyengine/bevy/pull/21153 is ready, and includes some light jokes

[edgy jetty]

More release notes: https://github.com/bevyengine/bevy/pull/21154

[proud bone]

https://github.com/bevyengine/bevy/tree/release-0.17.0 updated with the merged PRs, I'll let CI do its things and publish the 0.17.0-rc.2 in ~1 hour

I think at this point we could update main to the 0.18.0-dev, and clean the release content from the main branch. that means that after that, PRs to update the release content will need to be opened against the release branch, and potentially bug fixes will need to be opened on main and on release

@south shell could you update https://github.com/bevyengine/bevy/pull/21001 to clean the release content folder?

[edgy jetty]

I'm happy with that. https://github.com/bevyengine/bevy/issues/21110 is the only non-docs fix left, and it's a small bug fix for an experimental feature so...

[edgy jetty]

I'm a little reluctant to do this because it will make migration guide / release note changes harder, but I can cope :p

We should get the remaining release note PRs merged though probably?

[proud bone]

everything will need to happen on the release branch, but otherwise it will be the same

[edgy jetty]

Oh okay, that's easy enough

SGTM then

[proud bone]

you won't have the release queue so faster merges 🥷

[edgy jetty]

I'll pay attention and swap the branch when needed

@final zinc @fathom finch I've cut https://github.com/bevyengine/bevy/pull/21114 from the milestone. It's too contentious. I can make a PR upstream to bevy_ui_text_input to workaround this for now if you'd like?

[edgy jetty]

@proud bone I think we need https://github.com/bevyengine/bevy/pull/20990 in too

[proud bone]

oh that's why I couldn't find it easily, I wanted to review it with a computer instead of on a phone 😄

[edgy jetty]

Oh, I can review and merge this one 🙂 That should allow BEI by @grave dove to migrate I think?

[final zinc]

Sounds good to me!

[grave dove]

Yeah, this will make presets code so much nicer.

[edgy jetty]

https://github.com/bevyengine/bevy/pull/21109 is ready for re-review

[final zinc]

Regarding your comment on the text input issue, the incompatibility with TabNavigationPlugin could be a Feathers bug

But it’s certainly not blocking, since the tab navigation in Feathers has no UI implementation anyways

[south shell]

Will do!

[edgy jetty]

Oh yeah, I'll take a look today

[final zinc]

Talin already answered 🙂

[final zinc]

It’s because the text input and Feathers currently just have different ideas how focus should work

Not really a bug, just a disagreement

[edgy jetty]

kk

[south shell]

done!

[opaque magnet]

@edgy jetty On the issue of Propagate I am not sure who to ask for a definitive answer. The question is: is the intent of Populate:

• To only be used to initially populate the hierarchy on spawning (for example, inserting custom materials in a loaded GLTF scene)
• Or, is it intended to be used to dynamically keep the populated components up-to-date after spawning?
  That is, I know that Populate will fill in components for new child entities if they are added to the hierarchy after the initial population; what I don't know is whether Populate is supposed to be able to replace/overwrite components for pre-existing child entities if the root component is replaced. I can imagine that there could be technical limitations that prevent this, meaning that the behavior I want is out of scope; but unfortunately the documentation is silent on this issue.

To put it another way, there are three things that can happen in the context of Populate:

• A new Populate component is added to the root of an existing tree or sub-tree.
• A new child entity is added as a descendant of an entity with Populate
• A pre-existing Populate component is replaced with a new value.

The first two of these work; what I don't know is whether the third case is supposed to do something or not. I wrote feathers assuming that it did (and unfortunately didn't test that case).

[edgy jetty]

@crisp folio was the PR author, but my intention as <@&1064697043869777990> is that all three of those should work

That is how our transform / visibility propagation works, and I expect @warm crystal would like this for e.g. RenderLayers too

[warm crystal]

which i think was rob's original use case as well. render layers are probably significantly less "dynamic" than other uses, they're much more likely to be set and forget just annoying to add to a deep hierarchy

[edgy jetty]

I think the right fix for the feathers bug as a result is to fix what's going on with Propagate

[opaque magnet]

As far as I can tell, replacing the Populate component has no effect; when I ripped out the Populate component and just manually traversed the hierarchy with iter_descendants, everything started working as expected.

[edgy jetty]

I'll write a regression test tomorrow, then fix the bug 🙂

[opaque magnet]

Even if we don't adopt my fix, we'll want to keep the changes I made to the example which allow the behavior to be tested

I made it so that clicking the first checkbox also controls the disabled state of one of the buttons

[edgy jetty]

Yes please; can you split these out into a new PR and I'll merge it immediately?

[final zinc]

Lovely idea!

[opaque magnet]

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

[edgy jetty]

https://github.com/bevyengine/bevy/pull/21162 another migration guide improvement for y'all

Hey @slim lintel how do I fix https://github.com/bevyengine/bevy/issues/21041 ?

[edgy jetty]

And another one down: https://github.com/bevyengine/bevy/pull/21163

@fathom finch, I poked at https://github.com/bevyengine/bevy/issues/21059 but I'm not sure what the right fix is

[warm crystal]

will leave some notes when i’m back at computer, this might be a little too specific

[edgy jetty]

Thank you 🙂

[edgy jetty]

Thank you! Commited your changes and merging with Jasmine's approval (and my own of your suggested changes)

[maiden heath]

I added https://github.com/bevyengine/bevy/issues/21164 to 0.17 because it results in some pretty garbled output. naga-oil is producing colorized output and tracing-subscriber no longer allows ansi escapes as of 0.3.20 (lowest version allowable by 0.17) for security reasons.

[warm crystal]

oh yeah, oof

maintainers completely ignoring this https://github.com/tokio-rs/tracing/issues/3369

i think we should pin as suggested until there's a fix

https://rustsec.org/advisories/RUSTSEC-2025-0055.html
https://www.cve.org/CVERecord?id=CVE-2025-58160

[warm crystal]

the workaround also seems fine though. i guess we could also just disable colored output

[maiden heath]

yeah, workaround is at least servicable, but I also didn't see any acknowledgement beyond the original fix in the tracing repo

and to be clear, this is colors in the messages specifically, not colors for things like INFO

[crisp folio]

That was definitely meant to work … I’ll have a look today

[fathom finch]

Basically, it's just a renaming of the field to be clear that it's just defining a z-ordering now, like the z coord does in 2d. The actual changes were made back in 0.15.

[fathom finch]

oh no that's wrong, it was still a u32 in 0.16, but post extraction it was converted to an f32 and an offset was added to it, now it's extracted as an f32 so you can add an offset to set a draw order during extraction, rather than afterwards

I'll write something up quickly

[fathom finch]

Maybe we should have an M-Release-Content label

[edgy jetty]

Thanks!

[edgy jetty]

Looks like we're good: https://github.com/bevyengine/bevy/pull/21172.

@opaque magnet can confirm

[opaque magnet]

Seems to work

[opaque magnet]

All this being said, I'm not sure that Propagate is the right solution going forward.

Specifically, Propagate has a limitation that all of the entities in-between the descendant and the ancestor must either match the query or have PropagateOver.

While this makes sense for something like Visibility, it's a confusing restriction for people who want to style text, especially given the way that text entities are structured.

Right now, the Button component is a flexbox. This doesn't matter for the vast majority of buttons that have a single child, but the second most common case is a button with text and an icon arranged in a row. However, we can imagine non-traditional buttons that have a more complex inner structure. For these kinds of buttons, you won't get automatic inheritance of text font or color unless all of the intermediate entities are properly annotated.

[crisp folio]

An alternative is to propagate a custom component (without a filter) and only read it on entities with ThemedText. Up to you really. I don’t think adding more constraints/complexity to propagate itself is the best answer though

[edgy jetty]

I think we could make this behavior implicit for component types that opt-in

[edgy jetty]

Okay, valid

[opaque magnet]

I think the first step is to decide exactly what behavior we want

Right now what I have is kind of a middle ground between CSS's implicit inheritance of text properties by default, and the previous Bevy model of having to be explicit about everything.

[edgy jetty]

I think we're at an okay state for 0.17, so can we move to #ui-dev?

[opaque magnet]

ok

It's good enough for now

[edgy jetty]

@grave dove, let us know how the BEI migration goes with RC2 please 🙂 That's the only serious outstanding thing that I want to ensure we test from RC2 before shipping 0.17.0

[final zinc]

FYI after BEI is migrated I'll migrate Foxtrot to 0.17, which historically is very good at catching rendering bugs because of how many rendering features it uses concurrently

[static hearth]

@edgy jetty you're so fast! I was just about to link https://github.com/bevyengine/bevy/pull/21173 here for a review, but it's already in the merge queue

[edgy jetty]

#github is great 😄

[static hearth]

:O

That's your secret :)

[proud bone]

@static hearth is https://github.com/bevyengine/bevy/pull/21173 a problem on main or just on the 0.17?

only target the release-0.17.0 branch if the issue is just on the 0.17, otherwise open on main and the PR will be cherrypicked

[edgy jetty]

On main too

[proud bone]

you can't change the base branch using github ui now that we've conflicted all the cargo.toml 😄

[edgy jetty]

😭

[proud bone]

@edgy jetty in case you didn't know, you can do https://github.com/bevyengine/bevy/pulls?q=is%3Apr+is%3Aopen+base%3Arelease-0.17.0 to filter by base branch

[edgy jetty]

ooh fun

[fathom finch]

This only fixes the problems with the feathers example, font propagation is still broken

[edgy jetty]

Okay 🤔 I'll think about this more

[opaque magnet]

No, I made it a required component of InheritableFont

[fathom finch]

Simple way to break the examples again is just to change the button's child params from:
Spawn((Text::new("Normal"), ThemedText))
to
Spawn(( Node::default(), children![(Text::new("Normal"), ThemedText)] ))

Which is a necessary construction if you want to add icons or something

[opaque magnet]

Oh right, yes, I mentioned this earlier this morning

[opaque magnet]

#1404237363550486751 message

I think it's good enough for the moment, we can figure out what we want to do with font propagation in the next cycle

[fathom finch]

#21120 seemed like it would be fine with a couple of changes

If we want just a definitely works for now solution, we could just walk the tree every frame and update whatever is needed

[static hearth]

Good to know, I’ll recreate the PR one more time :)

Ok, https://github.com/bevyengine/bevy/pull/21173 is back up, sorry for the confusion!

[edgy jetty]

https://github.com/bevyengine/bevy/pull/21177 is already reviewed in its last form, but I had to remake it targeting the other branch. Can I have a quick set of eyes?

@naive turtle is better at git than I am, and rebased their PR properly in https://github.com/bevyengine/bevy/pull/21020 :p

[edgy jetty]

Thank you @warm crystal 😄

[warm crystal]

we should apologize to our users for subjecting them to this 🥲 (the rec for bevy cli is a good alternative)

[edgy jetty]

Yeah lol, I'm so salty about it still

<@&1064694928589991936> @south shell @maiden heath, what do you think we should do for https://github.com/bevyengine/bevy/issues/21164 ? This is the last non-migration guide issue for 0.17

[south shell]

We don't really have much of a choice unless they push out a fix soon.

[edgy jetty]

Can we pin the minor version for this? I always forget the details of how cargo works on this

[south shell]

Given it's a security vulnerability, I would rather us not do so.

[edgy jetty]

Ugh, okay. So we just have to eat the problem until they do a release

[south shell]

We can patch naga_oil and make a patch release until then.

[dull schooner]

Could we just default to no colors for naga_oil?

[warm crystal]

yeah we can do that

but i'm a little peeved

[dull schooner]

yeah, I mean, I'd prefer having colors too, but I guess once tracing fixes the issue we can make a point release that turns it back on?

[south shell]

They know via the linked issue. My hope is that they'll allowlist colors.

[warm crystal]

i can prepare a naga oil pr if someone else isn't already doing it

[south shell]

Alternatively we could just patch bevy_log

[warm crystal]

how so?

[south shell]

I could've sworn there was a way to write a log filter for something like this

It would be pretty jank, but it would at the minimum not show up in the naga_oil releases

[edgy jetty]

Yes please

[dry rune]

Are we good to make the bevy->bevy-website release content move?

[warm crystal]

https://github.com/bevyengine/naga_oil/pull/129

[dry rune]

I know theres one outstanding migration guide, but we can do that on the bevy-website side

[edgy jetty]

Yeah I can make a PR to that instead if you want

(for #21041)

[dry rune]

As in you'll grab it instead of nth?

[edgy jetty]

Yep!

[dry rune]

Cool. I'll start doing the move then

[dry rune]

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

[edgy jetty]

Queued 🙂

[edgy jetty]

And merged 🙂 Ping me when you have things for me to review! I'll be around this evening

[dry rune]

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

We have two paths forward here: merge now and iterate (it is already set to "draft" / hidden mode) or work on that branch

I like "merge and iterate"

[edgy jetty]

🚀 🚀 🚀

[dry rune]

"merge now" doesn't mean right now. its worth reviewing the content

[edgy jetty]

I take it you're planning a second PR for the migration guides?

[dry rune]

Yup!

[edgy jetty]

I'll do a review then we'll merge and iterate?

[dry rune]

I think its most important to review the "new" content (the intro and the shortcode)

In addition to making sure everything is there / well formatted

[edgy jetty]

Hmm, lemme check how @fair harness's abomination is formatted on the site 🤔

[fair harness]

how is it

my cursed unholy digital offspring

[edgy jetty]

I think that's "tolerable"

Mostly funny

[fair harness]

not too bad yeah

[acoustic nimbus]

PRs: Too many to count (X)

[edgy jetty]

Ah, of course. (We should merge without adding this)

[slim lintel]

in the future i want to have better support in the tool for automatically finding and downloading these.

just need to pick markup for it.

[edgy jetty]

Yeah, preparing images can really take a lot of time

[slim lintel]

it might instead make sense to have a private maintainer-only google drive (or similar) that yall can collect images into as you merge stuff?

[edgy jetty]

Eh, won't save that much time

The core problem is correlating the images with each section

And generating missing ones

[dry rune]

I'd be on board for filtering this down

It certainly is using more space than it deserves / it will cause most readers to think about it when they probably shouldn't be

[slim lintel]

an expanding section would be neat. PRs: #0000, #00001, and 6000 more (and you click on it to reveal the rest)

[dry rune]

Why is this rendering so wObbLy for you?

[fair harness]

what wobble?

[dry rune]

@edgy jetty's rendering of some characters are bigger / offset weirdly

[fair harness]

oh shit

damn

the p and d

[fair harness]

i thought your screenshot was a screenshot of hers, and was analyzing that

[dry rune]

WHOA look at my chromium rendering

Something is WRONG

[edgy jetty]

Yeah I'm on Chrome here

[fair harness]

comic sans 2

[dry rune]

OS?

[edgy jetty]

PopOS

[dry rune]

Hopefully just scoped to linux

[edgy jetty]

Yeah. It's okay, Linux people are used to things being slightly wonky for inexplicable reasons

[dry rune]

Still deeply embarrassing / will reflect poorly on us:

[fair harness]

this reminds me of noscript jank font rendering

[dry rune]

Same deal on bevy.org / this isn't scoped to localhost

Also affecting rust-lang.org (who also uses fira sans)

@edgy jetty its worth giving the rust team a heads up. know a good person to ping?

[solid sapphire]

secret halloween easter egg :o (but not really)

[edgy jetty]

@grave fiber who should we bother about this?

[edgy jetty]

Yeah, this is Not Good

[slim lintel]

two pings in one night

[grave fiber]

oh my god web native SpongeBob text

[grave fiber]

no idea probably the infra team folks lol, I think there's a website team??? but I can't really remember and infra would be able to get the right ppl lol

[edgy jetty]

Hey @dire widget, I'd be interested in your opinions on the hotpatching section of our draft release notes before we ship them. You'll have a few days, but I want to make sure you're happy with both credit and explanation

[edgy jetty]

Doing this now

https://github.com/bevyengine/bevy-website/issues/2235\

[warm crystal]

can't repro on macos

[edgy jetty]

Noted, thanks

[dry basalt]

Hwat in the god damn. Do we have comic sans as the backup font?

Huh nope we load from local font assets

[dull schooner]

For the record, it looks fine on windows with vivaldi (chromium)

[dry basalt]

I can't check on Fedora rn 'cause Chromium is bugging out.

of course its because wayland broke chromium.

switching to x11 mode on chromium I can replicate on Fedora 42 wayland

not seeing it on firefox however

so def chromium issue

and since its not on windows or macos its a linux chromium issue

gonna do a couple of local html tests. (doesn't seem to have issues rendering Fira Sans on google fonts site)

Reddit to the rescue https://www.reddit.com/r/pop_os/comments/1n9dpj6/solution_for_corruptedpixelated_fonts_in_chrome/

Chrome update to its font renderer borked up Fira Sans

[candid sable]

looks fine on zen browser which is a firefox fork, arch linux

checked on firefox as well no issues

[dry basalt]

ah, supposedly was fixed in version 140.0.7339.127, however not everyone reports it fixed (I tested on 140.0.7339.185 so def not fixed for me)

so nothing we can do about it except drop Fira Sans (I don't think this is wanted) or wait for chromium to get this fixed

related chromium issue page: https://issues.chromium.org/issues/445826647

Ah, I see now, the fix was for version 141 and beyond which hasn't entered stable (see https://issues.chromium.org/issues/438792570)

based on current Chromium release schedule, this should be fixed with the release of 141 around Sep 30th , so start of October. https://chromiumdash.appspot.com/schedule

[normal crag]

I just want to point out that this is a real card (sorry for the distraction, keep up the good work fellas)

[dry rune]

I've kicked off a merge of https://github.com/bevyengine/bevy-website/pull/2233

Migration guide is queued up. Required some shortcode changes so i'm waiting to open until after that merges

I've found a solution to the "spongebob text"

If we comment out the local() font sources, I get proper rendering

Given that most people won't have Fira installed, thats probably not a big deal

[edgy jetty]

Okay perfect

[edgy jetty]

Glad to hear it 🙂

[dry rune]

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

@edgy jetty given you also have a repro, can you verify that works?

[edgy jetty]

Aye-aye. I'm caught up on sleep finally, so I'll take a look promptly

[edgy jetty]

The problem is gone but I can't reproduce it now on live so 🙃

I vote we merge anyways though

[dry rune]

I'm going to start taking screenshots / recording videos / filling in missing media

[edgy jetty]

Sounds great. I'll focus my efforts on editing.

<@&1064695155975803020> @final zinc @grave dove @maiden heath, how's the temperature on a final release?

(and the rest of y'all here too!)

[maiden heath]

afaict temperature is good. The major things I was aware of are bevy-enhanced-input migrating and the naga-oil/tracing issue. Most people seem to have had smooth migrations so far. There's a few crates that usually update but haven't yet, like bevy_asset_loader. Perhaps that's just due to the smaller rc window at the moment. Otherwise seems pretty good overall.

I feel like the issues in rc.1 got raised and fixed really fast this cycle

[edgy jetty]

That's because there weren't a dozen different rendering regressions, thanks to @proud bone

(and I was able to do things other than just grind away on release notes)

[dry rune]

Yup I think we're in a good spot, other than finalizing release notes

(and landing the NonSendMut aliasing fix)

[edgy jetty]

Yeah lol

Excellent spot on that @naive turtle. Merging #21186

[acoustic nimbus]

@dry rune left a bunch of feedback on https://github.com/bevyengine/bevy-website/pull/2233#pullrequestreview-3260349774 (didn't have anywhere else to put it)

[edgy jetty]

Website issues would have been easier to track IMO 🙂

But it's very much appreciated!

I'll spin them out?

[acoustic nimbus]

Err if you want? I think 1 gh issue per comment is going to be a lot, but up to you

[edgy jetty]

Much easier to track for me

Opening and closing issues is cheap

[dry rune]

Perhaps a single issue with a link? Those are pretty small / tweakable

[edgy jetty]

Okay, can do 🙂

[dry rune]

@acoustic nimbus if you want you can also just make the changes yourself 🙂

[acoustic nimbus]

No time, I need to finish packing before the movers come tomorrow 😥

Hence the very short comments

[dry rune]

No worries. Thanks for the feedback!

[edgy jetty]

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

I took a look and formed opinions on all of these too

[primal arch]

There's one thing tripping me in the upgrade; you used to be able to do cycles in required components (A requires B and B requires A, to guarantee the archetype invariant that A and B are always inserted together on an entity). It's not possible anymore, is that intended?
It's a fairly disruptive change, that was pretty useful to me. This limitation was added in https://github.com/bevyengine/bevy/pull/20110

[edgy jetty]

I think this is a reasonable use case, but it was never intentionally supported (which is why there's no tests for it)

@onyx oxide may have ideas on how we can square the circle there 🤔

[edgy jetty]

Editing notes! https://github.com/bevyengine/bevy-website/pull/2239

[edgy jetty]

Can you please file an issue for this? I would like to support this in the long-term, but I don't think the fix is easy, and the linked PR that broke this is also quite important.

[onyx oxide]

It's my understanding that this was explicitly disallowed in the previous implementation, but due to a bug it was never enforced and I fixed that (among other things)

I'm not sure if the logic still works correctly when there are such cycles though.

FYI it was first introduced in this PR https://github.com/bevyengine/bevy/pull/15458

[edgy jetty]

cc @fathom shoal for discussion too if you have things to say 🙂

[edgy jetty]

Yeah, that's about my feeling. It would be nice if it worked, but it seems somewhat incoherent with the formal model of this

[onyx oxide]

Thinking about if for example any of A or B required a C that requires a D then I think we would probably order D incorrectly

Or maybe not 🤔

Yeah even if it worked this is really confusing to reason about

[acoustic nimbus]

Thanks! Will look tomorrow after the moving is done. I am too exhausted to edit writing after finishing packing.

[edgy jetty]

Very reasonable!

[grave dove]

A bit busy with Replicon (I started working on a feature before RC and it took more time then expected) and life stuff. Will try to provide feedback asap :)

[fathom shoal]

Mm Avian release prep may still take a while, but that's of course not blocking for a Bevy release

[final zinc]

Looking good! I would feel more confident if I could verify that Foxtrot renders the same, but that depends on BEI. @grave dove let me know if you need help with the migration 🙂
Also note that Hanabi has not migrated yet, but I think any issues they would run into are going to be wgpu and not Bevy-related

[grave dove]

We have an unfinished branch for 0.17. If you are interested, feel free to pick it up, I'll be able to review and merge today 🙂

But let me know ahead of time if you do to avoid duplicate work, because I planned to start the migration soon 😅

[final zinc]

Updating BEI now, got a tiny documentation issue for 0.17: https://github.com/bevyengine/bevy/issues/21194

[final zinc]

Also, here's a trivial blocker: https://github.com/bevyengine/bevy/pull/21198

[primal arch]

Opened https://github.com/bevyengine/bevy/pull/21196

[final zinc]

I created this PR twice: once for main and once for release-0.17.0. That's the intended way, right?

[final zinc]

Update: oh, apparently not

Okay, continue submitting stuff to main, got it

[edgy jetty]

Thank you!

[final zinc]

Migrated Foxtrot! Everything is running almost perfect 🙂

@spiral wren seedling is running well, other than the symphonia spam that I hoped would be gone by now. I guess they didn't fix it yet? And I think those ALSA logs are new, not sure

@fathom shoal I thought you had fixed this, but I may be misremembering

And lastly

Does anyone have an idea where this window in the top left is coming from?! 😂

@pure mantle is that from bevy_inspector_egui?

Or is this some new Bevy feature I didn't know about? 😄

[fathom shoal]

I fixed the warning about a duplicate solver plugin, but not that yet

[final zinc]

aaah right, now I remember!

now let's see if WebGPU still works

[nimble bison]

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

[final zinc]

Oh thanks!

[dry rune]

I'm curious how it was displaying without you knowing about it / configuring

[final zinc]

It looks like it's not following the same display rules as whatever I had configured to only show the FPS counter when I press F3

I believe it's ignoring the enabled setting :/

[edgy jetty]

That's believable 😅

[final zinc]

Ooooh it's an own thing

FrameTimeGraphConfig

[edgy jetty]

We should cross-link those in the docs

[final zinc]

A bit confusing that adding the plugin enables two things that I need to disable separately

[edgy jetty]

Yeah, it feels like those should be fields on one resource?

[final zinc]

hold up

[final zinc]

check this

it is already nested

the top-level enabled is just ignored

[edgy jetty]

Issue or PR please 🙂

[final zinc]

oof I don't like this design :U

[final zinc]

I'll open an issue

[spiral wren]

Yes, unfortunately.... symphonia has had a very slow release pace these last couple years.

[final zinc]

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

[final zinc]

Yep, that was it

app.add_plugins(FpsOverlayPlugin {
    config: FpsOverlayConfig {
        enabled: false,
        frame_time_graph_config: FrameTimeGraphConfig {
            enabled: false,
            ..default()
        },
        ..default()
    },
});

fn toggle_fps_overlay(mut config: ResMut<FpsOverlayConfig>) {
    config.enabled = !config.enabled;
    config.frame_time_graph_config.enabled = config.enabled;
}

[edgy jetty]

I hate that lol

[dull schooner]

So, uh, I'm like 99% sure the reason it's like this is just because I yeet the whole FrameTimeGraphConfig thing at the gpu and that's what controls the visibility enabled/disabled. I have no idea if the PR that adopted my PR changed that.

That code was mostly a proof of concept

[edgy jetty]

I'll try and make it less bad 😄

[final zinc]

alright, running on web is working less well

[spiral wren]

oh ya i ran into this with wasm bindgen 0.2.102 (or 103? one of them)

[final zinc]

what was your solution? I'm on wasm-bindgen 0.2.104

[maiden heath]

you have to pin the cli and the lib to the same version

[spiral wren]

...downgrade it to 101 😅

[final zinc]

heh, alright

[maiden heath]

the wasm-bindgen-cli and lib are shipped in lockstep, and must match exactly

[spiral wren]

Right, but in my case I thought trunk already downloaded the correct version. Although maybe it looked at the Cargo.toml and incorrectly guessed the version.

[proud bone]

it gives another error on version mismatch

[maiden heath]

ah, you're right, I read the "replaced" too fast.

[final zinc]

yeah that part I know 😄

[proud bone]

I'm compiling the breakout example on 0.2.104 and it works

[final zinc]

then it's probably seedling's fault

[pure mantle]

hehe i thought that was a feature

[craggy cypress]

Trying to run examples in wasm. If I run either
cargo install --git https://github.com/TheBevyFlock/bevy_cli --branch main --locked bevy_cli
or
cargo install wasm-server-runner
I get

error: The "wasm_js" backend requires the `wasm_js` feature for `getrandom`. For more information see: https://docs.rs/getrandom/0.3.3/#webassembly-suppor

I have the env var set (RUSTFLAGS='--cfg getrandom_backend="wasm_js"') and can build bevy successfully for wasm with
cargo build --example deferred_rendering --target wasm32-unknown-unknown --features getrandom/wasm_js

[warm crystal]

you need bevy cli to install bevy cli

[final zinc]

bevy run --example deferred_rendering --features getrandom/wasm_js web

I don't think it enables the feature for you

just the rustflag

Is that right @rapid mantle?

[rapid mantle]

That's right. It wasn't possible for us to automatically enable the feature without modifying the Cargo.toml, so we don't do it automatically

[craggy cypress]

this was about installing bevy cli, I tried the binary but wasm-bindgen is out of date

[final zinc]

oh I see

[craggy cypress]

i have 0.2.104 everywhere

[warm crystal]

i totally ran into this and have no idea how i fixed it

[craggy cypress]

I'm really confused as to why there isn't an issue about it. How is anyone installing it?

[warm crystal]

did you try in a totally fresh shell? i'm trying to remember what i ended up doing or whether it magically started working. but i had the exact same like uhhhhh how am i supposed to install anything? problem

[final zinc]

Mine just, uuh, works

[rapid mantle]

Are you setting rustflags globally, e.g. in your ~/.cargo/config.toml?

Maybe you are enabling the Wasm backend even if you are not compiling for wasm

[craggy cypress]

I made a global env var

[warm crystal]

point being, i'm really frustrated by this. it's extremely user hostile and i think deserves us taking action although i'm not sure what that looks like

[craggy cypress]

$env:RUSTFLAGS
--cfg getrandom_backend="wasm_js"

[rapid mantle]

Basically, when you enable the getrandom backend, you also have to enable the feature
So doing it globally unconditionally doesn't work well

[warm crystal]

having to set rustflags to install a crate is something i've literally never done before in 8 years of writing rust

[craggy cypress]

oh

[rapid mantle]

You can remove that workaround and then let the CLI enable the flag itself only when compiling for Wasm

[craggy cypress]

dfaskdjfahsdkjfhaweuoifbans;d

[final zinc]

See, the getrandom devs truly live in the future

[edgy jetty]

I griped a bit about it upstream >.> Nothing really came of that though

It's very bad though

[final zinc]

on the bright side, since rand is a very widespread crate, it suddenly became very normal to do this for a lot of applications that run on web

[craggy cypress]

I had figured that enough time had passed that there would have been good docs about it, for this reason. But apparently not.

[warm crystal]

open source is really easy when you don't care about your users

[craggy cypress]

ooooook now getting somewhere. It starts to load and then locks up with:

[final zinc]

you need to enable the reflection feature

sec

Enable reflect_auto_register

[craggy cypress]

I get the same error with bevy run --release --example deferred_rendering --features getrandom/wasm_js,reflect_auto_register web

[final zinc]

the heck >:[

[craggy cypress]

It also didn't look like it recompiled anything

[rapid mantle]

I think on some systems, separating multiple values by comma didn't work?
Just as a sanity check, try

bevy run --release --example deferred_rendering -F getrandom/wasm_js -F reflect_auto_register web

[craggy cypress]

I get the same issue with this, and no recompile.

[rapid mantle]

Is it just the latest bevy main?
I'll try locally as well

[craggy cypress]

git checkout tags/v0.17.0-rc.2

[rapid mantle]

Did you do anything else or just load it?
Which OS and browser is this?
It seems to work for me

[craggy cypress]

just ran bevy run --release --example deferred_rendering -F getrandom/wasm_js -F reflect_auto_register web on a clean checkout and then opened the link in the browser if that's what you mean
This is windows, tried both ff and chrome

[rapid mantle]

I'm on Linux, but I don't see any issues on neither FF nor Chrome

[craggy cypress]

I guess I'll try on a mac

[craggy cypress]

seems to work on the mac, though forward+prepass looks more messed up than usual

[warm crystal]

wait this is on web not metal right

[craggy cypress]

web

[warm crystal]

lemme give it the ol reproduce-a-roo

[craggy cypress]

Still getting the reflection issue on windows. Did rustup update, cloned bevy main into new folder.

[warm crystal]

i see the same result on chrome but not firefox

although firefox is unbearably slow

chrome left ff right

[fair harness]

try reverting https://github.com/bevyengine/bevy/pull/20313

im 99% sure that will fix it

[warm crystal]

it's broken on webgpu too on chrome

[warm crystal]

okies will try

[final zinc]

Does PixelEagle not validate web renders?

[warm crystal]

this requires some key presses after the example loads

which would probably be worth supporting

[warm crystal]

revert fixes it

[craggy cypress]

I'm not sure if it runs the deferred rendering example either

[fair harness]

knew it. i'd revert only the impl changes to the view transformations

not the new view transformation file

[craggy cypress]

(which is unfortunate since it breaks often)

[fair harness]

i dont know why chrome cares about this

seems real wacky

[warm crystal]

i need to run in a sec but can we create an issue for the above ^ in 0.17

[fair harness]

https://github.com/bevyengine/bevy/pull/21202 made a pr for a revert and put it on the milestone, if no other solution is found i guess we go with this

[warm crystal]

why is math so silly sometimes

[fair harness]

its not about the math being wrong

this is some kind of weird chrome wgsl bug

im not really sure whats triggering it

but i havent investigated at all

im guessing something about passing a binding as fn param gets fucky for some reason

[craggy cypress]

chrome would be using glsl here though

[fair harness]

oh glsl

ew

[craggy cypress]

so your pr making wgsl that naga turns into glsl that chrome doesn't like

[fair harness]

yea

horrendous

[craggy cypress]

chrome probably turns it into hlsl on windows and msl on metal.. idk about linux

hopefully just spirv in angle

[fair harness]

😭 wgsl -> naga ir -> glsl -> hlsl

[craggy cypress]

this is especially funny considering everything gets inlined anyway

[fair harness]

wesl cant come soon enough

[craggy cypress]

it's not like GPUs ever call functions you wrote unless it's like CUDA or something

[craggy cypress]

How does wesl affect this?

[craggy cypress]

other than it then being wesl -> wgsl -> naga ir -> glsl -> hlsl -> dxil

[fair harness]

with wesl we would inline it at the source

so it would be indistinguishable to everything downstream

@inline attribute

[craggy cypress]

interesting, never considered a shader lang having an @inline attribute since everything is always inlined anyway

Probably makes sense to deal with bugs like this and lets you do get around misc limitations I guess

(like being able to pass anything to/from a fn)

(or put anything in a struct)

[fair harness]

yup

wesl is gonna be so great

[craggy cypress]

Why require the attribute? Other languages (hlsl/slang) let you pass most things to/from a fn or put them in a struct without needing an attribute.

I guess stuff useful for the buggy case

[fair harness]

yeah, it might become automatic at some point

[final zinc]

Update again: Foxtrot is definitely working alright in 0.17, but bevy_seedling's experimental Wasm multi-threading audio backend is broken.
It's probably not the fault of Bevy, but worth noting for anyone trying to migrate. (maintainers are already informed)

[dry rune]

Almost done with "release post media"

I'm also going to slim down my "event rearchitecture" section. taking up a bit too much brain space at the moment

@acoustic nimbus is setting the clear color in Solari possible? Currently recording a smooth flyby through the robot scene, and a white background would be nice (if its supported)

Currently it seems like ClearColor is ignored

(or perhaps "covered" by the outputs)

AH

wait its being set on the camera

[acoustic nimbus]

Oh hmmm, technically no, I should add that, but if you go to restir_di.wgsl, you can replace textureStore(view_output, global_id.xy, vec4(vec3(0.0), 1.0)); with whatever color you want

I'll make a note to support clear color, and eventually I did want to add atmosphere support

[dry rune]

Yup changing this does nothing

[acoustic nimbus]

But the tricky thing is that the atmosphere/background should affect the scene's lighting because it's all RT

And doing that will be a bit annoying

Anyways

[dry rune]

Hmm "do a thing thats technically not supported in the release" or "make it pretty"

[acoustic nimbus]

yeah don't use the component it won't work

[acoustic nimbus]

I can make a 3 line PR if you want 😅

Just need to add clear color as a push constant and then use that in the shader

Or have a dedicated "clear" pass before using solari

I'm unsure long term what I'll want to do

[dry rune]

Hehe if its that easy lets do it. I'll hack it in

Seems like a feature people would be happy about anyway

[acoustic nimbus]

Tbh the proper thing to do is probably to setup a render pass that does nothing but clears the texture...

And then remove that shader line

Hrmm

Also note that a white background is technically not physically correct, as rays that miss the scene geometry should technically return white, not zero

But tbh who cares, it's a video game

[dry rune]

Yup that makes sense. I doubt people will find "sorry the only background you can have is black because that is the only physically correct background" a compelling argument 🙂

[acoustic nimbus]

Yeah 😅

[dry rune]

@acoustic nimbus do you have good pics for this already?

[acoustic nimbus]

Steal from my blog post: https://jms55.github.io/posts/2025-09-20-solari-bevy-0-17/

Gbuffer (not everything pictured)

DI

GI

Composited

Denoised and antialiased (and upscaled, although the previous screenshots I had upscaling disabled)

[dry rune]

Nice. Hmm I just recorded the flyby but didn't do any toggling like you did in yours:

[acoustic nimbus]

ooh nice

[dry rune]

Sadly we can't use a bunch of time for file size reasons

[acoustic nimbus]

actually, makes me a little sick to watch on repeat :/

[dry rune]

I should probably avoid pressing shift. creates some "jerks"

I added some crude camera interpolation. Probably worth adding first class support upstream and enabling slight interpolation by default

[acoustic nimbus]

Leave it to someone else !!

Honestly that sounds fun to do though I will add it to my list™

(I have an actual list)

Oh if you want static screenshots btw https://jms55.github.io/posts/2025-09-20-solari-bevy-0-17/#numbers

[dry rune]

Yeah this is low hanging fruit / reasonably high value

[acoustic nimbus]

Sadly I cannot get you any other screenshots, my PC is in a shipping container atm 😅

[dry rune]

Ah should I be manually configuring anything to get maximum render quality?

[acoustic nimbus]

Not really? There aren't any exposed knobs atm on purpose. Goal is to have close to zero knobs.

[dry rune]

How about DlssPerfQualityMode

[acoustic nimbus]

The only ones that you can really change (by modifying the source code) are sample count for DI and world cache updates, but I would leave them as default, they're already close to max quality unless you have a 100 lights in your scene (large amounts of lights sadly not great quality in solari atm)

[craggy cypress]

the clear color and env color aren't really related imo, they're totally seperate in bevy's existing pbr, can be separate in blender/unreal, etc...

[acoustic nimbus]

Yes that too, you can trade resolution for performance. Set it to DLAA if you want highest quality, although you may kill your PC depending on resolution 😛

[acoustic nimbus]

Mhm. I have to sit down and figure out what it should look like 🙂

[dry rune]

Nice that runs at full fps for me

[acoustic nimbus]

What's your GPU and resolution?

[dry rune]

4090 (in a laptop) and 1280x720

[acoustic nimbus]

Oh, that would do it 😅

For comparison in my blog I used an RTX 3080, rendered at 1600x900, and upscaled to 3200x1800 using DLSS-RR performance mode.

And DLSS-RR performs way better on 40 and 50 series GPUs

[craggy cypress]

wow

[acoustic nimbus]

rtx 3080 is between the rtx 3070 and rtx 3080 ti in perf

[acoustic nimbus]

Yeah, Solari atm is strongly a "4070 reccomended" kinda feature :/

I think @heavy escarp has a rtx 4070 super iirc

Still, we can do a lot better

[craggy cypress]

I have one too actually

[acoustic nimbus]

Someone in the graphics server has a 500us GI 😛 (using completely different techniques)

Sooo ways to go 🙁

[dry rune]

At 3440x1400 and DLAA I get 40 fps on that scene

"playable" from console perspectives 🙂

[craggy cypress]

Tiny Glade has a few ms GI on GTX780's :p

(using obvhs #not-an-ad)

[acoustic nimbus]

Keep in mind half the pixels are background pixels and don't do any raytracing unless you zoom in, and on bigger scenes like bistro the world cache is about 23x more expensive 🙃

[acoustic nimbus]

Tiny glade is only RT GI though, not DI, while Solari does both

I think

I know they were messing with stochastic DI, but idk if it shipped yet

But yeah perf is a WIP

Solari is a big WIP

We're probably going to rewrite it completely

[craggy cypress]

Oh totally they are not remotely comparable except being a GI

[craggy cypress]

it has

[acoustic nimbus]

ReSTIR DI might not even stay