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.

@eszdman

2 ай бұрын

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

@timmygilbert4102

2 ай бұрын

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.

@jktech2117

2 ай бұрын

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)

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.

@DouglasDwyer

2 ай бұрын

Sometimes I do wish that I could team up with another voxel KZreadr or two. We would be able to accomplish more, faster, than by working on our own.

@NerferCo

2 ай бұрын

The Smoothieboard guy?? This is not a crossover I was expecting lol :)

@ArthurWolf

2 ай бұрын

@@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 !

@ArthurWolf

2 ай бұрын

@@DouglasDwyerMaybe ask? In my experience, that works much more often than people expect.

@timmygilbert4102

2 ай бұрын

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

8 күн бұрын

8^3 using avx has to be faster tho right?

@plokki456

5 күн бұрын

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

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!

@prltqdf9

2 ай бұрын

I wanted to make a comment like this but you already stole the show.

@st20332

2 ай бұрын

ok​@@prltqdf9

This small niche of voxel engine ytubers is so comfy

@DouglasDwyer

2 ай бұрын

We've become a remarkable little community, haven't we? :)

Welcome back to raytracing! I’m really excited to see where you take this engine.

@DouglasDwyer

2 ай бұрын

Thanks frozein! It seems like all of our engines are headed in that direction, huh?

@frozein

2 ай бұрын

@@DouglasDwyer Yeah there's been some amazing progress from everyone lately!

THC Tree 😅. I've heard it referred to before as a 64-tree

@punchster289

2 ай бұрын

what about kd quaternary tree?

@cvabds

2 ай бұрын

​@@punchster289what about CBD tree?

@punchster289

2 ай бұрын

@@cvabds yes i like that one

@goobus_floobus

2 ай бұрын

THC Tree is definitely sticking for me 🤣

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

@stevy2

2 ай бұрын

That game was so good.

@bigblackchode9628

2 ай бұрын

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

@thephoenixsystem6765

Ай бұрын

I was so sad when it died

The low-res style is sick! I think it would suit a horror game very well.

@Stormmblade

2 ай бұрын

It's got an interesting charm to it, like an old retro game except 3D and using voxels

Lower resolution looks perfectly fine. imo it will create better result if used well

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.

@RJiiFin

Ай бұрын

This so much.

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.

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

Amazing progress, I love your devlogs! :)

@DouglasDwyer

2 ай бұрын

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.

Lets go!

Holy crap that church looked amazing

@goobus_floobus

2 ай бұрын

baked voxel lighting looks awesome - you can see it in Ethan Gore's demo too

@TheDroidsb

2 ай бұрын

@@goobus_floobus yea I follow him as well 😂

@goobus_floobus

2 ай бұрын

@@TheDroidsb Every time I see the scale of the world in his demo my brain explodes 😂

Awesome! It's incredible that you had the motivation to re-write all of that.

Nice to see the project coming along! Very excited! Thank you!

just started my data structure/algorithms course and seeing why the efficiency can be so important even on personal projects is motivating

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 😄

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.

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.

Well DonE! I absolutely love the new vid style! Please keep up your good work!

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!

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!

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 !

Loved the video! also thanks for linking Gabe's channel that one's new to me

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.

Really beautiful! And the performance is insane 😲

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

Imagine Magic Carpet remake with this tech!!!! Destructable castles, volcanos, tremors, everything. :DD

I tried the demo, I was quicker than expected. Good work.

real scan environment looks so sick. with a little bit of hand finishing it would be an amazing level generation tool

@harriehausenman8623

Ай бұрын

Absolutely 🤗

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

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

That's a very nice acheivment. Congrat

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.

@DouglasDwyer

Ай бұрын

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 low resolution gives me 90s vibes in a good way.

This is so awesome!! The game looks amazing keep going!

@DouglasDwyer

Ай бұрын

Thanks for watching :)

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.

Amazing :) What do you think could be done to prevent the low res version from "flickering"? Also, how do you calculate the voxel normal? From what I've seen you color the whole voxel one color instead per voxel face, no?

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

