kbale / osgocean Goto Github PK

It would be nice to be able to load models into oceanExample to test them
and see them in/on the ocean.

This is simple to implement with osgDB::readNodeFiles(...) like osgviewer
does. And with the .trans, .rot and .scale pseudo-loaders, the user can do
what they want with their models to place them and see them in the scene.

Really simple but would be nice to have.

What steps will reproduce the problem?
1. create a particle effect that has a transparency on its particles...

What is the expected output? What do you see instead?

I'm having a problem with my particle generator when i use it in the same
scene as osgOcean (dtOcean). All the transparent alpha pixels seem to glow
instead of being invisible. Also the particles transparency value has no
effect anymore...so instead of slowly vanishing...the particles just pop
out of existence.

attached is a screen shot of what i get....the picture shows a screen with
and with out osgOcean (dtOcean)....notice how the particles look...

i tried disabling the glare shader....but that had abs no effect....

i also noticed that it matters from which side you look at the
particles.....sometimes the transparency gets semi fixed....so i'm thinking
its a lighting thing...but don't know...

What version of the product are you using? On what operating system?

osgOcean 1.0.1
and dtOcean (part of Delta3D)

Win XP VS2008

_enableDefaultShader is not initialised in OceanScene

In ShaderManager.cpp, #include <osgDB/fileutils> should be
#include <osgDB/FileUtils>.  Only Windows will accept the lower
case name, is no one using Linux?

I can not compile the trunk, there is a lot of errors,
and the integration of subMask (for river an d lac by Oliver 9volt) is not in 
the trunk???

in the tag the code is very old(2009), so I preffer to use trunk.

thank you for your help in advance.

What is the expected output? What do you see instead?
My terrains are very large scale... about 65k x 65k and more. I start off
the scenario very far from the origin.... lets say about (35000,35000,50)... 
When osgOcean initializes, the sky dome and the sky shaders dont seem to
work....its like everything that has to do with the sky dome gets turned
off, and all i see is a black sky. When i start to move around.... after
some time...usually after i look up...it suddenly turns on and after that
works just fine...

What version of the product are you using? On what operating system?
osgOcean 1.0.1
winXP 
vs2008

A suggestion:

The projected reflection is completely independent of the actual water
geometry (waves) - the effects are most noticable when looking in wind
direction (see screenshot - although lighting clearly suggests the wave is
there the reflection looks just like on a plane).

Personally I think...

-tempPos.xy = v.xy + disp * N.xy;
+tempPos.xy = v.xy + disp * - v.z * N.xy;

...in distortGen() looks a lot more realistic (it no longer looks like the
reflection is cutting through the wave-tops).

But as this is probably highly subjective I'll leave it up to the
maintainer. :-)

Because FFTOceanSurface::computeNoiseCoords() simply keeps increasing a
static (not nice) float (not nice in combination) large time jumps can lead
to an unrecoverable state with not enough precision available in the
counter to provide smooth animation.

Although these time jumps are probably caused by a bug in my application I
still consider osgOcean's behaviour here a bug - locally I added a _time,
added a advanceTime(dt); call to update() and changed the logic to:

void FFTOceanSurface::advanceTime( const double& dt )
{
    float maxLength = 32.f * osg::Vec2f(2.f, 4.f).length();
    float maxTotalTime = maxLength / 2.0;    
    _time += dt * 0.0008;
    _time = fmod(_time, maxTotalTime);
}

osg::Vec3f FFTOceanSurface::computeNoiseCoords(float noiseSize, const
osg::Vec2f& movement, float speed)
{
    float length = noiseSize*movement.length();
    float tileScale = _tileResInv * noiseSize;
    osg::Vec2f velocity = movement * speed / length;
    osg::Vec2f pos = velocity * _time;
    osg::Vec3f x = osg::Vec3f( pos, tileScale );
    return x;
}

... now, due to the copied (from update()) magic constants in advanceTime()
(one obviously needs the largest used values) I realize this might not be
inclusion-worthy, but I don't know how to properly do this as I have no
idea where the magic constants in update() come from in the first place. :-)

What steps will reproduce the problem?

