News | Forum | People | FAQ | Links | Search | Register | Log in
TyrUtils V0.11
TyrUtils v0.11 has been released:

*Support BSP2 format (qbsp requires the "-bsp2" command line option)
*qbsp: Fix animating texture bug when brushes are textured with alt-animations
* qbsp: Fix a crash in tjunc calculations
* qbsp: Exit with error if verticies exceed 65535 (BSP29 limit)
* qbsp: Add experimental "-forcegoodtree" command line option (thanks Rebb)
* vis: reduce "leaf recursion" error to a warning and continue processing

Download from the utils page as usual (Win32 / OSX / source).
Heh - I'm soon to have a gargantuan sandbox hull to test the BSP2 functionality >:) 
Hmm... Thats Great! 
Just can�t figure out how to run it under OSX... 
which bsp2 version is supported? 
Is there any chance you can add the following options to the qbsp.exe?
-q2map : Enable Q2 style map format
-group : Enable func_group parsing
@mfx: these are command line apps, so you need to run them from the terminal

@sock: func_group should already work (no command line option needed). I'll look into the Q2 map format - I think there's just some extra fields to ignore? 
@gb: I think it's known as the RMQ version. The one the Tronyn used for the "Wicked" maps. I implemented it using this guide
some extra fields at the end are ignored and also the textures need to have paths stripped from them. dunno if there is anything else. 
i know, but it happens nothing after prompting to vis and such... 
Doesn't only the RMQ engine support BSP2 format maps? 
FTE does it as well..? 
I think RMQ, FTE, Darkplaces and TyrQuake snapshots all support this BSP2 format. 
I think DirectQ, QuakeForge, and probably either Proquake or Qrack do as well.

Engines have moved to supporting both of the slightly different implementations - they can be told apart by looking at the BSP in a hex editor I think, one uses "BSP2" and the other uses "2PSB". 
Isn't*checkout*/remakequake/engine/Experimental/BSP2Tools/BSP2%20for%20Engine%20Coders.txt the wrong one?

Wicked used the wrong one and was never fixed.

It would majorly suck to leave engine coders to have to support two versions, kind of like a nehahra thing. 
I'm still here. I am going to be using BSP2 for all remaining maps. Point me to a set of compilation tools that creates the correct version of BSP2 (and supporting engines), and I'll recompile Wicked and use those tools for future maps as well. 
Well damn, guess I'll need to implement the "other" bsp2 format as well. 
It would majorly suck to leave engine coders to have to support two versions, kind of like a nehahra thing.

Nah, not in this case. The differences are minor, mostly the magic string being 2PSB vs BSP2. This is not a big problem tbh, just be aware that not all engines support both versions.

FTE is an example engine that supports both, I believe DP and QF do as well. 
As you can see, Tyrann did implement one version, not both. Could you at least update the documentation so people following it end up with the final spec?

How many maps with the wrong format are out there? Can't they just be recompiled/edited to the new format and then we can forget about the old format forever? 
It looks pretty easy to support both, but I'd like to see if there is some kind of consensus out there as to which one is bsp2 and does everyone call the other one bsp2rmqe or something else. No time this weekend, but I'll look into it more next week. 
personally I'd go with -bsp2 and -2psb. Call a spade a spade sort of thing. Hopefully the 2psb format will die just as soon as someone bothers fixing rmqe... 
The BSP2 Schism 
The "BSP2" variant was intended to replace the "2PSB" one after RMQ consultation with Lord Havoc, who requested these changes for BSP2 support in Darkplaces. From RMQ side, I agreed to those changes - in hindsight, maybe I shouldn't have. The situation is simply due to the mod (and the engine) dying before the change could be implemented. At that point in time, the mod team had mostly trickled away, meaning the people in key positions were just absent. There was nobody left who could do tool and engine coding, and thus the RMQ BSP2 toolchain uses 2PSB to this day.

The RMQ engine is dead, as far as I know, since MH has no time and is exclusively working with DirectX now, and to my knowledge neither of the RMQ successors use the engine anymore.

It's kinda sad, because it is a kick-ass engine that's in so many ways ahead of its time. I still love the engine and I might yet do something with it.

If you're looking for a standard, I suggest BSP2 - like Spike says - since it was the intention and it might just make sense.

For the specific set of changes between 2PSB and BSP2, people should consult the Darkplaces and FTE code, or LH and Spike, respectively. I'm not an engine coder. From the tools side, I believe hmap2 and the Quakeforge tools support "BSP2". 
there is always q3bsp, which is supported by DP and FTE, and last I heard most Quake players use DP anyway. It's just the logical conclusion, really. BSP2 is an iffy compromise to begin with.

You can make Quake maps using q3bsp just fine, you'll just need to convert your wad textures to TGA or something. And viola, low resolution textures in q3bsp. You don't even have to use those horrible curves and shaders, except for things like sky and liquids. But I guess this will be seen as heresy :) 
I love the RMQ engine, but it doesn't work on my surface pro.

Is there a point to using BSP2? I thought most of the features had been ported over anyway (like func_detail brushes etc)... 
Im Using It (BSP2) 
You can make even bigger maps than the standard extended format. Which was only double. This is double again, isn't it?

