Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 08 Apr 2011
Offline Last Active Today, 03:38 PM

#5226329 Visual Studio and HLSL compiling

Posted by KaiserJohan on 29 April 2015 - 01:42 PM

I've got VS 2013 pro and currently have one hlsl source file for each pcf kernel, for example pcf2x2.hlsl, pcf3x3.hlsl, pcf5x5.hlsl, ...

VS compiles them automatically at build time, but it leads to some code redundancy and it unpleasant to work with. It would be much better to simply have one source file and recompile with different macros - but how does one make VS recompile the same file several times?

#5214680 NVIDIA NSight vs Visual Studio 2013 Graphics Debugger?

Posted by KaiserJohan on 05 March 2015 - 03:02 AM

Try RenderDoc (http://cryengine.com/renderdoc). Of all the three, it is the one I keep going back to. Free, fast, awesome. 

#5208079 Light-weight render queues?

Posted by KaiserJohan on 01 February 2015 - 02:25 PM


Is it a sound idea to do view frustrum culling for all 6 faces of a point light? For example, my RenderablePointLight has a collection of meshes for each face.


Is this about a shadow-casting point light which renders a shadow map for each face?


If your culling code has to walk the entire scene, or a hierarchic acceleration structure (such as quadtree or octree) it will likely be faster to do one spherical culling query to first get all the objects associated with any face of the point light, then test those against the individual face frustums. Profiling will reveal if that's the case.


If it's not a shadow-casting light, you shouldn't need to bother with faces, but just do a single spherical culling query to find the lit objects.



Yeah its for shadowmapping. How do you do a spherical culling query?

#5174629 So... C++14 is done :O

Posted by KaiserJohan on 19 August 2014 - 12:43 AM


 I still think the range-based loops were unnecessary. 


Can you elaborate more? Personally I feel it is alot more readable.

#5172915 Point light shadowmapping

Posted by KaiserJohan on 11 August 2014 - 03:15 PM

Fixed it... in case it helps anyone else:


The TextureCube follows Left-hand coordinate system in DirectX, while it is right-handed in OpenGL. I am using right-handed matrices due to GLM, so It required flipping the +/-Z tex cube faces:

    const Vec3 CUBEMAP_DIRECTION_VECTORS[DX11PointLightPass::TEXTURE_CUBE_NUM_FACES] = { Vec3(1.0f, 0.0f, 0.0f), Vec3(-1.0f, 0.0f, 0.0f), Vec3(0.0f, 1.0f, 0.0f),
                                                                                         Vec3(0.0f, -1.0f, 0.0f), Vec3(0.0f, 0.0f, -1.0f), Vec3(0.0f, 0.0f, 1.0f) };

    const Vec3 CUBEMAP_UP_VECTORS[DX11PointLightPass::TEXTURE_CUBE_NUM_FACES] = { Vec3(0.0f, 1.0f, 0.0f), Vec3(0.0f, 1.0f, 0.0f), Vec3(0.0f, 0.0f, 1.0f),
                                                                                  Vec3(0.0f, 0.0f, -1.0f), Vec3(0.0f, 1.0f, 0.0f), Vec3(0.0f, 1.0f, 0.0f) };

Likewise, the projection matrix is different from OpenGL to DirectX, as the range of NDC is different. The old VectorToDepth function I used in OpenGL I altered to this:

float VectorToDepthValue(float3 Vec)
    float3 AbsVec = abs(Vec);
    float LocalZcomp = max(AbsVec.x, max(AbsVec.y, AbsVec.z));

    const float f = 100.0;
    const float n = 0.1;

    float NormZComp = -(f / (n - f) - (n * f) / (n - f) / LocalZcomp);

    return NormZComp;

ALTHOUGH I had to add an extra instruction to the pixel shader:

    float3 cubemapDir = (float3)(worldPosition - gLightPosition);
    cubemapDir.z = -cubemapDir.z;       // TODO: any way to remove this extra instruction?
    float storedDepth = gShadowmap.Sample(gShadowmapSampler, cubemapDir).r;
    float visibility = 0.0;
    if (storedDepth + 0.0001 > VectorToDepthValue(cubemapDir))
        visibility = 1.0;

Any input on how to optimize this away would be awesome

#5172354 DXGI leak warnings

Posted by KaiserJohan on 08 August 2014 - 03:30 PM

Nevermind, I fixed it. 


In case it helps anyone else: It turns out Get() methods such as OMGetDepthStencilState() also increases the RefCount - and now that I think about it, of course it does... those pointers would have to be released aswell.

#5171722 Cubemap texture as depth buffer (shadowmapping)

Posted by KaiserJohan on 05 August 2014 - 04:25 PM

I'm converting my OpenGL 4 renderer to DirectX 11. Once I got over making a simple textured triangle, the rest went very easy, I now have a deferred shader setup with ambient/point/directional lights and am now reimplementing the shadow mapping parts, starting with point lights (omnidirectional shadowmaps).


Here's how I create my texture cubemap:

// create shadowmap texture/view/srv
D3D11_TEXTURE2D_DESC depthBufferDesc;
ZeroMemory(&depthBufferDesc, sizeof(D3D11_TEXTURE2D_DESC));
depthBufferDesc.ArraySize = 6;
depthBufferDesc.Format = DXGI_FORMAT_D32_FLOAT;     // potential issue? UNORM instead?
depthBufferDesc.Width = shadowmapSize;
depthBufferDesc.Height = shadowmapSize;
depthBufferDesc.MipLevels = 1;
depthBufferDesc.SampleDesc.Count = 1;
depthBufferDesc.Usage = D3D11_USAGE_DEFAULT;
depthBufferDesc.BindFlags = D3D11_BIND_DEPTH_STENCIL;
depthBufferDesc.MiscFlags = D3D11_RESOURCE_MISC_TEXTURECUBE;
DXCALL(device->CreateTexture2D(&depthBufferDesc, NULL, &mShadowmapTexture));
DXCALL(device->CreateDepthStencilView(mShadowmapTexture, NULL, &mShadowmapView));
DXCALL(device->CreateShaderResourceView(mShadowmapTexture, NULL, &mShadowmapSRV));

I'm currently at a loss of how to select which face of the cubemap to use as the depth buffer. In OpenGL I would iterate 6 times and select the cubemap face with:


But in DirectX11, cubemaps seems to be defined as Texture2D but with different array size. Looking at the OMSetRenderTargets(), it dosn't specify anywhere which cubemap face to use either.


Any pointers on how to select the proper face to use as depth texture?


I've been browsing around like mad on MSDN, and it is fine as a reference for structures and functions, but awful for anything else :(

#5168921 SamplerState in code or HLSL?

Posted by KaiserJohan on 24 July 2014 - 11:43 AM

Since you're using a second vertex stream, the input layout should reflect that:

  inputDescription[1].InputSlot = 1;
  inputDescription[1].AlignedByteOffset = 0;
Such troubles are better analyzed with a graphics debugger where you can see if your texture upload succeeded and if your vertices are correct.



Thats it. Thanks.


The result is not as good as I hoped it to be, even with anisotropic filtering set to 16. Here's an example:





In the background you see its very blurry. Is there any way to get better visuals?

#5154138 Why do I fail to create a window?

Posted by KaiserJohan on 16 May 2014 - 04:51 PM

Don't you have the major/minor version macros wrong?


This is what I use:


Note the difference
If it dosn't work, run the GLEW example tool which finds your highest supported OpenGL and all possible extensions and use that as hint

#5132028 Destructors or Release methods?

Posted by KaiserJohan on 17 February 2014 - 09:09 AM

What language are you using?


If you are using C++, look into RAII (http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization).

#5117971 Deferred shading and point light range issue

Posted by KaiserJohan on 18 December 2013 - 05:02 PM

Thanks, it works wonderfull!

#5117951 Deferred shading and point light range issue

Posted by KaiserJohan on 18 December 2013 - 03:53 PM

My idea with max distance is to have it be 0 at maxDistance and 1 at the centre, so it clamps between the two. Then to have an additional parameter, what I call "FalloffFactor" to be how steep the falloff is between 1 and maxdistance


At the moment I'm ready to accept the simplest just to get the actual light volume working properly before trying a better formula, as shown it dosnt work properly in the pcitures in the previous post - something is bollocks and I dont know what


The light spheres radius is the maxdistance btw

#5117950 Deferred shading and point light range issue

Posted by KaiserJohan on 18 December 2013 - 03:50 PM

I'd rather go for 1);


Here's what I got then

http://postimg.org/image/xtld8cevz/  -  you can see the bounding sphere not touching the chair

http://postimg.org/image/q087316yb/   - it actually lits the chair


With the small change to calculate attenuation:

    vec4 CalcPointLight(vec3 worldPos, vec3 normal)                                                                        \n \
    {                                                                                                                       \n \
       vec3 positionDiff = (UnifShadingPass.mLightPosOrDir.xyz - worldPos);                                                   \n \
                                                                                                                              \n \
       float dist = max(length(positionDiff) - UnifShadingPass.mMaxDistance, 0);                                            \n \
                                                                                                                            \n \
       //float attenuation = 1 / ((dist / UnifShadingPass.mMaxDistance + 1) * (dist / UnifShadingPass.mMaxDistance + 1));  \n \
       //attenuation = max((attenuation - UnifShadingPass.mMaxDistance) / (1 - UnifShadingPass.mMaxDistance), 0);             \n \
        float attenuation = 1.0 - (dist / UnifShadingPass.mMaxDistance);                                                                                                                   \n \
       vec3 lightDir = normalize(positionDiff);                                                                             \n \
       float angleNormal = clamp(dot(normalize(normal), lightDir), 0, 1);                                                   \n \
                                                                                                                            \n \
       return angleNormal * attenuation * UnifShadingPass.mLightColor;                                                      \n \
    }                                                                                                                       \n \

#5106038 Opengl ?.x and what Tutorial

Posted by KaiserJohan on 31 October 2013 - 01:58 PM

http://www.arcsynthesis.org/gltut/Basics/Basics.html is the best source of modern OpenGL 3.x+ tutorials I've seen. Very informative and goes into great detail at everything. 


There are more 3.x tutorials than 4.x tutorials and also 4.x is not supported on all that many hardware, I believe any Intel laptops only support up to 3.1 or 3.2 last time I checked. 

OpenGL 3.3 is a good aim, it was released at the same time as OpenGL 4.0 too I believe and the differences is that OpenGL 3.3 is more widely supported.

#5078102 Game Design: When to stop brainstorming and start programming

Posted by KaiserJohan on 16 July 2013 - 04:39 AM

Start coding asap and then go back to refactor once you've got some naive implementation. It might be disheartening knowing much of your first implementation might get scrapped but when actually coding you'll stumble into all sorts of problems you probably could never have dreamt of while designing, and even if you spent days on a solid design the first implementation is hardly water-proof no matter how much you prepare.

Refactor and iterate is king, especially in hobby projects when you can go back how many times you want and find and correct your past mistakes, you'll quickly progress into a better programmer overall