In fact, particle shaders are compute shaders in 4.0. I've used them to create the terrain and quite successfully. In addition, in this case, you can significantly reduce the number of meshes to one, if you need distances up to 4k meters, then up to 2x. Using the NaN effect, you can discard vertices outside the camera. Аnd solving the problem of chunk edges simply by shifting vertices at the edge of the chunk. This gives a very nice smooth transition, like terrain in UE4 and 5.
Thank you William I also thought using particle Shader, But I was not sure about that Do you have any code example or documentation to share so I can see how the thing that you have created work I know one of the most disadvantage of doing thing in my way is the number of the object, and increase in draw calls But I have some plan to fix this also One can be merging some of the chunks far from player to a bigger chunks and other one is by removing some of chunks after a certain distance But First I should make sure this will work without any problem and at last I will add these features But anyway I am interested the way you handled the terrain, and if you have any more information I will be happy to know about them
If I understand correctly you have a thread that does chunk LOD calculation. But when you trigger the recalculation? If a player doesn't move do you still go through recalculation? I haven't done that sophisticated LOD system, but I'd use a grid coordinate system. In most cases, 2D would be enough but it is extendable to 3D. I trigger recalculation when a player changes a grid cell and that eliminates running calculations without the need to recalculate. Another idea could be to recalculate when a player moves at least a certain distance from a previous recalculation position. That would be dependent on the way the grid positioning works.
I don't think that matter to much The way I do it now is as soon as other CPU thread finish it's job I call that to recalculate again But of course you can do it when the player moved from its original direction a little bit and that is just one line of code I also set the calculation priority of terrain calculation to be low so it will not affect the fps And Also I don't think that is a much problem now days because most of the pc have multiple core and this kind of calculation is not too much for them
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
Love that you shared other examples, the proposal, and other creators approaches to terrain and tessellation!
In fact, particle shaders are compute shaders in 4.0. I've used them to create the terrain and quite successfully. In addition, in this case, you can significantly reduce the number of meshes to one, if you need distances up to 4k meters, then up to 2x.
Using the NaN effect, you can discard vertices outside the camera. Аnd solving the problem of chunk edges simply by shifting vertices at the edge of the chunk. This gives a very nice smooth transition, like terrain in UE4 and 5.
Thank you William
I also thought using particle Shader, But I was not sure about that
Do you have any code example or documentation to share so I can see how the thing that you have created work
I know one of the most disadvantage of doing thing in my way is the number of the object, and increase in draw calls
But I have some plan to fix this also
One can be merging some of the chunks far from player to a bigger chunks
and other one is by removing some of chunks after a certain distance
But First I should make sure this will work without any problem and at last I will add these features
But anyway I am interested the way you handled the terrain, and if you have any more information I will be happy to know about them
fantastic video, keep em comin
Thanks
Wow, love that you got the update time in microseconds! This technique could also be very cool for an ocean system.
Yeah good Idea You can use this also for Ocean
The plugin have a godot 4 branch.
If I understand correctly you have a thread that does chunk LOD calculation. But when you trigger the recalculation? If a player doesn't move do you still go through recalculation?
I haven't done that sophisticated LOD system, but I'd use a grid coordinate system. In most cases, 2D would be enough but it is extendable to 3D. I trigger recalculation when a player changes a grid cell and that eliminates running calculations without the need to recalculate.
Another idea could be to recalculate when a player moves at least a certain distance from a previous recalculation position. That would be dependent on the way the grid positioning works.
I don't think that matter to much
The way I do it now is as soon as other CPU thread finish it's job I call that to recalculate again
But of course you can do it when the player moved from its original direction a little bit and that is just one line of code
I also set the calculation priority of terrain calculation to be low so it will not affect the fps
And Also I don't think that is a much problem now days because most of the pc have multiple core and this kind of calculation is not too much for them
Nice vid!
Thanks
Godot also desperately needs resource streaming. At least for textures and 3D models would be great!
Asset streaming is being looked at , but the priority now is stability and perfomance.