Observers, hooks, and event handling aren't that different. All of them effectively process event data. EventReader systems can be better for parallelized event processing, but have to wait to read events until the time at which the system runs in the frame to pull events in, which can lead to processing events next frame instead of this frame depending on ordering. As a contrast, Observers and hooks will process an event "on-demand" much sooner. So if you want to guarantee a low-traffic event is processed this frame Observers work for that, or if you want to uphold an invariant (like adding an entity to an index) Hooks run even before Observers and are lighter-weight since they don't respond to user-created events (only component add, insert, remove). Observers are new as of a week or two ago in the 0.14 release, so you'll see me using them and hooks a bit more because of that as well.
I have no idea why you decided to use the observer pattern instead of events with event readers/writers, bit silly if you ask me... none the less, wonderful video, thank you for putting up some bevy content !!!!!
granted I'm super new with bevy and this could be the proper way todo it. Just seems like you were trying to conform it to the trigger/observer stuff when it would've been a better match to an event with a listener
Sorry but I had to start laughing so hard at around 8:00. Imagine someone who is not into computer science trying to decipher what you are saying. And crate rayon is just the cherry on top.
On the one hand it's so cool to see this engine getting all the fancy 3d features and fireworks like god rays, volumetric fog but on the other hand you have 2d which again was abandoned and doesn't even have the most basic 2d lighting, not to mention some normal maps or something :/
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 )
Dude, why are you just making transitions between the code. I'm new to RUST and how should I understand why I don't have Gradient::new defined. Why haven't you ever shown me where the hell it's imported from? if you show it, then show the full code and import dependencies.
Thank you for showcasing my ongoing project and all the efforts you put in creating those videos. You're even looking for info in threads, and that must take a lot of time! Small mistake in the video: the red cube is one meter on a side, not one kilometer.
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
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.
Nanite team also made a custom rasteriser- basically, gpu rasteriser suffers on small triangles, so they wrote a software rasteriser that works on triangles that are smaller than 25*25 pixels or so. It whould be such a cherry on top
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.
@@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.
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.
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.
Yes TY for this series. I’m really struggling with Rust for embedded (work) purposes, but it’s so cool to see that Rust is doing some great stuff for games (play). Cheers
Man, I stumbled over this. This technique is awesome, allows one to edge host cheaply without paying for a database server. I am gonna note that down. Have there been any new developments? What do you think about technologies like libsql?
1:44 really nice seeing my game here. i never got any recognition for my projects, so i'm really thankful for showing it here. btw, mijocraft is a temporary name because i haven't thought of a better name yet, lol.
Thanks so much for making this series each week. I'm a computational physics/(control systems) engineering guy (so lots of C++ and a Python) and decided to learn Rust. Unlike a sane person, I decided my first Rust project should be a port of some of my visualisation software that runs too slowly in Python+matplotlib+Cairo. It's been a steep learning curve, but this series has helped me fall in love with Bevy and motivated me to stay on that learning curve. Mathematics in my head is very visual and geometric (even abstract algebra). I feel like a world is opening up for me to let others view the world as I see it in my head, and that is truly exciting 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 )
