kbale / osgocean Goto Github PK
View Code? Open in Web Editor NEWAn ocean rendering nodekit for OpenSceneGraph
License: GNU Lesser General Public License v3.0
An ocean rendering nodekit for OpenSceneGraph
License: GNU Lesser General Public License v3.0
osgOcean v1.0 ------------- DEPENDANCIES ------------ Resources --------- Both the library and the example require a set of resource files (models/textures) which can be downloaded from here: http://osgocean.googlecode.com/files/osgOcean-Resources-1.0.rar Once you downloaded them, extract the 'Island' and 'Textures' folders into the resources directory found in the root of the source code tree. The install project will copy the relevant data files to the bin path like so: *install_path*/bin/resources/ osgOcean uses the osgDB registry to find the resource files. By default it adds the following paths to the registry: Shader path: resources/shaders/ Texture path: resources/textures/ If you wish to move these resources you must update the data file path list within the registry yourself. This can be down from outside the library with the following code: osgDB::FilePathList& pathList = osgDB::Registry::instance()->getDataFilePathList(); pathList.push_back( new_path ); Libraries --------- osgOcean also requires a Fast Fourier Transform library. It can work with either FFTW or FFTSS. **IMPORTANT LICENSE ISSUE** FFTW is released under a General Public License, by selecting this option in CMAKE the resulting build of osgOcean will also be covered under the GPL license. GPL License details: http://www.gnu.org/copyleft/gpl.html FFTSS is covered under a Lesser General Public License which allows the osgOcean library to remain LGPL. LGPL License details: http://www.gnu.org/licenses/lgpl.html or see LICENSE.txt FFTW and FFTSS can be downloaded from: FFTW: http://www.fftw.org/ FFTSS: http://www.ssisc.org/fftss/
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.
Original issue reported on code.google.com by [email protected]
on 12 Jun 2009 at 1:43
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
Original issue reported on code.google.com by [email protected]
on 27 Jan 2010 at 1:41
Attachments:
_enableDefaultShader is not initialised in OceanScene
Original issue reported on code.google.com by [email protected]
on 16 Jun 2009 at 2:47
In ShaderManager.cpp, #include <osgDB/fileutils> should be
#include <osgDB/FileUtils>. Only Windows will accept the lower
case name, is no one using Linux?
Original issue reported on code.google.com by [email protected]
on 20 Jul 2009 at 1:24
I get Could not find: islands.ive
even though the file really exists in %install_path%/bin/resources/island/
as the usage instructions say.
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.
Original issue reported on code.google.com by [email protected]
on 30 May 2013 at 9:18
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
Original issue reported on code.google.com by [email protected]
on 27 Jan 2010 at 5:36
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. :-)
Original issue reported on code.google.com by felix.nawothnig
on 12 May 2010 at 10:01
Attachments:
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. :-)
Original issue reported on code.google.com by felix.nawothnig
on 31 Mar 2010 at 8:57
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.
Original issue reported on code.google.com by [email protected]
on 2 Jan 2012 at 2:50
Attachments:
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?
Original issue reported on code.google.com by [email protected]
on 14 Apr 2011 at 1:58
I haven't been able to test these changes but it does mean the code will compile against OpenSceneGraph 3.5.0. They should work against 3.4.0
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
Original issue reported on code.google.com by [email protected]
on 17 Jun 2009 at 3:06
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.
Original issue reported on code.google.com by [email protected]
on 17 Jun 2009 at 11:53
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?
Original issue reported on code.google.com by [email protected]
on 13 Feb 2012 at 8:51
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 17 Jun 2009 at 7:43
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.
Original issue reported on code.google.com by [email protected]
on 17 Jun 2009 at 7:42
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","")
Original issue reported on code.google.com by [email protected]
on 25 Dec 2010 at 10:18
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.
Original issue reported on code.google.com by felix.nawothnig
on 31 Mar 2010 at 9:05
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...).
Original issue reported on code.google.com by felix.nawothnig
on 10 May 2010 at 11:14
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.
Original issue reported on code.google.com by [email protected]
on 12 Jun 2009 at 1:38
When I try to build it on ubuntu 18.04, I get the following error. Any suggestion to fix it? Thanks.
CMake Error at /usr/share/cmake-3.10/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
Could NOT find osg (missing: OSG_LIBRARY OSG_INCLUDE_DIR)
Call Stack (most recent call first):
/usr/share/cmake-3.10/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake-3.10/Modules/Findosg.cmake:50 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:26 (find_package)
-- Configuring incomplete, errors occurred!
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.
Original issue reported on code.google.com by [email protected]
on 26 Feb 2010 at 6:43
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
Original issue reported on code.google.com by [email protected]
on 23 Nov 2009 at 7:44
Attachments:
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...
Original issue reported on code.google.com by felix.nawothnig
on 12 May 2010 at 9:37
Attachments:
<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?
Original issue reported on code.google.com by [email protected]
on 19 Apr 2011 at 8:00
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.
Original issue reported on code.google.com by felix.nawothnig
on 31 Mar 2010 at 9:12
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.
Original issue reported on code.google.com by [email protected]
on 19 Jun 2009 at 9:42
Attachments:
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());
Original issue reported on code.google.com by felix.nawothnig
on 7 May 2010 at 7:33
What is the license of these files? LGPLv2?
And why are they not part of the repository?
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
Original issue reported on code.google.com by [email protected]
on 23 Nov 2009 at 7:36
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 26 Sep 2011 at 4:19
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 10 Jun 2010 at 12:07
Attachments:
As you provide settings for the texture units making the used clipping
planes configurable would both be nice and consistent.
Original issue reported on code.google.com by felix.nawothnig
on 31 Mar 2010 at 9:08
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?
Original issue reported on code.google.com by [email protected]
on 16 Nov 2010 at 8:36
When first going or moving underwater I get:
"
FRAGMENT glCompileShader "gaussian1_fragment_shader" FAILED
FRAGMENT Shader "gaussian1_fragment_shader" infolog:
0:11(21): error: no matching function for call to `texture2DRect(sampler2DRect, vec4)'; candidates are:
0:11(21): error: vec4 texture2DRect(sampler2DRect, vec2)
0:11(15): error: operands to arithmetic operators must be numeric
0:14(21): error: could not implicitly convert operands to arithmetic operator
0:17(21): error: could not implicitly convert operands to arithmetic operator
glLinkProgram 0x7fd820bc7ae0"gaussian1" FAILED
Program "gaussian1" infolog:
error: linking with uncompiled shader
FRAGMENT glCompileShader "gaussian2_fragment_shader" FAILED
FRAGMENT Shader "gaussian2_fragment_shader" infolog:
0:11(21): error: no matching function for call to `texture2DRect(sampler2DRect, vec4)'; candidates are:
0:11(21): error: vec4 texture2DRect(sampler2DRect, vec2)
0:11(15): error: operands to arithmetic operators must be numeric
0:14(21): error: could not implicitly convert operands to arithmetic operator
0:17(21): error: could not implicitly convert operands to arithmetic operator
glLinkProgram 0x7fd820e881c0"gaussian2" FAILED
Program "gaussian2" infolog:
error: linking with uncompiled shader
FRAGMENT glCompileShader "dof_combiner_fragment_shader" FAILED
FRAGMENT Shader "dof_combiner_fragment_shader" infolog:
0:41(15): error: no matching function for call to texture2DRect(sampler2DRect, vec4)'; candidates are: 0:41(15): error: vec4 texture2DRect(sampler2DRect, vec2) 0:43(22): error: no matching function for call to
texture2DRect(sampler2DRect, vec4)'; candidates are:
0:43(22): error: vec4 texture2DRect(sampler2DRect, vec2)
0:43(22): error: type mismatch
0:46(25): warning: centerDepth' used uninitialized 0:75(36): warning:
centerDepth' used uninitialized
glLinkProgram 0x7fd820e77d60"dof_combiner" FAILED
Program "dof_combiner" infolog:
error: linking with uncompiled shader
"
This is with mesa-libGL-17.2.4 on an Intel GPU:
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Ivybridge Mobile
OpenGL core profile version string: 4.2 (Core Profile) Mesa 17.2.4
OpenGL core profile shading language version string: 4.20
See attached
Original issue reported on code.google.com by [email protected]
on 19 Jun 2009 at 9:43
Attachments:
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).
Original issue reported on code.google.com by [email protected]
on 12 Jun 2009 at 1:52
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
Original issue reported on code.google.com by [email protected]
on 7 Apr 2013 at 1:29
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?
Original issue reported on code.google.com by [email protected]
on 18 Nov 2010 at 2:24
Attachments:
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.
Original issue reported on code.google.com by [email protected]
on 30 Oct 2009 at 7:23
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.
Original issue reported on code.google.com by [email protected]
on 12 Jun 2009 at 1:48
Running osgOcean in 16bit color causes a glare and DOF to fail with the
following error:
RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cdd
Original issue reported on code.google.com by [email protected]
on 17 Jun 2009 at 5:37
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?
Original issue reported on code.google.com by [email protected]
on 2 May 2011 at 5:03
Attachments:
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
Original issue reported on code.google.com by [email protected]
on 25 Dec 2010 at 11:17
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.
Original issue reported on code.google.com by [email protected]
on 5 May 2009 at 4:22
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
Original issue reported on code.google.com by [email protected]
on 24 May 2010 at 7:15
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.
Original issue reported on code.google.com by [email protected]
on 12 Jun 2009 at 1:41
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 [email protected]
on 12 Jun 2009 at 5:42
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.