Looks like that glitched shadow in fitz0063.jpg was introduced in TyrUtils 0.7, in commit cc36d8e. I reverted part of that commit and it seems to have cleared up the holes in sunlight shadows as well as fixed up the AO.

win32 osx source

The dirtmapping looks way better in this snapshot than the previous ones! It looks reasonable now without -extra4. 

https://www.dropbox.com/s/5hmx6nortmhkksb/fixed.jpg?dl=0 

God, OUTSTANDING. 

I KNEW IT

i just didn't test all the way back to 0.7 because I had no idea the version of tyrlite I was using was that bloody old. :( 

Also this is what the last snapshot looked like:
https://www.dropbox.com/s/9wy9aky8u9j2myr/tyr-trace.jpg?dl=0

It was totally broken! The rays to test occlusion were not impacting the world properly and the measurement of the distance to impact was also messed up. Would love to see what your screenshots look like recompiled with this fixed build, WarrenM :D 

Only because you're my hero ...

Unlit/Dirt Only/Full Lighting
https://dl.dropboxusercontent.com/u/161473/Misc/Dirty_Shot1.jpg

I turned down the dirty setting to 1.5 since the new code makes it a lot dirtier!

And a random shot:

https://dl.dropboxusercontent.com/u/161473/Misc/Dirty_Shot2.jpg 

 

Hmm, the floor under the chain in the middle shot looks a bit odd. https://dl.dropboxusercontent.com/u/161473/Misc/Dirty_Shot1.jpg

Could just be the occlusion test rays are hitting the chain, combined with high dirt settings, in which case it's expected I guess. If you think it might be a bug, I'd be happy to have a look at the .map for that chunk. 

Sure ...

https://dl.dropboxusercontent.com/u/161473/Misc/MapJam4.map

And no, this won't be finished for the jam. :) 

Seems to just be shadows from the chain! 

 

Hmmm wonder what my map would look like with this AO pass now... 

that is some sexy looking dirty brushwork! 

ooo 

Is very nice. The lighting and shadows are very believable. Maybe we need an "ikebony" type texture set. 

Leveled lighting : https://dl.dropboxusercontent.com/u/161473/Misc/FixedLevels.jpg

Really nice ... !! 

that's awesome! Would love to see a whole Quake level that looked like that 

I have to think that perhaps the ikwhite jam maps would have looked about 10x better with these tools *HINT HINT* 

 

eh, the geometry sticking out over the shadowed areas looks all wrong or are those bars actually floating and not connected to walls and floor? 

How did you do that? What compilers did you use? 

Photoshop + Levels adjustment layer I believe. 

Yeah, Photoshop ... 

The shot is me trying to add the sky-scatter that metlslime described somewhere earlier. (taken with r_lightmap 1.) still playing with it.

I want to try it on lava, too, because I lit my jam2 map mainly by trying to match what a feature like that would look like. 

Is yours in the broom closet? :) 

...This was the result of experimenting on one of my scrapped quake maps. 

 

 

Looks inviting :)

What compilers and settings did you use? 

does typing -extra4 take that long? 

But I meant quakespasm.exe, not light.exe. 

People have suggested using an external text file to specify what surfaces should give off light. This is exactly what Valve did for hl/hl2/etc via "mapname.rad."

This is sensible enough as a decision on its own, but one of the pains of the Source engine is that everything is in a different text file with its own syntax parsed by a different command line tool. If you take the Quake engine and add features piecemeal over 20 years, making a lot of small sensible decisions in a vacuum without building toward some kind of more perfect ideal, you're recreating the exact steps for creating the Source engine. :)

So: is there something better we can do? Someone suggested the Q2 map format, which, yes, it does that, but then we all need a level editor that loads Q1 texture wads but has a Q2 surface property dialog and saves the Q2 map format, which is zero editors. It could be one editor, if sleep puts it in TB, but everyone assumes sleep is adding everything to TB and not everyone uses TB anyway.

I'm a fan of worldspawn keys - something I've considered adding to tyrlight is mirroring worldspawn keys on the command line, and command line flags as worldspawn keys. If I decide on a specific set of dirt variables or whatever that looks good with map A, I don't have to have a special set of map A batch files, I can just save the settings into the map. Or, if I want to fine-tune my sunlight I can just relight it with a different -sunmangle over and over at the command line without having to edit the map and do an -onlyents repeatedly each time too.


I personally wouldn't use a surfacelight definition, though, since it's more important to me that every room is tweaked to look its best than a texture emit the same amount of light every time it's used, specifying light per texture name just takes away that ability. With a 16 unit luxel, area lights are never very visually distinct from pointlights anyway, unless you're talking about a significantly large surface, like the sky or a pool of slime or lava. I don't think that's enough to justify light emission on a per-texture basis - do you need two different light levels emitted from two different lava textures? Per-content-flag is enough for that, which is how sun and skylight already work. 

What if you just had light entities (likely placed in a box outside the main level) and you could add a "_surface" key to them that you declared a texture name. The light compiler would then do q2/q3 style light from all surfaces with that texture name using clones of that light entity. This makes it compatible with all editors, and isn't that difficult a setup. 

I could very simply enable the surface flag editor for Quake 1 maps, yes. But you'd have to wait for TB2, as TB1 doesn't support Quake 2 at all. 

You say that yet support has been patched in ;)

http://leray.proboards.com/thread/3529/trenchbroom-simplest-editor-quake2-addon 

But TB2 has full support built in. 

What if you just had light entities (likely placed in a box outside the main level) and you could add a "_surface" key to them that you declared a texture name. The light compiler would then do q2/q3 style light from all surfaces with that texture name using clones of that light entity. This makes it compatible with all editors, and isn't that difficult a setup.
This sounds like a really good way to do it. 

I use Negke's compiling gui and my settings forl ight are -dirty -addmin -soft -extra4. 

how about adding keys to the worldspawn, this would be less work and easier to view/edit later

"_surfacelight_slite1_4" "50"
"_surfacelight_*lava01" "100" 

Well, you can copy/paste lights more easily from one map to another than worldspawn keys, and you can specify all the wait/delay/color/style/etc shenanigans you want instead of just a brightness. I like scampie's method. 

 

That has the same limitation tho ... every time you use that texture, it's going to emit the same light value. 

I didn't say that's why I liked it. It seems like a pretty reasonable way to set per-map texture light automation if that's a thing people want, I just don't personally. 

I WOULD use a system like this, because most of my lighting I just copy identical lights around everywhere anyway. I never really tweak individual lights that often.

I think the value here is that you can use it when you need it... if you have a million little 16x16 lights that are mostly accents, it makes it very easy to set them all up as a single _surface light and you can tweak them all at once. But you aren't required to use the system for all your lights, and can do per-use lights for anything else and tweak to your hearts delight. 

Adding worldspawn keys for the various -dirt flags should be super easy.

Awesome shot, quaddy! It makes me curious how much phong shading within the light tool would help avoid some of those sharp edges in the lightmap - interpolating normals of the sample points if the angle between faces is leas than some value. 

...more along the lines of some very specific textures in the control of the person making the level instead of someone else deciding for you what the brightness, delay etc was going to be.

Most (not all just to cover the bases) levels use the same textures over and over again. So, for example, *lava might emit a bright but short radius and it "Should" be consistent throughout the level.

Lighting, for me anyway, was always where I stopped mapping. I'm too picky about it.

A tech level might use the same light "Fixture" several times over so consistency might be desirable in some cases.

There's nothing stopping a mapper from taking tech_lite(X) and renaming a copy in the .wad as tech_lite(X+1) with tech_lite(X+1) having a default lightmap value attached to it. 

But you aren't required to use the system for all your lights, and can do per-use lights for anything else and tweak to your hearts delight.

If the light texture is getting the same light entity cloned onto it by the compiler every time, how would I create an exception, besides duplicating the texture? 

Sorry, I guess I was confusing by stating something obvious for no real reason.

I simply meant that you could set it up for just the light textures you wanted it use it for (such as lots of little lights), and light by normal methods for anything else (such as you might not set up larger light textures and do those by hand to fill the specific areas they are used it) 

I really liked when doing Quake3 maps that I just put a light texture on something, and BOOM, it was lit. But I would get really annoyed having to edit a .shader, or create a new one, to modify the lights, for me it always feels like a distraction to leave the editor to change things... so being an object you set up for yourself in the editor is key for me. And if some mappers don't want to use the system, than there's nothing wrong with doing things the old fashioned way, or just limited use of it! 

sorry, I ramble a bit 

You COULD do something like that to create sort of a lighting prefab system tho ...

Like in the worldspawn set up a

"light_hot" "light:450,wait:4.0,blahblah"

And then in your light entities use:

"prefab" "light_hot"

to refer to that setting ... might be interesting.

Or not.

Whatever. 

