UrhoSharp: HLSL Shader issue for water on D3D11 paints water black

I3DB · February 20, 2019, 3:44am

The difference between these two, codewise, is one runs the hlsl water shader, and the other the glsl water shader.

When run on D3D11 water is black.
PNG

Here it is run on openGL with urhosharp bindings to winforms platform and the water is clear.
PNG

Any ideas? Is it a transparent vs. black sort of issue or something in the shader?

EDIT:
There is a solution provided at end of this thread. To test that proposed solution, used the 1.7 urho3d version urhosharp distributes and tested on D3D11 win 10 x86 platform, and this did NOT solve the problem, nor provide any visible change. Water still painted black. Not solved.

Sinoid · February 20, 2019, 3:59am

Please enumerate the machine specifications.

Also, the render is correct but the blend-states or buffer management are all kinds of messed up. Too many things can make this happen - if an AMD chip though, you’re probably sunk on Win10 in GL.

Leith · February 20, 2019, 6:45am

This is very strange - I suspect the issue is the refractColor term, but the code appears to have the same output for glsl and hlsl. I mean, you’re getting reflections, so it’s not the fresnel term, and it’s not the reflection term, it has to be about refraction term by pure deduction. That’s being sourced from an environmental map, so it looks like the problem is narrowed down to a failure on environmental probe to render to (I assume) a cubemap. This is boilerplate code, it should “just work”. I agree, we need to see the hardware capabilities to figure out what’s going wrong.
Also, I kind of like it - the water looks murky, it has more character than the “working” version.
It’s absolutely not correct, but it looks nice

I3DB · February 20, 2019, 4:14pm

Ran the UWP on two hardware platforms, but both running Win10. One is an intel powered desktop, the other platform is a hololens.

I’ve come across a number of anamolies in addition to this. For instance, shadows not working on hololens/UWP. Another instance is the Outline.HLSL that was put up on another thread, where it was not working correctly.

At first I thought this was just hololens, but now have concluded it is D3D11 and the hlsl shaders.
Something is not correct here, and it’s affecting numerous HLSL shaders.

So here in this thread, I point out Water, Shadows, Outline … all working INCORRECTLY on D3D11 platforms.

For shadows, here is UWP sample

Here is the winForms (opengl) sample

I3DB · February 20, 2019, 4:19pm

For hololens, here is a hardware breakdown.

For other platform:
Processor Intel(R) Core™ i7-4770S CPU @ 3.10GHz, 3101 Mhz, 4 Core(s), 8 Logical Processor(s)
Adapter Description Intel(R) HD Graphics 4600

Not sure what other info is useful. Let me know and I’ll get it.

Best for me would be advice on how to troubleshoot further. This issue is readily repeatable for me … just don’t know what to look for next … ???

I3DB · February 20, 2019, 4:29pm

Is that a statement of calm defeat? Not sure what you mean specifically.

I3DB · February 20, 2019, 4:39pm

Also, I could not get a NoTextureMultiply to work. The blend state always errors with this error:
System.Exception: Failed to create blend state (HRESULT 80070057).

The Decode: E_INVALIDARG : One or more arguments are not valid ( 0x80070057 )

I saw this error on another issue, where the second UV map was missing. @lezak pointed out the underlying issue, the text of the message was different though, and it pointed out missing vertex elements, but this one doesn’t have that just the blend state failure.

The result is shown, the NoTextureMultiply on UWP:

But on winForms looks like it works, and no errors:

I suspect there is something going on that is common amongst all these D3D11 shaders, such as blend state. But I have too little experience to know where to look next.

I3DB · February 20, 2019, 4:43pm

I thought that too, and perhaps it is. But the sample setup uses a reflection camera and a reflection plane, and there is nowhere an environmental map is specified looking through the material, technique and shader files. Also, if I mix a couple of the samples, for instance mix the animating scene with the water sample, the floating cubes from the animating scene are visible in the reflection, so conclude an environmental map isn’t used.

No … I’m wrong. Actually environment is used as described by this comment. This also explains another reason porting the water sample to a stereo application has been so hard. As per the sample code, I’ve only been creating a single refraction camera, but suspect I need two, and they must be working in stereo mode, so the refract pass might (hopefully) get it correct.

When viewed without the nice reflection, for instance, move up and over the water, it just turns black and loses it’s ‘character’. On hololens, this is even more apparent. Though, using a BlueTransparent material looks sort of nice, but there is no rippling of the water.

The overall goal here is to replicate the c++ functionality on hololens using urhosharp. And replicate it perfectly. This is one of the samples that I’ve failed on thus far.

I3DB · February 20, 2019, 4:49pm

Here’s another sample where the water isn’t painted black and it seems to work fine:
UWPWaterNotBlack

This sample just assigns the water material to a sphere.

lezak · February 20, 2019, 6:46pm

I’m unable to reproduce Your issuses on ‘normal’ (c++) version of the engine (running on dx11, win10), so I’ve downloaded urhosharp samples and I can see them when running on UWP, so the problem is on the urhosharp’s side.

