Thinking about barricade

#1 James,
This may be a more complicated solution than you are looking for, but it's something that I've had on the shelf to look at for a few things:

Valve Publications:
http://www.valvesoftware.com/publications.html

Efficient Self-Shadowed Radiosity Normal Mapping:
http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_EfficientSelfShadowedRadiosityNormalMapping.pdf

Don't freak out about the alternate co-ordinate space. It took me many reads, and much thought to fully grok what was going on, but it is a VERY cool technique. They are basically storing the result of N dot V, for three different V's. Those V's are the basis vectors that they are talking about. This lets them scale the result of N dot V, for each value of V, to provide self-shadowed bump maps.

The Screen Space Ambient Occlusion techniques have been a floodgate recently, and there are a lot of approaches taken.

I have not done any implementation work on either of these techniques, but hopefully it will give you some ideas.

#2 That is very cool but I'm looking for something a little more subtle and easier to implement. I just need to find how the ambient light is fed to the shader in the TGEA system, I would think that this would be there I just am not seeming to find it. I mean if you look at barricade you can plainly see where areas that should be darker than they are because there is a ambient or "environment" light being passed. is this is the mission file or is this lighting coming from the light map of the mission or what? That has to be exposed to the shader system some how. I would thing that I could have that multiplied by a texture map int he pixel shader can't I?


I'm not really looking for self shadowing and radiosity. That is way over my head.

#3 I think the ambient lighting is fed to the shaders via the PC_AMBIENT_COLOR shader constant. The value of this constant is set by the light manager (search the engine code for PC_AMBIENT_COLOR).

This value is taken from the ambient lighting specified in the mission for the sun. However, objects are able to override this value themselves and use their own customAmbient value, so every object can potentially have a different ambient value.

#4 EDIT: Ah, sorry. Just skimmed and saw the ambient occlusion part. Ambient occlusion would greatly enhance the realism of Torque though, it's definitely worth investigating.

I've been working on a screen-space ambient occlusion technique. Right now it's quite basic, but I think it gives some nice results:



Basically it does a simple nearest-neighbor ray march in all directions and compares occlusion information using a depth map.

#5 Sounds expensive. I think that using a a texture is prolly the best bet. and possibly offers a way to make a resource for TGE and should make it easy to run on crappy hardware.

#6 Actually, it's one of the cheapest SSAO algorithms out there. Precomputed ambient maps will always be faster, but they really don't work well for dynamic scenes.

#7 Dynamic AO is an expensive feature. The thing, though, is that it's really no more expensive to run it on the entire scene, than it is to pre-bake some of the scene, and have some of the scene dynamic. SSAO is the way to go. It's an approximation, which means it has errors, but it's currently a very hot research topic, with lots of material being written about it.

#8 Would like to know what it is they are using for the new abient light approach in "Crysis Warhead" read an interview and it has far better results than the SSAO they used last time and they say it has 0 performance hit. Actually they are saying that Warhead will run faster on lower hardware and look better do to the fact that the code is that much more optimized now.