KSP2 devs just announced they will be replacing their old terain generation algorithm with this one as it their main performance bottleneck at release, and it looks really promising!
Very nice indeed. Wondering how one would use this with landscape tiles for implementing a landscape system in a game. Can the landscape be split into uniform sized tiles and if so would the resulting tiles be seamless with regards to tessellation/LODs? The goal is to be able to use different shaders per tile.
It's not clear to me how to parallel propagate subdivision into neighboring triangles. Is there a way how to avoid recursive subdivision on half-edges of main mesh triangles?
Thanks for the awesome video! As far as I understood, you store cbt buffer in GPU memory and looping it in parallel. If the LOD will be big, isn't it really an issue to loop potentially huge amount of nodes and recalculate sum reduction ? And I don't clearly understand from demo, how and where you scale geometry with "PixelsPerEdge" parameter. Does it connected to LOD level and can it be somehow cached ?
Excellent presentation, such an easy to understand explanation of the algorithm! I'm curious in practice in what way the result of the algorithm (in GPU memory) is used to generate geometry.
Thank you :) My paper explains how to generate the geometry from the CBT. You can also have a look at my code here: github.com/jdupuy/LongestEdgeBisection2D/blob/master/terrain/shaders/TerrainRenderCommon.glsl#L33
@@kunkerkar It is currently being considered for integration. For more information see this talk "Experimenting With Concurrent Binary Trees for Large-scale Terrain Rendering" advances.realtimerendering.com/s2021/index.html
It's a complete solution by itself, which is meant to provide an alternative to tessellation shaders. The main benefit of this approach compared to tessellation shaders is that it allows you to cache your scene's geometry. This is useful whenever you have rendering algorithms that require multiple passes over your scene geometry (e.g., shadow mapping, Z prepass, path tracing, visibility buffering, etc.). With tessellation shaders, you would have to recompute the geometry at each pass. Here, you don't have to. Also, you have a very fine control over the adaptivity of the mesh. Hope this is clear :)
KSP2 devs just announced they will be replacing their old terain generation algorithm with this one as it their main performance bottleneck at release, and it looks really promising!
came here just to say that man, looks very promising!!!
This really helped me understand CBT
You are a research scientist at Unity! How exciting!
Beautiful solution, great explanation. Many thanks : )
Very nice indeed. Wondering how one would use this with landscape tiles for implementing a landscape system in a game. Can the landscape be split into uniform sized tiles and if so would the resulting tiles be seamless with regards to tessellation/LODs? The goal is to be able to use different shaders per tile.
It's not clear to me how to parallel propagate subdivision into neighboring triangles. Is there a way how to avoid recursive subdivision on half-edges of main mesh triangles?
Thanks for the awesome video! As far as I understood, you store cbt buffer in GPU memory and looping it in parallel. If the LOD will be big, isn't it really an issue to loop potentially huge amount of nodes and recalculate sum reduction ? And I don't clearly understand from demo, how and where you scale geometry with "PixelsPerEdge" parameter. Does it connected to LOD level and can it be somehow cached ?
Just dropping by again to rewatch. Still great! Lol
Excellent presentation, such an easy to understand explanation of the algorithm!
I'm curious in practice in what way the result of the algorithm (in GPU memory) is used to generate geometry.
Thank you :)
My paper explains how to generate the geometry from the CBT. You can also have a look at my code here: github.com/jdupuy/LongestEdgeBisection2D/blob/master/terrain/shaders/TerrainRenderCommon.glsl#L33
@@jdupuy01 will this be implemented inside the unity game engine? Because this will be really great for creating huge open world games inside unity
@@kunkerkar It is currently being considered for integration. For more information see this talk "Experimenting With Concurrent Binary Trees for Large-scale Terrain Rendering" advances.realtimerendering.com/s2021/index.html
I dont think I fully understand. Is this used in conjunction with tesselation shaders or is it a complete solution by itself?
It's a complete solution by itself, which is meant to provide an alternative to tessellation shaders. The main benefit of this approach compared to tessellation shaders is that it allows you to cache your scene's geometry. This is useful whenever you have rendering algorithms that require multiple passes over your scene geometry (e.g., shadow mapping, Z prepass, path tracing, visibility buffering, etc.). With tessellation shaders, you would have to recompute the geometry at each pass. Here, you don't have to. Also, you have a very fine control over the adaptivity of the mesh.
Hope this is clear :)
@@jdupuy01 That is very clear. Thank you. What a fantastic solution!