Black ocean from certain viewpoints about crest

[dizzy2003]

I think I fixed it. (Havent tried your latest changes though) you need to change the tag to "LightMode"="ForwardBase" with LightMode=always as you have now unity thinks its not doing any lighting in the shader so isnt setting the _WorldSpaceLightPos0 value, so its set to whatever value for what was drawn previously, so if it was a forwardAdd shader or something then its value might be a point light position.

…

On Mon, May 28, 2018 at 10:24 PM, Huw Bowles ***@***.***> wrote: Thanks for that! Yes that helped a lot, although I'm a bit confused by what I saw: Unity has passed in a light position instead of a direction into the shader. Are you guys using a light type that is not a directional light? This should be fine normally of course, but my code made the (bad) assumption that it was always a directional light. The issue was i was assuming this would be unit length, and doing some exponentiation on it, which made it blow up to infinity when its a large world position vector. I now detect if unity has given the shader a position instead of a direction and normalize appropriately. Could you please try latest? I'm a bit surprised by this. I am half-expecting that there is actually a deeper or secondary issue at play here. However the stuff i described above is a legit issue and that is generating the INF values that I'm seeing, so I'm definitely interested to hear what happens with that fix! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOU9GPlvB6LOqj_StMruDjgtCulpajsoks5t2-x8gaJpZM4UPrN4> .

[huwb]

Thanks Midda! Thats pretty severe! I have not seen that behaviour before. I tried a few things here to find repro steps but did not get too far.

On clamping, i yesterday found a couple of unclamped bugs which caused bright fireflies and triggered bloom. You said you have latest but thought I'd mention it a I pushed it 12hrs ago. 26a2d7b . This issue looks more severe though.

I assume this is happening in editor - let me know if not though.

Thanks for trying the debug flags. Could you try disable transparency? I've added another debug flag "Debug Disable Multiply by LightColor0" - with this flag, everything involved in computing the ocean colour is disabled.

I've also added another debug flag "Debug Disable Shape Textures" - this will stop it from touching the shape textures, which i suspect are messed up for some reason.

Along that line of thought, it could be useful to enable the debug GUI and see the shape textures. Its not in the core crest files by default (but maybe it should be..) but its in the example content here: https://github.com/huwb/crest-oceanrender/blob/master/src/unity/Assets/Crest-Examples/Scripts/OceanDebugGUI.cs

All of the above would be interesting to see, but there is a more powerful debugging tool which will give me a complete view of the render and should direct me straight to the problem - a renderdoc capture. this would capture some data used in the frame (geometry, textures), so you may not want to post it online. if you are up for going down that route, the steps are:

• install renderdoc (freely available)
• enable shader debug info: "Compile Shader With Debug Info (D3D11)" on material. this will add overhead, be sure to turn this off afterwards.
• in the Game view dropdown menu, select Load Renderdoc
• press play and repro the issue, then click the little Renderdoc icon at the top of the Game view (see tooltip)
• renderdoc should open. right click the capture thumbnail that should appear and select save, and email it to me.

thanks!

[Midda-C]

Emailed that through. Let me know if I can do anything else to help track this down!

[huwb]

Thanks for that! Yes that helped a lot, although I'm a bit confused by what I saw:

Unity has passed in a light position instead of a direction into the shader. Are you guys using a light type that is not a directional light? This should be fine normally of course, but my code made the (bad) assumption that it was always a directional light. The issue was i was assuming this would be unit length, and doing some exponentiation on it, which made it blow up to infinity when its a large world position vector. I now detect if unity has given the shader a position instead of a direction and normalize appropriately. Could you please try latest?

I'm a bit surprised by this. I am half-expecting that there is actually a deeper or secondary issue at play here. However the stuff i described above is a legit issue and that is generating the INF values that I'm seeing, so I'm definitely interested to hear what happens with that fix!

[Midda-C]

Our world is lit by a directional light, but we do have other lights in the world (e.g. campfires have point lights on them).

So I just tested this by disabling the objects in my scene that have point lights on them, and yep, the issue disappeared.

I grabbed latest, and it mostly addresses the issue, but I can now see that when the point light sources are in view, the ocean tiles seem to be tinted by the point light colour, even though they are quite far away. It usually affects all the ocean tiles in view, but at some viewpoints, you can see a sharp line where a few tiles remain unaffected by the point lights (like what is seen in the example 3 pic).

[Midda-C]

Yeah, just changing to ForwardBase with no other changes fixed the issue, including the odd tinting of the tiles to the point light colour. It does also mean that point lights have no influence on the ocean surface whatsoever. While that would be nice, I guess that's irrelevant to this bug, and is more something for the Dynamic Lighting issue (is other light types are even in the scope at all).

[huwb]

Nice find!! This actually fixes #15 as well in one fell swoop. It looks great to me here so I pushed it.

I kept the previous change i did, which at least would support one big point light in the world. Regarding supporting multiple lights, I would consider it in-scope but I'm not geared up to comment on what it would take/if its possible etc. Do you have requirement for this, such as local lights at night time or such?

Thanks a bunch!

[dizzy2003]

To support point lights you do the same shader again with a tag of forwardadd, now you calc the lighting uisng the point light info, and output a pixel that is added to the result from forwardBase. I will do it at some point if you dont beat me to it. The mesh is rendererd multiple times depending on how many lights overlap it. thats the downside of using forward over deferred. Fortunately your method of building the wave heights as a separate texture is a big win here not having to recalc the vert heights.

…

On Tue, May 29, 2018 at 6:40 PM, Huw Bowles ***@***.***> wrote: Nice find!! This actually fixes #15 <#15> as well in one fell swoop. It looks great to me here so I pushed it. I kept the previous change i did, which at least would support one big point light in the world. Regarding supporting multiple lights, I would consider it in-scope but I'm not geared up to comment on what it would take/if its possible etc. Do you have requirement for this, such as local lights at night time or such? Thanks a bunch! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOU9GFN25wukFsfLmiPS5oCq8sOps1etks5t3QmQgaJpZM4UPrN4> .

[huwb]

Ah gotcha. Interesting!

The ocean rendering as tiles is a huge win here as well - as many of the tiles will probably only end up rendering once if there are just a few local point lights.