It's kinda cool :)

I still see the engine side and the new tools that mh provided (Aguire + BSP2) as the new pinnacle. RMQ is (to the layman anyway) Fitz+++. This is why I would love to see Fitz Mk5 support it. Because it's such a cool engine, but I wanna make maps with 128k marksurfaces and crazy awesome coloured lighting, thank you very much. :) 
Fixed flickering entity (admittedly now a moot feature with detail brushes).

The engine also has various under the hood optimization a for multiple animated light styles and running big maps. And I mean big - even Tronyn's maps haven't yet pushed the limits of the engine in terms of massive open world.

In theory, using Tyrann's detail brushes as your structures and a giant trisoup of the terrain courtesy of trenchbroom a Minecraft in Quake level is possible.

Might even give it a go when I get back, with Preach's flyer vehicle as an enemy.

Even if it fails horribly it'll still be an interesting challenge... 
Flickering Entities 
Can be fixed with one line in progs.h:

#define MAX_ENT_LEAFS 64 
I'll look into the Q2 map format - I think there's just some extra fields to ignore?
I am not sure, I know it is a Q3 format because it has a lot of extra surface information. If you need a sample map file, let me know. 
The Only Differences 
are the additional directory in the texture name and three additional values at the end of each face definition: surface contents, surface flags, and surface value. You can just skip those. 
TyrUtils V0.12 
New version is up with support for the newer/better LordHavoc version of BSP2. Qbsp will create BSP2 files in this format with the -bsp2 command line. All other utils understand both kinds of BSP2, so you can still light and/or vis your '2PSB' maps if you want to use another Qbsp compiler.


