Codebase OVERHAUL, new EVENT SYSTEM, LODs, and MORE [Voxel Devlog #9]

[@ttj_]

loving this style. your engine is coming along so well. i’d love to see a video where you further delve into rasterization with greedy meshing and seeing the performance impacts of it!

[@LegoDinoMan]

Each time I see this engine it blows my mind. The amount of effort and hours you've dedicated to this project is incredibly impressive.

[@sa-hq8jk]

i like the informal conversational style better. it comes off as more natural. also insane how much work you’ve done in only a month. keep up the good work!

[@sjoerdev]

This is your best devlog so far imo

[@MountainLabsYT]

Gosh 0:15 looks so satisfying.

[@GiacomoPerin]

light theme vscode, you are truly an amazing programmer

[@w花b]

Not using c++ too, truly based indeed.

[@egedq]

@@w花b writing cutting edge game like this in Rust is truly based, very inspiring...

[@lukepowers8122]

This is a really cool project, and I love all of the optimizations. I'm also making a voxel engine, and its an incredibly difficult journey. Its pretty funny how many people are trying to make voxel engines right now, yours seems the most developed and promising though.

[@undefdev2239]

So nice to see progress on this! Have you thought about making physics somewhat like Noita's Falling Everything physics engine?

[@DouglasDwyer]

I'm not particularly familiar with Noita, but I would love to have a physics simulation that allows any voxel object to interact with gravity (so that trees don't float like in Minecraft). I would probably accomplish this via some sort of 3D connected component detection whenever a user edits a chunk.

[@haiperbus]

new Douglas update, ya love to see it

[@jonyleo500]

I would love to see (or do it myself if the code is open source) a proper comparison between greedy meshing and parallax raymarching.

[@HickoryDickory86]

Got a question for you: Have you ever heard of Tom Mulgrew here on KZbin? About a decade ago he was putting up videos of his voxel/polygon hybrid engine. From the camera out to certain distance, the engine would show rasterized polygons. Beyond that distance, it would switch to voxels. It was tuned so well that you could not see a difference between the two. It was great! I have no idea what he's done with it now; but I do know he was using CUDA, because the voxels were stored in a sparse voxel octree. Anyway, I was just wondering if you might be interested in doing something similar, but using your parallax raymarching technique, etc. And if you can't tell by what I'm sure are inaccuracies with my descriptions, I know very little when it comes to rendering and software development. I just love watching these kinds of videos out of pure interest. But even with what little I know, I can tell you are extraordinarily talented and doing great things here. Please keep it up.

[@DouglasDwyer]

I hadn't heard of Tom Mulgrew before, but I had a look at his work and it's very interesting. Thanks for sharing! Indeed, I might continue trying to integrate some ray marching approaches into my work. For now, though, I want to keep things simple and start implementing more effects like lighting and multiple objects. Greedy meshing seems like the simplest way to pursue this, while still being performant (and allowing a wide range of devices to run the game with varying LOD settings).

[@thomasmcbride2287]

Love the style. Very entertaining 10/10 would recommend :D

[@СергейФёдоров-щ8ш]

Great job! The event system is a very correct decision. I also wanted to do it once, but I was too lazy) You are great!

[@Vextrove]

Awesome video

[@darkandblue4118]

Would be interesting to have the sky with voxels too. But it needs to be drawn at a fixed voxel size in an infinite distance.

[@valovanonym]

So how one would achieve that? It would mean rendering an infinite amount of voxels?

[@darkandblue4118]

@@valovanonym not an infinite amount. I just mean that the sky should be rendered at a fixed distance while the voxels should keep the same size.

[@DouglasDwyer]

I would definitely like to have a more detailed sky (with a sun, stars at night, etc.) in a voxel style rather than one solid color. I'm assuming that this is what you mean? My plan at current is to just render a pixelated skybox that fits with the rest of the scene's visuals. Let me know if you have any other ideas on this!

[@LiamNajor]

I have done some experiments in a THREE.js voxel engine, and making any kind of mesh follow a camera is a lot more challenging then you'd expect

[@wrldfrice]

nice to see the progress, well done!

[@Vextrove]

I recommend making a game where the player character isn't two blocks tall, but much larger

[@DouglasDwyer]

That's the goal! :)

[@Vextrove]

