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