* Implement the Darkplaces (LordHavoc) style BSP2 format and use as default
* Still support the RMQ style BSP2 format (but don't create any new ones)
* qbsp: Fix bug causing sky brushes to be non-solid

Download from the utils page as usual (Win32 / OSX / source). 
It seems 0.12 (didn't test 0.11, the last version I used was 0.6) no longer automatically adds the entire animated sequence of textures to a .bsp. If you use +0blah, the .map has to include faces with +1blah and +2blah for tyrqbsp to include those textures. Was this intended? 
I mentioned this in one of the emails a while back, but maybe it got lost in the shuffle. Or I didn't.

By the way, the error message change as opposed to critical stop fixes the .map I sent a couple of weeks ago?

Miss mapping, have a few random ideas I'd like to experiment with as well... 
Well My Map Compiled 
It's not ridiculously huge but it does break a lot of limits. By the time I've finished detailing it will definitely break limits.

Good news - tyrqbsp compiled the map. Didn't get warnings either, and the map ran in darkplaces (latest windows auto build), and the map also compiled with TxQBSP but only after a mit of messing around with leaks n stuff. It tried TxQBSP first, by the time I fixed all of the leaks I was still getting about 50 warnings.

tyrqbsp just compiled it fine (with the -bsp2 option). 
When I Say TxQBSP 
I really mean mh's TxQBSP branch 'TxQBSP2'.

So, are there any Fitz-branch engines that support the Darkplaces BSP2 format? Ir is Fitz still on RMQBSP2 only, via MH's RMQEngine?

Does DirectQ support it, or anything like that?

Too lazy LMGTFY 
That post was more of a direct question for Tyrann since I've been throwing wip stuff at him for a while now. Aside from making a level / mod my ulterior motives we're give some feedback on both these tools and Trenchbroom. 
The os8 update seems to have locked my email accounts on the tablet since I'm currently overseas - which is why I didn't send one. 
@scampie: hrm, that's a bug. I'll look at that today.

@ijed: I'll take a look at your map today. 
Ricky: Nope and nope. DP and FTEQW support it. 
I'll be back in a week or so... 
TyrUtils V0.13 
This one should fix the issue with ijed's map and the animating textures bug that Scampie pointed out.


* Fix handling of func_group/detail entities with no solid brushes
* Fix automatic adding of animated texture frames 
Great Thanks 
I wasn't aware trenchbroom also had an issue with no-brush func's. It's a common error with worldcraft levels so hopefully the same fix here will also serve for that editor.

Something to be added to an error checking / entity management system in later TB editions possibly. 
Yeah, it wasn't just no-brush func's, but I had a bug in my qbsp where if the func_group or func_detail had only liquids (and no solids) the brush list would become corrupted (brushes would go "missing" during the compile. 
@sock: You want to test this quick hack up of Q2 map compatibility? No extra command line needed, it will just ignore the extra fields and texture paths: 
So all I was doing rebuilding areas was changing the brush order in the map file.

Good to know it's fixed, hope to wrap this one up starting next week and have a few other ideas to get done. 
So all I was doing rebuilding areas was changing the brush order in the map file.

Good to know it's fixed, hope to wrap this one up starting next week and have a few other ideas to get done. 
So all I was doing rebuilding areas was changing the brush order in the map file.

Good to know it's fixed, hope to wrap this one up starting next week and have a few other ideas to get done. 
So Now Public Buses 
In England have wifi. Shame it's a bit patchy. 
T-t-t-triple Post! 
Triple Post 
Just like the buses, you wait for ages then three come along at once. 
@sock: You want to test this quick hack up of Q2 map compatibility? No extra command line needed, it will just ignore the extra fields and texture paths
It works a treat, thank you. :) I wanted to test the -forcegoodtree parameter and it does indeed make the marksurfaces lower.

Original - 39768 marksurfaces 79536
New - 40166 marksurfaces 80332
New + fgt - 37811 marksurfaces 75622
Here is the full compiler stats. 
Great, thanks sock. 
I'm using tyr-glquake.exe or tyr-quake.exe, with the DP 'BSP2' format from the new compiler. Version of the engine is .61 1175. qbsp is 0.13.

The engine throws a 'not version 29' error when I try to load the map.

Think I'm gonna download tyrutils 0.12.....

Shame because the map took 520 seconds to compile (just qbsp) :P

I still cannot believe it doesn't throw warnings. Or do I need -verbose for that..... 
Or Do I Just Need To Use -2psb? 
Gonna check..... 
Doesn't work with -2psb. How do I force RMQBSP2? 
Sorry, the compiler doesn't do 2PSB format anymore - I'll upload a new TyrQuake snapshot for you that will load the BSP2 format.

Might look at supporting a -2psb command line option for qbsp also, but probably better to use the -bsp2 and I'll fix the engine. 
TyrQuake With (DP Style) BSP2 Support 
Snapshot version 0.61-1221 uploaded here:

Win32 and Mac OS X.

One of these days I'll have to do a proper release! 
I haven't actually tested that Windows build, but it should be okay. 
OK Cool 
Here goes nothin.... 

I understand that feature-bloat is a bad thing and all, but ATM RMQe is the only Fitz-branch engine with any kind of BSP2 going on. I can only speak for myself here, but I would really love the feature right now. The main reason being that I want to us MHAguireLight to do the light, and it won't work on V29 maps. I just love AguireLight, and now we have lit support with it, I was so made up when we hit that milestone.

Having said that, I'm still keen on using Tyrquake. And I'm really impressed with the QBSP. It seems really stable to me. I'm so used to having trouble compiling huge maps, but this compiler has blown me away. And I haven't tried your light tool for ages either, but I guess the entities are set up differently to Aguires.....?

One quuestion - does it support the -extra4 level of resolution? And the really cheeky question - does it do dynamic (flickering etc) coloured lights? I seem to remember that RMQe + MHAguireLight would actually do that stuff. But I'm not and engine or tools guy, other that using them heh.

Now, where was I.... 
That Snapshot Works 
Changing the resolution and applying full screen from the menu caused no textures to be drawn, I could only see the shading on the gun. everything else (including the menu) was flat grey.

Launching from command line with the resolution and fullscreen applied worked fine. I cant remember the cvars to apply texture filtering. I prefer the blurry bilinear type texture effect. Lit files not working (were they supposed to be?), no aspect-ratio correction stuff (especially on the weapon).

I decided that what I'm going to do (for now) is use TyrQBSP v0.11 to compile my map, and hopefully I can use MHAguireLight to light it, and run it in RMQe. To me that is going to be the most Fitz-like experience. Baker? 
Maybe Someone Could Hack DPstyle BSP2 Support Into 
MHAguireLight. Maybe MH would do it? Que Sera Sera.

Then that can be a standard and FitzQuake MkV will also support it and all will be perfect and centered in the universe again 
Well I Can Confirm That The Following Combo Works 
TyrQBSPv0.11 + MHAguireLight + RMQe

And I LOVE it! 
Yeah, lots of unfinished stuff in TyrQuake. Resolution changing is only partly done - I really need to finish that off.

I'll get another build of qbsp up with -2psb support. 
TyrUtils V0.14 
Qbsp can now parse Quake 2 map format - you still need your textures in WAD format, but qbsp will automatically strip the leading path from the texture name and ignore the extra surface attributes that are not used by Quake. And by popular demand, we can now output RMQ style BSP2 ("2PSB") format bsp files again with the -2psb command line.

TyrUtils v0.14 changes:

* qbsp: Added Quake 2 map compatibility
* qbsp: Add -2psb option to output in RMQ compatible BSP2 format

Download from the utils page as usual (Win32 / OSX / source). 
@RickyT23: my light util has most things that are provided by the bjp tools - give it a try and see if it does what you need. Check the docs to see which options and keys are available. 
I'll try the light tool too :) 
Fantasic Stuff, But A Small Problem 
This is great news that you have added RMQ BSP2 support for Tyrqbsp. However, there is one crucial feature that crashes v14 of tyrqbsp before it even begins, fence textures, or alpha masked textures.

If tyrqbsp finds any texture in the map that starts with the { character, is stops operation and results in an error of:

************ ERROR ************
Internal error: didn't allocate enough entities?


************ ERROR ************
Internal error: didn't allocate enough brushes?

depending upon the map. I've done various tests and concluded the result of this error is in fact the cause of having just one texture starting with the { character, which any alpha masked texture must start with to be rendered properly by RMQ etc.

Surely this is an easy fix? 
Doesn't support these yet either.

I haven't investigated any code or anything - what was the reason for using opening brace? This seems to be the cause of most of the problems.

Lame question, seeing as how close I was to the development of the format, but why not use a neutral / unused symbol, like @ or something... 
TrenchBroom Does Allow Them 
but only if you enclose the texture name in quotes. 
Double Quotes 
to be precise: " 
Return Of The { 
seriously... that curly brace is causing more trouble than it's worth! 
Good To Know :) 
Damn, Missed That Opportunity :{ 
Yeah, { Not Difficult 
@Orl: Does this snapshot work for you? If not, can you email me a test map + wad?

Snapshot tyrutils-0.14-1-ge8d1f59: Win32 and Mac OS X
Yes Sir 
Indeed it does Tyrann, works perfect. :) 
Tyrann, if you get bored, might be an idea to generate some hexen2 variants (primarily for bsp2 support) too.
I don't personally make maps, but I'm sure someone would appreciate it... eventually...
(hexen2 burns through clipnodes much faster). 
like Spike said, if it became possible to use BSP2 with Hexen 2, then I could finish this hexen 2 map

Had to shelf it in frustration months ago because of bsp limit. 
Not sure that any H2 engines support a BSP2 format yet? Might not be too much work to hack it into uHexenII - haven't looked at that project in a long time. Anyone got some pointers to info on the H2 bsp format(s)? 
the stuff on your blog always looks awesome. I really like the look of that Hexen 2 map, especially the wooden stuff. Also seeing more shots of your e1m2-based map is great (I like the idea of adding an outside/location to the original map). 
FTE theoretically does. Both bsp2 and 2psb variants, as well as the h2 tweeks. I don't see any reason why it would fail to work properly, but this particular usage is untested hence my usage of the word 'theoretically'.
The hope is that the other engines will eventually gain support once there are actually maps that use it (that they can test against), as its not too hard to add support to an engine (I really ought to provide a more usable diff in that markv zip).

Basically, max_map_hulls is 8 instead of 4, with 6 hulls used instead of 3.

Here's the hull size list you'd need to generate:
0 0 0, 0 0 0 (render hull, exactly the same as quake)
-16 -16 -24, 16 16 32 (player hull, exactly the same as quake)
-24 -24 -20, 24 24 20 (no longer the shambler hull)
-16 -16 -12, 16 16 16
-8 -8 -8, 8 8 8
-48 -48 -50, 48 48 50

The .map format can be different, the extra fields can be ignored I believe. This doesn't affect the output, but is a tweak you might need for the map parser if you don't already support that. 
That's a lot of hulls! There's the answer as to where all the clipnodes go ;)

No promises, but I'll play around with it and see what I can do. 
High Marksurfaces 
Tried v0.14 tonight out of curiosity. At first I thought -forcegoodtree just wasn't working:

txqbsp_xt -forcegoodtree 31815 marksurfaces
tyrqbsp -forcegoodtree 33242 marksurfaces

Then I ran them both without -forcegoodtree:

txqbsp_xt 33205 marksurfaces
tyrqbsp 34644 marksurfaces

There is an almost identical decrease in marksurfaces (1402 vs 1390) between the two versions, but in both cases the marksurfaces with Tyrutils v.14 is almost 5% higher.

Any idea as to why? 
Looking at the full output of both qbsp compilers might give me some clues. 
Here You Go 
---- qbsp / TyrUtils v0.14 ----
Input file:
Output file: wishtest.bsp

---- LoadMapFile ----
33522 faces
5670 brushes
1981 entities
200 unique texnames
2624 texinfo

Opened WAD: C:QuakeID1Wish13.wad
Processing hull 0...
---- Brush_LoadEntity ----
5190 brushes
---- CSGFaces ----
30614 brushfaces
25596 csgfaces
21931 mergedfaces
---- SolidBSP ----
16691 split nodes
7609 solid leafs
8639 empty leafs
444 water leafs
43368 leaffaces
35821 nodefaces
---- Portalize ----
9083 vis leafs
9083 vis clusters
29991 vis portals
---- FillOutside ----
2796 outleafs
---- MergeAll ----
17258 mergefaces
---- SolidBSP ----
11831 split nodes
6183 solid leafs
5264 empty leafs
385 water leafs
30076 leaffaces
23920 nodefaces
---- Portalize ----
5649 vis leafs
5649 vis clusters
17062 vis portals
---- Tjunc ----
24194 world edges
82878 edge points
18203 edges added by tjunctions
0 faces added by tjunctions
---- MakeFaceEdges ----
---- GrowRegions ----
Processing hull 1...
Processing hull 2...
---- WriteBSPFile ----
11250 planes 225000
33723 vertexes 404676
13866 nodes 332784
2624 texinfo 104960
26876 faces 537520
31194 clipnodes 249552
7404 leafs 207312
33340 marksurfaces 66680
122760 surfedges 491040
62456 edges 249824
207 textures 2256512
lightdata 0
visdata 0
entdata 237337

36.769 seconds elapsed
Peak memory usage: 122568632 (116.9M)

TxQBSP 1.13 ( XT build 260513 ) -- Modified by Bengt Jardrup
-- Further mods by Baker, mh, rebb
-- Original Detail/Hint code by Alexander Malmberg <>

Outputfile: wishtest.bsp

------ LoadMapFile ------
Title: "Wish 13"
33522 faces
5670 brushes (0 detail)

1981 entities
199 miptex
2581 texinfo
Added 8 texture frames

Building hulls sequentially...
Processing hull 0...

------ Brush_LoadEntity ------
5190 brushes read
------ CSGFaces ------
30614 brushfaces
24947 csgfaces
21726 mergedfaces
------ SolidBSP ------
17511 split nodes
8060 solid leafs
8976 empty leafs
476 water leafs
43873 leaffaces
37058 nodefaces
------ FillOutside ------
2939 outleafs
------ MergeAll ------
17058 mergefaces
------ SolidBSP ------
11628 split nodes
6158 solid leafs
5096 empty leafs
375 water leafs
29088 leaffaces
23295 nodefaces
----- Portalize Detail ----

5471 vis leafs
16536 vis portals
5471 real leafs
------ Tjunc ------
23802 world edges
80823 edge points
17496 edges added by tjunctions
0 faces added by tjunctions
------ MakeFaceEdges ------
------ GrowRegions ------
Processing hull 1...
------ MergeAll ------
15451 mergefaces
Processing hull 2...
------ MergeAll ------
12962 mergefaces

------ FinishBSPFile ------
WriteBSPFile: wishtest.bsp
11245 planes 224900
32578 vertexes 390936
13677 nodes 328248
2581 texinfo 103240
26122 faces 522440
24351 clipnodes 194808
7228 leafs 202384
32163 marksurfaces 64326
119052 surfedges 476208
61322 edges 245288
207 textures 2256512
lightdata 0
visdata 0
entdata 237337

Skipped 0 surfaces

Elapsed time : 1:20.32

Peak memory used : 42.9 MB 
The difference in texinfo counts looks suspicious to me, I might start looking there. 
It's Probably Not That Important 
Marksurfaces being 5% higher seems like a lot and it's odd that there's much difference at all, but I think I'm probably the only one here that even cares how high they are. I'll be fine with txqbsp_xt for this map. 
Rick, the increase of marksurfaces can often fluctuate because of the map file. Some editors reverse the saving order of brushes, entities and groups each time they save. Marksurfaces is extremely sensitive to the order in the map file.

I used 0.14 for my latest map zendar and I could not get goodtree or onlyents to work properly. Whenever I tried to compile with the goodtree option I would get endless leaks through solid brushes throughout the map. These tools are not 100% reliable just yet. 
Yeah, But 
That's the same exact map file, just two different qbsp exes, no editor touched it or re-saved it between compiles. That's why I found it strange.

Netradiant seems to be pretty good about not screwing up things from one save to another. Usually, just changing brushes doesn't affect the marksurfaces too much. Only when adding or deleting brushes do I see large differences. 
Brush order in the actual map file seems to have big influence on msf count.

Cutting out parts of the geometry and pasting them back in after saving the file, can effect in some reduction of the numbers, if this is done "room by room".

Problems occur when maps are not made totally out of connnected boxes or "rooms", zendar or my latest map comes to mind. Forcegoodtree did not work for me too:) 
My �4.50 
Why restrict yourself to 1996 limitations?

I get it, but from the screens you've been posting Rick I suspect you're procrastinating over your level too much. I'm all in favour of making YOUR level, but, hopefully without being a cunt, I think you've gone into tweaking overdrive.

If you love it, let it go.

And then learn from it. 
It's Actually Pretty Much Done 
Has been since probably November. I was just trying the new utils. All I've really done in the last few months is lighting and monster placement and a couple of new textures. Marksurfaces are fine now with txqbsp_xt, a little lower than they were in November actually.

I long ago came to the conclusion that I was never going to be completely happy with it, even if I worked on it for another two years (which isn't gonna happen).

I was hoping to release it sometime in December, but ran into a minor issue and was delayed by the Holidays. I've actually been ignoring it for the last week or so. There's one more thing I want to try, but after that... 
I can't understand how func_detail work. Change someting if I will transform some brushes into func_detail?
Do it reduce time for vis process? 
Basically func detail brushwork is ignored by everything apart from the vis tool. So almost everything which isn't sealing the void or subdividing your level should probably be detail brushes - unless it's a func of course. 
And when the vis tool detects detail brushwork it doesn't include it in the vis calculation. 
And when the vis tool detects detail brushwork it doesn't include it in the vis calculation. 
A new version is out! 
1. The BSP compiler ignores func_detail brushes when calculating the BSP tree for the VIS compiler to use, then it removes the entity information from the brush(es) making just another solid brush.

2. The LIGHT compiler sees it as a solid, end of story.

3. The VIS compiler doesn't see it because the BSP compiler never included it in the BSP tree calculations that vis uses to do its thing.

Try using the skip texture on it just to see something "Special" (or rather not see it). You will get an invisible brush that will cast a shadow. 
light with _color property not lit. Why? 
try color without the underscore. 
No, it turned out a different format from 0 to 255. I used to use from 0 to 1 
light format "_color" "255 255 255" worked, but not compatible with NetRadiant. Light entity looks like white light. 
255 255 255 IS white. try 255 0 0, does that display red? 
I mean the format of the parameter. No, "255 0 0" display as white. NetRadiant worked for format "_color" "0-1 0-1 0-1" 
No Underscore? 
in documentation with underscore 
Working For Me Without. 
No joke. 
Both Work Here 
I am using Tyrutils-0.15 and both properties work for me to give colored light. That is, I can either write the word color with or without an underscore and the results look identical to me. The numbers have to be in range from 0 to 255.

I just tested this with this example line inside a light entity declaration:

"color" "255 10 10" // it's a red light now

The light program produces a .lit file when I use the color properties in a map file, and I need to copy the .lit file alongside the .bsp file into the same directory for loading into a Quake engine. If I omit the .lit file I still get the lights in the map, but they are always white.

I'm using the most recent release version of Darkplaces to test the map & the lighting. I hope this clarified things for anyone having issues. 
Degenerate Edge Error 
This is a problem aimed specifically at tyrqbsp, so I would assume only Tyrann would know the answer to it, but if anyone else ever experienced the same problem or have any info regarding it, feel free to chime in.

My current map in progress, when sealed, produces a bogus error at the TJUNC stage of compiling with the message of:

---- Tjunc ----
************ ERROR ************
Degenerate edge at (0.000 0.000 0.000)

I really don't know what to make of this error, since the origin 0 0 0 of the map is located in the void. Curiously enough, when the map is unsealed it compiles without any error.

So without knowing what and where to look for the problem, I've hit a roadblock. I have sent you, Tyrann, a much more detailed description of this problem several days ago, but haven't gotten a response back, and figured perhaps you might see it here first.

I am using the latest version of tyrqbsp, along with Jackhammer as my editor. I am more than willing to provide you the .map file so that you may take a closer inspection of what the problem might be.

Or I suppose you can do what TxQbsp does and treat degenerate edges as warnings instead of errors. But I'd first like to hear your thoughts on what this error might mean, and what steps I can take to fix it. 
First Thought 
If it's at the origin and you haven't placed any brushes in that area, my guess would be that it's a rogue brush with zero size generated by the editor by mistake. Most editors have something that will check for problems like this and allow you to delete the offending brush. 
Most editors have something that will create brushes like this. 
Here are builds with two experimental features - these are unofficial, not approved by Tyrann or anything :)
-dirt support
-0-1 color format support

Plus some older fixes that are already in tyrutils git:
-lightmap coordinates fix for 64-bit binaries (only affects mac or linux builds)
-fix for writing a corrupted bsp when using wad3 (halflife) textures

win32 osx source 
awesome! thanks ericw! 
Thanks Ericw! 
But I have a question. There was a bit of talk about doing some sort of radiosity with light.exe in quake when you first came up with the -dirt idea and it got me to thinking. Is it possible to do one or more of the following:

1) An invisible "Light" brush. I get that it "Can" cause problems with multiple faces and light types if it gets too big and it probably shouldn't be used with anything but a solid light (no flickering, throbbing or maybe even switchable). It works with _sunlight so I was wondering if it was possible to translate that over to other textures or if because of how sky is displayed that's too far afield.

2) A sort of "Fake" radiosity tied to specific textures like *lava and *slime by default. The way most engines handles liquids makes it look a bit off when it's in a dark location. Maybe even instead of default textures (like *lava or *slime) a way to set up a user created data file.txt that specifies specific textures that act like a "Light" brush above during the compile process).

