Video

I think your memory layout can probably benefit a little from ordering by which stage of execution needs the direction. The newer CPU has a better cache and branch prediction, and that's why it outperformed on the culled renderer. The greedy mesher caused it to stall more, so these advantages were likely nullified. Your greedy mesher seems to tax the cache a lot - your blocks are 32x32x32 bits (right?), and interleaved in triples; but it could be better to somehow make them fit into 64x8=8x8x8 bits (64 bytes, a cache line) for each of their core operations. So, making the block smaller by a factor of 2 to 4 in every dimension AND ordering the memory according to execution order / ordering execution to be doing operations on directly adjacent memory blocks directly after one another could probably give you another big boost.

7:41 Uh StdDev and MAD appear to be faster though? A picosecond is smaller than a nanosecond, 1000th of it to be exact. Even when their results entered nanoseconds in your example they appear to have been roughly 150-155 times faster.

4:55, I'd like to make different suggestion that isn't so memory hungry. To start with, yes every block type shares the same map area. When the game 1st boots it also produces the very first binary map, doesn't matter what type, only that the types are looped through in order during this. You might need some additional binary maps depending on how faster the mesher is vs the binary mapper. Every time you finish one binary map you permit the mesher to go through it, whenever the mesher does this it recends it's right to do so at the end by putting it back in the pool of maps to map to. This way you have at most a few dozen maps to use for any number of block types. It all depends on how many potential block types can be assigned to the same map. So if you're map is say 8x8x8 then you have at most 2048 potential binary maps to make. Let's be real, that's only going to happen if the player is allowed to place block types and the player happens to be a limit pusher of some kind like "let's game it out".

For non-programming people programming looks like magic, but for me graphics programming looks like magic :D I wish i will have enough courage to learn it someday

You lost me a rust, legit 18 seconds in

What glider game is shown at 1:47? It looks beautiful

At least it gave you an amusing outro

Crying rn that Lua was only B tier to you 😂 Great beginner language imo (no reasonable person likes indented languages, Python.) especially since it’s the staple of Roblox, which very well means it’s introducing programming to the youth, and that’s always welcome.

Misread the title as "Racist Multi-Threading Code Review". Seemed a curious thing.

A true tool for coders, while we develop games we can share our plugins. Yes, Godot is great and will become much better, but it is not the best tool for coders.

I program on Mac and don’t use dlls (dumb language libs). How does one get around this?

Great video, thanks for explaining it so well! Just started making my first game in Godot, when I suddenly learned about ECS. Since I love Rust, I was extremely tempted to switch over to bevy, but the lack of an official editor is a deal breaker for me as a complete beginner. I could do it the hard way, learning game dev entirely with bevy. I'm sure that would make me a better dev in the end. As complexity grows, existing abstractions you import through frameworks become too limited and you need to dig deeper. In Godot I already had to ditch the particle system and handle that myself due to engine limitations. That's why I love love love that bevy has such loose, almost nonexistent boundaries between the game engine and the game you make using it. If it's all Rust, it's so much more ergonomic! I'll definitely start learning bevy relatively soon! But for now I'll stick with the extremely helpful GUI the Godot editor gives me!

Someone on the internet makes a fast greedy voxel mesher. *distant horizons 2.0 has entered chat

This was insanely interesting. I wonder if any of this could be used to optimize minecraft

If i wasn't suffering from severe autistic burnout *and* had enough focus and time to properly learn all these different optimized voxel engines i've watched people on youtube do, i'd probably already have all the info i need to construct the fastest physically possible voxel renderer with real time editable terrain

