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.
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.
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.
for the purpose of controlling the ship, we can think about it in two dimensions because we're using keyboard input to drive it. Keyboard arrow-key input is left/right and up/down which can be though of as the x axis and y axis in a 2d plane. We're going to use this "x/y" 2d plane and use it to drive the "x/z" coordinates in our 3d space. For each of the directions the player presses, we add or subtract 1 from the x or y axis of our Vec2 (github.com/rust-adventure/yt-low-poly-terrain-bevy/blob/054d042bf4a63ad2dbf6679baef72accda3cfb08/src/main.rs#L331-L342). This gives us a Vec2 that will have values that are -1, 0, or 1. Like Vec2::new(-1,1) for "left and forward". So this `z = y * 5` line is taking that 2d-input y value and mapping it to the z axis of our 3d space. The 5 is an arbitrary choice to speed up the ship so instead of adding 1 unit of distance per frame it adds 5 per frame, thus moving "5x faster" on the z axis.
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.
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.
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.
![[LIVE] : ONE ลุมพินี 82 วันนี้!! คู่เอก | ยอดไอคิว vs อับดัลลาห์](http://i.ytimg.com/vi/hSsyTl_9bqs/mqdefault.jpg)
![โรงเรียนตอนตี 2 โคตรหลอน..!! [โรงเรียนไดเม่]](http://i.ytimg.com/vi/2MAEMwqVYh8/mqdefault.jpg)
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.
Thank you, Chris! This is super cool.
cool! keep them coming!
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.
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.
@1:07 that line 213 `z = y * 5` is a headscratcher tho... It's like, instead of going forward, you go 5x that amount up from the surface?
for the purpose of controlling the ship, we can think about it in two dimensions because we're using keyboard input to drive it. Keyboard arrow-key input is left/right and up/down which can be though of as the x axis and y axis in a 2d plane. We're going to use this "x/y" 2d plane and use it to drive the "x/z" coordinates in our 3d space.
For each of the directions the player presses, we add or subtract 1 from the x or y axis of our Vec2 (github.com/rust-adventure/yt-low-poly-terrain-bevy/blob/054d042bf4a63ad2dbf6679baef72accda3cfb08/src/main.rs#L331-L342). This gives us a Vec2 that will have values that are -1, 0, or 1. Like Vec2::new(-1,1) for "left and forward".
So this `z = y * 5` line is taking that 2d-input y value and mapping it to the z axis of our 3d space. The 5 is an arbitrary choice to speed up the ship so instead of adding 1 unit of distance per frame it adds 5 per frame, thus moving "5x faster" on the z axis.
LOL at release mode eliminating the stuttering in chunk generation 😅
I'm curious to see what approach you'll use to make generation async
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.
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.
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.
@@chrisbiscardi thank you so much! This was really informative