Only spitballing here so feel free to ignore it. 
How About 
specifying light emitting textures? Defined by a text file given to the commandline. With all wait/delay functionality. Would help making spotlights for example. Just an idea. 
sounds like a great feature idea.
I could see either a command-line flag like "-lighttexture {texture light r g b wait delay}" or something, or having a list of these in a text file.
The quake2 light tool has it, (I think it's set as a surface flag?), and at first glance it seems to be intertwined with the radiosity support. It'd definitely be a bigger project than adding the -dirt was, but would be cool to do (as well as having radiosity) 
Give Q1rad A Try 
It's Cool 
I think i used that on my first map.. but it's old, the source isn't available, and the readme says it's derived from Valve's q1rad so it woudn't be possible to combine with a modern gpl quake1 tool anyway.

The quake2 qrad3 is GPL'ed though: 
"Fake" Radiosity Tied To Specific Textures Like *lava And *slime By De 
I implemented this in the last version of MHColour, but instead of emitting light the radiosity was used to tint the already existing light data. It's easy enough to do and you can just butcher the code and get something that works up and running quick enough. 
I looked at that and while it sort of does the job there is no control over it (re specific textures for example) specifically because it "Does" use pre-existing lights. The user also can't specify any textures to ignore or add.

It worked pretty well for generating .lit files for .bsps where the source files weren't available but quite honestly the hues and intensity of the colors weren't really to my liking about 80% of the time. Too much like Q2. As I've said before with Quake and colored lights, less is almost always more. It ain't the Las Vegas Strip. It's what you might find deep underneath the Las Vegas Strip after a bad night out.

I was thinking of something that didn't use a light entity (in the traditional sense) at all but turned the top face (or any face exposed to "Air" I suppose) of a brush into a light all by itself. 
In fairness that's all it ever really set out to do. The last version was a good deal more subtle than earlier versions, but I'd guess about 50% of users preferred the stronger colouring.

In general I agree - mapper control of lighting in the tools and at the compilation stage is the correct way to go, and MHColour was never meant to be a replacement for that.

Despite all the above the theory is still applicable - it's just tracing the BSP between points, then checking distance and facing, after all. 
I'm pretty sure nobody's mentioned this yet.

So I tried out the fancy hacked dirtmapping and got this:

That's looking at the corner of a room. The diagonally opposite corner looks correct, and the two remaining corners are wrong on one plane or the other, almost as if the sample points are off by one in a positive-axis direction. 
Hm Weird 
I also get some problems with a box map:
-lit -dirty -dirtdebug:
-lit -dirty -dirtdebug -extra4:
Quakespasm is hacked to show lightmaps with nearest-neighbour filtering.

One issue is, even with extra4, the left and right walls don't get any significant dirt applied at the edge with the back wall. Will look into it.. 
This might be related to some other problems I've been having for a while with tyrlight. Here's just sunlight, no dirt:

Opposite corner from my previous screenshot. Note that those blocks are not floating.

I would really like to say when I started seeing this kind of thing, because I know it happened after I tried to get the latest compilers six or eight months ago, but I've tried to reproduce the collection I had before that and I still get those gaps and bleeds, so I can't actually prove it's a change in some compiler that's done it.

eric, what are you BSPing with? Do you think it matters? Utter conjecture here, but could some subtle difference in point quantization or double rounding in the BSP phase cause the lightmap sample origins to fall on the wrong side of a face or become coincident with an edge in a microscopically unhealthy way? 
p.s. the poorly shadowed corner in 0061 is the -x,-y corner, and in 0063 it's the +x,+y corner. 
Thanks Lun 
I think I understand the dirtmapping glitches on my box room, at least. The problem seems to be the raytracing code in tyrutils is unreliable when sample points lie exactly on a plane separating the void from the map interior. (but unreliable in a consistent way, so in some directions it works) Unfortunately, you get these quite a lot of these void-straddling points with the way the sample points are positioned:
The sample points for the west wall of a box room, for example, are distributed in a grid that's pushed 1 unit into the middle of the room, so most of the points are free-floating in the map interior as desired. The problem is, the columns of points on the north and south edges lie exactly in the plane of the north and south walls, and same goes for the row of points along the floor and ceiling.

The one thing I tried as a fix, which is admittedly a coarse-grained fix, was replacing the trace code with LordHavoc's from his hmap2 compiler, which seemed to magically fix the dirtmapping glitches. It seems it can consistently deal with sample points straddling the void and treat them as within the map, which would be good.

Could you send me the map for 0063.jpg? (or just that section of it?) I'd like to see if I can fix that bleeding is the same way as the dirtmapping glitches.

For bsp I'm using snapshot I posted in #113, osx version. I don't think that's a factor, though I can double check on windows. 
Another Snapshot With Fixed AO 
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. 
Screenshot Of Jam2_sock 
Ericw For President Of Space 

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:

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

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

And a random shot: 
Love That Second Shot! 
Hmm, the floor under the chain in the middle shot looks a bit odd.

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 ...

And no, this won't be finished for the jam. :) 
Looks Fine Here 
Seems to just be shadows from the chain! 
Lovely Stuff Warren! 
Hmmm wonder what my map would look like with this AO pass now... 
God Damn 
that is some sexy looking dirty brushwork! 
Is very nice. The lighting and shadows are very believable. Maybe we need an "ikebony" type texture set. 
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* 
E4M3rmx_lun Confirmed 
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 ... 
Willem, Is Your Computer In Your Yard? 
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? :) 
After Experimenting With The Compilers And Lighting Tricks... 
Holy Crap! 
Ericw Please Enable Antialiasing By Default 
Looks inviting :)