I am using a cell shader implementation, where the outline is created by 
drawing the backfaces in wireframe mode with activated front face culling:
"osg::ref_ptr<osg::StateSet> linestate = node->getOrCreateStateSet();
linestate->setAttribute(new osg::LineWidth(4.0f));
linestate->setAttribute(new osg::CullFace(osg::CullFace::FRONT));
linestate->setAttribute(new osg::PolygonMode(osg::PolygonMode::BACK, 
osg::PolygonMode::LINE));"

The fragment shader draws a black fragment, if the fragment is backface and the 
regular color, if the fragment is front face:
"...
void main()
{
    if (gl_FrontFacing)
    {
        gl_FragColor = lighting();
    }
    else
    {
        gl_FragColor = vec4(0.0, 0.0, 0.0, 0.80);
    }
}
..."

In the reflection image the front- and backface is switched(as seen in the 
picture).
I changed the frontface mode to clockwise for the reflection camera to fix this 
issue.

osgOcean::OceanScene::init(), OceanScene.cpp, line 363

BEFORE:
"// clip everything below water line
            _reflectionCamera=renderToTexturePass( reflectionTexture.get() );
            _reflectionCamera->setClearColor( osg::Vec4( 0.0, 0.0, 0.0, 0.0 ) );
            _reflectionCamera->setCullMask( _reflectionSceneMask );
            _reflectionCamera->setCullCallback( new CameraCullCallback(this) );
            _reflectionCamera->getOrCreateStateSet()->setMode( GL_CLIP_PLANE0+0, osg::StateAttribute::ON );
            _reflectionCamera->getOrCreateStateSet()->setMode( GL_CULL_FACE, osg::StateAttribute::OFF );"

AFTER:
"// clip everything below water line
            _reflectionCamera=renderToTexturePass( reflectionTexture.get() );
            _reflectionCamera->setClearColor( osg::Vec4( 0.0, 0.0, 0.0, 0.0 ) );
            _reflectionCamera->setCullMask( _reflectionSceneMask );
            _reflectionCamera->setCullCallback( new CameraCullCallback(this) );
            _reflectionCamera->getOrCreateStateSet()->setMode( GL_CLIP_PLANE0+0, osg::StateAttribute::ON );
            _reflectionCamera->getOrCreateStateSet()->setMode( GL_CULL_FACE, osg::StateAttribute::OFF );
            _reflectionCamera->getOrCreateStateSet()->setAttributeAndModes(new osg::FrontFace(osg::FrontFace::CLOCKWISE), osg::StateAttribute::ON | osg::StateAttribute::PROTECTED);"

The fix is also working, if the front and backface are drawn normally and it 
should also be helpfull if the backface is not drawn at all.

There are some problems using osgOcean with a CompositeViewer with multiple 
views. The last view added to the viewer (so presumably the last one to be 
rendered) will control LOD of the ocean tiles, and will be the only view in 
which some effects will be visible (refraction, transparency, height map). I am 
investigating this, but it seems only effects requiring MRT behave this way - 
reflection is fine in multiple views.

I have modified the oceanExample to demonstrate this when run with the 
--compositeViewer argument. The post-render passes (DOF, glare) won't work at 
all in multiple views, I get a black screen. However, this is of less 
importance for us in the short term as we don't use these effects anyways, so I 
have disabled them completely for now.

The effects that concern me right now are reflection and transparency (which 
uses the refraction MRT pass). Reflection works correctly in multiple views 
already. But in the short-term I need to use transparency.


Symptoms of the problem:

1. LOD
This is not really a problem for us, as both views' viewpoints will generally 
be close to each other in our present application.

2. Refraction
The refraction MRT only applies to the last view in the CompositeViewer. Is 
this because the MRT just uses the same textures? Would we need to have 
multiple target textures, one for each view, and just swap them in the cull 
traversal for each camera? If so, we might want to adopt a strategy similar to 
the osgShadow view dependent techniques, which is to store a ViewData object 
per view and use this for things that must be kept different for each view.

3. Shadow in refraction
When the refraction MRT is used with osgShadow, the shadow in the refraction 
seems to be one frame late (presumably because the refraction MRT happens 
before the shadow pass for the current frame). 

Let me quickly describe an example of when that happens: Imagine there is a 
port with a dock, where the dock has a floor pretty near the surface. Some 
object in the port (say a crane) casts a shadow that is visible through the 
water on the dock floor. The crane's shadow outside the water is fine, but the 
shadow on the dock floor when seen through the water surface (so in the 
refraction MRT) is one frame late, which we can clearly see when 
moving/rotating the camera.

