Yes sorry I got confused with the q3map3 "-dark" feature, which was the half-arsed version, not this one.

Good good. Just a silly name for it then. 

Source-code not included though? Or am I missing something. 

hogsy, it is a diff against a git revision.

Are the original id1 wad files somewhere? I wanted to re-compile all the maps to try this but got a lot of missing textures when I used wads from my collection.

base.wad
jr_med.wad
medieval.wad
metal.wad
start.wad
tim.wad
wizard.wad 

with: http://imgur.com/DeokKU6
without: http://imgur.com/xSjYZ6f

Free Beer unlocked. 

This is good timing too. Right at the start of a fresh year of mapping. I'm excited! 

Anything else we can pilfer from the Quake3 tools? :P 

So much happy... this is fullbright, with JUST the AO showing:

https://dl.dropboxusercontent.com/u/161473/Misc/QuakeAO_2.jpg

https://dl.dropboxusercontent.com/u/161473/Misc/QuakeAO_3.jpg 

 

"Are the original id1 wad files somewhere? I wanted to re-compile all the maps to try this but got a lot of missing textures when I used wads from my collection."

Just use bsp2wad and re-extract them. Takes all of a second or two.

http://www.quaketerminus.com/tools.shtml 

 

Now I want to recompile all my old levels... :O 

Stop adding new stuff to Quake! I still don't know how to do skyboxes or colored lights or Quoth or knight models! 

 

I thought that id already did that in E1M3 by the teleporter secret...

Or was that supposed to be the Quake logo? 

Ugh, E1M4 I mean.

More coffee or something... 

 

I want thong shading more than anything now! 

awesome screenshots, WarrenM! Glad to see it working :)

Anything else we can pilfer from the Quake3 tools? :P

heh, that's what I was thinking.. Looks like the most interesting thing is the proper radiosity, but i'd guess that would be harder to copy.

btw here's a neat post in the discussion thread from when this was added to q3map2:

During production of Star Wars: Episode II, ILM didn't have time to render a real radiosity pass for every frame of CG they needed. Where they could get away with it, they used a key/fill/highlight setup, an additional "bounce" light to approximate the predominant color of whatever the radiosity light would be for a given scene, and used an Ambient Occlusion pass to sell the whole effect as true radiosity. You know the old mantra of CG: the look is all that counts.

Since we have real radiosity with Q3Map2, and we have time to impliment it when we compile our maps, we don't really need to use AO to simulate GI. AO does have another effect, though, in that if you add a little noise to the AO pass and multiply it on top of an already-affected-by-radiosity lightmap, a given surface will be made to look "dirty" or "grimy." Like a statue that is tough to clean and is very old or something. link 

mainly in that i usually hear GI and AO used interchangeably to describe the same effect. This quote makes a distinction as if AO is a cheap way to imitate GI. 

I think it attacks it from the other direction. GI bounces light around, leaving darkness in the corners. AO adds darkness into the corners directly. Heh... 

As I understand it AO usually looks at just the immediate area surrounding the sample to determine how occluded it is and darken the sample appropriately, with no attention paid to light bounce like GI does. 

Classic AO approximates how "obscured" a surface point is by other geometry, over a hemisphere.

Actual GI is about calculating bounced light effects.

If you shine a spotlight at the floor next to a wall, GI will light up that wall via light bouncing. AO will not. 

Here's what I'd like to see:

Nondirectional light cast from sky surfaces, affected by dirt-AO. Regular lighting calculated from there and added on top.

(also thong shading) 

lunaran: i do have a local build of light.exe with nondirectional sky surface lighting, it looks a lot like GI except without bounce lighting. But it looks really good in outdoor areas which normally look flat with the existing light tool's "sunlight" implementation.

The one thing i didn't solve is a good uniform distribution of points on the half-sphere where i place the "suns" I just iterate over latitude and longitude which means there are too many lights near the pole, and it means that lights are arranged in rows and columns which produces obvious bands where a whole row of suns' shadows line up. 

metl, have a look at:

http://mathworld.wolfram.com/SpherePointPicking.html

If instead of randomising the values of u and v in [0,1] you just had a uniform grid of values with u in [0, 1] and v in [0.5, 1] you ought to get a nice even half-sphere distribution out of it. If you still get lines, maybe try rotating the u values between "evens" and "odds" for each v, like 0.1, 0.3 ...0.9 then 0, 0.2,..,1. The key to it is to use arccos(2v-1) for the latitudinal angle, anyway.