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

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.

Not using c++ too, truly based indeed.

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

That's the goal! :)

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

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

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

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

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

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!

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

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.

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.

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.

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!

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.

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

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!

Indeed, on desktop, it is possible to change the swap interval dynamically. However, I am also targeting the web. In WebGL, the only way to hint that the browser should use VSync is to pass the desynchronized context attribute during WebGL context creation; you cannot change it afterward. Perhaps a better example, which is true for both web and native, would be antialiasing - as far as I know, you cannot change whether multisample is enabled on the default framebuffer once the window is created. Having a reloadable graphics system has other benefits as well, like allowing the user to switch their active GPU at runtime. Nonetheless, the information that you provide is good to know - anyone developing a desktop game need not worry about changing vertical sync. Thanks for your comment!

@@DouglasDwyer Oh wow.. I was ignorant of WebGL's state and its relation to the browser. Didn't know it was this bad on the web side.

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: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-YQ83XfZQHHA.html&lc=Ugx8bR15w00QkXtopB14AaABAg.9k86iH6brPV9k8EorfJPB0

@@DouglasDwyer Sweet thanks!

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

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

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

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