When I was making honey I had already written a converter from my editor's native format to .map, so for a moment I toyed around with adding functionality for a light stylesheet of sorts, where you'd place a light, give it a "class" and it would grab the correct values from a file. What was nice was that it could also generate secondary lights, so you could place a single spotlight in the map, and the tool would create fill lights and bounce lights in the right places.
In the end it wasn't really worth it and I refactored it out because copy/paste is so simple in the editor anyway, and mass-changing values was also quick because there were some advanced search tools that let you find similar entities in an instant. 

"and mass-changing values was also quick because there were some advanced search tools that let you find similar entities in an instant. "

Hmm? I don't think I know about this ... how and in which editor? 

It was our in-house editor at Starbreeze. There was a really old version released to the public, but it's kinda shit tbh.
The map format was fairly similar to Quake, so writing a converter wasn't too much work. 

Ahh nice. Yeah, Ogier always looked interesting to me from the screenshots. 

"ogier" is Polish for "stallion" 

for entities. Map->Entity Report

You can bulk-edit keys n stuff. 

Hello chaps, long time lurker etc. Very impressed with what you've done to this dear old game, so much that I thought I'd have a bit of a play around, which led me to this little issue (unless I'm missing something obvious, which is quite possible).

Dirtmapping happens after the usual lights have lit the map, which makes sense otherwise there would be no lit surfaces to make "dirty". This usually looks really good, but I noticed a situation where it is problematic.

Imagine a light inside a small alcove. The dirtmapping makes the alcove very dark, despite the bright light, because the inside surfaces are all very occluded.

Here is an image showing what I mean (I have used -dirtscale 2.0)

http://i.imgur.com/XKHEGrf.jpg

I can't think of a nice simple general solution to fix this.

One option I thought of could be to create a property you could add to light entities - e.g. "postdirt" "1" - this flag would tell the light compiler to actually process this particular light after the the dirtmapping pass. What this would mean is you could create small, bright, but low radius lights in places like the alcove pictured, in addition to the main alcove light, which would then just brighten the insides of the alcove up again after the dirtmapping has done its thing.

I'm sure there are other ways to slice this particular sausage though. 

.. isn't ideal.

Back when i implemented it with ydnar, AO was a bit of a "novelty".

The main inspiration for this particular one came from "dirtmapping" shaders for Mental-Ray, where it was applied as a dirt mask and not really used for lighting, although it could be made to work with that too.

I believe someone later added a new Q3Map2 switch that only applies it on map-wide ambient light, which would be more correct.

That would be an option, on top of making lights able to opt-in for the AO ( "_useAO" key ? ).

That way you can make low fill-lights that act as localized ambients, while main lights are not subscribed to the AO and will act more physically correct. 

That sounds like a good way to go. Having an AO opt-in/out flag on individual lights would give us total control over the look. 

Cool, didn't realize you did the original dirt code rebb :)

Yeah, some sort of key to opt-in on a per-light basis sounds like a good idea (or opt out?) I don't know if would be overkill to have flags for enabling dirt on the minlight and dirt on the sunlight, too. 

I'd probably go for opt-in as the default behaviour (if none is specified) on all lights, as I think it looks good most of the time - it's really just the light-in-an-alcove sort of situations where it looks bad. 

it's coming along nicely, and also looks like it's straightforward to have adjustable dirtscale/dirtgain per-light, so you can have bigger AO shadows in outdoor areas, etc. Only the dirtmode and dirtdepth settings need to be constant across the map. 

I guess it depends what type of lights the mapper places more often, low fill lights or main lights. AO is mainly an effect meant for ambient lighting and can look strange when applied on main lights or sunlight. 

Did Tyrann disappear again? I ran into the same issue as digs just now when I was recompiling an RMQ map with these tools. At first I thought the litfile was all black, but then it occurred to me that the color parameter expects 0-255 now whereas Radiant and MHLightColored expect 0-1.

I have to search and replace all my light values now? Or can I use my old light tool with these? I really just want detail brush support. 

after compile i get the message saying 0 switchable light styles along with the time elapsed and the light data amount.

In fact, i have several of them in the map, and they all work as intended.

Only the compiler tells me otherwise. 

I've been in touch with him lately and forwarded him some patches, he's just really busy at the moment.

For now I'd suggest the version of tyrutils I posted in #129 of this thread: http://www.celephais.net/board/view_thread.php?id=60967&start=129

That one will automatically handle 0-1 and 0-255 color values. It also fixes a pretty critical bug Lunaran noticed that was creating cracks in sunlight shadows, and probably other lighting glitches. It also has a first attempt at ambient occlusion if you want to play with that! (still WIP though) 

Thanks ericw, I will try that.

AO in my experience needs somewhat light-coloured textures to look good, Quake's are pretty dark though (probably in order to hide the horrible lightmap resolution.) 

Working On This Now

Superb! What a great community this game has :) 

Messed around with detail brushes last night. As expected, all the fidgety detail that used to be func_wall now casts shadows. Nifty. Checking out dirtmapping now.

What I don't get is, why do you guys add all this stuff to Q1bsp instead of just switching to Q3bsp? You get shaders, mapmodels and patches for free with that one. Quite a few editors support it, too (although no worldcraft NOOOOO) 

The extremely simple answer is because only Darkplaces supports Q3bsp. 

ericw,

I tried the dirtmapping and I have to change my opinion. It works pretty nicely in Quake, really enhances the creepy shadows... I also have my coloured lights back.

https://runeofearthmagic.wordpress.com/2015/01/30/dirt/

Kinn,

well, OK. Few engines support it. FTEQW does, though, and it recently got a nice vanilla preset with square particles, netquake physics etc. FTE also supports most of the Q3 shader language (and custom GLSL) while DP only supports single-stage shaders. But I understand that you guys would rather die than give up Fitzquake (and FQ forks.) That's fine, everyone has their preferences. I shouldn't have brought it up again. 

 

You're as tactful as a rhino. 

I second the thing about lights in alcoves + dirtmapping. I'd say opt-out is a lot more reasonable than opt-in since you'll want AO everywhere in your level if you use it at all. 

...part of me says there's a programmatic solution to the alcove problem, the other part of me says full designer control is better. 

But I understand that you guys would rather die than give up Fitzquake

...

You're as tactful as a rhino. 

...because the engines aren't compatible with my laptop. Requiring a particular engine shuts people out, making things that work with all engines doesn't. It's not about loyalty to a particular engine, it's the opposite: allowing all the engines to play... 

and where was the need to stir the fire after I already basically said I was sorry? Massive grudge much? 

Plus, it just gets strange when you add support for really high-res things, but then still use them alongside original unchanged low-res things. A 2048 normal mapped skin looks stupid on a 200 poly monster animated at 10fps.


Quake perfectly reproduced in Quake3, targeted specifically at Quake3 engine budgets and resolutions, would be joyous. 

Massive grudge much?

...

(although no worldcraft NOOOOO) 

Moreso since I can't think of any post-Q3 engine that could pull off that goal successfully. Definitely not idTech 4 with its ridiculous portaling... 

Going off topic, but if you've tried Quakespasm 0.90.0 and it didn't run on your laptop, I'd be happy to look into it if you want. It should run practically everywhere. 

If you need to keep using a func_wall in some situation, tyrann added support to make it cast shadows - just set "_shadow" "1" on the func_wall. 

Portaling, and just the investment time of making the textures and models, lighting the maps, etc. It's not fun to spend an entire Quake map of time and not have an entire map. 

To say nothing of the amount of non-map work that would be needed for idtech 5. 

Is it possible to add _sunlight2 and _sunlight3 from AguirRe's tools? Some of my maps depended quite heavily on that. What it does is basically add a bit of minlight only around the areas that have sky, so you can still get 100% black shadows in indoor areas.

Stark black shadows around outdoor areas are quite rare in nature, hence why I liked to use it. I also liked how it seeped into neighbouring areas a bit. I found it quite natural.

The alternative with the current tools would be to manually place some local minlights around, but that's comparatively sketchy. _sunlight3 was nice and easy, but if I'm the only one who ever uses that, it might be too much work for you...

I really like the dirtmapping, so I don't necessarily want to switch back to BengtLightColoured.

Thanks for mentioning the _shadow key, I'll have to play around with that one. 

It really helps soften those hard shadows. 

osx win32 src

The only changes are more options to control AO:

- _dirtmode/_dirtdepth/_dirtscale/_dirtgain worldspawn keys
- _dirtscale/_dirtgain can be customized per-light
- _nodirt can be set on a light to ignore AO for that light (so it illuminates the AO shadows)
- _sunlight_nodirt can be set on the worldspawn to disable AO for sunlight

In the previous build, dynamic lights were not affected by AO, now they are unless you specify _nodirt.

If it's annoying with AO as opt-out I can make it opt-in, or add a command line switch to make it opt-in. I'm worried about the settings getting too complex, so feedback welcome.


re: _sunlight2/_sunlight3, I can put it on my to-do list. I tried deleting the lights in jam2_mfx and testing _sunlight/_sunlight2/_sunlight3 from bjptools_xt in the outdoor area and didn't seem much improvement between the different sunlight modes. I'm interested to see what Lunaran is cooking with metlslime's idea of distributing lights around a dome.

