White LOD borders/lines/gaps when far from center

[nitroman123]

Describe the bug The LOD border are showed when upgrade to a newer version of crest. As Dale told was caused becasue of big tranform. I think its something else cause in the previous version of crest ocean was always 6000+ on x and the same o z axis and i will prove it with a screenshot in my backup files.

Screenshots / video I even try to move ocean very far away and camera again far about 2000 on x,z axis no artifacts Previous Version of Crest Ocean position Camera Position from 0,0,0 (ocean position)

Versions Standard RP Latest 2019(f12)LTS

To Reproduce Dale has the prefab i send him

Platform

• Editor
• Platform Windows

Hardware CPU Ryzen 3700x , RTX 3080

Additional context So after some updates we cant get an endless ocean ? Never had this issue before

[daleeidd]

This is caused by the precision fixes for the grid (searchable in source by using keyword :OceanGridPrecisionErrors). The epsilon value added to the scale of the ocean chunk was suppose to solve these very fine gaps, but it appears not to work very well once the camera goes very far from centre. Increasing the value to 1.1 does, but that is quite a large tweak.

Another option is to use a floating origin which should solve other possible issues when the camera is that far out. Have you tried this?

[nitroman123]

I just tried this , no result still the same problem.

[huwb]

Could we get a reproduction case pushed to a branch.

@nitroman123 are you able to reproduce this issue in one of the example scenes, like main.unity? If so could you paste a screenshot of hte camera transform like you did above?

Thanks

[nitroman123]

Yes of course @huwb, you mean to position the camera far from the center and take a screen? If so tomorrow I will make it!!! I downgraded to an older version and I don't have any problem now. Maybe I will not upgrade to a newer version for now. I forgot maybe to change the ocean renderer script for a while and this keep me safe from this issue. When I change to the last version this happened, in conclusion when I have everything in one scene and getting far from 0,0,0 starts to have a problem and for many projects that have open seas this won't work at all. I will reproduce it tomorrow and upload a screen.

[huwb]

Thank you :)

[nitroman123]

Here I downloaded the latest crest now and reproduce it , hope this helps

[daleeidd]

@huwb I have uploaded the prefab @nitroman123 provided which reproduces the issue. The only changes I have made is adding it to a scene. Take notice of the scene root level transform and the ocean renderer transform (very large values).

Issue #665.zip

And here is a reproducible for the original issue (large gaps), and the subsequent issue (fine gaps). There are four cameras which are named for what issue they are for and how to reproduce:

GridGaps_LOD_256 Large gaps which are visible with LOD resolution 256. Will need to disable both OceanGridPrecisionErrors fixes.

GridGaps_LOD_384 Large gaps which are visible with LOD resolution 384 (might be hardware or OS dependent). Will need to disable both OceanGridPrecisionErrors fixes.

ScaleGaps_Forward_Scale_1.0 Fine gaps which are visible in forward rendering and no vertex scaling.

ScaleGaps_Deferred_Scale_1.00001 Fine gaps which are visible in deferred rendering and 1.00001 vertex scaling.

Precision Issues.zip

[huwb]

Thanks I grabbed the first zip and stuck it in branch fix/cracks-between-tiles . I can see some single pixel holes along the tile boundary (i had to rotate the camer aslightly to see them, on my setup). I will play around with it.

[huwb]

I removed the fudge factors and the cracks disappear. @daleeidd could you perhaps help me break it again - would you be able to help me find an issue with the fudge factors removed? Maybe we can dupe the current scene in that branch and find a new arrangement that breaks it, so we can store a sequence of test situation scenes in the same folder so i can try each one after making changes?

The required data is probably in your above post/data but i'm being chased around the room by a baby so forgive me for dumbing it down. I did try different LOD resolutions but i did not try forward rendering yet. Maybe lets focus on deferred for now.

[daleeidd]

@huwb I have duplicated the scene to show the original issue which is the large gaps in the tiles. I have also added another scene which shows the issues using camera switching (press C).

[daleeidd]

For anyone experiencing this issue and wants a workaround, please make the following changes. Just be aware that these lines were added to fix another precision issue. See #595 for details.

Delete the following lines in Crest/Shaders/Ocean.shader (skip this one for HDRP)

// Scale up by small "epsilon" to solve numerical issues.
// :OceanGridPrecisionErrors
v.vertex.xyz *= 1.00001;

Change 2.000001 to 2.0 for the following lines in Crest/Shaders/OceanVertHelpers.hlsl

// Grid includes small "epsilon" to solve numerical issues.
// :OceanGridPrecisionErrors
const float GRID_SIZE_2 = 2.000001 * i_geometryGridSize, GRID_SIZE_4 = 4.0 * i_geometryGridSize;

