Clone the sources: git clone --recurse-submodules github.com/emeiri/ogldev.git If you want to get the same version that was used in the video you can checkout the tag 'TERRAIN6'. Build on Linux: cd ogldev/Terrain6 && ./build.sh Build on Windows: Open the Visual Studio solution: ogldev\Windows\ogldev_vs_2022\ogldev_vs_2022.sln Build the project 'TerrainRendering\Terrain6'
Hi! I did implement similar terrain triangulation few youers ago, now I get back to my "engine" project and I just found this tutorial. Im so glad there is someone else sharing the same approach and making tutorial of it so I can compare your implementation with mine. Thank to you I can analyze both implementations and find a spots for improvement of my algorithms. Thanks a lot for this tutorial!
@@OGLDEV in addition i must say that the part when you explain normals, really saved my a lot of time and performance issues. The idea of summing triangle normals and calculating average to get vertex normals, brilliant :) So simple and effective. Will for sure watch all your videos, wish you all the best!
Yes, though it will be a very simple algorithm so not sure if you will find it sufficient but this is what I have right now. I plan to research this topic in the future and come up with better algorithms.
This is quite old slow technique. Newer variations use static mesh and use compute shader to prepare index buffer (or my favorite solution: they compute interpolation position for vertex without neighb. for eliminating of edge cracks) for one drawcall terrain. Will you make tutorial on this?
Yes, eventually. Would also like to explore tessellation for terrains. Unfortunately there aren't new books on terrains so if you want to create a more modern course you have to research the papers.
@@OGLDEV Tesselation seems like a dead end. Yes, no new book as far i know. In the old days there were few books which computer graphics used a lot like red book or gpu gems. Nowadays we are stuck on GDC slides or published papers (which very often skip details - crucial parts of implementation).
@@OGLDEV Not a professional (although I actually wrote my bachelor thesis on tessellation for terrains) but I think the issue is that tessellation is very static compared to the other tools we have available. Vulkan and DX12 offer mesh shaders (I'm not sure if there is a ogl extension) which kind of throw the whole vs -> tcs -> tes -> gs -> fs pipeline out the window and for most cases modern GPUs are probably quick enough that you could just use the compute shader. Considering that the compute shader is probably already used, it's probably just a little extra step in the already existing shader to tessellate terrain. Additionally, and this is kinda what I never got to explore after writing the thesis about rendering, I honestly don't know how you do collision with tessellation. With the compute shader, you get output. With the tessellation shader, you get nothing. So, tessellation for more detail really close up? Awesome. Just throw a bounding box around it and you're golden. No need to care about the actual generated geometry. Tessellation for actual walkable terrain? Well now you need to know the high value of the generated vertex. That's an issue.
Thank you so much for these series!! I changed MidpointDisplacement Terrain to use GeomipGrid instead of TriangleList but now I am getting incorrect edges on the sides of the map, any idea what could be causing this?
@@OGLDEV Patch size is 33, tried 513 (same as terrain), and I should mention I don't always get this when launching application. So maybe this started happening before, could be problem with Midpoint Displacement algorithm maybe?..
@@OGLDEV Thanks for the tip, started using GeomipGrid class for Fault formation, but it looks nice with this algorithm, so seems like only midpoint displacement is affected, weird
@@nerijusvilcinskas7851 Another option is to define the smallest patch with 3 vertices but make sure the world scale is large lile a 100 otherwise you may miss it. Then slowly increase the patch size. Terrain should be 3 as well.
Clone the sources:
git clone --recurse-submodules github.com/emeiri/ogldev.git
If you want to get the same version that was used in the video you can checkout the tag 'TERRAIN6'.
Build on Linux:
cd ogldev/Terrain6 && ./build.sh
Build on Windows:
Open the Visual Studio solution: ogldev\Windows\ogldev_vs_2022\ogldev_vs_2022.sln
Build the project 'TerrainRendering\Terrain6'
Hi! I did implement similar terrain triangulation few youers ago, now I get back to my "engine" project and I just found this tutorial. Im so glad there is someone else sharing the same approach and making tutorial of it so I can compare your implementation with mine. Thank to you I can analyze both implementations and find a spots for improvement of my algorithms. Thanks a lot for this tutorial!
You're welcome! Good luck with your engine :-)
@@OGLDEV in addition i must say that the part when you explain normals, really saved my a lot of time and performance issues. The idea of summing triangle normals and calculating average to get vertex normals, brilliant :) So simple and effective. Will for sure watch all your videos, wish you all the best!
It's not my idea but I don't mind taking credit for it ;-)
Hope you enjoy them, thanks!
awesome, stellar instruction, very clear
Thanks!
will these series cover collisions that allow a player to move on the terrain?
Yes, though it will be a very simple algorithm so not sure if you will find it sufficient but this is what I have right now. I plan to research this topic in the future and come up with better algorithms.
This is quite old slow technique. Newer variations use static mesh and use compute shader to prepare index buffer (or my favorite solution: they compute interpolation position for vertex without neighb. for eliminating of edge cracks) for one drawcall terrain. Will you make tutorial on this?
Yes, eventually. Would also like to explore tessellation for terrains. Unfortunately there aren't new books on terrains so if you want to create a more modern course you have to research the papers.
@@OGLDEV Tesselation seems like a dead end. Yes, no new book as far i know. In the old days there were few books which computer graphics used a lot like red book or gpu gems. Nowadays we are stuck on GDC slides or published papers (which very often skip details - crucial parts of implementation).
Why do you think tesselation is a dead end?
@@OGLDEV Not a professional (although I actually wrote my bachelor thesis on tessellation for terrains) but I think the issue is that tessellation is very static compared to the other tools we have available. Vulkan and DX12 offer mesh shaders (I'm not sure if there is a ogl extension) which kind of throw the whole vs -> tcs -> tes -> gs -> fs pipeline out the window and for most cases modern GPUs are probably quick enough that you could just use the compute shader. Considering that the compute shader is probably already used, it's probably just a little extra step in the already existing shader to tessellate terrain.
Additionally, and this is kinda what I never got to explore after writing the thesis about rendering, I honestly don't know how you do collision with tessellation. With the compute shader, you get output. With the tessellation shader, you get nothing. So, tessellation for more detail really close up? Awesome. Just throw a bounding box around it and you're golden. No need to care about the actual generated geometry. Tessellation for actual walkable terrain? Well now you need to know the high value of the generated vertex. That's an issue.
Thank you so much for these series!! I changed MidpointDisplacement Terrain to use GeomipGrid instead of TriangleList but now I am getting incorrect edges on the sides of the map, any idea what could be causing this?
You're welcome!
Is this happening with my code?
Try to set the patch size to the size of the terrain.
@@OGLDEV Patch size is 33, tried 513 (same as terrain), and I should mention I don't always get this when launching application. So maybe this started happening before, could be problem with Midpoint Displacement algorithm maybe?..
@@nerijusvilcinskas7851 Not sure. You can try fault formation.
@@OGLDEV Thanks for the tip, started using GeomipGrid class for Fault formation, but it looks nice with this algorithm, so seems like only midpoint displacement is affected, weird
@@nerijusvilcinskas7851 Another option is to define the smallest patch with 3 vertices but make sure the world scale is large lile a 100 otherwise you may miss it. Then slowly increase the patch size. Terrain should be 3 as well.
It would be cool if you can scale this series into water rendering as well. Again, thanks for tutorial! 🙂
Yes, it's on the roadmap. We can't live without water ;-)
@@OGLDEV We are part of water ;D
Water gives a lot more details to terrain :)
gg
?
@@OGLDEV sorry ahah, I meant very good video and thank you for this amazing serie, thanks to you I truly love Graphics 3D and even more OpenGl !
@@valentinmenucerri6230 You're welcome :-)