I'm surprised nobody has done a monolithic compiler app ... one that does it all in one shot - with the possible benefit being what you mentioned, each process being able to have knowledge of what the earlier ones did. Although I guess there's little benefit so why bother? 

AO baked into the lightmaps AKA the way CS:GO does it. AO would look awesome with brush architecture but the few engines I've tried to force it "on" in doesn't work. 

If there was any way to hack in higher resolution lightmaps that would be lovely too :) 

Something I thought about but never tested was creating 2x size versions of all the textures you are using in the level and then set the default texture scale to .5 so that you would have double resolution lightmaps across your level.

Unsure how it would look/work and some textures would probably be too large at 2x size. 

What's AO lightmaps? 

http://en.wikipedia.org/wiki/Ambient_occlusion

Doing it as a lightmap means just making extra shadows in corners. Q3map2 has an option to do something like it in Q3. http://en.wikibooks.org/wiki/Q3Map2/Light#-dirty 

Do quake lightmaps have enough resolution to support a -dirty AO effect? I guess hence your question regarding higher res lightmaps?

In the old days, I tried this and it does work to give you higher res lightmaps, but you would run out of lightmaps pretty quick.

Of course, these days, there are a lot more lightmaps available... 

Wish we hadn't called it "dirtmapping" in Q3Map2, but back then pretty much the first popular incarnations of AO were "dirtmap" shaders for 3D apps that were used mainly as masks for gunk and dirt in corners. 

"Something I thought about but never tested was creating 2x size versions of all the textures you are using in the level and then set the default texture scale to .5 so that you would have double resolution lightmaps across your level. "

That's ... a really cool idea! 

so that you would have double resolution lightmaps across your level.

and presumably quadruple the face count, but i'm guessing no-one cares? 

oh right, that was another problem with doing that. 

Just tried to frankenstein the "-dirt" code from q3map2 into tyrutils, and it looks like it could be usable!
http://i.imgur.com/TbxbITN.jpg

(e1m1 with r_lightmap 1, light is just using the AO values and ignoring lights in the map file) Will tidy it up a bit and post a build tomorrow if anyone wants to play with it. 

Yea that does look usable indeed! Sign me up for that :) 

In the words of Daz, "you are a fuck". 

Aye that's the biscuits, nice one :) 

awesome! 

"and presumably quadruple the face count, but i'm guessing no-one cares?"

I guess it depends on the end result. If it looks good enough, it might be worth it. 

i've got this error
what gives?
dp engine http://quaketastic.com/files/screen_shots/dp_error.png 

Does it work in a normal Quake engine without mods? 

i guess it's somewhat related to an fte compiler, with its all optimization turned on

i'm just wondering what the hell is vm_vlen 0/1 

basically, when i'm running quake/mod via fitz(for example) it runs fine
when i'm running quake via dp it runs fine,

and when i'm trying to run the mod using DP, it crushes (vm_vlemn) 

qc bug.
vm_vlen is DP's internal name for the vlen builtin. the error is complaining about:
foo = vlen();
when the qc should have done something like:
foo = vlen(somevectorhere);
any modern qc compiler will generate a warning for that, so stop ignoring warnings and actually fix that stuff!.. whoever's qc mod that is... 

It should be fun playing with that, can't wait to see how it will affect future quake maps. 

Hell, any older map as well. You can always re-light any .bsp. You just can't change the individual lights, but anything usable in the light.exe command line is fair game. 

Here's the experimental build of tyrutils light with the -dirty option hacked in! The light.txt explains all of the new flags.
https://www.dropbox.com/s/nt78oeh49wevejx/tyrutils-light-dirtmap.zip?dl=0