Shader output depends on other shaders bug

I have the wierdest bug right now and I am a bit baffled about what is happening.

Some shader acts wierd, it seems to be using wrong parameters.

I dig and find that it looks right when some other shader is not used.

I dig even further and find that it looks right when the other shader uses a different technique.

It seems like it’s not related to my code.

So - 2 different shaders. They have no relationship, other than that they write to the same rendertarget.
They have parameters of the same name, but these are applied for each shader individually.
If 1 uses Technique1 the second one works, if 1 uses Technique2 the second one is broken. Nothing else changed.

???

EDIT: To specify the texture read is wrong for the second shader.


Looks like… scanlines … like zoomed in on them or a texture being stretched.

Position.X (and or Y) *2 or uv *.5 somewhere in the code maybe ?
or
Could this be a accumulated effect somehow from alpha or some sort of blending or stretching of a rendertarget ?

Flip off your Antialiasing and see what you get on the bottom one, flip on point clamp or wrap and see what you get. I wouldn’t be surprised if it turned into dots.
Looks like something the light or shadowing is being multiplicatively interpolated improperly on the uv or position coordinates that determines one the other or both.

I’ve seen this effect in doing regular image processing. When you read from uv of a smaller texture to a larger one basically source to destination instead of calculating the source from the destination you get this visual effect.

E.G. say that image A width and height is 100x100 and you drop it onto image B that has width height of 200 200… for example…if you were to find then the texel for the position on B by calculating uv of A * 2. as B is double the size of A.
that would be incorrect…

That is what you would see in your second image above as a result when the card itself performed anti-aliasing on the result.
Edit actually you would see more so dots if one dimension of the image was larger say x or y of image A you would see scanlines. which is what i see in your second image and vaguely in the first. Where the root of it is? just saying mathematically this is how it usually occurs.

Were proper interpolation would be to get the uv of source A from Interpolated positions across B the destination then calculate the uv of a to get the correct texel. texel position B = uv of A found by position B * .5

What is occuring in the first image im less sure but it is possibly the same thing.

Looking at the bush under the trees i see what appears to be the same artifact much less pronounced as in the second image.

The blendmode has no impact and I don’t have any AA.

The shader code is the same regardless of what shader is called before, so that shouldn’t be the issue. It could be an internal issue with samplerstates or some buffers Monogame creates and doesn’t update

Sorry yes alpha wouldn’t have anything to do with it this looks like improper interpolation to me though.

Ah you know what i just thought of something im on a build from a few weeks ago but when i resized the window the back buffer wasn’t changing and the whole thing was pretty bugged up in november… i wonder.
Well i don’t know how to test the actual size of the rendertargets.

Yes, it looks like textures or a sampler state are/is not being updated properly. What syntax are you using in your shader for declaring the sampler and texture? And how are you setting it in code?

That’s a funny effect though, maybe leave it in as a feature :stuck_out_tongue:

Texture2D ShadowMap;

SamplerState ShadowSampler
{
	Texture = (ShadowMap);
    AddressU = CLAMP;
    AddressV = CLAMP;
    MagFilter = POINT;
    MinFilter = POINT;
    Mipfilter = POINT;
};

...

ShadowMap.SampleLevel(ShadowSampler, texCoords, 0);

deferredDirectionalLightParameter_ShadowMap = deferredDirectionalLight.Parameters["ShadowMap"];

Shaders.deferredDirectionalLightParameter_ShadowMap.SetValue(ShadowMap);

Hmm, that’s the tried and tested way. The issue must be elsewhere. If you can narrow down the issue a bit or provide a test case I can do some further digging. I hope that’s doable given the complexity of your program.

How about shader version?
Are both Technique1 & Technique2 the same version (4_0,4_0_9.1,… )?

I could update the deferred rendering solution to the state with the problem (I don’t usually update main branch with “broken” versions), and give instructions how to replicate the problem, but since it is fairly complex in code I don’t know if you want to dig around. But at the same time it’s seems like a hard problem to reproduce from ground up. The shader code is commented though, but I suspect it has something to do with sampler states and potential caching of these.

As far as I could find out though it seems the problem does not lay with the c# code hopefully, since simply changing the one line

from this
Shaders.deferredPointLightShadowedVolumetric.Passes[0].Apply();

to this
Shaders.deferredPointLightShadowed.Passes[0].Apply();

seems to fix the other shader (which is a directional light)
Shaders.deferredDirectionalLightShadowed.Passes[0].Apply();

So depending on whether or not my point lights have volumetric properties my directional light shadows get distorted.

How about shader version?
Are both Technique1 & Technique2 the same version (4_0,4_0_9.1,… )?

The point lights used 4_0, the directional lights use 5_0. Changing both to 5_0 reproduces the error.

I don’t think it has something to do with that but you could try an graphics driver update.

I had an issue once with the nvidia driver. Using the intel graphics card it was all right. After updating the nvidia driver it also worked with the nvidia card. Maybe I have a screenshot from the bug somewhere which I can post at night, when I arrive at home…

It had to do with the dual paraboloid shadow maps of the point lights. One half worked. Using a minus sign and rendering the other half produced something like noise in the shadow render target.

If you point me to a branch with the broken behaviour, I’ll see if I can find the time to investigate.

I’m not so sure about that. I wouldn’t be surprised if it’s MG not setting renderstate right at some point. And I hope it is that, because that we can fix

yes, I agree. I meant my project code, but who knows.

I’m busy with something else right now, but I’ll come back to that for sure once I try to work with the shadows again

1 Like