Baked ambient occlusion

#21 Thats interesting, I looked at his engine the other day.

It looks like he's doing some light bouncing (looks like sort of a photon mapping type of affair). He mentioned using 60 bounces somewhere.

The problem isnt actually calculating the AO, its being able to render with it (which wouldnt be a problem, if it werent for missing features within the mesh format).

#22 @Phil - I questioned him about it... he is using a separate UV set, wrote his only mini-raytracer to generate the maps, and is using a simple packing algo for the textures (split odd shaped triangles... pack in order from largest to smallest).

As far as dynamic objects... they're totally ignored.

So nothing magical there.

You might want to ping Fairfax on the new mesh format embedded into the DIFs generated from Constructor. Since they are lightmapped he must have a separate UV set already. That might be something to take a look at.

#23 Actually, one of the things that kinda silently snuck in with TGE 1.5.1 is allowing the tsMesh's to have more than one UV channel (look for getUVs()). This change should also make it into TGEA 1.0.2. We ended up using something totally different for the embedded static meshes but I thought this change was worth bringing over.

For now there is no way to use the multiple UV channels but it would be pretty straight-forward for someone to alter a DTS exporter to do it.

#24 Matt... hah... you guys rock!

Now to pester the Dark Industries guys to slip that option into the 3dsMax DTS exporter! :)

#25 @Phil - Well, you still have the tools problem. Who owns and updates the exporter? The trouble is, I just dont think anyone has time or money to really support exporters.

Have you looked on verse?

www.quelsolaar.com/verse/pipeline.html

www.uni-verse.org

verse.blender.org

#26 Just a quick mention, XNORMAL the incredible and FREE Normal Mapper (and Ambient Occlusion maps). The tool can be helpful for Ambient Occlusion maps.

santy.xnormal.net/projects.aspx

www.xnormal.net

#27 Looking at the Unreal Tech Video from GDC this year they mentioned realtime ambient occlusion done in a pixel shader. A quick search and i found the technique which was developed for Crysis.

This video shows it in action. Even as fake as it is... its extremely impressive looking and is better than any other technique i've seen.

If anyone gets it running in Torque i'd be very interested to check it out.

#28 Tom, there is a paper by one of the valve guys about a technique similar if not identical to Cryteks. Basically it involves another texture for the AO bake. Almost like a "directional lightmap" where they encode the AO from some sample directions into a texture (I cant remember the exact details, but consider it like a really really low resolution version of the hemisphere you'd use for sampling radiosity) encoding that into what is essentially an occlusion map.

The technique when I was reading the paper about it sounded pretty bleedin simple really. Which I'm sure it is.

But right now dont have the energy to play with it and tsMesh just warps my brain sometimes :)

One thing T2 could uses is a well documented internal mesh format (hint hint).

#29 Hey guys,
Im not sure if this is what you mean but i have previously gotten multiple UV's to work on a single model.

www.garagegames.com/mg/forums/result.thread.php?qt=69217
I never got round to sorting it out via a shader as mentioned the thread.

Hope that helps :)

#30 @Phil - Yes Crysis uses that technique for indoor areas which is a baked solution similar to HL2. Still they developed another technique for outdoor scenes... a Screen Space Ambient Occlusion... where only the depth buffer for the scene is needed. The technique is stupid simple... it just analyzes the relative depths of neighboring pixels.


That looks pretty damn good to me... why bake anything offline if you don't have to.

#31 Because that technique probably requires a huge ass pixel shader to be able to do any of that :)

Looks kind of strange though. But a nice idea.

One thing though, they use deferred shading anyway, so the AO pass is probably based off the Z write pass for the deferred shading I'd guess. Or they use MRT to write the depth pass into the depth and AO buffers at once.

Would be fun to try these things out, but frankly, it'd require a ton of cool art to show it off and I've got NO art, never mind cool art :)

#32 Well worth doing even without cool art :) im sure it would make allot of people rather happy. If you want I can always shoot over some content?

#33 I'm new to torque, but i'm pretty sure I understand ambient occlusion (I do CG stuff, i use AO every day). There seem to be 3 things being confused here:

1) Pre-baked ambient occlusion for an item with a unique, non-tiled UV, usually baked out and applied to the texture in multiply mode.

2) Realtime ambient occlusion, either using the old method of alot of shadow casting lights, or Screen Space Ambient Occlusion, both very expensive.