From what rebb was saying and what I've read, AO should be applied to fill lights that are simulating reflections/indirect lighting. so I'm interested to see what can be done with AO to fill in ambient light in outdoor areas. 

So... on your light you would put :-

_nodirt "1"

is that correct? 

There's more detail in the light manual too 

ericw you mistyped RTFM 

http://imgur.com/a/urAJn#0 

 

Yes it would be better to have it opt-in. Just activate it on certain lights. 

I wander around a lot.. 

Yes it would be better to have it opt-in. Just activate it on certain lights.

Disagree. I just had a play with this, and I'd definitely want AO on all lights and I'd only opt-out when I come across the "alcove problem" (or similar situation) as described earlier.

It just looks too cool! Who cares if it's not physically realistic? 

I prefer opt-out too. 

I was gonna suggest that perhaps you could set the default behaviour on the command line. Then I decided it would be nicer to just have it recorded on the map. So how about something like a "_dirt" key on the worldspawn which controls whether lights are dirtmapped by default, and then a "_dirt_override" key on lights which toggles them relative to the chosen default? 

Yeah there are probably good uses cases for both default off and default on.

What about:

_dirt 1/-1 on worldspawn for setting the default on/off,
_dirt 1/-1 per-light for forcing it on/off for that light?

The the _nodirt and _sunlight_nodirt keys could be removed, though to keep control of sunlight we'd need _sunlight_dirt 1/-1. 

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. 

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. 

@mh
Just thread it? 

Nice idea for software but in GL it all happens in glTexSubImage2D. 

Sorry for noob question, but I saw some comments in the Beyond Belief in one map thread that made me wonder if I can add AO to maps by recompiling them with TyrLite? I saw some AO screenshots and it looked really nice. In short, can I recompile the vanilla game's bsp's (and other ones as well of course) and get those nifty effects - or is it more involved than that? 

Nope, it really is that easy. Extract bsp from pak, relight with -dirtwhatever, play and ogle.

Should distribute a batch file that does all the stock maps. end.bsp might even look half decent. 

When you have a chance to play with it, curious how the _sunlight2 in the latest build compares to what you were doing!
The actual sun positionong I took from the "skylight" feature in q3map2 

i redid the quake maps but found dirt mapping isn't as awesome in those as you would think.

the real benefit comes from outdoor areas that use the modern _sunlight method because that yields completely flat light on its own, and the dirt mapping comes in and makes it awesome.

id had done all their lighting with point lights which already gives a bit of a dirt mapping look.

so yeah, dirt mapping does improve the lighting in oldschool lit maps, but the real benefits will be maps that relied a little too much on minlight or had big outdoor _sunlight areas. 

eric, will test, recovering form hard drive replacement 

eric, will test, recovering form hard drive replacement minor surgery. 

Get well soon! :-) 

Cool, thanks! 

I may be talking out of my arse here, because I don't know the tools code very well, but I was thinking....

You know how face splits due to fiddly details (thin bars, steps, walltorch holders etc.) can often cut across lots of geometry, and it sucks?

I was wondering - if it was possible to influence the order in which faces get split, could it improve the situation?

To wit - imagine a key which you could put on a func_detail (or func_group) - i.e. "_split_priority" or something - then bsp uses this to order the way faces get split so you can constrain fiddly details to splitting just the immediately adjacent faces by making them func_ and giving them a lower split priority. You could even have more than one func_ butting into each other, and use different _split_priority on them to really micro-manage the order of splitting.

Caveat - just the rumblings of someone who doesn't know much about quake's BSP algorithm, but does any of this sound interesting / make sense? 

faces do not define leafs, thus in theory, it should be possible to just omit the splits entirely (maybe revert to the original surface if it got split in too many ways without being disjointed, but still clip it to any outer-edge planes of the fragments).
this would result in more overdraw (without randomly spewing into walls too much), but software rendering is supposed to be zero-overdraw anyway, while hardware renderers should be fast enough to not care.
the catch is that it would take more edges, but at least you wouldn't feel like you had to spend all your time building the bsp tree by hand only for it to mess up again when you change something. 

Sorry for another noob question, but how do I actually run TyrLite? I've used PAK Explorer to extract a bsp, but then I'm stumped. Well, I guess I must run a command line, telling it to execute light.exe and then adding lines pointing to the bsp and detailing what to do, but I don't find any info in the readmes on how to do it. And it didn't help much to google command line utilities either. In short, is there "run a command line utility for dummies" or some such guide? 

Sure, just put light.exe and the map you want to light (say e1m1.bsp) in a folder like c:\\mapping.
Launch the windows command prompt, cmd. (iirc, start->run, then enter cmd.exe, or search for "cmd" at the windows 8 start screen)
Type:

cd c:\\mapping
light.exe -dirt e1m1.bsp
 

those double slashes should just be one slash 

cd:\\\\\\\\\mapping\\\\\light.exe \\\\\ 

to relight all maps this way:
- make a folder: c:/maps
- extract all the maps into this folder
- put light.exe into this folder
- open notepad and paste this into it:
for %%A in (*.bsp) do light -threads 4 -extra4 -dirty -dirtmode 1 -dirtdepth 160 -dirtscale 2.1 -dirtgain 0.7 %%A
- save text file as run.bat

double click run.bat

also try fiddling with the numbers like -dirtdepth and -dirtscale. i think they are set really high because I was testing stuff. now my maps are really dark and I'm too lazy to try to fix it. 

uh, put run.bat in the same folder, btw 

woooooooo.... made a folder called "dirty" with all the dirty stuff added. 

osx win src

Only one change, key/value "_dirt" "-1" is supported on brush model entities (func_door, etc), this disables dirtmapping on that bmodel. Useful in combination with bmodel-specific "_minlight" if you have a door that touches or sticks into the world, and you want to prevent those parts from turning black from the AO. 

I think I will end up using this a lot 

Thanks, guys. When running the run.bat as described in necros' post, light.log says:

Unknown option "-dirty"

I tried with -dirt as well but then I get:

Unknown option "-dirt"

Otherwise, it seems to run and the .bsp's get resaved. I'll check it out ingame. 

http://celephais.net/board/view_thread.php?id=60967&start=287&end=287

try these. 

Thanks, mfx, I misunderstood the post previously. Yes, now it works and it's a noticeable difference as well. And I agree with necros - it's a bit too dark IMO. But it will be fun experiment around with the settings now that I got it running. 

fun to experiment around rather (I must learn that you can't edit posts here...). 

 

"It also fixes a pretty critical bug Lunaran noticed"
Is it possible that has anythi g to do with shadows forming along face splits in the floor, e.g. along diagonals? I've been getting wierd lighting ever since I started to have to use bsp2. (map got too big) 

re: #279

Ok, I am officially intrigued.

I am also not entirely sure now what the real downsides are with the current ugly splitting, other than it just looking nasty to someone used to nice clean meshes. Would we see potential performance benefits to changing the procedure so it splits less or avoids splits entirely, as you describe? 

do you still get those artifacts with my builds, e.g. the one in #287?

There shouldn't be artifacts from using bsp2, but you never know. If it's still happening with the last build I can take a look at the map if you want. 

It's not a bug with light, it's a bug with tyrann's bsp.exe Here's 3 pictures showing the difference between tyrann's latest qbsp and good ol txqbsp:

https://dl.dropboxusercontent.com/u/20160676/tyrann_lightingerror1.jpg

Lines drawn to highlight ugly areas:
https://dl.dropboxusercontent.com/u/20160676/tyrann_lightingerror2.jpg

https://dl.dropboxusercontent.com/u/20160676/txqbsp_beautiful.jpg

Please note that tyrann's looks the same regardless of whether I use bsp2 (all vis groups visible) or normal bsp (a couple visgroups turned off).
The txqbsp has to have the visgroups turned off since it doesn't compile for bsp2.

Any idea what's going on? 

I guess this isn't really the right thread for it. ericw's light works ok btw. 

Okay, it appears to have something to do with subdivide face. In tyrann's qbsp I'm fiddling with adjusting the -subdivide ## parameter and getting different results, usually crashes such as Alloc fails or Failed to Subdivide Face. Hopefully I can figure out what is going on and why it would differ from txqbsp's implementation. FYI, the textures in my scene are scaled at 0.50 on every wall, floor and ceiling. I wonder if that has something to do with it? 

Figured it out. Jackhammer editor breaks world texture alignment when flipping brushes with Texture Lock turned on. I found that more than half of the textures in the room in the screenshots above had their World check box unticked. Ticked them (which caused them to flip negatively on the x-axis), flipped their X-axis so they were aligned correctly again, and BAM - - perfect lighting!

Editor problem.

User problem (not understanding my editor). 

So...in conclusion, Tyrann's qbsp for some reason doesn't handle undefined face alignment (neither World nor Face checked) very well and causes poor lighting along the edges on those faces that aren't World or Face aligned when created in Jackhammer. Txqbsp handles these okay so there must be some fundamental difference in handling of Subdivide Face between the two.

Just a heads up to anyone else who has this issue when they are using Jackhammer. 

glad you narrowed it down Qmaster.
Could you post part of the .map file (or even just that one brush that gets the black stripe) just for reference? I might be able to fix qbsp if it's an each change.

Btw, rebb's modifed txqbsp is worth checking out, it's probably the best qbsp right now (handles bsp2, detail brushes): http://www.voidspark.net/projects/bjptools_xt/ 

Here you go, I copied and pasted out a small portion of my main map to create a small test map. It's pretty ugly, I retextured it with all the same texture to save time and so that you could open it in standard quake (I'm using a different palette for my game).

