I would positively love to see a solely-GPU physics engine! Many things, like the separating axis test, would lend themselves well to parallelization.

That's a great idea! Because transparency happens in a separate render pass, I should be able to sample from the solid render target. This could allow for screen-space reflections or underwater refraction :)

Heat waves too I'd think. 🤔

Makes sense to avoid having to start all over again from the root of the tree. Have you tried ray packets by any chance? I'm used to using them for raytracers but never tried for volume ray marchers. It seems a bit tricky to use them combined with your optimization since each ray in the packet might want to resume from a different node in the tree.

@@darkengine5931 have not but I'll be looking into that now

Thanks for your kind words :)

There are two main reasons for this. First and foremost, it was an "artistic choice" to mirror the style of Minecraft transparency. I want to allow people to create thicker glass windows and sculptures, which I fear would appear noisy and majority-opaque if I used volumetric transparency. With the shell approach, users still have the option to create volumetric transparency by layering different materials, which will both appear even on inner surfaces - but by default, it's easy to create thick glass windows. Second, it does help with performance, because there are typically less details to draw :)

@@DouglasDwyer That makes sense. Thanks for the response!

Depth-peeling is an intriguing technique, since it allows for exact results without triangle sorting. However, it places a very heavy load on the GPU (requiring multiple extra render passes and textures). As I want to target lower-end GPUs, this fact made me choose against it.

he said that he would

@@christopherbroms2508 epic

Thanks for watching the video! Let me give you the details: 1. No, I switched to targeting OpenGL about a year ago, in Episode 4. This was because I wanted to make my project usable in a web browser, and playable on a wider variety of hardware. It was a tradeoff for portability that I made for my specific design goals. I still do miss Vulkan and its modern features, though. 2. Performance would definitely decrease. For projects like this, achieving good performance means fine-tuning to one's specific use case. As I've designed my engine to work at the scale shown in the video, I fear that it wouldn't run well with larger quantities of voxels onscreen. That's not to say rendering more voxels is impossible - it would just require more engineering and special use of LODs. Dealing with that much data voxel data has consequences beyond rendering, though - I also need to sync voxel objects over the network and store them in-memory, so it's a delicate balancing act :) 3. I don't have a Discord server - unfortunately, I simply don't have the time and willpower to manage one. However, there's another voxel KZfaq called Gabe Rundlett who's working on some really cool tech. He has a Discord server where myself and a number of other people talk about voxels, so you can reach me there if you'd like!

No problem - I love answering these questions, it's why I make videos! 1. Yes, there are some other people working on voxel engines. One such individual is Gabe Rundlett - definitely check out his channel if you haven't! His voxel engine is open-source, unlike mine. John Lin, Voxelbee, and some other KZfaqrs are developing engines as well. I'm not aware of anything that's been completed, though. That's part of my motivation for working on the engine! 2. While many of the above-mentioned KZfaqrs provide inspiration, I don't have as many resources to provide regarding technical help. Do you have any specific areas of voxel engine design that you'd like to learn? There are so many topics - rendering, networking, audio, storage, and the like - which is part of what makes engine development so fun. If you're interested in rendering voxels, the first place to start is probably learnopengl.com. The website provides a stellar introduction to computer graphics :)

@@DouglasDwyer I can't believe it, I never expected such a detailed response, thank you so much! You went above and beyond my expectations, and now I'll start exploring the channels and resources you recommended. I already joined the Discord server! I'm absolutely convinced of the success of your project, and I really don't want your idea to die at the stage of creating a game engine, as it happens so often

It may give an nice ray tracing touch!

Thanks for the question! Another commenter asked something similar, about why I chose to make transparency be "hollow." This was my response: First and foremost, it was an "artistic choice" to mirror the style of Minecraft transparency. I want to allow people to create thicker glass windows and sculptures, which I fear would appear noisy and majority-opaque if I used volumetric transparency. With the shell approach, users still have the option to create volumetric transparency by layering different materials, which will both appear even on inner surfaces - but by default, it's easy to create thick glass windows. Second, it does help with performance, because there are typically less details to draw :) Regarding whether it would be possible, it probably would take some additional work. I wouldn't implement it for normal voxels, for the reasons above. But I would like that kind of effect for water!

Sure! The lighting is a standard shadowmap, as described on learnopengl.com/. To make the lighting appear per-voxel rather than per-pixel, I just round the position at which I sample the shadowmap to the nearest voxel.