I3DB · February 20, 2019, 6:51pm

Are there any clues you could give me on how to narrow this down in the urhosharp implementation?

Where to look, what to look for? It’s just a c# wrapper, so if I could gain enough insight on the data flow for this issue I might find something.

Modanung · February 20, 2019, 7:28pm

Have you tried copy-pasting the shader file from the Urho3D repository or are they identical?

I3DB · February 20, 2019, 7:51pm

As I’ve gone down this craggy road of shader exploration, mostly I’ve found what is delivered with urhosharp is identical. In some cases they are different, but also renamed in those cases.

I purposely copied or reviewed differences, between water.xml material, water.xml technique and water.hlsl. There is a single difference found, on the water.xml material file, where the water feature sample has changed one parameter used for the water feature sample called basic techniques where a custom material has been defined. But currently the same on urho3d and urhosharp sites.

github.com

xamarin/urho-samples/blob/b72d055a424d0e6be825c0239683c225d29ee723/FeatureSamples/Assets/Data/Materials/Water.xml#L7


<material>
<!-- The water example will assign the reflection texture to the diffuse unit -->
<!-- The engine will automatically assign the refraction (viewport) texture to the environment unit during refract pass -->
<technique name="Techniques/Water.xml" />
<texture unit="normal" name="Textures/WaterNoise.dds" />
<parameter name="NoiseSpeed" value="0.05 0.05" />
<parameter name="NoiseTiling" value="50" />
<parameter name="NoiseStrength" value="0.02" />
<parameter name="FresnelPower" value="8" />
<parameter name="WaterTint" value="0.8 0.8 1.0" />
</material>

Doing this is when I found that whatever is in CoreData.pak is always chosen when there. So when I edited various hlsl files I had, those were always ignored in favor of choosing the unedited original in CoreData.pak. I had to rename techniques and shaders to get them to be loaded.

The urhosharp project forked urho3d 1.7, and those coredata shaders haven’t been changed in 3 years.

So for instance the urhosharp water.hlsl shader, is identical to the current urho3d shader.

In a loosely related issue, I found a missing hlsl custom shader, and rewrote it from glsl and had fairly good success, but my rewrite wasn’t quite correct, it seemed to change when moving camera from left to right in a stereo application. Eventually I found there was a D3D11 conversion from glsl that I’d missed.A pattern for it shown in the water.hlsl shader. The cbuffer pattern specifically. I put this into the custom shader rewrite and it fixed it. This particular pattern is briefly mentioned, but not in a useful way for this on microsoft’s page about hlsl conversion from glsl.

I3DB · February 20, 2019, 8:43pm

Maybe @Egorbo or @migueldeicaza will jump in and offer a direction of exploration to get this issue fixed?

cosar · February 20, 2019, 11:53pm

@I3DB Are you using the latest version or 1.7 release. I submitted a bug report sometime ago (#2232) that was creating a similar issue. I think it is fixed on the head.

I3DB · February 21, 2019, 1:21am

Using this latest github version of urho3d that downloads on clone.

And assume this is the issue 2232.

The file that I’m using has the changes in that commit. If you’re saying these introduced changes caused the issue, then it’s not been fixed.

I’m using urhosharp, but will revert that change and see what happens.

Edit:
This thread has been locked, but can still edit the prior posts. The issue is not solved by this change. It does seem like it’s the spot on issue, but perhaps the Urhosharp guys did some other changes. Continuing to test this, but so far have found it has no effect by reversing the changes in the commit highlighted in the #2232 closed case.

Edit Next:
The reason it has no effect is because on the testing I’ve done so far, the multisample test, or the need for multisample processing, isn’t set in the code I’m executing. Haven’t tracked down the reason why. That bug was opened for the case where multisample > 1, and apparently it failed and treated multisample as false resulting in water being painted black. In my case, it is false and doesn’t incur the failure, but the end result is the same.

However, this bug case gets right to a spot which can be used to track back the issue.

Edit Final:

Haven’t solved the issue at all.

The bug referenced by @cosar is for a specific case that isn’t happening on the platforms I’m testing.
Additionally, the urho 1.7 branch I’m using has additional code related to the urhosharp implementation of UWP and Hololens. For example compare this urhosharp urho3d file, with the urho3d C++ file, and search on UWP to see some of the changes, or note they differ by over 100 lines. But @lezak is correct in that it’s an urhosharp problem.
I did back out the changes as per the bug fix, but it has zero effect on the cases I’m looking at, running on both an x64 and an x86 win10 UWP platforms and one is a hololens. Both behave identically meaning both paint water black in this case and neither produces shadows.

Since this issue is closed here, I’ll try to keep it updated on xamarin once solved.

cosar · February 21, 2019, 1:40am

That is the issue.
The repository that you indicated does not contain the fix for issue 2232. I think the fix is in this commit: https://github.com/cadaver/Urho3D/commit/b00fab9b2850031bd6b22316d8df26419a16efca (you can easily apply it manually)

Modanung · February 21, 2019, 11:08am