#Bevy 0.17 Release Crew

2816 messages · Page 3 of 3 (latest)

heavy escarp
#

I've already yeeted it, but not done implementing the replacement

#

and ofc no idea if it'll be any better

craggy cypress
#

(hypehype's stuff looks even crazier, running on stuff way slower than GTX780. I think it's all DI though (but soft))

acoustic nimbus
#

But it is stochastic

heavy escarp
#

if you can get away with super simple proxy geo you can make GI pretty darned fast tbh

craggy cypress
acoustic nimbus
craggy cypress
acoustic nimbus
#

(bring your own proxies though)

craggy cypress
#

oh lol this is the release crew thread, sorry for the GI spam xD

acoustic nimbus
#

Lol it's nice to see people interested in it. Very motivating compared to just developing it by myself.

#

We do have a solari thread if you want to talk there

heavy escarp
#

and then every thought in your head

craggy cypress
heavy escarp
#

we can make that 2025-forever super_bavy

craggy cypress
#

#goals

acoustic nimbus
#

Jasmine 2022-present (2023-2024 had a partial gap with virtual geometry taking up more brain space)

craggy cypress
#

My first post in this server / first use of bevy technically had GI: #showcase message

warm crystal
ivory nymph
#

Museum of Dead Card Games is finally up to 0.17-rc, almost all pain was in the events rework + figuring out where a bunch of imports had moved to.

normal crag
#

man this is exciting, bevy is starting to look like a real engine, hehe

final zinc
#

@edgy jetty I'll add an issue for this in a few minutes. Should it be a blocker? #1420792280880513134 message

#

It causes a render failure for users that

  • use image nodes
  • have those images nodes compressed
  • the image size is not a multiple of 4
  • and the app runs on webgpu
#

Which is… very specific 😄

#

Doing the exact same on native will crash on 0.17 with a human-readable error message

#

It’s just the fact that I mainly tested webgpu that had me running in circles

edgy jetty
naive turtle
final zinc
#

Oh wait that wouldn’t make sense here as it’s a migration

#

My bad

naive turtle
#

main doesn't have migrations tuff anymore

proud bone
proud bone
final zinc
proud bone
naive turtle
#

I've created a pr against .17 for now

dry rune
naive turtle
final zinc
#

did not add it to the milestone

#

Just uuh

#

keep it in mind in case a user asks about weird errors on webgpu after migrating

naive turtle
final zinc
#

fixed 🙂

edgy jetty
edgy jetty
#

I can do it for you: I think you're on European time 🙂

#

And I have another of my own to add.

edgy jetty
final zinc
edgy jetty
final zinc
edgy jetty
edgy jetty
edgy jetty
#

@spiral wren @subtle ridge @fathom finch @dusty dagger @dry rune @warm crystal @dull schooner I've highlighted plans that are loosely "yours" in here: please let me know if you have complaints about the framing or inclusion of them 🙂

#

Oh also @final zinc @dusk linden @maiden heath I have an asset preprocessing work item in there that would benefit from your feedback

final zinc
maiden heath
final zinc
#

might be a skill issue though

opaque magnet
edgy jetty
final zinc
maiden heath
#

I wouldn't include this in the notes without a documented issue tracking work or someone who has dedicated time to work on it. We don't even have a working group for it right?

final zinc
#

AFAIK (and again, I might be out of the loop), it's something we all agree needs to be better, but no one (singular or plural) is spearheading it

#

So I would also cut it from that section

maiden heath
final zinc
final zinc
#

outside of the text input stuff

#

It's neat that we have experimental UI widgets now, but what I'm really really excited for is what @opaque magnet can cook up with BSN 🙂

opaque magnet
#

@edgy jetty In terms of "what's next" I was also thinking of writing up a tracking issue for all of the various ideas that @fathom finch and I have been thinking about for improving text and fonts:

  • ComputedTextStyle
  • Font style inheritance
  • Font aliases and registration
  • Font atlas caching and retention
  • System fonts
  • Rem/Em units
final zinc
opaque magnet
#

I kind of want to revive the old lorem-ipsum working group, although perhaps under a new name - the specific issue that WG was intended for (text as entities) was successfully implemented, and it has proved to be a winner IMHO. But there are a lot of other text-related improvements that never got done.

final zinc
opaque magnet
#

@final zinc I think supporting rem units is probably the best way to solve your specific readability issues that you have brought up. For example, if the button height could be specified in rem units, then buttons would increase in size when the global font size was increased.

final zinc
opaque magnet
#

I've also thought about a standard BEI action for adjusting the global font size, which gives you the +/- behavior that you are used to in VSCode.

dry rune
#

