Hopson, So 2 years ago you made a Minecraft game in 7 days, I’m looking forward to make a game like roblox so could you please make a game like roblox in 7 days?
@@eureptus dude making a game, even in just 7 days takes a looooong time. Besides, you can't really make a basic version of roblox due to it's multiplayer aspects and creation tools
As a fellow voxel game developer, I too find the greedy meshing article to be somewhat technical. But eventually I figured it out (or so I think): First, loop through the blocks along the X axis (at Y=0), and combine each of them into a single group until you meet another type of block, increasing extend.x while doing so. (If you meet another, just create a new group.) Then, repeat the same process at Y=1 and so on. Same goes for the Z axis. So your groups have the following fields: starting position (vec3), extend (vec3i), and the block type (uint in my case). But we haven't finished yet! Now, for each group, let's say Group 1 is at (0, 0, 0). And say Group 2 is at (0, 1, 0) - one unit above Group 1. If their extend (the amount of blocks along each axis) are the same, then combine the groups together - for instance if their extends are (10, 1, 1) then after the combination the extend of the new group becomes (10, 2, 1). Essentially, a group will ALWAYS be a cuboid with 12 triangles only. That is the basic idea of greedy meshing. You can try optimising for faster grouping of blocks (I developed mine in a day so I'm pretty sure there are a lot of space for optimisations). Besides that, I believe a basic cull before the grouping can be quite beneficial too.
Ayyy the how I optimize my voxel game too! I didn't knew this was how the greedy mesh method worked. Extending on the X axis is easy but on the Z and Y is hard and costly.
The method in the linked article is quite a bit different. Instead of working with cuboids, it deals with 2D slices. First, it looks at 2 adjacent 2D slices of the voxel grid. From them it generates a mask, which tells you where you need quads. Then it picks a first quad, and tries to extend it. When this quad is maxed out, it clears the mask in that region(since we've already filled those quads), and moves onto a next quad. This process is then repeated for all slices in the current direction. When that is done, it moves onto the next direction, so you go throughthe volume 3 times total.
@@imnotstpid Indeed it does, but it only happens if you insist to use a normal dumb graphics pipeline - with shaders (hint: floor()) you can achieve the same effect easily.
its very neat, however you have to be very careful about premature optimizations if you start doing stuff like too early it can really hurt you in the long run.
@@krubbles101 yes hopson did it at the right time, the game was having a problem and he fixed it. The problem is when you do stuff like bitpacking to optimise memory before you've even fully worked the texture/lighting/... mechanics out.
@@albingrahn5576 excellent video! Crazy to think that chrome takes >500mb of ram easily. Programmers have stopped caring since "powerful" machines are so cheap these days which i find quite sad.
Hey it might not mean a lot to you but I'm really glad you've started uploading again after your bit of a hiatus. I'm not a great programmer because I've only ever worked with very high level languages and libraries, so learning about how to do all of the nitty gritty is super fascinating. And seeing the final project come together, or course :)
Happy to see you make another video on this game! (3:35) Why do you need to store the max local position of each block in a 32x32x32 subchunk as '32', while 0-31 is already a range of 32 blocks? Then you could also go from using 6 bits to 5 bits, as 2^5 = 32. :)
A chunk is 32 blocks wide, but it is 33 vertices wide. Picture a fence of posts | and segments --. There will always be one more post than there are segments, like so: |--|--|--|--| (4 segments, 5 posts). Now replace segments with blocks, and posts with vertices. So therefore 32 blocks needs 33 vertices :)
I don't know if this would make sense, but could you not store the new lighting value (2..5) in two bits instead of three by subtracting 2 and thus only needing to store 0, 1, 2 or 3 which is a two digit binary number? :)
I wonder where the line is between some neat optimisations, and code that is just full of magic numbers and offets, that noone understands 3 months after...
@@deamon6681 I feel like such an important part of a game engine might need to be as optimised as possible and therefore it's ok for the code to be harder to understand. Good variable naming and documentation is ofc important. I was more worried that my 'optimisation' might just not improve anything as there is enough room in the variable he packs all the bytes into. Then, my optimization would just add an unnecessary operation. And I also generally don't know, if saving one bit is worth one extra operation
that would be an additional operation for each vector and the extra bit in memory to save that might be the more efficient approach. The memory efficiency vs processing efficiency is always a complex argument.
This wouldn't make a difference to the resulting code since memory alignment means any struct is always packed to align to the nearest 4 byte size. So even if you go to 31 bits per block it'll still pad to 32 bits.
man, I watched your "build minecraft in 1 week challenge" a year ago and was inspired to build a minecraft clone myself and when I got to meshing I had to make my own algorithm. But 6 months later I see this video in recommended and clicked on it because it reminded me of programming my game and watching that old video and WOAH turns out you're the same guy who made it.
0:21 Donkey Kong Country 2 - David Wise - Stickerbrush Symphony 1:36 Donkey Kong Country 2 - David Wise - Aquatic Ambience oh thank you for putting music in description
I did a voxel world some month ago, and I ran into that VRAM problem. I'm surprised I didn't thought of declaring the textures inside the shader, this is so simple yet so effective.
Minecraft still uses a texture atlas, it just assembles it at runtime. If you look at the console as the game is starting up, it says some stuff about texture atlases, and it even saves it to disk. I found it while playing modded at one point, and found some very strange things from some mods
5:50 : Why make it complicated with division? Just have a 6-entries lookup table for desired lighting values (or normal vectors in the 6 directions, incase you'll ever need them) in the shader. Perhaps such a lookup table instead of division might even improve performance, albeit very slightly.
@@oblivion_2852 Lookups are way, way, way slower. On a GPU, multiplication, division, addition, multiply-add, subtraction, inverse square roots, exp2, sin, and cos are all one clock cycle. (this does not apply for integers, only floats). A lookup may be implmented with a texture read, which is pretty much the only thing that matters for shader performance. Never use lookup textures in a GPU to replace mathematical operations.
@@gNpNct Both multiplication and division are incredibly fast on a GPU. The division is sometimes 2 clock cycles (one reciprocal and one add) and sometimes 1 clock cycle (1 divide), but either way it is very fast.
I am thinking of something like this: Define a 3D array of "Blocks". Each block can have an byte for it's Type. The coordinates don't need to be saved as we already have them when we index into the array. So, for the storing the blocks themselves it will only take 1 byte, and when you want to expand, you can just change the data type from "byte" to "short". You will still be using less than 4 bytes. Now, here's an explanation for how you can use the index for the coordinates. the x, y, and z index will denote where the center of the block is, simple as that.
Thank you for making this kind of video, it puts my mind to rest a bit, while it would be fun to implement a voxel game, there already are plenty. The exercise to implement the renderer would be fun, probably one day I will give in and do it, but until now, it is nice to reiterate the steps while watching you, good video and thank you!
0:15 Wanted to point out a mistake here. All triangles are convex. in simple terms this means that if you wrap a string or rubber band around it you'll never have points that poke inward away from the band. Triangles are also coplanar, for which the definition in the video is given as the definition of 'convex'.
Convex refers to the angle formed at the vertices. A convex shape can inhabit multiple planes so long as none of it's internal angles are greater than 180 degrees. Overall you are correct, a triangle can only exist in one plane but this is because a plane needs three points to be defined and obviously that's all a single triangle has. I believe "plane figure" would be a better choice of words there.
a great improvement would be to use a geometry shader, and just pass a 6bit integer telling wich faces to draw.. you would reduce the whole 36 vertices to a single vertex :)
If I'm not mistaken, on OpenGL 3.1+ you can use glDrawArraysInstanced. You do not need to use 64 byte transformation matrices, and can use 12 byte 3D vectors because you only need to translate the block from model space to world space.
I knew this would be first attempt at secret sauce on this. Thinking further about it that paper you highlighted is going to do this same thing algorithmically and shortcut something as this will be the middle or lower middle ground for what needs to be truely optimized. The thing is that if you are going to use bytes there are a set of secrets of just using things representationally and mapping in the code these bytes to another set of values much like base 10 or base 8 - the bits can be representational of an infinite number of values when mapped in different contexts. Going to go smoke some weed and think more on this.
that opening threw me right back into the one and only time I worked in a studio. The lead was allergic to triangles, but I was modeling something for their Unreal Engine VR movie thing ... I didn't end up being hired. Fun job but people in this industry can be mindless frustrating.
Another thing I do is store them in quads and then use indices in the shader to convert quads to triangles, making there be only 4 vertices per block face instead of 6. I also store the 'per vertex' data separately from the 'per block face' data.
That’s a pretty cool video and a tutorial, however that would work only for games that use purely voxels, I.e. it wouldn’t be possible to pack such data in case you would want to introduce different models per block. I still found it very informative, thanks!
At 1:48, what r the 3 floats for texture and 1 for lighting? Wouldn't texture just be 2 floats (a uv coord) ?and wouldn't there 3 floats for the normal per vertex?
The 3 floats were the uv coords and the index of the texture array, (opengl texture array) The one float for lighting was a number for the direction the block was facing This isn't traditional lighting that uses a light source and a normal, but rather just very very simple lighting that changes how bright the block face Eg the top of the blocks had a value of 1 and the bottom had the value of 0.4 So when this number is multipled by the value of the texture, it makes the top of the block full light and the bottom of the block a lot darker
It's important to note that these optimizations are only possible because you're leaving definition behind, not that it's bad, but because those are the compromises you're willing to make
3:40 I don't know if you made a mistake, but 32 binary values can fit within 5 bits, from 0 (00000) to 31 (11111). So we only need 15 bits to store position information.
There are 33 possible vertex positions from 0 to 32 Imagine chunks are 2x2, then the top verticies would be like this ._._. Where the dots represents vertex, the positions go from 0 to 2, giving 3 possible vertex positions in a given axis
You could store your whole structure into a single unsigned long and a float by using bit shifting Or just simply for the (x,y,z) those could be inside one int (1,32,16,08) (you need a 1 at the start if x < 10)
Just use bitmaps. 32*32*32 with visibility directions + type + light + color will usually take around 50-200 bytes. For filled chunks such as air it will just take couple of bits. You also get greedy meshing along x axis with this approach AND greedy blocks (you pass through visible blocks/bits, skipping all empty block iterations). You can also just render entire FoV 10*10*10 chunks by recombining bitmaps, optimize it, then calculate greedy mesh for entire FoV.
Oh and you could also just store 2 bits (instead of 3) for the lighting, since you only have 4 values. That would give you values from 0-3. Adding 2 to that gives you values from 2-5 which you can then divide by
@@Hopsonn no, you didnt understand what i meant, i know the music in this video, its just that all of the tracks have been posted in videos where people do a think in the comment section called a "checkpoint" example1: at 0:23 starts the track in this vid ruclips.net/video/hHKu9W_m0nc/видео.html example2: at 6:05 ruclips.net/video/Q9XTqQbuavI/видео.html it was just a comment in case someone else recognised the songs because of the checkpoint vids, but i guess its not as known as i thought :v
There’s actually another thing you missed. If your chunk size is 32, your relative block offset can only be 0..31, not 0..32. That means you’re okay with just 5 bits per side instead of 6.
Yes, but it's talking about vertices - the edges of the blocks - and not the blocks themselves, therefore the lowest one is at 0, and the highest one is at 32
Any updates on this project? Love seeing this code optimization type videos. A suggestion on the lighting though, make it 1 byte so you have all possible light intensities (0-255). Its going to make the light decay from torches or other light sources look much better
I have considered this approach in my little MC-like game, but using integers for the coordinates meant that block models with fractional coordinates are not supported: things like half-slabs, glass panes, the brewing stand. To support those, a fixed-point number could be used, but I wasn't sure how to design such a structure. I didn't want to pick the number of bits for the fractional part, e.g. 4 bits for a resolution of 0.0625 blocks, only to later on find out that I want to implement a block that needs a greater resolution for its model. Now that I think about it, it's not such a big deal. Changing the number of bits for the fractional part could be as easy as just changing a constant in the CPU program and vertex shader with no changes to code, but at the time I was kinda scared to make a decision.
to have greedy meshing and this one, how much memory usage will be reduced? i dont think you can use the gl index because if you have a greedy meshed flat desert, the whole desert will have a large sand texture, not individual sand textures for each block.
I believe light levels in Minecraft range from 0 to 15 That would require 4 bits. Using 3 bits I could do half the quality of the lighting and range the light values from 0 to 7, and then do some calculation in the shader to put that between 0 to 1.
I realized why about 3 seconds later - it would be impractical to store 31 bits rather that 32, so the extra bit gained would be wasted anyway. However, you could allocate 13 bits to the texture array index instead of 12, allowing for up to 1024 block textures.
Question about your magic number unpacking: In OpenGL, do you define the size of each vertex attribute (is that the name?) in bits? Couldn't you just define the size on that to have OpenGL unpack the values for you? Or does a problem happen with how C generally likes to align things on byte boundaries?
What about vertex indexing? Usually you have a list of vertices, and a list of 16-bit unsigned integers to specify the sequence of how the vertices should be rendered. This means that vertices never have to be duplicated, helping a lot.
While it might be possible to do this in a voxel game that uses polygon rendering, it's incredibly awkward due to the nature of how the mesh is generated. Usually you would add individual block faces to a mesh (a quad), and keep adding more quads. Issue is its hard to predict whether the next quad will be able to share vertices or not, without looking ahead of time. And by this point, algorithms such as greedy meshing give much better results, where rather than sharing verticies, you instead share entire faces, drastically reducing the triangle count, giving a huge boost in performance. And sharing the vertices in the block faces themselves would actually use more memory than doing it this way. (I would type out the numbers to prove this, but I am on mobile atm :p) Thanks for watching!
There's several big improvements to do. The first one would be to only use 4 vertex per face, using vertex index. The second would be (and here I'm being more hypothetical), to only use 1 vertex per block, since all the relevant data of a single voxel can be contained in a single vertex, and the the whole block can be constructed in the geometry shader or somethig
Using an index buffer as you suggest would actually increase the memory usage. My method 6 vertices *4 bytes each =24 bytes per face Index buffer 4 vertices * 4 bytes each + 6 indices * 4 bytes each = 40 bytes As for the geometry shader, I could but I never learned how use those lol
Instead of lighting value, I would use a normal index which maps to one of six possible normal vectors in de shaders that you can then use for any light sources. Since you only need to worry about 6 possible normals, 3 bits will still suffice.
since there's only four possible lighting values, couldn't you store it in just two bits? I mean, sure it would take more math to change the value (either 0, 1, 2, or 3) into the correct multipliers for shading (1.0, 0.8, 0.6, 0.4). it wouldn't be as simple as just dividing the value by 5, but you could instead take the value (again, either 0, 1, 2, or 3), add two, and then divide that by five, right? if this works as I think it should, you could store the lighting in 2 bits, compared to 3. but would that be a significant improvement? like, is it worth it to have another step in changing the value to the lighting multiplier just to save one bit?
Hey Hopson, this question is really out of context and Im not really sure if it works like this cause Im new to this but does the uv coordinate system loop through every texture, if so is there a way to have to where you only have it loop through texture which would make sense for it to be there? For example, lets say your in the nether so it wouldn't make sense for the uv "loop" to go through every texture instead is it or can it be biome or chuck specific? Thanks!
There is no loop. The uv coordinate is the same for every texture, and the only difference is the "layer" of the texture array, which is baked into the geometry when the chunk is created. Even when baking the texture ID into the chunk, it is done via a lookup table, and so no looping is required.
Join my discord here if you want to :=) discordapp.com/invite/DeEhUXY
Hopson, So 2 years ago you made a Minecraft game in 7 days, I’m looking forward to make a game like roblox so could you please make a game like roblox in 7 days?
@@eureptus lol no
@@eureptus dude making a game, even in just 7 days takes a looooong time. Besides, you can't really make a basic version of roblox due to it's multiplayer aspects and creation tools
aaaand the link is dead
@@untodesu ill be making new links soon
Minecraft still uses a texture atlas, it's just stitched together dynamically at runtime now. Great video!
oh so it puts all the individual texture files into on big atlas? I'm guessing the're doing something different for the animated textures
@LapisSea holy crap they never stopped using the fixed function pipeline?
wait but i thought with 1.15 they redid their rendering stuff completely new and optimized everything (i think they called id blaze3d or something)?
@LapisSea im probably gonna look into fabric 1.15 soon when i find the time, would be really cool if mc had at least decent rendering
LapisSea Tell us your thoughts :) Pretty cool
As a fellow voxel game developer, I too find the greedy meshing article to be somewhat technical.
But eventually I figured it out (or so I think):
First, loop through the blocks along the X axis (at Y=0), and combine each of them into a single group until you meet another type of block, increasing extend.x while doing so. (If you meet another, just create a new group.) Then, repeat the same process at Y=1 and so on. Same goes for the Z axis.
So your groups have the following fields: starting position (vec3), extend (vec3i), and the block type (uint in my case).
But we haven't finished yet! Now, for each group, let's say Group 1 is at (0, 0, 0). And say Group 2 is at (0, 1, 0) - one unit above Group 1. If their extend (the amount of blocks along each axis) are the same, then combine the groups together - for instance if their extends are (10, 1, 1) then after the combination the extend of the new group becomes (10, 2, 1).
Essentially, a group will ALWAYS be a cuboid with 12 triangles only.
That is the basic idea of greedy meshing. You can try optimising for faster grouping of blocks (I developed mine in a day so I'm pretty sure there are a lot of space for optimisations). Besides that, I believe a basic cull before the grouping can be quite beneficial too.
Ayyy the how I optimize my voxel game too! I didn't knew this was how the greedy mesh method worked. Extending on the X axis is easy but on the Z and Y is hard and costly.
The method in the linked article is quite a bit different.
Instead of working with cuboids, it deals with 2D slices.
First, it looks at 2 adjacent 2D slices of the voxel grid. From them it generates a mask, which tells you where you need quads. Then it picks a first quad, and tries to extend it. When this quad is maxed out, it clears the mask in that region(since we've already filled those quads), and moves onto a next quad.
This process is then repeated for all slices in the current direction. When that is done, it moves onto the next direction, so you go throughthe volume 3 times total.
Wouldn't greedy meshing completely ruin the resolution of your lighting though since it removes a whole load of verts?
@@imnotstpid Indeed it does, but it only happens if you insist to use a normal dumb graphics pipeline - with shaders (hint: floor()) you can achieve the same effect easily.
Thank you
I love nity grity optimizations like this, especially when you have to get creative with your bit packing. Great video!
its very neat, however you have to be very careful about premature optimizations
if you start doing stuff like too early it can really hurt you in the long run.
@@k1ngjulien_ Mesh memory is the limiting factor in the view distance of a voxel game. This optimization is not premature.
@@krubbles101 yes hopson did it at the right time, the game was having a problem and he fixed it.
The problem is when you do stuff like bitpacking to optimise memory before you've even fully worked the texture/lighting/... mechanics out.
i love it too! this video comes to mind whenever i think of optimization like that: ruclips.net/video/ZWQ0591PAxM/видео.html
@@albingrahn5576 excellent video! Crazy to think that chrome takes >500mb of ram easily.
Programmers have stopped caring since "powerful" machines are so cheap these days which i find quite sad.
Hey it might not mean a lot to you but I'm really glad you've started uploading again after your bit of a hiatus. I'm not a great programmer because I've only ever worked with very high level languages and libraries, so learning about how to do all of the nitty gritty is super fascinating. And seeing the final project come together, or course :)
Happy to see you make another video on this game!
(3:35) Why do you need to store the max local position of each block in a 32x32x32 subchunk as '32', while 0-31 is already a range of 32 blocks? Then you could also go from using 6 bits to 5 bits, as 2^5 = 32. :)
A chunk is 32 blocks wide, but it is 33 vertices wide.
Picture a fence of posts | and segments --.
There will always be one more post than there are segments, like so: |--|--|--|--| (4 segments, 5 posts).
Now replace segments with blocks, and posts with vertices.
So therefore 32 blocks needs 33 vertices :)
I don't know if this would make sense, but could you not store the new lighting value (2..5) in two bits instead of three by subtracting 2 and thus only needing to store 0, 1, 2 or 3 which is a two digit binary number? :)
I wonder where the line is between some neat optimisations, and code that is just full of magic numbers and offets, that noone understands 3 months after...
@@deamon6681 I feel like such an important part of a game engine might need to be as optimised as possible and therefore it's ok for the code to be harder to understand. Good variable naming and documentation is ofc important. I was more worried that my 'optimisation' might just not improve anything as there is enough room in the variable he packs all the bytes into. Then, my optimization would just add an unnecessary operation. And I also generally don't know, if saving one bit is worth one extra operation
@@gumbawu4135 I guess profiling is the only way to find out!
that would be an additional operation for each vector and the extra bit in memory to save that might be the more efficient approach.
The memory efficiency vs processing efficiency is always a complex argument.
This wouldn't make a difference to the resulting code since memory alignment means any struct is always packed to align to the nearest 4 byte size. So even if you go to 31 bits per block it'll still pad to 32 bits.
E V E R Y T H I N G I S T R I A N G L E S
Block game is actually diagonal pyramid game
SQUARES MAKE A CIRCLE
E V E R Y T H I N G I S S Q U A R E S
all these squares make a circle
--⬛
⬛⬛
:)
What's the universe made of?
Triangles and stuff
It sad knowing that he gave up on his channel.
@@tikete really?
Cake
5:50 Just a small arithmetic error.
2 / 5 != 0.2
And 6:20 - 28 bytes = 12 bytes + 12 bytes + 4 bytes = 96 bit + 96 bit + 32 bit = 112 bits
Oh dude! Why did I not think of this!? I am going to apply this to my project
(I also stumbled accross that unreadable article about Greedy Meshing)
Nice video ... And even more beautiful you are using The Chrono trigger theme here 5:07
When you showed terrain.png at 0:46 it gave me so much nostalgia
Not just any terrain.png, but the one from the Painterly Pack. :)
man, I watched your "build minecraft in 1 week challenge" a year ago and was inspired to build a minecraft clone myself and when I got to meshing I had to make my own algorithm. But 6 months later I see this video in recommended and clicked on it because it reminded me of programming my game and watching that old video and WOAH turns out you're the same guy who made it.
0:21 Donkey Kong Country 2 - David Wise - Stickerbrush Symphony
1:36 Donkey Kong Country 2 - David Wise - Aquatic Ambience
oh thank you for putting music in description
Great video! As a beginning game developer myself, this is incredibly inspiring stuff! Thanks for making videos!
How's that going now?
@@manifestbruhlol It's going. Kinda taken a back seat recently due to a bunch of life stuff, but it's going :)
That music choice from the end of the internet.. Good choice, and great video!
I did a voxel world some month ago, and I ran into that VRAM problem. I'm surprised I didn't thought of declaring the textures inside the shader, this is so simple yet so effective.
Cave Story and Beyond Good and Evil music? Man you have some great taste. Great video as always :)
Minecraft still uses a texture atlas, it just assembles it at runtime. If you look at the console as the game is starting up, it says some stuff about texture atlases, and it even saves it to disk. I found it while playing modded at one point, and found some very strange things from some mods
4:00 Minecraft still uses a texture atlas, however it's generated at runtime.
5:50 : Why make it complicated with division? Just have a 6-entries lookup table for desired lighting values (or normal vectors in the 6 directions, incase you'll ever need them) in the shader. Perhaps such a lookup table instead of division might even improve performance, albeit very slightly.
A compiler that's intelligent enough will optimize it into a single division (1/5) and multiply by that reciprocal anyway.
@@gNpNct Yes but it's still a multiplication operation instead of a lookup. Lookups are faster pretty sure.
@@oblivion_2852 Multiplication operations are pretty fast. When it comes to arithmetical operations, the slow one is usually just division.
@@oblivion_2852 Lookups are way, way, way slower. On a GPU, multiplication, division, addition, multiply-add, subtraction, inverse square roots, exp2, sin, and cos are all one clock cycle. (this does not apply for integers, only floats). A lookup may be implmented with a texture read, which is pretty much the only thing that matters for shader performance. Never use lookup textures in a GPU to replace mathematical operations.
@@gNpNct Both multiplication and division are incredibly fast on a GPU. The division is sometimes 2 clock cycles (one reciprocal and one add) and sometimes 1 clock cycle (1 divide), but either way it is very fast.
Great video as always. You're a good source of inspiration!
That model in the intro made every single bit of my 3D artist soul hurt.
Mouse engine
Ah the Aquatic Ambiance from Donky Kong Country. I see you are a man of culture as well (:
Great vid, just subbed!
I am thinking of something like this:
Define a 3D array of "Blocks".
Each block can have an byte for it's Type. The coordinates don't need to be saved as we already have them when we index into the array. So, for the storing the blocks themselves it will only take 1 byte, and when you want to expand, you can just change the data type from "byte" to "short". You will still be using less than 4 bytes.
Now, here's an explanation for how you can use the index for the coordinates. the x, y, and z index will denote where the center of the block is, simple as that.
5:40 But... you have exactly 4 options. That fits neatly into 2 bits. Why would you use 3?
Because I was silly and didn't realise that until I was making the video haha
wow just 4 bytes! that is actually super convenient and super impressive! awesome, and subd
Thank you for making this kind of video, it puts my mind to rest a bit, while it would be fun to implement a voxel game, there already are plenty. The exercise to implement the renderer would be fun, probably one day I will give in and do it, but until now, it is nice to reiterate the steps while watching you, good video and thank you!
0:50 Good old Painterly Pack.
Come for the programming, stay for the sweet sweet chrono trigger music. :3
I've never watched your videos before but I approve of your choice of music
i loved that you showed a screenshot of the valve hammer editor
0:15 Wanted to point out a mistake here. All triangles are convex. in simple terms this means that if you wrap a string or rubber band around it you'll never have points that poke inward away from the band.
Triangles are also coplanar, for which the definition in the video is given as the definition of 'convex'.
Not sure what coplanar means but it's probably out the scope of what the point of this video is, but I'll look into that regardless
Thanks this video helped a lot mainly so I can understand my codes and even figure out more
Convex refers to the angle formed at the vertices. A convex shape can inhabit multiple planes so long as none of it's internal angles are greater than 180 degrees. Overall you are correct, a triangle can only exist in one plane but this is because a plane needs three points to be defined and obviously that's all a single triangle has. I believe "plane figure" would be a better choice of words there.
Voxel engine development, cute lizard avatar? This is microtargeted at me somehow. Subscribed.
On the git it says you decided that this project is not for you, does this mean this series will be discontinued?
ShibeGuy oh rip
yes
Aaah the nostalgia hit when I heard Beyond Good and Evil music
a great improvement would be to use a geometry shader, and just pass a 6bit integer telling wich faces to draw..
you would reduce the whole 36 vertices to a single vertex :)
The performance of that is terrible. Lots of branching, which is bad on the GPU.
If I'm not mistaken, on OpenGL 3.1+ you can use glDrawArraysInstanced. You do not need to use 64 byte transformation matrices, and can use 12 byte 3D vectors because you only need to translate the block from model space to world space.
Finally this series is back!
Been trying to figure out the greedy meshing algorithm too, but sadly I too do not understand anything lol
These videos are so nice to watch!
I knew this would be first attempt at secret sauce on this. Thinking further about it that paper you highlighted is going to do this same thing algorithmically and shortcut something as this will be the middle or lower middle ground for what needs to be truely optimized. The thing is that if you are going to use bytes there are a set of secrets of just using things representationally and mapping in the code these bytes to another set of values much like base 10 or base 8 - the bits can be representational of an infinite number of values when mapped in different contexts. Going to go smoke some weed and think more on this.
that opening threw me right back into the one and only time I worked in a studio.
The lead was allergic to triangles, but I was modeling something for their Unreal Engine VR movie thing ...
I didn't end up being hired. Fun job but people in this industry can be mindless frustrating.
Allergic to triangles? Sounds like you dodged a bullet regardless
Another thing I do is store them in quads and then use indices in the shader to convert quads to triangles, making there be only 4 vertices per block face instead of 6. I also store the 'per vertex' data separately from the 'per block face' data.
That’s a pretty cool video and a tutorial, however that would work only for games that use purely voxels, I.e. it wouldn’t be possible to pack such data in case you would want to introduce different models per block.
I still found it very informative, thanks!
At 1:48, what r the 3 floats for texture and 1 for lighting? Wouldn't texture just be 2 floats (a uv coord) ?and wouldn't there 3 floats for the normal per vertex?
The 3 floats were the uv coords and the index of the texture array, (opengl texture array)
The one float for lighting was a number for the direction the block was facing
This isn't traditional lighting that uses a light source and a normal, but rather just very very simple lighting that changes how bright the block face
Eg the top of the blocks had a value of 1 and the bottom had the value of 0.4
So when this number is multipled by the value of the texture, it makes the top of the block full light and the bottom of the block a lot darker
You deserve my like for your awesome work you are doing but this time my like goes for using Chrono trigger music :D
It's important to note that these optimizations are only possible because you're leaving definition behind, not that it's bad, but because those are the compromises you're willing to make
Yaaaay i been waiting for another of these. Inspiration!!
3:40 I don't know if you made a mistake, but 32 binary values can fit within 5 bits, from 0 (00000) to 31 (11111). So we only need 15 bits to store position information.
There are 33 possible vertex positions from 0 to 32
Imagine chunks are 2x2, then the top verticies would be like this
._._.
Where the dots represents vertex, the positions go from 0 to 2, giving 3 possible vertex positions in a given axis
You could store your whole structure into a single unsigned long and a float by using bit shifting
Or just simply for the (x,y,z) those could be inside one int (1,32,16,08) (you need a 1 at the start if x < 10)
The SONG in the background
'Home sweet home' :Beyond Good and evil , it's an old PlayStation 2 game. Love it 😍
That's actually insane, congratulations
Just use bitmaps. 32*32*32 with visibility directions + type + light + color will usually take around 50-200 bytes. For filled chunks such as air it will just take couple of bits. You also get greedy meshing along x axis with this approach AND greedy blocks (you pass through visible blocks/bits, skipping all empty block iterations). You can also just render entire FoV 10*10*10 chunks by recombining bitmaps, optimize it, then calculate greedy mesh for entire FoV.
I love your videos man, you inspire me
How about just rendering quadrilaterals, since a voxel world doesn't really have any triangles in it? That should bring down the memory usage a ton.
Hopson I really like your videos so I'm making this comment to stimulate the algorithm
When is the next episode coming out?
The cave story soundtrack at the beginning❤️❤️❤️
you a real one for the DKC2 tracks
5:39 that's 4 different values so why 3 bits and not 2?
He's not doing a lookup of an array, the 3 bits comes from the maximum value of 5 in this case
@@paavorotsten508 Doesn't matter, subtract two and it falls under that range.
Oh and you could also just store 2 bits (instead of 3) for the lighting, since you only have 4 values. That would give you values from 0-3. Adding 2 to that gives you values from 2-5 which you can then divide by
It's really useful. Thank you!
I just knew I heard Brambles from Donkey Kong Country 2 in the background.
the music you chose in this video made me feel like i was gonna see some checkpoint comments :v
Gimmie the time stamp and I'll tell you the music
Is all in description anayway
@@Hopsonn no, you didnt understand what i meant, i know the music in this video, its just that all of the tracks have been posted in videos where people do a think in the comment section called a "checkpoint"
example1: at 0:23 starts the track in this vid
ruclips.net/video/hHKu9W_m0nc/видео.html
example2: at 6:05 ruclips.net/video/Q9XTqQbuavI/видео.html
it was just a comment in case someone else recognised the songs because of the checkpoint vids, but i guess its not as known as i thought :v
Surely you could build all the vertices in the geometry shader, only needing to store the voxel X,Y,Z pos and an index to it's texture.
Nice cave story music!
There’s actually another thing you missed. If your chunk size is 32, your relative block offset can only be 0..31, not 0..32. That means you’re okay with just 5 bits per side instead of 6.
Yes, but it's talking about vertices - the edges of the blocks - and not the blocks themselves, therefore the lowest one is at 0, and the highest one is at 32
Any updates on this project? Love seeing this code optimization type videos. A suggestion on the lighting though, make it 1 byte so you have all possible light intensities (0-255). Its going to make the light decay from torches or other light sources look much better
Will you ever come back to posting videos?
6:24 28 bytes is 224 bits. Informative video, though, will use it when I become good enough at coding
i was too distracted by the music to pay attention
Nice profile pic
I have considered this approach in my little MC-like game, but using integers for the coordinates meant that block models with fractional coordinates are not supported: things like half-slabs, glass panes, the brewing stand. To support those, a fixed-point number could be used, but I wasn't sure how to design such a structure. I didn't want to pick the number of bits for the fractional part, e.g. 4 bits for a resolution of 0.0625 blocks, only to later on find out that I want to implement a block that needs a greater resolution for its model.
Now that I think about it, it's not such a big deal. Changing the number of bits for the fractional part could be as easy as just changing a constant in the CPU program and vertex shader with no changes to code, but at the time I was kinda scared to make a decision.
this video is super awesome, thanks alot dude!
You don't need to pass in 2 bits for the UV lookup, just use gl_VertexID % 6 with a 6 row lookup table
That bg music is just awesome!!)
Where is he?
Cheers! All music is listed in the description
No, guy, I mean, why ain't ya Makin new videos? I love programming, regardless to the fact that I m a little bit newbie...)
a really fun video I enjoyed watching!
Aren't bitwise operations really slow on the GPU? Is the memory saved worth that?
If I store the vertices as integers instead of floats, they will have to be converted to floats on the GPU. Can this increase power usage?
to have greedy meshing and this one, how much memory usage will be reduced?
i dont think you can use the gl index because if you have a greedy meshed flat desert, the whole desert will have a large sand texture, not individual sand textures for each block.
But what if you want to have more complicated lighting? Like in minecraft
I believe light levels in Minecraft range from 0 to 15
That would require 4 bits.
Using 3 bits I could do half the quality of the lighting and range the light values from 0 to 7, and then do some calculation in the shader to put that between 0 to 1.
Maybe I'm missing something, but why store numbers in the range 2-5 when you could subtract 2 and store 0-3, which requires only 2 bits instead of 3?
I realized why about 3 seconds later - it would be impractical to store 31 bits rather that 32, so the extra bit gained would be wasted anyway. However, you could allocate 13 bits to the texture array index instead of 12, allowing for up to 1024 block textures.
Background music at the start. Is it Banana Switch?
All music is listed in the video description :)
Question about your magic number unpacking: In OpenGL, do you define the size of each vertex attribute (is that the name?) in bits? Couldn't you just define the size on that to have OpenGL unpack the values for you? Or does a problem happen with how C generally likes to align things on byte boundaries?
You have to use an array of integers as your vertices and do bitwise operations in your shader program. This does require different vertex attributes.
Put subtitles in Portuguese, I'm from Brazil and I love your channel
I like this method a lot, however how would you implement other block models? Like slabs, stairs, etc.
@@crowiethecrow7735 thanks! It's not ideal but the only way I can think is they could go into a separate mesh and rendered separately
@@Hopsonn Yea, good idea. Also pretty quick reply for a 4 year old video. Appreciate it!👍
why on 6 min didnt you subtracted 2 giving you 0,1,2,3 so you can put the information in 2 bits instead of 3
Great video!
What about vertex indexing? Usually you have a list of vertices, and a list of 16-bit unsigned integers to specify the sequence of how the vertices should be rendered. This means that vertices never have to be duplicated, helping a lot.
While it might be possible to do this in a voxel game that uses polygon rendering, it's incredibly awkward due to the nature of how the mesh is generated.
Usually you would add individual block faces to a mesh (a quad), and keep adding more quads. Issue is its hard to predict whether the next quad will be able to share vertices or not, without looking ahead of time. And by this point, algorithms such as greedy meshing give much better results, where rather than sharing verticies, you instead share entire faces, drastically reducing the triangle count, giving a huge boost in performance.
And sharing the vertices in the block faces themselves would actually use more memory than doing it this way. (I would type out the numbers to prove this, but I am on mobile atm :p)
Thanks for watching!
There's several big improvements to do.
The first one would be to only use 4 vertex per face, using vertex index.
The second would be (and here I'm being more hypothetical), to only use 1 vertex per block, since all the relevant data of a single voxel can be contained in a single vertex, and the the whole block can be constructed in the geometry shader or somethig
Using an index buffer as you suggest would actually increase the memory usage.
My method 6 vertices *4 bytes each =24 bytes per face
Index buffer 4 vertices * 4 bytes each + 6 indices * 4 bytes each = 40 bytes
As for the geometry shader, I could but I never learned how use those lol
What Are its controls
Instead of lighting value, I would use a normal index which maps to one of six possible normal vectors in de shaders that you can then use for any light sources. Since you only need to worry about 6 possible normals, 3 bits will still suffice.
Awesome video. I subed
since there's only four possible lighting values, couldn't you store it in just two bits? I mean, sure it would take more math to change the value (either 0, 1, 2, or 3) into the correct multipliers for shading (1.0, 0.8, 0.6, 0.4). it wouldn't be as simple as just dividing the value by 5, but you could instead take the value (again, either 0, 1, 2, or 3), add two, and then divide that by five, right?
if this works as I think it should, you could store the lighting in 2 bits, compared to 3. but would that be a significant improvement? like, is it worth it to have another step in changing the value to the lighting multiplier just to save one bit?
saw the 2017 one week minecraft vid and now I'm trying to decide how to catch up
Hey Hopson, this question is really out of context and Im not really sure if it works like this cause Im new to this but does the uv coordinate system loop through every texture, if so is there a way to have to where you only have it loop through texture which would make sense for it to be there? For example, lets say your in the nether so it wouldn't make sense for the uv "loop" to go through every texture instead is it or can it be biome or chuck specific? Thanks!
There is no loop.
The uv coordinate is the same for every texture, and the only difference is the "layer" of the texture array, which is baked into the geometry when the chunk is created.
Even when baking the texture ID into the chunk, it is done via a lookup table, and so no looping is required.
@@Hopsonn bet ty bro
awww YES Thorn Thorn Tale Meiro - Super Donkey Kong 2