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 ;)
@@thecodejarThank 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
you could make a more obvious set of lines by getting the difference of the normal and quantized data, however it needs to be corrected based on the slope to be of equal width
Interesting, could you expand on this? The discretized height values have an undefined gradient at the isolines, so instead I suppose you essentially want an isoline width with proportion to e.g. one minus the dot product between the up vector and the global normal of the fragment? I feel this is not trivial to implement as we are computing each pixel individually. Perhaps a height gradient magnitude buffer can be used to widen the lines in a second pass? Of course, I could be misunderstanding your point :) I also have to admit, youtube compression is tough on this effect. It does the job well enough when rendered at native resolution without compression.
@ (x - (floor(x*steps)/steps))*steps gives you a bunch of 0-1 ramps. if it’s a constant slope, simply thresholding at 0.1 or 0.9 would give you nice lines, but if the slope is varying, the threshold needs to be offset by the a scalar produced from the gradient (i am on my phone and so i can’t test in 2d in blender, however i have done this correction in blender before)
Ah interesting! I have only done that with a static threshold, in which case you get isolines with a width proportional to the "flatness" of the terrain. This technique also suffers from an issue where large areas under the threshold may all be treated as an isoline, which is also not ideal. A second render step like I mention in the video fixes this, and with some tweaking it could take into account underlying terrain steepness better. Thank you for your suggestion!
@ so checking what i did in blender, it looks like the threshold is 0.1 times the length of the bump mapped height where the z is first set to 0, so straight up is 0 length, all the way over is 1 length. and in that shader i did multiple in parallel offsetting the height before abs and thresholding but i think that could be adapted to a scaled modulo sort of thing
I really, really am very slightly annoyed. I wouldn't be such a hater if this wasn't so good, though. I had this exact idea last year, and it's what I'm working at now. I have a gaggle of ideas for my engine, but I cannot share them with someone of your ranking because I don't want to give you any more ideas. P.S you deserve my subscription, so here, take it. 👏
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.
Not sure if you absolutely need an edge detection to render iso lines, maybe you could just multiply the normalized range by your desired line density, take the frac, and then clip the values according to line weight
From my experience you get very inconsistent edge widths if you compute them based on the underlying data directly. You can observe this too in illustrative rendering, when computing edges based on the dot product of the view direction and the surface normal. A post processing step does not have this problem, so therefore I chose to use it. Of course, it may be possible, but to achieve it it would be best to dive into the math behind it.
@@thecodejar Yeah I guess its a stylistic choice. Theres also different edge detections that could be used, like the difference of gaussians and so on, I for example could barely make out the lines in the video at all. And was wondering if that legibility could be improved somehow (higher weight, and less patchy lines)
@@miroaja1951 I noticed that the yt compression (and downsampling from 1440p to 1080p) diminishes the effect greatly haha. In game I think the effect currently is subtle enough, while greatly improving the ability to distinguish color bands, much like in the Zelda BoTW minimap. Other than that, totally a stylistic choice, and other algorithms might look (subjectively) nicer :)
I'm glad you like the project! As an avid (hobbyist) musician myself, I think I will try to tackle music myself first, but I will keep it in mind for sure!
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 :)
@@thecodejar 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)
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 :)
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 :)
Your videos are so awesome and clear!
Glad you like them!
that's just insane
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 ;)
@@thecodejarThank 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 :))
you could make a more obvious set of lines by getting the difference of the normal and quantized data, however it needs to be corrected based on the slope to be of equal width
Interesting, could you expand on this? The discretized height values have an undefined gradient at the isolines, so instead I suppose you essentially want an isoline width with proportion to e.g. one minus the dot product between the up vector and the global normal of the fragment? I feel this is not trivial to implement as we are computing each pixel individually. Perhaps a height gradient magnitude buffer can be used to widen the lines in a second pass?
Of course, I could be misunderstanding your point :) I also have to admit, youtube compression is tough on this effect. It does the job well enough when rendered at native resolution without compression.
@ (x - (floor(x*steps)/steps))*steps gives you a bunch of 0-1 ramps. if it’s a constant slope, simply thresholding at 0.1 or 0.9 would give you nice lines, but if the slope is varying, the threshold needs to be offset by the a scalar produced from the gradient (i am on my phone and so i can’t test in 2d in blender, however i have done this correction in blender before)
Ah interesting! I have only done that with a static threshold, in which case you get isolines with a width proportional to the "flatness" of the terrain. This technique also suffers from an issue where large areas under the threshold may all be treated as an isoline, which is also not ideal. A second render step like I mention in the video fixes this, and with some tweaking it could take into account underlying terrain steepness better. Thank you for your suggestion!
@ so checking what i did in blender, it looks like the threshold is 0.1 times the length of the bump mapped height where the z is first set to 0, so straight up is 0 length, all the way over is 1 length. and in that shader i did multiple in parallel offsetting the height before abs and thresholding but i think that could be adapted to a scaled modulo sort of thing
I really, really am very slightly annoyed. I wouldn't be such a hater if this wasn't so good, though. I had this exact idea last year, and it's what I'm working at now. I have a gaggle of ideas for my engine, but I cannot share them with someone of your ranking because I don't want to give you any more ideas. P.S you deserve my subscription, so here, take it. 👏
Haha thank you ;) Good luck with whatever you are working on!
@Code_Jar Thanks. I hope to see more of your content, and who knows? Maybe this game you're making will blow up one day.
@Code_Jar I mean, not bad blow up, but you get what I mean.
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.
🔥
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!
Not sure if you absolutely need an edge detection to render iso lines, maybe you could just multiply the normalized range by your desired line density, take the frac, and then clip the values according to line weight
From my experience you get very inconsistent edge widths if you compute them based on the underlying data directly. You can observe this too in illustrative rendering, when computing edges based on the dot product of the view direction and the surface normal. A post processing step does not have this problem, so therefore I chose to use it.
Of course, it may be possible, but to achieve it it would be best to dive into the math behind it.
@@thecodejar Yeah I guess its a stylistic choice. Theres also different edge detections that could be used, like the difference of gaussians and so on, I for example could barely make out the lines in the video at all. And was wondering if that legibility could be improved somehow (higher weight, and less patchy lines)
@@miroaja1951 I noticed that the yt compression (and downsampling from 1440p to 1080p) diminishes the effect greatly haha. In game I think the effect currently is subtle enough, while greatly improving the ability to distinguish color bands, much like in the Zelda BoTW minimap.
Other than that, totally a stylistic choice, and other algorithms might look (subjectively) nicer :)
Heel cool 😎
When it comes time to make music for your game, consider hitting me up. Would love to work on this! Clearly you are a skilled developer. Cheers,
I'm glad you like the project! As an avid (hobbyist) musician myself, I think I will try to tackle music myself first, but I will keep it in mind for sure!
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 :)
@@thecodejar 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! 🥴