51

Shadow mapping and stencil shadows (shadow volumes) are definitely the big two, as you've mentioned, so I'll stick to comparing the two. And since you've pointed out the most obvious shortcomings of shadow mapping and advantages of stencil shadows, I'll do the opposite. Stencil shadow shortcomings Shadows match the shape of the casting mesh. This is very ...


12

The basic process for a directional light (whose rays are parallel) is as follows: Calculate the 8 corners of the view frustum in world space. This can be done by using the inverse view-projection matrix to transform the 8 corners of the NDC cube (which in OpenGL is [‒1, 1] along each axis). Transform the frustum corners to a space aligned with the shadow ...


8

You could apply the bias when rendering the shadow map, instead of when sampling it. I think that's the usual/"standard" approach to shadow map biasing, actually. BTW, if you want tan(acos(something)), it's probably faster to calculate sqrt(1 - something^2) / something, which is equivalent (using some trig identities). Generally if you're combining ...


6

You are using sampler2D with a texture that has GL_TEXTURE_COMPARE_MODE != GL_NONE. That is not going to work, you are invoking undefined behavior. This line: GL11.glTexParameteri(GL11.GL_TEXTURE_2D, GL14.GL_TEXTURE_COMPARE_MODE, GL30.GL_COMPARE_REF_TO_TEXTURE); Tells OpenGL that when you fetch something from this texture, rather than returning the actual ...


5

Variance shadow mapping, plainly put, just suffers from these light bleeding issues. I personally prefer to implement ESM (check out page 257 of ShaderX6) as the memory pressure is half of the VSM map and the artifacts are much less abrasive to me: (The very beginning of the shadow is a bit too bright.) With this said, here is a (rather old) PDF full of ...


5

try using a multiplicative "bias" instead of additive: shadowCoordinate.z *= 0.98; If you're doing the sampling yourself rather than using the shadow comparator interpolating the shadow map helps reduce acne a lot. There shouldn't be any shadow visible behind the object as the light should not affect it with the light being completely occluded by the ...


5

In the Unity docs under shader references. Shadow mapping macros Declaring and sampling shadow maps can be very different depending on the platform, so Unity has several macros to help with that: UNITY_DECLARE_SHADOWMAP(tex) - declares a shadowmap texture variable with name “tex”. UNITY_SAMPLE_SHADOW(tex,uv) - samples shadowmap texture “tex” at given “uv”...


5

Realtime shadow maps allocate texels for everything the light can see. Lightmaps allocate texels for everything. This makes a big difference in several cases: faces occluded from the light don't contribute any information to a shadow map - they occupy the same texels as the object occluding them. A lightmap will allocate separate texels to shadowed faces. ...


4

You should set your far plane to infinity for shadows, instead of setting a far clip distance of 1000. Also, for a ratio of far/near of 1000.0/0.1 you would get better precision with a far plane at infinity anyway. Check this paper out http://www.geometry.caltech.edu/pubs/UD12.pdf ("3 - Projection Matrix Precision").


4

Your problem is that you need to render the scene twice. One from the view of the Light and then the normal rendering pass from the camera point of view. Now, do I even need a fragment shader in this shader pass? Yes. According to your question you are using OpenGL 3.3 which makes it required to define a fragment shader to be able to render anything. ...


4

You can suppresses messages from the debug layer: #include <wrl/client.h> using Microsoft::WRL::ComPtr; #ifndef NDEBUG ComPtr<ID3D11Debug> d3dDebug; hr = m_d3dDevice.As(&d3dDebug); if (SUCCEEDED(hr)) { ComPtr<ID3D11InfoQueue> d3dInfoQueue; hr = d3dDebug.As(&d3dInfoQueue); if (SUCCEEDED(hr)) ...


4

If you don't need the pixel shader (eg: you don't write to depth manually in there or don't use discard), you can just set the Pixel Shader stage to null. Depth stencil will still be written to, and your warning message will disappear. so just doing deviceContext->PSSetShader(NULL,NULL,0); Will do the trick. It (should) also be faster since you don'...


4

After much deliberation and a stroke of insight I figured out what the problem was. It was a problem with my shadow map vertex shader; I wasn't putting the objects into model space. That means that all objects were being rendered at 0, 0, 0 with a scale of 1 and no rotation. OOPS. Properly applying a model matrix in the shader managed to fix the issue. ...


4

Shadow maps, the way you're using them, don't filter well. The linear filtering does what it's supposed to, it's just not the thing you actually want for this context. Take a sample point halfway between an occluded sample (say, depth from light = 5 vs my depth from light = 10), and a non-occluded sample (depth from light = far plane). We somehow want to ...


