Hi Bawenang,
Hi, I actually have been using osgOcean for a year now. Well, I actually use
Delta 3D which uses OSG and in turn osgOcean.
Excellent, we appreciate you using it! Progress has been slow in the
past few months but we hope to be able to put a bit more time on it in
the near future.
It's a pretty good library for rendering ocean, would be better if you can add
atmospheric scattering using Mie and Rayleigh approximation for real time
day-night situation. But beggars can't be chosers, right? :D
I think the skydome that osgOcean does is useful just for the demo app,
its focus is really the ocean so adding effects in the sky would be an
over-extension of the library's goal IMHO. Another library should do
this. We use osgEphemeris for our skydome, it doesn't do scattering but
gives a beautiful day and night sky (with accurate stars, moon and
planets placement relative to the
longitude/latitude/year/month/day/hour/minute/second you set). It would
be possible to add scattering effects to that nodekit and in that case I
think it would be appropriate.
Anyway I've found 2 bugs on osgOcean. One I still haven't been able to solve,
that is the glare functionality. It seems like the glare would also affect the
skybox and not only the ocean. I believe it's a shader issue when you are
downsampling the rendered texture with glare.
I'll have to let Kim field any questions on the shaders as I didn't work
on them (apart from fixing a few issues that prevented them from
compiling on GeForce 7 GPUs).
The other one is the "FFTOceanSurface::getSurfaceHeightAt()" method.
Thanks for investigating the bug. Actually, the code I have for this
function is different from what you have (the condition at the top is
different):
if(ix < _numTiles && iy < _numTiles)
{
const OceanTile& data = _mipmapData[_oldFrame][0];
float tile_x = oceanX - ix * _tileResolution;
float tile_y = oceanY - iy * _tileResolution;
if (normal != 0)
{
*normal = data.normalBiLinearInterp(tile_x, tile_y);
}
return data.biLinearInterp(tile_x, tile_y);
}
It seems to have been that way forever in the SVN repo (that function
was added in revision 146 and it hasn't changed since) so I don't know
why your code is different... We have also used that function
extensively here at CM-Labs, and have never had a crash there, so I
wonder if it could be that check that makes it work for us (it indeed
seems like it could influence the values of tile_x and tile_y which
could then be valid all the time in our version).
Could you try out our version, and also perhaps investigate why your
code is different? Are you using a version of osgOcean that was
integrated into Delta3D? Could the Delta3D people have made changes when
integrating it?
In general, when submitting fixes to an open source library, it's always
best to try out the most up-to-date version first (SVN trunk) and see if
your problem is still reproducible. It may have been fixed already,
which saves you some time coding up and submitting a fix. That being
said, if the modified code doesn't fix your problem, then by all means
you should try to find a fix and submit it. The other thing is that in
OSG's case (and I think the same for osgOcean) it's preferable to submit
whole modified files when submitting a change, that way we can clearly
see what you changed, and would have quickly spotted that different if()
I noted above.
Thanks,
J-S
--
______________________________________________________
Jean-Sebastien Guay [email protected]
http://www.cm-labs.com/
http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
