Ambient Occlusion by Mike Blackney

This one could be very useful...I can't wait to try it out.
Do you have any samples of this in use?


Rawn

And a kinda wood panel texture:

Heh yeah it is one of those terms. I think it's probably intentionally obsure so that only the pros will do it, or something. Occlusion just means 'to hide' and the ambient is talking about ambient light. So it really means, 'hide from ambient light' and it's used when talking about pit and crevasse shadowing.

Everywhere that there's a crack, pit or dimple on a surface, the pit is shadowed because the only light that can reach the deepest part of the pit to reflect back is light from directly overhead. This means that all the ambient light (which is light that bounces around the atmosphere and off other objects, rather than direct light coming straight from a light source) tends not to reflect and pits look darker. Here's a great primer with images of why you might want AO in game texturing: http://www.gamasutra.com/features/200...ll_pfv.htm

I hope that's understandable...

Yeah, except that until recently more often than not people have rendered out ambient occlusion using their rendering app and taking a good ten minutes for a high-quality version. Using the normal to make an AO map is reasonably new and since CrazyBump recently started offering it I figured FF could do it no sweat

Very clever filter [ like all your filters ] and interesting about lighting - had a look at your web site very impressive - one comment though veiwing your site [ using IE 7 ] the sub-heads in a number of places partially overlays the text above making them almost illegiable

We have a working AO implementation stashed
It could use some support for bent normals for even more realistic lighting, along with proper handling of seamless (ray wraping) and non-seamless (range limitation) cases.
But most importantly, it needs a new rendering UI logic, since it's slow as hell for the first block due to the amount of precalculations needed, but then it gets faster and faster -- might be some sort of a cached data which has some kind of "precalc" progress bar, with intermittent storage much alike the relighting scheme that was recently discussed in a neighboring thread.

Note: Above posts do not imply that this code will be released in _any_ future versions. Currently, it's "not ready for production".

The shadows look much nicer, but the highs look depleted.....probably because of the plateaus in the sample.....would like to see it on a sphere.....

i also notice on this last, something i've seen when working with the noise components... lighting doesnt just re-light or re-shadow or highlight or diminish, it also is changing the basic shapes and forms at times, or at least the 'apparent' shapes and forms. i would think this would be something to avoid in a true lighting scheme. it's kind of cool in an artistic view, but for true lighting, particularly in 3d environment, i'm not so sure it's desirable.

p.s. when i said 'last' here, i was referring to the stones images, not the spheres. that spheres one was posted while i was writing.

onyx, look at the two stones images you posted. they are not exactly the same in form any more. the lighting actually changed the shapes in places. you can tell they are the same image because mostly the forms of the two line up exactly, but not everywhere. do a side by side comparison and you'll see what i mean. or better, do them in layers and with a lowered opacity settign on the top one.

hehe, well, i suppose if you changed everything to white or everything to black, the form/shape of the image would change