Open daleeidd opened 3 years ago
Thanks for posting. I don't immediately know what works cause this but will post if I figure it out
This is not specific to fft, it happens with shape gerstner also.
It also affects ShapeGerstnerBatched, but it is not noticeable with a full spectrum.
@huwb I think ShapeGerstner and ShapeFFT are more susceptible because they are tiled? Rendering the Jacobian directly into the foam data shows the issue still. The foam data from the ShapeGerstnerBatched appears more stable. An option could be to add noise or blur the foam data.
Would it be possible to see it happening for SGB? With a simplified spectrum would be useful.
I messed around here but did not notice an issue using SGB.
Yeah the tiling could be exacerbating it for SG/SFFT. But its not clear to me why. If the waves were not tiling properly that would do it. Perhaps some very large wavelengths are not tiling or something. Although I jut spent some time messing around with SFFT. There are obvious repeating patterns in the foam data, but im not getting "gridlines" like the above screenshot. I tried the repro steps above. Would itbe worth pushing a temp branch that we can use as a repro, so i can make sure i get the issue here?
Sure. Test branch here: https://github.com/wave-harmonic/crest/tree/test/foam-grid-issue
Test scenes are under Test folder. There is one scene per shape type.
Thanks. Weirdly i suddenly seem to repro it easily by just dropping in an FFT component.
It looks indeed like the wave patches are not tiling. I see lines every 0.5m which is exactly the size of the first wave cascade. If i turn off ~0.5m waves in the spectrum sliders, they go away.
I don't know why the waves are not tiling properly, the FFT was not messed with too much. so it is supposed to be strictly repeating patches (FFT is not able to do non-repeating). Might be worth comparing the spectrum with other similar code, or hacking the spectrum to only have one non-zero value to produce a single wave and try to show that it clearly does not tile.
Will post again if i make progress.
Fixed with 4.14.
Has this really been fixed? I still get lines after updating from 4.13 - 4.15. Do I need to replace components?
I still get lines after updating from 4.13 - 4.15. Do I need to replace components?
It should have been fixed in 4.14. Have you seen any improvement? It may still be possible to incur these with low settings perhaps.
Watch the image above. The foam damping was almost zero - just to illustrate. But one can also see it with other settings. The "idea" of stripes is everywhere. It has not changed at all compared to 4.13. What component(s) is producing that? What files are involved, so I could have a look at the diff.
I tried different values for SAMPLES_PER_WAVE (in FFTSpectrum & ShapeFFT) but cannot see any difference. It looks more or less like this.
There is 4 WaterInteractionSpheres producing the waves with these parameters:
Greater weight produces more waves and more of the lines.
So the lines only appear because of the Sphere Water Interaction and FFTs together? There is a resolution param on the ShapeFFT. Not sure if it will help with these sort of patterns.
The strips are everywhere. The WaterInteraction creates more waves, that´s why they are better visible. But here is the scene away from WaterInteraction. You can see the lines
Stripes align always on the x-axis, and it seems like they are only in the inner most LOD.
Are you able to share a minimal scene or presets to reproduce? I haven't seen these lines that prominent since they were fixed. No need to provide Crest as I have a copy (I'll use latest URP version). Can send on Discord if you want.
This is an export of a prefab with minimal dependencies. http://clients.kobald.com/crest/ocean/ I could not get it to work in a new project because of some urp setting. If you have a working scene it should be ok, I think.
Thanks! I can see them now. Looks like we only improved the situation for a OR resolution of 384. Anything else appears to produces the pattern. I'll reopen.
That´s interesting - I can live with 384. Question: a higher number (like 384) will use more cpu or gpu? If I increased _geometryDownSampleFactor to 4, would that compensate for higher cpu usage then?
Mostly GPU and memory. Increasing that will help performance but I don't think it will help with CPU.
Describe the bug Reported by @klauskobald on Discord. When using the ShapeFFT, foam simulation data appears to have grid lines.
Screenshots / video
Versions Latest
To Reproduce
Platform
Additional context I tried disabling the variance to see if it was that but had no effect from what I could see.