What compilers and settings did you use? 
"Please Enable Antialiasing By Default " 
does typing -extra4 take that long? 
That Too 
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. 
For Surface Lights: 
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. 
Sleep Puts Everything In TB 
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. 
TB1 Doesn't Support Quake 2 
Yeah I Saw That 
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. 
@ Generic 
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. 
Thanks, Quaddy! 
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. 
I Was Thinking... 
...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! 
That's All I Meant 
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.

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. 
Fun Fact For Czg 
"ogier" is Polish for "stallion" 
You Know That Worldcraft Has 'advanced Search Tools' 
for entities. Map->Entity Report

You can bulk-edit keys n stuff. 
Dirty And Lights In Alcoves 
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)

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. 
The AO Approach In Q3Map2 2.5.16 
.. 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. 
Very Interesting 
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. 
Working On This Now 
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. 
Another Issue 
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. 
Hey Gb 
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:

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. 

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.


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. 
Cognitive Dissonance Much? 
But I understand that you guys would rather die than give up Fitzquake


You're as tactful as a rhino. 
I Never Played Anything With Bsp2... 
...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. 
Also Random Note For Gb 
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. 
_sunlight2 + 1 
It really helps soften those hard shadows. 
New Snapshot 
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 
Thanks Eric 
Zer Progs!??? 
Yes it would be better to have it opt-in. Just activate it on certain lights. 
Yes Zer Progs!! 
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. 
Perhaps A Worldspawn Default... 
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:

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 
Ericw Beat Me To It 
yeah I like your 1/-1 idea 
That seems the better option. Looking forward to messing about with this. 
Ericw +1 
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 Should Just Get A Github Account Already 
That Reminds Me 
I put my code up on github:
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. 
New Experimental Builds 

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! 
Woot, Sir 
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? 
Testing Out The Lighting Now... 
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 
Could You 
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

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? 
Oh Ok 
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. 
Compiles Slow But It Looks Great... 
how is the tree casting a shadow if it's a model? 
_shadows 1. 
Could be anti-lights, or skip textured invisibrush 
MFX Wins 
it's a func_wall with a skip texture and _shadows 1. 
Light Thoughts 
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. 
High Resolution Lightmaps 
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. 
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. 
BTW Lunaran 
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! 
BSP Split Priority 
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)

