Want to learn how to write powerful, high-performance code? Then be sure to check out CodeCrafters using the link below, and help support my channel: app.codecrafters.io/join?via=DouglasDwyer They have one project which is completely free to complete during their beta, and you can begin any of their projects for free! Get 40% off if you upgrade to a paid account within three days.
Great video, please try using frame interpolation based on ground-truth motion maps generated by GPU and then apply this map to previous frame multiple times
Bro I made that tetrahexaconta tree joke before 😢 no credit 😂 joke aside, you are wrong about rasterisation vs marching, use a GBuffer to resolve the lighting, independent of the rendering type. Also light probe might help as a light cache, which would open gather as scatter global illumination. Look at hddgi too, you basically have the structure to do it by default. You can also have nlogn ray update with hierarchical segment tracing cache in hierarchical lightprobe.
bro why dont u make voxels that represent vertices instead of cubes? u will have less faces for a smoother look. but u might need to instead of doing culling u need to decide the shape of the voxel based on its neighbours, so depending on the situation if it cant be a vertex it will be like a lowpoly sphere if theres no neighbours, or something like this ynow? edit: this is exactly my plan for my game called pretend, but rn im working on more basic projects on irrlicht to get used to it and then progress using only irrlicht (since its faster and more compatible than godot)
Hi Douglas! Regarding supporting the channel: do you have patreon? If not, please create one as I would like to give something back for all the knowledge you’re sharing. Cheers! 😊❤️
@@YippeePlopFork hey, that's very kind of you! I do not accept any monetary support right now, since this project is still a hobby for me. As the engine gets closer to release, I may consider something like Patreon - but for now, I don't want to be "obligated" to create anything, and that's how I would feel if people donated to me. You can best support my work by continuing to watch my content and perhaps share it with others.
I had a dream. That every one of the "I made a voxel engine" youtubers came together to code an open-source voxel engine and put it on github under an open-source license, and it was so awesome and slick and efficient that the open-source community came together and rebuilt minecraft and hundreds of other games/mods on top of it. Then I woke up and I had to go to work :( Great video.
@@NerferCoAHAHA First time in 10 years I'm "recognized in public" :) I'm famous \o/ Did you use the board? We're working hard on v2, we'll be done shipping the kickstarter boards soon, I promise !
Given how they influence each other, by taking inspiration, that's working together in my book... Also I literally invented as a joke the word tetracontahexaconta for 1bit voxel, and guess who took large inspiration from it because I commented it? 😂 I know the literature on the subject, nobody else use that word, well now it's enshrined in his engine 😂
The data structure you're describing is called an N^3-tree which generalize octrees. Since you use a branching factor of 4, that would be a 4^3 tree. As you noted, it's possible to efficiently traverse this structure thanks to the bitmask trick. A very efficient algorithm for traversal is called hierarchical DDA (digital differential analyser), which is more commonly used for dense voxel grids but can also be applied in a hierarchical fashion on each level. Note that you may use a different branching factor on each level in order to reduce the depth of the structure while still retaining good sparsity. There is a paper describing all of this called "VDB: High-Resolution Sparse Volumes with Dynamic Topology" in case you need a reference. In my own work, I use a 3 level hierarchy where the first level is dense and the following two use a branching factor of 4. Hope this helps :)
@@solenskinerable avx is a set of vectorized floating-point arthmetic instructions on the cpu, right? This video and my comment were considering a gpu implementation. Now, in the case of cpu ray tracing, I suppose you could use vectorized instructions to trace multiple rays in parallel but this doesn't have anything to do with the datastructure. Ray tracing along a single ray remains a sequential operation that cannot be parallelized.
DUDE! 10:49 This reminds me of the old "Ace of Spades" game. Basically a voxel fps that could run on anything when I was a kid. I would love a sandbox game or anything really in a retro style like this! Keep going I got really excited while watching this video :D
fun fact! to this day it is still playable and quite enjoyable. The 2 most used client implementations are OpenSpades and BetterSpades, the server list can be found on the build&shoot website
Also known as a multi-layer grid, I have used these a lot. You can actually make it a little more efficient memory wise for spatially by hashing multiple values in the same nodes. The first low resolution grid is sometimes also called a bloom filter. You can use a processor's vector instructions like SIMD, openvc or cuda to skip many empty bits at once.
Love this! I saw some other comments on further ways to optimize traversal & memory usage, but from now on the common term for the 4^3-tree models should obviously be the THC-tree model 😄
The resolution and resource scaling is perfect on this lol. 100% gpu and cpu usage across 32 threads, and 1100fps default window size to 280 at 1440p. Looking forward to seeing how this project progresses, great job on it!
The low resolution has a really cool old-school feeling to it; you should play around with a CRT post-processing pass, could look awesome with the right resolution settings!
damn dude, this is the coolest stuff in CS in my opinion. Such a good combination of math and algorithms/data structures, to make something that looks so cool, and if it wasn't for job prospects, I'd totally go for it. I'm in second year uni, in cs and physics, and I'm so split in what area I want to go in. I worked on my own shitty, completely entry level 3D rendering/physics engine, and it was so much fun. But the game industry is going through so much layoffs right now, and if I want to work on other physics simulations like robotics or autopilots, it seems like I'd need a masters, which idk if I'd go for. I'm so torn on what I should work on this summer, if I should continue working on my game engine, or get into AI which is probably the more employable path, but doesn't seem as interesting as this. Also from what I hear game devs don't earn as much as other software engineers, but I wouldn't call this type of thing "game dev", more like engine designer, right? does it pay adequately to how much work you have to put in? maybe I care about the pay too much...
I think that your concerns about money are understandable. There definitely are game engine and GPU-related jobs out there, but they are competitive to obtain and the games industry doesn't pay quite as well. I'm not sure what advice to give you, other than that I personally would not go into AI. The area is overhyped right now, especially since the field has a low skill floor. Anyway, maybe consider software jobs in other areas related to low-level programming? In addition to games industry jobs, there are positions at companies like Qualcomm and AMD for developing new GPU drivers and tech.
One of the things I always wanted in AoS was vehicles. Imagine driving around a map in a Jeep, or driving a self-propelled artillery to a strategic high point? I could never figure out how a vechicle would navigate voxel terrain, but this idea of "normals for each voxel" could make it work.
GPU memory isn't slow, it's way way faster than standard system memory. GPUs aren't designed though to be programmed like CPUs you need to take into account the architectural differences and leverage the GPUs huge advantages when designing memory structures to be run on them.
Super awesome! It is pretty funny how many dev log videos start with. “I decided to reprogram it from scratch” 😂 I am also guilty of doing this tho so can’t say much
considering how fast these engines are at lower window resolutions, exploring upscaling options similar to DLSS might be a valuable win for lower end hardware. i think the nature of voxel scenes could lend themselves extremely well to certain upscaling techniques (or look ugly idk). would be fun to expiriment
Love your work. Voxel engines have a nostalgic place for me. Games like the original Outcast or Comanche (this dates me) had astonishing visuals for their time. That a voxel engine was possible on 1992 when barely any games were 3D at all is testment to their potential. There's a certain charm and art style to low res combined with a blocky world that is worth exploring. Bonus if that means it can run on a potato or a very old machine. Great potential there.
I think it is amazing what you were able to achieve with the surface normals. Not using polygons frees you of building the chunks with this geometry to render the voxels. Nice idea, really amazing !
I've always loved voxels, since Ken Silverman's Voxlap engine. I love the destructibility in particular, since polygons can't really do this. I think you have the rare opportunity to push the medium. So if we take the concept of destruction and voxel physics. What other cool things can we do that is only achievable with voxels? What are the limitations with polygons? I really feel like the future of game dev will be in a medium similar to voxels but something like gaussian splatting. Where the engine works with atoms. Maybe it's best to think of voxels as atoms. It's really an exciting area that has been so neglected by developers. You're very lucky to be working in an area that is yet to be fully explored creatively.
Absolutely love the photoscans!!! Also, i think the formal term for a tree with 8^3 sized nodes is a B+tree, B as in binary, + as in more than two children.
I believe the "higher levels" of searching through the voxels is some form of spatial hashing (you "hash" the ray positions to a coarser grid, which is then used to iterate through smaller grids).
First time I've come across your channel. I've always felt voxels are like a computer making graphics like (checks notes) a Post-Impressionist oil painter. The church and village at the end of the vid? Both facinate and excite my brain for reasons I simply can't fathom. Love, love, love voxels and if that's your engine? You've absolutely cracked it visual wise. Subscribed.
Oh also wanted to say that I found your channel (which has been great by the way). Because of a random video "You can Parry Nukes" for that V.A. Proxy game. I thought, Man it would be cool if that slash or explosion could slice a mountain in half as it traveled forward. Then I started thinking of Voxel destruction and how Voxel art would be pretty good for showcasing that kind of destruction. (Even that game looks like it be transformed into a Voxel art style. Then ended up down a rabbit hole of Voxel plugins for Unreal then custom Voxel engines and such which led me here.
Excellent work. I'm happy you went back to ray tracing. It does look much better. I love the idea of using photogrammetry to build out levels. I think this would make a really interesting almost PS1 looking game.
The one frustrating thing with the photogrammetric models is that they are hollow on the inside. It would be really nice to preprocess them so that they are solid (and also have proper normals).
Hey capslpop! Nice to see you here - I've actually been watching your channel since your first uploads two years ago. The Church of St. Sophia really is a nice test model, isn't it? Your channel was the first place that I saw it :)
I think global illumination could really make your engine look *even* better. I recently learned about an interesting technique for global illumination from a channel called xima. In his voxel engine he is using a cellular-automata based global illumination model that runs in a compute shader(to great effect).
I just learned about Xima's cellular automata GI, and it looks revolutionary! But I'm not sure how it would scale to scenes with more voxels. That said, GI is definitely something that I would like to learn about. I agree that it could take the graphics to the next level on high-end GPUs.
@@DouglasDwyer I don't think the performance impact is as big as you might imagine for this technique. The cellular automata only needs updates when the light conditions change, probably works well with octree-like structures, and lends itself well to caching. Plus, there is really no need to tie the light updates to the framerate, or at any fixed rate. You could just GI-update a small region at a lower rate for lower-end GPUs - due to the cached results for the non-updated chunks performance might should be ok? Really I'm just guessing here, maybe ask him for help? He seemed really nice in the comments where I already asked him some questions along those lines earlier :P
I definitely will reach out to him in the future. What I meant in terms of scale was more referring to memory consumption. Every time you double the size of your scene, it consumes 8x the memory, since the cellular automata requires storing per-voxel data, right? So I wonder how the memory is compressed. But maybe Xima has a solution :)
Wait a sec.. i recognize you. I used your fork of cpal for getting audio to work on the web in my game engine. Thanks and keep it up with the rust graphics content!!
Wow, that "low resolution" looks very interesting IMO. Idk why, but it reminds me ps1, and it's fascinating that it's all voxels. I think there would be a lot of cases of making use a such style. And it's true pixel-art (without shifting and rotating pixels)
Honestly, the low resolution example at the end looks much more interesting in my opinion. The high resolution shots, especially of the mediterranean cityscape, look sort of uncanny and moreover kind of lifeless. Could be sublime for horror games though I suppose.
Fantastic! Why oh why don't we see more retro-style games using voxels? I guess the engine programming is difficult and non-standard, but old games like Outcast and even older games like Ecstatica were fantastic, and the low-rez example in the end of this video reminds me a lot of Ecstatica for example. More! More!
10k UA-camrs - "I'll optimize this engine, even with the cost of rewriting 11 thousand lines of code." Multimillion companies hiring hundreds of programmers - "It reaches 48 FPS on RTX 4090, that should be enough!" Thank you for the video, it's very informative. Great job!
Try and add FSR 3 for lower resolutions on integrated video cards. You might end up gaining quality, even with high-end specs for this specific engine. You can also consider exchanging the language to Zig, as benchmarks show it can be up to almost 10x faster than C.
Something to consider (if you haven't already) for the tree structure you're using, a way to potentially be even more efficient might be to use a BVH BVHs are commonly used in many raytracing programs already because of their efficiency. It's basically LoD, but for the raytracing algorithm itself
BVHs would not be as efficient for my use case because my data is completely grid aligned. BVHs are designed to handle many overlapping objects with arbitrary transforms scattered throughout space. However, my voxels are on a fixed grid without overlap, so the BVH structure would just introduce extra overhead. Using a BVH on the top level when I am ray tracing against multiple voxel objects is something to consider, though.
You should also sometimes give each of the edges of a voxel a color. Otherwise surfaces often look like just a single color with no 3D dimension to it, not even like it's a 2D surface in a 3D world but like it's just some color added on top of the screen (like the wood of the well at 5:54). A voxel shouldn't ***have*** to have special color for the edge (to boost performance when it doesn't), but should be able to. When it does, it should maybe even be able to have different colors for different edges, thereby creating less uniform textures with irregular short stripes
You know the rust BTree is actually split into sixteen at each level instead of 2 for speed. That's fascinating to see the same kind of memory speed dynamics play out on the GPU. Also maybe you could look into using something like AMD fsr for low end GPU's. Amazing work!
How could we be mad, I personally absolutely understand your decision to start again, usually when you start a project, you have no clue how to do stuff and so you learn in process, code grows and becomes more mess, at some point you realise doing changes is complicted and if you want to do major change, only option is to start again. Or of course stop.
Another optimization I've seen for ray marching is "cone marching". It's an obscure term but there's a fairly understandable Powerpoint presentation that comes up when you Google it. It relies on having an actual signed distance function, so I don't know if you're using one/it's well defined enough for the method. Neat project, anyway!
There are definitely related optimizations that I could do, but sadly I don't build an SDF (too slow and memory intensive) so not sure if the approach could work here.
ok, you've conviced me to look harder into making my own engine. I am an unreal engine programmer so my current knowledge set is locked within that engine. need to expand man, but feels like there is little out there
I'm curious if you have ever tried the BrickMap data structure, which is very similar to yours, but its 8x8x8 instead of 4x4x4, though, I don't believe its organized in a tree structure. Great video as always!
Problem with higher subdivisions is that the bitmask he's using to traverse the tree becomes longer. 8^3 requires that many bits (1024), which is 8x64-bit ints. There's a tradeoff there when it comes to complexity, and it's somewhat hard to try out all the different trees because they all require custom CPU and GPU code so switching between them takes a bit of time.
Great video, as always. However, I’d like to give some clarification on GPU memory, you said it was “really really slow” and it’s not, in fact, it’s really really fast, the slowness you get from using more video memory is transferring memory from the CPU to the GPU, which is the bottleneck that is “really really slow”. The reason why reducing the memory usage makes the engine faster is because you are transferring less memory from the cpu to the gpu which is very slow.
I disagree. I meant what I said in the video - random access memory reads on the GPU are slow. On my integrated GPU, if I render a fullscreen quad and use a shader with 20+ texture loads per pixel, the framerate begins to drop below 60 FPS. If I render a fullscreen quad that only does 1 texture load, things are much faster. The random access memory reads and writes demonstrably affect program runtime. This is in contrast to the CPU, where you can do tens of thousands of memory reads each frame and be just fine. What you say is true as well, though - transferring between CPU and GPU is also slow. But if this were the only bottleneck in my engine, the game would only lag while the world was loading, and start running faster once all data had been uploaded to the GPU.
i don't know if you've added in octree LODs, but with ray marching it easily increases performance a ton, and the LODs, on an octree only increases memory usage (for color data) by 1/7, the value being essentially the average of its 8 children
Yes, I did make sure to include support for this. It's not visible yet in the demo since it hasn't been hooked up to my chunk management system. It should allow me to make the render distances comparable to Episode 16.
If the tetrahexaconta-thing lets you weed out empty cells, it's officially a weed tree and there is no getting out of this. Also the low-rez version looks great to me... not just an excuse for sure.
GPU memory isn't slow but random access is slow. That's particularly problematic on a GPU because it's not built for speculative execution and doesn't have a large per-core cache like a CPU. When rasterizing the data is fed to the GPU sequentially which is much more efficient since it makes it easy to predict future memory accesses for prefetching.
That's a good point - I should have clarified in the video by saying random access reads :) GPU memory is a complex beast, and taking advantage of cache coherency with linear access patterns can help performance. But the best way to optimize memory usage is to not use it at all!
technically, you dont need to store normals per every voxel/voxel face. you just need two normal directions per "sub object" that are perpendicular to each other, and the 3rd can be calculated with the cross product, because every cube in a grid aligned space will have the same normal for each face of each cardinal direction anyways.
I store a single normal which is used to light the entire voxel. This allows for the voxels to appear smooth, even in non-axis aligned directions, and represent shapes like spheres
@@DouglasDwyer Its not an end-of-the-world tradeoff to store just one normal. I suggested having a "tangent normal" for a similar reason to tangent space normal maps. Without a tangent calculated from the UVs its ambiguous how a face is "rolled" along that normal axis. Or in this case, how a voxel grid is "rolled" around its normal axis. im not sure how much that impacts your rendering process Though, I still don't like the idea of storing one for *every* voxel rather than for every grid-aligned space (IE, the world itself has normals, a tree rotated 45 degrees has its own, ect)
Coyo, thanks for clarifying - I didn't fully understand your suggestion at first! I think I was confused because I store per-voxel colors. So I don't need a full tangent space for every voxel, as I don't need to sample any textures. As for storing a normal per-voxel versus just using the object orientation, that's a stylistic choice. Having per-voxel normals allows for smooth surfaces like the rocks in the video. If you just used face normals, the rocks appear more like they do in the game Teardown.
@@DouglasDwyer Thats fair. I'm coming from hacking apart old minecraft versions so per-face normals are my... Norm v_v Technically, you could split grid spaces further into "normal chunks", where each.. well, has its own normal direction. Works great if theres only a few unique normals, but falls apart for something like your smooth terrains. I do hope there will be some suppourt for per-face normals in the future though, so that you can have sharp edges & corners on structures/items.
![Doubling the speed of my game's graphics [Voxel Devlog #18]](http://i.ytimg.com/vi/P2bGF6GPmfc/mqdefault.jpg)
![Emissive voxels and fancy lighting [Voxel Devlog #19]](/img/n.gif)
Want to learn how to write powerful, high-performance code? Then be sure to check out CodeCrafters using the link below, and help support my channel:
app.codecrafters.io/join?via=DouglasDwyer
They have one project which is completely free to complete during their beta, and you can begin any of their projects for free! Get 40% off if you upgrade to a paid account within three days.
Great video, please try using frame interpolation based on ground-truth motion maps generated by GPU and then apply this map to previous frame multiple times
Bro I made that tetrahexaconta tree joke before 😢 no credit 😂 joke aside, you are wrong about rasterisation vs marching, use a GBuffer to resolve the lighting, independent of the rendering type. Also light probe might help as a light cache, which would open gather as scatter global illumination. Look at hddgi too, you basically have the structure to do it by default. You can also have nlogn ray update with hierarchical segment tracing cache in hierarchical lightprobe.
bro why dont u make voxels that represent vertices instead of cubes? u will have less faces for a smoother look. but u might need to instead of doing culling u need to decide the shape of the voxel based on its neighbours, so depending on the situation if it cant be a vertex it will be like a lowpoly sphere if theres no neighbours, or something like this ynow?
edit: this is exactly my plan for my game called pretend, but rn im working on more basic projects on irrlicht to get used to it and then progress using only irrlicht (since its faster and more compatible than godot)
Hi Douglas! Regarding supporting the channel: do you have patreon? If not, please create one as I would like to give something back for all the knowledge you’re sharing. Cheers! 😊❤️
@@YippeePlopFork hey, that's very kind of you! I do not accept any monetary support right now, since this project is still a hobby for me. As the engine gets closer to release, I may consider something like Patreon - but for now, I don't want to be "obligated" to create anything, and that's how I would feel if people donated to me. You can best support my work by continuing to watch my content and perhaps share it with others.
I had a dream. That every one of the "I made a voxel engine" youtubers came together to code an open-source voxel engine and put it on github under an open-source license, and it was so awesome and slick and efficient that the open-source community came together and rebuilt minecraft and hundreds of other games/mods on top of it.
Then I woke up and I had to go to work :(
Great video.
Sometimes I do wish that I could team up with another voxel UA-camr or two. We would be able to accomplish more, faster, than by working on our own.
The Smoothieboard guy?? This is not a crossover I was expecting lol :)
@@NerferCoAHAHA First time in 10 years I'm "recognized in public" :) I'm famous \o/
Did you use the board? We're working hard on v2, we'll be done shipping the kickstarter boards soon, I promise !
@@DouglasDwyerMaybe ask? In my experience, that works much more often than people expect.
Given how they influence each other, by taking inspiration, that's working together in my book... Also I literally invented as a joke the word tetracontahexaconta for 1bit voxel, and guess who took large inspiration from it because I commented it? 😂 I know the literature on the subject, nobody else use that word, well now it's enshrined in his engine 😂
Not only have you gotten better on the technical side of things, but you have also improved a lot in video quality! Keep going man, love your stuff!
I wanted to make a comment like this but you already stole the show.
ok@@prltqdf9
This small niche of voxel engine ytubers is so comfy
We've become a remarkable little community, haven't we? :)
The data structure you're describing is called an N^3-tree which generalize octrees. Since you use a branching factor of 4, that would be a 4^3 tree. As you noted, it's possible to efficiently traverse this structure thanks to the bitmask trick. A very efficient algorithm for traversal is called hierarchical DDA (digital differential analyser), which is more commonly used for dense voxel grids but can also be applied in a hierarchical fashion on each level. Note that you may use a different branching factor on each level in order to reduce the depth of the structure while still retaining good sparsity. There is a paper describing all of this called "VDB: High-Resolution Sparse Volumes with Dynamic Topology" in case you need a reference. In my own work, I use a 3 level hierarchy where the first level is dense and the following two use a branching factor of 4. Hope this helps :)
8^3 using avx has to be faster tho right?
@@solenskinerable avx is a set of vectorized floating-point arthmetic instructions on the cpu, right? This video and my comment were considering a gpu implementation.
Now, in the case of cpu ray tracing, I suppose you could use vectorized instructions to trace multiple rays in parallel but this doesn't have anything to do with the datastructure. Ray tracing along a single ray remains a sequential operation that cannot be parallelized.
Welcome back to raytracing! I’m really excited to see where you take this engine.
Thanks frozein! It seems like all of our engines are headed in that direction, huh?
@@DouglasDwyer Yeah there's been some amazing progress from everyone lately!
I mean, if you're a programmer in your early 20s and you like CG programming - then you need to make your own voxel engine. I don't make the rules.
THC Tree 😅. I've heard it referred to before as a 64-tree
what about kd quaternary tree?
@@punchster289what about CBD tree?
@@cvabds yes i like that one
THC Tree is definitely sticking for me 🤣
The low-res style is sick! I think it would suit a horror game very well.
It's got an interesting charm to it, like an old retro game except 3D and using voxels
DUDE! 10:49 This reminds me of the old "Ace of Spades" game. Basically a voxel fps that could run on anything when I was a kid.
I would love a sandbox game or anything really in a retro style like this!
Keep going I got really excited while watching this video :D
That game was so good.
fun fact! to this day it is still playable and quite enjoyable.
The 2 most used client implementations are OpenSpades and BetterSpades, the server list can be found on the build&shoot website
I was so sad when it died
Lower resolution looks perfectly fine. imo it will create better result if used well
Awesome! It's incredible that you had the motivation to re-write all of that.
Also known as a multi-layer grid, I have used these a lot. You can actually make it a little more efficient memory wise for spatially by hashing multiple values in the same nodes. The first low resolution grid is sometimes also called a bloom filter. You can use a processor's vector instructions like SIMD, openvc or cuda to skip many empty bits at once.
Love this! I saw some other comments on further ways to optimize traversal & memory usage, but from now on the common term for the 4^3-tree models should obviously be the THC-tree model 😄
The resolution and resource scaling is perfect on this lol. 100% gpu and cpu usage across 32 threads, and 1100fps default window size to 280 at 1440p.
Looking forward to seeing how this project progresses, great job on it!
Lets go!
The low resolution has a really cool old-school feeling to it; you should play around with a CRT post-processing pass, could look awesome with the right resolution settings!
damn dude, this is the coolest stuff in CS in my opinion. Such a good combination of math and algorithms/data structures, to make something that looks so cool, and if it wasn't for job prospects, I'd totally go for it. I'm in second year uni, in cs and physics, and I'm so split in what area I want to go in. I worked on my own shitty, completely entry level 3D rendering/physics engine, and it was so much fun. But the game industry is going through so much layoffs right now, and if I want to work on other physics simulations like robotics or autopilots, it seems like I'd need a masters, which idk if I'd go for. I'm so torn on what I should work on this summer, if I should continue working on my game engine, or get into AI which is probably the more employable path, but doesn't seem as interesting as this. Also from what I hear game devs don't earn as much as other software engineers, but I wouldn't call this type of thing "game dev", more like engine designer, right? does it pay adequately to how much work you have to put in? maybe I care about the pay too much...
I think that your concerns about money are understandable. There definitely are game engine and GPU-related jobs out there, but they are competitive to obtain and the games industry doesn't pay quite as well. I'm not sure what advice to give you, other than that I personally would not go into AI. The area is overhyped right now, especially since the field has a low skill floor. Anyway, maybe consider software jobs in other areas related to low-level programming? In addition to games industry jobs, there are positions at companies like Qualcomm and AMD for developing new GPU drivers and tech.
This has to be the most immersive voxel engine I’ve seen so far
Amazing progress, I love your devlogs! :)
Thanks for watching, Xima! Your engine is very inspiring. I'm excited to see where we can take web-based voxel graphics now that WebGPU is maturing.
One of the things I always wanted in AoS was vehicles. Imagine driving around a map in a Jeep, or driving a self-propelled artillery to a strategic high point? I could never figure out how a vechicle would navigate voxel terrain, but this idea of "normals for each voxel" could make it work.
real scan environment looks so sick. with a little bit of hand finishing it would be an amazing level generation tool
Absolutely 🤗
GPU memory isn't slow, it's way way faster than standard system memory. GPUs aren't designed though to be programmed like CPUs you need to take into account the architectural differences and leverage the GPUs huge advantages when designing memory structures to be run on them.
This so much.
Super awesome! It is pretty funny how many dev log videos start with. “I decided to reprogram it from scratch” 😂 I am also guilty of doing this tho so can’t say much
considering how fast these engines are at lower window resolutions, exploring upscaling options similar to DLSS might be a valuable win for lower end hardware. i think the nature of voxel scenes could lend themselves extremely well to certain upscaling techniques (or look ugly idk). would be fun to expiriment
just started my data structure/algorithms course and seeing why the efficiency can be so important even on personal projects is motivating
Love your work. Voxel engines have a nostalgic place for me. Games like the original Outcast or Comanche (this dates me) had astonishing visuals for their time. That a voxel engine was possible on 1992 when barely any games were 3D at all is testment to their potential. There's a certain charm and art style to low res combined with a blocky world that is worth exploring. Bonus if that means it can run on a potato or a very old machine. Great potential there.
Glad you enjoyed the video, and I agree about the nostalgic aesthetic :)
I think it is amazing what you were able to achieve with the surface normals. Not using polygons frees you of building the chunks with this geometry to render the voxels. Nice idea, really amazing !
Holy crap that church looked amazing
baked voxel lighting looks awesome - you can see it in Ethan Gore's demo too
@@goobus_floobus yea I follow him as well 😂
@@TheDroidsb Every time I see the scale of the world in his demo my brain explodes 😂
The low resolution gives me 90s vibes in a good way.
I've always loved voxels, since Ken Silverman's Voxlap engine. I love the destructibility in particular, since polygons can't really do this. I think you have the rare opportunity to push the medium. So if we take the concept of destruction and voxel physics. What other cool things can we do that is only achievable with voxels? What are the limitations with polygons? I really feel like the future of game dev will be in a medium similar to voxels but something like gaussian splatting. Where the engine works with atoms. Maybe it's best to think of voxels as atoms. It's really an exciting area that has been so neglected by developers. You're very lucky to be working in an area that is yet to be fully explored creatively.
great progress, I've been a fan of voxel worlds since I was a wee little child, so it's always a treat seeing some new progress in this arena
Absolutely love the photoscans!!! Also, i think the formal term for a tree with 8^3 sized nodes is a B+tree, B as in binary, + as in more than two children.
just here to say I love the low res look, look like one of those "demake" but with its own style and not just PS1/2 look
0:13 Idk why but that pixelated lens flare is so cute hahaha
I believe the "higher levels" of searching through the voxels is some form of spatial hashing (you "hash" the ray positions to a coarser grid, which is then used to iterate through smaller grids).
First time I've come across your channel. I've always felt voxels are like a computer making graphics like (checks notes) a Post-Impressionist oil painter. The church and village at the end of the vid? Both facinate and excite my brain for reasons I simply can't fathom. Love, love, love voxels and if that's your engine? You've absolutely cracked it visual wise. Subscribed.
Nice to see the project coming along! Very excited! Thank you!
Imagine Magic Carpet remake with this tech!!!! Destructable castles, volcanos, tremors, everything. :DD
Oh also wanted to say that I found your channel (which has been great by the way). Because of a random video "You can Parry Nukes" for that V.A. Proxy game.
I thought, Man it would be cool if that slash or explosion could slice a mountain in half as it traveled forward. Then I started thinking of Voxel destruction and how Voxel art would be pretty good for showcasing that kind of destruction. (Even that game looks like it be transformed into a Voxel art style.
Then ended up down a rabbit hole of Voxel plugins for Unreal then custom Voxel engines and such which led me here.
I love how the game looks on the IC, maybe even better than on the GTX.
I think one of the coolest things about averaged normals per-voxel is that you get nice edge bevels on sharp objects basically for free
I tried the demo, I was quicker than expected. Good work.
I really like the low res look, especially if you add moody lighting and fog
Excellent work. I'm happy you went back to ray tracing. It does look much better. I love the idea of using photogrammetry to build out levels. I think this would make a really interesting almost PS1 looking game.
The one frustrating thing with the photogrammetric models is that they are hollow on the inside. It would be really nice to preprocess them so that they are solid (and also have proper normals).
The lower resolution + voxel style together looks very nice. Perfect for lower end GPUs as well like you said.
this looks so good, i find the low resolution version charming
The photoscan stuff is the best reminds me of Vagrant Story on PS1, some of the best lo-fi graphics ever made!
That church looks oddly familiar 🤔
Hey capslpop! Nice to see you here - I've actually been watching your channel since your first uploads two years ago. The Church of St. Sophia really is a nice test model, isn't it? Your channel was the first place that I saw it :)
Thanks for watching! Can't wait to see what you do in your next video :)!
Well DonE! I absolutely love the new vid style! Please keep up your good work!
Really beautiful! And the performance is insane 😲
11:10 Looks even more nostalgic really.
Loved the video! also thanks for linking Gabe's channel that one's new to me
I think global illumination could really make your engine look *even* better.
I recently learned about an interesting technique for global illumination from a channel called xima. In his voxel engine he is using a cellular-automata based global illumination model that runs in a compute shader(to great effect).
I just learned about Xima's cellular automata GI, and it looks revolutionary! But I'm not sure how it would scale to scenes with more voxels. That said, GI is definitely something that I would like to learn about. I agree that it could take the graphics to the next level on high-end GPUs.
@@DouglasDwyer I don't think the performance impact is as big as you might imagine for this technique. The cellular automata only needs updates when the light conditions change, probably works well with octree-like structures, and lends itself well to caching. Plus, there is really no need to tie the light updates to the framerate, or at any fixed rate. You could just GI-update a small region at a lower rate for lower-end GPUs - due to the cached results for the non-updated chunks performance might should be ok? Really I'm just guessing here, maybe ask him for help? He seemed really nice in the comments where I already asked him some questions along those lines earlier :P
I definitely will reach out to him in the future. What I meant in terms of scale was more referring to memory consumption. Every time you double the size of your scene, it consumes 8x the memory, since the cellular automata requires storing per-voxel data, right? So I wonder how the memory is compressed. But maybe Xima has a solution :)
Wait a sec.. i recognize you. I used your fork of cpal for getting audio to work on the web in my game engine. Thanks and keep it up with the rust graphics content!!
Yep, that's me! One day I will add audio to my own engine with it too.
Wow, that "low resolution" looks very interesting IMO. Idk why, but it reminds me ps1, and it's fascinating that it's all voxels. I think there would be a lot of cases of making use a such style. And it's true pixel-art (without shifting and rotating pixels)
Your brick tree is similar to cone marching just in grid aligned space, and could also be thought of as a sort of acceleration structure.
Rerwriting is at the heart of gamedev :)
Honestly, the low resolution example at the end looks much more interesting in my opinion. The high resolution shots, especially of the mediterranean cityscape, look sort of uncanny and moreover kind of lifeless. Could be sublime for horror games though I suppose.
Easily my favourite UA-camr, another great upload!
Wow, great job! Hope you can also implement reflection and refraction!
Yep! Reflection, refraction, and volumetrics are all stuff that I want to try!
Fantastic! Why oh why don't we see more retro-style games using voxels? I guess the engine programming is difficult and non-standard, but old games like Outcast and even older games like Ecstatica were fantastic, and the low-rez example in the end of this video reminds me a lot of Ecstatica for example. More! More!
This man is literally making history
10k UA-camrs - "I'll optimize this engine, even with the cost of rewriting 11 thousand lines of code."
Multimillion companies hiring hundreds of programmers - "It reaches 48 FPS on RTX 4090, that should be enough!"
Thank you for the video, it's very informative. Great job!
Now I really wanna see it with multiple ray bounces. Deeper shadows would go a long way in bringing out the details.
Ray tracing you say? Oh, i see, that rays bouncing around and making super realistic... wait... it's ray marching
bro you really need some ACES in your life this will look 1000 times better trust me
Try and add FSR 3 for lower resolutions on integrated video cards. You might end up gaining quality, even with high-end specs for this specific engine. You can also consider exchanging the language to Zig, as benchmarks show it can be up to almost 10x faster than C.
Woooo! He's back at it again with the rewrite! This guy is gonna be the next Notch!
That's the goal!
@@DouglasDwyer never go full notch
10:41 looks like when google street view doesn't load properly.
Something to consider (if you haven't already) for the tree structure you're using, a way to potentially be even more efficient might be to use a BVH
BVHs are commonly used in many raytracing programs already because of their efficiency. It's basically LoD, but for the raytracing algorithm itself
Lie
@@cvabds ?
BVHs would not be as efficient for my use case because my data is completely grid aligned. BVHs are designed to handle many overlapping objects with arbitrary transforms scattered throughout space. However, my voxels are on a fixed grid without overlap, so the BVH structure would just introduce extra overhead. Using a BVH on the top level when I am ray tracing against multiple voxel objects is something to consider, though.
You should also sometimes give each of the edges of a voxel a color. Otherwise surfaces often look like just a single color with no 3D dimension to it, not even like it's a 2D surface in a 3D world but like it's just some color added on top of the screen (like the wood of the well at 5:54). A voxel shouldn't ***have*** to have special color for the edge (to boost performance when it doesn't), but should be able to. When it does, it should maybe even be able to have different colors for different edges, thereby creating less uniform textures with irregular short stripes
That's a very nice acheivment. Congrat
You know the rust BTree is actually split into sixteen at each level instead of 2 for speed. That's fascinating to see the same kind of memory speed dynamics play out on the GPU. Also maybe you could look into using something like AMD fsr for low end GPU's. Amazing work!
I didn't know that! Yet again Rust proves that it is the best language, haha
The point of a btree actually is being wide, b doesn't stand for binary tree
Very intresting to watch, thank you
How could we be mad, I personally absolutely understand your decision to start again, usually when you start a project, you have no clue how to do stuff and so you learn in process, code grows and becomes more mess, at some point you realise doing changes is complicted and if you want to do major change, only option is to start again. Or of course stop.
I get around 8 fps on integrated graphics in the church which is 8 more than I expected, good work! (laptop defaults to IGPU with chrome)
I like the new video format!
Everyone wants something like Jhon Linn's renderer
Another optimization I've seen for ray marching is "cone marching". It's an obscure term but there's a fairly understandable Powerpoint presentation that comes up when you Google it. It relies on having an actual signed distance function, so I don't know if you're using one/it's well defined enough for the method. Neat project, anyway!
There are definitely related optimizations that I could do, but sadly I don't build an SDF (too slow and memory intensive) so not sure if the approach could work here.
When resizing the screen, use something like ICBI / FCBI to upscale the image and get a almost high quality result!
This is amazing, continue your good work
Man keep It up! The best voxel engine will be the one that gets published
Haha definitely
Amazing work! I think you might have found the method Euclideon unlimited detail uses...
Wow! (11:00) a multiplayer map for Gears [ War
Or Tomb Raider Death Maych/Free for All
I'd definitely appreciate being able to set the resolution if my GPU can handle it. Look beautiful either way
Thanks!
ok, you've conviced me to look harder into making my own engine. I am an unreal engine programmer so my current knowledge set is locked within that engine. need to expand man, but feels like there is little out there
Good luck!
That low res version reminding me of a game called Carpet or is it Magic Carpet released in late 90s or early 2000-ish I think.
I'm curious if you have ever tried the BrickMap data structure, which is very similar to yours, but its 8x8x8 instead of 4x4x4, though, I don't believe its organized in a tree structure. Great video as always!
Reportedly a brickmap of individual 64x64x64 octrees can also give great results.
Problem with higher subdivisions is that the bitmask he's using to traverse the tree becomes longer. 8^3 requires that many bits (1024), which is 8x64-bit ints. There's a tradeoff there when it comes to complexity, and it's somewhat hard to try out all the different trees because they all require custom CPU and GPU code so switching between them takes a bit of time.
@Caellyan puts it perfectly here. The 64-tree structure is the optimal size for register usage and empty space skipping, from my experience so far.
I think the low res looks really good. Reminds me of an Windows 98 game called Outcast which used voxels for the terrain.
11:08 super cute, love it
the lower resolution actually looks way more athstetically pleasing
Great video, as always. However, I’d like to give some clarification on GPU memory, you said it was “really really slow” and it’s not, in fact, it’s really really fast, the slowness you get from using more video memory is transferring memory from the CPU to the GPU, which is the bottleneck that is “really really slow”. The reason why reducing the memory usage makes the engine faster is because you are transferring less memory from the cpu to the gpu which is very slow.
I disagree. I meant what I said in the video - random access memory reads on the GPU are slow. On my integrated GPU, if I render a fullscreen quad and use a shader with 20+ texture loads per pixel, the framerate begins to drop below 60 FPS. If I render a fullscreen quad that only does 1 texture load, things are much faster. The random access memory reads and writes demonstrably affect program runtime. This is in contrast to the CPU, where you can do tens of thousands of memory reads each frame and be just fine.
What you say is true as well, though - transferring between CPU and GPU is also slow. But if this were the only bottleneck in my engine, the game would only lag while the world was loading, and start running faster once all data had been uploaded to the GPU.
@@DouglasDwyer ah, I see what you mean now, thanks for clarifying.
I feel like this is a bad reply, but I don't know how to put what I want to say into cohesive words, I'm sorry >~
i don't know if you've added in octree LODs, but with ray marching it easily increases performance a ton, and the LODs, on an octree only increases memory usage (for color data) by 1/7, the value being essentially the average of its 8 children
Yes, I did make sure to include support for this. It's not visible yet in the demo since it hasn't been hooked up to my chunk management system. It should allow me to make the render distances comparable to Episode 16.
If the tetrahexaconta-thing lets you weed out empty cells, it's officially a weed tree and there is no getting out of this. Also the low-rez version looks great to me... not just an excuse for sure.
GPU memory isn't slow but random access is slow. That's particularly problematic on a GPU because it's not built for speculative execution and doesn't have a large per-core cache like a CPU. When rasterizing the data is fed to the GPU sequentially which is much more efficient since it makes it easy to predict future memory accesses for prefetching.
That's a good point - I should have clarified in the video by saying random access reads :)
GPU memory is a complex beast, and taking advantage of cache coherency with linear access patterns can help performance. But the best way to optimize memory usage is to not use it at all!
god you're so cool, i hope i'm this good at programming one day
Just keep working hard and build new things! You can become an even better programmer :)
@@DouglasDwyer thank you! your channel, and many other programming ones, are very inspiring to me haha
This is so awesome!! The game looks amazing keep going!
Thanks for watching :)
technically, you dont need to store normals per every voxel/voxel face. you just need two normal directions per "sub object" that are perpendicular to each other, and the 3rd can be calculated with the cross product, because every cube in a grid aligned space will have the same normal for each face of each cardinal direction anyways.
I store a single normal which is used to light the entire voxel. This allows for the voxels to appear smooth, even in non-axis aligned directions, and represent shapes like spheres
@@DouglasDwyer Its not an end-of-the-world tradeoff to store just one normal. I suggested having a "tangent normal" for a similar reason to tangent space normal maps. Without a tangent calculated from the UVs its ambiguous how a face is "rolled" along that normal axis. Or in this case, how a voxel grid is "rolled" around its normal axis. im not sure how much that impacts your rendering process
Though, I still don't like the idea of storing one for *every* voxel rather than for every grid-aligned space (IE, the world itself has normals, a tree rotated 45 degrees has its own, ect)
Coyo, thanks for clarifying - I didn't fully understand your suggestion at first!
I think I was confused because I store per-voxel colors. So I don't need a full tangent space for every voxel, as I don't need to sample any textures. As for storing a normal per-voxel versus just using the object orientation, that's a stylistic choice. Having per-voxel normals allows for smooth surfaces like the rocks in the video. If you just used face normals, the rocks appear more like they do in the game Teardown.
@@DouglasDwyer Thats fair. I'm coming from hacking apart old minecraft versions so per-face normals are my... Norm v_v
Technically, you could split grid spaces further into "normal chunks", where each.. well, has its own normal direction. Works great if theres only a few unique normals, but falls apart for something like your smooth terrains.
I do hope there will be some suppourt for per-face normals in the future though, so that you can have sharp edges & corners on structures/items.
I almost prefer the low rez version, as it makes the game 'feel' like some games I played in the 90's. its a good look I miss.
Nice job all around.