Presumably, we would need to ensure the shadow pass happens before the 
refraction MRT, but I have no idea how to do this.


As mentioned above, I modified the oceanExample to demonstrate this use case.

Use --compositeViewer to trigger the creation of a small inset view.

You should also use --testCollision so you can see the effects without having 
to move towards an island. Still, moving toward an island is educational as 
well, as you'll clearly see that the ocean tiles only take the last view (the 
inset by default) into account.

Then, to see the result when adding the main view last (instead of the inset 
view which is the default, since it's the case I've seen in most apps) you can 
use the --mainViewLast argument. Then the main view will be OK, but if you move 
the main view's camera towards an island, you'll see that in the inset view, 
the boat floats way above the ocean because the ocean tiles are now at a very 
low LOD. When staying close to the boat in both cases, you'll see the 
refraction/transparency doesn't apply to the inset view, even though reflection 
is fine.

I'd like some comments on this, mostly focusing on the transparency effect. 
What are some possible solutions, is the one suggested above a good one?

worldVertex is vec4
param is vec3

Offending function:
computeScattering( osgOcean_Eye, worldVertex, vExtinction, vInScattering);

Found in:
default_scene.vert
OceanScene default_scene local shader
terrain.vert

Forgot to add a callback that calls oceanScene::setScreenDims(osg::Vec2s 
size) when the application window is resized. Result is that the FBOs and 
screen aligned quads don't update to reflect the new size.

In our multi-threaded application, we have a thread that renders osg, and 
another one that displays a GUI. That GUI changes ocean properties, such as 
refraction.

When enabling/disabling refraction, a null-pointer is dereferenced in 
OceanScene::ViewData::cull()

I do not know the exact sequence that causes this, but I simply added a check 
for null-pointers and the problem went away.

Here's a patch file of my modifications in OceanScene.cpp.

Any idea why this might happen?

What steps will reproduce the problem?
1. Turn all underwater effects off 

Possible cause:

Wave heights are going about the fog line exposing unfogged geometry.

Small gaps are appearing in the ocean surface.

Possibly a corner piece that's breaking.

Possible cause:

The difference between mipmap levels is too great or small.

This might have to wait until I've redesigned the FFTOceanSurface 
implementation.

When I run the "convert_shaders.py" in MacOSX, it generates broken "*.inl" 
files.
The source shader files contain CRLF ("\r\n") line endings. This results in a 
carriage return character (0x0D) just before the \n" at the end of the line. 
For example this gives:

static const char osgOcean_downsample_frag[] =
    "#extension GL_ARB_texture_rectangle : enable
\n"

Note the orphan \n" at the new line. This doesn't compile.

Following patch in the python script fixes the problem:
Replace line
       newLine = line.replace("\n","")
with
       newLine = line.replace("\n","").replace("\r","")

Obviously a trivial issue and you can't provide shaders which magically
work with every application out-of-the-box but support for clipped water
would still be nice. Maybe you'll consider adding it.

As I failed to figure out how to reopen issue 27 (is that even possible?)
I'm filing a new one... copying my last comment:

I see that you reverted the patch again - may I ask why? The problem I'm
seeing is
that in the shader you do

  if(osgOcean_EnableReflections)
  {
    env_color = texture2DProj( osgOcean_ReflectionMap,
distortGen(vVertex, N) );   
  }
  else
  {
    env_color = gl_LightSource[osgOcean_LightID].diffuse;   
  }

although you (correctly) skipped reflection culling in
OceanScene::preRenderCull() -
which causes random noise from the reflection texture unit to appear on the
surface
(I suppose this depends on the OpenGL implementation...).

Since osgOcean uses multi-pass rendering and particularly full-screen
effects that are rendered to full-screen quads from previous RTT passes, it
is unlikely to be compatible with other nodekits that implement multi-pass
effects, or indeed any multi-pass effects created by the user.

I think this is inevitable in the current way of implementing these effects
(osgOcean and osgShadow, for example), but it would be nice if it were
possible to refactor the two to make them compatible. If this could be
done, we could then specify clearly what needs to be done for any
multi-pass effect to be compatible with osgOcean.

I think the first step is exposing the passes that are done in the
OceanScene in some way, as well as their order, and allow the user to
insert passes in the sequence. Perhaps some kind of scene manager object
could be devised to decouple this from osgOcean itself.

