Live data from Hacker News

Bevy game engine 0.6

bevyengine.org

51–60 of 93 posts

Re: Bevy game engine 0.6

#51
post #4

Lead Bevy developer here: feel free to ask me anything!

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?

Re: Bevy game engine 0.6

#52
post #4

Lead Bevy developer here: feel free to ask me anything!

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?

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).

Re: Bevy game engine 0.6

#53
post #52

Earlier quoted context omitted.

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?

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…

Thanks for the response, I'll check back in a year!

Re: Bevy game engine 0.6

#54
post #37

Earlier quoted context omitted.

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.

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 pattern…

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.

Re: Bevy game engine 0.6

#55
post #7

Earlier quoted context omitted.

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.

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.

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.

Re: Bevy game engine 0.6

#56
post #4

Lead Bevy developer here: feel free to ask me anything!

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?

Re: Bevy game engine 0.6

#58
post #4

Lead Bevy developer here: feel free to ask me anything!

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?

Re: Bevy game engine 0.6

#59
post #56
post #4

Lead Bevy developer here: feel free to ask me anything!

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?

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 :)

Re: Bevy game engine 0.6

#60
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)

Post reply on HN