@DouglasDwyer

Ай бұрын

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.

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.

@DouglasDwyer

Ай бұрын

Glad you enjoyed the video, and I agree about the nostalgic aesthetic :)

This has to be the most immersive voxel engine I’ve seen so far

Easily my favourite KZreadr, another great upload!

That church looks oddly familiar 🤔

@DouglasDwyer

2 ай бұрын

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

@capslpop

2 ай бұрын

Thanks for watching! Can't wait to see what you do in your next video :)!

This is amazing, continue your good work

Very intresting to watch, thank you

Great video! I am curious if you plan on tweaking the shadows and lighting to make it more realistic? I noticed that there is a lot of ambient light being used. Any plans to use a raytracing/phong lighting system in the future?

@DouglasDwyer

2 ай бұрын

Yes, I want to experiment with different kinds of lighting in the future. At the very least, I would want to support ambient occlusion and point lights. But having some kind of global illumination or other system would be cool too.

Just wondering, how does the ray marching work for non-grid aligned voxels? doesn't the raycast rely on the grid and octrees to be efficient?

@DouglasDwyer

2 ай бұрын

Absolutely. The objects in each chunk are stored in a list, and I ray march each object separately. So it's still efficient - it just uses multiple grids, basically :)

@JensonTM

2 ай бұрын

@@DouglasDwyer ah i see, thank you

10k KZreadrs - "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!

Beautiful work.

this looks so good, i find the low resolution version charming

The lower resolution + voxel style together looks very nice. Perfect for lower end GPUs as well like you said.

The photoscan stuff is the best reminds me of Vagrant Story on PS1, some of the best lo-fi graphics ever made!

could you please go into more detail about per voxel normals? either here or in another video?

I really like the low res look, especially if you add moody lighting and fog

I could run it with const 15-16-17ms in my browser on any map with any quality of rendering and all, so I think it is working pretty well on external graphics cards as well (I have an old AMD one). Curious to see how it would perform under stress or with more features like physics and all And talking about physics, don't you think the old rasterization way of doing thing would be easier to integrate than with the new raymarching way? I mean because you would be able to kind reuse the render meshes as collision meshes and all, or are you planning to go with a more voxel-friendly approach for collisions here?

@DouglasDwyer

2 ай бұрын

Excellent question, and thanks for trying the demo. The voxel physics has always used the voxel data itself for the collisions, so there won't be any problems there! That said, I am planning to redo the physics system since my first attempt was a bit crippled. I learned a lot making it, and I hope to create a much better result this time around.

Wow, great job! Hope you can also implement reflection and refraction!

@DouglasDwyer

2 ай бұрын

Yep! Reflection, refraction, and volumetrics are all stuff that I want to try!

I was working on a voxel engin, and I used to use same ray tracing for my rendering. But I had one problem, that I think you did solve. How did you manage to support multiple object ? In my case if the object behind is render after, he takes over the first one. Did you draw a cutsom depth buffer and discard pixel if the ray goes further an already drawn depth ? or myabe you sort your object before rendering ?

@shadow_blader192

2 ай бұрын

🤔 your ray must have minDepth variable to check if you need draw object (draw if distance to object is lower than minDepth, and set minDepth to this distance.

@songo2968

2 ай бұрын

Yes, it's what I meant by custom depth buffer (because the minDepth has to be sample on every pixel = for every ray). But my problem is having a "texture" (my buffer) that I can read (get minDepth) and write (update minDepth if needed) in my shader. Since all my shader will use the buffer in same time (asynchronously), I don't know how to achieve that. At the moment I can use a texture to write to it, or one to read, but not both.@@shadow_blader192

@DouglasDwyer

2 ай бұрын

During the ray marching, I cast a ray for each potential object (not in any particular order). For each object, I check to see if the point that was hit (if any) is closer than the closest point I've seen so far. If so, that point becomes the new closest point. At the end of the algorithm, the closest point is returned as the ray hit.

@songo2968

2 ай бұрын

@@DouglasDwyer your algortihm is done gpu side I guess, so you render all your object with one big call ? You dont draw them one by one ?

@DouglasDwyer

2 ай бұрын

@@songo2968That's right, this is a pure ray marcher - so all of the calculations (even with multiple objects) happen in a single compute shader right now.

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

Do you upload the entire scene to the GPU memory at once? What if that does not fit, do you use any compression or out-of-core techniques?

@DouglasDwyer

Ай бұрын

As described in the bricktree section of the video, I use a sparse data structure and only the surface voxels are uploaded to the GPU. Further, the world is infinite and broken into chunks, so only the chunks around the player are loaded into memory. Right now, the chunk radius is just a user setting, but maybe I can lower it automatically if memory runs out :)

