Making my Voxel Engine faster

I'm making a voxel engine with RUST! (the programming language...)
I originally was making my voxel game with Unity, but my love for the Rust programming language caused me to see if it's viable to swap over to that.

This episode is all about optimizing the code for the world generation.
Multithreading, benchmarking, profiling and data compression, are all things I've tackled with lately.

My discord group:

Want to support me?
XMR:
43Ktj1Bd4Nkaj4fdx6nPvBZkJewcPjxPB9nafnepM7SdGtcU6rhpxyLiV9w3k92rE1UqHTr4BNqe2ScsK1eEENvZDC3W1ur

timestamps:

0:00 hi
0:43 Tantans mixtape: gotta go fast

0:55 video layout
1:33 world generation
2:58 what we need to optimize
4:04 queue
4:37 multithreading
7:27 benchmarking & profiling
9:39 Generation settings for my pc
9:58 problems
10:26 Unity VS Rust
11:09 pain
11:22 the winner is
12:11 data compression

Resources:
The tech I'm using!

The tutorial I followed to learn wgpu:

Relevant resources that may help when learning how to make a voxel engine:

Voxel Game Mesh Optimizations by @Hopson

I Made Minecraft in 24 Hours by @Sam Hogan

Making Minecraft from scratch in 48 hours (NO GAME ENGINE) by @jdh

[Tantandev]

I can't thank you guys enough for the support!
my discord group:

[stevenchristy]

Practical optimization is two parts memory allocation strategy, one part algorithmic complexity with maybe a little knowledge of CPU caching thrown in. Ideally you minimize the number of memory allocations and adopt algorithmic approaches that bring you as close as possible to O(1). Got a loop that does 1 million allocations, first start by doing one allocation of a million instances and your program will gain performance increase in orders of magnitude. On the low end once you've addressed allocation strategy and algorithmic complexity you can eek a little bit out by removing or simplifying calculations, or finding opportunities to precalculate, etc. Throwing more threads at your code is not optimization. Keep in mind that a modern CPU-core executes billions of instructions per second, and the reason your code runs so slowly is because the CPU is effectively idle waiting for other tasks. Throw more threads at the problem without fixing the underlying cause is not optimization and will only compound the problem. Fix the underlying problem first, then once you have a sleek fast implementation, make it parallel and you'll unlock the true potential of the hardware.

[krtirtho]

I feel bad, your devlogs being so underrated

[barj]

Tantan really dipped for a month a wrote his own engine lmao

[TylerGreen]

Your devlogs have to be one of the most underrated on this platform. Awesome job and love the song!

[JeremyChone]

Your videos are as addicting as coding Rust. Thanks for those super high quality content and format.

[SmoothieBuns]

Our favorite rapping/didgeridoo playing Swedish coder is BACK.

[RisingFoxGames]

This stuff is so interesting, I love your video style. Didn't even realize the video was 16 minutes long.

[scotthooper]

I wrote something similar in Java and later C++ years ago, but went farther, with ambient occlusion, textures, some variability on lighting, proper shadows. I then started to convert it to Vulkan and lost progress as life got in the way.

Compression of those vertices is critical, but I recommend you skip the unnecessary bit fiddling and just use bytes for relative x, y, z, and another byte for your "face" (normal).

Another key is to reduce geometry by making things like texture and brightness (from MC-style falling light, or ambient occlusion) dynamic so that you can ALWAYS mesh large flat areas into simpler shapes (with simpler geometry than it would be if you used one square per cube). I found moving brightness to textures and using a binning system was optimal.

Good luck! I had a TON of fun working on my system!

Oh, and be sure to use ambient occlusion, render front-to-back, and if you can, render down the primary, secondary and finally terteriary axis. That was my last improvement, and it made a huge difference in eliminating invisible geometry.

[DrIngo]

Using any kind of println!(...) or similar console output for debugging will always slow down your program. Also, did you test your Rust code in a --release build or a debug build (default when you run cargo build/run) against whatever Unity is doing by default 🙂? You didn't mention, so I thought to ask.

[oglothenerd]

Now that I am making a voxel engine of my own, these videos are so helpful! Thank you!

[thor-grey]

Just found your videos recently and I love how you show your code with the highlighting, different angles, and smooth transitions! Appreciate the work you put into making these high quality devlogs!

[MarcusIlgner]

Impressive that you manage to not only do all that work on the game and engine but also create this high-quality video content!
Keep up the good work! For a one-person-army these are some really impressive results!

[Zac]

nice video! i rly liked that you talked about bitwise operations, it's such an interesting topic, this video is amazing as always, can't wait for the next one

[zolaire]

Watching your videos gives me energy, thank you.

[Khud]

Here I am, googling how Minecraft chunk generation and world saving (anvil file format) work in the morning, and in the evening Tantan releases the most comprehensible take on it ever. :D

[kjpg]

Great work! Really sells the difference between the two engine approaches. One pain point is that Perlin is a very visibly square-biased function for noise. There's a sort of vicious cycle in the PCG community where it's taught far more often than the alternatives which address its issues, and far too often not in the context of techniques which mitigate its issues. As resource creators we should strive to teach the best possible information, and this is an area that really needs it. Best of luck with your channel!

[AlexandruEnex]

These are a joy to watch. I want that profile & optimize song on spotify :D

[willlacey]

Just stumbled on your channel! ABSOLUTELY LOVE YOUR CONTENT. Great work 😊

[AntonioNoack]

@15:24 you can make the code easier to read by writing (pos >> 18) & 63 instead of (pos & 16515072) >> 18

and also storing colors as floats? do you really have a 10 bit display where that would be of any use? use 8 bits per channel, at max