The quality of this video is astonishing, so much work into it! Thanks a lot for all the valuable information, can't wait for the next video, I will still try to experiment with mountains and noise before seeing your implementation. Keep up the good work, truly amazing!
Hey, this is a year old video, but I just wanted to say that this video really helped my project! I'm implementing the marching cubes algorithm with the transvoxel algorithm for transitions, and I was really stuck on calculating if a chunk was bordering another chunk using my octree implementation. I genuinely would not have been able to get it done without this video!
This is great! I not only learn how to do something but why it works. Thank you for sharing this information with the world! I can't wait for this series to continue. (Subbed)
Same! I've been stuck on one small part of the code for about a week now, but after I fix that everything will be working :). It's quite slow though, so I'll have to optimize it a lot in part 5, probably using shaders of some sort.
Hm this is interesting. I did a similar project some time ago, and I did something completely different to fix this problem. I don't remember exactly what I did, but it involved finding a mathematical formula for the level of detail at any given position. With this, I could evaluate a function and compare the detail levels, like if the level of detail was larger than that of the quad I was checking on, I know I'd have to do something different with the geometry. I think your solution might be more efficient though, given the simplicity of the arithmetic. Well done!
@@simonholmqvist1951 Also, I wanted to ask if you got any issues with cracks in between the borders of the terrain faces? This ended up being an issue in my implementation, and I was never quite sure how to solve it.
@@TebiByyte Unfortunately, I do have those. I will try to fix them in a future video, but they aren't really noticeable unless you have a pretty low resolution on your planet.
@@simonholmqvist1951 The cracks inbetween terrain faces happen because neighbouring quads on different terrain faces have different normals - because they are different meshes. The recalculate normals method of unities mesh class of course doesn't know about other meshes. One idea I had to to fix these is to merge all the meshes together into one and remove duplicate vertices. Since I implemented the planets in Java OpenGL and not unity I didn't try this solution yet, though, because my mesh class doesn't have a "remove duplicate vertices" method. Anyone have any idea how to implement one efficiently?
what about edge fans being triggered for chunks at the boundary of a terrain face and another terrain face. is there a way to check neighbors that arent even in the same quadtree?
Another approach is "edge skirts". I intend to try that for my project. Basically, you add an extra row of triangles that go down into the planet. It does not make it a proper manifold mesh but it should hide the misalignment well enough.
You could implement some LOD-checks, similar to what I've done for the edge fans, before you subdivide a quad. The easier solution, though, would be to select LOD-distances such that the neighbours always are within one detail level.
@@simonholmqvist1951 thanx for response ... but I dont get scripts working, i applied planet.cs to sphere and tag camera to player, but i dont get any effect ...
@@hiru92 Oops, I forgot to upload one of the scripts! You should now see an additional file called "GameManagement" that will take care of some floating-point issues. Put it on an empty game object along with the Presets script. Also, you don't have to put the planet.cs script on a sphere. Just put it on an empty game object.
It isn't any simpler way? It's hard for me to explain but look at 0:12,well you can see that there is a middle point that is is in the higher lod mesh. Well,you can't move that middle point down?(to the center,i belive it need's to be the avarage of his two neighborns),and like that it will be on the line of the lower resolution mesh I am not sure how easy it is to do that but i think it is more optimised
The actual application of the edge fans is pretty light performance-wise. The part that costs by far the most performance is figuring out where to apply the edge fans, so I don't think changing the geometry of the edge fans will result in any significant performance gains. Perhaps even the opposite, since just moving the vertex down instead of removing it results in additional invisible polygons which, apart from slowing down rendering, will cause a lot of pain when I elevate and texture the surface. It's an interesting idea though! I have a habit of overcomplicating things when I'm programming, so it's good that people like you challenge my ideas. There is incredible beauty in simplicity :)
The quality of this video is astonishing, so much work into it!
Thanks a lot for all the valuable information, can't wait for the next video, I will still try to experiment with mountains and noise before seeing your implementation.
Keep up the good work, truly amazing!
Hey, this is a year old video, but I just wanted to say that this video really helped my project! I'm implementing the marching cubes algorithm with the transvoxel algorithm for transitions, and I was really stuck on calculating if a chunk was bordering another chunk using my octree implementation. I genuinely would not have been able to get it done without this video!
Glad you enjoyed it :)
Very well done, thoroughly enjoying this series.
This is great! I not only learn how to do something but why it works. Thank you for sharing this information with the world! I can't wait for this series to continue. (Subbed)
Just found this channel and subscribed ofc - great content thx - always wanted to implement huge planet ( earth - like ) landing
Can't wait for part 4!
Same! I've been stuck on one small part of the code for about a week now, but after I fix that everything will be working :). It's quite slow though, so I'll have to optimize it a lot in part 5, probably using shaders of some sort.
Great video man! I like that you show and explain the codes :D
Thank you, I'm glad you liked it :)
Ok, now how do I use this with triangles in icosahedron subdivision?
I'm sure I can come up with something.
Hm this is interesting. I did a similar project some time ago, and I did something completely different to fix this problem. I don't remember exactly what I did, but it involved finding a mathematical formula for the level of detail at any given position. With this, I could evaluate a function and compare the detail levels, like if the level of detail was larger than that of the quad I was checking on, I know I'd have to do something different with the geometry. I think your solution might be more efficient though, given the simplicity of the arithmetic. Well done!
Thank you! I love your smoke simulation :)
@@simonholmqvist1951 Also, I wanted to ask if you got any issues with cracks in between the borders of the terrain faces? This ended up being an issue in my implementation, and I was never quite sure how to solve it.
@@TebiByyte Unfortunately, I do have those. I will try to fix them in a future video, but they aren't really noticeable unless you have a pretty low resolution on your planet.
@@simonholmqvist1951 The cracks inbetween terrain faces happen because neighbouring quads on different terrain faces have different normals - because they are different meshes. The recalculate normals method of unities mesh class of course doesn't know about other meshes. One idea I had to to fix these is to merge all the meshes together into one and remove duplicate vertices. Since I implemented the planets in Java OpenGL and not unity I didn't try this solution yet, though, because my mesh class doesn't have a "remove duplicate vertices" method. Anyone have any idea how to implement one efficiently?
@@Kahitar1 Check out the next video in this series (#4). I managed to solve the normal issue :)
Thank you so much, I was looking for a way to optimize planets.
what about edge fans being triggered for chunks at the boundary of a terrain face and another terrain face. is there a way to check neighbors that arent even in the same quadtree?
Good question! That is one of the limitations of my planet. It will be a top priority if I get back to this project :)
Another approach is "edge skirts". I intend to try that for my project. Basically, you add an extra row of triangles that go down into the planet. It does not make it a proper manifold mesh but it should hide the misalignment well enough.
how do you go about creating a 'restricted quadtree' so that the neighbors have always within 1 detail level
You could implement some LOD-checks, similar to what I've done for the edge fans, before you subdivide a quad. The easier solution, though, would be to select LOD-distances such that the neighbours always are within one detail level.
I saw Tessellation thing in hdrp rendering, is that also work like LOD system ...
I explored that alternative, but I couldn't get it to work with the terrain. It's definitely doable though, so feel free to try yourself :)
@@simonholmqvist1951 thanx for response ... but I dont get scripts working, i applied planet.cs to sphere and tag camera to player, but i dont get any effect ...
@@hiru92 Oops, I forgot to upload one of the scripts! You should now see an additional file called "GameManagement" that will take care of some floating-point issues. Put it on an empty game object along with the Presets script. Also, you don't have to put the planet.cs script on a sphere. Just put it on an empty game object.
It isn't any simpler way?
It's hard for me to explain but look at 0:12,well you can see that there is a middle point that is is in the higher lod mesh.
Well,you can't move that middle point down?(to the center,i belive it need's to be the avarage of his two neighborns),and like that it will be on the line of the lower resolution mesh
I am not sure how easy it is to do that but i think it is more optimised
The actual application of the edge fans is pretty light performance-wise. The part that costs by far the most performance is figuring out where to apply the edge fans, so I don't think changing the geometry of the edge fans will result in any significant performance gains. Perhaps even the opposite, since just moving the vertex down instead of removing it results in additional invisible polygons which, apart from slowing down rendering, will cause a lot of pain when I elevate and texture the surface. It's an interesting idea though! I have a habit of overcomplicating things when I'm programming, so it's good that people like you challenge my ideas. There is incredible beauty in simplicity :)
Great Job!
The numbers Mason!! What do they mean!?😂
Swedish?
Jajamensan!
that bitmask thing is above my iq