Nanite does a bit more than "just" LOD it is basically a live preprocessor to cut down the geometry before it is send to render on the GPU. It's purpose is to throw away every mesh that's to small to rasterize and replace it with a texture equivalent. You won't believe the amount of garbage data that's send to GPUs that never makes it into the final image on a display. Nanite reduces a whole chunk of that. So that available resources can do work that matters.
For anyone put off by the ugly boilerplate in Unity's ECS/DOTS framework, Bevy offers a much cleaner implementation which feels at home in Rust. CPUs are generally the bottleneck in more simulation geared games so this could be the next big thing.
bevy was my first introduction to game development. i enjoyed using it, but i want to wait for webgpu to be supported in more browsers. then i can build games with bevy and compile them to wasm to be played in the browser.
@@thegoldenatlas753 i think it could be much bigger than that. peak potential is having triple a games in the browser. truly cross platform games. doom 3 has already been ported to the browser with wasm and webgpu will make it possible for new games.
There are a decent number of steam games written in Rust at this point. Also, many of these are alpha/beta type projects and don't claim they should be used for large projects because they're unstable.
Rust is only 9 years old for 1.0 release. That means the engines are even younger. That means it leaves even less time for the actual game. And just because it is written in Rust it does not mean that the competition Unreal, Unity and Godo does not exist. So actual game designers will stick with them. But of course your "famous progaymmor" knew all this. -.-
Bevy isn't a flagship product of a corporation, nor is it remotely as old and mature as the big boys. It doesn't even have an editor. Don't beat a toddler.
It's crazy how good Bevy 3D graphics are when comparing to something like Godot which had much more time to mature... makes you wonder if it's just lack of expertise when developing Godot.
@@autismspirit This was made as an api for programmers to use. Being forced to use an editor doesn’t give you full control. There are many game frameworks like this.
I tried bevy about 1.5 years ago. As much as I loved it and as much as I like rust, the issue is the ecosystem, both for bevy and rust. I kept running into "issues" for which no solution existed yet, in other words, there were no crates (library) available yet for some very basic stuff. Where other game engines/frameworks/languages have multiple different libraries/plugins to choose from, there was nothing available here. So many things have to be written from scratch. Small features which you think is 30 minutes of work suddenly turns into 2 weeks of work. It makes you realize how much work went into other game engines and languages. It is so extremely time consuming to work on projects when the ecosystem is literally decades behind.
PCF is indeed a little harder to spot, but it becomes more apparent as you decrease the shadow map resolution. PCF is sort of like a blur for shadows (since you can't just blur the shadow map texture with gaussian blur), and its effects are more pronounced as the shadow resolution becomes lower. Agree on the SMAA, can't see that at all.
@@RenderingUseri think it can do most of them tho they dont have per object motinblur still to my knowledge so u can’t have montion blur in godot that doesn’t suck
The description for PCF is, "Percentage-closer filtering is a standard anti-aliasing technique used to get softer, less jagged shadows," and it applies just to point lights. From what I read, it's basically a very slight Gaussian blur to point light shadow edges. It's likely being used as a very performant and effective alternative to anti-aliasing. Speaking of anti-aliasing, I'm so happy to see SMAA making a comeback! MSAA and SMAA are the best! FXAA and its successor, TAA, just make everything a blurry, indistinct smear, like a thin coat of Vaseline was applied to the camera lens. Also, I would love for Intel to open source their original version of CMAA. Back in the day, it produced a great image while also being incredibly performant.
FXAA is to me a better implementation of MLAA than original SMAA, i would argue; if it's too blurry just tune fxaaQualitySubpix down and other parameters. And TAA has nothing to do with FXAA and MLAA at all. Intel's CMAA2 is quite nice btw.
@@HickoryDickory86 TAA is accumulation antialiasing, where the TTA controller injects a differing subpixel offset into rendering of each frame to reveal sub-pixel details over the course of several frames and then averages these several frames to provide true anti-aliasing, while trying to keep ghosting to a minimum by forward-correcting prior frames using motion vectors. Basically distorting the old picture to align with the new one, and then averaging them out. It doesn't have to turn out blurry, but due to issues in frame to frame coherence of the underlying renderer and numeric precision issues, usually ends up being blurry. Say in practice, it doesn't actually add a limited number of frames together, but maintains a rolling decay buffer, which accumulates long term error which imprints as blur, so any imprecision in forward projecting prior frames lingers for ages. Fundamentally the forward projection has a large error, since it's effectively snapped to the pixel grid, does not maintain subpixel accuracy. This is also what FSR2 does better, since it can do the forward projection at a higher resolution, but there's also a lot more other trickery, one could write a book about these things. FXAA is a form of morphological anti-aliasing which works on a single image with no further information. MLAA starts off the observation that if you have a fully aliased rendering of a black half-space adjoining a white half-space, and compare it with a fully anti-aliased one, you find that you can accurately reconstruct the grey-tones just from the stair stepping pattern of the aliased picture. Namely you can do this by a directional blur filter and apply such a blur filter vaguely perpendicular the edge direction, with filter parameters that depend on slope computed from the stair step pitch. The algorithm is further augmented with detection of features that need to be processed, to make it work on something that isn't a pure monochrome picture. As such it ends up blurring all high-frequency detail in a real picture, because the picture really doesn't look like the algorithm-underlying observation. Since morphological anti-aliasing does not have access to any sub-pixel information, it is not a true anti-aliasing algorithm. I'm very sorry, describing image processing algorithms in text without pictures is really really difficult. But in case of morphological algorithms, Intel Developer website on CMAA and CMAA2 should be helpful. Some morphological algorithms take into account say depth buffer or other intermediate image buffers to reject a bunch of pixels that would otherwise be blurred and keep them sharp. But this runs into the issue that many shaders produce internal aliasing that gets missed. Also you know what, i am now seeing that SMAA was much nicer than i remembered. But in the form where it can shine, it was also a substantial performance hog for the time. FXAA solved the performance problem and then it just stuck as the default implementation, because you can mindlessly throw it on things. All of these MLAA variants have their own detail issues.
Thanks for the video! I was under the impression that the primary purpose of meshlets in Bevy 0.14 is to improve the efficiency and performance of rendering detailed geometry by breaking down complex meshes into smaller, manageable pieces. This way, it can handle more detailed scenes more effectively. However, you mentioned it's primarily for downscaling images and geometry. Could you clarify if meshlets are intended more for optimizing high-resolution models for performance rather than just downscaling them?
It is for optimizing high-resolution models for performance by dynamically down-scaling them, as needed. It is very inefficient to render triangles that draw just a couple of pixels in the screen, or any at all.
@@Rodrigo-xf2oe Thanks. I'm trying to deepen my understanding of these concepts (and my understanding of moden graphics pipelines is very elementary). My current understanding is that the key design principle behind meshlets is to more efficiently handle large detailed meshes. By being able to address sub meshes of a much larger mesh you have opportunities to more efficiently work with them in a pipeline, including but not limited to improvements in how you do level of detail. Other efficiencies gained with using meshlets could also include the way the geometry information is batched, culled, streamed / moved to and from host and GPU memory etc. So my primary comment wasn't that LOD or 'down-scaling' isn't important, just that it wasn't the only (or even primary) motivation for introducing them into Bevy.
Anyone know how it is to do quick prototyping in Rust/Bevy, i.e. hack together something without a care for code quality or bugs? I'm curious how the borrow checker and Rust's whole soundness approach affects these kinds of things.
in my experience doign exactly this with Bevy it works well. the ECS abstracts a lot kf borrow checker woes away from you, which is very useful. Other than that, you can easily just spawn a bunch of entities and go ham with 1 big mega function even though that's not intended/ideal. Nannou, a creative coding framework in Rust is also switching to being based on bevy.
@@thegoldenatlas753 I personally agree, but probably not everyone is looking for that, I think a lot of people prefer a "batteries included" engine. To me, it's the best engine right now.
@@lolligerjoj1 Yea? I didn't say bevy *wouldn't* have stuff, like rn there's talks to upstream a popular UI crate that was made for bevy. Alot of this 0.14 update render changes are upstreamed from tiny glade. Etc etc.
The problem with making game engines (intended for production quality projects), is that it's just such a titanic task to make and it takes decades (literally) for user adoption curves to inflect. It's great watching the development process but at this point in 2024 it only garners "That's nice honey". I just don't think it's the 2010s anymore and self made game engines aren't as impressive anymore given it will be eons before they are ready for anything and AI lurking around the corner.
is this so? i wouldn't be so sure. From what i can tell a organized project like bevy is capable of catching up, by which i mean implementing things faster than the older/bigger engines can add more features. Onba high level, this is mostly due to lessons learned and a fresh implementation being cleaner due to it. And bevy is not just 1 persons side project anymore, theres 2 fulltime jobs, many Subject Matter Expert roles, and many more people contributing the features they need.
@@laundmo bevy is awesome. But again it's dwarfed by big boy game engines. Even Godot (the arguably most promising underdog) took 10 years to get to where it is.
From devs that work on editor( a comment on bevy discord) :" A basic (but official) running prototype within the next four to five months seems likely. But I wouldn't put money on it. " Basically it's hard to say when exactly ...
@@samuelhulme8347 I'm talking about UI to use in the game. For example, libGDX has it. Bevy only has the bare minimum, making anything more than a bunch of buttons with it is quite tedious
@@SomeRedTeapot new UI stuff is being upstreamed from a crate that's popular with users, editor work is waiting on the bevy remote protocol and reflection In meantime people are building editor prototypes to flesh out current needs
Following the development more closely (as in actually reading github discussions etc.) its very clear that a lot is being done towards better UI. Bevy always does a new release every 4 months with whatever is ready and it just happened to align so that UI things will be in next release most likely
Honestly TH-cam stats have always been off, but lately they've been just useless. Often for the first 5 or so minutes I often get 0 analytics data at all... no clicks (but I do gets likes and comments). Makes it very hard to make early judgement calls about thumbnails, titles, etc. But yeah, don't put any stock in the views of a video for the first 24 hours, it's always off. I don't think I would compare it to SDL or SFML, it's a layer of abstraction higher than that. NotGate's LibGDX is a pretty good analogy. ORX is another, as is The Forge.
@@notgate2624 Oh I see. Thanks for taking time to correct my conjecture. I'm very new to computer science and game stuff so I don't know what libGDX is but I'll read up on it. My idea of a game engine, at least so far, is a kind of super same where you can swap out assets/mod it to produce a new game. At a glance, to me, Bevy doesn't quite fit the bill but then again, what I'd classify as "Monolith" engines like unity have pretty much messed up my perception. More research for me, lol. It's a goal of mine to produce one of those some day no matter how useless.
@@gamefromscratch Well, I understand that much. The x views in y minutes is a recurring joke in the youtube community 😅. I don't think most people believe it since me of all people understands the idea. So when you say it's a layer of abstraction higher than that, does that pretty much mean that it might use something like sfml/sdl in the code except it's more organized for the purposes of aspiring game devs? or something along those lines??
@@FengWan-v8y why would you not call it a game engine? An editor is just an interface that interacts with the game engine. Scripting is just another type of “interface” that can interact with the engine. Look at Minecraft, they use a custom engine (based on LWJGL) and it doesn’t have an editor.
@@thegoldenatlas753If you have a small single threaded game, Rust is going to be cpu bottleneck very fast because of amount of cpu instruction rustc generates, C is basically macroses for assembly, lightweight, no compiler guards and fast
@@thegoldenatlas753 you don't get the point, I'm not talking about speed. Rust is known for making big binaries, there are more instructions compared to gcc, it's because of 'bloated' optimizations compiler inserts in final executable, it makes cpu bottleneck. Speed always comes at a cost.
@@samuelhulme8347 This is untrue, because bevy does want to be a full fledged game engine. It is not on it's 1.0 yet so chill out, and their plan is for the editor to be optional.
That's a non-argument. Rust is still young and as in any other industry there's massive inertia when it comes to commonly used programming languages. Being able to choose a language purely on its merits is a rare luxury.
Chill motion blur can be good if it per object instead of camera, on nanite well a poop igpu could handle billions of polygons with it at 20fps, so it not so bad .
@@NapkinKing FOSS would be better if there wasn't 30000000 "options" for a program, and instead there was atleast 1 that didn't suck. everyone wants to feel super special and make up their own thing, and then demand donations and get salty when no one pays money for something that only has half the features anyone could need. same thing with kdenlive. anyone who worked on kdenlive is a moron who wasted thousands of hours for literally nothing. their life was wasted for 0 benefit to anyone.
*Links*
gamefromscratch.com/rust-powered-bevy-game-engine-release-0-14/
-----------------------------------------------------------------------------------------------------------
*Support* : www.patreon.com/gamefromscratch
*GameDev News* : gamefromscratch.com
*GameDev Tutorials* : devga.me
*Discord* : discord.com/invite/R7tUVbD
*Twitter* : twitter.com/gamefromscratch
-----------------------------------------------------------------------------------------------------------
Nanite does a bit more than "just" LOD it is basically a live preprocessor to cut down the geometry before it is send to render on the GPU.
It's purpose is to throw away every mesh that's to small to rasterize and replace it with a texture equivalent.
You won't believe the amount of garbage data that's send to GPUs that never makes it into the final image on a display.
Nanite reduces a whole chunk of that. So that available resources can do work that matters.
@@dotcom4389nanite has improved a lot for foliage since 5.2
@@dotcom4389 I heard they made it work with foliage
For anyone put off by the ugly boilerplate in Unity's ECS/DOTS framework, Bevy offers a much cleaner implementation which feels at home in Rust. CPUs are generally the bottleneck in more simulation geared games so this could be the next big thing.
Tbf unity is making an abstraction to ecs while bevy is *just* ecs
So bevy has had alot better design decisions available.
just ECS. Yeah sure buddy.
Nice graphics capabilities and stable physics now we only need a nice editor
Ive done alot of talking in the editor dev channel and things have finally kicked into gear it seems
Yeah, once bevy gets a good enough editor I might go and do a project with it.
For now I'll stick with c++ and unreal
bevy was my first introduction to game development. i enjoyed using it, but i want to wait for webgpu to be supported in more browsers. then i can build games with bevy and compile them to wasm to be played in the browser.
@@crab-cake i gueess webgpu will be the new flash games lol
@@thegoldenatlas753 i think it could be much bigger than that. peak potential is having triple a games in the browser. truly cross platform games. doom 3 has already been ported to the browser with wasm and webgpu will make it possible for new games.
Bevy can build to WebGL and run in browsers with WebGPU support
its gonna blow up soon
Bevy won’t “blow up” until it has hit 1.0
To quote a famous programmer: There are currently 5 games written in Rust and 50 game engines...
There are a decent number of steam games written in Rust at this point. Also, many of these are alpha/beta type projects and don't claim they should be used for large projects because they're unstable.
People who are programming in Rust are more likely to care about the systems than the games. Also, only two engines, chill.
@@techpriest4787 And you are teaching "Famous Programmer". lol.
Rust is only 9 years old for 1.0 release. That means the engines are even younger. That means it leaves even less time for the actual game. And just because it is written in Rust it does not mean that the competition Unreal, Unity and Godo does not exist. So actual game designers will stick with them. But of course your "famous progaymmor" knew all this. -.-
Bevy isn't a flagship product of a corporation, nor is it remotely as old and mature as the big boys. It doesn't even have an editor. Don't beat a toddler.
It's crazy how good Bevy 3D graphics are when comparing to something like Godot which had much more time to mature... makes you wonder if it's just lack of expertise when developing Godot.
They're focusing on advanced flashy features to get users instead of adding basic functionality, such as an editor.
@@autismspirit OK, but that still doesn't explain how can Godot still have such poor 3d graphics in general.
@@autismspirit an editor is not really *that* basic. You need functionality before having UIs to use them.
@@autismspirit This was made as an api for programmers to use. Being forced to use an editor doesn’t give you full control. There are many game frameworks like this.
@@beetledjuice3062 A rudimentary GUI is way easier than virtualized geometry, for example.
I tried bevy about 1.5 years ago. As much as I loved it and as much as I like rust, the issue is the ecosystem, both for bevy and rust. I kept running into "issues" for which no solution existed yet, in other words, there were no crates (library) available yet for some very basic stuff. Where other game engines/frameworks/languages have multiple different libraries/plugins to choose from, there was nothing available here. So many things have to be written from scratch. Small features which you think is 30 minutes of work suddenly turns into 2 weeks of work. It makes you realize how much work went into other game engines and languages. It is so extremely time consuming to work on projects when the ecosystem is literally decades behind.
about the same kind of thing you'll experience using any non game engine framework
I mean now things are pretty well developed.
Curious what things you couldn't do now.
1.5 years ago is a LOOONG time ago. I tried it this month and the ecosystem met all my needs.
@@askeladden450 true. Rust ecosystem is evolving at a really rapid rate. Even an experience from 6 months ago isn't relevant anymore.
That's the case with any non-mainstream games language, gamedev it's very tied to C++
PCF is indeed a little harder to spot, but it becomes more apparent as you decrease the shadow map resolution. PCF is sort of like a blur for shadows (since you can't just blur the shadow map texture with gaussian blur), and its effects are more pronounced as the shadow resolution becomes lower. Agree on the SMAA, can't see that at all.
these effects are soo much better than the ones in Godot...
really?
pretty sure you could achieve most of that stuff in godot. other than the motion blur. idk how to do that one
@@RenderingUseri think it can do most of them tho they dont have per object motinblur still to my knowledge so u can’t have montion blur in godot that doesn’t suck
Yeah, I agree.
It's such a letdown when you consider how many years Godot has been in development...
The description for PCF is, "Percentage-closer filtering is a standard anti-aliasing technique used to get softer, less jagged shadows," and it applies just to point lights.
From what I read, it's basically a very slight Gaussian blur to point light shadow edges. It's likely being used as a very performant and effective alternative to anti-aliasing.
Speaking of anti-aliasing, I'm so happy to see SMAA making a comeback! MSAA and SMAA are the best! FXAA and its successor, TAA, just make everything a blurry, indistinct smear, like a thin coat of Vaseline was applied to the camera lens.
Also, I would love for Intel to open source their original version of CMAA. Back in the day, it produced a great image while also being incredibly performant.
FXAA is to me a better implementation of MLAA than original SMAA, i would argue; if it's too blurry just tune fxaaQualitySubpix down and other parameters. And TAA has nothing to do with FXAA and MLAA at all.
Intel's CMAA2 is quite nice btw.
@@SianaGearz Is TAA not a direct successor/offshoot of FXAA, or am I misremembering?
@@HickoryDickory86 TAA is accumulation antialiasing, where the TTA controller injects a differing subpixel offset into rendering of each frame to reveal sub-pixel details over the course of several frames and then averages these several frames to provide true anti-aliasing, while trying to keep ghosting to a minimum by forward-correcting prior frames using motion vectors. Basically distorting the old picture to align with the new one, and then averaging them out. It doesn't have to turn out blurry, but due to issues in frame to frame coherence of the underlying renderer and numeric precision issues, usually ends up being blurry. Say in practice, it doesn't actually add a limited number of frames together, but maintains a rolling decay buffer, which accumulates long term error which imprints as blur, so any imprecision in forward projecting prior frames lingers for ages. Fundamentally the forward projection has a large error, since it's effectively snapped to the pixel grid, does not maintain subpixel accuracy. This is also what FSR2 does better, since it can do the forward projection at a higher resolution, but there's also a lot more other trickery, one could write a book about these things.
FXAA is a form of morphological anti-aliasing which works on a single image with no further information. MLAA starts off the observation that if you have a fully aliased rendering of a black half-space adjoining a white half-space, and compare it with a fully anti-aliased one, you find that you can accurately reconstruct the grey-tones just from the stair stepping pattern of the aliased picture. Namely you can do this by a directional blur filter and apply such a blur filter vaguely perpendicular the edge direction, with filter parameters that depend on slope computed from the stair step pitch. The algorithm is further augmented with detection of features that need to be processed, to make it work on something that isn't a pure monochrome picture. As such it ends up blurring all high-frequency detail in a real picture, because the picture really doesn't look like the algorithm-underlying observation. Since morphological anti-aliasing does not have access to any sub-pixel information, it is not a true anti-aliasing algorithm.
I'm very sorry, describing image processing algorithms in text without pictures is really really difficult. But in case of morphological algorithms, Intel Developer website on CMAA and CMAA2 should be helpful.
Some morphological algorithms take into account say depth buffer or other intermediate image buffers to reject a bunch of pixels that would otherwise be blurred and keep them sharp. But this runs into the issue that many shaders produce internal aliasing that gets missed.
Also you know what, i am now seeing that SMAA was much nicer than i remembered. But in the form where it can shine, it was also a substantial performance hog for the time. FXAA solved the performance problem and then it just stuck as the default implementation, because you can mindlessly throw it on things. All of these MLAA variants have their own detail issues.
CMAA2 is open source under Apache 2.0 license? Or maybe you meant specifically CMAA 1?
@@kai-.-man I had no idea! Thanks for telling me! Now I wish Bevy would roll CMAA 2 into their engine.
Man, I cannot shove enough rust into my face, I don't know if its healthy, but I love it. If its wrong, I don't want to be right.
Bevy needs a gui
that _is_ on the todo list before version 1.0 release
ill start properly using it in production then.
For now there is a tool to make blender into a game editor for bevy
@@thegoldenatlas753 so thats what aarthificial is using
@@RenderingUser i think so, there's several options available rn
This was made as an api for programmers to use. Being forced to use an editor doesn’t give you full control. There are many game frameworks like this.
that's quite the beefy laptop you got there lol nice
Honestly I was thinking that was more imoressive than the game engine itsrlf
Bevy is awesome and 0.14 is fantastic, can't wait for more! Thanks for making the video covering this.
Notice the shadow in PCF filtering example !? It make shadow edge blur, something like anti-aliasing
@9:44 Mike, look at the shadows!
edit: Ok, never mind. You noticed it.
the PCF filtering mostly affects the shadows
Graphics are more mature, and it may take longer for Bevy to develop more on UI and ECS
9:50 The difference in the PCF filtering is in the shadows
Thanks for the video! I was under the impression that the primary purpose of meshlets in Bevy 0.14 is to improve the efficiency and performance of rendering detailed geometry by breaking down complex meshes into smaller, manageable pieces. This way, it can handle more detailed scenes more effectively. However, you mentioned it's primarily for downscaling images and geometry. Could you clarify if meshlets are intended more for optimizing high-resolution models for performance rather than just downscaling them?
It is for optimizing high-resolution models for performance by dynamically down-scaling them, as needed. It is very inefficient to render triangles that draw just a couple of pixels in the screen, or any at all.
@@Rodrigo-xf2oe Thanks. I'm trying to deepen my understanding of these concepts (and my understanding of moden graphics pipelines is very elementary). My current understanding is that the key design principle behind meshlets is to more efficiently handle large detailed meshes. By being able to address sub meshes of a much larger mesh you have opportunities to more efficiently work with them in a pipeline, including but not limited to improvements in how you do level of detail. Other efficiencies gained with using meshlets could also include the way the geometry information is batched, culled, streamed / moved to and from host and GPU memory etc.
So my primary comment wasn't that LOD or 'down-scaling' isn't important, just that it wasn't the only (or even primary) motivation for introducing them into Bevy.
thankyou for this quick informational video
Are you running a Clevo X370, or a Variant? My Origin Eon-17X v2 has the same processor video card combo.
This engine finna be insane
Anyone know how it is to do quick prototyping in Rust/Bevy, i.e. hack together something without a care for code quality or bugs? I'm curious how the borrow checker and Rust's whole soundness approach affects these kinds of things.
in my experience doign exactly this with Bevy it works well. the ECS abstracts a lot kf borrow checker woes away from you, which is very useful. Other than that, you can easily just spawn a bunch of entities and go ham with 1 big mega function even though that's not intended/ideal. Nannou, a creative coding framework in Rust is also switching to being based on bevy.
@gamefromscratch Tauri 2.0 RC is out
4090 i9-13900HX
unfair i want one :
Bevy is like the Godot for programmers (if you know you know).
@@jamad-y7m but it isn't rust enough for rust programmers
9:36 looks like light scattering on the surface.
You need to update that rig asap 🙂
Benchmark generator
Bessie Causeway
👍
To me this release feels like they slowed bit down. Not the rendering side but on ECS evolution side and editor direction.
0.14 is the biggest release yet though, and things are expected to iincrease with 0.15
Is there any game demo using bevy?
@@moonskined Tiny Glade but they have their own renderer they use, they have upstreamed some of their work back to bevy tho.
the most high profile one is called tiny glade. Though as far as I know they do use a lot of custom solutions on top of bevy.
@@lolligerjoj1 Tbf that's a selling point of bevy, its modularity and ability to be customized is big focus.
@@thegoldenatlas753 I personally agree, but probably not everyone is looking for that, I think a lot of people prefer a "batteries included" engine.
To me, it's the best engine right now.
@@lolligerjoj1 Yea? I didn't say bevy *wouldn't* have stuff, like rn there's talks to upstream a popular UI crate that was made for bevy. Alot of this 0.14 update render changes are upstreamed from tiny glade. Etc etc.
Lol update your Nvdidia drivers
No occlusion culling?
??
As far as I get from googling there is occlusion culling in bevy, but it's bugged 😕
Nice
Am here
is possible make review imperial game engine 2 engine? is developer
The problem with making game engines (intended for production quality projects), is that it's just such a titanic task to make and it takes decades (literally) for user adoption curves to inflect. It's great watching the development process but at this point in 2024 it only garners "That's nice honey". I just don't think it's the 2010s anymore and self made game engines aren't as impressive anymore given it will be eons before they are ready for anything and AI lurking around the corner.
is this so? i wouldn't be so sure. From what i can tell a organized project like bevy is capable of catching up, by which i mean implementing things faster than the older/bigger engines can add more features. Onba high level, this is mostly due to lessons learned and a fresh implementation being cleaner due to it.
And bevy is not just 1 persons side project anymore, theres 2 fulltime jobs, many Subject Matter Expert roles, and many more people contributing the features they need.
@@laundmo bevy is awesome. But again it's dwarfed by big boy game engines. Even Godot (the arguably most promising underdog) took 10 years to get to where it is.
Thank you for what you're doing 🙏
Nice laptop :)
My one is couple of tiers below :12700h and 3070ti, 64gb ram.
Never used rust. Shame this engine isn't for C!
@@MikAlexander its made for Rust because Rust is better than C.
@@thegoldenatlas753 Rust is rusty, C is citrus fresh ;P
@@thegoldenatlas753Rust definitely isn't better than C
@@thegoldenatlas753 absolutely not lol, not for games at least
@@aamorous why
Arvid Drives
rtx4090 huh?
No editor... :/
its fine
you have external editors
sometimes that can be even better
take LDtk for example
This was made as an api for programmers to use. Being forced to use an editor doesn’t give you full control. There are many game frameworks like this.
Rust's type system is adequate to give you the expressiveness of an editor with the level of control you get from code
From devs that work on editor( a comment on bevy discord) :" A basic (but official) running prototype within the next four to five months seems likely. But I wouldn't put money on it. " Basically it's hard to say when exactly ...
Hold on, now the rusty bevy missioners will show how you don't ever need an editor. And just looking into sacred rust code should be enough for you.
how can bro not know what anti aliasing is 😭😭😭
Does it have editor?
They are literally doing everything but the UI, kek
Say that to Three JS, there are many game engines made to be a programming api for programmers to use.
@@samuelhulme8347 I'm talking about UI to use in the game. For example, libGDX has it. Bevy only has the bare minimum, making anything more than a bunch of buttons with it is quite tedious
@@SomeRedTeapot new UI stuff is being upstreamed from a crate that's popular with users, editor work is waiting on the bevy remote protocol and reflection
In meantime people are building editor prototypes to flesh out current needs
@@thegoldenatlas753 That's good to know, thanks!
Following the development more closely (as in actually reading github discussions etc.) its very clear that a lot is being done towards better UI. Bevy always does a new release every 4 months with whatever is ready and it just happened to align so that UI things will be in next release most likely
Rust build times make it inappropriate for game development
@@ar_xiv you've never actually compiled a rust project have you?
i get, with some setup, sub-second iterative compile times.
i'm perfectly happy with 0.8 seconds.
2 views in 1 minute? You fell off bro. Anyway, is Bevy pretty much rust SDL/SFML?
No, you can use SDL or SFML in Rust just fine. Bevy is a full engine (like libGDX) with a focus on ECS for the architecture.
Honestly TH-cam stats have always been off, but lately they've been just useless. Often for the first 5 or so minutes I often get 0 analytics data at all... no clicks (but I do gets likes and comments). Makes it very hard to make early judgement calls about thumbnails, titles, etc. But yeah, don't put any stock in the views of a video for the first 24 hours, it's always off.
I don't think I would compare it to SDL or SFML, it's a layer of abstraction higher than that. NotGate's LibGDX is a pretty good analogy. ORX is another, as is The Forge.
@@notgate2624 Oh I see. Thanks for taking time to correct my conjecture. I'm very new to computer science and game stuff so I don't know what libGDX is but I'll read up on it.
My idea of a game engine, at least so far, is a kind of super same where you can swap out assets/mod it to produce a new game. At a glance, to me, Bevy doesn't quite fit the bill but then again, what I'd classify as "Monolith" engines like unity have pretty much messed up my perception. More research for me, lol. It's a goal of mine to produce one of those some day no matter how useless.
@@gamefromscratch Well, I understand that much. The x views in y minutes is a recurring joke in the youtube community 😅. I don't think most people believe it since me of all people understands the idea.
So when you say it's a layer of abstraction higher than that, does that pretty much mean that it might use something like sfml/sdl in the code except it's more organized for the purposes of aspiring game devs? or something along those lines??
Nobody's gonna use half baked renderer without decent gui as a game engine. The same case as wicked engine.
This was made as an api for programmers to use. Being forced to use an editor doesn’t give you full control. There are many game frameworks like this.
@@samuelhulme8347 i mean, they are working on an editor now so that's not entirely true. they said it should be ready in 4-5 months.
@@samuelhulme8347 sure, I wouldn't call it game engine though
@@FengWan-v8y why would you not call it a game engine?
An editor is just an interface that interacts with the game engine. Scripting is just another type of “interface” that can interact with the engine.
Look at Minecraft, they use a custom engine (based on LWJGL) and it doesn’t have an editor.
@@samuelhulme8347 I'd call it library or a framework
i dont like rust for game programming.
Why?
@@thegoldenatlas753because of the compilation times? The case is even worse than C/C++ build times.
@@thegoldenatlas753If you have a small single threaded game, Rust is going to be cpu bottleneck very fast because of amount of cpu instruction rustc generates, C is basically macroses for assembly, lightweight, no compiler guards and fast
@@aamorous rust compiles down to assembly just as well as C
They are constantly being compared with little speed difference between them
@@thegoldenatlas753 you don't get the point, I'm not talking about speed. Rust is known for making big binaries, there are more instructions compared to gcc, it's because of 'bloated' optimizations compiler inserts in final executable, it makes cpu bottleneck. Speed always comes at a cost.
I still don't like rust.
needs editor
This was made as an api for programmers to use. Being forced to use an editor doesn’t give you full control. There are many game frameworks like this.
@@samuelhulme8347
This is untrue, because bevy does want to be a full fledged game engine. It is not on it's 1.0 yet so chill out, and their plan is for the editor to be optional.
All that rubish about "Rust is amazing" and yet i have not seen 1 solid game engine made with it.
bruv
the ecosystem is fairly new
give it a second
Tiny Glade just released demo recently.
That's a non-argument. Rust is still young and as in any other industry there's massive inertia when it comes to commonly used programming languages. Being able to choose a language purely on its merits is a rare luxury.
In what, < 10 years of popular and mature existence? Surely you are being fair.
Wake me up when they get an editor.
I don't want to learn Rust just for an engine with no editor.
nanite and motion blur are both red flags, these are very stupid technologies
Chill motion blur can be good if it per object instead of camera, on nanite well a poop igpu could handle billions of polygons with it at 20fps, so it not so bad .
Rust is too shitty an option to write a game engine
Bevy is so horrible
nah, it's pretty good
what a waste of time
Said BrentMalice
@@diadetediotedio6918 yep thats wat i said. congrats on reading
why
Why so malicious?
@@NapkinKing FOSS would be better if there wasn't 30000000 "options" for a program, and instead there was atleast 1 that didn't suck. everyone wants to feel super special and make up their own thing, and then demand donations and get salty when no one pays money for something that only has half the features anyone could need. same thing with kdenlive. anyone who worked on kdenlive is a moron who wasted thousands of hours for literally nothing. their life was wasted for 0 benefit to anyone.