@@DouglasDwyer It would be quite interesting to me to see what it'd feel like

[@Vextrove]

​@@rayzorpaid4 Not really, it depends on how big objects in the world such as trees and hills are

[@krish-ut9de]

you are a hidden gem

[@Conlexio]

awesome :]

[@Conlexio]

does pure rasterization see more benefit to the LOD system than your parallax ray marching? i’m assuming with raw ray marching LOD won’t impact performance too much so i’m wondering if raw rasterization becomes less comparable when LOD is disabled

[@DouglasDwyer]

That's a great question - I haven't actually done a side-by-side profile of raster versus parallax marching with LODs enabled for both. However, I was having some performance issues with parallax marching even at low draw distances, so I'm inclined to believe that it would be the same performance at best. I would like to investigate this at some point, because I invested a lot into the parallax marching approach. I will say, one thing I like about pure rasterization is that it's easier to maintain (the code is simpler and there are less hiccups when it comes to things like maintaining a Z-buffer).

[@DouglasDwyer]

The nice thing about my engine design now is that it's easy to swap out various rendering techniques if I ever want to do so!

[@TinkerHat]

okay this is exactly what i need, when will the engine be public for use?

[@Sammy-ws9re]

This looks awesome! I wish I understood what you were talking about. Especially with the parallax raymarching. Do you plan on making a discord server or something of the like?

[@CSPciccionsstibilepippons]

how is it possible to update 256^3 chunks in real time using greedy meshing!? 😯👍

[@DouglasDwyer]

Chunk updates are accomplished in realtime using three key optimizations: - Voxel data is represented in an octree, which allows for efficiently identifying surface voxels and converting them to faces. - The greedy mesh output is cached after chunk generation is complete, and parts of it are re-used when a chunk is edited. - Multithreading is employed so that when multiple chunks are modified their meshes are recomputed simultaneously.

[@sgmvideos5175]

discovered you few minutes ago, great job, I wonder how much this project was inspidered by john lin's engine (it's sad it died, it was looking so awesome)

[@Dedinside-l7n]

Great job!

[@valet_noir]

amazing !!!

[@lemonke8132]

Impressive as always! How are you able to write such complicated code (like network/event systems or rust game engines) from scratch? I feel like I have to follow a tutorial or else I have no idea what I'm doing.

[@sechmascm]

I don't do Rust, but in any programming language you want to start figuring out stuff without tutorials. You can do this in many ways. First step would be to take a tutorial and modify it in small ways while looking for the answer online. Could be the documentation, forums, etc. You want to get a simple idea and research how to do it. If you regularly poke around the docs and stuff you'll find methods or functions that will make you go: "hey, I could do that other cool thing using this. Let me try it out." Most functions in the docs tell you exactly what they do, and what they take as inputs, so it's easier than looking at tutorials, which may skip explanations or use cases for many functions. Another way, is to start really simple like with pong or generic platformer #12138496198411287. You'll quickly fall down the rabbit hole of making your jump feel nice. Different gravity for falling so it feels like the character has weight, coyote timer, allowing to jump a few ms after jumping if falling, and extras like double-wall-other jumping, sliding, climbing, then attacks, then enemies, then levels, collectibles, goals, difficulty, etc, etc.

[@DouglasDwyer]

This is an excellent question, which I think can be answered from a few different perspectives. The other commenter, S, is spot-on correct when it comes to building one's programming experience. The best way is to learn by doing! Start with some goal or project in mind - like building a platformer - and then follow tutorials that each contribute a piece to that puzzle, like a tutorial for how to make a jumping player, or a UI, until you have a working game. Another perspective on which I'd like to comment is how to produce and maintain an ever-growing codebase. Complicated code is not easy to write, even for me - this video, where I change everything, is perfect evidence for that. Another key skill, which is gained through experience, is learning to modularize one's code (keeping the graphics and networking systems separate, for example). If you keep your code modular, it's easier to debug and add new things. This is another thing I worry about when writing complex software from scratch. All in all, I think it does come down to experience and learning by doing. But everyone starts from the tutorial stage at one point or another! So my recommendation is to choose a reasonable goal of what project you want to build, and then attempt to use whatever resources possible - tutorials, docs, and the like - until you've accomplished it. As you build upon and *extend* others' work, you'll become more comfortable creating unique content.

[@boredastronaut78]

