Brushes look good! But the torches, maybe try this

http://necros.fov120.com/post.php?postID=5 

If you map using Radiant you could do a test with Q3bsp + Q3MAP2 inside FTE or DP, which has the 'floodlight' and 'dirty' compiler switches. Essentially a form of AO. It can also do bounced lighting. Otherwise just spamming a ton of large radius low intensity lights in a 3D grid kind of works, though it won't give you the high res crispy-outlines kind of AO. 

I just remembered Slapmap's awesome lighting technique.

http://slapmap.wordpress.com/2013/04/23/outdoor-lighting-and-fake-g-i-in-quake-with-examples/ 

yeah that is bloody good, as as the chap says himself, it's fairly easy to spam a load of lights around like that.

That said, AO done in light.exe would be nice 

http://i.imgur.com/kQavNMu.png
http://i.imgur.com/Q0wP3Vo.png 

On the wiki. 

That looks great, and is basically what I was rambling about :)

Something like that works great outdoors, I wonder how it could be used for indoor stuff as well. Perhaps creating an array of minlights around prominent indoor light sources as well? I would have to test it but it could work. 

The shadows cast by the wall torches. It's almost like some sort of fake AO effect.

I wonder if an AO technique could actually enhance the base quake aesthetic. All the big bulky architecture could possibly make it look really nice. It looks fantastic in Minecraft (I think they use some sort of fake AO effect there) and really makes the blocks pop.

Unreal (1) had a nice effect that I always liked as it made things seem really solid - I think it just darkens the seams where polys meet in a concave way.

Also, q3map2 has the -dark switch, which

"Enables darkening of lightmaps at brush/lightmap seams. Sort of like a half-assed occlusion pass, ends up looking a bit Unreal 1-ish. Very subtle."

I'll add it to my tyrlight wishlist... 

It did make it virtually impossible to do rounded concave corners that didn't look like ass though.

I always assumed Unreal didn't pad edge pixels in the light maps, causing interpolation to leak in the black margins around the edges.
I'm not sure if that's what was happening or it had something to do with the light attenuation formula. 

if it always darkened edges the same amount it wouldn't be good, but if it took into account the angle between the faces and interpolated between vertices, it'd probably be pretty awesome. 

if it always darkened edges the same amount it wouldn't be good, but if it took into account the angle between the faces and interpolated between vertices, it'd probably be pretty awesome.

Yeah i assume it's shaded based on angle 

I don't know if i can make a chandelier:

http://i.imgur.com/sZ8Ieo3.jpg 

The chandelier implies it's a housing environment, now it looks like it's asking for some more decorative elements... tables and book cases near the walls maybe? Floor rugs? Perhaps experiment with the lighting, making the chandelier the primary source? Maybe some wooden bars across the ceiling holding a secret? Just keep doing your thing, sir! 

i like it! 

I wonder if an AO technique could actually enhance the base quake aesthetic.

Lun3DM5 has zero pointlights and 100-something sunlights. I really wish q3map2 supported Quake1 :( 

I think I might rely too much on "realistic" light sources (torches and lamps). Do you use fill lights often? If so, what kind of attenuation? I usually add a zero-fall or inverse light with low value to create AO effects like that. 

I did not read all above but DP has a software GI renderer since 2012 if I recall correctly. 

A few years ago I modded aguirre's light.exe to support AO without hand-placing hundreds of lights. The thing is that the "sunlight 2" feature already auto-generates hundreds of lights, but the code clamps the result so that everything looks flat. If you take out the clamping and reduce the intensity of each of those lights, you actually get something that looks like AO. However you need to improve the distribution of those lights to get equal light from all directions of the sky -- the default distribution doesn't spread the lights out uniformly since it doesn't matter when you clamp the results.. Problem: hundreds of really dim lights run into precision problems, so you'd need to do some changes to the intermediate math so you don't lose a lot of precision. But it does look good. I should probably clean up and release that code. 

:D 

yeah, i'd be interested in that too. i hacked in AO/GI with sunlights but I didn't change the light level data type so you'd just get integer junk which looked ok, but didn't give much control. 

I would love to have a play with that light util if you get some time to release it metl! 

... I think. Is there a compiler roundup somewhere? 

http://i.imgur.com/TYHiHJr.jpg
http://i.imgur.com/xzyHQiq.jpg 

great work! 

Great stuff! !!