Hi, Will (Mi ?) I am also curious what will Kim answer.
I have not studied osgOcean thoroughly and never used it in practice except for few test runs. But I will want to share some of my observations I made long time ago when I worked on my own Tessendorf paper implementation. We all are practical people, so when we see such advanced algorithm based on scientific paper we often start google and look for some existing code samples. And when I did that, every piece of FFT ocean wave code I found was doing the same trick with inverting sign diagonally. See cuda ocean for example (but many other samples can be found too). I was as puzzled as you are now. I have spent some time trying to investigate it and learning FFT properties and I have found that many fwd FFT functions used in these samples expect array of parameters for frequencies in following order : // Bourke fwd FFT uses 0-N/2 indices for 0, 1/T, 2/T .. N/2/T frequencies // and N/2 + 1 to N - 1 indices for -(N/2-1)/T...-2/T, -1/T frequencies But all those sample implementations of Tessendorf paper seemed to make an error there. They were assuming 0 frequency factors should be stored in N/2 index while in practice it should be stored on index 0. Because of that, generation of K param used in Philips spectrum for 0 frequency was often incorrectly placed. And that 0 frequency was responsible for sign changes in generated heightfield. I guess people empirically found that sign can be reverted diagonally and that hack was adopted. But why everybody did the same mistake, one may ask ? I guess it may mean I was wrong on something (because complex number FFT can be tricky) or everybody was copying from former implementations ;-P. But thats just my 2 cent conspiracy theory... Anyway, it was long ago and I could have made some error while describing it. But please check generation of PhilipsSpectrum factors and check if they arte stored on proper indices for particular FFT you use and check how they should be set according to Tessendorf paper. If they are set correctly that sign multiplication may be not neccessary. Wojtek 2013/7/3 WillScott <[email protected]> > Dear Kim, > > I have done some research on the paper "Simulating Ocean Water" > (the paper you provide for me several days ago). And the third part -- > Practical Ocean Wave Algorthms ---- is an attriactive algorthms. > > However , the corresponding codes in OSGOcean class > -- FFTSimualtion-- is not in accord with origianl paper that presented. In > the function "void FFTSimulation::Implementation::computeHeights( > osg::FloatArray* waveheights ) const" , the DFT algorithm is done for wave > height simulation. But the final lines in this member function really > confused me a lot : > > const float signs[2] = { 1.f, -1.f }; > > for(int y = 0; y < _N; ++y) > { > for(int x = 0; x < _N; ++x ) > { > waveheights->at(y*_N+x) = _realData0[x*_N+y][0] * > signs[(x + y) & 1]; > } > } > > So , could you please explain to me why "sings[(x+y)&1]" was > used here? In addation , why noly the "_realData0[x*_N+y][0]" used for > the wave height computation? To some extent , the codes here is not that > corresponding to the function(19) presented in the third part of the > origianl paper. I have taken several day to thought about it , but in > vain. Therfore , I will feel appreciate if you can give me a resonable > reply or provide some relevant materials to me. > > I am looking forward to your reply. > > > Sincerely Yours, > > > Zhang Mi > > School of Remote Sensing and Information Engineering , Wuhan > Universiy , Hubei Provinence , China. > > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
