Hi, Wojtek,

      Thanks for your reply . But up to  now , I still can not figure out the 
exact meaning of the codes there.

May Kim bless us! I hope that he can answer us as soon as possible!

                                                                                
   ZhangMi
 



From: w.p.lewandow...@gmail.com
Date: Wed, 3 Jul 2013 14:30:43 +0200
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Some Question About OSGOean class :FFTSimulation


One more word. I might have been wrong that it was 0 frequency. Memory does not 
serve me well these days ;-). So do not rely on the fact it was 0 frequency or 
0 vs N/2 index. It might have been some other frequency but certainly there 
were an issue with matching proper indices of FFT input array for frequencies 
in generation of PhilipsSpectrum from Tessendorf paper. 


Wojtek



2013/7/3 Wojciech Lewandowski <w.p.lewandow...@gmail.com>


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 <scott200...@hotmail.com>






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
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




_______________________________________________ osg-users mailing list 
osg-users@lists.openscenegraph.org 
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org       
                                
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to