*Miscellaneous Errata:* - There's a lot of different words for the same things in this field, but it seems that the algorithm I described as Greedy Meshing is more often referred to as Optimal Meshing, or "True" Greedy Meshing. The algorithm I described with the faces that grow in the positive directions, which I called Pseudo-Greedy Meshing, is often called just Greedy Meshing. - In the section about Level of Detail, I forgot to mention that as the block scale is increased, the chunk size in world space should be proportionally increased. So if a chunk at 1x scale is 32 blocks cubed, a chunk at 2x scale should represent 64 blocks cubed, at 4x scale a chunk should represent 128 blocks cubed, etc.
There is a Minecraft mod called Nvidium that uses mesh shaders to drastically improve the rendering performance. The mod author says that the mod is only supported on NVidia GPUs, but the mesh shaders technology is available on AMD and Intel GPUs and is part of the Vulkan API. Also, Distant Horizons mod makes it so you can render over 100 chunks around you. But I think it just uses some kind of LOD implementation, which you have started implementing. But I'm sure you can find something interesting from the Minecraft mods to implement in your voxel engine. Love your videos, keep it up.
I also recommend Voxy, it is like Distant Horizon but it uses the GPU for LOD generation and it uses a different LOD system that visually looks identical to normal blocks but somehow renders less blocks...? I don't know how that black magic works but it looks amazing
Yeah, I've been absently aware of all of these, but I haven't taken the time to look into them. I should probably do some 'market research' on stream at some point and compare the rendering techniques and algorithms they use to generate LOD terrain :)
This made me think that the further away from the camera's location, the shallower the angle the camera sees the blocks with respect to the horizon. This means that proportionately less of the top of voxels you see in the distsnce, and the more of one ot two of their sides. So at some distance you should be able to get away with not drawing multiple sides of the voxels (whichever quadtree level of detail they are at) but instead draw Billboards of their closest side.
@@AMcAFaves You're right, but that requires you to generate separate meshes for each block face and then check which face is visible. I'm pretty sure it's not worth the effort though. But for reference: in order to avoid holes you can't rely on angles because there's degenerate cases, so you'd basically render a single face for 6 blocks that are aligned with camera on each side, 2 faces for blocks that are coplanar with the camera on any axis, and 3 faces for the rest. The problem is that you can't render a single face (or only 2) for a single block (slice) in a chunk and more for others without changing the baked chunk meshes as the camera moves - doing so is likely slower for large number of chunks than using other techniques and plain backface culling. Assuming you can change the chunk meshes quickly enough, implementation of this is quite hairy (I've tried) and you end up with very complicated meshing code that's hard to add to.
Super cool video with a lot of great information! I love the depth you went into things, but still seemed relatively beginner friendly. Very much looking forward to the companion videos and anything else! Please keep up the great work, this was super cool and I can't wait for more!
I was also struggling a lot with LOD transitions in the past, but I actually found a quite simple solution: It requires a bit of a paradigm shift. Usually for a given chunk mesh you'd store all the border faces that point away from blocks of that chunk. But this can be switched to storing the faces that point into the chunk. This may seem a bit counter-intuitive at first, but it helps making the LOD transitions: You can easily generate all the faces that point into the chunk from a neighbor LOD chunk and store it in the high resolution chunk mesh. And then whenever a high resolution chunk has a LOD neighbor, you can just swap the border part of the mesh. Another advantage of storing it in the high res chunk is that you get tight meshes, which makes transparency work as well.
What do you mean by 'swap the border part of the mesh' exactly? Are you saying if a neighbor chunk is low resolution then you draw the inward faces on the high res chunk but otherwise you don't and let the neighbor chunk draw them?
Hey, thanks for the advice! I'm trying to understand how this improves the LOD seams... Is the idea that you mesh the inwards faces of neighboring LOD meshes as though they're high resolution, and treat the blocks as though they're solid 2^3 cubes of whatever block type is at that spot? That does seem like it would make things a bit easier than trying to figure out what faces are occluded by a higher resolution chunk bordering an LOD chunk. You also wouldn't need to mesh the inwards facing quads FROM a higher res chunk into a lower one, because those would always be facing away from the player. Is that what you're talking about? If so, that's a really great idea!
I feel that last part sooo much - dealing with the exact same problem right now… I keep underestimating the scope of my video ideas and now my initial planned list of dev-logs has almost doubled in size because I had to split up so many topics into smaller chunks… I really love the textures in your voxel game! Reminds me of that one minecraft mod called „eden ring“ I used to play with :D
Eden Ring is one of my favorite Minecraft dimension mods! I played it on a modded server recently and I was in love with it's art direction. If my game is serving the same energy, I must be doing someting right! Thanks!! ✨
It's rare to find developer videos that are this well put together. This video is not just informative but extremely engaging and entertaining as well. Can't think of a single complaint. You're not just learning how to make your own game engine, but learning about content creation as well. If you keep going down this path I have no doubts about the success of your channel! I can see the tremendous amount of effort that has gone into this project and video, and you should be proud of yourself! I'm glad that I'm able to provide some small amount of support. Best of luck to you, your project, and your channel. I'll be cheering for your success! 🎉
This is the first video of yours I've seen. Fantastic! Well edited and everything is explained very clearly. Clumping distant blocks into larger blocks for LOD is a really interesting idea. I'm very curious how that would look in practice.
Thank you! I'm glad you liked it! I don't have an exact timeline, but I'm hoping I can get an actual implementation of LOD in time for part 2 or part 3. In the meantime, the Distant Horizons mod for minecraft employs a very similar technique, if you'd like to see an example in a different game! :)
Another LOD think you can do is to reduce the complexity of the fragment shader so that "pixels far away" will be less demanding to process, like using smaller textures, simpler lighting or skipping some calculations depending on what the shader does. For example if you have a lava block or something changing texture brightness with time and a sine wave or smth it can probably be skipped and just have a static brightness.
You're completely right! I was working on that a while ago, but then I shelved it because I didn't have a very good solution for managing swapping shader pipelines my rendering architecture, as all the chunks no matter what LOD were blocked together in one big render list. I need to change that anyways once I get seriously high LODs going, because I'll need to render translate them coordinates closer to the player to avoid floating point imprecision--similar to what source games do with their skyboxes--so at that point I'll definitely be writing a simplified terrain shader for them.
wait. what exactly is the difference between the greedy meshing algortihm and your mesher? I read an article that basically mentioned the same "expand in all positive directions" approach but they actually called it true greedy meshing, so now im a bit confused.
Yeah I was actually mixed up on that one. Even the article I read months ago for my implementation calls my algorithm greedy meshing and the "greedy meshing" I mentioned "optimal meshing". Sorry about that! I'll probably write a little pinned comment clarifying.
Very fun video :3 despite knowing a lot of these techniques through my experiences with writing Minecraft mods I still learned quite a bit! I love your editing style too
You can squeeze even more performance out of greedy meshing by using binary meshing. Which is basically representing your voxels as integer values and doing some clever bit masking operations on them to "merge" the faces. Hope this helps if you ever need to optimize the algorithm further. It still won't be perfect greedy meshing, so there won't be a reduction in vertices, but still faster haha.
Great to have you back!!! 😁 It's always kinda interesting to see, what's actually behind programming an engine. I've been working with Unreal for a few years now and have learned a lot about optimizations, while the engine itself itself is doing most of the work. Creating them yourself is a whole different beast, though! 🤯
Thank you, glad to be here!! I'd probably go crazy if I was trying to make a general purpose engine. Making a focused voxel engine is enough for one lifetime!
This is a great video, I have no idea how there isnt more views yet. You keep it up like this and there will be guaranteed. You just need to gather people over time because youtube isnt helping as much as it should
Thanks! I'm glad you enjoyed it :) TH-cam probably isn't recommending my channel that much because I disappeared for the better part of a year, but honestly, it's already doing much more than I expected. I have high hopes for this video! Big numbers in the first few hours here ✨
Yep. It's quite dissapointing to see how much of a performance boost a single mod can give Minecraft (Sodium). It brings it from 40 fps at 32 render distance to 140, on a Steam Deck (@1080p) lol
Vanilla Minecraft is _horribly_ inefficient -- partially due to Notch not being a graphics programmer, partially due to Mojang being extremely lazy. _Optifine_ got famous for literally doubling the frame rate. Mods such as _Distant Horizons_ that have a HUGE draw distance shows what is possible when you have people who actually know what they are doing.
Yep, Minecraft is incredibly basic as far as rendering is concerned. Unless I'm mistaken, it's almost entirely single threaded too. It's a real shame, honestly. But it does make it very easy to make impressive seeming performance gains in my game, even if those optimizations are pretty standard at this point :p (I am going into some more interesting optimizations in the next video though, this was mainly an introduction to the topic!)
8:02 I’ve also seen that video. But apparently, the GPU doesn’t make extra calculations. GPU works with SIMT (Single Instruction Multiple Threads), so it’s not each individual threads running in parallel of each other, it’s multiple groups of threads that runs parallel to each other. When the gpu needs to execute a fragment shader, it dispatches multiple groups of 2x2 threads. So when there is only one fragment to draw on, only 1 thread is working while the others just sit there. The same thing happens when you branch in shader code, if threads within the same group don’t branch to the same place, the others needs to wait for the other one to finish and vice versa. I don’t know if I made it clear, but I recommend reading on the SIMT architecture, this will also help you for compute shaders (how and why we dispatch them the way we do). Good video btw!
Thank you for the clarification! I gave a pretty high level overview of this phenomenon, as this video is meant to be more of a cursory introduction to the topics I'll be exploring in the next videos. Correct me if I'm wrong, but I believe everything that I claime is still correct with the behaviour you described, as spinning up multiple threads that end up being discarded is still wasting threads that on a larger polygon would be doing actual work. GPUs have a fixed number of threads to do operations like rasterization, right?
@@Aurailus Yes I agree, I just wanted to point out that the GPU don’t do unnecessary calculations, it just stays idle for the most part. And in the end, does in fact waste time that could be spent on processing other data. Sorry if my comment sounded a little rude 😅
@trzrekzii9361 No worries at all! It didn't come off rude, I just wanted to check my understanding. I should have done a bit more research into how it "wastes energy".
I've spent a similar number of years on iterations of my own voxel engine (although I went the route of ray-marching and small voxels and all that stuff, somewhat more like Teardown). I'm just about to the point where I've decided "you know, maybe plain old triangle meshes aren't so bad after all" lol. Definitely subscribing. I always like to hear about peoples' voxel engines.
I've seen a lot of cool raymarching voxel projects, I'm personally just very partial to the classic minecraft style low-poly meshes. It's kinda crazy how quickly you can just slip into working on one project for years and years. Best of luck and thanks for watching!
Some amazing voxel projects I have seen on YT are from the following channels: * John Lin * Ethan Gore * Gabe Rundlett * Douglas * Frozein * Tooley1998 * Voxelbee * Daniil Gan'kov Of these, I think only Ethan Gore and Tooley1998 use rasterization for rendering.
I've watched videos from a bunch of these devs! Raytracing is a very cool technology, but I like the classic rasterized render pipeline and the flexibility it affords. I really enjoy non-voxel models in voxel-grid-space, and that's not as easily doable with the high performance raytracing techniques that a lot of these devs do. I really respect the hell out of their projects though, and follow many of them.
one idea of fixing the jumps between two chunks with different level of detail is to move the chunk with lower lod down a bit, since that chunk will be further away. Unfortunatly the max jump is like half the "merged voxel size", so the entire world would curve down the further you look. Another approach would be to blend between chunk borders (i.e. place some more voxels in the chunk with higher lod). This idea also reminds me of how Minecraft blends between chunk borders but instead of doing it for lod they blend when chunks have been generated in different versions resulting in massive jumps between chunk borders.
I actually considered this! But unfortunately, that only works for seams between the top edges of blocks. Shifting the chunk down wouldn't help with vertical seams, which are more rare, but still possible. I might be able to fix it by caching lower detail chunk info on LOD edges in my octree. I'll think about it more and hopefully make a video on it!
Very cool video, definitely subscribed! A good LoD system really makes the Voxel worlds feel infinite. You could also try to add a simple heightmap renderer for really distant chunks, instead of rendering what is essentially a single-block chunk, which makes really distant chunks easier to archive. If you don't have the chunk generated, you could on-the-fly calculate just the heightmap for the terrain generator(assuming the terrain generator supports this, but this is common) instead of full chunks. This could archive "realistic" viewing distances(10km+ to horizon), see also the Distant Horizons Minecraft mod!
You're back, the female human who I have never head of!!! I'm unironically so happy to be able to listen to actually educational and bearable videos, I'll *subscribe!*
2:54 minecraft does back-face culling which you can see by going into spectator (which i realise you said later on) and it does frustum culling too, interestingly these don't apply for entities also they did something with octrees in 24w34a but idk what
I forgot to mention frustum culling!! Oh wow, well that's something I should tack on to the next video. There's a really cool article on one on the Minecraft Pocket edition devs about doing occlusion culling using flood fill on chunks. It's here if you want to read about it tomcc.github.io/2014/08/31/visibility-1.html
Hey there! I recently found your channel and am super impressed by your game and especially your work with the engine! I've dabbled a little bit in voxel engines myself, but not to the epic level that you're getting to with yours. I was wondering if you'd share what resources you found to be the best for learning how to make your engine? Was it content from university or any interesting books or blogs? I would love to know what you found helpful, I'm really interested in learning about how you architect everything neatly as the program grows and how you implement all these amazing optimization techniques. Good luck with your game!! Looking forward to the updates!
Hey, thank you so much!! I put resources at the bottom of my Video Descriptions that are related to the topics in the video, but generally I learned a lot from O FPS (0fps.net/), the Seed of Andromeda blog (now defunct, but you can find it on archive.org), learnopengl.com, and vkguide.dev. I also get a lot more into the code during my livestreams every week on Sunday, if you want to see anything specific / ask questions there. Thank you!!
@@Aurailus Thank you so much for sharing! Huge respect, I'll definitely be checking out the livestreams! And if I ever end up making a cool voxel project I'll be sure to let you know too :)
I'm definitely going to use fog for the very borders of the loaded terrain, but I'm not sure how I'd go about masking LOD jumps with it. The terrain on both sides of the jump has to appear to be continuous.
AFAIK, your "pseudo-greedy meshing" algorithm is excatly what most people label as greedy meshing. It visits faces in order and naively tries to grow each quad to its maximum size without any regard for how this greed might negatively impact the size of future quads. The better algorithm you describe that finds the largest possible quads would be better described as "Optimal meshing" as it's guaranteed to produce an optimal mesh.
Oh well this makes me look silly. Yeah even the article I linked in the description calls it optimal meshing and my algorithm greedy meshing. I read that one months ago when I was first implementing it and I mixed up my terminology. Thanks for the correction!!
This is really impressive ^^ I've tried to implement a minecraft kinda thing but always got stuck at lighting and gave up because doing skylight with cubic chunks is something that isn't commonly discussed and is really annoying to figure out myself
Oh hey, I know exactly what you're talking about! I've got cubic chunks as well and implementing lighting with them really just is a disaster. I have a solution I'm still cooking that I hope to get to a state where I can share. Thanks for the comment!
I'd love to see it whenever it does come out, that would be super helpful ngl x33 Good luck working on this, was on your most recent stream and am definitely interested in all of this now
mario 3D land ost (specifically special world 8) oddly fits the vibes of the voxel world :D apologies for subscribing, blame youtube for recommending this vid randomly
There are so many cool people talking about the engines they're making Very very cool 👀 This is a really cool project and I'm excited to see what you gave in store in the future
I suggest not making chunks half the resolution, instead make chunks double the size (so effective resolution is halved but number of meshes is cut down). And instead of querying occupancy of the neighbouring voxel of the same LoD, query whether any of the 4 voxels in the higher LoD are free. A few extra faces wouldn't hurt.
You're right, I have already been planning on making the lower detail chunks larger, I kinda skimmed over that part in the video 😅. Querying if any faces are free in the higher LOD chunk would definitely be an improvement!
You're right! I haven't put that much thought into how I'm going to handle that, but this algorithm seems pretty cool: www.reddit.com/r/VoxelGameDev/comments/eem5yc/greedy_meshing_fixing_tjunctions_by_filtering_out/ It's basically a screen-space post-processing technique that uses the depth buffer to find gaps in the world, and fill in the color with the average of adjacent pixels. Pretty smart solution that doesn't require messing with geometry, imo!
Thanks!! It's Obsidian, with a bunch of plugins and stylesheets. I mainly use Minimal Theme and Make.MD, in addition to the CSS snippets here github.com/Aurailus/Obsidian-Snippets
I tried, okay ;-; I TRIEDDDD (I had all the lines recorded but I realized I fucked up their name in editing, and there's no way to get the exact same acoustics again after time has passed)
I've been trying my hand at vulkan and it's oh so much to learn. But one thing that I keep stumbling over is API and how I should architect it. I was wondering if your code was on github or somewhere so that I can try and learn from it. Thanks for the great videos!
Hi! Vulkan is definitely a huge learning curve, took me weeks to port my project over from OpenGL. Unfortunately my project isn't Open Source, but everything I've done, I've learned from vkguide.dev. It's an absolutely excellent resource, and I do recommend following it. Best of luck!
So cool to discover another channel on game graphics (I don't blue screen while watching it) which is kind of an hidden jewelry 🤭😅 Just to share with you guys (& lads 😌) a project I felt across a couple years ago that blew my mind but sadly enough was discontinued by the author: th-cam.com/video/6Cp9R2JBvoY/w-d-xo.htmlsi=xwdn9RuH2CiI6_a_ 👾 From 🇨🇵
Love John Lin's work. I didn't realize that they discontinued the project :( Was there any announced reason, or is that just an assumption given the radio silence?
@Aurailus no sadly enough, I guess the project did not found echo by the time it was under development so it was discontinued by John! It was so promising!
04:29 the grass requires alpha clipping which would require the whole mesh to be cutout instead of opaque. Did you notice an improvement on rendering the blocks after you could drop the cutout? Edit: oh, i noticed you got foliage on the grass-wall cubes, so you still need alpha clipping.
I haven't thought about disabling alpha clipping on chunks. As you pointed out, I do still have transparent faces in the backface culled meshes, and if I wanted to split meshes by if they should have alpha clipping or not, I'd need an entirely new render pass. I'm not sure that math works out on if that's better than doing it the way I'm currently doing it. I'd need to experiment though, I might look into that in the future!
Thank you so much! I use Motion Canvas to create my animations. It's a FOSS code-based animation software. They have a Discord server if you're interested!
Out of curiosity, wouldnt that greedy meshing bite you in the ass when you had superflat world for example and break a block? I don't know how efficient it is, but i guess it would freak out for a moment to recalculate meshes, if its not hard limited to chunk or something.
Good question! Greedy Meshing is usually still limited by the size of the chunk being rendered, which in my engine is 32x32x32 blocks. The game also already calculates the entire chunk mesh whenever a block is updated, so the so using greedy meshing or not doesn't really affect the remeshing time significantly.
Thanks! The project is in C++, and I'm using V8/Typescript for defining content and behaviour. I don't plan on open sourcing the project any time soon unfortunately, as I'm hoping to sell my game for profit when I eventually get to the point that I can do so. I do love Open Source though, and I have a lot of other Open Source materials at github.com/Aurailus !
@@AMcAFaves you technically can make a game engine in cobol now that it's modern iteration supports object oriented programming! You're just going to have to write some bindings yourself if you need like, sdl. XD Fortran is still better, you can never go wrong with it, if you want to squeeze every drop of performance out of you're machine like you're a more insane version of the dark magician, Kaze Emanuar himself! 😂
@@Aurailus that would be a level of hardcore, batsh*t insane that not even Kaze Emanuar himself would touch! That's, creator of roller coaster tycoon level! XD Still sticking with gfortran, so that I can attempt to surpass Kaze, as greatest optimization stickler! 😁
Have you thought of giving a name to your speedier pseudo-greedy mesh algorithm? LOL @ "too busy playing with mud" I love the power of 2 plaque. I'm so, so, so, sorry that I have subscribed to you. Please forgive me! 🙇🏻♂️ 😝 "...started using the TH-cam platform when I was, like, nine..." Thanks for reminding me I'm old...NOT! 😜
As others mentioned later on in the comments, I actually mixed up two ideas and the algorithm I described is actually true greedy meshing. The algorithm I said uses box packing is Optimal meshing, which nobody really uses. I'll try to find it in my heart to forgive you :p
4:30 Given the quads in the meshs are axis aligned why not just sort them into multiple meshs based on facing and use a hand full of ifs on the cpu to do 90% of the work the backface culling is doing? Would even save on the geometry feed into the vertex shader which is already going to be worked harder in Minecraft likes vs other games. 7:40 The talk of Simon's video and the problems with edges and LODs reminded me of the youtube video 'A Deep Dive into Nanite Virtualized Geometry' purposely cut link: watch?v=eviSykqSUUw
I haven't really been thinking about sorting my meshes by side because I'm fairly draw-call limited right now, but in my last stream Quantum Developer suggested I do it as well and since then I've been giving it more thought. If I multiply the mesh region size by two on each axis, I could then split it into 7 face meshes (6 for the cardinal axes + 1 for non-culled faces), and it would still be a net gain on draw calls. I think I'm gonna try it! I haven't watched that Simondev video yet, I'll do so!
@@Aurailus Also if your draw call limited, GL has ways to shove draw call info into GPU memory and batch up multiple of them. (MultiDrawInderict, if I rememeber right) Also the video is a decade old but look up "Beyond Porting: How Modern OpenGL Can Radically Reduce Driver Overhead (Steam Dev Days 2014)". If your using Vulkan I would imagine equivalents exist, as Drawcall limited (read as: driver overhead), is one of the primary reasons Vulkan came to be.
Yeah, I've messed around with Multi Draw Indirect a bit, and I was still getting pretty bad performance. I'm thinking I might actually be misattributing cache coherency issues to draw call time. Hopefully I can address it somehow though!
Hey, I have seen your message on the motion canvas discord about this video. I've watched the video and first of all great one. Second of all, do you happen to have the source code for your motion canvas components somewhere so I can snag them?
Hey, thank you! I publish my components to my videos on this GitHub Org (github.com/AurailusVideos). The latest ones aren't there yet because I've got some unreleased animations in the project. I'll be publishing it after I clear those out in the next week or so, though! :)
4:57 about you're greedy mesher, there's actually a better version of this optimization technique called binary greedy meshing, I learned about it watching a tantan video.
I loooove my Better than Adventure world ❤it's the only version of the game I actually play nowadays :P I couldn't miss the opportunity to show off a bit of the train station I built in the video, even though I'm technically discussing the modern game when talking about Minecraft in this video.
@@Aurailus Same lol, it feels like a way more polished and enjoyable experience than the actual modern versions. Also, can't blame you, train stations are a necessity for a beta world.
also, i think the solution to chunk LODs is that the neighbor higher detail chunk has to blend to the lower detail version of it at the border with the lower res chunk
I'm not currently using instancing for grass meshes, but I've got an idea I'm going to be experimenting with for how to handle it much more efficiently which I'll be going over in part 3 of this series. I think you're right about the LODs! I just need to have the border chunks account for the lower level of detail on the edges of the neighboring chunks. There's probably some funky preprocessing I could do to account for it at the moment I queue a mesh to be generated.
Yup! In my defense, I started working on this project before Distant Horizons was published :) That just goes to show how much time I've spent on this though 😅 Distant horizons is a great mod, and it's incredibly impressive they were able to retro-fit LOD into Minecraft!
OMG, I am now in the videos of two of my most beloved tech-gods: you and Aarthificial (≧ヮ≦) 💕. The video is awesome: concise, packed to the brim with information and even has some meme-sprinkles here and there! But it felt... a bit too fast? Like, being a professional web-dev with no background in game-dev - I needed to pause here-and-there or even rewind to understand what's going on. If your target audience is game-devs with experience - I guess it's ok, but if not - maybe your info-per-second can be toned down a bit. Anyway, can't wait to hop onto your next stream :3
Hey, thank you so much!!! You're definitely right that the pacing is a little fast. I'm working on improving the pacing of my delivery, but it's a slow process as if I suddenly started speaking way slower I would sound really robotic. It's actually scary how used we get to our regular cadences and intonations. I'll probably also dwell on topics a bit more in the future, so even if I'm saying words quickly, I won't be racing from topic to topic as much. Thanks you so much for your support!
@@Aurailus haha he is very well respected and makes some pretty useful videos, you should check him out! Also have you seen Ethan Gores voxel project? I calculated one time and his world contains an undecillion blocks and ALL of it is rendered. He uas an effective render distace of over a quadrillion blocks (he makes heavy use of lods but still) and it is powerful enough that he can place down entire minecraft maps as if they were blocks with each pixel of each block in the map being its own voxel. With every block representing one molecule it could fit the entire human body into the world and render all of it
Oh I've definitely heard of acerola, he's super great. I have seen a little bit of Ethan's work as well, and it seems incredibly impressive. I need to watch more of his videos!
but... these aren't voxels. This is plain old 3d model rasterization. Just in case you haven't seen it already, take a look at Comanche (1992) for an example of voxel rendering. Other than that, great introduction on azdo and other optimization techniques. Ah before I forget, one issue with LOD you want to consider is that _one_ instance of a small model at a distance can be ignored. _Many_ instances, of a small model, closely packed together at a distance can not. Think of a single flower at a distance, which you can even omit without losing anything, versus a dense patch of flowers of the same kind of flower.
The term "Voxel" was mainly popularized in the public consciousness by Minecraft, another game that uses rasterization. Yes, there have been a lot of raytracing projects recently which are "true" voxel engines, but I continue to use Voxel in the way that I and the public (that I can see) are familiar with, because that's the way that I've always heard the word used outside of specific game dev people. There's not really an appropriate term for raster rendered cube games other than Voxel, either, which contributes to the issue.
Vercidium is a great content creator! I've seen the video you're talking about, and it's a good resource. However, the pacing was quite fast in my opinion, and it skimmed over a few details that I want to cover in more depth. I also have some unique tricks that he hasn't covered, to my knowledge.
@@Aurailus I agree, he didn't tried to cover lods, and that's important for keeping details without performance problems with quads (2x2 pixel clusters that GPU utilizes to rasterize triangles)
Hey! I use a bunch of plugins, but mainly MakeMD for the file icons & folder sorting and stuff. I'm not a fan of the default styling of the plugin, so I have a CSS snippet for it which I use as well in this repo: github.com/Aurailus/Obsidian-Snippets/. I'm also using my own fork of the extension which fixes a few bugs that the dev wasn't addressing, so the current version might have broken styles with my stylesheet. My fork is here: github.com/Aurailus/MakeMd
*Miscellaneous Errata:*
- There's a lot of different words for the same things in this field, but it seems that the algorithm I described as Greedy Meshing is more often referred to as Optimal Meshing, or "True" Greedy Meshing. The algorithm I described with the faces that grow in the positive directions, which I called Pseudo-Greedy Meshing, is often called just Greedy Meshing.
- In the section about Level of Detail, I forgot to mention that as the block scale is increased, the chunk size in world space should be proportionally increased. So if a chunk at 1x scale is 32 blocks cubed, a chunk at 2x scale should represent 64 blocks cubed, at 4x scale a chunk should represent 128 blocks cubed, etc.
The voxel LODs sound really exciting. I want to see how that works.
High quality youtube game-dev content
Thank you!
Accurate descriptive comment.
There is a Minecraft mod called Nvidium that uses mesh shaders to drastically improve the rendering performance. The mod author says that the mod is only supported on NVidia GPUs, but the mesh shaders technology is available on AMD and Intel GPUs and is part of the Vulkan API.
Also, Distant Horizons mod makes it so you can render over 100 chunks around you. But I think it just uses some kind of LOD implementation, which you have started implementing.
But I'm sure you can find something interesting from the Minecraft mods to implement in your voxel engine.
Love your videos, keep it up.
I also recommend Voxy, it is like Distant Horizon but it uses the GPU for LOD generation and it uses a different LOD system that visually looks identical to normal blocks but somehow renders less blocks...? I don't know how that black magic works but it looks amazing
Yeah, I've been absently aware of all of these, but I haven't taken the time to look into them. I should probably do some 'market research' on stream at some point and compare the rendering techniques and algorithms they use to generate LOD terrain :)
@@WakeUp4L1fe I think the point was that the devs for Minecraft never implemented beyond the one change she said
This made me think that the further away from the camera's location, the shallower the angle the camera sees the blocks with respect to the horizon. This means that proportionately less of the top of voxels you see in the distsnce, and the more of one ot two of their sides. So at some distance you should be able to get away with not drawing multiple sides of the voxels (whichever quadtree level of detail they are at) but instead draw Billboards of their closest side.
@@AMcAFaves You're right, but that requires you to generate separate meshes for each block face and then check which face is visible. I'm pretty sure it's not worth the effort though.
But for reference: in order to avoid holes you can't rely on angles because there's degenerate cases, so you'd basically render a single face for 6 blocks that are aligned with camera on each side, 2 faces for blocks that are coplanar with the camera on any axis, and 3 faces for the rest. The problem is that you can't render a single face (or only 2) for a single block (slice) in a chunk and more for others without changing the baked chunk meshes as the camera moves - doing so is likely slower for large number of chunks than using other techniques and plain backface culling.
Assuming you can change the chunk meshes quickly enough, implementation of this is quite hairy (I've tried) and you end up with very complicated meshing code that's hard to add to.
I've been looking for a good explanation of voxels for the past month. Thanks so much!
Glad it was helpful!
Super cool video with a lot of great information! I love the depth you went into things, but still seemed relatively beginner friendly. Very much looking forward to the companion videos and anything else! Please keep up the great work, this was super cool and I can't wait for more!
Thank you so much!! Next one will be out as soon as I can~
I was also struggling a lot with LOD transitions in the past, but I actually found a quite simple solution:
It requires a bit of a paradigm shift. Usually for a given chunk mesh you'd store all the border faces that point away from blocks of that chunk.
But this can be switched to storing the faces that point into the chunk. This may seem a bit counter-intuitive at first, but it helps making the LOD transitions:
You can easily generate all the faces that point into the chunk from a neighbor LOD chunk and store it in the high resolution chunk mesh.
And then whenever a high resolution chunk has a LOD neighbor, you can just swap the border part of the mesh.
Another advantage of storing it in the high res chunk is that you get tight meshes, which makes transparency work as well.
What do you mean by 'swap the border part of the mesh' exactly? Are you saying if a neighbor chunk is low resolution then you draw the inward faces on the high res chunk but otherwise you don't and let the neighbor chunk draw them?
@@SonicTheCat I always draw the inward faces no matter if they come from a low-res or a high-res neighbor. This makes it possible to swap them out.
Hey, thanks for the advice! I'm trying to understand how this improves the LOD seams... Is the idea that you mesh the inwards faces of neighboring LOD meshes as though they're high resolution, and treat the blocks as though they're solid 2^3 cubes of whatever block type is at that spot? That does seem like it would make things a bit easier than trying to figure out what faces are occluded by a higher resolution chunk bordering an LOD chunk. You also wouldn't need to mesh the inwards facing quads FROM a higher res chunk into a lower one, because those would always be facing away from the player. Is that what you're talking about? If so, that's a really great idea!
@@Aurailus Yeah, that's exactly what I'm doing.
another voxel game youtuber to add to my collection... very good... yes (also powers of 2 are awesome you're so real for that
There are dozens of us, dozens!!
Base two is awesome I love it so much :)
Real life takes priority! Don't burn yourself out, it's always nice to hear how people make their vowel engines
I'm glad to be back, but thank you for your concern! :)
Apologies 😭 just found and subbed to your channel a couple days ago. Thanks for the update and the entertaining/interesting topics!
Welcome! I'm glad you liked the video!!
Absolutely worth the wait! Thank you SO MUCH!
Thank you!!!
I feel that last part sooo much - dealing with the exact same problem right now… I keep underestimating the scope of my video ideas and now my initial planned list of dev-logs has almost doubled in size because I had to split up so many topics into smaller chunks…
I really love the textures in your voxel game! Reminds me of that one minecraft mod called „eden ring“ I used to play with :D
Eden Ring is one of my favorite Minecraft dimension mods! I played it on a modded server recently and I was in love with it's art direction. If my game is serving the same energy, I must be doing someting right! Thanks!! ✨
It's rare to find developer videos that are this well put together. This video is not just informative but extremely engaging and entertaining as well. Can't think of a single complaint.
You're not just learning how to make your own game engine, but learning about content creation as well. If you keep going down this path I have no doubts about the success of your channel!
I can see the tremendous amount of effort that has gone into this project and video, and you should be proud of yourself!
I'm glad that I'm able to provide some small amount of support. Best of luck to you, your project, and your channel. I'll be cheering for your success! 🎉
Thank you so much!! I really appreciate your kind words ❤️❤️
7:09 usually you make the size of the chunks bigger so they still contain 32^3 voxels but the voxels are bigger
Yeah, I realized I glossed over that but I do plan on meshing larger regions into one mesh as well as reducing the detail!
This is the first video of yours I've seen. Fantastic! Well edited and everything is explained very clearly. Clumping distant blocks into larger blocks for LOD is a really interesting idea. I'm very curious how that would look in practice.
Thank you! I'm glad you liked it! I don't have an exact timeline, but I'm hoping I can get an actual implementation of LOD in time for part 2 or part 3. In the meantime, the Distant Horizons mod for minecraft employs a very similar technique, if you'd like to see an example in a different game! :)
Anyone else reminded of Tantan's greedy meshing algorithm when Greedy Meshing was mentioned?
Another LOD think you can do is to reduce the complexity of the fragment shader so that "pixels far away" will be less demanding to process, like using smaller textures, simpler lighting or skipping some calculations depending on what the shader does. For example if you have a lava block or something changing texture brightness with time and a sine wave or smth it can probably be skipped and just have a static brightness.
You're completely right! I was working on that a while ago, but then I shelved it because I didn't have a very good solution for managing swapping shader pipelines my rendering architecture, as all the chunks no matter what LOD were blocked together in one big render list. I need to change that anyways once I get seriously high LODs going, because I'll need to render translate them coordinates closer to the player to avoid floating point imprecision--similar to what source games do with their skyboxes--so at that point I'll definitely be writing a simplified terrain shader for them.
wait. what exactly is the difference between the greedy meshing algortihm and your mesher?
I read an article that basically mentioned the same "expand in all positive directions" approach but they actually called it true greedy meshing, so now im a bit confused.
Yeah I was actually mixed up on that one. Even the article I read months ago for my implementation calls my algorithm greedy meshing and the "greedy meshing" I mentioned "optimal meshing". Sorry about that! I'll probably write a little pinned comment clarifying.
Fantastic video. Loved the editing and visuals. Keep up the good work!
Thanks a ton! I'm glad you enjoyed it :)
Very fun video :3 despite knowing a lot of these techniques through my experiences with writing Minecraft mods I still learned quite a bit! I love your editing style too
Thank you! Glad you liked it!
You can squeeze even more performance out of greedy meshing by using binary meshing. Which is basically representing your voxels as integer values and doing some clever bit masking operations on them to "merge" the faces.
Hope this helps if you ever need to optimize the algorithm further. It still won't be perfect greedy meshing, so there won't be a reduction in vertices, but still faster haha.
I've heard a lot about this since publishing this video. I need to investigate it at some point. Thanks!
Great to have you back!!! 😁
It's always kinda interesting to see, what's actually behind programming an engine. I've been working with Unreal for a few years now and have learned a lot about optimizations, while the engine itself itself is doing most of the work. Creating them yourself is a whole different beast, though! 🤯
Thank you, glad to be here!! I'd probably go crazy if I was trying to make a general purpose engine. Making a focused voxel engine is enough for one lifetime!
Fantastic video! It's fascinating to see what optimisations you're able to do with voxels.
This is a great video, I have no idea how there isnt more views yet. You keep it up like this and there will be guaranteed. You just need to gather people over time because youtube isnt helping as much as it should
Thanks! I'm glad you enjoyed it :) TH-cam probably isn't recommending my channel that much because I disappeared for the better part of a year, but honestly, it's already doing much more than I expected. I have high hopes for this video! Big numbers in the first few hours here ✨
I never knew that Minecraft only uses the second stage of naive meshing instead of greedy meshing.
That's a bit disappointing tbh.
Yep. It's quite dissapointing to see how much of a performance boost a single mod can give Minecraft (Sodium). It brings it from 40 fps at 32 render distance to 140, on a Steam Deck (@1080p) lol
Vanilla Minecraft is _horribly_ inefficient -- partially due to Notch not being a graphics programmer, partially due to Mojang being extremely lazy.
_Optifine_ got famous for literally doubling the frame rate.
Mods such as _Distant Horizons_ that have a HUGE draw distance shows what is possible when you have people who actually know what they are doing.
Yep, Minecraft is incredibly basic as far as rendering is concerned. Unless I'm mistaken, it's almost entirely single threaded too. It's a real shame, honestly. But it does make it very easy to make impressive seeming performance gains in my game, even if those optimizations are pretty standard at this point :p (I am going into some more interesting optimizations in the next video though, this was mainly an introduction to the topic!)
8:02 I’ve also seen that video. But apparently, the GPU doesn’t make extra calculations. GPU works with SIMT (Single Instruction Multiple Threads), so it’s not each individual threads running in parallel of each other, it’s multiple groups of threads that runs parallel to each other. When the gpu needs to execute a fragment shader, it dispatches multiple groups of 2x2 threads. So when there is only one fragment to draw on, only 1 thread is working while the others just sit there. The same thing happens when you branch in shader code, if threads within the same group don’t branch to the same place, the others needs to wait for the other one to finish and vice versa. I don’t know if I made it clear, but I recommend reading on the SIMT architecture, this will also help you for compute shaders (how and why we dispatch them the way we do). Good video btw!
Thank you for the clarification! I gave a pretty high level overview of this phenomenon, as this video is meant to be more of a cursory introduction to the topics I'll be exploring in the next videos. Correct me if I'm wrong, but I believe everything that I claime is still correct with the behaviour you described, as spinning up multiple threads that end up being discarded is still wasting threads that on a larger polygon would be doing actual work. GPUs have a fixed number of threads to do operations like rasterization, right?
@@Aurailus Yes I agree, I just wanted to point out that the GPU don’t do unnecessary calculations, it just stays idle for the most part. And in the end, does in fact waste time that could be spent on processing other data. Sorry if my comment sounded a little rude 😅
@trzrekzii9361 No worries at all! It didn't come off rude, I just wanted to check my understanding. I should have done a bit more research into how it "wastes energy".
Love to find videos made by people who definitely deserve more subscribers!
Cool video to watch, even though i am not a game dev lol
Thank you!! Glad you liked it :)
first discovering this channel and i cant believe you have so few subscribers, this is amazing and i'm sure you'll go big. Outsanding content.
Thank you so much!! Here's hoping 🤞
I've spent a similar number of years on iterations of my own voxel engine (although I went the route of ray-marching and small voxels and all that stuff, somewhat more like Teardown).
I'm just about to the point where I've decided "you know, maybe plain old triangle meshes aren't so bad after all" lol.
Definitely subscribing. I always like to hear about peoples' voxel engines.
I've seen a lot of cool raymarching voxel projects, I'm personally just very partial to the classic minecraft style low-poly meshes. It's kinda crazy how quickly you can just slip into working on one project for years and years. Best of luck and thanks for watching!
Queen! I hope you had a quick recovery from Covid
It took longer than I had hoped, but I'm back to full functionality now! :P Thanks!!
Some amazing voxel projects I have seen on YT are from the following channels:
* John Lin
* Ethan Gore
* Gabe Rundlett
* Douglas
* Frozein
* Tooley1998
* Voxelbee
* Daniil Gan'kov
Of these, I think only Ethan Gore and Tooley1998 use rasterization for rendering.
I've watched videos from a bunch of these devs! Raytracing is a very cool technology, but I like the classic rasterized render pipeline and the flexibility it affords. I really enjoy non-voxel models in voxel-grid-space, and that's not as easily doable with the high performance raytracing techniques that a lot of these devs do. I really respect the hell out of their projects though, and follow many of them.
one idea of fixing the jumps between two chunks with different level of detail is to move the chunk with lower lod down a bit, since that chunk will be further away.
Unfortunatly the max jump is like half the "merged voxel size", so the entire world would curve down the further you look.
Another approach would be to blend between chunk borders (i.e. place some more voxels in the chunk with higher lod). This idea also reminds me of how Minecraft blends between chunk borders but instead of doing it for lod they blend when chunks have been generated in different versions resulting in massive jumps between chunk borders.
I actually considered this! But unfortunately, that only works for seams between the top edges of blocks. Shifting the chunk down wouldn't help with vertical seams, which are more rare, but still possible. I might be able to fix it by caching lower detail chunk info on LOD edges in my octree. I'll think about it more and hopefully make a video on it!
Great video. Nice intuitive visual explanations and animations!
this is honestly insane! Your very intelligent and the edit is just perfect :O
Well done, I hope to see more
Thank you so much!!! ❤️
you're so cool i love your videos :3
Very cool video, definitely subscribed! A good LoD system really makes the Voxel worlds feel infinite. You could also try to add a simple heightmap renderer for really distant chunks, instead of rendering what is essentially a single-block chunk, which makes really distant chunks easier to archive. If you don't have the chunk generated, you could on-the-fly calculate just the heightmap for the terrain generator(assuming the terrain generator supports this, but this is common) instead of full chunks. This could archive "realistic" viewing distances(10km+ to horizon), see also the Distant Horizons Minecraft mod!
You're back, the female human who I have never head of!!!
I'm unironically so happy to be able to listen to actually educational and bearable videos, I'll *subscribe!*
Ahaha, thank you! I'm glad my videos can be 'bearable' for you 😛
2:54 minecraft does back-face culling which you can see by going into spectator (which i realise you said later on) and it does frustum culling too, interestingly these don't apply for entities
also they did something with octrees in 24w34a but idk what
I forgot to mention frustum culling!! Oh wow, well that's something I should tack on to the next video. There's a really cool article on one on the Minecraft Pocket edition devs about doing occlusion culling using flood fill on chunks. It's here if you want to read about it tomcc.github.io/2014/08/31/visibility-1.html
Very interesting video and very well presented. Learned quite a bit. Thanks!
Thanks!! Glad you enjoyed it!
Hey there! I recently found your channel and am super impressed by your game and especially your work with the engine!
I've dabbled a little bit in voxel engines myself, but not to the epic level that you're getting to with yours.
I was wondering if you'd share what resources you found to be the best for learning how to make your engine? Was it content from university or any interesting books or blogs?
I would love to know what you found helpful, I'm really interested in learning about how you architect everything neatly as the program grows and how you implement all these amazing optimization techniques.
Good luck with your game!! Looking forward to the updates!
Hey, thank you so much!!
I put resources at the bottom of my Video Descriptions that are related to the topics in the video, but generally I learned a lot from O FPS (0fps.net/), the Seed of Andromeda blog (now defunct, but you can find it on archive.org), learnopengl.com, and vkguide.dev. I also get a lot more into the code during my livestreams every week on Sunday, if you want to see anything specific / ask questions there.
Thank you!!
@@Aurailus Thank you so much for sharing! Huge respect, I'll definitely be checking out the livestreams! And if I ever end up making a cool voxel project I'll be sure to let you know too :)
You could use fog to hide the chunk boundaries, like a smooth rolling fog.
Sorry for 2¹¹ subs
I'm definitely going to use fog for the very borders of the loaded terrain, but I'm not sure how I'd go about masking LOD jumps with it. The terrain on both sides of the jump has to appear to be continuous.
AFAIK, your "pseudo-greedy meshing" algorithm is excatly what most people label as greedy meshing. It visits faces in order and naively tries to grow each quad to its maximum size without any regard for how this greed might negatively impact the size of future quads.
The better algorithm you describe that finds the largest possible quads would be better described as "Optimal meshing" as it's guaranteed to produce an optimal mesh.
Oh well this makes me look silly. Yeah even the article I linked in the description calls it optimal meshing and my algorithm greedy meshing. I read that one months ago when I was first implementing it and I mixed up my terminology. Thanks for the correction!!
Really interesting video, thank you for sharing this, and looking forward to the next ones :D
Thank you!!
another great vid, thanks for all the effort!
Thanks!! Glad you enjoyed it!
This is really impressive ^^
I've tried to implement a minecraft kinda thing but always got stuck at lighting and gave up because doing skylight with cubic chunks is something that isn't commonly discussed and is really annoying to figure out myself
Oh hey, I know exactly what you're talking about! I've got cubic chunks as well and implementing lighting with them really just is a disaster. I have a solution I'm still cooking that I hope to get to a state where I can share. Thanks for the comment!
I'd love to see it whenever it does come out, that would be super helpful ngl x33
Good luck working on this, was on your most recent stream and am definitely interested in all of this now
mario 3D land ost (specifically special world 8) oddly fits the vibes of the voxel world :D
apologies for subscribing, blame youtube for recommending this vid randomly
I love the Mario 3D land OSTs! The beach theme from that game is another one of my favorites 💖
as far as I'm aware what you used is in fact greedy meshing, because greedy is for the greedy in ''greedy algorithm"
You are absolutely correct! I got mixed up unfortunately. I'm going to add a pinned comment correcting that mistake.
There are so many cool people talking about the engines they're making
Very very cool 👀
This is a really cool project and I'm excited to see what you gave in store in the future
Thank you so much!
Holy Hexxy, she's back
How long until I cave and just make this a HexCasting TH-cam channel? :P
Sassy GPU cracks me up
For some reason , hardware components babbling in animalese just feels right, lol
Thank you for such a good video 🙏
Glad you liked it!
love the video! thank you so much
You're so welcome! Glad you liked it!
I suggest not making chunks half the resolution, instead make chunks double the size (so effective resolution is halved but number of meshes is cut down). And instead of querying occupancy of the neighbouring voxel of the same LoD, query whether any of the 4 voxels in the higher LoD are free. A few extra faces wouldn't hurt.
You're right, I have already been planning on making the lower detail chunks larger, I kinda skimmed over that part in the video 😅. Querying if any faces are free in the higher LOD chunk would definitely be an improvement!
Greedy meshing usually has problem of t-junctions.
You're right! I haven't put that much thought into how I'm going to handle that, but this algorithm seems pretty cool: www.reddit.com/r/VoxelGameDev/comments/eem5yc/greedy_meshing_fixing_tjunctions_by_filtering_out/
It's basically a screen-space post-processing technique that uses the depth buffer to find gaps in the world, and fill in the color with the average of adjacent pixels. Pretty smart solution that doesn't require messing with geometry, imo!
9:50 what is that note taking app? Looks pretty good. Kinda reminds me of Notion, but it's not like I remembered it.
Anyways, great video!
Thanks!! It's Obsidian, with a bunch of plugins and stylesheets. I mainly use Minimal Theme and Make.MD, in addition to the CSS snippets here github.com/Aurailus/Obsidian-Snippets
I'm not unhearing that " * B U T T E R * " adlib anytime soon. lol
I tried, okay ;-; I TRIEDDDD (I had all the lines recorded but I realized I fucked up their name in editing, and there's no way to get the exact same acoustics again after time has passed)
I've been trying my hand at vulkan and it's oh so much to learn. But one thing that I keep stumbling over is API and how I should architect it.
I was wondering if your code was on github or somewhere so that I can try and learn from it. Thanks for the great videos!
Hi! Vulkan is definitely a huge learning curve, took me weeks to port my project over from OpenGL. Unfortunately my project isn't Open Source, but everything I've done, I've learned from vkguide.dev. It's an absolutely excellent resource, and I do recommend following it. Best of luck!
So cool to discover another channel on game graphics (I don't blue screen while watching it) which is kind of an hidden jewelry 🤭😅
Just to share with you guys (& lads 😌) a project I felt across a couple years ago that blew my mind but sadly enough was discontinued by the author:
th-cam.com/video/6Cp9R2JBvoY/w-d-xo.htmlsi=xwdn9RuH2CiI6_a_
👾 From 🇨🇵
Love John Lin's work. I didn't realize that they discontinued the project :( Was there any announced reason, or is that just an assumption given the radio silence?
@Aurailus no sadly enough, I guess the project did not found echo by the time it was under development so it was discontinued by John! It was so promising!
04:29 the grass requires alpha clipping which would require the whole mesh to be cutout instead of opaque. Did you notice an improvement on rendering the blocks after you could drop the cutout?
Edit: oh, i noticed you got foliage on the grass-wall cubes, so you still need alpha clipping.
I haven't thought about disabling alpha clipping on chunks. As you pointed out, I do still have transparent faces in the backface culled meshes, and if I wanted to split meshes by if they should have alpha clipping or not, I'd need an entirely new render pass. I'm not sure that math works out on if that's better than doing it the way I'm currently doing it. I'd need to experiment though, I might look into that in the future!
I got the Acerola vibes
People keep saying that and it's driving me MAD!!! (jk, thanks for watching)
Welcome back!
Thank you!!! Glad to be here :)
Very nice video ! I was wondering, what tool do you use to create the explanation animation ? They look so good !
Thank you so much! I use Motion Canvas to create my animations. It's a FOSS code-based animation software. They have a Discord server if you're interested!
@@Aurailus Thank you ! I will definitly check it out ! On your side, keep the hard work, you're killing it !
Out of curiosity, wouldnt that greedy meshing bite you in the ass when you had superflat world for example and break a block?
I don't know how efficient it is, but i guess it would freak out for a moment to recalculate meshes, if its not hard limited to chunk or something.
Good question! Greedy Meshing is usually still limited by the size of the chunk being rendered, which in my engine is 32x32x32 blocks. The game also already calculates the entire chunk mesh whenever a block is updated, so the so using greedy meshing or not doesn't really affect the remeshing time significantly.
@@Aurailus okay thank you for answer :)
Great explanation! Perhaps you could open source your engine some day :). Are you writing in C/C++/Rust?
Thanks! The project is in C++, and I'm using V8/Typescript for defining content and behaviour. I don't plan on open sourcing the project any time soon unfortunately, as I'm hoping to sell my game for profit when I eventually get to the point that I can do so. I do love Open Source though, and I have a lot of other Open Source materials at github.com/Aurailus !
C++ voxel game engine? Bah! Modern Fortran is where it's at! 😈 Wait unitl I make a fortran game engine!
Just you wait, I'll one-up you and remake the whole thing in assembly!
Fortran? Bah, COBOL's where it's at!
@@AMcAFaves you technically can make a game engine in cobol now that it's modern iteration supports object oriented programming! You're just going to have to write some bindings yourself if you need like, sdl. XD
Fortran is still better, you can never go wrong with it, if you want to squeeze every drop of performance out of you're machine like you're a more insane version of the dark magician, Kaze Emanuar himself! 😂
😱
@@Aurailus that would be a level of hardcore, batsh*t insane that not even Kaze Emanuar himself would touch! That's, creator of roller coaster tycoon level! XD
Still sticking with gfortran, so that I can attempt to surpass Kaze, as greatest optimization stickler! 😁
Have you thought of giving a name to your speedier pseudo-greedy mesh algorithm?
LOL @ "too busy playing with mud"
I love the power of 2 plaque.
I'm so, so, so, sorry that I have subscribed to you. Please forgive me! 🙇🏻♂️ 😝
"...started using the TH-cam platform when I was, like, nine..."
Thanks for reminding me I'm old...NOT! 😜
As others mentioned later on in the comments, I actually mixed up two ideas and the algorithm I described is actually true greedy meshing. The algorithm I said uses box packing is Optimal meshing, which nobody really uses. I'll try to find it in my heart to forgive you :p
Very good!
Thanks!!
4:30 Given the quads in the meshs are axis aligned why not just sort them into multiple meshs based on facing and use a hand full of ifs on the cpu to do 90% of the work the backface culling is doing? Would even save on the geometry feed into the vertex shader which is already going to be worked harder in Minecraft likes vs other games.
7:40 The talk of Simon's video and the problems with edges and LODs reminded me of the youtube video 'A Deep Dive into Nanite Virtualized Geometry' purposely cut link: watch?v=eviSykqSUUw
I haven't really been thinking about sorting my meshes by side because I'm fairly draw-call limited right now, but in my last stream Quantum Developer suggested I do it as well and since then I've been giving it more thought. If I multiply the mesh region size by two on each axis, I could then split it into 7 face meshes (6 for the cardinal axes + 1 for non-culled faces), and it would still be a net gain on draw calls. I think I'm gonna try it!
I haven't watched that Simondev video yet, I'll do so!
@@Aurailus Also if your draw call limited, GL has ways to shove draw call info into GPU memory and batch up multiple of them. (MultiDrawInderict, if I rememeber right) Also the video is a decade old but look up "Beyond Porting: How Modern OpenGL Can Radically Reduce Driver Overhead (Steam Dev Days 2014)". If your using Vulkan I would imagine equivalents exist, as Drawcall limited (read as: driver overhead), is one of the primary reasons Vulkan came to be.
Yeah, I've messed around with Multi Draw Indirect a bit, and I was still getting pretty bad performance. I'm thinking I might actually be misattributing cache coherency issues to draw call time. Hopefully I can address it somehow though!
Hey, I have seen your message on the motion canvas discord about this video. I've watched the video and first of all great one. Second of all, do you happen to have the source code for your motion canvas components somewhere so I can snag them?
Hey, thank you! I publish my components to my videos on this GitHub Org (github.com/AurailusVideos). The latest ones aren't there yet because I've got some unreleased animations in the project. I'll be publishing it after I clear those out in the next week or so, though! :)
@@Aurailus oh yeah that makes sense, I only saw the other Github account so I thought the they weren't online
I have made a serious and continuous lapse in my judgement when I decided to subscribe. my apologies but I will not be reimbursing the subscription.
Hmm, I'll accept it. But you're on thin ice!
really good video, subbed
Thank you!!
great job! I like such content
Thank you!!
4:57 about you're greedy mesher, there's actually a better version of this optimization technique called binary greedy meshing, I learned about it watching a tantan video.
I heard about this after publishing my video, but I haven't had a chance to look into it. I'll have to read into it some more!!
2:53 MC BETTER THAN ADVENTURE MENTIONED 🔥🔥🔥🗣🗣
I loooove my Better than Adventure world ❤it's the only version of the game I actually play nowadays :P I couldn't miss the opportunity to show off a bit of the train station I built in the video, even though I'm technically discussing the modern game when talking about Minecraft in this video.
@@Aurailus Same lol, it feels like a way more polished and enjoyable experience than the actual modern versions. Also, can't blame you, train stations are a necessity for a beta world.
This is vey interesting. I really hope you can build something to pass on to a games company.
Thank you! I'm hoping to self publish a game using this engine!
I have no idea what a 'game dev' is but it sounds interesting
Game Dev; Noun
Somebody who spends way too much time messing with polygons
Might have to mess with some polygons sometime
are you using instanced rendering for the grass meshes?
also, i think the solution to chunk LODs is that the neighbor higher detail chunk has to blend to the lower detail version of it at the border with the lower res chunk
I'm not currently using instancing for grass meshes, but I've got an idea I'm going to be experimenting with for how to handle it much more efficiently which I'll be going over in part 3 of this series. I think you're right about the LODs! I just need to have the border chunks account for the lower level of detail on the edges of the neighboring chunks. There's probably some funky preprocessing I could do to account for it at the moment I queue a mesh to be generated.
Woo optimizing!
Woot!
Built in Distant Horizon :O
Yup! In my defense, I started working on this project before Distant Horizons was published :) That just goes to show how much time I've spent on this though 😅 Distant horizons is a great mod, and it's incredibly impressive they were able to retro-fit LOD into Minecraft!
OMG, I am now in the videos of two of my most beloved tech-gods: you and Aarthificial (≧ヮ≦) 💕.
The video is awesome: concise, packed to the brim with information and even has some meme-sprinkles here and there! But it felt... a bit too fast? Like, being a professional web-dev with no background in game-dev - I needed to pause here-and-there or even rewind to understand what's going on. If your target audience is game-devs with experience - I guess it's ok, but if not - maybe your info-per-second can be toned down a bit.
Anyway, can't wait to hop onto your next stream :3
Hey, thank you so much!!! You're definitely right that the pacing is a little fast. I'm working on improving the pacing of my delivery, but it's a slow process as if I suddenly started speaking way slower I would sound really robotic. It's actually scary how used we get to our regular cadences and intonations. I'll probably also dwell on topics a bit more in the future, so even if I'm saying words quickly, I won't be racing from topic to topic as much. Thanks you so much for your support!
idk how to explain it but your mannerisms kinda remind be of Acerola
Lmao. I think that's a compliment, so thanks!
@@Aurailus haha he is very well respected and makes some pretty useful videos, you should check him out!
Also have you seen Ethan Gores voxel project? I calculated one time and his world contains an undecillion blocks and ALL of it is rendered. He uas an effective render distace of over a quadrillion blocks (he makes heavy use of lods but still) and it is powerful enough that he can place down entire minecraft maps as if they were blocks with each pixel of each block in the map being its own voxel. With every block representing one molecule it could fit the entire human body into the world and render all of it
Oh I've definitely heard of acerola, he's super great. I have seen a little bit of Ethan's work as well, and it seems incredibly impressive. I need to watch more of his videos!
wow, just, wow
♥
sorry
I forgive you 🙃
Dope 👍
♥
You code Java? I am so sorry for your loss.
Yeahhhh, I used to code in Java, It's not fun. But this project is in C++, with a Javascript modding API :)
wait. minecraft doesnt use greedy meshing?!
Sure doesn't!
There's just a few reasons mods for MC can boost frame rate... alot. /s
C++ ye B)
but... these aren't voxels. This is plain old 3d model rasterization. Just in case you haven't seen it already, take a look at Comanche (1992) for an example of voxel rendering. Other than that, great introduction on azdo and other optimization techniques. Ah before I forget, one issue with LOD you want to consider is that _one_ instance of a small model at a distance can be ignored. _Many_ instances, of a small model, closely packed together at a distance can not. Think of a single flower at a distance, which you can even omit without losing anything, versus a dense patch of flowers of the same kind of flower.
These are literaly voxels. just check what is a voxel..
The term "Voxel" was mainly popularized in the public consciousness by Minecraft, another game that uses rasterization. Yes, there have been a lot of raytracing projects recently which are "true" voxel engines, but I continue to use Voxel in the way that I and the public (that I can see) are familiar with, because that's the way that I've always heard the word used outside of specific game dev people. There's not really an appropriate term for raster rendered cube games other than Voxel, either, which contributes to the issue.
@Vercidium made a better one video tutorial on optimizing voxel meshes down to GPU memory chunck layout.
Vercidium is a great content creator! I've seen the video you're talking about, and it's a good resource. However, the pacing was quite fast in my opinion, and it skimmed over a few details that I want to cover in more depth. I also have some unique tricks that he hasn't covered, to my knowledge.
@@Aurailus I agree, he didn't tried to cover lods, and that's important for keeping details without performance problems with quads (2x2 pixel clusters that GPU utilizes to rasterize triangles)
🤧
♥
great vid! what obsidian plugins do you use? those tab icons are so satisfying.
Hey! I use a bunch of plugins, but mainly MakeMD for the file icons & folder sorting and stuff. I'm not a fan of the default styling of the plugin, so I have a CSS snippet for it which I use as well in this repo: github.com/Aurailus/Obsidian-Snippets/. I'm also using my own fork of the extension which fixes a few bugs that the dev wasn't addressing, so the current version might have broken styles with my stylesheet. My fork is here: github.com/Aurailus/MakeMd
@@Aurailus Fantastic thanks!