Hi Kim,
Adding in a transform between OceanScene and OceanTechnique would be ok, aslong as it's just a translation on the z axis. Any other transformations (scaling x/y trans, rotations) would cause problems with the mipmap level calculations and the tracking of the sea relative to the camera position.
Yes, so perhaps as a first step hiding the transform and just giving access to s/getHeight() would be safer. If OceanTechnique subclasses from MatrixTransform, then people will think they can position it by calling oceanTechnique->setMatrix(), which might lead to problems as you say.
Alternatively a quick hack would be add an offset to the _startPos variable in FFTOceanSurface, or even make it a member variable of the base class. That way you could position the ocean surface at any point on the x,y,z and *i think* it would all still work. However, I think perhaps adding in support for matrix transforms is a more desirable solution.
The problem with the offset to _startPos is that for it to take effect, you'll have to regenerate the geometry, am I right? Whereas with a transform (perhaps limiting it to z offset as discussed above) the change would be instantaneous and not change anything in the geometry.
I apologise for the vague answer but I don't have time at the moment to dig around and test out how it would be done best.
You call that vague? I thought it was pretty darn detailed! :-) 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