Ah i see, I want everything to be per voxel including reflections, but I cannot get any good working method.

@@DouglasDwyer real smart, utilizing what gpus accel at (rasterization) and combining that with existing techniques with a twist

I think that it depends upon your goals! If you're looking to make a game with a voxel art style (or even a game with editable, Minecraft-style terrain) then Unity is an excellent choice. Its batteries-included engine makes it easy to develop gameplay and other fun concepts. This is at the expense of flexibility, though - if you're looking to create a highly-detailed voxel environment (like myself or some other KZfaqrs), then it's probably necessary to build your own engine. However, that takes a great deal of time and dedication, and it's a lot harder to make a feature-complete game. So choose whatever best fits your aspirations :)

@@DouglasDwyer Thanks, ya unity definitely struggles when you make the voxels smaller then minecraft

Unity allows you to create custom meshes, so you can probably use a greedy-meshing algorithm to speed things up.

@@bluesillybeard i just dont think i would have the time to learn greedy meshes and deal with all the bugs from it

I target OpenGL and WebGL 2.0 so that my engine can run in a web browser. However, I am hoping to switch to WebGPU soon - it is a more modern and ergonomic API that will soon be a browser standard.

​@@DouglasDwyer and the CPU code is Rust as far as I can see :) So you have some experience in writing a rendering engine. What would you say if someone (not me haha) wanted to write his engine in C#? Notice that he tries to make everything manually disposable (via the IDisposable interface), so he can avoid the automatic garbage collection, which can cause stuttering) as good as possible.

@@banditbloodwyndevs8782 I think C# is a fine choice - in fact, my engine started out in C# (see devlogs 1-3). You'll never be able to achieve the performance of a native language, unfortunately - in my testing, I've found that Rust and C++ are about twice as fast. This, coupled with the fact that C# doesn't run well on the web, was why I switched to Rust. That being said, C# is a great backend language and very good for writing business logic. So if your primary goal is to create a scalable application with many features, C# should be fine. For any heavy calculations, though, you might need to offload to native code or the GPU. Regarding optimizations, I think the biggest thing is avoiding heap allocations entirely. So your primary goal should be to use structs, not classes, wherever possible. If I recall, you can implement interfaces on structs - so using IDisposable with structs might be a powerful idiom. But C# is not at the point of being as fast as a native language.

@@DouglasDwyer good points. So one last question: In C# we have projects to organize large solutions. Let's say I switch to C++. There we don't have projects. Do you know an easy and elegant way to organize the code in a similar way beside of simple namespaces?

Depending upon your build system, you can still have separate projects with dependencies - I believe that MSVC allows for this, at least. That said, C++ build systems are a nightmare, and I would recommend against them for productivity's sake. Much better to use Rust and its package manager Cargo - which allow you to easily separate your workspace (solution) into multiple crates (projects).

I would love to have fluids in the game at some point. However, I have some other priorities - such as rigidbody physics, multiplayer, and gameplay - on which I want to focus first.

Yes - in fact, chunks are positioned in a 3D coordinate system already! There's no build height limit.

Hey, thanks for watching! I appreciate your honest feedback. If I could ask, what exactly is bothersome to you about the mic? Granted, it definitely sounds bad in my earlier episodes. In the latest few, though, I've managed to eliminate noticeable artifacts like clipping. Truly, it sounds fine to me. What should I improve?

@@DouglasDwyer Your audio seems a little echoey, and a bit distant. I'm going to assume it's a standalone mic and not inside a phone or laptop. If you want to make the most of your mic, first you'll want to stay within 2 feet of it. Next, you'll want to prevent your voice from bouncing around the room, the best way is to have something soft like a blanket surround your setup. This is why some people record in a closet with lots of cloth in there. You can also try comparing your audio to a clip of someone testing their studio quality mic and see how close you can match theirs. I hope any of this can result in some improvement, but your audio has gotten better recently, but your current audio quality doesn't subtract from the videos or your project! Good luck ^^

Right now, I'm aiming for the scale that Minecraft *would have* if every single voxel were editable. This would mean a scale of 16-20 voxels per meter, since in Minecraft there are 16^3 voxels per block :)

While there is a public demo, the project isn't open-source at present. I'm still working on refining the technology and turning it into a playable game :)

i personally don't mind, im here for the info, and its not distractingly bad