3

You have two problems here: First problem: Adding some kind of position offset to your lookat matrix (currently your camera position) is essentially supposed to center the "light camera" (whatever your light source sees from its view) around that position. This is done because the shadow map will only cover a limited range, but if your shadow maps in one ...


3

Spotlight shadow maps are created by projecting the scene with a perspective frustum. This allows the light to radiate out from a single point. This perspective frustum is built using: A view matrix originating from the light's position and pointing in the direction of the spotlight A perspective projection matrix that encompasses the light volume In a ...


3

You do need a fragment shader (it's required by the standard), but you can just provide an empty fragment shader. shadowmap.frag: void main() {}


3

I've already found some time and solution to my problems and I want share it with you. Maybe it will help someone: float distFromCentroid=ACamera.far(); camera.setLookAt(frustum_centroid+dir->direction*distFromCentroid,frustum_centroid); for(int i=0;i<8;i++){ point[i]=ACamera._point[i]*camera.matrix; } min=point[0]; max=point[0]; for(int i=0;i&...


3

The pixels outside of the lights view are dark because they're being sampled from outside the lights depth texture. When you transform the vertex by the projection matrix you get the clip coordinates [lightspace_Position] of the fragment. You are then converting that into texture coordinates [UVCoords]. However, clip space coordinates of a fragment can ...


3

No, you would not typically render a shadow map for each light AND object. Typically there will be a fixed number of shadow maps per light (sometimes 1, sometimes more), but the number of shadow maps doesn't usually vary with the number of objects to be shadowed. There are three kinds of lights commonly used in computer graphics: spot, point, and ...


3

There is an advanced technology based on compute shaders that will analyze the depth buffer of the main camera, and return the min depth, and max depth, with 1 pixel precision (reduce operation). This information can be used to create a very precise frustum for the shadow camera. Elements outside the view that casts shadows are only in the frustum that goes ...


3

When you're projecting a texture, the goal is to take some texture and 'paste' it onto the scene. This is essentially mapping points on the texture to points in the scene, so if we can find a mapping between these coordinate systems we'll have our solution. It's difficult to map from the texture's 2D coordinates to 3D world coordinates, but it turns out to ...


3

You will need to implement multiple alternative solutions depending on the GPU. Not only are there many choices (GL_DEPTH_COMPONENT16, GL_DEPTH_COMPONENT24, GL_DEPTH_COMPONENT32, GL_DEPTH_COMPONENT32F, and GL_DEPTH24_STENCIL8, GL_UNSIGNED_INT_24_8_OES) every GPU has different levels of support and fallbacks must be implemented. It is possible the GPU does ...


2

There isn't a way to bake lightmaps at runtime using Beast (Unity's lightmap engine). Beast only works in the editor. However, you can run editor functions from the command line using -executeMethod so if your procedural level was XML you could send it to a server, run an editor method similar to this (javascript): static void PerformBuild () { ...


2

p(x) there is the blur kernel, usually a Gaussian, with which you convolve the depth and depth^2 buffers. (Or if you don't do a Gaussian blur on the VSM, then it's just the bilinear filtering kernel.) The random variable is, correspondingly, the depth of a random point in the shadow map chosen with a Gaussian distribution around the point whose shadow you'...


2

The hardware slope-scaled depth bias should work fine with deferred shading. It only affects the depth values written into the shadow map, so you generate the same shadow map regardless of whether you're using forward or deferred shading. Is it possible you're not reconstructing position from (camera) depth correctly when you do your lighting passes? That ...


2

Your code is only sampling the corner texels, so is only valid for a 2x2 filter. Sample all the texels within your filter shape to achieve correct results.


2

The method with viewSpace.z is storing depth, while the method with length(viewSpace) is storing distance to the light, not depth (which is always measured parallel to a view direction). You could store either one, but you have to be consistent about it. If you store distance instead of depth when you render your shadow map, you have to compare against ...


2

The answer was simple. The order of multiplication was wrong - this is what it should've been: corners[i] = inverseVPMatrix * corners[i]; I thought the order of vector/matrix multiplication didnt matter, but I guess it did... with the above, it works fine. Now that I think about it, glm math library is column-major, so maybe that is why?


2

I had similar problem to yours. And I think that you can have something wrong in two places: Bad light view projection matrix. You should make some preview of each cascade and check if shadow map looks ok. In my case after transform bounding box of frustum split by light view matrix, transformed box position in z axis was wrong and in far distances shadow ...


Only top voted, non community-wiki answers of a minimum length are eligible