As I mentioned in the video, I'm thinking of calling this game/engine/project "Daydream"! I've been trying to come up with a short, concise, meaningful but not-cheesy name for years at this point. I kind of got really hung up on "Blox" as a name and I wanted something with a similar 'tongue-feel' but obviously not running afoul of trademarks and perhaps a little less overly 'voxel-game-named'. So I thought back upon all of my game design notes and how I was composing the music for this game. The music isn't themed after the presentation of the game, or the specific features it has, but instead is being themed based on the *emotion* or *vibe* that the player should be experiencing as a result of the game mechanics and game design, so why not use that philosophy for the name too? Since the game design I've set out so far aims to turn the game into a zen-like experience with tight core loops, calm unwinding activities, all set in an infinite world you can imagine and create anything inside of with full dominion and no other characters to think of, it gave me the vibe that the game felt like a kind of lucid dream. Indeed, the music already leans into this with repeating melodies, pedals and ostinati, all played with light touches. It all feels quite floaty and dreamlike, so that's the direction I wanted to lean into. This lines up with other aspects of the game too, like the cute abstracted details on the block textures (as opposed to Minecraft's more gritty style), the more casual, cursive font, and features of the worlds that I plan to generate (such as whimsical, physically impossible cliffs for the purposes of more interesting building opportunities). So I think framing the game like a 'daydream' makes total sense, and it encapsulates all of those vibes into one single word that rolls off the tongue and isn't a cheesy voxel game name at all. Of course, before settling on the name for sure, I did do a quick search for other games. Apart from some tiny visual novels, there's nobody just using "Daydream" as a standalone name, though of course Google did try and use it as the name of their underwhelming discontinued phone VR platform. I'm generally happy enough with the availability to go for it. So what do you guys think? Great name or great mistake?
I actually like the name Daydream. Dream aesthetic is really cool and nice that you are going for it. I can think of other options that could be cool. Oneiric, Oneirisme, déjà rêvé and anemoia are other words related to dreams.
I started building this same binary greedy mesher a couple weeks ago and I've been stuck figuring out how to get the swizzling part right. I like forcing myself to figure stuff out the hard way, so I haven't really looked at any references for help, but I've been stuck for several days now. This helped remotivate me, and realize I should probably understand how swizzling works beyond a surface level lol.
This reminds me strongly of Tantan's latest video about optimizing greedy mesher for his Bevy voxel renderer. Now I know what he did is called binary meshing.
I'm actually glad that more devs are using the binary approach ever since Tantan made a video about it. And also, Daydream fits so well with the overall game's concept
Oh, wow! I had the exact same thoughts about the visibility culling problem. I also tried some stuff, but I also found most solutions only worked in 2D.. Awesome to know there might be a solution. Looking forward to your attempt, sounds very interesting! Might look at it myself if I find the time
Awesome work! For voxel scenes that are very dynamic, I have always thought that meshing would never work because its just too slow (I want high voxel densities) but last couple weeks I've been playing around with a GPU-driven voxel meshing algorithm and its pretty good so far. I don't greedy mesh or anything, since I think that would be slower. I essentially only mesh the visible voxels due to GPU-driven occlusion culling, and I do nanite-like compute rasterization for the small triangles.
I just stumbled across your channel last night! Love what you're doing over there, and this GPU-side meshing sounds very cool too :) I'm going for less dense voxels here (50cm) since I'm building more of a Minecraft-like game with limited dynamic content, so I figure it's still in the realm where CPU-side meshing makes some sense. Ideally I'd ray march the whole thing but I have some reservations about how that'd scale to lower end devices. But who knows, maybe one day!
@@dphfox Thanks, yeah I think your approach makes a lot of sense for a minecraft-like voxel density. I really enjoyed the video, surprised I was engaged all the way throughout, though I would like to have seen more images in-engine, for example visualizing the culling.
I already saw binary greedy meshing in a presentation video named: Greedy Meshing Voxels Fast - Optimism in Design Handmade Seattle 2022 by Davis Morley
what makes something performant is relative to the issue at hand, sometimes there are general things like having less data in memory, other times its itterating over alots of the same things to prevent cache misses, it is relatively speaking... relative to the problem at hand.
For sure! The main problem here is a CPU side bottleneck where the rendering system didn't have enough meshing throughput, so that's what I solved here, but there's also some nice future benefits in the form of reduced overdraw, better utilisation of early z, and reducing the number of non-cobtributing fragment shader calls, which should set us up nicely for translucency and lighting down the line too! I definitely don't think about performance in overly simplistic terms - it's a bit of a fuller picture than I present in the video because it's be a bit too technical for some.
Currently developing my own Voxel (Blocky) Engine in Vulkan and this is a goldmine lol I very much know all of this already but thats a very nice summary for me.
My main reference was this talk: ua-cam.com/video/4xs66m1Of4A/v-deo.html Ultimately what I wanted to do was HDDA/ray marching in a fragment shader rather than doing rasterisation at all, but I figured that it's better for performance to take advantage of the power of rasterisation for direct visibility checks. Down the line I'll probably use GPU-side HDDA for lighting / ray tracing. I saw Tantan's video and it looks like they're doing slightly different things - they're focused more on just using meshes. I don't know if splitting the chunk mesh based on block ID is what I would have done, but it seems to work for them! :)
Forgive me if I'm a bit nooby! I do vaguely understand that things nowadays are moving towards a GPU-driven direction (do things in compute etc) but honestly? I'm just not yet smart enough to understand it all. I'm also not sure if wgpu is particularly well suited to that kind of thing, judging by the Github issues.
![Doubling the speed of my game's graphics [Voxel Devlog #18]](http://i.ytimg.com/vi/P2bGF6GPmfc/mqdefault.jpg)
As I mentioned in the video, I'm thinking of calling this game/engine/project "Daydream"!
I've been trying to come up with a short, concise, meaningful but not-cheesy name for years at this point. I kind of got really hung up on "Blox" as a name and I wanted something with a similar 'tongue-feel' but obviously not running afoul of trademarks and perhaps a little less overly 'voxel-game-named'.
So I thought back upon all of my game design notes and how I was composing the music for this game. The music isn't themed after the presentation of the game, or the specific features it has, but instead is being themed based on the *emotion* or *vibe* that the player should be experiencing as a result of the game mechanics and game design, so why not use that philosophy for the name too?
Since the game design I've set out so far aims to turn the game into a zen-like experience with tight core loops, calm unwinding activities, all set in an infinite world you can imagine and create anything inside of with full dominion and no other characters to think of, it gave me the vibe that the game felt like a kind of lucid dream. Indeed, the music already leans into this with repeating melodies, pedals and ostinati, all played with light touches. It all feels quite floaty and dreamlike, so that's the direction I wanted to lean into. This lines up with other aspects of the game too, like the cute abstracted details on the block textures (as opposed to Minecraft's more gritty style), the more casual, cursive font, and features of the worlds that I plan to generate (such as whimsical, physically impossible cliffs for the purposes of more interesting building opportunities).
So I think framing the game like a 'daydream' makes total sense, and it encapsulates all of those vibes into one single word that rolls off the tongue and isn't a cheesy voxel game name at all.
Of course, before settling on the name for sure, I did do a quick search for other games. Apart from some tiny visual novels, there's nobody just using "Daydream" as a standalone name, though of course Google did try and use it as the name of their underwhelming discontinued phone VR platform. I'm generally happy enough with the availability to go for it.
So what do you guys think? Great name or great mistake?
I actually like the name Daydream. Dream aesthetic is really cool and nice that you are going for it. I can think of other options that could be cool. Oneiric, Oneirisme, déjà rêvé and anemoia are other words related to dreams.
I think the name itself is cool, but not very unique therefore I don't think it'd be a good name
I think it's a great name! Simple and easy to remember, and like you said few to no games have used it.
daydreams a great name, though if youre going for something "lucid dream"-y, maybe lucid itself could be great?
I started building this same binary greedy mesher a couple weeks ago and I've been stuck figuring out how to get the swizzling part right. I like forcing myself to figure stuff out the hard way, so I haven't really looked at any references for help, but I've been stuck for several days now. This helped remotivate me, and realize I should probably understand how swizzling works beyond a surface level lol.
Update: I figured it out. Wasn't too far off, with some slight tweaks to my code I got it working! 😁
This reminds me strongly of Tantan's latest video about optimizing greedy mesher for his Bevy voxel renderer. Now I know what he did is called binary meshing.
this is giving me flashbacks to the latest Tantan video
I have no experience in graphics programming but this was really interesting! I will look forward to future episodes :)
I'm actually glad that more devs are using the binary approach ever since Tantan made a video about it.
And also, Daydream fits so well with the overall game's concept
eventually i want to be on this level of programming
daydream has a nice sound to it
Oh, wow! I had the exact same thoughts about the visibility culling problem. I also tried some stuff, but I also found most solutions only worked in 2D.. Awesome to know there might be a solution. Looking forward to your attempt, sounds very interesting! Might look at it myself if I find the time
Awesome work! For voxel scenes that are very dynamic, I have always thought that meshing would never work because its just too slow (I want high voxel densities) but last couple weeks I've been playing around with a GPU-driven voxel meshing algorithm and its pretty good so far. I don't greedy mesh or anything, since I think that would be slower. I essentially only mesh the visible voxels due to GPU-driven occlusion culling, and I do nanite-like compute rasterization for the small triangles.
I just stumbled across your channel last night! Love what you're doing over there, and this GPU-side meshing sounds very cool too :)
I'm going for less dense voxels here (50cm) since I'm building more of a Minecraft-like game with limited dynamic content, so I figure it's still in the realm where CPU-side meshing makes some sense. Ideally I'd ray march the whole thing but I have some reservations about how that'd scale to lower end devices. But who knows, maybe one day!
@@dphfox Thanks, yeah I think your approach makes a lot of sense for a minecraft-like voxel density. I really enjoyed the video, surprised I was engaged all the way throughout, though I would like to have seen more images in-engine, for example visualizing the culling.
@@GabeRundlett thanks! I'll make sure to include more footage next time :)
wow... I loved this video soo much! Thank you
I already saw binary greedy meshing in a presentation video named:
Greedy Meshing Voxels Fast - Optimism in Design Handmade Seattle 2022
by Davis Morley
There's also Tantan's latest video where he implements binary greedy meshing in his voxel engine in rust
that's my inspiration!
@@dphfox ooo that's cool
Grease Lightning... So much nostalgia😖
I thought this was made by a much bigger channel until I saw the view count. Good stuff Daniel
what makes something performant is relative to the issue at hand, sometimes there are general things like having less data in memory, other times its itterating over alots of the same things to prevent cache misses, it is relatively speaking... relative to the problem at hand.
For sure! The main problem here is a CPU side bottleneck where the rendering system didn't have enough meshing throughput, so that's what I solved here, but there's also some nice future benefits in the form of reduced overdraw, better utilisation of early z, and reducing the number of non-cobtributing fragment shader calls, which should set us up nicely for translucency and lighting down the line too! I definitely don't think about performance in overly simplistic terms - it's a bit of a fuller picture than I present in the video because it's be a bit too technical for some.
Currently developing my own Voxel (Blocky) Engine in Vulkan and this is a goldmine lol
I very much know all of this already but thats a very nice summary for me.
Awesome video! This is a great way to explain optimization on engines, one question. Where did you find these resources to optimize?
That article at the end looks more or less like a problem I wanted to solve in a 2D game, haha
keep it going
Daydream just sounds like a generative AI service xd
Wow, that's a really great video! What colour theme are you using?
I'm using Github Dark Default!
awesome vid!
very cool
Did you find this out from Tantan?
My main reference was this talk: ua-cam.com/video/4xs66m1Of4A/v-deo.html
Ultimately what I wanted to do was HDDA/ray marching in a fragment shader rather than doing rasterisation at all, but I figured that it's better for performance to take advantage of the power of rasterisation for direct visibility checks. Down the line I'll probably use GPU-side HDDA for lighting / ray tracing.
I saw Tantan's video and it looks like they're doing slightly different things - they're focused more on just using meshes. I don't know if splitting the chunk mesh based on block ID is what I would have done, but it seems to work for them! :)
@@dphfox Ah, cool!
I'm also thinking of making a game in rust (just a small one for the experience of it) how did you get it to display things?
I use winit and wgpu - check out this tutorial track: sotrh.github.io/learn-wgpu/
Nice video! Just a heads up, the sound being out of sync with the audio is a bit unpleasant
Thanks for the heads up! I'll recalibrate my setup so it'll hopefully be a little bit better next time.
"Somnium" could be a good name. It's latin for "dream".
You can use it for shadows
Will the game support multiplayer?
Hopefully!
why do you move your hands around so much are you trying to give me a seizure
i like your funny incantations magic man
i think humans communicate emphaisis by using hand gestures so
why do you need to send stuff to the gpu. isnt it already there. gpgpu not cpu to gpu. yeah 16+ say 48gigs of gddr6+ is main system memory.
Forgive me if I'm a bit nooby! I do vaguely understand that things nowadays are moving towards a GPU-driven direction (do things in compute etc) but honestly? I'm just not yet smart enough to understand it all. I'm also not sure if wgpu is particularly well suited to that kind of thing, judging by the Github issues.
@@dphfox cpu is fine too. I mean gpu compute, use gpu ram as the main ram.
Voxel dev stealing algorithm from each other without crediting their sources... Hbomberguy plagiarism 😂
Oh I absolutely don't take credit for these! I'm not that smart 😅
First (hehe)