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 ...
Expanding on TomTsagk's correct answer, I thought it might help to describe a bit more about why games work like this.
Light in games doesn't really "travel" from the source, to the surface, to the camera, getting obstructed along the way.
To figure out how bright to draw each pixel of a surface based on a given light, we use (or approximate) a math ...
Real-life soft shadows have a shape that depends on the shape of the light source as it appears from the point of view of the shadowed surface. This is because penumbras occur due to partial occlusion of the light source from the shadowed surface's point of view. The shape of the shadow is therefore something like the shape of the occluder convolved with ...
Long story short, this happens for performance reasons.
When there's a light on the screen, by default it shines on all objects (obstructed or not), so the game would need to make extra calculations to see which object is affected by what.
This is easier to solve on static objects by using static and baked lighting, but this is not the same on dynamic ...
Going to try and doodle up what I mean here as soon as I finish typing this, but:
What about merging the two?
Use the second (occlude by base) for everything that isn't a wall and the first (occlude by tops) for lighting the walls?
You actually did this by accident in your second example, with the wall that goes off the bottom of the image. Extending ...
http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-16-shadow-mapping/ gives a nice overview over the basics. http://en.wikipedia.org/wiki/Shadow_mapping links to a multitude of research papers describing different improvements and optimisations.
Shadow volumes have been 'the thing' a few years ago. http://en.wikipedia.org/wiki/Shadow_volume ...
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 ...
The problem is that "cheap" lighting is a calculation based solely on the light source and the object it is applied to, any possible intermediate object that would block the light is not a part of the calculation.
Therefore a lot of games use such lights coupled with some shadow system.
Finally got it working!!!
The problem indeed was in the fragment shader.
First of all, there was no need to invert the position, the error came from the UV coordinates.
Finally I remembered when I was using XNA the textures where flipped vertically respect to OpenGL, and that was the problem.
After flipping the V coordinate and correcting the reversed ...
I did a quick sketch of how it could be done.
Yellow round thing is the Sun, obviously, grey things are rays and black ones are boxes. The blue lines are the shadow triangles and yellow dots are the vertex points.
You cast rays down from the Sun to the edges of the blocks and through them. Take the vertices where it hit the box and the ground. Then you ...
As promised, I have written a very long article about how I optimised the shadow renderer in my game "Dark".
My article goes into a lot of detail, reaching a whopping 2500 words, plus illustrations, so I won't repost it here. But I will give a quick overview:
There are two major things that I had to optimise, for Dark: ...
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 ...
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”...
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.
Some information on the Grow Home/Grow Up art direction here if you're still interested :)
We relied very heavily on our custom Fresnel shader for... well... the entire look of the game. But it was especially important for the lighting of cave interiors. We pretty much only had one directional light in the whole game from the sun, but you're not seeing any ...
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").
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.
I've implemented a similar method in the past, and it can be quite tricky to get it right. The best resource I've seen is on Amit Patel's fantastic site:
There are quite detailed explanations of each step, lots of good demos, and some code samples.
To briefly answer your question directly, the "polygon ...
I have a couple of suggestions
Avoid Allocations and Copies
A lot of your code has unnecessary allocations and copies. Instead of filling a vector with push_back, try pre-allocating the vector and setting the data there. You have a fixed maximum number of intersection points, so pre-allocate a vector of that size.
Do a Simple Broadphase
Before you do ...
For simple shadows you can create a material and select the shader as Sprite>Diffuse , this will enable shadows on the sprite.
If you are looking for more than just shadows i.e. adding normal maps and other cool stuff, then check these two links give below :)
Writing a SpriteLamp Shader in Unity
Kencho's dev blog
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.
Are you using blending between your rendering passes?
It sounds like your rendering loop is going something like this:
Fill first explicitly defined shadow map
Render scene fully using the first light
Fill second explicitly defined shadow map
Re-render scene fully once again but using second light
Under that situation, the result of step 4 will ...
So it seems like while changing the quality settings did increase the quality of the shadows it did not remove the artifacts, but when I was int he QualitySettings menu, I saw some settings that I had seen in other forums. Changing the shadow distance to a lower value increased the quality of the shadows and removed the artifacts. This also allows the use of ...
You have two problems here:
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 ...
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 ...
There are a few things you should do to optimise the shadows in your game:
Use lightmapping heavily to compute the shadows for static meshes. Unity has a builtin lightmapper. See http://docs.unity3d.com/Documentation/Manual/Lightmapping.html and http://docs.unity3d.com/Documentation/Manual/OptimizeForIntegratedCards.html.
The computation of dynamic lights ...
In general, the way that shadow maps are supposed to work is not by combining a screen-space shadow texture with a rendered texture. In that case you will always get awkward artifacts at boundaries between fully-lit areas and fully-shadow areas that have similar z-values. These are the areas where you're sampling at a boundary in the shadow map.