cd c:\\mapping
light.exe -dirt e1m1.bsp
those double slashes should just be one slash 
cd:\\\\\\\\\mapping\\\\\light.exe \\\\\ 
To Expand On Ericw's Post 
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. 
Minor Update 
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. 
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...). 
Ooh Cool! 
About That Bug 
"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:

Lines drawn to highlight ugly areas:

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? 
Oh, Sorry 
I guess this isn't really the right thread for it. ericw's light works ok btw. 
Qbsp Subdividing Wierdness 
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? 
GOT 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). 
Tyrann's Qbsp 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): 
Test Map. 
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:

.BSP File (Looks awful! and I don't mean just the texturing):

Compile Log:

P.S. The percentages have a newline for every % or something, FYI. 
Also, when I say undefined face alignment, I mean arbitrarily aligned: 
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?

Excerpt from my compile log:
$ ~/dev/tyrutils/bin/qbsp -bsp2
---- 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:
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...". 
April 17 TyrUtils-ericw Snapshot 
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

* 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"

* all: increase stack size to 8MB. Fixes qbsp crash with 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 (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. 
Thank You Sir! 
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 in line with txqbsp-xt (as well as improving leaf/node counts close to what txqbsp-xt gets), but they also caused 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. 
Holy Crap! 
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? 
Surface Lights Screenshot

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... 
Glad To Hear It 
Minor Qbsp Update 
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 :) 

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. 
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. 
May 1 Update
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 ;) 
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 
Radiant Ent For Tyrutils .15 
I turned the entire tyrutils docs into a radiant ent for q1.