.MAP File:
https://dl.dropboxusercontent.com/u/20160676/lighttest.map

.BSP File (Looks awful! and I don't mean just the texturing):
https://dl.dropboxusercontent.com/u/20160676/lighttest.bsp

Compile Log:
https://dl.dropboxusercontent.com/u/20160676/lighttest_log.txt

P.S. The percentages have a newline for every % or something, FYI. 

Also, when I say undefined face alignment, I mean arbitrarily aligned: https://developer.valvesoftware.com/wiki/Texture_alignment#Arbitrary_Alignment 

I tried compiling the map, looks whatever the problem was is already fixed in my modded tyrutils, as I don't get the weird patterns that are in the bsp you posted. (The qbsp.exe in my packs has a couple of fixes from Tyrann newer than his last 0.15 release).

Could you try with both the qbsp.exe and light.exe from here? http://celephais.net/board/view_thread.php?id=60967&start=287&end=287

Excerpt from my compile log:
$ ~/dev/tyrutils/bin/qbsp -bsp2 lighttest_tyr.map
---- qbsp / TyrUtils v0.15-17-g84caccd ----
..
$ ~/dev/tyrutils/bin/light lighttest_tyr.bsp
---- light / TyrUtils v0.15-17-g84caccd ----
.. 

Tried to compile willem's jam5 map with tyrutils, got this:

$ vis MapJam5_Warren
---- vis / TyrUtils v0.15-5-g5111c54 ----
running with 4 threads
testlevel = 4
BSP is version 29
14599 leafs
2613 clusters
8492 portals
Loaded previous state. Resuming progress...
Calculating Full Vis:
0....1....2....3....4....5....6....7....8....9....
Expanding clusters...
************ ERROR ************
Vismap expansion overflow


-vv probably gives more info, but it outputs a lot 

how long did it take you to get there?

i used h2map to create prt file from the already compiled bsp and then vis.exe to re-vis the map. it is working so far, but it's extremely slow. at this rate it will beat castle of the dark ages vis world record... 

We might want to accept that it's a terrible BSP and move on. :) I would do many things differently if I started that thing over... 

no way.. it's too early to give up :-) 

not long, i interrupted it often, total i would guess an hour or two. i5-3470. I went from the .map, not the existing files. 

i'm at 20% after 15 hours. it reminds me recompiling travail levels for transparent water support. of course, back then i had crappy single core cpu and no multi-thread vis tool. 

I'm curious as to how vis can be broken like that if - as you say in another thread - detail brushes were used extensively. 

Probably detail touching the void(wild guess). 

Is that a problem? There's TONS of that. 

this can be the reason for some trouble.
Try deleting all detail brushes and compile again.
If it leaks now, there is your problem. 

-makedetailleak is the switch in txqbsp_xt. 

It happens after

leaf 10366 : 12797 visible
leaf 10367 : 12797 visible
leaf 10368 : 12797 visible
************ ERROR ************
Vismap expansion overflow

so either leaf 10369 is the trouble maker or what code runs after the "Expanding clusters...". 

win32 os x src tgz src git light manual

with some new stuff:

* light: fence texture tracing, for bmodels with "_shadow" "1"
* light: surface light support via "_surface" "texturename" light key

convenience:
* light: respect "_dirt" "-1" bmodel key in -dirtdebug mode
* light: allow setting "-dist" and "-range" command-line flags in worldspawn
("_dist", "_range")
* light: accept "_sunlight_mangle" as an alternative for "_sun_mangle"

other:
* all: increase stack size to 8MB. Fixes qbsp crash with bbin1.map on Windows, light crashes.
* qbsp: switch to hardcoded MAX_MAP_PLANES (262K), speeds up map file loading phase.
* qbsp: MakeFaceEdges: accelerate with a hash table to avoid slow O(n^2) search for edges
* qbsp: ChooseMidPlaneFromList: fix off-by-one error in axial plane test. On the first SolidBSP pass, gives fewer split nodes on bbin1.map (128k vs 199k)
* light: MatchTargets: disable copying "style" key/value from a light to the entity that targets it. Don't see any point, and causes problems if "style" is meaningful for the targetting entity (e.g. a monster).

Thanks Scampie/Lunaran for the ideas earlier in the thread about surface lights. I agree it's limited because you can't customize individual lights, but it still may be handy (e.g. for lighting a big lava surface).

Also thanks to mh for the example of how to do surface lights in one of his MHColor builds. 

 

Someone post screenshots! I wanna see lava lighting up some shit... 

MakeFaceEdges: accelerate with a hash table might be a nice patch to have in txqbsp-xt. Your SolidBSP is already lightning fast, and I noticed MakeFaceEdges was one of the bottlenecks on big maps; with this patch it completes almost instantly.

I was looking at bringing some of the qbsp optimizations from txqbsp-xt to tyrutils: the 1024-unit max node size, and the different way that SelectPartition measures the bounding box of the list of surfaces.
These brought the compile time of the huge bbin1.map in line with txqbsp-xt (as well as improving leaf/node counts close to what txqbsp-xt gets), but they also caused telefragged.map to leak, so I didn't merge those changes in (maybe next snapshot I'll put them in with a command-line flag, though). 

How hard would it be to add all the surfaces a mirror can see to the visibility for any area that can see the mirror?

I have mirror alpha implemented in Mark V beta but I'm trying to decide how to tackle visibility.

I thought I'd ask this before I decide on a course of action. 

Sounds like it wouldn't be too hard, as a postprocessing step after vis. Something like: 1) find all leafs that have a mirror in them (based on a texture prefix?) 2) for each leaf X, check whether each other leaf in its PVS is a mirror-containing leaf marked in 1. if yes, merge the mirror-leaf's PVS into X's PVS. 

tbh you're probably better off doing that in the engine, if only because it means you don't have to trust the vis tools.
plus it also opens up the possibility of q3-style portals with complex gamecode. 

Hehe, I've been meditating ever since ericw posted back.

Thinking about that kind of dilemma. i.e. What about moving mirrors, etc.

Also the possibility of mirrors in maps that didn't expect to have them.

I've got probably 1 more week of polishing up the engine before I think hard about this. 

Awesome! Thank you for adding surface lights to the tools ericw! And all the other little improvements! 

Am I the only one who thinks we should have a proper standard for mirrors before building infrastructure to support them? We all remember what happened with skyboxes and fog. 

is support for am_detail dropped completely in favour of func_detail? 

https://twitter.com/back2cccp/status/593157752442253312

just to clarify how this works, it's nothing more than automated copy & paste by the compiler. the "_surface" key is put on a light, this turns that light into a template 

Nice, and I like that implementation ... 

This is already being used in my retro jam map :) 

My god. This is amazing. Just had a play with it tonight ... it's like getting lighting for free. Fuck ... FUCK. Gotta map... 

 

win32 os x src

* qbsp: fix broken -onlyents flag
* qbsp: fix texture offset on rotate_object, so they match in the
editor. Added "-oldrottex" flag to revert to old behaviour. From txqbsp-xt.

No changes to light though. 

Tinkering with this, it's great. I used it for the lava in my RJ3 map but I'm toying with it for all light textures atm, it might turn out to be a really good time saver :) 

lighting...

will be handy for speedmapping 

surface light = very good stuff! 

Love these lights. Simple shot below ... the only difference is the addition of a lava brush.

https://dl.dropboxusercontent.com/u/161473/PersonalMapJam/PMJ_B.jpg 

Light crashes when I tried this with surface lights =

_deviance 1
_samples 4 

I dont think it's surface light thats the problem.

I just made a standard light with the same keys and it crashes. 

https://www.dropbox.com/sh/1q5giu2leyvvhk0/AAA0UCacYD-tgVpElMSpf5Awa?dl=0
getting lazy about making all of those direct links.. This has _deviance fixed. 

* light: fence texture tracing, for bmodels with "_shadow" "1"

Wait.. does this mean that a fence texture would cast a shadow of the fence? Isn't this a huge deal?? 

Sadly not... it only casts the bounding box I believe. 

There's also a bunch of dev spam from the current light tool ... no big deal, just messy.

jitterning blah blah, or something over and over... 

Yeah, the fences cast proper shadows if you use func_wall with "_shadow" "1" for the fence. This is with fence textures with the { prefix. It can be hard to see with the low light map res in quake, but could be useful in the right place. (Tree branches? A grate over lava?)

@warren, thanks for pointing that dev spam 

Are you sure? That's pretty crazy if that's true. 

I was trying to avoid posting a hideous dev screenshot ;)
http://imgur.com/aLGR9Az 

