SphereWaterInteraction and RegisterDynamicWavesInput do not work correctly inside a flow area

[klauskobald]

Current Behavior

SphereWaterInteraction and RegisterDynamicWavesInput do not create waves in the areas that have flow splines:

You can see it at the border where the flow starts.

Expected Behavior

waves everywhere

Steps To Reproduce

No response

Unity Version

2021.3.31�

Crest Version

4.19

Render Pipeline

Universal

Editor or Standalone

Editor (Play Mode)

Environment

- OS: Mac 13.1
- GPU: Apple M1 Pro
- Graphics API: Metal
- Target Platform: Mac

Anything else?

No response

[klauskobald]

Sorry! I found the problem.
I was scaling the object with the spline by a factor of 4, for testing. That screwsed up the thing.
Setting all to 1 solved the problem!

[klauskobald]

Unfortunately it is still not really solved. I made some tests:
This is a sphere moving at a speed of 6 thru not flowing water:

And this is a sphere sitting still in a water flow of 6

It generates way less waves in the moving water. I have put the same FFT wave settings onto the flow component.

Overall the waterinteractions produces way less waves inside a flow area.
Any advise?

Another thing I found out is that the SphereWaterIteraction.VelocityOffset works on the world speed of the object. This is wrong! It has to use the relative speed thru the water, right?

[klauskobald]

Better images:
Flow: OFF

Flow: ON

Same relative speed of 6.
Seems also to be a difference in the created foam.

[daleeidd]

Yeah, that doesn't seem right. I would think it would be stronger if anything but I could be wrong. If you disable the following line it does a bit to keep the interaction strength - can go even further by changing it to an add to increase the interaction strength:

crest/crest/Assets/Crest/Crest/Scripts/Interaction/SphereWaterInteraction.cs

Line 170 in 92af050

relativeVelocity -= new Vector3(surfaceFlow.x, 0, surfaceFlow.y);

I don't know if this will be the actual solution as going against something that seems intentional but worth a test anyhow. LMKWYT

Another thing I found out is that the SphereWaterIteraction.VelocityOffset works on the world speed of the object. This is wrong! It has to use the relative speed thru the water, right?

That makes sense and will look into it.

[klauskobald]

Yes! That's it. Looks right to me! Please do not forget to change this for the next update!

[kyleli]

Unfortunately removing that line or adding the surfaceFlow vector to relativeVelocity creates a new issue where the interaction sphere effect begins to compound on itself over time when no input is applied. This is what happens when you remove the line with a flow of 9 and do not add any input to the spheres (just let it move with the flow).

Screen.Recording.2023-11-20.at.9.06.30.AM.mp4

This is the behavior normally without removing or adding the surfaceFlow vector, note the lack of amplified interaction sphere forces:

Screen.Recording.2023-11-20.at.9.10.19.AM.mp4

I do believe that the issue might stem from taking the world object speed and not relative speed.

Edit:
Upon further testing this unwanted amplification occurs at any flow rate. You can reproduce by setting a curve with flow, placing an interaction sphere with no further inputs in the flow, and disabling the following line:
relativeVelocity -= new Vector3(surfaceFlow.x, 0, surfaceFlow.y);

Ideally the behavior should replicate wakes similarly between non flow and flow elements with the same interaction settings.

[daleeidd]

Thanks for the additional input. I will look into it further and see if I can come up with something.

[daleeidd]

I had a harder look and the velocity calculations are correct.

There is an issue where wakes do not work very well at higher velocities which flow can contribute to and may be related in certain cases.

There is certainly a diminished wake in flow. I am not sure how SWI should behave in flow and whether this is correct or needs fixing. It may take a while before a conclusion on that.

For the time being I think the loss of wakes can be compensated by modelling the boat's propulsion system and further compensated with water spray as the boat will have to work harder against flow to maintain velocity.

[daleeidd]

Alright... so wakes are far more diminished when flow is not axis aligned. When axis aligned it is pretty close to expectations.

[kyleli]

I had a harder look and the velocity calculations are correct.

There is an issue where wakes do not work very well at higher velocities which flow can contribute to and may be related in certain cases.

There is certainly a diminished wake in flow. I am not sure how SWI should behave in flow and whether this is correct or needs fixing. It may take a while before a conclusion on that.

For the time being I think the loss of wakes can be compensated by modelling the boat's propulsion system and further compensated with water spray as the boat will have to work harder against flow to maintain velocity.

I do actually agree with this, I was doing thinking as well and flow should definitely dampen the effect of SphereWaterInteractions, however I think the current iteration of flow is neutering this far too much to where at any flow above
certain values completely removes any impact of a sphere interactor e.g. in flows of 5 or above. If we refer to even shallow rapids we can see a noticeable impact of the watercraft e.g. https://youtu.be/FW8c75CUBGU. Perhaps the impact of water interactions in flow should be a tunable setting on the flow side?

[daleeidd]

e.g. in flows of 5 or above

Fastest river speed would be around 3MPS (in rare cases almost 5MPS). Flash flooding is around 7MPS.

This will take a while to solve properly as there is potentially various factors.

As for increasing the weight of SWI in flow that is a possible workaround. I made a branch you can try: fix-weak-flow-swi-interaction