How do you calculate a normal of a voxel? Arent voxels just aligned cubes? Do you take the average of nearby other voxels to calculate a slope?

@DouglasDwyer

Ай бұрын

Excellent question. For imported maps (which don't come with normal data), then I need to calculate a slope, yes. This is done at import-time (and is somewhat imperfect, hence the strange lines on certain parts of the model). Once I switch to procedurally generated/built worlds, though, I can calculate the normals directly from the shapes used to build the world. For example, if the player wants to place a sphere in the world, I can analytically calculate the normals on the sphere's surface and assign them to the voxels.

I love how the game looks on the IC, maybe even better than on the GTX.

Woooo! He's back at it again with the rewrite! This guy is gonna be the next Notch!

@DouglasDwyer

2 ай бұрын

That's the goal!

Video quality is great!

I am not sure if it is technically the same, but in uni we were taught the "branch on need octree" which is kind of the tree you are using?

that looks amazing!

awesome demo!

@DouglasDwyer

Ай бұрын

Glad you liked it!

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!!

@DouglasDwyer

Ай бұрын

Yep, that's me! One day I will add audio to my own engine with it too.

8:56 so I’ve got a question, it’s my understanding that the bit mask stores whether or not something is there. How do you tell it “what” is there rather than just “something”? This is the part that I’ve been struggling in my own journey, is encoding the “what” along with the “where” because either are easy on their own. My initial guess was maybe you have a mask for each type of material?

@DouglasDwyer

13 күн бұрын

In my engine, each voxel is represented by a 32-bit integer. The 32-bit integers are stored in memory directly after the bitmask. The bitmask is used for ray traversal and compression.

This is incredible!

It all looks really good. Will other things, like transparency or volumetrics, be easier with this new method?

@DouglasDwyer

2 ай бұрын

Volumetrics will absolutely be easier, since volumetrics involves accumulating the amount of light along a ray! I anticipate that transparency will be equally annoying to implement as in rasterization, just in a different way lol

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.

Fantastic! Is there a game / project in mind for the engine, or are you planning to release the engine itself? Either way, great work and I enjoyed hearing about the more granular GPU challenges and solutions you encountered - thanks for sharing!

@DouglasDwyer

Ай бұрын

My goal is turn to the engine into a multiplayer platform where users can create their own experiences with mods/plugins. The rough project roadmap for me involves three steps. First, I want to finish the core engine. Then, I intend to build a small proof-of-concept game with it, and release that. Finally, I'll release the suite of modding tools and related stuff so that people can build and extend the engine.

@Arctan95

Ай бұрын

@@DouglasDwyer Sounds ambitious! Though you're clearly a very proficient GPU programmer, good luck to you!

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)

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!

@chris-pee

2 ай бұрын

Reportedly a brickmap of individual 64x64x64 octrees can also give great results.

@Caellyan

2 ай бұрын

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.

@DouglasDwyer

2 ай бұрын

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

@DouglasDwyer

2 ай бұрын

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.

@Maxjoker98

2 ай бұрын

​@@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

@DouglasDwyer

2 ай бұрын

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

wow this looks amazing

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.

Incredible! 😮

11:10 Looks even more nostalgic really.

Duuuuuuuuuuuuuude this is awesome. All these voxel games 😊

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.

