Good progress in developing a real ocean

I am very happy about the release of r156. I immediately looked at the example with the compute texture. This will now be the next step to bring the IFFT wave generator from webgl2 to webgpu and replace the renderTargets with compute shaders to generate significantly better waves.

With webgpu, a very realistic water surface will be possible thanks to the computer shaders. The geometry is now very satisfactory, it is very fast and completely stepless.
This allows also to create huge landscapes that are always in high resolution wherever you are. The LODs are always concentric circles around the target (camera) that morph into each other.

I’m going to replace my old landscape generator that I used to create my Mars. Here is a video link to my mars which is running with my old LOD generator. Of course it’s also very good, but it doesn’t have morphing LOD transitions but stitching so that there are also no gaps between the LODs.

But my new ocean LOD geometry generator is more efficient.

Phil Crowter inspired me to this beautiful ocean project.


This looks great! What kind of LOD system are you using? It doesn’t look like a chunk based quadtree LOD. Is it CDLOD?

I have to admit I don’t know what CD in CDLOD means.
It is indeed a chunk based quadtree LOD (on Mars there are several quadtrees and everything in the original scale). Geometry chunks are then created. You can see this in the ocean because new square areas in different colors keep appearing. So there are actually many individual chunks that always fit together perfectly. You don’t see any gaps between them or any transitions anywhere on Mars. The surface appears to be made of a single geometry. But I used stitching on Mars because I hadn’t thought about morphing. The intermediate points of a higher resolution area that borders on a coarser one interpolates its intermediate points so that there are no gaps. With the ocean I made a few things more advanced to avoid the complex stitching in the vertex shader.
On Mars I already do the stitching in the workers that generate the new chunks, but on Ocean I have a moving surface and I would then have to constantly re-stitch. This also works very well but morphing is more advanced
For performance reasons, I use 7 workers so that my main thread remains undisturbed while my 7 remaining CPU cores can fully take care of generating new chunks. So I use all 8 CPU cores and it works so well that everything works on my tablet.

With the ocean in the vertex shader I morph the vertices towards each other or apart depending on the camera distance so that a smooth transition from LOD to LOD is created. You can no longer recognize any LOD changes on the surface.
It is allways a perfect surface with smooth LOD transitions.

Now I will take care of improving the IFFT generator, because in WebGL2 I had to use 5 renderTargets in each interval. Thanks to r156 I can now do the same thing in WebGPU with compute shaders which is more efficient.
This will be a beautiful open source ocean.

For real landscapes like Mars, I don’t need WebGPU, but I do need other very complex components that I’ve worked on for a long time. With better height maps for mars this would be much better. For the earth I have 14520 maps from NASA with 1 arc second resolution (30m)

I was thinking about starting a github project.


You should definitely start a GitHub project. I’m working on a similar project using the chunk LOD approach at GitHub - miguelmyers8/PlanetTechJS: PlanetTechJS is an open-source JavaScript library built using vanilla THREE.js, for creating and editing planets at scale. I have to say yours is one of the best I have seen.


The “CD” stands for Continuous Distance. Found this paper on the subject.

Then i have that because that’s exactly the paper that inspired me to do it.

Now I am improving the IFFT wave generator thanks to r156 with compute texture. Then comes raytracing in conjunction with a depthtexture to take objects close to the surface or the ground into account when scattering.


Thank you, my planetary generator has now become very extensive. When I started a little over two years ago, I faced numerous hurdles. I use 512 high-resolution individual 16-bit height maps. Unfortunately, there is nothing better from Mars than the material from the Mars MOLA mission. However, there are numerous individual, very high-resolution maps of smaller areas (HiRISE mission). I’ll include those too. I only load the higher resolution maps when approaching and only in the areas around the camera. For my tablet, the RAM memory is the bottleneck. I had to be very careful with the maps.

