:-| 

I'm kinda with WarrenM here.

If the whole map runs fine with increased lightmap resolution, I think I'd just go with that, rather than spending a ton of time setting up funcs all over the place where detailed shadows appear. 

Brainfart really

let's say the compiler does a hi-res lighting pass. After this pass, could you then do something a bit clever like automatically detect surfaces that have uniform or near uniform lighting and automatically downscale the lightmap resolution there as appropriate? 

@WarrenM, if you compile a box room and whack the lightmap scaling to 0.0625 (1:1), then fire a rocket, your framerate WILL plummet (you can use rtlight-style lighting to avoid any slowdown, or just use gl-style flashblends instead, in any current engine including vanilla... assuming you were getting those slowdowns from crazy lightmap resolutions in vanilla anyway).
throw in a load of flickering lightstyles and your framerate will stutter 10 times a second (this can be worked around like rmqe already does, although this is not without its own cost).
high lightmap resolutions are NOT without their cost, and using a scale lower than 0.25 (4 texels to each luxel) is probably going to be abusive unless constrained to specific surfaces. 0.25 should generally be okay though.
For reference, 0.0625 gives 176mb for just vanilla start.bsp. There is no way around the load times, if nothing else. Using that resolution on every single surface a light might hit is just impractical, but you can get away with it if its just one or two surfaces.

@necros, typically you want the lightmap resolution concentrated behind the fence texture (typically ground). spreading it around the entire light is going to be wasteful. see my remark about <0.25 being abusive.
it would be nice to auto-detect the surfaces that got light applied to them through a fence texture, or areas with hash shadows, possibly by just calculating it at a high res and then reducing the resolution if it doesn't have many harsh boundaries on it, but this is likely to result in either every surface being high-res or significant glitches between highres and lowres surfaces.

@ericw, presumably the "black" texture should have its lightmap scale set to a low resolution by default, as it shouldn't normally be significant anyway (really this should be surfaces that have all texels set to 0). 

Maybe it could use the standard res lightmaps for dynamic lighting effects ... like, overlay them on the high res lightmaps. Odds are you wouldn't even notice. 

Kinn, I was thinking the same thing, automatically lowering the resolution when it won't be visible would be cool. Just need to try coding it. 

there's gotta be a pretty standard image processing algorithm that finds the minimum resolution for an image that still preserves its significant details. 

my original suggestion was with the implication that all lightmaps would be high res, and only indicated lights would cast high res traces (because it is the traces that will take the most time). For other lights, they would put their low res maps (upscaled to match) on the high res lightmap. (like simply increasing a bitmap's size by 2x, maybe use some filtering to smooth out the results)

I have had light take several hours when doing final passes with -extra4 and all that other stuff.

increasing the number of traces to get high res light maps would increase that by order of magnitude, I would imagine...

unfortunately I hadn't considered how dynamic lights would work what with having to update all those lightmaps.

could there be 2 full lightmaps, one low res for dynamic and one completely static high res one and then just do some additive blending at run time?

also, for setting lightmap res on faces, would that just be a huge pain? If i set 1 light to be high res vs setting all the walls, doors, plats, whatever else in the room to high res? 

the problem with per-surface lightmap res is how you get it from the editor to the qbsp. it would require a new .map format instead of just new entity fields. and that would require editing all the map editors etc too, which becomes a significant undertaking.
I doubt that it would be that hard for the qbsp though. 

You could do it with the standard .map format by using texture names as flags... so a surface with the texture "*texturename*$lm256" or something like that would be flagged in the light compiler as using a 256x256 lightmap res.

Might be a slight pain to work with, but if you're only going to utilize the highres lightmaps in key areas, it shouldn't be too bad to set up 

Metallic GuardShaftsLava Fissure 

Nice, I really like the lava river ... the organic shoreline with the structure of the pillars works really well. 

Also what Warren said, lava river is the one. 

how big is this and when is it coming? 

Near completion with a few tidbits left to do.

http://i.imgur.com/EpzDPbq.png 

Neat!

What editor are you using? 

Nice, I never say no to new Dook maps. 

Yeah I wanna play it :) 

Hi, I was browsing this thread and came across a screenshot on some blog, I'm trying to find it again. It was of a fairly basic scene, with two views. One with void or dark area, the other with lava. I'm pretty sure it was from this thread, a few pages back. Anyone recall? 

http://www.moddb.com/mods/arcane-dimensions/images/restless-rivers-of-lava 

The scene is of a corridor with a gap in the floor, which has lava in the second view. I think it's a single image of composed of two shots. 

In post #12241 there's a link to a map from jam5. It crashes my ezquake as it loads, did I install it wrong or is it for another client? 

ezquake is a quakeworld client, it is not meant for singleplayer, it will make you play a different singleplayer, it will not support mods, you should use quakespasm, fitzquake or directq. 

Use sv_progtype and sv_forcenqprogs 

AAS, I can load the map with both of those set to 1 but crash on spawn. With ezquake.

But jam5_hypnos2 doesn't look like the early shots from posts 12087 and 12106 :)