Camera-Space Cubemap Faked AO

[nbohr1more]

Ever since the light baking thread I've been thinking about the following question:

 

"Why not use GL Subtractive Camera-Space Cubemaps to approximate AO in all materials?"

 

As the angle of the texture/material trends away from the viewer, it will get darker a la AO.

 

So...

 

1) Can GL Minus One be applied to a cubemap stage in a material definition?

 

2) Is it still too expensive to apply cameracubemap to all (or most?) materials in a scene?

 

 

Similar discussion for the OGRE engine:

 

http://www.ogre3d.or...=37128&start=25

 

Edit: filter key word?

Edited September 20, 2010 by nbohr1more

[nbohr1more]

(For my own reference because I'm on work PC more than at home to try these things )

 

textures/your_desired_editor_texture_folder/your_texture_name
{

description 	"Add here a little description of your texture"
qer_editorimage textures/your_file_folder/your_texture_name_ed

bumpmap 	textures/your_file_folder/your_texture_name_local
diffusemap 	textures/your_file_folder/your_texture_name
specularmap 	textures/your_file_folder/your_texture_name_s

{
forceHighQuality
blend filter
cameraCubeMap env/fake_AO
texgen reflect
}


}

 

Since it's just an effect, we probably don't need to actually GL subtract?

(unless filter does that anyway? not light reactive...)

 

Tests pending...

 

(unless someone chimes in and says this wont work at all... )

Edited September 20, 2010 by nbohr1more

[nbohr1more]

It may still be useful to make the darkened area light reactive...

 

textures/your_desired_editor_texture_folder/your_texture_name
{

description 	"Add here a little description of your texture"
qer_editorimage textures/your_file_folder/your_texture_name_ed

bumpmap 	textures/your_file_folder/your_texture_name_local
diffusemap 	textures/your_file_folder/your_texture_name
specularmap 	textures/your_file_folder/your_texture_name_s

{
forceHighQuality
blend 	gl_zero, gl_one_minus_src_color
cameraCubeMap env/fake_AO
texgen reflect
zeroclamp
//alphazeroclamp
colored

}


}

[LEGION]

If you want someone more qualified than me to take part on your 'conversation' you should move this to the Editors Guild, oh, I think you can´t.

[nbohr1more]

I try (as much as possible) to keep my weirdo rambling out of the official spaces LEGION ...

(Trying to be courteous to the editors).

 

This is the next best option other than "Off-Topic".

 

(When I post 90% ramble, it's hard not to clutter things up anyway... )

[LEGION]

Ah, come on. From what I understood it´s an alternate method for this light baking, and from light baking the TDM can benefit. It´s good for better performance and even better for SOFT SHADOWS. The only downside is that these soft shadows are not affected by moving lights like a lantern from a patrolling guard f.e., right?

I would have to see it on my screen, Softshadows and a moving light-source I mean, to judge if it´s illusion-breaking or not.

 

If this is not about Light-baking then it´s a reason more for moving this to the editors guild!

[nbohr1more]

You have gotten the gist of the Strombine concept but I'm afraid that this is a different topic LEGION

[LEGION]

but I'm afraid that this is a different topic LEGION

 

See, what did I said?

[nbohr1more]

Actually the light from a torch should overwhelm the soft-shadows baked into the Strombine projection image but if a soft-shadow disappears and a hard-shadow appears right near it, it may be a bit jarring... (just to clarify your previous post)...

[LEGION]

Actually the light from a torch should overwhelm the soft-shadows baked into the Strombine projection image but if a soft-shadow disappears and a hard-shadow appears right near it, it may be a bit jarring... (just to clarify your previous post)...

 

That´s what I thought. But it should be fine for outside-areas or shadows from big buildings when I think about it. I really would like to test that in that map, but I need to know how I can:

spawn a

 

-lantern

and as we´re at it:

-arrows

 

I can´t get the classnames pointed out in the console. So, as long as no one else is answering to the main topic you could help me out here. Isn´t getting off-topic funny?

[nbohr1more]

 

If you are thinking of cheating by adding inventory to your in-game character I don't have any tips of the top of my head but you could look at the inventory selection area of the start map and review the Start Mappers guide in the wiki... I'm sure the number of items can be adjusted that way...

 

(Got side-tracked during my Dark Radiant training and started exploring these odd-ball ideas... )

 

(Edit: yep, they are in the wiki... )

 

 

(Edit Edit: Specific wiki section. )

Edited September 20, 2010 by nbohr1more

[LEGION]

I´m still stuck during the Tutorial (so time-consuming) and I can´t figure out how to spawn that items, I don´t want to cheat (noooo), it´s only for test-reasons! I really should go on with that Tutorial, I always have the habit to start with things that one should do later...

[nbohr1more]

Cubemap gradient concept

 

I presume that the cubemap should have a gradient like this:

 

[STiFU]

That wouldn't look right. Try it and stand next to a wall at a steap angle: FAIL! Simply relying on the angle for AO estimation is a little too big reduction of the problem. Besides, something like this could be realized a lot better on the interaction.vfp side of things.

 

Also, the referencfed thread is talking about a different technique, which is used for computing lightmaps: FAIL AGAIN! The author is talking abnout something called "cubemap SSAO", while the approach he descibes does not take place in Screen-Space as it seems, so I wouldn't give too much about what he is saying.

[nbohr1more]

Angle based occlusion is part of all current real-time SSAO implementations.

 

Yes, if the filter is too strong it will look wrong but I have seen some pretty wrong looking AO demonstrations from ATI and Nvidia. They exaggerated the effect to make sure you could easily tell the difference.

 

If I'm not mistaken, ordinary AO maps only include depth based AO. So having cubemap angle based AO and and AO depth map should complete all the basic requirements (other than that the depth based AO is not dynamic...). Yes, these are crude AO methods and do not factor in occlusion interactions with the light-space.

 

That thread was the closest reference to the technique I am proposing but relies on six cubemaps instead of one (and is not piggy-backing on the camera system for it's engine...).

 

My technique probably bears a closer resemblance to this:

 

http://wiki.polycoun...volved+Cube+Map

 

...except we are reducing the light-space to the absurd "If it faces me it's brighter".

 

If applied in a subtle fashion, it may still enhance the look though.

 

But yes, there are still many questions:

 

1) Will the Normals in the Normal Map react to the filter correctly? If not we are doing AO per poly which would look very ugly...

 

2) How do we ensure that the Cubemap correctly occupies the camera-space so that is occludes correctly? If this were not reliant on Doom 3's fixed camera space calculation, we could adjust the Z factors more accurately without having to play with the cubemap image as much. (unless camercubemap has variable proportion controls????)

 

 

Finally, I would be careful about referring to anybody's experiments as "FAIL", especially when you have claimed that Thief 2 has AO:

 

http://modetwo.net/d...post__p__222499

 

T2 uses prebaked lighting with ambient occlusion

 

This is an absurd notion as AO is dependent on view space and baked lighting does not react to view-space. Yes there are occlusions but they are due to GI not AO.

Edited September 21, 2010 by nbohr1more

[rebb]

Ambient Occlusion isn't dependent on the View, only SSAO implementations are.

 

Classic Ambient Occlusion is a way to approximate certain Global Illumunation effects on a surface based on surrounding geometry which blocks light coming from the environment.

 

It pretty much sets up a hemisphere of rays on a sampling point and checks for occluders, outputting a certain occlusion value in to the sample afterwards - i implemented AO into the old Q3Map2 Lightmapper ages ago when nobody even knew what AO is even supposed to be, it was pretty new and sometimes called "dirtmapping" ( because the AO term can be used to drive grime or dirt effects ).

 

So it's not absurd to bake AO into textures or to vertices, this was and is being done a lot these days.

 

SSAO ( and it's many variations ) is the realtime version of AO that doesn't require any baking, but has it's very own set of problems.

 

I must admit i didn't really follow the thread, are you trying to simulate SSAO using a cubemap attached to the viewer ?

[STiFU]

Hehe, well this is the first time that I read, that SSAO is angle-dependent. I'd really have another look at the wiki articale about Screen-Space Ambient Occlusion if I were you (I don't want to dis you, but it seems a little you didn't quite get it yet). Only different depth values surrounding a pixel are analyzed to compute occlusion. This has nothing to do with the viewing angle unless you relate the depth between the reference pixel and an analyzed candidate to the viewing angle, which is an unneccessary step to my knowledge.

 

Don't take my comments too seriously though... So sorry about the "Fail", it was just intended funny. But what I stated is still technically correct. As I said, I don't know if it was specifically used in T2, but AO has been used for computing lightmaps in numerous engines, like the quake 3 engine with the advanced map compiler q3map2 (Google for it and you'll find it supports AO). Computing lightmaps with AO is in fact possible because it is not view-dependent unlike SSAO, hence the name SCREEN-SPACE Ambient Occlusion. So if I were mean, I'd add another "FAIL" at this point too, but I'm not gonna.

 

Edit: Oh my God, this calls for a *LOL*. Seriously, you Rebb are the one who implemented AO for q3map2. Awesome and thanks a lot. It greatly improved the visuals on my q3 trickjump maps...

[rebb]

Hehe, well this is the first time that I read, that SSAO is angle-dependent.

 

The newer and better-looking Variations of SSAO do take angle the surface-normals into account for a cleaner result, maybe this is what nbohr1more meant with the angle-basedness.

[rebb]

Edit: Oh my God, this calls for a *LOL*. Seriously, you Rebb are the one who implemented AO for q3map2. Awesome and thanks a lot. It greatly improved the visuals on my q3 trickjump maps...

 

That's nice to hear .

 

For a long time it seemed that nobody really knew that to do with the ominous -dirty mode ( should have been called something else, but back then the team AO wasn't very widespread either ).

 

Afaik there have been some improvements by the UrbanTerror team, who turned it into the -lightflood mode.

 

Oops, thread derailed a bit, sorry.

[nbohr1more]

I was hoping you would chime in, thank you.

 

Yes, the idea is really simple, I think, (probably dumb too...), but we simply make things that are at an off angle to the viewer occlude. We are using camercubemap to track the angles to viewer.

 

Yeah, AO is a confusing term these days but I imagine that most modern light-maps do not use AO for GI but instead use a more accurate GI method. So using AO to describe occlusions in a baked GI is bound to lead to confusion. I suppose you could instead call it Global Occlusion. So you would have GI and GO? (Two sides of the same coin?)

 

Edit:

 

Don't worry about derailing any of my threads..

Edited September 21, 2010 by nbohr1more

[rebb]

So it's like shading everything based on the facing-ratio to the viewer, essentially it would be like a lightsource sitting on the player i guess - and it would probably look a lot like that too, and not so much like an SSAO effect.

 

Say you have a chair sitting right up to a wall, and you view the chair head-on, you wouldn't get any AO-like shading where the chair meets the wall for example.

 

If the facing-ratio is exponentiated in a certain way it could also look like a cel-shading.

You could blur this and apply it as a post-process, but that would probably require rendering the scene more than once per frame to capture the facing-ratio based shading.

And once you're doing that, you can just as well use that extra renderpass for a depth-capture instead, and use the depth-capture for a "real" SSAO postprocess step.

 

That is, if i understand the concept correctly.

[nbohr1more]

You've got it. It's an attempt at real cheap (hacky?) SSAO method. I was trying to see if pre-computing the occlusion via a cubemap would save a little performance but there are TONS of caveats as both I and (now) you have pointed out.

 

It still might be a cool post process effect but there are probably better uses for those passes.

[STiFU]

You've got it. It's an attempt at real cheap (hacky?) SSAO method. I was trying to see if pre-computing the occlusion via a cubemap would save a little performance but there are TONS of caveats as both I and (now) you have pointed out

The problem is that the occlusions are scene-structure dependent but you seem to want to apply the upper cubemap to materials, which would just result in what rebb just described: Shading as if there was a lightsource on the players head. For this method to give proper results, you'd need a cubemap for every possible pixel at every point in the map so that you'd essientially remove the check for occlusions in the AO-factor calculation. This is of course impossible and would also still just result in a lightmap.

 

JC Denton once suggested to store AO information in vertex colors of brushes to get the desired look, which would be a real cheap implementation performance-wise, but of course it also comes along with considerable limitations, like no AO for models and no support for dynamic scenes. SSAO is still the way to go, as long as there is no lightmap support, so that we can use proper GI.

[nbohr1more]

Hmm... Maybe just horizontal parallax occlusion and have the vertical cubemap orientations all white... Again, it's still pretty hacky...

[nbohr1more]

If dynamic cubemap scripting were possible, you could collect one cubemap per scene then reduce it to a filter map ala similar to how this method is a radiance map:

 

http://wiki.polycount.com/DiffuselyConvolvedCubeMap?action=show&redirect=Diffusely+Convolved+Cube+Map

 

If you could use a light reactive filter (GL Minus One?) then it would be like a precomputed screen-space AO map similar to HL2's precomputed radiance. But it would require mappers to collect cubemaps for every room and would depend on the ability to script cubemap blends...