Multi frame lag on CPU SampleHeight is causing issues.

[wave-harmonic]

Multi frame lag on CPU SampleHeight is causing issues.

[huwb]

Ok, thanks for the note. I think the first thing I'll do is an option to make the readback synchronous. This will add stalls but would be useful for comparisons/debugging. I'll post back when I've done this.

Besides that i'm thinking about two directions to solve this currently.

A first one is to compensate for the time delay and move the collision accordingly. See commit 8146864 . It records a timestamp with each readback request, and when it does get collision data it computes the velocity that the surface (height) is changing and then extrapolates forward to the current time. In my tests it was a able to track the surface pretty well, with the exception of some slight noise which i dont think would be a blocker, or could be polished out. It would need some kind of system to cache velocities etc, i can think about this.

The other thought i had was to actually start rendering out shape two frames ahead on the gpu, so that it can come back to the cpu in time (i guess this needs a fixed framerate to work 100%) things that are deterministic in time should work well, but for dynamic simulation stuff i guess this will just shift the lag into the sim. these disadvantages and the mess i'm guessing it will make of the code make me think the first option is worth exploring first.

i'll let you know when i have more..

[huwb]

I hacked in the option to do synchronous readbacks (to avoid the async latency) for debugging/comparison. I decided to put it in a branch for now, but could probably be convinced to put it in master with #ifdef's and such. It's a static which I've added to the debug GUI - Use Async Readback.

Turning it on is expected to hit perf (it will make the CPU block-wait for the GPU to render everything and transfer over the shape), but its just for functionality comparison purposes.

If you get a chance, could you confirm this fixes the issue you report above?

8fa07a5

[dizzy2003]

Turning it on is expected to hit perf By turning it on do you mean set _useAsyncReadback to false? With it false I get a ton of exceptions it seems _dispTexCopy is null, and is set after its read. If I fixed that and init it first, then I get problems where the GetSuggested Lod is always -1 because the lod cameras rectangles are always 0 I think maybe I'm meant to start off with async true then toggle it to false at runtime. Doing that it appears though that the height returned is possibly premting the actual wave height, a cube placed in the water with a script that just sets its position to water height has the cube going up to the top of the wave a little early.. then making the 16meter wavelength quite strong so a big pointy wave comes in You should be able to recreate the issue with a similar test..

…

On Wed, May 30, 2018 at 5:48 PM, Huw Bowles ***@***.***> wrote: I hacked in the option to do synchronous readbacks (to avoid the async latency) for debugging/comparison. I decided to put it in a branch for now, but could probably be convinced to put it in master with #ifdef's and such. It's a static which I've added to the debug GUI - Use Async Readback. Turning it on is expected to hit perf (it will make the CPU block-wait for the GPU to render everything and transfer over the shape), but its just for functionality comparison purposes. If you get a chance, could you confirm this fixes the issue you report above? 8fa07a5 <8fa07a5> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#20 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOU9GAfZJtenKeMyHgE3eks5bgnWMFV-ks5t3k7qgaJpZM4UPvI7> .

[huwb]

Sigh.. sorry.. i hacked that in a quickly and after experimenting now I've realised _useAsyncReadback must be left true on startup so that everything gets init'd properly, and then turned on/off while running.

My steps:

• Assign OceanCollisionDemo script to camera
• Assign OceanHeightDemo script to a cube
• Press play (with _useAsyncReadback = true)
• Turn _useAsyncReadback on/off using debug gui at runtime to compare

With this, I get something that tracks the surface very closely, even for an aggressive wave:

https://drive.google.com/open?id=1ZH8oc3zR4lioWYXtWZ6D1BoQrUOarKcM

I did my best to clamp it to 30fps. I pushed the hacks i did to make the video: fcf73a1

The white cubes sample the displacement, the red cube inverts the displacement to get the height.

They seem to track the surface closely for me. There is some visible error, but this is a quite extreme wave. Are you seeing the same level of error and is this proving to be an issue?

[huwb]

One more capture, this time failing a bit less at running at 30fps:

https://drive.google.com/open?id=1Yml_gAO9fsFlzqikgdXC0UQhsghVNITn
f9bdede

[dizzy2003]

Yours looks a lot less laggy than ours.. I just removed our cache incase that was the issue, but it was the same. One thing it might be related to is update order, if you dont explicitly set the execution order value unity chooses a random order (and sticks with it until you restart unity) to execute components, maybe a few frames of lag can creep in if unity executes the worst case order of camera/get height sequence.. We are getting latest water today with the foam so will see what happens

…

On Thu, May 31, 2018 at 5:46 PM, Huw Bowles ***@***.***> wrote: One more capture, this time failing a bit less at running at 30fps: https://drive.google.com/open?id=1Yml_gAO9fsFlzqikgdXC0UQhsghVNITn f9bdede <f9bdede> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#20 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOU9GGDPUvdA3vHmds2p5uPAulX-VCKGks5t35_lgaJpZM4UPvI7> .

[huwb]

Oh that made me realise - we should compare readback request queue lengths. This is the number of frames of latency. I've just added this to the debug GUI on master and merged this into this test branch. The GUI shows the min and max queue over all shape lods.

On my laptop I'm getting a solid [2,2] in both editor and standalone.

As you may have already seen, I have dictated the execution order for all update dependencies - it would be worth checking to make sure these are coming through in your project as well.

[dizzy2003]

we just got latest from our week old version and the latency seems much much better

…

On Mon, Jun 4, 2018 at 5:13 PM, Huw Bowles ***@***.***> wrote: Oh that made me realise - we should compare readback request queue lengths. This is the number of frames of latency. I've just added this to the debug GUI on master and merged this into this test branch. The GUI shows the min and max queue over all shape lods. On my laptop I'm getting a solid [2,2] in both editor and standalone. As you may have already seen, I have dictated the execution order for all update dependencies - it would be worth checking to make sure these are coming through in your project as well. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#20 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOU9GOz6vc8x8HPJalGAejHMNKEymslNks5t5N4kgaJpZM4UPvI7> .

[huwb]

That sounds promising! I'll leave this open for the next day or two let me know if it regresses.