Advertisement Jump to content
  • Advertisement
  • entries
  • comments
  • views

Ambient occlusion

Sign in to follow this  


I've been working on an ambient occlusion module for my ASE2Bin model viewer, and tested it on a Minas Tirith building.

There are many issues with the way it is currently done. The main one is, while waiting for a proper lightmapping implementation, the ambient occlusion values are stored per-vertex in a color component. And per-vertex means being very tesselation dependant. Unfortunately, the building below is on the "good" side; i've seen many buildings that didn't behave as well.

Initially, the algorithm casted for each vertex 256 random rays in the half hemisphere pointed by the vertex normal. Each ray intersects the scene, and the distance is used to compute an "ambient" color. All the results of the rays are averaged, and the end result is a color to store per-vertex. That didn't work very well, because often, a vertex is "inside" a wall, while it was logically on the wall, but the modelers prefered to do it that way to save polys and avoid T-Junctions.

I've experimented an alternative algorithm, based on casting rays for each triangle, instead. 256 rays are still thrown into the scene, but this time from a circle more or less on the center of the polygon. The ambient color of a triangle is then added to its 3 vertices, and in a next pass, all the vertices ambient values are averaged. The result is looking much better, but it's still tesselation dependant, and i don't think there's any way to fully fix it.

Here's a result on a single building:
LEFT: diffuse lighting only
RIGHT: diffuse + ambient occlusion

Sign in to follow this  


Recommended Comments

I wonder whether it would look better if the tesselation were more "architechtural". Here, the arch-tops are tesselated in a very unnatural way. Were the triangles arrayed in a more symmetric and construction-style layout, it might look pretty good. Instead they look like auto-tesselation, with large triangles surrounded by slivers.

Share this comment

Link to comment
Guest Anonymous Poster


Wow, this is getting interesting.

I guess it would look damn fine if you further subdivide the mesh based on how much the illumination coefficents vary...

Unfortunately you already have 5 mill polygons and adding another 2.5 might be overkill just for the sake of cool lighting (sniff)...
And second, it would probably be messed up by your lod algorithm (if it is not already in its current form).

And... doing it per pixel would blow the chips off any graphics board in the world (both memory and gpu ;-)


PS: Your devlog is really nice. Keep on going!

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!