I was thinking of releasing this as open source. And I hit an issue that is stumping me so I thought well why not try to take advantage here. If an actual domain expert is willing to put in some time to help me solve this, I'll commit to open sourcing it. FYI if you know what the problem is just by looking at it and turn out to be right, that counts. But I'm assuming I'll need to package this all up and send it to someone directly so they can have the complete code. So I need to pick just one person for that scenario. So to start here is the issue, it's fairly obvious something is being inverted and possibly stretched here. Although verifying against the reference and looking at the wireframes, the meshing and heights all look correct. WW internal data is left handed Z up and their demo renders with GLFW3. So there is some coordinate translation I had to do. Plus it's native meshing works off of transforming all the vertices in the vertex shader. Plus there is a lot of packing uvs into float4 and then unpacking and using against world coordinates. So there could be some incorrect swizzling going on. But... I also have a version using a different meshing system where it looks mostly correct. It's the same core ww logic as all the sampling is abstracted out. So that tells me a lot is probably right. And WW uses world positions for everything here. So I'm thinking/hoping that I'm missing something quite simple. The WW meshing is they hand you single indice/vertice buffers when you create the quad tree, which contains 16 unique patch meshes. Per frame you query the quad tree with camera matrices and get back indexes into the buffers and a scale/offset. So culling is baked in here. It was designed to work with draw indexed, and I'm using DrawMeshInstanced which is the closest equivalent in Unity. I'm also using NativeArray's so I can just pass pointers directly to native and have it fill out the nodes there. It's all very performant although some final optimizations on the Unity side to be done (fill out DrawMeshInstanced matrices in jobs). I need to get this rendering issue fixed before final polishing. This is in HDRP. The hlsl to do all the displacement and sampling for normals/gradients/etc is all separated out into helpers, so it's easily adaptable to any render pipeline. I did most of the integration using Better Shaders. And then moved to a low level vert/frag setup for the final frag shader. As the actual shading is all world position based and calculating light/reflections/specular/fresnel directly. I'm doing custom sky/scattering anyways so this low level approach fits my context well. If you wanted to really integrate this well into the normal HDRP shading flow I strongly suggest Better Shaders. Mainly due to all the sampling a Shader Graph port would be some work. WW supports DX11/12 and Vulkan. My native plugin hardcodes DX11 resource types. It also uses a low level DX11 CopyResource due to some limitations with Unity's api in using external texture2d arrays. But making it work with DX12/Vulkan would I think be fairly straight forward. I might end up open sourcing this even if I don't get help. But helping me solve this will ensure it happens, as just working with someone will force me to package it up cleanly. Also for those that don't know and most won't unless they have worked with FFT water. Every open source solution you will find out there is pure crap in terms of being usable in an actual game. The best I found did 200+ compute dispatches per frame. FFT water takes some very specific optimization techniques like butterfly and others and is non trivial. And unless you do those it's worthless. That's just the bar now days. Plus good LOD is non trivial. Nvidia's implementation is amazingly performant. The actual FFT generation is barely a blip on the gpu. The heavy work is all in the shading. Which also means it's easily tunable performance wise. The quad tree system also allows full control over mesh density and has as far as I can tell infinite LOD levels. The default is 15. It's a concentric geomorphed LOD that is based on distance from camera.