Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 15 Aug 2005
Offline Last Active Yesterday, 11:19 AM

Posts I've Made

In Topic: When you realize how dumb a bug is...

12 July 2016 - 08:54 AM

So I was switching over one of the libraries i use from a prebuilt dynamic DLL to a static library (that I was pulling and building/linking against directly).  Everything compiled and linked successfully, but whenever I ran it I would get crashes deep inside standard runtime libraries!  I was building and rebuilding and changing settings and trying to figure it out for a couple days, frustratingly to no avail.  Finally (I should have done this sooner), I started following the include links in the IDE and noticed that it was still including the old precompiled headers.  The functions all existed so I didn't get any errors during build, but a lot of the signatures and parameters had changed so it wasn't calling things correctly!


Grr, note to self, when changing library versions, just rename the old directory (or delete it entirely) to make sure it's not getting included by accident.  XD

In Topic: Retrieving World Position in Deferred Rendering

24 June 2016 - 08:09 AM

It's a little hard to tell from the image, but it looks like you are using face normals to do the lighting calculation.  If it's a depth precision issue, what are your near/far values for the projection matrix?  Try scaling them to just fit your scene and see if that fixes the issue.  Since the depth will be distributed between near/far, the smaller those values are, the more precision you'll have.  If you have a far large view distance, then you sacrifice precision for distance.  If it's a normals issue, check what normals you are writing to your deferred buffer.  Make sure you're storing the normals per pixel, not per vertex/face.

In Topic: Retrieving World Position in Deferred Rendering

23 June 2016 - 02:37 PM

Correct, I probably could/should set it up to use the depth buffer itself, but so far I'm writing to a separate render target for the depth.  It started out because I was packing information into my g-buffers, but at this point it is just a separate render target that I write the depth to.

In Topic: Retrieving World Position in Deferred Rendering

23 June 2016 - 08:16 AM

Are you sure you need the world position?  If you store the linear depth, then this is the view space depth (the distance from the camera).  When rendering your lights, if you render a quad (or an extra large triangle) and use the corners as the view vectors, you can then multiply the view vector per pixel by the depth to get the view space position.  With this, you can do all your lighting in view space, just transform your lights from world space to view space, then the lighting equation remains the same.


Here's the code code to calculate the linear depth in the pixel shader, this is the first shader that stores all the info into my g-buffers:

outputPixel.depthBuffer = (inputPixel.viewPosition.z / Camera::maximumDistance);

This just takes the view space position, takes the depth of it, then converts it to the [0,1] range.


Here's code to use that depth to get the view space position:

float3 getViewPosition(float2 texCoord, float depth)
    float2 adjustedCoord = texCoord;
    adjustedCoord.y = (1.0 - adjustedCoord.y);
    adjustedCoord.xy = (adjustedCoord.xy * 2.0 - 1.0);
    return (float3((adjustedCoord * Camera::fieldOfView), 1.0) * depth * Camera::maximumDistance);

float surfaceDepth = Resources::depthBuffer.Sample(Global::pointSampler, inputPixel.texCoord);
float3 surfacePosition = getViewPosition(inputPixel.texCoord, surfaceDepth);

This uses the texture coordinate, remaps it from [0,1] to [-1,1], then treats that as a vector away from the camera.


Just to finish it off, here's the code that renders a large triangle over the screen.  This is from Bill Bilodeau's vertex shader tricks presentation:


Pixel mainVertexProgram(in uint vertexID : SV_VertexID)
    Pixel pixel;
    pixel.texCoord = float2((vertexID << 1) & 2, vertexID & 2);
    pixel.position = float4(pixel.texCoord * float2(2.0f, -2.0f)
                                           + float2(-1.0f, 1.0f), 0.0f, 1.0f);
    return pixel;

You can just draw a simple 3 vertex primitive with this shader, no vertex or index buffers required since it uses the vertex ID.

In Topic: About resouce files

24 May 2016 - 03:48 PM

A type of ico in the RC file, and "ico" in FindResource call, should result in a custom resource type.  "ico" is not an existing resource type (https://msdn.microsoft.com/en-us/library/ms648009(v=vs.85).aspx), which means it's being imported and compiled in as a regular blob in the resources.  This is why it gets found when finding it, there's no special handling going on and you're matching the RC type when finding it.


ICON and RT_ICON will do it's own special handling, and I've found that icons can be pretty tricky when used as resources.  Have you made sure that the icon is valid and supported (no odd sizes/laters/color depths/etc)?  Open the icon in Visual Studio and make sure it loads/looks correct, and try actually saving it there as well.  Make sure you save it explicitly (Save As and overwrite, or save to a new name), otherwise it might not think it needs to save.