then a "_dirt_override" key on lights which toggles them relative to the chosen default?

Well if we're going down that road, I think we need to be explicit, not relative, something like on the worldspawn have "_dirt_default" (0/1)

then on lights have:

"_dirt_override":
0 - use worldspawn default
1 - override default - AO on
2 - override default - AO off

then, if you toggle the worldspawn key, you don't change the behaviour of those lights with override set.

if you set nothing for the _dirt_override key on a light then it, uses the world default 

yeah I like your 1/-1 idea 

That seems the better option. Looking forward to messing about with this. 

 

surely now these two:

_dirty 0/1 (enable/disable dirtmapping)
_dirt -1/1 (set default dirmapping flag for lights)

can be simplified to just the one...

_dirt (-1/0/1) (set default dirtmapping flag on lights, or disable dirtmapping on everything)

does that make it less complicated or more complicated? lol

for the sake of less flags and switches to worry about, I'd also be tempted to remove the dirt-related command line options and just keep the worldspawn / entity options 

I'll send you my sky code in a bit, but you're going to hate the diff because I couldn't stand the batshit indentation. 

i just want to recompile dm3 with ao
where to i put the command line in light.exe? 

"light.exe -dirty dm3.bsp" should do it. The default effect is subtle, you can add "-dirtscale 2" for more. 

just noticed a bug with dm3: the sky is blocking rays for the AO calculation. will be fixed in the next build. 

I fixed that locally too - be advised that rays that think they start inside a skybrush will also return 0, so once you fix that you'll still get a dark line along sky edges sometimes.

I felt TestSky and DirtTrace needed to be better unified, since they both test against the world slightly differently. that was on my todo list. 

 

I put my code up on github: https://github.com/ericwa/tyrutils
ao is in the "ao" branch.

be advised that rays that think they start inside a skybrush will also return 0, so once you fix that you'll still get a dark line along sky edges sometimes.
yep, noticed this too. I'm not sure if there's a way to fix that, other than just using -extra4 - the problem gets averaged away. 

osxwinsrc

The doc/light.html file is updated with the new stuff, the main things are:

worldspawn keys:

"_sunlight_penumbra" "n"
Specifies the penumbra width, in degrees, of sunlight. Useful values are 3-4 for a gentle soft edge, or 10-20+ for super diffuse sunlight. Default is 0.

"_sunlight2" "n"
"_sunlight2_color" "r g b"
Set the brightness/color of a large dome of lights positioned around the map (16K unit radius). Useful for simulating higly diffused light (e.g. cloudy skies) in outdoor areas. Needs to be a bit brighter than it would with aguirre's, try 150. Default 0.

"_dirt", "_sunlight_dirt", "_sunlight2_dirt", "_minlight_dirt"
enable (1) or disable (-1) AO on specific types of light. "_dirt" "1" turns it on for all lights that don't override it to off with "-1".

light entity keys:

"_deviance" "n"
"_samples" "y"
Convert the light into a sphere of randomly positioned lights with radius "n" (in world units). Useful to shadows cast by the light a wider penumbra. "_samples" must also be set to a number greater than 1,try 16 or more for higher quality. Default is 0.

"_dirt" "n"
Overrides the worldspawn setting of "_dirt" for this particular light. -1 to disable AO, 1 to enable.

Note if you were using "_nodirt" "1" from the last build, that's changed to "_dirt" "-1".

Usual "may be buggy" disclaimer, and thanks to q3map2 for most of the code! 

 

Monsieur, with these Rocher, you are really spoiling us!

Gonna dig out an old map and play with this for sure! 

i have to say, we've been really blessed with some extremely talented tool programmers.

Aguirre, MH, Warren, rebb, Tyrann, ericw...

If it wasn't for you guys, we'd still be mapping with plain old tools that died on the slightest complexity, ran on a single core and still used stock limits. 

How many episodes would Tronyn have made? 

Does seem to take a bit of time to compile (without even putting dirt into it) 

It's amazing to me to see how the Quake tools continue to evolve and keep improving. It's really cool. After, what, 20 something years? Man... 

Cool. The _sunlight_penumbra creates 100 suns currently and _sunlight2 around 200. I should probably lower these for a base compile (I.e. not -extra) to speed it up a bit 

Make it a parameter?

It'd most likely have to be fixed or something though to not completely break it when some mapper puts in 666 or 43535.4

Maybe;
0 = 10
1 = 100
2 = 200
3 = 400
...Or whatever makes sense with the code :) 

1.5 = 150? 

unchecking extra 4 seems to make the compile quick anyway and when I'm just testing I will also uncheck dirty to speed that up too.

I guess putting on crappy graphics mode was standard back in the day anyway when you're deep into mapping? 

Yeah -extra4 should be 16x slower than plain mode, -extra should be 4x slower.

With stuff like AO and the options that make 100s of suns, you end up with way more processing per light sample than before, it makes sense to go back to using non-extra mode while mapping, and only doing -extra4 for the final compile. 

Sure, I can add an option for the quality of _sunlight2 and _sunlight_penumbra, the only reason I didn't is to avoid adding too many command-line options.

Though the bjptools solution of automatically scaling up the number of suns with -extra and -extra4 is kind of elegant.