Infinite chunk based terrain generation in Bevy 0.14

[@rawvoxel]

I'd love to see the async video. Building a voxel chunking system right now, async is the main missing component right to get rid of blocking during voxel generation.

[@Kiaulen]

Thank you, Chris! This is super cool.

[@b1chler]

cool! keep them coming!

[@xavierthomas1980]

Thanks. I would love async. I would also like LOD with stitching to avoid gaps. I would also like the chunks grid not being constrained to a checker of square chunks (and also not to a honeycomb of hexagonal chunks) but being more generic and allowing a mix of chunks with all shapes and sizes (different from chunk to chunk), just using a center and a radius. But I suppose this is much less procedural and require much more manual modeling. Anyway, no pressure, just giving my opinion in case it might be useful, but not requesting something that is probably way too much.

[@chrisbiscardi]

definitely useful to hear requests! thanks :) LODs are a definite possibility for this series. Especially as we scale up and potentially move to GPU/compute shader generation. I think for arbitrary mesh construction/decimation/etc I'll save that for another series. There's similar things like erosion that deserve their own focus too. This series will likely stay with planes and layered noise and focus on chunks/async/lods/etc.

[@eclipse6859]

The 3rd party library sickle_ui is no longer being maintained due to the apparent changes to the UI in bevy 0.15. Do you have any information on these changes or know of any PR(s) or issue(s) I can take a look at? I've been using sickle_ui, and I want to try to get ahead of this massive refactor.

[@chrisbiscardi]

I'm not sure what's going to happen with sickle_ui. Its possible that the 0.14 version will get forked and maintained for 0.15 since its such short notice. The change they seem to be referring to is the GhostNode PR which actually won't affect you at all if you're going to refactor. Its new/future functionality not something that will break your current code afaik. If you're looking to refactor definitely look into Required Components and the new bevy_picking functionality. bevy_picking is basically bevy_mod_picking upstreamed and switched to use observers. there's an example here: github.com/bevyengine/bevy/blob/e72b9625d7a2a55f940deeb31d71b41122371a83/examples/picking/simple_picking.rs Required Components is mostly going to affect how you use Bevy's internal bundles. Bundles aren't going away so you can still use them in userland code but the engine's bundles are all transitioning to using Required Components. A lot of the Required Components changes are happening this week, so its useful to check out the PRs that are merging if you want to gauge how things are changing: github.com/bevyengine/bevy/pulls?q=is%3Apr+required+components+is%3Aclosed UI hasn't had a Required Components PR yet as far as I can tell, so you may have to wait a couple days to see what changes actually land there. There is a proposal that lives on hackmd (alongside all the other Required Components proposals, many of which have been merged already) -- hackmd.io/puAA8c18TzeMhjclo36vEQ The first release candidate is currently slated for after these Required Components changes finish landing, so likely next week, and you can definitely expect the release notes to have a migration guide when the stable release comes out. I'm waiting for the changes to land before I do a Required Components video but I do have one queued up.

[@eclipse6859]

@@chrisbiscardi thank you so much! This was really informative

[@RobertoMaurizzi]

LOL at release mode eliminating the stuttering in chunk generation 😅 I'm curious to see what approach you'll use to make generation async

[@chrisbiscardi]

always check release mode if there's a performance issue lolol the async generation is going to be a task pool unless I come up with any better ideas before that. I need to make the generation slow first though. Maybe just cranking up the number of verts is enough of a showcase though.