Here it is run on openGL with urhosharp bindings to winforms platform and the water is clear.
Any ideas? Is it a transparent vs. black sort of issue or something in the shader?
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.
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
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:
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.
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.
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.
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.
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.
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.
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.
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.