I'll ask on osg-users to see if people have suggestions about a general way
of doing this. Right now all the solutions I can think of would require
refactoring of all the nodekits we want to be compatible with each other to
follow the same scheme of doing things, which will be inconvenient for
exising users of those nodekits.

Hi,

When i build svn on my 64 bits archlinux box i get this build error :

FFTSimulation.cpp: In member function ‘void 
osgOcean::FFTSimulation::Implementation::computeBaseAmplitudes()’:
FFTSimulation.cpp:266: erreur: no match for ‘operator*’ in 
‘std::complex<float>(real, imag) * 
sqrt((((double)osgOcean::FFTSimulation::Implementation::phillipsSpectrum(((
const osg::Vec2f&)((const osg::Vec2f*)(& K))))) * 5.0e-1))’
make[2]: *** [src/osgOcean/CMakeFiles/osgOcean.dir/FFTSimulation.cpp.o] 
Erreur 1
make[1]: *** [src/osgOcean/CMakeFiles/osgOcean.dir/all] Erreur 2
make: *** [all] Erreur 2


replace sqrt by sqrtf solve the issue.

The reflected image seems to be backwards/reversed from what it should be.  
I.e., the reflected image shows the front of the object being reflected, 
when you're looking at the rear of the object.

See the attached image and note you can see the windscreen in the 
reflection, but not in the object itself.

osgOcean r182

reflections: true

WindowsXP
VS2008
FFTSS
GeForce GTX 280

Hope this helps,
Erik

When the wave-top hits an object it's possible that the reflection is
dissected by the clipping plane (see screenshot, that's my oil-rig in the
ocean) which is really irritating (from a distance it appears that the
object is hovering over the water).

As a quick hack I shifted the clipping plane:

reflClipPlane->setClipPlane(0.0, 0.0, 1.0, -getOceanSurfaceHeight() + 1.5);

... but I suppose it would be a lot nicer if the maximum wave-top would be
used instead of that magic 1.5. I just couldn't figure out where to get it. :)

I realize that this increases the risk of below-surface geometry ending up
in the reflection map so it _might_ be prudent to make this configurable -
OTOH I've seen no such artifacts in my application after the change...

<code>
C:\repository\git\win32\3rdparty\osgOcean\Release>cmake -G "Visual Studio 9 
2008 Win64"  
-DOSG_INCLUDE_DIR:PATH="C:\repository\git\win32\3rdparty\x64\osg-2.9.10\include"
 -DCMAKE_INSTALL_PREFIX:PATH="C:\repository\git\win32\3rdparty\x64\osg-2.9.10" 
-DWIN32_USE_MP=ON 
-DFFTSS_INCLUDE_DIR:PATH="C:\repository\git\win32\3rdparty\fftss\include" 
-DFFTSS_LIBRARY:PATH="C:\repository\git\win32\3rdparty\x64\build\Release\fftss.l
ib" -DCMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING="/MD /Zi /Od /Ob0 /D NDEBUG" ..
-- Check for working C compiler using: Visual Studio 9 2008 Win64
-- Check for working C compiler using: Visual Studio 9 2008 Win64 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler using: Visual Studio 9 2008 Win64
-- Check for working CXX compiler using: Visual Studio 9 2008 Win64 -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Found osg: C:/repository/git/win32/3rdparty/x64/osg-2.9.10/lib/osg.lib
-- Found osgDB: C:/repository/git/win32/3rdparty/x64/osg-2.9.10/lib/osgDB.lib
-- Found osgGA: C:/repository/git/win32/3rdparty/x64/osg-2.9.10/lib/osgGA.lib
-- Found osgViewer: 
C:/repository/git/win32/3rdparty/x64/osg-2.9.10/lib/osgViewer.lib
-- Found osgUtil: 
C:/repository/git/win32/3rdparty/x64/osg-2.9.10/lib/osgUtil.lib
-- Found osgText: 
C:/repository/git/win32/3rdparty/x64/osg-2.9.10/lib/osgText.lib
-- Found OpenThreads: 
C:/repository/git/win32/3rdparty/x64/osg-2.9.10/lib/OpenThreads.lib
OPENTHREADS_LIBRARYC:/repository/git/win32/3rdparty/x64/osg-2.9.10/lib/OpenThrea
ds.lib
-- Using FFTSS (LGPL) as FFT library.
CMake Error: The following variables are used in this project, but they are set 
to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake 
files:
OPENTHREADS_LIBRARY_DEBUG
    linked by target "osgOcean" in directory C:/repository/git/win32/3rdparty/osgOcean/src/osgOcean