How do you handle shadows? From the video it sounded like you're doing 1 ray per pixel (find which voxel, find if obscured from light), but the demo doesn't appear to be working that way, as it's resolving 1 ray-per-voxel, i.e.: each voxel is either in shadow or in light in it's entirety. Did I get the wrong impression about how it's done, or is there a decision / optimization at play here? If you are actually sending out a shadow ray per-pixel rendered after finding the hit voxel, I'd expect the shadows to be sharper (since their detail is tied to the render resolution) and the sun movements to result in smother shadow movement. But if there is an optimization in play (i.e. a per-voxel shadow mask) that is computed separately from rendering and looked up, or simply that to fire the shadow ray you're using the same position per-voxel regardless of where the voxel was struck I could see how the current behaviour came about. The later option though would mean that you're firing multiple rays per voxel for lighting and ignoring all but one result, but I could be wrong.

@DouglasDwyer

2 ай бұрын

It's currently the last thing you mentioned - firing out the same exact shadow ray for every pixel covering a voxel. In the future, I will find a way to average the results of pixel lighting across entire voxels. This will eliminate the redundancy of casting the same ray multiple times, and allow for the implementation of Stochastic effects like ambient occlusion :)

Wow, this is so cool!

This is so impressive dude! Is the brick tree only a 2 level tree? How do you handle off grid voxels and all that? At a high level obviously.

@DouglasDwyer

Ай бұрын

Here is a rough diagram of my rendering data structure: imgur.com/a/P5cldl2 It's a bit outdated - I now use linear arrays rather than linked lists to store objects. In short, my voxels are organized into 256³ chunks - so each chunk is a 4-level 64-tree. Non-grid-aligned objects are stored as a list of indices on each chunk, and are ray marched independently before ray marching the main chunk :)

@JosephGleespen

Ай бұрын

@@DouglasDwyer Man thank you for this, I love seeing how other people imagine solutions for these problems, very cool!

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!

11:08 super cute, love it

This video was great

Very cool dude!

As always, excellent informative videos! I've implement a voxel raymarching engine which uses a octree of voxel volumes. Do you know of a good online source of information about how to implement the bitmask "leaping" technique? I already have "leaping" being done via hierarchical DDA's, but I may be able to optimize that further with bitmasks. Any help would be greatly appreciated. Keep up the great work!

@DouglasDwyer

2 ай бұрын

I don't know of any online resources - this is tech that myself and others have been developing ourselves! If you want to talk about it more with me, you can join Gabe Rundlett's Discord. I am pretty active in there and we have had some good discussions about it.

@teknologicus

2 ай бұрын

@@DouglasDwyer Thank you for offer to join the Discord discussions! I may join at some point. I tinkered with adding bitmasks to my code to help further optimize leaping/skipping empty space last night and realized the way I'm currently ray marching through my octree of voxel volumes with hierarchical DDA's would probably not benefit in performance with the addition of bitmasks. However, I will give the bitmasks more thought...

@teknologicus

Ай бұрын

@@DouglasDwyer Do you have a version of the "Church_Of_St_Sophia" map in MagicaVoxel format you could share? I see there is one in MagicaVoxel format on the TeardownMods website, but I am unable to activate a newly created account due to never receiving activation emails. (I tried it with two different email accounts.) P.S. I'm implementing a tetrahexacontree in my voxel raymarching engine for better performance. :)

@DouglasDwyer

Ай бұрын

@@teknologicus I have uploaded a copy of the original .vox in the folder linked in the description

@teknologicus

Ай бұрын

@@DouglasDwyer Awesome! Thank you so much!

Looks great ! I'm not an english native and not a dev by any mean so I might have missed something in the video, but I was wondering after toying with your mod if you would be able to make a "scale factor" that increases the further a voxel is from the camera, instead of doing the entire screen ? So that tiny voxel cubes we can barely see can be regrouped with other voxels nearby, to make a bigger cube. Hopefully this can allow less calculation to be done afterwards for lighting, "painting the scene" :) Maybe even simplifying physics if the calculations uses big cubes instead of doing it voxel by voxel. Or a combination of both (rendering tiny voxel cubes while doing all the calculation with cubes 2/4/8 times biggers) ? I honestly dont know, like I said I'm not a dev so it's just wild guesses. But that's what I'd personally do if I wanted to improve performance :D

