You used y as the up axis instead of z? Literally unwatchable
@Ethanthegrand23 күн бұрын
What you mean, Y has always been the up axis in 3D space and video games
@seftondepledge365821 күн бұрын
@@Ethanthegrand Z is the up axis in pretty much all of mathematics, I wouldn't know about games. My comment was not serious either, I really enjoyed the video.
@Ethanthegrand21 күн бұрын
@@seftondepledge3658 ahh I see. Growing up coding, when working with 2D games, X is left/right, Y is up/down, which makes sense, and introducing Z adds the forward/back axis
@arthur111213217 күн бұрын
To be exact, any axis could be up without any noticeable consequences as long as the positive directions are maintained relative to each others following the right hand rule (which basically means that the cross product of 2 axis gives the third one). So if +X is right, and +Y is up, then +Z must be back. I tend to prefer having Z upward because it means that X can stay pointed toward the right and Y becomes positive towards the front, which makes more sens to me, and I think this is also the reason why mathematics sticks to that norm as well. However, just like I was saying at the begining, it barely change anything in the end as the direction ultimately ends up to be relative to the camera orientation.
@seftondepledge365817 күн бұрын
@@arthur1112132 Oh, it makes absolutely no difference to the maths I agree. But my brain prefers it that way. I think it also makes sense (in maths at least) as you are used to 2d graphs being on paper on a desk etc where the x-y plane is horizontal. So z being the vertical axis is just an extension of this. Not a reordering.
@PRIMARYATIAS3 ай бұрын
Where is z(n+1) = z(n)^2 + C (mandlebrot) ??? I did not see this nice application of complex numbers in the video.
@TommyLikeTom3 ай бұрын
hackers crack the code, game devs write the code
@warpzone84213 ай бұрын
Can the voxels be edited at runtime, like in Minecraft? Or is this mostly only useful for pre-baked, static, or algorithmically generated terrain?
@davis-morley3 ай бұрын
That actually is the main benefit of this technique. Since you don't have to mesh you can, in one way or another (could just be a naive buffer), just upload the voxels directly to the gpu to be sampled whenever.
@warpzone84213 ай бұрын
@@davis-morley Ah! So literally just raw voxels, not blocks or an Unreal-style terrain mesh?
@hoyteternal31733 ай бұрын
you are smart as fuck bro
@mikkelens4 ай бұрын
I love what the captions say at 13:10
@DeznekCZ4 ай бұрын
Delete and modulo may be replaced by shift and mask for getting coord from index.
@michaels8514 ай бұрын
I worked in a studio at some point that did that trick you showed at the end. It worked for a while but we ran into issues with overdraw especially on lower-end hardware. All that air is being meshed and being drawn, thousands if not tens of thousands of layered transparent triangles that the GPU can't optimize. You can fix this with Raymarching in the fragment shader instead. So instead of 64*6 faces, you do 6 faces 1 giant cube for the chunk, then raymarch inside it usually outperforms the 64*6 faces.
@khawn48884 ай бұрын
I love setting RGB to position mod 1!!!! I do it so much when I debug and test shaders!! haha, I thought it was funny that I'm not the only one!
@burgessvoshell80624 ай бұрын
how do you render different color/materiality of block types with these optimizations?
@niuage4 ай бұрын
What if some of your voxels can have different models, like a cube for the default, but also campfires or whatever, and different materials, like animated lava etc, would the optimizations still work?
@mikkelens4 ай бұрын
The optimizations would still work for the voxels, but not for the new general meshed objects since they cannot be assumed to easily align to the simple 3D axis. You could still add (relatively) smaller amounts of meshes into the scene though, since the voxels are still technically rendered using meshes with depths etc.
@deathstroyer4 ай бұрын
I've done a similar approach to greedy meshing for compressing voxel models. the binary greedy meshing is really clever, never occurred to me
@lachee30554 ай бұрын
"really really fast, probably" what?
@awillingham4 ай бұрын
@13:10 requires a certain amount of what?
@teok99644 ай бұрын
I just watched your talk, found it extremely fascinating as to how much optimization and thought went into the systems you were describing, and seeing it working here is fantastic. I was wondering if you have any resources you'd reccomend for learning more about these systems, or resources for ameteur programmers in general?
@davis-morley3 ай бұрын
Sorry to only get to this now, the best advice I could give is just work on anything that excites you. Don't be afraid to experiment or to try really wacky things out. Some of my greatest experiences are from small projects where I just wanted to try out an idea or two. As for what has inspired me, I really enjoy Jonathan Blow's talks on programming and game design. Casey Muratori also has a great course called "Performance Aware Programming", its paid but definitely worth it. Note: if you do get that course get the month-to-month subscription as he has somewhat recently stated that he doesn't plan to keep it going for the rest of this year. But yeah to summarize, find something that excites you and run with it, don't be afraid to fail and just see where it takes you.
@oglothenerd4 ай бұрын
Suggestion: Make the video audio a bit louder. I had to watch this on 145% volume, and even then, I am lucky! Windows and MacOS users cap at 100%, and even then, most Linux users also cap at 100%. I am in a special situation, because I am using a window manager.
@MplusARIO4 ай бұрын
I'm so glad I finally stumbled over this video. This really inspired me on my quest to find a subject for my bachelor's thesis. I've known for some time now that I wanted to do something in the area of voxel-based procedural generation, and was wondering if a few of the concepts you mentioned could be applied to marching cubes or other isosurface extraction algorithms. Although with such great performance and the ability to render so many voxels you wouldn't need mc anymore. How would you handle collisions if the mesh of the chunk includes the air? Am I wrong in assuming that you would need a pass of your meshing algorithm that separates air and terrain(like you show) to extract a collision mesh where you need it? Or could you maybe handle collision entirely on the gpu in some fancier way than a collision mesh? Anyways, for your first talk you did very very well! I love your approach to greedy meshing and your explanatin was really nice to follow. Very good presentation - even years later.
@LeBopperoni4 ай бұрын
The mesh and underlying block data don't need to have anything to do with each other. You can collision test against nearby blocks with the safe assumption that they will always be lots of individual axis aligned bounding boxes.
@GIRGHGH4 ай бұрын
It's raining "right"s.
@axanarahyanda6284 ай бұрын
Does the global lattice use more gpu ressources due to being partially transparent?
@voxeldoesart4 ай бұрын
I'm honored.
@n00blamer4 ай бұрын
video thumbnail has t-junctions
@ciCCapROSTi4 ай бұрын
That multidimensional array to simple array is so incredibly overexplained holy shit, this is such basic stuff. And a 3D array in any language you'd actually consider writing something efficient in would result in continuous memory anyways, so there is literally only syntactic difference between his implementation and what the compiler would produce. This is BAD.
@niuage4 ай бұрын
Cool so you chose to focus only on the small kinda irrelevant part and disregard the actual meat of the talk, good job :) It did start slow tho, I'll give you that.
@arthur111213217 күн бұрын
It's true that the coordinates to single index conversion probably didn't need to be explained taht deepely. It's trivial stuff that any programer end up learning soon enough. However, it's false to think that the language will actually do this for you. While it's mostly true for any statically allocated buffers, this is no longer the case when it comes to multi dimentional heap allocated buffers where each sub-buffers (along the first coordinate) are no longer guaranteed to be contiguous in memory. Considering the actual size of the array here being 64^3, the total memory size can vary from 0.26 MB to 2.09 MB per chunk (considering you only store simple integral type into it). While it may work for a single chunk, it is totally unthinkable to render an entire world with statically allocated arrays of that size.
@chackiejan33534 ай бұрын
As neat as the lattice method is, it doesn't seem practical. If you're targeting newer desktop GPUs, octrees and ray tracing are the way to go. If you need to use rasterization either for consoles, mobile, or older GPUs, vertex compression, octrees, LODs, and compute-based occlusion culling is the way to go. For examples of the latter, Ethan Gore has excellent KZread demo's of a voxel engine using traditional rasterization with OpenGL and achieving mind-bogglingly large voxel worlds many, many times larger than this at <2ms on a GTX 1070.
@JustAskQuestions4 ай бұрын
What is going on with this project/data structure approach? I came across you via your talk and was interested enough to look into what this is ultimately capable of. I can't find anything better than this. I tried all sorts of different spellings of Voxely without success. I searched your name. I found your Twitter, where you stopped posting just after the talk. I found this channel, where you also stopped posting after your talk. A year without updates anywhere? Did you hit a roadblock? Did something about the VRAM usage or overdraw make this approach unfeasible? Obviously you sell your work so there may be NDAs and trade secrets involved, but speaking from the outside, if that's the case maybe an internal conversation is in order. If KZread's algorithm has decided to now give you attention, you might want to have something more impressive and recent somewhere searchable.
@davis-morley4 ай бұрын
Voxely doesn't use this technique, it is just the company where I was working at the time of this talk. Frankly I just want to work on other projects and don't want to dedicate more time to the Global Lattice, I haven't worked on it since. The technique is very feasible especially with suggested additions I've made in the comments of the original talk video. I am under no NDAs relating to this talk.
@JustAskQuestions4 ай бұрын
Good to know and certainly understandable. Thanks for the reply :)@@davis-morley
@DementioMod4 ай бұрын
I also just saw your talk. Do you think you will ever release pseudocode for the binary greedy meshing and/or lattice system? I think this would be hugely beneficial to the voxel game dev community, as most "efficient" voxel tutorials just use basic greedy meshing. @@davis-morley
@Moonz974 ай бұрын
Thats awesome! Wont you still need to do meshing for the physics colliders?
@davis-morley4 ай бұрын
People always say this but in my mind you would just have your own physics solver or only mesh the relevant chunks (with binary greedy meshing) whenever you need to. The cost of binary greedy meshing is so low that this is feasible if required.
@kappascopezz51224 ай бұрын
The 3D/index conversion can be simplified to be more intuitive if you just see it as packing 3 different numbers into the different bits of a number. x + 64 z + 64² y is the same as (x) | (z << 6) | (y << 12), and this is the same as just concatenating the three 6 bit numbers in binary to get a single 18 bit number. Edit: Okay I've watched further, and doing what I proposed would have been pretty awkward for the presentation because the next step also uses binary, and it would probably get confusing But a more important addition: What your global lattice does is have the GPU check on every point where a pixel intersects with a plane that is aligned with the surfaces of your voxels. But doing that doesn't actually need rasterization, you can just run a loop with the ray/plane intersections on the GPU. Doing that is called voxel traversal, and it can be simplified a lot if you do good bookkeeping for the repeated ray/plane intersections. I also saw a paper about having it support empty voxels of varying size, so that you can skip larger pieces of air, but I haven't read it in detail yet.
@maksymiliank51354 ай бұрын
sounds like using an octtree where the root is the entirety of the visible world and last layer of nodes represents the chunks, and if a branch ends early then that means its an area filled with air. Edit: I just realized that you can further subdivide a chunk to be 1/8 or 1/(8^2), etc. and if any of those volumes is empty then you can skip it as well.
@fast-yi9js4 ай бұрын
Its a shame about the example clip they used at the start, that game project went dead silent after the first two tech teasers years ago
@omargoodman29994 ай бұрын
Sometimes, the only reason something is technically impossible is because all the technical experts in the field are so insistant that it just _cannot_ be done. It's impossible, so don't waste your time and (more importantly to them) don't waste *their* money attempting it. There are *so many* far better, more effective, more efficient ways to do _just about everything;_ not just technical stuff like this, but *everything.* From economics to education to even more abstract things like philosophy and self-awareness, it's possible to do better than you're currently doing; all you have to do is stop insisting it's impossible, and just _try._ And not just a token display where you design the attempt to fail, just to prove it's impossible; but a real, genuine effort to test it. Sure, it's great to learn from the mistakes of others; you don't need to re-invent the wheel and you don't need to do it wrong yourself if you've already witnessed someone else make the same mistake. But *did* _you_ witness the mistake? Technology was re-invented at times when it was either lost, or in separate parts of the world before its prior invention from one part had spread to another. Don't re-invent the wheel, invent a *better* wheel; you can patent it if it's different and innovative enough.
@1234macro4 ай бұрын
Very cool, but you gotta stop with the bold and italics. It's a chore to read.
@omargoodman29994 ай бұрын
@@1234macro It's to replicate the major and minor verbal emphasis I'd put on words or phrases if I were speaking. It helps better convey the tone and avoid the flattening that happens in long posts, since I can't really pick up on tone differences intuitively. In other words, it's how I adjust for my ASD so my writing doesn't come across with incorrect emotional projection; I've had that issue before, where I type something in an explanatory or educational tone, but without my normal speaking emphasis, they read it as a rant or an angry, accusatory post. So just let it flow naturally as speech with bold as emphasized words, and italics as half-emphasized words.
@1234macro4 ай бұрын
@@omargoodman2999 Tone indicators should be used sparsely, and is a matter of taste. Your usage comes across as preachy and corny. You should seek to convey your tone through improved writing as opposed to enriching the glyph itself. Tone indicators _ought to_ be used *sparsely,* and is a matter of taste. _Your_ usage comes across as *preachy* and *corny.* You _should_ seek to convey your tone through improved _writing_ as opposed to enriching the glyph itself. I know which version _I_ prefer.
@omargoodman29994 ай бұрын
@@1234macro Actually, the second version is a lot easier for me to read. I read it, but my brain automatically processes it like "voice". It sounds more natural and explanatory. The first one is just flat text.
@1234macro4 ай бұрын
@@omargoodman2999 In that case, you might have a form of dyslexia.
@petepi4 ай бұрын
Right?
@BorderKeeper4 ай бұрын
You could say that this presentation was Really Powerful
@sentinelav4 ай бұрын
Hey if this was your first public speaking event, you killed it!
@davis-morley4 ай бұрын
Thanks! Appreciate it.
@cheako911554 ай бұрын
Just skipped over how to implement the naive mesh, pointing to an example would have been nice nothing relevant in google?
@niuage4 ай бұрын
Oh yea, there are so many tutorials for naive meshing. Literally just go over any minecraft tutorial on youtube, they never bother going past the naive meshing. Google b3agz minecraft series, follow it, and you'll know how to do naive meshing.
@TinyDeskEngineer4 ай бұрын
"55 FPS is slow" Really? I don't even find 30 to be slow. If I saw a video that's 30 FPS and a video that's 60 FPS, I doubt I'd even be able to tell them apart.
@ImmoralKoala4 ай бұрын
Yep, there's a big difference between 30, 60 and 144. It's less noticeable on video because you're not inputting anything. higher fps noticeably improves the responsiveness and smoothness of games.
@k_otey4 ай бұрын
55 FPS is definitely slow. in the context of real-time rendering for games, that is. and yes, the difference between 30 and 60 is definitely noticeable. most people can tell them apart. what is the refresh rate of your monitor?
@arthur111213217 күн бұрын
It is slow in the context of real time rendering. First of all, we tend to easily forget that FPS are actually a verry bad benchmarking unit as it is non linear. Loosing 5 FPS from 60 to 55 is not the same as loosing 5 FPS from 200 to 195: the former means a 1.51 milliseconds loss while the later only represents a 0.12 milliseconds difference. Now, even if it is highly dependent on the exact hardware you have, most of them are able to reach over 60K FPS when rendering less than a few tousands of triangles, which means a minimum of roughly 0.016 milliseconds or 16 microseconds per frame. When working with realtime rendering, we often consider our program as having a "frame time budget" that we are gonna spend across all of our different features. 55 FPS means 18.18 milliseconds per frame, which is probably finewhen talking about a completely finished game (even tho some would argue with that). However, when talking about a prototype like in the video where the only thing done is meshing and rendering a single 64^3 chunk, 18 milliseconds IS slow because it basically means that all of your time budget has been spent on that chunk only and that you won't be able to spend much more for anything else without negatively impacting the overall performances of your project.
@question_mark4 ай бұрын
overdraw 💀
@theashbot40974 ай бұрын
I am confused on how the global lattice works. If you have a mountain in 3D space and only render the 6 faces of a chunk, then you get closer to the mountain wouldn't you clip into the chunk and then see nothing? I feel like I missed something. If I did please let me know.
@konignickerchen72654 ай бұрын
You aren't rendering just the boundaries of the chunk, that would just be 6 faces total. Instead, you are rendering every possible slice of the chunk along all 3 axes, hence 6*64 faces.
@theashbot40974 ай бұрын
@@konignickerchen7265 Oh OK.
@TheBigLou134 ай бұрын
would've liked to see the type buffer - isn't the whole map stored as 3D-VU-maps in vram this way? where are the limits here for various graphic cards?
@austindolan31424 ай бұрын
That was an amazing talk
@morthim4 ай бұрын
amazing talk
@morthim4 ай бұрын
using a non-triangle vertex really popped out at me as having potential.
@teok99644 ай бұрын
I think the main problem is hardware for this sort of solution, GPUS are very optimized for triangles already and trying to go against that would be needlessly inefficient, at least until we have better inbuilt voxel solutions on the GPU. sort of like how the new raytracing GPUS now have that built in.
@ravenmillieweikel38474 ай бұрын
The only issue I can see with this voxel lattice system is OBSCENELY MASSIVE amounts of overdraw.
@uis2464 ай бұрын
9:19
@ravenmillieweikel38474 ай бұрын
@@uis246That only applies to the naive, greedy, and binary greedy meshing algorithms. You can’t punch a hole in a quad without adding more vertices, and that’s what the voxel lattice technique is trying to avoid.
@IsmeGenius4 ай бұрын
Yeah, very suspicious that author does not even touch on this. And his replies elsewhere in the comment section he is very vague about it.
@ravenmillieweikel38474 ай бұрын
@@IsmeGenius I can see it working for small-scale voxel rendering, but for a large world? This is quite literally the worse case of overdraw I have ever seen, bar none. Not even shell texturing comes close to this level of absurd.
@uis2464 ай бұрын
@@ravenmillieweikel3847 voxel lattice doesn't create big quads in the first place. As an example you can play minecraft and in spectator mode move inside wall of blocks and you will see, or rather not see all the quads that are occluded by other voxels.
@DrenKillfree4 ай бұрын
yeah, I'm barely keeping up with you here but thats pretty slick. I'd love to see some places thats been put into practice
@anastasiaklyuch27464 ай бұрын
How do we handle collisions? This is kinda pointless if we don't have any.
@stoician4 ай бұрын
Although it is usually implemented that way in 3D engines, collision detection doesn't need triangles. In this case, sampling the voxel array directly will work just as well.
@anastasiaklyuch27464 ай бұрын
@@stoician whoa, I wish to implement this in Godot, but I can't really imagine from the description. It would be cool, but how would anything know how to collide and what normal to bounce around without triangles? How do we ensure collisions match the visual mesh?
@Chrisknyfe4 ай бұрын
I do a "greedy meshing" algorithm that finds the largest possible rectangular prisms to represent the solid voxels. Start with the first unmeshed voxel, expand in X direction, then Y direction, then Z direction as far as you can. Then do the same for each unmeshed voxel. Take all those rectangular prisms together as collision shapes for your kinematic body, and you're done!
@stoician4 ай бұрын
@@anastasiaklyuch2746 I was thinking in a full custom sort of way, but if you are using Godot, there are things you could leverage to skip the details. Keep in mind, I've never used Godot, so this is only after a quick look at the documentation, but it looks like a StaticBody3D containing BoxShape3D for each voxel would do it. Knowing that the fragment shader is going to be using the fragments location in 3D space rounded to the nearest whole number to index into the voxel array, you would iterate over the voxel array on the CPU and when a solid voxel is found use the index to generate the location coordinates to place a BoxShape3D there. But that will be a lot of BoxShape3Ds, which might be too much for the physics engine. So a more optimized way would be to use the coordinates of the movable object/player character to generate an index and loop over the nearby voxels to place BoxShape3Ds in only those locations. Then as the object moves, also move the BoxShape3Ds that get too far away to the voxels that get closer. That should be extremely fast since it will only require a handful of Shape3Ds. To go more towards what I was thinking in my original reply, there might be ways to improve the efficiency further by subclassing Shape3D to make a VoxelChunkShape3D, but that would require deep knowledge of how Shape3D interacts with the physics engine. Perhaps looking at how SphereShape3D and BoxShape3D are implemented will provide some hints.
@geekazodium4 ай бұрын
out of curiosity, would there be overdraw problems with that many meshes drawn on top of each other?
@ukyoize4 ай бұрын
You could draw meshes front-to-back
@IsmeGenius4 ай бұрын
@@ukyoize It will still need to compute at least depths, up to 8k or more times for each pixel, excessive to say the least.
@ZERR0R4 ай бұрын
Getting X, Y and Z coordinates from a one-dimensional index when the size of the chunk is a power of 2 is much faster with bitwise operations. Instead of the modulo operation (index%64) do the AND (index&63), and instead of integer division (index/64) do shifts (index>>6). Division (and modulo, since you still have to divide to find the modulo) are slow operations, and bitwise operations are much faster. But I'm sure it's still fine to write it the way shown in the video, since the compiler is probably smart enough to realize what you are trying to do and will optimize it anyways into bitwise operations.
@davis-morley4 ай бұрын
Yeah, I've tested in the past with clang and it didn't change anything, probably still worth it for debug builds though!
@abcxyz58064 ай бұрын
Also bitwise and does the correct thing for negative numbers, where modulo will return a negative number!
@ZERR0R4 ай бұрын
@@abcxyz5806 Well, I don't think that working with negative array indexes is a good thing in the first place, but if you want, you can. And I don't see how it's helpful in any way here... but technically it works...
@BleachWizz4 ай бұрын
Brilliant, I loved it. You ended up on the best solution possible in my book. And I do mean it. Always when possible the best solution is to not have a problem, so if you have a problem you just stop and think: "but what if it's not a problem". And then you don't have a problem anymore. it's perfect.!
@iZulach5 ай бұрын
If it's seamless what are the visible seams?
@davis-morley5 ай бұрын
This was right after I figured out the technique and is an old video that was uploaded *at* the conference basically just to give people a rough idea. The seams are actually not from any streaming or anything its just from how the types are being sampled in this early version. The technique is seamless in the sense that there is no meshing, unlike in games like Minecraft where you have to mesh a chunk before uploading it to the GPU the only thing you have to upload is the data itself. So the data flow you see here is how it works, the visual artifacts are not the "seams" I'm referring to and are merely a byproduct of the initial discovery.
@mrbonono29515 ай бұрын
How are you texturing the individual voxels? Are you sending pre-computed textures from the cpu to the gpu? Are you sending the individual voxel data to the gpu instead and iterating through each individual voxel's data to decide the texture for each face? Which would be theoretically be faster since you could implement it to process it in parrallel. How I'm unsure. Either way your are storing a LOT of data rendering so many chunks, in the video you are repeating the chunk data, so did the data format stop you from implementing more? Performance will be worse with run length encoding, but is there a way to parrallelize that on the GPU as well for each pixel or something? What graphics api are you using? Why did you stop development? Would you consider releasing the source code to the public?
@davis-morley5 ай бұрын
I am repeating chunk data because this was literally right after I discovered it and I just uploaded a single chunk to test it. When it comes to data you can do tons of things, you could store the types naively like you said, you could store the type surface manifold in an array or texture and uv into it using the faces, you could have a virtual streaming system which is something I myself have tried and works really well. You could store compressed data on the GPU and decompress it on the fly for whatever chunks need it! This video necessarily was memory capped because the lattice itself was representing quadrillions of voxels. This was using Vulkan. I might consider uploading the source but it would have to get a polish pass which is kind of low priority now. I also have some better ideas I'd like to share sometime so maybe I'll end up going with those instead.
@mrbonono29514 ай бұрын
@@davis-morleyThanks for the reply. You talk was super interesting. I have been implementing the same idea myself because in terms of memory usage the lattice technique is super efficient. I haven't gotten around to implementing it, but since I'm not all that good at shader code I'm planning on creating on big texture per face and sending it to the gpu. The lattice size, will suffer, and now there is some reliance on the cpu to computer which I don't like, but this technique is really undocumented from the rudimentary research i did, or at the very least uncommon. Super cool stuff, thanks for making that talk!
@jonathanhallstrom5 ай бұрын
17:58 it seems like you should be able to binary search this
@jonathanhallstrom5 ай бұрын
should take you from 8 ands to 3, albeit adding the creation of the masks
@davis-morley5 ай бұрын
@@jonathanhallstrom Yeah I think this is a matter of trade offs. I'm unsure that this would be actually faster but I'd have to check!
@DreadKyller5 ай бұрын
I'm a bit confused about one point. You used an example of an 8192x8192x255 sized world. That's 17,112,760,320 voxels, if each of those voxel positions was associated with a material, and let's say we allow 1 byte for each material id that's 17 GB of material data that you're saying to store on the GPU. That takes up the 71-72% of the VRAM on a 4090. Obviously this data could be compressed but still even such that's a pretty astronomical amount of data. Are you doing anything in particular to optimize that, Octrees, DAGs, RLE, anything? Because if so that wasn't presented and it'd be interesting to hear about it. Preliminary tests with this method on smaller worlds the performance seems good in crowded areas with close by geometry due to distance checks, but on very wide open areas the performance of this seems to drop significantly, to the point there I get much better performance just sticking with static planes for each chunk over the entire world as I can skip rendering entirely of completely empty chunks and thus have far, far reduced overdraw in very open scenes (like pains with lots of open air). Number of triangles doesn't necessarily carry over into better performance.
@davis-morley5 ай бұрын
I agree the triangle count is not always the cost here, its more that it makes the scene very easy to represent. When it comes to data there is necessarily in any game ever a point where you add a constraint such as "I am not going to have every single voxel set in the entire world". For instance an occlusion culling method is necessarily an optimization for a general case and is expecting the player to not be able to see every single piece of geometry at once in the world, this is technically a design constraint and is something that can be considered during development. The naive solution actually gets you very far, as in, expecting that the entire world will not be set at once. Obviously this will change directly with however you are doing terrain generation but you can optimize around this. As for overdraw there are many obvious solutions. My point with this talk was to provide a good general solution for a common archetype of game being the block game. The method works especially well with a world that is not cubic, so where there are more fragment tests in this world (the horizontal axis, 8192 x 8192) these are also the axis more likely to be populated with voxels, cutting down the overdraw. A really easy method to expand into is what you're mentioning, have a lattice per-chunk and do it that way, it would drastically decrease overdraw definitely. Another thing to try is to order faces and the draw calls of said faces based on a line algorithm every frame. E.g. in a compute shader, for every chunk based on its position relative to a camera, get a perspective correct ray and basically run DDA on it, getting the optimal ordering of faces using the reciprocal of the camera direction and then order your draw calls as such. This way you could analytically draw perfectly ordered faces, this also would be great for transparency sorting!
Пікірлер
where can i try this/make a game with this?
You used y as the up axis instead of z? Literally unwatchable
What you mean, Y has always been the up axis in 3D space and video games
@@Ethanthegrand Z is the up axis in pretty much all of mathematics, I wouldn't know about games. My comment was not serious either, I really enjoyed the video.
@@seftondepledge3658 ahh I see. Growing up coding, when working with 2D games, X is left/right, Y is up/down, which makes sense, and introducing Z adds the forward/back axis
To be exact, any axis could be up without any noticeable consequences as long as the positive directions are maintained relative to each others following the right hand rule (which basically means that the cross product of 2 axis gives the third one). So if +X is right, and +Y is up, then +Z must be back. I tend to prefer having Z upward because it means that X can stay pointed toward the right and Y becomes positive towards the front, which makes more sens to me, and I think this is also the reason why mathematics sticks to that norm as well. However, just like I was saying at the begining, it barely change anything in the end as the direction ultimately ends up to be relative to the camera orientation.
@@arthur1112132 Oh, it makes absolutely no difference to the maths I agree. But my brain prefers it that way. I think it also makes sense (in maths at least) as you are used to 2d graphs being on paper on a desk etc where the x-y plane is horizontal. So z being the vertical axis is just an extension of this. Not a reordering.
Where is z(n+1) = z(n)^2 + C (mandlebrot) ??? I did not see this nice application of complex numbers in the video.
hackers crack the code, game devs write the code
Can the voxels be edited at runtime, like in Minecraft? Or is this mostly only useful for pre-baked, static, or algorithmically generated terrain?
That actually is the main benefit of this technique. Since you don't have to mesh you can, in one way or another (could just be a naive buffer), just upload the voxels directly to the gpu to be sampled whenever.
@@davis-morley Ah! So literally just raw voxels, not blocks or an Unreal-style terrain mesh?
you are smart as fuck bro
I love what the captions say at 13:10
Delete and modulo may be replaced by shift and mask for getting coord from index.
I worked in a studio at some point that did that trick you showed at the end. It worked for a while but we ran into issues with overdraw especially on lower-end hardware. All that air is being meshed and being drawn, thousands if not tens of thousands of layered transparent triangles that the GPU can't optimize. You can fix this with Raymarching in the fragment shader instead. So instead of 64*6 faces, you do 6 faces 1 giant cube for the chunk, then raymarch inside it usually outperforms the 64*6 faces.
I love setting RGB to position mod 1!!!! I do it so much when I debug and test shaders!! haha, I thought it was funny that I'm not the only one!
how do you render different color/materiality of block types with these optimizations?
What if some of your voxels can have different models, like a cube for the default, but also campfires or whatever, and different materials, like animated lava etc, would the optimizations still work?
The optimizations would still work for the voxels, but not for the new general meshed objects since they cannot be assumed to easily align to the simple 3D axis. You could still add (relatively) smaller amounts of meshes into the scene though, since the voxels are still technically rendered using meshes with depths etc.
I've done a similar approach to greedy meshing for compressing voxel models. the binary greedy meshing is really clever, never occurred to me
"really really fast, probably" what?
@13:10 requires a certain amount of what?
I just watched your talk, found it extremely fascinating as to how much optimization and thought went into the systems you were describing, and seeing it working here is fantastic. I was wondering if you have any resources you'd reccomend for learning more about these systems, or resources for ameteur programmers in general?
Sorry to only get to this now, the best advice I could give is just work on anything that excites you. Don't be afraid to experiment or to try really wacky things out. Some of my greatest experiences are from small projects where I just wanted to try out an idea or two. As for what has inspired me, I really enjoy Jonathan Blow's talks on programming and game design. Casey Muratori also has a great course called "Performance Aware Programming", its paid but definitely worth it. Note: if you do get that course get the month-to-month subscription as he has somewhat recently stated that he doesn't plan to keep it going for the rest of this year. But yeah to summarize, find something that excites you and run with it, don't be afraid to fail and just see where it takes you.
Suggestion: Make the video audio a bit louder. I had to watch this on 145% volume, and even then, I am lucky! Windows and MacOS users cap at 100%, and even then, most Linux users also cap at 100%. I am in a special situation, because I am using a window manager.
I'm so glad I finally stumbled over this video. This really inspired me on my quest to find a subject for my bachelor's thesis. I've known for some time now that I wanted to do something in the area of voxel-based procedural generation, and was wondering if a few of the concepts you mentioned could be applied to marching cubes or other isosurface extraction algorithms. Although with such great performance and the ability to render so many voxels you wouldn't need mc anymore. How would you handle collisions if the mesh of the chunk includes the air? Am I wrong in assuming that you would need a pass of your meshing algorithm that separates air and terrain(like you show) to extract a collision mesh where you need it? Or could you maybe handle collision entirely on the gpu in some fancier way than a collision mesh? Anyways, for your first talk you did very very well! I love your approach to greedy meshing and your explanatin was really nice to follow. Very good presentation - even years later.
The mesh and underlying block data don't need to have anything to do with each other. You can collision test against nearby blocks with the safe assumption that they will always be lots of individual axis aligned bounding boxes.
It's raining "right"s.
Does the global lattice use more gpu ressources due to being partially transparent?
I'm honored.
video thumbnail has t-junctions
That multidimensional array to simple array is so incredibly overexplained holy shit, this is such basic stuff. And a 3D array in any language you'd actually consider writing something efficient in would result in continuous memory anyways, so there is literally only syntactic difference between his implementation and what the compiler would produce. This is BAD.
Cool so you chose to focus only on the small kinda irrelevant part and disregard the actual meat of the talk, good job :) It did start slow tho, I'll give you that.
It's true that the coordinates to single index conversion probably didn't need to be explained taht deepely. It's trivial stuff that any programer end up learning soon enough. However, it's false to think that the language will actually do this for you. While it's mostly true for any statically allocated buffers, this is no longer the case when it comes to multi dimentional heap allocated buffers where each sub-buffers (along the first coordinate) are no longer guaranteed to be contiguous in memory. Considering the actual size of the array here being 64^3, the total memory size can vary from 0.26 MB to 2.09 MB per chunk (considering you only store simple integral type into it). While it may work for a single chunk, it is totally unthinkable to render an entire world with statically allocated arrays of that size.
As neat as the lattice method is, it doesn't seem practical. If you're targeting newer desktop GPUs, octrees and ray tracing are the way to go. If you need to use rasterization either for consoles, mobile, or older GPUs, vertex compression, octrees, LODs, and compute-based occlusion culling is the way to go. For examples of the latter, Ethan Gore has excellent KZread demo's of a voxel engine using traditional rasterization with OpenGL and achieving mind-bogglingly large voxel worlds many, many times larger than this at <2ms on a GTX 1070.
What is going on with this project/data structure approach? I came across you via your talk and was interested enough to look into what this is ultimately capable of. I can't find anything better than this. I tried all sorts of different spellings of Voxely without success. I searched your name. I found your Twitter, where you stopped posting just after the talk. I found this channel, where you also stopped posting after your talk. A year without updates anywhere? Did you hit a roadblock? Did something about the VRAM usage or overdraw make this approach unfeasible? Obviously you sell your work so there may be NDAs and trade secrets involved, but speaking from the outside, if that's the case maybe an internal conversation is in order. If KZread's algorithm has decided to now give you attention, you might want to have something more impressive and recent somewhere searchable.
Voxely doesn't use this technique, it is just the company where I was working at the time of this talk. Frankly I just want to work on other projects and don't want to dedicate more time to the Global Lattice, I haven't worked on it since. The technique is very feasible especially with suggested additions I've made in the comments of the original talk video. I am under no NDAs relating to this talk.
Good to know and certainly understandable. Thanks for the reply :)@@davis-morley
I also just saw your talk. Do you think you will ever release pseudocode for the binary greedy meshing and/or lattice system? I think this would be hugely beneficial to the voxel game dev community, as most "efficient" voxel tutorials just use basic greedy meshing. @@davis-morley
Thats awesome! Wont you still need to do meshing for the physics colliders?
People always say this but in my mind you would just have your own physics solver or only mesh the relevant chunks (with binary greedy meshing) whenever you need to. The cost of binary greedy meshing is so low that this is feasible if required.
The 3D/index conversion can be simplified to be more intuitive if you just see it as packing 3 different numbers into the different bits of a number. x + 64 z + 64² y is the same as (x) | (z << 6) | (y << 12), and this is the same as just concatenating the three 6 bit numbers in binary to get a single 18 bit number. Edit: Okay I've watched further, and doing what I proposed would have been pretty awkward for the presentation because the next step also uses binary, and it would probably get confusing But a more important addition: What your global lattice does is have the GPU check on every point where a pixel intersects with a plane that is aligned with the surfaces of your voxels. But doing that doesn't actually need rasterization, you can just run a loop with the ray/plane intersections on the GPU. Doing that is called voxel traversal, and it can be simplified a lot if you do good bookkeeping for the repeated ray/plane intersections. I also saw a paper about having it support empty voxels of varying size, so that you can skip larger pieces of air, but I haven't read it in detail yet.
sounds like using an octtree where the root is the entirety of the visible world and last layer of nodes represents the chunks, and if a branch ends early then that means its an area filled with air. Edit: I just realized that you can further subdivide a chunk to be 1/8 or 1/(8^2), etc. and if any of those volumes is empty then you can skip it as well.
Its a shame about the example clip they used at the start, that game project went dead silent after the first two tech teasers years ago
Sometimes, the only reason something is technically impossible is because all the technical experts in the field are so insistant that it just _cannot_ be done. It's impossible, so don't waste your time and (more importantly to them) don't waste *their* money attempting it. There are *so many* far better, more effective, more efficient ways to do _just about everything;_ not just technical stuff like this, but *everything.* From economics to education to even more abstract things like philosophy and self-awareness, it's possible to do better than you're currently doing; all you have to do is stop insisting it's impossible, and just _try._ And not just a token display where you design the attempt to fail, just to prove it's impossible; but a real, genuine effort to test it. Sure, it's great to learn from the mistakes of others; you don't need to re-invent the wheel and you don't need to do it wrong yourself if you've already witnessed someone else make the same mistake. But *did* _you_ witness the mistake? Technology was re-invented at times when it was either lost, or in separate parts of the world before its prior invention from one part had spread to another. Don't re-invent the wheel, invent a *better* wheel; you can patent it if it's different and innovative enough.
Very cool, but you gotta stop with the bold and italics. It's a chore to read.
@@1234macro It's to replicate the major and minor verbal emphasis I'd put on words or phrases if I were speaking. It helps better convey the tone and avoid the flattening that happens in long posts, since I can't really pick up on tone differences intuitively. In other words, it's how I adjust for my ASD so my writing doesn't come across with incorrect emotional projection; I've had that issue before, where I type something in an explanatory or educational tone, but without my normal speaking emphasis, they read it as a rant or an angry, accusatory post. So just let it flow naturally as speech with bold as emphasized words, and italics as half-emphasized words.
@@omargoodman2999 Tone indicators should be used sparsely, and is a matter of taste. Your usage comes across as preachy and corny. You should seek to convey your tone through improved writing as opposed to enriching the glyph itself. Tone indicators _ought to_ be used *sparsely,* and is a matter of taste. _Your_ usage comes across as *preachy* and *corny.* You _should_ seek to convey your tone through improved _writing_ as opposed to enriching the glyph itself. I know which version _I_ prefer.
@@1234macro Actually, the second version is a lot easier for me to read. I read it, but my brain automatically processes it like "voice". It sounds more natural and explanatory. The first one is just flat text.
@@omargoodman2999 In that case, you might have a form of dyslexia.
Right?
You could say that this presentation was Really Powerful
Hey if this was your first public speaking event, you killed it!
Thanks! Appreciate it.
Just skipped over how to implement the naive mesh, pointing to an example would have been nice nothing relevant in google?
Oh yea, there are so many tutorials for naive meshing. Literally just go over any minecraft tutorial on youtube, they never bother going past the naive meshing. Google b3agz minecraft series, follow it, and you'll know how to do naive meshing.
"55 FPS is slow" Really? I don't even find 30 to be slow. If I saw a video that's 30 FPS and a video that's 60 FPS, I doubt I'd even be able to tell them apart.
Yep, there's a big difference between 30, 60 and 144. It's less noticeable on video because you're not inputting anything. higher fps noticeably improves the responsiveness and smoothness of games.
55 FPS is definitely slow. in the context of real-time rendering for games, that is. and yes, the difference between 30 and 60 is definitely noticeable. most people can tell them apart. what is the refresh rate of your monitor?
It is slow in the context of real time rendering. First of all, we tend to easily forget that FPS are actually a verry bad benchmarking unit as it is non linear. Loosing 5 FPS from 60 to 55 is not the same as loosing 5 FPS from 200 to 195: the former means a 1.51 milliseconds loss while the later only represents a 0.12 milliseconds difference. Now, even if it is highly dependent on the exact hardware you have, most of them are able to reach over 60K FPS when rendering less than a few tousands of triangles, which means a minimum of roughly 0.016 milliseconds or 16 microseconds per frame. When working with realtime rendering, we often consider our program as having a "frame time budget" that we are gonna spend across all of our different features. 55 FPS means 18.18 milliseconds per frame, which is probably finewhen talking about a completely finished game (even tho some would argue with that). However, when talking about a prototype like in the video where the only thing done is meshing and rendering a single 64^3 chunk, 18 milliseconds IS slow because it basically means that all of your time budget has been spent on that chunk only and that you won't be able to spend much more for anything else without negatively impacting the overall performances of your project.
overdraw 💀
I am confused on how the global lattice works. If you have a mountain in 3D space and only render the 6 faces of a chunk, then you get closer to the mountain wouldn't you clip into the chunk and then see nothing? I feel like I missed something. If I did please let me know.
You aren't rendering just the boundaries of the chunk, that would just be 6 faces total. Instead, you are rendering every possible slice of the chunk along all 3 axes, hence 6*64 faces.
@@konignickerchen7265 Oh OK.
would've liked to see the type buffer - isn't the whole map stored as 3D-VU-maps in vram this way? where are the limits here for various graphic cards?
That was an amazing talk
amazing talk
using a non-triangle vertex really popped out at me as having potential.
I think the main problem is hardware for this sort of solution, GPUS are very optimized for triangles already and trying to go against that would be needlessly inefficient, at least until we have better inbuilt voxel solutions on the GPU. sort of like how the new raytracing GPUS now have that built in.
The only issue I can see with this voxel lattice system is OBSCENELY MASSIVE amounts of overdraw.
9:19
@@uis246That only applies to the naive, greedy, and binary greedy meshing algorithms. You can’t punch a hole in a quad without adding more vertices, and that’s what the voxel lattice technique is trying to avoid.
Yeah, very suspicious that author does not even touch on this. And his replies elsewhere in the comment section he is very vague about it.
@@IsmeGenius I can see it working for small-scale voxel rendering, but for a large world? This is quite literally the worse case of overdraw I have ever seen, bar none. Not even shell texturing comes close to this level of absurd.
@@ravenmillieweikel3847 voxel lattice doesn't create big quads in the first place. As an example you can play minecraft and in spectator mode move inside wall of blocks and you will see, or rather not see all the quads that are occluded by other voxels.
yeah, I'm barely keeping up with you here but thats pretty slick. I'd love to see some places thats been put into practice
How do we handle collisions? This is kinda pointless if we don't have any.
Although it is usually implemented that way in 3D engines, collision detection doesn't need triangles. In this case, sampling the voxel array directly will work just as well.
@@stoician whoa, I wish to implement this in Godot, but I can't really imagine from the description. It would be cool, but how would anything know how to collide and what normal to bounce around without triangles? How do we ensure collisions match the visual mesh?
I do a "greedy meshing" algorithm that finds the largest possible rectangular prisms to represent the solid voxels. Start with the first unmeshed voxel, expand in X direction, then Y direction, then Z direction as far as you can. Then do the same for each unmeshed voxel. Take all those rectangular prisms together as collision shapes for your kinematic body, and you're done!
@@anastasiaklyuch2746 I was thinking in a full custom sort of way, but if you are using Godot, there are things you could leverage to skip the details. Keep in mind, I've never used Godot, so this is only after a quick look at the documentation, but it looks like a StaticBody3D containing BoxShape3D for each voxel would do it. Knowing that the fragment shader is going to be using the fragments location in 3D space rounded to the nearest whole number to index into the voxel array, you would iterate over the voxel array on the CPU and when a solid voxel is found use the index to generate the location coordinates to place a BoxShape3D there. But that will be a lot of BoxShape3Ds, which might be too much for the physics engine. So a more optimized way would be to use the coordinates of the movable object/player character to generate an index and loop over the nearby voxels to place BoxShape3Ds in only those locations. Then as the object moves, also move the BoxShape3Ds that get too far away to the voxels that get closer. That should be extremely fast since it will only require a handful of Shape3Ds. To go more towards what I was thinking in my original reply, there might be ways to improve the efficiency further by subclassing Shape3D to make a VoxelChunkShape3D, but that would require deep knowledge of how Shape3D interacts with the physics engine. Perhaps looking at how SphereShape3D and BoxShape3D are implemented will provide some hints.
out of curiosity, would there be overdraw problems with that many meshes drawn on top of each other?
You could draw meshes front-to-back
@@ukyoize It will still need to compute at least depths, up to 8k or more times for each pixel, excessive to say the least.
Getting X, Y and Z coordinates from a one-dimensional index when the size of the chunk is a power of 2 is much faster with bitwise operations. Instead of the modulo operation (index%64) do the AND (index&63), and instead of integer division (index/64) do shifts (index>>6). Division (and modulo, since you still have to divide to find the modulo) are slow operations, and bitwise operations are much faster. But I'm sure it's still fine to write it the way shown in the video, since the compiler is probably smart enough to realize what you are trying to do and will optimize it anyways into bitwise operations.
Yeah, I've tested in the past with clang and it didn't change anything, probably still worth it for debug builds though!
Also bitwise and does the correct thing for negative numbers, where modulo will return a negative number!
@@abcxyz5806 Well, I don't think that working with negative array indexes is a good thing in the first place, but if you want, you can. And I don't see how it's helpful in any way here... but technically it works...
Brilliant, I loved it. You ended up on the best solution possible in my book. And I do mean it. Always when possible the best solution is to not have a problem, so if you have a problem you just stop and think: "but what if it's not a problem". And then you don't have a problem anymore. it's perfect.!
If it's seamless what are the visible seams?
This was right after I figured out the technique and is an old video that was uploaded *at* the conference basically just to give people a rough idea. The seams are actually not from any streaming or anything its just from how the types are being sampled in this early version. The technique is seamless in the sense that there is no meshing, unlike in games like Minecraft where you have to mesh a chunk before uploading it to the GPU the only thing you have to upload is the data itself. So the data flow you see here is how it works, the visual artifacts are not the "seams" I'm referring to and are merely a byproduct of the initial discovery.
How are you texturing the individual voxels? Are you sending pre-computed textures from the cpu to the gpu? Are you sending the individual voxel data to the gpu instead and iterating through each individual voxel's data to decide the texture for each face? Which would be theoretically be faster since you could implement it to process it in parrallel. How I'm unsure. Either way your are storing a LOT of data rendering so many chunks, in the video you are repeating the chunk data, so did the data format stop you from implementing more? Performance will be worse with run length encoding, but is there a way to parrallelize that on the GPU as well for each pixel or something? What graphics api are you using? Why did you stop development? Would you consider releasing the source code to the public?
I am repeating chunk data because this was literally right after I discovered it and I just uploaded a single chunk to test it. When it comes to data you can do tons of things, you could store the types naively like you said, you could store the type surface manifold in an array or texture and uv into it using the faces, you could have a virtual streaming system which is something I myself have tried and works really well. You could store compressed data on the GPU and decompress it on the fly for whatever chunks need it! This video necessarily was memory capped because the lattice itself was representing quadrillions of voxels. This was using Vulkan. I might consider uploading the source but it would have to get a polish pass which is kind of low priority now. I also have some better ideas I'd like to share sometime so maybe I'll end up going with those instead.
@@davis-morleyThanks for the reply. You talk was super interesting. I have been implementing the same idea myself because in terms of memory usage the lattice technique is super efficient. I haven't gotten around to implementing it, but since I'm not all that good at shader code I'm planning on creating on big texture per face and sending it to the gpu. The lattice size, will suffer, and now there is some reliance on the cpu to computer which I don't like, but this technique is really undocumented from the rudimentary research i did, or at the very least uncommon. Super cool stuff, thanks for making that talk!
17:58 it seems like you should be able to binary search this
should take you from 8 ands to 3, albeit adding the creation of the masks
@@jonathanhallstrom Yeah I think this is a matter of trade offs. I'm unsure that this would be actually faster but I'd have to check!
I'm a bit confused about one point. You used an example of an 8192x8192x255 sized world. That's 17,112,760,320 voxels, if each of those voxel positions was associated with a material, and let's say we allow 1 byte for each material id that's 17 GB of material data that you're saying to store on the GPU. That takes up the 71-72% of the VRAM on a 4090. Obviously this data could be compressed but still even such that's a pretty astronomical amount of data. Are you doing anything in particular to optimize that, Octrees, DAGs, RLE, anything? Because if so that wasn't presented and it'd be interesting to hear about it. Preliminary tests with this method on smaller worlds the performance seems good in crowded areas with close by geometry due to distance checks, but on very wide open areas the performance of this seems to drop significantly, to the point there I get much better performance just sticking with static planes for each chunk over the entire world as I can skip rendering entirely of completely empty chunks and thus have far, far reduced overdraw in very open scenes (like pains with lots of open air). Number of triangles doesn't necessarily carry over into better performance.
I agree the triangle count is not always the cost here, its more that it makes the scene very easy to represent. When it comes to data there is necessarily in any game ever a point where you add a constraint such as "I am not going to have every single voxel set in the entire world". For instance an occlusion culling method is necessarily an optimization for a general case and is expecting the player to not be able to see every single piece of geometry at once in the world, this is technically a design constraint and is something that can be considered during development. The naive solution actually gets you very far, as in, expecting that the entire world will not be set at once. Obviously this will change directly with however you are doing terrain generation but you can optimize around this. As for overdraw there are many obvious solutions. My point with this talk was to provide a good general solution for a common archetype of game being the block game. The method works especially well with a world that is not cubic, so where there are more fragment tests in this world (the horizontal axis, 8192 x 8192) these are also the axis more likely to be populated with voxels, cutting down the overdraw. A really easy method to expand into is what you're mentioning, have a lattice per-chunk and do it that way, it would drastically decrease overdraw definitely. Another thing to try is to order faces and the draw calls of said faces based on a line algorithm every frame. E.g. in a compute shader, for every chunk based on its position relative to a camera, get a perspective correct ray and basically run DDA on it, getting the optimal ordering of faces using the reciprocal of the camera direction and then order your draw calls as such. This way you could analytically draw perfectly ordered faces, this also would be great for transparency sorting!