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. 

when is someone going to add extra8? ;)

Get dem high def shadows 

when you use -extra4, it's like using a raytracer to render a 400x400 pixel image, then scaling down to 100x100 in photoshop, versus rendering at 100x100 directly. The final resolution is the same, the -extra4 version just has imperfections smoothed out.

For actual HD shadows, you'd need a new file format, like a high-res version of .lit, and engine support :(. I was just asking spike yesterday, no one's build such a format for q1bsp as far as he was aware. 

.lit2 go! 

That's quite interesting to know, I thought it was genuinely higher res. :) 

I meant just make it less controllable to avoid weird numbers messing up the distribution.

But using the levels of 'extra' makes much more sense. 

But using the levels of 'extra' makes much more sense.
it does and it doesn't. decoupling sun count from -extra means you can do tests with higher number of suns without the lighting pass taking 30 minutes. 

http://www.quaketastic.com/files/screen_shots/5thlighttest.jpg

This is with dirt mapping and extra 4. 

how is the tree casting a shadow if it's a model? 

_shadows 1. 

Could be anti-lights, or skip textured invisibrush 

it's a func_wall with a skip texture and _shadows 1. 

I wonder would a radiosity solution work better for sunlight than just spawning multiple fake light entities. It needn't have bounced light (that's not radiosity, that's indirect lighting), just surfaces emitting light.

Using visdata (if present) to accelerate lighting seems to be something that nobody has ever done in the Quake tools. The Quake 2 tools do this and it should work quite well.

High res lighting could in theory be done by just taking the output of a -extra (etc) pass and using it directly. Would need engine support, dynamic lights and animated lightstyles would become slower to update, and shadows would start becoming harder-edged with more noticeable stair-stepping. I'm not sure it's a great idea. 

How hard would it be to add an option to up the resolution of lightmaps? That alone I think would improve Quake visuals a ton. I know it would require some engine level fiddling and tool changes, but I wonder how much REALLY. 

The biggest problem with these is updating of dynamic lights and animated lightstyles. It's not a question of work, it's a question of performance.