I had no idea it had this feature. 

I guess I made this thing just in time, then. 

 

Now you just need lightmap resolutions that are high enough to do it justice... :s 

I turned the entire tyrutils docs into a radiant ent for q1. http://www.filedropper.com/entities_1

I also posted the source of the individual ent lists that I created from the docs. http://quakeone.com/forums/quake-mod-releases/works-progress/11535-complete-tyrutils-radiant-ent.html

All keys, docs, everything are now included in the entity inspector 

thanks for preparing that, Gypsy! I think it would be nice to bundle with the tool next time I do a release if that's ok with you? 

@ok with me

I look at it this way. YOU did all the work, I just reformatted your docs to be ent nodes. Like quite literally that is exactly what I did. So hell yeah! Bundle away, brother. If I made some mistake somewhere or if I actually did forget something, please feel free to tell me and I will fix it.

You made one error in your docs though.

docs: "_surface_offset" "texturename"

"texturename" should be "n", right? If I am wrong then I need to fix the ent. 

Let me get a wild hair up my arse and I'll make you a fgd version too. Which will be a LOT easier cause fgd's let you make reusable "class chunks" that can be referred to by name within an entity.

I'll get on it eventually. I'm ented out right now. 

cool, thanks. You're right, that should be "_surface_offset" "n" (it takes a number), i'll fix the docs. 

http://www.filedropper.com/quake

complete q1 fgd with TyrUtils keys included. Honestly, this is completely untested but I know my syntax is right and I didn't make any format errors. There is no reason why this shouldn't work.

You can head to my above posted quakeone thread if you want to see the more isolated changes I made to the fgd. (give me a minute to actually write that post)

Also in my entities.ent, I realized that I spelled prenumbra wrong in the worldspawn entity. sorry about that just add an "r" and you're golden or you can dl the fix below.

http://www.filedropper.com/entities_2 

is there a good place to find fgd's for other id tech games? I wouldn't mind downloading them all... 

Somewhere, I have like all of them. Give me some time to search some drives and I'll get back to you. If I find them, the latest post I made on my quakeone link above shows you how to "Tyr" them in like 2 minutes. 

http://www.filedropper.com/fgd

I couldn't find any on any hard drives so I just did an ass-load of google searches and downloaded as many as I could find.

This includes:

Quake, Quoth2, Custents, Zerostoerer, Hipnotic, Rogue and ?RRP? (I have no idea what rrp is). If I kept searching I could probably find more. I remembered a lot of the original filenames/zips that these could be found in and I just googled those filenames directly. 

Unfortunately it would be windows only :( cause I don't know any languages that are OS inspecific (well I know one but I doubt y'all want to deal with AIR).

Would this be something that y'all can use? Are there enough windows users for this to make it viable?

I have the skills to pull it off and I also actually have half the code written already due to a similar project.

If I get enough "do it"s, I'll totally bang it out. I really like what he is doing to the map compilers and I want to contribute from my end of experience. 

what is the tool chain? it's not just qbsp -> vis -> light? 

Well that alone would be a tool chain but, you forgot bspinfo and bsputil.

I could make an interface that sums up all of them. For instance you would (ex) expand the qbsp panel and all command line swiches would be available upon click. In the case of switches that expect extra data, a textfield or potentially a selection box would be available as well.

Really there is only a couple/few reasons why this would be better than using batch/bash. 1 it would almost eliminate the potential for a typo. 2 you wouldn't have to remember shit cause all the choices/info would be right there in the interface and 3 it can come packaged in a way that separates the user from worrying about things like paths.

Of course the app could be made to accept data (MapFile) straight from radiant, making the stock build menu useless. I don't know if I could do that for hammer/worldcraft but, I would assume I can. Both obviously have the ability to call compile tools and inject data. The app could just be treated like a compile tool. 

"bspinfo and bsputil"

Having never used these, ever, what's their purpose to the average mapper? 

Bspinfo prints basic information about a bsp

Bsputils allows you to extract entities and textures and check that data structures are clean.

They aren't amazing tools but, they exist so I would have to include them in the app. 

http://i.imgur.com/QljsEbE.jpg

Heres an ugly, quick and dirty example of the interface I see in my head. Of course this needs tons of work, but the concept is there. 

I have created a tool like this: https://shoresofnis.wordpress.com/utilities/ne_q1spcompilinggui/ but feel free to make your own, mine is getting on in age and it doesn't have the best setup and some things can be awkward to do like switching to different maps that have different configs.

If i ever go back to it, i'd probably make the ability to save 'presets' so you could load a different configuration for different maps (including different compilers)... but yeah, dunno if I will.

I should probably just rewrite the thing in C# instead of VB anyway. 

Lol, i wrote what you see in html, css, (jquery, javascript) and VBscript. That's why it's windows only, it's an HTA.

I stripped the crap out of another project for the basic interface, styled it black and white right quick and detailed the light tool for example purposes.

The cool thing is: I already wrote a savable profile code that I don't even need to tweak cause it is REALLY dynamic, and the code to run your selections as a command line is actually in the image I posted, right behind the app.

In other words. I could probably make this entire app in one day just by cannibalizing (-sp) a different project, and customizing my collapsible panel info to erics docs. 

At this point, you should probably just do it. If you'd written code instead of all these words, you'd be done by now. :P 

 

Truer words have never been spoken @ Spirit, and posts like Warrens crush it.

@Warren, Imma pretend you didn't say that so I don't feel the need to bitch slap you through the internet. 

Actually, I'm just done. It's time to find a social group that promotes being social. Enjoy your ents and fgds. I'm probably done at Quakeone too. I just don't feel this shit anymore. 

don't get the point in forum drama. It's not like the quake community is super tight, it's fragmented as it is. 

Good lord, I added a smiley. Sorry you got all butt hurt. 

My post wasn't meant as insult, it's nothing special to tick that way. 

 

If anyone wants to play with it, I posted some alpha builds over at inside3d at the bottom of the first post:
http://forums.inside3d.com/viewtopic.php?f=3&t=5696

Note that the format is not frozen yet, so please don't release maps using it yet :-) 

The pain of having the light compiling twice... ouch.
And .lit2 files are pretty big (only done a .5 lmscale so far). Like 3 times bigger than the original .lit file! 

Screenshots or GTFO. 

I'm trying to get a shot of the x16 lightmap-ness. It's taking an eternity to compile. I gave up on doing a full x16 pass after the line didn't move, instead I'm choosing a very select couple of surfaces.

I have to say though, even on 0.5 scale it's really really nice. I think having 0.5 scale as the default for .lit2 and then being able to up-res other areas should be the way .lit2 works IMO. 

http://i.imgur.com/Zu35DBO.jpg
jam2_sock relit with "-lightmapscale 0.25 -extra" (so 4x vanilla resolution) 

1x res
https://www.dropbox.com/s/60oyen21bv83nc3/1.png?dl=0
https://www.dropbox.com/s/hdiiyktnsm56e6l/2.png?dl=0

2x res
https://www.dropbox.com/s/rsbvrohtens5ouc/1-2x.png?dl=0
https://www.dropbox.com/s/7eham7t5t8a9j68/2-2x.png?dl=0

16x res
https://www.dropbox.com/s/rtp7cildc0khzp2/1-16x.png?dl=0
https://www.dropbox.com/s/3ckqik3odfx4ko1/2-16x.png?dl=0

textured comparison, 1x res and 16x res

https://www.dropbox.com/s/xpz05jtj2p4dve7/start-1x.png?dl=0
https://www.dropbox.com/s/2pr08ltxp1bq1fs/start-16x.png?dl=0


Takes a fscking long time to compile at 16x res. Looks pretty awesome. File size for .lit2 at 16x res is 7mb, 2 floors were converted to func_detail and are the only areas with the higher lightmap. Took 20 minutes to compile 16x compared to 20 seconds on normal. Normal .lit is 449kb.
This is on my start map for retrojam 3.

I dunno if model lighting works well on 16x (model light is based on the floor luminosity rather than light entity), seems to get light or dark but doesnt always correlate to floor lighting. Probably needs more testing.

I think 2x scale is nice. 4x scale is probably going to be what most people will aim for. 8x at a push. I can't see myself wanting 16x normal lightmap res. 

i think I prefer the blurry lightmaps in those examples... the high res ones just look like crummy doom3 shadows. 

You'd likely want to approach lighting differently when at high resolution. Rather than do a single light entity that will cast stark shadows, which is ok when you have blurry lightmaps, you'd want a few slightly separated lights combined so that you get a penumbra effect to the shadows. 

