fwiw, 2d isn't "abandoned" and there are people thinking about and working on it, including some interesting 2d-specific transform and such features. New feature development is often driven by contributor interest and time, and 3d features tend to have more people interested in upstreaming those contributions at the moment (also pcwalton, which is incredibly productive and responsible for a lot of the "volumetric fog" type features this cycle, is working on 3d rendering features, which means an uptick in 3d compared to other areas) for 2d lighting there are a few different crates that can be used depending on what approach you're looking for. * github.com/jgayfer/bevy_light_2d/ * github.com/443eb9/bevy_incandescent * github.com/goto64/bevy_2d_screen_space_lightmaps * github.com/zaycev/bevy-magic-light-2d (Jarl uses bevy-magic-light-2d -- www.youtube.com/@Jarl-Game-com )

the author left a comment with the correction. it is 1m, not 1km.

thanks for the correction! and glad you're enjoying the videos.

if you cmd+f for "WIP water simulation" on the site you will find it. The code unfortunately is not released yet, so the link is only to the bevy discord thread which has a few gifs and some discussion, but no code. discord.com/channels/691052431525675048/692648638823923732/1258445516300095548

All of the links are on the website, which is linked to from the description. All of the headings match the chapters in the video.

@@chrisbiscardi Thank you :)

I think that is from post processing shader, not something that they actually wanted to show.

not sure. the showcase is the first time bevy_water was working with the reflections, etc so I'd assume there's still a few issues to work out with how the reflections interact with the custom material.

I actually had never uploaded it, but just went and found the directory today github.com/rust-adventure/yt-ratatui-audio-viz/tree/main There's some extra files and whatnot since I was starting to move towards using wgpu iirc, but the core program seen in the video still works. use cargo run.

my understanding is that meshlets as a feature are based around preprocessing large assets. So you can have a really large detailed mesh and process it instead of using displacement maps.

Why? What we’re seeing here is per-object motion blur, not the annoying type of motion blur that is affected by camera movement. I think it actually looks really good.

@@CjqNslXUcM are you looking for the FromRng implementation on Quat? docs.rs/bevy/latest/bevy/math/struct.Quat.html#impl-FromRng-for-Quat

@@chrisbiscardi yes, where is the implementation?

I don't understand the question, I've already linked you to it.

@@chrisbiscardi You have, but when I click on source, the implementation for Distribution<Quat> is missing. I finally found it, it's generated by a macro in the glam crate, but it's not uniform. They need to remove the implementation before someone accidentally uses it.

ah yeah, I see what you mean. Yes the Bevy implementation defers to glam for the actual implementation. There's some additional information in the PR that implemented it around needing to do some more testing: github.com/bevyengine/bevy/pull/12857 I asked in the bevy math channel in the discord if there was ever followup to check the uniformness. How did you determine it wasn't? Would you be open to posting how in the bevy_math channel in the discord?

after doing thisweekinbevy for the entire cycle, and helping out some with the release processes and candidate issues it was reasonably easy for me to figure out when the release was actually going to happen and record a video at the right time.

it depends on your use case and requirements

@@chrisbiscardi Intractive Digital Twin apps Developement

For most basic games absolutely, if you don't mind writing them in code instead of UI/graphs. For advanced cases it depends on how much you depend on specific Unity/Unreal functionality. Bevy is very modular and you can add any missing features on top with very little overhead, but depending on which features you're adding it might end up being a lot of work. You can also use large chunks of bevy (ecs, color, ...) without using the whole engine suite if you're rolling your own engine from scratch.

TIL! Thanks for the info. The audio working group channel confirms this is the case (current audio doc includes this comment as well hackmd.io/@solarliner/bevy-audio-v2 for anyone else interested)

@@chrisbiscardi Hi! That is correct, we're switching to making a custom audio engine for various reasons (as listed in the above design docs you liked), hopefully it is the correct choice and means easier time implementing new audio features, better user-facing API, and more stable especially in WASM.

@@SolarLiner looking forward to seeing audio take shape as this progresses!

There will be no editor until 1.0.0 version. Also, if you need editor then this is not for you. What I like the most about Bevy is that it gives me opportunity to make my own dev tooling that I need with eGUI. and having game + editor panels is nice dx.

​@@RootsterAnonIt's the other way around actually. There will be no 1.0 without an editor. This release lays a lot of technical groundwork for the editor and more will follow (most notably a new Scene format and the Bevy Remote Protocol). Several people have started prototyping stuff for the editor. It just takes time for everything to come together.

@@paulkupper194 I don't want them to focus on editor, I want them to progress with features and new scene format as you mentioned etc. Editor you can have in few different flavors if you want like custom one, blender, etc. lets wait for all of the features to be in presentable state then official editor can emerge if really needed. I would like API to be more stable so we can migrate easy from version to version, docs to be up to date with latest api changes and good examples. Editor can wait. :D

@@RootsterAnon 1. You're very selfish, you're thinking about what you want not what Bevy needs, but for Bevy to be taken seriously, it needs an editor that you like it or not. 2. An editor written in Bevy is the perfect tool for dog fooding, just like Godot does.

@@francois199 That is just reality of the situation we are in. You can't have editor without stable api. It's that simple.

MIJOCRAFT MENCIONADO‼️‼️✔️☠️🗣🤙🤙

having even a temporary name is very helpful when making these videos, it gives something to "attach" explanations and future updates to.

Keep at it! Once you get comfortable with Rust writing it is an absolute joy!

I'm very happy to have played some small part in your journey and comments like this make the work that goes into these videos worth it for me.

@@theninjascientist689I want to be at that place where Rust is a joy. It’s hard if you come from Python “and” don’t have a C/C++ background. The concepts click, but all the fancy annotations and rules (it’s like learning a language that has a different alphabet). Still, I return to trying when between deadlines.

things like nil existing, type assertions and erroring handling, panics occurring from those things and using panics as control flow, etc. defer bugs like when closing files require additional external documentation to use correctly (ex: go.dev/blog/defer-panic-and-recover )

bevy's asset system supports hot-reloading. If you're changing asset-type things like .blend files then hot-reload should work, if you're changing Rust code you have to do an incremental compile.