I also posted the source of the individual ent lists that I created from the docs.

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? 
I Don't Drink But Cheers Anyway :) 
@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. 
Wild Hair Executed

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. 
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. 
Here Ya Go

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. 
What If I Made A GUI For Eric's Tool Chain? 
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.

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: 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 
If Social Reassurance Drives You, Announcements Fuel Motivation 
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. 
Le Sigh... 
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. 
Ayy Lmao 
If anyone wants to play with it, I posted some alpha builds over at inside3d at the bottom of the first post:

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. 
jam2_sock relit with "-lightmapscale 0.25 -extra" (so 4x vanilla resolution) 
Screenshots - 
1x res

2x res

16x res

textured comparison, 1x res and 16x res

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

seems we hit some limits here? 
Couple Of Notes 
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! 
Oh, Sweet! 
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. 
Fifth's Textured Shot 
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 

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? 
It Should Work 
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 and not saving as 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. 
Nah Brah 
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. 
Cool Stuff There Scamps 
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? 
Area Light Support? 
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. 
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. 
Alright Hitler 
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. 
After Testing 
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 - (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 - - 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. 
Multiple Lights For Skies 
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 
No Need For A Decompiler... 
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. 
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. 
Area 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. 
Area Lights 
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 
You Mean 4xAM 
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. 
DM2 Link? 
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....

warren: yeah, sorry... my monitor apparently doesn't look like anyone else's and my screenshots always come out too dark :| 
Ok Here's An Idea 
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.

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. 
Lightmapped Liquids 
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: 
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?

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 
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

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. 
Oh, Duh, Of Course :D 
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? 
Oh, Duh, Of Course :D 
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? 
Oh, Duh, Of Course :D 
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. 
Other Options 
-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:
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. 
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! 
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. 
Oh, Duh, Of Course :D 
How About Letting Lightmap Intensity Determine Water Alpha 
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... 
I Thought... 
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. 
Thats Cool 
I do hope this is something that gets implemented then, fullbright water is crap. 
That Left 4 Dead Texture 
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? 
Ok I Made A Doodie
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:

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"

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 
"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.
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 Like It. 
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. 
Blowing Dust Off From My Mad Mapping Skillz In Jackhammer 
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: 
Quick fix for geometry, small changes for light and texturing: 
I think you're in the wrong thread. :) 
You must be logged in to post in this thread.
Website copyright © 2002-2019 John Fitzgibbons. All posts are copyright their respective authors.