Vilem Otte

It looks good, I could run it at work on GTX 680, no luck at Radeon 6870. At home I can't get it run on AMDs either. The problem probably aren't supported features though, it is more likely that some GLSL shaders aren't valid for AMD gpus, but are valid for NVidia gpus.

This especially counts twice for compute shaders, as AMD finally supports them in stable driver (13.4 has been beta for quite a while -> now it is stable -> hooray), but the driver has like a TON of differences from NVidia driver (damn those vendors, both!) ... so most likely the compute shaders are causing the issues. I could give it a look or two on AMD, sadly I have too much work these weeks and I won't be regularly available till 15th June or so.

What about State Matchines? Let's just imagine a simple case:

Imagine an actor inside the world. It's staying on point A, it's state is IDLE. Now his AI determines he needs to go to point B, so he gets the path from AI. The state changes to WALKING and his virtual position is moved along the path to the point B. Once he reaches point B, his AI determines that his goal was successful, the state changes to IDLE back again.

Now the state-animation relation for each entity can be stored F.e. as:

State IDLE
{
      Animation "idle.anim"
}

State WALKING
{
      Animation "walk.anim"
}

Each of your entity type you will have stored state-animation relation. Each single entity will store its state (you don't need to use strings, use IDs instead of them - assigning them in load time based on the strings ... or store state names directly as IDs, but it's quite to harder to make that easy-to-describe ... nah I think you get this idea). Now upon processing your entity, you check it's state, update it and render it with animation based upon that state.

#cr88192

But computing Sun-shadows as point light shadows yields incorrect result (unless that point light isn't at distance of 149.6 * 10^9 meters ~ assuming you want to do same Sun-shadows as they're on Earth) ~ actually it should be treated as spherical (not point) light shadow of sphere at distance of 149.6 * 10^9 meters and radius of 6.9 * 10^8 meters.

The problem is, that the distance to sun is larger (by magnitudes) than dimensions of world - thus we can simulate Sun-light and Sun-shadows using directional light and ortho- projected shadow map (note that for correct softening and specular reflections we have to take Sun's radius into account).

All of this is assuming we want to correctly simulate sun light behaviour (or closely approximate it). Of course there are reasons where you don't want to approximate it (Non-photorealistic rendering, stylisation, etc. etc.) ... or that you can fine-tune everything so it looks very good in the end.

I am using an bounding volume around my lights as well, but that won't work if you have directional lights. So how are you handling that type of light.

There are actually several solutions on handling this. In my case, the only directional light is the sunlight (respectively moonlight in the night), they're handled separately. As I stated in case of exterior scene the sunlight has maximal importance (e.g. it will always be rendered).

Now you need to somehow work with shadow maps for sun. In my case, I use cascaded shadow maps. For more information on them, see http://msdn.microsoft.com/en-us/library/windows/desktop/ee416307%28v=vs.85%29.aspx (or just google for "cascaded shadow maps" - there is like a TON of resources) ... and as "rendering importance" is maximal for sunlight, the "cascades" gets re-rendered, if either camera-position changes, light-position changes or dynamic object in the exact cascade has moved.

And as cascaded shadow maps cover the whole view frustum, they're perfect for simulating shadows for directional lights (note that they might not cover 100% of your frustum in order to optimize, you can cover F.e. only like 50% of your view frustum, and make your shadows disappear in the distance ~ with same number of cascades you will get better resolution of shadows near the camera). Cascaded shadow maps can (and should) be stabilized to achieve non-shimmering shadows.

NOTE: Of course if you have lots of directional lights, there is no way to do cascaded shadow mapping for all the lights at good frame rate (performance reasons of course).

NOTE 2: That spotlights can also use cone as bounding volume. Somehow limited directional light (affecting just known area of plane that is perpendicular to light direction) can also have bounding volumes (like "infinite" cylinder - it's actually finite, because you can limit near and far planes to just cover the scene).

Just for information, in my game engine I got multiple BVHs (one for static objects, one for dynamic objects and one for skinned objects) for objects in my scene. Scene lights are stored in another "BVH" (each light has bounding volume in leaf that describes area lit by the light).

First of all, I test which light's bounding volumes are seen from the camera. This gives me a list of lights, for which I need to have shadow map. For each light in the list I decide its "importance", e.g. whether it's really needed to have the shadow map and at what resolution. The "importance" is based (for point lights) upon their distance from camera, their lighting radius (currently I use surface area of their bounding volume) and their intensity (low intensity lights doesn't need high resolution shadows), for sunlight the importance is (if we're in exterior) maximal - e.g. it has always defined resolution.

Next thing I have to check is whether dynamic BVHs has changed inside the light bounding volme or whether light position has moved. If none of these happened, I check whether I already have shadow map at wanted resolution for this light -> in that case I don't need to update it. Otherwise I render shadow map for that light.

Updating shadow map is again tricky, I again traverse static and dynamic BVHs for leaves intersecting the light's volume. Those leaves are models that need to be rendered.

E.g. summarized, I only update shadow map when I have to, and update it only using models that are affected by light.