@DouglasDwyer

Ай бұрын

Yes, your idea is an excellent one! This is called a level-of-detail (LOD) system and I actually did implement one in the renderer (if you look at the montage about 30 seconds into the video I think that you can see it working). But I haven't hooked up the LOD system to the world generator/manager yet, meaning it doesn't work in-game. I am currently adding that feature now!

@Tideroo

Ай бұрын

@@DouglasDwyer Nice ! Thanks for the info. Can't wait for the next video to see more about it :)

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)

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.

6:10 You said GPU memory is reeeally slow.. Im curious which GPU memory tech were you referencing? I know the top end consumer cards use GDDR6X while Workstation cards use the slowerGDDR6. What kind of memory exists that is superior or works best? Is it better to have more memory, wider bandwidths, lower latency? Honestly, I have very little knowledge of this tech and just saw a few videos recently and just got interested in this area of development. I make stuff with tools that exist I have never looked under the hood of how it works.

@DouglasDwyer

Ай бұрын

Thanks for asking such a well thought-out question. Of course, there's no such thing as objectively fast or slow. I was generalizing in the video, but what I meant to say precisely was: "random access memory reads are much slower on the GPU than any other operation, and they are much more expensive than memory reads on the CPU." The longer answer is that memory performance varies widely across cards. GPU memory is designed to be high-bandwidth, with the tradeoff that it is also high-latency. High-end GPUs have much faster memory than low-end or integrated GPUs. For cards produced in the past 10 years, a random-access memory read can take between 300 to 800 clock cycles. That can be mitigated with optimal cache usage and latency hiding, but it's still much worse than compute instructions. On my integrated GPU, if I do more than ~20 memory reads per pixel, the frame times start to drop. This is in contrast to the CPU, where you can do millions of memory reads per frame and be just fine. As such, reducing memory reads is an important part of GPU algorithm design.

@SubzeroBlack68

Ай бұрын

@@DouglasDwyer Ok I'm starting to get it. If you have time for this hypothetical I would appreciate it.(Just a silly question, really. There are still some gaps in my understanding so this question may not even make sense, but I would appreciate some enlightenment.) In the past or on servers, there exist dual processor platforms. (2 Cpus in 1 computer). If a computer can allocate the processes and reads efficiently would those types of configurations work better for this instead of a powerful GPU. You know what... Perhaps I should think this out a bit more lol. Even I am seeing some potential issues. I am just really curious what kind of technology would be needed to create a super fast and super optimzed Voxel engine/game that is on the scope of... Let's say tech jump from SNES to N64. something that completely blows current limitations out of the water.

@DouglasDwyer

Ай бұрын

The thing about GPUs is that they are very good at executing the same code on many pieces of data at once. Even though the speed of a thread on the GPU is slower than a CPU, and memory reads are also slower, GPUs can execute tens of thousands of threads at the same time. For tasks that are parallelizable, CPUs (even a multi-CPU setup) can't really compete with that :)

@SubzeroBlack68

Ай бұрын

@@DouglasDwyer I appreciate the responses. They have been extremely helpful. I hope you continue to make great progress on your projects and channel.

How does performance compare to Teardown? Is it already on par? Because I am running into size constraints with my really bloated Teardown map I’m making.

@DouglasDwyer

Ай бұрын

I'm not really sure that I can give a comparison, since performance depends on things like number of objects, the number of rendering effects used (Teardown has a whole bunch of post-processing effects, while I just do one forward render pass), and the like. Still, the performance is quite good and it can definitely run on the same hardware that Teardown does.

Man keep It up! The best voxel engine will be the one that gets published

@DouglasDwyer

2 ай бұрын

Haha definitely

This looks cool