• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
dpadam450

Baking Occlusion Maps

7 posts in this topic

I'm working on baking Ambient Occlusion for my static objects. I have them unwrapped to a light map texture with no shared overlapping UV's.

For each of those pixels I compute the occlusion only, no shadows, light color, emission. Just occlusion. And this includes self-occlusion as well as occlusion from any other objects in the scene.

I'm wondering what peoples techniques are and how fast they are. My current technique can generate a 512x512 occlusion map in 2.9 mins. I'm still working to speed this up and think I may potentially be able to get this to about 1 minute. 512 is relatively high resolution I would think for an occlusion map for an object since it will just get blurred, in my opinion. The results are fine in terms of texture quality, I just want to know how fast other algorithms are because I have to bake a ton of objects and want to know if I should maybe go to a CPU ray caster. Anyone else have specs that they have or can run on baking a 512 size texture?

Current algorithm on GPU:
Render objects world position and world normals into the ambient occlusion texture.
Read the normals and positions to the CPU.
For each pixel in the occlusion texture that has a normal (IE a triangle mapped to it and wrote a normal)
--->Set a camera in the world at position from texture

--->Set camera orientation based off of the normal

--->Cull the scene against camera, and render the scene. This is the depth buffer from the pixels point of view on the object.
--->Take all pixels in the depth buffer, compare them to generate an occlusion value for this pixel

I render the depth buffer to a 4x4 texture (so 16 depth samples per pixel). Could do 8x8 but it really doesn't matter after the blur is applied.

0

Share this post


Link to post
Share on other sites

I have a project I've been working on at home that uses Intel's embree ray-tracing library to pre-bake various kinds of GI. I fired it up with Crytek's version of Sponza (~262K triangles) and baked the equivalent of a 730x730 AO map using 625 rays per sample point, and it completed in about 18 seconds using all 4 cores of my Core i7 2600. So yeah, I think you can do better than 3 minutes. tongue.png

 

The way you're baking AO definitely works and is fairly easy to get going, but it can be really slow since there's a lot of overhead from setting up the GPU and reading back the results for every sample point that you bake. The GPU also never really gets fully utilized, since it has keep serializing. A ray-tracer on the other hand can be really fast for baking occlusion since it's trivial to parallelize. Embree is very very fast (especially if you only want to know if a ray is occluded instead of finding the closest intersection point), and GPU ray-tracers can be extremely fast as well. At work we use Optix to bake GI, and we can bake multiple passes for huge scenes in a minute or two on a beefy GPU.

I should also point out that it sounds like you're not quite baking AO correctly based on your description. To get a proper AO bake for a sample point, you need to sample occlusion in all directions in the hemisphere surrounding the normal. With your approach you'll only get directions within the frustum which can only cover 90 degrees, so you'll miss the sides. Typically when using a rasterization approach you'll render to a "hemicube" by rendering in 5 directions for each sample point. You'll also want to make sure that you weight each occlusion sample by the cosine of the angle between the sample direction and the surface normal (N dot R), otherwise it won't look right. With a ray-tracer using monte carlo integration you can actually "bake" the cosine term into your distribution of sample ray directions as a form of importance sampling, which lets you skip the dot product and also get higher quality results.

2

Share this post


Link to post
Share on other sites

I can change the FOV to get most of the hemisphere (its a bit warped of course), but it works. I also don't read back anything on the CPU. I bind the depth texture and render a 1x1 pixel point to the final Occlusion texture using a shader to compute occlusion. But yes even doing that as I said is slow.

I wanted to test this to see if it would be faster than a cpu approach since it sounded like it may have been until I got 3 mins.

0

Share this post


Link to post
Share on other sites

Is there an article on how to use Embree for baking occlusion? I built the code but I'm not sure how to extract this to put into my own engine / bake occlusion.

Edited by dpadam450
0

Share this post


Link to post
Share on other sites
I bake AO "inside out" (sky visibility) by positioning hundreds of directional lights outside the object, pointing in. Each light renders the object to a 512 depth buffer, and uses that to apply a small amount of light to a 1024 AO texure (by rendering the object in lightmap-UV space). This produces blurry results, and doesn't work for indoor areas / cavities, but only takes a few seconds on a GeForce7, so I'm able to do it for a whole level during the loading screen (where the GPU was idle anyway).
2

Share this post


Link to post
Share on other sites

MJP - Sounds kind of lame if I can't instance geometry and have it have a matrix. IE if I have instanced geometry I have to tranform all verts into world space for each instanced mesh and load those into Embree.  Even for non-instanced geometry, when I export it, it still has a transform applied to it so that its positioned in the world properly.

Hodgman - Yea can't do it that way because of the cavities/indoor. Plus that doesn't really work well in outdoor forests either. If you have a few close boxes, but they are under a ton of tall trees, then it will get no direct lighting at all because leaves will cover every one of those depth buffers, so I have to start at the object and go out just like SSAO.

 

BTW, I did get it down to 1.8 mins just by getting rid of my "preview" where I show the output to the screen for each camera to see it working in real time.

Edited by dpadam450
0

Share this post


Link to post
Share on other sites

Another idea -- at the moment you're doing 'for each position, trace 16 rays', you could instead use the algorithm from this ray-tracer, which is 'for each ray direction, trace rays through a million positions', which maps better to GPU rasterization hardware and might result in less overall passes of the scene.

Hodgman - Yea can't do it that way because of the cavities/indoor. Plus that doesn't really work well in outdoor forests either. If you have a few close boxes, but they are under a ton of tall trees, then it will get no direct lighting at all because leaves will cover every one of those depth buffers, so I have to start at the object and go out just like SSAO.

My very cheap hack to deal with that is to mostly place lights in the upper hemisphere, but also place some in the lower hemisphere, and to not render the ground into the depth buffer, so it doesn't cast shadows upwards onto objects. This allows objects that are covered by a 'canopy' to still receive some level of "AO" gradients.

 

Stealing inspiration from the above link, you could also solve this issue completely by rendering the shadow maps with depth-peeling, which allows you to measure the length of the ray from the surface position to the nearest occluder, rather than the "most outside" occluder.

Edited by Hodgman
1

Share this post


Link to post
Share on other sites

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
Sign in to follow this  
Followers 0