[nitroman123]

@daleeidd this works !!!

[daleeidd]

@huwb on fix/cracks-between-tiles with the tiles expand it is fixed for LOD resolution 256 but not 384.

There was still a gap to the very left of the image for GridGaps_LOD_384.

After changing the tlCornerType from SlimXFatZ to Fat it was fixed. EDIT: Looks like this the entire 384 case was either OS or hardware dependent. I switched from MacOS to PC and the 384 case wasn't present. I had to move the camera around in the scene view to reproduce and it was flaky to reproduce with the fixes

GridGaps_LOD_256 had a lot of z-fighting for me where the tiles overlap. But 384 was fine.

[huwb]

Thanks dale - agree that that tile shoudl be fixed to fat if we go in this direction. as an aside i will at some point submit a PR that removes the term "fat" :/.

yeah i also saw zfighting, pretty annoying. its probably the lod blending that starts to different from one tile to the next if the overlap is large, whcih it is for the 256 case. this is a thorny issue and is one reason why i hope that alternative fix that i prototyped will pan out

[daleeidd]

A new solution to solve this problem will be out with 4.8 as per linked PR

[daleeidd]

@nitroman123 are you able to check if latest master or latest release solves this issue for you?

[nitroman123]

@daleeidd nope still got them

[huwb]

thanks for the camera transform. i can repro it here. i have a fix, which increases the tile dilation slightly.

@nitroman123 you could try this change locally: https://github.com/wave-harmonic/crest/pull/746

otherwise we will merge it into master after dale reviews.

i also get sparkly pixels which are drawing as underwater, which can be mistaken as cracks, but are not. the gpu is reporting them as backfaces even though i'm clearly above the surface!?

for some camera angles, they glitter/flash as well. fun times.

[daleeidd]

i also get sparkly pixels which are drawing as underwater, which can be mistaken as cracks, but are not. the gpu is reporting them as backfaces even though i'm clearly above the surface!?

If I change the minRadius in SnapAndTransitionVertLayout to 0.25 they go away. Anything over 0.25 causes these specks. An option is to add another hack like the _ForceUnderwater but for above water. It doesn't solve all cases since these specks can appear within two metres from the surface.

[daleeidd]

The fix has been adjusted to cover the latest case which will be out for 4.9.

[daleeidd]

Except for the specks which is a different issue (faces being incorrectly "flipped").

[daleeidd]

4.9 has been released. Solution ended up being dilating the ocean tiles by an epsilon scaled by distance from zero so hopefully it covers all cases. Let us know if you do find any more cases (hopefully we got all of them).

There are still issues due to VFACE being erroneously flipped which can look like gaps from underwater. They can appear above water too but aren't as noticeable. I'll leave this open for now.

[nitroman123]

I can confirm that is fixed !!! On the first run I saw them but on the second run it wasnt there as far I could go

[nitroman123]

So i found them again... the ship this time is at 0,0,0 this happens at curtain sun position , is there any workaround at least increase a value to get rid of them like before by increasing a value ?

I provide a screen , unity 2019.4.15f

[nitroman123]

@huwb @daleeidd also in main scene with the current values , in this case they are black even at start

[daleeidd]

Do they show up if the underwater is disabled and culling set to back faces?

[nitroman123]

@daleeidd yeap... they still show up even if i dont move the camera in the main scene and not moving the sun at all... i am disappointed ...

[daleeidd]

The screenshot shows the position of the sun, not the camera so I couldn't reproduce. Here is the line where it all happens (same location as before):

o.worldPos.xz = lerp(tileCenterXZ, o.worldPos.xz, lerp(1.0, 1.01, max(cameraPositionXZ.x, cameraPositionXZ.y) * 0.00001));

Increasing the 1.0 value to something like 1.001 might be suitable.

[nitroman123]

in the last screen i didnt move the camera from the original start pos , but even if i dont press i see them. Also the change didnt make anything i still have them....

[daleeidd]

I think I have reproduced this. It looks like this one is due to the normal maps. If you add the following line to the very beginning of the fragment shader, and also change the Clear Flags on the camera to Solid Color and set the Background to red, do you see anything other than black on the surface?

return i_isFrontFace ? 0 : half4(0, 1, 0 , 1);

[nitroman123]

I think i found it and no i dont see any black in the screen now there are no gaps or anything. is there anything i can do to fix it ? I think on unity 2020LTS they are not visible... i dont know why this is happening

[daleeidd]

Thanks. They aren't gaps then. I haven't looked into it deeply, but it is the normals. We'll look into it.

[nitroman123]

thanks man , hope you fix it soon otherwise all the fix about the gaps are fine !!! Well done