(given that we're landing hotpatching)

final zinc
#

so users will pick up the rc anyways

#

Though I suppose having that point to the newest version at release makes sense

#

approved

edgy jetty
#

I'll focus on UI and docs next cycle I expect

static hearth
dry rune
#

They behave like "major versions" afaik

final zinc
#

So I woudln't be surprised if Cargo treated them like major versions

dry rune
final zinc
#

In that case I fully agree that we need to have this in 0.17 🙂

#

good catch!

dry rune
#

Oops accidentally deleted a message pinging you @static hearth. Sorry if thats confusing (I was just drawing your attention to the last couple of messages)

final zinc
#

but maybe that item itself got removed from the release notes shrug

dry rune
final zinc
#

The part I as a user would want to see is the one showing the "canonical" orientation in Blender

#

i.e. this guy

455078018-8f5ae364-48f0-46e4-922b-50bccb8d58b3.png
dry rune
#

I didn't consider that it would need them. I think that screenshot does help illustrate though

#

I think including the others would probably be excessive though

final zinc
#

I think I wrote somewhere to only include the fox

#

but maybe I'm misremembering

dry rune
#

I recommend adding a TODO in the release notes themselves, as I only click through PRs for screenshots when I think to look for them

#

(or a TODO tells me to)

final zinc
dry rune
final zinc
dry rune
final zinc
#

If you open an issue and assign me to it, I can write it tomorrow

#

if you already add the pic now, I can just reference it 🙂

dry rune
final zinc
dry rune
#

Bringing blender (and their coordinates) into the picture just adds another set of information for the reader to contend with

final zinc
#

And he would definitely have appreciated a clear pic of "look, this is how it's supposed to look"

#

but it's definitely a cherry-on-top kinda deal

dry rune
#

Maybe we should direct that energy to adding a section to the book that covers the whole blender <-> bevy coordinate system story

final zinc
dry rune
#

Yupyup

final zinc
#

I bet @maiden heath also has a thing or two to say about Blender <-> Bevy

final zinc
dry rune
#

Blender -> BSN is the endgame I think

final zinc
maiden heath
dry rune
final zinc
#

And it's kinda neat that I can do that by just exporting glTF

#

exporting both glTF and BSN feels comparatively heavy. Do I put both in my VCS?

dry rune
#

If you need other tools between blender and bevy, I think gltf-only is the move

#

Unless you want to add BSN support to those tools 🙂

final zinc
dry rune
#

Nope 🙂

edgy jetty
#

No rendering-specific future work, but I think that's fine because we're mostly in a tech-debt/foundations phase for the next bit from what I've seen 🙂

final zinc
#

-# also bevy_seedling is amazing, thanks for including it

edgy jetty
final zinc
#

approved in that case check_accept

edgy jetty
#

I also don't think it's very convincing to people who aren't currently Bevy users 🤔

final zinc
#

Oh btw, we managed to iron out all WebGPU and multithreaded audio issues on Foxtrot 🙂 Can confirm it all works lovely in 0.17!
(See https://janhohenheim.itch.io/foxtrot on a browser that has WebGPU support)

edgy jetty
#

<@&1064695155975803020> the final two PRs for Bevy 0.17 are in the merge queue. We have open PRs for all of the remaining content for the release notes: summary, future work and images.

The only remaining release tasks are:

  • refine and merge the final bevy-website PRs
  • final numbers for contributors etc
  • more polish on the release notes
  • bump to 0.17.0 and do a cargo publish
#

I'm done for the week now, and will be hiking quite a bit this weekend 😄

#

So uh, my availability will be limited!

dry rune
edgy jetty
radiant crescent
# final zinc not sure if that's intentional, but it's missing the screenshots in https://gith...

I think this is incredibly tricky in every game engine out there. There are hundreds of hours of YouTube content dedicated to exporting correctly from Blender to other things. Usually other engines seem to expect you to change export settings in Blender as a prerequisite to have it working correctly in engine. I personally think things like this should be extensively documented so that people don't have to do trial and error. Even if gltf coordinate conversions magically solves all the issues I think the underlying problems should still be documented. Maybe this has no bearing on the 0.17 release but I just wanted to mention I agree that this stuff is vitally important to extensively document somewhere.

craggy cypress
# radiant crescent I think this is incredibly tricky in every game engine out there. There are hund...

Even if gltf coordinate conversions magically solves all the issues
Unfortunately it can't. At least not with gLTF. You can either have the coordinate systems match (current and prior bevy) or have the forwards match (the new feature (with some exceptions)) but not both, at least not while maintaining other things bevy cares about much more (at least based on various conversations this cycle).

dusty dagger
naive turtle
primal arch
fiery raven
primal arch
#

Oh i see; how could i make a dynamic query (FilteredEntityMut) be able to fetch disabled components?

fiery raven
#

I would expect builder.filter::<Allows<CustomDisabled>> to work, but I haven't actually tried it.

primal arch
#

Maybe by changing my query to Query<(Option<&Disabled>, FilteredEntityMut)> thanks to your other change?

fiery raven
#

builder.data::<Has<CustomDisabled>> should also work

final zinc
#

This stuff should be in the migration guide imo

fiery raven
#

No, Option<&Disabled> never counts as a use, because we can't distinguish Option having access to some things from EntityMut having optional access to everything.

#

Yeah, sorry, I should have written a migration guide for that. The first version didn't have the breaking change, and I forgot to add one when I reworked it.

primal arch
#

Both your alternatives work, thanks!
I'm a bit confused as to why Has<T> is archetypal; doesn't Query<Has<T>> match all entities?

fiery raven
#

The meaning of "archetypal" here is a little muddled. I think it was originally added for Has<T> to mean "this query doesn't read T, but the results might change if a T gets inserted or removed". It then got repurposed for Allows<T> to mean "this query doesn't read T, but it mentioned T, so bypass default query filters for T". Which is sort of the opposite! But also it means Has<T> bypasses the default query filters for T, which it clearly needs to do.

primal arch
#

Thanks, that's a very clear summary

final zinc
#

No pressure, it’s also fine if we at least copy paste this discussion into the open issue 🙂

fiery raven
final zinc
verbal ice
final zinc
#

@dry rune do you want some production feathers_ui showcase for the release notes?

image.png
#

The only non-upstream part of that screenshot is the text input, which is ick's bevy_ui_text_input, i.e. the one that we're upstreaming in 0.18 (in a modified form)

acoustic nimbus
#

Where did we get the cover image from? The lighting looks a little off 🤔

#

Like an I crazy, or are some objects missing shadows?

final zinc
acoustic nimbus
#

With a robot factory thing that's orange

final zinc
acoustic nimbus
#

Nw

final zinc
#

pretty sure that's a factory game I've seen in #showcase

#

and yeah the shadows don't look correct

#

Found it: #showcase message

#

yep, found it in their press kit

Press Kit

Press resources and media kit for Exofactory - indie factory game exploring the id and ego

#

Not that I have anything against their art style, but I would personally prefer the Solari scene as a cover 🙂

denoised_full.png
#

though there is no cute robot in the middle (yet?)

#

huh, weirdly enough this other screenshot of their press kit has correct shadows

MainCapsule_1232x706_01.png
#

Though maybe that was rendered in Blender and not Bevy

acoustic nimbus
acoustic nimbus
final zinc
acoustic nimbus
#

Unfortunately I don't have acess to my pc for a bit, but anyone else with a Nvidia GPU should be able to set it up

#

Also we should probably credit pica pica in the release notes

edgy jetty
edgy jetty
final zinc
fathom shoal
#

I kinda liked Jasmine's Bistro render over pica pica

bistro_perf.png
#

but we already used Bistro for 0.6's cover image, and yeah it makes sense to showcase real projects

dry rune
#

Yup the cover image is locked in for this one!

dry rune
celest hill
# edgy jetty <@330583390359257089>, in case you have better shadows available 🙂

Ahh the fact that people think the shadows look correct isn’t a good sign. The shadows are soft as an aesthetic choice to make the world look warmer.

I am using the default bevy shadow system tuned such that the shadows are as soft as possible for said aesthetic reasons. When I took those screen shots I didn’t have a save system written yet so I can’t easily recreate them sadly.

#

Let me take some new shots real quick

celest hill
#

With more accurate shadows settings

Screenshot_20250926_221717.png Screenshot_20250926_220955-1.png
edgy jetty
#

Man, that's so cool that this is Bevy

celest hill
#

This is the special "show off bevy's shadow system" build

wet thistle
#

Wow bevy’s shadows have come a long way since 0.6, looks great!

final zinc
final zinc
celest hill
slim lintel
#

just checking in, how has the new progress been for maintainers? it seems like the content migration went smoothly?

#

do we need to enforce better conventions for making where image/video content should be added manually?

dry rune
edgy jetty
dry rune
# slim lintel just checking in, how has the new progress been for maintainers? it seems like t...

In general it was definitely a big improvement. Some pain points:

  • I still spent a lot of time capturing / recording media, either because it wasn't included, it didn't follow conventions (the big ones being including "debug text" and "OS window decorations"), or it didn't put the feature in its best light. I also spent a reasonable amount of time re-encoding / trimming (converting pngs to jpgs to cut down size, cutting down videos that were too long / weren't mp4s / were "too big", etc)
  • I still spent a reasonable amount of time on a quality / editorial pass. Not much to be done about this as my whims are arbitrary.
  • I had to do a pass to unify markdown styling (ex: _emphasis_ vs *emphasis*, - list item vs * list item). Our rules look for internal consistency rather than global consistency. Global rules here would be nice.
edgy jetty
edgy jetty
#

https://github.com/bevyengine/bevy-website/issues/2252 could use some bikeshedding. My initial draft erred on the side of "underpromising", but maybe we could have a line that explicitly calls out that building an "editor" remains our driving goal, and the Future Work there all builds towards it?

GitHub
Consider discussing future editor development plans explicitly at t...

I was checking and there's a hint missing about the future of Bevy Editor:https://github.com/bevyengine/bevy-website/blob/main/content/news/2025-09-24-bevy-0.17/index.md#whats-next

acoustic nimbus
#

I was assuming maintainers would just take my screenshot, crop out the window title, and then resize it and add text

wet thistle
#

Someone needs to create an ascii cinema tool but for bevy demo content capture lol

acoustic nimbus
#

Probably just need to have a template for setting the window size, setting it to borderless, displaying some text with a certain font, etc

edgy jetty
#

bevy pretty_screenshot

maiden heath
#

it would be cool if there was some command-line config for examples that removed the window titles, etc. I've spent some time doing similar things and we might be able to plop an example plugin with the config behind a flag?

edgy jetty
proud bone
#

we could just do a plugin with Bevy builtin screenshot capability

#

otherwise instructions will have a part that will be OS dependent, it's going to be a bit painful

#

so instructions would be "add plugin ScreenshotPlugin, press key p, boom you have a screenshot"

#

next will be to write the ScreenrecordPlugin plugin that can record a movie... and its v2 that takes a list of positions and timings and smoothly move the camera

maiden heath
proud bone
#

no… I mostly use it in CI on integrated GPU where it’s definitely too slow

#

maybe it’s fast enough on actual hardware

#

otherwise we would have to make the ecs being driven by frame capture… which I wouldn’t hate. it would make Bevy usable for movie creation

maiden heath
#

its something I'd be interested in. the alternatives are things like remotion for graphics, etc.

proud bone
#

define target fps, make time advance when the frame is captured. we already have most of the tools

edgy jetty
proud bone
#

I know a few cartoon are made on Unity

#

work on the scene on your computer at 1080p / 60fps, once it's all good send it to the render farm to be rendered at 8k / 240fps

proud bone
edgy jetty
proud bone
#

doesn't exist on my laptop 😄

warm crystal
maiden heath
#

would I like better? yes. Is disk space my primary concern? no.

warm crystal
maiden heath
proud bone
#

ffmpeg can take a folder full of images to make a movie

#

but then ffmpeg can probably take /dev/urandom and make that into a movie

craggy cypress
#

folder of .exr files is basically the vfx industry's canonical video format

#

It would be funny to see what writes more to the drive per second: clean bevy build vs screenshots at 1080p60

proud bone
#

it would also probably be easy enough to capture every frame and send them to a software encoder instead of writing them all to disk

#

not as good as hardware encoding, but workable

craggy cypress
#

Unrelatedly, it seems like bevy is building faster than I remember

fair harness
#

render crate splits and reflect codegen cleanups

dry rune
#
  1. I think it has better composition
  2. I like that theres no UI in the shot
#

I think what makes a good "gameplay shot" is sometimes at odds with what makes a good "blog post cover shot"

#

I'm still inclined to roll with that one / I'm happy with it. The shadows dont really bother me. If you want to do more workshopping, I'm definitely down though 🙂

#

If we're going to try more options, my notes would be:

  1. Lets hide the reticle in the center and the ui widgets on the sides (although we can just crop the side widgets out ... only the reticle would require code changes)
  2. I think a shot closer to the ground, with the robot slightly off center works really well (with machinery and other stuff in the background)
proud bone
#

ouch discord compression makes it look way worse

maiden heath
#

yeah, assuming that flickering doesn't exist in the original?

proud bone
#

yup

maiden heath
warm crystal
#

or should be able to?

#

i know at least readback is fine to run every frame

proud bone
proud bone
#

from 30fps to 120fps is not friendly

warm crystal
#

we need in tree framepacing fr

final zinc
warm crystal
final zinc
warm crystal
#

this was a good summary of a few kinda related projects we would like to land in this area

slim lintel
#

i think i now understand point (3) properly, after talking with the winit devs.

#

our event loop need reform, i hope to do that during 0.18 and have it ready to land early in 0.19

#

assuming 0.18 is super quick, like everyone is sugesting

warm crystal
#

very excited! am available for review / testing as needed 🫡

#

one of my big goals this cycle is to get bevy set up on my old android/iphone so that i can finally test all the platforms

#

famous last words

slim lintel
#

oof

#

i'll take "able to run unit tests on web"

#

and be happy

warm crystal
#

oh very interesting

opaque magnet
#

@dry rune @edgy jetty I know this is kind of last minute, but a lot of my repos relied on the ability to impl DynamicBundle, and with the recent changes to bundles it appears that this may no longer be possible. That is, I used apply_effect to do various reactive things, and this now gives me compilation errors about being unsafe. I didn't detect this earlier because my experiments were working off of cart's branch which didn't have those changes.

#

Bundle's documentation now says:

/// Manual implementations of this trait are unsupported.
/// That is, there is no safe way to implement this trait, and you must not do so.

craggy cypress
#

If it crashes that sounds like a bug. Can you file an issue?

verbal ice
naive turtle
proud bone
grave dove
final zinc
grave dove
#

Thanks!

edgy jetty
proud bone
#

already cherry picked 🙂

grave dove
#

I really like the new entity layout - it compresses nicer into two varints.
However, the methods for reconstructing an entity feel a bit too raw. For example, here's how I create an entity with index = 1 and generation = 1 in my unit tests:

let expected_entity = Entity::from_bits((1 ^ u32::MAX) as u64 | (1 << 32));
#

We have Entity::from_raw_u32, but maybe we could rename it into Entity::from_raw_u32_index and add Entity::from_raw_u32 that accepts both generation and index as u32?

edgy jetty
#

I would be fine with friendly constructors for Entity like this as long as methods to spawn specific entities remain locked down

opaque magnet
# naive turtle this comment has existed for a while, but all of the bevy_ecs bundle types with ...

Well, I tried adding unsafe to my impl but the compiler just gives me an error, even with empty methods:

unsafe impl<E: EntityEvent, B: Bundle, M, I: IntoObserverSystem<E, B, M>> Bundle
    for AddObserver<E, B, M, I>
{
    #[inline]
    fn component_ids(
        _components: &mut bevy_ecs::component::ComponentsRegistrator,
        _ids: &mut impl FnMut(bevy_ecs::component::ComponentId),
    ) {
    }

    #[inline]
    fn get_component_ids(
        _components: &bevy_ecs::component::Components,
        _ids: &mut impl FnMut(Option<bevy_ecs::component::ComponentId>),
    ) {
    }
}
# 
error: implementation of an `unsafe` trait
spiral wren
opaque magnet
spiral wren
pure mantle
naive turtle
#

you might have to have an #[expect(unsafe_code, reason = "")] before the unsafe impl?

opaque magnet
onyx oxide
grave dove
primal arch
#

Does Single change meaning in 0.17? or is it planned for 0.18?

final zinc
#

it's planned for whenever the error handler can differentiate between error severities

verbal ice
#

speaking of the error handler, if an error occurs, will that always stop the app in some way?

#

like a system returning a Err(BevyError)

edgy jetty
verbal ice
#

okay, thanks

edgy jetty
dry rune
grave dove
frosty hare
final zinc
#

@arctic siren mind taking a look?

#

Also, tracy being broken on macOS sounds like a definite blocker to me, moving the original issue back into 0.17 too

#

Which should be alright, given that the fix is right there 😄

feral imp
#

i'm a bit curious, do somone have the time it tooks for each bevy version to get released ?
I feel like 0.17 took 5 month and half and 0.16 took 5 month and like 7 days ?

grave dove
verbal ice
ivory nymph
#

0.6 georg

feral imp
#

i noticed each update become more and more ambitious with bigger/harder to code feature since 0.14

#

and bsn/the editor/many-to-many feature are comming, so it looks like it will continue to go this way for 0.18-0.21

dusty dagger
#

Can i just check if the latest feathers changes are up to date on main @opaque magnet? I’d like to get more feathers stuff in the inspector to showcase

final zinc
final zinc
feral imp
final zinc
#

Imo we had some bad timing with things like the event rearchitecture happening last minute and the RC being blocked by annoying stuff like docs.rs failing

feral imp
#

but it does continue the trend of each version taking longer than the previous

final zinc
feral imp
#

Bevy mostly has 1 release every 6 month right now

#

the community had a growth spike around 0.14 and stabilized (same time as release started to take longer)

#

it will probably have another growth spike when the editor get released in some shape

dusty dagger
#

sorry been OOTLP for a bit

fathom shoal
#

A whole bunch of Avian tests are now failing with this on 0.17 🤔

Encountered an error in system `Enable the debug feature to see the name`: Parameter `Enable the debug feature to see the name::messages` failed validation: Message not initialized
feral imp
#

oh jondolf

#

do you think just wanting a kinekic character control with gravity physic + hitbox collision is enough of a reason to add avian to a project ?

#

(no non kinetic character)

#

kinematic *

fathom shoal
#

For a sec I thought name::messages was some actual thing

fathom shoal
final zinc
final zinc
fathom shoal
#

Yeah apparently no message is initialized for AssetEvent<Mesh> in (your 😛) ColliderCachePlugin

dusty dagger
fathom shoal
final zinc
#

but uuh

#

that's not the job of the ColliderCachePlugin

#

sounds more like that plugin is not added in the test suite?

final zinc
fathom shoal
final zinc
#

I don't remember if the cache plugin is gated behind those though

#

Also, I have a new magic incantation for headless glTF tests in 0.17 that you probably will want to use

#

sec

# 
fn headless_plugins(app: &mut App) {
    app.add_plugins((
        MinimalPlugins,
        LogPlugin::default(),
        AssetPlugin {
            file_path: "your_test_asset_dir".to_string(),
            ..default()
        },
        ScenePlugin,
        MeshPlugin,
        TransformPlugin,
        VisibilityPlugin,
        GltfPlugin::default(),
    ))
    .init_asset::<StandardMaterial>()
    .register_type::<Visibility>()
    .register_type::<InheritedVisibility>()
    .register_type::<ViewVisibility>()
    .register_type::<Aabb>()
    .register_type::<MeshMaterial3d<StandardMaterial>>();
}
#

^ this might be of interest to other migrating to 0.17 as well

fathom shoal
#

oh also the tests do have MeshPlugin thonk so it seems like it's something else

final zinc
#

Which goes into crappy "we have plugin dependencies at home" territory

#

imo better to be honest about which things beyond MinimalPlugins you need

#

But this is a weakly held opinion ^

final zinc
#

but it's weird

#

add .init_asset::<Mesh>() to the incantation

#

If that works, I'll explain why

#

or at least try

final zinc
fathom shoal
#

Yup it works

final zinc
#

Okay, it's a caching issue

slim lintel
final zinc
slim lintel
#

In practice people were waiting for 0.13.1 to come out, which usually took a month or so

final zinc
#

The solution was rm -r ~/.cargo/registry/src/* bavy

#

Interesting that we both hit the exact same cargo caching issue while migrating

#

Hold up

#

I take that back

#

eek, MeshPlugin really doesn't init the mesh asset in 0.17!

fathom shoal
#

oof

final zinc
#

oh no

#

wait

#

wait a fucking second

#

There are two MeshPlugins bavybavybavybavybavybavybavybavybavybavybavybavy

fathom shoal
#

??

final zinc
#

the first one initializes the mesh asset

#

the second doesn't

#

so uuuh

#

@fathom shoal is it possible that you're adding the wrong MeshPlugin?

fathom shoal
#

I believe I am yeah, 0.16 only had the bevy_render one so it's still using that

final zinc
#

oh wow this is subtle

#

the 0.16 MeshPlugin was moved to bevy_mesh, but there is now a new MeshPlugin that is at the exact same import path as the old one

#

ping @fair harness

#

okay, this is a definite blocker IMO

#

Looks to me like the rendering plugin is an implementation detail

#

Can we just not make it pub?

#

hmm, the rendering MeshPlugin has a doc comment saying it's supposed to add the asset

image.png
#

But that reads like it's more or less a duplicate of the regular MeshPlugin with some extra steps, which sounds wrong

#

would you look at that, the Bevy CI itself does the same mistake lol

#

@fathom shoal there ya go

#

wheew, good thing we caught this, otherwise with a headless server would have gotten a very very confusing error

#

Also funny that I already ran into this and gaslit myself into thinking it was a caching issue

final zinc
#

@fathom shoal 💀💀💀

image.png
#

What even is the difference between the two MeshRenderPlugins?

#

Both seem to "make sure meshes can be rendered"

#

hmm loads a bunch of shaders, I see

#

I'll rename that one to MeshPbrPlugin

#

I hate all of this

fathom shoal
#

It seems like MeshRenderPlugin does the actual rendering, and bevy_render::mesh::MeshPlugin mostly prepares mesh data, assets, and resources and whatnot?

#

idk

final zinc
#

I'll instead name the one in bevy_render to MeshRenderAssetPlugin, given that it works with RenderAssets

#

Yeah, I like that

fathom shoal
#

as not-a-rendering-person, that seems reasonable

final zinc
#

I think it still needs to be public, since I believe that the glTF plugin actually needs both MeshPlugins bavy

#

Let's see what the CI says

fathom shoal
#

One might find it mildly bavy that a MeshRenderAssetPlugin does not actually initialize Mesh as an asset

#

but it's probably fine since it's documented that it's done by MeshPlugin

final zinc
#

@fathom shoal btw here's the pre-existing migration guide

image.png
#

re-exports have now been removed.
ironic

fathom shoal
final zinc
fathom shoal
#

yeah

final zinc
#

Otherwise I would have added it, yeah

final zinc
#

Whew we were in luck

#

no need to add MeshRenderAssetPlugin to the GltfPlugin

#

The reason the CI complained (rightfully!) was that MeshPlugin forgot to initialize skinned mesh bind pose assets

#

PR should be good now 🙂

#

Also added two trivial PRs by @primal arch to the milestone, since they are extremely low risk and they would like them for their migration

edgy jetty
viral shoal
final zinc
final zinc
#

^ wanna include this in the section about the new headless widgets? 🙂

viral shoal
final zinc
viral shoal
#

I'd be for it

#

Shows clearly what bevy is capable of

worn current
edgy jetty
final zinc
edgy jetty
# final zinc

IMO this is most interesting because it demonstrates the truly unusual level of flexibility that we're striving for in bevy_ui

#

9-patches and shaders are a common request for game UI

#

And extremely rare everywhere else

outer escarp
#

I'm trying to migrate the hexx crate to 0.17 and I'm having some issues with reflect. I've read the 0.17 migration guides relating to reflect, but can't work out what I'm meant to do. I've not contributed to hexx before so not totally familiar with its inner workings. I get an error with a struct member that's a reference to a type that itself derives reflect:

#[derive(Debug, Clone)]
#[cfg_attr(feature = "bevy_reflect", derive(bevy_reflect::Reflect))]
pub struct PlaneMeshBuilder<'l> {
    /// The hexagonal layout, used to compute vertex positions
    pub layout: &'l HexLayout,

the inner type HexLayout also derives reflect:

#[cfg_attr(feature = "bevy_reflect", derive(bevy_reflect::Reflect))]
pub struct HexLayout {

But in 0.17 I get this error

error[E0277]: &'l HexLayout does not implement GetTypeRegistration so cannot be registered for reflection
help: consider removing the leading &-reference

I was thinking it could be auto-registration related? And/ or related to this being a library that doesn't pull in bevy default features (in fact, it just depends on bevy_reflect). The 0.16 code doesn't call register_type on either PlaneMeshBuilder or HexLayout, so my understanding of the autoregistration migration was, that I wouldn't need to enable reflect_auto_register in 0.17? Sorry, this could be off-topic. But was wondering if there was maybe an incomplete migration guide?

final zinc
acoustic nimbus
#

I've been out the last few days, are we still planning on releasing today?

dull schooner
#

I think it's been pushed back to tomorrow

slim lintel
#

there's a compile error in assets on web to do with the new http loader

#

i think this is a release blocker.

acoustic nimbus
#

:((

slim lintel
#

it should be pretty easy to fix though

warm crystal
#

i really see your art deco influences now @opaque magnet (:

ivory nymph
#

Art deco is one of the ones that really flies in the face of material design, it's a really good example.

final zinc
marsh crest
opaque magnet
outer escarp
marsh crest
edgy jetty
#

@outer escarp are you sure that the versions of glam etc used match? Bevy updated glam versions, which will cause this flavor of error

outer escarp
marsh crest
edgy jetty
#

Maybe we broke reflecting references?

#

Bisecting this would be helpful, yeah

#

And then we can revert or fix

#

@outer escarp can you please open an issue? Ideally with a minimal repro

#

And then we can fix and add a test

marsh crest
#

Removing the bound does break it

image.png image.png
edgy jetty
outer escarp
edgy jetty
#

@marsh crest are you preparing a fix? I can do a reversion if you're not once I'm done with the #assets-dev fix

marsh crest
edgy jetty
#

Alright, thank you very much

onyx oxide
edgy jetty
#

I fixed the easy problems at least 🙈

torn spindle
#

Maybe it can be simplified further, but at least that makes it compile
edit: simplified it a bit

marsh crest
#

I have found a way for #[derive(Reflect)] to not break on structs with lifetimes, but with the new 'static bound even TypePath wouldn't work, which makes it completely useless.

#

I suspect the right course of action in that case is to just not derive Reflect for those structs in the first place since they aren't usable for reflection anyway

edgy jetty
#

I misread the error mesage that rustc gave me

#

Because I didn't think + use<> was a thing

torn spindle
edgy jetty
#

Mhmm. This must have broken during the 2024 edition upgrade

edgy jetty
outer escarp
# onyx oxide Did this actually work in 0.16? As in, the struct is usable with `Reflect`?

It's a good question, I've not contributed to the hexx crate before. Looking at it more, reflection is an optional feature, and disabling it doesn't seem to break any of the functionality of the crate. In the examples, reflection is used for bevy egui inspection, but never for the structs with the reference. I agree with @marsh crest the fix is either to remove reflect from those structs, or not have that member be a reference.

maiden heath
#

is the release still tentatively happening tomorrow?

edgy jetty
edgy jetty
dry rune
dry rune
dry rune
#

I'm doing one more pass over the release notes to account for the most recent changes and do last minute tweaking / fill in stats + contributors

final zinc
dry rune
#

@edgy jetty @opaque magnet currently the release notes state that feathers has

Decorative elements such as icons for visual enhancement.

To my knowledge theres nothing like this right now, other than the "decorative" nature of the checkbox and radio buttons (which is a stretch and already covered by another bullet point). What is this referring to?

#

If it isn't a part of 0.17 we should cut that line

opaque magnet
#

There are some standard icons in the bsn branch.

#

Like close (x), menu dropdown chevron, etc.

#

Also, it doesn't sound like my writing, I wouldn't use the words "visual enhancement" (I could be wrong, I'd need to look at the blame to be sure.)

dry rune
#

Cool ill cut it for now

#

sounds like content for 0.18

opaque magnet
#

At some point we should discuss how feathers should treat assets. Right now the fonts and shaders are embedded, because we don't want to burden people writing editors to have to copy the feathers assets into their assets folder. But since embedded assets cost ram even if unused, we don't want to embed a large selection of icons in feathers either.

dry rune
#

For the editor itself, it probably makes sense to make them on-disk assets

opaque magnet
dry rune
#

But idk ... perhaps in memory is better for loading times

#

We can experiment with different paradigms. We might need it to be configurable

opaque magnet
#

@dry rune What I (and I guess others) have proposed is that we have an accelerated schedule for 0.18 that primarily focuses on BSN (this is assuming we can get something releasable in a month or two). This doesn't mean no other changes, but it would mean putting off major work on other things (like the desperately neglected asset processing overhaul).

#

The things I'd like to see for 0.18:

  • BSN with basic support for incrementalism (really basic, as in "replace this subtree")
  • Finish the feathers roadmap, including text input
  • There's a bunch of font-related issues/PRs teed up
  • UI transitions and fallible interpolation
  • Un-regress the multi-material mesh drawing in some way
dry rune
opaque magnet
dry rune
#

Given that asset system work is likely bottlenecked on me to a degree, I can definitely say that I'll commit to landing BSN + UI first

onyx oxide
dry rune
#

I've updated the release-0.17.0 branch the outstanding 0.17 items

#

^ a few more tweaks

#

After that all that remains is adding the release stats + contributors, and updating the release date

proud bone
dry rune
#

As a heads up, the generate-release tool we've used for previous releases to generate the contributors list no longer works, as our history has extended past the pagination limit:

Pagination with the page parameter is not supported for large datasets, please use cursor based pagination (after/before)

#

I believe this is fixable by just adding an after to our api call to filter out older stuff

#

working on that now

dry rune
#

I'm guessing these migration guide entries are supposed to be links?

image.png
dry rune
wet thistle
#

Is it considered a bug that ui will not render if bevy_ui_render feature is not enabled? No compliation error or runtime warning is printed either.

dry rune
#

<@&1064695155975803020> I'll merge this tomorrow morning when the release is published

#

Or rather, this morning, as it is 1:27am here

wet thistle
#

Are you open to logging a warning for this?

dry rune
# wet thistle Are you open to logging a warning for this?

The challenge here is that just because bevy_ui_render is disabled doesn't mean that some other render backend isn't trying to render it (this is the main reason we factored that out). We need to distinguish between "no renderer" and "3rd party renderer"

#

(if we want to print a warning)

wet thistle
#

For sure, it's the only thing I noticed as being unexpected and not able to be guided by the compiler in my upgrade from 0.16-> 0.17 so I thought I'd mention it here

dry rune
wet thistle
#

Indeed

#

For improved compile times

dry rune
#

Yeah non-default cargo feature management will continually be breaking and unexpected for people as we add/remove features

#

We need "profiles" or something to help manage the complexity

wet thistle
#

Oh fwiw I think not having the equivalent for sprite caused the ColorMaterial type to not be available but there was no euqivalnt compile time issue for UI, probably just a matter of which types were moved?

dry rune
proud bone
dry rune
wet thistle
#

Thanks for the feature migration advice! I'll let you get back to release work now

fair harness
#

i think we could have a compile warning if bevy_render and bevy_ui are enabled but not bevy_ui_render

dry rune
fair harness
#

it would be a matter of putting a bevy_ui feature on bevy_render and having the bevy_ui feature in bevy_internal enable it with bevy_render?/bevy_ui, then print warning

proud bone
#

that would need to live in bevy_internal...

#

and probably not fun to maintain

fair harness
#

thats not true

#

i personally dont think its worthwhile but if its needed it can be in bevy_render. all it needs is to have bevy_ui feature enable bevy_render?/bevy_ui

dry rune
#

Feels gross no matter where we put it

fair harness
#

yeah

dry rune
#

The alternative is runtime state of some kind. Like a BevyUiBackendPresent resource or something

proud bone
#

we could maybe have a dev tool plugin CheckThePluginsYouHaveMakeSensePlugin 😄

dry rune
#

But thats also gross in that it requires backends to know to set it, and it only exists to print a warning

fair harness
#

alternatively we could have a bevy_custom_renderer feature that disables the warnings globally

#

and just always warn when no ui render but yes ui

#

it kinda sucks

dry rune
#

These all make me sad

fair harness
#

im happy with just calling it pebkac

proud bone
#

my preferred solution is to have the cli/editor handle that in a friendly way, and if you do it manually you're on your own

dry rune
#

Thats something even I have no interest in doing for my projects

fair harness
#

disabling engine features mostly helps clean build time, i think its largely a non issue for most gamedev work. it only becomes relevant for library authors

#

if you're swapping the renderer thats your bag of worms to spill

naive turtle
#

This sounds like something that plugin dependencies could solve, when a plugin has no dependants but has some flag set indicating it needs a consumer of some sort

fair harness
#

we could also just not add the ui plugin in default plugins maybe. just have ui render add it

#

idk if that solves anything tho

#

the components are still usable

final zinc
dry rune
worn current
proud bone
final zinc
#

Sure, will do later

proud bone
static hearth
#

I don't have time to work on it right now, but the migration guide's headings are kinda quirky

#

There are some incorrect headings (like "Opt-Out variant" should be a sub-heading)

image.png
#

And the zstd section has this giant "Migration Guide" H1 sticking out of no where:

image.png
#

I don't think it's blocking, but it would be nice to get fixed before the majority of our release traffic hits the page

maiden heath
final zinc
final zinc
#

Just checked, yep, it’s clustered

#

Bummer

final zinc
#

(nearly wrote "Je suis fini" and then remembered that that's an entirely different thing)

final zinc
#

Working only on native Windows, Linux, and Android is quite the limitation

final zinc
final zinc
proud bone
proud bone
#

(and merged into Cart PR)

grave dove
#

I love the new events architecture, but I'm not a big fan of the new "Message" naming.
It collides with messages in networking 😢

verbal ice
#

should have been called Letter 🙃

acoustic nimbus
#

Notification(?)

grave dove
#

Maybe I just need to get used to it.
"Message" on its own feels natural for a buffered event, but after working on a networking crate my brain associates that name with networking.
I'm not running into any type naming collisions with bevy_replicon, just with variable names 🤔

dull schooner
grave dove
dull schooner
#

Ah, right, so a message would be a combination of packets, got it

opaque magnet
#

Part of the problem, I think, is that we live in an industry in which the need for terminology of finely-differentiated modes of communication and information transfer has outstripped the English vocabulary.

torn spindle
#

I like calling them netmessages / netmsg, or c2s/s2c for a specific direction

dull schooner
#

Just go full java NetworkingCombinedPecketMessage with an associated NetworkingCombinedPacketMessageFactory

ebon kindle
#

my favorite: "bevy_replicon::Message" and "bevy_event::Message" being explicitly written every time 😂

south shell
grave dove
south shell
#

I also may just used to terminology for tools like zeromq or rabbitmq which all work a similar way

grave dove
#

Here is a small snippet of the old naming.

Now I need to rename event(s) -> message(s). But I already have messages, so it becomes client_messages.
When I iterate over messages, the loop variable now message. But it's also occupied. So it becomes bytes.
And things like this across the whole codebase 😢

image.png
#

So nothing critical. Just too many messages 😅

opaque magnet
#

You could always go with something archaic like "missive" or "tidings" 🙂

misty oriole
#

Epistles

dry rune
#

I've started the release process, but I'm missing perms to publish some of the crates. I've reached out to the relevant person, but I've gotta wait until they come online to wrap up

#

The train is back on the rails!

acoustic nimbus
#

What were we missing??

#

Oh wait was it solari, we never created that crate did we

#

Oh nice it does exist now though

dry rune
#

Nah solari was already in a good spot

acoustic nimbus
#

Also all the new rendrering sub-crates

fallow raptor
#

Just finished updating all of taintedcoders.com to 0.17, just waiting for the release. Gonna be the first release I'm right on time 😆

fair harness
#

WOOOOOOOO

ivory nymph
#

Congrats :)

slim lintel
#

nice work yall

grand oyster
#

Congrats on the release! I'm curious why the blog post is not linked in the announcement message?

fair harness
#

to maximize engagement with posts on external sites

slim lintel
#

time for the post 0.17 merge fest to commence

#

it's mergetoberfest

warm crystal
#

we did itttt, congrats everyone incredible work

agile shoal
warm crystal
spiral wren
#

almost actually haha

agile shoal
#

Ah I see

rapid mantle
#

Well done everyone :)
Small nit: The environment maps are in-between the sections of feathers and headless UI which is a bit weird. Also in the highlights it's first headless UI and then feathers while it's the other way around in the post itself

proud bone
#

nightly broke building docs for Bevy 0.17 on docs.rs

warm crystal
fathom shoal
#

also the heading levels are still very much wrong

image.png
#

someone mentioned it earlier already, don't remember where

fathom shoal
night lagoon
proud bone
#

I'll publish a 0.17.1 as soon as it's fixed

night lagoon
#

🤦 find-and-replace not broad enough (those are the ones that mention docsrs_dep)

proud bone
#

I would appreciate an approval 🙂

south shell
proud bone
proud bone
#

so... no docs for us 🙁

#

after fixing those doc_auto_cfg, we have an ICE:

error: internal compiler error: compiler/rustc_middle/src/ty/typeck_results.rs:593:9: node HirId(DefId(0:11 ~ type_data[1e94]::main::Damageable::damage).6) (type `Self::Health`) cannot be placed in TypeckResults with hir_owner DefId(0:8 ~ type_data[1e94]::main)
final zinc
#

or is there a way to tell the docs to exclude a specific example from crawling?

proud bone
final zinc
proud bone
edgy jetty
final zinc
#

We can even just PR it right back lol

#

just needs to be gone for the release

edgy jetty
#

I'm off work today but I can do that

final zinc
#

nope, cannot reproduce

#

blindly remove the example it is, then

#

hold up

#

there's doc-scrape-examples

#

can we just make that false hmm

final zinc
#

no promises

#

but I hope that changing this setting will make cargo rustdoc on their end not compile this example

edgy jetty
final zinc
#

want to try something out locally

edgy jetty
final zinc
# edgy jetty kk

alright, I can verify locally that this change does what I hoped it does 🙂

#

I still cannot reproduce the ICE, but cargo rustdoc doesn't complain when I introduce a syntax error into the file, meaning that the compiler must be ignoring it

#

if any other examples cause an ICE, we can just also disable doc scraping for them

#

ready for merge

edgy jetty
#

Merging

eternal elbow
#

I assume very one is already aware of this, but just in case.

image0.jpg
edgy jetty
#

Probably releasing an immediate 0.17.1 to fix this

dry basalt
proud bone
#

Bevy 0.17.1 published, I'm waiting for the build on docs.rs to pass to make the discord announcement

maiden heath
#

oh the new observe bundle effect is locked behind bevy/experimental_bevy_ui_widgets, was that intentional?

#

I get that its temporary and a non-final api, but it should probably be in the prelude with the amount of people that are going to reach for it

opaque magnet
#

But I agree that the concept is one that is badly needed.

maiden heath
#

yeah, it just seems very separate from the widgets and something everyone is already trying to reach for

#

I can say with confidence that every project I build will use this experimental flag just for observe, but not necessarily for widgets

opaque magnet
maiden heath
opaque magnet
#

Maybe what we should have done is have a separate feature flag for just the observe function.

maiden heath
#

I can tell people to turn on the flag, but I was curious if it was intentionally behind it currently or more of a "this pr went in the day before release" kind of thing

opaque magnet
#

That I was using features of Bundle effects beyond their intended use

maiden heath
#

yeah, I do get that we want a different end API for it, with many/many relations backing it

opaque magnet
#

Essentially, it's a component that inserts nothing () but has a side effect of calling .observe().

maiden heath
#

well maybe it will have the effect of more people using the widgets then

maiden heath
opaque magnet
proud bone
proud bone
#

for those that think the 0.17 improved compile times... building all the examples in wasm on the 0.16 took 15h19m, on the 0.17 1d9h52m

spiral wren
#

that's so much worse that it seems like it's hitting a pathological case or something 😅

grave dove
#

Maybe it's worth turning some of the examples into doc examples?

proud bone
grave dove
#

I thought compiling examples themselves takes a lot of time 🤔

proud bone
#

building less examples is hiding the problem, not fixing it. if we want them faster for the website we can throw more CI at it

#

I hope nobody is building all the wasm-compatible examples twice (webgl2 and webgpu) on their local

spiral wren
#

Was there a significant number of new examples introduced?

proud bone
#

I don't have the exact number, but from pagination, less than 20

#

out of 227

grave dove
proud bone
#

compile time changes over the last few months... (on linux, native, with 8 cores)
the recent decrease was when I updated Rust ❤️
wasm is usually a bit worse, and less cores in CI

Screenshot_2025-10-01_at_14.26.55.png
feral imp
#

Congratulation for everyone involved in 0.17, gl for the future work of 0.18

worn current
final zinc
#

It’s fully intentional that it’s as gated off as possible

#

With the rationale of "things that are not components should never pretend to be components"

#

So even a different implementation wouldn’t have been treated any differently, because observers fundamentally are not components

#

Instead, Cart wants this kind of operation done by BSN, where you can say "spawn this and observe it like that"

#

So the current observe function is just there as a crutch to make the API of the headless widgets / feathers more usable and closer to the 0.18 version for an easier migration

#

It will almost certainly be removed in 0.18

#

^ paraphrasing Cart for all of this

edgy jetty
dry rune
maiden heath
# final zinc With the rationale of "things that are not components should never pretend to be...

to be clear, I was already aware of all of this reasoning before I asked about the feature flag, I was asking because the PR was created and merged at the very last second for the release. I know the observe implementation is not the end-goal api and that it will change. What we've done here is provide the api and make life harder for anyone that is interested in using it... and changing the APIs between 0.17 and 0.18 is a regular, expected occurrence for any api. Are you saying that we're planning to break this API in 0.17.2?

#

I view including observe here (hidden behind the experimental flag and scoped to the widgets work) as a targeted "middle ground" compromise in the interest of not hamstringing the UX of this work while we wait for bsn!.

https://github.com/bevyengine/bevy/pull/21247#pullrequestreview-3282282172

Is the actual reasoning I was looking for if anyone else comes up with the same question.

grave dove
#

Migrating renet, which is a networking crate. It contains the bevy feature.
But it's a bit confusing to have ServerEvent, which is a Message in Bevy.
On the other hand, renaming it to ServerMessage would be even worse 😢

image.png
stoic osprey
#

I use ServerClientMessage/ClientServerMessage

unkempt swan
#

I don't know the specifics of renet, but in all my previous work with client/server authoritative MMOs, usually it is message passing between client and server.

#

So I don't find it strange or weird

final zinc
grave dove
#

But it's not a message from client to server. It's an event that happens on the server when client connects or disconnects.

unkempt swan
#

I see, yeah, IIRC some of them had a distinction between things that was about to happen (Messages) and things that had already happened (Event). So I guess this example fits on the second one, which is kinda weird indeed.

ivory nymph
#

It's another Svendoring Saturday for me 😔

#

cleaning up the bits of my dependency tree that aren't up at 0.17 proper

ivory nymph
#

And all up to date 🫡 though web builds are broken for me, going to try to update my bevy_cli

opaque magnet
#

Trying to do a land-grab on those names is likely to end in tears.

ivory nymph
rapid mantle
ivory nymph
# rapid mantle Which error are you running into? Get random v2 and v3 should work in combinatio... 
error: the wasm*-unknown-unknown targets are not supported by default, you may need to enable the "js" feature. For more information see: https://docs.rs/getrandom/#webassembly-support
   --> /Users/[]/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/getrandom-0.2.16/src/lib.rs:346:9
    |
346 | /         compile_error!("the wasm*-unknown-unknown targets are not supported by \
347 | |                         default, you may need to enable the \"js\" feature. \
348 | |                         For more information see: \
349 | |                         https://docs.rs/getrandom/#webassembly-support");
    | |________________________________________________________________________^

error[E0433]: failed to resolve: use of unresolved module or unlinked crate `imp`
   --> /Users/[]/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/getrandom-0.2.16/src/lib.rs:402:9
    |
402 |         imp::getrandom_inner(dest)?;
    |         ^^^ use of unresolved module or unlinked crate `imp`
    |
    = help: if you wanted to use a crate named `imp`, use `cargo add imp` to add it to your `Cargo.toml`
rapid mantle
rapid mantle
ivory nymph
#

I'm building this with the bevy cli web bundling command, I don't get a snippet (version is alpha.2)

#

ooh, maybe this round it'll actually get through.

rapid mantle
ivory nymph
#

Proprietary, but I've got it to work (some subset of the above had to be specified. Going to narrow down on which.)

rapid mantle
#

Not sure why the CLI didn't provide you with the snippet though

ivory nymph
#

with bevy cli, it was this that got there in the end

[target.'cfg(target_arch = "wasm32")']
dependencies = { getrandom_2  = { version = "0.2", features = ["js"], package = "getrandom"} }
# 
features = {default = ["getrandom:wasm_js"]}
rustflags = ['--cfg', 'getrandom_backend="wasm_js"']

are also sitting about there in my actual toml but I think they're from quite a while ago and removing them didn't impact anything.

#

(for target_arch = wasm32)

rapid mantle
ivory nymph
#

need to lobby for cargo new/init to just always add wasm getrandom workarounds regardless of project 😌

rapid mantle
upbeat arrow
old marlin
#

we should probably call out at the top of the migration guide that there are new *_render features that people using no default features might need to enable.

worn current
dry basalt
#

Is simply "new *_render features have been added, so projects without defaults features may need to enable them" in the bullet points of important stuff good enough? Should we also have a list of these new features? Should it be its own guide that is linked to?

fair harness
#

i thought i already include a guide for this

old marlin
#

The guide is good but the failure mode is that your stuff doesn't render, so it's hard to know what to search. So a bullet point at the top may help

dry basalt
edgy jetty
dry basalt
# edgy jetty There's a huge rendering crate refactoring one

That doesn't outright state that new rendering features have been added, may need to enable them when no default features. Just sort of implies it by mentioning that specific things are under this crate a user may have never seen before (so implies there may be a new feature and crate you hafta import).

#

I guess proper solution is make that migration guide more detailed, and clarify / mention the new features may need to be enabled in the bullet point up top.