Nice stuff, very well structured video! It seems like this method wouldn't be able to handle mapping areas with a "roof", like a cave, inside a building, or underwater. Do you have any plans to expand it for that? The simplest method I can think of would be to flag certain objects (water surface, roof of building, cave top) as transparent to the depth map depending on which "floor" the map is on. How do you think this would perform? And is that feasible for a procedurally generated world?
very interesting! I have not thought about this. The first thing that comes to mind is from an old Nvidia paper about order independent transparency using depth peeling. The idea is that you use multiple render passes, but constantly discard fragments if their depth is at least as close to the camera as their value in the previous depth buffer. They would use compositing to combine these passes into a single image with correct transparency, without needing to order anything. This could work for the map too I imagine. Alternatively, for human made structures you could create a different render pass altogether that renders paths/roads/hallways into a buffer, which you could composit onto the map. I might tackle this if I end up doing structure generation ;)
@@Code_JarThank you, some useful avenues for me to research there. The layered depth method certainly sounds fun, although the separate render pass would probably be nicest. Especially, as you say, with man-made structures allowing to highlight them to the player more easily
Using rasterization, wouldn't mean that you could not utilize frustum culling? Because meshes that are behind in the first person camera, could be visible from the map camera
I assume that Godot handles frustum culling per camera. Frustum culling does not delete objects or modify the scene, rather it is about not sending useless rendercalls to the GPU (i.e. meshes outside the view frustum which wouldn't be drawn to the screen buffer). Additionally, the secondary camera can use a subset of the render layers. For instance, we do not have to render the water, details and the player mesh.
man watching this makes me sad I nerver figured out why procedural terrain I made in godot was always so laggy I tried other people's projects and sent mine to others but the issue was only on my end and I never figured it out with godot 4 maybe I should give it another go but I dont have that much time anymore and I'd feel like investing that much time to godot instead of vulkan for example is kind of a waste
It's challenging but extremely rewarding :) I do not think I would be a waste of time, especially if you want to focus on procedural terrain generation. Personally, I want to start a simple volume rendering project in Vulcan in 2025, as I only have experience with OpenGL, and I would like to broaden my horizons. However, terrain generation is challenging enough so it is nice to implement that in a game engine that takes care of all the rendering :) Good luck with your future endeavours :)
@@Code_Jar thank you, you too I will have any significant spare time only after may of 2025 so that's fun and yeah problem solving/optimizing is rewarding, but not debugging some issue noone has had online and that only appears on your end(I think I tried it on my cheap laptop and it worked better)
Love the explanation! As a big fan of botw I think you nailed it.
Thanks! BoTW has got to be one of my favorite games of all time :)
I saw your blogpost about it some time ago. Good to see video version of it ;)
Yeah I decided to create a video for it, glad you liked it :)
Nice stuff, very well structured video! It seems like this method wouldn't be able to handle mapping areas with a "roof", like a cave, inside a building, or underwater. Do you have any plans to expand it for that?
The simplest method I can think of would be to flag certain objects (water surface, roof of building, cave top) as transparent to the depth map depending on which "floor" the map is on. How do you think this would perform? And is that feasible for a procedurally generated world?
very interesting! I have not thought about this.
The first thing that comes to mind is from an old Nvidia paper about order independent transparency using depth peeling.
The idea is that you use multiple render passes, but constantly discard fragments if their depth is at least as close to the camera as their value in the previous depth buffer.
They would use compositing to combine these passes into a single image with correct transparency, without needing to order anything.
This could work for the map too I imagine.
Alternatively, for human made structures you could create a different render pass altogether that renders paths/roads/hallways into a buffer, which you could composit onto the map.
I might tackle this if I end up doing structure generation ;)
@@Code_JarThank you, some useful avenues for me to research there. The layered depth method certainly sounds fun, although the separate render pass would probably be nicest. Especially, as you say, with man-made structures allowing to highlight them to the player more easily
your project is looking great!
Thanks :))
Great video I wish I could understand any of that tho
Computer graphics is quite hard, but one of the most fun fields in science imo!
Using rasterization, wouldn't mean that you could not utilize frustum culling? Because meshes that are behind in the first person camera, could be visible from the map camera
I assume that Godot handles frustum culling per camera. Frustum culling does not delete objects or modify the scene, rather it is about not sending useless rendercalls to the GPU (i.e. meshes outside the view frustum which wouldn't be drawn to the screen buffer). Additionally, the secondary camera can use a subset of the render layers. For instance, we do not have to render the water, details and the player mesh.
🔥
man watching this makes me sad I nerver figured out why procedural terrain I made in godot was always so laggy
I tried other people's projects and sent mine to others but the issue was only on my end and I never figured it out
with godot 4 maybe I should give it another go but I dont have that much time anymore and I'd feel like investing that much time to godot instead of vulkan for example is kind of a waste
It's challenging but extremely rewarding :) I do not think I would be a waste of time, especially if you want to focus on procedural terrain generation.
Personally, I want to start a simple volume rendering project in Vulcan in 2025, as I only have experience with OpenGL, and I would like to broaden my horizons.
However, terrain generation is challenging enough so it is nice to implement that in a game engine that takes care of all the rendering :)
Good luck with your future endeavours :)
@@Code_Jar thank you, you too
I will have any significant spare time only after may of 2025 so that's fun
and yeah problem solving/optimizing is rewarding, but not debugging some issue noone has had online and that only appears on your end(I think I tried it on my cheap laptop and it worked better)
First! 🥴