Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 27 Jan 2014
Offline Last Active Jul 13 2016 10:38 AM

Posts I've Made

In Topic: Periodic shadow mapping artifacts

13 June 2016 - 08:48 AM

I'm going to bump this on the off chance that somebody who haven't already seen it would have any ideas.

Sorry if this isn't allowed.

In Topic: Are there any ways to eliminate / reduce the seam artifacts where dual parabo...

06 June 2016 - 05:20 PM

Hm I don't think that is what's causing the seams though. It isn't that things line up incorrectly between the hemispheres, but rather that a line of "nothingness" (the depth clear value) end up around it. The most obvious cause I can imagine is that the texels at the very edge of the projected circle blend together with the cleared outside. Since the shadow map is circular there will always be this "invalid" outline, so that's where I was thinking that maybe you could try to project a bit beyond a hemisphere and then only sample the middle 95% or something, such that you get a more proper "clamping" behaviour at the edge texels.

Another thing I thought of just now is that perhaps it would be better (if more expensive) to perform the paraboloid space transform in the pixel shader instead of the vertex shader? I imagine there will be more edges in the vertex shader approach, especially if the geometry isn't that detailed. I'm not sure if it would fix this particular issue though but it could be worth a try.

In Topic: SampleLevel not honouring integer texel offset

06 June 2016 - 01:08 AM

One way to make sure that you use the right version is to not use an import lib at all, and instead manually call LoadLibrary/GetProcAddress to get a pointer to the function you want to use from d3dcompiler_47.dll.

Ah yes, that should work; there are only two functions being imported from there so should be an easy thing, thanks.


I probably should see about making the switch and look further into what that will entail in regards to older OS support one of these days though.

In Topic: SampleLevel not honouring integer texel offset

05 June 2016 - 10:00 AM

Hah, yeah I suppose I really should try for that sooner or later.


What's blocking you from making the move to the Windows SDK?

Mainly a somewhat large pre-existing codebase and laziness, but also the need to support Windows 7 and Vista. I'm not sure whether upgrading to the Windows SDK would affect that, though I do recall reading that this was more for Windows 8+ (ie DirectX 11.1 and above)? I may very well be wrong there though.


As your linked-to article says however:

Your application uses use XAudio2 and supports Windows 7 systems.

This would also be a problem. Not an insurmountible one though as I don't have that much audio functionality yet; it would probably be possible to change to another library without too much of a hassle.

In Topic: SampleLevel not honouring integer texel offset

05 June 2016 - 03:40 AM

Can you compile the following shader and paste the DXBC output and compare it to what I get?

Certainly. As you can see, there is no mention of any offset coordinates, neither does it use the "aoffimmi_indexable" postfix:

dcl_globalFlags refactoringAllowed
dcl_sampler s0, mode_default
dcl_resource_texture2darray (float,float,float,float) t3
dcl_input_ps linear v0.xy
dcl_output o0.x
dcl_temps 1

mov r0.xy, v0.xyxx
mov r0.z, l(2.000000)
sample_l(texture2darray)(float,float,float,float) r0.x, r0.xyzx, gTex.xyzw, gSampler, l(0)
mov o0.x, r0.x

The array texture is bound to register t3 and is named "gTex", while the sampler is named "gSampler" and bound to s0 so I guess those add up with the differences towards your output.



Version 43 of the compiler is pretty old now, the latest Windows SDK contains Version 47.

Yes I know, perhaps I should try to replace it. I've been using it since it's the version that is included with the DirectX SDK from February 2010 which is the one I'm using. I recall trying to upgrade to the June 2010 version gave me troubles about two years ago so I settled for downgrading. Is there any way to maybe just replace the HLSL compiler? It would appear it simply loads d3dx11_42.dll (yes I was wrong and it isn't even using version 43 :rolleyes: ) at runtime so I guess I could take a newer version, rename it to that and drop it in my program's working directory. I'd rather not have to rename it though.




Based on personal experience do not rely on the offset parameters. Broken drivers, broken hardware; missmatching results across vendors. It's better to just apply the offset yourself to the UVs.

Hm, I see. Yes, I suppose that wouldn't be too big of a hassle; I did change it for that successfully and I guess I will stick to that in the future as well then. Thanks for pointing it out!