wave-harmonic / crest

A class-leading water system implemented in Unity
MIT License
3.49k stars 478 forks source link

Wave sim intensity is very frame-rate dependent #44

Closed Rbn3D closed 5 years ago

Rbn3D commented 6 years ago

Hi @huwb !

Looks like Wave sim/Foam sim intensity are very related to framerate. I have tested this on 3 diferent machines:

On machine 1, there is a lot of foam just after starting accelerating the ship a little, and after get some speed, the generated wave is way higher (in height) than desired.

On machine 2, is also noticeable there is a lot more foam than normal, and that waves go too up as well, but not as much as on machine 1.

On machine 3, there is almost no foam (unless you go pretty fast and turning), and wave sim is way smaller, not getting as high as any of the other machines.

I've just double checked this on latest https://github.com/huwb/crest-oceanrender/commit/d4d8536507f7237f75f94a473331a6a296e506a2 commit from master.

I think that some time-dependent values are not multiplied by Time.deltaTime, or maybe we are mixing fixed time step with regular time steps. I'll try to figure out what is causing this.

Thank you!

huwb commented 6 years ago

Thanks for reporting. That's useful info.

I haven't made progress fixing this but added a helper for debugging - I added a Sleeper script that can just generate a random pause during the frame, so you can get a badly varying framerate.

I did a test with this script and set the foam fade rate very high (so foam is removed every frame), and set the foam generated from the wave sim to high, and i get this image of beauty: https://drive.google.com/open?id=1K46UfNF9ZlWOwvB3w0HFn76bSzphY90T

this indicates that the computed acceleration is highly unstable, which is computed from current and previous dts. Something is wrong here.

It's not clear that this is related to general wave behaviour being different at different frame rates, but its clearly an issue and perhaps something that should be fixed first.

If the wave dynamics are still time dependent after that fix, we might experiment with integration schemes (i compared a few in the past - http://www.huwbowles.com/spring-dynamics-production/ ). Semi Implicit Euler should be simple to implement and seems to conserve energy well.

huwb commented 6 years ago

Quick note - in #47 we discovered how to generate displacements from the dynamic wave sim, which means both the ocean waves and the dynamic interaction waves can now produce foam through the same mechanism, which does not suffer from the issue I show above in the video. I have now deprecated the foam path that causes that flicker issue in my video above - so thats one less issue to deal with.

However this wont affect the dynamic waves having higher amplitude etc at low frame rates so the main issue is still open.

Rbn3D commented 6 years ago

Just tested latest commit https://github.com/huwb/crest-oceanrender/commit/3f531a0a8008ea0d0e8af687b34816151d47dca9 from master on both machine 1 (slowest) and machine 3 (fastest) and the looks like the foam thing is fixed!

There is still higher amplitude of waves on machine 1, but they seem to have descreased a bit. Also, wave shape looks more realistic now (I guess it's the new displacement) so this is going in the right direction 👍

Foam on machine 3 it's perfectly nice and goes just along the waves (as they should). Foam on machine 1 it's perfect too and just along the waves, but the higher amplitude of wave makes the foam a bit more intense (just a little bit), but I guess this is not a foam issue itself but related to wave amplitude issue.

Thanks for your efforts on this!

Rbn3D commented 6 years ago

Hi @huwb !

What's the status of this issue? Does https://github.com/huwb/crest-oceanrender/commit/8e1ae156025ec757e4b4bf6313f15de19eac7196 fix the amplitude issue? Would be nice to have a system that works on a predictable way on all machines.

Thank you.

huwb commented 6 years ago

Hey there, thanks for the bump.

Sadly it does not (yet). I started to see if i could rebuild the sim from the ground up, and so far the results in that commit are a bit crazy. I came to the conclusion that i need to find a book or other resource to write a solid sim. I always find it really difficult to get good and solid results when I write my own sim stuff starting from the equations..

The other potential plan is to run the current sim at 60hz (fixed), or run it with steps up to but not more than 16ms. The latter means i could always update to the frame end time and wouldnt have to worry about interpolating results to avoid jitter etc. This is my favourite option, but I tried this for some time and could not manage to create a command buffer to successfully do multiple ticks. I don't recall the exactly why i failed but I think my next move will be to try the same thing again with fresh eyes.

I hope I can sort this and #55 some time soon. I'll post back if i make progress.

Rbn3D commented 6 years ago

Thanks for the update.

Yeah, sim stuff looks pretty difficult for me too, I would really like to help there, but I feel like I need stronger math skills... Also need to digg a little more into Crest codebase to realise how things are done...

I'll post back if I find resources or anything helpful.

huwb commented 6 years ago

Still haven't made progress on this. I'm not really mentally geared up to rewrite simulation code at the moment, and I have pressing things (that I actually do understand :)) that keep overtaking this on my list. Also my day job is getting busy at the moment so my time windows for Crest are becoming smaller. And above all that, at some point in the future the built in render pipeline will probably be deprecated (?) and I want to start laying the groundwork for transitioning to the scripted pipelines.

I'm afraid I'm transitioning the status of this to "no current plans to work on it", and I'll apply the help wanted tag in case someone who is good at writing sims reads this and comes to our rescue! Sorry about this.

huwb commented 5 years ago

Simulation time step is now limited to a max of 16.67ms (60hz). This should add enough consistency to resolve this issue.

Rbn3D commented 5 years ago

Hi @huwb !

Many thanks for your work.

Cannot test this right now, but I hopefully will some time soon! :)