Deferred Virtual Texture Shading 4

Reading a post at gameangst made me realize yet some more advantages to my "Deferred Virtual Texture Shading" (*sigh* i really need to think of a better name for this!) idea:

• It's possible to exclude/include objects from the influence of lights, this makes it easier to make sure that you won't have light bleeding through walls when a light doesn't actually cast any shadows.

Some time soon i'm going to try this idea out.

Deferred Virtual Texture Shading 3

Just realized another good property of my "Deferred Virtual Texture Shading" idea:

• Anti-aliasing is not a problem with this technique because all the shading occurs in texture space, and the rendering is 'simply' just rendering geometry with one (or two) textures ;)
• Update: Also, if we render our lights in texture space, we can't use proxy meshes to only render light to the pixels that are visible to both the light and the camera. To reduce this disadvantage we could have some sort of octtree/hashed grid/whatever to determine which texture-pages are 'hit' by the light and only redraw those. If we also take page-mipping into account, and only redraw the part of the mip that holds the page we're touching we actually get the "the smaller the light is, the less pixels we process" advantage of deferred lighting back.
• Update 2: Another interesting property is that smoothing the lighting over a surface to make it look as if it's more curved than it actually is would be much easier in texture-space..

I really need to allocate some time and try to implement this technique ...

Fluid dynamics experimentation

Here is an experiment in fluid dynamics i'm working on:

Deferred Virtual Texture Shading 2

I just read a post on EntherTheSingularity about some variations on a new technique that's roughly based on deferred rendering.

Basically they can work with transparent surfaces and can let you render the lighting at a lower resolution (saving fillrate), which works because lighting is usually rather low frequency anyway.

This made me realize a couple of things about my "Deferred Virtual Texture Shading" idea that i mentioned in a Previous post.

The good:

• Since we're rendering in texture space we can render lighting at a lower resolution. We could still combine it with albedo at a higher resolution (probably at render time). Yay!

The bad:

• Rendering in texture space can cause light leaks, which would be bad. So texturing geometry (or filtering) would have to take edges into account. Ouch ...

Behavior Tree & Navigation Meshes

Behavior Tree

Today i've been busy implementing a behavior tree in C#, which was suprisingly easy!

(In case you don't know what a behavior tree is, read this NOW!)

Update: Apparently i the link i provided is in a part of that website which requires (free) registration..

However, the same article is also available (oddly enough) in the publicly accessible part of the website, but split in 3 parts (go figure).

Here are the links.

One of the more complicated parts of the tree is that you don't run the entire tree each frame (which is a good thing!), so it has to be split into small pieces.

I realized that i could probably abuse the whole enumerator/yield construction in C#, and came up with the following solution:

public class Sequence : IBehaviorTransform
{
public IEnumerable<BehaviorResult> Process()
{
   foreach (var node in Children)
   {
       foreach (BehaviorResult result 
                in node.Execute())
       {
           switch (result)
           {
               case BehaviorResult.Success:
                   // If child-node executes
                   // successfully, continue 
                   // to the next node
                   goto NextChild;

               case BehaviorResult.Failure:
                   // Notify parent that 
                   // we've failed ..
                   yield return 
                       BehaviorResult.Failure;
                   // Exit the function
                   yield break;

               case BehaviorResult.Running:
                   // Notify parent that
                   // we're still running
                   yield return 
                       BehaviorResult.Running;
                   // Continue the loop
                   continue;
           }
       }
       NextChild:
       ;
   }
   // Finally, if all nodes are processed
   // without failing we return success
   yield return BehaviorResult.Success;
}
}

Every IBehaviorTransform implementation would return an IEnumerable of BehaviourResult, and as i enumerate my enumerable once each frame, it'll just magically work ;)

Navigation Meshes

Another rough idea of mine is about navigation meshes (Look here if you don't know what those are).

I haven't played with them yet, but it seems to me that it should be possible to simply perform A* on the traversable edges (that are wide enough for the current entity) to find a path.

One problem with navigation algorithms is that they're relatively expensive and either need to be stored and/or re-calculated every x frames..

So you really want to only calculate a rough high level path, and use some more refined (maybe completely different) algorithm at a lower level.

Suddenly i realized that quite often you'd end up with long paths in any navigation mesh where several connected cells/nodes form a chain.

Which means that you could basically just skip the whole chain during the high level path finding, and only check the nodes/cells where you need to make a decision!

You'd probably need to store some basic stuff like the minimum portal size so you can tell in advance if an entity will actually fit through that chain. And you'd need to be able to update the chain in case it's obstructed.

Maybe information about obstructions could be stored at an entity level?

(probably too memory heavy though)

Entities would then expect a pathway to be clear, but when they arrive it's blocked (useful for planning an ambush?), and then will either try to remove the obstruction (if possible and doesn't require too much time and energy) or try another route instead...

Deferred Virtual Texture Shading

For some time now i've had this, admittingly pretty vague, idea about a combination of deferred shading and virtual textures (aka "mega-texture").

It hit me that most of the attributes stored into a G-buffer during deferred shading are already present in a virtual-texture, so if you combine the two you'd only need to store the virtual-texture coordinates, which would require smaller G-buffers.

Ofcourse that's not entirely true, since a pixel in a G-buffer almost never exactly match a texel on a texture; that's what filtering is for.

But what if we would use our virtual-texture cache as the G-buffer itself?

The problems:

1. We'd need to fill some of the attributes of the virtual texture at runtime, like coordinates/normals of the texels. However, For static geometry this could be pre-baked, for dynamic geometry this could be cached. (Interestingly enough this sounds a lot like geometry images)
2. Another big problem is how can we (efficiently) render the lights into this "virtual G-buffer"?

I'm not sure how the last problem could easily be done without losing all the benefits of deferred shading. It would definitely help to have some sort of hierarchy where virtual texture pages are matched with chunks of geometry.

That way we'd only calculate the light for lights who's radius touches those chunks of geometry and their respective virtual texture pages.

It would also make it possible to move the paging algorithm completely to the cpu side, that way we won't need a nasty readback from the gpu to discover what virtual texture pages to upload.

But if (a BIG if) these problems would be solved, it would give us some interesting properties:

• Lighting calculations can be cached.
• A virtual texture would be able to contain a lot more data, at a much higher quality, compared to G-buffer (which would potentially create a disk space problem)
• Rendering the geometry would simply be a matter of rendering the geometry with a single texture.
• Transparent surfaces wouldn't need to be rendered in a separate pass. (depth peeling?)
• All shadows and lighting would automatically be filtered. (so you'd better have a high-res virtual texture!)
• Filters and blurs can be applied on lit surfaces (although there would be some difficulties at cache-page boundaries), which could be useful for subsurface scattering effects.
• If you ignore all the caching, all the calculations would be relatively constant, scaling nicely with the amount of geometry and lights.

The questions are, is it possible? and, is it fast enough?