-- Configuring incomplete, errors occurred!
</code>

Is it possible to build only release without debug libraries?

When fog isn't set to extreme values and one is flying rather high (yea
well, doing a flight simulation here :-) as in the example the end of the
endless ocean is easily visible so I added some (static) quads around the
dynamic tiles in FFTOceanSurface.

If wanted I'll provide a patch as soon as I have cleaned the code up a little.

See attached image.

Possibly misusing the clip node as I believe you are only able to have one in 
the scene?

Two are used.. one for the silt and one for reflections but the clip planes 
are different so I presumed this was correct, perhaps not.

The reflectionVisible calculation in OceanScene::preRenderCull is broken -
it doesn't take into account _enableReflections:

It should be:

-        bool reflectionVisible = cv.getEyePoint().z() <
_eyeHeightReflectionCutoff - getOceanSurfaceHeight();
+        bool reflectionVisible = _enableReflections &&
(cv.getEyePoint().z() < _eyeHeightReflectionCutoff - getOceanSurfaceHeight());

The reflected image of the boat doesn't seem to stay "attached" to the boat 
that's being 
reflected.  When a wave raises the boat up, the reflection seems to move lower.

osgOcean r182

reflections: true
refractions: true

None of the other osgOcean settings appear to have any affect (aside from 
making the 
waves smaller).

Note the attached image.  The water line on the boat is visible, but the 
reflection is 
well below it.  Same affect is found in the osgOcean osgExample with 
--testCollision.

WindowsXP
VS2008
FFTSS
GeForce GTX 280

Hope this helps,
Erik

What steps will reproduce the problem?
1.Download source and resource files.
2.Build the program.And susccessed.
3.Run oceanexample.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
win7

Please provide any additional information below.

Hi,

We've compiled the osgOcean sucessfully and the osgExample runs well.

When we quit the application, the compiler vc++ 2008 (express edition) shows an 
unhandled exception in the oceanScene.cpp file. It points to ~OceanScene 
destructor. See the image below for details 

As you provide settings for the texture units making the used clipping
planes configurable would both be nice and consistent.

i get a black ocean?
 I checkout the new tunk code,but it is not good,the sky is nice but the ocean is black,the log imformation is:

VERTEX glCompileShader "ocean_surface_vertex_shader" FAILED
VERTEX Shader "ocean_surface_vertex_shader" infolog:
Vertex shader failed to compile with the following errors:
ERROR: 0:50: error(#168) Reserved built-in name gl_ModelViewProjectionMatrix
ERROR: error(#273) 1 compilation errors.  No code generated

FRAGMENT glCompileShader "ocean_surface_fragment_shader" FAILED
FRAGMENT Shader "ocean_surface_fragment_shader" infolog:
Fragment shader failed to compile with the following errors:
WARNING: 0:60: warning(#283) Implicit cast from int to float
ERROR: 0:214: error(#202) No matching overloaded function found pow
ERROR: 0:214: error(#160) Cannot convert from 'const float' to '2-component vect
or of float'
ERROR: error(#273) 2 compilation errors.  No code generated

glLinkProgram "ocean_surface" FAILED
Program "ocean_surface" infolog:
Vertex and Fragment shader(s) were not successfully compiled before glLinkProgra
m() was called.  Link failed.

Warning: detected OpenGL error '无效操作' after RenderBin::draw(,)
RenderStage::drawInner(,) FBO status= 0x8cd5

is  the "ocean_surface_fragment_shader"  bug?

See attached

As noted in Issue 2, osgOcean will most probably be incompatible with other
multi-pass effects, including osgShadow, especially because of the
full-screen effects. If an API could be provided to turn these off, then a
basic ocean surface would probably be possible that would be compatible
with other effects. (not sure but probably)

This should be explored and an example should be added to demonstrate this.
The current oceanExample would become the "everything and the kitchen sink"
example, and the new example would be the basic "bare-bones" example.

This is pretty high on my priority list since my current project at work
would require this (as a start).

Hy I want use osgOcean in cloud rendering.
On left ,right and down edge is water without reflection it is maximum 4 pixels 
and it is changing and when I join together frames from other computers I get 
(no reflection) lines on total frame.  I think it can be issue with water 
shader or... can you repaire it ? 

Ferry

when i remove skydome in osgocean,ocean become very dark,
i want to inset osgephmeris in osgocean ,then i remove osgocean's skydome,
however ,ocean become very dark.why?

   First,I established an empty osg+MFC project. NO ERROR!

   Then, I add oceanScene example files to the project, and delete 
the "main()" function
in the "application.cpp" file. Then errors emerge:

  c:\...\osgocean\oceanScene(213) : error C2059 : syntax error : ";"
  c:\...\osgocean\oceanScene(223) : error C2059 : syntax error : ";"

  In order to find the problems, I delete all the oceanScene example 
files, 
and just add code "#include <oceanScene>" head file to "stdafx.h". But the 
same errors.

It would be nice to be able to change the parameters of the ocean surface
on the fly. Everything that's currently a command line argument (and
possibly more) could be changed by keystrokes ('a' to go one way, 'A' to go
the other way for numeric values, for example).

Then there could be a key to output a text file that would contain the
command line arguments that would reproduce the current ocean surface settings.

This would require minor refactoring of OceanSurface / FFTOceanSurface to
support run-time rebuilding with new settings. I would suggest that
OceanSurface have a virtual getEventHandler() method in which subclasses
would return a class-specific event handler that would have keys for the
parameters that the given OceanSurface sublclass knows about.

Running osgOcean in 16bit color causes a glare and DOF to fail with the 
following error:

RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd

I add rain or snow in osgocean1.01 is ok
but i do in the latest check out osgocean with it ,
it have some problem. why?

I have encountered following CMake related build issues on MacOSX:

When running CMake, following error appear:
"CMake Error at src/osgOcean/CMakeLists.txt:136 (INSTALL):
  install TARGETS given no FRAMEWORK DESTINATION for shared library FRAMEWORK
  target "osgOcean"."
This error appears both for Xcode and "Unix makefiles" generator. It seems that 
you can't specify to build a framework while not specifying the FRAMEWORK 
DESTINATION.

The following patch fixes it (remove the FRAMEWORK property in 
src/osgOcean/CMakeLists.txt):
Replace: 
SET_TARGET_PROPERTIES(
  osgOcean
  PROPERTIES FRAMEWORK TRUE
  PUBLIC_HEADER "${LIB_HEADERS}"
)
with
SET_TARGET_PROPERTIES(
  osgOcean
  PROPERTIES
  PUBLIC_HEADER "${LIB_HEADERS}"
)

With this patch, you can only build dylib and no framework. But at least the 
dylib work. I don't use frameworks and I don't know enough about CMake to 
propose a patch that allows to build both dylib and frameworks on MacOSX.



There is an additional issue that only appears when building with XCode. The 
XCode project is generated successfully, but it doesn't build. Many errors like 
the following appear:
make: ../../CMakeScripts/ReRunCMake.make: No such file or directory
make: *** No rule to make target `../../CMakeScripts/ReRunCMake.make'.  Stop.

It compiles successfully, when I remove the line:
SET( CMAKE_USE_RELATIVE_PATHS true )

It seems that the XCode projects generated with CMake are not compatible with 
the relative paths. Would it be possible to remove this by default to allow 
XCode compile on the Mac?

Thanks,

Jean-Claude

The bump mapping on the surface looks poor at certain angles. Cloudy effect.

water.f, water.v

Object space bump mapping should be fine here as I average the normal maps
into the vertex normal.

Could be the normal maps, the noise coords or the shader code itself.

Hi Kim, 

I saw the code in 'OceanScen.cpp', that 5 cameras 
in 'osgOcean::OceanScen::_glarePasses' were used to render the glare 
effect. 

But I saw the realization code in "water.frag" is just as bellow: 
if(osgOcean_EnableGlare) 
{ 
float lum = luminance(lumColor); 
gl_FragData[1] = vec4(lum); 
} 
And it looks like that the cameras in 'osgOcean::OceanScen::_glarePasses' 
have not been used anywhere. Will tell me why? 


Thank you! 

Cheers, 
Tian

The resources in the downloads section are not up to date. The islands
model and new shaders are missing.

This needs to be addressed before the 1.0 release.

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.