Feature/local water bodies

[huwb]

Status: Ready to merge

What & why:

An often-requested feature is to use Crest for local bodies of water (limited in area), rather than filling the whole world. I refer to this as 'local' as opposed to 'global'.

It turns out Crest is able to do local water well \o/ by adding the following mechanisms.

How:

• Sea level can vary instead of being globally fixed - extend ocean depth to add sea level value - in this PR
• Localised gerstner waves - Local gerstner waves #440 (merged)
• Clipping extensions
  • 'Include area' variant of clipping shader - Invertable default clip state #558 (merged)
  • Order inputs to enable including before clipping - Sort ocean inputs based on render queue #444 (merged)
  • Default/base clipping state - clip nothing vs clip everything - Invertable default clip state #558 (merged)
• WaterBody component which demarcates an area in the world. If present, OceanRenderer will intersect all ocean tiles with all WaterBody's and turn off any tiles that don't intersect with a body, meaning they'll never get processed/submitted/rendered. - WaterBody script for tile culling #549 (merged)
• Any water surface below the terrain are not drawn through normal GPU depth testing / z buffering (works out of the box)
• Shadow data and underwater effect take sea level offset into account - in this PR . Curtain is deprecated and no attempt is made to extend it to support this.

Authoring all this is a bit of a brainful / juggling act, so i've also experimented with adding a wizard (Window/Crest/Create Water Body) which allows the user to place a water body, configure some settings, and it will create the setup. The resulting setup can be tweaked, moved, duplicated. - #561 (merged) . UPDATE: The authoring has been made much easier and I have now removed this wizard.

Testing:

There's a Lakes scene added. It's not representative of what would be pushed, its just for testing.

Issues:

• The LODing system scales/adjusts detail based on viewer altitude, measured relative to sea level. This works with one sea level, but breaks with multiple sea levels, and as a result water bodies above/below sea level are starved of detail. I'm not sure how to drive the LODing, I could imagine adding C# to detect when camera is near different sea levels and adjust as necessary. This wouldn't work though if the sea level is generated by geometry (like a river proxy geometry), in which case sea level would not be known to C# (unless it read the geometry on the CPU i suppose..). UPDATE: addressed this problem by driving LOD from height above water, and having this vary smoothly over time. It sort-of works but not sure if it will hold up.
• Currently sea level is written at same time as cached depths. Cached depths use 'min blending', and since its in the same pass, sea level also has to use min blending, and theres a hack to deal with this which has a side effect that secondary sea levels have to always be greater than the global sea level. This is a bit rubbish/confusing and can probably be fixed by rendering depths and sea levels separately, at the cost of more draw calls. UPDATE: I've left it as is for now. Due to how the Register scripts are written / inputs are registered, i think this would require a new 'LodData' type for sea level offsets. Maybe we should just live with the constraint that water bodies must lie above sea level, so sea level needs to be lowest water level. Sea level can be changed at runtime which might help as well.
• WaterBody doesn't have correct bounds, its currently hacked. Need to convert OBB to AABB.
• Probably need validation to warn user if they have local water bodies but don't have clipping set to clip all. UPDATE: I'm not certain if this is a valid warning. Leaving for now
• Shadow data needs to take into account sea level offset
• Having to give the materials for gerstner & clip on the local water body wizard sucks. Should we create material assets for them?
• Can sea floor depth render target be single channel unless sea level offset needed? UPDATE: Added a settings object for sea floor depths. Defaults to on, but can be switched off by advanced users to save a bit of perf.
• Placement is awkward (creating a plane proxy object), makes it difficult to see what is happening. Needs massaging. UPDATE: Wizard removed

Note on materials: There isnt a good mechanism for varying water materials/appearance. We could probably add a mechansim to assign an ocean material to each WaterBody, but this wouldn't help in the case of rivers which would need smoothly varying & connected attributes across water bodies. I think this is a future fish to fry. UPDATE: the simple approach merged in #902 . A more fancy approach would need to create a separate lod data for material blends, or such.

[magenta404]

Yeah both could work, that sounds good, ill let you play around with it then.

Any ideas yourself?

[huwb]

Any ideas yourself?

Not sure, its always tricky.

Wondering if we should try make it textured or just make it grayscale or a grid pattern or etc. Textured will always be more professional/impressive etc but can be tricky to make look good.

For the asset store versions we have some pbr textures used in the PirateCove scene which we have permission to use, maybe they are useful. Maybe a good approach is to take pirate cove and resculpt it into a different scene with a lake and a river, and could sprinkle in the rocks etc, and maybe can look good that way. The textures and assets would not be usable in BIRP (would not be pushable to MIT licensed git i dont think) but thats prob a secondary problem at this point.

Other ideas.. Not sure if theres a free asset we could get away with using: https://www.turbosquid.com/Search/3D-Models/river

Thought maybe this had a river but does not look like it: https://www.youtube.com/watch?v=iV-224nMwN8&ab_channel=Unity

I guess a last option would be to put some funds towards contracting an artist to look at it. This would be good but i dont have one in mind so we'd have to ask on the discord or find one online, i think theres websites for this.

I'll keep thinking about it.

[magenta404]

We can do both. Having basic scenes like boats.unity which have the flexibility to be purely instructive are useful. And it is good to have a scene for built-in since it is used for evaluation. Then we can keep fancy scenes like Pirate Cove for UAS only.

[huwb]

Thanks for the notes.

Shadows fixed now

Data reverted

Attempt at docs done

[huwb]

One area that might be an issue is when the camera is up high. The lack of mesh density can cause noticeable degradation - especially with the added normals. But can be solved by giving splines a decent margin so rivers don't disappear etc.

Agreed

[huwb]

@daleeidd i think i've addressed everything, re-requested review

[magenta404]

Nice work. Just a few review items. Mostly minor ones.

I've enabled docs for this branch in case you wish to review your changes: https://crest.readthedocs.io/en/feature-local-water-bodies/

[huwb]

I think that may be everything addressed, rerequested review. Thanks for those

[magenta404]

Great work on achieving an important milestone! Works well and no issues that I experienced.

[huwb]

Awesome thanks for all your help!