"Greedy meshing is slow…er" lol Can you do a video continuing to explore your use of this greedy meshing code with things like how to minimize the amount of additional work done when inserting and removing voxels, and how determine and what to do when a lot of voxels are changed in an area (such as blowing something up or hitting it with a 4x4x4 hammer that smashes a whole cube of 64 blocks at once)? I'm doing my own voxel engine and I don't think I can improve on your approach here, and there are a lot of problems to solve in general. (My voxel plugin is just for terrain, so it's simple; the goal is to allow the programmer to just plop blocks in the world and have it do the right thing, including handling meshing, culling of non-visible blocks, hitbox compositing, and so forth.)

Oh! Great catch. Initially in my rendering I've used 64 bitmasks, because my chunks (not rendering chunks) were always 4x4x4 voxels. Tho I haven't implemented a greedy meshing, because I need to support much more than a solid block, so different shapes etc. End up with custom rasterizer.

Cool 😎

YO THIS IS A PAPER

Offense taken.

trojan detected, don't download

When I saw the file picked I said "hmm, that looks a lot like Helix".

So impressive

3:20 i dont know, but it sounds like TCP

Is there really a need for all those flat arrays? Wouldn't the compiler allocate n-dimensional statically sized arrays contiguously anyways?

reminds me of the game, Kingdom

i want to play the gme

I imagine, there should be a way to optimise the procedure at ~3:35 so that the whole meshing step is complete in the smallest number of expansions possible (for the general case).

I wanted this video and I find

1. You're using Rust, why would you care that it's too complicated for people 2. Simdeez time? 3. I see a few temp Vecs like the one from the greedy mesher, there is probably a better way to avoid those allocations, perhaps with an `impl Iterator`(wish generators are stable) or just a vec that you pass &mut to the function so they don't have to allocate their own, or maybe you can give the function your vertex buffer and have the function append to it directly.

Blazingly fast 🔥🚀

Some things to note: You couldve navigated the Open/Save As/Open Folder dialogs entirely with the keyboard When you land on the dialog, your focus is on the file name area Press shift + tab 3 times to access the folder tree on the left and use the arrow keys to select the folder you want, expand it with right arrow or collapse with left Then press enter and the folder should be open in the folder pane on the right Use the arrow keys or start typing the name of the file/folder you want, then once the item you want is selected and you see its name in the folder/file name area, press alt + o to click the open button (or alt + s to click the save button if save dialog) Alternatively once in the right folder you can press alt + n to select the folder/file name field and type it there, to select a suggestion there (then press enter or alt + o to select) Also also in apps with menu bars you can press alt + the first letter of the menu button (like alt + f for file menu) then follow the underlined letters to select options

Make it faster.

Now speedrun vulkan triangle from memory, without storing the vertices in the shader, and selecting the memory types correctly, and ensuring validation layers are enabled but with no errors. No using vkb or vma. Edit: And no dynamic rendering

shank

So that's how devs spread dozen of weird named libraries... to get high 😂

Wait, I need speed to handle 10Billions polygons in a single mesh 😂

This guy don't need drug to get high, but coding 😂

My culled mesher in my i5 of second generation is around 0.102156ms even I got 0.0947ms

This is the same algorithm as bitmap edge detection. Shift-not-and-ing is really common in other applications 🤙

What if instead of always checking one direction all the way first, you checked all axes, and picked the one that grew the rectangle/ractangular-cuboid (not the name I remember the shape having, but it's what Wikipedia told me it's called, the generic brick shape) the most? Would the delay added by the measuring and comparison be enough to counter the faster growth of the block per-step on average?

50:12 are you a wayland user by chance?

In the beginning of the video looking the rust syntax is the reason why C is better, why make things harder for nothing why?

So what you're saying is: If your voxel data was already bools in the binary matrix of the world ... this whole thing would be 60% faster still? Since you wouldn't need the step that converts the data, right?

Whats funny about this, the more you don't use something that made everything infinitely easier the more you learn how a PC was originally designed. It actually helps people think better, problem solve especially how it helps you adapt and teach people about hotkeys, menu drops and new software to assist you and even from the beginning of the video you had stated you created something to make it easier this has to be healthy for us! (or maybe i'm going overboard and getting too excited over this minor thing lol)

Is it possible to make write this threaded? each axis having it's own thread? or somehow execute this on a gpu? Thx for the deep dive, I learned a lot!

4:50 ... the humans are dead!

Every time you say "chunk", it sounds like "shaunk"

i love everything about this your awkward presentation, the handdrawn sketches, the weird pronounciation, the focus on speed, your manbun, your long hair that makes you look like a metalhead, the jokes, the effort you made, everything, everything in this video is just *right* .

My first idea was to just bitmask. If you have a 1x4 area and want to check the area next to it, it'd be far faster and cheaper to just get the area next to it, use the first one as a bit mask over it and if there are no differences then it's all good and you can proceed. If it isn't, you can check where the differences begin and then you can discard from the conflicting side and then keep going. Okay, seems like that's pretty much exactly what's done.