3) Ambient Occlusion as a lightmap, requiring a second UV, which multiplies the light values it receives (if you baked out a lightmap yourself like you usually would, and then baked an ambient occlusion map, you'd combine them in photoshop by setting the ambocc layer to multiply).

1 is easy, 2 is fancy and really expensive, and 3 is no more expensive than having a normal lightmapped object because it's pre-baked anyway - who cares what's in the pixels. Therefore, the following things are missing in TGEA (but I could be horribly wrong):

- Ability to export a second set of UV's for the lightmap - would require alteration of the DTS format aswell as your chosen DTS exporter.

- Ability for TGEA to calculate ambocc in it's lightmapping system.

Now what I'm confused about is this, because i'm a nub at Torque. Torque already does lightmapping doesn't it? when I was playing around in the editor it was, but maybe it was only doing it on terrain. Does it automatically make your second UV set for you or something? If it already has this function, you won't be able to bring in your own lightmaps, but someone could add in ambocc functionality to the existing lightmapper and you'd pretty much have what you want :)

#34 Like this, where the one on the left is straight directional light/ambient, and the one on the right has ambient occlusion multiplied over it:

#35 Well I know on the forums somewhere theirs reference to a gentlemen extending the 3DMax DTS exporter to support a second UV layer (and claimed it was pretty easy todo), and the engine I believe already does support more than one UV set as mentioned above.

Personally I would just like to see 1) first, and support a simple second UV channel would make a big difference.

Interior (.dif) objects are lightmapped, and can be relight ingame (along with the terrain).

At the moment I think the lack of some form of AO is killing TGEA, just compare it to the other engines and you can see the difference.

I had started another thread on the subject in the shader section in regards to per-vertex AO, but mostly got boo'ed out of that.

#36 I can't really think of many engines that bake AO to lightmaps.

Source (HL2) calculates and bakes radiosity, which is a whole other kettle of fish. Max Payne, Serious Sam II do the same thing.

Unreal3 pretty much does what TGEA does, but you'll notice people tend to have alot of lights in levels that are told to only affect the lightmap, to fake light bounce and stuff.

CryEngine 1 did what TGEA does, but in addition, for terrain it baked a fake kind of ambient occlusion (lots of shadow casting lights arranged in a half-dome).

Unity doesn't have any inbuilt lightmap functionality at all, so it's up to you to make the lightmaps.

So, with that second UV thing, that allows us to pre-bake lightmaps and bring them in I think. This might require custom shaders or overwriting the lighting kit thing, I dunno. You could then use tools like Gile[s] to bake your lightmaps, however, what really stinks is you basically have to recreate your entire map in whatever program you're using so that the lighting is right. So yeah, it would be all far more satisfactory if TGEA had this functionality - either AO, radiosity (like Source), or both.

#37

Quote:that technique probably requires a huge ass pixel shader to be able to do any of that.

Quote:Realtime ambient occlusion, either using the old method of alot of shadow casting lights, or Screen Space Ambient Occlusion, both very expensive.

Its a misconception that SSAO is really expensive. Its not free, but its relatively cheap for what you get out of it. Its also scalable to some extent trading quality for performance... you could even disable it for low spec GPUs.

First off it requires a screen space depth texture... so you do need to do a z-pass, but your buying early z rejects from it while your at it.

Second its an image space technique... you just need one more draw call with a full screen quad. Per-pixel you randomly sample neighboring depths to generate a "blocking" factor. This factor is modulated with the screen buffer as the ambient occlusion term.

That's a simplification of the Crysis implementation... but that's it. No raytracing or spherical harmonics involved.

This Gamedev.net thread has a pretty faithful reproduction of the original technique.

The same guy from the above post has an article on his personal site where he mentions that his implementation works in a 2.0 shader with a little optimization.

This other post has an interesting variant that uses a specialized gaussian blur.

A blog post with links to alternate screen space AO techniques.

#38 This is the method I am currently looking at for SSAO. There is another method, described in a paper (coming soon, supposedly) that some nvidia guys presented at GDC this year which is similar to horizon mapping. That should be interesting.

#39 Oh... a low-pass filtered depth buffer... thats freaking smart.

#40 Yep, and with a Z-fill render manager, you can easily just assign a render-target during z-fill, and output depth values to it, so you need no MRTs or anything.