Writing complex software is difficult. Like anything difficult, you learn through a mixture of study and practise. However, there are a manageable number of simple concepts underlying all software. Once you have an intuitive understanding of those concepts, it becomes easier to understand entire programs, no matter how large and complex. This is why you study theoretical computer science, which concerns itself with the fundamental concepts that define the fundamental nature of programs and computation. The majority of the concepts involve structures or behaviours. Programming itself involves translating these ideas into source code for specific tasks. One of those concepts is hierarchy, and a common example is the use of functional decomposition, which appears everywhere in software. Douglas demonstrated it in his rewriting of his event system to use hierarchical dependencies. Tutorials often teach specifics of the craft-mostly about programming languages and APIs-and maybe even some applied theory. But they rarely touch on the fundamental concepts. But these are essential to evolve from beginner/experienced to advanced developer. You need them in order to successfully build very large complex programs, the kind that have many different subsystems, that do different tasks that must be integrated together. A game engine that handles graphics, audio, UI, input, networking, physics, game logic, file management, re-uses fundamental software design principles throughout its subsystems, enabling the system designer to manage the complexity.

[@krish-ut9de]

so coollll

[@infernoplayzgames1684]

Where did you start with when you began writing this engine? I want to make one myself but don't know where to start.

[@DouglasDwyer]

Much work on the engine has involved integrating different concepts, including 3D graphics, networking, octree algorithms, and more. I think that it's important to learn about each one of these in turn, so I'd recommend picking one area with which you're unfamiliar and working on THAT part of the project. If you're looking to work on 3D graphics in particular, I highly recommend learnopengl - it's a great tutorial series for all levels of programmers. There are similar resources out there for other parts of game engines. The most important thing is that you learn by doing! See also the following reply on another comment for this video. The commenter does a great job of describing how to build up knowledge by following tutorials, and then attempting to implement new/unique features on top of them: kzbin.info/www/bejne/j4KbZIucj7Z7fqM&lc=Ugx8bR15w00QkXtopB14AaABAg.9k86iH6brPV9k8EorfJPB0

[@infernoplayzgames1684]

@@DouglasDwyer Sweet thanks!

[@infernoplayzgames1684]

@@DouglasDwyer Do you have any good resources I can use to learn opengl?

[@DouglasDwyer]

As I mention in my other comment, I think that learnopengl.com/ is probably the best resource out there :)

[@krish-ut9de]

i really want to see efficient water physics

[@memyselfishness]

I really did enjoy this style to the old ones, but maybe that's because you had less to show off?

[@DouglasDwyer]

Glad to hear it. This new style was easier to produce as well, so I think that I might continue with it in the future. Thanks for the feedback!

[@Dongcryto_8488]

Voxel coin??

[@benrex777productions9]

I'm in favor of any video style which is easier to make for you and is still pleasant to the eye. Making videos should not be a drag.

[@BanditBloodwyn]

Two things I wouldn't have done: 1. Creating more system dependencies always is a bad thing to do. Refactor one system and you might have to change every system which is dependend on the first one. 2. Do not use inline comments in your code. They will be ignored most of the time, sooner or later. You should try to use code based naming instead. For example by extracting code blocks out into separate methods and/or classes (which have good descriptive names) and by using descriptive variable names.

[@DouglasDwyer]

Thanks for your feedback! I think you raise two good points; excessive dependencies are not great and inline comments may be ignored. Let me try to clarify for you how these relate to my project: 1. Of course functionality should be modular and self-contained. But I would argue that, in my case, this is exactly what a dependency system does. When functionality is separated into a DAG of dependent modules, if you refactor one (as long as no changes are made to the public-facing API) you don't have to refactor the others. It's like using a Java interface; the implementation details change but consumers of the interface don't. 2. Those are Rustdoc comments, so they're treated specially. They are converted to HTML documentation pages and also show up in the IDE when you hover over items. It's the standard way of documenting Rust code :)

[@BanditBloodwyn]

@@DouglasDwyer Ah I see. Yes, in my way of thinking, "refactoring" often means changes in the public interface. As long as this doesn't change, you have no problems. And yes, I don't know anything about Rust, so if your inline comments contribute to the HTML docs, they have a right to exist.👌

[@dpdbpdbpdbpddpdpddbbbdpdbdppdp]

very good!