Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 01 Sep 2011
Offline Last Active Aug 03 2016 05:57 PM

#5038215 Specular Control

Posted by on 01 March 2013 - 06:46 PM

Ah, so the shadows are supposed to be added into the lighting buffer output apparently. Since I wasn't the one who set this up originally I hadn't really done much research into the compositing stage of shadows, so I just assumed it was normal to add them in during the final gbuffer pass. Thanks for the help guys.

#5038171 Help me to make work D2D with D3D11

Posted by on 01 March 2013 - 04:29 PM

I suggest you enable the directx debug runtimes and fix all the errors it reports. There are several of them

#5037778 Help me to make work D2D with D3D11

Posted by on 28 February 2013 - 04:36 PM

Your LightShader::RenderText method doesn't appear to draw the contents of the shared texture to screen. It looks like it sets up for it but never actually does the draw call.

#5037532 Specular Control

Posted by on 28 February 2013 - 04:04 AM

How do you do that with a deferred renderer? Ambient and diffuse are precombined.

#5036020 Transparent voxels

Posted by on 24 February 2013 - 01:08 AM

I had the wrong blend mode. Halos are fixed now. Can we use premultiplied alpha to get rid of the grass-on-grass darkness? Or does that not work?

Edit: Another question: will this work for glass and other transparent blocks without looking terrible?

#5036006 Transparent voxels

Posted by on 23 February 2013 - 11:34 PM

-- Drawing your grass with additive blending and no depth testing, and a write mask of rgb=false, a=true (so that only the alpha channels are summed).

-- Drawing your grass with depth-testing and alpha-testing (no blending), and a write mask of rgb=true, a=false (so that only the color channels are written).

First pass state:
descBlendAlphaOnly.RenderTarget[0].IsBlendEnabled = true;
descBlendAlphaOnly.RenderTarget[0].RenderTargetWriteMask = ColorWriteMaskFlags.Alpha;
descBlendAlphaOnly.RenderTarget[0].SourceBlend = BlendOption.SourceAlpha;
descBlendAlphaOnly.RenderTarget[0].SourceAlphaBlend = BlendOption.SourceAlpha;
descBlendAlphaOnly.RenderTarget[0].DestinationBlend = BlendOption.One;
descBlendAlphaOnly.RenderTarget[0].DestinationAlphaBlend = BlendOption.One;
Second pass state:
descBlendColorOnly.RenderTarget[0].IsBlendEnabled = false;
descBlendColorOnly.RenderTarget[0].RenderTargetWriteMask = ColorWriteMaskFlags.Red | ColorWriteMaskFlags.Green | ColorWriteMaskFlags.Blue;
Are these correct?

This is the result I'm getting:
RuinValor 2013-02-24 00-33-06-95.png

I have no alpha testing on the first pass and the 2nd pass uses this:
if(color.a == 0.0f)

#5035979 Transparent voxels

Posted by on 23 February 2013 - 08:48 PM

Is there a way to properly render layered transparent objects when you can't do depth sorting? Since the terrain is all built up into 2 vertex buffers per region (1 for solid blocks, 1 for transparent blocks), we can't do the typical depth sorting. Are there any alternatives?

This is what its coming out like right now:

RuinValor 2013-02-23 21-42-37-02.png

#5034909 Cascaded Shadow Map Issue

Posted by on 21 February 2013 - 02:21 AM

Increasing the shadow bias fixed the remaining issue:

RuinValor 2013-02-21 03-13-26-14.png

So it's pretty much working now. I'm getting just about every other problem possible though. Peter panning, jittering when moving, shadows disappearing when the object is behind the camera, and some weird issue where a triangle of shadow pops in on the right hand side (you can see it in the screenshot). The last two issues are particularly problematic though.

Edit: Switching to our old ESM shadow filtering (instead of PCF from the sample) mostly fixes issues 1, 2, and possibly 4. 3rd one is still something I'd really like to fix.

#5034872 Cascaded Shadow Map Issue

Posted by on 20 February 2013 - 10:22 PM

I can't get the reconstructed position to even come close to the position_ws_VS.  I found something else out, however, while reading MJPs blog about reconstructing linear depth.  The GetCorners function in SharpDX returns the corners in a different order than XNA.  So I switched the indexes around and now the first shader output seems a little closer to what it should be (at least I think so...).  It no longer rotates with the camera, but it's still moving with it:

#5034341 Cascaded Shadow Map Issue

Posted by on 19 February 2013 - 05:35 PM

Heres the video of what the test shader is doing:


#5033931 Cascaded Shadow Map Issue

Posted by on 18 February 2013 - 04:44 PM

Here's how I do the calculation:
world = Matrix.RotationYawPitchRoll(Yaw, Pitch, 0);
world.TranslationVector = pos;

Matrix.Invert(ref world, out view);
The world matrix is sent to the shader as the InverseView matrix. As for the coordinate system, we originally used XNA and then switched over to SharpDX, so to avoid having to change a ton of stuff, we stuck with the XNA system where Y=up and we use right-handed matrices.

#5033686 Cascaded Shadow Map Issue

Posted by on 18 February 2013 - 03:47 AM

Those are shots from just the rotation of the camera. So I guess that means the InverseView is broken...? Not really sure how that can be the case, there are other places where the InverseView is used and they don't have any problems.

#5033542 Cascaded Shadow Map Issue

Posted by on 17 February 2013 - 04:23 PM

The sampling Y position is already inverted. If I remove it, the shadows seem to look even weirder.

Heres what it looks like with 1 cascade with a recognizable object in the scene:

RuinValor 2013-02-17 17-12-36-25.png

And again, with the camera moved to the side a bit (the light position hasn't changed):

RuinValor 2013-02-17 17-12-48-57.png

Edit: I should probably note, those lighter colored shadows directly beneath the blocks are static shadows, completely unrelated to this. Ignore them.

#5033329 Cascaded Shadow Map Issue

Posted by on 17 February 2013 - 04:39 AM

Hmm, no luck. I tried the original code and it came out the same.

#5033321 Cascaded Shadow Map Issue

Posted by on 17 February 2013 - 04:18 AM

That part of the code is actually changed from the sample. There's a comment on MJP's blog where a user uploaded a changed ComputeFrustum function that is supposed to reduce jitter that occurs when the camera is moving. The code is here: http://pastebin.com/Yn5SVPUP. Is that code actually wrong? Should I just use MJP's original version instead?