3D World Generation: #3 (Quadtree & LOD) 

Hello, how do you blend the vertices for each plane in the quadtree?

@@diegomacias7727 i guess he does not... but I am not sure

ty, got anything you wanna see covered in future vids?

Np, what are you building?

@@simondev758 An open world game that runs well on my phone. I'm particularly interested in having the land change based on climate, rockiness etc instead of biomes

Great idea! Yeah that'll totally work, I actually do it later in the series, I think it's #7.

Pretty sure it's just one of the canned ones with three.js.

@@simondev758 Thank you!

No problem, glad you're finding it useful. As for your question, yeah I'm recreating it every frame. Is it the best possible way to do this? Almost certainly no, but it's more than fast enough for showing off the technique, and it's simple to understand. I'm a big fan of profiling to decide when to optimize, and this runs at 60fps easily, so I doubt that the quad tree code contributes much per frame.

@@simondev758 Yeah. You're doing it the standard way. It's faster to rebuild the tree than try to adjust it every frame

Thanks, are you working on something related?

@@simondev758 Nah. But I Like To Watch Javascript Based 3D Modeling, Images, Video

nice

Dynamic tessellation is definitely something I'd like to add, but hasn't been high on the TODO list. re: second idea, yeah I think I've read about that idea, although I haven't tried it myself. The only concern I have there is that as you move, you want to do it incrementally so that the entire mesh doesn't bounce around. It's an interesting approach though.

@@simondev758 thanks. It’s awesome, that you invest the time to reply.

These are just vertex shaded IIRC, I don't touch on textures until a later video.

Awesome, yeah I try to explain it in a way that isn't platform specific. What did you end up implementing it in?

@@simondev758 Well, I implemented a quadtree before, I was just trying to get into it even more. FYI, I implemented QuadTree in Godot, it's freely available. github.com/sairam4123/QuadTree-Godot

Nice, haven't tried Godot yet, on my TODO list of things to try.

Don't forget to check it, it's cool. I've been using it to develop my big game.

Yep, fixing the seams is on my todo list :) When I get a minute away from the kids, I'll just go over every project and make sure they're all up. Hopefully today.

Yeah, I pretty much came across the same issue. It was impossible to not notice the seams when the camera is closer to the ground, like how a player standing on the ground would see things. Although I haven't quite figured out how to work it out, my theoretical solution for this was to have a transition when a smaller chunk meets a larger one. The idea is that the row of vertices in the larger chunk are the same distance apart where the large chunk meets the small chunk, and the row after it is normal. In that row of squares only, you have 3 triangles per square instead of 2. It's hard to explain in just words, so I left a link to a picture of what I mean: gyazo.com/45369ef94042c0d66c8b1425a587aee5 I haven't quite figured out how to put that idea into code, since it basically alters the foundation of triangle generation that I set up earlier, but that's the idea of it.

I ran into this with LOD planets and would also like a solution

Sorry for the late reply, these reply comments don't seem to show up in the admin dashboard in youtube so I had no idea anybody had asked. I haven't revisited this yet, but off the top of my head I think you need to create a skirt around the quadtree cells. I'd imagine that you could either tessellate the lower resolution cell near the edges, or (easier) just force the vertices near the edges of the higher resolution cell to match their neighbours. This should just require a cell to have the edges of the graph and to use neighbouring cells for guidance when generating.

Noise is random but continuous

So I have it fixed locally, but haven't made the video yet. I'll describe the fix. Assuming you've fixed the actual gaps between different chunks, you've still got lighting discontinuities caused by the normals. You're on the right track, the normals are the issue. The problem is that the normals are generated by generating face normals, and then averaging all the face normals for each vertex. Imagin3 2 triangles that share an edge. The 2 vertices that form that edge, when you calculate the normals, will get a normal that's averaged from the 2 different triangle faces. Then imaging if those 2 triangles had the exact same edge, but you didn't average those normals for the edge vertices, you'd see a lighting discontinuity there. There's a bunch of complexity here because you're calculating different levels of detail, and additionally they're being generated on different threads. What I did was used a stable way of generating normals for those edges, by taking finite differences instead of face normals. It worked pretty well, not 100% sure it's the way to go, but so far it works.

@@simondev758 Oh thanks! I got the normals looking good by generating an extra column and row on each side of the chunk to get the correct normal at the edge of the chunk.

@@DomainDrivenDavid Nice! Are you using different levels of detail too? I tried that approach, but wasn't able to fully get rid of the lighting discontinuities.

@@simondev758 Yes, 88 quads of 100x100. I am no pro tho, so it may very well be that you see lighting discontinuities where I do not. I can link short video if you like.

@@DomainDrivenDavid I'm kinda curious, can you run a test where you reduce the chunk resolution super low, like 4x4, and see if the lighting holds up between neighbouring chunks of different resolutions? Need to make the terrain pretty bumpy. This is how I got mine to show the problems prominently.

I haven't yet, coming in a later tutorial. I swear, I'll actually make one at some point. I actually have the code for some later stages done, but getting around to making a video takes me forever.

Interesting, got some code with the changes? And any idea how much of a speedup that provides?

@@simondev758 instead of using if checking every chunck you can just round position to exact chunk origin and get chunk id (thou to go deeper you must use loop). Example: floor(x*chunksizex)/chunksizex - gives x origin of the chunk that contain that x coordinate. Dividing again by chunksizex will return chunk number from 0 x

I dont know by how much exactlcy it speedup, because I were doing something simillar before these tutorials on GML

I think in this video I was working towards a planet for a later video, so the structure isn't appropriate for infinite size.

WebGPU just landed in a recent version of chrome, so yeah as of now it's available.

Thanks! I'll check those out. This series also integrates threading later, I think around #6.

I deal with them in a later video

Not quite, Three.js is a wrapper over WebGL. Its' responsibility is to make that easier, add additional functionality like texture/model loading, scene management, that sort of thing. There's really nothing that will "move" things from the cpu to the gpu except you, the programmer. Writing these for the cpu is just easier, making this all run on the gpu is totally doable but adds an extra layer of complexity to these tutorials.

@@simondev758 Thanks, that clears it up. Follow up question, where exactly do you need to implement changes to make it run in the GPU? In the custom shaders you're writing?

@@ezequielgarrido51 In WebGL2 yeah, you'll write it in the vertex shader to deform the mesh.

@@simondev758 Thanks!

It's all on github: github.com/simondevyoutube

Octree divides 3d space into 8 children, along each axis. This only takes xz into account.

@@simondev758 gotcha thanks for the explanation