Seamless displacement

 An essential property of the proposed algorithm by Tessendorf, Simulating Ocean Water, is that the result of the FFT actually tiles seamlessly. This means that an individual tile will end in x-direction as it starts in x-direction, with regard to the color gradient going left to right and vice versa.



Left: One individual displacement texture rendered using Tessendorf's algorithm. Middle: 10x10 tiles tiled side by side. Right: Seamsless edges between tiles observed through a skewed angle

This implies that to render a very large ocean, it is only necessary to render one single tile mesh of ocean, and then those can be seamlessly tiled together. One problem with this approach is that if the ocean is observed from far above the surface, so that many tiles are visible simultaneously, then one can spot the recurring patterns in the meshes.


Left: Mesh rendered by displacing pixels in y-direction according to the displacement map.
Right: Mesh with blinn-phong illumination after naively calculating normals.

Even though tiling the meshes should be straight forward, some bugs occurred among the way. First of all, one has to lazily connect the vertices of the two tiled meshes, meaning one is forced to add N + N + 1 extra vertices around the mesh and set the height of those vertices to the height of the corresponding vertices on the other edge. Particularly, we have that vertex (N, N) should map to the same height as vertex (0, 0).

In code, it was easily fixed by indexing the displacement map with a different index than the list of vertices.

uint32_t N = Np1 - 1;
for (int z = 0; z < Np1; z++) {
for (int x = 0; x < Np1; x++) {
int i_v = z * Np1 + x;
int i_d = (z % N) * N + x % N;
vertices[i_v].position.y = displacement[i_d].real();
}
}


Left: Tiled ocean with visible seams due to non connected vertices. Middle: Tiled ocean with invisible seams, though vertices are improperly connected by the index buffer. Right: Properly
connected vertices and tiling works without seams.

The water however still does not look very realistic, and this is due to the naive normal
calculation done. The basic idea was to just get some basic lighting going, and to do so I calculate the normal for every vertex by calculating the surface normal for all triangles
neighboring the vertices. The vertex normals are then summed together and normalized.

This approach is creates a worse looking ocean according to Tessendorf. Instead, it is
suggested to calculate the x and z derivatives through two extra FFT-passes described in equation 37.
This will be implemented next up, together with choppy waves, which requires displacing
the points in x and z-direction. Choppy waves and slope calculations require yet another
four FFT-passes to calculate, but yields much more naturally behaving waves.


Kommentarer

Skicka en kommentar

Populära inlägg i den här bloggen

Dear ImGui - Interactive settings for ocean water

Bild
The last crucial piece of the project implementation relates to GUI. It is tedious having to restart the application for testing different settings, and I wanted to be able to change the settings of the ocean in real time. Using a GUI I wanted the following settings to be modifiable in real time. For ocean: Wave length Amplitude Wind speed Wind direction Normal displacement amount  Vertex count Tile count For application: Camera movement speed Camera rotation speed Enable/disable wireframe mode Enable/disable skybox Enable/disable skybox lighting Selecting skybox cubemap A very convenient and handy tool for debugging graphics applications is Dear ImGui , or simply ImGui. Integrating ImGui is simple and it has an implementation agnostic interface for whichever window environment and graphics library you are using. When the ImGui library is linked properly to the application, dialogs and GUI utils are easily drawn to the screen by initializing an ImGui context. When a context is runn...
Läs mer

CUDA cuFFT vs FFTW

Bild
My initial thoughts were that I was going to perform FFT on the GPU as it intuitively sounds fast to use the multi-core system that the GPU provides. However, depending on the size of the FFT, GPU based algorithms may actually be outperformed by running FFT on the CPU. Transferring memory-buffers to the GPU is a slow operation, and the overhead of transferring data to the GPU does affect the overall performance of running FFT particularly. When using CUDA cuFFT compared to serial FFTW, it has been shown that for small N, approximately N <= 4096, the gain from running cuFFT is lost due to slow memory transfer rates. From lecture: "Fast Fourier Transforms (FFTs) and Graphical Processing Units (GPUs)" - Kate Despain, University of Maryland Institute for Advanced Computer Studies. Originally from University of Waterloo (2007). Comparing FFT and cuFFT including and excluding memory transfer rates. Y axis labeling flops, X axis labeling size of FFT work set.  In my project, ...
Läs mer

Gradients and Choppy waves.

Bild
As mentioned in the last post, the focus of the last days was to fix proper normal calculations using the gradient of the height-field. Gradient, together with creating a displacement in x and z-direction, only required setting up a four more cuda-buffers and performing an inverse FFT-pass on each of them. Calculating the gradient and the x-z displacement is easy, and comes from equation 20 and 29 in Tessendorf's paper, which you should be familiar with now. The input for calculating the x-gradient and z-gradient simply meant multiplying the input for the displacement map with the imaginary number ik, for each k where k is the propagation direction of the wave at each point. Formula for gradient calculation for realistic surface normals (Tessendorf 2001) Left: z-gradient normalized to range 0-1. Right:  z-gradient normalized to range 0-1 One problem that occurred when calculating the surface normals using the gradient values was that the result of the FFT is naturally rather small....
Läs mer