FFTOceanSurface Efficiency

[GoogleCodeExporter]

The generation of vertices and mipmaps in FFTOceanSurface needs an overhaul
as the current implementation is a little ineffecient.

At the moment a vertex array is created to store all of the vertices
required for rendering the surface. The size of this array varies depending
on the current mipmap configuration. 

Example:
Number of tiles: 10x10 (100)
Highest tile resolution: 64x64 (4096)
Mipmap levels: 6

Vertices used: ~11500.

These vertices must be updated everytime the mipmaps or ocean animation
frame changes. The time taken for the configuration above is fairly trivial
but if we want to use higher resolution FFTs or a larger tile grid this
will soon become an issue.

Alternative 1.
Use a vertex array which contains only one set of tile data (e.g. 64x64 =
4096 vertices) attach this to each tile geometry and then translate the
tiles into position using a vertex shader. Alternatively use
matrixtransforms, but the vertex shader would be more effecient with
regards to the cull traversal.

Advantages:
1. Better performance for higher resolution FFT tiles
2. Geomipmap index arrays could be precomputed as the vertex indices do not
change - further reducing the update time.
3. More consistant vertex array update time.

Disadvantages:
1. Future surface interactions 'may' be a little more complicated to compute.

Alternative 2.

Explore the use of the new draw instanced functionality in OpenGL. Need to
find out more about the implications of this. One possible disadvantage is
the current level of support for the draw instanced functionality in
graphics cards.

Original issue reported on code.google.com by kcb...@googlemail.com on 12 Jun 2009 at 5:42

[GoogleCodeExporter]

I think that as part of this change, some refactoring of 
OceanSurface/FFTOceanSurface
should be done. The generator function and the meshing should be separated.

That way, if I want to create the mesh using screen-space meshes, but still use 
the
FFT generator to generate the height field, I can. Likewise, if I want to use
geomipmapping as now, but generate the height field using Perlin noise or sums 
of
sines or whatever, I can. I could even create a trivial generator that would 
just
make a flat surface, and then use the existing meshing with it, and it would be 
easy.

Decoupling these two things seems natural and would ease extension.

Original comment by jean.sebastien.guay13@gmail.com on 12 Jun 2009 at 7:19

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Also: http://graphics.cs.lth.se/theses/projects/projgrid/

And that's what I mean, if we separated the meshing and the generator, we'd be 
able
to implement many meshing schemes and many generators and use them with each 
other
interchangeably.

Original comment by jean.sebastien.guay13@gmail.com on 16 Jun 2009 at 7:56

[GoogleCodeExporter]

I've seen that paper before it's a nice demo, very similar to Hydrax, infact I 
think 
it's the method they use. However, you can't use the projected grid approach 
with the 
FFT simulation. 

I do agree with the decoupling though.

Original comment by kcb...@googlemail.com on 17 Jun 2009 at 8:39

[GoogleCodeExporter]

Robert mentioned that it might be good to support shallow water rendering a 
while 
back (rivers etc). The current FFT approach, with the style of shader that is 
used is 
only really respresentive of water in the open sea. 

An alternative shader implementation which takes into account the depth of the 
terrain underneath might be a nice addition for the future. The shader wouldn't 
be 
such a problem, the colouring is roughly the same equation as I've used for the 
underwater light scattering. But it would also allow for a transparent water 
surface, 
which is important where water meets terrain edges. 

I also think Gerstner waves might be more suitable for rivers and shallow 
waters. 

http://citeseer.ist.psu.edu/cache/papers/cs/26265/http:zSzzSzwww.cs.sunysb.eduzS
z~ash
zSzwaterCGF.pdf/

Original comment by kcb...@googlemail.com on 17 Jun 2009 at 8:49