[HN Gopher] Bevy game engine 0.6
___________________________________________________________________
Bevy game engine 0.6
Author : VitalyAnkh
Score : 262 points
Date : 2022-01-08 18:15 UTC (4 hours ago)
(HTM) web link (bevyengine.org)
(TXT) w3m dump (bevyengine.org)
| twofornone wrote:
| Looks like a good reason to finally try out Rust. Does HN have
| any recommended IDEs?
| pjmlp wrote:
| It pains to suggest it, but VSCode is one of the best
| experiences.
|
| Don't forget to also add Microsoft's C/C++ tooling for the
| debugging support.
| petee wrote:
| I'm just learning myself, and I found just Visual Studio Code
| and the Rust extension are great on Windows
| fsloth wrote:
| Seconded! It all works incredibly well. Rust with Visual
| Studio Code and the relevant suggested extensions (CodeLLDB,
| rust-analyzer) must be least hostile expert system I've ever
| used (and I've tried a few).
| friedman23 wrote:
| Make sure to use the Rust Analyzer extension, it's is
| significantly better than the default Rust extension.
| petee wrote:
| I tried for a minute but it just wouldn't work out of the
| box and I didn't have time to investigate, so I reenabled
| the default for now.
|
| I thought I saw somewhere rust devs themselves recommending
| Rust Analyzer too
| djmcnab wrote:
| You can either use rust-analyzer[1] (for which vscode is most
| well supported), or IntelliJ Rust [2]. Personally, I use `rust-
| analyzer` with vscode as a bevy developer.
|
| [1]: https://github.com/rust-analyzer/rust-analyzer
|
| [2]: https://www.jetbrains.com/rust/
| mahulst wrote:
| I'm in favor of intelliJ or CLion but I hear good stuff about
| rust analyzer and vacode as well.
| lordnacho wrote:
| Yep, and I've used bevy. Just get VSCode and the rust-analyzer.
| It's remarkable how well it works together with the language.
| There's also a thing that prints the errors and warnings in
| line to make it stand out more, sometimes you'll miss a
| squiggle.
|
| But also the suggestions are spot on quite often, eg finding
| the right import that you can just click without scrolling up
| to the top to insert, or adding/removing the & and * operators.
| You'll almost never come across a situation where you think it
| will compile but it doesn't.
| nu11ptr wrote:
| I _love_ the Rust plugin for Intellij. I have used VSCode a ton
| as well, but never for Rust. In general, I think Intellij is
| heads and shoulders above VSCode, but it is possible that 'rust
| analyzer' makes all the difference (I might check it out
| sometime).
| pizza234 wrote:
| I've tried Bevy v0.5 and it was very immature (as a matter of
| fact, all the Bevy "games" are single-screen). By looking at
| the release notes, it's not clear if it now supports OpenGL,
| which means that on some setups, it's not even possible to run
| correctly at all.
|
| It may be fun to write a hello world, but in this case, there
| are much easier (and more stable) engines.
|
| A typical setup if VSCode + Rust Analyzer. RA wasn't very
| stable around 6 months ago, but it was stable enough to be used
| regularly.
| justinhj wrote:
| I use Neovim 0.6.0 with its built LSP with some plugins
| including simrat39/rust-tools.nvim. It uses rust-analyzer. It
| works extremely well but I don't use the debugger at all. I've
| used IntelliJ with a Rust plugin, to and it has debugger
| support of sorts, but the overall experience was sluggish and I
| never went back.
| dang wrote:
| Some past related threads:
|
| _Bevy 's First Birthday: a year of open source Rust game engine
| development_ - https://news.ycombinator.com/item?id=28132114 -
| Aug 2021 (13 comments)
|
| _Bevy 0.5: data oriented game engine built in Rust_ -
| https://news.ycombinator.com/item?id=26716166 - April 2021 (65
| comments)
|
| _Bevy: A game engine built in Rust_ -
| https://news.ycombinator.com/item?id=26131350 - Feb 2021 (117
| comments)
|
| _Bevy 0.4: data oriented game engine built in Rust_ -
| https://news.ycombinator.com/item?id=25480321 - Dec 2020 (23
| comments)
|
| _Making a Snake Clone with Bevy_ -
| https://news.ycombinator.com/item?id=24999073 - Nov 2020 (11
| comments)
|
| _Bevy 0.3: game engine built in Rust_ -
| https://news.ycombinator.com/item?id=24983956 - Nov 2020 (55
| comments)
|
| _Bevy 0.2_ - https://news.ycombinator.com/item?id=24530698 -
| Sept 2020 (43 comments)
|
| _Bevy: A Game Engine in Rust_ -
| https://news.ycombinator.com/item?id=24334307 - Aug 2020 (42
| comments)
|
| _Bevy: A data-driven game engine and app framework built in
| Rust_ - https://news.ycombinator.com/item?id=24123283 - Aug 2020
| (103 comments)
| terafo wrote:
| With 3 month release cadence one question becomes more pressing:
| will it be 1.0 or 0.10?
| alice-i-cecile wrote:
| 0.10!
| [deleted]
| rl3 wrote:
| Congratulations to cart and the core Bevy contributors! This
| release was a long time coming, and their efforts are greatly
| appreciated.
|
| If you use this project and you can afford to donate, you
| definitely should!
|
| Having paid close attention to the Bevy Discord this past year,
| the sheer amount of work that's happened on this release is
| _mind-boggling_.
| jasonjmcghee wrote:
| Curious if others are able to see the WebGL2 examples working on
| iOS. They do not render for me, but WebGL2 definitely works in
| general, at least on 15.1+ (as per other sites and my own dev
| work)
| chmod775 wrote:
| It looks great in a lot of respects, but I can't help but notice
| the aliasing. In the example scene at the top, when in motion, it
| probably looks like there's a snow storm going on in the foliage
| and on most of the wall/floor textures.
|
| To me good anti-aliasing strategies is the single most important
| factor when it comes to graphics. I don't really care about
| things looking realistic or whatever, but I do care about my
| screen not being full of moving, weird, and distracting grainy
| patterns.
|
| This involves more than just softening the edges around polygons.
| There's also textures that contain shapes and the borders in
| textures with transparency to think about (usually foliage).
|
| My go-to solution in games with lackluster anti-alias is to just
| render them at a super-high resolution (4k/8k) and downscale, but
| that's not great for performance usually. You can compensate a
| bit because you won't need as much anisotropic filtering and such
| if you downscale, but even on expensive hardware that's not a
| solution in all games.
|
| To get to the point: In some older games I've seen blurring
| (possibly due to hardware limitations) of further-away detailed
| textures reducing aliasing. I'd love to see that technique
| revived in more modern games, possible with the help of AI to
| detect patterns/edges on textures that may be susceptible to
| aliasing, and selectively running those through a filter -
| basically shifting the work from the artists having to design
| textures that don't create artifacts to something automatic.
|
| In general good AA tends to be a second-class citizen in many
| modern game engines, partly because of how their renderer is
| configured by default (looking at you, Unreal). I really wish it
| wasn't so.
| rl3 wrote:
| This release primarily constitutes a massive rendering API
| rework. You can think of it more as a foundation that makes it
| easier to implement better rendering features in the future.
|
| If you check the release notes, you'll see HDR/Bloom support
| was dropped at the last minute, and several other major
| rendering features are still pending implementation. [0]
|
| The great part about Bevy is that it's modular, so you can swap
| out the renderer if you like. For example, there's already
| several people using Bevy with Embark's _kajiya_ renderer.[1]
|
| [0] https://bevyengine.org/news/bevy-0-6/#more-renderer-
| features
|
| [1] https://github.com/EmbarkStudios/kajiya
| posix86 wrote:
| You're the first person I see that also has this position!
| Anti-alias makes the difference between an image looking like
| it's a rendered set of datastructures by a computer, or if it's
| a virtual world you happen to have an image of. All other
| aspects of graphics - light, shadow, texture resolution,
| polygon count - can be considered endearing style, but not
| aliasing and bad texture filtering.
| andrewmcwatters wrote:
| > To me good anti-aliasing strategies is the single most
| important factor when it comes to graphics. I don't really care
| about things looking realistic or whatever, but I do care about
| my screen not being full of moving, weird, and distracting
| grainy patterns.
|
| I don't think I've ever heard this perspective before. Thank
| you for sharing your thoughts. This one is pretty unique, I
| think.
| masklinn wrote:
| > My go-to solution in games with lackluster anti-alias is to
| just render them at a super-high resolution (4k/8k) and
| downscale, but that's not great for performance usually.
|
| By "lackluster anti-alias" do you mean some sort of home-grown
| MSAA that's garbage?
|
| Because you're hand-rolling SSAA/FSAA, can't you just override
| the AA settings in the graphics driver to force FSAA or
| something?
| _cart wrote:
| The aliasing you're seeing is "texture aliasing" from a lack of
| mipmaps. We have an implementation in the works, it just didn't
| make it into this release. This is a straightforward and well
| understood problem. Thankfully our mesh edges are already crisp
| (thanks to MSAA) and we have a number of other anti-aliasing
| implementations in the works (TAA, SMAA, FXAA), each with their
| own strengths and tradeoffs.
| chmod775 wrote:
| That's cool - as are mipmaps, but even with those you'll
| still have patterns emerge that don't exist on the original
| texture. Humans are really good noticing patterns, so they're
| distracting (a tiled floor doesn't doesn't look like it has
| u-shaped curves in reality). Those patterns not having
| sharp/grainy edges anymore already helps a lot though.
|
| Maybe what I'm asking for is impossible, because fighting
| those patterns any further would just go too far into blurry
| territory. It might just be an inherent property of
| projecting something on a grid of neatly ordered pixels,
| which is very unlike the receptors in our eyes.
|
| Though to be honest, I didn't even consider that it may just
| be missing mipmaps making it look like that. My perspective
| is much that of a consumer who spend a lot of time trying out
| various settings/technologies and ordered them into "looks
| bad" and "looks better".
| lewispollard wrote:
| There's a really good blog post about the engineering of
| mipmaps from the perspective of mipmapping messing up their
| VR game's text legibility here:
|
| https://bgolus.medium.com/sharper-mipmapping-using-shader-
| ba...
|
| (May have been featured on HN recently, I can't remember
| how I got there).
|
| Often mipmaps are pretty much automatic from the player's
| perspective, it's often kind of baked in by the developers
| when processing the texture files. It can probably be
| disabled but I can't remember seeing that option in a game
| for a while.
|
| I'm curious to see how Bevy's doing it. I'm making a game
| in Godot at the moment, and their is the option there to
| generate mipmaps or not for an imported texture, and you
| can choose use a bilinear or trilinear filtering for the
| mipmaps, but that's about it (maybe there's more in the
| API, I haven't checked.)
|
| > Maybe what I'm asking for is impossible, because fighting
| those patterns any further would just go too far into
| blurry territory. It might just be an inherent property of
| projecting something on a grid of neatly ordered pixels,
| which is very unlike the receptors in our eyes.
|
| Basically it solves this exact problem - that rendering a
| high res image at a lower size can lose details at points
| you don't want them to (e.g. because some part of the
| texture like a line is entirely in subpixel "space"), and
| pre-processing a lower res image to switch to at different
| distance thresholds from the camera. The result is actually
| _better_ details at scaled down sizes, with much less
| flickering, even though the actual rendered texture at a
| distance can be much lower quality.
|
| They can also save a bit of GPU power and possibly VRAM, as
| the lower res, distant textures stream much more quickly
| than the ultra high res, near ones.
| mahulst wrote:
| Awesome! What a lengthy blog, so many new features. Great job on
| the new milestone!
| knobli wrote:
| I waited til 5am for this, it's currently 5:25am in Melbourne
| Australia...
| marcusbuffett wrote:
| Shameless plug, I wrote a snake tutorial for bevy that's become
| pretty popular, and just updated it for 0.6.
| https://mbuffett.com/posts/bevy-snake-tutorial/
| dralley wrote:
| Bevy's release notes are consistently the best I've ever seen.
| _cart wrote:
| Lead Bevy developer here: feel free to ask me anything!
| fsloth wrote:
| Looks really nice! If one was to implement a simple "3d arcball
| rotator" viewer for 3d formats to get familiar with the engine
| (i.e. load obj, view) can you suggest which examples would be
| most relevant (presuming bevy architecture is the only
| unfamiliar topic here)?
| _cart wrote:
| The input examples and the GLTF loading example are good
| places to start.
|
| https://github.com/bevyengine/bevy/tree/main/examples/input h
| ttps://github.com/bevyengine/bevy/blob/main/examples/3d/loa..
| .
| eb0la wrote:
| Evil question:
|
| I wonder why do you have version zero.something - this looks
| good enough for a version 1.
|
| What do you like to accomplish?
|
| And... What kind of help you'll need to get there??
| rl3 wrote:
| > _What do you like to accomplish?_
|
| The _What 's Next For Bevy?_ heading in the release
| announcement covers this:
|
| https://bevyengine.org/news/bevy-0-6/#what-s-next-for-bevy
| djmcnab wrote:
| I can't speak for cart here, but from my perspective as a
| contributor to `bevy`, it's extremely useful having freedom
| from backwards compatibility concerns to improve our APIs.
|
| For example, we want to rework our input handling, asset
| handling and UI; supporting this current UI solution
| indefinitely would be frustrating when we hope to make
| something much better once we can focus on that. As an
| example of this, we massively changed our rendering APIs for
| this release, allowing the improvements listed in the blog
| post to be implemented.
| pella wrote:
| Any public roadmap?
| mahulst wrote:
| All the way to the bottom of the blogpost, there is a list of
| areas being focused on.
| pella wrote:
| Thanks! https://bevyengine.org/news/bevy-0-6/#what-s-next-
| for-bevy
| ffhhj wrote:
| Congrats for the release, looks great! Not a criticism, but
| model projected shadows (not prebaked on lightmaps) are very
| jagged or really low-res, reminds me of early Unity shadows. I
| know Unity worked hard to improve them for years and acquired
| experts on shaders, because users complained and even moved to
| Unreal for that reason alone. Not sure if there are now well
| known solutions to get highly defined shadows, but I'm curious
| on your plans to improve them.
| _cart wrote:
| Yup shadows are notoriously difficult to make pretty in all
| situations. Fortunately we do have a number of "shadow
| quality" improvements in progress:
| https://bevyengine.org/news/bevy-0-6/#more-renderer-features.
| And we'll probably be improving shadows indefinitely from now
| on. The tech in that space is constantly evolving.
| infogulch wrote:
| I noticed the short section on changes to Bevy's UI. I expect
| both GPU rendering and ECS will be important capabilities to
| consider for new GUI systems, and Bevy does both well. How do
| you imagine Bevy fitting into the budding Rust GUI story a la
| https://areweguiyet.com ? An entrant itself? The backend for
| one? Would you consider pure GUI applications an important use-
| case for Bevy now, or perhaps some time in the future?
| Animats wrote:
| I'm using Rend3 for a Second Life/Open Simulator client. The
| current system with Rend3 has one thread doing nothing but
| refreshing the screen, while other lower-priority threads are
| independently changing the scene based on incoming messages
| from the network. Is that something the Bevy architecture can
| handle? Should I consider switching to Bevy?
| _cart wrote:
| Pipelining allows rendering and app logic to run in parallel.
| You can adapt to changes from the network when the app logic
| runs, so in that sense, it seems like a good fit. And you can
| use bevy_tasks to spawn background tasks (and spawn tasks
| across different thread pools, if that is required). I think
| it is worth considering Bevy, but I also think Rend3 is a
| great piece of software. We discuss rendering with that
| project's lead constantly :)
| nchi3 wrote:
| Super happy to see 0.6 released, great work!
|
| I've been sponsoring for close to a year, but haven't kept up
| with the Discord in many months. Currently I'm just been
| checking for updates every couple of weeks, and sometimes
| checking the state of GitHub issues and milestones.
|
| However, is there any better way for me to keep up with
| progress? If not, has there been any thought about having
| regular status updates? They don't have to take a lot of your
| (or someone else's) time, but just a few sentences on what's
| been decided, what's happened, etc, would be nice! Once every
| 30 or 60 days would definitely be enough.
| _cart wrote:
| Going forward, we will be doing a curated This Month In Bevy
| newsletter. We've had templates in draft mode for awhile, but
| getting 0.6 out the door has taken precedence. I'd like to
| release our first newsletter this month!
| nchi3 wrote:
| That's great to hear! Thank you for all the hard work, I'm
| looking forward to see Bevy grow, and really hope it'll end
| up becoming a worthy competitor to Unity/UE/Godot for
| commercial games some day!
| mysterydip wrote:
| If I'm a dev looking at engines to use, would now be the time
| to jump to Bevy, or is there expected to be significant changes
| to API and data structures moving forward still?
| _cart wrote:
| Things have started to stabilize, but unless you're willing
| to get your hands dirty and deal with regular breaking
| changes, I don't yet recommend staking your livelihood on it.
| That being said, by the end of the year I think we will be
| _much_ closer to our first stable release, and I expect the
| number of "serious projects" adopting Bevy to increase
| throughout the year. Now is the right time to start
| _evaluating_ Bevy for future projects (and experimenting with
| it).
| mysterydip wrote:
| Thanks for the response, I'll check back in a year!
| wrnr wrote:
| Thanks for your work. What is the support for low-end and
| mobile devices? I have tried developing with bevy on my old
| macbook with an Intel Iris graphics card, maybe not ideal but
| that is what I have and I want to support most hardware. Last
| time I tried the simple cube example made my fans spin. Is this
| something that can be alleviated?
| _cart wrote:
| We support low-end devices well (although this is a constant
| balancing act)! Bevy runs well on iOS currently (and we have
| WIP Android support ... we're working on re-enabling that
| asap). Fans spinning is a known issue, but it is generally
| decoupled from framerates (which tend to be fine). On some
| machines we are over-engaging cores, even with empty apps
| that do nothing ... my current theory is that we need to
| adjust how our task pools are managed.
| bullen wrote:
| Pipelined rendering increases motion-to-photon latency.
| _cart wrote:
| It can, but with care you can largely resolve this. And you can
| always disable pipelining if the performance benefits aren't
| worth it to you. Unity has a great article on this topic here:
| https://blog.unity.com/technology/fixing-time-deltatime-in-u...
| gameswithgo wrote:
| yes, you desperately want low latency, but also desperately
| want high throughput. such is life.
| cptroot wrote:
| Do you mind explaining why? Near as I can tell it should be the
| same unless you were already maxing out your CPU to run the
| game.
| steeleduncan wrote:
| Instead of doing all operations required to render the
| gamestate in a single frame you spread them in parts across
| multiple frames. This means that the output represents the
| state of the game some number of frames ago, increasing the
| time between your control inputs and what you see changing on
| screen.
| dagmx wrote:
| I don't believe that multi frame processing is a required
| part of a pipelines render.
|
| It just means the render stages are customizable, therefore
| is more flexible. See Unity as an example.
| mtsr wrote:
| This kind of pipelining is really about efficiency. Without
| it, either only the game logic is busy (utilizing just the
| CPU, most often) or the renderer is busy (utilizing both
| CPU and GPU). By starting next frames game logic sooner
| (concurrently with current frames rendering), one can keep
| a steadier load on both CPU and GPU with less idle time.
| serverholic wrote:
| Bevy is one of the most exciting projects in the rust space IMO.
___________________________________________________________________
(page generated 2022-01-08 23:00 UTC)