thing is that adding more lights increases light time by a lot since each light is traced on every face, regardless of visibility or whatever. :( 

i think the solution is to scale the antialiasing and the soft effect to now match the new resolution of the lightmap. 

Yeah, you're probably right... thought -soft or -extra really affects compile time...

speaking of, ericw warned me this might happen on twitter... here's jam5_scampie with 16x lightmap and no other fancy options

http://scampie.net/etc/ohgosh.jpg

seems we hit some limits here? 

Thanks for the initial testing!

Careful with -extra/-extra4, they do make the compile roughly 4x/16x longer, and this will stack up with -lightmapscale to give you really long compiles. "-soft" should have much less performance impact, not sure exactly, but it does work against the resolution gain by blurring the lightmaps.

"-lightmapscale 0.25" with no "-extra" should be the same compile time as "-extra4" with no "-lightmapscale", as they both have to compute a 4x res lightmap.

Fifth: I think you found a bug with mdl lighting, and I got a comment from MH about the code being missing for that, so I will look into that.

necros: yeah I agree the 16x does look like a bad stencil shadow. scaling the "soft" effect is a good idea, haven't yet looked into that. 

Rather than do a single light entity that will cast stark shadows, which is ok when you have blurry lightmaps, you'd want a few slightly separated lights combined so that you get a penumbra effect to the shadows.

There IS a convenience option for this, which I stole from q3map2, setting "_deviance" "8" on a light entity will turn it into an 8-unit radius sphere of lights. Default if you use _deviance is to create 16 lights, but you can customize it with "_samples". This will slow down compiles of course! 

Also, everyone disregard that pic I posted... I had forgotten to copy my .lit2 files into the right directory (necros, your compile gui doesn't copy .lit2 files for me you scum!!!!), and had made some out of date .lit files because it seems that when you generate a .lit2 file, no .lit file is created so you get out of sync really easily. 

source is here good sir. ;)

but yeah, I should try to get around to that if this is going to become a common lighting thing.

I'm still not convinced 16x is necessary. 2x or 4x with scaled blur effects. Oh and deviance lights, utterly badass. 

Nice thumbnails, asshole. 

easily prefer the 1x lighting. But yeah could be because lighting method/other cvars unchanged. 

Also, everyone disregard that pic I posted... I had forgotten to copy my .lit2 files into the right directory

so post the fixed shot shrimptease 

TRIP REPORT ON 16x RESOLUTION AND -EXTRA4 AND -SOFT

After 2.5 hours, a 337mb .lit2 file was made. Quakespasm crashed with AllocBlock: Full even with "-heapsize 655360" 

lol... and how many lights and faces were there? :P :P :P 

Sorry about that, the "AllocBlock: full" is when you exceed the hardcoded lightmap limit in QS. Even if it did load, performance would be awful because dynamic lights are all rendered on the CPU. The 8x and 16x options are probably best avoided, or only used very selectively.

jam2_scampie looks pretty nice with "-extra -lmscale 0.25", though, and only takes 4 minutes to light.

I really need to code the thing that automatically lowers the resolution on faces with no detail. 

It's jam2_scampie, so it's not excessive, but it's reasonable for a proper sized map.

4x resolution seems to be the max for this level, generating a 23mb .lit2, anything more and the .lit2 is too large to be loaded.

These are comparisons with -extra and -soft between standard .lit and .lit2 with 4x res.

area1, lit, textured
area1, lit, lightmap
area1, lit2, textured
area1, lit2, lightmap

area2, lit, textured
area2, lit, lightmap
area2, lit2, textured
area2, lit2, lightmap

The gains in this map are mostly in the spotlights being a bit sharper... but it's not very noticable when set against these textures. Perhaps a less noisy/dark/ugly set would be a better test? I'll give my Jam5 a go, since 4x isn't too excessively long to compile. 

Yeah it really doesn't add anything to jam2_scampie in those comparisons, even the upward pointing spotlights probably look better in the vanilla version 

To be fair, I also don't rely on shadows that much in my lighting. Mostly because Quake is so blurry (and I suck at lighting...)

As a bonus though, in my Jam5 map I notice I can actually get some lighting on some of the detailed faces I wasn't able to light correctly. The blue crystals and grass bits actually receive lighting on their small little faces much better... experimenting a bit now with the hanging vines to see if I can make them cast shadows, which I opted not to do because they were so blurry previously. 

does "_shadow" "1" not work on func_illusionary? 

This latest build needs the '-fence' commandline flag to do the tracing through fence textures. But without that, a func_illusionary with _shadow 1 should cast a solid shadow 

no... again my bad... I kept saving jam5_scampie.map and not saving as jam5_scampie_16.map which is what I was compiling... *headdesk* 

Added shadows to the func_illusionary hanging vines compared to the released version... the differences here are subtle. It's all in the details, you can get some nice crisp shadows, and in some cases that really pops and is noticeable... but often the subtle nice differences in the lightmap are lost when mixed with textures. Again, -extra and -soft, the .lit2 is 4x resolution.

area1, lit, textured
area1, lit, lightmap
area1, lit2, textured
area1, lit2, lightmap

area2, lit, textured
area2, lit, lightmap
area2, lit2, textured
area2, lit2, lightmap

area3, lit, textured
area3, lit, lightmap
area3, lit2, textured
area3, lit2, lightmap

area4, lit, textured
area4, lit, lightmap
area4, lit2, textured
area4, lit2, lightmap

area5, lit, textured
area5, lit, lightmap
area5, lit2, textured
area5, lit2, lightmap 

Basically... not sure it's worth an extra ~25mb of download for general use. There's some nice treats and bonuses here and there, but unless you're doing some really detailed shadow casting, it may not be worth it?

My maps and lighting style may be a bad example though, I tend to light and make bright highlights rather than cool shadows due to the low res nature of Quake's light maps 

Thanks for the comparisons Scampie.
It's entire possible this isn't really a useful feature for quake's visuals, or at least for most maps.

I guess the main thing it gives you is the ability to have harder edge shadows without stairsteps. e.g. for sunlight casting an angled shadow, with the default resolution, you have to blur quite a lot to get rid of the stairsteps. So the problem may be, the harder edged shadows may not be desirable anyway.

Regarding file size, the optimal way to use this is just enabling it on brushes that need the higher res, and this will both shrink the .lit2 file as well as have less of a performance hit. I'd recommend never using the map-wide resolution setting on a release version of a map, and only using the per-brush setting. 

I will make sure that all my maps are minimum 16x res shadows...

I wont play by your rules!!!! 

would global 2x res be worth doing? Filesize prolly wouldn't be too bad? 

Like I said, don't call this a bust or anything yet. I'd approach my lighting differently if every/most things had crisp shadows, because I'd want to highlight those more often rather than the ugly blobs we currently have and use a bunch of blurring to make look passable. 

are there any quake maps that actually use cast shadows really well? We should test on those. I'm thinking like, dm2 and dm4 have a lot of shadows behind grates and stuff. 

dm6 stairs maybe? 

Don't know that it's the best test case, but dakyne is what came to mind first. 

here's DM2, compiled with -extra4 -soft -dirty -dirtscale 1.5 -dirtgain 0.9 -lightmapscale 0.25 (4x resolution)

area1, lit, textured
area1, lit, lightmap
area1, lit2, textured
area1, lit2, lightmap

area2, lit, textured
area2, lit, lightmap
area2, lit2, textured
area2, lit2, lightmap

area3, lit, textured
area3, lit, lightmap
area3, lit2, textured
area3, lit2, lightmap

area4, lit, textured
area4, lit, lightmap
area4, lit2, textured
area4, lit2, lightmap

Obviously DM2 wasn't made with this in mind, but I think this does show were some of the higher resolution lightmaps can make a big difference. 

DM2 is definitely a good showpiece for this new feature 

just tried to compile dm2 at 16x with all those settings...15min compile to make a 93mb .lit2 that is too big and crashes :_( 

I was testing fte with a 173mb lit2 before I started messing with projected lights.

(side note: xz compessed it to 14mb, so if you can cope with the load times then its not completely impractical to distribute, just use 7z or xz instead of zip or gz - assuming lit2 was a finalized file format anyway) 

I prefer the blurry lit1 shots in all of those examples. 

scamp - any chance you could post a shot of area3 with 2x instead of 4x? 

Wait dont we have area lights support in these compilers? If so then you can have sharp bases for the lights that widen out and look super sweet with this new resolution.

http://area.autodesk.com/userdata/forum/3/3dsmax_viewport_shadows.jpg 

Not going to bother with 2x. That goal isn't 'find a compromise where higher resolution and American McGee's lighting from 1996 looks good'. The goal is to make a high resolution lighting system, and make THAT look good. 

keep your trousers on. 

I disagree. I don't like the 16x lighting. The hard edges and sharp shadows don't look good to me. What I'm looking for is a 2X, maybe a 3x, improvement in resolution. That would give me what I need to make Quake levels look better than they do today while still retaining the look that makes them work. 

I came to the conclusion that either 2x or 4x could be the new standard for modern mappers. I'm certainly going to map with this in mind. 

I think one of the factors making the DM2 shots look bad is the unnatural approach id took to lighting back then, using multiple lights to represent light from the sky as this screenshot taken at Scampie's location 3 indicates - http://puu.sh/hVGCZ/4ed3224645.jpg (taken with DarkPlaces and r_editlights 1 for the sake of convenience).

As a result, you get shadows being cast in several different directions, in a location where one sees a sky above and no other light source and thus expects all shadows to be cast in the same direction. Consequently it ends up looking weird when they aren't. This wasn't quite so prominent with lower lightmap resolution.

I think of all the screenshots Scampie took, the one at location 4 looks best, and that's not surprising since there is only a single light source there - http://puu.sh/hVH6K/089cd1541c.jpg - and thus it looks more realistic. However, as others have said, even in location 4 there is the issue of the shadows looking unnaturally sharp a la Doom 3 and the increased resolution can produce that old problem of better quality media appearing dissonant with the low fidelity of most of the game.

Nonetheless, ericw, I think once people have worked out what combination of compile options works best for a given scenario, this will be a really nice feature and I wouldn't be discouraged by the mixed results so far. 

Correction: the first screenshot in my previous post is actually Scampie's location 2. 

AFAIK id never had the ability to scale lights using the options we have now, they certainly never had things like skyboxes casting light in pretty much any uniform direction. 

Yes, like I said, DM2 obviously wasn't lit with this in mind, of course it looks terrible. The test was for curiosity, and to see how much of a difference higher resolution lightmaps make on a map which relies heavily on shadows (as opposed to my maps, where I rely more on bright highlights of light)

And yes 5th, the original tools had no falloff options, no sunlights, -extra was the only compile option for added quality.


Anyone know a decent decompiler? I'd actually like to take a stab at relighting DM2 with a proper sunlight setting 

all the map sources have been released by romero... you can pretty much just use that to redo everything.

No idea where you can find the files, it used to be on romero's website but that hasnt worked in a while. 

oh... must be on quaddicted somewhere. 

https://www.quaddicted.com/files/maps/sources/quake_map_source.zip 

Here it is -

http://www.quaketastic.com/files/single_player/maps/quake_map_source.zip 

I disagree. I don't like the 16x lighting. The hard edges and sharp shadows don't look good to me. What I'm looking for is a 2X, maybe a 3x, improvement in resolution. That would give me what I need to make Quake levels look better than they do today while still retaining the look that makes them work.

Remember that at the moment, soft edges are not working correctly as they are not scaled to the resolution.

One of the things that might be interesting to explore with the new resolution is to have shadows change hardness based on distance of light to shadow caster to shadow receiver. If you can fake that, or if you need to resort to light arrays, either way, that would be one way to exploit the higher resolution without it just looking like lame Doom3 stencil shadows. 

Yea that is why I was asking about area shadow / Area Lights support.

With the new BSP / Material lighting option you can get that effect. But the light source is always visible as GEO. Not a bad thing I guess but be nice to have BSP materials cast light and then be tossed out once compiled or with no rendering or collision. 

Couldn't find anything on how area lights are implemented in raytracers, but the _deviance/_samples keys can probably emulate it (or they may be the same thing as area lights?) 

I'm not sure too much more needs to be done for softer edges, assuming you light with higher resolution in mind.

Here are some shots of my relighting of DM2. No, it's not true to the original; this is more to get a feel for how decent high res lightmaps look when you light with them in mind. No comparisons.

Shot1: Textured | Lightmap
Shot2: Textured | Lightmap
Shot3: Textured | Lightmap
Shot4: Textured | Lightmap
Shot5: Textured | Lightmap
Shot6: Textured | Lightmap
Shot7: Textured | Lightmap
Shot8: Textured | Lightmap

Download if you want to see it in action or compare things or just look at the .map file... realize that this isn't a proper release, needs a .lit2 compatible engine, and will likely break if file formats change...blah blah blah... 

above shots are 4x resolution lightmaps, with -soft and -extra4. 

1 comparison, to show the sorts of details in play here... compare to shot3

textured | lightmap 

actual link to lightmap comparison

sorry my head is broken it's 4am 

 

For screenshots showing off lighting, those are some of the blackest images I've ever seen. 

That said, once I level them in Photoshop, VERY nice. 

Scampie can you reupload your DM2 again? that link is dead. 

sorry, the download link was owned by caps... this is why you do things when you are awake and paying attention....

http://scampie.net/privfiles/DM2_lite_052215.zip


warren: yeah, sorry... my monitor apparently doesn't look like anyone else's and my screenshots always come out too dark :| 

If we are going down the road of .lit2 + special engine support...

Could we introduce lightmaps on liquid surfaces as part of lit2's features?

Quake's ugly fullbright water is one of the big immersion-breaking things imo, and it would be cool to update that a bit :} 

Thanks Scampie. DM2 looks a million times better. I recently ported DM2 over to Quake 3 and give it a similar treatment.
http://i1187.photobucket.com/albums/z382/AndehGX/quake3/axq1dm2.jpg

Also, does anyone still have Gypsy's .ent and virtuoso pack for Quake 1? I lost it in a format, and his links are dead :/ 

Could we introduce lightmaps on liquid surfaces as part of lit2's features?

Yes plz! (need to have some way to make lava fullbright though!)

--

I calibrated my monitor (brightness was way too high) and adjusted levels on my screenshots in post #435 and reuploaded them, hopefully they aren't super dark anymore? Think the map itself is actually lit too dark, but it's not terrible. 

Hah, the same request came up in the inside3d thread. I think it can be done in a way that's backwards compatible, without needing special support in lit2. It'd probably be a "-litwater" flag for qbsp and light; qbsp would use it to chop liquids on the 256 grid (they aren't normally chopped), light would generate lightmaps instead of not. Pretty sure engines not supporting lit water will just ignore the lightmaps (but need to verify this.)

According to LH, DarkPlaces will already render them. 

Could we introduce lightmaps on liquid surfaces as part of lit2's features?

This doesn't actually need LIT2 at all. You could do it with a regular light tool and some engine modifications.

It would also need QBSP modifications because by default liquid surfaces aren't subdivided as much as solid ones.

But you probably don't want this at all, because in most cases it actually looks worse than fullbright water. 

yeah, you can't light water without going into a whole consideration of how light interacts with water. eventually you'll put a fancy portal2 water shader alongside 300-poly monsters and you get this silliness:
http://quakeone.com/~files/ss_e2m1_FN3.jpg 

mmm yeah, you're right... in Lun's example pic, that water would just be standard Quake water, except tinted bright yellow by the bright yellow lights. 

I don't have the game right now to check, but didn't Quake 3 just have lightmaps on top of simple Quake-esque water?

Coupled with transparency, it didn't look too bad if I recall? 

http://scampie.net/etc/q3_water.jpg

think q3dm10 is the only place it's used in stock q3?

It does look reasonable, but might only work because there's like 3 layers of mostly transparent water textures blended with the light. 

I reckon vertex-lit water would be reasonable, with a single vertex colour for the entire water plane. Of course the mapper would need to be careful about the placement of lights relative to water so that we don't get weirdness like water surfaces half-in and half-out of a really bright area. But it would solve what I guess is the primary problem here, which is a fullbright water surface in an otherwise uniformly dark area.

Much of that also goes away with translucent water, where the water surface blends with the underlying geometry. You almost certainly don't want to add lightmaps there - light is supposed to shine through water, after all.

Another problem with lightmapped water is that the lightmap can obscure the turbulent warp effect. Under certain conditions it just looks like a regular solid surface (until you walk into it).

Shadows being cast on water surfaces also looks wrong.

To be honest, and having implemented this in the past (but with realtime light rather than lightmaps), fullbright water is really just the lesser evil. Lightmapped water falls apart real quick once you move away from just wanting it and graduate to actually thinking about how it would look. 

Shadows being cast on water surfaces also looks wrong

http://i.imgur.com/5GU8rQi.jpg
http://i.imgur.com/f10kgnE.jpg 

Looks wrong somehow. 

Vertex-lit water like mh suggests could actually be good, just avoiding super-bright water when you're putting it in dark areas likely would be enough.

Tricky part might bebackwards compatiblity and lava which should be fullbright no matter what. But it sounds like a reasonable approach to try 

http://i.imgur.com/5GU8rQi.jpg
http://i.imgur.com/f10kgnE.jpg

The first one looks OK because you can still see the water effect through the shadow.

The second one looks like concrete.

Both are completely irrelevant because we're talking about Quake water here.

Tricky part might be ... lava which should be fullbright no matter what

QBSP identifies lava by the presence of the word "lava" in the texture name, so the light tool and the engine could do the same and just skip lighting/draw without lightmaps. A modified QBSP could of course identify lava by something else.

I'm of the opinion that teleports should also be fullbright, and slime should at least have some light of it's own too. QBSP also identifies "slime" like it does "lava", but doesn't identify teleports. 

You're right about teleporters, but it might not be that large of an issue since they are generally placed in bright places anyway. Slime I could take it or leave it if it were brighter than water or not, you're likely right that it's more commonly meant to be brighter than normal though.

maybe a good idea for something like this to have cvar scalers like r_waterbright 0.X, r_slimebright 0.X, and r_lavabright 0.X, and default those to sane values? 

You're right about teleporters, but it might not be that large of an issue since they are generally placed in bright places anyway. Slime I could take it or leave it if it were brighter than water or not, you're likely right that it's more commonly meant to be brighter than normal though.

maybe a good idea for something like this to have cvar scalers like r_waterbright 0.X, r_slimebright 0.X, and r_lavabright 0.X, and default those to sane values? 

You're right about teleporters, but it might not be that large of an issue since they are generally placed in bright places anyway. Slime I could take it or leave it if it were brighter than water or not, you're likely right that it's more commonly meant to be brighter than normal though.

maybe a good idea for something like this to have cvar scalers like r_waterbright 0.X, r_slimebright 0.X, and r_lavabright 0.X, and default those to sane values? 

If crisp shadows look bad on water, maybe lower-res lightmaps on water are an option?

I think the main goal is to just get darker water in dimly lit areas of the map - not to make super realistic looking water. 

-setting a low r_wateralpha
-using dark water textures
-use a darker .tga for the water texture, to avoid quake palette limitations 

If crisp shadows look bad on water, maybe lower-res lightmaps on water are an option?

I think the main goal is to just get darker water in dimly lit areas of the map - not to make super realistic looking water.

this is the kind of thing that would really need to be tweakable. there are many different effects someone might want to try for. Say your water is muddy, then a harder shadow makes sense. But it might be clean lake water, so a much softer (or no) shadow may be called for. thing is, none of that can be inferred from the texture name (*water) unless you get into fancy stuff like (*waterHazy vs *waterHard) or some such but it would be better to just have a .txt file with some values in it that is read by the compiler in that case. 

Both are completely irrelevant because we're talking about Quake water here.

I wouldn't say they're completely irrelevant. After all, they're photos of what water looks like in the real world and given that Quake is designed to render the real world with as much accuracy as possible (to the extent possible in 1996 and to whatever extent we judge now to be in keeping with its original fidelity/style), getting water that's as accurate as possible within those constraints should be worth attempting.

Obviously no one's suggesting we start pursuing a proper simulation of how light interacts with water, including refraction, reflection and so on, but a simple approximation of real water might be to say that clear and/or shallow water ignores shadows and instead lets them cast on whatever's below it, whereas murky and/or deep water allows shadows to be cast on its surface.

Ideally that might be done like the new texture lighting is done, with each texture being assigned a certain level of transparency. If it's flagged as, say, anything below 0.7, it doesn't allow shadowing on its surface, if it's above 0.7 it does. So you might might specify *water0 (used in the stream at the start of e1m1) as 0.5 transparency because you intend to use it for shallow, clear water, whereas you might want *04water1 from the start of e1m2 to be used for filthy, murky water and thus you assign it a transparency of 1.

Obviously you'd want any map that uses this to disregard whatever value the player has set for any r_*alpha settings.

Not sure how technically feasible all that would be, but it would make water look better, while staying true to Quake's modest looks and allow mappers to configure it in a fairly intuitive way. 

kinn's examples aren't shadows on water, they're shadows on the dense silt suspended in the water. water is transparent:
https://mw2.google.com/mw-panoramio/photos/medium/18556818.jpg
and lightmaps on clear or partly transparent water are what look strange, because they're not coupled with a volumetric fog component to explain the shadow to the eye.
https://developer.valvesoftware.com/w/images/8/88/L4d2_flowmap_user.jpg 

Its only the specular term of the water surface that is visible - its reflections (also, those little white specs you get on the tips of waves that are annoying to model correctly, resulting in most games having far too shallow waves).
Obviously there needs to be some sort of fog effect when the water contains impurities that reflect light, and this can have shadows cast upon it. good luck getting that realistic though.
Following on from that thought, any water fogging needs to know the surface plane of the water - and on maps like dm3, there is no singular plane, and that just makes any sane waterfogging logic go crazy.
If the water surface is reflecting light then this of course means that there should be a darkening of the surfaces below the water line. Also, any water impurities should cause the lights to have a higher attenuation for the parts of the ray that travel through the fog, relative to the amount that gets reflected up and away from the water volume before it can reach the surfaces below.
Also, lights shallow angles will reflect some light from the surface of the water rather than through the water (fresnel effect), increasing with how close to the water plane the light is - and of course, if you have waves then the closeness varies...
This is all very interesting if you're writing some glsl (yay for cubemap refraction and screen-space difraction), but if you're writing a static tool then you're basically doomed. DOOMED I SAY! Okay, melodrama over, but imho the best you can do is just use a single light value for the entire water surface (which of course might need to consider the intensity of the water texture too, which iirc is typically a little darker due to not expecting any lighting ever).

It might be interesting to generate really low res lightmaps for water, and by really low res, I mean one lightmap sample for every 1024qu or something. However, with that sort of scale, I expect you'll have a whole load of issues with vertexes inside walls and other sorts of issues. calculate at 1/16 and average it something like -extra4 already does? 

FFS, it's Quake ... what could possibly look worse than the fullbright water surfaces we have now? Just try something. Anything. :) 

Hmmm - well, it's possible to set things up so that water recieves light but doesn't occlude it - which actually looks mostly OK!

http://i.imgur.com/lDKcJs7.jpg 

Warren speaks the truth. Let's not get sperged down by details of physically realistic water.

I reckon:

ability to specify lightmap resolution on liquids - as discussed, lower resolutions than usual will probably look better.

0-1 float value to define liquid lightmap "influence" - 0 = fullbright surface as before, 1 = full lightmap, as if it's a solid opaque surface.

For lava, I'm sure you'd want 0 always, but for slime and water, I reckon there's a happy medium somwhere. 

 

And then normalize the color maybe?
Just thinking out loud here...

float Alpha = magnitude(lightmap.rgb)
float3 LightColor = normalize(lightmap.rgb)
float3 Color = texture.rgb * LightColor
output float4(Color, Alpha)

Haven't written any shaders in years, can't remember how it's actually done.

Maybe skip the color and just use intensity
Maybe this would look completely weird... 

the reason why we dont have lightmapping on water was because the water texture warps around and moves, and the lightmap would move and distort with it? 

Not necessarily. It's possible to warp the water texture but not warp the lightmap. 

I do hope this is something that gets implemented then, fullbright water is crap. 

Is gorgeous, lets just do that ;)

Theres no clean water in quake anyway! Shub-n-word-erath and his buddies have been jizzing in it for aeons, we all know that. Does no one even read the back story? 

https://www.shadertoy.com/view/MtB3DK
Click and drag around to mess with the alpha values! I'm sorry I suck at this! 

I'm not quite sure I see the appeal of what's going on in that czg...thing - but let's stick with the czg theme for a bit and just remind ourselves about this sort of thing:

http://i.imgur.com/htecdQb.jpg

We've been using those crummy "waterfall" textures for years, and they get lightmapped, and I don't think anyone's complained (about the lightmaps on them). I think they look alright don't they? I still don't get what's so terrible about just trying that on the proper liquids. 

Well... that's something we can test right now with the tools given to us. Here's a crummy waterfall made of func_illusionarys with "alpha" "0.65"

http://scampie.net/etc/transwater_1.jpg
http://scampie.net/etc/transwater_2.jpg

It looks okish when viewed from above, but once you get to about chest deep in the water, you realize it's just a plane of animated texture and it starts to look fake. It's not the worst thing in the world, but certainly not convincing.

here's the .bsp and .map and all that. requires an engine that supports "alpha" key on brush models (fitzquake engines)... if you want to compile the .map so you can fool with the alpha values and such, you'll want ericw's tyrlite becuase it's mostly lit with sunlight and sunlight2
http://scampie.net/etc/transwatertest.zip 

"It's not the worst thing in the world, but certainly not convincing. "

This implies that it was convincing before. 

Well, what I meant is it looks odder where you have a lightmap on the transparent water because you lose a sense of it having any volume. The bright spots on the surface of the water call attention to the fact that there should be lighting on some volume inside the water as well, so it ends up just looking like a flat plane suspended in the air. In a modern engine, people would be putting volumetric effects and fog in the water to hide exactly this.

http://scampie.net/etc/transwater_3.jpg
Uniform brightness of the water surface, despite being too bright here, seems to sell volume better. Without the added transparency of the shadowed areas revealing that the light isn't hitting any particles in the water, your mind fills in that the water must be dense. I think if this were simply vertex lit to end up being closer to average brightness of the area it would look fine. 

I for one love it. And just leave it up to the math authors to support it or not. This on muddy swamp water would look great. This could work nicely when used on fake ground fog as well. 

Just started with corridor for the level introduction. I'm not even sure if that matches the theme in anyway, also I wasn't using any level editor for like 7 years, so it is just a quick sketch to remember basic things:

http://imgur.com/a/rGJIz 

Quick fix for geometry, small changes for light and texturing:

http://imgur.com/8GSFG88 

I think you're in the wrong thread. :)