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. 

When I did this for Lun3DM5 I skipped point picking on spheres and just used the vert coordinates of a unit-size poked buckyball, but before I did that I was going to do something in a regular spiral using the Golden Angle. Random distribution just needs too many samples, although lun3dm5 had 122 suns and you can still see staggered hard shadows.

Q3 of course has .shaders you can jam all the sun shit into that you want. What would a more elegant way of getting advanced lighting definitions into Quake look like, other than the current method of splitting it between worldspawn _keys and command line parameters? new light_ entities that light.exe would strip out for backwards compatibility? 

I like it. I just re-lit all of Episode 1 using:

light -extra4 -light 12 -dirty -dirtmode 1 -dirtscale 2.1 -dirtgain 0.7 [mapname].bsp

(batch file of course, it took about 30 minutes on a POS 10 year old PC).

And gave it a quick run through on easy and it looks even more "Quake-y" than the original. I'm not too sure how much of that was tyrlight's -extra4 but it certainly looked better overall. The -light 12 (overall minlight) really seemed to soften it up a bit without it being noticeable overall. I messed around with the settings using only the start map until it looked right first. The defaults were a bit too subtle and without the -extra4 it really stuck out like a sore thumb.

Probably my only suggestion would be if somehow any sharp 90 degree angles touching a liquid brush might be softened somehow (water diffuses light in general and the way ID did it in some places with 90 degree angles looks out of place (E1M1 under the first bridge especially) but that's still not a complaint because I was looking out for specific stuff like that and probably wouldn't have noticed it otherwise).

Good jerb there ericw. 

I bet episode 4 might be improved by the same treatment, but the other episodes probably don't need minlight. 

Becuz I have teh suckz00rs 133t skilz when it comes to this board and posting stuff and quaketastic doesn't like me using ZigguratVertigoBlewTronynsSocksOff.

That's why. :P

and I'm too lazy to set up dropbox right now. 

...the first episode maps re-lit and dirty using the above parameters I'll email it out and they can do it (and I'll even toss in that new knight model all in a PAK3.pak file), 2.97mb zipped. I can be reached at zombie.abe.vigoda at some geemail dot something or another and they can deal with it.

I'd do the other three and DM 1-6 but I don't want to be all warez-y and stuff but Episode 1 is shareware so whatever, and I'll even toss in the batch file to convert Pak1.pak (you'll need to extract and insert the new .bsp's yourself though). 

Dunno about using dirtscale, doesn't look great a bigger values IMO. I think dirtdepth is worth playing with though. 

Currently using quite subtle values on mine.

-dirtmode 1 -dirtgain 0.75 -dirtdepth 160 

SCREENS. :) I want the pretty... 

Well, dirty lighting is on the top screenshot and the normal lighting is at the bottom. The bottom light seems brighter but that's because I couldn't time it properly with the light style on that light.

https://www.dropbox.com/s/634686l70ick794/dirtlight.jpg?dl=0 

Thanks for putting this in Eric, that's awesome.

Any chance you could share a Mac OS X build? I see you included a .diff in the zip, but if you have one lying around already that'd be handy. 

Sure, I updated the archive to include osx builds and also added the full snapshot of the source, here's the link again: https://www.dropbox.com/s/nt78oeh49wevejx/tyrutils-light-dirtmap.zip?dl=0 

Thanks! 

I'm fairly new to mapping for the original Quake and now working on my first Quake single player map (w/ Trenchbroom).

I've made a trap room that works as intended with Quakespasm, GLQuake etc. but I tested it in WinQuake and some func_* appears to get culled away when looked at from some positions and angles.

Anybody knows what can cause this?

The room have quite many func_* objects in it: 2x buttons, about 15x func_doors and 2x func_trains. Is it too much for winQuake or is it something with Vis?

Any ideas are appreciated! /Daniel 

Doesn't 'lip' work with secret doors? I've got a door that slides into a wall and causes some Z-fighting flickering between the textures and thougt I could just add a small value to lip but doesn't do anything. Tried with extreme values also. Even looked through the .map file so the the lip key and value was there. 

Most likely it is "too much" for winquake.
Try t_width and t_length as keys on secret_doors.
Try negative values too! 

try increasing these two variables:

r_maxedges
r_maxsurfs

You might have to reload the map or restart quake for the change to take effect. not sure about that.

For the secret door, make sure the door has a slot to go into, rather than just going into another solid brush. 

The "Lowest" engine you should be shooting for is GLQuake. If still you want to do something for WinQuake then you really have to be careful about getting too complicated of a space going on. There's a reason why the original levels were relatively simple. WinQuake wasn't really intended for modern computer systems and it's also ~7 OS generations old. Five of which aren't even supported anymore. 

Making maps that abide to original limits has its own charm and is good for weak devices (Quake runs everywhere). I like it when people do that. 

However when you do that you need to keep in mind the limits that that imposes on what's possible when you use almost 20 year old software designed for over 20 year old technology. 

.. need a timing machine !