Does Github have something like a limit when it comes to data size? All the maps I currently use need around 10 GB. And in addition I still have 150 GB of very high-resolution maps of the Earth.

You definitely will not be able to push the code with those large images. What I’ve seen other people do is just push the code to GitHub and, in your readme, link to your images that are hosted on something like AWS or a site designed for storing images so a user knows where to download it.

On a side note, doesn’t your application crash when using such a high-resolution image? You must have a pretty good computer, but you have to think about the stress this will put on a user’s machine

I don’t load all the maps. In total that would be 46k for Mars, 96k for the Moon or 178k for Earth.
As long as I’m far away I use lower resolution height maps. When I get closer, I load the higher-resolution maps in the area around the camera. It even runs quite well on my tablet (samsung galaxy tab S8+) and it only have 3.5 GB ram available. The map management was one of the many very big challenges. I would also like to have 178k for Mars, which would be about 16 times higher resolution. If there was a 1M map of Mars I would use it. I developed extra tools in Python because I had previously spent weeks just cutting maps and naming them. Now I can quickly convert and create hundreds of maps in my tools.

However, I can improve the map management a little here and there - there is still potential.
The only time I had crashes was when the RAM on my tablet was full. Otherwise I didn’t have to deal with crashes. The software runs very stable.
When it ran without any problems and the RAM load on my tablet was around 2 GB, I admittedly became a little comfortable and dedicated myself to the Ocean.
An earth without a real ocean just seems uhhh. Clouds are also important. I can create planet-wide clouds on my desktop without any problems. That looks very good. But for my tablet clouds are a very heavy stuff. I use raytracing for the atmosphere and the clouds. I have a simple cloud example on github if you’re interested.

Regarding github:
Then I’ll have to finally continue with my homepage. I could make the thousands of maps available for download on my homepage.

But first I want to make progress on the ocean. Thanks to r156, I’m now in a development frenzy :sweat_smile:

Do you guys use Discord? I am building my own LOD terrain renderer at and would love to connect with people who also are into this sort of thing. Mine is Jycerian#9355.


I once had a discord account. I would have to reactivate it. You also did a CDLOD. I plan to start a project on github where I will then upload the ocean. Since I do everything with WebGPU, I can only now continue effectively with r157. I recently downloaded r157 and integrated it into my project and also integrated the new StorageTexture class. I think it’s great. WebGL2 is simply not well suited for the ocean with its moving surface. I don’t yet know how I do this with my planets, as the project folder is already 10 GB in size due to the many elevation maps. I will have to do this via my own homepage.

1 Like

I don’t like unfinished things per se, but I could upload my ocean project to Github as soon as I’ve simply implemented the IFFT mechanism in WebGPU. It won’t look like an ocean at the beginning, but it will contain the most important elements fully functional, such as my multithreading CDLOD.

1 Like

Thanks @sunag, with r158 there has been great progress in the development of my webgpu ocean. Phil has also once again inspired me to make a significant improvement. Unfortunately I can’t load this onto my site because for efficiency reasons I use several sharedArrayBuffers for which I need crossOriginIsolation. What is easy on a local server is unfortunately not possible on a standard server that you host. Therefore just pictures. The wave behavior is very real, I can stare at the screen for minutes and not get bored. And at the moment it’s just a monochrome, opaque, non-reflective surface without ray tracing, without foam. Just displacement and normal texture. This highly efficient ocean surface is only possible with the three.js webGPURenderer. Dozens of compute shaders are executed at every interval and it runs on my laptop with a simple onboard graphics chip.

Now with a better surface:

If you look closely you will notice gaps in the surface. This is because I had to deactivate lod morphing because otherwise there would be ugly texture errors. The reason is because I access the position attribute in the colorNode. But I need my morphed “vPositions” from the positionNode in the colorNode. But I don’t yet know how to pass that in the node system.
Normally this works in wgsl with structs. Alternatively, I could use stitching instead of lod morphing, but morphing is more elegant because it is stepless.